When using the Arduino as a gateway for 433MHz messages, the Raspberry will lose a lot of cpu/interrupt intensive workload which is taken over by the Arduino. The Raspberry will then send simple and short messages to the arduino over USB, for example to switch on the lights and the Arduino will message the Raspberry upon receiving sensor values or handset commands from 433 MHz devices.
For more information about Raspberry and Arduino Gateway, visit the dedicated page on the Hardware Guide.
For more information on the physical 433 MHz messaging protocols recognized by the Arduino receiver, visit the 433messaging page.
Initially, we will focus on the klikaanklikuit commands as those are the devices I do have in my home. We like to include some other protocols as well, so that the direct connected devices to the Raspberry and those supported by the Arduino gateway become the same.
This will mean in short that we like to include support for weather sensors etc.
Of course we have to keep in mind that the Arduino receiver which is interrupt based, will spend more time in recognizing incoming pulses if we include a great deal of protocols in the Arduino. Therefore it is wise that the Arduino will only selectively receive messages and non important message format of devices not used will be excluded from its parser.
Keep in mind that we keep the message layout VERY SIMPLE, initially we supported a set which was more verbose, however this would mean a lot more work on the Arduino side to understand the messages, interpret and send responses. The current message format is so simple that almost every command and parameter will fit in a char, except group codes etc. which will be integer in length.
* Message formats not supported but planned are put in the table with a *
Command |
Send |
Notes |
|
|---|---|---|---|
| Admin commands | > {cnt} 0 {cmd} {Args} {Args} | A series of commands | |
| List active codecs | > {cnt} 0 0 {list of codecs for devices/sensors} | First byte is admin mode; Second byte is code select command; rest of list is codecs (integers) to support when receiving. Result is binary string, 0 is off, 1 is on |
|
| Set Codec enable | > {cnt} 0 1 {codec} {value} | Same as above, but set a value on (=1) or off (=0) | |
| Set statistics | * | > {cnt} 0 2 {value} | Ask for statistics, expect a comment back!! Values 0=off and 1 is on |
| Set debug level | > {cnt} 0 3 {value} | Values 0 and 1 are supported (2 and 3 optional) | |
| Get software version | > {cnt} 0 4 | Response is given as a comment and message | |
| Set time | * | > {cnt} 0 5 {yy} {mm} {dd} {hh} {mm} {ss} | Set the new date and time (MEGA only) |
| Get Time | * | > {cnt} 0 6 | Get the currnt Arduino time (MEGA) |
| Transmit Commands | |||
| Send to transmitter | > {cnt} 1 {codec} {addr} {unit} {value} | First byte is "send" mode; second byte codec. Codec: 0 for Kaku, 1 for Action (see database.cfg for brands). > 100 1 0 100 1 10 ; Sets device with address/group 100, unit 1 to 10 |
|
| Send to Device | * | > {cnt} 2 {codec} {Message to Sensor} | Not used (yet) |
| * | > {cnt} 2 {codec} {addr} {unit} {message} | Send to PIR Activate and timeout | |
| Send to Sensor | > {cnt} 3 {codec} {addr} {unit} {message} | ||
The first "word" is the message counter that should be in every message. The second gives the command for the Arduino, The next byte is a subcommand e.g. all admin commands or all transmitter commands etc. The rest of the string are bytes to support these subcommands. All words are separated by the space character " ", although in most cases comma "," will work as well.
Messages generated and sent by the arduino are short and simple and are either a reply (for command above) to a Raspberry request or are coming from 433MHz messages received over its antenna.
| Command | Receive | Notes | |
|---|---|---|---|
| All other comments or messages coming from Arduino | ! {Message} | Everything after the ! is just comment and not interpreted. The ! could be first character on a line, or follow an existing reponse. | |
| Reply to an admin message (0) | Only applies to the Arduino connected to the Raspi Gateway | ||
| * | < {cnt} 0 0 {list of devices codecs} | ||
| < {cnt} 0 1 {codec} {value of codec} | value must be 0 or 1 | ||
| < {cnt} 0 2 {List of statistics} | NOTE: exceptional, expect a ! list of comments back | ||
| < {cnt} 0 3 {debug reply} | Debug mode is toggled | ||
| < {cnt} 0 4 {Version} | Response to request for the version number | ||
| * | < {cnt} 0 5 {Time} | Give RTC time of Arduino | |
| * | < {cnt} 0 6 {Time} | Read RTC of Arduino | |
| Reply to device cmd of Raspi (1) | < {cnt} 1 {codec} {addr} {unit} {value} | This is a reply on a Raspberry message (optional: hardly used). |
|
| < {cnt} | |||
| Receive device message (2) | < {cnt} 2 {codec} {addr} {unit} {value} | Value is "off", "on" and 0-15 as a dim value | |
|
< {cnt} 2 0 100 1 0 | kaku switch with group 100 and unit 1 is set to off | |
|
< {cnt} 2 1 {addr} {unit} {val} < {cnt} 2 1 31 2 1 |
action switch housecode 31, unit 2 is set on. The address is between 0 and 31, device is between 0 and 4 (5 bits, bit coded 1 when device active) |
|
|
< {cnt} 2 5 {addr} {unit} {val} < {cnt} 2 5 23783 8 1 |
Level not used but for compatibility with other codecs is always 1 | |
|
< {cnt} 2 7 {addr} {unit} {val} < {cnt} 2 7 93756057 85 1 |
pressed | |
| Receive 433 Sensor message (3) | < {cnt} 3 {codec} {address} {channel} {parameter1} {parameter2} | wt440h (UPM/Esic) is one codec 1 but there are more | |
|
< {cnt} 3 0 {sensor addr} {unit} {temp} {humi} < {cnt} 3 0 40 0 26.5 50.1 |
Arduino on-board I2C sensor message. The code 40 tells us it is a HTU21 SHT21 device on the I2C bus. All on-board sensors have code 0 | |
|
< {cnt} 3 1 {address} {unit} {temp} {humi} < {cnt} 3 1 1 0 8984 85 |
Receive UPM weather message temperature (20.1 Celcius encoded) and humi (85%) for address 1 and channel unit 0. This is the only message type supported by the real WT440h device. This message format is also used for HTU21D sensors reporting. |
|
|
< {cnt} 3 2 {address} {unit} {temp} {airpressure} < {cnt} 3 2 1 0 8984 85 |
Almost same message as above, but instead of humidity show airpressure value as 85 + 930 = 1015 Hpa. I use the WT440 protocol with some extra modifications to transmit values of my own (BMP085) sensors. |
|
|
< {cnt} 3 3 {address} {unit} {batt%} {nu} < {cnt} 3 3 1 0 885 0 |
Battery percentage is 88.5%. Used for betterySensor devices. | |
|
< {cnt} 3 4 {addr} {unit} {val} {nu} < {cnt} 3 4 9 1 1 0 |
PIR alarm on device 9 channel 1. | |
| * | < {cnt} 3 5 | (reserved) | |
|
< {cnt} 3 8 {addr} {temp} {humi} < 111 3 8 138 0 237 0 ! Auriol Cs: 0, N1: 1000, N2: 100 |
Receive Auriol weather for device id 138, message temp is 23.7 Celcius encoded and humi 0% (not supported). Optionally when debug is active (!), it will provide the N1 and N2 parameters (N1 1000 tells us the battery is still OK). When Statistics is compiled, it will show timing info after the "!" as well. |
|
|
* | < {cnt} 3 10 {addr} {unit} {parameter} {value} | (reserved) |
As you can see, the message coming in from the Arduino of a device is the same as the message that is sent by the Raspberry to get the Arduino to send a command to a KlikAanKlikAuit device.
1. We will need some sort of admin mesages to be received from the Arduino as well. For Gateways we coul use the standard admin (=0) commands initiated from the Raspberry, but for Arduino Sensor or other devices i might be better if once in a while the Arduino would check itself and send warnings is certain critical conditions occur or will occur in the future.
Examples are:
2. Also it would be good if we can actively set parameters in Arduino devices that do have a receiver connected and use it to change the internal state of some variables and parameters. Examples:
3. Finally, as the wireless protocols WT440h and Auriol are fairly limited and do not support other sensors than temperature and humidity, we need a homegrown protocol that enables us to define messages (like the ones we send over USB) and send them over the air.
The codec is different for different type of commands. So the codec for handsets and sensors is different.
Please keep in mind that for the current version not all protocols are supported. Legend: < means receive, > means transmit is supported. (*) Means being worked on and reserve the code
Some sensors may have their own manufacturer protocol and their own transmitter. But there may also be ones that are connected to an Arduino who will forward the sensor message to the LamPI-node daemon.
Not supprted and tested yet