Интересный глюк

Сегодня ночью несколько раз самопроизвольно включался свет… Рано утром начал разбираться и обнаружил странное поведение WB5. Работал как-то странно, Configuration Files: Error listing the configs: MQTT RPC request timed out - постоянно вылетало несколько раз перегружал через терминал - не помогало, при этом срабатывали устройства, которые срабатывать не должны. Вообще, я постепенно вывожу из работы WB, там практически не осталось скриптов и используются только опрос нескольких modbus rtu и дискретные входы на модулях I2C с кнопок - вот они и срабатывали (и отсылалось в iobroker), хотя на них никто не нажимал. Виновником оказался не WB, а микротик к которому был он подключен. Микротик при этом работал, но работал странно. Перезагрузка микротика решила проблему. Но осадок остался - это получается при внешней сетевой проблеме WB ведет себя совершенно не предсказуемо. Отсылает состояния входов не те что на самом деле (которые iobroker честно отрабатывал и включал свет). К примеру на этом же микротике стоит и modbus tcp модуль с которым работает напрямую iobroker - он ничего не отсылал (и не должен) лишнего, только подтормаживал (именно это и навело на мысль с сетевой проблемой). Вот такие дела…

В процессе поиска проблемы обнаружил:

root@wirenboard:~# ps -A | grep wb-
 2005 ?        00:00:00 wb-watch-config
 2027 ?        00:00:00 wb-watch-config
 3068 ?        00:07:28 wb-homa-adc
 3105 ?        00:03:32 wb-homa-gpio
 3174 ?        00:01:50 wb-homa-w1
 3213 ?        00:00:45 wb-mqtt-confed
 3227 ?        00:00:10 wb-mqtt-db
 3243 ?        00:00:37 wb-mqtt-lirc
 3280 ?        00:29:49 wb-rules
 3294 ?        00:00:00 wb-watch-update
 3299 ?        00:00:00 wb-watch-update
 3455 ?        00:07:03 wb-mqtt-serial

wb-watch-config и wb-watch-update так и должны быть в двух экземплярах?

А что за модуль modbus tcp для микротика используете? И для чего?

По проблеме - WB мог отправлять retain топики модуля И2С в иоброкер при восстановлении связи (поправьте гуру mqtt, если я говорю глупости, я не так давно с ним разбираюсь), в которых сохранялись какие-то старые состояния нажатий кнопок.

Ну он не для микротика, а вообще… :slight_smile:
такой
Аналогичный 517N больше года успешно проработал, взял несколько месяцев назад этот для перевода входов-выходов с I2C модулей WB5 (если честно - задолбал своей “специфичностью” c I2C и вообще…). Нареканий нет, по TCP работает напрямую с iob, по 485 - с wb5 (что-то вроде отказоустойчивости), причем одновременно. Наверное буду брать еще один такой, чтобы полностью перенести все с WB I2C, или присматриваюсь к такому, пока еще не решил… в принципе мне нужны еще только дискретные входы. А этот, хоть и дороже, но имеет интересные особенности - скоростной счетный вход (есть у меня специфичный счетчик) и работа в качестве… (неожиданно) модбас шлюза для rtu. Куда я с радостью хочу перенести “гирлянду” устройств с того же WB5.

Теперь понял :))
Я то думал вы на микротик в усб поставили usb-485, и используете микротик как модбас-тсп шлюз. .
Можете еще из некитайского посмотреть на серию Адамов, например 6050 - http://www.advantech.ru/products/a67f7853-013a-4b50-9b20-01798c56b090/adam-6050/mod_b009c4b4-4b7c-4736-b16f-241978245e6a
они у нас доступны, и стоят сравнимых денег.

Если рассматривать шлюз, то интересна
такая
железка, 3 порта… вот только купить ее проблемно - или юрлицам или поставка 6 недель. Я пробовал дешевые serial серверы китайские с поддержкой modbus - хреновенько работают. Хоть и работают… вот только ошибки лезут и больше одного устройства rtu на порту в связке с iob совсем плохо… а этот адам что-то совсем не интересен как модуль ввода-вывода (и только), по мне вышеуказанные китайские поинтереснее будут.

Если один порт достаточно, возьмите проверенное временем https://www.moxa.ru/shop/com_v_ethernet/standart/5000/5100/nport-5150/ . Если нужно без проволочек, у меня пара новых 5150 лежит про запас.

Это serial server, разница с modbus gateway как оказалось - существенная. Эта даже не умеет из modbus rtu делать modbus tcp, моя, к примеру, это делает… так что 5150 вообще никак не подходит. Я нацелился именно на шлюз. Если интересно могу кинуть описание на вышеупомянутый девайс с 16 входами и шлюзом - там видно как настраивать подключение внешних rtu устройств - каждый регистр надо прописывать для трансляции в TCP. У moxa есть шлюзы, но цены на них совсем не гуманные, раз в 5 дороже…

Спасибо, пока не требуется.
А эта железка на 3 порта вроде не умеет работать как serial-сервер? Мне он больше нужен в проектах, я с Modbus TCP не работал, только читал про него.

Не-а, не умеет. У меня есть на 3 порта китайский serial server - 50$ на али. И модбас tcp умеет, но криво… хотя сейчас у меня работает именно с модбасом, по одному устройству на каждом порту. Буду менять на нормальный шлюз, если интересно - как освобожу - могу уступить.

Очень странная проблема. Это действительно могли быть retained-сообщения из mqtt, только вот неправильные значения там появиться не могут, если все нужные сервисы на контроллере запущены и работают. Может быть есть ещё какой-то фактор, про который вы не упомянули? Какие-нибудь специфические сетевые настройки или ещё что-то.

Тут надо понимать, что это не “WB себя странно ведёт”, а это стандартный Debian с стандартным свежим ядром Linux и стандартным сетевым стеком, вместе со стандартным брокером mosquitto ведут себя странно. Все эти компоненты, и по отдельности и вместе работают много лет на сотнях тысяч серверов. Так что в необъяснимые сетевые проблемы я верю с трудом, скорее всего тут что-то простое и не факт что вообще на WB.

А что именно вам не нравится в модулях ввода-вывода WB?

Я описал происходящее. Ночью я спал и ничего не делал. Все запущено и работает. И, к слову, заработало нормально как только я перегрузил микротик. Почему он встал колом - загадка (первый раз такое увидел - вместо имен интерфейсов - unknown, при этом как-то трафик через него все равно ходил, разруливались vlan-ы), судя по всему, проблема для WB была не в отсутствии связи, а в значительной доли потери пакетов на этом микротике.

Все может быть, но я все же подозреваю проблему в WB - ситуация нестандартная, конечно. В обычном режиме все нормально. Нечто похожее наблюдается при перезагрузке WB и наблюдалось всегда - случайным образом может сработать что-то, что до перезагрузки было выключено. Например, включиться сигнализация. И насколько помню, про это уже раньше говорилось.

Не нравится заточенность на WB. Модули не универсальны, я их никуда не смогу приткнуть в случае, если захочу что-то изменить. Вот у меня такое желание и возникло, захотелось бОльшего удобства и стабильности (сделано). При этом WB все равно останется в строю - для резервирования особо критичных процессов своими скриптами (безопасность, протечки и тп), работая напрямую и одновременно с ioBroker с одними и теми же модулями ввода-вывода на модбасе (сделано). Ну а в такой схеме модулям расширения просто нет места. Фактически сейчас неспешно их демонтирую и переношу провода на другие девайсы.

wb не перезагружался?

Вы управляете топиками через WB или ioBroker? В топики /on что-то кроме wb пишет? Если да — убедитесь, что оно не пишет retained-сообщения. Иначе будет ад, хаос и анархия.

В том случае сам конроллер не перегружался. Я перегружал, но, разумеется, не помогало пока не понял что микротик глючит. Сейчас в топики “on” пишет практически только wb, на нем на данный момент не осталось устройств управления (которые интересны iob), только дискретные входы на I2C (на них еще остались кнопки управления разными режимами, но будут убираться) и modbus устройства, которые отдают данные без управления (тоже будут убираться). Вроде датчика СO2. Также есть на модбасе универсальный модуль входов-выходов, но ioBroker c ним работает напрямую параллельно вместе с WB (по TCP и 485 - для отказоустойчивости - так и останется работать). Раньше, когда на WB висели девайсы с управлением (дискретные выходы) - ioBroker без проблем писал в “on”. Единственное исключение, куда ioBroker сейчас еще пишет - топик с виртуальной кнопкой, которая отвечает за состояние сигнализации. Чтобы синхронизировать параллельную работу для отказоустойчивости. Могу еще добавить, как я уже выше говорил - при перезагрузке состояние устройств может принимать случайное состояние и это наблюдалось и до ioBroker. Собственно, такое поведение тоже добавило желания основным контроллером сделать что-то другое… Ну а то что произошло - однозначно при таком раскладе с микротиком WB отправлял на ioBroker топики с дискретных входов (кнопки) меняя их состояния, хотя кнопки никто не нажимал. Не часто, разумеется… ну и ioBroker честно их отрабатывал, управляя собственными исполнительными устройствами, например включая свет. И в результате ночью я несколько раз просыпался и видел, что свет горит, вспоминал, что я его все же выключал, гасил и опять засыпал… А если это был бы не свет, а, что-то более критичное? Так и пожар можно устроить…