Вот какой вопрос у меня к разработчикам службы.
На Гите явно прописано:
Драйвер master-slave протоколов для устройств, работающих через последовательный порт
А если у нас протокол не master-slave. А просто без запросов что-то льется по последовательному порту, ну например тот же GPS. Внутрянняя архитектура сервиса позволит доработать к нему обработчики таких протоколов? А если протокол проприетарный, и работает тоько через API разработчика + отдельно библиотека?
Я все это к чему. Пока просто присматриваюсь. Есть ли смысл пытаться самостоятельно что-то подобное дописывать к mqtt-serial, или так и оставить кучку мелких сервисов, каждый из которых работает с отдельно взятой железкой по serial.
Я в код еще не смотрел, поэтому и спрашиваю совета разработчиков. Имеет ли смысл вообще смотреть в эту сторону?
Добрый день.
Тут, конечно, от цели зависит. Для устройств которые не поддерживают master-slave размещение их на одной же физической шине - чревато коллизиями.
А если под такое устройство выделять отдельный порт - то и serial не нужен, можно использовать свой сервис.
То есть мультипротокольность serial - применяется как раз для возможности работать с разными устройствами одной шины.
Конечно речь идет о выделенных портах под каждый набор устройств. Например RFID считыватели работают до 4х штук на 485 порту, но требуют свой API и свою библиотеку. Множество разных сервисов расстраивает меня. Их настраивать и конфигурировать сложно. Децентрализовано получается. А так - общий конфиг для mqtt-serial и все.
wb-mqtt-serial больше рассчитан на запрос-ответ. Лучше сделать отдельный сервис, его проще поддерживать. Библиотеки можно подключать любые, в этом нет никаких проблем. Настройки все задаются централизовано через web-интерфейс. Не важно, что они в разных файлах лежат, надо только сделать JSON-схему с описанием.