Вот с чем столкнулся сегодня:
root@wirenboard-ARAXKJYF:~# service wb-mqtt-serial status
[FAIL] wb-mqtt-serial is not running … failed!
root@wirenboard-ARAXKJYF:~# service wb-mqtt-serial restart
[…] Restarting MQTT Driver for Serial devices: wb-mqtt-serialstart-stop-daemon: warning: failed to kill 3374: No such process
. ok
Полагаю, что очередной раз натыкаюсь на незавершённый процесс SetTimeout или в чем дело? Можно по этой информации понять что произошло? Restart сервиса помог, но хотелось бы избежать подобной ситуации. Может автоматический рестарт возможно сделать, проверяя службу через Cron?
Jun 30 01:15:38 wirenboard-ARAXKJYF user.notice serial: ModbusRTU::ReadRegisterRange(): failed to read 16 coil(s) @ 0 of device modbus_io:185:3: Serial protocol error: request timed out
Jun 30 01:15:40 wirenboard-ARAXKJYF user.notice serial: Init: IODIR: setup register <modbus_io:185:3:: 10000> <-- 0
Jun 30 01:15:40 wirenboard-ARAXKJYF user.notice serial: Init: IPOL: setup register <modbus_io:185:3:: 10001> <-- 0
Jun 30 01:15:40 wirenboard-ARAXKJYF user.notice serial: Init: GPINTEN: setup register <modbus_io:185:3:: 10002> <-- 65535
Jun 30 01:15:40 wirenboard-ARAXKJYF user.notice serial: Init: DEFVAL: setup register <modbus_io:185:3:: 10003> <-- 0
Jun 30 01:15:40 wirenboard-ARAXKJYF user.notice serial: Init: INTCON: setup register <modbus_io:185:3:: 10004> <-- 0
Jun 30 01:15:40 wirenboard-ARAXKJYF user.notice serial: Init: IOCON: setup register <modbus_io:185:3:: 10005> <-- 17476
Jun 30 01:15:40 wirenboard-ARAXKJYF user.notice serial: Init: FLAG: setup register <modbus_io:185:3:: 9999> <-- 1
Jun 30 01:19:57 wirenboard-ARAXKJYF user.notice serial: FATAL: Serial protocol error: can’t write to discrete. Stopping event loops.
До этого события я вручную через WEB интерфейс выключил свет, который не погас по таймеру. Больше ничего не совершал, а утром обратил внимание, что устройства ввода-вывода не реагируют, но правила живы и виртуальные контролы тоже отвечали.
Starck, а какая у вас топология RS-485? Кроме WB-MIO с адресом 185 есть что-то? После падения wb-mqtt-serial, до перезагрузки, вы через modbus_client можете опросить WB-MIO, например? Или другие устройства на шине?
Bp кода не видно, что могло бы приводить к такой ошибке. Однако, поскольку у вас имена контролов формируются на лету, я бы включил отладку и вставил для начала хотя бы логгирование вызова правил, чтобы определить, в каком правиле происходит сбой, а затем бы смотрел, каким именно устройствам/контролам вы пытаетесь присвоить значение.
Сейчас как на зло, это может долго не наступить, а лучше бы никогда в идеале. А как выявить падение этого сервиса? Если правила не упали, то можно отправить сообщение о сбое serial ? Должна же быть Команда возвращающая статус сервиса. Так можно все сервисы проверять и уведомлять о проблемах своевременно.
Слышал щелчок реле и в интерфейсе устройства стали неактивны на пару секунд. Вот что в логе:
ModbusRTU::ReadRegisterRange(): failed to read 16 holding(s) @ 250 of device modbus_io:185:2: Serial protocol error: request timed out
События произошли в разное время и устройства подключены к своим MIO, объединенных между собой одной шиной.
В первом случае это устройство WBIO-DI-DR16, а во втором: WBIO-DO-R10R-4. Правила не выполнялись, до этого я делал рестарт у mqtt-serial
Именно. Может из-за помех на линии RS-485 все это происходит? Кто инициирует чтение регистров, если правила молчат? И почему они ошибку выдают? Такое ощущение, что запросы генерируются случайным образом. Отсюда и попытка записи в DI, описанная в начале поста.
Линию опрашивает wb-mqtt-serial, он же пишет в регистры. Ошибка на линии вполне возможна. Запросы генерируются в циклической очереди, последовательно, с отработкой ошибок, записи в регистр ставятся вне очереди после окончания очередного запроса. Если ошибки повторяются относительно часто, то надо поставить у порта в Web-интерфейсе флажок отладки и смотреть, какие сообщения будут приходить от wb-mqtt-serial в /var/log/messages.
Хорошо, понаблюдаю. Хотите ли Вы сказать тем самым, что это нормальная практика и переживать не стоит? или все же это сказывается на работе устройств как правило и надо разбираться? Мне Евгений ваш рекомендовал еще в прошлом году землю всех MIO объединить для уменьшения помех. Видимо и с этим придется поработать для понимания истинных причин в сбоях.
Ну, переживать точно не стоит, надо разобраться, когда происходят эти сбои: при коммутации мощной нагрузки? Объединить GND всех устройств, подключенных к порту – хорошая практика, думаю, это стоит сделать.
