|
Post by SDL on Apr 11, 2022 13:53:31 GMT -8
OK! I have found a duplicate on our test system too. I suspect it is another case of the system picking up bad data and then reporting it rather than ignoring it.
Thank you guys. I'll get on this later this week.
BP
|
|
|
Post by cdenney on Apr 12, 2022 9:47:11 GMT -8
In case it's still useful,those two readings I posted earlier were the only two instances I've had of those anomalously high values. Didn't see it again in the day or two between posting it and getting the fix,and haven't seen it since.
|
|
|
Post by SDL on Apr 15, 2022 12:26:57 GMT -8
I still haven't found the source of the problem. Since this happens so rarely, I need some help!
I no longer believe that it is in the switchdoc software in rtl_433, but I don't know where the magic number of 2147480000 (0x7FFFF1C0) is coming from! I have hit the maximum 131069 lux numbers several times today, but do not see the funky number (looking in rtl_433, not in SkyWeather2). I also am now awaiting bad data.
Make sure you turn on SWDEBUG and run SkyWeather2.py from the terminal window like this:
sudo nohup python3 SkyWeather2.py &
Then we wait until we get a bad value . Then, go through your nohup.out file and find the printed JSON that comes in from the WeatherRack2.
I'm doing the same thing.
BP
|
|
|
Post by SDL on Apr 15, 2022 13:04:04 GMT -8
Here is our test to force high light readings to try to trigger the problem, if that is it! We are hitting the high of 131069 right now. BP
|
|
|
Post by SDL on Apr 15, 2022 13:06:27 GMT -8
And the kludge gives us data! I just forced the 2147480000 error! Hurrah! and I have the data! Now to look at it.
BP
|
|
|
Post by SDL on Apr 15, 2022 13:07:27 GMT -8
And the kludge gives us data! I just force the 2147480000 error! Hurrah! and I have the data! Now to look at it.
It's in the Python3
BP
|
|
|
Post by SDL on Apr 15, 2022 13:33:16 GMT -8
I fixed it. Not exactly a program bug. Turns out the internal software for the WeatherRack2 does not quite match the actual software coming in. When you hit the maximum reading from the sensor, it give a different reading.
I'll be releasing a 27.4 shortly up to the repository, but here are the lines to be changed:
in wirelessSensors.py change:
wLight = var["light"] if (wLight >= 0x1fffa): wLight = wLight | 0x7fff0000
to:
wLight = var["light"] #if (wLight >= 0x1fffa): # wLight = wLight | 0x7fff0000
Whew! This is off my bug list.
BP
|
|
maccampb
New Member
Posts: 21
Raspberry Pi: Yes
Other Device: Linux on X64, Particle Photon, MAC
|
Post by maccampb on Apr 15, 2022 17:46:58 GMT -8
I’d like to test this. To be clear, do you need the radio software update AND this patch to get the readings correctly?
|
|
|
Post by SDL on Apr 16, 2022 8:40:50 GMT -8
Yes. Update both. There were two problems. 1) High Light Levels were not being read correctly and 2) Error conditions weren't handled properly in Python. Couldn't see problem #2 until #1 had been fixed!
BP
|
|