Создание своего протокола

1

Здравствуйте!
Перечитал документацию и темы поддержки, но не до конца понял момент добавление нового протокола в систему. У меня есть устройство, которое возможно подключить к системе, но формат сообщений отличается от стандартного modbus. Из всего прочитанного я понял, что для обмена информацией необходимо создать свой протокол. на сайте

я понял принцип его создания. Но расскажите пожалуйста как файлы, описывающие обмен информацией, добавить в устройство wirenboard? и как потом прописать в системе, чтобы я мог создавать шаблоны устройств, используя просто описание “protocol” : “myprotocol”?
Спасибо

3

Шаблоны создаются так: Подключение стороннего Modbus-устройства к контроллеру Wiren Board — Wiren Board
Подробно структура шаблона оисана в документации к сервису: https://github.com/wirenboard/wb-mqtt-serial/blob/master/README.md

Но, доработка драйвера - путь требующий уверенного понимания кода.
Я предпочитаю работать с нестандартными протоколами просто ияпользуя RPC: GitHub - wirenboard/wb-mqtt-serial: Wiren Board MQTT serial protocol driver
Таким образом все что нужно - один скрипт.

4

Спасибо за ответ!
Тогда, если двигаться в направлении RPC, не могли бы еще один момент подсказать. Есть выключатель, который при нажатии кнопки посылает информацию в шину. Контроллеру просто необходимо “слушать” шину и, при появлении в ней информации, обработать ее. Не подскажете команду, которая получает информацию из шины? Спасибо

5

RPC драйвера позволяет только master режим, который не предусматривает отправку устройствами чего-то в шину без запроса от master.

Предполагается что устройство на шине одно? Или шина с разрешением коллизий (что будет если два устройства одновременно начнут передавать)?

6

Спасибо за ответ! Что-то я уже запутался в поиске информации(
Есть выключатель, который имеет нестандартную для модбас длину запроса и ответа
Мигать подсветкой научился через правила, вроде сложного ничего нет. Использую команду
runShellCommand(“/usr/bin/printf ‘\x02\x06\x10\x41\x00\x00\xDD\x2D\xAA’ > /dev/ttyRS485-2”).
Но не могу получить информацию о нажатых кнопках на выключателе.
Перепробовал несколько вариантов:
1. modbus_client_rpc как я понял использует стандартный модбас запрос и ответа от устройства никакого нет ( ‘msg’ - неправильно формируется)
modbus_client_rpc --debug -mrtu -pnone /dev/ttyRS485-2 -a2 -t6 -r0x1021 1
2023-11-13 12:47:28,210 [DEBUG] Data to write: 0x01
2023-11-13 12:47:28,211 [DEBUG] [02][06][10][21][00][01][1c][f3]
2023-11-13 12:47:28,214 [DEBUG] Connecting to broker unix:///var/run/mosquitto/mosquitto.sock
2023-11-13 12:47:28,217 [DEBUG] RPC Client → {‘path’: ‘/dev/ttyRS485-2’, ‘baud_rate’: 9600, ‘parity’: ‘N’, ‘data_bits’: 8, ‘stop_bits’: 1, ‘response_size’: 8, ‘format’: ‘HEX’, ‘msg’: ‘0206102100011cf3’, ‘total_timeout’: 1000} (1000 timeout ms)
2023-11-13 12:47:28,794 [DEBUG] Options: {‘debug’: True, ‘mode’: ‘rtu’, ‘slave_addr’: 2, ‘read_count’: 1, ‘start_addr’: 4129, ‘func_type’: 6, ‘timeout’: 1000, ‘address_decrement’: False, ‘baudrate’: 9600, ‘data_bits’: 8, ‘stop_bits’: 1, ‘parity_port’: ‘N’, ‘mqtt_broker’: ‘unix:///var/run/mosquitto/mosquitto.sock’, ‘serialport_host’: ‘/dev/ttyRS485-2’, ‘write_data’: [1]}
ERROR occurred
2023-11-13 12:47:29,796 [DEBUG] Error message: Server error
2023-11-13 12:47:29,797 [DEBUG] Error code: -32000
2023-11-13 12:47:29,798 [DEBUG] Error data: Port IO error: Serial protocol error: request timed out

2. runShellCommand(“/usr/bin/printf ‘\x02\x06\x10\x41\x00\x00\xDD\x2D\xAA’ > /dev/ttyRS485-2”, {
captureOutput: true,
exitCallback: function (exitCode, capturedOutput) {
log.info("cmd output: " + capturedOutput);
}
});
в ответе ничего нет(

3. runShellCommand(“cat < /dev/ttyRS485-2”) тоже ничего путного нет

Не подскажете, какую команду применить, чтобы от устройства получить HEX ответ и, разобрав его побайтно, выполнять последующие действия
Спасибо

7

Да.
Так что я думаю, для “нестандартного”, для отправки вообще любой последовательности байт в шину надо использовать именно RPC, пример реализации можно посмотреть Шаблон для электрокарниза - #6 от пользователя BrainRoot

printf не подразумевает никакого ответа из шины. К тому же он не учитывает что шина (может быть) занята драйвером.

Да, привел пример выше.

8

Большое спасибо! То, что нужно))
Надо вам как то в отдельный топик вынести, похоже такие вопросы иногда возникают)

9

Описание есть в документации драйвера.

10

Эта тема была автоматически закрыта через 7 дней после последнего ответа. В ней больше нельзя отвечать.