Ok so I have set up an open thread border router using an SZLB-06 from SMLight. Trouble is I am getting a “ghost” OTBR appearing. I think? because I have an Amazon Echo Gen 4. How the heck do I turn that Amazon thread signal off? Second question. How do I roll out more SZLB-06 thread routers to extend my thread networK… or is that not possible using these devices? thanks!
Good question, did not see ‘router firmware’ yet for these.
Anyway, simply use EspHome with an esp32-h or esp32-c6 to create thread routers.
1 Like
Thanks
Any clues how I get rid of Amazon thread interfering?
May I ask, where in HA are you seeing a “ghost” OTBR? Do you see it in the Thread Integration?
I see it in the Open Thread Border router Integration… as two OTBR services …
That’s interesting… I think the OTBR Integration auto-discovers the OTBR AddOn when used in HAOS, but I believe the only other way to add an entry is to manually specify a URL to another OTBR instance (I don’t think an Amazon Echo would automagically be added here). Anyway, you should be able to delete the ghost entry using the 3-dots for that entry and select Delete.
Sure. The trouble is I don’t know which one to delete. In any case how do I turn off the darn Thread router signal from the Amazon Echo?
In my case the entry says: Home Assistant SkyConnect (OpenThread Border Router)
What does yours show? Maybe provide an image of what you are seeing.
I’m not sure yet that this is the/a problem. Any Thread Router should be discoverable and it would show up in the Thread Integration. Do you see Amazon/Alexa in the Thread Integration?
1/ I see a local HA OTBR which is set to “preferred”
2/ Yes. I see AMZN-Thread-25b8 1 border router as “another network”
Umm… about “1/”. You said earlier that the ghost OTBR was appearing in the OTBR Integration. “Preferred” would not show up in the OTBR Integration but instead would show up in the Thread Integration. So I believe what you meant to say was that the ghost TBR is showing up in the Thread Integration and not the OTBR Integration. If correct, then this Amazon TBR is not really an issue.
Thread
Preferred network
ha-thread-dc51
1 border router
Other networks
AMZN-Thread-25b8
1 border router
So the OTBR Integration shows routers it has been told to connect to over a RESTful API, which gives HA a little bit of control over the router config (basically changing the credentials and radio channel). This extra control appears elsewhere, in the Thread Integration settings screen, and as you’ve noticed, having multiple OTBR instances is also poorly handled from a UX perspective since there is no way to tell them apart. The least they could do it put a settings button or tell you what IP address each is using.
My recommendation is to shutdown one of the border routers at a time, then wait for one of the instances to show an error (or click the three-dot menu and “reload” to speed it up). Once you know which is which, you can manually rename them, again in the three-dot menu. There is no harm or interference having two instances here, so in most cases once you’ve properly named them you can just ignore them as long as they aren’t showing errors.
Meanwhile the Thread Integration shows networks it discovers because all vendors’ TBRs send broadcast announcements over your network. Again these other networks usually aren’t interfering with each other, but they’re available to use if you ever need them, so you can safely ignore extra entries. If they all have the three-dot menu option to “join preferred network” (a feature provided by the OTBR REST API) then you have the option of merging them into your primary chosen mesh.
Oh I see now that you actually do have two OTBR integration instances …
If you have some technical skills, here is something you could also do:
- pick one of those entries, click on the 3-dots and “rename” it to something like “OpenThread Border Router2”
- With your ssh (or similar) go to your HA
/configdirectory and then go to.storage/ - Open up the file
core.config_entries(BE SURE NOT TO CHANGE/SAVE THIS FILE!!). Better to dogrep otbr core.config_entrieswhich won’t change the file. - Within the file, you should see a line/entry that looks like the following (search on
otbr):
{"created_at":"1970-01-01T00:00:00+00:00","data":{"url":"http://core-openthread-border-router:8081"},"disabled_by":null,"discovery_keys":{},"domain":"otbr","entry_id":"d92a5787bfcblahblah9657e9202850d1","minor_version":1,"modified_at":"1970-01-01T00:00:00+00:00","options":{},"pref_disable_new_entities":false,"pref_disable_polling":false,"source":"hassio","subentries":[],"title":"Home Assistant SkyConnect (OpenThread Border Router)","unique_id":"ec8eb9b639blahblahd750249f9b78e","version":1},
You should see 2 such entries, but one of them should have a “title” OpenThread Border Router, and another entry should have the :title" your renamed it to such as “OpenThread Border Router2”.
The important part is what is the “url” for each entry? If you are using HAOS and the OTBR AddOn, it should have been auto-discovered and the the url should show as above (i.e. http://core-openthread-border-router:8081). This url is the websocket that supports the Restful API that allows HA to somewhat manage the OTBR.
What do your urls point to?
Ok thanks everyone. I will take a look. How did this happen? Was it me (inadvertently) or a bug in HA? thanks
Unless it prompted you to enter a URL for the OTBR Integration, my guess is that something happened during the auto-discovery process (perhaps over a few reboot/restart cycles) of the OTBR AddOn and or Thread-USB-stick showing up.
Thanks to all for the help - I am sick of this … spent all of last few days trying to restore a stable thread experience
See my post that was moved to social (by a mod)
Matter/Thread is nothing but a big tech scam