HomeKit Controller Climate can't pair with ecobee

[raccettura]

Home Assistant release with the issue:

0.73.0 **Last working Home Assistant release (if known):** New component **Operating environment (Hass.io/Docker/Windows/etc.):**

Ubuntu 16.04 Component/platform:

HomeKit Climate

Description of problem: Two thermostats show up to configure, opening them prompts for code, however thermostat isn't being triggered to show code.

Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):

discovery:
  enable:
    - homekit

Traceback (if applicable):

Additional information: No errors or anything interesting in logs.

[Jc2k]

No nothing I can see in the current spec. I think in the ideal homekit setup your schedule would live on the controlling client, in this case home assistant.

[Enzo-Matrix]

@Jc2k Hope you can help. I upgraded to HA 94.b4 and lost connection to the thermostat. It was paired and working prior, now it is not detected at all. I am also unable to discover the device. Any suggestion?

[Jc2k]

Thanks for the heads up. First of all, were you running any of the previous betas? Did they work? I suspect the answer is no but need to rule that out.

Discovery won't be able to find the device against whilst it is paired. So that much is expected. Don't try and reset the pairing yet, I need to figure out why the migration wasn't successful.

Have you tried restarting since upgrading? What about reloading the UI (with a full hard refresh)?

[Jc2k]

Also if you are able to try previous beta's that could be helpful.

Also, can you make sure that zeroconf is enabled in your config:

zeroconf:

[Jc2k]

(I suspect zeroconf is the culprit so please try that first)

[Enzo-Matrix]

@Jc2k I do not have zeroconf enable. I will try that later today. I won't be able to test before mid-night your time so check for my updates tomorrow.

Also, I went from 92.2 with your climate and manifest patch to 94.b4. I will stick with the same version and try the zeroconf. If that doesn't work, I will run through the previous betas (though I doubt that will solve the issue).

[Enzo-Matrix]

zeroconf: did it.

With 94 there is now frequent time out error in the log for the homekit sensors:

2019-06-03 23:43:28 WARNING (MainThread) [homeassistant.components.binary_sensor] Updating homekit_controller binary_sensor took longer than the scheduled update interval 0:00:30
2019-06-03 23:43:51 WARNING (MainThread) [homeassistant.helpers.entity] Update of climate.main_floor is taking over 10 seconds

These repeat about every minute.

[Jc2k]

Does it report this for all ecobee entities? Or just sensor? Or just that one example ?

[Enzo-Matrix]

All the entities time out. The log is filled with them. Timeout is reported from: [homeassistant.components.climate] [homeassistant.components.sensor] [homeassistant.components.binary_sensor] [homeassistant.helpers.entity]

[Jc2k]

OK. So it must have migrated the entity to a config entry for the entity to show. So it shouldn't be a network issue, but equally timeouts are normally network issues.

Did the timeouts start immediately after the upgrade, or sometime after? Have you restarted since they started happening?

In your config/.storage folder you should have a homekit_controller-entity-map file. Does it contain JSON, and can you see the make and model of your device in there?

Also in config/.storage, you should have a core.config_entries. Look for the value of "AccessoryIP" - it should be the right IP for your device. Check it in your router config. Check you can ping it. Does it match the value shown by 'python3 -m homekit.discover`?

[Enzo-Matrix]

The entities are showing and I do get status (motion and temp). The timeout started immediately after the upgrade. It was a full restart of HA after adding the zereconf: setting.

The IoT devices are on their own subnet with good network reception. The ecobee is pingable from the access point and HA. Definitely not network issue.

I will get back to you on the conf file entries once I check.

[Jc2k]

Sure network is fine, but was worried about it not recovering from an IP change or something like that. Will wait for details from the conf entries / IP address checks..

[Enzo-Matrix]

Here is snippet of the homekit_controller-entity-map file. The MAC and type have been redacted.

{
    "data": {
        "pairings": {
            "00:00:00:00:00:00": {
                "accessories": [
                    {
                        "aid": 1,
                        "services": [
                            {
                                "characteristics": [
                                    {
                                        "format": "string",
                                        "iid": 2,
                                        "perms": [
                                            "pr"
                                        ],
                                        "type": "00000000-0000-0000-0000-000000000000",
                                        "value": "Main Floor"
                                    },
                                    {
                                        "format": "string",
                                        "iid": 3,
                                        "perms": [
                                            "pr"
                                        ],
                                        "type": "00000000-0000-0000-0000-000000000000",
                                        "value": "ecobee Inc."

I couldn't spot anything that would indicate the device model.

The core.config_entries shows the correct IP. The devices IP is statically assigned and is reachable from HA.

{
                "connection_class": "local_poll",
                "data": {
                    "AccessoryIP": "1.2.3.4",
                    "AccessoryLTPK": "<long string>",
                    "AccessoryPairingID": "00:00:00:00:00:00",
                    "AccessoryPort": 1200,
                    "Connection": "IP",
                    "iOSDeviceLTPK": "<long string>",
                    "iOSDeviceLTSK": "<long string>",
                    "iOSPairingId": "<string>"
                },
                "domain": "homekit_controller",
                "entry_id": "<string>",
                "options": {},
                "source": "zeroconf",
                "title": "Main Floor",
                "version": 1
            }

[Tediore]

@Jc2k So it looks like HomeKit has scenes that could be used to trigger home/away mode on the ecobee (along with many other things)...do you know of any way for these HomeKit scenes to be imported into Home Assistant via HomeKit Controller?

[Jc2k]

Is anyone on the final 0.94 tag able to see if this is all working for them now? All the pairing related fixes should now be merged.

@Tediore Are you able to give any more details about this? Maybe screenshots or links or something? HomeKit scenes are local to the controller(s) (i.e. your iPhone), so theres no way to manage them or activate them through the API the devices use. I've only seen one model of ecobee, its possible newer models might expose Home/Away modes as switches or something. I'd need to see the homekit_controller-entity-map file of a device that had working Home/Away to see what the deal was (without redacting the type field).

@Enzo-Matrix

The "type" values you redacted are UUID's that describe what the field is. E.g. 0000000F-0000-1000-8000-0026BB765291 is whether the thermostat is currently on. The model is 00000021-0000-1000-8000-0026BB765291. I mostly just wanted to check the file had been populated correctly, and it seems to have.

Does the port match what you get if you run the discover command manually?

[raccettura]

Original ticket creator here... I was able to pair 2 ecobee thermostats the other night and so far everything seems to work well.

[Jc2k]

Excellent news!

[Tediore]

@Jc2k I don't have an iPhone, but here's the documentation on it from ecobee's website: https://support.ecobee.com/hc/en-us/articles/115004905767-How-do-I-connect-my-ecobee-thermostat-to-Apple-HomeKit- "What are HomeKit scenes and automations?" section

[Jc2k]

Interesting! Can you send me your entity map file from your config .storage folder and I’ll see if I can see anything

[Tediore]

Can do! Might not be until Sunday, is that ok?

[Tediore]

@Jc2k I have what you need--how would you like me to share it with you?

[Jc2k]

You can attach it here if you like, the only personal information is maybe the names of things (which you can see easily enough in the JSON) and it might have a serial number which you can edit out if you like.

Or i'm on the HA discord, i think you can send private messages there.

Or you can send it to me via Keybase.

[Tediore]

Perfect, see attached (not sure how valuable it will be). I omitted any personal info. homekit_controller-entity-map.txt

[Jc2k]

OK so if you look for 0000000F-0000-1000-8000-0026BB765291 in that file. Thats the start of the Current Heating Cooling State characteristic in the thermostat service. From there down to 00000023-0000-1000-8000-0026BB765291 (the name characteristic) are normal standard thermostat characteristics. You can google those UUIDs and find out what they mean, and there is a spec from Apple that says what they should do and stuff.

After then there are 16 completely non standard and undocumented ecobee specific characteristics. If you google them you just find this ticket.

It's likely the features you found in the ecobee docs are using these, and that they don't work without an ecobee app. I'd need to see a screenshot from the Apple Home app of thes scenes they are talking about to confirm things.

We can infer what some of the non standard ones might do (they declare they are "celsius" or a number in the range 1 to 100 so probably a percentage. But there is no obvious "set home mode" toggle.

Right now even if we reverse engineered the meanings of all of these, unlike the official characteristics they are private interfaces so theres no guarantee Ecobee won't change them.

They are also specific to this device, but homekit_controller is trying to be device agnostic. It will be hard to have support for these as part of the core homekit_controller without adding really low quality spaghetti code to support quirks for different thermostats. We don't have a mechanism to have a seperate version of homekit_controller that understands the ecobee specific secret characteristics (and with this many custom characteristics it probably would warrant a full integration of its own).

So I don't think i can help with that right now.

[Tediore]

Makes sense, thanks. I bet I can probably emulate my current Ecobee setup solely in home assistant. Probably will require using Auto instead of heat/cool and changing temps instead of using home/away.

[Tediore]

@Jc2k Having some trouble with Auto mode... I can't seem to set target_temp_high and target_temp_low. There's also only one slider for Auto mode instead of two like expected. Here's the automation I'm trying to use:

- id: 'tstat_sleep_home'
  alias: Thermostat sleep at home
  initial_state: 'off'
  trigger:
    platform: time
    at: '22:30:00'
  condition:
    condition: and
    conditions:
    - condition: state
      entity_id: binary_sensor.tstat_mode
      state: 'auto'
    - condition: or
      conditions:
      - condition: state
        entity_id: alarm_control_panel.abode_alarm
        state: disarmed
      - condition: state
        entity_id: alarm_control_panel.abode_alarm
        state: armed_home
  action:
    service: climate.set_temperature
    data:
      entity_id: climate.thermostat
      target_temp_high: 65
      target_temp_low: 71

Using set_target_temp works but it seems to set the high and low temps around the temp you set based on the minimum heat/cool diff in Auto mode. For example, if the minimum diff is set to 5 and I change the target temp to 70, it will set the cool setpoint to 73 and the heat setpoint to 68. Any ideas?

Edit: If auto mode won't work it's no big deal, I'll just add another condition that sets the target temp based on the current operating mode (heat or cool) instead.

[arsaboo]

@Jc2k I am still having issues pairing my Ecobee thermostat. I have 3 Ecobee3 thermostats and only one is being detected in HA. The homekit_controller-entity-map is a huge file with 703 rows and I can pm you the file on discord if it helps.

[Jc2k]

@Tediore bad news! I think target_temp_high and target_temp_low might not be supported by native characteristics either.

A dev has reached out to me about their own custom characteristics requirements, so i'll see if that changes things about supporting the secret characteristics on your device. Can't promise anything though. In the mean time, you can only set a single target temperature, and thats why there is only a single slider.

@arsaboo If you have that file and it has that many rows then I would guess that you have managed to pair at least one of your thermostats (that file can only be created with a valid pairing). Have you tried restarting HA since pairing? Maybe its only showing one device at a time because they have the same name (or a similar one?). Have you tried using the "+" button to trigger a manual HomeKit pairing? You can also use the command python3 -m homekit.discover in your installation to scan on the command line (might be python -m homekit.discover depending on your OS / install method).

[Tediore]

No worries, thanks for the update. I'll just set up separate heat/cool mode automations.

Interesting to hear about the custom modes. I won't get my hopes up but I'll keep an eye out. I've also got a Chromebook now instead of a Windows machine so I can actually access a Linux terminal if testing is needed with that.

[arsaboo]

@Jc2k I did try the "+" in the integrations page and it still does not detect the other Ecobees. They also do not have same names.

Here's the output of python -m homekit.discover:

(homeassistant) homeassistant@aloknuc:/home/arsaboo$ python -m homekit.discover
Name: Philips hue - 403DB0._hap._tcp.local.
Url: http_impl://192.168.2.229:8080
Configuration number (c#): 19
Feature Flags (ff): Supports HAP Pairing (Flag: 1)
Device ID (id): 73:AC:88:89:xx:yy
Model Name (md): BSB002
Protocol Version (pv): 1.1
State Number (s#): 1
Status Flags (sf): Accessory has been paired. (Flag: 0)
Category Identifier (ci): Bridge (Id: 2)

Name: Lifx3._hap._tcp.local.
Url: http_impl://192.168.2.234:80
Configuration number (c#): 5
Feature Flags (ff): Supports HAP Pairing (Flag: 1)
Device ID (id): 65:2C:7A:DB:xx:yy
Model Name (md): LIFX BR30
Protocol Version (pv): 1.1
State Number (s#): 1
Status Flags (sf): Accessory has been paired. (Flag: 0)
Category Identifier (ci): Lightbulb (Id: 5)

Name: LifxnrGuest._hap._tcp.local.
Url: http_impl://192.168.2.49:80
Configuration number (c#): 5
Feature Flags (ff): Supports HAP Pairing (Flag: 1)
Device ID (id): 45:27:33:95:xx:yy
Model Name (md): LIFX BR30
Protocol Version (pv): 1.1
State Number (s#): 1
Status Flags (sf): Accessory has been paired. (Flag: 0)
Category Identifier (ci): Lightbulb (Id: 5)

Name: Lifx5._hap._tcp.local.
Url: http_impl://192.168.2.176:80
Configuration number (c#): 2
Feature Flags (ff): Supports HAP Pairing (Flag: 1)
Device ID (id): 8C:5A:61:F9:xx:yy
Model Name (md): LIFX BR30
Protocol Version (pv): 1.1
State Number (s#): 1
Status Flags (sf): Accessory has not been paired with any controllers. (Flag: 1)
Category Identifier (ci): Lightbulb (Id: 5)

Name: LifxnrKitchen._hap._tcp.local.
Url: http_impl://192.168.2.16:80
Configuration number (c#): 5
Feature Flags (ff): Supports HAP Pairing (Flag: 1)
Device ID (id): BD:0C:EE:96:xx:yy
Model Name (md): LIFX BR30
Protocol Version (pv): 1.1
State Number (s#): 1
Status Flags (sf): Accessory has been paired. (Flag: 0)
Category Identifier (ci): Lightbulb (Id: 5)

Name: Bedroom._hap._tcp.local.
Url: http_impl://192.168.2.247:1200
Configuration number (c#): 6
Feature Flags (ff): Supports HAP Pairing (Flag: 1)
Device ID (id): 96:15:38:98:xx:yy
Model Name (md): ecobee3
Protocol Version (pv): 1.1
State Number (s#): 1
Status Flags (sf): Accessory has been paired. (Flag: 0)
Category Identifier (ci): Thermostat (Id: 9)

Name: Upstairs._hap._tcp.local.
Url: http_impl://192.168.2.44:1200
Configuration number (c#): 3
Feature Flags (ff): Supports HAP Pairing (Flag: 1)
Device ID (id): 44:61:32:F4:xx:yy
Model Name (md): ecobee3
Protocol Version (pv): 1.1
State Number (s#): 1
Status Flags (sf): Accessory has been paired. (Flag: 0)
Category Identifier (ci): Thermostat (Id: 9)

Name: Downstairs._hap._tcp.local.
Url: http_impl://192.168.2.184:1200
Configuration number (c#): 4
Feature Flags (ff): Supports HAP Pairing (Flag: 1)
Device ID (id): 44:61:32:E5:xx:yy
Model Name (md): ecobee3
Protocol Version (pv): 1.1
State Number (s#): 1
Status Flags (sf): Accessory has been paired. (Flag: 0)
Category Identifier (ci): Thermostat (Id: 9)

Name: Homebridge-CAD8._hap._tcp.local.
Url: http_impl://172.17.0.1:51826
Configuration number (c#): 1848
Feature Flags (ff): No support for HAP Pairing (Flag: 0)
Device ID (id): CC:22:3D:E3:xx:yy
Model Name (md): Homebridge
Protocol Version (pv): 1.0
State Number (s#): 1
Status Flags (sf): Accessory has been paired. (Flag: 0)
Category Identifier (ci): Bridge (Id: 2)

[Jc2k]

@arsaboo from that output it looks like all 3 are paired. If there is only one showing in HA you will have to reset the HomeKit pairing on the device itself, that should make it show up in Discovery.

@Tediore are you on discord? If you want (and we can find a time that works) we could pair your device with the CLI and start trying to work out some of these custom characteristics.

[Tediore]

Yes I am! Sounds good. USA, Central time zone. What about you?

[Jc2k]

@Tediore UK timezone. Sorry for late reply! Are you on the HA Discord?

@arsaboo did my last note help? is your problem now resolved?

@Enzo-Matrix where were we up to - did things start working in the end or is it still broken?

[Tediore]

@Jc2k No worries. Yes I am.

[garyak]

This morning I was able to integrate my S30 thermostats into HA 99.3. Quite a surprise! While multi-zone configuration isn't available, a big thank you to those of you who have worked on this.

[GaryOkie]

@garyak - that is indeed great news your Lennox S30 is now connected! I've been following the updates but must have missed what change (if any) fixed the handshake.

A while back, HA detected my S30 via zeroconf, but that is no longer the case, and I'm not sure what enabled it. I've installed a bonjour browser and it sees hassio and other zeroconf-supported stuff, but not the S30. (They are on the same network, but the S30 is wifi and Hassio is ethernet.)

Are you able to confirm if the S30 only broadcasts bonjour just when the wifi and Homekit is being set up via an Apple IOS device? If so, I'll have to go borrow a iPhone/iPad like I did once before to get this set up.

[garyak]

I can not verify that WAC mode is the only time the S30 broadcasts. The steps I followed:

1. Enter WAC mode on the S30. This triggered discovery on my HA instance resulting in a notification and listing on the HA Integrations page.
2. Select the S30 from the Wi-Fi networks screen on the iPhone/iPad.
3. Wait for the S30 to discover the iPhone/iPad's SSID, then press Done on the iPhone/iPad Find a APP screen. This prompted the S30 to display the pairing code.
4. Select Configure from the integrations page to call up the HomeKit code dialog and enter the code in this format xx-xxxx-xx. Failure to add the dashes causes an error.

I do have zeroconf: in my configuration.yaml file.

[GaryOkie]

Thanks for the clear steps! Step 1 showing that entering WAC mode is what triggers HA discovery is key. My S30 is configured for wifi via the wifi menu, not via WAC - which apparently requires iOS. (WAC pairing via Android doesn't work).

So I'll need to borrow an iOS device and try this again.

[GaryOkie]

Still no go for me. With an iOS device, Lennox S30 WAC mode works fine to connect to wifi and to initiate Homekit pairing. HA 93.3 zeroconf notification recognizes the S30 immediately for configuration. Entering the code (with dashes) results in the S30 claiming a successful Homekit pair, but the HA component fails with Pairing attempt failed with an unhandled exception

Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/homekit_controller/config_flow.py", line 278, in async_step_pair
    start_pairing, self.hkid, self.hkid
  File "/usr/local/lib/python3.7/concurrent/futures/thread.py", line 57, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/usr/local/lib/python3.7/site-packages/homekit/controller/controller.py", line 374, in start_pairing
    raise AlreadyPairedError('Alias "{a}" is already paired.'.format(a=alias))
homekit.exceptions.AlreadyPairedError: Alias "51:34:90:F8:50:D1" is already paired.

Tried again by doing a Homekit factory reset on the S30 and restarting HA. Exact same result. I guess @Garyak just got lucky.

[Jc2k]

Glad to hear things are working for you @garyak. I'm still waiting for some feedback to my question on the Lennox E30 thread.

https://github.com/home-assistant/home-assistant/issues/20885#issuecomment-519799145

We probably should continue the discussion there, but if someone can test out code changes I might be able to add some retrying to handle the raciness for this thermostat.

[stale[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue now has been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[Jc2k]

I'm going to close this because pairing with ecobee thermostats now works.

If you are waiting for support the temperature ranges in heat/cool mode, you can track this ticket.

There is also a ticket about presets but I can't see how that will work without using vendor specific extensions.

Feel free to open a ticket and @ me if there are ecobee niggles. I am tied up with adding support for events and don't have much time but I will always try and prioritize regressions over new features.