[Solved] Protocol for Xiron weather station

---

I’m pretty new with Pimatic and all. Recently configured my 433Mhz receiver and transmitter via an Arduino Nano and homeduino plugin. Kaku switches are working fine with that.
Next project is trying to receive the info from my Xiron weather station.
The homeduino debug log shows some received data, from which I’m sure that it comes from the station (switched it off and on). I also played with changing the channel and setting from C to F om the station.
Below is the log where I also noted the channel, temperature and humidity at that moment. The station also reports battery status btw.
How can I make this to work in pimatic / homeduino?

channel 1: 28,2C 54%
debug [pimatic-homeduino]: received: [ 556, 1048, 1972, 3888 ] 020202010202010102010101010101020101010202010201020202020101020201020201010101010103
16:40:41

channel 1: 28,3C 53%
debug [pimatic-homeduino]: received: [ 544, 1056, 1984, 3880 ] 020202010202010102010101010101020101010202010201020202020101020201020202010101010103
16:41:35

channel 1: 28,4C 53%
debug [pimatic-homeduino]: received: [ 556, 1048, 1976, 3904 ] 020202010202010102010101010101020101010202010202020202020101020201020102010101010103
16:42:32

channel 1: 28,5C 53%
debug [pimatic-homeduino]: received: [ 556, 1048, 1976, 3904 ] 020202010202010102010101010101020101010202020102020202020101020201020102010101010103
16:43:29

channel 1: 28,6C 52%
debug [pimatic-homeduino]: received: [ 552, 1052, 1976, 3888 ] 020202010202010102010101010101020101010202020201020202020101020201020101010101010103
16:45:23

channel 2: 28,6C 52%
debug [pimatic-homeduino]: received: [ 552, 1052, 1976, 3888 ] 020202010202010102010101010101020101010202020201020202020101020201020101010101010103
16:45:23

channel 1: 83,4F 52%
debug [pimatic-homeduino]: received: [ 548, 1052, 1980, 3884 ] 020202010202010102010101010101020101010202020201020202020101020201020101010101010103
16:49:39

@cees Unfortunately the last three reading samples are identical, thus, they do not match with the sensor values and channel settings. Could you please create more samples for different channel settings?

I will try to do that this evening. Already thanks.

OK. Here are my preliminary findings, however, more samples are required to understand the encoding of the channel to provide proper support for it as part of homeduino.

      020202010202010102010101010101020101010202010201020202020101020201020201010101010103
      Transform
      01 -> 0
      02 -> 1

      1110 1100 1000 0001 0001 1010 1111 0011 0110 0000 003
      ???? ???? ???? TTTT TTTT TTTT ???? HHHH HHHH ????

      T: Temperature Value (divide decimal by 10) = 28,2
      H: Humidity = 54

EDIT: Please also let me know the model of the weather station

Here is some more logging with switching the sensor channel from 1 to 2 and 3.
I also tried to take some negative temperature, by putting the sensor in the fridge. These values might not be very accurate because of temperature rising fast when I took it out of the fridge.
The model is Xiron Made in China (no type name):
https://www.google.nl/search?q=xiron+weather+station&source=lnms&tbm=isch&sa=X&ved=0CAgQ_AUoAmoVChMIlL299b6mxwIVSkkaCh2MswFV#imgrc=XE-P9PayyhruEM%3A

Here is the logging
debug [pimatic-homeduino]: received: [ 548, 1056, 1984, 3896 ] 020202010202010102010101010101020101020202020102020202020101020201010101010101010103
16:37:29debug [pimatic-homeduino]: data: "RF receive 548 1984 1056 3896 0 0 0 0 010101020101020201020202020202010202010101010201010101010202010102020202020202020203"
channel 1 31.7C 48%

debug [pimatic-homeduino]: received: [ 552, 1056, 1980, 3892 ] 020202010202010102010101010101020101020202020201020202020101020102020202010101010103
16:38:26debug [pimatic-homeduino]: data: "RF receive 552 1980 1056 3892 0 0 0 0 010101020101020201020202020202010202010101010102010101010202010201010101020202020203"
channel 1 31.8C 48%

debug [pimatic-homeduino]: received: [ 560, 1048, 1972, 3912 ] 020202010202010102010102010101020101020202020202020202020101020201010101010101010103
16:40:28debug [pimatic-homeduino]: data: "RF receive 560 1972 1048 3912 0 0 0 0 010101020101020201020201020202010202010101010101010101010202010102020202020202020203"
channel 2 32.0C 47%

debug [pimatic-homeduino]: received: [ 560, 1048, 1976, 3872 ] 020202010202010102010102010101020102010101010102020202020101020102020202010101010103
16:41:35debug [pimatic-homeduino]: data: "RF receive 560 1976 1048 3872 0 0 0 0 010101020101020201020201020202010201020202020201010101010202010201010101020202020203"
channel 2 32.1C 47%

debug [pimatic-homeduino]: received: [ 560, 1048, 1976, 3896 ] 020202010202010102010201010101020102010101010201020202020101020102020202010101010103
16:43:29debug [pimatic-homeduino]: data: "RF receive 560 1976 1048 3896 0 0 0 0 010101020101020201020102020202010201020202020102010101010202010201010101020202020203"
channel 3 32.2C 47%

debug [pimatic-homeduino]: received: [ 552, 1060, 1984, 3884 ] 020202010202010102010201010101020102010101020101020202020101020102020202010101010103
16:46:07debug [pimatic-homeduino]: data: "RF receive 552 1984 1060 3884 0 0 0 0 010101020101020201020102020202010201020202010202010101010202010201010101020202020203"
channel 3 32.4C 46%

debug [pimatic-homeduino]: received: [ 552, 1060, 1984, 3884 ] 020202010202010102010201010101020102010101020101020202020101020102020202010101010103
16:46:07debug [pimatic-homeduino]: data: "RF receive 552 1984 1060 3884 0 0 0 0 010101020101020201020102020202010201020202010202010101010202010201010101020202020203"
channel 1 -22.8C 49%

debug [pimatic-homeduino]: received: [ 516, 1024, 1952, 3856 ] 020202010202010102010101020202020101020202020201020202020101020201010202010101010103
18:12:09debug [pimatic-homeduino]: data: "RF receive 516 1952 1024 3856 0 0 0 0 010101020101020201020202010101010202010101010102010101010202010102020101020202020203"
channel 1 -19.4C 51%

debug [pimatic-homeduino]: received: [ 524, 1024, 1948, 3856 ] 020202010202010102010101020202020201010101020102020202020101020201020202010101010103
18:14:03debug [pimatic-homeduino]: data: "RF receive 524 1948 1024 3856 0 0 0 0 010101020101020201020202010101010102020202010201010101010202010102010101020202020203"
channel 1 -12.3C 53%

Thanks. I have managed to identify the channel id as part of the bit stream

• Is it possible for you to make a low battery test (maybe by replacing one of the batteries with a used one)?

1110 1100 1000 0001 0001 1010 1111 0011 0110 0000 003
1110 1100 1001 0001 0100 0001 1111 0010 1111 0000 003
1110 1100 1010 0001 0100 0010 1111 0010 1111 0000 003
???? ???? ??CC TTTT TTTT TTTT ???? HHHH HHHH ????
0    4    8    12   16   20   24   28   32   36
T: Temperature Value (divide decimal by 10)
H: Humidity
C: Channel (2 bits + 1, 00=1, 01=2, 10=3)

With almost empty batteries:
debug [pimatic-homeduino]: received: [ 576, 1052, 1976, 3892 ] 020201010102020201010101010101020101020102010101020202020101020202020101010101010103
19:57:39debug [pimatic-homeduino]: data: “RF receive 576 1976 1052 3892 0 0 0 0 010102020201010102020202020202010202010201020202010101010202010101010202020202020203”

channel 1 +/- 29.9C and 57% and low battery:
debug [pimatic-homeduino]: received: [ 560, 1068, 1992, 3904 ] 020201010102020201010101010101020101020102010201020202020101020202010102010101010103
20:04:18debug [pimatic-homeduino]: data: “RF receive 560 1992 1068 3904 0 0 0 0 010102020201010102020202020202010202010201020102010101010202010101020201020202020203”

So we already had this:
1110 1100 1000 0001 0001 1010 1111 0011 0110 0000 003
1110 1100 1001 0001 0100 0001 1111 0010 1111 0000 003
1110 1100 1010 0001 0100 0010 1111 0010 1111 0000 003
???? ???? ??CC TTTT TTTT TTTT ???? HHHH HHHH ????

And your latest sample decodes to this:
1100 0111 0000 0001 0010 1000 1111 0011 1100 0000 003

There are changes in the first 9 bits… is it possible that all 8 of them realte to the battery level?

@Sebastian-Rösch That I don’t know. That is also why I started this topic
I find it also strange that the two debug lines have different starting bits:
0202010101…
0101020202…
You look for the one starting with 0202. But what is the other doing?
Anyway, I wonder how and if you’ll can make a protocol out of this. I hope you can…

@Sebastian-Rösch I think the first 8 bits are the device id. As @cees replaced the batteries to test the low battery scenario, the device started in learning mode which supposedly results in a new device id.

@cees may be you can make replace the batteries once again and create a few more samples. If the first 8 bits are different from the values of the previous samples it is the ID for sure. Following this I am happy to contribute a draft implementation of the protocol for testing.

020202010202010102010101010101020101010202010201020202020101020201020201010101010103
01 -> 0
02 -> 1
1110 1100 1001 0001 0100 0001 1111 0010 1111 0000 003
1110 1100 1010 0001 0100 0010 1111 0010 1111 0000 003
1110 1100 1000 0001 0001 1101 1111 0011 0101 0000 003
1110 1100 1000 0001 0001 1010 1111 0011 0110 0000 003
1110 1100 1000 1111 0011 1110 1111 0011 0011 0000 003
1100 0111 0000 0001 0010 1000 1111 0011 1100 0000 003
1100 0111 0000 0001 0010 1010 1111 0011 1001 0000 003
IIII IIII BxCC TTTT TTTT TTTT xxxx HHHH HHHH xxxx
0    4    8    12   16   20   24   28   32   36
I: Device ID, 8-bit unsigned Int
B: Low-Battery Flag (1-bit, 0=Battery OK, 1=Battery Low)
T: Temperature Value, 12-bit signed Int (divide decimal by 10)
H: Humidity, 8-bit unsigned Int
C: Channel (2 bits + 1, 00=1, 01=2, 10=3)
x: Unused

Already thanks guess.
I have removed the batteries several times and it seems you’re right about the Id:
debug [pimatic-homeduino]: received: [ 564, 1032, 1956, 3872 ] 020101020101020202010101010101010202020101020201020202020102010201020101010101010103
10:22:37debug [pimatic-homeduino]: data: "RF receive 564 1956 1032 3872 0 0 0 0 010202010202010101020202020202020101010202010102010101010201020102010202020202020203"
debug [pimatic-homeduino]: received: [ 564, 1028, 1956, 3872 ] 020101020101020202010101010101010202020102010201020202020102010201020101010101010103
10:23:34debug [pimatic-homeduino]: data: “RF receive 564 1956 1028 3872 0 0 0 0 010202010202010101020202020202020101010201020102010101010201020102010202020202020203”

Removed and inserted batteries:
debug [pimatic-homeduino]: received: [ 564, 1032, 1952, 3876 ] 010201020101020102010101010101010202020201010102020202020102010201020101010101010103
10:24:52debug [pimatic-homeduino]: data: "RF receive 564 1032 1952 3876 0 0 0 0 010201020101020102010101010101010202020201010102020202020102010201020101010101010103"
debug [pimatic-homeduino]: received: [ 560, 1036, 1960, 3864 ] 010201020101020102010101010101010202020201010201020202020102010201020101010101010103
10:25:46debug [pimatic-homeduino]: data: “RF receive 560 1036 1960 3864 0 0 0 0 010201020101020102010101010101010202020201010201020202020102010201020101010101010103”

Removed and inserted batteries:
debug [pimatic-homeduino]: received: [ 556, 1040, 1964, 3876 ] 020201020201010102010101010101010202020201020202020202020102010201020101010101010103
10:26:25debug [pimatic-homeduino]: data: "RF receive 556 1964 1040 3876 0 0 0 0 010102010102020201020202020202020101010102010101010101010201020102010202020202020203"
debug [pimatic-homeduino]: received: [ 568, 1032, 1960, 3864 ] 020201020201010102010101010101010202020202010202020202020102010201010202010101010103
10:29:12debug [pimatic-homeduino]: data: “RF receive 568 1960 1032 3864 0 0 0 0 010102010102020201020202020202020101010101020101010101010201020102020101020202020203”

What about the negative temperatures, is that the inverse bits e.g. 1101 being 0010 ?

@Sebastian-Rösch Thanks for upvoting my post

@cees Thanks for providing the additional samples. These show exactly the id changes each time after the battery has been replaced. The information we have is enough to implementing the protocol and I’ll provide a draft later today. Regarding unused bits these may be used by variants of the protocol, e.g. other Xiron sensors or OEM products. The protocol implementations we have for some Auriol & Vellemann devices appear to be close relatives (weather7 and weather10, pulse counts differ, however). Btw., one more question:

• Does the log also contains protocol candidates (see example below)?

debug [pimatic-homeduino]: weather5: { id: 58, lowBattery: true, avgAirspeed: 39.2 }
12:33:01
debug [pimatic-homeduino]: weather1: { id: 207, channel: 1, temperature: 25.8, humidity: 51, lowBattery: false }
12:33:01
debug [pimatic-homeduino]: received: [ 536, 1908, 3856, 9184 ] 01020102020201010202020202010101010101020101010101010201010102020101020203
12:33:01
debug [pimatic-homeduino]: data: "RF receive 536 1908 3856 9184 0 0 0 0 01020102020201010202020202010101010101020101010101010201010102020101020203"

No I don’t see any other weather protocol candidates.

@cees OK, here is a first implementation of the new protocol (weather11). You can install it by executing the steps below (assuming pimatic is installed on raspberry pi).
If the git command is not available on your system, you need to install it first (sudo apt-get install git). After the installation you should see ‘weather11’ candidates in your log file.
Once the protocol has bee proven to work I’ll create a pull request to get included as part of the pimatic-homeduino release.

sudo service pimatic stop
cd ~/pimatic-app/node_modules/pimatic-homeduino/node_modules/homeduino/node_modules
sudo mv ./rfcontroljs ./rfcontroljs.bak
sudo git clone https://github.com/mwittig/rfcontroljs.git
cd rfcontroljs
sudo npm install
sudo service pimatic start

@mwittig Great it works! Thanks .
Still two questions: the sudo npm install took very long. I wonder what is installed by that.
What if this is implemented in the next update of the homeduino plugin.
Do I have to uninstall this test version or…?

And the lowBattery status, that is not supported.
My idea was to use that value to trigger a mail going out.

Anyway, many thanks again

@cees Great to hear that it generally works! The battery status should also work, I’ll look into this asap.

Re your questions:

• Yes, npm install takes a long time as nodejs dependencies can be like hell. I guess this is due to all the gulp packages which are required for development. As far as I know these are not contained in the production build (installation via npmjs).
• Once, an update for homeduino becomes available it should override the rfcontroljs without problems. However, you can also roll-back by moving ./rfcontroljs.bak to ./rfcontroljs (you may need to remove ./rfcontroljs first)

EDIT: Just double-checked: lowBattery should work.Does the battery icon show up? What is the battery status displayed in case?

@mwittig I assume I have to configure it as following:

    {
      "id": "weerstation",
      "name": "Weer Data",
      "class": "HomeduinoRFWeatherStation",
      "protocols": [
        {
          "name": "weather11",
          "options": {
            "id": 216,
            "channel": 1,
            "lowBattery": false
          }
        }
      ],
      "values": [
        "temperature",
        "humidity"
      ]
    },

I don’t see any lowBattery icon or status. Only in the log.
Adding lowBattery in the values part will give an error message.
I’m I doing something wrong?

@cees You don’t need to set lowBattery as this is an status attribute. I don’t think you have to define the values property either. The following should do:

{
      "id": "weerstation",
      "name": "Weer Data",
      "class": "HomeduinoRFTemperature",
      "protocols": [
        {
          "name": "weather11",
          "options": {
            "id": 216,
            "channel": 1
          }
        }
      ]
    },

@mwittig Done that, but still no icon or what so ever. Also creating a rule does not give any lowBattery possibility. But this is not a big thing. I’m already happy with temperature and humidity