Шина данных (KNX, HDL BUSPRO, RS-485 мультимастер)
Добавлено: Пт ноя 25, 2016 4:50 pm
РАЗМЫШЛЕНИЕ НА ТЕМУ ШИНЫ ДАННЫХ УМНОГО ДОМА (KNX, HDL BUSPRO, SMART BUS, RS-485 МУЛЬТИМАСТЕР)
Введение
Как и многие из нас заинтересовался я системой автоматизации дома, или как принято называть «Умный дом». В сети много идей и проектов, но хотелось сделать законченное готовое решение в корпусе на DIN –рейку и платах изготовленных в заводских условиях.
Для удешевление системы, решено было отказаться от Ethernet сети и сделать на RS-485:
- плюсы - дешевые микросхемы сети, и топологи сети позволяющая подключать устройства последовательно по двум проводам на длину линии 1200 м.
- минусы – из имеющихся открытых протоколов таких, как ModBus RTU где есть Master и Slave. Все Slave - устройства в сети молчат, только мастер спрашивает, ему уже отвечают, для небольшой сети это все нормально, но когда количество устройств растет и задержки увеличиваются, так как опрос происходит в цикле.
Но это все влияет на обратную связь, то есть на отображение информации, например на панели визуализации. А когда мы отправляем команду с той же панели команда в вклинивается в цикл опроса и например лампа включается моментально.
Решено было остановится на шине RS-485. Сделал несколько прототипов модулей и шлюза и на тот момент так как только начал изучать программирование, сделал на своем собственном протоколе на теоретических основах modbus.
И заказал несколько плат на заводе в Поднебесной.
Позже была допилена пршивка и все было переведено на modbus RTU. Теперь система выглядела так конечные устройства Slave управления освещениеем и прочии. Ишлюз который от центарльного сервера принимает команды на управления и считывания по Modbus TCP (Ethernet), шлюз в свое время перенаправляет эти потоки в Modbas RTU (RS-485) . Представленно на рисунке ниже.
При реализации такого решения в качестве ПО центрального сервера решено было использовать свободно распространяемое «Majordomo», но и здесь оказалось не все так гладко, так как модуль modbus TCP в программном комплексе Majordomo работает не так как во всех других программа когда можно настроит опрос устройств с интервалом хоть 100-200 мс. В данной системе опрос происходит в основном цикле с минимальной скоростью 2-3 секунды. Это только влияет на отображение статусов, то есть когда нажимается физическая кнопка, то например на ПК или планшете или телефоне вы видите изменение с задержкой 2-3 секунды. А при включение лампы с графического приложения через majordomo лампа включается моментально.
И вдруг я натыкаюсь на интересный протокол MQTT (почитайте в интернете, если не знаете). Решил я переделать шлюз, что бы со стороны Ethernet он работал не по modbus TCP, а по MQTT. Что мне это дало, теперь все устройства в сети RS-485 опрашивает сам шлюз с периодичностью 200 мс, можно и меньше. В случае если состояние изменилось, только тогда шлюз шлет данные по MQTT и все происходит почти без задержек.
Все отлично работает. Но есть пару «но»:
- первое у меня в сети пока 4 ведомых устройства, один модуль управления светом на 8 групп, два диммера на 220 в, и один модуль к которому подключены датчики температуры по шине 1-ware. То есть при добавление устройств, будет увеличивается период опроса и соответственно задержка в отображении на графическом интерфейсе.
- второе одно устройство не может напрямую управлять другим, то есть нельзя сделать выключатель, работающий на шине или не сделать датчик движения который будет работать и в охранной системе и управлять лампой, так как на шину его отдельно нельзя поставить, а если считывать мастером и потом сервером слать команду на включение, будет большая задержка.
RS-485 мультимастер.
Решил по изучать решения оборудования предлагаемого на рынке от европейских и азиатских производите.
С европейцами все понятно KNX дорогое оборудование дорогие приемо-передатчики. Но интересное решение шина организованна на двух проводах по которым идет питание и данные.
Любое устройство в сети может слать информацию и управлять другим устройством, то есть система децентрализована.
Процесс обмена данными между шинными устройствами является событийно управляемым. Данные посылаются в шину отдельными пакетами друг за другом. Таким образом, в одно и то же время по шине передаётся только один пакет данных от одного конкретного шинного устройства. Из соображений надёжности для осуществления обмена телеграммами и для доступа к шине применяется метод децентрализованного доступа CSMA/CA (Carrier Sense Multiple Access/Collision Avoidance).
Одновременный доступ к шине нескольких шинных устройств одной линии независимо друг от друга может привести к возникновению коллизий. Метод CSMA/CA гарантирует сохранность данных и оптимальное использование шины.
Благодаря дополнительному механизму учёта приоритетности телеграммы данные (напр, сообщения о неисправностях) обрабатываются в соответствии с их уровнем приоритетности. Обмен данными в системе KNX является событийно управляемым, т.е. телеграммы передаются только в том случае, если происшедшее событие требует передачи данных.
Это и есть реализация мультимастерной сети. Думаю, а можно же сделать то же самое только на сети RS-485, только нужно будет еще два проводника для организации питания, то есть получим шину на четырех проводах:
И что же выдумаете натыкаюсь на производителя оборудования для умного дома пд брендом HDL. У которого шина построена на RS-485 и работает на мультимастер протоколе BusPro или Smart bus один и тот же протокол с разными названиями, так как создатели там чего то не поделили разъединились и поэтому называют их по разному (если хотите поищите инфу в сети).
А уже программы визуализации и автоматизации, также ПО для настройки оборудования, работает через шлюз, который передает данные из RS-485 (smart bus) в Ethernet (UDP) и обратно соответственно.
Далее немного иллюстраций, для наглядности и понимания.
Сеть RS-485 (HDL Bus pro)
Рекомендованное подключение:
Топология сети HDL
Сложности и решения:
Для того чтобы мои разработки смогли работать на подобной шине необходимо реализовать три вещи:
1. Переработка железа. Которая сведется к тому что бы переделать стабилизатор питания на модуле. Так по шине нужно будет подавать напряжение 24 в и у имеющегося в моих модулях стабилизатор на LT1117 слабый КПД так как избыток напряжения преобразуется в тепло, а с таким напряжением он не справятся.
Для этого решения есть много вариантов. Один из них представлен ниже на микросхеме TPS5430.
С этим трудностей не возникнет. Так что идем дальше.
2. мультимастер протокол для шины RS-485. Протокол HDL BUSPro(smart bus) хоть и открытый, но есть одно большое «НО». Протокол описан, но не описана его реализация, нет описания реализации решения коллизий о которых я упоминал когда говорил про KNX - Метод CSMA/CA (в одно и то же время по шине передаётся только один пакет данных от одного конкретного шинного устройства определеним модулем ) В этом и будет основная трудность реализации.
Ниже предоставлено описание протокола.
Определение базовой структуры протокола
Start
Код запускается символом пакет данных и фиксированного формата 0xAAAA, он начнет получать весь пакет, когда приемник исправить Формат данных и принимать данные, как длина пакета данных.
LEN of Data Package
это одно показывает, сколько байт пакета данных.
Диапазон Данных: 11-78.
Как рассчитать?
SN от 2 до 10, не включенными SN 1.
Original subnet ID & Original device ID
Адрес устройства, к которому отсылает пакет данных, объем значение 0-254
Адреса включает в себя 2 части, идентификатор подсети и ID устройства.
Original Device Type
Тип оригинального устройства, другой модуль имеет различные типы устройств; пожалуйста, см. таблицу ниже определения. Объем значение 0-65535
Operation code
Коды операций указывать все функции и команды системы. От 0-65535
Target subnet ID & Target Device ID
Адрес устройства, которое будет получать пакет данных. Объем данных 0-255
если идентификатор сети и идентификатор устройства 255, это означает, транслировать пакет данных будут приниматься все модули.
Additional Content
Данные о дополнительном контенте, который является переменным, это зависит от кода операции, различные операции код может имеет различное содержание.
CRC H & CRC L
Код CRC проверку, чтобы проверить потерю данных или нет. Как получить сведения CRC?
Мы получим данные от SN 2 до 9, а затем применить CRC арифметике для генерации кода проверки. Мы расскажем подробно ниже.
3. Ну и конечно третье, наверное самая сложная задача, написать ПО для конфигурации устройство, чтобы например в любой момент времени подключившись к шине можно было переназначить, что данный выключатель включит данную группу света на этом устройстве или на другом.
Для этого я засел за глубокое изучение С++ и QT. Но не знаю насколько я смогу с этим стправиться.
P.S. Пишите свои мысли, идеи по данному вопросу. Если у кого есть, какие дополнительные сведения или библиотеки или готовые протоколы, пишиТе или поделитесь ссылками.
Еще очень интересно если у кого то есть возможность сфотографировать или есть такие фото заводских модулей для умного дома, поделитесь, пожалуйста, хотелось бы посмотреть на каких электронных компонентах они собраны и на каких микроконтроллерах.
Введение
Как и многие из нас заинтересовался я системой автоматизации дома, или как принято называть «Умный дом». В сети много идей и проектов, но хотелось сделать законченное готовое решение в корпусе на DIN –рейку и платах изготовленных в заводских условиях.
Для удешевление системы, решено было отказаться от Ethernet сети и сделать на RS-485:
- плюсы - дешевые микросхемы сети, и топологи сети позволяющая подключать устройства последовательно по двум проводам на длину линии 1200 м.
- минусы – из имеющихся открытых протоколов таких, как ModBus RTU где есть Master и Slave. Все Slave - устройства в сети молчат, только мастер спрашивает, ему уже отвечают, для небольшой сети это все нормально, но когда количество устройств растет и задержки увеличиваются, так как опрос происходит в цикле.
Но это все влияет на обратную связь, то есть на отображение информации, например на панели визуализации. А когда мы отправляем команду с той же панели команда в вклинивается в цикл опроса и например лампа включается моментально.
Решено было остановится на шине RS-485. Сделал несколько прототипов модулей и шлюза и на тот момент так как только начал изучать программирование, сделал на своем собственном протоколе на теоретических основах modbus.
И заказал несколько плат на заводе в Поднебесной.
Позже была допилена пршивка и все было переведено на modbus RTU. Теперь система выглядела так конечные устройства Slave управления освещениеем и прочии. Ишлюз который от центарльного сервера принимает команды на управления и считывания по Modbus TCP (Ethernet), шлюз в свое время перенаправляет эти потоки в Modbas RTU (RS-485) . Представленно на рисунке ниже.
При реализации такого решения в качестве ПО центрального сервера решено было использовать свободно распространяемое «Majordomo», но и здесь оказалось не все так гладко, так как модуль modbus TCP в программном комплексе Majordomo работает не так как во всех других программа когда можно настроит опрос устройств с интервалом хоть 100-200 мс. В данной системе опрос происходит в основном цикле с минимальной скоростью 2-3 секунды. Это только влияет на отображение статусов, то есть когда нажимается физическая кнопка, то например на ПК или планшете или телефоне вы видите изменение с задержкой 2-3 секунды. А при включение лампы с графического приложения через majordomo лампа включается моментально.
И вдруг я натыкаюсь на интересный протокол MQTT (почитайте в интернете, если не знаете). Решил я переделать шлюз, что бы со стороны Ethernet он работал не по modbus TCP, а по MQTT. Что мне это дало, теперь все устройства в сети RS-485 опрашивает сам шлюз с периодичностью 200 мс, можно и меньше. В случае если состояние изменилось, только тогда шлюз шлет данные по MQTT и все происходит почти без задержек.
Все отлично работает. Но есть пару «но»:
- первое у меня в сети пока 4 ведомых устройства, один модуль управления светом на 8 групп, два диммера на 220 в, и один модуль к которому подключены датчики температуры по шине 1-ware. То есть при добавление устройств, будет увеличивается период опроса и соответственно задержка в отображении на графическом интерфейсе.
- второе одно устройство не может напрямую управлять другим, то есть нельзя сделать выключатель, работающий на шине или не сделать датчик движения который будет работать и в охранной системе и управлять лампой, так как на шину его отдельно нельзя поставить, а если считывать мастером и потом сервером слать команду на включение, будет большая задержка.
RS-485 мультимастер.
Решил по изучать решения оборудования предлагаемого на рынке от европейских и азиатских производите.
С европейцами все понятно KNX дорогое оборудование дорогие приемо-передатчики. Но интересное решение шина организованна на двух проводах по которым идет питание и данные.
Любое устройство в сети может слать информацию и управлять другим устройством, то есть система децентрализована.
Процесс обмена данными между шинными устройствами является событийно управляемым. Данные посылаются в шину отдельными пакетами друг за другом. Таким образом, в одно и то же время по шине передаётся только один пакет данных от одного конкретного шинного устройства. Из соображений надёжности для осуществления обмена телеграммами и для доступа к шине применяется метод децентрализованного доступа CSMA/CA (Carrier Sense Multiple Access/Collision Avoidance).
Одновременный доступ к шине нескольких шинных устройств одной линии независимо друг от друга может привести к возникновению коллизий. Метод CSMA/CA гарантирует сохранность данных и оптимальное использование шины.
Благодаря дополнительному механизму учёта приоритетности телеграммы данные (напр, сообщения о неисправностях) обрабатываются в соответствии с их уровнем приоритетности. Обмен данными в системе KNX является событийно управляемым, т.е. телеграммы передаются только в том случае, если происшедшее событие требует передачи данных.
Это и есть реализация мультимастерной сети. Думаю, а можно же сделать то же самое только на сети RS-485, только нужно будет еще два проводника для организации питания, то есть получим шину на четырех проводах:
- GND
+ Data
–Data
+ ACC
И что же выдумаете натыкаюсь на производителя оборудования для умного дома пд брендом HDL. У которого шина построена на RS-485 и работает на мультимастер протоколе BusPro или Smart bus один и тот же протокол с разными названиями, так как создатели там чего то не поделили разъединились и поэтому называют их по разному (если хотите поищите инфу в сети).
А уже программы визуализации и автоматизации, также ПО для настройки оборудования, работает через шлюз, который передает данные из RS-485 (smart bus) в Ethernet (UDP) и обратно соответственно.
Далее немного иллюстраций, для наглядности и понимания.
Сеть RS-485 (HDL Bus pro)
Рекомендованное подключение:
- COM (питание - ) → коричнево-белый, оранжево-белый
Data －(данные - ) → сине-белый, зелено-белый
Data ＋(данные + ) → синий, зеленый
DC24V (питание + ) → коричневый, оранжевый
Топология сети HDL
Сложности и решения:
Для того чтобы мои разработки смогли работать на подобной шине необходимо реализовать три вещи:
1. Переработка железа. Которая сведется к тому что бы переделать стабилизатор питания на модуле. Так по шине нужно будет подавать напряжение 24 в и у имеющегося в моих модулях стабилизатор на LT1117 слабый КПД так как избыток напряжения преобразуется в тепло, а с таким напряжением он не справятся.
Для этого решения есть много вариантов. Один из них представлен ниже на микросхеме TPS5430.
Код: Выделить всё
Wide Input Voltage Range:
– TPS5430: 5.5 V to 36 V that integrates a low-resistance, high-side N-channel MOSFET. Included on the substrate with the listed
– TPS5431: 5.5 V to 23 V
High Efficiency up to 95% Enabled by 110-mΩ accuracy under transient conditions; an undervoltage- Integrated MOSFET SwitchС этим трудностей не возникнет. Так что идем дальше.
2. мультимастер протокол для шины RS-485. Протокол HDL BUSPro(smart bus) хоть и открытый, но есть одно большое «НО». Протокол описан, но не описана его реализация, нет описания реализации решения коллизий о которых я упоминал когда говорил про KNX - Метод CSMA/CA (в одно и то же время по шине передаётся только один пакет данных от одного конкретного шинного устройства определеним модулем ) В этом и будет основная трудность реализации.
Ниже предоставлено описание протокола.
Определение базовой структуры протокола
- 2016-11-25_16-43-48.png (31.87 КБ) 6874 просмотра
Start
Код запускается символом пакет данных и фиксированного формата 0xAAAA, он начнет получать весь пакет, когда приемник исправить Формат данных и принимать данные, как длина пакета данных.
LEN of Data Package
это одно показывает, сколько байт пакета данных.
Диапазон Данных: 11-78.
Как рассчитать?
SN от 2 до 10, не включенными SN 1.
Original subnet ID & Original device ID
Адрес устройства, к которому отсылает пакет данных, объем значение 0-254
Адреса включает в себя 2 части, идентификатор подсети и ID устройства.
Original Device Type
Тип оригинального устройства, другой модуль имеет различные типы устройств; пожалуйста, см. таблицу ниже определения. Объем значение 0-65535
Operation code
Коды операций указывать все функции и команды системы. От 0-65535
Target subnet ID & Target Device ID
Адрес устройства, которое будет получать пакет данных. Объем данных 0-255
если идентификатор сети и идентификатор устройства 255, это означает, транслировать пакет данных будут приниматься все модули.
Additional Content
Данные о дополнительном контенте, который является переменным, это зависит от кода операции, различные операции код может имеет различное содержание.
CRC H & CRC L
Код CRC проверку, чтобы проверить потерю данных или нет. Как получить сведения CRC?
Мы получим данные от SN 2 до 9, а затем применить CRC арифметике для генерации кода проверки. Мы расскажем подробно ниже.
3. Ну и конечно третье, наверное самая сложная задача, написать ПО для конфигурации устройство, чтобы например в любой момент времени подключившись к шине можно было переназначить, что данный выключатель включит данную группу света на этом устройстве или на другом.
Для этого я засел за глубокое изучение С++ и QT. Но не знаю насколько я смогу с этим стправиться.
P.S. Пишите свои мысли, идеи по данному вопросу. Если у кого есть, какие дополнительные сведения или библиотеки или готовые протоколы, пишиТе или поделитесь ссылками.
Еще очень интересно если у кого то есть возможность сфотографировать или есть такие фото заводских модулей для умного дома, поделитесь, пожалуйста, хотелось бы посмотреть на каких электронных компонентах они собраны и на каких микроконтроллерах.