unsupported sensor type 18! Digital Barometer Thermometer Hygrometer (TFA 35.1154.01)

[patrikhall]

type 0x18 sensor seems to be the only weatherhub that support barometric air pressure. The display shows air pressure in HPa, temperature and humidity.

According to MobileAllerts gateway inary upload document, the sensor sends a 3-byte tx counter, temperature as a word, humidity as a byte and air pressure as another word.

Typical debug output:

#000 1668864169 L=44  4b 2d d4 2b 24 18 39 90 8d 49 c9 40 02 94 00 da 1d 27 c4 00 da 1d 27 c5 02 05 07 0a 0b 0c 00 00 00 00 00 00 d0 9d 83 3c 00 80 aa 0a  RSSI 66 WHB: Probably unsupported sensor type 18! Please report
; 1017.9 HPa, 21.8 deg C, 30% humidity

#013 1668864529 L=44  4b 2d d4 2b 24 18 39 90 8d 49 c9 40 02 95 00 db 1e 27 c3 00 da 1d 27 c4 02 06 08 0a 0c 0d 00 00 00 00 00 00 72 49 60 10 00 20 86 2e  RSSI 66 WHB: Probably unsupported sensor type 18! Please report
; 1018.0 HPa, 21.9 deg C, 30% humidity

#036 1668865249 L=45  4b 2d d4 2b 24 18 39 90 8d 49 c9 40 02 97 00 dc 1e 27 c3 00 db 1e 27 c3 02 06 07 0a 0b 0d 00 00 00 00 00 00 ee 72 4b 9d 00 80 0a 11 00  RSSI 69 WHB: Probably unsupported sensor type 18! Please report
; 1017,9 HPa, 22.0 deg C, 30% humidity

CRC-32 init value for the sensor is 0xf39c8e73.

[jarau-de]

I wish support for this sensor type too. If I would now how the initial value is calculated by reveng tools (as mentioned in the whb.cpp file) I could try to add that by myself. Is the checksum for the whole byte stream? Or does it start after id? I don't know. I had no success with the reveng tool yet.

[patrikhall]

I did first verify reveng functionality with a known sensor and a known init crc value, like this:

#7106 1675763487 L=33  4b 2d d4 2b 1a 09 5f 4a 26 33 a1 37 77 00 b3 00 b4 0a 24 00 b3 00 b4 0a 24 0d da 75 14 4c 80 5b 0d  RSSI 77 WHB09 ID 95f4a2633a1TEMP 17.9 HUM 36 TEMP2 18, PTEMP 17.9 PHUM 36 PTEMP2 18

The type of sensor is 9, the init value should be 0xa7a41254.

4b 2d d4 2b is the init bytes, 1a is the length. 1a is also the first byte in the crc calculation. I found out that leaving out the three last bytes 80 5b 0d results in 0x00000000 as end value, and this is what we would like to accomplish.

The command for verify would look like this:

$ ./reveng -c -w 32 -p 0x04c11db7 -i 0xa7a41254 1a095f4a2633a1377700b300b40a2400b300b40a240dda75144c
00000000

Ok, next step would be to search for algorithm with reveng. We need many samples. I collected some samples from my sensor, and serching will be done like this:

./reveng -w 32 -s 241839908d49c940029400da1d27c400da1d27c50205070a0b0c000000000000d09d833c00 241839908d49c940029500db1e27c300da1d27c40206080a0c0d0000000000007249601000 241839908d49c9404d6d00d71c27aa00d71c27ac03070a0a0d0f01010101010176415bec00 241839908d49c9404d6c00d71c27ac00d71c27ac010608090b0e030303030303bbbce01b00
width=32  poly=0x04c11db7  init=0xca0abb08  refin=false  refout=false  xorout=0x00000000  check=0x5fd65594  residue=0x00000000  name=(none)

The init crc value for the sensor seems then to be 0xca0abb08

[jarau-de]

Thanks a lot for the response. But I got it by myself. It was not mentioned where the crc-32 starts. Because there is the initial code which obviously not belongs to the crc range. That was my problem. I had a look into the whb.cpp and saw that first 4 bytes are skipped. That helps. I own a WHB07 which is already supported. With these information I was able to to calculate initial crc value for WHB07, finally for WHB18 and added WHB18 to the code. I also added the battery status for command line output. WHB18 also contains information of previous data (temp, hum, barometric pressure). Somebody interested in these code?

[patrikhall]

I would be interested, sure, as I also have a WHB18 myself. I would like to get temp, humidity and pressure fed as parameter to external script using -e option.

[jarau-de]

I've forked code and mad a pull request for my additions for WHB18.

[patrikhall]

I did see your fork, you might consider using cvs_temp with extended range like this:

sd.pressure=cvt_temp(bp, 1);

...to get better range for air pressure. The range is probably even bigger than 10 or 11 bits, so creating another cvt_pressure with 16 bit would be appropriate. Just my thoughts.