@06_ripcord.ogress that’s really weird… you should be on aiocoap 0.4.4. Let me look around, maybe some other component is pulling in 0.4.1.
EDIT: if you want to fix this now, change the else: line on 187 of ws.py to elif port != 0: being careful to preserve the spacing and restart HA.
@setomerza @DaJonas it is possible you are having the same issue if you are on 2022.11.x. Can you please check your aiocoap version? And please make this change. It is a fix I pushed into aiocoap months ago to solve this problem. I’m not sure why it has downgraded.
I am up to 8 thread homekit devices (though 7 in active use). Mixture of Eve, Nanoleaf and Wemo.
The biggest source of outages for me has been my HomePod hopping between wifi networks (moved it to my iot vlan so the RA’s were handled properly, but it remembers the old network and keeps hopping back).
From errors I’ve seen on GitHub, this one:
aiocoap.error.NetworkError: [Errno 113] received through errqueue
has usually been connectivity issues (dodgy wifi repeaters, RA’s not been handled properly, surprise border router on a different vlan, etc).
(EDIT: 113 is an OS error code for “no route to host” which is generally what I’ve seen)
As I was beginning to debug this and follow your steps I rebooted home assistant OS (core 2022.11.X) to set up root SSH authorized_keys, and sure enough when I checked homekit controller all the devices were back on the network working properly now… I still have the
and self.enc_ctx.send_ctr - self.enc_ctx.recv_ctr < 1
patch applied but this was the first time I observed any difference in behavior over the past 2 days.
I also ran these commands to verify:
grep ^Version /usr/local/lib/python3.10/site-packages/aiocoap-*/METADATA
Returns:
Version: 0.4.4
And this
grep -n -C 3 3000 /usr/local/lib/python3.10/site-packages/aiocoap/transports/ws.py
Returns:
3 3000 /usr/local/lib/python3.10/site-packages/aiocoap/transports/ws.py
50-
51- Due to a shortcoming of aiocoap's way of specifying ports to bind
52- to, if a port is explicitly stated to bind to, CoAP-over-WS will bind to th at
53: port plus 3000 (resulting in the abovementioned 8683 for 5683). If TLS serv er
54- keys are given, the TLS server is launched on the next port after the HTTP
55- server (typically 8684).
56-"""
--
211- port = 8683
212- elif port != 0:
213- # FIXME see module documentation
214: port = port + 3000
215-
216- server = await websockets.serve(
217- functools.partial(self._new_connection, scheme='coap+ws' ),
/usr/local/lib/python3.10/site-packages/aiohomekit/controller/coap #
We’ll see how long this behavior lasts for. Fingers crossed!
My aiocap Version is 0.4.4 as well.
I have just implemented your fix with the “timeout=45.0” (which was harder than you might think without any knowledge about how to access it). Just did a reboot, verified the timeout is still 45.0. At least at the moment the devices are still unavailable, but pingable. (only checked that with one device though but at least that device should be available then)
@setomerza really glad to hear it. While things are working, can you grab some network info and set it aside? We’ll compare later states to it if things stop working again. From HA, run:
ip -6 aip -6 rip -6 n
@DaJonas thanks for testing. Can you please turn on debug logs for aiohomekit, restart HA, and DM them to me? You can use the File Editor or Visual Studio Code add-ons, or just modify configuration.yaml directly on the console. Add the following or modify an existing logger: block:
logger:
default: info
logs:
aiohomekit: debug
@lambdafunction
Thanks for pointing me in the right direction, it turns out aioairctrl used by philips-airpurifier-coap had aiocoap 0.4.1 as a dependancy, I forked the repo, updated the library and now my HA is using 0.4.4 and the Nanoleaf bulbs are working as expected!! Thanks again!!
Thanks again for all the help!
ip -6 a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 fd45:7a0a:5395:42f1:11b5:f444:ec4e:8451/64 scope global dynamic noprefixroute
valid_lft 1776sec preferred_lft 1776sec
inet6 fe80::dc7b:1455:3c4:1927/64 scope link noprefixroute
valid_lft forever preferred_lft forever
4: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP
inet6 fe80::42:6fff:fec9:80de/64 scope link
valid_lft forever preferred_lft forever
5: hassio: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP
inet6 fe80::42:34ff:fe76:2149/64 scope link
valid_lft forever preferred_lft forever
7: vethb9bee09@if6: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 state UP
inet6 fe80::ec5f:86ff:feb1:6641/64 scope link
valid_lft forever preferred_lft forever
9: veth491ffd6@if8: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 state UP
inet6 fe80::f041:b7ff:fe49:cdea/64 scope link
valid_lft forever preferred_lft forever
11: veth21820b3@if10: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 state UP
inet6 fe80::dc42:17ff:fe3a:8685/64 scope link
valid_lft forever preferred_lft forever
13: veth9a365a7@if12: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 state UP
inet6 fe80::3892:41ff:fed4:47dd/64 scope link
valid_lft forever preferred_lft forever
15: veth264e13e@if14: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 state UP
inet6 fe80::448:a4ff:fe8f:a608/64 scope link
valid_lft forever preferred_lft forever
17: veth8b5dfb0@if16: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 state UP
inet6 fe80::a03d:19ff:fe95:6a49/64 scope link
valid_lft forever preferred_lft forever
19: veth1078d11@if18: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 state UP
inet6 fe80::5c7d:13ff:fe71:6150/64 scope link
valid_lft forever preferred_lft forever
21: veth01d7185@if20: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 state UP
inet6 fe80::a093:7dff:fec4:953f/64 scope link
valid_lft forever preferred_lft forever
23: veth6c45250@if22: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 state UP
inet6 fe80::84ed:4bff:feea:d488/64 scope link
valid_lft forever preferred_lft forever
25: veth80b9f39@if24: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 state UP
inet6 fe80::14a0:5fff:fea6:6600/64 scope link
valid_lft forever preferred_lft forever
ip -6 r
::1 dev lo metric 256
fd0c:29f0:2531::/64 metric 100
fd45:7a0a:5395:42f1::/64 dev eth0 metric 100
fe80::/64 dev eth0 metric 100
fe80::/64 dev hassio metric 256
fe80::/64 dev vethb9bee09 metric 256
fe80::/64 dev veth491ffd6 metric 256
fe80::/64 dev docker0 metric 256
fe80::/64 dev veth21820b3 metric 256
fe80::/64 dev veth9a365a7 metric 256
fe80::/64 dev veth264e13e metric 256
fe80::/64 dev veth8b5dfb0 metric 256
fe80::/64 dev veth1078d11 metric 256
fe80::/64 dev veth01d7185 metric 256
fe80::/64 dev veth6c45250 metric 256
fe80::/64 dev veth80b9f39 metric 256
anycast fe80:: dev hassio metric 0
anycast fe80:: dev vethb9bee09 metric 0
anycast fe80:: dev veth491ffd6 metric 0
anycast fe80:: dev docker0 metric 0
anycast fe80:: dev veth21820b3 metric 0
anycast fe80:: dev veth9a365a7 metric 0
anycast fe80:: dev veth264e13e metric 0
anycast fe80:: dev veth8b5dfb0 metric 0
anycast fe80:: dev veth1078d11 metric 0
anycast fe80:: dev veth01d7185 metric 0
anycast fe80:: dev veth6c45250 metric 0
anycast fe80:: dev veth80b9f39 metric 0
multicast ff00::/8 dev eth0 metric 256
multicast ff00::/8 dev hassio metric 256
multicast ff00::/8 dev vethb9bee09 metric 256
multicast ff00::/8 dev veth491ffd6 metric 256
multicast ff00::/8 dev docker0 metric 256
multicast ff00::/8 dev veth21820b3 metric 256
multicast ff00::/8 dev veth9a365a7 metric 256
multicast ff00::/8 dev veth264e13e metric 256
multicast ff00::/8 dev veth8b5dfb0 metric 256
multicast ff00::/8 dev veth1078d11 metric 256
multicast ff00::/8 dev veth01d7185 metric 256
multicast ff00::/8 dev veth6c45250 metric 256
multicast ff00::/8 dev veth80b9f39 metric 256
ip -6 n
fe80::1044:a500:dfc:7acd dev eth0 lladdr 4e:ad:22:9d:e6:45 used 0/0/0 probes 1 STALE
fe80::8ce:e617:be06:f950 dev eth0 lladdr 94:ea:32:6a:83:54 router ref 1 used 0/0/0 probes 1 REACHABLE
fd45:7a0a:5395:42f1:1c11:543d:441b:cd83 dev eth0 lladdr f4:34:f0:03:9f:2a router ref 1 used 0/0/0 probes 1 REACHABLE
fe80::1ce8:8292:9bc6:332a dev eth0 lladdr f4:34:f0:03:9f:2a router ref 1 used 0/0/0 probes 1 REACHABLE
fe80::86:a87d:2ab2:24df dev eth0 lladdr f4:34:f0:7c:2f:7b router used 0/0/0 probes 1 STALE
fd45:7a0a:5395:42f1:1018:b1a4:75e9:a722 dev eth0 lladdr 94:ea:32:6a:83:54 router used 0/0/0 probes 1 STALE
fe80::1ce7:7e1:174c:1d28 dev eth0 lladdr 5a:41:cf:70:84:34 used 0/0/0 probes 1 STALE
fd45:7a0a:5395:42f1:103c:caf3:57d5:c5ab dev eth0 lladdr f4:34:f0:7c:2f:7b router ref 1 used 0/0/0 probes 1 REACHABLE
Same issues with mine. I just took them off home assistant and put them back onto homekit until this can be resolved.
Where does this issue stand? I just tried adding my first thread bulb (Nanoleaf) to HA. Second attempt I was able to add it, got very excited, But it did not take long for it to become unavailable.
I’m running latest version HassOs at 2022.11.2 with 3 HomePod mini’s handling my thread devices. My Apple stuff is running the beta 16.2 version so the new HomeKit.
another attempt - I reboot all my home pods, re-added the bulb to HomeKit. Removed it and added into HA. Fingers crossed…
I have 2 bulbs active now and are working (1 day so far). I do get a these messages a few times.
- CoAP POST returned unexpected code <aiocoap.Message at 0x7fc104aceda0: Type.ACK 4.04 Not Found (MID 6711, token 41b7) remote <UDP6EndpointAddress [fd6e:cabf:6c84:0:8007:d074:27d0:7d80] (locally fd27:5084:df49:44ed:d0e1:d94b:b8ed:795d%enp0s18)>>
- Decryption failed, desynchronized? Counter=825/826
- Failed flailing attempts to resynchronize, self-destructing in 3, 2, 1…
Logger: aiohomekit.controller.coap.pdu
Source: components/homekit_controller/connection.py:711
First occurred: 8:01:39 AM (1 occurrences)
Last logged: 8:01:39 AM
Transaction 0 failed with error 6 (Invalid request
Downloaded latest Home Assistant hoping it would solve the issue with multiple homepods. However the same issue has happened once again. I had everything all set up on my apple TV home hub and as soon as I plugged in the homepod minis all hell broke loose.
New Update: Rebooted Home Assistant Rasp Pi System (Hardware) and so far everything paired up again. Will keep posted if anything changes.
That is what I have discovered as well. I have added a script to restart the rpi on my troubleshooting tab for ease of access, but restarting the raspberry pi definitely works more consistently than restarting hassos. Also, I have added an automation sending a notification to my phone/watch when any of my nanoleaf bulbs changes state to unavailable. when that triggers I will restart my homepod minis and the rasp pi. So far that has consistently reconnected the lights to home assistant.
Update 2: So the restart only worked because I had Bluetooth integration enabled. This was causing my bulbs to be connected to my Raspberry Pi’s Bluetooth. Once I disabled the integration only 3 bulbs were still disconnected and would not reconnect even on restarts. I am going to try and unplug both HomePod minis and then restart to see if the restart needs 1 hub to connect.
It seems like the mesh system is just broken. Hopefully we can get it working with this integration.
Hmm … I have one homepod mini and one nanoleaf strip - I set it up late September, and other than 1 occurrence of the strip being unavailable in mid-Oct, I’ve been rock solid.
I haven’t been keeping accurate score, but it seems that one of the differences my “stable” system and all you folks who seem to have pretty unreliable systems is that I have an extremely limited thread network (both in terms of devices and homepods). Could it be related?
I think it is because you only have 1 border router (i.e 1 homepod mini). I have an apple tv and 2 homepod minis (I.e Multiple Border Routers). The multiple border routers is causing the thread devices to link separately rather than talking to each other. I am not an expert on this so I may be wrong.
Update 3: Unplugged Homepod Minis so that my AppleTV is the only hub and have hardware restarted twice with no success.
Don’t know what else I should do to fix this besides trying to repair again. Quite a frustrating dilemma.
Update 4: It looks like all of these unpaired bulbs are not showing up on hap.udp , so somehow they got disconnected I guess?
Does anyone have Apple’s Thread Border Routers pulling IPv6 prefix delegations and passing IPv6 GUAs onto Thread devices successfully? The standard says they “should”, and I’ve got DHCPv6 on my OPNsense firewall set up with a PD range, but the Apple devices (ATV 4k 3rd gen & HomePod Mini) don’t seem to be even requesting prefixes. Trying to figure out if that’s just expected or if I’ve configured something wrong.
Can you ping the “offline” bulbs, either at their last known IP or by using their .local hostnames? (Might need to try it right from your HASS server depending on your network setup.) That they’re not showing up in _hap._udp. makes me suspect they won’t respond, and if they’re not even reachable that way, the issue is outside of the scope/control of HASS and would appear to be an Apple problem. FWIW, I have two Apple devices acting as TBRs (ATV + HomePod Mini) and don’t have the kinds of issues you’ve described.
Edit: (Also, State sucks! Go Blue!)
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, but thats still in progress.
Regarding multiple thread border routers - this might not be our bug. E.g. https://www.reddit.com/r/HomeKit/comments/yvq64y/experience_to_date_going_all_thread/. Sounds like right now thread gets in a tizzy if it has to reorganise itself and even with native iOS this can be a big mess.
Oh and my environment continues to be fairly solid - like @putch I only have one border router.
Hi! What’s the state of provisioning homekit thread devices on a thread network? I’m trying to decide whether I should buy a HomePod mini as a thread border router, or whether I should wait till I can run an open thread border router via my silabs based Zigbee stick.