Originally posted by Krejt
View Post
Decoded - EvoHome API access to control remotely.
Collapse
X
-
I'm recently installed evoHome in our house for 4 UFH and 6 radiator zones plus the hot water bolt on. It's working fairly well but I'm disappointed in the lack of graphs showing actual vs desired vs heat demand hence my interest in the API.
It's great to see the hard work already gone into understanding the API and it was therefore easy for me to get the PHP clients et al pulling down data for my install.
However I'm unable to find data points which indicate 1) if a particular zone is calling for heat (which you don't see visually on the central controller either) and 2) an indication if the zone is in "Optimised Start" mode e.g. its starting heating in advance of a set point to ensure that set point is meet? Neither data is shown in the iOS app either.
I'm looking at data returned from the "https://tccna.honeywell.com/WebAPI/emea/api/v1/location/[loc]/status?includeTemperatureControlSystems=True" call.
Anyone find a way to obtain or derive the above two data points?
Thanks in advance
Comment
-
-
I think the general consensus is that heat demand and optimal start information is not available through the Web API, and only a software update on the controller would ever make that possible.
If you were monitoring the wireless traffic between devices with an HCI80 then theoretically the heat demand of each zone thermostat would be available however optimal start information would not because zone thermostats just see that as a set point change occurring earlier than it otherwise would. They have no knowledge in the over the air protocol of why that set point changed and whether it might be earlier than a scheduled time.
Comment
-
-
Hi All,
First, a big thanks to everyone who's contributed to this thread. I'm writing an app to connect to EvoHome and it wouldn't be possible without the people here.
Some questions I have about the EvoHome API:
1) Is it possible to obtain information about the battery status of rad valves?
[I can't see anything, but perhaps it's accessible from another endpoint like zone schedules?]
2) Is it possible to determine if the 'window function' is active or not for a zone?
[This is something the main EvoHome controller displays so I hope to replicate it in my app. At the moment I've having to deduce that the 'window function' is active if the setpoint has dropped to 5C and the mode is not 'Off' and the setpoint is not 5C in the schedule.]
3) Is it possible to obtain the temperature setpoint when it has been overridden at the rad valve?
[Overrides set using the main controller or the smartphone app seems to be reported, but if the setpoint is over-ridden at the rad valve it never seems to be reported. I suspect this isn't possible without a controller firmware update.]
4) Has anyone (as an individual customer) had any luck gaining access to the official API documentation and support via Honeywell themselves?
Thanks
Comment
-
-
Originally posted by zcapr17 View PostHi All,
First, a big thanks to everyone who's contributed to this thread. I'm writing an app to connect to EvoHome and it wouldn't be possible without the people here.
Some questions I have about the EvoHome API:
1) Is it possible to obtain information about the battery status of rad valves?
[I can't see anything, but perhaps it's accessible from another endpoint like zone schedules?]
2) Is it possible to determine if the 'window function' is active or not for a zone?
[This is something the main EvoHome controller displays so I hope to replicate it in my app. At the moment I've having to deduce that the 'window function' is active if the setpoint has dropped to 5C and the mode is not 'Off' and the setpoint is not 5C in the schedule.]
3) Is it possible to obtain the temperature setpoint when it has been overridden at the rad valve?
[Overrides set using the main controller or the smartphone app seems to be reported, but if the setpoint is over-ridden at the rad valve it never seems to be reported. I suspect this isn't possible without a controller firmware update.]
If you have the new Wifi model controller you should by now have received a firmware update for the controller which enables reporting HR92 overrides back to the controller - as a consequence the phone apps and API will also now indicate the HR92 local overrides. In effect the controller with new firmware converts a local override into a timed zone override, but only for single room zones.
Comment
-
-
Originally posted by DBMandrake View PostWhat model of controller do you have ? If you have the original colour controller with the separate RFG100 then no, HR92 local overrides are never reported back to the controller and thus aren't reported via the API either. Honeywell have indicated that no updates are forthcoming for this model controller so you are out of luck if you have this model.
If you have the new Wifi model controller you should by now have received a firmware update for the controller which enables reporting HR92 overrides back to the controller - as a consequence the phone apps and API will also now indicate the HR92 local overrides. In effect the controller with new firmware converts a local override into a timed zone override, but only for single room zones.
Comment
-
-
One more thing… having just re-read this thread I’ve noticed people are referring to different versions of the API (“v1”, “v2”, "US" vs "EMEA") and I’m now not sure which version I’m using and, more importantly, which is the best one to use.
At the moment my app is authenticating using: https://tccna.honeywell.com/Auth/OAuth/Token
Then GETting and POSTing objects using: https://tccna.honeywell.com/WebAPI/emea/api/v1/...
I had assumed that this is the latest and greatest version of the API for EMEA, is this correct?
However, I’ve also seen references to:
https://rs.alarmnet.com/TotalConnect...PI/api/Session
https://rs.alarmnet.com/TotalConnect...I/emea/api/v1/
Is anyone able to summarise the differences between all the various versions of the API, which ones to use when, and if any of them are depreciated?
Many Thanks.
Comment
-
-
Got an email from Honeywell today:
We noticed that you are using an old version of the Total Connect Comfort Intl app on at least one of your mobile devices.
The following versions of the app will no longer be supported and will stop working on the 20th of April 2016:
• 1.3.6
• 2.2.16
• 3.0.25
Anyone know any more about this, will all our custom apps using the 'b013aa26-9724-4dbd-8897-048b9aada249' applicationId stop working next week?!? Is there a newer applicationId that we can use? Or am I just getting worried over nothing?
Comment
-
-
Originally posted by zcapr17 View PostGot an email from Honeywell today:
Thing is, the only mobile app I'm using is the latest iOS one (4.0.9), so I suspect Honeywell think I'm using an older product because of the applicationId ('b013aa26-9724-4dbd-8897-048b9aada249') that's embedded the custom app I've developed, which uses the ../emea/api/v1/.. API.
Anyone know any more about this, will all our custom apps using the 'b013aa26-9724-4dbd-8897-048b9aada249' applicationId stop working next week?!? Is there a newer applicationId that we can use? Or am I just getting worried over nothing?
Should be using much newer:
https://tccna.honeywell.com/WebAPI/api/......
As mentioned by Joe(Jack)@Honeywell USA who appeared here much earlier this year.
I've got old/current test/debug programs (Windows) that connects to all the old and new URLs with different params so I can test on the 20th.
Of note - I have not received such an email (yet), but I don't use the old URLs.
Comment
-
-
Originally posted by MrB View PostI would guess it's to do with the old AlarmNet URL
Should be using much newer:
https://tccna.honeywell.com/WebAPI/api/......
As mentioned by Joe(Jack)@Honeywell USA who appeared here much earlier this year.
I've got old/current test/debug programs (Windows) that connects to all the old and new URLs with different params so I can test on the 20th.
Of note - I have not received such an email (yet), but I don't use the old URLs.
FYI, the app I've developed is an (unofficial) Evohome connector for SmartThings, since SmartThings' development of the official app appears to have ground to a halt. It's written in Groovy. If anyone's interested, see https://community.smartthings.com/t/...egration/44953 and https://github.com/codersaur/SmartThings
Comment
-
-
Yup Paul, Wireshark..... or Honeywell!
( Both the Evohomeclient and evohomeclient2 currently use the https://tccna.honeywell.com domain.
The evohomeclient uses the ApplicationId 91db1612-73fd-4500-91b2-e63b069b185c and URL's like https://tccna.honeywell.com/WebAPI/api/...
The evohomeclient2 uses the applicationId b013aa26-9724-4dbd-8897-048b9aada249 and URL's like https://tccna.honeywell.com/WebAPI/emea/api/v1/..... )
On my Raspberry Pi I use the evohomeclient2 and do not remember to have recieved the mail mentioned above in the mailbox of the related Total Connect Comfort account, but I might have missed it?
And since Zcapr17 in his SmartThings connector uses the same https://tccna.honeywell.com/ domain, the /WebAPI/emea/api/v1/..... URI and the b013aa26-9724-4dbd-8897-048b9aada249' applicationId we might all face breakdown next week!
Good idea to fire up Wireshark (who?),.. and let's ask Honeywell to provide some more information and guidance on using the API? It is about time....
@Honeywell: It isn't very 2016 to have us sniff and reverse engineer your API! Please provide some information and guidance in the discussion above first, and include Evohome in your Connected Home open API program (https://developer.honeywell.com/) quickly?Evohomeclient temperatures on ThingSpeak: https://thingspeak.com/channels/79213
Comment
-
Comment