Decoded - EvoHome API access to control remotely.
Collapse
X
-
Originally posted by Krejt View PostSwitching to the tccna.honeywell.com host doesn't seem to be as simple as to search and replace that host name in all evohomeclient2 files. I tried that (being totally clueless ;-) and hit a HTTP/1.1 404 Not Found error on the very first request. I bet the tccna.honeywell.com machine uses different directories. This is something for smarter guys like watchforstock to look into ;-)
You need to drop the /TotalConnectComfort/ out of the URL.
So from this: https://rs.alarmnet.com/TotalConnect...PI/api/Session
to this: https://tccna.honeywell.com/WebAPI/api/Session
Seems to be working for me so far
Comment
-
-
Perfect! Dropping the /TotalConnectComfort directory from the URL while changing from the rs.alarmnet.com host to the tccna.honeywell.com host did the trick!
I patched my evohomeclient2 and now seem to be able to request temperatures using the V2 API without any error 500 messages. (Just tested for about an hour.)
Note to watchforstock: maybe check the need for the :443 port numbers in your code. This port number isn't consistently declared in the zone.py and hotwater.py files?Evohomeclient temperatures on ThingSpeak: https://thingspeak.com/channels/79213
Comment
-
-
I've updated the library to reflect this change - based on a quick check it seems to be working ok - feedback welcome!
Either download it direct from github at https://github.com/watchforstock/evohome-client or run:
Code:pip install evohomeclient
Code:pip install -U evohomeclient
Last edited by watchforstock; 19 January 2016, 11:05 PM.
Comment
-
-
@watchforstock - Unfortunately no, the US API resource structure is very different from EMEA, different API keys, accounts, devices, etc. Willing to help though if you're interested.developer.honeywell.com | I work for Honeywell. API Evangelist. Views are my own.
Comment
-
-
This is something Honeywell should include, data logging, maybe inside the web interface.
Should be great some enhancements in the iPhone app too, such as the ability to copy the entire week schedule to another zone (feature present on EvoHome Touch Control), and native geofencing inside the app (already present in USA Lyric App), without the need of Life360 and IFTTT.
Schermata 2016-01-19 alle 23.28.07.jpg
Comment
-
-
Originally posted by jzwack-honeywell View PostOriginally posted by watchforstock View PostI've updated the library to reflect this change - based on a quick check it seems to be working ok - feedback welcome!
Either download it direct from github at https://github.com/watchforstock/evohome-client or run:
Code:pip install evohomeclient
Code:pip install -U evohomeclient
I'd also like to thank Joe for joining this thread so that we have some contact with someone from honeywell who works on the API!
As you have probably gathered Joe, the existing libraries and implementations such as the one from watchforstock were originally developed based on a reverse engineering of the over the air protocol, so it's possible that not everything about the API is understood correctly or done correctly - for example we were unaware that the address of the servers had changed, so it's a good thing you came along when you did.
Presumably the mobile apps were updated in a recent update to use the new servers but those of us using the APIs directly were oblivious to the change so would have been wondering what was wrong when the old servers were finally retired!
I have a quick question regarding the V1 and V2 API's - which API is recommended for use for simple tasks such as polling the zone temperatures and set points every 5 minutes for graphing purposes - I had been using the V1 API purely because the V2 API had been returning about 25% HTTP 500 errors, thus leaving lots of gaps in my graph data. As the same data I needed was available from the V1 API and that did not seem to return any errors I used that.
Assuming that the HTTP 500 errors are no longer an issue with the new server address, should I be switching back to the V2 API ? I don't know much about the APIs but I get the impression that the V2 API was implemented to provide for the new iPhone/Android app functionality of configuring schedules remotely which was absent in the V1 API, and it looks like the V2 API functionality is a superset of V1. So is it likely that the V1 API will get phased out any time soon ?
After the update to the server URL's I'm finding both API's much quicker than before - previously the V1 API was taking maybe 10 seconds and the V2 API (when it worked) about 20 seconds. With the new server address the V1 API takes 3 seconds to return all my zone temperature and set point data and the V2 API takes 6 seconds, and so far (touch wood) no HTTP errors.Last edited by DBMandrake; 20 January 2016, 12:47 PM.
Comment
-
-
Originally posted by watchforstock View Post@Krejt - thanks for the note about ports, I've just posted an update to the library which as well as making the changes noted above removes the port numbers. It won't have affected anything, but better to clean up!
V1:
{'temp': 14.0, 'setpoint': 5.0, 'thermostat': u'EMEA_ZONE', 'name': u'Hall', 'id': 1377389}
{'temp': 11.0, 'setpoint': 5.0, 'thermostat': u'EMEA_ZONE', 'name': u'Living Room', 'id': 1378782}
{'temp': 15.5, 'setpoint': 5.0, 'thermostat': u'EMEA_ZONE', 'name': u'Main Bedroom', 'id': 1438045}
V2:
{'temp': 14.0, 'setpoint': 5.0, 'thermostat': 'EMEA_ZONE', 'name': u'Hall', 'id': u'1377389'}
{'temp': 11.0, 'setpoint': 5.0, 'thermostat': 'EMEA_ZONE', 'name': u'Living Room', 'id': u'1378782'}
{'temp': 15.5, 'setpoint': 5.0, 'thermostat': 'EMEA_ZONE', 'name': u'Main Bedroom', 'id': u'1438045'}
Notice the difference at the end after id. Edit: also just before EMEA_ZONE.
Comment
-
-
Yup, this difference in syntax was there already before the recent evoclient update. I noticed this last week already and made a note to investigate the meaning of the 'u'. (user?) Another difference I noticed then was a difference in the order of the zones. Your post suggests that difference is gone? I'll look into this tonight.Evohomeclient temperatures on ThingSpeak: https://thingspeak.com/channels/79213
Comment
-
-
Originally posted by DBMandrake View PostAs you have probably gathered Joe, the existing libraries and implementations such as the one from watchforstock were originally developed based on a reverse engineering of the over the air protocol, so it's possible that not everything about the API is understood correctly or done correctly - for example we were unaware that the address of the servers had changed, so it's a good thing you came along when you did.
Presumably the mobile apps were updated in a recent update to use the new servers but those of us using the APIs directly were oblivious to the change so would have been wondering what was wrong when the old servers were finally retired!
I have a quick question regarding the V1 and V2 API's - which API is recommended for use for simple tasks such as polling the zone temperatures and set points every 5 minutes for graphing purposes - I had been using the V1 API purely because the V2 API had been returning about 25% HTTP 500 errors, thus leaving lots of gaps in my graph data. As the same data I needed was available from the V1 API and that did not seem to return any errors I used that.
Assuming that the HTTP 500 errors are no longer an issue with the new server address, should I be switching back to the V2 API ? I don't know much about the APIs but I get the impression that the V2 API was implemented to provide for the new iPhone/Android app functionality of configuring schedules remotely which was absent in the V1 API, and it looks like the V2 API functionality is a superset of V1. So is it likely that the V1 API will get phased out any time soon ?
After the update to the server URL's I'm finding both API's much quicker than before - previously the V1 API was taking maybe 10 seconds and the V2 API (when it worked) about 20 seconds. With the new server address the V1 API takes 3 seconds to return all my zone temperature and set point data and the V2 API takes 6 seconds, and so far (touch wood) no HTTP errors.
Also, glad you're finding the new endpoint quicker. That was part of the plan!developer.honeywell.com | I work for Honeywell. API Evangelist. Views are my own.
Comment
-
-
jzwack, while we have your attention
Do you know why the API does not return the correct value for a HR92 mode? That is, it always says "Off", but allowedModes indicates that it could return either "Heat" or "Off" depending on whether its calling for heat. This would be useful data to have from the API.
Comment
-
-
You specifically interested in what I would call "runtime"? As in is the valve actually open or closed? I don't know the specific answer to that, but I know in the US we don't enable that on all of our thermostats either. It's a power/firmware problem.developer.honeywell.com | I work for Honeywell. API Evangelist. Views are my own.
Comment
-
-
Originally posted by jzwack-honeywell View PostYou specifically interested in what I would call "runtime"? As in is the valve actually open or closed? I don't know the specific answer to that, but I know in the US we don't enable that on all of our thermostats either. It's a power/firmware problem.
I assumed the controller must know whether a valve is open or not so it can control the boiler demand appropriately. Is this not the case?
Comment
-
Comment