Resideo API Binding for Honeywell Thermostats and Sensors

Add-on Marketplace Bundles
,
41

I’m just in the middle of adding fan support. I see you have a fan also are you able to make sure the changes for the fan work okay? Then I can add the EmergencyHeat support.

Does it fail if the thermostatSetpointStatus is NOT set to PermanentHold? Can I get away with setting just mode and the extra emergencyHeatActive flag?

EDIT:

I take it back, it was a two line add as long as I don’t need to futz with the thermostatSetpointStatus. So I added it, you just need to be prepared that the fan support needs testing and I have no fan on my system so it’s a bit of a black box.

42

Does it fail if the thermostatSetpointStatus is NOT set to PermanentHold ?

no, as long as you send it when calling the api, the value doesn’t matter.

I will happily test your fan function!

43

So here is the update it contains three changes:

  • Support for new modes, they will show up based on the feed information;
  • Special processing support for EmergencyHeat mode;
  • Support for setting the fan function.

For the emergencyHeatActive flag it is just set on entering the EmergencyHeat mode and ignored on all other modes. You can not send:

...
"mode": "EmergencyHeat",
"emergencyHeatActive": false,
...

https://github.com/protectivedad/openhab-addons/releases/download/beta-v1.6c/org.openhab.binding.honeywell-4.2.3-SNAPSHOT.jar

EDIT:
I am worried that the emergencyHeatActive might be a little ‘sticky’. When switching to EmergencyHeat the flag is set. When the scheduled data from Honeywell is received the flag is ‘erased’. So if you set the mode and unset the mode quickly the unset might error out depending on how the API handles it. Please, test if you switch to EmergencyHeat and then switch back to Heat before the system receives a scheduled update whether it fails.

44

I’m testing it live.

First, setting the mode to Emergency with the binding is working. The thermostat changed his mode but in OpenHab, it was reset to Heat without doing anything else.

For the fan, it works as expected. The three available modes are sent correctly to the API and the scheduled response, corresponds to the status as programmed

45

Okay. With the thermostat set to regular heat mode start a trace and make sure to capture a data structure (they will probably be the same as the ones you provided earlier, but I want a new baseline). Then while tracing change the mode to Emergency. Does it change back right away or after the scheduled update from the API? After it changes back stop the trace and send it to me.

EDIT:
I should have asked this before. What is the purpose of the emergency mode? How is it used from a user perspective?

46

Here is the scheduled update from the API.

Raw ScheduleData: '{"displayedOutdoorHumidity":86,"vacationHold":{"enabled":false},"currentSchedulePeriod":{"day":"Monday","period":"Wake"},"scheduleCapabilities":{"availableScheduleTypes":["None","Geofenced","TimedNorthAmerica"],"schedulableFan":false},"scheduleType":{"scheduleType": "Timed","scheduleSubType":"NA"},"changeSource":{"by":"partner","name":"Openhab43"},"scheduleStatus":"Pause","allowedTimeIncrements":15,"settings":{"hardwareSettings":{"bright ness":0,"maxBrightness":5},"fan":{"allowedModes":["On","Auto","Circulate"],"changeableValues":{"mode":"Auto"}},"temperatureMode":{"air":true},"specialMode":{"emergencyHeatAct ive":true},"devicePairingEnabled":true},"deviceOsVersion":"TH6220WF2006","deviceClass":"Thermostat","deviceType":"Thermostat","deviceID":"LCC-48A2E6BAFB4C","deviceInternalID" :7062669,"userDefinedDeviceName":"Thermostat","name":"Thermostat","isAlive":true,"isUpgrading":false,"isProvisioned":true,"macID":"48A2E6BAFB4C","deviceSettings":{},"service" :{"mode":"Up"},"deviceRegistrationDate":"2025-01-08T19:24:30.1633333","dataSyncStatus":"Completed","deviceSerialNo":"2306LBJ03159","units":"Celsius","indoorTemperature":19.5, "outdoorTemperature":-21,"allowedModes":["EmergencyHeat","Heat","Off","Cool"],"deadband":0,"hasDualSetpointStatus":false,"minHeatSetpoint":10,"maxHeatSetpoint":26,"minCoolSet point":18,"maxCoolSetpoint":32,"changeableValues":{"mode":"Heat","emergencyHeatActive":true,"heatSetpoint":21,"coolSetpoint":24,"thermostatSetpointStatus":"PermanentHold","he atCoolMode":"Heat","endHeatSetpoint":null,"endCoolSetpoint":null},"operationStatus":{"mode":"EmergencyHeat","fanRequest":true,"circulationFanRequest":false},"deviceModel":"T5 -T6"}'
Raw FanData: '{"allowedModes":["On","Auto","Circulate"],"changeableValues":{"mode":"Auto"}}'
Raw ConstraintsData: '{"allowedModes":["EmergencyHeat","Heat","Off","Cool"],"allowedTimeIncrements":15,"minHeat Setpoint":10,"maxHeatSetpoint":26,"minCoolSetpoint":18,"maxCoolSetpoint":32}'
Raw ChangeableValuesData: '{"mode":"Heat","emergencyHeatActive":true,"heatSetpoint":21,"coolSetpoint":24,"therm ostatSetpointStatus":"PermanentHold","heatCoolMode":"Heat","endHeatSetpoint":null,"endCoolSetpoint":null}'
47

I should have asked this before. What is the purpose of the emergency mode? How is it used from a user perspective?

When it’s very cold outside and you have to go from 19 Celsius to 21 Celsius, for example. It is quite possible that the heat pump will take a long time to reach the set temperature, as it is less effective at temperatures below -20 Celisus. In this case, it is possible for us to use a heating element (+/- 18kW) to temporarily replace the heat pump in order to reach our set temperature faster but with more energy consumption. This is a mode that must be activated manually. So in my case, if I consider that using emergency mode is advantageous, I can call it manually.

48 
Raw DeviceData: '{
    "displayedOutdoorHumidity": 86,
    "vacationHold": {
      "enabled": false
    },
    "currentSchedulePeriod": {
      "day": "Monday",
      "period": "Wake"
    },
    "scheduleCapabilities": {
      "availableScheduleTypes": [
        "None",
        "Geofenced",
        "TimedNorthAmerica"
      ],
      "schedulableFan": false
    },
    "scheduleType": {
      "scheduleType": "Timed",
      "scheduleSubType": "NA"
    },
    "changeSource": {
      "by": "partner",
      "name": "Openhab43"
    },
    "scheduleStatus": "Pause",
    "allowedTimeIncrements": 15,
    "settings": {
      "hardwareSettings": {
        "brightness": 0,
        "maxBrightness": 5
      },
      "fan": {
        "allowedModes": [
            "On",
            "Auto",
            "Circulate"
          ],
          "changeableValues": {
            "mode": "Auto"
          }
        },
        "temperatureMode": {
          "air": true
        },
        "specialMode": {
          "emergencyHeatActive": true
        },
        "devicePairingEnabled": true
      },
      "deviceOsVersion": "TH6220WF2006",
      "deviceClass": "Thermostat",
      "deviceType": "Thermostat",
      "deviceID": "LCC-48A2E6BAFB4C",
      "deviceInternalID": 7062669,
      "userDefinedDeviceName": "Thermostat",
      "name": "Thermostat",
      "isAlive": true,
      "isUpgrading": false,
      "isProvisioned": true,
      "macID": "48A2E6BAFB4C",
      "deviceSettings": {},
      "mode": "Up"
    },
    "deviceRegistrationDate": "2025-01-08T19:24:30.1633333",
    "dataSyncStatus": "Completed",
    "deviceSerialNo": "2306LBJ03159",
    "units": "Celsius",
    "indoorTemperature": 21,
    "outdoorTemperature": -21,
    "allowedModes": [
      "EmergencyHeat",
      "Heat",
      "Off",
      "Cool"
    ],
    "deadband": 0,
    "hasDualSetpointStatus": false,
    "minHeatSetpoint": 10,
    "maxHeatSetpoint": 26,
    "minCoolSetpoint": 18,
    "maxCoolSetpoint": 32,
    "changeableValues": {
      "mode": "Heat",
      "emergencyHeatActive": true,
      "heatSetpoint": 21,
      "coolSetpoint": 24,
      "thermostatSetpointStatus": "PermanentHold",
      "heatCoolMode": "Heat",
      "endHeatSetpoint": null,
      "endCoolSetpoint": null
    },
    "operationStatus": {
      "mode": "EquipmentOff",
      "fanRequest": false,
      "circulationFanRequest": false
    },
    "deviceModel": "T5-T6"
  }'
49

So the EmergencyHeat mode seems to be working as it is currently implemented. The system sends the mode EmergencyHeat with the flag emergencyHeatActive set to true. This turns on the mode. The Resideo API from this point forward sends back the mode Heat which is what is displayed. If you resubmit Heat does it turn off the emergency mode? If not then, what is the submission that turns off the mode? The API document say don’t send emergencyHeatActive except with mode EmergencyHeat.

EDIT:
As asked does changing the mode cause it to turn off emergencyHeatActive, or does the system have submit:

...
"mode": "EmergencyHeat",
"emergencyHeatActive": false,
...

What a pain. They couldn’t just keep it consistent. EmergencyHeat turns on Heat turns off. Argh.

Assuming that you find that submitting the flag as true/false turns on and off the EmergencyHeat function. I think the best way is for people who have the EmergencyHeat mode create a channel for the flag and have changing the flag submit the proper API call. And just ignore the mode in the list of allowed entries.

50

ok I sent an Emergency Heat using openhab. It works as expected. Then, the API return the status as “Heat”. Also expected. After receiving the update from the API, I sent back a Heat mode and emergencyHeatActive switch to false. My question, if we use this method, is how can I deal with systemStatusMode item in my rules if it change back to a false Heat mode after a few minute? Is it possible to add a channel for the emergencyHeatActive? While this flag is ON, it overwrite the thermostatsSystemMode or ignoring it? I agree, it’s a pain. I think they did it this way because EmergencyHeat isn’t schedulable within the thermostat… Don’t know…

51

This wasn’t the most clear I was think typing. :slight_smile: I will create a switch channel for the emergency heat. You turn it on/off and it will send the proper mode/flag combination. The mode will always show Heat and you can base a rule on the flag. I’m going to let it percolate for a day or so and see how I can implement it.

EDIT:

I want to clarify. Will setting the mode to Heat clear the emergencyHeatActive flag or did you have to send a special API with the json 'emergencyHeatActive': false? Did you try a special API with:

...
"mode": "EmergencyHeat",
"emergencyHeatActive": false,
...
52

ok got it. To switch off Emergency Heat, I just need to send this payload:
{
“mode”: “Heat”,
“thermostatSetpointStatus”: “PermanentlyHold”,
“heatSetpoint”: 21,
“coolSetpoint”: 24
}

53

Here is how I am thinking of the emergency heat feature. If your thermostat has the emergency heat mode the system will create a read-only “Emergency Heat Active” channel which will display the value coming in from the data feeds. If the feature is not active then no change is done to the feed mode value it stays as Heat, Cool or Off. If the feature is active then the feed Heat mode will be translated to EmergencyHeat mode for openHAB.

In this way in openHAB changing from Heat to EmergencyHeat should be sticky. The feed will say Heat with feature active but openHAB will say EmergencyHeat. The “Emergency Heat Active” channel is a helper channel to make rules easier and read-only.

Does this make sense and will it be suitable for your usage?

54

It makes a lot of sense. I think I can manage my rules and everything in this way.

55

Update for “Emergency Heat Active” channel. I made the new channel a command channel as well as a status channel. Sending ON to the channel will switch mode to Heat with active set true (openHab EmergencyHeat) and sending OFF will switch to Heat with active set false. So regardless of the previous mode (Cool/Off) it will switch to Heat with active set true/false.

Please check:

  • Channel shows up;
  • Channel shows the proper values, when set from the physical thermostat on/off;
  • Channel shows the proper values when mode is changed from physical thermostat;
  • Channel changes the proper mode/flag when turn ON/OFF;
  • Mode changes in Thermostat Thing (Heat/EmergencyHeat) change the proper flag.
    Also, please note when setting in the mode/flag in the thermostat thing does the other flag/mode change right away or after an update from the API.

https://github.com/protectivedad/openhab-addons/releases/download/beta-v1.6d/org.openhab.binding.honeywell-4.2.3-SNAPSHOT.jar

This breaks nothing on my end but my system doesn’t run any of the new code :slight_smile:

56

I’m not ignoring this thread, I plan on treating the new fan channel this weekend. I’m happy to see all these new features! It’s been pretty stable for me this whole time. I occasionally see a warning able a failure to connect but that doesn’t happen too often and it seems to work. I’m haven’t had a chance to do further looking into whether there’s a pattern.

57

When the network goes down or has an issue during the binding fetching data from the API the binding will pause itself for the user to look at and investigate. The latest beta changes this behaviour. The binding will only pause on specific authorization errors. For all other errors it will either continue with the next thermostat (in multiple thermostat configurations) communication or wait for the next scheduled update. This should stop it from pausing itself except for more dire circumstances. The authorization channel connected can be used to detect if a connection has a temporary problem.

The fan and emergency mode channels have not been added to the beta-v1.7. Let me know when you have some time and I will post a fan mode version for you to look at.

58

Whenever you are ready I should be able to test. This shouldn’t take much to test out.

59

Here is the test jar:
https://github.com/protectivedad/openhab-addons/releases/download/beta-v1.7f/org.openhab.binding.honeywell-4.2.3-SNAPSHOT.jar

If you could test:

  1. Does the Fan Mode Channel show up;
  2. Does it have the correct mode and when the mode is changed on the thermostat does it change after an update;
  3. Does the fan mode list contain the proper entries, for your feed it should be “On”, “Auto”, and “Circulate”;
  4. Does changing the fan mode in the binding change the fan mode on the thermostat?

A trace log of the system as you go through these steps would be useful for both testing and my documentation.

Thanks.

60
  • I put the binding into trace level logging and shunted the logs to its own file.
  • I then stopped OH, removed the old jar file from the addons folder, downloaded the new one and started OH again.
  • I waited for Honeywell to connect.
  • Navigated to the thermostat Thing and verified the new Fan Mode Channel is present.
  • Linked it to an Item.
  • Item’s state remains UNDEF after linking. Clicking on the widget does show the options “ON”, “AUTO” and “CIRCULATE”.
  • I cycled through the options “AUTO”, then “CIRCULATE”, and then “ON” (it was ON to start) and I verified that the status on the device changed as I commanded the Item.

Logs are attached.

honeywell.log (418.1 KB)

I’m not 100% certain the fan wire is hooked up to the thermostat because changing the mode didn’t actually turn on the fan. But as far as the add-on is concerned it appears to work as expected.