Post by triggerfish on Dec 28, 2018 1:38:39 GMT -8
3.03 worked "best" for me. I modded it to save the temp/hum after a good read, to use that in case of a bad read. That showed some short flatlines in the wunderground graph. I did not have the sunlight sensor then, so I can not say anything about that. Since the rework on the am2315 driver things started going from bad to worse imho.
I can accept the stuff works at SDL, but by now we have three setups we know of, having the same problems. So there must be some sort of problem... Reproducing it, would give the same errors we give you, so that should not hinder investigating. Having the problem yourself just speeds up testing.
I am having a crippled setup for a couple of months now and I am perfectly willing to accept some tinkering, but the set is sold as a working kit, but so far, no luck.
Are you absolutely sure at SDL, the setup is identical? I understand it's derrived from the curacao project which had more hardware on it to do stuff. For instance the arduino with the ram to store data when there is not enough power to feed the whole system.
I am about to throw in the towel and decide I learned an expensive lesson, not to get stuff overseas anymore. When thing goes wrong, it's apparently nearly impossible to get things fixed.
Peter, I noticed that the AM2315 craps out when the graphing routines run. I commented out the apscheduler entry for graphing and I now have the longest run without AM2315 failure. I have been seeing the failure anywhere from 15 minutes after startup to a couple of hours after startup. Without the graphing routines, it has run for over 24 hrs without a failure. This could mean that the graphing routines were causing the problem or just that the failure hasn't happened. Time will tell. If you aren't using the graphs for anything you might give this a try.
@switchdoc, still haven't had a chance to wipe/reload the github repo yet, but was thinking over the holiday. If helpful I could save an iso of my current SD card and dropbox it to you. My thought is, that if it is software related, that would be the best way to replicate the issue and fix. Let me know if you would like me to do so.
Above is a screenshot, The outside temp/humidity sensor is always showing 0 for the humidity, and 32 for the temp. When I run the program it states that the sensor is not present. Everything else seems to be working.
Here's my sample code - I simply repeat the read until the 2315 comes to it senses or has failed five times.
I'm not completely confident on python yet (am doing a course at the moment), but it seems to see that you assume temperatures above 100 to be wrong... The problem wit this is that the device often returns 0 when it fails. I even got temperatures of -2350 or so. I used to check the humidity because that can be more reliably checked to be between 0 and 100.
The following seems to work for me, although only time will tell. Using V3.02 (because 3.12 does not work for me at all), I searched for am2315.sense and inserted the following while statement:
if (config.AM2315_Present): outsideTemperature, outsideHumidity, crc_check = am2315.sense() while (crc_check==-1 or outsideHumidity==0 or outsideTemperature >60 or outsideTemperature <-20): print "Unacceptable values from AM2315 - resensing" outsideTemperature, outsideHumidity, crc_check = am2315.sense() print "outsideTemperature: %0.1f C" % outsideTemperature print "outsideHumidity: %0.1f %%" % outsideHumidity print "crc: %s" % crc_check
You can of course change the values to suit your climate. Also, I realise that this can potentially cause an infinite loop, but at the moment I actually want it like this - to see how many times it can fail.
Last Edit: Dec 29, 2018 22:59:55 GMT -8 by hvrooyen: Python indentation was lost during copy-paste.
Thanks for the info. You mention 3.3 vs 5 V. I am not in a position to measure voltages where I am, but does the kit as supplied with Grove connectors not supply 3.3V to all I2C devices? (Also - you still have the same problem, so it seems supply voltage is not the cause of the weird readings?)
I'd say that supply voltage is not the _only_ cause of weird readings. I think it mostly is caused by the general design of the sensor - quite admirably it tries to minimize energy usage, but that comes with added complexity to get it to wake up, calibrate, and provide measurements. Would be interesting to compare this against a BME280 that's sealed in a similar way. I know the BME280 is much more reliable and quicker, but at what cost (energy consumption)?
GWP supplies 5V to all sensors. Here is a copy of our latest AM2315 thoughts (referring to OurWeather, which is 3.3V but still applicable).
2) The AM2315 problem - It has been dramatically improved, but not solved. It only seems to affect some users now. I am thinking it is power and noise related. It could be a 5V/3.3V issue. The Raspberry Pi with Pi2Grover seems to have fewer problems (5V versus 3.3V) I know a way to solve the lockup problem,, but it requires some additional hardware. This seems to be related to the AM2315 itself and not the OurWeather itself. We are looking at updating the OurWeather hardware base board to solve the lockup on the AM2315 and we can also supply the hardware for you to do it yourself. Grove PowerSave is the off the shelf solution. A key piece of information here is that when the AM2315 fails or locks up, power cycling it always fixes it.
Post by triggerfish on Dec 31, 2018 7:34:25 GMT -8
In my experience the AM2315 did not dramatically improve. It may provide better reading in general, but when a problem hits, it hits hard. With the previous versions the general program loop kept working, sometimes solving the problem itself. I used to save every last good read to use with a bad read. When things go bad now, there is no recovery, but power cycling...
That power cycling can apparently done locally on the AM2315 itself somehow... Which leads to the question : how and what will that cost additionally? And what guarantee is there the problem is solved. Since you apparently are not able to reproduce, how an you be sure this is the fix?
It may provide better reading in general, but when a problem hits, it hits hard. With the previous versions the general program loop kept working, sometimes solving the problem itself. I used to save every last good read to use with a bad read. When things go bad now, there is no recovery, but power cycling...
In looking at all of these problems, it looks like adding a GrovePowerSave between the AM2315 and the I2C bus controlled by a GPIO pin will fix this.
Here is the link to a Grove Power Save. Eventually we may redo the kit to include this or add it to the main weather board.