|
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.
|
|
|
Post by doxidad on Dec 28, 2018 7:10:10 GMT -8
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.
Hope this helps (and is the problem) TR
|
|
|
Post by brakow on Dec 28, 2018 7:56:52 GMT -8
@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.
|
|
|
Post by SDL on Dec 28, 2018 8:52:51 GMT -8
Brakow,
Summarize the issues you are seeing. Then let's talk about the ISO image. That is a good suggestion.
BP
|
|
|
Post by triggerfish on Dec 28, 2018 11:10:11 GMT -8
TR
Will try to leave out the graph scheduling when the station is recharged and running again.
Thanks for the tip.
Best regards, Peter
|
|
|
Post by brakow on Dec 28, 2018 11:57:49 GMT -8
@switchdoc, Grove Weather Pi BlynkAbove 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.
|
|
|
Post by SDL on Dec 28, 2018 16:37:45 GMT -8
That means you aren't receiving any information from the AM2315.
Check out the wiring of your AM2315. That is the problem. Test the AM2315 sensor by unplugging the I2C Mux and plugging the AM2315 directly into the Pi2Grover I2C bus.
run "i2cdetect -y 1" twice really quickly and see if you pick up the AM2315 (0x53).
Run the testAM2315.py program under the SDL_Pi_GroveWeatherPi/SDL_Pi_AM2315/ directory and see if you are getting values.
BP
|
|
|
Post by lbendlin on Dec 29, 2018 12:13:24 GMT -8
It's at 0x5c.
sudo i2cdetect -y 1
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- 43 -- -- -- -- 48 -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- 5c -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 6f
70: -- -- -- -- -- -- 76 --
Also make sure it gets 5V at Vcc, it doesn't like 3.3V too much.
Here's my sample code - I simply repeat the read until the 2315 comes to it senses or has failed five times.
class AM2315(object):
def __init__(self, address=AM2315_I2CADDR):
self._address = address
self._bus = smbus2.SMBus(1)
#wake up
#self._bus.write_byte_data(self._address, AM2315_READREG ,0x00)
def _read_data(self):
self.count = 1
tmp = 0
while self.count <= MAXREADATTEMPT:
try:
time.sleep(0.5)
# TELL THE DEVICE WE WANT 4 WORDS OF DATA
self._bus.write_i2c_block_data(self._address,AM2315_READREG,[0x00, 0x04])
time.sleep(0.1)
tmp = self._bus.read_i2c_block_data(self._address,AM2315_READREG,8)
if tmp[2] != None:
self.humidity = ((tmp[2] << 8) | tmp[3]) / 10.0
if self.humidity == 0.1:
self.humidity=100.0
self.temperature_c = (((tmp[4] & 0x7F) << 8) | tmp[5]) / 10.0
if (tmp[4] & 0x80):
self.temperature_c = -self.temperature_c
self.temperature = self.temperature_c * 1.8 + 32
if self.temperature > -100.0:
break
except:
self.count += 1
# GET THE DATA OUT OF THE LIST WE READ
def read_humidity_temperature(self):
self._read_data()
return (self.humidity, self.temperature, self.temperature_c,self.count)
|
|
|
Post by triggerfish on Dec 29, 2018 13:31:00 GMT -8
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.
|
|
hvrooyen
New Member
Posts: 32
Raspberry Pi: Yes
Other Device: Arduino
|
Post by hvrooyen on Dec 29, 2018 22:56:55 GMT -8
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.
|
|
hvrooyen
New Member
Posts: 32
Raspberry Pi: Yes
Other Device: Arduino
|
Post by hvrooyen on Dec 29, 2018 23:19:26 GMT -8
lbendlin: 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?)
|
|
|
Post by lbendlin on Dec 30, 2018 7:27:58 GMT -8
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)?
|
|
|
Post by SDL on Dec 30, 2018 9:25:43 GMT -8
lbendlin, 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. Read more: forum.switchdoc.com/thread/753/comments-regarding-freeze-problem-v35#ixzz5bBn12CBEBP
|
|
|
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?
|
|
|
Post by SDL on Dec 31, 2018 14:06:39 GMT -8
Peter, Would you describe what you mean by: 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. shop.switchdoc.com/products/grovepowersave-control-grove-device-power-with-your-computer-perfect-for-solar-powerBP
|
|