В Интернете существует множество учебников, особенно с RabbitMQ , по вопросам публикации данных датчиков; например, температура, влажность и т. д. Просто опубликуйте значение в очереди сообщений, и любой может его использовать.
Все идет нормально. Но как насчет приводов?
Давайте возьмем выключатель света для примера. Переключатель освещает текущее состояние светильника в очереди. Он также подписывается на вторую очередь для прослушивания событий. Это позволило бы двунаправленную связь. Если кто-то / что-то хочет включить свет, событие должно быть опубликовано в очереди сообщений, которую слушает выключатель света.
Я надеюсь, что вы понимаете идею. Это путь с приводами? Есть ли более разумное решение? Как насчет безопасности, подумав об использовании этого для дверей, например. Можно ли опубликовать мероприятие открытых дверей из любого места? Как легко это можно взломать?
Ответы:
Да, шаблон паб-саб применим к приводам.
Это один из способов, и это процветает из-за многих облачных провайдеров, таких как
пытаясь занять пространство IoT, чтобы легко перемещать данные из датчиков в облако, используя разные подходы, а поскольку устройства имеют ограниченную возможность соединения, мощность, пропускную способность, им нужен протокол с меньшим весом, такой как MQTT, и основанный на модели паб-суб.
Здесь я хочу сказать, что любое устройство, которое может воспринимать данные и может иметь данные, может использовать pub-sub, но разумная вещь проистекает из того типа реализации, который они выполняют. Предположим, что если вы не используете MQTT по какому-либо зашифрованному механизму (TLS / SSL), данные могут быть прослушаны.
Это зависит от приложения и ограничений, с которыми сталкивается проблема, и так называемое более разумное решение меняется с течением времени. Еще одна вещь, на которую следует здесь обратить внимание, это то, что более разумное решение - не самый разумный способ обойти, потому что реализация важнее всего, а не протокол или метод, который вы выбираете.
Да, открыть дверь можно из любого места, опубликовав событие, но все это зависит от приложения и аутентификации, которую вы предоставляете, например, вы можете сделать так, чтобы ваше приложение подписывалось / публиковалось в темах только после аутентификации.
Сценарий реального случая:
Я знаю много компаний, которые используют эту точную модель для приводов, в последнее время я работал в команде, которая является частью систем солнечного слежения, где солнечные панели управляются, контролируются с использованием беспроводных технологий.
Особенно в том, что для перемещения / вращения массива панелей в соответствии с положением солнца и на основе различных алгоритмов оптимизации энергопотребления мы используем линейные приводы , в этой системе у нас также есть возможность управления панелями вручную с веб / мобильных панелей мониторинга в случае аварийных ситуаций или любые цели обслуживания.
В приведенном выше сценарии для управления приводами используется модель Pub-Sub с аутентификацией / шифрованием.
источник
Согласно документации RabbitMQ использует TLS / SSL . Так что уровень безопасности так же хорош, как и эти технологии. Если вы проверяете поддержку RabbitMQ-TLS, вот ваши примеры использования SSL, получения сертификатов сервера и так далее.
По поводу вашего вопроса о выключателе света.
То, что вы описали, звучит довольно прямо. Переключатель прослушивает (подписывается) потенциальные источники, которые хотят включать или выключать светильник. А также уведомляет их об изменениях в состоянии светильника, чтобы они могли знать, когда и как действовать.
источник
Я думаю, что ваше коммутаторное устройство должно быть подключено к концентратору (domotic box, zwave controller, ...), который обрабатывает все эти события, поэтому коммутатор должен быть выделен для низкоуровневого взаимодействия с объектами (zwave, 433Mhz, ...)
Интеллектуальные устройства очень ограничены в батарее, поэтому чем меньше они работают в сети, тем дольше они работают.
источник