Lux and UV incorrect for Cotech 36-7959 #2073

biuklija · 2022-05-17T17:51:05Z

UV and light_lux were added for Cotech 36-7959 in commit 7f14007 , but light_lux is not decoded correctly. Maximum decoded light_lux value in decoded samples is always 69627 and I'm getting the same value although the console itself properly displays higher values and the value should go up to 200.000.

zuckschwerdt · 2022-05-17T18:30:04Z

It was added from #1575 with 67ee1d6 and is 16 (or 17?) bit, noted to reach 200.000? https://github.com/merbanan/rtl_433/blob/master/src/devices/cotech_36_7959.c#L42
This looks strange

    int flags     = (b[7] & 0xf0) >> 4;                           // [56:4]
    int light_lux = (b[10] << 8) + b[11] + ((flags & 0x08) << 9); // [80:16]

So top bit of b[7] goes to bit 12? I guess it should be 16, i.e.

    int light_lux = (b[10] << 8) | b[11] | ((b[7] & 0x80) << 9); // [56:1][80:16]

Can you modify your source code, recompile and test?

@andrewpile can you double-check that line?

biuklija · 2022-05-17T19:38:12Z

Recompiled, will test and report back tomorrow when the sun comes up to see how it behaves. I've tried some test samples, but they don't look promising. While one of my samples does decode over 69627 (77661 to be exact), all my other samples had lower values and all the samples in rtl_433_tests now decode as 131067 instead of 69627, which is suspicious.

Additionally, it seems that UV index is scaled by 10 so it might be a good idea to map it as a float, but I'll test this out as well.

andrewpile · 2022-05-17T20:55:29Z

It's been a long time since I looked at this, but the origins of this code were always a little suspicious and undocumented, so I suspect it needs more research.

biuklija · 2022-05-18T10:56:59Z

As expected, lux values are now capped at 131069, all those below are properly decoded.

time      : 2022-05-18 12:41:48
model     : Cotech-367959 ID        : 28
Battery   : 1            Temperature: 66.6 F       Humidity  : 45 %          Rain      : 9.3 mm        Wind direction: 85        Wind      : 2.0 m/s       Gust      : 3.0 m/s       Light Intensity: 78155 lux
UV Index  : 4.0          Integrity : CRC

time      : 2022-05-18 12:42:52
model     : Cotech-367959 ID        : 28
Battery   : 1            Temperature: 67.1 F       Humidity  : 45 %          Rain      : 9.3 mm        Wind direction: 82        Wind      : 1.8 m/s       Gust      : 2.3 m/s       Light Intensity: 131069 lux
UV Index  : 6.9          Integrity : CRC

The lux value is not a 16-bit integer. We do have a few spare bits of unknown purpose (block J), could they belong here? My knowledge of C and bitwise operation is limited, how would I go about testing this?

merbanan · 2022-05-18T11:00:13Z

Record some samples and their corresponding reading from the official receiver. Then we can look for what bits belong to what value.

zuckschwerdt · 2022-05-18T11:04:46Z

Even better add decoder_log_bitrow(decoder, 0, __func__, b, sizeof(b) * 8, "bitrow"); at https://github.com/merbanan/rtl_433/blob/master/src/devices/cotech_36_7959.c#L85 (the line before // Extract data from buffer), recompile and run.
Note the decoded rows you get and the light values you expect.

biuklija · 2022-05-18T11:16:33Z

The console displays higher values as klux, the following samples should be either 164.4 klux or 164.9 klux (although I'm not absolutely certain about the last one).

cotech_36_7959_decode: bitrow: {112} c1 c0 0c 11 5a 00 5d 84 37 2c ff fd 45 b2 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
time      : @0.324652s
model     : Cotech-367959 ID        : 28
Battery   : 1            Temperature: 67.9 F       Humidity  : 44 %          Rain      : 9.3 mm        Wind direction: 90        Wind      : 1.2 m/s       Gust      : 1.7 m/s       Light Intensity: 131069 lux
UV Index  : 6.9          Integrity : CRC

cotech_36_7959_decode: bitrow: {112} c1 c0 04 07 20 00 5d 84 3a 2d ff fd 45 e6 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
time      : @0.193760s
model     : Cotech-367959 ID        : 28
Battery   : 1            Temperature: 68.2 F       Humidity  : 45 %          Rain      : 9.3 mm        Wind direction: 32        Wind      : 0.4 m/s       Gust      : 0.7 m/s       Light Intensity: 131069 lux
UV Index  : 6.9          Integrity : CRC

cotech_36_7959_decode: bitrow: {112} c1 c4 08 0a 37 00 5d 84 3d 2b ff fd 44 c7 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
time      : @0.325144s
model     : Cotech-367959 ID        : 28
Battery   : 1            Temperature: 68.5 F       Humidity  : 43 %          Rain      : 9.3 mm        Wind direction: 311       Wind      : 0.8 m/s       Gust      : 1.0 m/s       Light Intensity: 131069 lux
UV Index  : 6.8          Integrity : CRC

biuklija · 2022-05-18T11:41:07Z

Before I forget, the UV value is indeed scaled by 10, ranges from 0 to 150, so it should be formatted as a float to avoid confusion (to prevent UV 0.9 being interpreted as UV 9). The original display console rounds this value up and only displays 0-15.

zuckschwerdt · 2022-05-18T12:09:41Z

The value of ff fd (b[10] b[11]) does look more like an error code than a reading.
Can you grab values over a wider range and paste lines this here?

{112} c1 c0 0c 11 5a 00 5d 84 37 2c ff fd 45 b2 : 164.4 klux or 164.9 klux

biuklija · 2022-05-18T14:03:34Z

I'll see what I can do, might take a while because they have to be in a precise range. I have a bunch of eligible samples, but not their expected values.

biuklija · 2022-05-18T14:55:49Z

Here's a few I managed to force with a flashlight, they're the best I can do today.

{112} c1 c0 0c 14 12 00 5d 84 47 1f ff fd 22 8b : probably 147.7 klux
{112} c1 c0 1c 21 3d 00 5d 84 48 1e ff fd 1f 3c : probably 146.2 klux
{112} c1 c0 16 21 48 00 5d 84 48 1e ff fd 1f 10 : possibly 146.2 klux

{112} c1 c0 0d 11 8b 00 5d 84 48 1d ff fd 1b 66 : 144.2 klux
{112} c1 c0 02 03 4a 00 5d 84 4a 1e ff fd 20 df : 146.7 klux
{112} c1 c0 00 03 69 00 5d 84 4c 1e ff fd 18 7d : 142.8 klux
{112} c1 c4 07 14 3d 00 5d 84 4d 1d ff fd 13 80 : 140.3 klux
{112} c1 c4 13 17 32 00 5d 84 4e 1d ff fd 12 9a : 139.8 klux
{112} c1 c4 0f 14 39 00 5d 84 4c 1d ff fd 1e 0e : 145.7 klux
{112} c1 c0 09 0d 04 00 5d 84 4d 1e ff fd 19 f0 : 143.3 klux

biuklija · 2022-05-18T15:06:04Z

If you need values that properly decode across the entire range, I have plenty of that.

{112} c1 c0 16 1e 6e 00 5d 84 29 2c e8 ba 37 1b : 124812 lux
{112} c1 c0 1a 28 5c 00 5d 84 24 2c e8 4d 32 43 : 125005 lux
{112} c1 c0 1f 28 47 00 5d 84 22 2c fc ce 2f 63 : 130254 lux
{112} c1 c0 14 21 45 00 5d 84 16 3d 22 75 1a 0b : 74357 lux
{112} c1 c0 07 0d 2c 00 5d 84 13 3d 17 b5 14 60 : 71605 lux
{112} c1 c0 19 2b 44 00 5d 84 11 3d 01 3c 14 2f : 65852 lux

zuckschwerdt · 2022-05-18T15:18:17Z

Oh, those all have ff fd in the bytes we expect the light value to be in.
Here is a BitBench with the codes. I don't see where the light value might be? It just seems to be "overflow".

biuklija · 2022-05-18T15:28:49Z

If it's overflowing, there's a chance that the light value is broadcast in a different message?

biuklija · 2022-05-18T18:45:25Z

Am I completely misreading this or is there a different package before the main one which we decode?
rtl_433 -X "n=Cotech-TEST,m=OOK_MC_ZEROBIT,s=488,l=0,r=988" -Y minsnr=20 -S all

time      : 2022-05-18 20:33:48
model     : Cotech-TEST  count     : 1             num_rows  : 1             rows      : 
len       : 127          data      : 0029838000006600ba07e04600960080
codes     : {127}0029838000006600ba07e04600960080
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
time      : 2022-05-18 20:33:48
model     : Cotech-TEST  count     : 1             num_rows  : 1             rows      : 
len       : 128          data      : 0014c1c0000033005d03f023004b0040
codes     : {128}0014c1c0000033005d03f023004b0040
cotech_36_7959_decode: bitrow: {112} c1 c0 00 00 33 00 5d 03 f0 23 00 4b 00 40 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
time      : 2022-05-18 20:33:48
model     : Cotech-367959 ID        : 28
Battery   : 1            Temperature: 60.8 F       Humidity  : 35 %          Rain      : 9.3 mm        Wind direction: 51        Wind      : 0.0 m/s       Gust      : 0.0 m/s       Light Intensity: 75 lux
UV Index  : 0.0          Integrity : CRC
cotech_36_7959_decode: bitrow: {112} c1 c0 00 00 33 00 5d 03 f0 23 00 4b 00 40 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
time      : 2022-05-18 20:33:48
model     : Cotech-367959 ID        : 28
Battery   : 1            Temperature: 60.8 F       Humidity  : 35 %          Rain      : 9.3 mm        Wind direction: 51        Wind      : 0.0 m/s       Gust      : 0.0 m/s       Light Intensity: 75 lux
UV Index  : 0.0          Integrity : CRC

*** Saving signal to file g001_433.92M_250k.cu8 (99015 samples, 262144 bytes)

zuckschwerdt · 2022-05-18T19:05:16Z

Yes, in the spectrogram (https://triq.org/pdv/) and looking at the data it very much looks like a proper transmission. And it's already a valid Manchester decode.
Can you capture more of those?

zuckschwerdt · 2022-05-18T19:07:17Z

Oh and the original author of the decoder knew that too ;) https://github.com/merbanan/rtl_433/blob/master/src/devices/cotech_36_7959.c#L57-L62

biuklija · 2022-05-18T19:26:08Z

Yes, in the spectrogram (https://triq.org/pdv/) and looking at the data it very much looks like a proper transmission. And it's already a valid Manchester decode. Can you capture more of those?

Not a problem capturing them, I have them from my tests above (when light_lux goes into overflow).
I have a sneaking suspicion that this package might also contain the watts per square metre because the display console can display both. I initially thought that it just approximated the w/m² value from the illumination using a fixed conversion factor, but the conversion factor varied between readings.

biuklija · 2022-05-18T19:29:08Z

Here's that batch, in transmission order, along with the expected values of klux.

{127}002983801a231600bb08903bfffa36cc
{112} c1 c0 0d 11 8b 00 5d 84 48 1d ff fd 1b 66 : 144.2 klux

{127}0029838004069400bb08943dfffa41be
{112} c1 c0 02 03 4a 00 5d 84 4a 1e ff fd 20 df : 146.7 klux

{127}002983800006d200bb08983dfffa30fa
{112} c1 c0 00 03 69 00 5d 84 4c 1e ff fd 18 7d : 142.8 klux

{127}00298388262e6400bb089c3bfffa2534
{112} c1 c4 13 17 32 00 5d 84 4e 1d ff fd 12 9a : 139.8 klux

{127}002983881e287200bb08983bfffa3c1c
{112} c1 c4 0f 14 39 00 5d 84 4c 1d ff fd 1e 0e : 145.7 klux

{127}00298380121a0800bb089a3dfffa33e0
{112} c1 c0 09 0d 04 00 5d 84 4d 1e ff fd 19 f0 : 143.3 klux

EDIT: corrected second value.

zuckschwerdt · 2022-05-19T06:47:26Z

Sorry, false alarm. Those are identical packets, just shifted one bit. I should have checked that first.
So no second transmission. Only the ff fd you see on overflow.

biuklija · 2022-05-19T10:09:34Z

Okay, how about this? On every other (unrepeated) package, I get the 25-28 extra rows:

Detected OOK package	2022-05-19 12:04:13
cotech_36_7959_decode: bitrow: {112} c1 c0 07 0a 5a 00 5d 84 51 1d ff fd 2c d7 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
time      : 2022-05-19 12:04:13
model     : Cotech-367959 ID        : 28
Battery   : 1            Temperature: 70.5 F       Humidity  : 29 %          Rain      : 9.3 mm        Wind direction: 90        Wind      : 0.7 m/s       Gust      : 1.0 m/s       Light Intensity: 131069 lux
UV Index  : 4.4          Integrity : CRC
Analyzing pulses...
Total count:  102,  width: 123.55 ms		(30887 S)
Pulse width distribution:
 [ 0] count:   77,  width:  504 us [472;532]	( 126 S)
 [ 1] count:   25,  width:  992 us [984;1000]	( 248 S)
Gap width distribution:
 [ 0] count:   76,  width:  472 us [448;496]	( 118 S)
 [ 1] count:   25,  width:  956 us [948;964]	( 239 S)
Pulse period distribution:
 [ 0] count:   65,  width:  976 us [964;992]	( 244 S)
 [ 1] count:   22,  width: 1464 us [1444;1488]	( 366 S)
 [ 2] count:   14,  width: 1948 us [1944;1956]	( 487 S)
Pulse timing distribution:
 [ 0] count:  153,  width:  488 us [448;532]	( 122 S)
 [ 1] count:   50,  width:  972 us [948;1000]	( 243 S)
 [ 2] count:    1,  width: 10004 us [10004;10004]	(2501 S)
Level estimates [high, low]:  15956,    671
RSSI: -0.1 dB SNR: 13.8 dB Noise: -13.9 dB
Frequency offsets [F1, F2]:   -1676,      0	(-6.4 kHz, +0.0 kHz)
Guessing modulation: Manchester coding
view at https://triq.org/pdv/#AAB10301E803CC271480808080808080808191918090818080808090808180808080808080808080908081808080919180919081918080808080808080809190808190818080809180809191808091808090808190808080808080808080808080808191809190818090819190808255
Attempting demodulation... short_width: 504, long_width: 0, reset_limit: 968, sync_width: 0
Use a flex decoder with -X 'n=name,m=OOK_MC_ZEROBIT,s=504,l=0,r=968'
pulse_slicer_manchester_zerobit(): Analyzer Device
bitbuffer:: Number of rows: 1 
[00] {127} 00 29 83 80 0e 14 b4 00 bb 08 a2 3b ff fa 59 ae 

*** signal_start = 6390574, signal_end = 6441455, signal_len = 50881, pulses_found = 102
Iteration 1. t: 178    min: 117 (77)    max: 239 (25)    delta 65
Iteration 2. t: 178    min: 117 (77)    max: 239 (25)    delta 0
Pulse coding: Short pulse length 117 - Long pulse length 239

Short distance: 122, long distance: 130, packet distance: 248

p_limit: 178
bitbuffer:: Number of rows: 26 
[00] { 9} 00 00     : 00000000 0
[01] { 1} 80        : 1
[02] { 1} 80        : 1
[03] { 3} 40        : 010
[04] { 7} 08        : 0000100
[05] {13} 00 20     : 00000000 00100
[06] { 4} 10        : 0001
[07] { 1} 80        : 1
[08] { 2} 40        : 01
[09] { 2} 80        : 10
[10] { 1} 80        : 1
[11] {10} 00 40     : 00000000 01
[12] { 3} 80        : 100
[13] { 2} 80        : 10
[14] { 4} 10        : 0001
[15] { 3} 20        : 001
[16] { 1} 80        : 1
[17] { 3} 20        : 001
[18] { 5} 20        : 00100
[19] {15} 80 00     : 10000000 0000000
[20] { 1} 80        : 1
[21] { 2} 40        : 01
[22] { 2} 80        : 10
[23] { 3} 40        : 010
[24] { 1} 80        : 1
[25] { 3} 80        : 100

*** Saving signal to file g013_433.92M_250k.cu8 (66156 samples, 262144 bytes)

biuklija · 2022-05-19T11:58:51Z

Ignore, it's just a wrong guess by the analyzer. This is getting really weird. The data has to be somewhere in the package because it gets regularly updated every 15 seconds along with all other data.

anthyz · 2022-05-19T23:42:14Z

klux is derived from the UV value. I played around with it a bit and found that the formula (131000 + (UV * 491) ) / 1000 gets the same klux values as reported (after rounding). The constants could be further tuned or confirmed with values closer to the point of lux overflow.

gdt · 2022-05-20T00:20:08Z

It's certainly good to extract what the official receiver sees. This rant is slightly off (illuminance vs irradiance, rather than illuminance vs UV index), but might be useful in understanding that converting UV to lux is an unsound hack, even if equipment manufacturers are willing to do it.

https://github.com/weewx/weewx/wiki/Watts-and-lux

anthyz · 2022-05-20T04:19:46Z

Interesting! Yeah, it’s likely a hack, but personally knowing nothing about the properties of the sensors I’d want more data before deciding how bad of a hack it is. It would be interesting to see how a camera lens UV filter in front of the sensors affected the readings.

biuklija · 2022-05-20T05:11:49Z

I'll test this out, I should have an UV filter somewhere.

It's certainly good to extract what the official receiver sees. This rant is slightly off (illuminance vs irradiance, rather than illuminance vs UV index), but might be useful in understanding that converting UV to lux is an unsound hack, even if equipment manufacturers are willing to do it.

As far as I can see, there's actually just the UV sensor in the window on the integrated sensor unit and, to be fair, the manufacturer does specify in the manual that the accuracy and resolution for UV index are ±1, while "sunlight" has ±15% accuracy and resolution.

Additionally, this would explain why I was unable to establish a fixed conversion factor between w/m² and lux. Rounding errors.

biuklija · 2022-05-20T06:16:59Z

In any case, what would be our best course of action in regards to RTL_433?
Should it just report the (likely derived) lux value until it overflows and stop reporting it while it's capped, with a note somewhere in the documentation that it's derived and how to do so, thus letting the end-recipient of the data (weewx, for example) deal with approximations upwards from 131 klux?
I don't think we should ignore this value altogether because it's bound to raise issues in the future, but we also can't let it report "capped" values.
Is there an official stance for situations such as this?

merbanan · 2022-05-20T06:32:57Z

Matching the official receiver is fine, unless it does really strange things.

merbanan · 2022-05-20T06:39:07Z

But do I get it right that when the sensor maxes out it just makes up values together with the UV index ?

clau-bucur · 2024-04-22T12:19:38Z

Seems to still be problematic. I have a NicetyMeter 0310 which send LUX and UV but the values read by rtl_433 do not match the values on the display.

zuckschwerdt · 2024-04-22T13:08:03Z

I think we did confirm that the 17th bit is the top most of the flags (b[7]), i.e. we should change to this

    int light_lux = (b[10] << 8) | b[11] | ((b[7] & 0x80) << 9); // [56:1][80:16]

And we know that the reading tops out at maybe 1FFFC = 131068 and 1 ff fd = 131069 indicates an overflow.

And maybe we could use anthyz' formula (131000 + (UV * 491) ) / 1000 to fake values after that from the UV reading.

Is that summary correct?

clau-bucur · 2024-04-23T09:54:58Z

I myself can't answer because I don't really understand the code.
But I can run tests if needed, just let me know what shall I do.

zuckschwerdt · 2024-04-23T10:13:51Z

Can you run rtl_433 -R 153:v when Lux values are lower than 65535 and post some codes you see?
E.g.

codes     : {127}00298380121a0800bb089a3dfffa33e0

clau-bucur · 2024-04-23T11:18:41Z

Can you run rtl_433 -R 153:v when Lux values are lower than 65535 and post some codes you see?

Values reported by rtl_443 or shown on the weather station tablet itself? (on the tablet currently I have 78.0k lux)

zuckschwerdt · 2024-04-23T11:40:56Z

Just any low value to confirm and document the 17th bit. No need for any exact value.

clau-bucur · 2024-04-23T11:47:40Z

Here's a small list of readings:

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2024-04-23 13:49:01
model     : Cotech-367959 ID        : 90
Battery   : 1            Temperature: 62.6 F       Humidity  : 48 %          Rain      : 86.1 mm       Wind direction: 80        Wind      : 2.4 m/s       Gust      : 3.6 m/s       Integrity : CRC
[pulse_slicer_manchester_zerobit] Cotech 36-7959, SwitchDocLabs FT020T wireless weather station with USB
codes     : {127}00298b403048a006bb080461b374a49e
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2024-04-23 13:49:01
model     : Cotech-367959 ID        : 90
Battery   : 1            Temperature: 62.6 F       Humidity  : 48 %          Rain      : 86.1 mm       Wind direction: 80        Wind      : 2.4 m/s       Gust      : 3.6 m/s       Integrity : CRC
[pulse_slicer_manchester_zerobit] Cotech 36-7959, SwitchDocLabs FT020T wireless weather station with USB
codes     : {128}0014c5a0182450035d840230d9ba524f
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2024-04-23 13:49:17
model     : Cotech-367959 ID        : 90
Battery   : 1            Temperature: 62.5 F       Humidity  : 47 %          Rain      : 86.1 mm       Wind direction: 77        Wind      : 3.8 m/s       Gust      : 4.6 m/s       Integrity : CRC
[pulse_slicer_manchester_zerobit] Cotech 36-7959, SwitchDocLabs FT020T wireless weather station with USB
codes     : {127}00298b404c5c9a06bb08025fb662a070
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2024-04-23 13:49:33
model     : Cotech-367959 ID        : 90
Battery   : 1            Temperature: 62.6 F       Humidity  : 47 %          Rain      : 86.1 mm       Wind direction: 94        Wind      : 2.2 m/s       Gust      : 3.0 m/s       Integrity : CRC
[pulse_slicer_manchester_zerobit] Cotech 36-7959, SwitchDocLabs FT020T wireless weather station with USB
codes     : {127}00298b402c3cbc06bb08045f5ef098ee
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2024-04-23 13:49:33
model     : Cotech-367959 ID        : 90
Battery   : 1            Temperature: 62.6 F       Humidity  : 47 %          Rain      : 86.1 mm       Wind direction: 94        Wind      : 2.2 m/s       Gust      : 3.0 m/s       Integrity : CRC
[pulse_slicer_manchester_zerobit] Cotech 36-7959, SwitchDocLabs FT020T wireless weather station with USB
codes     : {128}0014c5a0161e5e035d84022faf784c77
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2024-04-23 13:49:49
model     : Cotech-367959 ID        : 90
Battery   : 1            Temperature: 62.7 F       Humidity  : 48 %          Rain      : 86.1 mm       Wind direction: 65        Wind      : 1.5 m/s       Gust      : 2.0 m/s       Integrity : CRC
[pulse_slicer_manchester_zerobit] Cotech 36-7959, SwitchDocLabs FT020T wireless weather station with USB
codes     : {127}00298b401e288206bb080661fffaad5e
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2024-04-23 13:50:05
model     : Cotech-367959 ID        : 90
Battery   : 1            Temperature: 63.0 F       Humidity  : 47 %          Rain      : 86.1 mm       Wind direction: 96        Wind      : 2.5 m/s       Gust      : 3.3 m/s       Integrity : CRC
[pulse_slicer_manchester_zerobit] Cotech 36-7959, SwitchDocLabs FT020T wireless weather station with USB
codes     : {127}00298b403242c006bb080c5ff86aa94c
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2024-04-23 13:50:05
model     : Cotech-367959 ID        : 90
Battery   : 1            Temperature: 63.0 F       Humidity  : 47 %          Rain      : 86.1 mm       Wind direction: 96        Wind      : 2.5 m/s       Gust      : 3.3 m/s       Integrity : CRC
[pulse_slicer_manchester_zerobit] Cotech 36-7959, SwitchDocLabs FT020T wireless weather station with USB
codes     : {128}0014c5a0192160035d84062ffc3554a6
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2024-04-23 13:50:21
model     : Cotech-367959 ID        : 90
Battery   : 1            Temperature: 63.0 F       Humidity  : 47 %          Rain      : 86.1 mm       Wind direction: 58        Wind      : 3.0 m/s       Gust      : 4.0 m/s       Integrity : CRC
[pulse_slicer_manchester_zerobit] Cotech 36-7959, SwitchDocLabs FT020T wireless weather station with USB
codes     : {127}00298b403c507406bb080c5fbcc0a794
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
time      : 2024-04-23 13:50:37
model     : Cotech-367959 ID        : 90
Battery   : 1            Temperature: 63.2 F       Humidity  : 48 %          Rain      : 86.1 mm       Wind direction: 8         Wind      : 2.3 m/s       Gust      : 3.0 m/s       Integrity : CRC
[pulse_slicer_manchester_zerobit] Cotech 36-7959, SwitchDocLabs FT020T wireless weather station with USB
codes     : {127}00298b402e3c1006bb081061f2c6a85c

zuckschwerdt · 2024-04-23T13:42:34Z

Looks like the Light and UV values are flagged as invalid because the UV value is implausible.
Here is a BitBench with those codes (and older codes), are the light values plausible to you?

What about the UV values? Do those map to anything sensible?

If those are legit light values below 65535 then the TOPBITS field should show 0 not 8. Something is still wrong.

ProfBoc75 · 2024-04-23T15:43:27Z

@zuckschwerdt: this line is wrong

better to replace by:

int light_is_valid = (uv <= 150);

uv is scale 10 and from 0 to 15 so raw max uv is 150. Therefore, the final value must be also corrected and * 0.1f.

"uv",   "UV Index",  DATA_COND, light_is_valid, DATA_FORMAT, "%.1f uv", DATA_DOUBLE, uv * 0.1f,

ProfBoc75 · 2024-04-23T17:33:27Z

@clau-bucur:

With this formula for klux :

light_klux = 131 + (UV * 0.491)

I got this, is it correct ?

Code	Sync	klux	lux	uv
{127}00298b403048a006bb080461b374a49e	c5a0182450035d840230d9ba524f		121274	8.2
{128}0014c5a0182450035d840230d9ba524f	c5a0182450035d840230d9ba524f		121274	8.2
{127}00298b404c5c9a06bb08025fb662a070	c5a0262e4d035d84012fdb315038		121649	8.0
{127}00298b402c3cbc06bb08045f5ef098ee	c5a0161e5e035d84022faf784c77		110456	7.6
{128}0014c5a0161e5e035d84022faf784c77	c5a0161e5e035d84022faf784c77		110456	7.6
{127}00298b401e288206bb080661fffaad5e	c5a00f1441035d840330fffd56af	173.2		8.6
{127}00298b403242c006bb080c5ff86aa94c	c5a0192160035d84062ffc3554a6		130101	8.4
{128}0014c5a0192160035d84062ffc3554a6	c5a0192160035d84062ffc3554a6		130101	8.4
{127}00298b403c507406bb080c5fbcc0a794	c5a01e283a035d84062fde6053ca		122464	8.3
{127}00298b402e3c1006bb081061f2c6a85c	c5a0171e08035d840830f963542e		129379	8.4

Notice that the UV and Light values are still high here but aligned but did not help to find the 17th topbit / MSB.

But, from this older post here we have the confirmation of the TOPBIT is at b[7] & 0x80, here = 0 for Light = 75 lux & uv = 0 UVI, again aligned.

See last 2 lines in bitbench

So, I guess we have all information, just confirm the klux values based on the uv formula are more or less accurate, at least be same as on the weather station display.

More details about the error codes from this sensor that could be managed by rtl_433.

zuckschwerdt · 2024-04-23T17:54:04Z

Thanks! I somehow missed that info from biuklija. The n/a value in the examples we have seems to be 0xfb (and light n/a seems to be 0xfffb), so >150 is a good check. Checking the Light value by the UV with that formula is a neat trick!

The light and uv fix is now commited. But please confirm the table above is correct.

The error codes are very detailed, we should at least copy that to the docs.

zuckschwerdt · 2024-04-23T18:12:39Z

Instrument	Valid Range	Units	Errors	Errors Decimal	Bit Size	Formula
Temperature	-40 to 140.0F	F	0x7fa - invalid data	2042	12	(T-400)/10
			0x7fc - below minimum	2044
			0x7fd - above maximum	2045
Humidity	10-99	%rH	0x7a - invalid if temperature bad	122	8
Average Wind Speed	0.0-50.0	m/s	>500 (?)		9	AWS/10
Wind Gust	0.0-5.0	m/s	>500 (?)		9	WG/10
Wind Direction	0-359	degrees			9
Light	0-128K	lux	0x1fffa - invalid value	131066	17
			0x1fffb - no light	131067
			0x1fffd - above maximum	131069
UV Index	0-20.0	UV units	0xfa - invalid data	250	8	UV/10
			0xfb - No UV	251
			0xfd - Above Maximum	253
Rain	0-6553.5	mm	Rolls over at top?		16	Rain/10

clau-bucur · 2024-04-24T06:15:06Z

@clau-bucur:

With this formula for klux :
light_klux = 131 + (UV * 0.491) 
I got this, is it correct ?
...
So, I guess we have all information, just confirm the klux values based on the uv formula are more or less accurate, at least be same as on the weather station display.

I was not near the weather station display to check what readings it's showing there but I'll collect another set of readings these days when I can also see the display, and get back.

zuckschwerdt · 2024-04-24T07:23:39Z

Try to use a fresh version of rtl_433, the latest findings are already included now and values up to 131k should match perfectly.

clau-bucur · 2024-04-25T17:46:00Z

Thanks. Do I need to build one myself or can I find it somewhere already built?

zuckschwerdt · 2024-04-25T20:38:49Z

New builds should be available at https://github.com/merbanan/rtl_433/releases/tag/nightly in about 10-20 minutes.

clau-bucur · 2024-04-26T10:20:54Z

I've been running the nightly build since this morning.

The lux values are spot-on up to 131069lux. Seems that is the max value rtl_433 would report.
The tablet shows higher values though, I've seen values going over 164k on it. It's pretty cloudy today so only a few instances it happened.

The UV is a bit off too. Sometimes they match, but most of the time rtl_433 show a value lower by 1 than what the tablet shows.
I've collected a few readings:

  lux    rtl_433   tablet
28561 lx   2UV      3UV
30106 lx   2UV      3UV
30429 lx   2UV      3UV
32296 lx   2UV      3UV
61934 lx   3UV      4UV
65668 lx   3UV      4UV
42200 lx   3UV      4UV

Let me know if some more data is needed.

zuckschwerdt · 2024-04-26T10:24:41Z

The UV index from rtl_433 should be a float with one decimal digit. Is it maybe a rounding error?

clau-bucur · 2024-04-26T12:17:14Z

It's a rounding error indeed. rtl_433 reads the float value, however the MQTT auto-discovery add-on is doing the rounding:

{
  "name": "UV Index",
  "unit_of_measurement": "UV Index",
  "value_template": "{{ value|int }}",
  "state_class": "measurement",
  "state_topic": "rtl_433/NUC/devices/Cotech-367959/90/uv",
  }
}

zuckschwerdt · 2024-04-26T12:25:06Z

Ah, ok. That should be "value_template": "{{ value|float|round(1) }}",

clau-bucur · 2024-04-26T12:29:42Z

Do I open some separate ticket for it?

zuckschwerdt · 2024-04-26T12:52:36Z

I've just put that change in now with #2913

clau-bucur · 2024-04-26T13:06:42Z

Thanks alot!
What do you think about the lux values above 131069?
Shall I compile a list of readings when the tablet shows higher lux values?

zuckschwerdt · 2024-04-26T13:19:11Z

We have anthyz' formula (131000 + (UV * 491) ) / 1000 for that. We just need to decide if we want to output synthetic values not actually transmitted.

clau-bucur · 2024-04-26T13:44:36Z

I'd say it makese sense to have the same data as provided by the tablet too. So I'm for it.

gdt · 2024-06-02T18:46:47Z

Reading this, I think where we are (with several fixes landed!) is:

lux values up to 17 bits are decoded from packets and match the display
UV values match the display
we think there's a formula to (mis)computer lux from UV
when lux reading on display is > 131069 (why not 131071?), then lux value decoded is wrong
OP has not posted a recent table of display lux and rtl_433 lux, along with stray bits that aren't used in decoders

and therefore

we do know know where the next bit (bits?) is
we do not know if the full lux value is actuallyt transmitted, or if only 17 bits
we have not validated that for a large number of received samples when lux would be in range, the observed data matches the lux/uv formula
we might wish to consider code that says "if lux is far off from lux = uv2lux(uv), then set bits 18/19 based on this and use the low 17".

gremlin205 · 2024-06-14T18:13:09Z

I am intersted in the progress on this issue. I have one of these devices. I found this issue while searching for why my values for w/m2 from rtl_433, Cotech display, and what the Cotech display posts to wunderground.com are different. I can provide any additional information the team needs to solve this problem. I will read through the whole thread to see if I can proactively respond with the information the team requires to get to a solution.

zuckschwerdt transferred this issue from merbanan/rtl_433_tests May 17, 2022

zuckschwerdt added a commit that referenced this issue Apr 23, 2024

Fix Cotech-367959 lux and uv value (#2073)

8c7f214

zuckschwerdt mentioned this issue Apr 26, 2024

Change HA script power to energy and UV index to float #2913

Merged

gdt added the inactive issue is valid but no one is working on it label Jun 5, 2024

Lux and UV incorrect for Cotech 36-7959 #2073

Lux and UV incorrect for Cotech 36-7959 #2073

Comments

biuklija commented May 17, 2022

zuckschwerdt commented May 17, 2022

biuklija commented May 17, 2022 • edited Loading

andrewpile commented May 17, 2022

biuklija commented May 18, 2022

merbanan commented May 18, 2022

zuckschwerdt commented May 18, 2022

biuklija commented May 18, 2022 • edited Loading

biuklija commented May 18, 2022

zuckschwerdt commented May 18, 2022

biuklija commented May 18, 2022

biuklija commented May 18, 2022

biuklija commented May 18, 2022 • edited Loading

zuckschwerdt commented May 18, 2022 • edited Loading

biuklija commented May 18, 2022

biuklija commented May 18, 2022

zuckschwerdt commented May 18, 2022

zuckschwerdt commented May 18, 2022

biuklija commented May 18, 2022

biuklija commented May 18, 2022 • edited Loading

zuckschwerdt commented May 19, 2022

biuklija commented May 19, 2022

biuklija commented May 19, 2022

anthyz commented May 19, 2022

gdt commented May 20, 2022

anthyz commented May 20, 2022

biuklija commented May 20, 2022 • edited Loading

biuklija commented May 20, 2022

merbanan commented May 20, 2022

merbanan commented May 20, 2022

clau-bucur commented Apr 22, 2024

zuckschwerdt commented Apr 22, 2024

clau-bucur commented Apr 23, 2024

zuckschwerdt commented Apr 23, 2024

clau-bucur commented Apr 23, 2024 • edited Loading

zuckschwerdt commented Apr 23, 2024

clau-bucur commented Apr 23, 2024

zuckschwerdt commented Apr 23, 2024

ProfBoc75 commented Apr 23, 2024 • edited Loading

ProfBoc75 commented Apr 23, 2024

zuckschwerdt commented Apr 23, 2024

zuckschwerdt commented Apr 23, 2024 • edited Loading

clau-bucur commented Apr 24, 2024

zuckschwerdt commented Apr 24, 2024

clau-bucur commented Apr 25, 2024

zuckschwerdt commented Apr 25, 2024

clau-bucur commented Apr 26, 2024

zuckschwerdt commented Apr 26, 2024

clau-bucur commented Apr 26, 2024

zuckschwerdt commented Apr 26, 2024

clau-bucur commented Apr 26, 2024

zuckschwerdt commented Apr 26, 2024

clau-bucur commented Apr 26, 2024

zuckschwerdt commented Apr 26, 2024

clau-bucur commented Apr 26, 2024

gdt commented Jun 2, 2024

gremlin205 commented Jun 14, 2024

biuklija commented May 17, 2022 •

edited

Loading

biuklija commented May 18, 2022 •

edited

Loading

biuklija commented May 18, 2022 •

edited

Loading

zuckschwerdt commented May 18, 2022 •

edited

Loading

biuklija commented May 18, 2022 •

edited

Loading

biuklija commented May 20, 2022 •

edited

Loading

clau-bucur commented Apr 23, 2024 •

edited

Loading

ProfBoc75 commented Apr 23, 2024 •

edited

Loading

zuckschwerdt commented Apr 23, 2024 •

edited

Loading