HomeKit Controller Climate can't pair with ecobee

raccettura commented 6 years ago

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.

wes-warner commented 5 years ago

Just installed 0.90.0. My 3 remote ecobee3 sensor temperatures (and occupancy) now show up, which is great. Log gives one warning message --> "Loaded pairing for C3:0F:19:BF:2C:39 with missing connection type. Assume this is IP based."

This is the MAC address of my ecobee3. I expect this is related to the early way Homekit pairing was done in my case. Wes

On Monday, March 4, 2019, 1:35:57 p.m. EST, Jc2k <notifications@github.com> wrote:

That’s great news for me - I’ll make sure the basics work and then be in touch.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

Jc2k commented 5 years ago

Hi @wes-warner. Thats good to hear.

The warning is because the underlying library version now supports BLE and IP accessories and the pairing is missing a flag to say whether its BLE or IP, so it defaults to IP. So its not related to the way you paired, but it is perfectly harmless.

I've been slowly getting parts of my pairing / config entry work merged. 0.90 has a large chunk of the code merged but dormant, and have some more tests queue up to merge. I'm still trying to track down one bug that happens the first time you start HA after switching to my branch, when i've sorted that i'll almost be in a position to ask for help testing.

Jc2k commented 5 years ago

Can this issue please be re-opened, it appears to have been closed by mistake. I am the dev working on improving the pairing situation and the pairing issue we are discussing in this ticket is not yet resolved.

There is still 1 PR i have pending (reviews welcome :)) before i can rebase and start upstreaming the remaining parts of the config entry conversion. After that then i can resolve this pairing issue. But at the moment it is most definitely not resolved.

robbiet480 commented 5 years ago

Apologies for closing @Jc2k, I misread the most recent comments on this!

Jc2k commented 5 years ago

Np @robbiet480 😆

GaryOkie commented 5 years ago

I came here to see what progress there has been on this pairing issue... which seems to be the same as for Lennox iComfort S30, E30, and M30 T-stats. Many others have been trying to get these iComfort's working through HA and using the Homekit integration appears to be the most promising - if they would only pair!

Thanks for working on this. I'll follow this thread closely and help with testing.

wes-warner commented 5 years ago

Just updated to 0.91.0. Works with no visible changes here.
Minor issue I just noticed: The Ecobee3 actual relative humidity value is not reported. Is this a missing item in the code, or just a config issue for me? I have no plan to use the data but I suppose others might.

Jc2k commented 5 years ago

Update for people with pairing issues following this ticket - my PR with upstream has landed. When this is released on pypi it will unblock the changes to HA to support pairing with the Ecobee. I've already prototyped the HA changes, but they wil be queued up behind the remaining config entry changes as they depend on that work. Most of that work is merged, there are maybe 2 or 3 PR's left to go.

@wes-warner Looking at the JSON that you collected for me, there is one humidity reading. It appears to be part of the climate/thermostat service / accessory rather than a seperate service or accessory in its own right. So the humidity sensor code we do have does not fire in this case. Looking at the climate code, it looks like I could add code to do this and to support target humidity as well. I will add this to my todo - thanks for spotting it.

wes-warner commented 5 years ago

Thanks for the update, and the work. Let me know when you want me to re do pairing or any other testing with my ecobee3 thermostat via homekit. Wes On Thursday, April 11, 2019, 11:33:40 a.m. EDT, Jc2k notifications@github.com wrote:

Update for people with pairing issues following this ticket - my PR with upstream has landed. When this is released on pypi it will unblock the changes to HA to support pairing with the Ecobee. I've already prototyped the HA changes, but they wil be queued up behind the remaining config entry changes as they depend on that work. Most of that work is merged, there are maybe 2 or 3 PR's left to go.

@wes-warner Looking at the JSON that you collected for me, there is one humidity reading. It appears to be part of the climate/thermostat service / accessory rather than a seperate service or accessory in its own right. So the humidity sensor code we do have does not fire in this case. Looking at the climate code, it looks like I could add code to do this and to support target humidity as well. I will add this to my todo - thanks for spotting it.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

Jc2k commented 5 years ago

Have raised https://github.com/home-assistant/home-assistant/pull/23040 for humidity support.

Tediore commented 5 years ago

Thanks for the work with this so far @Jc2k. Just wanted to say I have an extra sd card so I'd be happy to run a branch of HA to help test this issue. I've been wanting local control of my ecobee for awhile now so I have a vested interest in this.

Jc2k commented 5 years ago

Thanks for the encouragement @ChickRepellent.

Current status:

Pairing changes are merged upstream in homekit_python. Waiting for a release of that.
Fixes for populating operation_list data (which controls if off/heat/cool options are available in UI) are reviewed and waiting to be merged (#23095)
Add support for humidity - waiting for review of #23040
Fix support for c# metadata changing (blocker for config entry branch) - waiting for review of #22995

When my outstanding HA pull requests land I need to get this merged. This started off at a 4000 line diff - most of it is already merged - but it still probably needs breaking up into at least 2 or 3 more seperate pull requests to be reviewable by the HA devs.

When thats done I can get to this.

If you are comfortable with python then you can run through the documentation here and pair manually. You'll need to run the git version to successfully pair with an ecobee device, and where it says to do -p pincode in the docs you need to leave it out and let it prompt you. When the CLI prompts you for a code it should be visible on the ecobee screen. We've actually just made a change to support tado devices on master so having someone test it out with another non-tado device would be really helpful.

Tediore commented 5 years ago

Awesome, thanks for the info (changed my username by the way). I might need your help with pairing manually...my main installation is hass.io on a RPi 3 B+ so I'm guessing I'll need to install another version of HA such as hassbian on my spare sd card in order to pair manually for testing (which is totally fine).

Jc2k commented 5 years ago

For pairing manually outside of HA we don’t really need HA at all, it should work on Raspbian (I sometimes do regression testing on old pis with Raspbian). So that’s plenty for command line testing of the library HA uses.

(Later we can transfer the pairing between systems if we want to test HA pieces).

Tediore commented 5 years ago

Ah I understand. Sounds good, I should have some time this week to install raspbian and try manually pairing my ecobee. Looked at the docs and I think I understand. All good if I ask questions here if I have trouble or would you prefer another method to reduce clutter in this thread?

Jc2k commented 5 years ago

Happy to do either this ticket is a bit of a beast tho. I am on the HA discord or you can Twitter DM maybe.

Jc2k commented 5 years ago

Hi guys - all my outstanding climate related PR's have been merged. This fixes the UI for selecting operation mode and adds support for any devices with humidity support. Still need to get a new release of homekit_python before I pairing will work out of the box, but i'm hoping that's not too far off.

Tediore commented 5 years ago

Awesome, thanks @Jc2k. So I went to test the homekit pairing commands yesterday when I realized I don't have a keyboard since I only own a laptop and it runs Windows so I'm assuming that's not helpful in this case. Either way I can get a keyboard to help test with Raspbian or run something in Docker on my laptop. Any suggestions?

wes-warner commented 5 years ago

Updated to 0.92.0 this am. Noticed that ecobee3 card on HA Overview page now reports Target Humidity as 36% which is the lowest setting of the slider. An attempt to set Target Humidity higher creates error pop-up saying: "Failed to call service climate/set_humidity. required key not provided @ data['humidity']" The sensor measured Humidity is not reported. I think it should be. Perhaps something is confused? My ecobee3 installation has no way to control humidity and there seems to be no way to set Target Humidity at the Thermostat or via the ecobee android app. Good to see gradual progress, thanks all. Wes

On Friday, April 19, 2019, 10:51:17 a.m. EDT, J <notifications@github.com> wrote:

Awesome, thanks @Jc2k. So I went to test the homekit pairing commands yesterday when I realized I don't have a keyboard since I only own a laptop and it runs Windows so I'm assuming that's not helpful in this case. Either way I can get a keyboard to help test with Raspbian or run something in Docker on my laptop. Any suggestions?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

Jc2k commented 5 years ago

@Tediore you could try and SSH into the Pi, plus the commands should work on an Ubuntu 18.04 VM or container.

@wes-warner thanks for the update! You seem to upgrade before I even notice an upgrade is out 😁

First of all - based on the JSON data you gave me previously I can confirm your Ecobee is reporting an optional HomeKit characteristic that it supports reading and writing a target humidity (as well as a current humidity readout). It accepts values between 20 and 50 in steps of 1. What setting this does in practice I do not know, but at a protocol level it is there so it's right that you should have the option to set it.

It looks like there isn't yet UI to show the current humidity when there is a current temperature. That's seperate to the homekit stuff (which is all i can really help with). But I can see the data is collected if i look in the HA backend (go to /dev-state in your HA frontend):

current_temperature: 21.8
min_temp: 7
max_temp: 35
temperature: 31
current_humidity: 34
humidity: 36
operation_mode: cool
operation_list: off,heat,cool
friendly_name: HomeW
supported_features: 137

I have been able to recreate the issue you reported. My first thought was this looks like a bug in the climate card maybe - if i dump what happens between the browser and HA when i change the temp i see:

{'type': 'call_service', 'domain': 'climate', 'service': 'set_temperature', 'service_data': {'temperature': 32.5, 'entity_id': 'climate.homew'}, 'id': 19}

But for the humidity i just see:

{'type': 'call_service', 'domain': 'climate', 'service': 'set_humidity', 'service_data': {'entity_id': 'climate.homew'}, 'id': 22}

But one thing is that the UI is a slider and there is no value for max_humidity. So maybe increasing humidity towards an undefined value causes it to try to change the humidity to undefined? I just edited my local UI so it thinks there is a min and max and it works, so that seems to be it. I had planned to support reading min/max temp/humidity from homekit as my next change to climate support, which I think will fix this.

wes-warner commented 5 years ago

As you say, measured humidity is reported in dev-state. It is on the home display of the ecobee3 so perhaps the climate card should be consistent but this is not a real issue for me. The ecobee also has an 'auto' operation_mode (which I don't use) as well as off, heat, cool. All this has to do with the HA front end climate card and off-topic here I guess. Let me know when it is time to re-try pairing. Good hunting, Wes

On Thursday, April 25, 2019, 4:52:53 p.m. EDT, Jc2k <notifications@github.com> wrote:

@Tediore you could try and SSH into the Pi, plus the commands should work on an Ubuntu 18.04 VM or container.

@wes-warner thanks for the update! You seem to upgrade before I even notice an upgrade is out 😁

First of all - based on the JSON data you gave me previously I can confirm your Ecobee is reporting an optional HomeKit characteristic that it supports reading and writing a target humidity (as well as a current humidity readout). It accepts values between 20 and 50 in steps of 1. What setting this does in practice I do not know, but at a protocol level it is there so it's right that you should have the option to set it.

It looks like there isn't yet UI to show the current humidity when there is a current temperature. That's seperate to the homekit stuff (which is all i can really help with). But I can see the data is collected if i look in the HA backend (go to /dev-state in your HA frontend): current_temperature: 21.8 min_temp: 7 max_temp: 35 temperature: 31 current_humidity: 34 humidity: 36 operation_mode: cool operation_list: off,heat,cool friendly_name: HomeW supported_features: 137

I have been able to recreate the issue you reported. My first thought was this looks like a bug in the climate card maybe - if i dump what happens between the browser and HA when i change the temp i see: {'type': 'call_service', 'domain': 'climate', 'service': 'set_temperature', 'service_data': {'temperature': 32.5, 'entity_id': 'climate.homew'}, 'id': 19}

But for the humidity i just see: {'type': 'call_service', 'domain': 'climate', 'service': 'set_humidity', 'service_data': {'entity_id': 'climate.homew'}, 'id': 22}

But one thing is that the UI is a slider and there is no value for max_humidity. So maybe increasing humidity towards an undefined value causes it to try to change the humidity to undefined? I just edited my local UI so it thinks there is a min and max and it works, so that seems to be it. I had planned to support reading min/max temp/humidity from homekit as my next change to climate support, which I think will fix this.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

Jc2k commented 5 years ago

Will do. Currently aiming for 0.94 for the new config entries based pairing, hopefully with the ecobee pairing fix at the same time but that depends on new release of homekit_python. There is a big change to prep for 0.94 already merged in 0.93 so on track at the moment.

Pull request for target humidity issue submitted.

Will leave UI fixes for other people - got months of work in front of me just to get HomeKit support to the level I want.

The operation_list thing is interesting though. Might be something I do need to look at as in the backend it reports:

operation_list: off,heat,cool

And no auto is listed. operation_list is populated from the heating-cooling.target (characteristic 33). For your device that looks like this:

                    {
                        "value": 1,
                        "maxValue": 3,
                        "minStep": 1,
                        "perms": [
                            "pr",
                            "pw",
                            "ev"
                        ],
                        "type": "33",
                        "minValue": 0,
                        "format": "uint8",
                        "iid": 18
                    },

It's the min and max values that matter here. It clearly supports off, heat, cool and auto. (auto is a value of 3, which is <= maxValue).

The code in hass has this:

MODE_HOMEKIT_TO_HASS = {
    0: STATE_OFF,
    1: STATE_HEAT,
    2: STATE_COOL,
}

So it can't map from auto in HomeKit to auto in HA. Just updating the mapping seems to be enough to sort it out. Will test it as best I can and submit a PR for this one too, but will be after the other one is merged.

Enzo-Matrix commented 5 years ago

I am still unable to get an ecobee3 paired with HA, both via HA UI or using homekit.pair command. Each time a pairing is attempted, the ecobee generates a new pin code. The homekit.pair command only output step 5 after each pairing attempt. I also do not get prompt for the pin if I run without the -p flag and the command fails stating that -p must be provided. I followed @Jc2k steps here.

Anything else I can try?

Jc2k commented 5 years ago

It’s not expected to work out of the box till 0.94, and as you can see from what Wes says it’s still incomplete.

Those instructions won’t work any more. I’m surprised you didn’t get an error message? If you really want to help alpha test I can update them when I’m back at my desk.

Enzo-Matrix commented 5 years ago

I can definitely help with testing. Let me know what information you need.

Jc2k commented 5 years ago

There are no instructions for testing the new pairing interface in HA yet - it involves too many unstable unreleased pieces. Hence my referencing 0.94. So all you can do so far is pair manually on the command line and then we can use that pairing with the current HA release.

It looks like you didn't quite follow the instructions but I don't quite know what happened. First of all, the instructions you referenced currently don't work:

$ ./venv/bin/pip install https://github.com/Jc2k/homekit_python/archive/ecobee.zip
Collecting https://github.com/Jc2k/homekit_python/archive/ecobee.zip
  HTTP error 404 while getting https://github.com/Jc2k/homekit_python/archive/ecobee.zip
  Could not install requirement https://github.com/Jc2k/homekit_python/archive/ecobee.zip because of error 404 Client Error: Not Found for url: https://codeload.github.com/Jc2k/homekit_python/zip/ecobee
Could not install requirement https://github.com/Jc2k/homekit_python/archive/ecobee.zip because of HTTP error 404 Client Error: Not Found for url: https://codeload.github.com/Jc2k/homekit_python/zip/ecobee for URL https://github.com/Jc2k/homekit_python/archive/ecobee.zip

(Feature is merged so i deleted the branch).

Secondly, despite the error you ended up with an old version of homekit_python without the pairing fix. Maybe you ended up using the version of homekit_python from your HA install and not the version from the virtualenv?

Here is an updated version that references the current fixed code. Make sure you do it in a fresh venv otherwise you might end up using the wrong version.

$ python3 -m venv venv
$ source venv/bin/activate

$ pip install https://github.com/jlusiardi/homekit_python/archive/master.zip
Collecting https://github.com/jlusiardi/homekit_python/archive/master.zip
  Downloading https://github.com/jlusiardi/homekit_python/archive/master.zip
     \ 1.4MB 800kB/s
Collecting zeroconf (from homekit==0.12.2)
  Using cached https://files.pythonhosted.org/packages/d2/4e/3e751bc1f33d0368bdba509a140cb9f2e54cd1cfb8ebcf4ebd8a5eef794b/zeroconf-0.21.3-py2.py3-none-any.whl
Collecting hkdf (from homekit==0.12.2)
Collecting ed25519 (from homekit==0.12.2)
Collecting cryptography (from homekit==0.12.2)
  Downloading https://files.pythonhosted.org/packages/d7/9e/12bb10fd009b0146935c169cc0e1e86221eacf8dc207990d54b783c47a7d/cryptography-2.5-cp34-abi3-macosx_10_6_intel.whl (1.7MB)
    100% |████████████████████████████████| 1.7MB 1.3MB/s 
Collecting ifaddr (from zeroconf->homekit==0.12.2)
Collecting asn1crypto>=0.21.0 (from cryptography->homekit==0.12.2)
  Using cached https://files.pythonhosted.org/packages/ea/cd/35485615f45f30a510576f1a56d1e0a7ad7bd8ab5ed7cdc600ef7cd06222/asn1crypto-0.24.0-py2.py3-none-any.whl
Collecting six>=1.4.1 (from cryptography->homekit==0.12.2)
  Using cached https://files.pythonhosted.org/packages/73/fb/00a976f728d0d1fecfe898238ce23f502a721c0ac0ecfedb80e0d88c64e9/six-1.12.0-py2.py3-none-any.whl
Collecting cffi!=1.11.3,>=1.8 (from cryptography->homekit==0.12.2)
  Using cached https://files.pythonhosted.org/packages/0b/ba/32835c9965d8a0090723e1d0b47373365525c4bd08c807b5efdc9fecbc99/cffi-1.11.5-cp37-cp37m-macosx_10_9_x86_64.whl
Collecting pycparser (from cffi!=1.11.3,>=1.8->cryptography->homekit==0.12.2)
Installing collected packages: ifaddr, zeroconf, hkdf, ed25519, asn1crypto, six, pycparser, cffi, cryptography, homekit
  Running setup.py install for homekit ... done
Successfully installed asn1crypto-0.24.0 cffi-1.11.5 cryptography-2.5 ed25519-1.4 hkdf-0.0.3 homekit-0.12.2 ifaddr-0.1.6 pycparser-2.19 six-1.12.0 zeroconf-0.21.3
You are using pip version 10.0.1, however version 19.0.1 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.

$ python -m homekit.discover
Name: DemoAccessory._hap._tcp.local.
Url: http_impl://10.0.1.11:8082
Configuration number (c#): 39
Feature Flags (ff): Paired (Flag: 0)
Device ID (id): 10:30:10:00:00:00
Model Name (md): DemoAccessory
Protocol Version (pv): 1.0
State Number (s#): 1
Status Flags (sf): 1
Category Identifier (ci): Lightbulb (Id: 5)

$ echo '{}' > pairing.json

$ python -m homekit.pair -d 10:30:10:00:00:00 -f pairing.json -a ecobee
Enter your setup code: 031-45-154
Pairing for ecobee was established.

$ python -m homekit.get_accessories -f pairing.json -a "ecobee"
1.2: >accessory-information<
  1.3:  (Identify) >identify< [pw]
  1.4: lusiardi.de (Manufacturer) >manufacturer< [pr]
  1.5: Demoserver (Model) >model< [pr]
  1.6: Testlicht (Name) >name< [pr]
  1.7: 0001 (Serial Number) >serial-number< [pr]
  1.8: 0.1 (Firmware Revision) >firmware.revision< [pr]
1.9: >lightbulb<
  1.10: False (Switch state (on/off)) >on< [pw,pr,ev]

$ python -m homekit.unpair -f pairing.json -a ecobee
Pairing for ecobee was removed.

Enzo-Matrix commented 5 years ago

@Jc2k Thanks for clarifying. Now I get this error:

(venv) hass@hal:~$ python3 -m homekit.discover
Traceback (most recent call last):
  File "/usr/lib64/python3.7/runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "/usr/lib64/python3.7/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/opt/hass/venv/lib64/python3.7/site-packages/homekit/discover.py", line 49, in <module>
    results = Controller.discover(args.timeout)
  File "/opt/hass/venv/lib64/python3.7/site-packages/homekit/controller/controller.py", line 88, in discover
    raise TransportNotSupportedError('IP')
homekit.exceptions.TransportNotSupportedError: Transport IP not supported. See setup.py for required dependencies.

Jc2k commented 5 years ago

Need to use the IP feature flag when installing since BLE support landed. Not sure how to install from a git url and use feature flags off the top of my head. So lets install stable and upgrade:

$ source venv/bin/activate
$ pip install homekit[IP]
$ pip install --upgrade https://github.com/jlusiardi/homekit_python/archive/master.zip

Make sure to specify --upgrade.

Enzo-Matrix commented 5 years ago

Perfect. The [IP] install fixed the error. For reference, the -p flag does not work for homekit.pair. Once the flag is removed, the user is prompted for the pin code, which then works.

Jc2k commented 5 years ago

When you say it does not work what do you mean exactly? It won’t work for devices with screens, only for devices with static codes printed on a label. Or do you mean even that doesn’t work?

Enzo-Matrix commented 5 years ago

Oh. This was pairing a device with dynamically generated PIN. I never tried with devices with static code. It would be helpful if that was mentioned in the help output for homekit.pair.

Jc2k commented 5 years ago

Good idea.

Not sure if you are already doing the next steps but I will repeat in case its helpful.

So now you hve a pairing.json and it looks something like this:

{
  "ecobee": {
    "AccessoryPairingID": "ff:f0:00:00:00:00",
    "AccessoryLTPK": "daaf0d8f58130830efe7aaaefbd7fc2ed08075a9210aef1bed60bac0c1537a90",
    "iOSPairingId": "0245a110-349c-45b7-89a5-63f43696ed0d",
    "iOSDeviceLTSK": "ff4516ffc4b8d5e3fc15df6d2164e8db6ffb2d0968ea366b9e80d4fcd84c9379",
    "iOSDeviceLTPK": "047838ed35e599dcfd208557972809ddd205520e6b84b09905768e1079cb125a",
    "AccessoryIP": "192.168.x.x",
    "AccessoryPort": 8085,
    "Connection": "IP"
  }
}

Edit it and replace "ecobee" with your AccessoryPairingID.

Then drop it in /config/.homekit/pairing.json (where /config is the directory with your configuration.yaml) and restart HA. After about 30s to 60s discovery will trigger the pairing to be loaded.

If your UI is already open when this happens you'll need to F5 to get it to show up..

Then your Ecobee devices should appear.

Known issues - target humidity will be detected but can't currently be set. Auto mode is not currently supported. Both are in my queue to get reviewed.

Let me know how you get on.

Enzo-Matrix commented 5 years ago

Never hurts to repost key steps. I was using the ID as the alias so it showed up right away once HA was restarted. Great work @Jc2k. Chime in anytime you need something tested/validated.

Enzo-Matrix commented 5 years ago

@wes-warner Are you getting the correct motion status for the Ecobee motion sensor (both on the thermostat and remote sensors)? Mine is stuck in on.

Jc2k commented 5 years ago

Don't know if anything of this is helpful but:

One thing to note with the motion sensor is that homekit_controller doesn't currently support events - its polling on a minutely basis. The motion sensor was added because I have an Eve Motion to test BLE support rather than because it was useful as a trigger for automations (yet...).

The motion sensor is the simplest HomeKit sensor - see https://github.com/home-assistant/home-assistant/blob/dev/homeassistant/components/homekit_controller/binary_sensor.py#L18. It literally reads the MOTION_DETECTED characteristic once every minute. That will be True or False. There's no motion specific update logic to go wrong. So it's likely a problem reading it would probably hit other characteristics too.

To prove if it is/isnt the HA code thats stuck you could bounce HA and see if the state goes straight back to ON. We could also stick a print() or log statement here to print the value from the sensor.

One thing with the Eve Motion is that you can set how long the on state is held for after it detects movement. So it can stay on for a minute, for 15 minutes, maybe even longer, depending on settings on the device.

wes-warner commented 5 years ago

Re ecobee3 motion sensors. Better called "occupancy sensors".There is one built into the thermostat, and I have three other remotes. They all work correctly and show up correctly in HA.The remote sensors report temperature and occupancy. Whenever a occupancy sensor detects motion it reports occupancy within seconds but then occupancy STAYS ON for 30 minutes after the last motion is detected. I think this makes sense for the purposes of a smart thermostat. You can come and go in a room without toggling overly-quick attempts to heat or cool that room. This operation (30 minutes on time) might not be what is wanted to control room lighting for example, but the actual off event is hidden in the Ecobee programming and not reported. Hope this helps. WesOn Apr 27, 2019 4:10 PM, Enzo-Matrix notifications@github.com wrote:@wes-warner Are you getting the correct motion status for the Ecobee motion sensor (both on the thermostat and remote sensors)? Mine is stuck in on.

—You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or mute the thread.

Jc2k commented 5 years ago

Just opened #23562. This won't fix pairing by itself, but contains the API changes I need to be able to fix pairing.

Still waiting for a review of the humidity fix (#23421), when that is merged I have a fix for auto not appearing in the operation list ready to submit.

Getting closer to wrapping this issue up...

Enzo-Matrix commented 5 years ago

@Jc2k I upgraded to homekit[IP] 0.14.0 and add a patch from your pull request. I can now see the additional humidity values and able to adjust the target humidity.

current_humidity:
humidity:
min_humidity:
max_humidity:

Now waiting for auto in the operation list. Do you have a link to your fix so I can create a patch for it in my setup?

Do you know if fan control is supported by homekit?

Jc2k commented 5 years ago

Thanks for testing @Enzo-Matrix - glad it is working for you.

The wonderful HA team have reviewed and merged those pull requests so i've been able to turn the auto fix into a PR, which is here: https://github.com/home-assistant/home-assistant/pull/23583.

Now 0.14.0 of homekit_python is merged I've finished writing the first pass at the pairing fix. It's a relatively simple change, but the new pairing API is 2 step process which means there are quite a few test changes. I don't want to entangle the switch to config flow with those changes so its currently behind config flow in my review submission queue. (Config flow is the API that will make homekit devices appear under "Integrations" and will enable things like assigning areas at pair time and unpairing from within HA).

Hoping #23583 and #23532 land soon so I can concentrate on prep for getting config flow into 0.94.

Enzo-Matrix commented 5 years ago

Can confirm that the addition of "Auto" from #23583 is working.

Jc2k commented 5 years ago

The main config flow work is now on dev so should be in 0.94. If you have paired manually the pairing will be migrated over to a config entry and your device will start showing up on the Integrations screen.

There is a related branch here that adds device registry support. This allows HA to know the relationship between entities and physical devices attached to HomeKit hubs.

Now that config entries is done I've also finished polishing the pairing patch which is really the one most people tracking this ticket are interested in. It's here. With this we should be able to support any HomeKit with a display (i.e. randomised pairing codes) - save for device specific quirks.

Tediore commented 5 years ago

Ok so this is super late (sorry) but I tried manually pairing my ecobee last night and couldn't pair because it gave me an error about crypt.py not being available (probably because I'm on windows). Just wanted to let you know that I didn't forget. I'm guessing I should just wait for 0.94 and test the pairing UI but any ideas?

Jc2k commented 5 years ago

Was that running on Windows directly? You could try running a Docker container on windows and either pair manually from within the container or run the dev version of homeassistant in Docker on Windows and just test the new pairing UI.

Tediore commented 5 years ago

Ah that's a good idea. I have Python installed on my Windows machine so I thought I could at least find the HomeKit code through the command line. Got close I guess. I'll install the dev version and try the new UI.

Jc2k commented 5 years ago

The first 0.94 beta fix has just been tagged while i was asleep (about 8 hours ago). This includes:

The pairing fix for devices with screens and random pairing codes
The new config entry support (so your devices appear under 'Integrations' like Hue etc)
Device info support (groups entities by phsyical device and lets you put them in areas)
Migrates to the new zeroconf module for discovery

This is still beta so there is still time to fix any surprise gotchas. This is obviously quite a big set of changes so if anyone can run the beta and let me know how they get on please do.

Tediore commented 5 years ago

I'll install the beta version of hass tonight or tomorrow instead of dev.

Tediore commented 5 years ago

Alright, just tried out the beta version and was able to pair my ecobee3 lite. No issues pairing or controlling. I did notice that there's no way to toggle home/away mode...is this expected? Edit: to clarify, the climate control panel for Ecobee connected via the cloud API has a toggle for away mode, but this isn't present when controlled via HomeKit controller (at least on my test build). Hassbian 0.94b. I can test if automations that toggle away mode still function when connected via HomeKit controller.

Jc2k commented 5 years ago

No, HomeKit doesn't have a concept of "Home / Away" mode for a climate service at the protocol level.

If you think of Home and Away as scenes, theres no provision for configuring those scenes in the homekit protocol, so theres no provision to activate those scenes either.

Unless you are relying on the UI on the thermostat you should just have your automation set a different target temperature / target operating mode directly, I think.

Tediore commented 5 years ago

Makes sense. That's too bad, seems like a bit of an oversight with HomeKit. I'm guessing it just doesn't fall within the use cases that Apple intends for HK. Either way, HK controller is working with Ecobee. Nice work!

Enzo-Matrix commented 5 years ago

@Jc2k Is there an option to resume the schedule via homekit? Changing the temp enables hold mode and setting the thermostat "to resume at next schedule" causes the away mode work-around to fail.

home-assistant / core

HomeKit Controller Climate can't pair with ecobee #15336