Выбор протокола для домашней автоматизации

[shemnik69]

Ну уж если все тут то и ..и
Придерживаюсь в основном проводных решений. Из низ только 2 и освоил. Это HTTP (поскольку домашняя разветвленная сеть есть) и RS 485. это промышленный, а значит надежность да и простая материальная база. (да и по работе с этим протоколом связан) радиоканалы есть (брелки.) и отчасти роутеры также как и WI-fi но основные сети все-же это провода.
Из интересных протоколов KNX . Граждане из других форумов особенно европейских очень много про этот формат пишут. Но он только на завершенных и пром решениях.

[ksgroup]

Придерживаюсь в основном проводных решений. Из низ только 2 и освоил. Это HTTP (поскольку домашняя разветвленная сеть есть) и RS 485. это промышленный, а значит надежность да и простая материальная база.

Чем конкретно по RS 485 рулите? Сам присматриваюсь к этой шине, но пока не нашел протокол допускающий режим мультимастер и эффективно решающий проблему коллизий.

[shemnik69]

На счет рулить...
тут все зависит от прикладных программ. В основном используется не протокол так как таковой, т.е полноценный пакет, на обеих элементах, (хотя такие есть и свободные) а именно его "железная" часть. Микросхемы, топология и тп.
Ну если уж точнее то например эл. счетчик и заводской мастер то это по сути два элемента которые целиком попадают в эту категорию. Для остальных (например самодельные мини контроллеры. На них минимальный алгоритм и они только отдают данные по запросу. И только.
Кроме того зачем использовать многомастерный режим? Тут нужна четкая политика зачем? это нужно.
Как раз в этой роли очень хороши аналоги либо MegaDevas-ов или на их аналогах с использованием тех же роутеров. (http://cyber-place.ru/showthread.php?t=1070). Но это опять уход в TCP/IP. Сам же железный интерфейс это наиболее простой и отчасти надежный в плане помех и тп. для построения сегментов сети в которой есть элементы с односторонним либо двусторонним обменом. И такие наиболее распространены (например контроллер датчиков. метеостанция. вешний контроллер обособленного помещения (двери.окна. вентиляторы нагрев) либо кого либо процесса (например теплица, полив проветривание ).
А если например в опросе в основном датчики которые по своей сути не "аварийные" то тут "мастер" как таковой и не нужен. Ведь информация которую формирует датчик имеет ценность только для устройства которому она нужна (MD).

[ksgroup]

На счет рулить...
тут все зависит от прикладных программ. В основном используется не протокол так как таковой, т.е полноценный пакет, на обеих элементах, (хотя такие есть и свободные) а именно его "железная" часть. Микросхемы, топология и тп.
Ну если уж точнее то например эл. счетчик и заводской мастер то это по сути два элемента которые целиком попадают в эту категорию. Для остальных (например самодельные мини контроллеры. На них минимальный алгоритм и они только отдают данные по запросу. И только.
Кроме того зачем использовать многомастерный режим? Тут нужна четкая политика зачем? это нужно.
Как раз в этой роли очень хороши аналоги либо MegaDevas-ов или на их аналогах с использованием тех же роутеров. (http://cyber-place.ru/showthread.php?t=1070). Но это опять уход в TCP/IP. Сам же железный интерфейс это наиболее простой и отчасти надежный в плане помех и тп. для построения сегментов сети в которой есть элементы с односторонним либо двусторонним обменом. И такие наиболее распространены (например контроллер датчиков. метеостанция. вешний контроллер обособленного помещения (двери.окна. вентиляторы нагрев) либо кого либо процесса (например теплица, полив проветривание ).
А если например в опросе в основном датчики которые по своей сути не "аварийные" то тут "мастер" как таковой и не нужен. Ведь информация которую формирует датчик имеет ценность только для устройства которому она нужна (MD).

Ну не скажите. Во первых если мастер только МД, то при зависании его все оборудование перестанет работать. Кроме того иногда есть например датчики данные от которых желательно получать оперативно, а не когда мастеру вздумается прочитать датчик. Можно конечно опрашивать датчик очень часто, но представьте если датчиков сотни? В этом случае не плохо было бы что бы датчик сам мог стать мастером и передать свое состояние. Кроме того устройства всегда делятся на устройства получения информации и исполнительные устройства. Намного лучше работать по схеме "датчик-исполнитель" чем "датчик-сервер(мозг)-исполнитель", потому что если сервер "умер", исполнитель не исполнит уже ничего. Поэтому хотелось бы что бы все приборы умели быть "мастером", тогда сеть не будет зависеть от центрального сервера. Тогда например RFID замок на калитке пошлет информацию в сеть о том что вы пришли, а контроллер освещения включит свет на крыльце и в коридоре, а кухонный контроллер, например, включит электрочайник, что бы вы с мороза согрелись чашечкой чая. И все это без участия центрального сервера. Центральный сервер будет только настраивать устройства (загружать в них алгоритмы действий на события) а так же мониторить события и выводить на консоль управления. Чем меньше мы завязываем действий на один контроллер, тем безотказнее будет система.

[shemnik69]

Согласен.
Но данные режимы решаются на уровне разделения функций.
Например контроллер входной калитки он для чего..для того чтобы зафиксировать изменение условий (поднесли руку к лузе считывания RIDER) подать сигнал, и чтобы на него кто то среагировал.
1. Это замок. но он может иметь не только один, а несколько каналов управления. (брелок. кнопка. домофон. сот телефон (через адаптер DTMF и тп)
2. МД он конечно будет реагировать более красиво... голосовое извещение. картинка и тп.
Но итог то, должна открыться калитка. Следовательно основные связи на уровне управления должны быть контроллер -замок. А информационные могут быть по другой схеме. И тут каналы передачи могут быть любые.
Канал передачи IP конечно идеален для этого но тогда что ставить такой контроллер в калитку?
И все равно даже если он будет такой "крутой" он все равно должен обладать связями более низкого уровня (низовой автоматикой).
Я не противник самой теории многомастерного режима, нет. Просто всегда внимательно рисую пирамиду связей устройств и их взаимодействие на вышеописанном уровне уровне т.е на уровне потоков.
Т.е не саму схему, а ее алгоритм работы, а уже под нее создаем схему.
Ведь должно быть так что железо под задачу, а не наоборот.

[ksgroup]

Согласен.
Но данные режимы решаются на уровне разделения функций.
Например контроллер входной калитки он для чего..для того чтобы зафиксировать изменение условий (поднесли руку к лузе считывания RIDER) подать сигнал, и чтобы на него кто то среагировал.
1. Это замок. но он может иметь не только один, а несколько каналов управления. (брелок. кнопка. домофон. сот телефон (через адаптер DTMF и тп)
2. МД он конечно будет реагировать более красиво... голосовое извещение. картинка и тп.
Но итог то, должна открыться калитка. Следовательно основные связи на уровне управления должны быть контроллер -замок. А информационные могут быть по другой схеме. И тут каналы передачи могут быть любые.
Канал передачи IP конечно идеален для этого но тогда что ставить такой контроллер в калитку?
И все равно даже если он будет такой "крутой" он все равно должен обладать связями более низкого уровня (низовой автоматикой).
Я не противник самой теории многомастерного режима, нет. Просто всегда внимательно рисую пирамиду связей устройств и их взаимодействие на вышеописанном уровне уровне т.е на уровне потоков.
Т.е не саму схему, а ее алгоритм работы, а уже под нее создаем схему.
Ведь должно быть так что железо под задачу, а не наоборот.

Ну мы же не космический корабль строим - зачем же нам делать несколько разных интерфейсов передачи данных? Я считаю ETHERNET он неизбежен, потому как интернет и связь между ПК нужны, но это для серьезных приборов с большими объемами данных. А вот для мелкого оборудования я у себя планирую RS-485. Можно еще какой нибудь радиолинк, для случаев где провод не проложить вообще, но это уже исключение. Получается что RS-485 будет по сути основным каналом связи устройств, поэтому мне нужно изначально предусмотреть возможность безконфликтной работы протокола. Для примера - сейчас у меня контроллер считающий расход воды установлен в санузле и имеет интерфейс ETHERNET, но это как из пушки по воробьям. Массив передающихся данных всего несколько байт, да еще и раз в 10 минут Считаю это слишком расточительно. Еще у меня стоит блок реле (8 штук) и они связаны с МД через ETHERNET. Стоимость всего контроллера вместе с реле меньше чем стоимость шилда 5100. И таких примеров масса! Поэтому нужен протокол для RS-485, но как производить арбитраж коллизий..... Похоже его придется разработать самому.

[x13dev]

Ну не скажите. Во первых если мастер только МД, то при зависании его все оборудование перестанет работать.

Согласно моему опыту проблемы с устройствами возникают заметно чаще, чем с компьютером и софтом. Но если уж совсем паранойя мучает, у нас можно 2 гейта воткнуть.

Намного лучше работать по схеме "датчик-исполнитель" чем "датчик-сервер(мозг)-исполнитель", потому что если сервер "умер", исполнитель не исполнит уже ничего. Поэтому хотелось бы что бы все приборы умели быть "мастером", тогда сеть не будет зависеть от центрального сервера.

Сильно напоминает LON-Bus, из того с чем я работал. И проблемы типичные: зоопарк прошивок с необходимостью помнить - а что там было наворочено. И проблемы с отладкой.

Ну мы же не космический корабль строим - зачем же нам делать несколько разных интерфейсов передачи данных?

Несколько интерфейсов нужны так-как необходимо решать несколько задач. Как-то связь Server-Server(SS), Server-Device(SD) и Device-Device(DD). Если для связи SD есть всего 2 варианта: Ethernet или последовательный порт, то для DD нужно учитывать расстояние и среду передачи. Например: шкаф(TTL serial, I2C), комната(RS232, RS485, CAN, Bluetooth), здание(RS485, CAN, RF, Ethernet).
В этом я согласен с Don Dingee, нужно делать бриджи с поддержкой нескольких протоколов.

Поэтому нужен протокол для RS-485, но как производить арбитраж коллизий..... Похоже его придется разработать самому.

Можно использовать доступ по маркеру как в Token Ring. В RS485 к сожалений нет аппаратного обнаружения коллизий, это не CAN.

[x13dev]

Для связи Server-Server нашёл WAMP - Web Application Messaging Protocol.
Что интересного:
Поддерживает asynchronous messaging patterns: publish-subscribe и RPC.
В качестве транспорта использует Websocket+JSON или TCP+MsgPack.
Есть клиентская библиотека для JavaScript из браузера.
Сложность базового профиля сопоставима с MQTT. Advanced профиль содержит кучу расширений.

[ksgroup]

Можно использовать доступ по маркеру как в Token Ring. В RS485 к сожалений нет аппаратного обнаружения коллизий, это не CAN.

К сожалению так как в Token Ring не получится. Там все приборы включаются в кольцо и маркер ходит по кругу, проходя через каждое устройство, а в RS485 параллельное включение устройств - мы не имеем отдельно входа и отдельно выхода. Тут скорее всего нужно что то основанное либо на задержке по рандому, либо на очередности по ID. Вариант с задержкой передачи со случайным значением времени, все же не гарантирует 100% отсутствие коллизий, так как нет гарантии что в двух или более устройствах не будет установлена одинаковая задержка. Очередность по ID очень похоже на Token Ring, но тоже имеет свои недостатки, так как при подключении нового устройства, либо отключении одного из устройств, нарушается очередность, но эти недостатки не так ощутимы. А какой интересно протокол используется в промышленных системах СКУД? Там ведь в основном используется RS485. Но скорее всего там не мультимастер.

[x13dev]

Тут скорее всего нужно что то основанное либо на задержке по рандому, либо на очередности по ID.

Если так хочется мультимастер, то точно работал вариант с запросом на занятие шины.

Дома я звезду делал, но надоело стены долбить.

hub485.jpg (70.09 КБ) 10683 просмотра