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

[shemnik69]

А по подробнее, про данный девайс, что на фото.
Какая основа. Что за протокол?
Я так понял что в основе протокол "от автора"?

[ksgroup]

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

Можно подробнее? Как запрашивается занятие шины и кто его отдает?
Стены долбить не понадобится - у меня везде в пол и стены при ремонте заложены пластиковые трубы под провода - затягивается сталькой новый провод на ура.

[x13dev]

А по подробнее, про данный девайс, что на фото.
Какая основа. Что за протокол?
Я так понял что в основе протокол "от автора"?

Одна из первых моих самоделок.

Hub485_sc.jpg (30.37 КБ) 10519 просмотров

Хаб постоянно опрашивает устройства - "Есть Чё"? При положительном ответе отсылает на компьютер. Была даже попытка организовать хабы в кольцо. При отсутствии ответа отсылается, что устройство потерялось.
Поскольку на каждое устройство идёт свой кабель, то можно подать питание и поломка устройства не влияет на всю сеть.

Как запрашивается занятие шины и кто его отдает?

Тот-же самый CSMA, только для маркера. За счёт маленькой длинны пакета уменьшается время разрешения коллизий.
Устройство слушает шину, если свободно - отослать запрос на занятие. Мастер отвечает - <адрес> <занимай> или <все> <коллизия>. По окончании устройство шлёт <все> <свободно>. Если при занятой шине долго было тихо, то мастер шлёт принудительно <все> <свободно>.

[shemnik69]

1. В основе как понял Atmega 32 ( )/
2. Судя по схеме цепи RX/TX разделены? Т.е по сути полный дуплекс.
3. Если мастер (т.е хаб) постоянно запрашивает (статус) то о какой коллизии идет речь?
Схема и программное обеспечение должны дополнять друг друга.
Скажу сразу я не силен в программировании как таковом (т.е PHP и подобное) но МК я освоил...

Коллизии, в структурной сети состоящей из однотипных по способу формирования запросов/ответов возможны только при условии если каждое из устройств имеющих возможность занимать общую линию в случайный момент времени с генерирует свой запрос с одновременным запросом другого устройства. Но тогда.
Если сеть состоит из разделенных каналов то по сути передатчики это сами устройства а приемник -мастер.
Если же, алгоритмика формирования запроса, строится как запрос/ответ с задержкой скажем 2-5 мс. то как правило коллизии это нестандартное точнее аварийное состояние.
Приведу пример.
Скажем массив счетчиков (RS485) мастер только и "кричит " в линию ID-DATA и все в ответ DATA +СRC//
Что может быть проще. Так же в основном и строятся алгоритмы обмена, поэтому на мой взгляд стоит не отвергать проверенные годами эксплуатации решения и на которые уже подведена как материальная так и программная база.
Уже указывалось выше что в основном сети которые строят владельцы систем УД это чаще всего витая пара (лучше ее что еще ? ) а раз так то под нее и стоит играть. Далее..варианты это либо звезда на которой присутствует мультиплексорное разделение либо многоканальный МК (например Arduino Mega) либо другое схемное решение. Либо это общая шина, что проще ...но все выше описанное к ней как раз и относится.
Теперь к металлу ..
Если брать несколько устройств датчик /мастер то проще делать по схеме (RX/TX) но в алгоритм заложить простую блокировку скажем передача только по запросу "Status" тогда используя такой механизм а также определенные коды скажем взаимного обмена можно в случае отсутствия сервера генерировать мультизапрос (типа Ststus 1 //2//3) и только на него будет конкретный ответ.
Я моделировал подобные ситуации в стимуляторе (Proteus) на примере двух плат контроллера ворот и контроллера освещения, а учитывая что данные устройства имеют COM (USART/RS232) порт (не USB) то мне очень просто его перевести в (стимуляторе) скажем в RS485 то закачав виртуально в процессоры код можно играть с возможными вариантами одновременно внося оперативные изменения в скетч (код).

Либо еще вариант ...использовать промышленное устройства. (Подходит не всем) а раз так .. следовательно тему нужно продолжать.

С Уважением!

[binladin]

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

Да, WAMP заманчивая вещь, там ещё и Routed RPC есть. Есть его реализация и на PHP, причем как клиента, так и роутера - Thruway.

[x13dev]

1. В основе как понял Atmega 32 ( )/

Я использовал ATMega162

2. Судя по схеме цепи RX/TX разделены? Т.е по сути полный дуплекс.

Нет. Они заходят на драйвер для RS485.

3. Если мастер (т.е хаб) постоянно запрашивает (статус) то о какой коллизии идет речь?

Это разные варианты. Схема для звезды, описание для общей шины.

[x13dev]

Да, WAMP заманчивая вещь, там ещё и Routed RPC есть. Есть его реализация и на PHP, причем как клиента, так и роутера - Thruway.

Хочется его использовать для обмена между комнатными серверами и для конфигуратора.
Ещё есть желание с web сервера раздавать только статику, а layout и данные отдавать через WAMP. Есть ли у кого такой опыт?

[sergejey]

Почитал вчера ночью про WAMP -- отличная штука. Из минусов только необходимость запуска отдельного сервиса для обслуживания веб-сокетов, но вообще понравилось. В перспективе можно на это дело перенести всё взаимодействие интерфейса с сервером вместо AJAX-а для работы в реальном времени.

[shemnik69]

Проанализировал все что отражено выше.
Итог:
Для простых и минимальных по возможностям систем это 1-ware (система дорогая. и не очень доступна (ну по крайне мере не везде)) может за исключением датчиков температуры.
Для более менее развитых и взаимно вложенных по алгоритмике хорошо идет как радио адаптеры, так и проводные решения. (но это как каналы организации передачи)
Для систем которые изначально строятся как шинные (не монтаж ) т.е где один мастер, то тут в качестве "железа" прекрасно интерфейс RS485 и в идеале конечно стандартизированный протокол. (CAN. ModBUS. KNX).
Либо протокол свой, но узко специализированный. Работает стабильно (правда короткие лучи) и довольно успешно. но не совсем легко переносится т.е Plug/Play не получится.
Еще есть USB (Тоже своего рода сеть.) например на мат плате 8 портов (Атом) есть еще HUB т.е подсесть с разными USB камерами, флешками. видео и звуковыми адаптерами, а также HDD, и всевозможные "свистки" (1-ware. УСО-2, USB/RS485 да и Arduino кстати, тоже по сути полноправная сеть.

Самый же продвинутый и скажем так упорядоченный да и технически/программно подкрепленный это конечно IP/TCP. Тут наверное самое широкое и предельно отработанное поле деятельности и самое главное что существует промышленная продукция под такой протокол. Немного конечно дороговато, (может быть) но то что получаешь взамен, оправдывает затраты. Самый простой вариант тут либо Mega.

От себя ...поскольку сама система уже работает, то она отчасти имеет все выше перечисленные ветви сетей. Самая большая 1-ware (датчики). Но постепенно все переведется на IP/TCP.

[Ivan]

1-Wire - Лучше уже не смотреть. Кроме температуры и ключей уже почти ничего нет в продаже.

RS485 - можно использовать если вы сами собираетесь всё паять и программировать. Готовых устройств почти нет.

CAN - тоже самое что RS485 только выйдет вам дороже (кстати авто производители начинают от него отказываться в пользу Ethernet)

Ethernet - стоит использовать если у вас будет 1 устройство на комнату с кучей датчиков. В противном случаи будет дорого

NooLite - проблема обратной связи и кроме как силовых модулей нет устройств (не считая 3 новых устройств)

ZWave - идеальная штука в плане готового решения. Но дорого

Предлагаю вам посмотреть в сторону mySensors.
- http://mysensors.org/
- http://smartliving.ru/forum/viewtopic.php?f=8&t=1852

Цена не дорогая. Разрабатывать ничего не нужно. Придётся паять самому

Сам перехожу на них. Уходя от 1-Wire, RF433