September 8, 2014 at 02:31Another library for working 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 lately. It is still raw enough for serious use, but for home crafts - just the right
address on github - github.com/eschava/rf-protocols-java
After the purchase, Cubietruck decided to transfer to it all the tasks of a smart home that were carried out on Arduino. Basically, it is 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 extensible as possible (factory registry and all that is customary in Java).
For working with RF devices via GPIO ports, I chose the rather little-known but promising library libbulldogwhich 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.
The popular library for Raspberry PI Pi4j is also supported (again theoretically) , but, unfortunately, it was not possible to try it out in practice
Currently, the following protocols
are implemented - Oregon V2 (temperature, 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 relays, the corresponding arduino library is called RC-switch)
- RemoteSwitch (Chinese radio relays, the name is similar to the well-known arduino library)
plus
- several utilities for studying and diagnosing protocols (see further )
- MQTT client for seamless integration with systems and smart home (see below)
The plans are to add support for as many popular radio protocols as possible (first of all, I would like Noolite and La Cross)
Work with radio protocols is divided into three levels:
- directly signals coming 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 the neighboring ones and can be reused (for example, the conversion from signals to packets is often the same for many devices, but the formation of messages from packets is already unique)
All protocols can be maximally configured using .properties files, since many constants (for example, pulse durations) can vary for different devices
There are two at the moment. I will show how, using both of them, to understand the protocol from radio remote controls with a PT2262 chip (the most popular on aliexpress)
- breakdown: it is used to study the length of pulses received from the receiver. As a rule, when the device does not send data to the air, the receiver receives noise with a various pulse lengths on the GPIO port, 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 in duration. For example, for a power button, the program will output such data (pulse duration in microseconds):
The first half of the lines is noise, the second is the button on the key fob is pressed
From the output of the utility it becomes clear that the pulses fall into the following groups: (400, 600) and (1300, 1600) (if you still experiment a little with groups, you can find out what is more pulses from the group (15000, 16000))
Now let's try to understand how the pulses from these groups alternate. To do this, we need the following utility
- intervals: allows you to give the intervals of pulses names and see their sequence. Let's name the first group “0”, the second “1”, and the last, 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 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
0101011001010101010110010101100110101001010101010101010
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 (sync onization)
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 shutdown button
We can assume that the job is done.
The library also includes an MQTT client, which can be launched as a separate application for seamless integration with ready-made smart home systems (planned with openHAB )
Client:
- automatically sends MQTT messages for all received data. For example, the temperature received from the Oregon device will be published on the topic
rf / OregonV2 / Temperature
- listens to the rf / send / PROTOCOL topics and sends radio commands with data received on the topic. For example, to simulate a command from the key fob from the previous paragraph, you need to send the command 020020221000 to the topic rf / send / pt2262
Start:
At the moment, all the stand-alone applications included in the library are launched as regular Java applications with the main () method.
Also, everyone has a -DpropertiesFile parameter to specify the settings file (pins, a library for working with pins, etc.). Examples of .properties files are on github ( github.com/eschava/rf-protocols-java/tree/master/examples )
In addition to the applications described earlier, there are the following:
Output of all received messages to the console
Output of all received packages (more low-level data than messages, as a rule it is a hexadecimal dump of packets)
Sending a message by protocol It seems to be all I am 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 lately. It is still raw enough for serious use, but for home crafts - just the right
address on github - github.com/eschava/rf-protocols-java
Prerequisites for the creation
After the purchase, Cubietruck decided to transfer to it all the tasks of a smart home that were carried out on Arduino. Basically, it is 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 extensible as possible (factory registry and all that is customary in Java).
For working with RF devices via GPIO ports, I chose the rather little-known but promising library libbulldogwhich 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.
The popular library for Raspberry PI Pi4j is also supported (again theoretically) , 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: a regular method call (getTemperature ()) and a call to properties by name
- Maximum removal of settings outside the code for more accurate adjustment to devices without changing the code
What is implemented
Currently, the following protocols
are implemented - Oregon V2 (temperature, 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 relays, the corresponding arduino library is called RC-switch)
- RemoteSwitch (Chinese radio relays, the name is similar to the well-known arduino library)
plus
- several utilities for studying and diagnosing protocols (see further )
- MQTT client for seamless integration with systems and smart home (see below)
The plans are to add support for as many popular radio protocols as possible (first of all, I would like Noolite and La Cross)
Architecture
Work with radio protocols is divided into three levels:
- directly signals coming 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 the neighboring ones and can be reused (for example, the conversion from signals to packets is often the same for many devices, but the formation of messages from packets is already unique)
All protocols can be maximally configured using .properties files, since many constants (for example, pulse durations) can vary for different devices
Protocol Research Utilities
There are two at the moment. I will show how, using both of them, to understand the protocol from radio remote controls with a PT2262 chip (the most popular on aliexpress)
- breakdown: it is used to study the length of pulses received from the receiver. As a rule, when the device does not send data to the air, the receiver receives noise with a various pulse lengths on the GPIO port, 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 in duration. For example, for a power button, the program will output such 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 the button on the key fob is pressed
From the output of the utility it becomes clear that the pulses fall into the following groups: (400, 600) and (1300, 1600) (if you still experiment a little with groups, you can find out what is more pulses from the group (15000, 16000))
Now let's try to understand how the pulses from these groups alternate. To do this, we need the following utility
- intervals: allows you to give the intervals of pulses names and see their sequence. Let's name the first group “0”, the second “1”, and the last, 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] 01011001010101011001010110011010100101010101010S0101011001010101011001010110011010101101010101010S01010110010101010110010101100010101010101010101001010101100010101010101010101010101010101010 [770] 100101011001101010010101010 [1281] (27) [3418] S0101011001010101011001010110011010100101010101010S0101011001010101011001010110011010100101010101010S0101011001010101011001010110001010101010101010010101011001010101011011011011011011011011011011011011011011011011011011011 To1011011011011011011011011011011011011011011011011011011011011011011011011011011011011011011 181011011
(Explanation - the numbers in square brackets are the duration of 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
0101011001010101010110010101100110101001010101010101010
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 (sync onization)
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 shutdown button
We can assume that the job is done.
MQTT client
The library also includes an MQTT client, which can be launched as a separate application for seamless integration with ready-made smart home systems (planned with openHAB )
Client:
- automatically sends MQTT messages for all received data. For example, the temperature received from the Oregon device will be published on the topic
rf / OregonV2 / Temperature
- listens to the rf / send / PROTOCOL topics and sends radio commands with data received on the topic. For example, to simulate a command from the key fob from the previous paragraph, you need to send the command 020020221000 to the topic rf / send / pt2262
Start:
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 included in the library
At the moment, all the stand-alone applications included in the library are launched as regular Java applications with the main () method.
Also, everyone has a -DpropertiesFile parameter to specify the settings file (pins, a library for working with pins, etc.). Examples of .properties files are on github ( github.com/eschava/rf-protocols-java/tree/master/examples )
In addition to the applications described earlier, there are the following:
Output of all received messages to the console
sudo java -cp bulldog.cubieboard.jar:rf-protocols-0.1-SNAPSHOT.jar -DpropertiesFile=protocols.properties rf.protocols.analysis.PrintAllMessagesOutput of all received packages (more low-level data than messages, as a rule it 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 It seems to be all I am waiting for reviews, bug reports, feature requests and other scary words
sudo java -cp bulldog.cubieboard.jar:rf-protocols-0.1-SNAPSHOT.jar -DpropertiesFile=sendmessage.properties -Dprotocol=RemoteSwitch -Dmessage=111110222220 rf.protocols.analysis.SendStringMessage