Протокол Modbus-RTU. Подключил ко второй линии 9600, c одним стоп-битом. Всё заработало. Создал кастомное устройство и вывел в него основные параметры, описанные в документации:
Основная проблема в том, что параметры часто получаются с ошибками. Скорее всего это из-за того, что у меня такая топология шины (хотя все проложено экранированной витой парой):
Топологию поменять не могу, но можно ли как-то увеличить ожидание ответа или уменьшить частоту запросов или еще что-нибудь, чтобы избежать ошибок?
P.S. У меня лежит бесхозный счетчик Принц G1.6 у которого прошла половина срока поверки. Могу прислать его вам для тестов или передать кому-нибудь в Питере. Нужен?
На скорости 9600 такая топология вполне приемлема, дело не в ней. Хотя не понимаю, почему WB и эл. счетчик не подключить шлейфом.
Я бы отключил wb-mqtt-serial и поигрался с modbus_client. Посмотрел бы, при какой частоте опроса регистры с ошибками читаются корректно. И привел шаблон в соответствие. А вот если ошибки будут регулярными и в режиме ручного опроса - тогда надо смотреть, что с шиной не так.
P.s. Встречал устройства, у которых ответить ошибкой на запрос из-за того, что микроконтроллер просто в данный момент занят своими делами, было нормой.
Отввод в 20 см влиять на 9600 не должен.
Точно ли соединены Gnd устройств?
Ну и - в логе на что ругается, таймаут или именно ошибки приема?
“Таймаут” - в принципе иногда свидетельствует что ошибка произошла на этапе передачи команды устройству, то есть оно получило некорректный запрос (CRC не сошелся, например) и не отвечает.
Сколько ни игрался с modbus_client ошибки никогда не возникают. И там нет определенных регистров, где случаются ошибки при опросе через wb-mqtt-serial, они каждый раз по-разному случаются для этого счетчика.
Шлейфом не подключил, потому что счетчик опечатан и коснись что, пришлось бы срывать пломбу, чтобы поменять топологию
А что за ошибки-то? Иногда сторонние устройства просто не выдерживают нашего совершенного драйвера, который максимально утилизирует шину. Поэтому целесообразно добавить guard interval побольше, как коллега выше советует.
Guard interval (us) 5000 и Response timeout (ms) 1000 улучшили ситуацию. Красные значения стали появляться гораздо реже, но не исчезли совсем (Пробовал Guard interval (us) до 100 000 поднимать - мало помогло)
лог - именно сервиса wb-mqtt-serial.
Как и написано в документации занчение meat “r” - ошибки чтения.
Просмотрте лог, если включить debug режим - то и отправленные-принятые байты.
Мервис ожидает корректного ответа от устройства в окно времени, определяемое timeout/ Если получен некорректный или не получен совсем - ошибка.
Ну да, смотрю wb-mqtt-serial.service логи через веб-интерфейс. Странно, что в интерфейсе ошибка обозначается красным, а в логах ничего со статусом Error, Critical и т.п. нет
Еще, кстати, добавьте, пожалуйста, в список групп g-gas-meter для газовых счетчиков. Или я и так могу указывать эту группу в шаблоне?
Можно подробнее про format. Пробовал играться с ним, но не похоже, что это то, что нужно. Хотя в моем случае может быть проще, т.к. данные о целой и дробной части идут в смежных регистрах.
Целая часть (регистр 0): 0xA1B1C1D1, дробная (регистр 2): 0xA2B2C2D2.
Причем байты поменяны местами, т.е. значения будут 0xC1D1A1B1 и 0xC2D2A2B2 (для чего успользую little_endian)
Мне же нужно вместо двух полей получить одно поле с числом с плавающей точкой на основе 0xA1B1C1D1A2B2C2D2 Пробовал int64 использовать, но получается шляпа.
Есть и другие ситуации, когда даты раскиданы по регистрам (год, месяц, день и т.д.), а нужно объединить их в одну строку (напр.: 18.07.2013)
