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

Configuration
, ,
1

I’ve recently purchased a SkyConnect USB for the Zigbee + Thread use, and have nothing but issues trying to make it work.

I’m using a HASSIO VM on Unraid with the SkyConnect USB as a passthrough. The ZHA integration worked after the next VM boot, as HA prompted to configure. I’ve setup the Silicon Labs Multiprotocol addon and Multi-PAN and enabled the Multiprotocol option via Settings → System → Hardware. They are both on the same radio channel (have tried 15 and 25 as initially the SkyConnect radio and ZHA radio integrated on different channels) and I can integrate my Zigbee sensors (Aqara Motion FP1s). That’s where the smoothness ends and the issues begin…

I have ~a dozen Nanoleaf Essential bulbs and had paired them all through BLE on the Android app. I’ve read that to make the migration into Thread that the bulbs may need to be reset, so I’ve been testing with one. The Thread Network option in the Android app can see a network named ‘home-assistant’ but is greyed out. Unfortunately I don’t know how far along this process that appeared as I’ve been at this for a few days.

In HA, I have the official Matter, OTBR and Thread add-ons configured (HA prompted to configure automatically after the Multiprotocol addon was enabled and the Multi-Pan addon was installed). This all looked good. The Android app cannot see the same radio settings that are currently configured on the OTBR, so I ended up resetting all 3 addons after a few days of troubleshooting. The unique identifiers in OTBR are all different to what they were initially, and still the Android app cannot see the Thread network.

While pairing one of the bulbs, I was looking at the Matter logs in debug mode and found a pairing attempt had come through from the Android app! Great, I thought… except the app still did not see the Thread network and continued to pair by BLE. I borrowed an iPhone to install the Discovery DNS-SD app check whether the HA Thread integration was even showing up, and it was (under _meshcop._udp.) listed as 'Home Assistant Silicon Labs Multiprotocol #. It could see the v4 address of the VM and 3 iterations of v6 addressing, as well the Thread version (1.3.0). For what it’s worth, my network is all Ubiquiti/Unifi with VLANs in place, so I initially throught that UDP broadcasting across VLANs may have been an issue, however I also have several Chromecasts sitting on the network on one VLAN which are accessible by others without issue, so I dismissed this being a problem (for now, anyway).

I know there are a lot of moving parts and fairly new integrations have their teething issues, but I’m at a loss as to how to progress from here. I would rather not use HomeKit with this integration at all as I do not own any Apple products or devices.

Any help would be appreciated. Thanks.

2

Not sure how helpful I will be, but can you clarify a couple of things below…

Can you clarify which Add-Ons you have by name? For Matter, there is only the one “Matter Server” Add-On which you mentioned. For Thread, there a couple of Add-Ons to choose from but should pick only one, either “Silicon Labs Multiprotocol” Add-On, or “OpenThread Border Router” Add-On, so just want to make sure you’re not running both.

Can you clarify “Android app”, is it one for the Nanoleaf bulbs or is it the HA companion App?

3

Thanks @wmaker, I appreciate the effort.

Looks like I’m too new to embed images, but I’ll provide the text descriptions.

  • Matter Server (v4.5.1) AND Matter (BETA) - not sure if relevant but when I install one, it also installs the other. IIRC one is a Websocket?
  • Thread v1.3.0
  • Silicon Labs Multiprotocol v2.0.0:
  • OpenThreadBorderRouter (unable to find version):

Interesting you mention that; when the Multiprotocol addon is installed, it automatically installs OTBR (as that is apparently by design, based on the documentation from the OTBR addon):

The Open Thread Border Router integration allows calling an Open Thread Border Router’s REST API from Python and via WebSocket. The integration is automatically set up when the “Silicon Labs Multiprotocol” add-on is installed.

Nanoleaf v9.0.6 (https://play.google.com/store/apps/details?id=me.nanoleaf.nanoleaf&hl=en_AU&gl=US)

Hopefully that helps.

4

Ah OK…the OTBR in this case is actually an “Integration” instead of an “Add-On” which makes sense as it this Integration that HA Core uses to talk to the Silicon Labs Multiprotocol Add-On.

From your description, it sounds like all the parts are in place and connected properly.

Now that I know that this is the Nanoleaf App, could it be that the app has chosen to only work with certain Thread networks? Their website lists a set of “Compatible Thread Border Routers” and HA is not listed, so just wondering if that is why it has greyed-out the home-assistant thread network? Anyway, maybe try and use the HA Android Companion App to see if you can add the Nanoleaf bulb as a Matter device.

5

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.

6

@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).

image
image694×84 2.84 KB

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.

7

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:

image
image1440×2036 183 KB

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 :expressionless:

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

8

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.

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)?

9

That would be an accurate assessment.

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.

10

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

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:

image
image3023×1815 229 KB

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.

3 Likes
11

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

12

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

13

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

14

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:

image
image1065×1615 79.7 KB

image
image1017×1667 83.6 KB

Port/IP Groups:

image
image953×474 17.1 KB

image
image960×494 14.8 KB

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.

1 Like
15

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?

16

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).

1 Like
17

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?

18

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

1 Like
19

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.

20

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

Hope the firewall rules helped :slight_smile: