общий черновой набросок, в схеме с mqtt-bridge and mqtt-driver, по аналогии с уже имеющимся подходом-схемой
первым по жизненному циклу запускается mqtt-driver, он
интасталирует свою схему, и создает свой экземпляр объекта in core, если таковых еще нет
инсталирует схемы классов mqtt устройств, если таковых еще нет
проверяет имеющиеся (upgrade???)
начинает слежение за изменениями в объектах
сырые данные в свойствах для интерпретации
список объектов (?)
обрабатывает изменения
mqtt-bridge
интасталирует свою схему, и создает свой экземпляр объекта in core, если таковых еще нет
считывает список имеющихся и ассоциированных с этим мостом mqtt устройств
если таковые есть то
считывает свойства устройств, и делает подписку в сооотвествующих mqtt brokers for accociated topics
отслеживает сообщения в топиках, при поступлении таковых пишет сырые данные в свойства объекта, для последующей обработки into/with mqtt-driver
начинает слежение за объектами в core (список, изменение свойств, данные для control message)
обрабатывает изменения
impacts & events
кто-то (это может быть admin interface or other applications) создает объекты mqtt устройств
кто-то меняет параметры в control of mqtt object, то есть толкает control message в mqtt устройство
реакции
mqtt-driver, отслеживая данные для интепретации в properies/controls
mqtt-bridge, отслеживая изменения, item 2c
связь между а) property and б) mqtt topics будет храниться в core object of mqtt device
и в общем случае, предусматривается что будет редактируема
точно параметры доступа
названия топиков в свойствах, при переконфигурировании mqtt device
(?) добавить-удалить свойства объекта, также как следствие переконфигурирования mqtt device
большая часть обработчиков-интепретаторов данных от mqtt устройст будут очень простыми.
предусматривается, что одно изменение control может породить несколько сообщений
в различные управляющие топики mqtt устройств
и в обратную сторону, одно сообщение из топика mqtt устройств может изменить
несколько свойств в mqtt объекте