Снова проблема с контроллерами, failed to convert value ‘’, passing raw, error: This control is incomplete

Я вижу что контроллер загружался в

Jul 04 09:37:38

Драйвер начал создавать контролы устройств в 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 ответа от устройств.
Я не могу понять с чего вдруг появилась такая проблема?

Так если устройство будет (когда-то) создано - да, можно обрабатывать и его создание и удаление. Если не обрабатывать специально - то естественно про отсутствие устройства будут сообщения.

Устройство к которому обращается скрипт - отсутствует…

Ответа на самый важный вопрос нет. Все что выше - это следствие.

Даже не знаю что сказать.
Могу попробовать воспроизвести, конечно.
Какой минимальный скрипт и настройки позволит это сделать?

День добрый!
Попробуйте у себя реализовать.
rr.zip (15,3 КБ)

То есть чтобы воспроизвести - надо именно вот такой стенд делать, с меньшим количеством скриптов - не воспроизведется?

Я как раз не готов ответить. Знал бы - решил вопрос самостоятельно)
Т.е. это все работало до какого-то момента, потом началась такая проблема.

День добрый!
Видео с проблемой [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
ls -l /var/lib/apt/periodic/update-stamp

-rw-r–r-- 1 root root 0 Jul 18 03:57 /var/lib/apt/periodic/update-stamp

ls -l /var/lib/apt/periodic/update-stamp

-rw-r–r-- 1 root root 0 Jul 17 05:10 /var/lib/apt/periodic/update-stamp

Следующий момент:
Контроллер 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 с контроллера.

Контроллер - точно такой жже компьютер за которым мы работаем. С совершенно теми же способами настройки. Абсолютно.

Именно поэтому я и выбрал WB

Каой план сети и маршрутизации в ней?

Сейчас батарея имеет критически малый заряд. Какое время она уже заряжается?

Да, соглашусь. А как реализовано в правилах чтение устройст? Есть ли что-то динамически добавляемое?
Возможно, какой-то минимальный пример, воспроизводящий поведение?

Только устройства отсюда. Больше ничего нет пока что)

Кстати, если перезапустить wb-mqtt-serial - первое опубликованное в mqtt значение энергии от счетчиков - тоже некорректно?

Пришлите пожалуйста файл /var/lib/wb-mqtt-serial/libwbmqtt.db с контроллера.

libwbmqtt.db (28 КБ)

На скриншоте вижу ответ от 192.168.2.133. Почему?
Покажите traceroute к этому ж узлу. Ну и лучше все ж текстом, скриншоты чтаются не очень.

Тут совсем все удивительно

  • WB7 7.3.3E, wb-2304, stable, s/n AP5CRMOL
ping 192.168.2.144

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

traceroute 192.168.2.144

traceroute to 192.168.2.144 (192.168.2.144), 30 hops max, 60 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *

  • WB7 7.3.3E, wb-2207, stable, s/n AP72NKRI
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=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

  • Windows
ping 192.168.2.144

Статистика Ping для 192.168.2.144:
Пакетов: отправлено = 21, получено = 21, потеряно = 0
(0% потерь)
Приблизительное время приема-передачи в мс:
Минимальное = 2мсек, Максимальное = 10 мсек, Среднее = 5 мсек

tracert 192.168.2.144

Трассировка маршрута к 192.168.2.144 с максимальным числом прыжков 30
1 * 110 ms 5 ms 192.168.2.144
Трассировка завершена.

  • Скрин
Скрин

Да. Почему ответ контроллер приходит от узла 192.168.2.133?
Если поменть адреса машинок друг с другом - то поведение такое же?

Почему ответ контроллер приходит от узла 192.168.2.133 ?

Ну потому что любое устройство с назначенным адресом при отсутствии ответа от целевого устройства (или несуществующего) будет давать ответ от себя что адрес недоступен. Это нормальное поведение в любой системе. Проверьте у себя. На скрине моя сеть и удаленная сеть, никак не связанная с моей.

Скрин

Разница в контроллерах в сетевом демоне. Как мне его переключить на старую версию, networks? Мне кажется все проблемы оттуда.

Как мне его переключить на старую версию, networks? Мне кажется все проблемы оттуда.

Поотключал все интерфейсы (включая gsm), остался только eth0.
Дропнул Network Manager, и?
На контроллере WB7 7.3.3E, wb-2304, stable, s/n AVZOK2XH стало так же как и на * WB7 7.3.3E, wb-2304, stable, s/n AP5CRMOL
Какие идеи?

SSH

Welcome to Wiren Board 7.3.3 (s/n AVZOK2XH), release wb-2304 (as stable)
Linux wirenboard-AVZOK2XH 5.10.35-wb133+wb101 #1 SMP Mon May 29 08:56:14 UTC 2023 armv7l GNU/Linux

System load: 6.08 1.62 0.55 Up time: 0 min
Memory usage: 19% of 997M Usage of /: 66% of 976M /mnt/data: 30% of 4.9G

8 package updates are available; type ‘apt update && apt upgrade’ to update them.

Last login: Fri Jul 21 06:35:08 2023 from 192.168.5.239
root@wirenboard-AVZOK2XH:~# ping 192.168.2.144
PING 192.168.2.144 (192.168.2.144) 56(84) bytes of data.
From 192.168.2.131 icmp_seq=1 Destination Host Unreachable
From 192.168.2.131 icmp_seq=2 Destination Host Unreachable
From 192.168.2.131 icmp_seq=3 Destination Host Unreachable
From 192.168.2.131 icmp_seq=4 Destination Host Unreachable
From 192.168.2.131 icmp_seq=5 Destination Host Unreachable
^C
— 192.168.2.144 ping statistics —
6 packets transmitted, 0 received, +5 errors, 100% packet loss, time 5166ms
pipe 4
root@wirenboard-AVZOK2XH:~# traceroute 192.168.2.144
traceroute to 192.168.2.144 (192.168.2.144), 30 hops max, 60 byte packets
1 wirenboard-AVZOK2XH.local (192.168.2.131) 2522.729 ms !H 2522.567 ms !H 2522.495 ms !H
root@wirenboard-AVZOK2XH:~#

ifconfig

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.2.131 netmask 255.255.240.0 broadcast 192.168.15.255
ether 00:85:01:01:57:cf txqueuelen 1000 (Ethernet)
RX packets 298782 bytes 21840850 (20.8 MiB)
RX errors 0 dropped 1838 overruns 0 frame 0
TX packets 501522 bytes 57628721 (54.9 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 65 base 0x5000

eth1: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
ether 00:85:01:01:f4:35 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 64

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
loop txqueuelen 1000 (Local Loopback)
RX packets 1167 bytes 65517 (63.9 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1167 bytes 65517 (63.9 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.42.1 netmask 255.255.255.0 broadcast 192.168.42.255
ether c4:3c:b0:5f:d1:24 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 15 bytes 900 (900.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

Спустя 5 минут…
Пока писал предыдущий текст ситуация поменялась

Ping Trace

root@wirenboard-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=8.81 ms
64 bytes from 192.168.2.144: icmp_seq=2 ttl=255 time=2.37 ms
64 bytes from 192.168.2.144: icmp_seq=3 ttl=255 time=3.72 ms
^C
— 192.168.2.144 ping statistics —
3 packets transmitted, 3 received, 0% packet loss, time 2008ms
rtt min/avg/max/mdev = 2.368/4.966/8.813/2.775 ms
root@wirenboard-AVZOK2XH:~# traceroute 192.168.2.144
traceroute to 192.168.2.144 (192.168.2.144), 30 hops max, 60 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
6 *^C

Смотрите на правила на маршрутизаторе.
Просто для примера:

Таблица маршрутизации выглядит так:

ip route
default via 10.0.0.2 dev eth0 proto dhcp src 10.0.0.78 metric 55 
default via 192.168.42.1 dev wlan1 proto dhcp src 192.168.42.184 metric 205 
default dev ppp0 proto static scope link metric 700 
10.0.0.0/24 dev eth0 proto kernel scope link src 10.0.0.78 metric 55 
10.64.64.64 dev ppp0 proto kernel scope link src 10.39.208.175 
192.168.42.0/24 dev wlan1 proto kernel scope link src 192.168.42.184 metric 205 
192.168.42.0/24 dev wlan0 proto kernel scope link src 192.168.42.1 metric 600 

Я хочу проверить маршрут к какому-то узлу расположенному за два маршрутизатора.
Предполагаю - что мне ответит сначала ближайший, тот который описан у меня как default, потом уже по цепочке.

traceroute 10.77.0.114  
traceroute to 10.77.0.114 (10.77.0.114), 30 hops max, 60 byte packets
 1  router.lan (10.0.0.2)  0.433 ms  0.339 ms  0.400 ms
 2  10.78.0.1 (10.78.0.1)  74.879 ms  75.019 ms  75.029 ms
 3  10.77.0.114 (10.77.0.114)  75.050 ms  75.183 ms  74.968 ms

У вас адрес 192.168.2.131 с маской 20.
Прошу прощения, сразу на маску не обратил внимания. Ну и выгляжу довольно глупо, рассуждая про маршрутизацию. Моя вина.
То есть - узлы сегмента сети могут иметь 192.168.0.1 - 192.168.15.254
Естественно что при работе в пределах одного сегмента - пакет не будет отправлен в шлюз а будет попытка определить mac целевого широковещанием.

arp -n

выводит связку ip и mac для целевого (192.168.2.144) хоста?

У вас адрес 192.168.2.131 с маской 20 .
Прошу прощения, сразу на маску не обратил внимания. Ну и выгляжу довольно глупо, рассуждая про маршрутизацию. Моя вина.

Все норм)

выводит связку ip и mac для целевого (192.168.2.144) хоста?

Да.

    • WB7 7.3.3E, wb-2304, stable, s/n AVZOK2XH
arp -n

Address HWtype HWaddress Flags Mask Iface
1.1.1.1 (incomplete) eth1
192.168.5.239 ether a4:97:b1:d7:aa:2b C eth0
192.168.2.144 ether a6:4c:5e:e6:75:47 C eth0
192.168.2.142 ether a6:4c:5e:e6:6b:a5 C eth0
192.168.2.139 ether a6:4c:5e:e6:6c:71 C eth0
192.168.1.253 ether 6c:3b:6b:ee:18:7c C eth0
192.168.1.117 ether 00:15:5d:01:7a:11 C eth0
192.168.2.137 ether a6:4c:5e:e6:36:c5 C eth0
1.1.1.1 (incomplete) wlan0
192.168.1.220 ether 0c:c4:7a:41:26:1e C eth0

Нет.

    • WB7 7.3.3E, wb-2304, stable, s/n AP5CRMOL
arp -n

Address HWtype HWaddress Flags Mask Iface
192.168.5.239 ether a4:97:b1:d7:aa:2b C eth0
192.168.42.80 ether 86:d9:49:34:73:99 C wlan0
192.168.6.28 ether d6:d0:70:08:42:88 C eth0
192.168.1.117 ether 00:15:5d:01:7a:11 C eth0
192.168.2.144 (incomplete) eth0
192.168.2.143 ether a6:4c:5e:e6:6c:6f C eth0
1.1.1.1 (incomplete) wlan1
192.168.1.253 ether 6c:3b:6b:ee:18:7c C eth0
192.168.2.138 ether a6:4c:5e:e6:75:4c C eth0
149.20.4.15 (incomplete) wlan0
192.168.2.141 ether a6:4c:5e:e6:5b:ce C eth0
1.1.1.1 (incomplete) wlan0
1.1.1.1 (incomplete) eth1
130.89.148.77 (incomplete) wlan0
192.168.2.145 ether a6:4c:5e:e6:37:f4 C eth0
192.168.42.67 ether 76:17:a0:45:d3:0d C wlan0
192.168.1.220 ether 0c:c4:7a:41:26:1e C eth0
192.168.2.140 ether a6:4c:5e:e6:74:9c C eth0
128.31.0.62 (incomplete) wlan0