Another library to work with 433 MHz devices
Hello!
I want to share the JAVA library for working with home automation radio devices (usually 433.92 MHz) that I have been working on recently. It is still raw enough for serious use, but for home crafts it is just right.
Address on github - github.com/eschava/rf-protocols-java
After buying Cubietruck decided to transfer to it all the tasks of the smart home, which were performed on the Arduino. This is mainly the reception and transmission of radio messages to home automation devices (sockets, sensors, heating)
Everything that was found on the network was either done only for the Raspberry Pi, or too sharpened for some specific functionality. Therefore, I decided to implement everything myself, using the familiar development language (Java) and make it as flexible and expandable as possible (the register of factories and all that, as is customary in Java)
')
To work with RF devices via GPIO ports, I chose a rather obscure but promising library libbulldog which allows you to abstract from the platform on which everything is running. Currently supported (theoretically) Raspberry Pi, BeagleBoard, Cubieboard, but it was tested only on Cubieboard3 (aka Cubietruck) which I have available.
Also supported (again theoretically) is the popular library for the Raspberry PI Pi4j , but, unfortunately, it was not possible to try it out in practice
The following protocols are currently implemented.
- Oregon V2 (temperature and humidity sensors such as THN132N, THR238NF, THWR800, THGN132N, etc.)
- Oregon V3 (temperature, humidity sensors)
- Oregon SL109 (temperature, humidity sensors)
- Owl (Owl Micro + current consumption sensors)
- PT2262 / PT2272 (Chinese radio relay, the corresponding Arduino library is called RC-switch)
- RemoteSwitch (Chinese radio relay, the name is similar to the well-known Arduino library)
a plus
- several utilities for research and diagnostics of protocols (see below)
- MQTT client for seamless integration with smart home systems (see below)
Plans to add support for as many popular radio protocols as possible (first I would like Noolite and La Cross)
Work with radio protocols is divided into three levels:
- directly signals from the receiver to the GPIO port (signal level)
- signals are transformed into packets. Typically, this is a sequence of bits (packet level)
- packets are analyzed and become messages. Messages already have specific user properties (temperature, command, etc.) (message level)
Each level is independent of its neighbors and can be reused (for example, conversion from signals to packets is often the same for many devices, but the formation of messages from packets is unique)
All protocols can be configured as much as possible using .properties files, since many constants (for example, the duration of pulses) can vary for different devices.
There are two of them at the moment. I will show you how to use both of them to deal with the protocol from radio trinkets with the PT2262 chip (most popular on aliexpress)
- breakdown: used to study the length of the pulses from the receiver. As a rule, when a device does not send data to the air, noise with various pulse lengths arrives at the GPIO port from the receiver, but if you press a button on the transmitter or wait for a signal, it is noticeable that the received pulses fall into certain groups. For example, for the power button, the program will display the following data (pulse duration in microseconds):
The first half of the lines is noise, the second is a button on the key fob
From the utility output, it becomes clear that the pulses fall into the following groups: (400, 600) and (1300, 1600) (if you experiment a little more with the groups, you can find out that there are more pulses from the group (15000, 16000))
Now let us try to understand how the pulses from these groups alternate. For this we need the following utility
- intervals: allows you to give pulse intervals names and see their sequence. Let's call the first group ā0ā, the second ā1ā, and the last, the longest, āSā. And we will only output groups in which at least 20 pulses in a row fall into these intervals:
(Explanation - the numbers in square brackets are the duration of the pulses before and after the sequence. Sometimes it helps to understand why the sequence was interrupted in the middle, the number in parentheses is the number of signals in the sequence)
It can be seen that the sequence between pulses called S is always the same for one button and looks like
0101011001010101011001010110011010100101010101010
If you study the sequences received from different buttons, you can see that these are always groups of characters.
0101
1010
0110
plus always zero at the end (synchronization)
It looks like a ternary number system. Give them the names 0,1 2 and get the sequence
020020221000 for the power button and
020020220100 for the off button
We can assume that the job is done.
The library also includes the MQTT client, which can be launched as a separate application for seamless integration with ready-made smart home systems (planned with openHAB )
Customer:
- automatically sends MQTT messages for all received data. For example, the temperature received from the Oregon device will be published on topic
rf / OregonV2 / Temperature
- listens to rf / send / PROTOCOL topics and sends radio commands with data received from the topic. For example, in order to simulate a command from the keyfob from the previous paragraph, you need to send the command 020020221000 on the topic rf / send / pt2262
Run:
At the moment, all independent applications in the library are launched as regular Java applications with the main () method
Also, all have the -DpropertiesFile parameter for setting the settings file (pins, a library for working with pins, etc.). Examples of .properties files are on github'e ( github.com/eschava/rf-protocols-java/tree/master/examples )
In addition to the applications described earlier, there are also the following:
Display all received messages on the console
Output of all received packets (lower-level data than messages, usually this is a hexadecimal dump of packets)
Sending a message by protocol
It seems to be all
Waiting for reviews, bug reports, feature requests and other scary words
I want to share the JAVA library for working with home automation radio devices (usually 433.92 MHz) that I have been working on recently. It is still raw enough for serious use, but for home crafts it is just right.
Address on github - github.com/eschava/rf-protocols-java
Prerequisites to create
After buying Cubietruck decided to transfer to it all the tasks of the smart home, which were performed on the Arduino. This is mainly the reception and transmission of radio messages to home automation devices (sockets, sensors, heating)
Everything that was found on the network was either done only for the Raspberry Pi, or too sharpened for some specific functionality. Therefore, I decided to implement everything myself, using the familiar development language (Java) and make it as flexible and expandable as possible (the register of factories and all that, as is customary in Java)
')
To work with RF devices via GPIO ports, I chose a rather obscure but promising library libbulldog which allows you to abstract from the platform on which everything is running. Currently supported (theoretically) Raspberry Pi, BeagleBoard, Cubieboard, but it was tested only on Cubieboard3 (aka Cubietruck) which I have available.
Also supported (again theoretically) is the popular library for the Raspberry PI Pi4j , but, unfortunately, it was not possible to try it out in practice
Main ideas
- Platform independence
- Autonomy of all components (for the implementation of any tasks)
- Easy extensibility (support for new devices and platforms)
- Decoded messages support two interfaces: the usual method call (getTemperature ()) and property references by name
- The maximum removal of settings beyond the code for more precise adjustment to the device without changing the code
What is implemented
The following protocols are currently implemented.
- Oregon V2 (temperature and humidity sensors such as THN132N, THR238NF, THWR800, THGN132N, etc.)
- Oregon V3 (temperature, humidity sensors)
- Oregon SL109 (temperature, humidity sensors)
- Owl (Owl Micro + current consumption sensors)
- PT2262 / PT2272 (Chinese radio relay, the corresponding Arduino library is called RC-switch)
- RemoteSwitch (Chinese radio relay, the name is similar to the well-known Arduino library)
a plus
- several utilities for research and diagnostics of protocols (see below)
- MQTT client for seamless integration with smart home systems (see below)
Plans to add support for as many popular radio protocols as possible (first I would like Noolite and La Cross)
Architecture
Work with radio protocols is divided into three levels:
- directly signals from the receiver to the GPIO port (signal level)
- signals are transformed into packets. Typically, this is a sequence of bits (packet level)
- packets are analyzed and become messages. Messages already have specific user properties (temperature, command, etc.) (message level)
Each level is independent of its neighbors and can be reused (for example, conversion from signals to packets is often the same for many devices, but the formation of messages from packets is unique)
All protocols can be configured as much as possible using .properties files, since many constants (for example, the duration of pulses) can vary for different devices.
Protocol Research Utilities
There are two of them at the moment. I will show you how to use both of them to deal with the protocol from radio trinkets with the PT2262 chip (most popular on aliexpress)
- breakdown: used to study the length of the pulses from the receiver. As a rule, when a device does not send data to the air, noise with various pulse lengths arrives at the GPIO port from the receiver, but if you press a button on the transmitter or wait for a signal, it is noticeable that the received pulses fall into certain groups. For example, for the power button, the program will display the following data (pulse duration in microseconds):
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
The first half of the lines is noise, the second is a button on the key fob
From the utility output, it becomes clear that the pulses fall into the following groups: (400, 600) and (1300, 1600) (if you experiment a little more with the groups, you can find out that there are more pulses from the group (15000, 16000))
Now let us try to understand how the pulses from these groups alternate. For this we need the following utility
- intervals: allows you to give pulse intervals names and see their sequence. Let's call the first group ā0ā, the second ā1ā, and the last, the longest, āSā. And we will only output groups in which at least 20 pulses in a row fall into these intervals:
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)
(Explanation - the numbers in square brackets are the duration of the pulses before and after the sequence. Sometimes it helps to understand why the sequence was interrupted in the middle, the number in parentheses is the number of signals in the sequence)
It can be seen that the sequence between pulses called S is always the same for one button and looks like
0101011001010101011001010110011010100101010101010
If you study the sequences received from different buttons, you can see that these are always groups of characters.
0101
1010
0110
plus always zero at the end (synchronization)
It looks like a ternary number system. Give them the names 0,1 2 and get the sequence
020020221000 for the power button and
020020220100 for the off button
We can assume that the job is done.
MQTT client
The library also includes the MQTT client, which can be launched as a separate application for seamless integration with ready-made smart home systems (planned with openHAB )
Customer:
- automatically sends MQTT messages for all received data. For example, the temperature received from the Oregon device will be published on topic
rf / OregonV2 / Temperature
- listens to rf / send / PROTOCOL topics and sends radio commands with data received from the topic. For example, in order to simulate a command from the keyfob from the previous paragraph, you need to send the command 020020221000 on the topic rf / send / pt2262
Run:
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
How to run stand-alone applications in the library
At the moment, all independent applications in the library are launched as regular Java applications with the main () method
Also, all have the -DpropertiesFile parameter for setting the settings file (pins, a library for working with pins, etc.). Examples of .properties files are on github'e ( github.com/eschava/rf-protocols-java/tree/master/examples )
In addition to the applications described earlier, there are also the following:
Display all received messages on the console
sudo java -cp bulldog.cubieboard.jar:rf-protocols-0.1-SNAPSHOT.jar -DpropertiesFile=protocols.properties rf.protocols.analysis.PrintAllMessagesOutput of all received packets (lower-level data than messages, usually this is a hexadecimal dump of packets)
sudo java -cp bulldog.cubieboard.jar:rf-protocols-0.1-SNAPSHOT.jar -DpropertiesFile=protocols.properties rf.protocols.analysis.PrintAllPacketsSending a message by protocol
sudo java -cp bulldog.cubieboard.jar:rf-protocols-0.1-SNAPSHOT.jar -DpropertiesFile=sendmessage.properties -Dprotocol=RemoteSwitch -Dmessage=111110222220 rf.protocols.analysis.SendStringMessage
It seems to be all
Waiting for reviews, bug reports, feature requests and other scary words
Source: https://habr.com/ru/post/235957/
All Articles