Всем привет!
Хочу поделиться JAVA библиотекой для работы с радио-устройствами домашней автоматизации (обычно 433.92 МГц) над которой я работаю в последнее время. Она еще достаточно сырая для серьезного использования, но для домашних поделок — в самый раз
Адрес на github — github.com/eschava/rf-protocols-java
После покупки Cubietruck решил перенести на него все задачи умного дома, которые выполнялись на Ардуино. В основном это прием и передача радио-сообщений устройствам домашней автоматизации (розетки, датчики, отопление)
Все, что было найдено в сети, было либо сделано только для Raspberry Pi, либо слишком заточено под какую-то определенную функциональность. Поэтому решил реализовать все самому, используя привычный язык разработки (Java) и сделать как можно более гибким и расширяемым (реестр фабрик и все такое, как это принято в джаве)
Для работы с RF устройствами посредством GPIO портов выбрал достаточно малоизвестную, но многообещающую библиотеку libbulldog которая позволяет абстрагироваться от платформы на которой все запущено. На данный момент поддерживаются (теоретически) Raspberry Pi, BeagleBoard, Cubieboard, но тестировалось только на Cubieboard3 (aka Cubietruck) который есть у меня в наличии.
Также поддерживается (опять же теоретически) популярная библиотека для Raspberry PI Pi4j, но, к сожалению, не было возможности опробовать ее на практике
На данный момент реализованы следующие протоколы
— Oregon V2 (датчики температуры, влажности, такие как THN132N, THR238NF, THWR800, THGN132N и т.д.)
— Oregon V3 (датчики температуры, влажности)
— Oregon SL109 (датчики температуры, влажности)
— Owl (датчики потребляемого тока Owl Micro+)
— PT2262/PT2272 (китайские радиореле, соответствующая ардуино библиотека называется RC-switch)
— RemoteSwitch (китайские радиореле, название по аналогии с известной ардуино библиотекой)
плюс
— несколько утилит для исследования и диагностики протоколов (см. далее)
— MQTT клиент для бесшовной интеграции с системами умного дома (см. далее)
В планах добавить поддержку как можно большего количества популярных радио протоколов (в первую очередь хотелось бы Noolite и La Cross)
Работа с радио-протоколами разбита на три уровня:
— непосредственно сигналы, поступающие от приемника на GPIO порт (уровень сигналов)
— сигналы трансформируются в пакеты. Как правило это последовательность битов (уровень пакетов)
— пакеты анализируются и становятся сообщениями. Сообщения уже имеют конкретные пользовательские свойства (температура, команда и т.д.) (уровень сообщений)
Каждый уровень независим от соседних и может использоваться повторно (например преобразование из сигналов в пакеты часто одинаковое для многих устройств, но уже формирование сообщений из пакетов уникально)
Все протоколы могут максимально настраиваться с помощью .properties файлов, так как многие константы (например продолжительность импульсов) могут варьироваться для разных устройств
Их на данный момент две. Покажу как используя обе из них, разобраться с протоколом от радио-брелоков с микросхемой PT2262 (самый популярный на aliexpress)
— breakdown: служит для исследования длины импульсов поступающих от приемника. Как правило, когда устройство не посылает данные в эфир, на GPIO порт от приемника поступает шум с разнообразной длиной импульсов, но если нажать кнопку на передатчике или дождаться сигнала, то заметно, что принимаемые импульсы по продолжительности попадают в некоторые группы. Например для кнопки включения программа выдаст такие данные (продолжительность импульсов в микросекундах):
Первая половина строчек — шум, вторая — зажата кнопка на брелоке
Из вывода утилиты становится понятно, что импульсы попадают в следующие группы: (400, 600) и (1300, 1600) (если еще немножко поэкспериментировать с группами, то можно выяснить, что есть еще импульсы из группы (15000, 16000))
Теперь попробуем понять, как чередуются импульсы из этих групп. Для этого нам понадобится следующая утилита
— intervals: позволяет дать интервалам импульсов имена и увидеть их последовательность. Назовем первую группу «0», вторую «1», а последнюю, самую длинную, «S». И будем выводить только группы, в которых не меньше 20 импульсов подряд, попадающих в эти интервалы:
(Пояснение — числа в квадратных скобках это продолжительность импульсов перед и после последовательности. Иногда помогает понять почему последовательность прервалась посредине, число в круглых скобках — количество сигналов в последовательности)
Видно, что последовательность между импульсами под названием S всегда одинакова для одной кнопки и выглядит как
0101011001010101011001010110011010100101010101010
Если поизучать последовательности, получаемые от разных кнопок, то можно увидеть что это всегда группы из символов
0101
1010
0110
плюс всегда нолик в конце (синхронизация)
Похоже на троичную систему счисления. Дадим им имена 0,1 2 и получим последовательность
020020221000 для кнопки включения и
020020220100 для кнопки выключения
Можно считать, что дело сделано.
Также в библиотеку входит MQTT клиент, который может быть запущен как отдельное приложение для бесшовной интеграции с готовыми системами умного дома (планировалось с openHAB)
Клиент:
— автоматически посылает MQTT сообщения для всех полученных данных. Например температура, полученная от Oregon устройства, будет опубликована по топику
rf/OregonV2/Temperature
— слушает топики rf/send/PROTOCOL и отправляет радиокоманды с данными, полученными по топику. Например чтобы просимулировать команду от брелока из предыдущего пункта, нужно отправить команду 020020221000 по топику rf/send/pt2262
Запуск:
На данный момент все самостоятельные приложения, входящие в библиотеку, запускаются как обычные Java-приложения с методом main()
Также все имеют -DpropertiesFile параметр для задания файла с настройками (пины, библиотека для работы с пинами и прочее). Примеры .properties файлов есть на github'е ( github.com/eschava/rf-protocols-java/tree/master/examples )
Кроме приложений, описанных раннее, есть еще следующие:
Вывод всех полученных сообщений на консоль
Вывод всех полученных пакетов (более низкоуровневые данные, чем сообщения, как правило это шестнадцатеричный дамп пакетов)
Отправка сообщения по протоколу
Вроде бы все
Жду отзывов, баг-репортов, фич-реквестов и прочих страшных слов
Хочу поделиться JAVA библиотекой для работы с радио-устройствами домашней автоматизации (обычно 433.92 МГц) над которой я работаю в последнее время. Она еще достаточно сырая для серьезного использования, но для домашних поделок — в самый раз
Адрес на github — github.com/eschava/rf-protocols-java
Предпосылки к созданию
После покупки Cubietruck решил перенести на него все задачи умного дома, которые выполнялись на Ардуино. В основном это прием и передача радио-сообщений устройствам домашней автоматизации (розетки, датчики, отопление)
Все, что было найдено в сети, было либо сделано только для Raspberry Pi, либо слишком заточено под какую-то определенную функциональность. Поэтому решил реализовать все самому, используя привычный язык разработки (Java) и сделать как можно более гибким и расширяемым (реестр фабрик и все такое, как это принято в джаве)
Для работы с RF устройствами посредством GPIO портов выбрал достаточно малоизвестную, но многообещающую библиотеку libbulldog которая позволяет абстрагироваться от платформы на которой все запущено. На данный момент поддерживаются (теоретически) Raspberry Pi, BeagleBoard, Cubieboard, но тестировалось только на Cubieboard3 (aka Cubietruck) который есть у меня в наличии.
Также поддерживается (опять же теоретически) популярная библиотека для Raspberry PI Pi4j, но, к сожалению, не было возможности опробовать ее на практике
Основные идеи
- Независимость от платформы
- Автономность всех компонент (для реализации любых задач)
- Легкая расширяемость (поддержка новых устройств и платформ)
- Декодированные сообщения поддерживают два интерфейса: обычный вызов методов (getTemperature()) и обращение к свойствам по имени
- Максимальный вынос настроек за пределы кода для более точной подстройки под устройства без изменения кода
Что реализовано
На данный момент реализованы следующие протоколы
— Oregon V2 (датчики температуры, влажности, такие как THN132N, THR238NF, THWR800, THGN132N и т.д.)
— Oregon V3 (датчики температуры, влажности)
— Oregon SL109 (датчики температуры, влажности)
— Owl (датчики потребляемого тока Owl Micro+)
— PT2262/PT2272 (китайские радиореле, соответствующая ардуино библиотека называется RC-switch)
— RemoteSwitch (китайские радиореле, название по аналогии с известной ардуино библиотекой)
плюс
— несколько утилит для исследования и диагностики протоколов (см. далее)
— MQTT клиент для бесшовной интеграции с системами умного дома (см. далее)
В планах добавить поддержку как можно большего количества популярных радио протоколов (в первую очередь хотелось бы Noolite и La Cross)
Архитектура
Работа с радио-протоколами разбита на три уровня:
— непосредственно сигналы, поступающие от приемника на GPIO порт (уровень сигналов)
— сигналы трансформируются в пакеты. Как правило это последовательность битов (уровень пакетов)
— пакеты анализируются и становятся сообщениями. Сообщения уже имеют конкретные пользовательские свойства (температура, команда и т.д.) (уровень сообщений)
Каждый уровень независим от соседних и может использоваться повторно (например преобразование из сигналов в пакеты часто одинаковое для многих устройств, но уже формирование сообщений из пакетов уникально)
Все протоколы могут максимально настраиваться с помощью .properties файлов, так как многие константы (например продолжительность импульсов) могут варьироваться для разных устройств
Утилиты для исследования протоколов
Их на данный момент две. Покажу как используя обе из них, разобраться с протоколом от радио-брелоков с микросхемой PT2262 (самый популярный на aliexpress)
— breakdown: служит для исследования длины импульсов поступающих от приемника. Как правило, когда устройство не посылает данные в эфир, на GPIO порт от приемника поступает шум с разнообразной длиной импульсов, но если нажать кнопку на передатчике или дождаться сигнала, то заметно, что принимаемые импульсы по продолжительности попадают в некоторые группы. Например для кнопки включения программа выдаст такие данные (продолжительность импульсов в микросекундах):
cubie@Cubian:~/gpio$ sudo java -cp bulldog.cubieboard.jar:rf-protocols-0.1-SNAPSHOT.jar -DpropertiesFile=breakdown.properties -Dlistener.groupCount=20 -Dlistener.maxLength=2000 rf.protocols.analysis.breakdown.BreakdownMain <100 <200 <300 <400 <500 <600 <700 <800 <900 <1000 <1100 <1200 <1300 <1400 <1500 <1600 <1700 <1800 <1900 <2000 >=2000 2054 1099 573 223 137 92 45 48 13 12 9 8 5 3 5 6 1 0 2 1 30 2399 1417 686 317 155 111 52 30 6 2 7 0 3 2 1 0 0 1 1 1 7 2479 1396 675 319 189 103 59 28 5 6 4 0 1 0 1 2 3 0 0 1 5 2333 1351 751 316 199 91 34 26 9 7 2 2 2 2 1 3 2 0 1 1 7 2307 1254 712 297 175 108 106 20 6 5 1 3 1 0 0 1 2 2 0 1 9 1249 714 368 164 182 158 33 12 3 6 0 4 10 110 63 2 2 0 1 0 12 1 0 1 0 171 232 0 0 0 0 0 1 0 252 127 3 0 0 0 0 22 0 0 0 0 173 226 0 0 0 0 0 0 1 247 131 2 0 0 0 0 21 1 0 1 0 201 196 0 0 0 0 0 0 1 217 156 4 0 0 0 0 20 0 0 0 0 216 188 0 0 1 0 0 0 0 218 159 4 0 0 0 0 22 0 0 0 1 195 205 0 0 0 0 0 1 0 227 152 2 0 0 0 0 21
Первая половина строчек — шум, вторая — зажата кнопка на брелоке
Из вывода утилиты становится понятно, что импульсы попадают в следующие группы: (400, 600) и (1300, 1600) (если еще немножко поэкспериментировать с группами, то можно выяснить, что есть еще импульсы из группы (15000, 16000))
Теперь попробуем понять, как чередуются импульсы из этих групп. Для этого нам понадобится следующая утилита
— intervals: позволяет дать интервалам импульсов имена и увидеть их последовательность. Назовем первую группу «0», вторую «1», а последнюю, самую длинную, «S». И будем выводить только группы, в которых не меньше 20 импульсов подряд, попадающих в эти интервалы:
cubie@Cubian:~/gpio$ sudo java -cp bulldog.cubieboard.jar:rf-protocols-0.1-SNAPSHOT.jar -DpropertiesFile=pt2262.properties rf.protocols.analysis.intervals.IntervalsMain [678]10010101100110101001010[1296] (23) [-1]01011001010101011001010110011010100101010101010S0101011001010101011001010110011010100101010101010S0101011001010101011001010110011010100101010101010S0101011001010101011001010110011010100101010101010[150716] (197) [770]100101011001101010010101010[1281] (27) [3418]S0101011001010101011001010110011010100101010101010S0101011001010101011001010110011010100101010101010S0101011001010101011001010110011010100101010101010S010101100101010101100101011001[934] (181)
(Пояснение — числа в квадратных скобках это продолжительность импульсов перед и после последовательности. Иногда помогает понять почему последовательность прервалась посредине, число в круглых скобках — количество сигналов в последовательности)
Видно, что последовательность между импульсами под названием S всегда одинакова для одной кнопки и выглядит как
0101011001010101011001010110011010100101010101010
Если поизучать последовательности, получаемые от разных кнопок, то можно увидеть что это всегда группы из символов
0101
1010
0110
плюс всегда нолик в конце (синхронизация)
Похоже на троичную систему счисления. Дадим им имена 0,1 2 и получим последовательность
020020221000 для кнопки включения и
020020220100 для кнопки выключения
Можно считать, что дело сделано.
MQTT клиент
Также в библиотеку входит MQTT клиент, который может быть запущен как отдельное приложение для бесшовной интеграции с готовыми системами умного дома (планировалось с openHAB)
Клиент:
— автоматически посылает MQTT сообщения для всех полученных данных. Например температура, полученная от Oregon устройства, будет опубликована по топику
rf/OregonV2/Temperature
— слушает топики rf/send/PROTOCOL и отправляет радиокоманды с данными, полученными по топику. Например чтобы просимулировать команду от брелока из предыдущего пункта, нужно отправить команду 020020221000 по топику rf/send/pt2262
Запуск:
sudo java -cp bulldog.cubieboard.jar:mqtt-client-0.4.0.jar:ST4-4.0.8.jar:rf-protocols-0.1-SNAPSHOT.jar:antlr-runtime-3.5.2.jar -DpropertiesFile=mqtt.properties rf.protocols.external.paho.MqttMain
Как запустить самостоятельные приложения, входящие в библиотеку
На данный момент все самостоятельные приложения, входящие в библиотеку, запускаются как обычные Java-приложения с методом main()
Также все имеют -DpropertiesFile параметр для задания файла с настройками (пины, библиотека для работы с пинами и прочее). Примеры .properties файлов есть на github'е ( github.com/eschava/rf-protocols-java/tree/master/examples )
Кроме приложений, описанных раннее, есть еще следующие:
Вывод всех полученных сообщений на консоль
sudo java -cp bulldog.cubieboard.jar:rf-protocols-0.1-SNAPSHOT.jar -DpropertiesFile=protocols.properties rf.protocols.analysis.PrintAllMessagesВывод всех полученных пакетов (более низкоуровневые данные, чем сообщения, как правило это шестнадцатеричный дамп пакетов)
sudo java -cp bulldog.cubieboard.jar:rf-protocols-0.1-SNAPSHOT.jar -DpropertiesFile=protocols.properties rf.protocols.analysis.PrintAllPacketsОтправка сообщения по протоколу
sudo java -cp bulldog.cubieboard.jar:rf-protocols-0.1-SNAPSHOT.jar -DpropertiesFile=sendmessage.properties -Dprotocol=RemoteSwitch -Dmessage=111110222220 rf.protocols.analysis.SendStringMessage
Вроде бы все
Жду отзывов, баг-репортов, фич-реквестов и прочих страшных слов
