День добрый! Ранее работа с новой прошивкой, вопрос не решен < Ссылка
Продолжаем исследовать новые проблемы.
WB7 7.3.3E, wb-2304, stable, s/n AVZOK2XH
Вчера ни с того ни с чего перестало обновляться правило получения и конвертирования данных со счетчиков MAP. Данные зависли на одном значении и не двигаются. При этом данные с физического модуля обновляются. В логах >100 сообщений в секунду о “failed to convert value ‘’, passing raw, error: This control is incomplete”
при чем по всем устройствам (встроенным в WB и подключенным), но не обновляются только счетчики ЭЭ. При этом в каналах MQTT статус по этим контролам - ОК.
При перезапуске контроллера ситуация не меняется.
При systemctl restart wb-rules не помогает.
Помогает удалить правила из папки, а затем заново их добавить туда. И тогда правила начинают работать. При следующей перезагрузке ситуация повторяется. wb-rules_20230704T083026.log (214,5 КБ)
Обзор по логу:
удалил/добавил файлы, 2023-07-04T05:25:47.983Z
посмотрел что данные начали обновляться, ~20 сек (сообщения INFO прекратились)
Решил обновить пакеты в контроллеры. Проблема ушла, правила начали работать.
Но ошибка осталась в логах. “failed to convert value ‘’, passing raw, error: This control is incomplete”
Стал доступен раздел обновления прошивки.
Список обновленных пакетов (apt update, apt upgrade)
Драйвер начал создавать контролы устройств в Jul 04 09:37:05
Приведенное вами сообщение из лога буквально переводтся как “Контрол незакончен”. То есть возникает имено при попытке обработать контрол в процессе создания. Я считаю поведение ожидаемым.
Вотрая перезагрузка сервиса wb-mqtt-gpio - в 09:56. С аналогичным поведением.
Напишите пожалуйста какое поведение было бы правильным.
Судя по логу контроллер не успевает инициализировать устройства и wb-rules пытается получить информацию с них. Соответственно и ошибки
ERROR: [rule error] Error in getting device: Device with given ID doesn’t exist
failed to convert value ‘’, passing raw, error: This control is incomplete
Правильно было бы ждать некого сигнала о загрузке устройств или ответа самих устройств или timeout ответа от устройств.
Я не могу понять с чего вдруг появилась такая проблема?
Так если устройство будет (когда-то) создано - да, можно обрабатывать и его создание и удаление. Если не обрабатывать специально - то естественно про отсутствие устройства будут сообщения.
Устройство к которому обращается скрипт - отсутствует…
День добрый!
Видео с проблемой [wb-mqtt-serial] ERROR: [serial client] Serial protocol error: IP:23 connect error: No route to host (113)
Снова же проблема появилась на ровном месте.
Проблема на контроллере WB7 7.3.3E, wb-2304, stable, s/n AP5CRMOL
На контроллерах ниже все ок.
WB7 7.3.3E, wb-2304, stable, s/n AVZOK2XH
WB7 7.3.3E, wb-2207, stable, s/n AP72NKRI
На видео модуль WB-MIO-E v.2 был подключен к контроллеру AP5CRMOL, недавно появилась ошибка;
подключаем к контроллеру AVZOK2XH, ошибка [wb-mqtt-serial] WARNING: <192.168.2.144:23>: closed due to repetetive errors;
подключаем к контроллеру AP72NKRI - все ок, все работает;
снова подключаем к контроллеру AVZOK2XH - все ок, все работает;
снова подключаем к контроллеру AP5CRMOL - ошибка [wb-mqtt-serial] ERROR: [serial client] Serial protocol error: IP:23 connect error: No route to host (113);
Ко всему остальному я уже все контроллеры вынес в менее жаркое место, что видно на видео. Зарядки нет.
Все контроллеры имеют одинаковые настройки сети с одинаковым mask, gw и dns.
Контроллеры имеют одинаковую версию обновления apt.
WB7 7.3.3E, wb-2304, stable, s/n AP5CRMOL
WB7 7.3.3E, wb-2304, stable, s/n AVZOK2XH
Следующий момент:
Контроллер WB7 7.3.3E, wb-2304, stable, s/n AP5CRMOL
Добавляю новые устройства, например Чиллер (WB-MAI6 через WB-MIO-E v.2). 2 датчика давления и 2 температуры.
После сохранения устройств перестают работать правила. Видно что драйвер перезагружает все устройства, добавляются новые. И данные, из части правил перестают обновляться. Т.е. на графике “флэт”.
Проблема решается service wb-rules restart, но это грабли. Так неправильно и не должно быть.
Контроллер - точно такой жже компьютер за которым мы работаем. С совершенно теми же способами настройки. Абсолютно.
А запущенный ping с тем же адрсом - что возвращает?
Через какой маршрут доступ к целевому адресу? Какой маршрут есть default, какой (если есть) именно в подсеть целевую? Я предполагаю неверные настройки сети.
Каой план сети и маршрутизации в ней?
Сейчас батарея имеет критически малый заряд. Какое время она уже заряжается?
Да, соглашусь. А как реализовано в правилах чтение устройст? Есть ли что-то динамически добавляемое?
Возможно, какой-то минимальный пример, воспроизводящий поведение?
Кстати, если перезапустить wb-mqtt-serial - первое опубликованное в mqtt значение энергии от счетчиков - тоже некорректно?
Пришлите пожалуйста файл /var/lib/wb-mqtt-serial/libwbmqtt.db с контроллера.
Да, соглашусь. А как реализовано в правилах чтение устройст? Есть ли что-то динамически добавляемое?
Возможно, какой-то минимальный пример, воспроизводящий поведение?
PING 192.168.2.144 (192.168.2.144) 56(84) bytes of data.
From 192.168.2.133 icmp_seq=1 Destination Host Unreachable
From 192.168.2.133 icmp_seq=2 Destination Host Unreachable
From 192.168.2.133 icmp_seq=3 Destination Host Unreachable
traceroute 192.168.2.144
traceroute to 192.168.2.144 (192.168.2.144), 30 hops max, 60 byte packets
1 wirenboard-AP5CRMOL.local (192.168.2.133) 3122.103 ms !H 3121.850 ms !H 3121.685 ms !H
WB7 7.3.3E, wb-2304, stable, s/n AVZOK2XH
ping 192.168.2.144
PING 192.168.2.144 (192.168.2.144) 56(84) bytes of data.
64 bytes from 192.168.2.144: icmp_seq=1 ttl=255 time=1.08 ms
64 bytes from 192.168.2.144: icmp_seq=2 ttl=255 time=1.60 ms
64 bytes from 192.168.2.144: icmp_seq=3 ttl=255 time=4.51 ms
64 bytes from 192.168.2.144: icmp_seq=4 ttl=255 time=9.43 ms
PING 192.168.2.144 (192.168.2.144) 56(84) bytes of data.
64 bytes from 192.168.2.144: icmp_seq=1 ttl=255 time=1055 ms
64 bytes from 192.168.2.144: icmp_seq=2 ttl=255 time=35.5 ms
64 bytes from 192.168.2.144: icmp_seq=3 ttl=255 time=2.65 ms
64 bytes from 192.168.2.144: icmp_seq=4 ttl=255 time=1.74 ms
traceroute 192.168.2.144
traceroute to 192.168.2.144 (192.168.2.144), 30 hops max, 60 byte packets
1 wirenboard-AP72NKRI.local (192.168.2.132) 3151.652 ms !H 3151.488 ms !H 3151.431 ms !H
Почему ответ контроллер приходит от узла 192.168.2.133 ?
Ну потому что любое устройство с назначенным адресом при отсутствии ответа от целевого устройства (или несуществующего) будет давать ответ от себя что адрес недоступен. Это нормальное поведение в любой системе. Проверьте у себя. На скрине моя сеть и удаленная сеть, никак не связанная с моей.
