search

merbanan / rtl_433

Program to decode radio transmissions from devices on the ISM bands (and other frequencies)
GNU General Public License v2.0
6.09k stars 1.32k forks source link

Support for Bresser Explore Scientific 7 in 1 Weather Center at 868 MHz #1492

Closed Tuxyso closed 3 years ago

Tuxyso commented 4 years ago

Hi!

I own:

https://www.bresser.de/en/EXPLORE-SCIENTIFIC-professional-7-in-1-Wi-Fi-Weather-Centre-with-Light-Intensity-and-UV-Measurement-Function.html

The sensor transmits data at 868 MHz. With

rtl_433 -f 868.3M

I do not receive any data.

Can I provide some raw data to you so that you can add support?

Kind regards, Tuxyso

zuckschwerdt commented 4 years ago

Sure, get sample data with -S unknown. Note down the expected measurement values from a read-out or head unit. Try analyzing each sample with rtl_433 -A gfile.cu8 to see if there is some real data. Also check the spectrogram by dropping samples on https://triq.org/iqs/ (it should look "busy" like this) Then upload the zipped samples here and post a description and tabled values per sample file. Happy hacking!

Tuxyso commented 4 years ago

I gathered data with rtl_433 -f 868.3M -S unknown

For the received files g001_868.3M_1000k.cu8 ... g007_868.3M_1000k.cu8

I called rtl_433 -A g001_868.3M_1000k.cu8

Output is as follows:

Reading samples from file: g001_868.3M_1000k.cu8 Detected FSK package @0.292000s Analyzing pulses... Total count: 99, width: 130.69 ms (32673 S) Pulse width distribution: [ 0] count: 4, width: 1544 us [1464;1788] ( 386 S) [ 1] count: 82, width: 488 us [484;492] ( 122 S) [ 2] count: 8, width: 976 us [972;980] ( 244 S) [ 3] count: 3, width: 2600 us [2440;2928] ( 650 S) [ 4] count: 1, width: 1952 us [1952;1952] ( 488 S) [ 5] count: 1, width: 4396 us [4396;4396] (1099 S) Gap width distribution: [ 0] count: 82, width: 488 us [484;492] ( 122 S) [ 1] count: 5, width: 1464 us [1460;1468] ( 366 S) [ 2] count: 8, width: 972 us [972;980] ( 243 S) [ 3] count: 2, width: 2684 us [2440;2928] ( 671 S) [ 4] count: 1, width: 1952 us [1952;1952] ( 488 S) Pulse period distribution: [ 0] count: 12, width: 2060 us [1948;2444] ( 515 S) [ 1] count: 72, width: 976 us [972;980] ( 244 S) [ 2] count: 7, width: 1464 us [1460;1468] ( 366 S) [ 3] count: 4, width: 2928 us [2928;2932] ( 732 S) [ 4] count: 3, width: 4392 us [3904;4884] (1098 S) Level estimates [high, low]: 15887, 42 RSSI: -0.1 dB SNR: 25.8 dB Noise: -25.9 dB Frequency offsets [F1, F2]: 5542, -6781 (+21.1 kHz, -25.9 kHz) Guessing modulation: No clue...

Reading samples from file: g002_868.3M_1000k.cu8 Detected FSK package @0.105900s Analyzing pulses... Total count: 54, width: 89.93 ms (22483 S) Pulse width distribution: [ 0] count: 1, width: 0 us [0;0] ( 0 S) [ 1] count: 26, width: 400 us [376;412] ( 100 S) [ 2] count: 10, width: 1196 us [1192;1208] ( 299 S) [ 3] count: 12, width: 796 us [792;808] ( 199 S) [ 4] count: 3, width: 1596 us [1596;1600] ( 399 S) [ 5] count: 2, width: 2196 us [2004;2392] ( 549 S) Gap width distribution: [ 0] count: 1, width: 9956 us [9956;9956] (2489 S) [ 1] count: 27, width: 396 us [388;408] ( 99 S) [ 2] count: 15, width: 800 us [788;812] ( 200 S) [ 3] count: 5, width: 1200 us [1196;1204] ( 300 S) [ 4] count: 5, width: 2000 us [1996;2008] ( 500 S) Pulse period distribution: [ 0] count: 1, width: 9956 us [9956;9956] (2489 S) [ 1] count: 14, width: 796 us [784;808] ( 199 S) [ 2] count: 8, width: 1596 us [1592;1604] ( 399 S) [ 3] count: 12, width: 1200 us [1196;1212] ( 300 S) [ 4] count: 15, width: 2184 us [1996;2408] ( 546 S) [ 5] count: 3, width: 2796 us [2792;2804] ( 699 S) Level estimates [high, low]: 1370, 45 RSSI: -10.8 dB SNR: 14.8 dB Noise: -25.6 dB Frequency offsets [F1, F2]: 2974, -2090 (+11.3 kHz, -8.0 kHz) Guessing modulation: Pulse Code Modulation (Not Return to Zero) Attempting demodulation... short_width: 400, long_width: 400, reset_limit: 409600, sync_width: 0 Use a flex decoder with -X 'n=name,m=FSK_PCM,s=400,l=400,r=409600'

Test mode active. Reading samples from file: g003_868.3M_1000k.cu8 Detected FSK package @0.115504s Analyzing pulses... Total count: 29, width: 79.93 ms (19983 S) Pulse width distribution: [ 0] count: 1, width: 27548 us [27548;27548] (6887 S) [ 1] count: 8, width: 800 us [796;808] ( 200 S) [ 2] count: 7, width: 396 us [392;408] ( 99 S) [ 3] count: 5, width: 1760 us [1600;2008] ( 440 S) [ 4] count: 7, width: 1196 us [1196;1204] ( 299 S) [ 5] count: 1, width: 2800 us [2800;2800] ( 700 S) Gap width distribution: [ 0] count: 5, width: 1192 us [1176;1204] ( 298 S) [ 1] count: 13, width: 400 us [396;408] ( 100 S) [ 2] count: 7, width: 796 us [788;808] ( 199 S) [ 3] count: 1, width: 2008 us [2008;2008] ( 502 S) [ 4] count: 1, width: 1596 us [1596;1596] ( 399 S) [ 5] count: 1, width: 2796 us [2796;2796] ( 699 S) Pulse period distribution: [ 0] count: 1, width: 28724 us [28724;28724] (7181 S) [ 1] count: 7, width: 1200 us [1192;1208] ( 300 S) [ 2] count: 4, width: 796 us [796;800] ( 199 S) [ 3] count: 9, width: 2132 us [2000;2404] ( 533 S) [ 4] count: 5, width: 3200 us [2800;3604] ( 800 S) [ 5] count: 2, width: 1600 us [1600;1600] ( 400 S) Level estimates [high, low]: 1419, 68 RSSI: -10.6 dB SNR: 13.2 dB Noise: -23.8 dB Frequency offsets [F1, F2]: 1329, -4566 (+5.1 kHz, -17.4 kHz) Guessing modulation: Pulse Code Modulation (Not Return to Zero) Attempting demodulation... short_width: 396, long_width: 396, reset_limit: 405504, sync_width: 0 Use a flex decoder with -X 'n=name,m=FSK_PCM,s=396,l=396,r=405504'

Test mode active. Reading samples from file: g004_868.3M_1000k.cu8 Detected FSK package @0.291996s Analyzing pulses... Total count: 98, width: 130.70 ms (32674 S) Pulse width distribution: [ 0] count: 8, width: 1504 us [1464;1788] ( 376 S) [ 1] count: 78, width: 484 us [480;492] ( 121 S) [ 2] count: 9, width: 972 us [972;980] ( 243 S) [ 3] count: 1, width: 1952 us [1952;1952] ( 488 S) [ 4] count: 1, width: 4396 us [4396;4396] (1099 S) [ 5] count: 1, width: 2928 us [2928;2928] ( 732 S) Gap width distribution: [ 0] count: 81, width: 488 us [484;496] ( 122 S) [ 1] count: 6, width: 1464 us [1460;1468] ( 366 S) [ 2] count: 2, width: 2684 us [2444;2928] ( 671 S) [ 3] count: 7, width: 972 us [972;980] ( 243 S) [ 4] count: 1, width: 1956 us [1956;1956] ( 489 S) Pulse period distribution: [ 0] count: 17, width: 2144 us [1952;2444] ( 536 S) [ 1] count: 70, width: 976 us [972;980] ( 244 S) [ 2] count: 6, width: 1464 us [1460;1468] ( 366 S) [ 3] count: 1, width: 2932 us [2932;2932] ( 733 S) [ 4] count: 2, width: 4880 us [4392;5368] (1220 S) [ 5] count: 1, width: 3904 us [3904;3904] ( 976 S) Level estimates [high, low]: 15890, 31 RSSI: -0.1 dB SNR: 27.1 dB Noise: -27.2 dB Frequency offsets [F1, F2]: 3648, -5674 (+13.9 kHz, -21.6 kHz) Guessing modulation: Pulse Code Modulation (Not Return to Zero) Attempting demodulation... short_width: 484, long_width: 484, reset_limit: 495616, sync_width: 0 Use a flex decoder with -X 'n=name,m=FSK_PCM,s=484,l=484,r=495616'

Reading samples from file: g005_868.3M_1000k.cu8 Detected FSK package @0.222096s Analyzing pulses... Total count: 52, width: 236.66 ms (59164 S) Pulse width distribution: [ 0] count: 1, width: 0 us [0;0] ( 0 S) [ 1] count: 2, width: 3476 us [3420;3532] ( 869 S) [ 2] count: 38, width: 492 us [492;496] ( 123 S) [ 3] count: 5, width: 980 us [980;984] ( 245 S) [ 4] count: 4, width: 1468 us [1468;1468] ( 367 S) [ 5] count: 1, width: 1956 us [1956;1956] ( 489 S) [ 6] count: 1, width: 16 us [16;16] ( 4 S) Gap width distribution: [ 0] count: 1, width: 76 us [76;76] ( 19 S) [ 1] count: 36, width: 476 us [476;484] ( 119 S) [ 2] count: 3, width: 1456 us [1456;1456] ( 364 S) [ 3] count: 1, width: 3404 us [3404;3404] ( 851 S) [ 4] count: 5, width: 964 us [964;968] ( 241 S) [ 5] count: 1, width: 4380 us [4380;4380] (1095 S) [ 6] count: 1, width: 20456 us [20456;20456] (5114 S) [ 7] count: 1, width: 8764 us [8764;8764] (2191 S) [ 8] count: 1, width: 11200 us [11200;11200] (2800 S) [ 9] count: 1, width: 123404 us [123404;123404] (30851 S) Pulse period distribution: [ 0] count: 1, width: 76 us [76;76] ( 19 S) [ 1] count: 3, width: 4100 us [3900;4384] (1025 S) [ 2] count: 31, width: 972 us [972;976] ( 243 S) [ 3] count: 6, width: 1948 us [1948;1952] ( 487 S) [ 4] count: 5, width: 1460 us [1460;1464] ( 365 S) [ 5] count: 1, width: 5848 us [5848;5848] (1462 S) [ 6] count: 1, width: 20952 us [20952;20952] (5238 S) [ 7] count: 1, width: 10232 us [10232;10232] (2558 S) [ 8] count: 1, width: 13156 us [13156;13156] (3289 S) [ 9] count: 1, width: 124872 us [124872;124872] (31218 S) Level estimates [high, low]: 12044, 40 RSSI: -1.3 dB SNR: 24.8 dB Noise: -26.1 dB Frequency offsets [F1, F2]: 3598, -8773 (+13.7 kHz, -33.5 kHz) Guessing modulation: No clue...

Reading samples from file: g006_868.3M_1000k.cu8 Detected FSK package @0.234420s Analyzing pulses... Total count: 460, width: 124.33 ms (31082 S) Pulse width distribution: [ 0] count: 2, width: 336 us [308;368] ( 84 S) [ 1] count: 411, width: 120 us [116;128] ( 30 S) [ 2] count: 47, width: 240 us [240;248] ( 60 S) Gap width distribution: [ 0] count: 411, width: 120 us [104;132] ( 30 S) [ 1] count: 1, width: 360 us [360;360] ( 90 S) [ 2] count: 47, width: 244 us [240;248] ( 61 S) Pulse period distribution: [ 0] count: 71, width: 368 us [364;492] ( 92 S) [ 1] count: 375, width: 244 us [240;252] ( 61 S) [ 2] count: 13, width: 488 us [488;492] ( 122 S) Level estimates [high, low]: 1000, 51 RSSI: -12.1 dB SNR: 12.9 dB Noise: -25.1 dB Frequency offsets [F1, F2]: 3722, -4026 (+14.2 kHz, -15.4 kHz) Guessing modulation: Pulse Width Modulation with sync/delimiter Attempting demodulation... short_width: 120, long_width: 240, reset_limit: 364, sync_width: 336 Use a flex decoder with -X 'n=name,m=OOK_PWM,s=120,l=240,r=364,g=0,t=0,y=336' pulse_demod_pwm(): Analyzer Device bitbuffer:: Number of rows: 2 [00] {283} ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff e0 [01] {175} 6b f6 ea ab f3 ef ff ef fb b5 4f 7d bf f9 db 6d fb 66 e9 ab ef 66

Detected FSK package @0.358840s Analyzing pulses... Total count: 336, width: 99.52 ms (24880 S) Pulse width distribution: [ 0] count: 72, width: 244 us [240;264] ( 61 S) [ 1] count: 264, width: 120 us [116;128] ( 30 S) Gap width distribution: [ 0] count: 263, width: 120 us [116;132] ( 30 S) [ 1] count: 72, width: 244 us [236;248] ( 61 S) Pulse period distribution: [ 0] count: 84, width: 364 us [360;396] ( 91 S) [ 1] count: 30, width: 488 us [484;492] ( 122 S) [ 2] count: 221, width: 244 us [240;252] ( 61 S) Level estimates [high, low]: 1000, 53 RSSI: -12.1 dB SNR: 12.8 dB Noise: -24.9 dB Frequency offsets [F1, F2]: 3431, -3769 (+13.1 kHz, -14.4 kHz) Guessing modulation: Manchester coding Attempting demodulation... short_width: 120, long_width: 0, reset_limit: 252, sync_width: 0 Use a flex decoder with -X 'n=name,m=OOK_MC_ZEROBIT,s=120,l=0,r=252' pulse_demod_manchester_zerobit(): Analyzer Device bitbuffer:: Number of rows: 1 [00] {408} 6d 01 7e cb f7 85 a2 ff ff ff f4 91 ff ff ff b4 91 8f ff 91 e9 ff bd 93 80 d3 cd 93 00 00 fb 92 e8 f8 72 d6 7d 3e 3f fb 93 60 d7 74 fb 91 ff ff ff 85 2e

Reading samples from file: g007_868.3M_1000k.cu8 Detected FSK package @0.292040s Analyzing pulses... Total count: 97, width: 166.71 ms (41678 S) Pulse width distribution: [ 0] count: 8, width: 1500 us [1464;1748] ( 375 S) [ 1] count: 74, width: 488 us [480;492] ( 122 S) [ 2] count: 11, width: 976 us [972;980] ( 244 S) [ 3] count: 3, width: 3092 us [2928;3416] ( 773 S) [ 4] count: 1, width: 64 us [64;64] ( 16 S) Gap width distribution: [ 0] count: 78, width: 488 us [484;492] ( 122 S) [ 1] count: 5, width: 1464 us [1460;1468] ( 366 S) [ 2] count: 2, width: 1952 us [1952;1952] ( 488 S) [ 3] count: 8, width: 972 us [972;976] ( 243 S) [ 4] count: 2, width: 2684 us [2444;2928] ( 671 S) [ 5] count: 1, width: 35992 us [35992;35992] (8998 S) Pulse period distribution: [ 0] count: 16, width: 2212 us [1948;2444] ( 553 S) [ 1] count: 67, width: 976 us [972;980] ( 244 S) [ 2] count: 7, width: 1464 us [1460;1472] ( 366 S) [ 3] count: 4, width: 4024 us [3904;4392] (1006 S) [ 4] count: 1, width: 2932 us [2932;2932] ( 733 S) [ 5] count: 1, width: 36484 us [36484;36484] (9121 S) Level estimates [high, low]: 15927, 34 RSSI: -0.1 dB SNR: 26.7 dB Noise: -26.8 dB Frequency offsets [F1, F2]: 6551, -5607 (+25.0 kHz, -21.4 kHz) Guessing modulation: No clue...

Does it help? Cu8 are following...

zipped-cu8.zip

Tuxyso commented 4 years ago

Additional info: According to datasheet the outdoor sensor transmits data every 12 seconds. The files g004 and g007have an exact difference of 12 seconds, so I guess these files are from the outdoor sensor.

g004_868.3M_1000k.cu8: 2020-09-13T10:46:32.000Z g007_868.3M_1000k.cu8: 2020-09-13T10:46:44.000Z

Signal is as follows:

image

g007_868.3M_1000k.zip g004_868.3M_1000k.zip

zuckschwerdt commented 4 years ago

You captured 3 different devices:

Your assumption fits with the first group. I'll take a closer look now.

Tuxyso commented 4 years ago

Further analysis: The indoor sensor transmits every minute. I received

g031_868.3M_1000k.cu8:2020-09-13T11:33:49.000Z g037_868.3M_1000k.cu8:2020-09-13T11:34:49.000Z

The occurence at the console corresponds to the tansmit led from the indoor sensor. The signal characteristic looks very similiar to the one from above.

Test mode active. Reading samples from file: g031_868.3M_1000k.cu8 Detected FSK package @0.292064s Analyzing pulses... Total count: 96, width: 130.63 ms (32658 S) Pulse width distribution: [ 0] count: 11, width: 1488 us [1460;1728] ( 372 S) [ 1] count: 77, width: 488 us [484;492] ( 122 S) [ 2] count: 6, width: 976 us [972;980] ( 244 S) [ 3] count: 2, width: 2196 us [1956;2440] ( 549 S) Gap width distribution: [ 0] count: 78, width: 488 us [484;492] ( 122 S) [ 1] count: 7, width: 1464 us [1460;1468] ( 366 S) [ 2] count: 5, width: 972 us [972;976] ( 243 S) [ 3] count: 1, width: 3908 us [3908;3908] ( 977 S) [ 4] count: 2, width: 2684 us [2440;2932] ( 671 S) [ 5] count: 2, width: 1952 us [1952;1952] ( 488 S) Pulse period distribution: [ 0] count: 17, width: 2024 us [1948;2444] ( 506 S) [ 1] count: 68, width: 976 us [972;980] ( 244 S) [ 2] count: 3, width: 1464 us [1464;1464] ( 366 S) [ 3] count: 2, width: 4884 us [4396;5372] (1221 S) [ 4] count: 5, width: 3024 us [2928;3416] ( 756 S) Level estimates [high, low]: 16003, 52 RSSI: -0.1 dB SNR: 24.9 dB Noise: -25.0 dB Frequency offsets [F1, F2]: 3838, -7093 (+14.6 kHz, -27.1 kHz) Guessing modulation: Pulse Code Modulation (Not Return to Zero) Attempting demodulation... short_width: 488, long_width: 488, reset_limit: 499712, sync_width: 0 Use a flex decoder with -X 'n=name,m=FSK_PCM,s=488,l=488,r=499712'

Test mode active. Reading samples from file: g037_868.3M_1000k.cu8 Detected FSK package @0.291976s Analyzing pulses... Total count: 97, width: 166.78 ms (41694 S) Pulse width distribution: [ 0] count: 9, width: 1504 us [1464;1812] ( 376 S) [ 1] count: 77, width: 488 us [484;492] ( 122 S) [ 2] count: 8, width: 976 us [972;980] ( 244 S) [ 3] count: 1, width: 2928 us [2928;2928] ( 732 S) [ 4] count: 1, width: 4396 us [4396;4396] (1099 S) [ 5] count: 1, width: 32 us [32;32] ( 8 S) Gap width distribution: [ 0] count: 80, width: 488 us [480;492] ( 122 S) [ 1] count: 5, width: 1464 us [1460;1468] ( 366 S) [ 2] count: 2, width: 1948 us [1948;1952] ( 487 S) [ 3] count: 6, width: 972 us [972;976] ( 243 S) [ 4] count: 1, width: 5372 us [5372;5372] (1343 S) [ 5] count: 1, width: 2928 us [2928;2928] ( 732 S) [ 6] count: 1, width: 36028 us [36028;36028] (9007 S) Pulse period distribution: [ 0] count: 16, width: 2124 us [1948;2448] ( 531 S) [ 1] count: 68, width: 976 us [972;980] ( 244 S) [ 2] count: 7, width: 1464 us [1460;1468] ( 366 S) [ 3] count: 1, width: 6840 us [6840;6840] (1710 S) [ 4] count: 2, width: 4640 us [4396;4888] (1160 S) [ 5] count: 1, width: 3416 us [3416;3416] ( 854 S) [ 6] count: 1, width: 36516 us [36516;36516] (9129 S) Level estimates [high, low]: 16003, 58 RSSI: -0.1 dB SNR: 24.4 dB Noise: -24.5 dB Frequency offsets [F1, F2]: 6007, -6489 (+22.9 kHz, -24.8 kHz) Guessing modulation: No clue...

image

image

g037_868.3M_1000k.zip g031_868.3M_1000k.zip

zuckschwerdt commented 4 years ago

Note that with 868M the default sample rate will be 1000k, so you need to add that when running -A on samples: -s 1000k.

zuckschwerdt commented 4 years ago

You can use rtl_433 -s 1000k -X 'n=Bresser-7in1,m=FSK_PCM,s=125,l=125,r=9000,preamble=2dd4' gfile.cu8 to read samples and also the -X option for live readings.

Tuxyso commented 4 years ago

I called

rtl_433 -f 868.3M -s 1000k -X 'n=Bresser-7in1,m=FSK_PCM,s=125,l=125,r=9000,preamble=2dd4'

and got:

2020-09-13 14:33:13 {271}1b1905c0a9ba18abaabaaaaaaaaa899afcac8cbdae8aaaaaaa000000000000000000
2020-09-13 14:33:25 {271}d16905c0bffa18aa9aa9aaaaaaaa899afeac8db3ae8aaaaaaa000000000000000000
2020-09-13 14:33:37 {271}eab705c0bbea18abbabbaaaaaaaa899afeac8f3eae8aaaaaaa000000000000000000
2020-09-13 14:33:49 {271}c63005c08e3a18aa9aa9aaaaaaaa899af9ac8c99ae8aaaaaaa000000000000000000
2020-09-13 14:34:01 {271}f21a05c08cba18aa9aa9aaaaaaaa899af9ac8c9fae8aaaaaaa000000000000000000
2020-09-13 14:34:13 {271}02b105c0beda18aaeaaeaaaaaaaa899af9ac8fc9ae8aaaaaaa000000000000000000
2020-09-13 14:34:25 {271}480605c0b2ba18aa8aa8aaaaaaaa899afeac8dbfae8aaaaaaa000000000000000000
2020-09-13 14:34:37 {271}812705c08aca18abaabaaaaaaaaa899afeac822cae8aaaaaaa000000000000000000

Do you need further information?

zuckschwerdt commented 4 years ago

This seems to be good data:

g001_868.3M_1000k.cu8  {271}9f5d05c08b2a18abcabeaaaaaaaa8adac8acffa9afcaaaaaaa000000000000000000
g004_868.3M_1000k.cu8  {271}631d05c09e9a18abaabaaaaaaaaa8adacbacff9cafcaaaaaaa000000000000000000
g007_868.3M_1000k.cu8  {271}3fb905c08dca18ab9ab9aaaaaaaa8adaceacfcd8afcaaaaaaa000000000000000000

Not sure what's encoded though, it doesn't look like the 5-in-1. Can you table more values with expected measurement values in a BitBench?

Tuxyso commented 4 years ago

Additionaly (with len 240, with 1 minute period probably indoor sensor):

time : 2020-09-13 14:41:57 codes : {240}ec76197005fd29000000000023865600004c000007000000000000000000

time : 2020-09-13 14:42:57 codes : {240}5b3b197005fd29000000000023765600005c000007000000000000000000

zuckschwerdt commented 4 years ago

Yes, that matches g005_868.3M_1000k.cu8 {240}6ab0197005fd29000000000022965700003c000007000000000000000000 something much different but likely the same protocol, so indoor sensor sounds good.

Tuxyso commented 4 years ago

Current values: Outdoor: 23.3° C / 54 % / 1026 hPa Light: 61.5 kLux Indoor: 23.7°C / 56 % no rain currently

zuckschwerdt commented 4 years ago

There is so much changing data in the codes that it's hard to spot where the value fields are. You need to play with the BitBench to hopefully pin down some values. Humidity might be easiest to spot, with 8d it should show up somewhere.

Tuxyso commented 4 years ago

Sorry, but I do not really understand what to do with BitBench. Later on this day I will provide more comprehensive und systematic measurements - I will exactly describe with values change from file to file. And I will put the indoor sender into the fridge and will additionaly change the channel. If you have any further hints for my measurements, I will listen to you :)

Tuxyso commented 4 years ago

I made a rather strange observation while analysing the indoor sensor:

56e4197005fd2900000000002426570000aa000007000000000000000000 (24,2 / 57 / CH 1) 2b7e197005fd210000000000255656000082000007000000000000000000 (25,5 / 56 / CH 1) 118f197005fd2200000000002506570000d0000007000000000000000000 (25,0 / 57 / CH 2) 8358197005fd27000000000025365600009c000007000000000000000000 (25,3 / 56 / CH 7)

Temperature and humidity is directly hex encoded, hex values = decimal values.

zuckschwerdt commented 4 years ago

Great! The format is "BCD". Marking the values (like bold in your post) is exactly what BitBench does :) This BitBench should better show how to mark and extract values.

Tuxyso commented 4 years ago

Further analysis for outdoor sensor:

[ ] seems to be temp; { } humidity
2b1f05c0beda18aaaaaaaaaaaaaa8f[aae]{3a}b892faa2aaaaaaa000000000000000000 (25,0° / 49%)
f85505c0bfba18aabaabaaaaaaaa8f[aae]{3a}b88acaa3aaaaaaa000000000000000000 (25,0 / 49%)
8c2a05c0a8fa18aabaabaaaaaaaa8e[fae]{3a}ed3b9a92aaaaaaa000000000000000000 (24,5 / 49%)
f4a105c0beaa18aa9aa9aaaaaaaa8f[aae]{2a}b882baa3aaaaaaa000000000000000000 (25,0 / 48%)
26c305c0bc9a18aa8aa8aaaaaaaa8f[aae]{2a}b8aadaa3aaaaaaa000000000000000000 (25,0 / 48%)
439a05c0bcba18aaaaaaaaaaaaaa8f[bae]{2a}b83fdaa3aaaaaaa000000000000000000 (25,1 / 48%)
1d4005c0888a18aabaabaaaaaaaa8e[cae]{2a}efef2a9daaaaaaa000000000000000000   (24,6 / 48)
c7dd05c08bda18aa8aa8aaaaaaaa8e[eae]{2a}e2d83aeaaaaaaaa000000000000000000   (24,4 / 48 )
967005c09b3a18aa8aa8aaaaaaaa8e[fae]{2a}e28cea93aaaaaaa000000000000000000   (24,5 / 48 )
zuckschwerdt commented 4 years ago

Here is the BitBench with this data. The fields seem right but are not easy to decode?

Tuxyso commented 4 years ago

The temperature / humidity field behaves strange. I summarize my current insights;

1) same hex value means same humidity (but some hex values stand for different humidities).

hex humidity (%)
2a 48
3a 49
aa 50
fa 75
  76
  77
2a 78
3a 79
aa 80
ba 81
8a 82
9a 83
ea 84

Strange is that 2a stands for 48% and for 78 %:

f4a105c0beaa18aa9aa9aaaaaaaa8f aae 2a b882baa3aaaaaaa000000000000000000 [25,0 48]

106205c09aca18aaaaaaaaaaaaaabd aad 2a aaaaaaaaaaaaaaa000000000000000000 [17,0 78]

2) hex values for humidity increment, but there are jumps: 2a = 48 3a = 49 aa = 50 8a = 82 9a = 83 ea = 84

3) same temperature / different values temperature increments, but there seem to be a strange interdependency from humidy when changing the tenner (e.g. 79 -> 80).

See the following annomaly:

c3c805c09afa18aaaaaaaaaaaaaabc dad 3a aaaaaaaaaaaaaaa000000000000000000 [16,7 79]

d74c05c09afa18aaaaaaaaaaaaaabc da2 aa aaaaaaaaaaaaaaa000000000000000000 [16,7 80]

Here you get for 16,7°C different values (probably dependent from humidity). Another example:

f85505c0bfba18aabaabaaaaaaaa8f aae 3a b88acaa3aaaaaaa000000000000000000 [25,0 49]

9c7205c0bcba18aaaaaaaaaaaaaa8f baf aa b8d92aa3aaaaaaa000000000000000000 [25,1 50] Normally 0.1 change increments in the first number. Thus after aae (for 25,0) it should be bae (for 25.1) but it is rather different.

Any hints / ideas, experts?

Complete sample:

2b1f05c0beda18aaaaaaaaaaaaaa8f aae 3a b892faa2aaaaaaa000000000000000000 [25,0 49] f85505c0bfba18aabaabaaaaaaaa8f aae 3a b88acaa3aaaaaaa000000000000000000 [25,0 49] A 9c7205c0bcba18aaaaaaaaaaaaaa8f baf aa b8d92aa3aaaaaaa000000000000000000 [25,1 50] A 8c2a05c0a8fa18aabaabaaaaaaaa8e fae 3a ed3b9a92aaaaaaa000000000000000000 [24,5 49] f4a105c0beaa18aa9aa9aaaaaaaa8f aae 2a b882baa3aaaaaaa000000000000000000 [25,0 48] 26c305c0bc9a18aa8aa8aaaaaaaa8f aae 2a b8aadaa3aaaaaaa000000000000000000 [25,0 48] 439a05c0bcba18aaaaaaaaaaaaaa8f bae 2a b83fdaa3aaaaaaa000000000000000000 [25,1 48] 1d4005c0888a18aabaabaaaaaaaa8e cae 2a efef2a9daaaaaaa000000000000000000 [24,6 48] c7dd05c08bda18aa8aa8aaaaaaaa8e eae 2a e2d83aeaaaaaaaa000000000000000000 [24,4 48] 967005c09b3a18aa8aa8aaaaaaaa8e fae 2a e28cea93aaaaaaa000000000000000000 [24,5 48] 93ad05c09aca18aaaaaaaaaaaaaabd 2ad fa aab9faaaaaaaaaa000000000000000000 [17,8 75] 106205c09aca18aaaaaaaaaaaaaabd aad 2a aaaaaaaaaaaaaaa000000000000000000 [17,0 78] 57b105c09aca18aaaaaaaaaaaaaabd aad 3a aaaaaaaaaaaaaaa000000000000000000 [17,0 79] 87ef05c09aca18aaaaaaaaaaaaaabc 3a2 ba aaaaaaaaaaaaaaa000000000000000000 [16,9 81] 4f9a05c09aca18aaaaaaaaaaaaaabc 3a2 8a aaaaaaaaaaaaaaa000000000000000000 [16,9 82] 5bb705c09aca18aaaaaaaaaaaaaabc 2a2 9a aaaaaaaaaaaaaaa000000000000000000 [16,8 83] 4fde05c09aca18aaaaaaaaaaaaaabc da2 9a aaaaaaaaaaaaaaa000000000000000000 [16,7 83] 080d05c09aca18aaaaaaaaaaaaaabc da2 8a aaaaaaaaaaaaaaa000000000000000000 [16,7 82] a3db05c09ada18aaaaaaaaaaaaaabc ca2 ba aaaaaaaaaaaaaaa000000000000000000 [16,6 81] e75205c09a2a18aaaaaaaaaaaaaabc ca2 aa aaaaaaaaaaaaaaa000000000000000000 [16,6 80] 54ac05c09baa18aaaaaaaaaaaaaabc cad 3a aaaaaaaaaaaaaaa000000000000000000 [16,6 79] 64f105c09bba18aaaaaaaaaaaaaabc cad 3a aaaaaaaaaaaaaaa000000000000000000 [16,6 79] A c3c805c09afa18aaaaaaaaaaaaaabc dad 3a aaaaaaaaaaaaaaa000000000000000000 [16,7 79] d74c05c09afa18aaaaaaaaaaaaaabc da2 aa aaaaaaaaaaaaaaa000000000000000000 [16,7 80] 909f05c09afa18aaaaaaaaaaaaaabc da2 ba aaaaaaaaaaaaaaa000000000000000000 [16,7 81] 58ea05c09afa18aaaaaaaaaaaaaabc da2 8a aaaaaaaaaaaaaaa000000000000000000 [16,7 82] 4fde05c09aca18aaaaaaaaaaaaaabc da2 9a aaaaaaaaaaaaaaa000000000000000000 [16,7 83] 1c2005c09aca18aaaaaaaaaaaaaabc ca2 9a aaaaaaaaaaaaaaa000000000000000000 [16,6 83] A ff1605c09afa18aaaaaaaaaaaaaabc fa2 8a aaaaaaaaaaaaaaa000000000000000000 [16,5 82] ff1605c09afa18aaaaaaaaaaaaaabc fa2 8a aaaaaaaaaaaaaaa000000000000000000 [16,5 82] ace805c09afa18aaaaaaaaaaaaaabc ea2 8a aaaaaaaaaaaaaaa000000000000000000 [16,4 82] 205705c09aca18aaaaaaaaaaaaaabc fa2 aa aaaaaaaaaaaaaaa000000000000000000 [16,5 80] ff1605c09afa18aaaaaaaaaaaaaabc fa2 8a aaaaaaaaaaaaaaa000000000000000000 [16,5 82] 7cc405c09aca18aaaaaaaaaaaaaabc ea2 ea aaaaaaaaaaaaaaa000000000000000000 [16,4 84] a00705c09baa18aaaaaaaaaaaaaabc ea2 ba aaaaaaaaaaaaaaa000000000000000000 [16,4 81]

zuckschwerdt commented 4 years ago

Looks like humidity is not the two nibbles you selected but one nibble to the left. Also it dies look BCD but with XOR 0xaa (something like whitening maybe?) -- which fits all the 0xaa we see, they would be 0x00 then):

2b1f05c0beda18aaaaaaaaaaaaaa 8faae3 ab892faa2aaaaaaa [25,0 49]  : 8faae3^aaaaaa = 250 0 49
f85505c0bfba18aabaabaaaaaaaa 8faae3 ab88acaa3aaaaaaa [25,0 49]  : 8faae3^aaaaaa = 250 0 49
9c7205c0bcba18aaaaaaaaaaaaaa 8fbafa ab8d92aa3aaaaaaa [25,1 50]  : 8fbafa^aaaaaa = 251 0 50
8c2a05c0a8fa18aabaabaaaaaaaa 8efae3 aed3b9a92aaaaaaa [24,5 49]  : 8efae3^aaaaaa = 245 0 49
f4a105c0beaa18aa9aa9aaaaaaaa 8faae2 ab882baa3aaaaaaa [25,0 48]  : 8faae2^aaaaaa = 250 0 48
26c305c0bc9a18aa8aa8aaaaaaaa 8faae2 ab8aadaa3aaaaaaa [25,0 48]  : 8faae2^aaaaaa = 250 0 48
439a05c0bcba18aaaaaaaaaaaaaa 8fbae2 ab83fdaa3aaaaaaa [25,1 48]  : 8fbae2^aaaaaa = 251 0 48
1d4005c0888a18aabaabaaaaaaaa 8ecae2 aefef2a9daaaaaaa [24,6 48]  : 8ecae2^aaaaaa = 246 0 48
c7dd05c08bda18aa8aa8aaaaaaaa 8eeae2 ae2d83aeaaaaaaaa [24,4 48]  : 8eeae2^aaaaaa = 244 0 48
967005c09b3a18aa8aa8aaaaaaaa 8efae2 ae28cea93aaaaaaa [24,5 48]  : 8efae2^aaaaaa = 245 0 48
93ad05c09aca18aaaaaaaaaaaaaa bd2adf aaab9faaaaaaaaaa [17,8 75]  : bd2adf^aaaaaa = 178 0 75
106205c09aca18aaaaaaaaaaaaaa bdaad2 aaaaaaaaaaaaaaaa [17,0 78]  : bdaad2^aaaaaa = 170 0 78
57b105c09aca18aaaaaaaaaaaaaa bdaad3 aaaaaaaaaaaaaaaa [17,0 79]  : bdaad3^aaaaaa = 170 0 79
87ef05c09aca18aaaaaaaaaaaaaa bc3a2b aaaaaaaaaaaaaaaa [16,9 81]  : bc3a2b^aaaaaa = 169 0 81
4f9a05c09aca18aaaaaaaaaaaaaa bc3a28 aaaaaaaaaaaaaaaa [16,9 82]  : bc3a28^aaaaaa = 169 0 82
5bb705c09aca18aaaaaaaaaaaaaa bc2a29 aaaaaaaaaaaaaaaa [16,8 83]  : bc2a29^aaaaaa = 168 0 83
4fde05c09aca18aaaaaaaaaaaaaa bcda29 aaaaaaaaaaaaaaaa [16,7 83]  : bcda29^aaaaaa = 167 0 83
080d05c09aca18aaaaaaaaaaaaaa bcda28 aaaaaaaaaaaaaaaa [16,7 82]  : bcda28^aaaaaa = 167 0 82
a3db05c09ada18aaaaaaaaaaaaaa bcca2b aaaaaaaaaaaaaaaa [16,6 81]  : bcca2b^aaaaaa = 166 0 81
e75205c09a2a18aaaaaaaaaaaaaa bcca2a aaaaaaaaaaaaaaaa [16,6 80]  : bcca2a^aaaaaa = 166 0 80
54ac05c09baa18aaaaaaaaaaaaaa bccad3 aaaaaaaaaaaaaaaa [16,6 79]  : bccad3^aaaaaa = 166 0 79
64f105c09bba18aaaaaaaaaaaaaa bccad3 aaaaaaaaaaaaaaaa [16,6 79]  : bccad3^aaaaaa = 166 0 79
c3c805c09afa18aaaaaaaaaaaaaa bcdad3 aaaaaaaaaaaaaaaa [16,7 79]  : bcdad3^aaaaaa = 167 0 79
d74c05c09afa18aaaaaaaaaaaaaa bcda2a aaaaaaaaaaaaaaaa [16,7 80]  : bcda2a^aaaaaa = 167 0 80
909f05c09afa18aaaaaaaaaaaaaa bcda2b aaaaaaaaaaaaaaaa [16,7 81]  : bcda2b^aaaaaa = 167 0 81
58ea05c09afa18aaaaaaaaaaaaaa bcda28 aaaaaaaaaaaaaaaa [16,7 82]  : bcda28^aaaaaa = 167 0 82
4fde05c09aca18aaaaaaaaaaaaaa bcda29 aaaaaaaaaaaaaaaa [16,7 83]  : bcda29^aaaaaa = 167 0 83
1c2005c09aca18aaaaaaaaaaaaaa bcca29 aaaaaaaaaaaaaaaa [16,6 83]  : bcca29^aaaaaa = 166 0 83
ff1605c09afa18aaaaaaaaaaaaaa bcfa28 aaaaaaaaaaaaaaaa [16,5 82]  : bcfa28^aaaaaa = 165 0 82
ff1605c09afa18aaaaaaaaaaaaaa bcfa28 aaaaaaaaaaaaaaaa [16,5 82]  : bcfa28^aaaaaa = 165 0 82
ace805c09afa18aaaaaaaaaaaaaa bcea28 aaaaaaaaaaaaaaaa [16,4 82]  : bcea28^aaaaaa = 164 0 82
205705c09aca18aaaaaaaaaaaaaa bcfa2a aaaaaaaaaaaaaaaa [16,5 80]  : bcfa2a^aaaaaa = 165 0 80
ff1605c09afa18aaaaaaaaaaaaaa bcfa28 aaaaaaaaaaaaaaaa [16,5 82]  : bcfa28^aaaaaa = 165 0 82
7cc405c09aca18aaaaaaaaaaaaaa bcea2e aaaaaaaaaaaaaaaa [16,4 84]  : bcea2e^aaaaaa = 164 0 84
a00705c09baa18aaaaaaaaaaaaaa bcea2b aaaaaaaaaaaaaaaa [16,4 81]  : bcea2b^aaaaaa = 164 0 81
zuckschwerdt commented 4 years ago

Your big table of values and readings was great help for this satisfying finding, thanks!

I would have said "encryption" at first, but actually it make sense: If you use PCM and expect long runs of 0's you are in trouble with timings. Using a pseudo-whitening of 0xaa is the easiest trick to get around that.

@merbanan @evilpete I have not seen this before but it might be a trick used in other protocols where we suscpect some encryption. Worth remembering and trying out!

I'll add a whitening feature for this to BitBench so we can check easily :)

Tuxyso commented 4 years ago

Stunning, great work!

If you give me a handy way to decode the signals I can also help to identify the other data fields, like (wind speed, wind direction, rain values, light intensity) from the outdoor sensor.

zuckschwerdt commented 4 years ago

I've now added the xor /whitening to BitBench. Take a look in this BitBench.

Just add codes in the first text box (green text) and then modify the string in the second text box. All uppercase letters will appear in the output, number and lowercase letters select some decoding.

Tuxyso commented 4 years ago

From the recorded values I could figure out some other data fields:

8h8h ID?8h8h WIND-DIR:8h4h.4h° 8h8h WIND-SPEED:8h8h 8h8h 8h8h TEMP:8h.4hC 4h HUM:8h% LIGHT:8h8hW/m² CHK?8h 8h 8h8h8h8h

WIND-DIR is 100% sure / WIND-SPEED I am not sure about the unit here; LIGHT in W/m² is 95% sure (fits to the data I have recorded during the day), I think the fields after WIND-SPEED have to do with rain (currently I cannot verify it due to missing rain)

With this decoding I get for example:

image

Pressure is still missing :-(

evilpete commented 4 years ago

@merbanan @evilpete I have not seen this before but it might be a trick used in other protocols where we suscpect some encryption. Worth remembering and trying out!

Insteon devices pad between packets with 001100110011,

Tuxyso commented 4 years ago

I could further improve decoding, see Bitbench: CHK:8h8h ID?8h8h WDIR:8h4h° 4h 8h WGUST:8h.4h WAVG:8h.4h RAIN?8h8h RAIN?8h8h TEMP:8h.4hC 4h HUM:8h% LIGHT:8h4h,4hKL ?:8h8h4h TRAILER:8h8h8h4h

Unit of light is kLux (not W/m²).

Any ideas on pressure? I have absolutely no clue.

Edit: updated your BitBench

zuckschwerdt commented 4 years ago

I guess I found the checksum: The first two bytes are an LFSR-16 digest, generator 0x8810 with the next two bytes (ID) as init.

Usually barometric pressure is measured indoors in the display unit. There would be no difference to a remote sensor reading (apart from height offset).

I'll write a decoder for this in the next days.

zuckschwerdt commented 4 years ago

There is some early test code in https://github.com/merbanan/rtl_433/tree/feat-bresser7in1 now. The checksum (likely digest) needs more work -- we really need that to validate the packets. Can you grab a good number of unique codes (say 50-100)? Either the raw bitbuffer codes like before, or the preamble-aligned msg from this branch or the xor'd ones, doesn't matter.

Tuxyso commented 4 years ago

I've recorded 85 unique checksums (see attachment). Do you need a similiar sample for the indoor sensor?

Preview: I've just ordered the

https://www.bresser.de/en/Weather-Time/Accessories/EXPLORE-SCIENTIFIC-Soil-Moisture-and-Soil-Temperature-Sensor.html

Soil-Moisture-and-Soil-Temperature-Sensor. I will provide sample data as soon as possible.

Still waiting for rain in a view days :)

There is some early test code in https://github.com/merbanan/rtl_433/tree/feat-bresser7in1 now.

Can I already compile & test the code?

outdoor_sensor_checksum.txt

zuckschwerdt commented 4 years ago

There is a working checksum for the tabled codes: LFSR-16 digest, generator 0x8810 key 0xba95 final xor 0x6df1. That final xor is strange, and I can't say if the key is fixed for all units or specific to yours and negotiated when pairing.

Can you also get codes for the indoor sensor? Then checksum should be something similar and might give more insight.

The test branch doesn't do much, but works:

model     : Bresser-7in1outdoor                    id        : 44906
Temperature: 20.7 C      Humidity  : 61            Wind Gust : 1.0 m/s       Wind Speed: 1.0 m/s
       Direction : 343 °        Light     : 65.5 klx
Tuxyso commented 4 years ago

I've recorded 39 samples (see attached file). During recording I changed the channel so you can check a possible effect on checksum calculation. Do not be confused about the changing temperature - I put the sensor into the fridge :)

indoor-sensor-checksum.txt

Tuxyso commented 4 years ago

Just another remark. Negative temperature are as follows for the indoor sensor: codes : {242}ac04197005fd290000000000 996e30000014000001c000000000000000000 [-0,4°] codes : {240}736e197005fd290000000000 983e30000045ffff07000000000000000000 [-1,7 30%] codes : {240}4f3b197005fd290000000000 977e31000005ffff07000000000000000000 [-2,3 31%] codes : {240}16e9197005fd290000000000971e31000065ffff07000000000000000000 [-2,9 31%] codes : {240}fecd197005fd290000000000966e31000016000007000000000000000000 [-3,4 31 % ] codes : {242}902f197005fd290000000000960e30000077ffffc1c000000000000000000 [-4 30 % ]

It seems that negative temperature begin at 99.. There is also an effect on humidity encoding if the temperature is negative

zuckschwerdt commented 4 years ago

Here is a BitBench of the Indoor sensor with all the temperatures. Looks like the bit after the Temp could flag a negative temperature, but we can also assume e.g. if temp > 70 then temp = temp - 100. Humidity seems okay?

zuckschwerdt commented 4 years ago

Just to note it here: the checksum at the end is an 8-bit wide add (with carry). For the indoor message this means skip two bytes (digest), sum 16 bytes to 0xff. This should also signal the end of the message as a checksum is usually the last field.

zuckschwerdt commented 4 years ago

For the indoor sensor the digest is gen 0x8810 key 0x5412 over the bytes excluding the add-checksum :)

Tuxyso commented 4 years ago

Humidity seems okay?

As far as I remeber the these values are the correct humidity values.

I've just purchased Soil moisture Sensor SM60020 for the weather station, see:

https://www.bresser.de/en/Weather-Time/Accessories/EXPLORE-SCIENTIFIC-Soil-Moisture-and-Soil-Temperature-Sensor.html

Bresser Explore Scientific SM60020.

The sensor sends every 5 minutes signals to the basis. I've recorded some data and tried decoding in Bitbench. Channel and temp are easy, don't know how humidity in encoded. Any ideas?

zuckschwerdt commented 4 years ago

The moisture seems to be in (maybe non-linear) increments, change HUM?:12h to 4h HUM:8d and see if you can table more values.

Tuxyso commented 4 years ago

I think we have the solution. According to the manual there are 16 data points:

image

16 - 99 % 15 - 93 % 13 - 80 % 02 - 7 % 01 - 0 %

Tuxyso commented 4 years ago

Rain today 👍 I have analysed the rain encoding of the outdoor sensor, see Bitbench

I was really surprised: The outdoor sensor only transmits the total amount of weekly measured rain in mm. From this metric every other metrics are calculated, also the rain rate in mm per hour. In combination with the timestamp you can calculate the rain rate in mm/h - but due to the kind of measurement this value is very slowly and time-delayed. I could verify this value by comparision with the RAIN per week value at my basis.

Example:

image

The meaning of one field is still unknows (denoted as RAIN? after RAIN-WEEKLY) in the image above. Any ideas?

zuckschwerdt commented 4 years ago

This is expected. The rain measure from weather station sensors is always an accumulated value. The display unit keeps time and derives all the "per x" values. Not sure about that extra field, more digits for the accumulated rain count don't seem plausible.

zuckschwerdt commented 4 years ago

I've merge this with the 6-in-1 and new 5-in-1 changes, the branch is now in #1225. I'll add the moisture support soon.

zuckschwerdt commented 4 years ago

Actually the indoor sensor is a 6-in-1. I've updated the code to reflect that. We still need to find out how the fields are flagged as valid/invalid as the sensors seem to come with different options.

Tuxyso commented 4 years ago

I've tested the new branch _rtl433 version 20.02-173-g46680b7 branch feat-bresser6in1 at 202009281822 and can give the following feedback:

I got some checksum failures. I am not sure if it works as designed (due to a weak signal) of if it is an error in the code (see complete debug information in the attached file:

checksum_errors.txt

Example:

MSG: {200} ac 51 19 70 05 fd 29 00 00 00 00 00 22 26 56 00 00 ad ff ff c1 c0 00 00 00 XOR: {200} 06 fb b3 da af 57 83 aa aa aa aa aa 88 8c fc aa aa 07 55 55 6b 6a aa aa aa bresser_7in1_decode: Digest check failed 06fb vs 0df9 (0b02)

Another point: I think the naming for the indoor sensor ("Bresser-6in1") in the output ist confusing. Example:

time : 2020-09-28 23:20:27 model : Bresser-6in1 id : 426771965 channel : 1 Battery : 0 Temperature: 22.3 C Humidity : 56 UV : 0.0 Flags : 2 Integrity : CRC

We are talking about this sensor:

https://www.bresser.de/en/Weather-Time/BRESSER-Thermo-Hygro-Sensor-7-Channel-868-MHz.html

UV fied seems strange. I prefer a more neutral / generic naming because the sensor is compatible to 3 different weather stations:

Suitable for the following BRESSER weather stations: 7002540000000, 7002560, 7002580

What about "Bresser-Thermo-Hygro-7CH-Sensor" ?

zuckschwerdt commented 4 years ago

Thanks for debugging. The digest fails in the (outdoor) 7-in-1 decoder because the packet is a 6-in-1. A 7-in-1 packet has lots of 0xaa and should contain 0x00 after xor, not like here:

MSG: {200} 80 c6 19 70 05 fd 29 00 00 00 00 00 22 36 57 00 00 9c 00 00 01 c0 00 00 00 
XOR: {200} 2a 6c b3 da af 57 83 aa aa aa aa aa 88 9c fd aa aa 36 aa aa ab 6a aa aa aa 
bresser_7in1_decode: Digest check failed 2a6c vs 6bd9 (41b5)

Basically both are very similar 6-in-1 18 bytes and 7-in-1 21 (maybe 25) bytes, but the trailer (a long lead-out FSK "space") will give us as many bytes as we want. We thus need to try the digest to find out.

About the name: the data is just 18 bytes of DIGEST:8h8h ID?8h8h8h8h FLAGS:4h BATT:1b CH:3d WSPEED:~8h~4h ~4h~8h WDIR:12h ?4h TEMP8h.4h ?4h HUM8h UV?~12h ?4h CHKSUM:8h I'm currently not sure if/how we can determine if the sender is an indoor sensor or a weather station. There could be some feature or model indication in the id (3rd to 6th byte)? I guess I'll split the id out and hopefully a good number of users can report what we have?

zuckschwerdt commented 4 years ago

It looks like flags is 4 for your moisture sensor and 1 on all other sensors? Otherwise it looks like any other 6-in-1 packet.

Tuxyso commented 4 years ago

Do you need further debug data? Please let me know.

zuckschwerdt commented 4 years ago

Is flags always 4 for your soil moisture sensor and 1 for everything else? Possibly be the only field with a type indication.

Tuxyso commented 4 years ago

Here you find sample data for further analysis (including indoor, outdoor and soil moisture sensor).

sample-data.txt

Tuxyso commented 4 years ago

Rain is not shown in current Git version:

` MSG: {200} d5 a7 05 c0 88 2a 18 aa aa aa aa af a2 aa bb da 32 aa 8e ff aa aa aa aa aa XOR: {200} 7f 0d af 6a 22 80 b2 00 00 00 00 05 08 00 11 70 98 00 24 55 00 00 00 00 00

time : 2020-10-03 15:51:40 model : Bresser-7in1 id : 44906 Temperature: 11.7 C Humidity : 98 Wind Gust : 0.0 m/s Wind Speed: 0.0 m/s Direction : 228 Rain : 0.0 mm Light : 2.4 klx Integrity : CRC `

Should be 50,8 for first entry. Is corretly shown in latest Bitbench

zuckschwerdt commented 4 years ago

Thanks, fixed.