Post by triggerfish on Dec 31, 2018 16:00:13 GMT -8
First of all: A happy newyear and all the best for 2019. We just passed midnight overhere!
What I meant was that currently when an error occurs, there is no recovering from it. "Before" when an error occurred, after a while readings usually went back to normal. When I started saving the last good read, that resulted in temporary flatlines in the wunderground graphs, while GWP was returning the same last good value a couple of times in a row.
On both my weather stations I do not see any locks. What I do see is the occasional 0 values from AM2315, but the while loop I inserted (see above) solved that (so far maximum 8 retries - no infinite loops).
With V3.12, it seems if abnormal values are returned (during startup checks?) then the code stops reading that sensor altogether, and a reboot is needed.
I also see problems with the sunlight sensor returning 0 values. My comment of a few days ago (see page 3) is also relevant here: ********* [multiplexer removed] The sunlight sensor initially returned 0 values. I opened another command line window and ran 'simpletest.py' in the SI1145 subdirectory, which gave me realistic values. Interesting thing though: suddenly GroveWeatherPi.py started returning values as well! A few minutes later the main routine started reporting 0 values again, but recovered when I ran simpletest again. ********* This behaviour does not seem to occur with the V3.12 code - when measurements fail, they seem to keep failing thereafter. For what it is worth, this phenomenon also *seems* to be independent of whether the multiplexer is present or not - it is just easier for me to run simpletest without the multiplexer (limited knowledge / experience / time).
(And then there is the issue of the "inverted gusts" - see separate thread...)
But it is not locking the I2C bus so no sensors are being read?
Hard to tell, because the systems stops reporting to Blynk and Wunderground also. Blynk status screen shows last sample being the time and date things gone wrong. Wunderground says station not reporting since time and at things went wrong. Logging does just repeat patting the dog. It does not display much sensor dat since 3.03 went to 3.11, so not much info from that either. I just queried the database and since time of things gone wrong, every record has the same values... So not sure if I2C bus is locked, but no new values are saved anywhere.
Powered down everything to fit the new waterproof power connectors for the solar panels. Started all up and initially all went well for about half an hour. The the dreaded error occurred and since then the database contained only identical records. Not sure if that is the lockup you mean, but it looks like no new values are read/used...
trying database before query query=INSERT INTO WeatherData(TimeStamp,as3935LightningCount, as3935LastInterrupt, as3935LastDistance, as3935LastStatus, currentWindSpeed, currentWindGust, totalRain, bmp180Temperature, bm p180Pressure, bmp180Altitude, bmp180SeaLevel, outsideTemperature, outsideHumidity, currentWindDirection, currentWindDirectionVoltage, insideTemperature, insideHumidity) VALUES(UTC_TIMESTA MP(), 0.000, 0.000, 0.000, "", 3.040, 8.054, 0.000, 8, 104.053, -224.683, 104.140, 6.400, 72.100, 45.000, 2.146, 8.529, 83.136) query=INSERT INTO Sunlight(TimeStamp, Visible, IR, UV, UVIndex) VALUES(UTC_TIMESTAMP(), 0, 0, 0, 0.000) before query query=INSERT INTO PowerSystem(TimeStamp, batteryVoltage, batteryCurrent, solarVoltage, solarCurrent, loadVoltage, loadCurrent, batteryPower, solarPower, loadPower, batteryCharge) VALUES (UT C_TIMESTAMP (), 3.807, 225.200, 1.592, -0.000, 4.976, 155.200, 0.857, -0.000, 0.772, 52.100) ----------------- Weather Sampling ----------------- ----------------- 'NoneType' object has no attribute '__getitem__' File "/usr/local/lib/python2.7/dist-packages/apscheduler/executors/base.py", line 125, in run_job retval = job.func(*job.args, **job.kwargs) File "/home/pi/SDL_Pi_GroveWeatherPi/GroveWeatherPi.py", line 1274, in sampleAndDisplay sampleWeather() File "/home/pi/SDL_Pi_GroveWeatherPi/GroveWeatherPi.py", line 1106, in sampleWeather ToutsideHumidity, ToutsideTemperature, crc_check = am2315.read_humidity_temperature_crc() File "./SDL_Pi_AM2315/AM2315.py", line 136, in read_humidity_temperature_crc self._read_data() File "./SDL_Pi_AM2315/AM2315.py", line 97, in _read_data self.humidity = ((tmp << 8) | tmp) / 10.0
------Patting The Dog------- ------Patting The Dog------- ------Patting The Dog------- ------Patting The Dog------- ------Patting The Dog------- Tick! The time is: 2019-01-02 17:04:13.241041 ------Patting The Dog------- ------Patting The Dog------- ------Patting The Dog------- ------Patting The Dog------- ------Patting The Dog-------
If there is some way of getting a working GWP weatherstation, please let me know...
At the moment I have issues with:
- powercontroll/watchdog not working together correctly
- UV/IR/Light sensor zeroing after the AM2315 "crash"
- AM2315 crashing
- Blynk battery gauge showing nothing.
This is going on for months now and to be honest, I'm at the end of my wits.
Post by triggerfish on Jan 2, 2019 11:50:31 GMT -8
Henk suggested trying to see what happens on the AM2315 when thing went bad. So I modified te test program for the AM2315. It took me some tinkering to get theoutput to my liking. In the mean time I did get output every testrun. When I got the output like I wanted I started again and this time I got the error. The program cancelled, but when I restarted, it just went on reading the sensor... So apparently the hardware recovers from the error very soon, but somehow the program does not... See output from my test script...
I tried breathing on the sensor to see if it was stuck, or still reading values. Both temp and humidity rose, and dropped later...
To me that proves the problem is not hardware related, the program code apparently does not know how to cope with one error...
While the big program stopped doing what it supposed to do... Not updatin Blynk, not updating Wundergroud, the test script kept om producing values... Ok, every now and then a -1 CRC, but it kept on running...
Post by triggerfish on Jan 2, 2019 13:01:15 GMT -8
Well... So Far So Good... My code change has been running for an hour and a half now... And still running... Blynk is updated, wunderground is updated... AND... the log shows, my code has caught about 40 or so error conditions, which did not result in program crashes... The code has been working longer than a couple of minutes before, but I actually see error conditions beeing taken care of... So I have good hopes I am one step closer to a solution ( and a working weather-station )...
Update us again in a few days. If it is still working, I'll update the main GWP code base.
You have to re-think the sanity check in the am2315 driver BTW. I still had some 0's sneaking through. I see you assume a change in temp less than 10 degrees as "good" but if you don't live in the tropics temps around 0 are common. By now the temp never rises above about 8 celsius around here. The difference between a valid 8 and error 0 is less than 10 and 0 is assumed to be valid. More reliable would be to decide on a good read to check humidity to be >0 and <100 Both extremes are close to impissible do an error 0 for hum would be safer to do your sanity check on the am2315 with.
First twelve hours without any visible problems. I did not count the miss-reads in the log yet, but so far all looks stable. To avoid battery drainage, I hooked up an external power supply during the night. At he moment I want to make sure the driver modification works. Tonight I expect the 48 hour reboot. Let's see what happens after that.