|
|
Post by SDL on Feb 8, 2019 6:31:55 GMT -8
github.com/switchdoclabs/SDL_Pi_GroveWeatherPiWe have implemented a new attempt to fix the long term reliability problems of the AM2315. We changed MAXREADATTEMPT to 10 under ~/SDL_Pi_GroveWeatherPi/SDL_Pi_AM2315.AM2315.py The suggestion for this came from Sopwith and some work he has done on his blog here: sopwith.ismellsmoke.netThanks to Sopwith. It will be interesting if this is the end of it. Best regards, BP
|
|
|
|
Post by triggerfish on Feb 9, 2019 8:39:15 GMT -8
Is that the only change to 3.14? Is the validity still checked with the 10 degrees deviation to the last value?
|
|
|
|
Post by SDL on Feb 9, 2019 10:48:01 GMT -8
Yes, this is the ONLY change. I'm trying to isolate the actual problem.
BP
|
|
|
|
Post by triggerfish on Feb 9, 2019 12:07:02 GMT -8
Can you post the code change? I did too much tweaking myself to get things the way I want to just pull 3.15 over it.
|
|
|
|
Post by SDL on Feb 9, 2019 12:42:38 GMT -8
This is the only functional change.
We changed MAXREADATTEMPT to 10 under
~/SDL_Pi_GroveWeatherPi/SDL_Pi_AM2315.AM2315.py
BP
|
|
|
|
Post by doxidad on Feb 9, 2019 13:26:44 GMT -8
Still reading random BIG negative numbers with 315. Went back to 314 with changes I made.
|
|
|
|
Post by triggerfish on Feb 9, 2019 14:26:24 GMT -8
Maxreads 10 is what I tried in the first place. It just postpones the error, but eventually it gets there.
|
|
|
|
Post by SDL on Feb 10, 2019 10:41:24 GMT -8
Doxidad,
OK. Well that pretty well concludes that. Doxidad, what are the exact changes you made and did they fix the problem?
BP
|
|
|
|
Post by doxidad on Feb 11, 2019 13:31:23 GMT -8
Actually, the changes I made have nothing to do with the AM2315.
Sorry you took it that I had made some great discovery. Wish I did!.
I should have said things differently. 314 seems to be fairly stable for me.
I did see the large negative numbers - Not sure how they were getting through since you have a clamp at -1000.
|
|
|
|
Post by triggerfish on Feb 11, 2019 13:52:40 GMT -8
And I just use humidity in stead of temp reading to check validity. I don't think the am2315 can be fixed to work flawlessly. I just think the module should be able to produce a valid reading with in say ten tries and return that or a False crc. Error handling on all am2315 access should be implemented. Now that is not entirely the case. There is still a condition that after all reads fail, no handling is fond, causing6an exception in the logs.
|
|
|
|
Post by SDL on Feb 11, 2019 18:38:26 GMT -8
Peter,
Update me on your changes to the AM2315 code and let's give that a try.
We still have an option to make it reliable in all cases, a Grove PowerSave.
BP
|
|
|
|
Post by triggerfish on Feb 13, 2019 2:39:52 GMT -8
Peter, Update me on your changes to the AM2315 code and let's give that a try. We still have an option to make it reliable in all cases, a Grove PowerSave. BP I have no more code changes to AM2315. For now, I check the humidity validity in the main program. |
|
|
|
Post by SDL on Feb 13, 2019 13:57:02 GMT -8
Peter,
Post your changes again and I will add them into the main code. Just want to make sure I have them the way you do.
BP
|
|
|
|
Post by triggerfish on Feb 14, 2019 13:52:47 GMT -8
Peter, Post your changes again and I will add them into the main code. Just want to make sure I have them the way you do. BP Hi, At my line 1112, I added the humidity check:
if (crc_check != -1) and (ToutsideHumidity >= 0 and ToutsideHumidity <= 100):
But I still feel that should be handled in the AM2315 driver in the first place. I just was not able to tweak that to my wishes, so I took this "quick and dirty" loophole.
|
|
