Issues with SkyConnect + OTBR + Thread + Android Nanoleaf + Essentials Bulb Integration

[idkwatimdoinman]

@wmaker

HA Android Companion App

I have the app installed now. When I try to add a Matter device, it redirects to the Google Home adding Matter device page but will not activate the camera. Not exactly sure why (doesn’t error out, but is a black screen).

I’ve tried with 3 different phones and they all behave the same way (Oppo Find X5 Pro, OnePlus 9, Samsung Galaxy S8+).

The fact that the Android app did actually see a Thread network (albeit greyed out) to me suggests there is some support mechanism to make HA’s Thread network appear.

EDIT: I’ve also tried the QR code onboarding, however the Nanoleaf Essential bulbs are only 8 digit pairing codes, whereas the Matter option to onboard without scanning QR requires an 11 or 21 digit code.

[idkwatimdoinman]

@wmaker For what it’s worth, I’ve made some decent progress.

My HA instance is hosted in Unraid on a HASSIO VM. My networking infrastructure is all Ubiquiti. I’ve enabled IPv6 on all VLANs for testing (was initially limited to IoT and my main WLAN). My HA instance sits on the IoT network.

After doing this and rebooting my VM, I found another batch of IPv6 addresses assigned (previously it was only fe80:: and my WAN IPv6 IP allocation). Now I have fd33, which from what I’ve read is ULA and is essential for the Nanoleaf lights to appear on the Thread network (can’t site sources right now, but other HA posts have suggested this as well as Github reported issues - I’ll try and find sources later).

I then rechecked my Thread setup and noticed my radio settings were different (this was probably due to the multiple resets of my border router). On the Android app, there was always one static entry with the very first radio PAN ID and Extended PAN ID. I then exposed the HTTP port of the OTBR addon (go to the Silicon Labs Multiprotocol addon, select Configuration, show hidden settings and enable HTTP 8080 AND Websocket HTTP 8081 (won’t work with just HTTP)). Navigate to your VM’s IP and the port number, and this will bring up the OTBR GUI. I selected Join, and it found 2 obsolete networks with the first PAN ID, not the current one. I managed to recover the network key it required to join this network from the Android Nanoleaf app (under Thread Network → home-assistant). I did have to try and pair another globe for the app to show the Network Key as it doesn’t by default. Copied the key down, used the same key to join the network, and it joined!

Refreshing the OTBR addon in HA now shows TWO OTBR networks (one current, one from ‘other network’). Couldn’t figure out a way to force the old OTBR config over the new until I came across this thread: How to configure preferred Thread network - #3 by stephane.stolz. After deleting the OTBR addon and restarting HA, the OTBR addon now shows no ‘current’ network, and my old one has an option to ‘Make Preferred’! After doing so, the old settings were now in place (and this can be confirmed from the OTBR GUI → Status). Brilliant!

I then done a Wireshark trace on my main PC, and lo and behold the Nanoleaf bulbs now appear (obscured some of the addressing).

This wasn’t happening before, so clearly it’s doing something useful.

I then attempted to pair the two bulbs listed through the Android Nanoleaf app, and it found the Thread networks successfully and added themselves within a second (previously it would ‘find’ the network, then time out after 30 seconds and defer to BLE).

Unfortunately even after finding the network successfully and claiming it was now on Thread, the bulbs are still showing BLE in the ‘My Devices’ section of the Android app and the Thread Network is still greyed out (from what I can tell, it should be green and your bulbs will appear in that network).

I feel like I’m 95% of the way there, but something is preventing the bulbs from fully latching onto the Thread network. Still doing some testing, but I’ll update here again if I make any further progress.

[idkwatimdoinman]

IT WORKS! (I think)

Ended up being a couple of missing Firewall rules (IPv6 ICMP (was only set to pass UDP) and a LAN IN rule to allow my homeassistant IP to communicate with ALL protocols within the IoT VLAN (this will be refined later)).

Thread logs now show something like this:

otbr-agent[304]: 02:51:02.626 [I] MeshForwarder-: Received IPv6 UDP msg, len:95, chksum:10ee, ecn:no, from:b64fe25f06f54759, sec:no, prio:net, rss:-69.0
otbr-agent[304]: 02:51:02.627 [I] MeshForwarder-:     src:[fe80:0:0:0:b44f:e25f:6f5:4759]:19788
otbr-agent[304]: 02:51:02.627 [I] MeshForwarder-:     dst:[ff02:0:0:0:0:0:0:1]:19788
otbr-agent[304]: 02:51:02.627 [I] Mle-----------: Receive Advertisement (fe80:0:0:0:b44f:e25f:6f5:4759,0x9c00)
otbr-agent[304]: 02:51:04.795 [N] MeshForwarder-: Dropping (reassembly queue) IPv6 UDP msg, len:195, chksum:0dec, ecn:no, sec:yes, error:ReassemblyTimeout, prio:net, rss:-75.0
otbr-agent[304]: 02:51:04.795 [N] MeshForwarder-:     src:[fe80:0:0:0:d893:8d9e:1e84:1f83]:19788
otbr-agent[304]: 02:51:04.795 [N] MeshForwarder-:     dst:[ff02:0:0:0:0:0:0:1]:19788
otbr-agent[304]: 02:51:09.627 [I] MeshForwarder-: Received IPv6 ICMP6 msg, len:48, chksum:99b1, ecn:no, from:0xf000, sec:yes, prio:normal, rss:-82.0
otbr-agent[304]: 02:51:09.627 [I] MeshForwarder-:     src:[fd33:6ea4:xxxx:x:xxxxx:xxxx:xxxx:xxx]
otbr-agent[304]: 02:51:09.627 [I] MeshForwarder-:     dst:[2403:580d:xxxx:x:xxxx:xxxx:xxxx:xxxx]

otbr-agent[304]: 03:04:15.678 [I] SrpServer-----: Received DNS update from fd6a:9axx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx
otbr-agent[304]: 03:04:15.683 [I] SrpServer-----: Processed DNS update info
otbr-agent[304]: 03:04:15.683 [I] SrpServer-----:     Host:Nanoleaf-A19-xxxx.default.service.arpa.
otbr-agent[304]: 03:04:15.683 [I] SrpServer-----:     Lease:3600, key-lease:604800, ttl:3600
otbr-agent[304]: 03:04:15.683 [I] SrpServer-----:     1 host address(es):
otbr-agent[304]: 03:04:15.684 [I] SrpServer-----:       fd33:6exx:xxxx:x:xxxx:xxxx:xxxx:xxx
otbr-agent[304]: 03:04:15.684 [I] SrpServer-----:     Adding service 'Nanoleaf A19 xxxx._ltpdu._udp.default.service.arpa.'
otbr-agent[304]: 03:04:15.684 [I] SrpServer-----: SRP update handler is notified (updatedId = 1844180815)
otbr-agent[304]: [INFO]-ADPROXY-: Advertise SRP service updates: host=Nanoleaf-A19-xxxx.default.service.arpa.
otbr-agent[304]: [INFO]-ADPROXY-: Handle publish SRP service 'Nanoleaf A19 xxxx._ltpdu._udp.default.service.arpa.': OK
otbr-agent[304]: [INFO]-ADPROXY-: Waiting for more publishing callbacks 1
otbr-agent[304]: [INFO]-ADPROXY-: Handle publish SRP host 'Nanoleaf-A19-xxxx.default.service.arpa.': OK
otbr-agent[304]: 03:04:15.684 [I] SrpServer-----: Handler result of SRP update (id = 1844180815) is received: OK
otbr-agent[304]: 03:04:15.684 [I] SrpServer-----: Update host Nanoleaf-A19-xxxx.default.service.arpa.
otbr-agent[304]: 03:04:15.684 [I] SrpServer-----: Update existing service 'Nanoleaf A19 xxxx._ltpdu._udp.default.service.arpa.'
otbr-agent[304]: 03:04:15.684 [I] SrpServer-----: Send success response

Android Nanoleaf app now looks like this:

Also found out that the Google Home app updated for me today and the layout is completely different. Tried scanning the Matter QR code, the camera now works (yay) but the app reports the Nanoleaf Essentials bulbs are not compatible with Matter :\

Talk about a pain in the arse to setup

Now need to do some more exploring as to why no entities are registering against Matter, Thread or OTBR.

[wmaker (Tommy Long)]

From what I can tell looking at the logs (and I’m still learning this), is that the HA OTBR received a DNS update from your bulb via IPv6 unicast and then turned around and ADvertised via PROXY this service over the LAN (which should be a multicast address). So to me, it looks like the bulb has successfully joined HA’s Thread network.

@idkwatimdoinman

Now need to do some more exploring as to why no entities are registering against Matter, Thread or OTBR.

Maybe I missed it, but did you add the device using HA’s Matter Integration (UI->Settings->Devices & Services->Devices Tab->Add Device (choose Matter)?

[idkwatimdoinman]

@wmaker

So to me, it looks like the bulb has successfully joined HA’s Thread network.

That would be an accurate assessment.

@wmaker

Maybe I missed it, but did you add the device using HA’s Matter Integration (UI->Settings->Devices & Services->Devices Tab->Add Device (choose Matter)?

I have tried this from the HA Android App, but the application looks for a Matter device, then when it cannot find one, redirects to Googles ‘Add Matter Device’ with the option to enter a QR code or scan the QR code. Both of which fail as the QRs on the Nanoleaf Essentials bulbs are apparently ‘not Matter QR codes’. The manual inputs require an 11 or 21 digit code, whereas the bulbs only have an 8 digit code.

[idkwatimdoinman]

@wmaker Good news! All the lights are now in Home Assistant

Suffice to say it wasn’t pain free, but it turns out reading related forum posts really does help from time time. Specifically https://community.home-assistant.io/t/homekit-accessory-protocol-hap-over-coap-udp-was-nanoleaf-essentials-bulb-via-thread-coap (helped me quite a lot).

Remaining issues:

• Needed to setup IPv6 specific rules in my UDM Pro to allow ICMPv6 traffic (that was a big one)
• Make sure on my HASSIO VM that these routes shown fe80 and the unique ULA addresses from the Nanoleaf bulbs:

ip -6 r
ip -6 a
ip -6 n

• ip-6 a and ip -6 n commands shown the ULA addresses for the Nanoleaf devices (they are different to the WAN and LAN v6 ranges). Needed to do a tcpdump to watch traffic on the HASSIO VMs interface to work out whether the routes were being broadcast and routed. Initially they were not due to the lack of IPv6 rules, but after the rules were added into v6 LAN LOCAL and v6 LAN IN on the UDM, and a reboot of Unraid and my UDM Pro, the routes appeared.
• Needed to pair all the bulbs with the Android Nanoleaf app first before looking at HA integration and have them appear on the Nanoleaf apps Thread network.
• Using HAP (Homekit Controllers) to do the integration… this last one was not documented anywhere.

In essence, if the bulbs are talking to each other by IPv6 UDP/ICMP via the ULA addresses (can be verified by looking for traffic starting with the ULA address via tcpdump), it means the OTBR/normal BR is advertising routes (expected behaviour). HA then sees this as a new integration via HAP and asks you to pair the bulb as if you were adding it to an Apple device.

The kicker was the PIN on the side of the bulbs were the key, BUT they needed to be in HAPs format! (ie. PIN on bulbs are xxxxxxxx, HAP asks for xxx-xx-xxx). Once that format was entered, it recognised the bulbs as Nanoleaf NL45s and paired as normal.

End result:

Courtesy of Thread’s performance, the lights respond in a split second from turning them on and off. Now working on the automations to have them work in sync with my sensors, but the biggest hurdle I’ve come across has now been cleared.

Sorry for the long winded post, but figured I’d update and close this one off in the event it becomes usual to someone that has a similar setup.

[wmaker (Tommy Long)]

Just curious, are these bulbs labeled as Homekit bulbs or are they labeled as Matter bulbs?

[idkwatimdoinman]

Homekit. The Matter ones were double the price and I’ve ended up fitting 30 of them.

[sayanova]

Can you share your Unifi Firewall Rules? I’m having trouble connecting Thread Devices(Matter, Homekit) to Home Assistant…

[idkwatimdoinman]

Sure, though mine are retrofitted for my use case so change as needed. I took these from another source (can’t find it off hand, will edit later if I find it).

My understanding is the most important two to have set are ICMPv6 Echo Replies and v6 UDP Multicast. You also need to make sure you are trying to add the devices from the same IOT network, and not trying to connect from one VLAN to another.

LAN v6:

Port/IP Groups:

The link_local_IPv6 addresses are very broad and that was for testing. They’ve since been refined, but the fe80 is v6 link local for local address communication. The fd00 is for the ULA range (the Essentials bulbs need to be communicating on a v6 range that’s not fe80).

Port 5353 is for Multicast and 5540 is the Matter communication port.

[sayanova]

Is it impossible to connect from one VLAN to another?
my Home Assistant is in Service VLAN and Apple HomeHubs are in Main VLAN. Then is it impossible to connect?

[idkwatimdoinman]

Correct; Matter is not designed for complex networks (needs to be as flat as possible). In my case I connect to the IoT WiFi to commission a new device.

Your HA instance also needs to be in the same network range as your IoT network for the same reason.

Edit: Matter and Thread (for reasons those smarter than I can elaborate on).

[sayanova]

I have 2 LAN interface so for HA it doesn’t matter.
But then How about Apple TVs? Should Apple TV be in IoT network too?

[idkwatimdoinman]

If you want the Apple TV to be the Thread Border Router, then Yes.

[sayanova]

Ugh, it was a nightmare! I tried setting up Apple TV on the IoT VLAN, and it was just a world of trouble.

Not to blame you, super thanks for your firewall rules. Thanks.

[idkwatimdoinman]

No problems, and I had just as many issues (different reason, same outcome).

Hope the firewall rules helped

[cadmium]

Thanks so much for your writeup. I’ve read through your comments, and I’m unfortunately in a bit of a similar situation where I am unable to get my nanoleaf essentials to connect via my thread network at all.

I’m currently running home assistant within kubernetes, and I’m running the silabs multipan RCP as a separate container (with both home-assistant and the mulipan RCP container connected to my LAN via multus-cni with a macvlan network attachment; I’m able to see and send mDNS requests successfully for other services like google cast, homekit protocol, etc)

• I am also able to see a meshcop DNS-SD entry, with the 3 ipv6 addresses associated with it, so I believe my thread network is being advertised.
• I can also see the thread network appear in my nanoleaf android app, like so:
  

However, when I try to pair my essentials strip with the android app, it just remains loading on the “looking for thread network” for about 10 seconds before giving up and just defaulting to BLE.

@idkwatimdoinman

I found another batch of IPv6 addresses assigned (previously it was only fe80:: and my WAN IPv6 IP allocation). Now I have fd33, which from what I’ve read is ULA and is essential for the Nanoleaf lights to appear on the Thread network

Where specifically did you find these batch of IP addresses assigned? If I go to my OTBR web interface → status, I can see that I have a MeshLocalAddress assigned there starting with fd77; did it have to be fd33 specifically?

@idkwatimdoinman

I managed to recover the network key it required to join this network from the Android Nanoleaf app (under Thread Network → home-assistant). I did have to try and pair another globe for the app to show the Network Key as it doesn’t by default. Copied the key down, used the same key to join the network, and it joined!

I’ve also skipped this entire thing as I wasn’t quite sure what you were referring to, but my home assistant instance only shows the one network and I have set that to preferred; my understanding is that this is where I should be.

@idkwatimdoinman

I then done a Wireshark trace on my main PC, and lo and behold the Nanoleaf bulbs now appear (obscured some of the addressing).

Would you be able to share what query you made in wireshark to view these? I am unable to find any ltpdu messages in wireshark (and I am assuming that’s because I haven’t been able to get the lights to join the thread network).

I’d appreciate any further direction you have - I have checked my firewall, but I seem to have full IMCPv6 allowed in my local network. Thanks.

[sayanova]

After enabling NAT64 features in OTBR, or using this with Apple Thread Border Router cause problem. Should I add same firewall rules for IPv4 range?

[Shadoxity (Leon Black)]

Are you seeing the bulbs stay up pretty reliably?
I have 36 of the essentials bulbs and since adding more than about 12-15, it seems a bunch of them are dropping off unavailable a lot of the time.
Gives me hope seeing someone with a whole lot of the lights up and connected.

[Danko_Crnkovic (Danko Crnković)]

I lost hours and hours on this one.
@idkwatimdoinman firewall rules were crucial for thread network to show up in nanoleaf app.
But, device would not connect to thread. And finally solution was Home Assistant companion app on my Android phone!
You must sync Thread network credentials. In the Companion app, go to Settings > Companion app > Troubleshooting , then select Sync Thread credentials .