Beginners guide to graphing Evohome temperatures using python and plot.ly

[Tempted]

Hi,

Sorry to bring up an old thread. I have been using the method posted by the OP since I got Evohome around a year and a half ago and in the most part it has done all that I need.

That is until I checked my graphs this morning and notice my Emoncms feeds hadn't received data in 18hrs. I tried running the Python script (evologger.py) manually and notice some errors (when I believe previously, it would have given the current temps within the DOS window.Attachment 1217

Could anyone shed any light at all please? Whilst I do work in IT, programming is pretty far removed from my day job to be honest, so I am out of my depth here

So it turns out the scripts that facilitate the evologger logging don't have any error handling for temperatures that aren't numbers. That is to say "- -" throws an error which breaks the whole lot. Someone in the household had 'OK'd' the warning about an actuator battery running flat and thus when it did, it couldn't communicate, hence reporting a null value.

As you were.

[DBMandrake]

Zones that have no temperature reported (hour glass on the controller or - - on the iphone app) are actually still reported by the API as a number, 128.0 degrees C.

I added a patch to evohome-munin a couple of years ago to handle this and prevent it literally being graphed as 128 degrees. (Which kind of ruins an autoscaling graph )

https://github.com/Infern1/evohome-m...4fada13cc6c8f8

[Dbldutch]

First of all, a big thank you for the posters in this section.
I had my app up and running in very little time.
I collect the data in rrdtool repositories, and use the simple graphing of that toolset for my use. It's adequate as far as I'm concerned.

I did however notice a little problem while querying the server. I use cron to do that every 5 minutes, and just about every 5 to 10 queries results in an exception ( TypeError: list indices must be integers, not str) from this line:

userId = userData ['userInfo']['userID']

The root cause is that the query sometimes yields a warning:

userData = [{u'message': u'Request count limitation exceeded, please try again later.', u'code': u'TooManyRequests'}]

An this of course causes the TypeError.

To test this, I have used a try-except around the above line, and simply wait for an additional 30 seconds and try again. This always solves the problem. The better solution is to add a few seconds to the 5 min. repetition rate, or use an appropriate sleeptime in the code to extend the 5 min of the cron timer.

The net-net is that it seems that a repetition of 5 minutes is just about on the border.

[Dbldutch]

The TypeError is caused by the server sending you a message that you exceeded the number of times with a request. The maximum time seems to be just over 5 minutes. I have put the statement in a try-except and simply wait 30 secs before I try again.

[DBMandrake]

Authentication attempts are severely rate limited since about August 2018, so if the script re-authenticates for every polling period you will have problems, even with a 5 minute polling period.

Actual API requests are not rate limited only authentication requests so if the script is re-written to cache the session id or access token (depending on API used) between runs it will solve the issue.

For a very long winded discussion on this issue and how it was solved for the evohome-client library have a look here:

https://github.com/watchforstock/evo...ient/issues/57

Without looking back through this thread I'm not sure if it uses watchforstock's evohome-client library - if it does, you'd want to update to the latest version in master and then make some modifications to the script to save and restore session id or access token between runs.

[Dbldutch]

Thank you, in the very many posts about this topic, I missed this development.
I'll update my code.