If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Not too big on python myself and I also hate the fact that running watchforstock's library takes 40-50 seconds to load and execute on the embedded system I use. But as far as I can see python does not appear to have a mechanism for privatizing variables, so you should be able to dump the API key to screen using `print client.access_token` (and its expiration time `client.access_token_expires`).

The only real problem here is that the client init procedure automatically calls the _login method. You need to delete that line in the library and then let your script decide whether to inject the API key from local storage or run the usual login procedure.

Originally Posted by gordonb3

Previous entry should apply to both APIs. In both cases the library requires you to supply your credentials on creation of the client object and neither one needs a separate call to the login procedure. Both login procedures return a token that must be sent with every subsequent call and is thus stored within the client object, so between runs you can save and restore that token rather than request a new one by logging in again.

Printing client.access_token and client.access_token_expiry in my simplified test script does indeed work, so you've given me an idea.

Instead of modifying the library I may be able to duplicate some of the client init procedure in my own script minus calling _login as a workaround. Effectively I'd be adding my own library function to do a cached login but just within my own script, and keeping track of the token and expiry manually in my own script.

I'm not sure of the intricacies of how python libraries work when they are imported (I just know how to import them and call their methods) and how feasible that is but I'll have a look into it.

At least until the library itself supports caching of the token across script instances (if it ever does) it might be a usable workaround.

Started to look at the library to figure out how to do this and I'm lost.

I've opened a Github issue for the library instead going into as much detail as possible as there are several contributors to the code so maybe one of them will be able to look at it.

I don't think what you intend to do can work. Creating the object/instance will cause the "__init_" procedure to be executed. Of course a failed login due to the imposed session limit does not keep you from still inserting the auth key from the previous session, but then you still need to call the routine that fetches your userId that is required to query the installation info and status.

Following the logic, __init_ calls _login (which you should prevent). _login calls _basic_login (which performs the actual login and stores the auth key), then calls get user info (this you must do) and finally a get installation info which is probably pointless because you are likely to do a get full installation info call in your script.

Edit: of course you could also cache the user ID and possibly other static info as well. Whether that simplifies the challenge at hand or complicates even more is a bit hard to answer.

Started to look at the library to figure out how to do this and I'm lost.

I've opened a Github issue for the library instead going into as much detail as possible as there are several contributors to the code so maybe one of them will be able to look at it.

I had prevously put together a nodejs app to query evohome servers as part of a web based schedule editor for evohome. This app cache's the token and only renews it when required. Although originally for schedule editing, I added some endpoints to provide the raw data for each zone etc. Not sure how well it would run on your Rpi's ,but if you think might help, I can upload to github.

Genuinely not wishing to knock this discussion off Python which (to my shame) I've never investigated but is anyone else finding the app generally a little more stable? Or the cynical part of me suspects the server load has reduced as users give up until March.

Genuinely not wishing to knock this discussion off Python which (to my shame) I've never investigated but is anyone else finding the app generally a little more stable? Or the cynical part of me suspects the server load has reduced as users give up until March.

I still have the occasional issue with overrides being accepted by the portal but not executed by my home system.

I don't think what you intend to do can work. Creating the object/instance will cause the "__init_" procedure to be executed. Of course a failed login due to the imposed session limit does not keep you from still inserting the auth key from the previous session, but then you still need to call the routine that fetches your userId that is required to query the installation info and status.

Following the logic, __init_ calls _login (which you should prevent). _login calls _basic_login (which performs the actual login and stores the auth key), then calls get user info (this you must do) and finally a get installation info which is probably pointless because you are likely to do a get full installation info call in your script.

Edit: of course you could also cache the user ID and possibly other static info as well. Whether that simplifies the challenge at hand or complicates even more is a bit hard to answer.

You're right, what I was thinking of doing wouldn't have worked, so I'm glad I didn't spend too much time on a fruitless endeavour.

Good news though, there have already been replies to my github issue and an updated test version of the library that supports saving the client token manually from the calling script and re-submitting it on a following session - it'll be a few days before I have time to do some testing on this, but it looks like the EvohomeClient() call automatically takes care of deciding whether to use the token or the username and password which are both submitted during the call:

A quick question - as described in that github issue, the V1 API apparently doesn't return a token expiry time, do you use the V1 API at all or only the V2 API ? If you do use the V1 API do you know what the token timeout for the V1 API is or whether it can be found from any of the response headers ?

Had an email from Intergas yesterday (after I wrote to them being unable to log in to the lan2rf gateway:

We are having an issue with the Intouch/ comfort touch software at the moment and its not allowing customers access to the apps. Our IT team in Holland are working hard to resolve the issues asap. You can still control the boiler via the Honeywell small room stat.

I only had the Intergas boiler installed last week. Last weekend my primary email address was compromised *suspicious successful logins. The email company say it may be the device server shooting off smtp messages. Anyone any comments?

I had problems recently myself. But I haven't had any warnings about suspicious logins.

In any case, I am a little fed up with it, and really want to access the 'cv_return_temp', which the public RESTful API doesn't provide. I was going to make a diagnostic cable, and see how I go from there: IntergasBoilerReader

Or another option is via RF, or hack into the RESTful API used by the Intouch Service (for installers) app (I can see a way forward with this, but wonder if it's best option).

FWIW, I wrote a python client library to interface with the Lan2RF gateway: intouch-client & I'd love people to test it out. It doesn't have thermostats yet, if someone wants to help with that...