Ну, смотрим в лог.
Видим что
2025-01-22T11:48:33.997Z [wb-mqtt-serial] DEBUG: [port] /dev/ttyRS485-2: Sleep 20000 us
2025-01-22T11:48:34.027Z [wb-mqtt-serial] DEBUG: [port] /dev/ttyRS485-2: Sleep 50000 us
2025-01-22T11:48:34.027Z [wb-mqtt-serial] DEBUG: [port] /dev/ttyRS485-2: Write: 78 03 00 6f 00 01 bf be
2025-01-22T11:48:34.043Z [wb-mqtt-serial] DEBUG: [port] /dev/ttyRS485-2: Sleep 16667 us
У устройства 120 запрошен 1 holding с адреса 0x6f (111)
2025-01-22T11:48:34.079Z [wb-mqtt-serial] DEBUG: [port] /dev/ttyRS485-2: ReadFrame: 8e 78 03 02 00 00 25
После чего мастер ожидал ответа 16,5мс и дождался:
8e 78 03 02 00 00 25
Предположу что ответ должен был быть “78 03 02 00 00 25 XX”
Так как он в любом случае начинается с адреса устройства, затем функция и количество байт. Ну и сами байты. И, если посчитать CRC то он должен выглядеть так: 0x8e 0x25.
То есть “78 03 02 00 00 25 8e”
И это после 70мс ожидания, то есть точно можно исключить что вернулся хвост от предыдущего сообщения.
Аналогичное с запросом ответом
2025-01-22T11:48:33.872Z [wb-mqtt-serial] DEBUG: [port] /dev/ttyRS485-2: ReadFrame: e3 78 03 02 00 00 25
2025-01-22T11:48:33.836Z [wb-mqtt-serial] DEBUG: [port] /dev/ttyRS485-2: Sleep 16667 us
2025-01-22T11:48:33.820Z [wb-mqtt-serial] DEBUG: [port] /dev/ttyRS485-2: Write: 78 03 00 6d 00 01 1e 7e
“0xe3” никак не может быть результатом от предыдущего запроса, не сходится.
Соответственно: Устройство отвечает располагая байты не в том порядке. Причем иногда.
Думаю что в его прошивке ошибки.