|
Post by triggerfish on Jan 4, 2019 4:01:59 GMT -8
!!!!!POEP!!!!! After about 30 hours of running without problems, surviving the 48 hour scheduled reboot, this morning, things went bad again
------Patting The Dog------- trying database trying database before query query=INSERT INTO WeatherData(TimeStamp,as3935LightningCount, as3935LastInterrupt, as3935LastDistance, as3935LastStatus, currentWindSpeed, currentWindGust, totalRain, bmp180Temperature, bmp180Pressure, bmp180Altitude, bmp180SeaLevel, outsideTemperature, outsideHumidity, currentWindDirection, currentWindDirectionVoltage, insideTemperature, insideHumidity) VALUES(UTC_TIMESTAMP(), 0.000, 0.000, 0.000, "", 0.320, 0.923, 0.000, 6, 104.044, -224.845, 104.141, 3.900, 93.400, 225.000, 2.934, 6.588, 89.018) query=INSERT INTO Sunlight(TimeStamp, Visible, IR, UV, UVIndex) VALUES(UTC_TIMESTAMP(), 368, 61, 4026, 40.260) before query query=INSERT INTO PowerSystem(TimeStamp, batteryVoltage, batteryCurrent, solarVoltage, solarCurrent, loadVoltage, loadCurrent, batteryPower, solarPower, loadPower, batteryCharge) VALUES (UTC_TIMESTAMP (), 3.746, 21.600, 0.016, -0.000, 4.976, 157.200, 0.081, -0.000, 0.782, 43.211) ----------------- Weather Sampling ----------------- ----------------- Error reading AM2315, retrying... Error reading AM2315, retrying... Error reading AM2315, retrying... Error reading AM2315, retrying... '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 1275, in sampleAndDisplay sampleWeather() File "/home/pi/SDL_Pi_GroveWeatherPi/GroveWeatherPi.py", line 1107, in sampleWeather ToutsideHumidity, ToutsideTemperature, crc_check = am2315.read_humidity_temperature_crc() File "./SDL_Pi_AM2315/AM2315.py", line 141, in read_humidity_temperature_crc self._read_data() File "./SDL_Pi_AM2315/AM2315.py", line 102, 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------- Did not look in the code, but maybe the driver tries five times before quitting???
So... We are getting there, but no cigar yet.
SDL: any new insights from this?
|
|
hvrooyen
New Member
Posts: 32
Raspberry Pi: Yes
Other Device: Arduino
|
Post by hvrooyen on Jan 4, 2019 4:32:34 GMT -8
Did the old code not run automatically on reboot?
|
|
|
Post by triggerfish on Jan 4, 2019 4:42:54 GMT -8
Did the old code not run automatically on reboot? Yes, so does the new code. The problem is not in the reboot.
@sdl: the reboot makes the AM2315 producing valid data again, but the visible light sensor zeroed out. I'll wait to see what happens now, but I guess I need to power the system off and on again to wake that sensor up again...
|
|
hvrooyen
New Member
Posts: 32
Raspberry Pi: Yes
Other Device: Arduino
|
Post by hvrooyen on Jan 4, 2019 4:47:36 GMT -8
In my experience the visible light sensor will correct when you run the demo code in a separate window /session. However, I removed my multiplexer - you will probably need to add that code...
|
|
|
Post by triggerfish on Jan 5, 2019 14:09:11 GMT -8
In my experience the visible light sensor will correct when you run the demo code in a separate window /session. However, I removed my multiplexer - you will probably need to add that code... I had a look at the SI1145 driver and found no error handling whatsoever... So when an error occurs, further reading fails. Until you apparently run another session. I requested adding error handling in the SI1145 thread on the driver like what is added to the AM2315 driver.
|
|
|
Post by triggerfish on Jan 6, 2019 4:47:07 GMT -8
After some struggling with python, I think I have come to some code that at least will keep running after errors.
The initial change I made to catch the red error's by "trying" them, worked until the errors looped out of the MAXREADS value. At that moment the program crashed anyway because of assuming data is there that was not. I checked for the MAXREADS after the loop and just assumed a bad crc if the MAXREADS where superseeded.
if count <= MAXREADATTEMPT:
if (AM2315DEBUG == True): ### Print number of reads on the AM2315 print "AM2315 failed", count, "times..."
# GET THE DATA OUT OF THE LIST WE READ self.humidity = ((tmp[2] << 8) | tmp[3]) / 10.0 self.temperature = (((tmp[4] & 0x7F) << 8) | tmp[5]) / 10.0 if (tmp[4] & 0x80): self.temperature = -self.temperature
self.crc = ((tmp[7] << 8) | tmp[6]) # Verify CRC here # force CRC error with the next line #tmp[0] = tmp[0]+1 t = bytearray([tmp[0], tmp[1], tmp[2], tmp[3], tmp[4], tmp[5]]) c = self.verify_crc(t)
if (AM2315DEBUG == True): print "AM2315temperature=",self.temperature print "AM2315humdity=",self.humidity print "AM2315crc=",self.crc print "AM2315c=",c
if (self.crc != c) or (count > MAXREADATTEMPT): if (AM2315DEBUG == True): print "AM2314 BAD CRC" self.badcrcs = self.badcrcs + 1 self.crc = -1 else: self.goodreads = self.goodreads+1 I feel this to be a bad quick-and-dirty method, but my current python knowledge does not give me any better solution. I am not sure at this moment this will catch al problems anyway. Will leave the code running for now. I am logging the read attempts in the loop, so over time I will have a general idea on the stabitily of the AM2315... My guess is that the power reset of the M2315 that is talked of by SDL would have to occurr in the code when MAXREADS has happened. At that time resetting the AM2315 with the power save module would overcome that???
|
|
hvrooyen
New Member
Posts: 32
Raspberry Pi: Yes
Other Device: Arduino
|
Post by hvrooyen on Jan 6, 2019 6:51:44 GMT -8
triggerfish: It seems you have a WXlink? (I don't - I am trying to find out why you seem to be doing the same as me, but with completely different looking code) What is the maximum number of sequential failed reads you have seen so far? H.
|
|
|
Post by triggerfish on Jan 6, 2019 8:32:48 GMT -8
triggerfish : It seems you have a WXlink? (I don't - I am trying to find out why you seem to be doing the same as me, but with completely different looking code) What is the maximum number of sequential failed reads you have seen so far? H.
I do not have a WXlink, the software if just reporting zeroes about it. Not sure why. To my best knowledge I have said False to it, but...
So far the reads have been like:
pi@IBADHOEV14:~/SDL_Pi_GroveWeatherPi $ grep "AM2315 failed" log/IBADHOEV14_2019-01-06_13.32.30.log | wc -l 472 pi@IBADHOEV14:~/SDL_Pi_GroveWeatherPi $ grep "AM2315 failed 0" log/IBADHOEV14_2019-01-06_13.32.30.log | wc -l 344 pi@IBADHOEV14:~/SDL_Pi_GroveWeatherPi $ grep "AM2315 failed 1" log/IBADHOEV14_2019-01-06_13.32.30.log | wc -l 48 pi@IBADHOEV14:~/SDL_Pi_GroveWeatherPi $ grep "AM2315 failed 2" log/IBADHOEV14_2019-01-06_13.32.30.log | wc -l 71 pi@IBADHOEV14:~/SDL_Pi_GroveWeatherPi $ grep "AM2315 failed 3" log/IBADHOEV14_2019-01-06_13.32.30.log | wc -l 9
So out of a total of 472, 48 times 1 failure, 71 times 2 failures and 9 times 3 failures...
|
|
|
Post by SDL on Jan 8, 2019 20:15:21 GMT -8
Peter,
Interesting results. Good way of doing that. Now, as far as insights. Yes. The
'NoneType' object has no attribute '__getitem__' means that the AM2315 object appears to have been zeroed out. Now that is an error we were not trapping and I don't see where that is actually coming from.
BP
|
|
|
Post by triggerfish on Jan 10, 2019 0:28:20 GMT -8
By now, I think I have tweaked the code to a situation that at least gave me three full days of sensible data. There is a small start part before and this morning things remained OK.
|
|
hvrooyen
New Member
Posts: 32
Raspberry Pi: Yes
Other Device: Arduino
|
Post by hvrooyen on Jan 10, 2019 0:36:51 GMT -8
Nice. My approach is more of a kludge, but with similar results (I just keep asking for new values in the main routine until they are acceptable). System has been runnning for about 10 days now, with no abnormal results. Maximum retries seem to be 8 (twice) and 7 (twice).
|
|
|
Post by triggerfish on Jan 10, 2019 0:51:41 GMT -8
Nice. My approach is more of a kludge, but with similar results (I just keep asking for new values in the main routine until they are acceptable). System has been runnning for about 10 days now, with no abnormal results. Maximum retries seem to be 8 (twice) and 7 (twice).
Not bad! My idea about the thing is that the driver (as I call the AM2315.py module) should produce either a valid value or a -1 crc after a limited amount of tries. Dealing with the value itself should be done in the main program, so your apporoach is not that dissimilar I guess. In the main loop I also validate the value to be sensible or not. I just use the previously saved valid value if one fails. That way the loop is run uninterrupted and all other values get updated. In the next loop there is another try on getting a valid value. If you keep trying until a valid value, you might end up with an infinite loop, also flattening other values like wind and rain, that are not affected by the AM2315 problem.
|
|
|
Post by SDL on Jan 10, 2019 9:54:15 GMT -8
Yes, that is exactly what is going on. I will sit down this weekend and fix this.
The I/O is all supposed to be protected, but obviously I am missing something here.
BP
|
|
|
Post by triggerfish on Jan 10, 2019 11:23:55 GMT -8
Yes, that is exactly what is going on. I will sit down this weekend and fix this. The I/O is all supposed to be protected, but obviously I am missing something here. BP Basically, you just missed one... The actual reading of the sensor. And the retyr loop can end with a bad read, so after exiting the loop, I did a double check on the sanity of the result. I added humidity, bacause that can much easier be established as valid or invalid. The temp change of 10 will not work here for most of the year. Like I explained, if the average temp is around 6 degrees, an errorous zero will give a change of less than 10 and is deemed valid then. Which in fact it is not. A zero or over 100 humidity is far more safe to check on I think.
This is what I did op de AM2315.py software
def _read_data(self): count = 0 tmp = None
while count <= MAXREADATTEMPT: try: try: # WAKE UP self._device.write8(AM2315_READREG,0x00) except: time.sleep(0.09)
# 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) self.temperature = (((tmp[4] & 0x7F) << 8) | tmp[5]) / 10.0
# check for > 10.0 degrees higher if (self.AM2315PreviousTemp != -1000): # ignore first time if (abs(self.AM2315PreviousTemp - self.temperature) > 10.0): # OK, temp is bad. Ignore if (AM2315DEBUG == True): print ">>>>>>>>>>>>>" print "Bad AM2315 Temperature = ", self.temperature print ">>>>>>>>>>>>>" self.badreadings = self.badreadings+1 tmp = None else: # Good Temperature self.AM2315PreviousTemp = self.temperature else: # assume first is good temperature self.AM2315PreviousTemp = self.temperature # IF WE HAVE DATA, LETS EXIT THIS LOOP if tmp != None: break
except Exception as ex: time.sleep(0.09)
except Exception as ex: if (AM2315DEBUG == True): template = "An exception of type {0} occurred. Arguments:\n{1!r}" message = template.format(type(ex).__name__, ex.args) print message print traceback.format_exc() print "AM2315readCount = ", count count += 1 time.sleep(0.10)
if count <= MAXREADATTEMPT:
if (AM2315DEBUG == True): ### Print number of reads on the AM2315 print "AM2315 failed", count, "times..."
# GET THE DATA OUT OF THE LIST WE READ self.humidity = ((tmp[2] << 8) | tmp[3]) / 10.0 self.temperature = (((tmp[4] & 0x7F) << 8) | tmp[5]) / 10.0 if (tmp[4] & 0x80): self.temperature = -self.temperature
self.crc = ((tmp[7] << 8) | tmp[6]) # Verify CRC here # force CRC error with the next line #tmp[0] = tmp[0]+1 t = bytearray([tmp[0], tmp[1], tmp[2], tmp[3], tmp[4], tmp[5]]) c = self.verify_crc(t)
if (AM2315DEBUG == True): print "AM2315temperature=",self.temperature print "AM2315humdity=",self.humidity print "AM2315crc=",self.crc print "AM2315c=",c
if (self.crc != c) or (count > MAXREADATTEMPT): if (AM2315DEBUG == True): print "AM2314 BAD CRC" self.badcrcs = self.badcrcs + 1 self.crc = -1 else: self.goodreads = self.goodreads+1
And this is what I did in the main loop...
ToutsideHumidity, ToutsideTemperature, crc_check = am2315.read_humidity_temperature_crc() if (crc_check != -1) and (ToutsideHumidity >= 0 and ToutsideHumidity <= 100): outsideTemperature = ToutsideTemperature outsideHumidity = ToutsideHumidity state.currentOutsideTemperature = outsideTemperature state.currentOutsideHumidity = outsideHumidity
I did the humidity sanity check in the main program, since I did not really know how to arrange that in de driver module...
This is far from neat programming, but all I can come up with now.
|
|
|
Post by SDL on Jan 10, 2019 19:24:26 GMT -8
Temp change of 10 in 60 seconds? Really?
BTW, the 10 could be bumped up to about 15. The theory here is a bit is flipped that gives an 16 degree C spike.
I am adding the try except loop to GWP 2.13 and the unprotected AM2315 read. And if it is a "None" error, then I am reinitializing the AM2315 module.
BP
|
|