thread-archived

[inner torrent]

These are always powered

It's a full replacement for a light switch

[twin vine]

Yeah then perfect placement to be a router

While keeping the form factor of the device not too thick

[inner torrent]

I preordered some; hoping nanoleaf can sort their problems by then 😵‍💫

[digital salmon]

Do these Inovelli switches have a smart bulb mode or do they turn the power on/off?

I am from Europe, sadly no Inovelli here.

[twin vine]

Haha you think it’s bad in Europe, imagine being in Australia 🙄. We haven’t even got the Nanoleaf downlights yet

[inner torrent]

They do have a smart bulb mode

[inner torrent]

You should be thankful we are beta testing them for you for free 🥲

[twin vine]

Do they run the same firmware as the essentals lineup? Or is seperate

[inner torrent]

It's the same

[twin vine]

Ah god…..

[civic cosmos]

is thread support still in beta?

just checking in since i dont have social media or any news feeds

yes wemo and eve have US switches. wemo has a dimmer switch, but they ran into manufacturing issues and i dont know if they have put those back on the market. their on/off switch is on amazon tho. Eve never had a thread dimmer. they have EU and US on/off switches.

oh wait, i misread your comment. you asked about matter over thread not just thread.

eve has added matter support to some of their thread devices but i dont think their switches have been updated yet.

if theres any public way to be kept up to date on thread progress or some feed i could watch for release news when it is available I would love to hear about it. just so i dont have to bother anyone here asking about how its coming along.

[inner torrent]

You can either follow the GitHub repo or just watch the notes in the core release. AFAIK there's no public roadmap

OTBR is still listed as experimental

[civic cosmos]

the core repo?

is there an issue or PR for it atm?

[twin vine]

The OBTR firmware is “independently” maintained by Google IIRC. But you might find a repo somewhere

[inner torrent]

It depends; there's the OTBR itself, the OTBR API, the matter server, and then the matter device command implementations

Are you looking for a specific issue?

[twin vine]

It’s not simple that’s for sure 😝

[civic cosmos]

just trying to stay on top the thread development. now is hass only working on matter over thread support? or is the expectation that thread only devices will eventually be included in that

[twin vine]

What do you mean “only” work on matter over thread

[civic cosmos]

im not that well versed on matter, but my assumption was that since manufaturers are updating their thread radio devices to support matter, then hass matter support wouldnt necessarily mean supporting devices that communicate with homekit using thread. but im no expert so this could just have been my misconception.

[inner torrent]

There's not many thread only devices in the works as that's basically just homekit

[spice imp]

thread is like wifi, matter is a protocol that runs on IP networks

[civic cosmos]

im aware of that much

[spice imp]

So it does not matter for ha if your device runs thread or not

[civic cosmos]

i have a ton of devices that use thread mesh networking and would be excited for them to be HASS compatible

[spice imp]

But what protocol do they use?

[civic cosmos]

currently? the devices i use communicate with thread border routers, which in turn are just homekit hubs.

[spice imp]

so they run homekit?

You can do that with HA too

[civic cosmos]

do what

[spice imp]

control them

[civic cosmos]

i cant control my thread devices on hass afaik

unless you know how i can currently do so. i dont see how you would.

[spice imp]

Yes you can, there is a homekit intigration

https://www.home-assistant.io/integrations/homekit_controller/

[civic cosmos]

oh you mean INSTEAD of adding the thread device to homekit. I can instead choose to pair to HASS with the homekit controller? Ok i hadnt considered that. Ill give that a shot and see how I like it.

do you know if they can appear in homekit using the bridge integration? so its in both places?

[spice imp]

You can also share devices from homeassistant to homekit

yes

Thats what im doing with my eve thermostats right now

[civic cosmos]

ah ok, cool beans

thanks for the info

[spice imp]

There are 2 integrations, homekit bridge and homekit controller

bridge is from ha to apple home

controller is device to ha

[civic cosmos]

yeah bridge ive used.

[tall rampart]

I'm looking to make a battery (CR2032) powered device (with a rotary encoder) that talks to HA. I'm thinking over Thread, but can also do Zigbee. What would be a good microcontroller to use for that? (I know it's slightly off topic, but I figured people here would probably know more than most places)

my Symfonisk rotary knob is dying, and it's discontinued 😦

[knotty citrus]

ESP32-H2 DevKit should work for you. Although I haven't used it myself, just read the announcement news.

Naive question about thread -- let's say I buy a few matter-over-thread devices and a few homekit-over-thread devices. And FWIW I'm only using HA's homekit controller, no Apple Hub (in fact I've no Apple devices at all). So I presume they'll all use the same thread network channel/credentials etc.
Does that form a combined mesh allowing for packets, regardless of their application-level protocol type, to travel over [border router ==> matter device ==> homekit device ==> matter device etc.]? And so I can benefit from all the promised benefits of thread, even though HA has to deal with different application level protocols?

Just thinking -- the availability of homekit-over-thread devices is more widespread today. Is there any advantage of waiting to buy a matter-over-thread devices down-the-road, if my usage is only going to be over Home Assistant ? (Given that my HA + OTBR is well set up now, with you guys' help)

[vapid shell]

Homekit controller maintainer here 👋

First of all, homekit over thread was reverse engineered. The guy that did that work hasn’t submitted any changes for a while now. The most active maintainer is focused on Bluetooth and the tcp (not thread) backend. I barely have any time for big contributions atm (life). Vs matter which has Nabu Casa engineers assigned to it.

Second of all, the homekit over thread protocol is a dead end. Most manufacturers are working on matter, so the bug fixes needed to make homekit over thread stable aren’t coming. At least not fast.

The picture I’m trying to paint here is that it’s a dying protocol and ecosystem. If you need help it’s probably not coming. Matter is only just getting going. If you have problems they might get fixed.

However you can make thread meshes with homekit and matter devices and they will work

[tall rampart]

Yeah, I have a devkit for the esp32-h2 on the way

I was just wondering if say the stm32wb was maybe a better option

[vapid shell]

With the caveat that the homekit firmware might be missing thread fixes from the past year 🤷‍♂️

[vapid shell]

Just to add a bit more to your mental model of thread, ha doesn’t have to know about protocols for thread to route them. It can be helpful to think of thread a bit like WiFi. Where each node is a tiny WiFi repeater. Your WiFi doesn’t need to know what the torrent protocol is for your laptop to download a Debian iso with it.

In fact if you had a ipv6 internet connection there’s nothing stopping your thread device running torrent over thread. Utterly pointless but it would probably work.

More concerning for some is that at some point your door contact sensor could bypass matter and just directly phone home to the vendors cloud over ipv6 or NAT64

For thread, ha isn’t really don’t all that much, just coordinating and sharing connection details between ecosystems and configuring the OTBR daemon. So it really couldn’t care less what data transits the mesh.

One final thing - if you go down the no HomePod route with homekit controller youll need a Bluetooth dongle or an ESPHome Bluetooth proxy to be able to configure the accessory to join thread.

The range can be spotty - be prepared to be 2m away from said dongle with your light bulbs or sockets or whatever

[knotty citrus]

That makes sense. I was only asking due to lack of product availability today, hopefully that improves soon. I suppose if I desperately need any devices, I'm better off taking chances with matter-over-wifi products + spotty wifi, rather than homekit-over-thread products.

[twin vine]

Gotta wait for matter support then

[knotty citrus]

Can you elaborate this some more?
I always viewed thread being a separate physical network as an advantage -- no risk of devices phoning home etc. or me having to worry about my firewall. But from your description it sounds like I do have to worry about this. In fact, the HomeAssistant + OTBR becomes the critical gateway which must implement a firewall.

I'm using the "Open Thread Border Router" addon which does have an option for "OTBR firewall". Is this the firewall of concern -- does it filter undesired traffic from the devices out to the internet?

Also, there's a NAT64 option there -- Should I disable it given my thread network is completely controlled by HomeAssistant and there should be no reason for any ipv4 traffic there ?

[vapid shell]

So in a scenario where your BR is able to DHCP6 your router it can ask for a /64 pool. In that scenario each thread device gets a globally routable ipv6 address out of that pool. Depending on your router connection, such an ip may even allow inbound pings and connections from the internet (it shouldn’t allow connections but some home routers are trash that you can own by sending them udp packets with shell scripts in, so i never assume). And of course outbound connections.

[vapid shell]

See https://openthread.io/guides/border-router#otbr_firewall

I’d need to see the generated rules to be confident in offering my own thoughts on that

[vapid shell]

If you are concerned about phoning home, yes.

[twin vine]

Almost better to leave it disabled

[inner torrent]

I've had issues with the firewall before

[steady forge]

couldn't get OTBR to be stable (with ZBDongle-E), went back to MultiPAN even though its OTBR is pretty old

[inner torrent]

I did a weekend project and put one of espressif's thread border routers into service. Fairly easy project and much cheaper than GLinet's product

Seems to be working okay, only cost about $15

[steady forge]

Does anyone know where configs get stored in the OTBR docker images? All example docker run commands I see have no persistent storage

[twin vine]

Tried /data like most containers?

[steady forge]

that's the folder for multipan, I'll check out silabs own docker image now

[pliant bronze]

Hi folks - can anyone point me in the right direction to get the silicon labs mulitprotocol container running for HA Container? I've tried a few different approaches, the furthest I've been able to get is with the b2un0 image, but it complains about "platformConfigureTunDevice() at netif.cpp:1803: No such file or directory" and never binds to 8081 or 8086.

[stable kettle]

Hi, what’s better to put as preferred, 4k apple tv and homepod mini or openthread HA border router?

[twin vine]

You can merge them

On the iOS app on the latest release

You are able to import the thread credentials from IOS

https://community.home-assistant.io/t/companion-app-for-ios-2023-12-let-s-go/661774

[modern root]

I think mine auto merged maybe. If I view the preferred network on android I only see one home-assistant network with 2 border routers, one being OBTR, other being a google nest hub I setup yesterday. https://i.imgur.com/DpKSg7j.png

Are there any android apps to view your thread network

[twin vine]

Yeah or they were on the same channel

[modern root]

Interesting, just checked on iOS and it shows the same as the above imgur, but if I select import credentials it says "No preferred network found"

[twin vine]

Do you have any Apple border routers?

HomePods/Apple TV 4k’s?

[modern root]

No, just the OBTR and nest hub

[twin vine]

That’s why you can’t import any Apple BR’s then

[inner torrent]

Depends what you mean by view, most topology viewers don't work well

[modern root]

yeah I guess a topological view, would be nice if it could view vendor/device info more than the OBTR topo view

[twin vine]

You can, just need to map the node ID to the device yourself

[zinc isle]

Hi. I have an issue I wanted to see if anyone else was experiencing. I currently have a handful of Thread devices (Aqara P2, 4 Nanoleaf bulbs running the latest beta firmware, and an Eve energy sensor) connected using Skyconnect, the Openthread border, and the python-matter-server all running under Podman in a VM. All in all things are pretty stable (9 out of 10 times responds as expected). With that said things go downhill very quickly if I plug in two nest hubs (Nest Hub (2nd gen) / Nest Hub Max). They're all on the same thread network. Long story short I had them all in the same thread network originally and kept having random issues with devices going unresponsive and figured I'd try to remove pieces and at this point I can reliably say these seem to be the source of my issues. Is anyone aware of any sort of incompatibility with them or experienced similar behavior?

[vapid shell]

So none of these have TREL. That means it’s up to Linux to figure out which BR to use. But at the ipv6 level there’s no way for anyone to know which BR is best.

So adding weakly interconnected BR can just add instability to your mesh.

Partitioning, interference, signal strength could easily be a factor.

Worse if you are using podman that likely means you aren’t using haos so you don’t have the ipv6 network stack the ha devs tuned for thread

Without that you can easily see random 30 minute outages because of the build up of stale up addresses

[zinc isle]

That makes sense at least in the worst kind of way 🙂 The Nest devices are definitely further away than the Skyconnect (although not extremely far so I would think it'd still have some amount of connectivity). Frankly I'm perfectly fine with only having the one border router...do you know if there's any way to disable the thread functionality on the nest devices?

[twin vine]

Nope

[zinc isle]

That's unfortunate. I guess I'll just leave them unplugged for the time being or see if I can find a way to force them onto their own thread network and just just ignore them.

[inner torrent]

By default, skyconnect forms it's own thread network. Maybe by reflashing the firmware / resetting the OTBR addon you could have it revert to the HA thread network then plugin your hubs

That way your skyconnect won't be on the nest thread network

[vapid shell]

You wouldn’t be able to use the android app to provision matter devices then, because you need to sync the credential into google land and there can be only one.

When the UI for provisioning devices directly in Ha (without android or iOS) is ready that is absolutely the way.

And if you feel like poking the internals from the shell?

[zinc isle]

Yeah that's a good point. I know I did some jumping through hoops to get them onto a singular thread network as that was giving me problems trying to pair devices initially since I had the two different thread networks.

[steady forge]

Just ordered a esp border router board off of AliExpress. Thanks for the hint! Can't get the Silabs stuff to work reliably

[twin vine]

Good luck 🙏

[inner torrent]

I just used the espressif devkit BR example and went from there. My only issue was I couldn't preconfigure the thread dataset, but I was able to join it to my existing network after I flashed the FW

[fickle mantle]

Does the 2023.12 iOS HA Companion App now support Matter commissioning onto an HA Thread network? I didn't see anything in the announcements, so assuming no, but wanted to ask anyway. Thanks.

[spice imp]

You can import your Apple thread network with the beta(maybe the normal realease too)

But not comission it to a thread network defined by ha

So no

(As far as i know)

[steady forge]

Doesn't work for me with OTBR

[fickle mantle]

In the Community Forum discussion on the 2023.12 iOS HA Companion App, one user had HA SiLabs as Thread "preferred" network along with Apple TBRs (not preferred), and using the new import Apple Thread credentials/dataset managed to get both SiLabs and all his Apple TBRs on the "preferred" network list. Since the SiLabs Thread network was already preferred, did the Apple Thread network change/migrate to match the SiLabs Thread credentials/dataset? Does the iOS HA Companion App push/write the SiLabs credentials/dataset to the Apple TBRs?

[twin vine]

If I remember correctly, the OBTR joins the Apple one

[vapid shell]

https://www.home-assistant.io/blog/2023/12/27/companion-app-for-ios-202312-lets-go/

You can now import your Apple Thread credentials into Home Assistant and then make Apple the preferred Thread network.

Hard to know what that person did without seeing a screenshot of their thread integration. But I’d agree with @twin vine based on ^

Of course probably a mistake of them to do that as technically makes their mesh less stable until the trel update for OTBR is out 🙂

(Disclaimer about mesh interconnected-ness and wall thickness)

Iirc Apple needs at least one HomePod or appletv to be the home hub?. So there isn’t really a scenario where they’d let you bring your own BRs only. At which point, having your Apple products join another mesh is a bit of a weird scenario for them I guess…

[twin vine]

Clearly it works, but I’m not to sure if they ever intend it to be more mainstream..

There is just so much that could (at-least at the moment) go wrong, that is is no doubt just not worth the hassle…

[vapid shell]

I said it before but thread reminds me of WiFi here. You would expect your iPhone or laptop to work with a netgear mesh or a UniFi mesh. But you wouldn’t expect a UniFi mesh to mesh with a netgear mesh. And I think the big vendors thought that’s how this would pan out.

They thought they’d each own their own control plane

And the data plane would be compatible

[twin vine]

They are allowing some third party devices to be a BR, (like Nanoleaf shapes). But I feel it’s just going to be a case of a everyone controls their own set of devices that they “work with” (aka Apple and Nanoleaf)

[vapid shell]

Yeah - was pretty clear when I did that with the nanoleaf it was a second class citizen

There was a different term for it in the ui

Was it “external br” or something like that?

I wouldn’t be surprised if the Apple clients didn’t even bother to use external brs unless all the others were unreachable

[twin vine]

I guess then they can control the experience of it. And it’s prolly not a bad thing

[vapid shell]

Yep

💯 that

Delegating such an important part of the matter experience to something they don’t control? Who fixes it when it breaks etc. When you think about it like that, I’m surprised interoperability is not an even bigger **** show

[inner torrent]

Ironic considering the app doesn't even use matter

[twin vine]

Just look at the early days of the matter server vs Apple Home (and its experience)

The countless logs of Apple hiding/masking the fact the device may not be responding by just delaying/increasing the time until its confirmed, while HA had it as almost immediately

[twin vine]

The Apple Home app?

[inner torrent]

No, the nanoleaf app

Unfortunately I feel like I know more than I care to about their stuff 🥲

[twin vine]

Ah yep, I’m sure that won’t bit them on the ass a few years down the track 🙄

[steady forge]

finally found this after sifting through github... it's /var/lib/thread for anyone interested

[obtuse harness]

I have a thread network with the two homepod minis in my room but the connection to the led strips in my room is really slow or not even available

[digital salmon]

Let me guess…, you’re talking about Nanoleaf strips.

[obtuse harness]

surprisingly the nanoleaf strip is the only one thats working

[knotty citrus]

I'm curious what were your issues? I got my ZBDongle-E to be very stable with ot-rcp firmware & OTBR addon. Granted I only have 2 devices on my thread network so far, but it's been super stable.

[digital salmon]

Ok, which led strips are you talking about?

[obtuse harness]

They are from meross idk which ones

[digital salmon]

There don't seem to be any Meross Thread LED strips on the market. Please state the exact model. Otherwise they are connected via WiFi.

[obtuse harness]

Msl320 pro

[inner torrent]

It says on the website that those are WiFi

So could just be spotty WiFi?

[steady forge]

I've identified multiple issues so far:

• MultiPAN crashing
• OTBR crashing (ot-rcp firmware) with rx failed logs -> but this is on RPI3 with HAOS on USB Stick so I suspect it's due to the poor USB stack being overloaded on the pi, haven't seen it yet with OTBR docker on a DietPi install from microSD and/or HAOS VM with the ZBDongle passed through to it
• When switching from MultiPAN to OTBR I've encountered issues when using Alexa app to join the new thread network -> it just goes back to the network key entry even though I'm not reusing anything from the previous dataset (new PAN ID etc.). This seems to clear up when power cycling both my iPhone and the echo devices in my house, I guess it's just stale mDNS
• the Onvis S4 plug seems to be the major issue though as with every combination I've had the same instabilities and reliability issues so I'm sending it back and a used Eve Energy is on the way to me so I can at least rule out bad thread implementation on the client side
• ot-rcp-2.4.0.0 (built against Gecko SDK 4.4.0) for ZBDongleE which you can find on the 4.4.0 branch of darkxst's github seems to be more stable than older versions but it's hard to say for sure

I also have a used Nest Hub 2 (for a tried and true border router with 5GHz Wifi) and ESP border router board (I just know it's gonna be flaky with 2.4GHz Wifi but at least there's a coexistence component) on their way to me if issues continue with the Eve Energy device. I really want to get to the bottom of this and it's been fun troubleshooting!

Also I have to say the "matter deep dive" blog series that's pinned on #matter-archived is truly amazing

[obtuse harness]

The device is next to a repeater. But maybe its still trying to connect to the router

The meross light strip is getting 72mbit/s

And is connected to the repeater

[inner torrent]

Hard to say, but sounds most likely like a network issue, particularly if your thread devices work fine

[arctic shore]

Thanks to all on HA and specifically Thread/Matter

its progress is nothing short of astounding

I can Pair a Thread device with HA without a proxy device - ALMOST -

I get a HA Gui error on mobile at the end of 'Registering with HA' - But the device is registered in HA and functioning

[obtuse harness]

the homepods work fine but when iam in the thread settings (HA) it always says no devices and when i press configure the two homepods show up after like 1 second (in preffered network)

[inner torrent]

That's normal

It's because the thread integration doesn't expose any entities or devices that you can interact with so it shows as "no devices"

[obtuse harness]

ah alr

Would it be better to just use an esp8266 as a controller?

The nanoleaf strip works nearly without delay now

lol

i just pressed a preffered thread credentials button

and the meross smart plugs also work without issues

even tho the smart plug is on another story

[inner torrent]

I don't think it's a matter controller problem so that wouldn't help

You could diagnose it by just pinging the device and comparing it to ping on your thread devices

[obtuse harness]

how do i do that

[bronze fog]

Thanks for the compliment on my blog series! Took a ton of work!

[steady forge]

Damn... OTBR crashed again after 24hrs without any thread devices attached... https://dpaste.org/2vjQC

[upbeat cairn]

What stick + firmware are you running?

[steady forge]

ZBDongle-E with OT-RCP
so far this happened with 2.3.1, 2.3.2 and now 2.4.0

next test setup will be a HAOS VM running the official OTBR addon, also without devices connected

[inner torrent]

I wonder if it's related to sonoff 's firmware

I run both silabs and espressif and have had 0 problems

[steady forge]

me too, maybe skyconnect fares better due to hardware flow control

[inner torrent]

Could try either a skyconnect, or the espressif board or the Nordic dongle

[steady forge]

espressif board is on its way to me from China 😄

[upbeat cairn]

Are you doing anything specific to reproduce this? Or does it just happen with no Thread devices, after letting the stick run for a while? Does restarting the addon help?

[steady forge]

It happened with and without extension cord on HAOS (from USB stick, addon) and DietPi (from microSD, official otbr docker) on an RPI3 by just letting the system idle for less than 24hrs

restarting the container works, although I've also had to power-cycle the stick once to make it work again

[upbeat cairn]

What happens if you leave it in the HandleRcpTimeout() at radio_spinel.cpp:2066: RadioSpinelNoResponse state?

[steady forge]

when using the haos addon it stops, the standalone openthread/otbr docker just keeps running with no further log output

[upbeat cairn]

So if you were to enable auto-restart for the HA OS addon, it would? Or would it hang until you unplug the stick?

I'm trying to see if this is a firmware-level problem that causes it to lock up

[steady forge]

as far as I could tell it would, just once I had to physically power-cycle the dongle. Next time this happens I'll try to just start the addon again (I'm on HAOS now)

[upbeat cairn]

Thanks! Ping me if you get it to happen again, I'm trying to track down all of these issues so that they can be fixed

[steady forge]

Thanks! I'll keep testing. What's of more use to you? This happening on the latest OTBR docker or current HAOS addon?

[upbeat cairn]

The HA OS addon. We have some patches on top of OTBR so they differ slightly.

[steady forge]

I should have a thread device available again tomorrow so production use testing can continue

A specific firmware you want me to use? Currently SL-OPENTHREAD/2.4.0.0_GitHub-7074a43e4; EFR32

[upbeat cairn]

The latest is fine, which is what I think you have

[steady forge]

yeah it's from Gecko SDK 4.4.0

[spice imp]

Has someone experimented with stopping devices from trying to access the internet over IPv6 and whats the most reliable way to do it? Having your own dns server and disabling all AAAA records?

[vapid shell]

With some of the HomeKit devices they actually hard code the dns server to 9.9.9.9 and others 🙄 and red blink angrily if you block them from having internet access (despite working perfectly with local only homekit access).

[spice imp]

For me its more the devices that have access to the internet that are trying to use IPv6

Even though they just get the ipv6 address from my thread network

[twin vine]

what devices do you think are calling home?

[vapid shell]

I gave 9.9.9.9 as an example because in on my phone. Point was more I can’t see how you can do it short of blackholing the entire /64 at your internet gateway (and turning NAT64 off on your br)

[spice imp]

The problem is not the calling home, but fx slow loading of websites when browsing the internet

or my tv not wanting to open netflix and so on

[twin vine]

are you sure thats an issue with thread?

[spice imp]

Disabling IPv6 pr devices helps

[twin vine]

hmm right

[spice imp]

Yes, im guessing its just shitty implementations. But i was more thinking if there is a better way to do that thats not on a pr device basis

[spice imp]

i dont even think there is any Nat64 thats usable running on my otbr

(apple homepod)

[vapid shell]

It’s an option on the haos OTBR now, default off, no idea what the others do.

[spice imp]

Well i cant access the internet over IPv6

[vapid shell]

But that answer was based on idea of some IoT sensor phoning home, not your tv Netflix being flakey.

NAT64 is for accessing ipv4 internet over ipv6 mesh so not relevant

[spice imp]

Yeah, i get that

[spice imp]

So the nat64 doesn't route ipv6 traffic thats not coming from the mesh?

So the solutions could be: setting up my own nat64, telling my isp to get their shit together or start using vlans to avoid my not thread/matter devices getting an ipv6 address

[vapid shell]

if your motion sensor wanted to talk to 8.8.8.8 it would just put that ipv4 address at the end of a well known IPv6 /96 prefix. And then the BR would do “normal” NAT. To 8.8.8.8 on behalf of the motion sensor.

So you’d have to steer traffic for that /96 to your Br to get it NAT64’d

Which is unlikely to happen for your Netflix

[spice imp]

true, forgot about that part of nat64

But yeah, what i think is happening that my devices try to get a response on the ipv6 address for websites and then fallback to ipv4

I had a lot of problems before with all websites loading super slow on my pc

And the problem completely disappeared once i turned off ipv6

[vapid shell]

I have ipv6 turned off on my core network gear for similar reasons.

HomePods and HA are on a vlan anyway so do their own local ipv6 fun on there

[spice imp]

same with one of my tv's, once i set and static ipv4 address and no ipv6 its behaving okay again

[vapid shell]

And core router ignores it

[spice imp]

What networking gear are you using?

[vapid shell]

Was Unifi but router did a magic smoke so currently running openwrt till I figure out what’s next

[inner torrent]

I had that problem but some of it seemed to be alleviated by DNS cache (but maybe placebo)

[spice imp]

i could instantly feel the difference. It was driving me insane before

100% its not placebo

[vapid shell]

Did have some trouble with Tailscale and that turned out to be the k8s dns server running IPv6

Can’t remember what i did about that

[spice imp]

mikrotik? 😄

[vapid shell]

Given the number that seem to be p0wned at any given moment I haven’t even looked to see how much I would hate that

[spice imp]

Of their routers? Or are you talking about something else?

https://www.cvedetails.com/vulnerability-list/vendor_id-12508/product_id-23641/Mikrotik-Routeros.html
That does not look as good as their prices 😅

[vapid shell]

https://www.microsoft.com/en-us/security/blog/2022/03/16/uncovering-trickbots-use-of-iot-devices-in-command-and-control-infrastructure/

They basically built a cdn out of infected microtik devices 😂

[knotty citrus]

I'm using ZBDongle-E with firmware ot-rcp-v2.3.2.0-zbdonglee-460800.gbl haven't tried the newer versions yet. And I'm using Onvis S4 smart-plugs as well -- I've one plug roughly ~5ft away from the dongle but through a wall and bunch of wiring. And the 2nd plug is placed ~20ft away through 2 walls.
My setup has HAOS running inside a VM on bare-metal ubuntu on a really old x86 laptop. I've both 2.4GHz & 5GHz wifi setup through a single TPLink router (whatever little interference that'll create). I don't have any other thread border routers or devices. Whole setup have been very reliable since I had it up.
I'm guessing that your main issue is like the RPi's weak performance/USB-stack, because reset of your setup looks very similar to mine.

[steady forge]

very similar indeed, it's interesting that we have such a different experience with roughly the same setup, I've had the same issues (especially with the onvis plug) on a HAOS VM aswell so I would rule out the RPi as the culprit

maybe the dongle itself is defective

[inner torrent]

I doubt it's the RPI, that's what I run my HAOS on and I have no problems

However I did have a problem wherein OTBR would just stop -- it ended up being a faulty USB extension cable

[knotty citrus]

Can you elaborate this a little more on how to do this -- I was well versed with IPv4 and subnets etc., but IPv6 is confusing for me.
I do have OpenWRT setup and a separate separate Wifi for IOT devices. But since all of thread devices are under HomeAssistant VM which is on my main server with full wifi access, I'm not sure how to isolate the thread network to block internet.

[steady forge]

i have another usb extension on the way aswell... with all these packages it's getting progressively harder to explain to my wife lol

[knotty citrus]

I am not even using extension cable -- from what I understand, it's the USB 3.x stuff that causes interference; but my laptop is so old, it doesn't have any USB 3.0 ports 😅 , so I guess it doesn't trouble me much.

[inner torrent]

I'm also interested in this but I don't think there's firewall rules yet for ipv6 for vlans... Unifi is very primitive. I tried defining some manual rules and using prefix rules but they never worked

[inner torrent]

Just be glad you don't have 15 nanoleaf bulbs for your wife to complain about 🫠

[steady forge]

Ouch!

That's why I left my tried and true zigbee2mqtt setup untouched with a separate dongle 😂

[knotty citrus]

The VM was running on RPi itself or some x86 or other machine?

If you have a spare laptop or desktop lying around, maybe you should trying running HAOS under a VM with USB-passthrough and see if that's more stable? At least that'll rule out whether it's the machine & software setup or it's the HW / network / local interference etc.

[steady forge]

VM is running on my UnRAID server

[knotty citrus]

And there you had issues for stability or did it fail the setup/commisioning step itself?
Also, did you use the cable to distance it from the PC / USB ports ?

[steady forge]

stability/reliability

especially with onvis it was very unstable

[knotty citrus]

Have attempted to change the channel being used for thread network? Maybe your area just has too much interference on specific thread channel

[steady forge]

yeah tried channels 15, 20 and 25

zigbee is pretty rockstable on 25 here

I need to go to bed. I'll check the logs in the morning to see if it crashed again 👍 Good night

[knotty citrus]

FWIW, to compare, I've OTBR addon v2.4.1, Matter Server addon v 5.0.1, HA v2023.12.4.

[fresh nymph]

Attempting to import thread credentials with HA using my Apple home border routers. I am getting an error 74. Is this a permissions problem?

[twin vine]

Ask in #ios_and_mac-archived

[steady forge]

Did you guys ever find yourself in a situation where you just can't connect a device to a thread network despite having the setup working before? I've rebooted everything, wiped all settings and it just won't pair anymore

[inner torrent]

Yeah unfortunately the moon wasn't in proper alignment

[steady forge]

It seriously feels this way lol

[split sapphire]

When I start up the OTBR add-on I get InvalidArgs errors w/ IPv6 setup. Does anyone have any ideas on what I could do to troubleshoot this?
otbr-agent[183]: 00:00:00.072 [N] Platform------: [netif] Changing interface state to up. otbr-agent[183]: 00:00:00.079 [W] Platform------: [netif] Failed to process request#2: No such process otbr-agent[183]: 00:00:00.080 [W] Platform------: [netif] ADD [U] fe80:0:0:0:ecbb:fe4b:6241:9440 failed (InvalidArgs) otbr-agent[183]: 00:00:00.080 [W] Platform------: [netif] Failed to process event, error:InvalidArgs otbr-agent[183]: 00:00:00.080 [W] Platform------: [netif] ADD [U] fdc9:b83e:d0a4:92ed:2046:87ae:f893:5d85 failed (InvalidArgs) otbr-agent[183]: 00:00:00.080 [W] Platform------: [netif] Failed to process event, error:InvalidArgs otbr-agent[183]: 00:00:00.080 [W] Platform------: [netif] ADD [U] fdc9:b83e:d0a4:92ed:0:ff:fe00:9800 failed (InvalidArgs) otbr-agent[183]: 00:00:00.081 [W] Platform------: [netif] Failed to process event, error:InvalidArgs otbr-agent[183]: 00:00:00.081 [W] Platform------: [netif] Failed to process request#6: No such process

I'm running HAOS in a Proxmox VM. OPNsense on the same host. All devices (including android phone) running on same untagged LAN network interface. I am able to ping HAOS from PC and phone using IPv6 address. The only thing I can think of is OPNsense firewall rules are interfering, but I have the default allow all IPv6 LAN to LAN rule enabled, which should open everything up.
I also tried installing the add-on on my Dell OptiPlex and received the same erros.

I'm using the skyconnect as well. I understand that it's not recommended and still in beta, but it's the only option available to me at the moment and I don't forsee myself getting any of the other TBRs that are available.

Full log: https://dpaste.org/b7vcY

[spring bramble]

Did you already disable OPNsense ? Also make sure that OPNsense may not be between the matter server and OTBR. This must all operate on the layer 2 and nothing may be routed.

[sick swan]

Using Android App?

[split sapphire]

When you say disable OPNsense do you mean shut down the VM? I think that would bring down my whole network and then I wouldn't be able to reach HAOS from my PC and phone. The Thread OTBR and Matter server are both set up as add-ons in HAOS, so there shouldn't be anything between afaik.

[split sapphire]

Yep

[spring bramble]

I'm repeating myself here but there should be no firewall in between the OTBR and matter server and your network - so your phone should be able to reach both matter server and OTBR without any interference

So I'm 99% sure that OPNsense is your issue

[split sapphire]

I agree, OPNsense must be the issue here. I'm just not sure how to get around it other than getting a dumb router and reconfiguring my network. Is that what you're proposing or is there another option here?

[spring bramble]

I still dont get what why your router is between your phone and your matter/otbr server

Also, its a bit scary to run your home router/firewall on a VM isnt ?

[vapid shell]

It’s a quite popular way to run pfsense

[split sapphire]

Yes, terrifying. Thought it would be easier then it has been, but I've learned a ton the last month and I think I finally have running pretty stable. Definitly some groing pains.

[split sapphire]

This might just be a misunderstanding.

[vapid shell]

I used to do it on esxi because I didn’t have the hardware

I got rid of it as soon as I could

[spring bramble]

maybe I'm just always messing too much and scared that I wipe my home internet connection (and have some angry family members) 😂

So I just run a hardware router/firewall

[vapid shell]

I was scared of trusting esxis network stack

[sick swan]

@split sapphire I was answering to Xploder, since he said that he has issues at times with Thread as well.

[spring bramble]

Yeah, that is what I hope beause if it sits between it will explain why it doenst work

[sick swan]

@split sapphire what is your issue exactly? Not quite clear to me.. 😅 I don't think the errors you pointed out are problematic, this is related to the virtual interfaces on HAOS.

[vapid shell]

Both the host that run that and the hardware router that replaced it have now blessed me with magic smoke 🙄

Hasty openwrt is working fine with thread tho 🙂

[split sapphire]

I am trying to pair an Inovelli matter switch to HA. It's my only matter device and I just set up the skyconnect yesterday, so unfortunately I don't have a great baseline to see if it's a device vs OTBR vs IPv6 issue. When HA initiates the pairing sequence it is able to find the device, connect to it, configure it with matter credentials, but then erros out on the "checking network connectivity" step and returns an error stating "can't connect to thread network home-assistant. check that your device can work with this network type and try again"

[vapid shell]

Dumb question, sorry if already asked, are your phone, the SkyConnect and the inovelli all close together? Like same room?

[split sapphire]

Will HA pair any matter device or is there a certification process that limits which devices are compatible? I ran into that problem trying to pair it to Google Home

[twin vine]

and the logs... https://dpaste.org/b7vcY

[twin vine]

what border router you got for google home? nest hub?

[sick swan]

Can you check in the App under Settings > Companion app > Trobleshooting > Sync Thread credentials. What is it saying after running the sync?

[split sapphire]

They are not that close together, maybe 15 meters with a couple walls in between, but I was assuming that since the pairing process breezed past the "connecting to device" stage that this meant it was close enough. Is that a fair assessment? Or is the phone connecting to the device in that step? Sorry for the stupid questions here, this is my first time delving into matter/thread.

[vapid shell]

The phone connects via Bluetooth to upload the thread creds

So there’s always the possibility that the device has a weak or non existent connection to the br

[split sapphire]

I was using the same OTBR. I didn't think that was possible but gave it a shot for giggles, and was suprised it made it past the first few stages of the pairing process. Guess I was mistaken here as it was just the bluetooth process that was making it that far.

[twin vine]

Oh, only the skyconnect? rightio

[split sapphire]

Let me see if I can the skyconnect closer to the switch. Unfortunately I can't move the light switch nor can I move the router, but I can try it again on the dell optiplex from a different room.

[twin vine]

you using the usb extender dongle with the skyconnect?

[vapid shell]

The router shouldn’t matter. You can get a really long usb cable for the sky connect

[spring bramble]

The range of the skyconnect is pretty limited, especially if its in a suboptimal place like the utility closet and has some interefrence from usb3, zigbee, wifi etc. so 15 meters with walls is definitely a bit far

[split sapphire]

Yeah but it's only a foot or two long. I think I have a longer one available somewhere as well, or I can use the one that's running my z2m setup. But I can move the optiplex a few feet away so that's probably best option just to be 100% sure it's not a distance issue.

[split sapphire]

I'll test this when I get everything back up and running. Thread network is down at the moment due to troubleshooting.

[graceful gull]

Hi all! I have a problem with connecting a Nuki 4.0 lock via thread+matter to Home Assistant
While I'm not new to home automation, I'm new to both zigbee and thread
I have a ZBDongle-E flashed with the MultiPAN firmware. I was able to configure it via the multiprotocol addon and add a few zigbee devices (IKEA buttons, LIDL-branded LED bulbs)
Now, I would like to add the Nuki 4.0. I have the OTBR and Thread integrations which were created automatically by the multiprotocol addon, and I have also created the Matter (BETA) integration, which in turn installed the Matter Server addon

Now, when I try to add the lock via the android Settings -> Google -> Devices and sharing -> Matter option, I'm getting something along the lines of "Thread border router required. Add the router to your network and try again". When I try to do it via the Home Assistant app, I'm getting "Something went wrong. Try again"

What could be some possible reasons of that?

[split sapphire]

After running the sync it was successful and said "Updated network from home assistant on this device". Tried to repair and errored out again on "checking network connectivity".

Unfortunately the issue persists after moving the skyconnect to a meter away from the light switch.

I should clarify that I am beta testing an unreleased switch. All other beta testers were able to pair it with OTBRs from Amazon Echo, Apple Home, etc., but I'm the first to try directly with skyconnect. Is it possible that the issue lies with the device's firmware? Or is it fairly universal whereas if it can pair with other OBTRs it should pair with HA/skyconnect as well?

[twin vine]

honestly, it could be diffrent if you had a google nest hub. as you could share it to ha from google home

[knotty citrus]

Don't trust that message, I was misled by it too. For whatever reason, Google caches the thread credentials and doesn't honor the "update" that HA's companion app is attempting to do.

[split sapphire]

Yeah that's the recommended route, and a few other beta testers had success pairing them with Amazon Echo and then to HA.

[knotty citrus]

@split sapphire see the message I replied to.

[twin vine]

damn, good news coming from amazon echos? amazon must of stepped up their game

[split sapphire]

Sadly I don't have an Echo with the OTBR capability and am trying to avoid going that route for privacy reasons. Local only voice assistant FTW

[spring bramble]

If you use an apple homepod (mini) as BR, HA is only using that for network communication, Apple wont have access to your devices/data.

[steady forge]

issues with both iOS Alexa/HA apps and Android Alexa/HA apps

[knotty citrus]

@split sapphire Easiest way to know that the credentials actually got updated : Rerun the sync credentials and it should report Home Assistant and this device use the same network. If you don't see this, your credentials are wrong and any attempts at commissioning a new device will fail. You may need to reset the Google Play Services app's storage & cache to fix this.

[split sapphire]

If I clear storage, will that clear out all my settings and configurations, such as the varios HA servers that are connected and what sensors are exposed?

[knotty citrus]

You need to clear the storage & cache for "Google Play Services" app and not the HA app, so it won't affect anything on Home Assistant app or anything else. But it'll remove all the credit cards and other things stored in the Google Wallet. See here (follow Step 2): https://support.google.com/googleplay/answer/9037938?hl=en

[split sapphire]

I cleared the cache and am still receiving the "Updated network from home assistant on this device"

[split sapphire]

Ohhh ok. I can try that.

Oof, I think I might end up regretting that one. My watch instantly disconnected from my phone. Hopefully I can get it back without factory resetting the watch.

[knotty citrus]

A side note -- do "configure" your "Thread" integration on the HA's server. In a simple setup, you should see "home assistant" thread network associated with your border router, and you may need to use the three-dots menu to select that network as "Use for iOS + Android credentials". In more complex setups with many thread networks from Apple or other hubs, you may see others listed too.

[split sapphire]

Gotch, mine shows "Used for Android + iOS credentials" and is greyed out, so it appears that is configured correctly.

[knotty citrus]

At least my naive understanding is, thread network is kinda similar to Wifi SSID and it is critical to get everyone on the same network to interact. It's a shame that Google & other vendors don't just let us select the right network but instead try to set it all up & hide it behind the scenes, in the name of convenience. Likely the main reason why setting up Thread is such a confusing cluster-f.

[split sapphire]

Is there a tutorial for how to set up the skyconnect as a thread-only border router and cofigure HA with the OBTR and Matter add-ons? I wonder if I'm missing something somewhere along the line. I initially followed the skyconnect multi-protocol setup tutorial and then moved to thread only and had to improvise from there.

I was finally able to get past the "checking network connectivity" step and made it to "Connecting device to home assistant", but then it errored out and said "something went wrong".
Screenshots: https://imgur.com/5vo6Dmw https://imgur.com/iBw3WE6
I don't see any new logs in the OTBR. Matter add-on has this though:

https://dpaste.org/WUDNq

[knotty citrus]

Not to my knowledge. Here's the rough steps I followed (I used ZBDongle-E instead of skyconnect but they're similar):

1. Get the ot-rcp firmware installed on the dongle.
2. Remove the multiprotocol addon, OTBR addon & integration, Thread integration, Matter addon, and reboot Home Assistant machine itself. This step is likely optional, but my original setup franken-setup somewhere and I couldn't get the integratinos and addons talking to each other, and doing this afresh helped.
3. After rebooting, install OTBR addon -- it should also automatically install OTBR and Thread integrations. Also install the Matter Server Addon.
4. Go to the "Thread" integration and configure the network such that you've a "home assistant" as primary network associated with 1 border router, and it is used for iOS+Android Credentials
5. Use the Android app => Settings => companion app => Troubleshoot => Sync thread credentials. You should see Home Assistant and this device use the same network. Debug/Troubleshoot logs etc. until you see that message.
6. Now attempt to commission the device using that phone -- ideally it should just work (for me it did).

[split sapphire]

It looks like step 5 was able to get me past the "checking network connectivity" phase, but it still errored out after that. I am finally receiving the "Home Assistant and this device use the same network" message when I sync thread credentials

[knotty citrus]

Your matter log does show an error while commisioning -- might be something wrong with your network; but I'm beyond my depth here. Might be worth chasing it down on #matter-archived to see anyone knows more there.

One thing to check is whether mDNS is working as expected and you can actually discover things from your phone. You can install Services Browser app and check if you see the _matter._tcp. (originating Matter Server) and _meshcop._udp. (originating Thread Border Router) are being listed.

Read the 3 part blog series here for reference: https://www.derekseaman.com/2023/10/part-1-smart-home-matter-and-thread-deep-dive.html

[split sapphire]

Funny enough, Derek's actually beta testing these switches as well and said numerous times not to try sky connect as it wasn't ready. Prob should've listened to him

[bronze fog]

Yes...not ready 🙂 (Derek here)

@spring bramble 2024.1 with Matter 5.0.2 has fixed the endless errors I was seeing on my network.

[split sapphire]

You just been watching this thread laughing your butt off haven't you

[bronze fog]

Well with Matter, reading the fine print on what's supported is ...um.....key?

[split sapphire]

I had to try something. Not entirely sure why they threw me on here without seeing if I had a matter/thread network up and running

[tacit dirge]

Any benefit to matter beta?

It should be ok to run on 24.1 right

[vapid shell]

I don’t think there is a beta version right now, got promoted to stable on Wed

[old merlin]

Hi, I'm having some difficulties setting up open thread on my HA yellow with skyconnect.
I see these in the logs

otbr-agent[184]: 00:00:33.191 [W] Platform------: [netif] Failed to process event, error:InvalidArgs
otbr-agent[184]: [NOTE]-BBA-----: BackboneAgent: Backbone Router becomes Primary!
otbr-agent[184]: 00:00:33.838 [W] Platform------: [netif] ADD [U] fd71:d86e:5dde:8f04:0:ff:fe00:fc38 failed (InvalidArgs)
otbr-agent[184]: 00:00:33.838 [W] Platform------: [netif] Failed to process event, error:InvalidArgs
otbr-agent[184]: 00:00:33.840 [W] Platform------: [netif] ADD [U] fd71:d86e:5dde:8f04:0:ff:fe00:fc10 failed (InvalidArgs)
otbr-agent[184]: 00:00:33.840 [W] Platform------: [netif] Failed to process event, error:InvalidArgs
otbr-agent[184]: 00:00:35.252 [W] Platform------: [netif] ADD [U] fdcc:3aa3:410a:1:f917:133a:2373:c3fd failed (InvalidArgs)
otbr-agent[184]: 00:00:35.252 [W] Platform------: [netif] Failed to process event, error:InvalidArgs
otbr-agent[184]: 00:00:44.030 [W] Platform------: [netif] ADD [U] fd71:d86e:5dde:8f04:0:ff:fe00:fc11 failed (InvalidArgs)
otbr-agent[184]: 00:00:44.031 [W] Platform------: [netif] Failed to process event, error:InvalidArgs
I tried googling and looking through past issues but I couldn't figure it out. Would anyone be able to help me out?

[steady forge]

Somehow the iOS keychain saved thread credentials from an old OTBR setup of a network that doesn't exist anymore and when I'm hitting the Import Credentials button on the iOS app it tries to get my Nest hub to join this network. Is there any way to clear this? I've already removed my home completely.

[old merlin]

Did anyone figure out how to get an eve thermo (or any other eve device) to switch to thread router that comes with HA yellow?
(without an apple thread router like homepod or tv)

[twin vine]

It’s possible, but is hard. What phone do you have? iPhone or android?

[old merlin]

iphone

[vapid shell]

In general it’s a 3 step process. 1 - Use the iPhone companion app to sync your Apple thread credentials into Ha

2 - Pair the eve thermo over Bluetooth

3 - There will be a button in its device page you can push to migrate it to thread

And you don’t need that first step if you have just an OTBR

As ha already knows the thread credentials

[old merlin]

2 - Pair the eve thermo over Bluetooth
Do I pair it using my phone?
3 - There will be a button in its device page you can push to migrate it to thread
Is this button in the Eve application or in another place?

also, when I press the "Import Credentials" button under the "Thread" service, it says "No preferred network found"

[twin vine]

Iirc, you need a thread network from a HomePod/Apple TV, hence why you don’t have a “network”

[old merlin]

but it does say "Used for Android + iOS credentials" when I press the 3 dot menu

not sure what that means

I tried to attach a screenshot but channel is not letting me

If I create a new network, I can select "Use router for Android + iOS credentials". Which it than displays a phone with a key icon on it. Is that maybe what you mean?

[vapid shell]

Don’t pair it to your phone

You can only pair it to one thing at once

That needs to be HA

The button will be in Ha

Don’t worry about that until you can control your Eve thermo in Ha over Bluetooth

It will become obvious when you can do that

[old merlin]

okay, but my HA doesn't have bluetooth I think

[vapid shell]

Then you need to get it

[old merlin]

I see, I was kind of on the right track than

I was hoping there was another way

[vapid shell]

Not if you want to use the yellow thread radio

[old merlin]

alright, is that also why the "Import Credentials" button is not working for me?

I assume that also needs to work in order for me to do this

[vapid shell]

If you have a working OTBR you shouldn’t need to because the OTBR integration should sync them over

But Im stabbing in the dark about what state your OTBR is actually in

[old merlin]

I am also unable to add matter device (Eve energy), when I try to do it using HA it tells me I need a border router

even tho I have it listed under preffered network

[vapid shell]

That’s a different kettle of fish

With HomeKit over thread Ha pushes the thread credentials over Bluetooth from ha

With matter, it’s your phone that does it.

Worse, it’s an Apple sdk that does it

So ha needs to sync its credentials to Apple

That isn’t supported yet

[old merlin]

I see

I didn't expect this to be easy but this is frankly ridiculous 😄

I'll give it another shot once I find a bluetooth adapter for HA, and I'll think of matter later I guess. Is there a recommended list of bluetooth adapters for HA?

[vapid shell]

Yes, there’s a big page on the Bluetooth integration in general and it’s on there

You should eventually be able to pair matter directly from Ha like you can homekit. But there’s a lot of work to do on many different pieces of the puzzle. So I don’t know when it’s coming.

[old merlin]

alright, thank you

[spice imp]

I have added a second google nest hub now. After that both suddenly started updating and now trel is enabled on one of my google nest hubs.

It seems like the one with trel enabled still has an older firmware version for some reason

[inner torrent]

I wonder if it's just a staged roll out

[twin vine]

what Fuchsia firmware?

the trel changes happened in F14, which is safe to assume it happened on any google nest device over firmware 14.x

[spice imp]

The Old one was stil at 11 until i rebooted it. Now its at 14 and trel is disabled

[twin vine]

is both on 14 now?

[spice imp]

Yes 😒

[twin vine]

Hmm, might even be worth a support ticket to them to see what they consider "feature flags"

[spring bramble]

If its coming.... as it doesnt make a lot of sense without bluetooth proxies... or should we ask people to take their fridge to the ha server 🙂

[magic girder]

Sorry if this has already been answered, but are we able to pair matter-over-thread devices from HA yet? Last I read a few months ago it was on the way.

[silk fjord]

If I pair a HomeKit over Thread device over Bluetooth to HA then provision thread credentials, does it fallback to Bluetooth if HA can’t connect over thread for some reason? (like if my single ATV border router goes down)

[tacit dirge]

Yes. Still officially beta but I've been doing it. Multiprotocol is pretty awful but thread only on skythingee is ok

[vapid shell]

No. There’s a tiny bit of groundwork towards that, but there’s a heck of a lot of refactoring needed to get there, there are lots of other priorities and no one with time.

Plus Apple thread is more reliable than Linux Bluetooth 😂

[silk fjord]

I have a handful of bluetooth proxies now, was mostly just curious if it was worth the time to go back and repair all my nanoleafs natively instead of with the add/remove from apple home. Saves me a lot of time not worrying about it 😅 My thread network is rock solid besides the one time my Apple TV turned automatic updates back on by itself and decides to update when I'm not home and I lost all thread devices until I restarted HA lol

[steady forge]

Hmm my Nest hub seems to force a channel change in my thread network randomly even if it's not the current elected leader. Sucks.

It follows my OTBR if I command a channel change but the next day it'll all be back on the channel the Nest Hub chooses

[sick swan]

@steady forge I was actually wondering how channel management is working with the Nest Hub.

Is that a HA/user provided Thread network or one which was originally generated by Google/the Nest Hub?

[inner torrent]

Just as a data point, mine didn't do that. I have a network that was originally formed by Google and my nest hubs have respected the channel change from the skyconnect

So might be a conditional issue

[steady forge]

My current network is one that was originally created by Google but adopted by OTBR (which is its current leader). The Nest hub was reset multiple times and I've made it join the now OTBR-owned network via the Android companion app's sync functionality.

With iOS it's a mess. As soon as you configure the nest hub with Google Home on iOS it pulls out very old thread credentials from my iOS keychain and forces the thread network to use it instead. I've had to uninstall the Google Home app entirely from my phone so it doesn't interfere. Also I can't find a function to remove old, saved thread credentials from iOS.

Oh, and the iOS HASS app Import Credentials button does the same and uses the old info from iOS keychain and forms a new network with both OTBR and Nest based on it. Of course it's the basic OpenThreadDemo one with standard 1234 credentials smh

[vapid shell]

These are the kind of problems I meant when I talked about data plane vs control plane previously. There isn’t a standard control plane for thread. There’s the otbr api, but that’s missing auth and encryption. It’s also not available on many BRs. There’s also (that I’ve seen?) no concept of ownership or multi-ownership. Which means who is responsible for things like channel changes is completely undefined?

I think Apple are working on matter support for routers and that has some thread primitives - maybe that will solve this?

But right now it seems pretty clear the big vendors expect you to use their control planes and not be tinkering behind its back

I don’t see how you solve that without a shared standard for a thread control plane

[steady forge]

Currently you're really forced to stay in one ecosystem (at least for the thread layer) or else you'll encounter problems. Once HA implements device sharing I'll try to switch to OTBR exclusively while adding devices to HA first.

I also completely hate that when adding a matter device via iOS (doesn't matter which app) the iOS keyring registers itself as a service on the device and takes up a potentially valuable controller slot by default. So far only the Google Home app has been able to show and remove registered controllers on a device.

There's lots of potential for HA here to have the best, most open and feature-rich implementations for both Matter and Thread!

[inner torrent]

Honestly the majority of headaches I see are from people on iOS

[steady forge]

Alexa's matter controller is buggy as hell but at least their app allows manufacturer-agnostic selection and network key entry of the thread network the device should join. This is very similar to how you would commission a wifi smart device to a wifi AP.

[twin vine]

We only need google and apple do to do the same, unfortunately the latter would no doubt only happen if their were forced to by the matter spec

[spring bramble]

I don't agree on that. In all my testing, iOS is the most stable and Android is a freakin mess.
But... indeed when you stay in the Apple ecosystem. Doing something outsude that path fails miserably. This is clearly not intended to be universal, hence we are not yet promoting it at all. It will be solved but we will have to wait for the Thread Group.

[inner torrent]

Yeah I'm sure within the confines of apple HW it's fine

But it's when you have to wrangle the credentials sync for other hardware that gets to be a problem

My experience with Google has been fine with other BRs in contrast

[spice imp]

Well what else is Apple supposed to do? Open it up so it gets advertised you can use Googles stuff and then they have a non working thread network since Google cant get their shit together?

They already have implemented some stuff in their border routers to fix buggy Google implementations

Since Google doesn’t fix it themselves

[sick swan]

Did someone look into/understand the SRP replication mechanism?

Or rather, how SRP works when multiple BRs are on a network?

[spice imp]

I looked at the thread cli commands yesterday, and there where some hints

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

Like this

While you are at it, would be nice if the otbr would be build with “OPENTHREAD_CONFIG_CHANNEL_MONITOR_ENABLE”

[sick swan]

The SRP server is enabled but not active due to existing SRP servers that are already active in the Thread network.
Uh yeah that is interesting. I definilty had two in running state 🤔

[spice imp]

From what i remember, its not defined behaviour what happens when multiple SRP servers exist.

[sick swan]

Hm, so according to https://github.com/openthread/openthread/blob/main/src/core/config/channel_monitor.h this would do an energy scan on every channel every 41s 🤔 What is your use case? Can we make this an option to enable at runtime (add-on config?)

[spice imp]

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

[sick swan]

@spice imp looking at the standard I found this:

Multiple active Thread Service by Registries MAY be announced on a Thread Network. In this case, each active instance MUST attempt to use service data replication to other active instances so a client only needs to register with one active on Service Registry instance.

I wonder if the OTBR version does not support this replication 🤔

Or rather, as per my observation, it doesn't seem to work 😅

[spice imp]

Well i actually just want to see whats the best channel to use, nothing fancy 😄

[spice imp]

I can imagine that this is also one of the reasons why vendors aren't combining their thread networks yet.

[sick swan]

Yeah...

I just played a bit around with Google Nest Hub 2nd Gen + OTBR, and this combination seems to work

As in, 2 Matter devices using the Thread network continued to work when both were enabled, one was disabled, both were enabled again, and the other one was disabled. First it was Google which acted as SRP server, then OTBR...

[spice imp]

https://github.com/openthread/openthread/blob/d81c6fab98df8fbeb0f3611ce5ec4c131c84cbce/src/cli/cli.cpp#L1314
I think thats only when you run channel monitor start

[sick swan]

Hm, I see, yeah seems a worthwhile option to enable 👍

[spice imp]

i think there has been some bug where apple disabled their srp server if a nest hub was present and would never start it. Idk if its still the case though

[sick swan]

"present" as in the same network? 🤔

[spice imp]

But tbh its just because i have been to lazy to set up an rpi with an border router where i do it myself 😄

[sick swan]

Is there a "supported" way to do this?

[spice imp]

Im not sure about that. It was someone from work who had a lot of problems with this for a while.

[sick swan]

I mean, we want a stellar OTBR 😅 If it has no downsides, I am all in to enable it by default 😅

[twin vine]

i mean, whats the worse that can happen 😄

[sick swan]

I guess if channel scanning is on all the time, you might miss packets.

[spice imp]

yes, it could also be a really nice feature to have that in the homeassistant UI for people with network problems.

[sick swan]

Which is not ideal....

[spice imp]

it says that its "zero" downtime

And i think the feature is used for border routers that have the channel manager activated, so it automatically changes the network to the best channel

[sick swan]

"zero-duration Energy Scan", what does that mean 😅

[spice imp]

maybe its something done while idling

And i guess when running multiprotocol, a lot of packages might be dropped anyway?

Could not find the apple BR with this btw: https://openthread.io/reference/cli/commands#trel_peers

Even though trel was enabled with the otbr, so its not working.

[sick swan]

With Multi-PAN (what our Multiprotocol add-on uses) Zigbee and Thread on the same RF channel. Channel access is already handled on a radio level. So it should not drop any packets. It's just that Thread and Zigbee need to get along on the same channel/with the same bandwith...

[spice imp]

so its basically just a pipeline filtering the packages and forwarding them to the right stack?

[sick swan]

Yeah I also noticed that there is no trel announcment via mDNS. But I have no clue why 😢

[spice imp]

I guess there might be some mdns thats not enabled?

[sick swan]

Yeah.. and on sending they need to get a long as well.

SiLabs also works on multi-channel multi-protocol. And that one seems to have caused side effects into the multiprotocol we are using, unfortunately (at least in Gecko SDK 4.3.2, also why we never released things built on that SDK).

[sick swan]

The OTBR itself announces itself also on mDNS. And that works. So it is weird.

[spice imp]

They have been doing a lot of multiprotocol at my workplace with bluetooth. All it does is causing problems

Just buy a second chip and have a happy life 😄

[sick swan]

Maybe there is some detection if there is another TREL capable BR, and it doesn't detect that correctly? Not sure, I haven't looked into it further at thsi point.

[sick swan]

With SiLabs? Bluetooth does channel hopping by default, so your RF frontend needs to switch channel to do regular Bluetooth even.

But yeah Bluetooth + 802.15.4 pretty much guantees packet loss.

In theory, if you can sample channels faster than baud rate of what you trying to receive, you essentially can receive on two channels simultaneously. But from what I understand this really pushes the RF frontend of nowadays chips.

Or they do software defined radio? Not sure.

I guess reasons the stuff is closed source 😢

[twin vine]

https://github.com/openthread/openthread/commit/d81c6fab98df8fbeb0f3611ce5ec4c131c84cbce

speaking of trel, this seems like it would be handy for debugging

[spice imp]

It was TI

[spice imp]

Can you even do that with their chips?

[spice imp]

There is no need if its never connecting to any neighbors 😄

[sick swan]

@spice imp https://github.com/openthread/ot-br-posix/commit/6c0a8ceddbe2f8bae95ee037b20ad96e3bfa3cdd might be the reason SRP stays on in our configuration 🤔

Related OT commit https://github.com/openthread/openthread/commit/615e951ca9b378331bcf6a29151ed1c1cdf98ac1

Nevermind, this should be enabled by default with OTBR_DNSSD_DISCOVERY_PROXY and OTBR_BORDER_ROUTING set

[spice imp]

When i write br routers i get an empyt output

Maybe no other srp server is detected?

[serene prawn]

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

[spice imp]

I get "InvalidCommand". Is it maybe something that needs to be compiled on the rcp?

[sick swan]

I enabled it in my build

of the OTBR... But yeah, it seems to be started by default (I did not use the ot-cli channel monitor start command, but it said enabled: 1 from the start)

https://github.com/openthread/openthread/blob/main/src/core/thread/thread_netif.cpp#L62-L64

[spice imp]

ugh, thats annoying 😦

[sick swan]

I mean, we can patch it out by default... then we can enable it via command 🤷‍♂️

I wonder if it is really totally unproblematic. Then we could also enable it by default.

[spice imp]

only one way to find out 😉

Just use the nanoleaf method

[sick swan]

I figured out why TREL isn't working

-        -DOTBR_TREL=ON \
+        -DOTBR_ENABLE_TREL=ON \

🙈

[spice imp]

Have you stested it?

[sick swan]

Not yet, working on it now.

[spice imp]

Error 35: InvalidCommand

[sick swan]

But it was clearly wrong.

[spice imp]

This is what i get on my s200

And it even says that trel is enabled :/

When aEnable is true, this function initiates an ongoing DNS-SD browse on the service name "_trel._udp" within the local browsing domain to discover other devices supporting TREL. Device also registers a new service to be advertised using DNS-SD, with the service name is "_trel._udp" indicating its support for TREL. Device is then ready to receive TREL messages from peers.
I actually suspected that the dns browse is not working

But maybe im wrong and it works now 😄

[sick swan]

Doesn't work. Hm, OTBR_ENABLE_TREL=1 is the header file definition, the cmake one is OTBR_TREL=ON. So that was correct 🤔

[sick swan]

The last commit of OTBR very much points into this direction:
https://github.com/openthread/ot-br-posix/commit/657e775cd9ca757af7487da2fb039aee645c3d65

But I compiled with this version before, and it did not make a difference

I currently just check if _trel._udp is being announced.

[spice imp]

Is the border router still using avahi for dns discovery?

[sick swan]

No mDNSResponder

[spice imp]

https://github.com/openthread/ot-br-posix/blob/657e775cd9ca757af7487da2fb039aee645c3d65/etc/cmake/options.cmake#L106

Isn't it same same?

[sick swan]

Yeah OTBR_TREL gets translated into OTBR_ENABLE_TREL.

Oh, it seems that needs a otbr-agent parameter:
https://github.com/openthread/ot-br-posix/commit/473be9c04c7525902ba6b59df9733bb6848399a3#diff-7a4cf9d84873dc1399f26f01efaeeeb2090fbda5f05530e81156ecd08e811272R4

Yeah that makes it work 🎉

[spice imp]

yeah, since you have feature flags enabled, right?

[sick swan]

Yes

But the radio url variant to select the interface to use for trel seems independent of feature flags, I think.

[spice imp]

What is your setup to test changes to addons?

[sick swan]

I manually build using docker on my dev machine, then push it to registry, pull from registry and tag it on the target.

This works well as long as the add-on config doesn't change.

docker build --progress=plain --build-arg BUILD_FROM=ghcr.io/home-assistant/amd64-base-debian:bullseye \
  --build-arg BUILD_ARCH=amd64 \
  --build-arg OTBR_VERSION=657e775cd9ca757af7487da2fb039aee645c3d65 \
  --build-arg UNIVERSAL_SILABS_FLASHER=0.0.16 \
  -t ttl.sh/amd64-addon-otbr:2.4.2 .

Then docker push ttl.sh/amd64-addon-otbr:2.4.2, and docker pull ttl.sh/amd64-addon-otbr:2.4.2 on the target, with subsequent docker tag ttl.sh/amd64-addon-otbr:2.4.2 homeassistant/amd64-addon-otbr:2.4.2 and add-on restart

[spice imp]

yeah okay, so i can just pull it from ttl.sh? 😄

[sick swan]

Sure 😅

For a while at least 😅

[spice imp]

001 ExtAddr:4eb6ccc7d5ed3b41 ExtPanId:fbcc53cdcd4466ab SockAddr:[fdfb:cc53:cdcd:66ab:437:1e96:1717:aa69]:51702
Done

works

otbr-agent[183]: 00:07:46.386 [W] P-RadioSpinel-: Handle transmit done failed: ChannelAccessFailure

Is this problematic?

[spice imp]

otbr-agent[183]: 00:07:13.480 [N] MeshForwarder-: Dropping (reassembly queue) IPv6 UDP msg, len:299, chksum:8d6a, ecn:no, sec:yes, error:ReassemblyTimeout, prio:net, rss:-20.0, radio:trel
Trel is also getting used now.

[sick swan]

Probably means radio was unable to send packet because air was busy.

Either because the channel is really jammed, or some interference.

Just pushed another container image, this time channel monitor is disabled by default

https://github.com/home-assistant/addons/pull/3396

[serene prawn]

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

[spice imp]

Yeah, its more if this actually is a problem or just happens

[sick swan]

I guess that depends on the higher level protocol. As in, does it have a retry mechanism...

[spice imp]

Yeah, looking at the channel monitor, it also does not seem like there should be a problem.

[sick swan]

The monitor seems very slow.

As in one sample every 41s, that is probably not very telling right now

If the air was busy when the BR tried to send, and that for longer than the backoff time etc, it is a lost packet in the end, I guess.

[spice imp]

I hope the data are aggregated, so lets see

[sick swan]

This seems a very size optimized way of collecting long term data about channel occupancy.

[spice imp]

Wasnt there also something with the srp server not automatically turning off?

Mine is actually disabled now

And it starts when i turn off my apple homepod

[sick swan]

So ot-ctl srp server state changed?

[spice imp]

yes

[sick swan]

to?

[spice imp]

disabled or stopped

i tried to reproduce it, but now its not happening again 😄

[sick swan]

I never saw anyting other than running here.

[spice imp]

https://github.com/openthread/openthread/issues/8223
https://github.com/orgs/openthread/discussions/8596

Maybe it worked last time because my ha otbr had the highest ipaddress and was therefore not priotised

• i had 3 other border routers

I cant seem to find any code in the openthread repo that would disable to border router.

https://github.com/openthread/openthread/blob/d81c6fab98df8fbeb0f3611ce5ec4c131c84cbce/src/core/net/srp_server.hpp#L769

maybe it was not a good thing

[sick swan]

It basically ties the SRP server mode to the actual border routing functionality, which seems sensible to me? 🤔

I guess we never disable it though, so it will remain on in our case.

[steady forge]

Just read through the 100+ messages. Very interesting stuff! I've noticed that my Nest Hub initially had a _trel mdns entry but it's gone now that the Nest has joined my OTBR network.

[sick swan]

https://fuchsia.dev/whats-new/release-notes/f14#thread_2

Hm, can we control these feature flags? 🤔

[steady forge]

Ohh that's why! I've checked mdns right after plugging it in before it did its Firmware Updates

[steady forge]

Maybe there's something like adb available for this thing

[sick swan]

From what I can tell this is controllable through D-Bus which afaik Google uses to control their BR.

But I don't think we can control that feature flag 😢

[faint siren]

Is anyone using a Nest Wifi as a Thread Border Router?

That option doesn't seem available yet on that device yet, but I just wanted some confirmation.

[spice imp]

have you tried using google home and just commission a thread device?

[faint siren]

I don't have a thread device yet, I was just thinking about getting a Nest Wifi ahead of time.

I'm still using Google Wifi, so a Nest Wifi can be apart of the mesh.

[spice imp]

I have been thinking if its really that nessecary. I think most of the data send are from the device back to the controller. This should chose the right border router to "exit" the thread network already. So the only benefit is sending data into the thread network.

[spice imp]

for google nest hubs you can't really "control" the thread border router. And i have seen before with my nest hubs that they first activated their thread network once i tried to commission a device.

    Displays: Nest Hub (2nd gen), Nest Hub Max
    Wi-Fi routers: Nest Wifi Pro (Wi-Fi 6E), Nest Wifi

[faint siren]

Okay, that's good to know.

[spice imp]

So if its listed here i think it should have a thread border router

But there might be some magic going on deciding when to activate it

[faint siren]

They do say that the Nest Wifi doesn't support "Matter" yet.

That and not one single person on the Internet saying they used one as a TBR makes me think it's not possible yet.

[spice imp]

do you have a link?

[faint siren]

https://support.google.com/googlenest/answer/6300732?hl=en

Matter is listed as "Coming Soon". So not available yet.

[spice imp]

but matter enabled and thread border router are two different things

A thread border router is basically a wifi router for your thread network

Then you have a "matter controller" on your wifi/ethernet that can talk to your thread network

using a border router

If that makes sense

Its like your HomeAssistant connected to ethernet talking to wifi devices

[faint siren]

It does, it's just that I don't think the Nest Wifi can be used as a TBR yet.

I've googled this here and there for months now. I haven't seen one person say that they're it for that purpose.

It's all been Apple devices or Nest Hubs I think.

[spice imp]

But has someone written that they have tried and it didn't work?

[faint siren]

I don't think I've seen that either.

[twin vine]

You are not buying a router to have it as a TBR… let’s be real

[faint siren]

I was just wanting a cheap option lol

But I guess I could get something like the Zemismart Matter hub with Thread

[spice imp]

but what do you want to do exactly with it?

[faint siren]

I just wanted one on standby for future devices. That's pretty much it.

I know that there is no need to rush.

Just felt like it would be nice to have one if I could for just $40-50.

[twin vine]

Gl.net have cheap border routers than can be powered by POE

[spice imp]

if you also want an wifi router, get the gooogle one.

[twin vine]

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

[faint siren]

That looks interesting. I may give it a shot. Thanks.

[twin vine]

Don’t think it’s commercially available, would have to fill out the form at the bottom

[spice imp]

it is

[inner torrent]

Even cheaper, just buy the board directly from espressif for $10 and toss it in a ABS plastic box and call it a day

[inner torrent]

You can get it from aliexpress IIRC

[spice imp]

but do they have poe?

[inner torrent]

I don't think it supports poe, no

[spice imp]

i can see they have an addon

for poe

[inner torrent]

It's for Ethernet but I don't believe it supports Poe, at least from what I could find

[spice imp]

https://docs.espressif.com/projects/esp-idf/en/latest/esp32/hw-reference/esp32/get-started-ethernet-kit.html

it does

[twin vine]

Aliexpress link?

[sick swan]

Does anyone has real world expirience with this ESP32 TBRs? Are they stable/working well with multiple devices?

[spice imp]

dont crush peoples dreams please 😂

[inner torrent]

https://www.aliexpress.us/item/3256805685744832.html

They are also on Amazon

[inner torrent]

Yeah ive got one up right now

Works fine, it's in my thread network with 2 Google BRs, 1 nanoleaf BR and skyconnect OTBR

[twin vine]

Cheers 🙏

[inner torrent]

Only issue I had was setting the default thread dataset to my existing network, but I just joined it after flashing the FW

It's got an auto boot in BR mode so I just have it connected to a USB power supply and leave it on all the time

[spice imp]

i dont think this one has POE though. You probably need to use the other board and connect a thread RCP to it.

[twin vine]

That’s fine

[inner torrent]

You have to get the main board and the sub board sits on like a hat I think

The main board is all you need if you don't want POE

[rain cairn]

I'm noticing the OTBR add-on is consistently using ~50 % cpu. Restarting starts low, but ends up here after a couple mins. Anyone have any ideas why this might be and/or ideas on how to address this? I'm running HA OS in a VM on a Synology with a SkyConnect.

[spice imp]

mine is constantly at 0%. Can you see how much cpu your vm is using? Maybe its a visual bug

But idling cpu power is wasted cpu power 😄

[rain cairn]

It shows as 50% in the HA addon screen. The VM software shows an extra 13-15% host CPU usage when it's running in HA.

[spice imp]

What version of everything are you running? There was this that got fixed: https://github.com/home-assistant/addons/issues/2910

[rain cairn]

I'm running the latest stable everything HA. For OTBR add-on it's v2.4.2. It's now showing 72% cpu in the addon 😦. I noticed higher then normal idle CPU on my nas a while ago, but finally tracked it down to OTBR afaict.

[spice imp]

you can run a shell in the container

install top or sth and see what process is causing it

[rain cairn]

If I could only figure out how to do that in haos 😢.
... Advanced SSH & Web Terminal 🫠

[rain cairn]

Looks like the following processing is using 100% of the container CPU:

/usr/bin/python3 /usr/local/bin/universal-silabs-flasher --device /dev/ttyUSB0 flash --ensure-exact-version --allow-cross-flashing --firmware /root/NabuCasa_SkyConnect_OpenThread_RCP_v2.4.0.0_ot-rcp_hw_460800.gbl

[inner torrent]

Looks like the flasher. Wonder if you couldn't just toggle off the flash firmware option and that would fix it

[rain cairn]

After disabling the flash firmware option, it's down to 0%. Seems to be holding, so 🤞. I guess I should log a GH issue related to this. No idea what the process of manually flashing the SkyConnect would be either.

[sick swan]

Note that the addon screen only shows a momentary snapshot of the CPU load. During startup higher CPU is also expected.

Flashing shouldn't use that much CPU. Seems it is running into some trouble. Make sure you don't have any other add-on or the Core accessing the same SkyConnect. E.g. uninstall Silicon Labs Supervisor addon and make sure to remove/disable ZHA

[rain cairn]

So, I'm not using ZHA in HA or Zigbee on the SkyConnect at all. I have another dedicated Zigbee controller using Z2M. I'm just looking to use the SkyConnect as a TBR. Which is working more or less ... with some stability issues from time to time (unavailable nanoleaf matter bulbs periodically).

[inner torrent]

Well nanoleaf has many more problems than the OTBR so more likely it's the bulbs

[rain cairn]

Yeah. My matter over thread blinds seem quite stable.

[sick swan]

Ok. Yeah I mean maybe during flashing there is some higher CPU load, or maybe it went stuck. But once the OTBR is up you shouldn't see high CPU load

[rain cairn]

Well like I said, even after restarting the add on, it’s pinned at 50% after a couple mins until I restart next time. After disabling the auto firmware flash, it’s at 0.1% and my nas is happily running at 4% (when it was 15% before) idling.

So seems something is up.

[mossy viper]

If you have access to "strace" you can sometime get a feel for what is going on. Just strace the pid and watch to see if it is "spinning" on read/write/ioctl, etc

[fickle mantle]

As a datapoint, just migrated from SiLabs AddOn to OTBR AddOn (successfully 🙂 !! ) Auto Firmware flash was set to ON during OTBR AddOn install and left ON. After several minutes of running, no noticeable CPU load.

[steady forge]

lol something is still forcing my Nest Hub to form a new thread network overnight based on my very old first OpenThreadDemo credentials that haven't been used in weeks and I don't even use OTBR currently. I've even uninstalled Google Home on iOS because I was sure it was due to old iOS keyring data and it's still doing it 🤷‍♂️ This is hard to troubleshoot. Could it be coming from Echo devices which are in my network as matter controllers?

Ah or is the iOS companion app just syncing old keyring credentials in the background without me using the "Import credentials" button? HA itself doesn't know anything about that network as I've always made sure to wipe .storage/thread.datasets. I'll deactivate the thread integration completely now.

[spring bramble]

Nope, the iOS companion app is not automatically syncing anything (the Android app does that, but that will also be changed)

[steady forge]

Okay, thanks. I always use the Thread sync functionality on an old Android phone to get back to my real Google network so I don't think it's the culprit

seems like play services actually holds the NEST-PAN network, not the old OTBR one

[spring bramble]

Yes, it keeps holding that until you completely reset your play services. Which will also wipe out things like your wallet and such

In my testing with Google things work happily as long as you do not add a Google BR into the mix. So on a vanilla google account/network with no Nest hub etc present, using your own OTBR works perfect. But if you already had a Google BR or add one later, Google seems to overwrite the credentials, which kind of makes sense from their perspective, they prefer the google BR.

But someone else reported that adding a Google BR later made it join the existing OTBR network created by HA so I might re-test it again as something may have optomized in the meanwhile.

---

On iOS the story is a bit different, there we can not push any credentials (so we can not set the preferred network) but we can actually read the current network/credentials and make our OTBR join that existing network.

[sick swan]

That is very likely

What does the Android phone says when force syncing?

[sick swan]

They don't overwrite the credentials. They just use whatever is on the phone storage. They don't allow to overwrite that storage, which is a problem. So if you ever once synced something to the Google Play store storage of a phone, or Google created a preferred credential for you, you won't get rid of it unless you delete the Google Play storage (and probably also reset your Nest Hub)

[serene prawn]

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

[proud berry]

Is here a way to get EVE Weather which has Thread into home assistant and if so how?

[vapid shell]

If it has thread but not matter then it’ll be HomeKit and might work with HomeKit Device.

There a couple of approaches listed in the docs for that integration

Which works for you depends on whether you use iPhone and a HomePod or something else

[proud berry]

We don't have any Homepod etc., just the HA Yellow and my wife an iphone. Would you mind to tell me what I need to look for - is it Homekit integration ?

[vapid shell]

There are 2 homekit integrations - homekit bridge and homekit device (formerly homekit controller) - you need homekit device

If you don’t have an Apple thread network then your yellow will need a Bluetooth radio to be able to pull this off

(Homekit uses Bluetooth to upload the thread connection details)

[proud berry]

Just checked - not sure if I have BT on my yellow. It is said, that it interferes with other radios. But I have the HA Companion app on my Phone - that I used to integrate matter devices. Would that work too (or the iphone from my wife)?

[vapid shell]

No

Matter support in HA uses the matter sdks from google and Apple to do this bit. There isn’t a similar sdk for homekit.

You can use a Bluetooth usb dongle and unplug it when you are done

Or use an esphome Bluetooth proxy

(You might find that an esphome proxy and Bluetooth is more stable anyway - the thread support for homekit is experimental, and the device firmware tends to lag behind that on the matter devices)

[proud berry]

OK many , many thanks - that does not give me many hope for a reliable operation. Maybe I should just send this device back until proper matter support over thread is available.

[vapid shell]

Your mileage may vary.

I know some people have lots of Eve Thermos that are working well

[proud berry]

OK. I have eve energy with matter over thread without any issues working. So thread in itself is fine in my setup. I misunderstood your comment about the homekit device integration (which uses the same thread add on as matter I assume). Anyhow the procedure would be : install the homekit device integration, integrate Eve Weather via BT dongle (connected to HA Yellow) . Will the Thread network automatically takeit over so that I can unplug the BT dongle ?

[proud berry]

@vapid shell I have the device now integrated (with an USB BT dongle) and can see weather data in HA. How can I now tranfer the communication to thread?

[vapid shell]

The thread integration doesn’t actually do very much, it’s more like a password store for sharing your thread network connection details between other apps and integrations. Homekit is able to pull the connection details out of there, but in the case of matter it’s the companion apps that get the connection details and sync them into the Apple or google ecosystems so a little different.

Thread devices appear on your network kinda like they were on WiFi so we are able to talk udp over ipv6 directly when the thing is migrated.

[vapid shell]

On the device page there should be a button that said “provision preferred thread credentials” or similar

Under sensors but above diagnostic

You should also be able to see a thread capabilities sensor and a thread status sensor on the same page

Press it once and wait up to a minute

Then the thread starts sensor should change

To child iirc

[proud berry]

I've found a button under Configuration "Provision Preferred Thread" which I can press. The diagnostics section shows Thread Capabilities - "sleepy device" and Thread Status - "deactivated" . I will press the button now 😉

Now the Thread Status changed to "child", but Thread Capabilities stayed at "Sleepy device". Shall I now unplug the BT dongle?

[vapid shell]

Yes

[proud berry]

wow it works;-) Wonderful! Many thanks for your time and help, I really appreaciate it!

[steady forge]

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

[inner torrent]

Is that "roadmap" part of the 1.4 spec?

[twin vine]

seems to be

but most of these changes require a gui, which could takes who knows how long from all the companies involved

[spring bramble]

yeah but its really a hot topic so I think there's some pressure to fix it

[spice imp]

yeah, but fx googles thermostats are still on matter v1.0 and you cant control devices in their ecosystem besides with their google home app

probably gonna take some time at least before everyone has implemented it

tbh, threadgroup should just rename "self healing" to "AI healing" and everything will be fixed in 1 month 😄

[steady forge]

so much duplication of effort

[knotty citrus]

Maybe I've not groked this well enough yet -- does this require GUI on every thread device? Or only the TBRs? I hope it's the latter?

[twin vine]

If the users have to “select a thread network” on pairing. There would have to be both an update to the GUI on the end client device (aka in the app) and also an update to the device to support it

[modern root]

More Ubiquitous Internet Connectivity
With this enhancement, Thread networks will require Thread Border Routers to provide a standardized path to the Internet for the devices connected to it. T

dislike

thats why I liked Thread, it could be seperated from my actual network entirely without fussing with VLANs etc

[twin vine]

It was already doing it, just though other border routers, like Apple TV, HomePod, google nest hub or Alexa stuff

[vapid shell]

Sigh

I do hope there are some matter vendors that do local first

[twin vine]

You expect a Chinese company to do local stuff 🙃

I mean, hard to make assumptions based off a press release.

Will just have to wait for the reviews to come out and hope you can use it without setting it up as a BR to wifi (aka as a internal router or whatever the name is)

[vapid shell]

There was a period where the Aqara hubs could do homekit only because they couldn’t comply with the GDPR

Managed to wire in the pairing mode toggle for it in Ha so you could add new devices without touching the app

But most of my homekit stuff (apart from eve and.. koogeek?) seemed to have a “side cloud” that you couldn’t turn off. And if you did you’d get an angry red light even though local access worked fine.

[twin vine]

It sucks that they have to call home, otherwise they assume there is an issue 🙄

[vapid shell]

And if every single device does that 😂

Oh no my door contact sensor can’t phone home so now it’s playing a sad tune every time I open the door 🥴🎉

But there’s definitely a future where some vendor collects door opening telemetry to help them better their products and protect your privacy with their 327 trusted partners

[inner torrent]

Assuming there support at some point we will just go back to iot vlans

[vapid shell]

(Do non eu people get cookie banners? They’ve started listing how many people they shared data on you with for me. And the wording is usually 🤢 - we value your privacy blah blah. We shared your data with our 257 entrusted valued partners blah blah).

[spice imp]

well as a developer i hate gdpr. There is so much stuff you don't even care about saving and just would like to ignore. As a consumer i like it tough

[spice imp]

the idea was good, the implementation is shit

its like changing your password every 10 days

[vapid shell]

I wonder who pissed in the gdpr pot

Someone with a fat wallet ?

Anyway it’s only relevant here in so much as there will be people wanting to “extract shareholder value” from this stuff.

And it will be just as hard to opt out

[knotty citrus]

The implementation is so shit, that even though I'm a privacy minded person, the cookie banners get irritating enough that my lizard brain just clicks whatever is necessary to remove them. And most sites implement a single-click "accept-all" but a 5 click, read N options to "decline all" 😦

[knotty citrus]

I just read the whole page:

More Ubiquitous Internet Connectivity
With this enhancement, Thread networks will require Thread Border Routers to provide a standardized path to the Internet for the devices connected to it. This assurance of connectivity means product makers can build devices that leverage the cloud for more dynamic features (like a thermostat that responds to weather changes) or give users the ability to remotely control their devices. They can also send software updates to the devices and perform diagnostics to provide better technical support.

This is just sad, and likely will ruin all advantage of thread for me. Having seen all IOT vendors so far, it's just a matter of time before every device will just ping back home for telemetry, exchange data and implement control using proprietary commands "for more dynamic features".
And people like us will be back implementing firewalls, maintaining online lists of which devices actually work offline vs. not. I was so hopeful that I'll eventually be able to buy any device with Matter & Thread logos, maybe 2 years from now. But now it'll be just as bad as WiFi 🤦‍♂️

[inner torrent]

IPv6 rules are even harder to implement and less supported (in my experience)

Wonder if that's the result of vendor pressure

The phoning home I mean

[inner torrent]

https://www.techspot.com/news/101396-european-union-set-revise-cookie-law-admits-cookie.html

[knotty citrus]

Yep - I want to do this, but I don't know how to; on IPv4 I know how to do this pretty well and do have a local-only subnet. And the fact that the TBR is "under" HA's OS (with internet access) instead of a standalone client on my main internet router doesn't help either. Looks like it's time I bite the bullet and do some deep reading on IPv6, DHCP6 etc.

Not sure if it's wishful thinking, but hopefully TPLink/Netgear etc. will create regular wireless routers with TBRs built-in as just another radio.

[twin vine]

why do so many people want that? i dont get it

i dont get the reason people like thread/matter within their wifi router, like why not just keep it in edge IOT devices where its most ideal (like homepods, apple tv's, google devices, amazon devices, etc etc)

[knotty citrus]

Today the routers are the primary orchestrators of the "IP" protocol in the home network. And looks like all of this is just regular IPv6 over a slightly different radio. So might as well have the same entity do it

[vapid shell]

If you want to dive into the thread relevant parts of ipv6, see RFC 4191.

[knotty citrus]

Personally, I run OpenWRT and can construct different firewalls and such to route/block/manage traffic on the router itself. So it's simpler for me to have it be another component on my firewall that I can mange directly.

[vapid shell]

It’ll be 20 next year 😅

[knotty citrus]

Thanks... But I'll probably need simpler sources. I'll look for more educationy material (Networking / OS books etc. or some videos on Youtube), or maybe get one of my friends who is a networking engineer to explain it to me. 😅

[vapid shell]

It’s the part of ipv6 that lets you have different routers for different networks, and some of the faff that entails. There’s a lot more on top of that of course.

[steady forge]

I know many people without any voice assistant devices but they all use a Fritzbox with the occasional FritzDECT smartplug so I guess it would be a good thing for general adoption

[spice imp]

Isn’t that limited to Germany?

Where you are lucky if you have an internet connection at all

[vapid shell]

No

Zen use them in uk

I have an unused one at the back of my wardrobe

They use them for all their packages i think including 1gb symmetric fibre

[spring bramble]

Makes sense, I'd imagine you just buy WiFi Access Point s(or mesh extenders) and get the Thread Radio included.
Google has already launched their Nest WiFi Pro, which is exactly that.

[digital salmon]

What??? I live in a very small village far away from a big city and can buy Multigig Ethernet from a local FTTH provider. I think in Germany we like to talk about everything being worse than it really is. 😉

[spice imp]

Welll, i have been sitting at the main trainstation in Munich and had no phone connection 😅 probably depends on the region

But there is a reason why some place the power providers in Germany charge for the highest power spike pr 15 or 30 minutes

Aka shitty infrastructure

[digital salmon]

Not everything is golden here…. 😉

[spice imp]

Nope, but my point is that Germany is “behind” in a lot of digital stuff(at least compared to other countries) and very privacy focused because of their history. So that what a lot of people do in Germany probably does not apply to the broader market.

[digital salmon]

UK made the Brexit. So you guys aren’t operating in our standard. 😂 But yes, you are right, we are behind other countries in regards to the digitalization. I recognize it mostly, when I want to use Apple Pay.

[spice imp]

Well im happy someone is fighting against it, but im not involved in the shit show

[vapid shell]

Grar ****ing brexit

FWIW I wish we were taking the lead from Germany on privacy

When I was a juniorish dev in the days before GDPR we made a site for some pharmaceutical company flogging male “performance” pills. I was bemused that they wanted to mask ip addresses in apache log files. Just for the German version of their site. Was a pain to do how they wanted to, and even more so pre chef / puppet / etc. now I think a hardline “minimize collection” attitude is the only way,

[rain cairn]

This may be a silly question, but it's not obvious to me from the docs, etc. If I have a SkyConnect and I want to use this as a TBR, do I install and run both (or just one) of the " Silicon Labs Multiprotocol" and " OpenThread Border Router" add-ons in HAOS? The issue I posted about Sunday related to high CPU usage for the flasher seems to occur when I'm running both. I actually realize that I can't run both atm. One or the other will end up causing errors, or shutting down, or the flasher process never finishes (and eats cpu). I sometimes also see log errors that are documented in https://github.com/home-assistant/addons/issues/2869.

[inner torrent]

Install just one, preferably OTBR

[rain cairn]

Thanks. This is very good to know and likely my issue. I know I sometimes skim through instructions, but even after re-reading docs for both, etc. this was not obvious. I only figured it out based on the behaviour I was seeing when troubleshooting.

Is it safe to say that if you want Zigbee + Thread use "Silicon Labs Multiprotocol" and for thread only OTBR?

[spring bramble]

Well, yes but multiprotocol is experimental and just OTBR is considered more stable

[old merlin]

Hi,
so as per the suggestion I bought a bluetooth adapter and attached it to my HA yellow box. I was able to pair eve devices to it, and get them to switch to using thread.
My question now is; I have an Eve window sensor. I'd like to update it to matter (i don't know if thats smart or not). There is an option for that in the eve app and it tells me the device requires a thread network in in order to be updated.

Is there a way to do this using HA alone, or do I need an apple thread router in order to do this?

[vapid shell]

I think the answer is no

For starters we can’t push the thread credentials from your yellow into the iOS ecosystem

So there’s no way to get past that error without a HomePod/ATV

[old merlin]

I was hoping if I could repair with Eve, thread credentials would stay there and sensor would use them to connect to thread

but after deleting it from HA its not repairing with Eve

[vapid shell]

Yeah battery powered (homekit) eve devices have a bug where they won’t unpair over thread

Same thing happened when you delete it from iOS over thread

[old merlin]

oh well

at least I have it over thread now

for all the good it does

[vapid shell]

I’m one of the homekit maintainers and.. I have my homekit eve devices connected by Bluetooth 😜 (esphome proxies)

[old merlin]

is there a way to see the thread devices in HA

in a network kind of view

[vapid shell]

Using HAOS?

[old merlin]

yes

[vapid shell]

The otbr (or multiprotocol) addon have a hidden web ui

Strongly suggest you don’t bother

[old merlin]

oh yeah I've seen it

[vapid shell]

It will crash your mesh

[old merlin]

wow

[vapid shell]

And the network view will have missing data when you get past a handful of devices as it can query the mesh quick enough

[old merlin]

well I only have 1 device so far so

[vapid shell]

It’s a prototype and not meant to be used by end users and will probably get removed at some point

[old merlin]

I was curious if I would still see it there after deleting it from HA interface

and indeed its still there

[vapid shell]

So what happens is it fails to unpair

So it’s still connected to the mesh with the old encryption keys

But ha thinks it’s unpaired and those keys are gone

[old merlin]

and now I need to reset it

to re-pair

[vapid shell]

Yes

[old merlin]

kinda sucks

but I was wondering if I could force an unpair over this UI

[vapid shell]

Ios has the same problem - it will always drop its copy of the encryption keys

[old merlin]

turns out you cannot

[vapid shell]

Even if the device was turned off

Or just out of range

In this case the device is buggy so you can’t even if it didn’t

[steady forge]

The OTBR WebUI is unstable? I've used the Form UI and its topology view before to troubleshoot link quality (turns out my office room is a faraday cage lol)

how would I activate the channel monitor in OTBR addon 2.4.3?
TREL works and shows up on mDNS 👍

[sick swan]

ot-ctl channel monitor start and check the results with ot-ctl channel monitor

[steady forge]

I don't have much experience with HAOS. I'd need to set up dev SSH access to docker exec into the OTBR container, correct?

[sick swan]

Yeah the feature is not really exposed, so the only way is via SSH access

[steady forge]

Alright, thanks. Will set this up tomorrow 👍

[sick swan]

SSH access to the underlying OS is possible on port 22222, but you need to use public key authentication

I think the community terminal add-on has Docker access when disabling protected mode.

[steady forge]

oh, interesting I've got that installed already

Can't find anything about disabling protected mode for that addon but I'll check the docs tomorrow for enabling real SSH access

[fickle mantle]

for the AddOn: Advanced SSH & Web Terminal ->Info tab look for "Protection mode" switch

[steady forge]

oh shoot I've got the basic one installed

this works thanks 🙂 channel monitor started, still shows 0% on every channel but I guess I need to wait for the first interval

[twin vine]

biggggg update! Nice to have trel finally!

[half bluff]

@sick swan Why do I keep getting this error even though the NAT64 is unchecked?

otbr-agent[177]: 00:37:45.917 [W] Nat64---------: incoming message is an IPv4 datagram but no NAT64 prefix configured, drop

When I do check it i get this error: otbr-agent[177]: 00:01:05.073 [W] Nat64---------: no mapping found for the IPv4 address

[steady forge]

you get this because it's disabled, don't worry about it

[sick swan]

Both warnings come from this code: https://github.com/openthread/openthread/blob/36133b93c291f0c84a23a11b0facc738033757c5/src/core/net/nat64_translator.cpp#L201

Yeah in the end your OTBR received an IPv4 packet and the OTBR tries to process it, but then recognizes that the NAT64 forwarding is not active.

FWIW, I don't see such messages in my OTBR. I wonder why you even get such messages 😅

[sick swan]

Hm, I see, as soon as your system receives a message with target 192.168.255.0/24 (default NAT64 CIDR) it gets processed. I wonder if that is really necessary 🤔

[digital salmon]

Do I understand it right, that we now have TREL with OTBR on HAOS?

[twin vine]

Exactly that 😉

[digital salmon]

Wooohhoooo

Can this somehow have a negative effect on my existing thread network?

Currently I have 2 AppleTV 4K 3rd Gen with TREL.

[sick swan]

I don't follow, if you don't use our BR, how could that affect the Apple BRs? 🤔

But in general, I haven't tested TREL with Apple BRs on my end.

@spring bramble added a OTBR running on a Yellow, and I think for him it worked so far (even without TREL).

[twin vine]

I mean I’m not at home, but my OTBR within my apple thread network isn’t having any noticeable issues

[sick swan]

Ok so I did some digging, and it seems the OTBR adds IPv4 routes even when NAT64 is disabled, which is unnecessary (but should't matter, as forwarding isn't going to happen since no mappings are present). I've created a patch which fixes that. So from now on these routes should only be present when NAT64 is actually enabled. This gets rid of the warnings in the future.
https://github.com/openthread/openthread/pull/9762

I don't bother backporting/releasing a new OTBR add-on as it's only cosmetics. It will eventually be fixed when updating to newer OTBRs.

[vapid shell]

Will that get fired when you toggle NAT64 through ot-cli?

Actually I just realised i was assuming you could even toggle NAT64 on and off /at/ runtime. Sorry for noise if you can’t 😅

[sick swan]

Yes you can toggle at runtime!

And yes, routes get added/deleted when toggling the feature.

In fact, the current code removes the route when toggling the feature off. So if you toggle it on, and back off, the route is gone 😅

We actually just toggle it on on startup when the add-on flag is set.
https://github.com/home-assistant/addons/blob/master/openthread_border_router/rootfs/etc/s6-overlay/scripts/otbr-agent-configure.sh

[vapid shell]

Ah nice

[digital salmon]

Yes, you are right. At the moment I don’t have OTBR active. But I already played around with it, but removed my SkyConnect from my HAOS again, because Apple made TREL available.

So, now I ask myself, if it is time to play with it again. 😃

[digital salmon]

Which Thread Border Routers do you use at the moment?

[twin vine]

2 HomePod minis, Apple TV, Nanoleaf shapes & the OTBR

[sick swan]

Yeah sure go ahead and please let me know how it works for you 😅 It should be fairly safe as you can just remove it in case things go offline or you expierence other type of problems.

[sick swan]

Nanoleaf shapes acts as BR on the same network? Do they support TREL?

[twin vine]

Yeah they act as a BR
but for TREL, They didn’t in ~early November when I last looked, but there has been a few FW updates since so maybe? But honestly I doubt

[digital salmon]

So you still have the Nanoleaf shapes, that do not use TREL and you do not recognize any downsides?

[twin vine]

Nope

[vapid shell]

It depends on your network

[twin vine]

For sure

But give it a go

What’s the worse that can happen by trying

[vapid shell]

That you have to hard reset them and redo the config

I guess if you have time to run nanoleaf in the first place that’s not an issue 😅

[twin vine]

All part of the fun init 😆

[digital salmon]

Ok, I will try my luck, when my wife goes to bed. 😂

[vapid shell]

I got too old for that after the first year of tcpdumping this stuff

[digital salmon]

It’s not really fun sometimes, when you have nearly 50 Thread devices and something goes wrong… 😑

[vapid shell]

In theory trel is most useful when your mesh is unstable (lots of nanoleaf?) or weakly interconnected (widely spaced brs but no “router” devices?)

[digital salmon]

But I am going to try it, when I find the time.

[vapid shell]

In those scenarios packets going via the non-trel routers are less likely to get there

But on nanoleaf networks you probably can’t tell the difference between where trel would help and when your bulbs are just crashing

Trel should prefer infrastructure networks so packets should bypass more nanoleaf bulbs in the mesh so less likely to see eve devices affected when nanoleaf start crashing and re-meshing

[digital salmon]

Yes, I have 11 bulbs on my mesh, but I also have 14 EVE Thread Routers. Since the last Nanoleaf beta firmware update I had 2 lights switching on by itself and one bulb that became unavailable and didn’t find its way back to HA, while it worked in Apple Home. I removed it from current for some seconds, it came back to HA and AH and since that it’s relatively stable. Sometimes a bulb doesn’t react, when I want to switch it on/off. But when you wait some seconds and try it again, it always worked. So I think it’s the point, where the bulb crashed and reestablished the connection.

[steady forge]

The channel monitor is very handy. Now I know why my NestHub always forced the network to channel 13

[digital salmon]

What channel monitor are you talking about?

[steady forge]

new feature enabled in OTBR addon accessible via the ot-ctl tool

looks like that https://i.imgur.com/OiSLXMY.png

[twin vine]

Yeah, it’s a really nice QoL feature to have!

[digital salmon]

Oh, great, I am on channel 25 with my Thread network. My 2.4GHz WiFi uses only channel 1/6/11 and my ZigBee Hue Bridge uses channel 20 to reduce interference overall. But I am really interested to see what the channel monitor shows me. 😃 Thanks

@sick swan Isn’t this channel monitor something you want to expose to the HA Web Interface?

Maybe in the Thread integration…

[twin vine]

It’s disabled by default, so who knows

I personally don’t see much value to it other than debugging, and the docs for openthread seems the same

[digital salmon]

So should I enable OTBR Firewall and NAT 64, when I setup OTBR again?

[digital salmon]

So, I couldn't resist. I updated to HAOS 11.4, installed the OTBR addon, enabled NAT64, disabled the OTBR firewall and started the OTBR. Is this configuration right? When I look at my mDNS services, I see the trel.udp service on my Home Assistant. So, that is great. 😄

But I am unsure, if everything is correct. I see a lot of "Failed to update ipsets: Failed" in the log: https://paste.ubuntu.com/p/KvQQKBBwDW/

What do you think about it?

NabuCasa_SkyConnect_OpenThread_RCP_v2.4.0.0_ot-rcp_hw_460800.gbl is installed now. Is that the right firmware?

[spice imp]

shouldn't trel just help with packages into the network?

And responses should just use the best border router without trel

[vapid shell]

I was talking about packets going in, sorry if that was unclear

I believe it will help with bindings too

As it’s seen as a radio in the OTBR with a higher priority than the actual radio?

[sick swan]

So they did change channnel even with devices connnected? 🤔

[sick swan]

Yes this is the right firmware

[sick swan]

Hm, I don't have them. What board are you on?

[digital salmon]

SkyConnect in a HAOS VM (Debian 11 KVM). Or what do you mean by 'board'?

OK, this looks good to me: https://imgur.com/a/WOxdEyB

I extracted the network key in the past with an nrf52840 dongle and already set my thread credentials to preferred before it was possible to sync the thread credentials via the HA iOS app.

[sick swan]

Yeah, essentially which HAOS image you are using. So "ova". 👍

[digital salmon]

Yes! So, what do you think about the logs?

Thanks again for all your help. 😃👍

[sick swan]

Yeah it is a bit weird, I don't seem to have those on my end (on generic-x86-64 HAOS image). I quickly checked, IP set support should be enabled on the ova image just fine. I'll have to play a bit to see if I can reproduce this.

Do the message appear on restart again?

[digital salmon]

so, I tried to get it to work:

➜  ~ docker exec -it addon_core_openthread_border_router bash
root@homeassistant:/usr/src# ot-ctl channel monitor
enabled: 0
Done

That doesn't look right.

[steady forge]

ot-ctl channel monitor start

then ot-ctl channel monitor

takes a few counts to build solid data though

[digital salmon]

ah, ok, thanks

[sick swan]

Yeah I think it takes a sample every 40s or so.

[serene prawn]

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

[digital salmon]

Restart HAOS or restart OTBR or reboot HAOS?

[serene prawn]

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

[steady forge]

yes because it needs to sample more data for every channel

it starts with 100% on one channel until it goes through all of them

[digital salmon]

OK, good to know. So, I let do what it needs to do. 😄

[serene prawn]

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

[steady forge]

I've found that I need to up the txpower to reach through the thick walls of my apartment. Currently running "ot-ctl txpower 4" with better link quality than before. Using 9dbm seems already too much as it worsens LinkQualityOut of my thread device. A lot of fun to fiddle with

your environment doesn't seem very crowded with signals

[digital salmon]

Where can you determine the link quality? 🙂

[digital salmon]

I have a house and a big garden, no neighbour 2.4GHz technolgies (WiFi, ZigBee, Thread). I own the complete frequency band. 😄

[steady forge]

very lucky. I'm in the middle of a 4 story apartment complex

[steady forge]

I use the topology view of OTBR's web gui

https://i.imgur.com/oP9N3j4.png

[twin vine]

What’s it on a scale of? 1-3?

[steady forge]

3 is best, 2 is OK, 1 is frequent delays and dropouts (at least for my environment)

yes 1-3

[digital salmon]

Ok, I am not going to use it. The last time I played with it, it always crashed my Thread network. I have 47 devices active:

• 11 Nanoleaf Matter over Thread bulbs
• 23 EVE Matter over Thread devices
• 13 EVE HomeKit over Thread devices

[steady forge]

damn you went all in, huh?

[digital salmon]

Yeah, its a bit crazy. Not all-in at the moment. There are a lot more devices. But yes, I think, I am on the way to Matter (over Thread) only. I have lot more Nanoleaf bulbs lying around. But they have to deliver a new and reliable firmware before I am going to install more bulbs... Devices with Matter over WiFi I do not own at the moment.

[steady forge]

I'll probably stay with Zigbee for a long time for most of my stuff, I just want to be ready for thread devices (like the new Nuki Lock 4.0)

[digital salmon]

I want all the devices to be part of my Thread network. And if EVE would also have some bulbs in their portfolio, I would be all-in with EVE... 😄

[steady forge]

Eve is really not that great imo. My thread test device is an Eve Energy plug and it has pretty poor range compared to the Onvis one, it's only certified for 12A compared to the usual 16A and it lacks an Android app which sucks as I can't use their iOS app because I don't own an Apple border router

[digital salmon]

For me it works relatively stable. Sometimes I loose a device in Home Assistant, but it mostly still works in Apple Home. I can get it back to live by removing it from current. But its alsways only Home Assistant. Apple Home 'mostly/always' works.

[steady forge]

on top they're crazy expensive

[digital salmon]

but they are also crazy reliable and thats what I am looking for.

[steady forge]

Compared to Onvis and Nanoleaf most definitely!

[digital salmon]

There are not many other Matter over Thread player on the market, where you get most gadgets you want/need.

[steady forge]

I think it's pretty lame that Signify has no plans for thread support, I'm a fan of Hue bulbs and we use them almost exclusively

they're the most reliable Zigbee devices for me and they never have coil whine

[digital salmon]

Yes, absolutely true. I have round about 40 Hue bulbs/lights and 10 Hue Dimmer Switches and never had a problem.

[steady forge]

you live in a mansion, huh? 🤣

[digital salmon]

Yes, I had a similiar discussion with OwnedbyGravity here. He called it a poor mans castle. 😄

#matter-archived message

[steady forge]

haha

[old merlin]

Once a device is configured with thread, do they still need to be in the bluetooth range

or is it enough for them to be in wifi coverage?

[inner torrent]

It's enough for them to be in thread coverage

[old merlin]

what does "thread coverage" mean?

[inner torrent]

It means it needs to be in range of the thread network; that could be a border router or a thread router

Thread isn't the same as wifi although it uses the same spectrum

[vapid shell]

If you only have SkyConnect and an Eve Weather for example, you might find the range is not much better than Bluetooth, but if you add an Eve Energy half way between you’ll potentially double that range.

But every radio is different (size of antennae etc), and placement could reduce or improvement that gain

[steady forge]

lol through a strange combination of different apps and many retries I was able to pair a Nuki Lock 4.0 to HA without having a Apple or Google border router

And I didn't need to enter a 39€ code to unlock the feature. This shouldn't be possible...

[vapid shell]

Lol

Hope they don’t remote disable it for you at some point

[steady forge]

I don't know at which point it would normally ask for a code. I think they only put the Nuki cloud stuff (remote access to the lock from the app itself / airbnb type management) behind the paywall.

Again: Kudos to the Alexa app with its free Thread network selection. While it wasn't able to successfully pair the lock (to be expected right now), it did let the lock join my OTBR network and left it there for HA companion to pick it up afterwards

[young inlet]

Can I change the preferred thread network?

[spice imp]

Yes, do you have more context about your setup?

[young inlet]

Yep, HA setup my Eero routers as preferred network (3 border routers), but I also have Amazon, Apple, Google and 2 separate SmartThings thread networks. So wanted to be able to decide which of those is preferred. Also if anyone has experience on which one is the most “stable” for having various thread devices?

[spice imp]

All of them combined

Or in theory

If they are too far from each other and they dont support trel, then it can cause some instabilities.

I have no clue about how stable amazons or smart things is. Apple is probably one of the most stable ones, googles is also fine.

But if your Apple device is hidden in some closet in the basement, it might be smarter to use googles or amazons. So it depends on a lot of factors

I have had luck changing googles thread network, and from I can read, you can do the same with amazons. So you could maybe use the apple thread network and move your Google and amazon devices there.

[young inlet]

How would I do that (changing preferred or moving devices?? Is there a tutorial or anything online?

[knotty citrus]

Does https://github.com/home-assistant/addons/tree/master/silabs_flasher use different code/versioning as compared to https://github.com/NabuCasa/universal-silabs-flasher ?
I can program my Sonoff dongle using a standalone python env with universal-silabs-flasher package, but I get errors and am unable to flash firmware through the silabs_flasher addon inside home assistant. I traced through the addon code and tried using the exact same universal-silabs-flasher commandline options & firmware in standlone environment, and it works standalone but not in addon.

[knotty citrus]

Ah I do see addon's build.yaml is using an older UNIVERSAL_SILABS_FLASHER version 0.0.13, so that's likely a reason. Where/who do I ask to get this version updated to the latest (0.0.16) ?