Комментарии 10
Zigbee все-таки нынче пишется как Zigbee, а не как ZigBee :-) И сравнивать его с MQTT, а MQTT с ним IMHO немного неверное (и наличие zigbee2mqtt не оправдание).
Z-Wav на картинке - это Z-Wave, поди?
Большое спасибо за ваше внимание! Уже исправлено)
Zigbee-то в тексте поправьте, это должно быть даже легче :-) Бывший Zigbee Alliance очень большое значение этому придавал :-) Специальное решение принимал о замене большой буковки на маленькую :-) Больше особо нечем иногда им заняться было, кончили тем, что и Альянс переименовали напрочь :-) Но проявите уважение :-)
А СПОДЭС и ГОСТ Р 58940-2020 - Требования к протоколам обмена информацией между компонентами интеллектуальной системы учёта и приборами учёта - как-то охвачены этими протоколами?
Да, отличный вопрос. Прямо даже как-то удивляюсь, что про DLMS и его отечественные изводы ни слова. Учитывая, что "Россети" всех (производителей ПУЭ) в жесткой форме сподвигли его поддерживать.
Про KNX не соглашусь по всем пунктам.
Прочитать стандарт надо. Производить что-то своё - надо лицензировать, чтобы было совместимо с другим оборудованием
SNMP мало распространен? Мало доступен??
Немного внесу дополнения, так как работал с проколами в автоматизации(изучал их архитектуру и api) и работал над нашим российским протоколом bus77 - https://github.com/iRidium-Mobile/BUS77-SDK. Советую его брать за основу, так мы все-таки имели весомый опыт работы с протоколами.
На базе него и линейку оборудования запилили с релейными блоками, мультисенсорами и диммерами. Кстати, работая над диммером серьезно так перетряхнул DALI и DALI2.
Теперь по статье и протоколам:
Очень странная градация на IOT и не имеющие отношения. Большинство производителей оборудования со своим протоколом имеют IP шлюз, который позволяет с ними комфортно работать.
Изучение этих протоколов - это лишь верхушка айсберга и они в себе несут жуткое легаси и проблемы с обнаружением устройств на большой шине, их удаленному программированию.
Помню разрабатывали шлюз для KNX и его отладка - это настоящая страдание, особенно, когда заморачиваешься с безопасностью и нормальной работой с большой шиной.
Протоколов на самом деле гораздо больше HDL, Lutron, Crestron, Dali и еще десятки других производителей, и каждый стремится написать свой:)
Распространенность протоколов я бы поделил на два типа : народные(так сложилось исторически и они бесплатны) и коммерческие (более молодые, имеют интересную модель продвижения за счет дилеров и поддерживаются государством, прим. KNX прописанный в официальных требования государств к системам автоматизации).
Коммерческие протоколы для изучения зачастую закрыты и требует состоять в ассоциациях и за доступ к документации просят денежные средства, порой немалые.
Что касается, сауреса, МТС и устройств Сбера, то считаю такие протоколы гавношлепничеством. Очень убыточны. Это как детские забавы, чтобы быстро выйти на потребительский рынок и продать Г.
Автор забыл самое главное, что требуется от шины - это надежность. Различные таймеры, расписания, системы измерения, работа без шлюза ставят перед создателями протокола интересные задачи и не каждый реализует их нормально. Так как сложная логика влечет сложные кейс применения, которые надо тщательно прорабатывать.
Про контейниризацию забавно(утопия для детей)... Порой новые устройства поддерживают какой-то свой особенный функционал, отличный пример KNX. Где производители устройств не используют полностью протокол, потом ставят аналог от другого производителями со "своими " особенностями и он нормально не отрабатывает из-за того, что те снова использовали часть функционала из протокола.
В свое время очень понравился подход www.beckhoff.com порывшись в их документации можно много интересного найти. Отлично подходят к конструированию устройств и соответствии их со всеми нюанасами протоколов. Может кому полезно будет:)
Анализ коммуникационных протоколов в сфере IoT для сбора данных с приборов учета