HomeKit Controller Climate can't pair with ecobee

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.

I tried debugging again with:
logger:
  default: warning
  logs:
    homeassistant.components.homekit: debug
    pyhap: debug

I also tried powering down one thermostat, in case that part of my setup was causing this not to work. Even with 1 thermostat, the configure button never caused the ecobee to display a pairing code.

I'm having this issue as well on Home Assistant 0.74 on Raspberry Pi 3, but I also do not see the prompts to enter a code.

I noticed 0.74 updated HomeKit in https://github.com/home-assistant/home-assistant/pull/15502 so I gave it another try, but no change.

to better debug use:
homeassistant.components.homekit_controller: debug
homeassistant.components.climate: debug
the one you're using is for the homekit component, not homekit_controller ;)

You are correct.  Tried updating... nothing shows up in the logs that's relevant to homekit.  As far as I can tell it never sends anything to the device to trigger it to show the pairing code.

With those debug flags you should be seeing something like:
Discovered device xx:xx:xx:xx:xx:xx
Is it paired with a iPhone/ tablet? Try resetting homekit on the ecobee, it can only pair with 1 device.

Neither thermostat is paired with anything (ever).
I see it showing it discovered two thermostats on startup.  When I click configure it shows no debug.

Have you tried entering a random/ wrong code? It can happen that After the wrong code  it Will show the right code on the ecobee... This is the way on a lyric thermostat

I have. Neither thermostat ever shows a code.
If I try and pair with my phone or tablet, it prompts with a code.  Then I cancel and try pairing with Home Assistant, and nothing.

After looking a bit, I believe Home Assistant uses HomeKit Python here: https://github.com/jlusiardi/homekit_python
I tested using it directly from the CLI with python3 -m homekit.discover, but it could not even detect my Ecobee device at all. It discovers other HomeKit devices just fine though; just not Ecobee.
With that, I'm believing that the issue probably lies with the HomeKit Python implementation rather than necessarily Home Assistant itself.

So something is up... it does detect my thermostats:

So that parts working.  It's when I try to configure them, I never get the prompt on the thermostats with the code.

I appear to have the same problem. Only twice, out of many attempts did my ecobee3 display a PIN during discovery.  Neither attempt to configure with the pin succeeded.
In the log I see this:
'018-11-14 15:40:33 INFO (MainThread) [homeassistant.components.discovery] Found new service: homekit {'properties': {'sh': 'rp34aA==', 'MFG': 'ecobee Inc.', 'sf': '1', 'md': 'ecobee3', 'pv': '1.1', 'id': '44:61:32:ED:31:C1', 's#': '1', 'serial_number': '316537030666', 'ci': '9', 'c#': '6', 'ff': '1'}, 'port': 1200, 'name': 'Home1', 'hostname': 'Home1.local.', 'host': '<IP_ADDRESS>'}'
Which makes sense to me.
When I attempt to configure with (I think) or without (mostly) the ecobee displaying a PIN the log shows:
Error executing service <ServiceCall configurator.configure (c:505b471f7433486ca9b1acfdd05d1bd4): fields=, configure_id=1716039024-1>
Traceback (most recent call last):
File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/core.py", line 1177, in _event_to_service_call
await service_handler.func(service_call)
File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/configurator.py", line 221, in async_handle_service_call
call.data.get(ATTR_FIELDS, {}))
File "/usr/lib/python3.5/asyncio/futures.py", line 380, in iter
yield self  # This tells Task to wait for completion.
File "/usr/lib/python3.5/asyncio/tasks.py", line 304, in _wakeup
future.result()
File "/usr/lib/python3.5/asyncio/futures.py", line 293, in result
raise self._exception
File "/usr/lib/python3.5/concurrent/futures/thread.py", line 55, in run
result = self.fn(*self.args, **self.kwargs)
File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/homekit_controller/init.py", line 187, in device_config_callback
code = callback_data.get('code').strip()
AttributeError: 'NoneType' object has no attribute 'strip'
Help appreciated.
Wes

Re post above:
Pi2B, Hassbian, HA 0.82.0

Hey guys - i've been done some work on homekit_controller recently and could try and look at this if there is someone on a UKish timezone willing to help (I don't have one of these devices to test so you'll have to be my eyes and ears).

Hi,I'm 5 hours from you in Ontario Canada and keen to help. I have an Ecobee3 thermostat and have HA on a Pie2B running Hassbian with latest current version sw. I'm not a programmer but am moderately technical (retired EE). My last comment on thread #15336 talks about the Ecobee3 displaying a brief flash of an 8 digit PIN. To me this suggests perhaps a timer value set incorrectly somewhere.  When told to display a PIN, the Ecobee3 must set an internal timeout running so it will return to a normal display. This feature is not likely to be broken.  I have tried making sense of the Apple spec with little success.I have no Homekit experience and no Apple devices (but I can borrow from time to time). The reason I want to connect using Homekit in this case is that the connection will be local and hopefully fast compared to using the Ecobee Servers over the net where delays are too long (occupancy sensors).WesOn Feb 3, 2019 4:18 PM, Jc2k<EMAIL_ADDRESS>wrote:Hey guys - i've been done some work on homekit_controller recently and could try and look at this if there is someone on a UKish timezone willing to help (I don't have one of these devices to test so you'll have to be my eyes and ears).
—You are receiving this because you commented.Reply to this email directly, view it on GitHub, or mute the thread.

Hi @wes-warner
So I've never had to look too much at the pairing code before, I think the underlying library has never had to deal with an accessory that displays its own codes. I think both I and the author only have devices that have static codes (like this). It sounds in the spec like on devices with displays these codes might change every time as well - can you confirm the code changes every time you see it?
I've noticed when testing changes with my iPhone that it sends its M1 request (section 4.7.1, page 39) at the point just before an iPhone is asking you to enter a code. Whereas the homekit library and thus HA send it right before using your setup code that you already entered. On an iPhone, no other requests are sent until you've entered a code. So I think the M1 request might trigger the display. Yep, the docs seem to confirm that in 4.7.2 SRP Start Response on page 40.  Doesn't let you control how long that request is valid for or how long to show anything on the screen, though.
So I suspect what happens:

You enter a random (or old) setup code
HA sends a M1 Pair Setup request
Ecobee triggers the display as part of its M2 response
HA sends a M3 SRP Verify Request and that never matches the code that was briefly shown
The pairing attempt is over, so the screen returns to normal

Even if you do see the code, the code is now invalid and you are back to square one.
And we need to change that flow to:

HA sends a M1 Pair Setup request
Ecobee triggers the display as part of its M2 response
You enter the code on the screen
HA sends a M3 SRP Verify Request and now it matches
The pairing attempt is over, so the screen returns to normal

I want to see if this is right so step 1 will be to make a branch of homekit that asks for a password at the last possible moment. I'll be back when I have something...

Yes the displayed PIN changes at each attempt. Sounds like you have a good plan.I will wait until you have something for me to try.Good hunting.WesOn Feb 4, 2019 3:03 AM, Jc2k<EMAIL_ADDRESS>wrote:Hi @wes-warner
So I've never had to look too much at the pairing code before, I think the underlying library has never had to deal with an accessory that displays its own codes. I think both I and the author only have devices that have static codes (like this). It sounds in the spec like on devices with displays these codes might change every time as well - can you confirm the code changes every time you see it?
I've noticed when testing changes with my iPhone that it sends its M1 request (section 4.7.1, page 39) at the point just before an iPhone is asking you to enter a code. Whereas the homekit library and thus HA send it right before using your setup code that you already entered. On an iPhone, no other requests are sent until you've entered a code. So I think the M1 request might trigger the display. Yep, the docs seem to confirm that in 4.7.2 SRP Start Response on page 40.  Doesn't let you control how long that request is valid for or how long to show anything on the screen, though.
So I suspect what happens:
You enter a random (or old) setup codeHA sends a M1 Pair Setup requestEcobee triggers the display as part of its M2 responseHA sends a M3 SRP Verify Request and that never matches the code that was briefly shownThe pairing attempt is over, so the screen returns to normal
Even if you do see the code, the code is now invalid and you are back to square one.
And we need to change that flow to:
HA sends a M1 Pair Setup requestEcobee triggers the display as part of its M2 responseYou enter the code on the screenHA sends a M3 SRP Verify Request and now it matchesThe pairing attempt is over, so the screen returns to normal
I want to see if this is right so step 1 will be to make a branch of homekit that asks for a password at the last possible moment. I'll be back when I have something...
—You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or mute the thread.

OK - i've put together a proof of concept where it sends a pair setup command to the device and then prompts you to enter the pin code, rather than requiring it up front. This is a bit of a hack, just to see if its enough to get the ecobee working.
Here's a shell session showing it working from a Mac against a mock homekit device. Should work on Debian/Ubuntu/Raspbian without much problem. Can you follow allong and see how it works for you?
$ python3 -m venv venv
$ source venv/bin/activate

$ pip install https://github.com/Jc2k/homekit_python/archive/ecobee.zip
Collecting https://github.com/Jc2k/homekit_python/archive/ecobee.zip
  Downloading https://github.com/Jc2k/homekit_python/archive/ecobee.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://<IP_ADDRESS>: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.

Hi,
You test script worked fine the first try. I changed the MAC address to my device's, the name to ecobee3, and added double quotes on the last line.  Below is a screen copy.  Note some device attributes are unknown.
Wes
$ pip install https://github.com/Jc2k/homekit_python/archive/ecobee.zipCollecting https://github.com/Jc2k/homekit_python/archive/ecobee.zip  Downloading https://github.com/Jc2k/homekit_python/archive/ecobee.zip     | 1.5MB 8.9MB/sCollecting cryptography (from homekit==0.12.2)  Downloading https://www.piwheels.org/simple/cryptography/cryptography-2.5-cp35-cp35m-linux_armv7l.whl (865kB)    100% |????????????????????????????????| 870kB 189kB/sCollecting ed25519 (from homekit==0.12.2)  Downloading https://www.piwheels.org/simple/ed25519/ed25519-1.4-cp35-cp35m-linux_armv7l.whl (142kB)    100% |????????????????????????????????| 143kB 442kB/sCollecting hkdf (from homekit==0.12.2)  Downloading https://www.piwheels.org/simple/hkdf/hkdf-0.0.3-py3-none-any.whlCollecting zeroconf (from homekit==0.12.2)  Downloading https://files.pythonhosted.org/packages/d2/4e/3e751bc1f33d0368bdba509a140cb9f2e54cd1cfb8ebcf4ebd8a5eef794b/zeroconf-0.21.3-py2.py3-none-any.whlCollecting six>=1.4.1 (from cryptography->homekit==0.12.2)  Downloading https://files.pythonhosted.org/packages/73/fb/00a976f728d0d1fecfe898238ce23f502a721c0ac0ecfedb80e0d88c64e9/six-1.12.0-py2.py3-none-any.whlCollecting cffi!=1.11.3,>=1.8 (from cryptography->homekit==0.12.2)  Downloading https://www.piwheels.org/simple/cffi/cffi-1.11.5-cp35-cp35m-linux_armv7l.whl (304kB)    100% |????????????????????????????????| 307kB 381kB/sCollecting asn1crypto>=0.21.0 (from cryptography->homekit==0.12.2)  Downloading https://files.pythonhosted.org/packages/ea/cd/35485615f45f30a510576f1a56d1e0a7ad7bd8ab5ed7cdc600ef7cd06222/asn1crypto-0.24.0-py2.py3-none-any.whl (101kB)    100% |????????????????????????????????| 102kB 963kB/sCollecting ifaddr (from zeroconf->homekit==0.12.2)  Downloading https://www.piwheels.org/simple/ifaddr/ifaddr-0.1.6-py3-none-any.whlCollecting pycparser (from cffi!=1.11.3,>=1.8->cryptography->homekit==0.12.2)  Downloading https://www.piwheels.org/simple/pycparser/pycparser-2.19-py2.py3-none-any.whl (111kB)    100% |????????????????????????????????| 112kB 340kB/sInstalling collected packages: six, pycparser, cffi, asn1crypto, cryptography, ed25519, hkdf, ifaddr, zeroconf, homekit  Running setup.py install for homekit ... doneSuccessfully 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(venv) pi@hassbian:~ $
(venv) pi@hassbian:~ $ python -m homekit.discoverName: HomeW._hap._tcp.local.Url: http_impl://<IP_ADDRESS>:1200Configuration number (c#): 9Feature Flags (ff): Supports Pairing (Flag: 1)Device ID (id): C3:0F:19:BF:2C:39Model Name (md): ecobee3Protocol Version (pv): 1.1State Number (s#): 1Status Flags (sf): 1Category Identifier (ci): Thermostat (Id: 9)
(venv) pi@hassbian:~ $ echo '{}' > pairing.json(venv) pi@hassbian:~ $ python -m homekit.pair -d C3:0F:19:BF:2C:39  -f pairing.json -a ecobee3Enter your setup code: 242-43-120/home/pi/venv/lib/python3.5/site-packages/cryptography/hazmat/backends/openssl/x25519.py:35: CryptographyDeprecationWarning: public_bytes now requires encoding and format arguments. Support for calling without arguments will be removed in cryptography 2.7  utils.DeprecatedIn25,Pairing for ecobee3 was established.(venv) pi@hassbian:~ $
(venv) pi@hassbian:~ $ python -m homekit.get_accessories -f pairing.json -a "ecobee3"/home/pi/venv/lib/python3.5/site-packages/cryptography/hazmat/backends/openssl/x25519.py:35: CryptographyDeprecationWarning: public_bytes now requires encoding and format arguments. Support for calling without arguments will be removed in cryptography 2.7  utils.DeprecatedIn25,1.1: >accessory-information<  1.2: HomeW () >name< [pr]  1.3: ecobee Inc. () >manufacturer< [pr]  1.4:<PHONE_NUMBER>66 () >serial-number< [pr]  1.5: ecobee3 () >model< [pr]  1.6:  () >identify< [pw]  1.8: 4.2.394 () >firmware.revision< [pr]  1.9: 0 () >accessory-properties< [pr,ev]1.30: >Unknown Service: A2<  1.31: 1.1.0 () >version< [pr]1.16: >thermostat<  1.17: 0 () >heating-cooling.current< [pr,ev]  1.18: 1 () >heating-cooling.target< [pr,pw,ev]  1.19: 22.2 () >temperature.current< [pr,ev]  1.20: 22.2 () >temperature.target< [pr,pw,ev]  1.21: 1 () >temperature.units< [pr,pw,ev]  1.22: 24.4 () >temperature.cooling-threshold< [pr,pw,ev]  1.23: 22.2 () >temperature.heating-threshold< [pr,pw,ev]  1.24: 31.0 () >relative-humidity.current< [pr,ev]  1.25: 36.0 () >relative-humidity.target< [pr,pw,ev]  1.27: HomeW () >name< [pr]  1.33: 0 () >Unknown Characteristic B7DDB9A3-54BB-4572-91D2-F1F5B0510F8C< [pr,ev]  1.34: 22.2 () >Unknown Characteristic E4489BBC-5227-4569-93E5-B345E3E5508F< [pr,pw,ev]  1.35: 24.4 () >Unknown Characteristic 7D381BAA-20F9-40E5-9BE9-AEB92D4BECEF< [pr,pw,ev]  1.36: 17.8 () >Unknown Characteristic 73AAB542-892A-4439-879A-D2A883724B69< [pr,pw,ev]  1.37: 27.8 () >Unknown Characteristic 5DA985F0-898A-4850-B987-B76C6C78D670< [pr,pw,ev]  1.38: 18.9 () >Unknown Characteristic 05B97374-6DC0-439B-A0FA-CA33F612D425< [pr,pw,ev]  1.39: 26.7 () >Unknown Characteristic A251F6E7-AC46-4190-9C5D-3D06277BDF9F< [pr,pw,ev]  1.40:  () >Unknown Characteristic 1B300BC2-CFFC-47FF-89F9-BD6CCF5F2853< [pw]  1.41: 2014-01-03T00:00:00-05:00 () >Unknown Characteristic 1621F556-1367-443C-AF19-82AF018E99DE< [pr,pw,ev]  1.48:  () >Unknown Characteristic FA128DE6-9D7D-49A4-B6D8-4E4E234DEE38< [pw]  1.49: 1 () >Unknown Characteristic 4A6AE4F6-036C-495D-87CC-B3702B437741< [pr,ev]  1.50: 0 () >Unknown Characteristic DB7BF261-7042-4194-8BD1-3AA22830AEDD< [pr,ev]  1.51: False () >Unknown Characteristic 41935E3E-B54D-42E9-B8B9-D33C6319F0AF< [pr,ev]  1.52: 0 () >Unknown Characteristic C35DA3C0-E004-40E3-B153-46655CDD9214< [pr,pw,ev]  1.53: 0 () >Unknown Characteristic 48F62AEC-4171-4B4A-8F0E-1EEB6708B3FB< [pr,ev]  1.54: Your ecobee3 thermostat is now paired with HomeKit. () >Unknown Characteristic 1B1515F2-CC45-409F-991F-C480987F92C3< [pr,ev]1.56: >motion<  1.28: HomeW () >name< [pr]  1.66: True () >motion-detected< [pr,ev]  1.67: 190 () >Unknown Characteristic BFE61C70-4A40-11E6-BDF4-0800200C9A66< [pr,ev]1.57: >occupancy<  1.29: HomeW () >name< [pr]  1.65: 1 () >occupancy-detected< [pr,ev]  1.68: 190 () >Unknown Characteristic A8f798E0-4A40-11E6-BDF4-0800200C9A66< [pr,ev]2.1: >accessory-information<  2.2049: Kitchen () >name< [pr]  2.2050: ecobee Inc. () >manufacturer< [pr]  2.2051: GY6X () >serial-number< [pr]  2.2052: REMOTE SENSOR () >model< [pr]  2.8: 1.0.0 () >firmware.revision< [pr]  2.2053:  () >identify< [pw]2.55: >temperature<  2.2064: 21.4 () >temperature.current< [pr,ev]  2.2067: Kitchen () >name< [pr]  2.2066: True () >status-active< [pr,ev]  2.2065: 0 () >status-lo-batt< [pr,ev]2.56: >motion<  2.2060: True () >motion-detected< [pr,ev]  2.2063: Kitchen () >name< [pr]  2.2062: True () >status-active< [pr,ev]  2.2061: 0 () >status-lo-batt< [pr,ev]  2.2059: 955 () >Unknown Characteristic BFE61C70-4A40-11E6-BDF4-0800200C9A66< [pr,ev]3.1: >accessory-information<  3.3073: Pourch () >name< [pr]  3.3074: ecobee Inc. () >manufacturer< [pr]  3.3075: D36S () >serial-number< [pr]  3.3076: REMOTE SENSOR () >model< [pr]  3.8: 1.0.0 () >firmware.revision< [pr]  3.3077:  () >identify< [pw]3.55: >temperature<  3.3088: 6.1 () >temperature.current< [pr,ev]  3.3091: Pourch () >name< [pr]  3.3090: True () >status-active< [pr,ev]  3.3089: 0 () >status-lo-batt< [pr,ev]3.56: >motion<  3.3084: True () >motion-detected< [pr,ev]  3.3087: Pourch () >name< [pr]  3.3086: True () >status-active< [pr,ev]  3.3085: 0 () >status-lo-batt< [pr,ev]  3.3083: 878 () >Unknown Characteristic BFE61C70-4A40-11E6-BDF4-0800200C9A66< [pr,ev]4.1: >accessory-information<  4.4097: Basement () >name< [pr]  4.4098: ecobee Inc. () >manufacturer< [pr]  4.4099: D3TP () >serial-number< [pr]  4.4100: REMOTE SENSOR () >model< [pr]  4.8: 1.0.0 () >firmware.revision< [pr]  4.4101:  () >identify< [pw]4.55: >temperature<  4.4112: 20.9 () >temperature.current< [pr,ev]  4.4115: Basement () >name< [pr]  4.4114: True () >status-active< [pr,ev]  4.4113: 0 () >status-lo-batt< [pr,ev]4.56: >motion<  4.4108: False () >motion-detected< [pr,ev]  4.4111: Basement () >name< [pr]  4.4110: True () >status-active< [pr,ev]  4.4109: 0 () >status-lo-batt< [pr,ev]  4.4107: 15808 () >Unknown Characteristic BFE61C70-4A40-11E6-BDF4-0800200C9A66< pr,ev pi@hassbian:~ $
(venv) pi@hassbian:~ $ python -m homekit.unpair -f pairing.json -a "ecobee3"/home/pi/venv/lib/python3.5/site-packages/cryptography/hazmat/backends/openssl/x25519.py:35: CryptographyDeprecationWarning: public_bytes now requires encoding and format arguments. Support for calling without arguments will be removed in cryptography 2.7  utils.DeprecatedIn25,Pairing for ecobee3 was removed.(venv) pi@hassbian:~ $---------------------------------------------------------------------------------
On Monday, February 4, 2019, 10:26:44 a.m. EST, Jc2k<EMAIL_ADDRESS>wrote:

OK - i've put together a proof of concept where it sends a pair setup command to the device and then prompts you to enter the pin code, rather than requiring it up front. This is a bit of a hack, just to see if its enough to get the ecobee working.
Here's a shell session showing it working from a Mac against a mock homekit device. Should work on Debian/Ubuntu/Raspbian without much problem. Can you follow allong and see how it works for you?
$ python3 -m venv venv
$ source venv/bin/activate
$ pip install https://github.com/Jc2k/homekit_python/archive/ecobee.zip
Collecting https://github.com/Jc2k/homekit_python/archive/ecobee.zip
Downloading https://github.com/Jc2k/homekit_python/archive/ecobee.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://<IP_ADDRESS>: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.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

This time without word wrapping
$ pip install https://github.com/Jc2k/homekit_python/archive/ecobee.zip
Collecting https://github.com/Jc2k/homekit_python/archive/ecobee.zip
Downloading https://github.com/Jc2k/homekit_python/archive/ecobee.zip
| 1.5MB 8.9MB/s
Collecting cryptography (from homekit==0.12.2)
Downloading https://www.piwheels.org/simple/cryptography/cryptography-2.5-cp35-cp35m-linux_armv7l.whl (865kB)
100% |????????????????????????????????| 870kB 189kB/s
Collecting ed25519 (from homekit==0.12.2)
Downloading https://www.piwheels.org/simple/ed25519/ed25519-1.4-cp35-cp35m-linux_armv7l.whl (142kB)
100% |????????????????????????????????| 143kB 442kB/s
Collecting hkdf (from homekit==0.12.2)
Downloading https://www.piwheels.org/simple/hkdf/hkdf-0.0.3-py3-none-any.whl
Collecting zeroconf (from homekit==0.12.2)
Downloading https://files.pythonhosted.org/packages/d2/4e/3e751bc1f33d0368bdba509a140cb9f2e54cd1cfb8ebcf4ebd8a5eef794b/zeroconf-0.21.3-py2.py3-none-any.whl
Collecting six>=1.4.1 (from cryptography->homekit==0.12.2)
Downloading 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)
Downloading https://www.piwheels.org/simple/cffi/cffi-1.11.5-cp35-cp35m-linux_armv7l.whl (304kB)
100% |????????????????????????????????| 307kB 381kB/s
Collecting asn1crypto>=0.21.0 (from cryptography->homekit==0.12.2)
Downloading https://files.pythonhosted.org/packages/ea/cd/35485615f45f30a510576f1a56d1e0a7ad7bd8ab5ed7cdc600ef7cd06222/asn1crypto-0.24.0-py2.py3-none-any.whl (101kB)
100% |????????????????????????????????| 102kB 963kB/s
Collecting ifaddr (from zeroconf->homekit==0.12.2)
Downloading https://www.piwheels.org/simple/ifaddr/ifaddr-0.1.6-py3-none-any.whl
Collecting pycparser (from cffi!=1.11.3,>=1.8->cryptography->homekit==0.12.2)
Downloading https://www.piwheels.org/simple/pycparser/pycparser-2.19-py2.py3-none-any.whl (111kB)
100% |????????????????????????????????| 112kB 340kB/s
Installing collected packages: six, pycparser, cffi, asn1crypto, cryptography, ed25519, hkdf, ifaddr, zeroconf, 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
(venv) pi@hassbian:~ $
(venv) pi@hassbian:~ $ python -m homekit.discover
Name: HomeW._hap._tcp.local.
Url: http_impl://<IP_ADDRESS>:1200
Configuration number (c#): 9
Feature Flags (ff): Supports Pairing (Flag: 1)
Device ID (id): C3:0F:19:BF:2C:39
Model Name (md): ecobee3
Protocol Version (pv): 1.1
State Number (s#): 1
Status Flags (sf): 1
Category Identifier (ci): Thermostat (Id: 9)
(venv) pi@hassbian:~ $ echo '{}' > pairing.json
(venv) pi@hassbian:~ $ python -m homekit.pair -d C3:0F:19:BF:2C:39  -f pairing.json -a ecobee3
Enter your setup code: 242-43-120
/home/pi/venv/lib/python3.5/site-packages/cryptography/hazmat/backends/openssl/x25519.py:35: CryptographyDeprecationWarning: public_bytes now requires encoding and format arguments. Support for calling without arguments will be removed in cryptography 2.7
utils.DeprecatedIn25,
Pairing for ecobee3 was established.
(venv) pi@hassbian:~ $
(venv) pi@hassbian:~ $ python -m homekit.get_accessories -f pairing.json -a "ecobee3"
/home/pi/venv/lib/python3.5/site-packages/cryptography/hazmat/backends/openssl/x25519.py:35: CryptographyDeprecationWarning: public_bytes now requires encoding and format arguments. Support for calling without arguments will be removed in cryptography 2.7
utils.DeprecatedIn25,
1.1: >accessory-information<
1.2: HomeW () >name< [pr]
1.3: ecobee Inc. () >manufacturer< [pr]
1.4:<PHONE_NUMBER>66 () >serial-number< [pr]
1.5: ecobee3 () >model< [pr]
1.6:  () >identify< [pw]
1.8: 4.2.394 () >firmware.revision< [pr]
1.9: 0 () >accessory-properties< [pr,ev]
1.30: >Unknown Service: A2<
1.31: 1.1.0 () >version< [pr]
1.16: >thermostat<
1.17: 0 () >heating-cooling.current< [pr,ev]
1.18: 1 () >heating-cooling.target< [pr,pw,ev]
1.19: 22.2 () >temperature.current< [pr,ev]
1.20: 22.2 () >temperature.target< [pr,pw,ev]
1.21: 1 () >temperature.units< [pr,pw,ev]
1.22: 24.4 () >temperature.cooling-threshold< [pr,pw,ev]
1.23: 22.2 () >temperature.heating-threshold< [pr,pw,ev]
1.24: 31.0 () >relative-humidity.current< [pr,ev]
1.25: 36.0 () >relative-humidity.target< [pr,pw,ev]
1.27: HomeW () >name< [pr]
1.33: 0 () >Unknown Characteristic B7DDB9A3-54BB-4572-91D2-F1F5B0510F8C< [pr,ev]
1.34: 22.2 () >Unknown Characteristic E4489BBC-5227-4569-93E5-B345E3E5508F< [pr,pw,ev]
1.35: 24.4 () >Unknown Characteristic 7D381BAA-20F9-40E5-9BE9-AEB92D4BECEF< [pr,pw,ev]
1.36: 17.8 () >Unknown Characteristic 73AAB542-892A-4439-879A-D2A883724B69< [pr,pw,ev]
1.37: 27.8 () >Unknown Characteristic 5DA985F0-898A-4850-B987-B76C6C78D670< [pr,pw,ev]
1.38: 18.9 () >Unknown Characteristic 05B97374-6DC0-439B-A0FA-CA33F612D425< [pr,pw,ev]
1.39: 26.7 () >Unknown Characteristic A251F6E7-AC46-4190-9C5D-3D06277BDF9F< [pr,pw,ev]
1.40:  () >Unknown Characteristic 1B300BC2-CFFC-47FF-89F9-BD6CCF5F2853< [pw]
1.41: 2014-01-03T00:00:00-05:00 () >Unknown Characteristic 1621F556-1367-443C-AF19-82AF018E99DE< [pr,pw,ev]
1.48:  () >Unknown Characteristic FA128DE6-9D7D-49A4-B6D8-4E4E234DEE38< [pw]
1.49: 1 () >Unknown Characteristic 4A6AE4F6-036C-495D-87CC-B3702B437741< [pr,ev]
1.50: 0 () >Unknown Characteristic DB7BF261-7042-4194-8BD1-3AA22830AEDD< [pr,ev]
1.51: False () >Unknown Characteristic 41935E3E-B54D-42E9-B8B9-D33C6319F0AF< [pr,ev]
1.52: 0 () >Unknown Characteristic C35DA3C0-E004-40E3-B153-46655CDD9214< [pr,pw,ev]
1.53: 0 () >Unknown Characteristic 48F62AEC-4171-4B4A-8F0E-1EEB6708B3FB< [pr,ev]
1.54: Your ecobee3 thermostat is now paired with HomeKit. () >Unknown Characteristic 1B1515F2-CC45-409F-991F-C480987F92C3< [pr,ev]
1.56: >motion<
1.28: HomeW () >name< [pr]
1.66: True () >motion-detected< [pr,ev]
1.67: 190 () >Unknown Characteristic BFE61C70-4A40-11E6-BDF4-0800200C9A66< [pr,ev]
1.57: >occupancy<
1.29: HomeW () >name< [pr]
1.65: 1 () >occupancy-detected< [pr,ev]
1.68: 190 () >Unknown Characteristic A8f798E0-4A40-11E6-BDF4-0800200C9A66< [pr,ev]
2.1: >accessory-information<
2.2049: Kitchen () >name< [pr]
2.2050: ecobee Inc. () >manufacturer< [pr]
2.2051: GY6X () >serial-number< [pr]
2.2052: REMOTE SENSOR () >model< [pr]
2.8: 1.0.0 () >firmware.revision< [pr]
2.2053:  () >identify< [pw]
2.55: >temperature<
2.2064: 21.4 () >temperature.current< [pr,ev]
2.2067: Kitchen () >name< [pr]
2.2066: True () >status-active< [pr,ev]
2.2065: 0 () >status-lo-batt< [pr,ev]
2.56: >motion<
2.2060: True () >motion-detected< [pr,ev]
2.2063: Kitchen () >name< [pr]
2.2062: True () >status-active< [pr,ev]
2.2061: 0 () >status-lo-batt< [pr,ev]
2.2059: 955 () >Unknown Characteristic BFE61C70-4A40-11E6-BDF4-0800200C9A66< [pr,ev]
3.1: >accessory-information<
3.3073: Pourch () >name< [pr]
3.3074: ecobee Inc. () >manufacturer< [pr]
3.3075: D36S () >serial-number< [pr]
3.3076: REMOTE SENSOR () >model< [pr]
3.8: 1.0.0 () >firmware.revision< [pr]
3.3077:  () >identify< [pw]
3.55: >temperature<
3.3088: 6.1 () >temperature.current< [pr,ev]
3.3091: Pourch () >name< [pr]
3.3090: True () >status-active< [pr,ev]
3.3089: 0 () >status-lo-batt< [pr,ev]
3.56: >motion<
3.3084: True () >motion-detected< [pr,ev]
3.3087: Pourch () >name< [pr]
3.3086: True () >status-active< [pr,ev]
3.3085: 0 () >status-lo-batt< [pr,ev]
3.3083: 878 () >Unknown Characteristic BFE61C70-4A40-11E6-BDF4-0800200C9A66< [pr,ev]
4.1: >accessory-information<
4.4097: Basement () >name< [pr]
4.4098: ecobee Inc. () >manufacturer< [pr]
4.4099: D3TP () >serial-number< [pr]
4.4100: REMOTE SENSOR () >model< [pr]
4.8: 1.0.0 () >firmware.revision< [pr]
4.4101:  () >identify< [pw]
4.55: >temperature<
4.4112: 20.9 () >temperature.current< [pr,ev]
4.4115: Basement () >name< [pr]
4.4114: True () >status-active< [pr,ev]
4.4113: 0 () >status-lo-batt< [pr,ev]
4.56: >motion<
4.4108: False () >motion-detected< [pr,ev]
4.4111: Basement () >name< [pr]
4.4110: True () >status-active< [pr,ev]
4.4109: 0 () >status-lo-batt< [pr,ev]
4.4107: 15808 () >Unknown Characteristic BFE61C70-4A40-11E6-BDF4-0800200C9A66< [pr,ev]
(venv) pi@hassbian:~ $
(venv) pi@hassbian:~ $ python -m homekit.unpair -f pairing.json -a "ecobee3"
/home/pi/venv/lib/python3.5/site-packages/cryptography/hazmat/backends/openssl/x25519.py:35: CryptographyDeprecationWarning: public_bytes now requires encoding and format arguments. Support for calling without arguments will be removed in cryptography 2.7
utils.DeprecatedIn25,
Pairing for ecobee3 was removed.
(venv) pi@hassbian:~ $

Looking good!
On GitHub If you do ``` on the line before and the line after your console output it will use a monospace font and be easier to read :-)
The unknown characteristics can be probably be ignored. They look to be temperature related, but they are not Apple standard ones as far as I can tell. The important thing is we can see a thermostat service and multiple accessories with a motion and temperature service.
So if you do this again, but don't do the last bit to unpair you will be left with a pairing.json with all the crypto keys needed to make it work with HA. You should just be able to drop it into your HA config directory, off the top of my head $CONFIG_DIR/.homekit/pairing.json, then restart HA. If you do that now we should be able to get an idea of whether the HA side of the code works. What i'm expecting is:

With HA 0.86 this should work, more or less, but you might get timeouts that require a HA restart. This can happen pretty quickly depending on the device. There is also a potential gotcha - you might see a KeyError about a field called valid-values. If that happens we are stuck again. If it does work, only the thermostat component will be understood.

With HA 0.87 (in beta), the timeouts are fixed, the KeyError should be worked around and the motion sensors will be detected and work, but at the moment only in polling mode (once a minute). I'm working on event supported but its a little way off.

I'm hoping that if you drop the pairing.json in the right place and restart your HA you will be able to control the target temperature etc from HA. If that's the case I'll get to work on getting this change properly upstream.

Will do as you suggest above, but first a note as to where I was headed in starting this.
As of now I don't plan to change Ecobee settings via HA.  All I need with the Homekit link is (preferably quick) access to sensor data.
I use the Ecobee android app when away from home, such as to set the temp so it is comfy when we get there.  Our home is very well insulated and the boiler/air handler/air conditioner are sized small for max efficiency. As a consequence the home responds slowly to a request for a temp change.  The ecobee does a good job of anticipating this for scheduled changes.  I suppose  geofencing could track us driving home from Florida and turn heat up 3 hours or so before we get there, but life is short....
As you may see from the info above I have 3 Ecobee remote sensors that track temperature and occupancy/motion in three rooms: Kitchen, Basement (family room) and Porch (3 season room with
overhead radiant electric heat for occasional cold weather use).  I want to use the Porch sensor via HA/Homekit to control the Porch temperature using the radiant heaters  when I ask for it (via Alexa) or first occupy the porch and so long as the porch remains occupied. If the Homekit connection is quick enough ( a second or so) I could control porch lights as well.
Wes

I copied the pairing.json file to ..../.homekit and rebooted.  No error is logged but HA still wants to configure ecobee ie it displays the Configurator card for ecobee3.
Wes

Good background info, thanks for that. The occupancy sensors should work in 0.87, but until I add events in they are going to be slow (1 minute poll). I don't have an ETA for that, there is a prototype but its currently queued up behind my bluetooth patches.
I forgot an important step with pairing.json. HA will choose a different alias to what we did. I don't have the code in front of me right now, but I think if you open pairing.json in a text editor you'll have something like:
{
  "ecobee3": {
    "iOSAccessoryId": "...........",
    "snip": ".....",
  }
}

You need to replace "ecobee3" with the serial number of your device (the one that you passed on the pair command line, so in my example it would be
{
  "10:30:10:00:00:00": {
       ... snip ...
  }
}

Now if you restart HA it should be able to see the ecobee3 pairing details....

Changed pairing.json per above, rebooted. Moving forward but not there yet. Log below:
.......
2019-02-05 09:52:12 INFO (MainThread) [homeassistant.setup] Setting up homekit_controller
2019-02-05 09:52:13 INFO (MainThread) [homeassistant.setup] Setup of domain homekit_controller took 1.3 seconds.
2019-02-05 09:52:13 DEBUG (Thread-19) [homeassistant.components.homekit_controller] Discovered unique device C3:0F:19:BF:2C:39
2019-02-05 09:52:13 INFO (Thread-19) [homeassistant.components.homekit_controller] Setting up Homekit device ecobee3
2019-02-05 09:52:13 INFO (Thread-19) [homeassistant.loader] Loaded configurator from homeassistant.components.configurator
2019-02-05 09:52:15 DEBUG (Thread-19) [homeassistant.components.homekit_controller] Found accessory-information
2019-02-05 09:52:15 DEBUG (Thread-19) [homeassistant.components.homekit_controller] Found Unknown Service: A2
2019-02-05 09:52:15 DEBUG (Thread-19) [homeassistant.components.homekit_controller] Found thermostat
2019-02-05 09:52:15 DEBUG (Thread-19) [homeassistant.components.homekit_controller] Found motion
2019-02-05 09:52:15 DEBUG (Thread-19) [homeassistant.components.homekit_controller] Found occupancy
2019-02-05 09:52:15 DEBUG (Thread-19) [homeassistant.components.homekit_controller] Found accessory-information
2019-02-05 09:52:15 DEBUG (Thread-19) [homeassistant.components.homekit_controller] Found temperature
2019-02-05 09:52:15 DEBUG (Thread-19) [homeassistant.components.homekit_controller] Found motion
2019-02-05 09:52:15 DEBUG (Thread-19) [homeassistant.components.homekit_controller] Found accessory-information
2019-02-05 09:52:15 DEBUG (Thread-19) [homeassistant.components.homekit_controller] Found temperature
2019-02-05 09:52:15 DEBUG (Thread-19) [homeassistant.components.homekit_controller] Found motion
2019-02-05 09:52:15 DEBUG (Thread-19) [homeassistant.components.homekit_controller] Found accessory-information
2019-02-05 09:52:15 DEBUG (Thread-19) [homeassistant.components.homekit_controller] Found temperature
2019-02-05 09:52:15 DEBUG (Thread-19) [homeassistant.components.homekit_controller] Found motion
2019-02-05 09:52:16 INFO (MainThread) [homeassistant.loader] Loaded climate from homeassistant.components.climate
2019-02-05 09:52:16 INFO (MainThread) [homeassistant.setup] Setting up climate
2019-02-05 09:52:16 INFO (MainThread) [homeassistant.setup] Setup of domain climate took 0.0 seconds.
2019-02-05 09:52:16 INFO (MainThread) [homeassistant.loader] Loaded climate.homekit_controller from homeassistant.components.climate.homekit_controller
2019-02-05 09:52:16 INFO (MainThread) [homeassistant.components.climate] Setting up climate.homekit_controller
2019-02-05 09:52:19 ERROR (MainThread) [homeassistant.components.climate] homekit_controller: Error on device update!
Traceback (most recent call last):
File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/helpers/entity_platform.py", line 248, in _async_add_entity
await entity.async_device_update(warning=False)
File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/helpers/entity.py", line 349, in async_device_update
await self.hass.async_add_executor_job(self.update)
File "/usr/lib/python3.5/asyncio/futures.py", line 380, in iter
yield self  # This tells Task to wait for completion.
File "/usr/lib/python3.5/asyncio/tasks.py", line 304, in _wakeup
future.result()
File "/usr/lib/python3.5/asyncio/futures.py", line 293, in result
raise self._exception
File "/usr/lib/python3.5/concurrent/futures/thread.py", line 55, in run
result = self.fn(*self.args, **self.kwargs)
File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/homekit_controller/init.py", line 213, in update
self.update_characteristics(service['characteristics'])
File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/climate/homekit_controller.py", line 53, in update_characteristics
from homekit.models.characteristics import CharacteristicsTypes
ImportError: No module named 'homekit.models'
2019-02-05 09:52:23 INFO (MainThread) [homeassistant.components.http.view] Serving /api/error/all to <IP_ADDRESS> (auth: True)
2019-02-05 09:52:46 INFO (MainThread) [homeassistant.components.http.view] Serving /api/error_log to <IP_ADDRESS> (auth: True)

Ah, I forgot about that. Good news is I found + fixed that in 0.87. If you feel brave you could update /srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/climate/homekit_controller.py.on line 53 the line that reads:
from homekit.models.characteristics import CharacteristicsTypes

should be
from homekit.model.characteristics import CharacteristicsTypes

Worth testing if you can.
Not sure when 0.87 is out but i've refactored things quite a bad and added tests for all the currently supported entities to pick up stuff like that.

Made little edit as above, closer still.

.........
2019-02-05 11:07:44 INFO (MainThread) [homeassistant.components.climate] Setting up climate.homekit_controller
2019-02-05 11:07:47 ERROR (MainThread) [homeassistant.components.climate] homekit_controller: Error on device update!
Traceback (most recent call last):
File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/helpers/entity_platform.py", line 248, in _async_add_entity
await entity.async_device_update(warning=False)
File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/helpers/entity.py", line 349, in async_device_update
await self.hass.async_add_executor_job(self.update)
File "/usr/lib/python3.5/asyncio/futures.py", line 380, in iter
yield self  # This tells Task to wait for completion.
File "/usr/lib/python3.5/asyncio/tasks.py", line 304, in _wakeup
future.result()
File "/usr/lib/python3.5/asyncio/futures.py", line 293, in result
raise self._exception
File "/usr/lib/python3.5/concurrent/futures/thread.py", line 55, in run
result = self.fn(*self.args, **self.kwargs)
File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/homekit_controller/init.py", line 213, in update
self.update_characteristics(service['characteristics'])
File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/climate/homekit_controller.py", line 66, in update_characteristics
mode) for mode in characteristic['valid-values']]
KeyError: 'valid-values'
2019-02-05 11:08:21 INFO (MainThread) [homeassistant.components.http.view] Serving /api/error/all to <IP_ADDRESS> (auth: True)
2019-02-05 11:08:37 INFO (MainThread) [homeassistant.components.http.view] Serving /api/error_log to <IP_ADDRESS> (auth: True)

Aha! Yes, that's also fixed in 0.87. Some HomeKit devices announce whether they support Hot / Cool / Auto / Off operation modes. It looks like this one doesn't. I just have to assume it supports all the modes in 0.87.
So same file, line 66, we can either go for:
                self._valid_modes = [MODE_HOMEKIT_TO_HASS.get(
mode) for mode in characteristic.get('valid-values', [])]

Or
                default_modes = list(MODE_HOMEKIT_TO_HASS)
                valid_values = characteristic.get('valid-values', default_modes)
                self._valid_modes = [
                    MODE_HOMEKIT_TO_HASS.get(mode) for mode in valid_values
                ]

The 2nd is closer to whats in 0.87, but i've had to tweak it a bit for 0.86.

Looks to be working.  Changed line 66 per the first option above. Temp display now shows up in History.
I need to poke around to find the Porch sensor, etc. but am still at bottom of the learning curve.  Thanks a lot for working on this.
Wes

Ah I think you will have to wait for motion sensors to show up. That was added in 0.87 too.

Hi: Not sure if this belongs in a new thread or here. I updated today to latest current hassbian and to HA 0.87.0.
Got 5 errors reported at top of log, each like this:
Error while setting up platform homekit_controller
5:19 PM components/homekit_controller/init.py (ERROR)
Here is the part of the kog related to homekit_controller;
...
 2019-02-07 17:19:31 INFO (MainThread) [homeassistant.loader] Loaded homekit_controller from homeassistant.components.homekit_controller 2019-02-07 17:19:31 INFO (MainThread) [homeassistant.setup] Setting up homekit_controller 2019-02-07 17:19:32 INFO (MainThread) [homeassistant.setup] Setup of domain homekit_controller took 1.1 seconds. 2019-02-07 17:19:32 DEBUG (Thread-21) [homeassistant.components.homekit_controller] Discovered unique device C3:0F:19:BF:2C:39 2019-02-07 17:19:32 INFO (Thread-21) [homeassistant.components.homekit_controller] Setting up Homekit device ecobee3 2019-02-07 17:19:32 INFO (Thread-21) [homeassistant.loader] Loaded configurator from homeassistant.components.configurator 2019-02-07 17:19:35 INFO (MainThread) [homeassistant.loader] Loaded hassio from homeassistant.components.hassio 2019-02-07 17:19:35 INFO (MainThread) [homeassistant.components.http.view] Serving /api/error/all to <IP_ADDRESS> (auth: True) 2019-02-07 17:19:37 DEBUG (Thread-21) [homeassistant.components.homekit_controller] Found accessory-information 2019-02-07 17:19:37 DEBUG (Thread-21) [homeassistant.components.homekit_controller] Found Unknown Service: A2 2019-02-07 17:19:37 DEBUG (Thread-21) [homeassistant.components.homekit_controller] Found thermostat 2019-02-07 17:19:37 DEBUG (Thread-21) [homeassistant.components.homekit_controller] Found motion 2019-02-07 17:19:37 DEBUG (Thread-21) [homeassistant.components.homekit_controller] Found occupancy 2019-02-07 17:19:37 INFO (MainThread) [homeassistant.loader] Loaded climate from homeassistant.components.climate 2019-02-07 17:19:37 DEBUG (Thread-21) [homeassistant.components.homekit_controller] Found accessory-information 2019-02-07 17:19:37 INFO (MainThread) [homeassistant.setup] Setting up climate 2019-02-07 17:19:37 DEBUG (Thread-21) [homeassistant.components.homekit_controller] Found temperature 2019-02-07 17:19:37 DEBUG (Thread-21) [homeassistant.components.homekit_controller] Found motion 2019-02-07 17:19:37 INFO (MainThread) [homeassistant.setup] Setup of domain climate took 0.0 seconds. 2019-02-07 17:19:37 DEBUG (Thread-21) [homeassistant.components.homekit_controller] Found accessory-information 2019-02-07 17:19:37 DEBUG (Thread-21) [homeassistant.components.homekit_controller] Found temperature 2019-02-07 17:19:37 DEBUG (Thread-21) [homeassistant.components.homekit_controller] Found motion 2019-02-07 17:19:37 DEBUG (Thread-21) [homeassistant.components.homekit_controller] Found accessory-information 2019-02-07 17:19:37 DEBUG (Thread-21) [homeassistant.components.homekit_controller] Found temperature 2019-02-07 17:19:37 DEBUG (Thread-21) [homeassistant.components.homekit_controller] Found motion 2019-02-07 17:19:37 INFO (MainThread) [homeassistant.loader] Loaded homekit_controller.climate from homeassistant.components.homekit_controller.climate 2019-02-07 17:19:37 INFO (MainThread) [homeassistant.loader] Loaded homekit_controller.binary_sensor from homeassistant.components.homekit_controller.binary_sensor 2019-02-07 17:19:37 INFO (MainThread) [homeassistant.components.climate] Setting up climate.homekit_controller 2019-02-07 17:19:37 INFO (MainThread) [homeassistant.components.binary_sensor] Setting up binary_sensor.homekit_controller 2019-02-07 17:19:37 INFO (MainThread) [homeassistant.components.binary_sensor] Setting up binary_sensor.homekit_controller 2019-02-07 17:19:37 INFO (MainThread) [homeassistant.components.binary_sensor] Setting up binary_sensor.homekit_controller 2019-02-07 17:19:37 INFO (MainThread) [homeassistant.components.binary_sensor] Setting up binary_sensor.homekit_controller 2019-02-07 17:19:37 ERROR (MainThread) [homeassistant.components.climate] Error while setting up platform homekit_controller Traceback (most recent call last):   File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/helpers/entity_platform.py", line 128, in _async_setup_platform     SLOW_SETUP_MAX_WAIT, loop=hass.loop)   File "/usr/lib/python3.5/asyncio/tasks.py", line 400, in wait_for     return fut.result()   File "/usr/lib/python3.5/asyncio/futures.py", line 293, in result     raise self._exception   File "/usr/lib/python3.5/concurrent/futures/thread.py", line 55, in run     result = self.fn(*self.args, **self.kwargs)   File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/homekit_controller/climate.py", line 37, in setup_platform     add_entities([HomeKitClimateDevice(accessory, discovery_info)], True)   File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/homekit_controller/climate.py", line 45, in __init__     super().__init__(*args)   File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/homekit_controller/__init__.py", line 202, in __init__     self.setup()   File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/homekit_controller/__init__.py", line 227, in setup     uuid = CharacteristicsTypes.get_uuid(char['type'])   File "/srv/homeassistant/lib/python3.5/site-packages/homekit/model/characteristics/characteristic_types.py", line 324, in get_uuid     raise KeyError('No UUID found for Item {item}'.format(item=orig_item)) KeyError: 'No UUID found for Item B7DDB9A3-54BB-4572-91D2-F1F5B0510F8C' 2019-02-07 17:19:37 ERROR (MainThread) [homeassistant.components.binary_sensor] Error while setting up platform homekit_controller Traceback (most recent call last):   File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/helpers/entity_platform.py", line 128, in _async_setup_platform     SLOW_SETUP_MAX_WAIT, loop=hass.loop)   File "/usr/lib/python3.5/asyncio/tasks.py", line 400, in wait_for     return fut.result()   File "/usr/lib/python3.5/asyncio/futures.py", line 293, in result     raise self._exception   File "/usr/lib/python3.5/concurrent/futures/thread.py", line 55, in run     result = self.fn(*self.args, **self.kwargs)   File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/homekit_controller/binary_sensor.py", line 22, in setup_platform     add_entities([HomeKitMotionSensor(accessory, discovery_info)], True)   File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/homekit_controller/binary_sensor.py", line 30, in __init__     super().__init__(*args)   File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/homekit_controller/__init__.py", line 202, in __init__     self.setup()   File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/homekit_controller/__init__.py", line 227, in setup     uuid = CharacteristicsTypes.get_uuid(char['type'])   File "/srv/homeassistant/lib/python3.5/site-packages/homekit/model/characteristics/characteristic_types.py", line 324, in get_uuid     raise KeyError('No UUID found for Item {item}'.format(item=orig_item)) KeyError: 'No UUID found for Item BFE61C70-4A40-11E6-BDF4-0800200C9A66' 2019-02-07 17:19:37 ERROR (MainThread) [homeassistant.components.binary_sensor] Error while setting up platform homekit_controller Traceback (most recent call last):   File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/helpers/entity_platform.py", line 128, in _async_setup_platform     SLOW_SETUP_MAX_WAIT, loop=hass.loop)   File "/usr/lib/python3.5/asyncio/tasks.py", line 400, in wait_for     return fut.result()   File "/usr/lib/python3.5/asyncio/futures.py", line 293, in result     raise self._exception   File "/usr/lib/python3.5/concurrent/futures/thread.py", line 55, in run     result = self.fn(*self.args, **self.kwargs)   File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/homekit_controller/binary_sensor.py", line 22, in setup_platform     add_entities([HomeKitMotionSensor(accessory, discovery_info)], True)   File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/homekit_controller/binary_sensor.py", line 30, in __init__     super().__init__(*args)   File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/homekit_controller/__init__.py", line 202, in __init__     self.setup()   File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/homekit_controller/__init__.py", line 227, in setup     uuid = CharacteristicsTypes.get_uuid(char['type'])   File "/srv/homeassistant/lib/python3.5/site-packages/homekit/model/characteristics/characteristic_types.py", line 324, in get_uuid     raise KeyError('No UUID found for Item {item}'.format(item=orig_item)) KeyError: 'No UUID found for Item BFE61C70-4A40-11E6-BDF4-0800200C9A66' 2019-02-07 17:19:37 ERROR (MainThread) [homeassistant.components.binary_sensor] Error while setting up platform homekit_controller Traceback (most recent call last):   File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/helpers/entity_platform.py", line 128, in _async_setup_platform     SLOW_SETUP_MAX_WAIT, loop=hass.loop)   File "/usr/lib/python3.5/asyncio/tasks.py", line 400, in wait_for     return fut.result()   File "/usr/lib/python3.5/asyncio/futures.py", line 293, in result     raise self._exception   File "/usr/lib/python3.5/concurrent/futures/thread.py", line 55, in run     result = self.fn(*self.args, **self.kwargs)   File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/homekit_controller/binary_sensor.py", line 22, in setup_platform     add_entities([HomeKitMotionSensor(accessory, discovery_info)], True)   File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/homekit_controller/binary_sensor.py", line 30, in __init__     super().__init__(*args)   File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/homekit_controller/__init__.py", line 202, in __init__     self.setup()   File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/homekit_controller/__init__.py", line 227, in setup     uuid = CharacteristicsTypes.get_uuid(char['type'])   File "/srv/homeassistant/lib/python3.5/site-packages/homekit/model/characteristics/characteristic_types.py", line 324, in get_uuid     raise KeyError('No UUID found for Item {item}'.format(item=orig_item)) KeyError: 'No UUID found for Item BFE61C70-4A40-11E6-BDF4-0800200C9A66' 2019-02-07 17:19:37 ERROR (MainThread) [homeassistant.components.binary_sensor] Error while setting up platform homekit_controller Traceback (most recent call last):   File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/helpers/entity_platform.py", line 128, in _async_setup_platform     SLOW_SETUP_MAX_WAIT, loop=hass.loop)   File "/usr/lib/python3.5/asyncio/tasks.py", line 400, in wait_for     return fut.result()   File "/usr/lib/python3.5/asyncio/futures.py", line 293, in result     raise self._exception   File "/usr/lib/python3.5/concurrent/futures/thread.py", line 55, in run     result = self.fn(*self.args, **self.kwargs)   File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/homekit_controller/binary_sensor.py", line 22, in setup_platform     add_entities([HomeKitMotionSensor(accessory, discovery_info)], True)   File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/homekit_controller/binary_sensor.py", line 30, in __init__     super().__init__(*args)   File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/homekit_controller/__init__.py", line 202, in __init__     self.setup()   File "/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/homekit_controller/__init__.py", line 227, in setup     uuid = CharacteristicsTypes.get_uuid(char['type'])   File "/srv/homeassistant/lib/python3.5/site-packages/homekit/model/characteristics/characteristic_types.py", line 324, in get_uuid     raise KeyError('No UUID found for Item {item}'.format(item=orig_item)) KeyError: 'No UUID found for Item BFE61C70-4A40-11E6-BDF4-0800200C9A66' 2019-02-07 17:19:47 INFO (MainThread) [homeassistant.components.http.view] Serving /api/error_log to <IP_ADDRESS> (auth: True) 2019-02-07 17:20:55 INFO (MainThread) [homeassistant.components.http.view] Serving /api/config/config_entries/entry to <IP_ADDRESS> (auth: True) 2019-02-07 17:20:55 INFO (MainThread) [homeassistant.components.http.view] Serving /api/config/config_entries/flow to <IP_ADDRESS> (auth: True) 2019-02-07 17:20:55 INFO (MainThread) [homeassistant.components.http.view] Serving /api/config/config_entries/flow_handlers to <IP_ADDRESS> (auth: True) 2019-02-07 17:22:09 INFO (MainThread) [homeassistant.components.http.view] Serving /api/config/customize/config/binary_sensor.door_sensor_34_31_6f to <IP_ADDRESS> (auth: True) 2019-02-07 17:23:17 INFO (MainThread) [homeassistant.components.http.view] Serving /api/error/all to <IP_ADDRESS> (auth: True) 2019-02-07 17:24:10 INFO (MainThread) [homeassistant.components.http.view] Serving /api/error_log to <IP_ADDRESS> (auth: True) 2019-02-07 17:24:15 INFO (MainThread) [homeassistant.components.http.view] Serving /api/error_log to <IP_ADDRESS> (auth: True)

Thanks for the update - there is a fix waiting to be merged for this - I’ll send you a link when I’m at my desk if you want to try it.

https://github.com/home-assistant/home-assistant/pull/20824/files

Just tried 0.87.1 which seems to have this pull request included. Unfortunately my ecobees still don't seem to pair.

I'm having the same issue, just tried 0.87.1 with the same result. Possibly interesting, possibly not, but I tried a suggestion from earlier in this thread and submitted a fake pairing code in the HA UI to see what would happen, and got this in the logs:
homeassistant_1  | 2019-02-11 00:26:04 ERROR (MainThread) [homeassistant.components.websocket_api.http.connection.1801008400] Error handling message: {'type': 'call_service', 'domain': 'configurator', 'service': 'configure', 'service_data': {'configure_id': '1801008944-1', 'fields': {'code': '123123123'}}, 'id': 44}
homeassistant_1  | Traceback (most recent call last):
homeassistant_1  |   File "/usr/local/lib/python3.6/site-packages/homeassistant/components/websocket_api/decorators.py", line 17, in _handle_async_response
homeassistant_1  |     await func(hass, connection, msg)
homeassistant_1  |   File "/usr/local/lib/python3.6/site-packages/homeassistant/components/websocket_api/commands.py", line 148, in handle_call_service
homeassistant_1  |     connection.context(msg))
homeassistant_1  |   File "/usr/local/lib/python3.6/site-packages/homeassistant/core.py", line 1130, in async_call
homeassistant_1  |     self._execute_service(handler, service_call))
homeassistant_1  |   File "/usr/local/lib/python3.6/site-packages/homeassistant/core.py", line 1152, in _execute_service
homeassistant_1  |     await handler.func(service_call)
homeassistant_1  |   File "/usr/local/lib/python3.6/site-packages/homeassistant/components/configurator.py", line 221, in async_handle_service_call
homeassistant_1  |     call.data.get(ATTR_FIELDS, {}))
homeassistant_1  |   File "/usr/local/lib/python3.6/concurrent/futures/thread.py", line 56, in run
homeassistant_1  |     result = self.fn(*self.args, **self.kwargs)
homeassistant_1  |   File "/usr/local/lib/python3.6/site-packages/homeassistant/components/homekit_controller/__init__.py", line 141, in device_config_callback
homeassistant_1  |     self.controller.perform_pairing(self.hkid, self.hkid, code)
homeassistant_1  |   File "/usr/local/lib/python3.6/site-packages/homekit/controller.py", line 192, in perform_pairing
homeassistant_1  |     pairing = perform_pair_setup(conn, pin, str(uuid.uuid4()))
homeassistant_1  |   File "/usr/local/lib/python3.6/site-packages/homekit/protocol/__init__.py", line 98, in perform_pair_setup
homeassistant_1  |     error_handler(response_tlv[1][1], 'step 3')
homeassistant_1  |   File "/usr/local/lib/python3.6/site-packages/homekit/protocol/__init__.py", line 48, in error_handler

Hey guys sorry to get your hopes up with the chatter on this ticket but we are still a way off having ecobee working.
Wes ran a fork of the homekit library with a hack in place to manually generate the pairing file, and copied an edited version into HA. The PR that was merged is for a problem after that.
To fix the pairing problem with pairing I need to get a change into the homekit library then quite a large change into HA. I’m working on that but it’s quite a bit of refactoring as I’m switching to “config entries” to give me the flexibility we need to support proper pairing.

Hi:
(Delayed to organize wife's 70th birthday party,)
I updated .... /homekit_controller/init.py  per the git link you emailed me.
Now loads 0.87.0 with no errors logged.
The temperature at each of my 3 remote sensors is not shown.
The occupancy/motion at the main thermostat and the 3 remote sensors is shown and correct.
The climate card is not displayed on the Overview page (although it was one step previous).
Let me know what else I can do.
Wes

Ecobee3 temperature card now displayed on overview page. The motion/occupancy sensors also show up. Perhaps they are not displayed until a status change. Display appeared after heat came on. I think ecobee sensors and temp card should display on startup.
Wes

Updated to HA 0.87.1.
No change from above.
Wes

Hey @wes-warner - thanks a lot for the update.
This is all very good news to hear. I think most of the gaps are expected. Still working on the UI changes for pairing. The basics works but there are a lot of edge cases I need to sort out before I can submit them.
I'm not expecting temperature at each of 3 remotes to work yet. 2 problems remain there:

There is no mapping from a homekit temperature sensor to a HA one. That should be fairly easy to add but that leads us to problem 2:
Right now there is a limitation in the integration about how many homeassistant entities can be linked to a single homekit accessory. It only shows the first it finds, so adding temperature might mean you lose occupancy! I need to explore why this limit exists and then figure out how to remove it. I'm a bit worried fixing it might change entity id's on people and break automations :-S.

I'm not sure why the card wasn't displayed. It should have been, theres no logic thats tied to the thermostat switching between states. How long did it take to appear? With some of the devices I have it used to take up to 5 minutes for everything to appear. I'm working on reducing that so I might say lets wait until my next set of changes land to investigate it further?
Previously you sent me the output:
python -m homekit.get_accessories -f pairing.json -a "ecobee"

It would be very helpful if you could send it in json format, then i can add it into my automated tests:
python -m homekit.get_accessories -f pairing.json -a "ecobee" -o json

Here is a link to the json output
https://www.dropbox.com/sh/6a04vk15t3slmt3/AAAz_-Huffxc3XJnt4sQAexWa?dl=0

note the name ecobee is changed to ecobee3 in the python command above.
Wes

After 21 days my Ecobee3 and its 3 extra sensors still working in HA at release 0.88.2.  I have not reset the Ecobee3 and attempted to pair again.  The temperature at the 3 sensors is not being read yet (as expected) but occupancy is reported.  I am keen to do more testing if it would help.  Wes

Hi @wes-warner - thanks for the ping.
I've started trying to upstream the work to move to config entires - a precursor for the pairing fix. The first PR is currently waiting in the review queue, its been a few days already so hopefully it will get looked at soon..
I'm planning to do some more integration testing of the full change. If you are comfortable with the idea of running a branch of HA rather than a fresh install then your testing there would be very valuable. But it's fine if you want to avoid messing up your install!
In the mean time another dev has added temperature sensors so that might start working in 0.89 (not sure if it was merged in time or whether it will be 0.90).

Neither my HA setup, or I, will be 'production ready' for some months. So I am happy to test on request. Wes
On Monday, March 4, 2019, 12:58:01 p.m. EST, Jc2k<EMAIL_ADDRESS>wrote:
Hi @wes-warner - thanks for the ping.
I've started trying to upstream the work to move to config entires - a precursor for the pairing fix. The first PR is currently waiting in the review queue, its been a few days already so hopefully it will get looked at soon..
I'm planning to do some more integration testing of the full change. If you are comfortable with the idea of running a branch of HA rather than a fresh install then your testing there would be very valuable. But it's fine if you want to avoid messing up your install!
In the mean time another dev has added temperature sensors so that might start working in 0.89 (not sure if it was merged in time or whether it will be 0.90).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

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

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<EMAIL_ADDRESS>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.

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.

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 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.

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

Np @robbiet480 😆

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.

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.

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.

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<EMAIL_ADDRESS>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.

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

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.

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.

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).

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).

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

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.

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.

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?

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<EMAIL_ADDRESS>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.

@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.

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<EMAIL_ADDRESS>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.

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.

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?

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.

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

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://<IP_ADDRESS>: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.

@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.

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.

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

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?

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.

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.

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.

@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.

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.

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<EMAIL_ADDRESS>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.

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...

@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?

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.

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

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.

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?

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.

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.

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.

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

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?

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.

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!

@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.

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.

@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 no detected at all. I am also unable to discover the device. Any suggestion?

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)?

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:

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

@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).

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.

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

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]

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`?

The entities are showing and I do get status (motion and temp). The timeout stated 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.

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..

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": "<IP_ADDRESS>",
                    "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
            }

@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?

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?

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

Excellent news!

@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

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

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

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

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 disscord, i think you can send private messages there.
Or you can send it to me via Keybase.

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

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.

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.

@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?

@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.

@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).

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.

@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://<IP_ADDRESS>: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://<IP_ADDRESS>: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://<IP_ADDRESS>: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://<IP_ADDRESS>: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://<IP_ADDRESS>: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://<IP_ADDRESS>: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://<IP_ADDRESS>: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://<IP_ADDRESS>: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://<IP_ADDRESS>: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)

@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.

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

@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?

@Jc2k No worries. Yes I am.

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.

@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.   (The 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.

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

Enter WAC mode on the S30. This triggered discovery on my HA instance resulting in a notification and listing on the HA Integrations page.
Select the S30 from the Wi-Fi networks screen on the iPhone/iPad.
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.
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.

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.

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.

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.

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.