Размышление на тему шины данных умного дома (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, только нужно будет еще два проводника для организации питания, то есть получим шину на четырех проводах:

  1. GND
  2. + Data
  3. –Data
  4. + 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 (в одно и то же время по шине передаётся только один пакет данных от одного конкретного шинного устройства определеним модулем ) В этом и будет основная трудность реализации.

 

Ниже предоставлено описание протокола.

  

 

Определение базовой структуры протокола

 

 

Start code

Код запускается символом пакет данных и фиксированного формата 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. Пишите свои мысли, идеи по данному вопросу.  Если у кого есть, какие дополнительные  сведения или библиотеки или готовые протоколы, пишите или делитесь ссылками.

Еще очень интересно если у кого то есть возможность сфотографировать или есть такие фото заводских модулей для умного дома, поделитесь, пожалуйста, хотелось бы посмотреть на каких электронных компонентах они собраны и на каких микроконтроллерах.

 

 

Категории

Теги

Последние записи

Статистика

Яндекс.Метрика
© 2014 - 2018 OKbit.ru - умный дом. Все права защищены.