I’ve set my Eero’s thread network as the preferred network in HA Android companion app by importing the Active Operational Dataset. I also chose one for the iOS/Android credentials, but I’ve no idea what that’s supposed to do.
When I attempt to add a Matter device, in this instance a Nanolead Essentials bulb, it says, ‘This device requires a Thread border router’ ‘Connect your border router, then try setting up your device’
Any insight as to why this might be happening?
I checked the diagnostic logs for thread and matter, but nothing appears to be valuable. However, I do not know what I should be looking for. I would be happy to share those if someone could let me know if any particular data should be redacted from them.
I’m not entirely sure, but somewhere along the way, when the HA Companion App is used for Commissioning a Thread device, the Companion App (I’ll assume you are using the same Android HA Companion App throughout):
The Companion App should have the Thread network’s credentials/dataset
The Companion App should also be able to see the mDNS discovery messages from the TBR that the credentials are usually stored against, as it needs to talk with the TBR to add the device to Thread
Since you used the HA Android Companion App to give HA the eero credentials/dataset, it seems to me you have satisfied #1.
If your Companion App, you HA and the TBRs (especially the TBR the dataset/credentials are stored against) are connected on the same layer2 network (and multicast is not filtered), then #2 should be satisfied as well. I should also mention that IPv6 needs to be running as well.
Hey Tommy, that’s great thanks for taking the time to respond.
Is there a way to verify ‘same layer2 network (and multicast is not filtered)’?
I have the ‘Discover’ application on my Mac, and it gives details of every service on my network, so I can probably confirm the above if I know the right things to look for.
I have IPv6 enabled, and all devices are connected to the same 192. IP address. Not sure how to see if multicast is not filtered.
Do you know what the Home Assistant companion app service should display as in Discover?
I’ve magically gotten a little further now. It’s no longer '‘This device requires a Thread border router’ ‘Connect your border router, then try setting up your device’.
It now says ‘Generating Matter credentials’ then ‘Checking the network connectivity’ but then fails now with ‘Can’t reach device’ ‘Make sure your phone is connected to Wi-Fi’ which it is.
Let me backup a bit …
The actual preferred method for commissioning a device in a setup such as yours is to first use eero stuff to commission a device onto the eero Thread network, then tell eero you want to share the device with another Matter Fabric (namely HA’s Matter) and when in this mode use HA’s regular “Add Device” for Matter. This gets around without having to deal with Thread/Thread credentials, special capabilities of Companion Apps for commissioning, etc. All that is needed in this case is to have IPv6 working correctly.
Anyway, to try and answer your questions:
TBRs should be advertising something like: _meshcop._udp.local
Assuming your HA server, your eero TBR and your Companion App are on the same 192.xxx network, then these devices should also be on the same IPv6 network. The eero TBR should be advertising an IPv6 “ULA” prefix for everyone to use, so your HA, eero, and Companion App mobile device should also have a IPv6 networking address, something like fdaf:blah-blah. Note: If the only IPv6 address is fe80:blah-blah, then that is an insufficient IPv6 address.
If you are seeing these discovery messages on your MAC, and your MAC is on the same 192.x.x.x/24 network as HA and your Companion App, then there is probably not any multicast filtering being performed anywhere.
My understanding is that “Checking the network connectivity” is the part where Companion App has handed the Matter/Thread device the Thread credentials via Bluetooth, and the device is trying to join the Thread network, (and here is where I’m a little fuzzy) if the device was able to successfully join the Thread network, then the eero TBR should be sending advertisements for the new device onto your IPv6 network for the Companion App to see, and then the Companion App will try to communicate to the device directly via the IPv6 network. So somewhere along the way this is failing.
As far as I know, and this is my primary issue with my Eero routers, is that they don’t have a way of doing any of this, at least the Matter part (I can, with a bit of frustration, get a Nanoleaf Thread device to join the Eero network directly and use the Nanoleaf app for controlling the device)
However, you can use Alexa to onboard a Matter-Thread device, which works dandy (presumably because Amazon owns them, and I noted that in a firmware update, they specifically mention ‘Support for controlling Matter devices with Alexa’.)
But ultimately, I want to move away from Alexa. So, I’m trying to determine if I can use HA Matter with Eero’s thread network.
I see both _meshcop._udp and _matter._tcp in Discovery, both of which are directly related to my Eeros, as I currently don’t have my HA instance booted up. I also have a _trel._udp again, which is related to my Eeros, which is ‘OpenThread,’ I believe.
So looks like Eero has all the magic components, but hopefully not wallgardened into Alexa regarding Matter.
Any advice for hijacking my Eeros and using HA matter?
I don’t know much about Eero and Alexa, but could it be the case that Eero is just a TBR and doesn’t know anything about Matter, and if I have it correct, Eero has Alexa Built-in, so could it be that Alexa is the Matter Controller? If roughly correct, then could it be the case that it is the Alexa App (that talks to the Alexa inside Eero) that does the Commissioning of devices onto Eero’s Thread network, and consequently it is the Alexa App that you would use to share the Matter device to HA’s Matter?
I would be happy to share those if someone could let me know if any particular data should be redacted from them.