thread-archived

[unborn jewel]

Is ther a way to use an esphome device as a thread border router?

[ionic plaza]

esp s3-h2 dev board

[spice imp]

I don’t think there are any guides 😅 the Google one I changed by resetting the hub, setting the matter credentials either the home assistant app and then setting it up again (or something like that).

[spring bramble]

No, but there are esp32 based options, like the mentioned esp s3-h2 dev board. It wont run esphome though.

[vapid shell]

I hope one day we can 😂 I guess there’s no need for a dedicated BR. But I do like the idea of borrowing its onboarding and firmware updating bits and pieces and having firmware that matches the HA otbr add-on in terms of features enabled etc.

[ionic plaza]

I am not sure if C6 would work, plan to get one to play with

oh I think it would. found this link from esp official github issue:https://github.com/espressif/esp-idf/tree/master/examples/openthread/ot_rcp

[inner torrent]

As others mentioned there's the s3-h2. I've got one and it's just kinda a set and forget so it's not a huge loss not having it in esphome somewhere

[subtle mica]

hi everybody, i very much enjoyed the matter youtube live session yesterday, but there is one thing i am still wondering:
can you use more than one skyconnect for the open thread border router, e.g. to have better coverage? ie can the open thread border router be installed seperately from home assistant in a different location and/or in multiple devices?

[spring bramble]

Our endgoal would be that yes. Fo rnow it is a DIY project if you want that. There are a few options available such as the development board from Espressif and GL-Inet has some products

More ideally is to have border routers on strategic locations in your house, that will perform better that one single skyconnect in your utility closet.

As you saw in the stream yesterday we currently advise google or apple BR's just for tyhe sake of simpliness and stability but if you want to get your hands dirty it is totally possible to create it yourself, we just do not yet provide the tools for it yet

[subtle mica]

thanks

[steady forge]

It's here and it's tiny! 😄
https://i.imgur.com/nDQcKBO.jpg

[sick swan]

You can just use a second HA installation which only plays BR... In the end if you buy a Apple/Google BR just for coverage, it is probably about the same (they are not based on microcontrollers and use a couple of watts just like a Pi or Yellow).

[subtle mica]

makes sense, thanks, falstaff321

[steady forge]

Love this little thing already, their WebUI is actually pretty nice

[spring bramble]

would a pi zero 2w work ?

[sick swan]

They don't have a USB Type-A plug, but I think their micro USB supports OTG

[spring bramble]

Yeah, I want to test one of those as well. Main issue I have with these is that there is not (yet?) a nice cover around it.

[steady forge]

they do come with rubber feet preinstalled, though 😄

[inner torrent]

I know you're in the EU so not sure if you can get the same item, but this is what I used. I just drilled holes for the USBC cable to go in and a few for ventilation

https://www.amazon.com/dp/B07S7RM4CT

[spring bramble]

haha yeah, that is how I also often solve issues like this 🙂
just get one of those boxes, some creative drilling and voila

[leaden ocean]

Hello,
I had a ZHA integration setup that was created right after plugging Skyconnect using the device discovery prompt. Then later on for unrelated reasons, I bought another Zigbee dongle(Sonoff Dongle P) and executed migration on my existing ZHA integration. I also renamed my ZHA integration from Skyconnect 1.0 to something else. This setup (if left alone) is currently working fine.

The problem happens when I want to repurpose my Skyconnect and create a thread border router setup with it. After flashing the Skyconnect with thread only firmware and plugging it in I notice my existing ZHA integration radio device immediately reverting back to Skyconnect, causing my Zigbee devices to fail. Even if I configure open border router integration and reconfigure ZHA integration to use my Sonoff, it keeps reverting to Skyconnect right after restart. However it works when I:

reconfigure my ZHA integration with Sonoff as the radio device and select keep existing network settings option.Until the next restart it works fine ZHA with Sonoff and Thread with Skyconnect
unplug my Skyconnect reconfigure ZHA one last time.
So to summarize I cannot plug both Sonoff and Skyconnect at the same time because my existing ZHA integration(originally created using Skyconnect) radio device setting reverts to Skyconnect. This is rather inconvenient for me because I would like to use my Skyconnect as a thread radio and keep using Sonoff for ZHA, even after restart without doing reconfiguration

Has anyone else experienced a similar issue? I would like to fix this hopefully without deleting my current ZHA integration.

[steady forge]

0.7W power consumption for the esp TBR board in a leading role

[upbeat cairn]

If your SkyConnect is running Thread firmware, ZHA shouldn't be able to communicate with it

How are you running Home Assistant OS? In a VM? Docker?

[young inlet]

How can I change the preferred border router to Apple? Right now it’s set to Eero.

[spring bramble]

from the HA companion app on ios

and than in that thread config panel

import the crdentials first and then set as default

[young inlet]

Thanks! Is there a way to combine thread networks? I have Apple, Google, Amazon, Eero, 2 different SmartThings networks.

[spring bramble]

No, not at this time, maybe in a year or so

[leaden ocean]

You are right it is not communicating hence causing ZHA to fail until I manually reconfigure radio device to Sonoff. I am running HAOS 11.4 core 2024.1.2

[upbeat cairn]

HA OS running on what system? Raspberry Pi? VM?

[leaden ocean]

Raspberry pi 4

[upbeat cairn]

Thanks! If possible, could you enable ZHA debug logging (https://www.home-assistant.io/integrations/zha/#debug-logging) the next time you do this and DM me a log once it reverts?

[honest jasper]

Is that the ESP TBR devkit?

[inner torrent]

Yes

[honest jasper]

Tempted to buy one to toy around

[inner torrent]

Just note the main board is wifi only, if you need Ethernet you need to also buy the Ethernet sub board

[honest jasper]

Any recommended place to buy?

[steady forge]

https://aliexpress.com/item/1005005802317569.html?spm=a2g0o.order_list.order_list_main.17.2b355c5fBC1STt&gatewayAdapt=glo2deu

I've bought from this seller, it was with me in Germany within a week 👍

[fresh nymph]

is multiprotocol usable on skyconnect? i do have some thread devices i want to add to HA

[spring bramble]

For now, better use the thread only firmware on skyconnect or a border router from another vendor such as apple or google

[fresh nymph]

i have homepods added to HA how do i use them for the border routers?

[spring bramble]

If you use the HA Companion app on iOS to do the commisisoning of matter devices, the homepods will automaticlaly be used as border routers.

[honest jasper]

Even if they aren’t part of the “preferred network” of the Thread component in HA

[spring bramble]

Yes, that is just for any HA border routers that you want to join the preferred network

[honest jasper]

I know, it was a remark because it is pretty confusing at first

[spring bramble]

Using the iOS companion app, the default crednetials of iOS will be used.

[spring bramble]

It is confusing. See our stream from yesterday why...

[fresh nymph]

where do i see this?

[honest jasper]

I know, I was there 😊

[spring bramble]

see what ?

[fresh nymph]

to setup the thread border routers or the devices? i am looking at the HA app on my iphone

[spring bramble]

you dont need to setup the border routers, apple already did that for you

you now just add matter devices to HA and you are done

no need to deal with border routers at all

[fresh nymph]

ok so what then settings / devices & services / devices / add device

[spring bramble]

exactly

[fresh nymph]

i have 12 border routers detected in the preferred network list

[spring bramble]

that should give you a good coverage around your house then - all apple ?

[fresh nymph]

home assistant / preferred network says nothing

me yes the family not so much 🙂 but yes prior to using HA i was pretty much all homekit

[spring bramble]

nah, you may ignore that for now. If you are browing that thread panel on your iphone you can actually make the MyHome network (apple) preferred if you want

import credentials

and then you can set it as default

so then it will also be used by google

and you can add other border routers to it

but you already have 12 so that is superb

just go add matter devices

[fresh nymph]

when i click import credentials i always get an error 74

i reset a thread plug and nothing comes up ..

[spring bramble]

OK, its not important. Try that again later. Again, you dont need it.

Just start adding matter devices - go to the matter channel for help if you are stuck.

You are sure you are trying to add Matter devices right ?

Or homekit over thread ?

[fresh nymph]

i guess its homekit over thread thats how i have always used it

[spring bramble]

ah ok!

For homekit devices, you first add them to apple home, then remove them there and they should be discovered by Home Assistant automatically. You will find them listed in the "devices & services page" as discovered device(s). Then you can enter the pairing code, I assume that works the same for thread based homekit devices as it does for wifi based homekit devices.

[fresh nymph]

I did try this added it to homekit successfully then removed it. when i tried to add it to HA just said it was already paired with another home and to reset it again

[steady forge]

Hmm while the HAOS OTBR detects the ULA in my network and stops advertising its own ULA, the esp border router doesn't and keeps sending RAs with its own fd62 prefix. Not cool.

[spring bramble]

OK, maybe @vapid shell has some clue what's going on here. That is how far my knowledge of Homekit goes tbh 🙂

[vapid shell]

Some devices are buggy and won’t cleanly unpair over thread.

For the Eve Thermos I had to turn all my border routers off and then use the Eve apps “Identify” feature to safely force a Bluetooth connection to start, then do the unpair from Apple Home.

Unfortunately Apple likes to hide certain failure modes, so from their end a failed remove is still a success. So you can’t tell this happened.

I was hoping that way of pairing was a thing of the past now we could import the Apple networks 😦

[fresh nymph]

@vapid shell any idea what error 74 means when trying import thread credentials?

[vapid shell]

no sorry, i just use the thread credentials that are imported, not involved in importing them

[carmine musk]

Hi guys. My SkyConnect had a multiprotocol update which is causing the ZHA integration to fail 1-2 hours after booting home assistant. Restarting temporarily fixes the issue. I received the multiprotocol update a few days ago but installed it today. Is anyone else experiencing the same issue?

[inner torrent]

@sick swan a suggestion for the ot br addon, maybe have the channel monitor run by default (or periodically) and throw a warning in the logs (similar to ZHA).

[sick swan]

Yeah we'd need an REST API to read the results from the Core. But sounds interesting ideaa 👍

[fickle mantle]

From what I read on a Thread Whitepaper, if the BR does not see a "suitable" PIO on its AIL, it generates one.

[spice imp]

What kind of warnings?

You get warnings when the otbr can’t send packages because there is too much traffic

[inner torrent]

High channel utilization warning

Would help with picking a thread channel

[spice imp]

Isn’t that kind of what you get already then

Also, idk how useful these warnings actually are. If the otbr is in one side of an house, it doesn’t say anything about the channel utilisation in the other end.

I’m not saying it should not be done, but I’m not sure how useful it is, especially if people follow it blindly.

[crimson sail]

has anyone been able to get a Thread EVE Room temprature sensor connected to HA?

Using Nest Hub 2nd as my thread border router

[vapid shell]

Yes. (Homekit, not matter, right?) Does your HA have a Bluetooth dongle? And is the Eve Room near the Bluetooth dongle and the nest hub? And is the nest hub set as the preferred thread network in Ha?

[upbeat fog]

Yeah I've been using one for awhile now. Using Homepods and AppleTV as Border Routers. I added it to Apple Home, then removed it (it stays on the thread network), then add to HA

[vapid shell]

You’ll not be able to use that method unless you have an AppleTV or HomePod and you’ve managed to get the nest to join that network first.

[crimson sail]

HA does not have Bluetooth dongle. Because it’s thread, I figured it wouldn’t need Bluetooth?

[vapid shell]

Thread devices (HomeKit or Matter) use bluetooth to get the thread connection details

[crimson sail]

Hmm. It shows up in Ha but when I go to configure it, it fails

[vapid shell]

got any logs?

[crimson sail]

I can try to grab once home. In about an hour. Haven’t set up the remote connection yet

[clear vector]

One message removed from a suspended account.

[serene prawn]

@crimson sail I converted your message into a file since it's above 15 lines :+1:

[crimson sail]

^please see log

[crimson sail]

i don't have the Apple TV border router. my border router is the Nest Hub 2nd gen. I do have a 1st gen Apple TV 4K which is used as my "Home Hub"

[steady forge]

The OTBR addon behaves exactly like this, ESP acknowledges my ULA as suitable PIO aswell and also puts this in its logs but still advertises its own. It's just a cosmetic thing really with how IPv6 works.

[vapid shell]

Your device is connected to thread but HA can’t establish an ipv6 coap connection, its timing out.

It could be your network setup, or it could be your thread signal strength

If you look in your integrations page, find thread, then click on configure, I think you’ll see a list of all the border routers on your network. I’d like to see a screenshot of that. Then from that same page there will be a … type drop down menu offering a diagnostic download. I need that too.

[crimson sail]

on the main thread page, it looks like this: https://imgur.com/a/m41nIbB

once i click Configure, it looks like this: https://imgur.com/a/cTEIQ6C

diagnostic download: https://drive.google.com/file/d/1STI8GRHLIeNu0b7HPdf5eE_dHTYVBhDr/view?usp=sharing

[vapid shell]

Do you have any vlans?

That diagnostic link doesn’t work for me

[crimson sail]

no

[crimson sail]

try this please: https://drive.google.com/file/d/1STI8GRHLIeNu0b7HPdf5eE_dHTYVBhDr/view?usp=sharing

[vapid shell]

Ok the network looks fine

What’s the distance between the eve room and the nest?

Any walls or ceilings between them?

[crimson sail]

yes 1 floor apart

[vapid shell]

Can you put it right next to the nest and try and pair again?

[crimson sail]

let me try. will use the HA mobile app

brb

[crimson sail]

Same error. Even tried to restart the nest 😦

[vapid shell]

Shrug. That device should work but we don’t have enough visibility into what’s going on here.

[crimson sail]

One thing and not sure else to resolve is that I have to connect to apple Home first - disconnect from home and then auto discovers in HA

@vapid shell sent you a DM of the image from the EVE app

Where it shows it’s connecting via thread

[steady forge]

There's currently no way for an echo thread border router to join my existing thread network, right?

[crimson sail]

Not now but it’s supposed to get fixed eventually: https://www.theverge.com/2024/1/8/24028203/thread-group-fix-credential-sharing-thread-border-router

[steady forge]

Supposed to, eventually. Got it 🫠😅

[steady forge]

And making my OTBRs join the echo network is not possible because I can't get the credentials, huh

[inner torrent]

You can use a third party app. Eve maybe? I know if you have a nanoleaf bulb you can see the creds

[steady forge]

I do have an eve device but their app only works with apple border routers

Maybe I can use an esp32-H2 to extract credentials

Or nanoleaf bulb but from what I've heard I better stay clear of those

[inner torrent]

One bulb is fine especially if you're just using it to extract credentials

You can't use the 32-H2 as you need the network key to join a thread network, which you don't have

[mellow night]

Trying to add my Nanoleaf lightbulb to Alexa, it's asking for HA's Thread network key. Where can I find this?

[inner torrent]

Settings, integration, thread, configure, press the little (i) symbol

Oh I just noticed that doesn't have the network key

[mellow night]

Yes it does not

[inner torrent]

Only other way I know is to ssh into the addon container and do it that way

[steady forge]

whoops I've almost ordered one

I'm toying around with espressif's ESP32-H2 docs right now. Having just 2MB of flash on the h2 of my border router pcb is not helping

[still quiver]

https://appleinsider.com/articles/24/01/10/thread-border-router-fix-should-improve-smart-home-networking

[vast sierra]

Oofff.... Now the shades I've had paired for months have stopped responding to HA. Remote works, so its not battery.

Matter/thread via SkyConnect. Wild how it was fine and have taken a nose dive the last few weeks.

[worldly portal]

are these issues with otbr causing network instability being tracked somewhere?

[spring bramble]

Not yet, we should create a meta issue for it. @sick swan where should we create this issue ?
We now have a few observations (myself included) that adding the OTBR as Border router for an existing Thread network causes instability. This is at least true for an Apple network, I'm not sure about others or standalone operation.

[inner torrent]

FWIW I've got 2 OTBR (including skyconnect) and haven't had issues. Primarily Google BRs

Wonder if it's TREL related since that was activated recently and apple is the only other one using it so far?

Edit: I'm also having increased resubscription

[worldly portal]

my scenario is apple devices (3 atv, 5 home pods), and two home assistant yellow running the latest otbr addon joined to the apple network

[modern root]

I started my thread network with OBTR and skyconnect (with only matter/thread no zigbee/dual proto) and then added just a nest hub and stability is fine even with mostly nanoleaf devices

I did order an espressif thread router device just to expand coverage, I would like to not be relying on the nest hub if I can avoid it

[random garden]

seems like it's not just Apple (though mine is a niche case probably). I have a GL-S20 (https://www.gl-inet.com/products/gl-s20/) which is OTBR based with Google Hubs as TBRs. Removed that from the network and the ~10 Nanoleaf Matter lights that were constantly resubscribing went stable.

Inb4 my previously reported network issues being the problem, have swapped to non-Unifi hardware (TPLink Omada) and has been running fine since.

[inner torrent]

Actually I'm also seeing an increase in subscriptions as well -- they were hidden in the actual device stats but listed in the server logs

Seems the problem for me isn't restricted to any particular device manufacturer (nanoleaf, Yale, aqara all having trouble)

[random garden]

mine seems limited to Nanoleaf (at least the 2x Aqara P2 sensors I have are not resubbing every few minutes - last time they were unavailable was 3 days ago). Nanoleaf has been in a resub fight with itself every few minutes, then goes stable for a time, then falls out again. This is with 4 Nest Hub 2s spread throughout the house also.

[inner torrent]

Do you have a skyconnect also or just the glinet

[worldly portal]

it would probably matter how the devices route too - if you have a problematic device routing a stable device, they will both look unstable, right?

[random garden]

I have 2x skyconnects, but 1x is unplugged and the other is just Zigbee only

[inner torrent]

And you still had trouble without the skyconnect?

[random garden]

yep

[inner torrent]

🤔

[random garden]

I have a GL-S200 though but that doesn't appear to be based to be OTBR? (at least Home Assistant does not identify it as such)

https://www.gl-inet.com/products/gl-s200/

[inner torrent]

I've got the glinet chip (espS3-H2) and have the instability also but I've not flashes a new firmware so I'm not sure where this is coming from all the sudden

[inner torrent]

I'm like 90% sure that's still OTBR -- at least a quick search of thread on OpenWRT returns some OTBR results

[autumn merlin]

Hi There, is there any reason to make my apple thread network the preferred one? At the moment i have an HA network and an apple network, it looks like HA is currently the preferred.

Skyconnect with multi protocol FYI/

[worldly portal]

the discussion above is about the network becoming unstable when you add the ha otbr into the apple network

so you may not want to do that

[autumn merlin]

OK - i think i will leave it as it is then 🙂

[random garden]

it's definitely OpenWRT based, but doesn't identify specifically that it is (the GL-S20 ID'd as gl-s20-otbr in the Thread integration, the GL-S200 just ID's as gl-s200.local)

and oddly enough, can be used with Android*+ iOS credentials? (the last I knew only Google and Apple TBRs could do that).

[worldly portal]

are there other options even?

[inner torrent]

I wouldn't put too much stock into that -- probably just listed that as the mDNS name

[inner torrent]

Yeah you can in the underlying chipset, you can have whatever you want.

It's probably also in the OTBR config somewhere

[random garden]

that's just it, there is no OTBR manual config. You have the option to create a TBR or join an existing. I joined the existing TBR from home-assistant and it just appeared. Even the backend for OpenWRT doesn't have any OTBR config to change.

[worldly portal]

is trel configurable? i could try turning that off?

[inner torrent]

https://openthread.io/reference/cli/commands#trel_enabledisable

Could try that ?

[random garden]

🤣 I just rebooted the GL-S200 and it broke my entire Thread network (all the Matter lights went to unavailable). Seems to be doing more than the Google Hubs.

I'd be tempted to buy another S200 for testing, but they are over $100AU... sadly the Google Hubs are cheaper :\

[inner torrent]

You can just get the s3-h2 from espressif

It's $10

Well $15 If you need ethernet

In my case I don't think TREL is doing anything since it has no peers

[random garden]

just dug through the config for the S200, and you are correct it is an OTBR:

ot-br-posix/2023-10-27-r4.3.1; POSIX;
SL-OPENTHREAD/2.3.1.0_GitHub-e6df00dd6_v12; EFR32;```

[worldly portal]

where do you see info about peers? web ui?

i haven’t really dug into this stuff yet

[tacit dirge]

Is the OTBR addon unstable now?

[inner torrent]

You can ssh into the otbr container and access the commands using ot-ctl

[zinc isle]

FWIW I've seen the inverse be true. I've had a thread network using skyconnect with OTBR running pretty smoothly with an Eve energy plug, Aqara P2, and 4 Nanoleaf bulbs. As soon as I plug in a Google border router (Nest Hub 2nd Gen / Nest Hub Max) then all of those devices either stop responding completely or very intermittently so it seems like there's some sort of incompatibility between things

[random garden]

it's odd... I've just tried doing the same (remove OTBRs, go Google Hub only) and the Matter logs are now throwing intermittent mDNS issues (I know 1000% that mDNS is working fine, and my routers DNS log also shows the same). Only 5 of the 12 lights in HA are reachable with just the Hubs (4 hubs total, spread throughout the house).

am curious though; since pulling the OTBRs, my ULA addresses for the Nanoleaf lights have changed and I now have 3 different subnets. Will multiple ULAs cause problems?

[steady forge]

Do you have a ULA prefix advertised by your router?

[random garden]

I want to say yes, but I don't see it specifically. The router (OPNSense) has v6 configured (track WANv6 interface). I am seeing the ULA addresses from Unraid (HAOS is in a VM) which seem to be flowing to the Thread/Matter integrations in HAOS as the Matter logs are showing the same UDP ULA traffic repeatedly (ping/resubscribe etc).

I've just gone through a staggered reboot of the GHubs and the ULA address has changed once again (now have 5 subnets) :\ The Nanoleaf lights are all reachable, so I'm assuming something isn't expiring the old ULA routes and just adds additional.

[steady forge]

I also use OPNsense, by default it generally does not provide a ULA

You need to go to Interfaces -> Virtual IP -> Settings and configure a IPV6 for your LAN interface there as IP Alias

https://pic.xpl.link/-QNd7ExpcUr/pasted-2024-01-15T091144.046Z.png

then the RA-Daemon will automatically advertise this prefix throughout your network as ULA

the OTBR HAOS Addon sees that there's a ULA and won't advertise its own, same with Amazon Border Routers (and I guess others aswell apart from the ESP one)

that way your ULA stays the same even if a border router goes offline and you won't have to wait for updated routes

[sick swan]

The OTBR is an official add-on so issues related to it should go here: https://github.com/home-assistant/addons/issues

FWIW, I have had issues here too when combining Google Nest 2nd Gen + SkyConnect/OTBR. At first sight it looks to me like an SRP issue. I'll need to spend more time to better understand what the problem is. It doesn't fail immeaditly, so it is a bit painfull to debug.

[sick swan]

Interesting observation, thanks for sharing. "Removed that" what does that refer to here?

[random garden]

Oh, the GL-S20. Sorry.

that = anything OTBR related

I'm also finding that more GHubs does not always equal better, either (which is odd, as I would have thought that the hubs would have worked together). Having all 4 GHubs up caused most of the lights to bounce from available to not every ~10 minutes or so. Reducing to 2 has been stable for the last 2 hours. Early days, but could just be my house topology 🤷

[sick swan]

From what I know, everything is OTBR based. It is BSD licensed, so integrators can fork and adjust it to their platform. So it is mainly a question how far did integrator X went with the integration work for their products. I expect that Apple and Google have forks of the OTBR with quite some adjustments for their needs.

[sick swan]

That is interesting. I wonder if the RF link between two of those were weak, and got selected as main TBR. Since Google BRs don't have TREL yet, you are more reliant on a stable RF link.

[random garden]

I suppose that is possible, though how far would the RF link extend to? The two GHubs that are stable are at polar opposite ends of the house (a good 25m or more).

[sick swan]

Yeah I think @spring bramble wording is bad here. It is the combination which seems to cause issues. As in OTBR alone works reliable, Apple BRs alone work reliable. The combination not so much. It is not clear who is at fault 😅

[sick swan]

I mean BRs can be on the opposite end no problem, as long as there are Thread routers (FTD/full Thread devices) inbetween (typically mains powered devices).

[random garden]

ah, of course... forgot that little detail. my bad.

[sick swan]

If you had the same Thread setup otherwise (same amount of border routers/locations), it kinda sounds more like a software issue.

[spice imp]

It looks like mine does not want to come online anymore right now 😦

https://github.com/home-assistant/addons/issues/3402 I think my logs look similar to this, ill check when i get home.

[steady forge]

Has anyone played with one of the esp-matter examples? I'm trying to get the active dataset extracted by using the matter console but no luck so far

[random garden]

aaaaaaand after about 9 hours of solid stability, all 15 A19 bulbs in the Matter Integration went offline, for no apparent reason. Only 4 have recovered and the others have gone to Narnia. sigh. Tomorrow problem.

[sick swan]

Are those the ones from Espressif themself? I've built the ESP32 examples from the upstream project-chip repo.

But not the Thread ones

[sick swan]

What BR setup are you running right now?

[random garden]

just the two GHs. No OTBRs

[sick swan]

I'd blame Nanoleaf 😄

[inner torrent]

15 is a lot of bulbs

[twin vine]

i mean, thats like the most optimal setup you could have and they still fail spectacularly 🙃

[random garden]

yeah, am blaming Nanoleaf on a lot of fronts (like, can't log into their cloud system with an account that was just created because of 'invalid creds' (ticket with them for that), as am wanting to try the betas.

15 isn't a lot, considering I had 35 going at one point (once I swapped away from Ubiquiti to TPLink for mDNS issues). Only reason that is no longer the case is I moved house 🙃

[twin vine]

oh, no doubt about it, 15 isnt much at all. just that anything over 12 seems to break and go to shit

[inner torrent]

15 is a lot for how stable the nanoleaf firmware is

[random garden]

yeah... doesn't help that I also bought 4 GU10s recently because something something downlights. 🤷 they're not even in the mix yet, lmao

[twin vine]

i mean, the downlights were just released and shipped in australia, over 6 months after its international release date....

[random garden]

I just figure the delay is because we're gurt by sea, so add 6 months to row the boats across.

[twin vine]

nanoleaf as a whole is a shitshow, im kinda shocked how quiet they are on it all, especially when you see the reddit about all the people returning them due to most of the crashes

[inner torrent]

They say they're confident they can get things stable but who knows

Next week or two should be telling as they won't have any more excuses about CES or holidays to not be releasing better firmwares

[random garden]

can only hope.

[fresh nymph]

When adding a thread device getting invalid flow specified. Any idea what this is?

It’s a HomeKit device that I added and then removed. It shows up in HA auto discover but can’t be added

[steady forge]

do they incorporate both ot-cli and matter console?

[sick swan]

The WiFi devices have the matter console only. Not sure about the examples for Thread based devices.

[steady forge]

looks like they only have the matter console aswell

I have a flash dump of the nvs partition where the data is stored but can't make sense of it (I've disabled encryption on partition table but maybe it's still encrypted)

[digital salmon]

I doubt that there devs all were present t CES…

[inner torrent]

Yes but they stated they had some rush items related to CES -- idk they don't explain their schedules to me lol

[vapid shell]

An invalid flow means that the ui was showing something as discovered that isn’t still discoverable.

[spice imp]

are you sure you cant compile it with the ot-cli enabled? Thats what i have done with nrf's boards at least

[steady forge]

if I compile with ot-cli enabled it doesn't make a difference, the matter console takes over

https://github.com/espressif/esp-matter/issues/488

problem is with just ot-cli I can't commission it and with matter I can't check the dataset, I've tried to send .host_config to the ESP log but it fails (I'm no programmer)

[fresh nymph]

So when i add it to apple home. I remove it, the device comes up immediately on HA. but then when i try to configure it and it accepts to the code i get "the device is already paired to another device. Please reset the accessory and try again"

[vapid shell]

It’s still #thread-archived message

When Apple fails to unpair cleanly it pretends everything is ok

[fresh nymph]

is that atleast the proper process?

[vapid shell]

It’s a process that worked for me and others with several nanoleaf and eve devices (with HomePods)

As HomeKit over thread was largely reverse engineered I won’t call it the “proper” process

[fresh nymph]

this is a wemo plug. and border routers i have plenty just none set as a preferred network for thread. still cant figure that out

ah well not a big deal. I can always replace these plugs with aqara zigbee plugs.

thanks anyway

[vapid shell]

I use eve energy myself, homekit over Bluetooth until nanoleaf fix their shit and I consider running thread in production again

[tacit dirge]

Since you use eve. Is it feasible to use them without an iPhone?

I've got my wife's old one lying around. I could theoretically make an iCloud account for but that's kind of a pain

If I just needed to do it like once for set up and firmware that would be ok but if I have to keep it around and use it continuously that would be annoying

[spice imp]

https://pastebin.com/PYvh08bL

Here are my logs

[half marlin]

anyone also have problems with eve motion? i have one in my corridor abd my automation resets the motionlgiht every 1 minute to stay on when there is movement. but my motion sensor doesnt pick up motion if i stay in the room and move. i have to leave the room to dected moviment again.

[steady forge]

The matter ones you can use without an iPhone

Their app only works with iOS and apple border routers though

[tacit dirge]

So can't use thread with obr?

[vapid shell]

You don’t need an iCloud account to use eve homekit stuff with HA. It’s all local first. One of their selling points.

[vapid shell]

I have been using eve stuff with ha for years - first via an eve extend hub, then directly via ha Bluetooth, and then ha with homekit thread and then next via matter. My eve smoke is still connected to Ha via that eve extend 😅

The eve extend is the only method that needs an iPhone, and then only to set it up. But with all the other approaches you can do it without an app.

The eve homekit stuff was tested with a ha yellow

[fickle mantle]

Yeah I was disappointed finding that out.

[tacit dirge]

Okay, that's good to know. I hate the apple ecosystem but wifey loves it so I'm adjacent at all times. I was looking at some of their motion detectors to fix our garage lighting.

I'm also debating the presence sensor since I could maybe use it to see if garage doors are open too.

Would have to play around with it a bit

[merry bison]

Anyone know of a list of non-proprietary, mater compatible, thread border routers? Ethernet is preferred, but I'm not sure such a thing exists. 2nd choice is WiFi.

[honest jasper]

No, but I know the ESP OTR devkit have a ethernet option if that can be an option for you

[steady forge]

I've opened a issue in esp-matter's github repo asking if it would be possible to dump the thread dataset. Let's see if something comes out of it. Would be neat to have a little "thread credential extractor" that's easily adoptable via matter.

If Amazon doesn't join my network I could at least join its. If you can't beat them, join them 😄

[vapid shell]

Isn’t that what the 2 HA BR options are?

Also see https://openthread.io/guides/border-router/build

[steady forge]

and this one https://www.aliexpress.com/item/1005005802317569.html?spm=a2g0o.order_list.order_list_main.23.5d971802urSqTf

[steady forge]

Someone at esp-matter github answered my issue and gave me some code to print the dataset to uart console during commissioning.

I'll test it tonight, no proprietary thread network will be safe from this little device 😂

[merry bison]

Thank you!

[sick swan]

I wonder if the Espressif OTBR build support the latest REST API 🤔

Then we could contnrol that OTBR also from HA side.

[steady forge]

"The ESP Thread Border Router server provides the REST APIs that are compatible with ot-br-posix"

https://docs.espressif.com/projects/esp-thread-br/en/latest/codelab/web-gui.html#thread-rest-apis

I've just tried adding it to HA's OTBR integration and it works

https://pic.xpl.link/-DackWJgxac/pasted-2024-01-16T125547.881Z.png

[sick swan]

Nice!

Yeah they updated that then. I remember looking at early version ~6 months back, and that one did not support the network creation yet

Do they expose a vendor? then we can add a nice logo there too 😅

I think the logo is based on vn txt property pushed via it's _meshcop._udp service annoucment. Can you check what it reports?

@brisk ridge we really need the multi-instance going for OTBR 🥺

[steady forge]

@sick swan not at home right now so I can only give you an avahi-browse output https://dpaste.com/8TJ3AF6UZ#wrap

seems very vanilla

[sick swan]

Just OpenThread, yeah... I guess we could add that as a logo 🤷‍♂️

[steady forge]

sure why not, just the "OT" icon from the OTBR integration should be enough and it's already there

[vapid shell]

Can we… get some sort of auth for this API

[steady forge]

It shouldn't be exposed in production so you'd think auth is very low in priority for OpenThread

[vapid shell]

Hopefully nothing production exposes it, but if we are talking about having ha support managing multiple OTBRs with that api then we will have to

[sick swan]

REST API is kinda stale from upstream OTBR side. Most recent changes were initiated by us
https://github.com/openthread/ot-br-posix/commits/main/src/rest

Afaik, Google uses the local D-Bus API exclusively. I assume they have some proprietary daemon which then talks to their cloud etc. on their Nest hubs.

Not sure what Apple uses, I am guessing they integrate with the OTBR directly using the C++ API.

[sick swan]

For the add-on which is only exposing the API in the internal hassio network the unnencrypted http REST API is okish. But yeah, authentication and encryption would be nice.

[brisk ridge]

OK!

[merry bison]

Would a SkyConnect flashed with Thread-only firmware work for this? I have one, but have major issues connecting it to my HA instance via Proxmox USB forwarding. I've tried it with both the official HAOS image, and as a container on a homemade docker box. I also couldn't flash the darned thing on Windows 11 using usb passthrough - I had to connect directly to my laptop.

Also, what is the minimum hardware version of Raspberry Pi required? I don't see that listed anywhere.

[vapid shell]

you'd have to ask them that, its not our project

[merry bison]

D'oh! Sorry, I didn't mean to direct that directly at Jc2k.

Was trying to reference the message.

[vapid shell]

pretty sure that would work; there are people doing similar (if not the same). worst case, run HAOS on a pi and just use it as a BR and ignore the 2nd HA instance 😆

actually, thats not a bad plan for getting OTBR updates and firmware updates deployed easily

[merry bison]

I'm not clear as to what constitutes an RCP in that document.

Ok.

[vapid shell]

https://openthread.io/platforms/co-processor

[merry bison]

I meant what specific devices. You already answered that my SkyConnect should work while I was busy typing...

Or, is that not what is meant by an RCP?

Anyhow, I'm probably asking my questions wrong.

My main question was can I use a SkyConnect with a Pi to make an OTBR. I believe this was answered.

Gunna probably try it a bit later.

[vapid shell]

yes

when you use HAOS, you'd install the openthread_border_router addon

(instead of multiprotocol)

when you do that, it uses the same spinel+hdlc+uart:// protocol as the guide i posted

if you want to go the super DIY route

[merry bison]

Probably not going to use full-blown HAOS, but I'll fall back to that as "plan b".

[steady forge]

> dataset active

Channel: 11
Ext PAN ID: b74000d16d711111
Network Key: 597503a6b32b0b784183privacy
Network Name: AMZN-Thread-cea8
PAN ID: 0xcea8

Hell yeah! I've been able to dump the Amazon Thread Network TLV using a esp32-c6 with esp-matter's light example! 🙂

[fickle mantle]

Cool! How?

[steady forge]

Mesh Local Prefix: fdde:ad00:beef:0::/64

Amazon is actually using the deadbeef local prefix for their echo border routers 👀

[steady forge]

With help from a very nice guy working on esp-matter
https://github.com/espressif/esp-matter/issues/798

[sick swan]

@steady forge you might know it but you can use dataset active -x to show the TLV representation

That one you can import into the Thread credentials store in HA Core 😅

[steady forge]

no need as I've extracted the credentials as ready-to-go hex TLV from the light example already but good to know!

[sick swan]

So did you had to do anything on Amazon side to pair the device? Register it as a dev device? 🤔

[steady forge]

No they're happy with the esp-matter example and don't even show a notification about adding an uncertified device. Vendor shows "TEST-VENDOR"

https://pic.xpl.link/-2HjWqkkA7W/IMG_4355.png

[steady forge]

Once I've joined the Amazon Thread network with my ESP border router it reformed as "OpenThread-c837"... weird

[inner torrent]

How did you join it?

Mine retained it's identity joining the Google network

[steady forge]

ESP WebUI

The Amazon network just renamed itself, it's still the same PAN ID and Network Key and the Echo device is still leader

let's see if the Alexa app gets confused now and asks for a Network key for its own network

holy crap it does! It doesn't even find its own network anymore. That's crazy

on second try it finds the network and asks for a network key lol it's the wild west right now

[elder dune]

mDNS issues?

[steady forge]

I don't think so it showed up on mDNS all the time

Guess it's just confused about not finding its own network anymore

gladly I've had their network key extracted - I've got your back, Amazon! Don't worry

[undone kelp]

It required factory reset and buying an Android phone (my main is an iphone), but I’ve managed to get all my nest smart screens, Nanoleaf panels, AppleTV, and Yellow (thread firmware) on the same Thread network, as reported by the thread integration. I don’t know how stable that’s going to be and I’ll be doing testing with my Eve thread devices.

[elder dune]

I am going to have to borrow an Android phone 🤣

[rough lily]

Does anyone know if it is possible to open a Thread Network using the nRF52840 USB Dongle? This DOCS page says yes: https://github.com/home-assistant/addons/blob/master/openthread_border_router/DOCS.md
but the description seems to be old or wrong because the Add-On exist but it does not let me choose a Dongle or anything, it only asks for a REST API which I am not sure how t oactivate or if that is even a thing with the default Open Thread Border Router.
I actually can see my Thread networks in this Add-On section but it does not let me choose it or whatever

[sick swan]

If used the dongle in the past as OT-RCP device. This should still work.

[rough lily]

do you remember the steps you had to do?

have you been using the HA OS or the Docker variant? (I am running the docker version currently)

[undone kelp]

You will probably need to build and flash OT-RCP yourself, then run the OTBR container with the dongle passed into the container, then finally add the OTBR integration in HA and connect it to the OTBR container.

[past charm]

Is there a way to view which firmware version I have flashed to my Zbdongle-E through HA? I have Thread RCP firmware flashed but can’t remember what version

[inner torrent]

It's in the logs at boot

[steady forge]

https://darkxst.github.io/silabs-firmware-builder/ the webflasher shows you the current installed version after connecting

[modern root]

I got my ESP-Thread-BR device to play with, but how do I get the network key/PSKd from the openThread border router in HA. I've tried what HA calls the Dataset ID and the Network Key in the join request, but I think I also need the PSKd which I cant seem to figure out where I can look that up

Every time I try to make a Join request on the thread-br it just gives me "Invalid Network Key"

https://github.com/zephyrproject-rtos/zephyr/issues/64536#issuecomment-1785460650 I think I managed to follow after starting the commision code on HA OTBR and it worked

[steady forge]

did you add the HA Open Thread Border Router as an integration?

Now I know why my ESP crashes the Amazon Thread network, reforms and confuses it when joining via WebUI

E (25867) web_api: get_openthread_network_properties(362): Network name is too long

it completely crashes the WebUI just because it deems "AMZN-Thread-cea8" as too long a network name (maybe it even is against spec?)

at least it works when joining via setting the dataset in CLI

[modern root]

Yeah thats all setup and fine, i was trying to join a new ESP-Thread-BR device to the existing network

but it seems to be working now at least, just wanted to expand my network since I have some smart lights on dumb switches that arent always online to mesh

[steady forge]

you can use the button in Integrations -> Thread -> Configure on your corresponding network to get the TLV dataset https://pic.xpl.link/-K4YJL6quWf/pasted-2024-01-17T185405.704Z.png

[modern root]

yeah but I just couldnt find where to put that TLV on the esp-thread-br interfaces'

the scan network/join rejected it in the fields it have available, but joining via the CLI after settting commission code in the HA OTBR worked so 🤷 it wasnt that painful

[steady forge]

on the ESP border router you could then just set this dataset via CLI

thread stop
dataset set active 11122233445....
dataset commit active
netif start
thread start

then via 'dataset active' you can print and note the network key for easier joining in the future via webUI

[modern root]

now I can just dream of someone adding support to ESPHome for these things

[inner torrent]

I mean if you have the network key you can just join through the web UI

Idk why the thread integration doesn't share it

[inner torrent]

One problem which I found out today is if you have the wifi version of the esp BR it will not auto reconnect if it drops and requires a reboot

Drops from wifi*

[modern root]

yeah, I got the ethernet addon just to avoid interference

[inner torrent]

Well they have some coexistence feature for wifi and thread but in my case it was an AP update

[steady forge]

oh wow that sucks

[brisk ridge]

As an initial step, the OTBR websocket API needs to be updated. My suggestion is:
"type": "otbr/info" - Let this return a list of maps, instead of a single map, each list item describes a managed OTBR. The list can be empty.
"type": "otbr/create_network" - New required parameter border_agent_id to specify which managed OTBR the network should be created on. The border_agent_id can be found in the list returned by "type": "otbr/info"
"type": "otbr/set_network" - New required parameter border_agent_id to specify which managed OTBR the network should be set on. The border_agent_id can be found in the list returned by "type": "otbr/info"
"type": "otbr/set_network" - New required parameter border_agent_id to specify which managed OTBR the channel should be set on. The border_agent_id can be found in the list returned by "type": "otbr/info"

[sick swan]

I kinda like using border agennt id. Just older OTBRs don't have border agent ids, so we kinda would exclude/not support those then 🤔

Hm, looks like the ESP32 implementation does't have it yet 😢
https://docs.espressif.com/projects/esp-thread-br/en/latest/codelab/web-gui.html#thread-rest-apis

@steady forge can you check your instance eif this is indeed true or just stale docs?

essentially navigate to http://<ip-of-your-esp-br>:<port>/node and check if you se BaId there

[vapid shell]

How unique is BaId? Like it’s unique within a network, but is it unique if the BR is in a different network?

[brisk ridge]

There's no reason we should allow managing whatever, let's require the border agent ID.

I thought this was primarily about allowing multiple OTBR hassio add-ons, do we want to "adopt" other OTBRs too? I guess that's fine, but we then need some config flow for that, I don't think we have that?

[brisk ridge]

I think it's supposed to be unique unique. The open source implementation we use at least ensures that, doesn't it @sick swan ?

[sick swan]

Don't remember the length, but some random identifier https://github.com/openthread/openthread/blob/f75e2bb567bd4cbe7a0c8f79979e06ebaf0e4c1e/src/core/meshcop/border_agent.cpp#L247-L269

[steady forge]

Guten Morgen @sick swan
Here's the output. No BaId.
https://paste.xpl.link/upload/ape-dog-pony

[sick swan]

It is long enough so we can consider it unique 803445265B5E6D969B038A8420E59BFF

[brisk ridge]

OK, we then have to exclude ESP32 routers for now. The border agent id is required by Apple + Google, IIRC so they'll have to add it no matter what?

[sick swan]

Yeah, their API requires it... I mean if we support ESP32 without BAID, you could still add the netework if you have a OTRB add-on BR on the same network. You can just use it's border agent id...

It shouldn't be a huge deal to add to ESP32...

However, it is a compile time config upstream (behind the OPENTHREAD_CONFIG_BORDER_AGENT_ID_ENABLE).
https://github.com/openthread/openthread/blob/f75e2bb567bd4cbe7a0c8f79979e06ebaf0e4c1e/src/core/meshcop/border_agent.cpp#L247-L269

So if we require it in our API, we essentially say we support only BRs which have it enabled 🤔

@brisk ridge do we have alternative identifiers we could use in the API? 🤔

[brisk ridge]

We already use and require the border agent ID in other places, let's not add another identifier

[brisk ridge]

So users can enable that flag and recompile then? Or is there some ESP-specific distribution or variant of OTBR?

[sick swan]

Yeah the ESP distribution is a forked version afaik. But they can (and did) resync in the past with upstream. So it will eventually be supported there.

If we don't have another/internal identifier available, I am fine using border agent id.

[brisk ridge]

We don't, without border agent ID we can't reliably match mDNS data with routers we know about, this complicates everything a great deal IMHO

Initial PR changing the WS API: https://github.com/home-assistant/core/pull/108282

Now, what about HassOS discovery?

HassOS limits to a single instance of an add-on, correct? But we have separate add-ons for multiprotocol and otbr, both of which provide otbr?

There's currently some code here to handle the situation where both the otbr and multiprotocol add-ons are installed: https://github.com/home-assistant/core/blob/a5b933de21bd3c64e08833f837a6b2b7f335acc8/homeassistant/components/otbr/config_flow.py#L127-L168
That should be updated to allow multiple config entries, but we want to deduplicate on the hassio slug I think?

[sick swan]

Yes, only single instance is allowed. TBH, it is probably also not very useful to have two OTBR running on the same device. You want to spread out your BRs..

What this multi-instance enables us is to have a second HA installation on and old Rpi or so, install OTBR there and expose the REST API. Then we can control both OTBRs from the same HA instance. And ultimately, it enables single purpose BRs like the ESP32 one...

[sick swan]

Yes, I'd say so. Let us just deduplicate on the slug.

The Multiprotocol uninstall should trigger a "discovery remove" event, and delete the OTBR config entry, if I am not misstaken? 🤔

[rough lily]

I already flashed a nRF52840 Dongle with the RCP Firmware, do I need a special firmware? Somehow the Open Thread Border Router integration only always akss for a REST API which I don't know what that should oint to?!
Also I tested with a friends setup yesterday and he has some kind of options and settings for baudrate, device and so on but I don't and I can not figure out what the difference might be!? Only difference is that he has a SkyConnect connected and I don'T

[brisk ridge]

Yes, that's right

[steady forge]

just recompiling with the flag set in sdkconfig doesn't work

maybe it does but /node won't show it because it wasn't implemented I guess

[sick swan]

The OT RCP firmware has a firmware API level, but I think OTBR supports a quite wide range. Just try it 😅

You'll have to install the OTBR add-on. The OTBR integration then talks to the add-on. Typically the integration will be discovered automatically once you've installed the add-on.

[steady forge]

I've switched to esp-idf:main and espressif/openthread:master to compile the most recent version, my version API is now up to 389. Had to disable WPA3 in menuconfig though because it wouldn't compile otherwise

[sick swan]

@steady forge looking at their code the BaId is really missing: https://github.com/espressif/esp-thread-br/blob/ec65dc8a17a6a4a0006871d3c5a7d5ba43801486/components/esp_ot_br_server/src/esp_br_web_api.c#L922

Probably best to open a issue and ask for Border Agent ID support along with REST API update

[rough lily]

there is no addon or I can not find it, whats it called?

[sick swan]

"OpenThread Border Router"

You might need to enable "Advanced" mode in the user profile.

[steady forge]

https://github.com/espressif/esp-thread-br/blob/ec65dc8a17a6a4a0006871d3c5a7d5ba43801486/components/esp_ot_br_server/src/openapi.yaml look at that it's actually implemented

/node/ba-id
returns "f5dc678cafd6a2e16fcaebca1d2c540f"

[rough lily]

omg.. thanks, thats it, I was not running in advanced mode!

[sick swan]

Ah I see. They missed adding it to the node return then

I think we rely on the explicit API, so I think we should be fine

https://github.com/home-assistant-libs/python-otbr-api/blob/main/python_otbr_api/__init__.py#L57

[rough lily]

damn.. once this is there it is really easy! Do you know a different way of commission a device into the network? I enabled the WebGUI and used the commission tab there, which works fine but is there a different way of doing that? Like an App or so from Home Assistant?

[sick swan]

For Matter devices the supported way to commission device is throught he Apps yes. Android or iOS compagnion app. What device do you try to add?

[rough lily]

I have my own DIY device which is not doing Matter but Thread: https://www.tindie.com/products/informatic0re/thread-sensor-tag
It only sends UDP pakets (Matter is to resource heavy and takes longer to be send which draws more battery, thats why we do UDP). The commission can be done by simply use the Thread Commission for example using the WebGUI (works perfectly fine). I was just wondering if there is more.
But I also have problems now to receive the UDP pakets within the host network. I think the container is blocking them 🥲
I want to create an AddOn to automatically translate the UDP Pakets into "meaningfull" MQTT Messages like the MQTT Device Discovery messages from Home Assistant.

With all together someone can setup the Thread Border Router with a nRF52840 using Home Assistant, install the plugin, commision the device and it will automatically appear in HA. Thats the goal.. but it seems a bit tricky due to the containerisations right now. The AddOn is running but it does not receive the UDP pakets. I had the same issue with running the OTBR in a docker container an a plain RPi.

[tough prairie]

I am trying to find a way to debug why an Eve energy plug which I have connected to my Skyconnect is not available roughly once per day for a few hours. I see error messages like "mDNSPlatformSendUDP got error 99" in the OTBR addon log but could not find any solutions for it. I suspect that ipv6 addresses change and therefore the routing is screwed ... but that's just a gut feeling.
I have other Eve plugs that are connected to an Homepod mini which work flawless but I really wanted to give the Skyconnect a shot.
I have 3 border routers: Skyconnect, Apple Homepod and a Google nest hub. Each with their own thread network (sucks ...). Any hints to debug why the routing doesn't work for some time and then "self repairs"?
Logs: https://dpaste.org/XAVHS

[sick swan]

The add-on has configuration options. There is a firewall enabeld by default, just like in the reference OTBR. You can disable it, certainly worth a try. I haven't tested the pure Thread commissioning for a long time, I am not sure if it still works. We typically use the Matter or HomeKit flow for commissioning, which is differennt.

You can enable the OTBR web ui by setting both ports in the add-on configuration.

[rough lily]

I have it enabled and the commissioning works very well (and very fast as well). I disabled the firewall as well but no luck so far

OH!! it works!!!

niiice!!

this is amazing! Thanks! I also had to change the IP to "::" instead of localhost in the addon script

[spice imp]

isn't there some low power version of mqtt that works over udp? And why did you choose such an overpowered chip?

[elder dune]

Is iOS commissioning in HA app working now? Still failing for me due to lack of OTBR credentials in keychain.

[spice imp]

its mqtt-sn

[spring bramble]

On iOS you can only use apple thread border routers

[spice imp]

i think commissioning with google home might actually set the thread network, if there is no existing netowrk in the key chain.

This requires a google br though

And im not 100% sure about this either

[twin vine]

it didnt a few months ago when i tried, but then again, things could of changed

[spice imp]

I think its only if you have no thread credentials on your Keychain

And from what i can read that happens when you delete all homes

But im not able to delete homes, they just reappear 😂

[rough lily]

there is no low power mqtt via UDP. UDP is simply pakets which are send. The one we are sending contains JSON and has no overhead, just values. We have to actually translate it on the host into MQTT or whatever else is needed.
THere is MQTT-SN (not sure about the name right now) which is a version of MQTT via Thread for device which are not connected permanently. We just figured that sending UDP is much faster then any other protocoll which saves a bunch of computing time and therefor battery. The sensor lasts ~3 years on a coin cell battery sending its data every 30s. Which is basically also the reason for that "overpowered" chip. The chip has to be able to do Thread and I don't know any low power chip besides this one (nRF52840) which is still capable of doing Thread. The nRF chip is very low power in consumption which is perfect for our use-case but yes maybe overpowered in terms of computing, but thats not an issue due to its price. We are using a certified chinese company Minew Module.

you can read more about the sensor here if you are interested, it is 100% open-source: https://hackaday.io/project/180630-openthread-sensor-tag

[steady forge]

deleting all homes did not clear thread credentials for me unfortunately

[steady forge]

if you have an amazon echo in your network you can use the alexa app in the meantime to freely add matter devices to a thread network

[spice imp]

Im using the otbr addon right now and its just a child in my thread network. Is there a way to force it to become a router?

[elder dune]

I’m really only interested in using OTBR. Not keen on giving cloud anchored devices direct access to internal hosts.

[steady forge]

I understand, this is just a temporary option that allows you to connect devices to a thread network and HA. You could power it off afterwards. That's how I'm pairing devices right now through a Nest Hub that only gets powered for this purpose

Nanoleaf Essentials E27 are on sale again on Amazon (if you dare)

[spice imp]

The e stands for error

[inner torrent]

They've been on sale in the US since December lol

[honest jasper]

Even if they worked ok, they are not that good in many aspects. Scenes are terribly limited on those, if you want to make a sunrise scenario is more like 7 colors flashing for 30 seconds each and that’s all

[inner torrent]

There's a fair bit of control via matter but it's very DIY unlike the app which provides you scenes

[honest jasper]

The scenes in the official app on the Essentials e27 have the limitation I just described

Like 7 colors max or so, and the time you can make each color stay is also limited for some reason, and to very low time windows

Dunno with matter, to be honest, I got fed of them after that

I probably could have scripted the scenario in HA or Apple Shortcuts but I just bought a Wiz e27 bulb for half the price and used their much better sunrise scenario

[inner torrent]

Yeah that's what I was getting at that you would have to script it

They don't use or implement matter scenes

[echo sundial]

I'm interested in trying some Matter Thread devices with HA - does anyone have suggestions on devices that work well? (any device type is fine)

[modern root]

eve stuff seems to work pretty well

[inner torrent]

You can also order some dev boards on the cheap if you just want to do testing

[honest jasper]

Is there any esphome support for thread ?

[vapid shell]

There was https://community.home-assistant.io/t/announcement-esphome-running-on-adafruit-52840-over-thread-mesh-networking-using-zephyrrtos/363712

I like the idea of using the esphome api over thread

It’s a year behind on esphome support tho, Sadface.gif

[inner torrent]

No but there's espressif thread chips

[serene prawn]

@sick swan I converted your message into a file since it's above 15 lines :+1:

[sick swan]

Ok, bot, that was annoying, but whatever 😅

[inner torrent]

Manually deleting routes seems troublesome?

[sick swan]

Yeah I mean this is not the solution.

Question of course is what is the fix here... Looking into the source right now, it seems that OTBR relies on default metrics for routes.

[spice imp]

I have had a problem with my border router never becoming a router and just staying a child. This is probably also the reason why i before noticed that the SRP server was online.

I was able to change that by manually writing ot-ctl state router

So while you are down in the rabbit hole, maybe you also spot something that could cause this 😄

[sick swan]

Not even router, that seems weird.

That was with the OTBR add-on?

[spice imp]

::1 dev lo proto kernel metric 256 pref medium
fd0e:ed8d:8132:1::/64 proto ra metric 100 pref medium
        nexthop via fe80::1844:73ad:556b:b15c dev enp0s18 weight 1
        nexthop via fe80::26ac:ec0b:def2:a733 dev enp0s18 weight 1
        nexthop via fe80::b7b9:bae3:a47:31e7 dev enp0s18 weight 1
fd0e:ed8d:8132:1::/64 dev wpan0 proto kernel metric 256 pref medium
fd3d:594f:94f0:1::/64 dev wpan0 proto kernel metric 256 pref medium
fd75:bf26:d838:1::/64 dev wpan0 proto kernel metric 256 pref medium
fdb4:fb71:965c:ffff::/96 dev wpan0 metric 65535 pref medium```

[spice imp]

yes, from what i can see the problem was that i have 16 routers in my network already.

[vapid shell]

That scenario is actually the exact opposite of the one I was worried about when combing OTBR with Apple routers. I assumed that an on link route would implicitly have a higher priority (as it’s always a 1 hop route, and the external routers are always 1+n routes).

[spice imp]

So it never got promoted to a router, and therefore could not work as a border router

[vapid shell]

But still, having on-link routes and normal routes for the same network just weirds me out

[sick swan]

The TREL stuff doesn't go through the routing table from what I can tell. TREL is essentially "Thread mesh routing" afaik.

[vapid shell]

Isn’t it the same without trel?

Both of those routes exist without it?

[sick swan]

Yeah not sure we can do much about it. HA needs to be able to communicate through other BRs, so we (NetworkManager) needs to listen to IPv6 ND router advertisments.

We could also be a router for one Thread network and forward for another Thread network.

[sick swan]

Yeah true.. So maybe really a pure IPv6 routing problem then, not TREL related really 🤔

[spice imp]

trel should actually solve this?

[sick swan]

Not really. From what I understand this packets probably won't really make it into the Thread network, as in they get forwarded by the kernel before the OTBR process (otbr-agent) gets its hands on it.

[spice imp]

So basically the kernel would route the "trel" packages back again?

[sick swan]

When they are trel packets, then they are already encapsulated Thread packets.

I think the regular IPv6 Matter packet which reaches the BR, actually got redirected.

[vapid shell]

Doesn’t ipv6 create short lived /128 routes to make icmp redirects more scalable ?

[sick swan]

So my initial tests with Eve motion sensor and two OTBRs look super promising now. It roams super quick between the two. I can restart one, create a motion even 2s later (when his parent is gone), annd it gets registered by HA. Same game with the other BR..

[spice imp]

So this problem is limited to imcp packages?

[sick swan]

Uh never heard of that.

[sick swan]

PR which includes the fix. also bumps OTBR: https://github.com/home-assistant/addons/pull/3426

Unfortunateley, my test with Google didn't went as well. Adding Google worked well, but when I removed it from the network again, the OTBRs didn't store the SRP records. I was wondering in the past already how that works with SRP records (#thread-archived message). More investigation needed.

[vapid shell]

So is it right to say that before this change in the non trel case, people who added their OTBR to an Apple network were basically never using the OTBR?

(Pre trel)

Or would it do redirects if needed?

And post this change, in the non trel case will it only send packets via wpan0 and never to your nest/echo/esp32?

[sick swan]

Yeah I think so. Or if it started using the OTBR, then devices went offline unreachable

[sick swan]

Yes. Any packet arriving at the BR which has a destination address of the OMR would get routed into the Thread network. Without TREL, there is/was no mechannism to forward to another BR.

[vapid shell]

So it’s all hypothetical but if I had a bunch of nests (no trel?) in my house, and I had one OTBR, but it was in some god awful position RF wise.. it would seem to work prior to this update, then potentially start to fail post this update?

(I mean there /should/ be partitioning?)

[spice imp]

I still don't completely understand the issue with devices being unreachable. Is the problem that both border routers had the route to the other border router as the highest priority?

[steady forge]

great stuff @sick swan ! I've definitely encountered these issues before.

[sick swan]

Yes, exactly this. So from what I understand two OTBRs kinda couldn't have worked so far.

PR is merged! I don't have a good setup with Apple BRs. Google didn't work well, but if someone is keen on testing mixing OTBR with Apple BR, I would be very interested to here your findings 😄 I don't have high hopes just yet, but who knows 🤞

[spice imp]

Makes sense
What exactly do you want to test?

I have a setup with both Apple and Google in the same thread network

[worldly portal]

i have apple border routers and otbr - i can test as well

based on the change looks like it should show up as an addon update

so this implies having a single OTBR was ok, but having two or more is not?

I have two

one of mine seems to have issues: [netif] Failed to process event, error:InvalidArgs a bunch of these errors

[past charm]

I have my Apple (TV4k) and OTBR (Zbdongle-E with Thread firmware) networks merged. Everything is fairly functional, but yes my OTBR logs are full of errors and the OTBR add-on can’t seem to go more than a couple hours without crashing.

[past charm]

Same. Also many, many “error:NotFound”, “error:Duplicated” and “error:Drop”

[tough prairie]

Just out of curiosity: how did you get all of those merged?

[tough prairie]

To answer myself: I enabled the NAT64 feature which has helped greatly. No idea why though...

[sick swan]

Mostly if it remains stable. 😅 It typically gets interesting when BR loose/become available, so essentially a good test is to communicate with a Thread device while turning off and back on various BRs.

[sick swan]

Yes add-on version 2.4.4.

[steady forge]

What difference does it make selecting another TBR within a single network as the one used for iOS/Android in Home-Assistant?

[vapid shell]

If you are talking about the option I think you are, it doesn’t really make any difference.

[twin vine]

You got an android phone?

[vapid shell]

Each TBR has a unique id, and the iOS and google APIs require one of those ids to work. It had to be the same one every time. So changing it is bad.

[tough prairie]

Yup, I have an Android phone and an iphone

[steady forge]

Interesting

[steady forge]

After updating OTBR it's the first time my Nuki Smart Lock became unavailable (in a Mixed Google + OTBR network). Stopping OTBR and restarting the Nest Hub made it work again, so I guess it never really worked well together at all.

[sick swan]

Yeah that is what I've observed with Google + OTBR too 😢 But Google is also without TREL. I don't think it matters, but testing the combination with Apple BRs would be interesting still.

[worldly portal]

not sure what else to test, but so far i don’t see unavailable states for my devices

i’ll keep monitoring though

my network is apple+otbr only, no google thread stuff

i just got the espressif otbr dev board - was going to hook that up as well, but i don’t understand how to configure it yet

[steady forge]

https://docs.espressif.com/projects/esp-thread-br/en/latest/

[worldly portal]

yeah i was following some docs. the part that i got stuck on was the thread network info. there are quite a few fields that i dont understand if i just leave as is or i need to sync to my existing network

The Thread network parameters could be pre-configured with OPENTHREAD_NETWORK_xx options

that’s all it says for the thread network info

[inner torrent]

That didn't work for me so I just joined it after flashing and bringing up the board. You can do it via cli or the web portal (if enabled)

[spice imp]

Removed the Google Home, extrcted my dataset from Apple, synced it with my Android device and set up my Google devices again

I guess you could also set the pendling dataset with the HomeAssistant otbr

To move both Googles and Apples br to the network you want

[tough prairie]

Currently all my thread devices are connected to my Apple BR. I have imported the credentials in the HA app and set the Apple network as the preferred one. But at least the thread panel still shows different entries for Apple and the OTBR entry. For the Google one, you say I need to remove the Nest hub from the Google home (so resetting it) and add it again? Why would it join the Apple network then?

[spice imp]

Under some circumstances Google imports the thread credentials on the device

For me it usually worked to delete my whole Google Home

And create a new one

And i Think you need to make your Apple thread network the prefered one

And then set the otbr to change network, somewhere in the options

[spice imp]

After updating my eve motion came instantly online. Lets hope my gf doesn't want to kill me anymore because the lights in the bathroom just turn off every minute 😛

[oblique ether]

Hi,
Is it possible to run Z2M and OpenThread Border Router on HA Yellow with the same device?

[quick bronze]

With the right stick and the multi-protocol add-on (at least a version that supports Z2M), but not advised

[vapid shell]

AIUI we are likely going to switch from “not advised” to “actively discouraged” very soon

[misty lotus]

I have bought an Eve smart plug. Added that to Apple Home app. Then added that to HA matter. My HA is in a Yellow. Now if I control that from my HA, is that using the thread radio of Yellow?

[sick swan]

No, Yellow is communicating through the Apple Border router to that Eve smart plug. It is still an encrypted, direct control of the device from Yellow.

[modern root]

hrm, after upgrading the OTBR addon my thread network is empty

at least in OTBR, the esp32-openthread has my devices but OTBR doesnt seem to want to rejoin the network

Lots of Failed to send IPv6 UDP messages in the log with "error:ChannelAccessFailure" And also Failed to send IPv6 UDP msg, len:90, chksum:644d, ecn:no, to:0xf800, sec:yes, error:NoAck, prio:low, radio:15.4

🤷 restarted the addon again seems to have fixed it

[sick swan]

error:ChannelAccessFailure hm, that sounds as if something was interferring/blocking the radio 🤔

[sick swan]

Ok, but kinda strange. Not sure how a restart could solve something like this 🤔 Maybe it resets the radio somehow 🤷‍♂️

[modern root]

yeah :iiam: I left it for a good 2 hours since I know it can take some time, but just never rejoined

[misty lotus]

Then it's a single point of failure, as I have only one Apple border router. Right? Other routers aren't going to help if there is any, I guess

[spice imp]

Maybe it was also a „child“ like the problem I had

[spring bramble]

So the correct advise is to NOT use the multi protocol add-on (especially not with z2m). Use a separate stick for Thread (with thread only firmware) OR use any of the production ready 3rd party border routers (such as homepod mini).

[rough lily]

Hey there! I created my very first Home Assistant AddOn: https://github.com/open-thngs/home-assistant-sensor-tag-addon
It is used to translate UDP Pakets from the Thread Sensor Tag into a Home Assistant Device using the MQTT Discovery feature.
The Thread Sensor Tag is an open source Sensor to measure Temperature, Humidity, Pressure and Light with ultra low power using the Thread Network.
Here you can find the sources of the Sensor: https://github.com/HomeSmartMesh/nrf52_thread_sensortag
Or some informations about the Sensor: https://www.homesmartmesh.com/docs/microcontrollers/nrf52/thread_sensortag/#overview
Or you can even buy the Sensor here: https://www.tindie.com/products/23918/

The AddOn DOCS also describe how to start an OpenThread Border Router using the nRF52840 USB Dongle and Home Assistant!
Feel free to give ma some feedback! Thanks

[sick swan]

@rough lily this is cool, thanks for sharing!

[rough lily]

thanks for helping!

[honest jasper]

I don’t have any use for it, but thanks for sharing! I’m supercurious about the energy savings of using UDP vs other protocols now 😅

[vapid shell]

Cool! I wonder if there is value in something like https://bthome.io but for homebrew thread sensors.

They try to be space efficient so their packets might already fit in a udp datagram, so might be able to reuse their parser (most of the bt parsers are “sans io” and don’t actually do Bluetooth), so could literally copy the BTHome integration but have it read from a udp socket instead parsing Bluetooth adverts.

Then you could use it even if you didn’t have Mqtt or you don’t use addons, and if it followed the bthome wire format would get new device classes over time for free 🤔

[rough lily]

mhmm... we are using the nRF52840 Chip, so this might work out of the box (more or less). But I wonder what the power consumption might be.
The reason why we do Thread and UDP is due to the fact that Thread is extremely power consumption friendly and UDP takes almost no time to be send. We compared it with Matter and others and it was the best option. Matter takes way to much space on the chip and is also slow in computing time which increases the wake-cycle time of the device drawing more power.
BLE should be low too but not sure if we can reach ~3 years with it. I will check it out, somehow I never heard from it

I see they have a CircuitPython port for nRF52840 - but when I played last time with micropython on the nRF52840 after flashing there was almost no space left for any application aka business logic 🥲

[vapid shell]

I think you have misunderstood

In talking about agreeing a common wire format for simple thread/udp projevts

Not ble

And whether such thing could be a core ha feature that doesn’t need external components

So that we don’t need everyone to make their own addon etc

[rough lily]

so Matter somehow did not fit on the nRF52840 memory and was to resource heavy but nor sure if they changed something there. We looked into other protocoll like CoAP. Just recently someone added some CoAP functionality to the samples of the firmware: https://github.com/HomeSmartMesh/sdk-hsm-sensortag/pull/21
But I can't remember the power consumption it might bring. UDP gets send in almost no time but the biggest benefit was using Thread as a network layer. The connection is very fast. One sensor wake-cycle takes 1.7sec. We have some measurments of the powerconsumption here: https://www.homesmartmesh.com/docs/microcontrollers/nrf52/thread_sensortag/#tag_sensors_broadcast

[rough lily]

aahhh I see! Yes! Please! That would be amazing! Some UDP standards for sensors.

our UDP mainly contains some JSON but for sure it would be nice to have something which every device can send.
I am (or I was) working on a "application layer"-language for I2C which I called GeniX. The goal was to define "Registers" and values to have a homogen environment for sensors. You would need a MCU for every sensor but at the end there is no need to write code for every stupid sensor once they speak GeniX language because with that interface defined you can Discover the Sensor and ask for its capabilities.
The same thing could be used with UDP pakets at least in a similar way. I might write that down somewhere open for everyone, its currently closed and in a doc somewhere.

funny.. my GeniX stuff looks almost the same as this BTHome Data Format 😅

[vapid shell]

🎉

So dumb approach - we open a portion the ha instance and the first time we see a packet for a given device, we create a “discovery”. The user has to accept that discovery. Then it’s pretty much identical to bthome. As we see different packet types we create the entities. You can send different data points at different rates to conserve power. Etc.

I’d be reluctant to not have a discovery step in case something flooded the udp with bad data

Most likely by accident when developing

We’d need a stable identifier for the device, in bthome that’s the MAC address and so it’s not part of the wire format.

[rough lily]

any device should have some kind of unique id like the mac. I think we are also using the BL mac

thats an ID: 8C8C14D62739A191
looks pretty much like a mac (a bit long tho)

I don't know if thats possible but you could collect "Devices" in a list first, not creating Entities or Devices. The list is created per ID that comes in via UDP and the user has to "acceppt" it

as a device

[vapid shell]

That’s basically what I’m suggesting

Only the list is the ha discovery system

[rough lily]

more like a list of IDs first and only a discovery once you acceppt it

[vapid shell]

I think thread multicast could also be interesting here but I don’t know how much that increases the complexity in both ends.

[sick swan]

I like that idea 😍 if we use link-local multicast, it will only work when the BR is running on the instance where HA is running (at least one of them in the network). I guess the way it is implemented now also only supports that.

Another idea could be to use the SRP service of nowadays Thread, and let the sensor data to be part of the service annoucement. This would work even with third party BRs, and it woudl kinda mimic what is being done in Bluetooth (make sensor data part of the annnouncements). But not sure how well mDNS is suited for that 🤔

[vapid shell]

Interesting

Homekit sort of does the same

But only really simple data

Eg it has s# which it increments to indicate a disconnected event

[sick swan]

The matter commissioning info has a couple of metadata as well, like discriminator, vendor/product identifier etc. (some of them are optional afaik).

[vapid shell]

Or c# to indicate a change in device schema

Both part of a TXT record

[sick swan]

But we could make a _hasensor._udp service where we define a ccouple of TXT records as sensor data

Not sure how well that works with TTL/updating.. 🤔

[vapid shell]

Possible benefit is that SRP would cache - so ha could get the latest value at cold start even if sensor only updates once a day 😂

Yeah ttl would make or break it. We’d have to test it

[sick swan]

Yeah caching per see isn't a problem, actually a nice feature. The question is more if an updated record propagates reliably.

Just wondering how complex a SRP client is 🤔 It's part of OpenThread so probably just make sure it is enabled and some API calls? 🤔

https://openthread.io/reference/group/api-srp#group__api-srp_1ga0ebf5d6f14933c1811ef07ac46c943c6 🤔

[rough lily]

you left me behind 😅 whats TTL and SRP

[sick swan]

SRP = Service Registration Protocol.

It is a way for Thread devices to register services, which then get forwarded as mDNS/DNS-SD services into the network.

TTL = Time-to-Live. These records linger a bit around.

On the Thread Border Router.

[vapid shell]

It would integrate really nicely into ha’s discovery system (with SRP)

And the cache benefits on cold start are dealing exciting

And it wouldn’t need a new open port in HA

All very compelling

The only unknown is how quickly or easily we could push data that way

[vapid shell]

Where’s the api go update the txt records 🥲 do we just mutate the txt service object directly? The lack of ttls is upsetting

[sick swan]

There is mLease mKeyLease, sounds like time related? 🤔

What worries me is that there is only otSrpClientAddService and otSrpClientRemoveService, no update.

I guess updating a record involves removing and readding, which probably translates to two mDNS/DNS-SD annnoucments on the BR...

[vapid shell]

Yeah 🥲

[sick swan]

Before diving into Thread too much, the question first probably must be does that work in mDNS/DNS-SD world at all...

https://datatracker.ietf.org/doc/html/rfc6762#section-8.4

A host may update the contents of any of its records at any time,
though a host SHOULD NOT update records more frequently than ten
times per minute. Frequent rapid updates impose a burden on the
network. If a host has information to disseminate which changes more
frequently than ten times per minute, then it may be more appropriate
to design a protocol for that specific purpose.

Okok 😅

[vapid shell]

Booo

[sick swan]

But ey 6s is not too bad

At least for Thread use case, I don't thing a higher frequency is really necessary.

[rough lily]

we send out our sensor data every 30s and more often is not really necessary I guess

might be an issue for "door contacts" or so, when you open and close a door super fast and often haha but well.. details

[vapid shell]

i think in those situations, its ok to break the limit

and anyway, with Srp you'd basically only need to transmit when the state changed, right?

and Srp would keep things awake on the BRs

[spice imp]

So basically you want to exchange all data using dns entries?

[tough prairie]

At least I got OTBR and the Apple one merged now. Google is reluctant. Unfortunately I can't delete my home as then some members will kill me.

[spice imp]

Dont be so scared, I have 13 Nanoleaf bulbs running in a thread network with the HA otbr mixed with Google and Apple 😂

But I think Google has some documentation to n how to change thread networks

Or at least how it works in the background, so maybe deleting is not nessecary

[tough prairie]

Got you. Well I am more scared of my wife when the Google home vanishes 😉 But that sounds promising.

[spice imp]

Well the trick is to make them dependent on it, break it, and then be able to use all the time and funds you “need” to fix it again 😂

At least that’s what worked for me

[tough prairie]

Lol

Will consider this

[spice imp]

If you send updates too often to the srp Server you get “banned” for a while

[vapid shell]

i think "want" is a strong word here. but its one option that fell out of wondering, "is there something like BTHome, but for thread"

i really like that the latest data would be cached even if the sensor was in lower power mode 😍

[spice imp]

But what about security? You can ofc encrypt the data you publish, but still…

[spice imp]

And I’m not sure when this exactly happens, but I have run into this issue a few times with matter devices and an Apple or Google br(can’t remember which)

[sick swan]

There is a per device rate limit?

[spice imp]

Something like that, I’m not sure what it is exactly. But it happened a few times when commissioning and recommission devices too often, where the logs showed something about not being allowed to publish entries and being banned. After waiting for a while everything was working again.

[sick swan]

BTHome has the same problem essentially, I guess most people run it unencrypted. it has AES support.

But IMHO, if that is your worry, maybe better to go with Matter? 😅

[sick swan]

What I have seens is that multiple stale entries were present, which can be confusing/problematic for the consumer. Is that maybe what has happened?

[spice imp]

I’m not sure, i never really looked into it. It could be.

Would just be annoying to do the whole implementation and then run into this limitation

[rough lily]

hmmm.. I had issues yesterday to commission my device and I couldn't find the problem. MAybe it was that because for testing my AddOn I had to re-do it multiple times

[spice imp]

But isn’t this using thread commissioning? Is that even using mdns?

[rough lily]

thought there might be a "bann" for that as well somehow

[spice imp]

I can imagine. But maybe that’s two different things?

[rough lily]

true

[sick swan]

Btw, something I just realized: If we use this with Thread at least things are encrypted in air (we have the network level encryption of Thread). Unlike BTHome, where advertisement packets are unencrypted in air...

[steady forge]

@sick swan This is how it looks on Alexa. Btw it was able to pair an esp-matter example light first try while HA didn't work (only when then shared by Alexa using a pincode)
https://pic.xpl.link/-nezLKb2R2i/Screenshot_2024-01-22-18-08-28-753_com.amazon.dee.app.jpg
https://pic.xpl.link/-JZ79TxzbEb/Screenshot_2024-01-22-18-08-38-608_com.amazon.dee.app.jpg

Are these MyHome networks I see everywhere actually Zigbee or are they Apple networks from my neighbors?

[twin vine]

Wow, bravo amazon, doing something pro-consumer!

[twin vine]

MyHome xx iirc tends to be apple, so maybe from your neighbors

[whole glade]

Hello! I am trying to share Thread credentials from my iPhone and when trying to add the Thread from the Sonoff dongle (which I am using Zigbee2MQTT with), I keep getting an "Failed to configure the border router error." I changed the radio in Zigbee2MQTT to channel 25, not sure why ZHA is using a channel when I removed ZHA before setting Zigbee2MQTT. Please advise and thank you. https://imgur.com/a/mKMLyF9

[sick swan]

Currently, combining the OTBR with Apple is kinda known to be unstable 😢

Also, if you have a Thread network with multiple Apple BRs, and adding a Thread network using the multiprotocol firmware, this likely will not help even in an ideal case. It means that Zigbee and Thread will share the same RF channel -> less bandwith for each of them. Your Apple BRs have a dedicated radio, so they can be on a separate Thread channel. i'd recommend to use a Zigbee only firmware on your Sonoff and use that for Z2M exclusively.

You still can communicate to Thread devices through Apple BR. Home Assistant doesn't need to be in the Thread network for that.

[whole glade]

Thanks for your speedy reply! If I flash the firmware to Zigbee only and use the Apple border routers, I will not need to share the thread credentials right? And Matter over Thread devices will work on HA?

[worldly portal]

apple + otbr has been stable since the upgrade for me - 2 days now

[twin vine]

yeah ive had no issues with apple+NL+otbr

https://imgur.com/a/AWkVyVW

havent been able to merge google yet coz im not at home, nor have access to an android atm

[sick swan]

Correct. The Home Assistant companion app will directly get the Thread credentials from iOS. So no need to have the credentials in the Home Assistant Thread config panel (but also doesnn't hurt 😅 )

Thanks for testing Apple + OTBR. That said, @whole glade 's case is Multiprotocol, which has a bit older configuration of the OTBR. That one is buggy still. Also, the channel sharing downside will be present no matter if things are stable or not. Better to keep them separate.

[spice imp]

lies, i have a stable network now with 13 nanoleaf bulbs, an apple homepod mini, home assistant otbr and 2 google nest hubs

😄

[twin vine]

Add an extra bulb and see the whole network crumble 🙈

[spice imp]

nah, its about placing the border routers smart

[twin vine]

Eh, hopefully we get some new beta firmware soon enough from Nanoleaf, they have been radio silence since CES

[spice imp]

i think its silabs who are slow

[twin vine]

It’s hard to know who the point the blame onto from a technical sense, but from the outside, Nanoleaf are doing next to nothing to make their customers happy, not even a public statement apologising

[spice imp]

i have actually had the same problem with their devboards

didnt think much of it though

But nanoleaf has probably been super slow at figuring out that its maybe not them

[twin vine]

But surely running multi stack can’t be helping at all?

[spice imp]

doesn't make it better. Im guessing that that's why its also harder for them to track down the issue

But all of this is also just guessing

[twin vine]

https://www.silabs.com/wireless/zigbee/efr32mg24-series-2-socs

iirc they use this soc

[vapid shell]

Spoke to Nick (the zeroconf maintainer for people at home) and while HAs zeroconf is super optimised and would probably be fine if we did this, peoples home wifi would probably not like it.

https://web.archive.org/web/20201019031102/https://help.ui.com/hc/en-us/articles/115001529267-UniFi-Managing-Broadcast-Traffic

And while HA has super optimised mdns, there’s lots of not super optimised mdns common on home networks that like to randomly query records not to do with them

Vaguely recall early homekit nanoleaf over thread having massive mdns spam issues

Think we are spoilt by Nicks work - used to take 10% cpu time just to process zeroconf messages before he got his hands on it.

[sick swan]

They are using SiLabs? Is that known?

[sick swan]

Hm, I see, I guess multi-cast means it broadcasts the packet on WiFi 😢

[twin vine]

#matter-archived message

and also subtle hints from the product manager in their discord

[sick swan]

Ok yeah make sense. i wonder if all their products were MG24. The chip is a bit newer, and Nanoleaf does Thread since quite a while.. 🤔

[spice imp]

I dont think you cant upgrade their homekit devices

[sick swan]

I see. So probably safe to say that their Matter products are all MG24 then 👍

[vapid shell]

Yeah they made a big deal about the homekit chip not having enough.. memory? For matter

[twin vine]

https://www.silabs.com/blog/silicon-labs-bg24-and-mg24-socs-now-available-to-help-customers-and-partners-bring-matter-ai-ml-and-innovation-to-iot

oh yeah, they mention nanoleaf using MG24 here, no doubt they got early access to dev kits before other vendors

[inner torrent]

I cut one in half to find out

Does indeed have a MG24

[frozen gale]

Anyone know how to get nest hubs on the same thread network as HA skyconnect?

[spice imp]

the other way around is easier

[inner torrent]

Have the skyconnect join the best

Nest*

[frozen gale]

how do i do that?

i'm not currently using thread for anything

but hope to start doing so

[twin vine]

you got an android phone?

[frozen gale]

affirmative

[inner torrent]

Under configure for the thread integration, click the three dots on the Google network and make preferred. Then click the three dots on the sky connect and press join preferred network

[frozen gale]

there's no options for 3 dots under teh nest networks

[inner torrent]

Is it preferred already?

Does the sky connect say make preferred instead?

You should have one network under "my network" (preferred) and another under "other networks"

[frozen gale]

https://imgur.com/a/PbrRRNH

the 3 dots only have "reset border router" and "Change Channel"

[quiet stirrup]

Not sure if this is the right place to ask but I was wondering if someone could help with HomeKit over thread devices. I’m able to add the devices through Bluetooth, then provision thread but as soon as I do that, I’m unable to control the devices(a lock that will not lock/unlock, and shades that will not go up or down). They worked fine on Bluetooth. Is there something I’m doing wrong?

[worldly portal]

i have some wemo thread homekit switches that seem to work. but the way to pair them is set them up in homekit, including thread setup, then delete in homekit and add to home assistant

[quiet stirrup]

I tried that originally and kept getting accessory already paired message. Reseting and adding them to ha using bluetooth was the only way I could get it to work

[inner torrent]

I'm not sure why that option isn't there 🧐 you could try syncing thread credentials if you haven't already, via the companion app?

[frozen gale]

Not sure what you mean

[inner torrent]

Settings -> companion app -> troubleshooting -> sync thread credentials

Also you need to have Google home installed if you don't already

[frozen gale]

That did the trick!

[sick swan]

We have new and improved Thread integration docs 🎉 https://www.home-assistant.io/integrations/thread

[spice imp]

iTs ToO LOnG, YUo CaNT eXPect ME To REaD AlL oF ThAT

[vapid shell]

Do we need to deploy a blinking <b> for setups that are unsupported or require you to know your way around tcpdump and iproute2 to get things fixed…

[steady forge]

maybe tag the entire integration with (Beta) just like the Matter one as a general disclaimer

[steady forge]

Is there a reason we don't set txpower higher than 0 in OTBR by default? I need to set it to at least +4 dbm to reliably keep an Eve Energy behind a thick concrete wall and furniture in the network

[sick swan]

Uh good point. Honestly I think I never really checked this in the context of the pure Thread firmware. I remember looking at it for Multiprotocol. There it turned out to be controlled by Zigbee side, so I did not bother.

[frozen gale]

Is it possible to use 2 skyconnects, one for thread and one for zigbee?

[sick swan]

The maximum value allowed value depends on the region. For Europe, 802.15.4 (the underlying PHY) has a rather small band it sends in, which limits the allowed power lower than the maximum RF rate for the 2.4GHz ISM band (which is 100mW/20dBm). Effectively, according to this paper https://www.highfrequencyelectronics.com/Archives/Aug13/1308_HFE_eustandards.pdf, 12dBm is allowed.

That said, It is often not wise to bump this too high as Thread is a mesh network. I think 3dBm or 6 dBm is quite common. Google says their is "max 10dBm" 🤔
https://support.google.com/product-documentation/answer/7055908?hl=en#zippy=%2Cgoogle-nest-hub-nd-gen

[sick swan]

Yes, should be possible! We also reference the two using their serial number (reference the serial dev with the by-id path). With that the two should never get mixed up, even when rebooting/swapping ports). Just make sure to ignore the ZHA integration discovery card for the one you use in Thread.

[modern root]

if I'm reading the OverView status of my ESP32-otbr it's defaulting to 21 dBM

[frozen gale]

mainly looking at breaking them out because my ZHA keeps failing randomly when in multiprotocol mode

goes to "Failed setup, will retry" and just sits there, even though it had been working for hours

[spice imp]

what hardware are you running on?

Nvm, didn't see its multi protocol

[frozen gale]

ya, if i restart ha, not even reboot the box, it comes back

but thats twice in the last day its done that and all of my automations for most of my devices are broke

[night moth]

Im wondering if rather than 2x skyconnects, would it be better to keep skyconnect doing zigbee and get like a google nest gen2 for a thread border router? WOuld that be more stable? Or probably not make much of a difference vs skyconnect on thread only?

[frozen gale]

So, i actually have 2 nest hubs and made that my preferred thread network anyways while i was tinkering with it, will HA work directly with those without having the skyconnect in thread mode?

even with skyconnect back in ZHA only mode, i'm still seeing them as the preferred thread network

[sick swan]

Yes! You can use the Google Nest Hubs as Thread border router directly. When using an Android phone, the Thread credentials will be used, but Matter commissioning will be made direct with HA. Google also allows to import the Thread credentials into HA Core. That is not that useful currently for Matter but it is possible 😅

[sick swan]

I mean it is a different device, different price etc. But definitely a compelling option as Thread border router. Also you can position it quite central in your home. It is just Google controller, not as open source as SkyConnect+ OTBR addon 😅

[night moth]

I dont want to and would rather use skyconnect, but if the nanoleaf going unavailable is skyconnect instead of its own firmware, at least that could potentially be a bit more stable till there is an update?

[inner torrent]

No

Nanoleafs problems are irrespective of your BR(s)

The nest will however give you better coverage

Versus the skyconnect alone

[spice imp]

one of the problems with nanoleafs bulbs is that they crash with too much traffic

so adding more border routers removes part of the problem

[twin vine]

it can help if you can segregate a bunch of bulbs into one area of your house with a br, and the same at another point down the other end.

tho, its isnt the most practical

[inner torrent]

Yeah I think it's related to how many bulbs are around the BRs, just adding them indiscriminately won't help

[spice imp]

From what i can see is that the less packages are routed over the nanoleaf bulbs the more stable they are

[inner torrent]

Yeah but I'm trying to say if you have 5 bulbs in your bedroom, but add a BR in your kitchen it won't help

[twin vine]

it would be intresting to see if ben responses to if its a sillabs issue or a implementation issue

they seem pretty confident about the whole "having enough power to run both stacks"

[spice imp]

does it really matter?

Just because a problem is triggered more under load, doesn't mean that the load is the problem

[twin vine]

depends on how adamant you are really, but they seem to be open to more technical questions, and from what ive seen they are the only ones on the market with the MG24?

[spice imp]

It might just increase the chance of something happening

[twin vine]

would be intresting to see what eve use

[spice imp]

eve uses nordic

[twin vine]

ahhhh right

https://www.nordicsemi.com/Nordic-news/2020/12/homepod-mini-smart-speaker-support-thread-networking-protocol-and-enables-nrf52840

yep, bingo

[spice imp]

Also eve's devices do way "less" than nanoleafs

they can turn on and off

thats it

[twin vine]

thats true, its just interesting to see the wildly diffrent approaches from both companies

[spice imp]

how so?

[twin vine]

one going all in on matter, the other using both matter, and their own proprietary system

[spice imp]

That has enabled nanoleaf to have an android app

[twin vine]

that is true, and i guess eve's approach coming from only apple (and especially with them being proactive) means they can do it

[spice imp]

They have been a pure "HomeKit" company before, so they are probably not loosing any existing costumers over it

I think nanoleaf has been working with other ecosystems before

[twin vine]

guess nanoleaf just has a ton more technical debt

but oh well, keep releasing buggy products and hope it will be fixed eventually

[spice imp]

i can imagine they also have some "startup" investors that want fast profits

[inner torrent]

They started from a Kickstarter so idk

They did say they want stable full thread devices but I dunno how feasible that is on the chipset

One guy was threatening to return his 80 (!) Bulbs -- sooner or later something will have to be done

[twin vine]

Yeah, you know it’s bad when people are saying that

But it’s worse if Nanoleaf don’t honour those refunds within the UK/EU/ANZ. 🙃

[night moth]

Strangely enough all the nanoleaf bulbs show up online and controllable over thread in the nanoleaf app, but the few showing unavailable and trying to resubscribe in HA still just unavailable. At least I could turn them off and hope the network gets some sense into it overnight 😛

[inner torrent]

When the nanoleaf app talks to the bulbs, it's using a proprietary protocol, not matter as HA does

[steady forge]

Google could have a point there, I've seen best Link Quality between 10 and 12, after that LinkQualityOut takes a hit. My zigbee network operates well on 14dbm.

[steady forge]

Yup Defaults to 20dbm for me

[serene prawn]

@keen mango I converted your message into a file since it's above 15 lines :+1:

[keen mango]

I had the same issue, although it's less common now. So I wrote an automation that reboots Home Assistant automatically when ZHA crashes. This is kind of a bandage fix but it works. However this issue is less common for me now, it seems to have sorted itself out and this is no longer frequently triggered for me.

On the other hand Thread crashes all the time. The irony is that back when I had the ZHA issues Thread was more stable, and now it's the exact opposite.

I have a Zigbee motion sensor and Thread bulb pair, the automation for that rarely works reliably because of these issues. I get pleasantly surprised each time that light actually turns on when I walk by it. The rest of the time it's just frustrating.

[spice imp]

Are you using multi protocol?

[keen mango]

Yes.

[spice imp]

its not advised to use it right now. If you want to have a stable setup it would probably be best to just get a second skyconnect.

[digital salmon]

Maybe the bulbs are the issue. At least If you are talking about Nanoleaf Matter over Thread bulbs, this can be the case. A lot of us are waiting for a new reliable firmware.

[sick swan]

Does someone have a mDNS service capture of a Nanoleaf BR? I am interested in the xa and id TXT properties 😅

[inner torrent]

I've got one and can help out later today

Not familiar with xa and id is that part of the mDNS service info?

[sick swan]

Yes.

[inner torrent]

xa=v\207\196XK\246\215+

it doesn't provide an ID, there's just no entry there

there's a vdid

[sick swan]

🤔 🙏

[inner torrent]

You'd like the vdid as well then?

[sick swan]

That seems vendor specific. Is it the same as some other property?

[inner torrent]

Not from what I can tell. Here's the records it has:

vo, vsn, vdid, omr, pt, at, sb, xa, tv, xp, nn, mn, vn, rv

[sick swan]

@steady forge you have an Amazon BR right? Can you share the mDNS records of such a device? 🥺

[elder dune]

Catching up on The State of Matter stream from a few weeks ago.

Excellent preso by @true fog on Thread & Matter fundamentals. One question or point of clarification. It was stated multiple times that a TBR bridges thread to WiFi but isn't it more correct that a TBR bridges thread to wifi and/or ethernet?

[twin vine]

I mean in his example he used HomePod mini’s, which can only do to wifi, but there are Ethernet based border routers out there as well, like an Apple TV, or custom ESP boards

[elder dune]

Cool. I was just looking for clarification.

[misty lotus]

Hi, I'm getting this error quite a few times in OTBR log. Is that normal?

Default: mDNSPlatformSendUDP got error 99 (Cannot assign requested address) sending packet to ff02::fb on interface fe80::b0bc:30ff:feb8:bb6d/vethf91351d/31

[ionic plaza]

I wonder if anyone know why multipotocal and open thread add-on are not listed in the add-on store. (HA 2024.1.5/generic-aarch64 on a Mac UTM)

[steady forge]

https://paste.xpl.link/upload/mouse-whale-camel

[true fog]

Yes Marcel mentions this afterward. It’s « your local network ». Most of them are WiFi based but indeed, you are correct 👍

[sick swan]

Yes this is normal, those type of interfaces don't support multicast, and the server tries to send there too. Probably could add some code to prevent the error messages. But it is definitly not problematic for regular operation.

[sick swan]

Make sure Advanced mode is enabled in your users profile.

[echo spruce]

Is there a way to just avoid sending multicast packets to such interfaces?

[sick swan]

I don't think it tries to send, it just tries to subscribe once on startup.

[misty lotus]

Hi all, I'm getting a few of these messages in the OTBR log of my Yellow.

otbr-agent[180]: 19:40:22.117 [W] Nat64---------: incoming message is an IPv4 datagram but no NAT64 prefix configured, drop

I see that in the configuration page there's an option to enable NAT64, should I enable it?

[twin vine]

It’s in the configuration settings of the OTBR add-on

I mean; you can if you want?

[sick swan]

Are you runniinig the latest version of the OTBR? It should be fixed with https://github.com/openthread/openthread/pull/9762

Btw, I like your username 😅

[vapid shell]

if you are security or privacy minded that setting is probably something you want to turn off fwiw. It’s not needed for matter.

[misty lotus]

My HA core is 2024.1.5, and the add-on version is 2.4.4 .

[sick swan]

Ah maybe you did not reboot the system since the last OTBR update?

The fix above just avoids adding an unnecesary IPv4 routing rule to the routing table. If you had <2.4.4 running on that system since your last system boot then this rule could still be in there.

[silver thunder]

Interestingly, despite all the warnings, the Silicon Labs Multiprotocol v2.4.3 is stable and working on my HA Yellow. Zigbee and Thread both working fine. Maybe because I also have a couple of Google Nest border routers on my Thread network?

[spring bramble]

For some people it indeed runs fine. Could indeed be that your google routers are doing the majority of work or you just have a small setup

[vapid shell]

One version of the BR addon actually had the route table such that otbr was not used at all if you had external brs

[silver thunder]

Happy to share some diagnostic info if that would be helpful

I only have two Thread devices right now (Eve motion sensor and Nanoleaf bulb) so that could indeed be part of it

[vapid shell]

The instability is exacerbated by thread traffic, so it’s likely to be

The nanoleafs are also silabs and also buckle on busy networks

I think we are probably seeing cascading failures on larger networks with devices that struggle

Because thread re-org obviously creates thread traffic

So device crashes, then its neighbours try to re-mesh with it, creating more traffic. Then one of those might crash…

[silver thunder]

The bulb works ok for me (with a few frustrations like the fact it can't handle transitions). But the logs do show that it often becomes momentarily unavailable before reconnecting to the network

[inner torrent]

NL bulbs are known to have problematic firmware, nothing to do with HA

[vast sierra]

Will a thread light switch like the new innovelli work as mesh extenders because they have constant power?

[inner torrent]

Just because a device has constant power doesn't mean it will perform as a thread router. However, inovelli did confirm their switches will act as routers (mesh extenders)

[vast sierra]

Excellent news. Thank you

[keen mango]

Consider yourself lucky. I have a similar setup and 2.4.3 was terrible. 2.4.4 is better although still not perfect.

[misty lotus]

The messages disappeared after a system reboot

[night moth]

Recently switched back to the multi pan and zigbee would crash every few hours till i unticked the beta matter server option, since then its been pretty solid.

[keen mango]

So you're not using SiLabs Multiprotocol? For me it's important because I have an equal amount of Zigbee and Thread devices.

[twin vine]

If you having issues, your best bet might just to be get another stick and use run thread on one, and zigbee on another

[night moth]

I was on thread only for a week trying to sort out the issues that now I know is largely just the nanoleaf's. And decided to switch back to multiprotocol so all my zigbee stuff would work again. So back on multiprotocol, but it would crash roughly every 6 hours and I would need to reload the zigbee integration, but after unticking the use beta option on matter server it has not crashed since for over 35hrs. And its beed pretty solid since. reduced my nanoleafs to 16 devices and its a lot more stable, only dropping off here and there, no difference to when it was thread only firmware

[inner torrent]

Another issue with multiprotocol is you have to share bandwidth. It's pretty simple to run separate dongles which is another reason for the recommendation

[keen mango]

Which option is that?

The entire Matter integration in Home Assistant is labeled BETA, so I'm not sure which option you mean. Unless you disabled Matter all together on Home Assistant.

[night moth]

Click the configuration tab of the matter addon and there is an option to "Use the latest beta"

[twin vine]

that does nothing at the moment, iirc it is the same bulid regardless?

[night moth]

I figured it probably does nothing since the latest update, but it was the only option I changed between zha crashing regularly and it being stable.

[twin vine]

yeah, the beta essentally pulls the latest build from here: https://github.com/home-assistant-libs/python-matter-server/releases

if its not the same as the add-on version that is.

[sudden fiber]

When I go to port 8081 I get { ErrorCode: 404, ErrorMessage: 404 }

How do I fix it?

[steady forge]

There's nothing to fix, port 8081 is the websocket port of OTBR. If you add /node to the end you'll get info about the instance

[twin vine]

Isn’t 8081 the API while 8080 is the frontend/GUI?

[brave crown]

Just a few minutes ago my update from OTBR Router 2.4.4 to 2.4.5 failed with the following error message:
"...[547956764992] Error updating OpenThread Border Router: Can't install homeassistant/aarch64-addon-otbr:2.4.5: 404 Client Error for http+docker://localhost/v1.43/images/create?tag=2.4.5&fromImage=homeassistant%2Faarch64-addon-otbr&platform=linux%2Farm64: Not Found ("manifest for homeassistant/aarch64-addon-otbr:2.4.5 not found: manifest unknown: manifest unknown")..."
Any glue, what the reason of this behavior can be. All previous updates worked fine. I am on Home Assistant version 2024.1.5 on Home Assistant Yellow Hardware.

Just a few minutes ago my update from

[digital salmon]

I have a question, some weeks ago some of recognized that Google disabled TREL on their Thread Border Routers. Is this still the case?

[twin vine]

Yes

The nest hub firmware hasn’t changed since early December, and no one quite knows what “feature flags” get it to be enabled

[inner torrent]

I suspect this is related to them trying to find a way to shove bard into the hubs 🙄

[twin vine]

And we haven’t had a new Fuchsia version since mid-Octoberish.

Honestly could just be the tech layoffs effecting them hard

[spice imp]

*ai hype insanity

[sick swan]

This are the OTBR internal feature flags https://github.com/openthread/ot-br-posix/blob/13d583e361c7038b967b601d5e5f6739b0bcf736/src/proto/feature_flag.proto#L19

But I've asked some Google contacts, there is no way for the user to influence these feature flags. But eventually TREL will come back to Google TBRs.

Btw, also mixing TREL and non-TREL should be safe from a protocol perspective. The ones without TREL just don't have that extra Thread link...

[spring bramble]

Maybe we should gather some known working setups of mixed environments ?
I had some issues 2 weeks ago but now my mix of HA Yellow + Apple BR's seems to be rock stable (knock on wood). I think it would be great if we can gather some insights from users running the various setups and combinations. Maybe even create a thread here per combi where people share their experiences

[sick swan]

I do watch on this channel quite actively the past ~two weeks, and from what I've seen, since 2.4.4 everyone reported good results.

But the thing here is, define "working"... Enabled it and the bulbs still worked? That is a very basic setup. Worked for two weeks? Worked even when other BRs went offline? Etc. etc.

The only negative report I've seen so far is my own testing 🙈 But my testing was abusive: I've pulled the plug of vairous BR while trying to communicate with a Thread device. At one point things stopped working. But there, I think the Matter subscription somehow timed out, and did not (immeaditly) recover...

I've also did some theoretical research, as state above, the TREL/non-TREL combination should be safe. I think we can assume that things are working, and track if anyone finds a combination which behaves erratic.

[spice imp]

Im running 1 skyconnect + 1 Apple HomePod mini + 2 Google nest hubs

The biggest problem im having is the otbr dying because my rcp somehow died

[twin vine]

😔✊

[modern root]

I have a espressif-openthread, OTBR, and one nest hub and it seems fairlly stable

I have nanoleafs on dumb switches and they seem to rejoin within a minute or two after being powered back on

[twin vine]

Honestly from what I’ve seen, if most people are running a network with a known reliable BR from Apple/google/amazon. It’s not too bad. It’s just when they are using their own DIY networks that things can go a bit sour

[sick swan]

What RCP are you using?

[spice imp]

Wireless gecko with an mg24

With an Intel nuc

The board is probably not dead, But i might need to restart it or maybe reflash

[sick swan]

Ah so dying as in not even a restart helps?!

With just a pure OT RCP firmware?

[spice imp]

Yeah its pure RCP firmware. But they have no official “thread” firmware. Its under their matter repo somehow.

And dying as inrestartikg the otbr does mot help. Havent powercycled it yet.

Last time i had a similar problem I had to reflash it.

But maybe I also did something while troubleshooting last time

Like shorting ground with phase in my home 😂

But that should not have an effect on it

[digital salmon]

The Thread Group itself announced the following features and enhancements:

• ⁠Credential sharing
• ⁠More ubiquitous Internet connectivity
• ⁠Thread over Infrastructure
• ⁠Network diagnostics
• ⁠Secure Commissioning at scale
• ⁠Numerous additional enhancements to robustness and scalability

Source: https://www.threadgroup.org/news-events/blog/ID/428/Threads-2024-Enhancements-and-What-Theyll-Mean-to-You

I think with ‘Thread over Infrastructure‘ they mean TREL. Maybe they hold it back by purpose to launch a much better Thread 2.0… What do you think?

[sick swan]

From what I understand TREL was not mandatory with Thread 1.3.0. I think their future specs will make it mandatory.

[spark orbit]

Matter over Thread SkyConnect

[worldly portal]

bunch of my thread devices went unavailable today - with the 2.4.4 otbr version

[wanton bough]

How ICD is going to reduce the power consumption?

[night moth]

Im back to multipan since 2.4.4 and its been pretty reliable, even my nanoleaf bulbs (with latest beta) however I did also reduce to only 16 nanoleaf bulbs on thread.
I would say its been about 97%, with just every so often 1 light does not respond. All zigbee devices have been happy too.
And commissioning has been working perfectly as long as I am doing Kill HA App every time, google home > link to HA, succesful. Kill HA app and repeat.

[keen mango]

Same experience here. 2.4.4 is a massive improvement

[vital sequoia]

Hey all, I'm running a home assistant on a virtual box VM, I've just bought a Sonoff ZBDongle-E, and I've flashed it with MultiPAN RCP - Zigbee + Thread, I've added the ZHA integration and added one Zigbee switch to the network, it was working at first for a few tries but it stopped working (I get an error "Failed to call service switch/turn_on. Failed to send request: Failed to deliver message: <EmberStatus.DELIVERY_FAILED: 102>" when trying to turn on the switch). After restarting the home assistant, i got a 1 repair notification saying "OTBR and ZHA share the same radio but use different channels" - OTBR is configured with a Thread network on channel 11, ZHA is configured with a Zigbee network on channel 20.
I only have Ignore and Learn more buttons and when I follow the "learn more" link it takes me to a skyconnect page with 3 options.

1st option tells me to check the thread channel and set the zigbee channel to the same number, but when I go to the zha configuration it's not letting me change the channel, it tells me to go to hardware menu. In Settings>System>Hardware there is no way to change the channel. Under "All hardware" i see the SONOFF dongle under ttyACM0.

2nd option tells me to reset the boarder router in the threads integration, but when i try to do that, i get an error "Failed to configure boarder router - unknown error"

3rd option tells me to use 2 separate wireless chips which I don't have

anybody encountered similar issue and knows how to solve it?

[sick swan]

Yeah the HW menu doesn't exist for the Sonoff stick 😢

There is a discussion in the addon issue tracker.

But if you have a second stick, I'd consider using separate radio sticks for Thread and ZHA

[sick swan]

FWIW, this is the mentioned discussion: https://github.com/home-assistant/addons/issues/3124

[keen mango]

Does SkyConnect multiprotocol work with Zigbee2MQTT? While keeping Thread support.

[sick swan]

Yeah with the 2.4.4 add-on which comes with the older Gecko 4.3.1 release of EmberZNet it works. But honestly, it is a bit meh, next time the add-on gets updated to a newer Gecko version it might break again 😢 I'd rather opt for two dedicated radios, one for Z2M and one for Thread. Then the two networks also have full bandwith 💪

[vast sierra]

So.... I see on https://www.home-assistant.io/skyconnect/ that they no longer are even trying to complete Multiprotocol, despite selling the device with that expectation.

Is there a Thread Only firmware so I can run just thread reliably with OTBR? Seems like waiting around for multiprotocol to work is a fools errand now.

[inner torrent]

https://skyconnect.home-assistant.io/procedures/enable-thread/

Just so you know, the HA team does not write the upstream firmware

[vast sierra]

It has been impossible to get a straight answer from anyone about where to go to talk about the SkyConnect and its firmware. I really dont wanna be drumming up convo in the wrong places and be that guy

I've been using multiprotocol since day 1 of getting the device, and it was mostly fine, but lately has been a flakey little brat after some updates.

I've managed to roll stuff back from backups and restore some functionality, but at this point I'm holding on to multiprotocol dor a single Zigbee switch I was told would be Thread updateable (still waiting on that) - so I'm considering just ditching that device and going thread only.

I just popped the SkyConnect off my rPi running HA, and updated it to the latest multiprotocol firmware. All my devices seem to be working for the moment. Need to go test adding a new device again - that has been extremely hit and miss

[inner torrent]

There's plenty of ZigBee dongles out there, could just run separate dongles?

I'll also mention that HA isn't the only one that's struggled with silabs firmware 😉

I only mention a separate dongle because $20 is a small price to pay for reasonable stability imo

[vast sierra]

I was aiming to not bother with ZigBee at all, if I could. I only bought the one switch on the promise it could update. Never imagined it would take so long to achieve.

Well look at that.
New device (window shade) finally commissioned.

[vast sierra]

The allure really was a single dongle, given that it needs to have an extension cable to work well. Would have been way cleaner.

Hoping that dot release on the multiprotocol firmware stays working, and I won't update that HA integration again until there is a must have or I hear this got more stable.

[keen mango]

This is disappointing. I'm sure I'm not the only one who bought the SkyConnect just for multiprotocol.

I wonder if Conbee III would have better luck? Or is it the same chip?

[vast sierra]

I agree. But at least it's sorta working again for me for now. Will see how things evolve over time. I'm trying to stick to thread since I'm fortunate to have just started out recently.

Home came with Zwave thermostats So I have that rolling for those.

[steady forge]

With Thread/Matter I see people are getting too caught up in the idea that they need some sort of USB connected dongle to "control" a device. Use a dongle for Zigbee and any TBR to bridge Thread devices to your LAN and you're good. The ESP TBR devkit board shows that there's really not much to a functioning, simple border router and it can be placed anywhere.

[sick swan]

We haven't given up completely. As @inner torrent mentions, we are dependent on Silicon Labs for the Multiprotocol firmware.

Since we don't have this under full control, and also because in many cases only one side was in use (Thread or Zigbee), and yet other cases separate networks anyways make more sense (large networks, existing third party border router) we decided to adjust our messaging a bit:
https://www.home-assistant.io/blog/2024/01/25/matter-livestream-blog/#using-home-assistant-yellow-or-home-assistant-skyconnect

So your use case seems a valid use case to use Multiprotocol, and please feel free to continue use it as things work for you. We also will continue to work on it. In fact I plan to make some improvements to the integrated OTBR. Once you get a Thread update for that Zigbee device, switching to the dedicated firmware is probably the better choice as you get rid of the complexity which Multiprotocol adds 😅

[keen mango]

That's good to hear. I will personally continue using Multiprotocol

[keen mango]

I also started recently, however Thread devices are still too rare for me to use exclusively. The range and variety of Zigbee devices is hard to ignore.

[elder dune]

Conbee III uses the same EFR32MG21 chipset as SkyConnect. You are going to see every modern 802.15.4 radio using this chipset due to versatility, low cost, and processing power.

[sick swan]

I just want to make expectations here clear: We really rely on third parties here, and I know they work on it. If they really manage to get this going relably, we'll see. Currently, we at Nabu Casa freeze development at this point. Ultimately, we feel that dedicated solutions for Thread-only and Zigbee-only are solid options that work today. We want to give those options a first-class experience first, and that is where we invest resources currently.

[small heart]

Hi my name is Eric and i work for dresden elektronik

just a quick question about the thread integration:

Everytime i try to add a matter device via the android companion app a second thread Network appears.

this second thread network has no border router, but the app trys to commission the device with this dataset instead of the selected one

The second Thread Network appears in the exact moment i confirm click on "Allow Home Assistant to access your Home Network"

has anyone else ever expirienced this ?

[sick swan]

@small heart 👋 hi Eric!

What do you meaen with "a second thread Network appears" exaclty? In the Home Assistant Thread integration network list?

[sick swan]

This indicates that your preferred network wasn't written by the Home Assistant companion app

[small heart]

yes. i can also see in the sniffer, that the devices then sends MLE Request to the PanID of the "Zombi"-Thread NEtwork

[sick swan]

Ah I guess you try to add a device and that fails, that is where the MLE requests get sent?

[small heart]

The Commisioning part works flawlessly.

In my Home setup it also works without issues. But when i use my Test setup at work. The exact moment my test phone clicks on "Allow Home Assistant to access your Home Network" this zombi Thread Dataset appears. And i can see in the Sniffer that the device i try to commission gets send this wrong dataset

the devices then trys to use this Zombi Dataset, so it never joins the correct thread network

[sick swan]

I guess that device just forms it's own network at that point no? 🤔

[small heart]

its not int the network yet

it semms the phone itselfs publishes a mdns meshcop

[sick swan]

Oh wow, I've not seen this no 😅

Do you have a Google Nest Hub associated with that phone?

[small heart]

there used to be one, but i disconnected it months ago

[sick swan]

Hm, maybe that phone still has those credentials stored? 🤔

[small heart]

i removed the device from the Google Home App and cleared all AppData of google Home

[sick swan]

In the HA App, under Settings > Companion App > Troubleshooting > Sync Thread credentials you can force a sync between HA Core's Thread credentials store and the phone's (Thread credentials store provided by the Google Play services to be specific)/

Have you also cleared the Google Play services data? We have that issue in our App that sometimes we can't properly update even our own Thread credentials. This doesn't seem to be the case in your case as the preferred credentials seem to come from another app (since you say the App asks for "Allow Home Assistant to access your Home Network", this means it tries to access credentials written/created by a different App)
https://github.com/home-assistant/android/issues/4146#issuecomment-1911707074

[small heart]

I get a error: "HomeAssistant and this device prefer different networks"

[sick swan]

Yeah so that means that the phone has a different Thread network stored as preferred network.

Other than the workaround linked above, I don't think there is a way to fix this.

[small heart]

This fixed it!

your are a legend

Stay tuned folks CB2 and CB3 Thread-RCP Firmware is comming the next days

[vast sierra]

No doubt - but I gotta bee part of the solution if I can. And I'm not in a hurry to buy a ton of gear.

Window covering from SmartWings are Matter/Thread and working great. Contact sensors exist as well. Would love my Level Bolt to update to Matter already. I have a billion lightswitches to strategically replace - of which Inovelli is crushing the game IMO.

For me, device avalibillity is fine for where im at currently.

What devices are you looking at that dont have a Matter/Thread version?

[vast sierra]

Oh yeah - I know this devices is a partner with a 3rd party.

Part of why I have been trying to find a more appropriate place to bellyache about the SkyConnect specifically - it feels like this entire server is the wrong place. Makes me feel bad for looking ignorant or hijacking a channel

[vast sierra]

Understandable, just a bummer as the thing was billed to do both as a selling point, and is the least supported thing on the stick.

[upbeat cairn]

What specific issue are you having? The SkyConnect is just hardware on its own and any issues are likely with the specific firmware you're running on it.

[vast sierra]

Until yesterday when I bumped the multiprotocol firmware up a path release, I was for over a month unable to commission new devices.

Today I'm back to some devices occasionally not being avalible, but I attribute that to a single dongle, no hardwired thread devices, and 6 battery operated ones, in a ~3000 sq/ft home. Assuming when I get the new White series switches from Inovelli scattered around the house that problem will go away.

[upbeat cairn]

There were issues with a recent multiprotocol update that were fixed last week

[vast sierra]

Yeah - i pulled the stick and updated via browser on my PC

[upbeat cairn]

For the SkyConnect you don't need to do this, the addon automatically installs the correct firmware