Есть ли поддержка чтения данных с шины без запроса?

Поддерживаемые устройства
, ,
1

Ситуация такая: у меня есть газовый сигнализатор (такой). У него есть шина “Линия”. Это, судя по доке (Приложение А) и по моим исследованим, RS-485. На ней периодически идёт “широковещательный” пакет с текущим статусом. Периодичность ~ 1 раз в 5 секунд. При срабатывании - чаще: 1 раз в секунду. Вроде бы, на 9600 8N1. По крайней мере, данные на ней стабильно одинаковые.

Производитель не даёт информации об используемом протоколе, чтобы можно было делать “запрос-ответ” (что значительно бы упростило бы задачу; реверсить - нет опыта и, тем более, данных, т.к. нет управляющей стороны).

Решение в лоб, конечно, - повесить “Линию” на отдельную шину в WB, написать простенький скрипт на питоне, и писать в топик текущий статус.

Однако, выделять для этого отдельную шину - по-моему, слишком расточительно (и, в общем случае, не всегда могут быть свободные).

Вопрос: есть ли в wb-mqtt-serial возможность создать шаблон устройства такого типа (без “запрос-ответ”), принимать эти широковещательные посылки, и привязывать их к заданным устройствам?

Если нет, то оцените примерно возможность доработки, и ткните пальцем в код, где и примерно как это можно было бы сделать (я ещё не погружался в код (да и я не С++ разработчик), но, если доработка не сильно сложная (для чего и нужна оценка), я, возможно, смог бы сделать патч, ну и PR)

2

Все поддерживаемые в wb-mqtt-serial протоколы, сейчас имеют одно общее: переферийное устройство не начинает передачу без запроса от мастера.
На RS-485 одновременно может передавать только одно устройство, механизмов разрешения коллизий нет. То есть в случае если устройство начнет передачу просто по таймеру, без запроса - велика вероятность того что его передача наложится на уже идущую передачу другого, мастера или слейва на шине.
То есть использовать вместе с modbus, например - не получится, в любом случае нужен отдельный порт.

3

это понятно )) принимем и назовём это “ограничения” или “особенности” работы )

ну, почему сразу “не получится” )) оно просто будет “немного вносить ошибок” )))) примем это во внимание )

я понимаю, что хочу странного ))
вопрос был про техническую составляющую ))

4

Нет. Если устройство начнет передавать в тот момент когда драйвер будет ждать ответ на запрос к другому - будет просто ошибка.

5

кстати, (для истории), скорость, всё-таки 9600 8O1

6

я про то и говорил. ok ))

тем временем, я придумал другой вариант )) чтобы шину на это не выделять: замастырить детектор на ардуине, а его уже цеплять на шину по Modbus и опрашивать как обычно ))

1 лайк
7

Ну это самый простой, наверное, путь)
Как вариант - сервер последовательных портов с кучей, собственно, портов, и слушать их как serial-over-ethernet. Тут надо смотреть, что проще и дешевле выйдет.

8

Да, код на ардуинке (esp) прост, можно даже не один дополнительный software serial сделать.
Для таких задач и использую. Реализовал “стандартные” регистры для настройки хранения адреса, параметров связи а остальное - дописываю.

9

опа! а есть в open source? ) (не люблю велосипеды писать, люблю использовать и допиливать уже написанное ))

10

Напомните в понедельник, открою на гитхабе. Но оно пока так, бета.

11

)
меня не смущает бета ))) мне интересны подходы профессионалов в этой сфере ))

1 лайк