#Nanoleaf Smart bulb wont connect to thread network

1 messages · Page 1 of 1 (latest)

pseudo folio
#

Hello,

I am new to Homeassistant. I intsalled it recently in a docker container on my home Server. Now I want to connect a Nanoleaf smart bulb (E27), which is Thread and homekit compatible. As a thread border router I'll have my two homepod minis.

That is how I've tried it:

  1. Connected the bulb to my Nanoleaf app
  2. Tried to move it to my thread network, which is also on my home Server. (I had to try this multiple times, because for some reason the bulb won't change the thread network)
  3. Then I removed the bulb from the Nanoleaf app, but I did not reset the bulb itself.
  4. Then the bulb has shown up in my home assistant device discovered page
  5. Then I wanted to connect to it but as soon as I pressed on the add button, I'll get an network error.

In my docker container I'll also get this error message (see attached photo)

Thanks to anybody who could help me!

barren crag
#

What is your home network setup like? That error suggests that the machine where the matter server is running isn't receiving the ipv6 router announcements (or otherwise isn't assigning ipv6 addresses), so it's not able to talk to thread devices.

#

er wait, this isn't matter

#

so it would be the system where home assistant itself is running which cannot talk to the thread network over ipv6

pseudo folio
barren crag
#

how do you have home assistant installed? you said docker?

pseudo folio
#

yeah

barren crag
#

it seems like you have a configuration issue on the host system where it's not handling ipv6 router announcements correctly

pseudo folio
#

ok, this makes sense. Does thread communicate over IPv6?

barren crag
#

yes, thread communicates only over ipv6

pseudo folio
barren crag
#

quick check on the host system is that you should see an ipv6 address starting with "fd" on your main network interface when you run ip -6 addr, and one or more routes to a different ipv6 subnet starting with "fd" that have a "nexthop via" set when you run ip -6 route

#

(if you have multiple thread border routers, then it's normal to have multiple "nexthop via" with different addresses)

pseudo folio
#
root@heimserver:/opt/homeassistant# ip -6 route
fd6c:cb9f:b16c::/64 dev enp1s0 proto kernel metric 256 expires 7160sec pref medium
fd6c:cb9f:b16c::/64 via fe80::2e3a:fdff:feb7:3a1a dev enp1s0 metric 1002 mtu 1500 pref medium
fe80::/64 dev enp1s0 proto kernel metric 256 pref medium
fe80::/64 dev veth1a7fc9d proto kernel metric 256 pref medium
fe80::/64 dev br-1349764fcee7 proto kernel metric 256 pref medium
barren crag
#

that looks more or less correct, i think

pseudo folio
#

yeah, I kept the most things on default in my compose file 😂 :

services:
  homeassistant:
    container_name: homeassistant
    image: "ghcr.io/home-assistant/home-assistant:stable"
    volumes:
      - ./config:/config
      - /etc/localtime:/etc/localtime:ro
      - /run/dbus:/run/dbus:ro
    restart: unless-stopped
    privileged: true
    network_mode: host
    environment:
      TZ: Europe/Amsterdam
barren crag
#

hmm. with the container running in host network mode, I think it should be able to access ipv6 as long as the host has working ipv6 addressing...

pseudo folio
#
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute 
       valid_lft forever preferred_lft forever
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 90:1b:0e:c1:03:2c brd ff:ff:ff:ff:ff:ff
    altname enx901b0ec1032c
    inet 192.168.178.187/24 brd 192.168.178.255 scope global dynamic noprefixroute enp1s0
       valid_lft 764016sec preferred_lft 656016sec
    inet6 fd6c:cb9f:b16c:0:921b:eff:fec1:32c/64 scope global dynamic mngtmpaddr proto kernel_ra 
       valid_lft 7147sec preferred_lft 3547sec
    inet6 fd6c:cb9f:b16c:0:e8e2:4445:d9e5:829c/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 7147sec preferred_lft 3547sec
    inet6 fe80::7a25:2d82:6648:98f/64 scope link 
       valid_lft forever preferred_lft forever
3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default 
    link/ether 8e:46:19:a3:30:a5 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever
7: br-1349764fcee7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default 
    link/ether 7e:29:e1:c7:a3:82 brd ff:ff:ff:ff:ff:ff
    inet 172.18.0.1/16 brd 172.18.255.255 scope global br-1349764fcee7
       valid_lft forever preferred_lft forever
    inet6 fe80::7c29:e1ff:fec7:a382/64 scope link proto kernel_ll 
       valid_lft forever preferred_lft forever
8: veth1a7fc9d@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-1349764fcee7 state UP group default 
    link/ether 8a:32:57:74:ae:ab brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet6 fe80::8832:57ff:fe74:aeab/64 scope link proto kernel_ll 
       valid_lft forever preferred_lft forever
#

it should be working

barren crag
#

one thing i'm not sure about is whether home assistant in docker has the zeroconf browser available? It's under Settings > System > Network (at the bottom of the page) on HAOS. That's useful for thread stuff, you should be able to see the homekit device advertising itself via mdns and see what ipv6 address it has.

#

your system knows how to route traffic to fd6c:cb9f:b16c::/64 but if the thread devices are on a different subnet, then something's not right here.

#

the thread network and your lan should be on different subnets, so seeing your machine having an address starting with fd6c:cb9f:b16c:0: and seeing a route to fd6c:cb9f:b16c::/64 both be present is very strange.

pseudo folio
barren crag
#

check in the zeroconf browser to see if there's any entries from _hap._tcp.local (i think that's what the homekit devices should appear as)

pseudo folio
#

Only my bridge and some devices are listed there. My homepods are listed somewhere else

barren crag
#

huh, the _hap._udp nanoleaf devices at the bottom look suspicious. and they're on an ipv6 subnet that your system doesn't know how to route to

barren crag
#

I don't know - the problem is with your system (either configuration of the network on the host os, or configuration of other network hardware e.g. router), not with home assistant itself :/