Page 22 of 47 FirstFirst ... 12171819202122232425262732 ... LastLast
Results 211 to 220 of 464

Thread: Evohome app broken

  1. #211
    Automated Home Legend
    Join Date
    Sep 2014
    Location
    Scotland
    Posts
    2,361

    Default

    Quote Originally Posted by gordonb3 View Post
    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.
    Quote Originally Posted by gordonb3 View Post
    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.

  2. #212
    Automated Home Legend
    Join Date
    Sep 2014
    Location
    Scotland
    Posts
    2,361

    Default

    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.

  3. #213
    Automated Home Ninja
    Join Date
    Dec 2016
    Posts
    273

    Default

    Quote Originally Posted by DBMandrake View Post
    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.
    Last edited by gordonb3; 17th February 2019 at 08:04 PM.

  4. #214
    Automated Home Sr Member
    Join Date
    Feb 2018
    Posts
    57

    Default

    Quote Originally Posted by DBMandrake View Post
    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.

  5. #215
    Automated Home Jr Member
    Join Date
    Aug 2018
    Posts
    45

    Default

    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.

  6. #216
    Automated Home Ninja
    Join Date
    Dec 2016
    Posts
    273

    Default

    Quote Originally Posted by BuxtonJim View Post
    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.

  7. #217
    Automated Home Guru
    Join Date
    Mar 2017
    Posts
    177

    Default

    I also have an occasional problem with overrides not being accepted

  8. #218
    Automated Home Legend
    Join Date
    Sep 2014
    Location
    Scotland
    Posts
    2,361

    Default

    Quote Originally Posted by gordonb3 View Post
    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:

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

    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 ?

  9. #219
    Automated Home Jr Member
    Join Date
    Feb 2019
    Location
    Salford, Greater Manchester, United Kingdom
    Posts
    18

    Default

    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?

  10. #220
    Automated Home Guru
    Join Date
    Jan 2018
    Posts
    106

    Default

    Quote Originally Posted by rjtucker View Post
    the lan2rf gateway?
    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...

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •