Honeywell EvoHome support coming?

By the way - I sent an email to UK Support to get on the beta test and had a reply within a day - so may be worth trying again.

If you want to set the EvoHome mode from a smartapp, here’s what I came up with:

// Set EvoHome thermostatMode:

def t = thermostats[0] // Only select one thermostat as changes will affect the whole EvoHome system.
log.debug “Mode for ${t} is ${t.latestValue(‘thermostatMode’)}.”
// Could use setThermostatMode() method, but it only works for the commands “emergency heat” “heat” “cool” “off” “auto”. I.e. NOT “away”, “dayOff” or “autoWithEco”.
// Instead we must use switchMode():
// switchMode() takes no args, instead it can only cycle through the modes: “auto” → “off” → “autoWithEco” → “away” → “dayOff” → …
while (t.latestValue(‘thermostatMode’) != ‘away’) {
log.debug “Switching mode for ${t}.”
log.debug “Mode for ${t} is now ${t.latestValue(‘thermostatMode’)}.”

It’s a bit messy as you have to cycle through the modes, which means it’s very difficult to do via Rule Machine, so at the moment I actually just use IFTTT to set my EvoHome mode based on my keyfob presense sensor, which works well.

Obviously, what the developers need to do is update the setThermostatMode() method to allow setting of other EvoHome-specific modes such as “away” / “dayOff” / “autoWithEco” (Economy). Also, switchMode() would be better-named cycleMode() :wink:



This could be very helpful. You could post it on the evohome beta thread? I however don’t understand code. I have set up some rules that send multiple SwitchMode commands, (ie if you’re in Auto, send switchmode x3 to change to Away, etc. I guess it works the same way. I have found this to be a little unreliable though.

Hi, posted in the beta thread but you can call a thermostat with the setthermostatmode() command
Off, Auto, Away seem to work but can’t get Eco working. Hmm, actually having seen @zcapr17 response perhaps Away doesn’t work either.
Not sure how you’d do it in RuleMachine as I can’t see Expert Mode?

@aaron any input here or on the beta thread from actual smartthings developers would be great. Particularly what functionality has or hasn’t been implemented from Evohome. Can you make non permanent changes?
Does the setthermostatmode() command actually work for all modes? If not, how do we get it to work?
My feedback has been limited so far as I haven’t really been given basic tools to test functionality, I’m just guessing at how it might work. Pretty awful way to run a beta with zero documentation!

Code below to change evohome quick action based on mode changes. Not complete as i don’t have subscriptions etc. but can post in full. Unfortunately, still just guessing at functionality.

def modeChangeHandler(evt) {
log.debug evt.value
def thermoSensorStateold = thermo.currentThermostatMode
log.debug “Old mode is $thermoSensorStateold”

switch (evt.value) {
case "Away":
    log.debug "Setting to Eco as AWAY"
case "Home":
    log.debug "Setting to Auto as HOME"
case "Holiday":
    log.debug "Setting to Off as HOLIDAY"
    log.debug "Setting to Auto as Default"
def thermoSensorStatenew = thermo.currentThermostatMode
log.debug "New mode is $thermoSensorStatenew"


Hrmmm… Full disclosure: I don’t have a specific update or clarification. Changes are being made to the integration based on feedback from the beta. Still trying to determine timelines, etc. Hang with us!

I managed to get onto the beta after pestering the UK support team by email (FYI, UK support are very helpful, whereas US support are a blackhole). Bearing in mind that I didn’t receive any documentation or instructions, here’s my thoughts to far:

General operation / GUI:

Overall, setup was easy and day-to-day operation works and is reliable. However, the EvoHome thermostat device handler is a bit clunky to say the least.


  • Cycling through the modes is not really usable as it’s too slow (it’s quicker to use the native Evohome app).

Temperature Setpoints:

  • If you change the temperature setpoint it’s permanent, which is annoying as this is different to the behaviour of the native Honeywell app. I would prefer this to be changed so that a manual setpoint is temporary by default (i.e. is overridden by the next scheduled setpoint), or it this is not possible, offer a setting to specify a default amount of time that a manual temperature setpoint should apply for (this could be a setting on the thermostat devices or the SmartApp).
  • There is no visual indication when a setpoint has been overridden. If I manually raise the setpoint, the status in the bottom left still says “Heat Auto” which is misleading (possibly it should say something like “Manual Override”). Same goes for displaying when the setpoint has been adjusted by the ‘optimisation’ logic, or when the ‘open window’ function is active. The native EvoHome controller will display a little icon next to the temperature setpoint to indicate these states, so something similar would be appreciated.
  • It would be wonderful if the temperatures were displayed with consistent precision, although this is a general SmartThings issue and not specific to EvoHome (SmartThings developers, please, please, please allow better control of display formats for smarttiles!!).

SmartApp development:


  • The EvoHome SmartApp and thermostat device handler code is currently hidden, it would be great if we can see the code (most of the issues I’ve raised I could fix myself very quickly if I could edit the code).


  • thermostatMode can be “auto” / “off” / “autoWithEco” / “away” / “dayOff” which is great, but setThermostatMode() does not appear to support setting all these modes! This is really annoying and means it’s not practical to set the thermostatMode from my own SmartApp or Rule Machine (see my post above, it’s actually easier at the moment to use a flag to control via IFTTT, which is plain silly).
  • There is a bug in the switchMode() method which means it sometimes ignores the current thermostatMode, or at least it doesn’t cycle in a consistent order.
  • When thermostatMode is changed the updated state cascades to all EvoHome thermostat devices (as there is effectively only one thermostat mode for the whole EvoHome system) however there can be a significant delay (2-20s) for all devices to update, it should be possible to improve this.
  • It would be great if each EvoHome thermostat had an independent thermostatMode, although I’m pretty sure this is a native EvoHome limitation rather than a SmartThings one.

Temperature Setpoints:

  • If would be great if the setHeatingSetPoint() method supported a time period akin to the native EvoHome functionality. E.g. “set to 22C for 2 hours”: setHeatingSetPoint(22,120). Plus, also allowed the time period to be aligned with the next scheduled setpoint change. Ditto for raiseSetPoint() and lowerSetPoint().
  • I would also like a method to be able to retrieve information about when the next scheduled setpoint is, and what the temperature is due to be set to. e.g. getNextSetPointTime() and getNextSetPointTemp()



@zcapr17 Do you have access to the beta thread?
I’m currently flipping between the beta thread and this one, and it’s a pain.

Yours is one of the most comprehensive bits of feedback so far, and echoes some of my findings …wanted to comment on your thread, but would prefer to consolidate such comments on the beta thread.

I tried searching for it, but I can’t see any other thread…

Probably cos you haven’t been granted access. I replied to your message saying the same, but included the link

Slight glitch, all Evohome thermostats stopped updating in SmartThings this morning. I had re-connect the SmartApp to Evohome to get it working again… anyone else with this issue?

Yes it happens relatively frequently. Logging back into Honeywell on the SmartApp is usually all you need to do. UK Support are aware of this as I’ve informed them on a couple of occasions and also posted about on it on this thread, or maybe it was the beta thread…

Still haven’t been grant access to the beta thread. Not had any connectivity or update issues before, but I can see refreshAuthToken() is now failing every 5 minutes… so it’s all broken for me right now.

> <guid>  ‎13‎:‎48‎:‎51: debug ___exception polling children: Unauthorized 
> <guid>‎  13‎:‎48‎:‎51: error refreshAuthToken() >> Error: e.statusCode 400 
> <guid>  ‎13‎:‎48‎:‎50: debug refreshAuthToken()

Ok, so if logging in again doesn’t work, delete the smartApp and reinstall. That’s what I had to do on one occasion. It’s a pain in the A

I have Beta access but it’s picked up a second single zone thermostat I have in a second location- not the primary 12 zone one. Have fed this back, but does anyone know if I can tweak the device ID in API to the MAC/ CRC of the other Evohome controller?

Did you end up getting access to the thread? I am also a beta tester but cannot find the thread anywhere :frowning: Although my observations are similar to others reporting in this thread, I did manage to write a small piece of code that would lower the set temperature to 5 degrees if no one was in the room for 15 minutes. After movement it then restored the set temperature to the initial value (not ideal)

No, never got details- suspect we may have come in too late in the Beta. Your app sounds good, one thing I wanted to do was change temperatures based on presence/ motion. I can’t even see my Evohome rooms in ST yet!

Has anyone been added to the beta recently? Support sent my details across some time ago but I never got a response, I just assumed the beta had closed.
Assuming it is is there any timescale on an open release?

If you want access to the beta thread, just email UK support. They’ll give you access.

Right, I’ve given up waiting for the official Evohome app to be released and have decided to release my own unofficial version.

I’ve created a new thread for it here: [RELEASE] Honeywell Evohome Integration


1 Like

SmartThings is happy to say that we’ve released our Honeywell evohome integration via the Marketplace in the SmartThings app! We apologise for the lengthy wait for this integration. This was due to OAuth stability issues that would cause occasional disconnects, forcing a manual re-authorisation. Honeywell has recently made improvements to their API to correct for this. Please contact SmartThings support if you notice any issues with the Honeywell evohome integration