Can't pair Eve Thermo w/ Thread via Homekit Controller

2

Hey Carsten, Just reporting I’m seeing the same problem except with an Eve Energy device. I’m trying to also connect over Thread.

I’m on CentOS with Docker implementation, tried with MacVLAN as well as network_mode: host without luck.

I posted my stuff on reddit

I’ve validated ipv6, but I was curious if it needs Bluetooth… as my implementation doesn’t have that and I know that is the only other method these talk about… but seems to be wanting to use ipv6. Maybe its not directing back to the container properly? Still working to get ipv6 dhcp server setup on the VLAN to rule this out and ensure all devices have the same gateway.

3

So ironically I bought an Eve Motion/Light sensor like 2 weeks ago that showed up today. I figure I would give it a shot as its not my same sensors. Connected to home app, paired, waited a minute, then removed it from the Home app, it popped up in Home Assistant, clicked configure and it loaded instantly without any errors. Added the homekit code (without the - like it has in the example), it then connected in and asked me the room and works just fine.

Problem 1) I was using macvlan, I had to adjust that and simply use a very basic config with the host, (note I think host wont work on version 3 of docker-compose, I rolled this back to 2.1). My docker-compose.yml file looks like this now:

  homeassistant:
    container_name: hass
    image: homeassistant/home-assistant
    volumes:
      - ${ROOT}/homeassistant/config/:/config
    environment:
      - PUID=${PUID}
      - PGID=${PGID}
      - TZ=${TZ}
    restart: always
    privileged: true
    network_mode: host

Problem 2) Which I think might be yours? Try hard resetting your eve device and starting from scratch. I also restarted HomeAssistant to try and clear any cache of the old device. Then add it back into home app fresh (Be sure to let it sit in home for a minute or so in the home app). Then remove from home and try again. No idea why this worked, but I’ve tried like 400 different options, even clean HomeAssistant servers etc… nothing worked. But this just paired an Eve Power I’ve been fighting with for hours. Note my eve power devices have been connected for over a year now… so maybe there is something different with how they add to the matter network now?
I think you can simply remove it from the home app, then power cycle the device before adding it in home assistant.

Update, I’ve got 2 more Eve Energy’s added.

4

hijacking the thread :slight_smile: thanks I’ll try that for my Eve energy plugs. Can you read power consumption from the Eve Energy v4 in Home assistant?

5

@carstenrn Hello, thanks for the logs. There are a few things we can check.

Recent HA releases support HAP over both BLE and Thread so first let’s make sure we’re looking at Thread discoveries. Use any mDNS service browser to look for _hap._udp devices.

  • MacOS: dns-sd -Z _hap._udp
  • Linux: avahi-browse -r _hap._udp
  • Android: (any mDNS service browser app that looks trustworthy)

Next, does your HA have good IPv6 networking. The easiest way to verify this is to ping the accessory from your HA:
ping6 Nanoleaf-A19-12FA.local
(put in a hostname discovered from the above mDNS commands)

Some devices have a short timeout (a few minutes) to pair before they shut HAP down. Try rebooting or otherwise waking the device being careful NOT to factory reset it.

Let’s start there & we can collect more debug info if needed. Let me know how it goes!

6

Hi. I’ve been trying almost everything to make my Eve Door Contact Sensor work in Home Assistant and I couldn’t add it. Once the sensor has been removed from the HomeKit app, it is discoverable by HA with the following details:

= hassio IPv4 Eve Door A214 _hap._udp local
hostname = [Eve-Door-A214.local]
address = [fd77:12ce:3c5d:0:a59c:4392:476c:549e]
port = [5683]
txt = [“sh=4KD3Lg==” “ci=10” “sf=1” “s#=4” “pv=1.2” “md=Eve Door 20EBN9901” “id=20:27:B9:10:0D:66” “ff=2” “c#=2”]

The host machine ( Debian physical box ) has the IPv6 enabled and assigning fe80::/64 addresses, locally. When trying to ping the Eve’s IPv6, it returns “host unreachable”.

Steps I tried so far

Modified the sysctl.conf on the Debian box as:

net.ipv4.ip_forward=1
net.ipv6.conf.all.forwarding=1

Even amended the hosts file to include the fd77 prefix:

The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
fd77::1 ip6-allnodes
fd77::2 ip6-allrouters

Checking the ipv6 route table returns only fe80 addresses:
ip -6 route show
::1 dev lo proto kernel metric 256 pref medium
fe80::/64 dev eno1 proto kernel metric 100 pref medium
fe80::/64 dev veth965ed33 proto kernel metric 256 pref medium
fe80::/64 dev hassio proto kernel metric 256 pref medium
fe80::/64 dev vethbc7aace proto kernel metric 256 pref medium
fe80::/64 dev docker0 proto kernel metric 256 pref medium
fe80::/64 dev vetha742930 proto kernel metric 256 pref medium
fe80::/64 dev veth0378562 proto kernel metric 256 pref medium
fe80::/64 dev vethfa884bc proto kernel metric 256 pref medium
fe80::/64 dev vethb401627 proto kernel metric 256 pref medium
fe80::/64 dev veth350bcaa proto kernel metric 256 pref medium

Docker current config - No IP range exposed on the homeassistant container. Is this normal ?
[…] Up 55 minutes homeassistant
[…] Up 56 minutes 0.0.0.0:4357->80/tcp, :::4357->80/tcp hassio_observer

I’ve concluded that since I am not able to ping the Sensor’s IPv6 from the Debian box itself, this could be the reason why I’m unable to add it the Sensor to HA.

HA logs

2022-11-15 15:21:57.042 WARNING (MainThread) [aiohomekit.controller.coap.connection] Pair setup 1/2 failed!

2022-11-15 15:21:57.070 ERROR (MainThread) [homeassistant.components.homekit_controller.config_flow] Pairing attempt failed with an unhandled exception

Traceback (most recent call last):

File “/usr/local/lib/python3.10/asyncio/tasks.py”, line 456, in wait_for

return fut.result()

asyncio.exceptions.CancelledError

The above exception was the direct cause of the following exception:

Traceback (most recent call last):

File “/usr/src/homeassistant/homeassistant/components/homekit_controller/config_flow.py”, line 479, in async_step_pair

self.finish_pairing = await discovery.async_start_pairing(self.hkid)
File “/usr/local/lib/python3.10/site-packages/aiohomekit/controller/coap/discovery.py”, line 57, in async_start_pairing
salt, srpB = await self.connection.do_pair_setup(
File “/usr/local/lib/python3.10/site-packages/aiohomekit/controller/coap/connection.py”, line 283, in do_pair_setup
response = await asyncio.wait_for(
File “/usr/local/lib/python3.10/asyncio/tasks.py”, line 458, in wait_for
raise exceptions.TimeoutError() from exc
asyncio.exceptions.TimeoutError

I would highly appreciate if you could point me to the right direction on how to sort this issue.

7

@Quira the Thread Border Router (which one do you have?) should be advertising the IPv6 info & your box should be configuring itself based on that. Have you tried setting this sysctl yet? Some people have needed it:

net.ipv6.conf.all.accept_ra_rt_info_max_plen=64

Check this post for a bit more info + a tcpdump you can try: HomeKit Accessory Protocol (HAP) over CoAP/UDP (was: Nanoleaf Essentials bulb via Thread/CoAP) - #257 by Jc2k

Let me know if you see the Router Advertisement. It may take a few minutes to show up.

8

Hi. Thank you very much for your response. I am using a miniHomePod at the ground floor ( kitchen ) + 2 HomePods in the LivingRoom. At the 1st floor I am using 2 x mini-HomePods, in each room. As well, I have 1 x nanoleaf A19 bulb and 3 x Nanoleaf Essential Light Strips that are installed at the 1st floor.

I’m running Home Assistant ( Supervised ) dedicated on a Lenovo SFF PC that is running Debian 11 which has IPv6 enabled on the NIC. I am not sure what do you mean by my box being configured itself based on the IP advertised by the Thread Border Router. The Debian box gets the IPv6 through DHCP from the Router. Perhaps I am missing something, but here’s my setup: The Debian box is cable connected to my Velop router which also has the connection for the ISP.

I’ll try your recommendation and follow up.
Much appreciated!

9

Thread doesn’t use the IPv6 from your DHCP, (just in case its relevant for anyone else - by default it doesn’t work between VLAN’s either).

Your thread border routers send out ICMP6 messages called “Router Advertisements” and these contain “additional route info”. If that ICMP6 message isn’t received or isn’t processed by your HA box, then it won’t have a route to your thread accessory, and nothing will work.

By default some environments ignore the “additional route info” - thats what the provided sysctl controls. In addition, because you are using DHCP6 you should check that the interface is configured to accept RA’s in general.

1 Like
10

Following up on the issue raised: Thank you for your response. Upon further troubleshooting and investigation I found the root cause of the issue. To resolve I had to amend the daemon.json file to enable the ipv6 on Docker, followed by reloading Docker service:

For the test I used one of the HomePod mini speakers

IPv6: fdcd:a065:56c1:4ce2:0:fd53:d858:49e2
MAC: F4:34:F0:57:2E:47

Enabled ipv6 on docker ( amended /etc/docker/daemon.json ):
(which now looks like this):

{
    "log-driver": "journald",
    "storage-driver": "overlay2",
    "ip6tables": true,
    "ipv6": true,
    "experimental": true,
    "log-opts": {
        "tag": "{{.Name}}"
    }
}

Checked tcpdump targeting the prefix fdcd:a065…

sudo tcpdump -n -vvv -e -i eno1 icmp6 | grep fdcd:a065:56c1:4ce2
tcpdump: listening on eno1, link-type EN10MB (Ethernet), snapshot length 262144 bytes

prefix info option (3), length 32 (4): fdcd:a065:56c1:4ce2::/64, Flags [onlink, auto], valid time 1800s, pref. time 1800s

11:21:48.474455 f4:34:f0:57:2e:47 > 33:33:ff:58:49:e2, ethertype IPv6 (0x86dd), length 86: (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::cc:9573:cbb1:9837 > ff02::1:ff58:49e2: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has fdcd:a065:56c1:4ce2:0:fd53:d858:49e2

Then on the Debian box then I checked the IPv6 route returning the IPv6 prefixes in use by the Eve and Nanoleaf devices:

ip -6 route command output:

::1 dev lo proto kernel metric 256 pref medium

fd1e:cee4:6c70::/64 via fe80::cc:9573:cbb1:9837 dev eno1 proto ra metric 100 pref medium

fd53:d858:49e2::/64 via fe80::14ec:1d83:9f7e:5196 dev eno1 proto ra metric 100 pref medium

fd77:12ce:3c5d::/64 via fe80::1c07:c3ab:1ddc:678a dev eno1 proto ra metric 100 pref medium

fdcd:a065:56c1:4ce2::/64 dev eno1 proto ra metric 100 pref medium

Checked ping status for Eve sensor :
ping6 fd77:12ce:3c5d:0:a59c:4392:476c:549e

returned 0% packet loss:

— fd77:12ce:3c5d:0:a59c:4392:476c:549e ping statistics —
6 packets transmitted, 6 received, 0% packet loss, time 5007ms

Final step was to configure the Eve Sensor in Home Assistant UI and paired successfully using code in format XXX-XX-XXX

image
image724×546 65.8 KB

image
image1821×1078 187 KB

Will try now to add the rest of the Nanoleaf and Eve devices.
Thanks again for your guidance!

1 Like
11

Awesome. Because this is a “sleepy” device you will probably see a lot of warnings in your logs. Sleepy devices sleep for 5s and then wake up to ask the border routers for any messages they missed. Unfortunately the CoAP library we use has a hard timeout at 2s, after which it sends a retry. Sleepy devices wake up and respond to the original transmission and the retransmission, but the CoAP library only expects one reply, and logs an error for the 2nd one.

This seems to be harmless (I see hundreds of them, but everything is still working for me), but is annoying and something that we are looking into solving.

1 Like
12

Fix HomeKit CoAP connection getting RST incorrectly by Jc2k · Pull Request #82553 · home-assistant/core · GitHub should help with “sleepy end devices” (reduces log noise and avoids RST’ing a working connection) however we are still sending dupe packets. We are working with the CoAP library maintainer so that we can avoid this for battery powered thread devices.

1 Like
13

I have a similar issue with my Docker based HA.

I have configured IPV6 on my Pi4 (with the out of the box settings for dhcp - I think). I have these addreses:

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether dc:a6:32:d1:2e:38 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.17/24 brd 192.168.0.255 scope global dynamic noprefixroute eth0
valid_lft 86130sec preferred_lft 75330sec
inet6 fd35:3735:59ee:4732:8349:27ba:9b02:2af6/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 1711sec preferred_lft 1711sec
inet6 fe80::dd0b:cb06:dc1b:f828/64 scope link
valid_lft forever preferred_lft forever

I have enabled IPv6 in Docker

{
“ipv6”: true,
“ip6tables”: true,
“experimental”: true,
“fixed-cidr-v6”: “fd00::/80”
}

But on my Pi I cannot do a ping6 to the address of the Eve Energy device. I can see through the avahi-browse function that it is there.

The Eve Energy device pops up in HA, but throws an error

[coap] Error received and ignored in this codepath: [Errno 101] Network unreachable” error.

When I install HA OS on a fresh Raspberry Pi, it has IPv4 and IPv6 configured. When I try to add the Eve Energy device, it works perfect.

I am lost on how to fix this. Is there something wrong with IPv6 on my Pi ? Do I need to be able to ping6 the Eve Energy device ? (I can ping it from my MAc without any issue).

Other Homekit integrations do work. e.g. my Homepod is configured as Apple TV.

14

I am having the exact same issue as the OP (in my case an Eve Room over Thread via an AppleTV border router), but the fix seems kind of complicated. Is this something that can be automatically dealt with in a future update of HA?

1 Like
15

Not in HA, but maybe in HA OS. It is on the radar of the Matter people (as they need it too).

1 Like
16

I can add, that Eve Motionblinds also work nicely with the same method:
1: Setup and pair with Eve App & HomeKit.
2: Remove from HomeKit
3: Discovered by HA as HomeKit Thread device, offered as integration.

:heart:

17

I’ve been trying this but in step #3 HA complains the device is already in use and needs to be reset. Doing so gets you right back to just being detected as a bluetooth device,

Any suggestions?

18

Hi John, are you talking about EVE Thermo? They can be upgraded to Matter using the EVE App. Then, if you have the Matter Integration in HA it is easy to add them to HA: In HomeKit you go to the Setting of the device, turn on Pairing Mode. In HA you go to Add Device and select Matter Device. Use the pairing code provided by HomeKit.
Matter allows equipment to be connected to several systems.

Don‘t know if Motion Blinds are Matter compatible
Rgds,
Joop

19

Sorry, forgot to mention this is an Eve Water Guard so, sadly, no Matter support yet.

20

This is the explanation for the issue I got with my EVE Aqua some time ago:

21

Thanks, will give it a shot…