New Ecobee Homekit Controller set point units '#' and value is in C (should be F)

[icepop456]

The problem

New items such as number.sun_room_thermostat_home_heat_target show up with units of '#' and have values in C. My installation uses F for all temperature, unless I am missing something in my installation.

Units are set to imperial on my configuration->General

What version of Home Assistant Core has the issue?

2022.3.0b1

What was the last working version of Home Assistant Core?

none

What type of installation are you running?

Home Assistant OS

Integration causing the issue

Homekit Controller

Link to integration documentation on our website

No response

Diagnostics information

homekit_controller-8414135c42a0e1d026da6c5d4dca19e7-Sun Room-b501a5b68049ea917ac993fe41b1a84f.json.txt

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

No response

[probot-home-assistant[bot]]

homekit_controller documentation homekit_controller source _{^{(message by IssueLinks)}}

[probot-home-assistant[bot]]

Hey there @jc2k, @bdraco, mind taking a look at this issue as it has been labeled with an integration (homekit_controller) you are listed as a code owner for? Thanks! _{^{(message by CodeOwnersMention)}}

[Jc2k]

Do they actually work? There's another report that says when you change them the ecobee app doesn't update. I'm more likely to remove them than anything at this point.

[icepop456]

Home Heat does not work. I would be concerned on how practical this would be since I have comfort settings beyond home/sleep/away.

It would be useful, to me at least, if we could look for ways to figure out current comfort profiles beyond home/away/sleep. If there is a way for me to see that unique ID per comfort setting, I can debug those codes.

[Jc2k]

The API exposed is very limited. There are 6 numerical values exposed which you can read and write. A heat and cool for each of the 3 default profiles. And it sounds like it doesn't even work.

There's no way to control the set points of custom profiles. The API does not have that capability.

It sounds like this should be dropped then. I'll put in a PR to remove them in the morning if you are sure they don't work.

[icepop456]

I have a few concerns with the latest updates causing confusion. I agree the setting the home profile temperature is not how Ecobee works. We should expect people to call for home/away/sleep and let ecobee handle what that does.

However, calling home does not work. My thermostat stays in away state that I manually triggered. I used the new integration to set away. That works. Set sleep works. Instead of setting "home", the clear hold works. This is actually the major improvement I needed. Thank you to those who helped.

However, the integration apparently has no way to see what the current mode actually is. For example, when it is in sleep, all my device entities/attributes show what would be normal "home" setting. I captured the developer view for when my thermostat is "sleep". I have this thermostat connected via homekit_controller and ecobee integration (cloud). Setting sleep works fine, home assistant apparently has no idea it worked. Even the history of the current mode entity does not reflect the change to sleep mode.

climate.sun_room_thermostat = HOMEKIT_CONTROLLER climate.sun_room_thermostat_e = ECOBEE Integration (cloud)

Entity State Attributes

[climate.sun_room_thermostat](https://REMOVED IP#) Sun Room Thermostat heat hvac_modes: off, heat, cool, heat_cool min_temp: 45 max_temp: 92 min_humidity: 20 max_humidity: 50 current_temperature: 68 temperature: 67 <------------Still thinks current setpoint is 67 target_temp_high: null target_temp_low: null current_humidity: 39 humidity: 36 hvac_action: idle friendly_name: Sun Room Thermostat supported_features: 7

[climate.sun_room_thermostat_e](https://REMOVED IP#) Sun Room Thermostat E heat hvac_modes: heat_cool, heat, cool, off min_temp: 44.6 max_temp: 95 target_temp_step: 0.5 fan_modes: auto, on preset_modes: Warm Day, Sleep, Home, Afternoon, PreSleep, Wake Up, Away current_temperature: 68.1 temperature: 45 <------------Actual setpoint is 45 due to sleep profile target_temp_high: null target_temp_low: null current_humidity: 39 fan_mode: auto hvac_action: idle preset_mode: Sleep aux_heat: off fan: off climate_mode: Home equipment_running: fan_min_on_time: 0 friendly_name: Sun Room Thermostat E supported_features: 91

[icepop456]

Looks like setting "Away" via the homekit_controller integration does not set this variable correctly. When I set away mode via the ecobee app (did this on their web interface), I see it set it to "2" which I suspect represents Away.

The impact is that now Home Asisstant reports the proper temperature set point (55) where before it was still reporting the original comfort profile (66-67). (Note: was changing the set point of the comfort profile to help track what changes were showing up, ignore 66 vs 67). Effective I have 45 (sleep), 55 (away), 67 (home), and 66 (custom presleep)

            "type": "B7DDB9A3-54BB-4572-91D2-F1F5B0510F8C",
            "iid": 33,
            "perms": [
              "pr"
            ],
            "format": "uint8",
            "value": 2,     <---------- stays 3 when I am in custom PreSleep and set Away in Home Assistant
            "minValue": 0,
            "maxValue": 3,
            "minStep": 1
          },

[Jc2k]

Let me be very clear here, the API we are using to expose these features is undocumented, very glitchy, and sometimes outright broken.

The only part that is supported by Ecobee properly is the generic homekit thermostat. All of the ecobee specific things (presets) are not exposed well over the homekit API and we are really unable to replicate your mental model of how an ecobee works.

There are just not enough controls and the ones we have don't work well.

I don't have one of these devices either (they aren't available in U.K) so am limited in how I can help.

Some of the APIs have workarounds we have discovered. For example, to make clear hold work, we have to write False then write True in a second request.

We believe the preset chooser only works if you clear hold first. You can't hold a preset when another preset is held.

Writes to the 6 set point characteristics are accepted but don't seem visible of the device (but are visible via homekit).

And again, I strongly suspect custom presets will not work. Ever. Because of limitations of their API. Notice in the example you gave. B7DDB9A3-54BB-4572-91D2-F1F5B0510F8C is limited to numbers <= 3. There's also no way to detect the name via the API. So even if it supported bigger numbers we'd only ever support "Custom 5" etc.

[Jc2k]

This ticket is about the 6 set point temperatures.

I think based on what you said they don't work, but I'm not sure because of the stuff about custom presets and the preset chooser.

Can you confirm that they don't work.

Then we can talk about the other stuff.

[icepop456]

I can confirm setting Home Heat Target does not do anything.

I recommend removing it. It does not match the intended use case. Users can always manually set the temperature through HA and that will create an indefinite hold temperature.

Home/Away/Sleep comfort settings should be handled within the Ecobee ecosystem. Home Assistant should only need to call them. I will create a separate issue for that topic as it is not currently working correctly.

[Jc2k]

I'm removing them because the don't work, (to be clear, if they did work I would not be removing them, and if someone finds out how to make them work I can re-add them).

In your other issue, can you confirm that the proposed workaround works or not? Apparently if you clear hold before you select a preset it works.

[icepop456]

It is not that straightforward. I can select a preset and the thermostat will honor it. For example, I can set the thermostat to sleep. That works.

However, home assistant has no idea that it worked. All device entities are unchanged. The current setpoint and the current mode remain the same (home comfort setting). Appears completely out of sync with the device.

I have an idea of what is going on based on scenes within Ecobee app. Normally we would have a "Leave Home" scene and attach thermostats and their presets for this scene. I have my thermostat hooked up to homekit_controller->homekit. Ecobee app refused to show available comfort presets. This could be a artifact of hub being "not certified to work with homekit". No idea.

I bring this because all the home assistant updates work fine when the comfort presets occur outside of home assistant. Something is preventing home assistant from refreshing/syncing with current status.

[Jc2k]

So the Ecobee extensions pretty much all suffer from coherency issues, and it sounds like thats whats happening here too.

E.g. You are supposed to write "True" to "clear hold" to clear the hold. But if you write true twice its like it has cached the previous write. You need to write False, then True to make it work.

Then when you write to one of the other endpoints (fan speed i think), it also remembers the previous value. So if you write 100 in homekit, then turn it off via the ecobee ecosystem, then write 100 again in homekit it won't work. So we have to write 99 then 100 to circumvent the bug.

[Jc2k]

A previous contributor figured out the presets suffered the bug you desribe a couple of years ago (outside of HA).

If you turn on debug logs for aiohomekit you can see the request to the ecobee polling once a minute, and it see it returning stale data.

What happens if you set a preset then restart HA?

[icepop456]

Did the following: Clear hold and confirmed everything is in home preset with ecobee and HA in agreement.

Set Sleep command with the following payload PUT command: {"aid":1,"iid":40,"value":1}

Confirmed thermostat did go to sleep. GET command returned: {"aid":1,"iid":33,"value":0}

Rebooted HASS GET command returned: {"aid":1,"iid":33,"value":0}

No signs of rebooting HA changed anything.

[Jc2k]

We poll CharacteristicsTypes.VENDOR_ECOBEE_CURRENT_MODE (iid 33). But we write to VENDOR_ECOBEE_SET_HOLD_SCHEDULE (iid 40). So thats as i expect.

I double checked in your latest diagnostics data and the Ecobee still says current mode is a read only number between 0 and 3 and that set hold schedule is a write only number between 0 and 2. I can't see any other characteristics that might have supersceded it.

So I think that this characteristic endpoint is also broken, at least for your model of device.

[icepop456]

Looks like my set hold schedule is between 0 and 3.

            "type": "1B300BC2-CFFC-47FF-89F9-BD6CCF5F2853",
            "iid": 40,
            "perms": [
              "pw"
            ],
            "format": "uint8",
            "minValue": 0,
            "maxValue": 3,
            "minStep": 1
          },

Anything else you want me to try? I have been toying with changing presets with HA and ecobee itself trying to track changes. Nothing obvious. I can only get (iid 33) to update if the change occurs outside of HA.

I can unpair/repair. Not sure if you heard of any sequence of upair, reboot, pair or something like that.

[Jc2k]

Related issue: https://github.com/home-assistant/core/issues/67151. This user seems to be OK if they clear the hold and then use the preset picker. I don't know if they've just not noticed the issues you've reported with the preset picker or if there is an environmental difference. If possible can you join the discussion there?

https://github.com/home-assistant/core/pull/67474 removes the broken threshold picker.

Please do open tickets for anything not covered in those 2 links.