|
|
Post by cdenney on Apr 22, 2022 13:09:26 GMT -8
I've been getting a problem recently where the data is failing to write to the SQL database with the following error (from the nohup.out file): trying database
Rain24Hour= 0.9000000000000057
sv= None
svtype= <class 'NoneType'>
--WeatherUnderground Data Send Failed
CPUT= 47.236
trying database
must be real number, not NoneType
File "/usr/local/lib/python3.9/dist-packages/apscheduler/executors/base.py", line 125, in run_job
retval = job.func(*job.args, **job.kwargs)
File "/home/pi/SDL_Pi_SkyWeather2/pclogging.py", line 241, in writeWeatherRecord
values = "%6.2f, %6.2f, %6.2f, %6.2f, %6.2f, %6.2f, %6.2f, %6.2f, %6.2f, %6.2f,%6.2f,%6.2f,%6.2f,%6.2f,%6.2f,%6.2f,%6.2f,%6.2f, \'%s\',%6.2f,%d, %6.2f, %6.2f, %6.2f" % (state.OutdoorTemperature, state.OutdoorHumidity, state.Indoo>
This error happened for several
I can't find a reference to the "sv" variable in pclogging (the stated line 241 doesn't have it), and the only reference I found was in the main script which seems to be a sunairplus thing, but I don't have that attachment.
Any suggestions on how to track this down/fix it?
Thanks
|
|
|
|
Post by SDL on Apr 22, 2022 17:41:49 GMT -8
Could you show more of the error? About 100 lines before and 20 after.
BP
|
|
|
|
Post by cdenney on Apr 22, 2022 19:03:39 GMT -8
Here is an excerpt that goes from when I restarted the pi, includes a few instances of the error, and continues to several succesful writes after the error stopped: Attachments:nohup_excerpt.txt (9.85 KB)
|
|
|
|
Post by SDL on Apr 23, 2022 10:12:30 GMT -8
It looks like the SDR has not yet gotten a WeatherRack2 reading, hence the state variable is not set.
Let this run for 30 minutes, then check the end of the log.
It's still a bug (We shouldn't be trying to send to WeatherUnderdground if we don't have a reading) but this will confirm the problem.
BP
|
|
|
|
Post by cdenney on Apr 25, 2022 8:58:25 GMT -8
Just as a quick update, it hasn't re-occurred, which is good, although it's a bit odd that it was failing to get a reading from the weather rack. The pi box/antenna has direct LOS to the rack and is <50 feet away. I double checked the SNR readings from that day and they never fell below 20 on either side of the missing data.
I guess without it re-occurring there isn't much to do though.
|
|
|
|
Post by SDL on Apr 26, 2022 10:58:41 GMT -8
Hmm. What is between you and the pi Box antenna and WeatherRack2? Also, humidity can make a difference.
BP
|
|
|
|
Post by cdenney on Jun 21, 2022 14:28:20 GMT -8
Ok, so this problem has reoccurred. I've been getting that same sv= None and svtype = <class 'NoneType'> for nearly 4 hours today, and rebooting the pi did not fix it.
In response to the question you asked last time that I missed, there is nothing in between the pi box antenna and the WeatherRack. It's a straight shot, uninterrupted line of sight of well under 50 feet. I've never seen any instances of poor SNR during the ~6 months I've been running the system.
However, I tried something new that I didn't try last time, which was to run the testWirelessSensors.py script while this problem was occuring.
I got the following output of the script:
pi@raspberrypi:~/SDL_Pi_SkyWeather2 $ sudo python3 testWirelessSensors.py
Starting Wireless Read
/usr/lib/python3.9/subprocess.py:941: RuntimeWarning: line buffering (buffering=1) isn't supported in binary mode, the default buffer size will be used
self.stdout = io.open(c2pread, 'rb', bufsize)
rtl_433 version -128-NOTFOUND branch master at 202204011242 inputs file rtl_tcp RTL-SDR
Use -h for usage help and see https://triq.org/ for documentation.
Trying conf file at "rtl_433.conf"...
Trying conf file at "/root/.config/rtl_433/rtl_433.conf"...
Trying conf file at "/usr/local/etc/rtl_433/rtl_433.conf"...
Trying conf file at "/etc/rtl_433/rtl_433.conf"...
quiet option (-q) is default and deprecated. See -v to increase verbosity
Consider using "-M newmodel" to transition to new model keys. This will become the default someday.
A table of changes and discussion is at https://github.com/merbanan/rtl_433/pull/986.
Registered 6 out of 153 device decoding protocols [ 146-148 150-152 ]
usb_claim_interface error -6
I tried doing some googling on that usb_claim_interface error but wasn't really able to figure out much.
|
|
|
|
Post by cdenney on Jun 21, 2022 15:36:39 GMT -8
Aaaaaaand it's back. Came back on it's own well over an hour after the restart.
|
|
Sopwith
Junior Member
"If it works out of the box - what fun is that?"
Posts: 69
Raspberry Pi: Yes
Other Device: Pico Pi
|
Post by Sopwith on Jun 21, 2022 17:45:42 GMT -8
re. the usb_claim_interface error You might find good info in this blog: www.cloudacm.com/?p=3203It seems you may already have a process claiming the dongle when you ran your test. Sopwith |
|
|
|
Post by cdenney on Jun 22, 2022 7:11:05 GMT -8
That makes sense, as the primary program was still running. So the testscript didn't tell me anything other than that. Still doesn't explain these occasional, persistent failures to connect to the WeatherRack
|
|
|
|
Post by cdenney on Jun 23, 2022 14:21:39 GMT -8
Ok, I think I have a clue about this. I have noticed a pattern that the error seems to happen most consistently in peak sunlight on clear, cloudless days. I know there was an update a while back about max sunlight readings. Is it possible that high sunlight measurements could be causing some kind of error?
|
|
|
|
Post by SDL on Jun 24, 2022 7:40:31 GMT -8
Yes, it could be. Are you running the latest rtl_433 (from SDL) and SkyWeather2?
Sopwith is right about the usb_claim error. Things will get really screwed up if you are running multiple rtl_433 instances.
So, I'm a little confused. Could you restate what your problem is that you would like me to look at now?
BP
|
|
|
|
Post by cdenney on Jun 24, 2022 12:23:57 GMT -8
So I've made some more progress. Part of the problem was that I had updated the rtl_433 after the sunlight issues a while back ( from this thread), but I had not made the change in wirelessSensors.py. I updated that today, and I have not had the drop out that I was getting previously, so I'm pretty sure that the mismatch in updates between those two was causing the dropout when sunlight readings were high.
The only remaining issue is that I appear to be consistently hitting the max lux value of 131069 (it's been pegged there for over an hour now, and if I'm right that that's what was causing the drops, it will stay there for another couple of hours). Considering I'm at a relatively high latitude of 45N, this seems like it's unlikely to be a real reading (wikipedia claims that 120,000 is the brightest sunlight lux reading, and I'm assuming that if the sun isn't directly overhead, which it never is at this latitude, the reading should be lower). Plus, an online calculator suggested that my actual lux reading should be ~102,000
So I don't know if I have a bad sensor, or if it's possible to re calibrate it or what, but that's the current state of my issue.
|
|
|
|
Post by SDL on Jun 24, 2022 19:23:26 GMT -8
Sounds like you may want to add a bit of calibration to your unit. It hits a max of the 131069 and waits until the value drops down.
BP
|
|
|
|
Post by cdenney on Jun 25, 2022 9:17:51 GMT -8
I assume you mean add a mathematical transformation in the script to fix it? Or is there an actual way to calibrate the sensor?
If it's the first, is there a way I could increase the lux cap in my rtl_433 folder? I _think_ it would involve changing line 138 and 139 of switchdoclabs_FT020T.c, but C++ is a bit beyond my chops.
The reason I ask is that it's hard to know the correct transformation when it's just getting capped. It looks roughly like my sensor might be reading between 1.5x and 2x (according to my other light sensor I've got, although I won't know for sure till I have at least a full day of comparison), but restoring the correct values during "peak" sunlight periods is going to be hard if it's all up against the cap. A simple multiplicative is still going to be flatlined, just at a lower level.
|
|
