|
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.
|
|
|
Post by SDL on Dec 31, 2018 17:47:39 GMT -8
But it is not locking the I2C bus so no sensors are being read?
BP
|
|
hvrooyen
New Member
Posts: 32
Raspberry Pi: Yes
Other Device: Arduino
|
Post by hvrooyen on Dec 31, 2018 21:13:53 GMT -8
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...)
|
|
|
Post by triggerfish on Jan 2, 2019 6:11:56 GMT -8
But it is not locking the I2C bus so no sensors are being read? BP 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.
|
|
|
Post by triggerfish on Jan 2, 2019 8:40:04 GMT -8
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[2] << 8) | tmp[3]) / 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...
pi@IBADHOEV14:~/SDL_Pi_GroveWeatherPi $ sudo python testAM2315.pyTraceback (most recent call last): File "testAM2315.py", line 13, in <module> outsideHumidity, outsideTemperature, 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[2] << 8) | tmp[3]) / 10.0 TypeError: 'NoneType' object has no attribute '__getitem__' pi@IBADHOEV14:~/SDL_Pi_GroveWeatherPi $ sudo python testAM2315.py 2019-01-02 20:38:44temperature: 5.7, humidity: 78.1, crc: 32160 2019-01-02 20:38:47temperature: 5.7, humidity: 78.2, crc: -1 2019-01-02 20:38:49temperature: 5.7, humidity: 78.2, crc: 32080 2019-01-02 20:38:51temperature: 5.7, humidity: 78.2, crc: 32080 2019-01-02 20:38:53temperature: 5.7, humidity: 78.2, crc: 32080 2019-01-02 20:38:55temperature: 5.7, humidity: 78.3, crc: 48385 2019-01-02 20:38:57temperature: 5.7, humidity: 78.3, crc: 48385 2019-01-02 20:39:00temperature: 5.7, humidity: 78.3, crc: 48385 2019-01-02 20:39:02temperature: 5.7, humidity: 78.3, crc: 48385 2019-01-02 20:39:04temperature: 5.7, humidity: 78.3, crc: 48385 ^CTraceback (most recent call last): File "testAM2315.py", line 19, in <module> time.sleep(2.0) KeyboardInterrupt 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...
2019-01-02 20:46:56temperature: 6.6, humidity: 92.4, crc: 46001 2019-01-02 20:46:59temperature: 6.6, humidity: 92.2, crc: 45649 2019-01-02 20:47:01temperature: 6.6, humidity: 92.0, crc: 29424 2019-01-02 20:47:03temperature: 6.6, humidity: 91.8, crc: 45457 2019-01-02 20:47:05temperature: 6.6, humidity: 91.6, crc: -1 2019-01-02 20:47:07temperature: 6.6, humidity: 91.4, crc: 28880 2019-01-02 20:47:09temperature: 6.6, humidity: 91.3, crc: 28704 2019-01-02 20:47:12temperature: 6.6, humidity: 91.1, crc: 30272 2019-01-02 20:47:14temperature: 6.5, humidity: 90.9, crc: 47009 2019-01-02 20:47:16temperature: 6.5, humidity: 90.7, crc: 46657 2019-01-02 20:47:18temperature: 6.5, humidity: 90.6, crc: 30224 2019-01-02 20:47:20temperature: 6.5, humidity: 90.4, crc: 46769 2019-01-02 20:47:23temperature: 6.5, humidity: 90.2, crc: 30160 2019-01-02 20:47:25temperature: 6.5, humidity: 90.0, crc: 46449 2019-01-02 20:47:27temperature: 6.5, humidity: 89.8, crc: 46225 2019-01-02 20:47:29temperature: 6.5, humidity: 89.6, crc: 29744 2019-01-02 20:47:31temperature: 6.4, humidity: 89.4, crc: 17552 2019-01-02 20:47:34temperature: 6.4, humidity: 89.1, crc: 17792 2019-01-02 20:47:36temperature: 6.4, humidity: 88.9, crc: 34081 2019-01-02 20:47:38temperature: 6.4, humidity: 88.6, crc: 34321 2019-01-02 20:47:40temperature: 6.4, humidity: 88.3, crc: 34561 2019-01-02 20:47:42temperature: 6.4, humidity: 88.0, crc: -1 2019-01-02 20:47:44temperature: 6.4, humidity: 87.7, crc: 33121 2019-01-02 20:47:47temperature: 6.4, humidity: 87.4, crc: 16592 2019-01-02 20:47:49temperature: 6.4, humidity: 87.2, crc: 32881 2019-01-02 20:47:51temperature: 6.3, humidity: 86.9, crc: 41889 2019-01-02 20:47:53temperature: 6.3, humidity: 86.7, crc: -1 2019-01-02 20:47:55temperature: 6.3, humidity: 86.6, crc: 25104 2019-01-02 20:47:58temperature: 6.3, humidity: 86.4, crc: 41649 2019-01-02 20:48:00temperature: 6.3, humidity: 86.3, crc: 44673 2019-01-02 20:48:02temperature: 6.3, humidity: 86.2, crc: 28368 2019-01-02 20:48:04temperature: 6.3, humidity: 86.1, crc: 28192 2019-01-02 20:48:06temperature: 6.2, humidity: 86.0, crc: 28336
|
|
|
Post by triggerfish on Jan 2, 2019 12:07:20 GMT -8
I noticed in SDL_Pi_AM2315/AM2315.py the actual reading of the sensor was not caught by try. I changed it to following:
# TELL THE DEVICE WE WANT 4 BYTES OF DATA try: self._device.writeList(AM2315_READREG,[0x00, 0x04]) time.sleep(0.09) tmp = self._device.readList(AM2315_READREG,8) except Exception as ex: print "Error reading AM2315, retrying..." time.sleep(0.09)
Now wait and see...
|
|
|
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 )...
|
|
|
Post by SDL on Jan 2, 2019 15:21:59 GMT -8
Peter,
Update us again in a few days. If it is still working, I'll update the main GWP code base.
BP
|
|
|
Post by triggerfish on Jan 2, 2019 16:22:24 GMT -8
Peter, Update us again in a few days. If it is still working, I'll update the main GWP code base. BP Will do. 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.
|
|
|
Post by SDL on Jan 2, 2019 17:10:02 GMT -8
Peter,
It is a "change" in 10 degrees. Not 10 degrees absolute.
Appreciate your comments.
BP
|
|
|
Post by triggerfish on Jan 2, 2019 17:41:43 GMT -8
Peter, It is a "change" in 10 degrees. Not 10 degrees absolute. Appreciate your comments. BP Yes I know. That's the problem. When it is 8 degrees real and the next read is an error 0, the change is 8-0 = less than 10 so assumed correct.
|
|
|
Post by triggerfish on Jan 3, 2019 2:02:57 GMT -8
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.
|
|
|
Post by doxidad on Jan 3, 2019 2:39:03 GMT -8
BP,
Something for you to consider on future releases.
The column TimeStamp is used in the queries in the graphing routines.
Example: SELECT TimeStamp, bmp180SeaLevel, as3935LastInterrupt, as3935LastDistance FROM WeatherData where now() - interval 240 hour < TimeStamp
On a database with ~140,000 rows this takes .55 seconds on a Pi 3B
With an index on this column the query takes .09 seconds.
This can be done with the following for each table after creation.
ALTER TABLE `WeatherData` ADD KEY `TimeStamp` (`TimeStamp`);
|
|
|
Post by triggerfish on Jan 3, 2019 12:27:48 GMT -8
About 24 hours without any obvious problems now. Looking good. Just need to find out why the batt gauge still is dead. But that's another thing.
|
|