1st gen Eve Room, Bluetooth and 2022.8

Hello everyone,

I’m happy to finally get Bluetooth integrated into home assistant… this may help me to completely get rid of HomeKit/appletv.

I currently have two Bluetooth devices… one Schlage sense lock and one 1st gen eve room.

I’ll try to add my lock latter this week.

Tonight, I’m trying to add the eve room… but it’s not working.
It’s detected by home assistant. But when I try to add it, I get this error (sorry it’s in French)… it’s says something like unknown error when pairing. Temporary error or device not supported. I tried to reset the device again… same error.

I’m running home assistant on a mini intel pc.
Is the eve room supposed to be supported?
If yes, how can I make it work?

Please turn on debug logs for aiohomekit and try again

I have exactly the same issue with EVE Room 1st Gen. HA OS, Raspberry PI4, onboard Bluetooth.

1 Like

here is the last part of the log… it looks like the device is no sending the key. it may need a specific integration like the august lock.

2022-08-04 06:47:59.358 ERROR (MainThread) [homeassistant.components.homekit_controller.config_flow] Pairing attempt failed with an unhandled exception

Traceback (most recent call last):

File "/usr/src/homeassistant/homeassistant/components/homekit_controller/config_flow.py", line 446, in async_step_pair

pairing = await self.finish_pairing(code)

File "/usr/local/lib/python3.10/site-packages/aiohomekit/controller/ble/discovery.py", line 132, in finish_pairing

pairing = await drive_pairing_state_machine(

File "/usr/local/lib/python3.10/site-packages/aiohomekit/controller/ble/client.py", line 213, in drive_pairing_state_machine

request, expected = state_machine.send(TLV.decode_bytes(response))

File "/usr/local/lib/python3.10/site-packages/aiohomekit/protocol/__init__.py", line 225, in perform_pair_setup_part2

raise InvalidError("M5: not an error or a proof")

aiohomekit.exceptions.InvalidError: M5: not an error or a proof

2022-08-04 06:47:59.463 DEBUG (MainThread) [aiohomekit.controller.ble.discovery] Ensure connected with device F2:4A:E1:1B:1C:07: Eve

2022-08-04 06:47:59.536 DEBUG (MainThread) [aiohomekit.controller.ble.client] Using fragment size: 147

2022-08-04 06:47:59.537 DEBUG (MainThread) [aiohomekit.controller.ble.client] Queuing fragment for write: b'\x00\x03Pu\x00'

2022-08-04 06:47:59.806 DEBUG (MainThread) [aiohomekit.controller.ble.client] Read fragment: bytearray(b'\x02P\x00\x03\x00\x01\x01\x01')

2022-08-04 06:47:59.806 DEBUG (MainThread) [aiohomekit.pdu] Got PDU 2: TID 50 (Expected: 50), Status:0, Len:3

2022-08-04 06:47:59.806 DEBUG (MainThread) [aiohomekit.protocol.tlv] receiving [

1: (1 bytes/<class 'bytearray'>) 0x01


2022-08-04 06:47:59.896 DEBUG (MainThread) [aiohomekit.protocol.tlv] sending [

6: (1 bytes/<class 'bytearray'>) 0x01

0: (1 bytes/<class 'bytearray'>) 0x01


2022-08-04 06:47:59.897 DEBUG (MainThread) [aiohomekit.controller.ble.client] Using fragment size: 147

2022-08-04 06:47:59.897 DEBUG (MainThread) [aiohomekit.controller.ble.client] Queuing fragment for write: b'\x00\x02\xb6v\x00\x0b\x00\t\x01\x01\x01\x06\x06\x01\x01\x00\x01\x01'

2022-08-04 06:48:00.166 DEBUG (MainThread) [aiohomekit.controller.ble.client] Read fragment: bytearray(b'\x02\xb6\x00\x05\x00\x01\x03\x07\x01\x01')

2022-08-04 06:48:00.166 DEBUG (MainThread) [aiohomekit.pdu] Got PDU 2: TID b6 (Expected: b6), Status:0, Len:5

2022-08-04 06:48:00.167 DEBUG (MainThread) [aiohomekit.protocol.tlv] receiving [

1: (3 bytes/<class 'bytearray'>) 0x070101


2022-08-04 06:48:00.167 DEBUG (MainThread) [aiohomekit.protocol.tlv] receiving [

7: (1 bytes/<class 'bytearray'>) 0x01


2022-08-04 06:48:00.167 ERROR (MainThread) [homeassistant.components.homekit_controller.config_flow] Pairing attempt failed with an unhandled exception

Traceback (most recent call last):

File "/usr/src/homeassistant/homeassistant/components/homekit_controller/config_flow.py", line 484, in async_step_pair

self.finish_pairing = await discovery.async_start_pairing(self.hkid)

File "/usr/local/lib/python3.10/site-packages/aiohomekit/controller/ble/client.py", line 63, in _async_wrap

return await func(*args, **kwargs)

File "/usr/local/lib/python3.10/site-packages/aiohomekit/controller/ble/discovery.py", line 121, in async_start_pairing

salt, pub_key = await drive_pairing_state_machine(

File "/usr/local/lib/python3.10/site-packages/aiohomekit/controller/ble/client.py", line 213, in drive_pairing_state_machine

request, expected = state_machine.send(TLV.decode_bytes(response))

File "/usr/local/lib/python3.10/site-packages/aiohomekit/protocol/__init__.py", line 132, in perform_pair_setup_part1

raise InvalidError("M2: Accessory did not send public key")

aiohomekit.exceptions.InvalidError: M2: Accessory did not send public key

is it the update of bluetooth as my iPhone was detected before if I was in the house, since the update I’m away however not moved since this morning?

The eve room showed up today. Unfortunately it paired right out of the box without any issues, but its not an older version.

I think we are going to need debug logs for

aiohomekit and bleak to see if we can figure out what is different.

Not problem for debug log of these two components.
anything specific I should look for or you want a complete copy of the core log as soon as pairing failed?

Just the log from the time you start pairing to when it fails is probably enough.


Here is my attempt to pair an Eve Room 1. I’ve tried to filter only the eve device as bleak is quite verbose.
I had to use pastebin as the log is too big for posting. I hope the paste will be available quickly from moderation.

Thank you!


here’s my log… there’s probably a lot more than what you are looking for…

Re-upload using controlc


Only tangentially related, but I noticed the pairing attempt is slow in the logs. These PRs should improve that but it won’t fix the issue here.

It looks like these devices have the older hardware coprocessor authentication which uses a different pairing method. In theory there is code in aiohomekit to support this, but it seems that the device isn’t sending the public key so it fails. It doesn’t look like its something that is a quick fix.

I found a used gen1 on ebay so I’ll see if there is anything we can do once I have it in hand at the end of the week

1 Like

Thank you for your work on this issue with gen1 eve room!
When/if you find the solution, I guess this may help with other older device too.

I have most of the older eve devices: eve room, eve thermo, eve energy, eve door, eve weather all first gen and few others newer gen. I can do tests when required. Btw eve energy gives the same error when pairing.

It could be repeated to https://github.com/Jc2k/aiohomekit/issues/136

I spent way to many hours looking for a bug in the srp code before I realized the mtu was wrong. Sadly they turned out to be asymmetric.

If someone with the device can enable debug logs for bleak and do a host reboot so we can the logs at startup time and then try to pair the eve device. we should be able to see what the actual mtu value is in the logs.

I can surely try this when I’m back home in a few hours.
you only need debug in bleak and not aiohomekit?

Yes. bleak only. It wouldn’t hurt to enable debug aiohomekit as well though in case there just happens to be something that comes up that sheds more light on this issue


here’s my home-assistant.log after boot and after trying to pair my eve room
default log set to warn. bleak and aiohomekit set to debug.

2022-08-08 18:33:53.099 DEBUG (MainThread) [bleak.backends.bluezdbus.manager] received D-Bus signal: org.freedesktop.DBus.ObjectManager.InterfacesAdded (/): ['/org/bluez/hci0/dev_C2_EB_3B_22_6B_82/service3000/char3040', {'org.freedesktop.DBus.Introspectable': {}, 'org.bluez.GattCharacteristic1': {'UUID': <dbus_next.signature.Variant ('s', 0000004e-0000-1000-8000-0026bb765291)>, 'Service': <dbus_next.signature.Variant ('o', /org/bluez/hci0/dev_C2_EB_3B_22_6B_82/service3000)>, 'Value': <dbus_next.signature.Variant ('ay', b'')>, 'Flags': <dbus_next.signature.Variant ('as', ['read', 'write'])>, 'MTU': <dbus_next.signature.Variant ('q', 158)>}, 'org.freedesktop.DBus.Properties': {}}]

Well its not the MTU, but at least we can cross that problem off the list.

We just added some more logging into aiohomekit that might help tell us whats going on in 2022.8.3