Prologue 433.92Mhz Temperature sensor

---

Hi!

I have another RF temperature sensor to add. If you have some pointers, I might me able to fix up something myself, but here it is:

debug [pimatic-homeduino]: data: "RF receive 468 3920 1972 8780 0 0 0 0 0102020102010202010101020202020202020202010101020102020201010202010102020203"

The sensor Only transmits the temperature, as far as I know. The Value on above is 23.2 Celsius.

@kitsunen

Product is this:
http://www.clasohlson.com/uk/Extra-Thermometer-Sensor/36-4744

@kitsunen said:

I might me able to fix up something myself, but here it is

You can simply try to decode it yourself:

• Copy the sequence into a text editor
• Replace all 01 with 0.
• Replace all 02 with 1
• Add a spece every 4 or 8 bits
• Take portions of the bit sequence and convert them with calculator (Windows Calculator is doing a fair job here if you switch it to programmer mode and set it to binary)

The value to watch out for typically is the temperature multiplied by 10, e.g. 232 in your case. The closes value I could find is 230 at offset 24 (10 bits). You should capture some more sample a t different temperatures.

Temp: 26.8c /
472 3916 1968 8784 0 0 0 0 0102020102010202010101020202020202020201020202020101020201010202010102020203

Binary: 011010110001111111101111001100110011 10
-------------------------------------------------------------------------------------------------------
Temp: 25.0c	/
476 3912 1964 8780 0 0 0 0 0102020102010202010101020202020202020202010101010102010201010202010102020203

Binary: 011010110001111111110000010100110011 10
-------------------------------------------------------------------------------------------------------
Temp: 23.3c / 73.9F
480 3912 1964 8784 0 0 0 0 010202010201020201010102020202020202020201010102010202010101020201010202020 3

Binary: 011010110001111111110001011000110011 10
-------------------------------------------------------------------------------------------------------
Temp: 21.7
476 3912 1964 8776 0 0 0 0 010202010201020201010102020202020202020201010201010202010101020201010202020 3

Binary: 011010110001111111110010011000110011 10
-------------------------------------------------------------------------------------------------------
Temp: 20.3c / 68.5F
476 3912 1964 8788 0 0 0 0 010202010201020201010102020202020202020201010202010201010101020201010202020 3

Binary: 011010110001111111110011010000110011 10
-------------------------------------------------------------------------------------------------------
Temp: 19.1c / 66.4F
476 3912 1964 8776 0 0 0 0 01020201020102020101010202020202020202020102010101010101010102020101020200 3

Binary: 011010110001111111110100000000110011 10
-------------------------------------------------------------------------------------------------------
Temp: 9.0c / 48.2F Uncertain!

472 3916 1972 8780 0 0 0 0 0102020102010202010101020202020202020202020102010102010201010202010102020203
Binary: 011010110001111111111010010100110011 10
-------------------------------------------------------------------------------------------------------
Temp: 8.9c / 48.0F

476 3912 1968 8784 0 0 0 0 0102020102010202010101020202020202020202020102010102020101010202010102020203
Binary: 011010110001111111111010011000110011 10

This is new for me… cool seeing these patterns and all, but for the life of me I can’t find the corresponding values from those.

8.9c/48.0F
01101011 00011111< 11111010 0110 >00110011 10 3
19.1c/66.4F
01101011 00011111< 11110100 0000 >00110011 10 3

the parts bolded are always the same.

Now I feel stupid.

Replace all 01 with 0.
Replace all 02 with 1

These were the other way around.
01 = 1
02= 0
Now I’m finding something useful

Temp 25.0c
476 3912 1964 8780 0 0 0 0 0102020102010202010101020202020202020202010101010102010201010202010102020203

Binary: 10010100 11100000 00001111 10101100 1100003
250:     11111010
----------------------------------------------------------------------
Temp 9.0c
472 3916 1972 8780 0 0 0 0 0102020102010202010101020202020202020202020102010102010201010202010102020203

Binary: 10010100 11100000 00000101 10101100 1100003
90:       01011010

@kitsunen Sorry, I should have mentioned that sometimes the transformation is just the other way round.

@mwittig No problem, I’m not on a hurry with this.

What should the next step be?

@kitsunen Is it possible for to measure a negative temperature?
This would be helpful to see if the value is 10-bits or 12-bits.

@mwittig Sure. I’ll put it outside for a minute … Something useful of being Finnish.

@mwittig

476 3916 1968 8808 0 0 0 0 0102020102010202010101020202020201010101010102010102020101010202010102020203

100101001110000011111101100111001100003
-3.9

-3.9 (-39) => 11011001

Also some additional info: You can select from 3 different channels on the device.
Here’s data from using different channels.

Channels
chan1
488 3900 1952 8772 0 0 0 0 0102020102010202010101020201020202020201020202020101010101010202010102020203

chan2
500 3888 1940 8812 0 0 0 0 0102020102010202010101020201020202020201020202020101010101010202010102020203

chan3
460 3928 1980 8792 0 0 0 0 0102020102010202010101020201020202020201020202020101010101010202010102020203

@kitsunen Great. I think this should be enogh information to draft a protocol implementation. However, I’ll not be able to do it with the next two weeks as I’ll be travelling. May be some other @Developer would like to take the initiative?

EDIT: Btw, the sequence for the different channels do not differ.

• Does the temperature sensor have a channel switch, or is the channel switch only provided with the weather station?

@mwittig The transmitter itself (temperature sensor) has a switch to select from 3 channels.
The receiver unit translates the channel automatically, so one would think it came with the sequence… it is odd, I thought that too about the sequence…

heres some more tests:

 [ 480, 1960, 3908, 8792 ] 0201010201020102010101010102020101010102010101010202020202020101020201010103
 [ 476, 1964, 3912, 8788 ] 0201010201020102010101010102020101010102010101010202020202020101020201010103
 [ 472, 1968, 3916, 8804 ] 0201010201020102010101010102020101010102010101010202020202020101020201010103
 [ 492, 1952, 3896, 8788 ] 0201010201020102010101010101020101010102010101010202010202020101020201010103
 Verifies as channel 3 on receiver unit


[ 484, 1956, 3904, 8776 ] 0201010201020102010101010101010201010102010101010202010102020101020201010103
[ 456, 1988, 3932, 8796 ] 0201010201020102010101010102010201010102010101010202010102020101020201010103
[ 480, 1964, 3912, 8780 ] 0201010201020102010101010102010201010102010101010202010102020101020201010103
[ 476, 1964, 3912, 8784 ] 0201010201020102010101010102010201010102010101010202010102020101020201010103
[ 480, 1960, 3908, 8784 ] 0201010201020102010101010101010201010102010101010202010102020101020201010103
Verifies as channel 2 on receiver unit

[ 484, 1956, 3904, 8788 ] 0201010201020102010101010102010101010102010101010201020202020101020201010103
[ 480, 1964, 3912, 8784 ] 0201010201020102010101010102010101010102010101010201020202020101020201010103
[ 480, 1960, 3908, 8784 ] 0201010201020102010101010102010101010102010101010201020202020101020201010103
[ 484, 1960, 3908, 8780 ] 0201010201020102010101010101010101010102010101010201020102020101020201010103
[ 480, 1964, 3912, 8796 ] 0201010201020102010101010102010101010102010101010201020102020101020201010103
Verifies as channel 1 on receiver unit

Is bumping acceptable?

If someone had the time to draft a protocol, I would be more than willing to test it out. This is a rather common temperature sensor in Nordic countries (Sold by Clas Ohlson).

Even without a certain channel info, one certain channel would cover most use cases.

I try to setup my new dev environment on Sunday. When i got it, your protocol is the first one.

@kitsunen @Icesory I already had started an implementation a couple of days ago based on the following code - https://github.com/merbanan/rtl_433/blob/3f066b0c7096c46a9b93b5e26fe4feec8c287aa9/src/rtl_433.c

@Icesory May be you can support @so-what by developing a protocol for a rain gauge sensor. The protocol seems to similar to weather12. See:

• http://forum.pimatic.org/topic/947/rain-gauge-protocol/
• http://forum.pimatic.org/topic/989/gt-wt-01-thermo-humidity-sensor-protocol

Getting back to Prologue sensor, there are also Prologue sensors which measure, both, temperature & humidity. For this reason, I have also included humidity in the protocol implementation following the rtl_433 source code. Most likely it is for the following sensor - http://www.clasohlson.com/uk/Extra-Temperature-Sensor-Hygrometer/36-4441

A draft implementation is now available for testing: https://github.com/mwittig/rfcontroljs
Based on the test data posted on this thread it works pretty well, but there are also some glitches: Sometimes a humidity measurement of 51% is output. We may also need to fine tune pulse parameters.

The code is available at https://github.com/mwittig/rfcontroljs including the new protocol weather14. Please setup the code as follows. If you are familiar with pimatic development, you can alternatively clone my fork into to your pimatic installation.

# make sure you have curl installed, you can install using 'sudo apt-get install curl'
cd /home/pi/pimatic-app/node_modules/pimatic-homeduino/node_modules/homeduino/node_modules/rfcontroljs/lib 
sudo curl https://raw.githubusercontent.com/mwittig/rfcontroljs/master/lib/controller.js -o controller.js
cd protocols
sudo curl https://raw.githubusercontent.com/mwittig/rfcontroljs/master/lib/protocols/weather14.js -o weather14.js
sudo service pimatic restart

@kitsunen Please provide pimatic-homeduino debug output code.

@mwittig

Example result, I’m at work right now so I can’t verify the temperature to the point, but usual temperature is +22.9 to +23.2 at my house, so it looks promising. I don’t know why weather12 gets in there too, but it is related to this protocol, not a rogue device :

debug [pimatic-homeduino]: weather14: { id: 175, channel: 1, temperature: -22.9, humidity: 51, lowBattery: false }
14:54:07debug [pimatic-homeduino]: weather12: { id: 149, channel: 1, temperature: 1.4, humidity: 38, lowBattery: false }

14:54:07debug [pimatic-homeduino]: received: [ 468, 1976, 3920, 8792 ] 0201010201020102010101010101010101010101020202010102010102020101020201010103

14:54:07debug [pimatic-homeduino]: data: "RF receive 468 3920 1976 8792 0 0 0 0 0102020102010201020202020202020202020202010101020201020201010202010102020203"```

Example:

#Value shown on device: +22.9 Celsius
debug [pimatic-homeduino]: weather14: { id: 175, channel: 1, temperature: -23, humidity: 51, lowBattery: false }
13:49:55debug [pimatic-homeduino]: weather12: { id: 149, channel: 1, temperature: 1.4, humidity: 46, lowBattery: false }
13:49:55debug [pimatic-homeduino]: received: [ 464, 1976, 3924, 8788 ] 0201010201020102010101010101010101010101020202010102010202020101020201010103
13:49:55debug [pimatic-homeduino]: data: "RF receive 464 3924 1976 8788 0 0 0 0 0102020102010201020202020202020202020202010101020201020101010202010102020203"

#Value shown on device: +22.5 Celsius
debug [pimatic-homeduino]: weather14: { id: 175, channel: 1, temperature: -22.6, humidity: 51, lowBattery: false }
13:51:35debug [pimatic-homeduino]: weather12: { id: 149, channel: 1, temperature: 1.4, humidity: 14, lowBattery: false }
13:51:35debug [pimatic-homeduino]: received: [ 488, 1956, 3904, 8776 ] 0201010201020102010101010101010101010101020202010101010202020101020201010103
13:51:35debug [pimatic-homeduino]: data: "RF receive 488 3904 1956 8776 0 0 0 0 0102020102010201020202020202020202020202010101020202020101010202010102020203"

#Value shown on device: +22.1 Celsius
debug [pimatic-homeduino]: weather14: { id: 175, channel: 1, temperature: -22.2, humidity: 51, lowBattery: false }
13:54:55debug [pimatic-homeduino]: weather12: { id: 149, channel: 1, temperature: 1.3, humidity: 110, lowBattery: false }
13:54:55debug [pimatic-homeduino]: received: [ 472, 1972, 3920, 8784 ] 0201010201020102010101010101010101010101020201020202010202020101020201010103
13:54:55debug [pimatic-homeduino]: data: "RF receive 472 3920 1972 8784 0 0 0 0 0102020102010201020202020202020202020202010102010101020101010202010102020203"

#Value shown on device: +20.1 Celsius
debug [pimatic-homeduino]: weather14: { id: 175, channel: 1, temperature: -20.2, humidity: 51, lowBattery: false }
13:56:35debug [pimatic-homeduino]: weather12: { id: 149, channel: 1, temperature: 1.2, humidity: 78, lowBattery: false }
13:56:35debug [pimatic-homeduino]: received: [ 488, 1952, 3904, 8776 ] 0201010201020102010101010101010101010101020201010201010202020101020201010103
13:56:35debug [pimatic-homeduino]: data: "RF receive 488 3904 1952 8776 0 0 0 0 0102020102010201020202020202020202020202010102020102020101010202010102020203"

So far it looks the offset is only 0.1 Celsius. Looks like it’s usable, but the negative value should be turned to positive …
And of course there’s that curious case of it identifying as weather12, but if it’s not added into devices it’s being discarded anyway.

@kitsunen said:

So far it looks the offset is only 0.1 Celsius. Looks like it’s usable, but the negative value should be turned to positive …

OK, I_ll have a look into this later. Perhaps the temperature is a 10 bit rather than 12 bit.

And of course there’s that curious case of it identifying as weather12, but if it’s not added into devices it’s being discarded anyway.

Exactly, it is common the multiple protocols match as candidates if the pulse length and number of pulse are similar.