thread-archived

[quick bronze]

https://tenor.com/view/mouse-thread-needle-cinderella-gif-8015272

[proud totem]

🧵

[normal arch]

yay

[half bluff]

I thought I heard someone mentioning they figured out how to incorporate the nanoleaf essential bulbs into OTBR? This is not through homekit controller/apple?

Anyone know?

[normal arch]

I have a nanoleaf essentials bulb connected to my OTBR but it still uses the homekit controller integration in home assistant.

[half bluff]

Oh I am sorry I meant to say is it directly connected to the OTBR? Not through apples thread network?

I want to try and connect it to the OTBR network not apples thread network

[normal arch]

in my case, I joined my OTBR to my nest hub and the bulb is connected via thread. I don't own any apple products (except this 10 year old macbook pro which I'm typing from).

I was able to join my OTBR to the nest hub by using the master key for the nest hub which was provided by the nanoleaf app (with no devices connected).

[half bluff]

Interesting so it must have joined either the nest hub thread network or whatever thread border router you are using (I.e Home assistant yellow/skyconnect)?

[normal arch]

I'm using zbdongle-e with zigbee+thread firmware that I built, but it's the same thing as skyconnect/yellow really

[half bluff]

Ideally that is what I want. I want to try and not have it connect directly to apples thread network. Not sure if that would work by joining the OTBR to apples border router?

[normal arch]

apple's thread is not good at the moment, they aren't on thread 1.3 by the looks of it

[half bluff]

Wait why did you have to join your nest hub?

[normal arch]

you won't be able to get your OTBR to join apple's without the master key of the apple thread network, I'm pretty sure

[half bluff]

Is there anyway to find that?

[normal arch]

and I joined my OTBR to my nest hub because I can't join them manually the other way around

[half bluff]

How did the nanoleafs get picked up by nest hub if they require apple homekit?

[normal arch]

I doubt it

since they are compatible with homekit and google home, when paired with google home, they get commisioned to the thread network

[half bluff]

Oh they are with google home? I thought they were only apple homekit

[normal arch]

it was just a matter of pairing with google home, then removing the device from google home which left it on the thread network, then it was discovered by the homekit controller integration in home assistant and the pairing process was as normal

[half bluff]

So thats what I do currently. Theoretically you wouldnt need the zbdongle if you did it that way.

[normal arch]

check the box, it says 'works with OK google, seamless setup with google home' on the side

[half bluff]

So the bulbs are on your google nests thread network. Not the zbdongle thread network

[normal arch]

yeah, but if I turn off the nest hub it will still work. I'm only running it this way because otherwise the nest hub wouldn't be doing anything and it's fun to experiment. I only have 1 nanoleaf/thread device anyway

[half bluff]

Interesting. And when turning the nest hub off its still using thread? Not bluetooth?

[normal arch]

I haven't checked, but it should due to my OTBR now being a router

https://ibb.co/RDQkdV9

[half bluff]

So in my world I would need to get these steps done.

1. Get the Master Key for thread from apple
2. Join OTBR from yellow to Apple thread network
3. Pair up my nanoleafs with homekit on iphone and then remove them one by one to show up in homekit controller
4. Disconnect all homepod/appletv hubs and see if thread on the nanoleaf bulbs are still working
5. If they are then I can reconnect the homehubs and hopefully the bulbs stick on the yellows border router.

I dont really see this being possible but thats my ideology behind it.

[normal arch]

yeah, I don't think you will get past step 1

[half bluff]

Lol

If only I could get step 1 I could test

Thanks for the explanation! Maybe in the future we will get direct connections to OTBR. Who knows.

Most will be covered by matter now but the small sliver of devices that dont use matter with thread.

[normal arch]

you will get it soon no doubt, the device will be able to be commissioned directly from home assistant onto the OTBR

@half bluff another thing to keep in mind. If you are using skyconnect or yellow with the multiprotocol firmware, make sure that zigbee and thread are running on the same channel. In my case, I had to change my ZHA channel to match what the nest hub thread channel was prior to joining. It will join just fine even if you don't but communication with zigbee devices will become unreliable and fail.

[half bluff]

I did that and my zigbee was still busted

I asked if they fixed it but I dont think they have yet

[normal arch]

oh that's not because of the channels thing, that's just the known bug

[half bluff]

How do you find the thread channel on your device? Doubt apple will tell

[normal arch]

the android nanoleaf app gave me everything in settings --> thread

[half bluff]

Yeah I dont think iOS app shows it all

[digital salmon]

Yes, there is a way to determine Apples Thread version. If you have an iPhone you can use the „Discovery“ app. If you don’t have an iOS device you can use every other mDNS browser, like “avahi-browser”. Look at your “.local” domain and there for “_meshcop._udp.” There you find „tv = 1.2.0“. tv stands for thread version. So yes, Apple still uses a Thread 1.2.0 network. 🙃

[half bluff]

I was talking about the thread channel number

[normal arch]

@digital salmon that's good info for apple users

[digital salmon]

Ok, so I understood you wrong… I don’t know how to find out the channel number. 😃

But it was hard work to find out which thread version is used by Apple. Someone on Reddit gave me that hint.

[half bluff]

https://openthread.io/guides/thread-primer/network-discovery

Seems to have info on network discovery but no info on how to find the channel

https://openthread.io/reference/group/api-channel-manager

[normal arch]

in the OTBR web gui, if you go to the 'Join' menu, I was able to see the nest hub thread channel prior to joining

channel 21 in my case, I don't know what logic google uses to determine the channel used or if it just uses channel 21 by default

[digital salmon]

Oh, yes you are right. I see channel 25. it’s the same channel my Philips HueBridge uses with ZigBee. Do they use the same frequency (ZigBee/Thread channel 25)?

Since I own my EVE Thread devices I recognized some small delays in my HUE setup.

[normal arch]

they can use the same frequency, but they don't have to in your case (if not using the multiprotocol add-on). You could possibly change the channel on the hue hub but I'm not sure about that, I've never used a hue hub

[digital salmon]

Yes, it is possible to change the channel on the HueBridge. But I have a big Wifi and all 2.4GHz channels are in use, except channel 13. Here in Germany we can use non overlapping Wifi channels 1, 5, 9 and 13 instead of only 1, 6 and 11. I don’t use Wifi channel 13, because ZigBee channel 25 overlaps

I don’t see neighborhood Wifi.

The plan is to get rid of ZigBee. But this can take years, because there not much Thread bulbs available at the moment. Only option is Nanoleaf. But the Reddit user feedback is not very well. I love my Hue system. It’s rock stable. 🙃

[normal arch]

the reddit users are crying because they have like 10 homepods and appletvs all running thread 1.2

[vapid shell]

There is a way now, but it is hard because the code isn’t finished and there are many manual steps. There is an API you can call over HomeKit ble to provision a device with the OTBR details directly. Eventually HomeKit controller will pair with BLE first, then get the OTBR creds fro HA and be able to seamlessly switch the pairing to thread mode. This is a way off working tho. But it works without needing apple thread or google thread or anything like that.

[digital salmon]

No, that’s not what I mean. I mean the missing support and warranty.

[normal arch]

the reason they feel support is lacking might be because they are having issues because of multiple homepods all running thread 1.2 and nanoleaf can't do anything about it

or the nanoleaf otbr are not very good, I'm not sure

uhh nanoleaf TBR I should say

it's not open at all

[digital salmon]

That may be true. But look at Reddit. There are also a lot of defect reports.

Why the hell is Apple still using Thread 1.2.0? I really don’t understand this.

[normal arch]

no idea

[digital salmon]

Did you try to reboot your iPhone? This works for EVE devices… Don’t ask me why. 😃

[vapid shell]

I have the 3 button one, 2 of them. They were a pain to get into HA. One of them was delivered with the wrong pairing code in the box. Had to work out the NFC pairing mechanism to get the actual pairing code!

In HA it shouldn’t matter what the device is doing, HA only does one version of homekit at a time, so if you pair it as thread it will only use thread (for now)

[viscid swallow]

Turns out there's a thread channel now! Just moving this here since it's a better place for it #matter-archived message

[viscid swallow]

What repo is the right place to report issues with OTBR?

[digital salmon]

If you go to the addon "Silicon Labs Multiprotocol" and look in the "Documentation" tab at the very bottom under "Support", you will find the following link:

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

Here is the official OpenThread GitHub page:

https://github.com/openthread/openthread

Please correct me, if I miss something.
Thanks

[tacit gate]

Im getting my HA SkyConnect delivered tomorrow and already got Eve Motion sensor with Thread (Matter to be supported soon according to their pages). Just wanted to check if SkyConnect supports adding Thread devices to HA running in docker container?

[vapid shell]

HA itself doesn’t talk thread, it doesn’t take the role of border router. If you have a border router running on your network using the SkyConnect HA can use it, as long are you don’t screw up your ipv6 networking.

If you use HAOS there are add-ons, but I don’t think there is official guide to running a standalone border router yet.

[viscid swallow]

Well it's not actually available in the list of addons to choose from when going there. My addon is crashing daily now and I'm not sure where I'm supposed to report it

[tacit gate]

Im running official HA docker image, so I guess I need to setup standalone border router. Any tip where to start? I can do some research and experimenting myself

[viscid swallow]

I reported it at https://github.com/home-assistant/addons-development but no idea if that's the right place.

[upbeat cairn]

Just saw your message here. Does this unresponsiveness happen after any Core/addon restart?

Or just after running for a few days?

[viscid swallow]

Can't say the other two times it happened for sure, but this one does seem to have happened around a core restart

if you need me to try anything let me know. Powering down and restarting was the only thing that fixedit last time

[upbeat cairn]

I've run across it a few times while testing and unfortunately the firmware just locks up, but only when restarting the addon

The Yellow is reset automatically when this happens. SkyConnect needs a power cycle.

[viscid swallow]

hmm and yeah I just replied on github, yes skyconnect

[upbeat cairn]

Feel free to @ me if you can find a way to reliably reproduce it, it'd really help figuring this bug out

[viscid swallow]

Unplugged rpi for a few seconds but no luck

[upbeat cairn]

My hunch is that just the addon needs to be restarted in a specific way. If you power cycle, it reboots everything and resets normally.

[sick swan]

The add-on is now in the official repository. I've moved the issue to that repo.

@viscid swallow one situation where I saw such problems was when I had something else accessing the serial port. Make sure you have only a single add-on running, and you disabled/removed any integration (e.g. ZHA) accessing the serial port.

[viscid swallow]

Nothing else should be using that port. I do use ZHA, but I have a completely different zigbee stick. But I'll keep an eye out for that

[viscid swallow]

@upbeat cairn I just tried installing 0.12.0. When it restarted the addon it now bootloops with this error FATAL in function 'protocol_version_check' in file /usr/src/cpc-daemon/server_core/server_core.c at line #610 : Secondary Protocol v3 doesn't match CPCd Protocol v2

[viscid swallow]

I think this may have been related to this version including a newer firmware and I had the auto-flash firmware turned off due to previous issues. Error message isn't the best though

[normal arch]

I tested the openthread only rcp firmware built with gecko sdk 4.2.0 and it failed with the openthread border router add-on. When I went back to the gecko sdk 4.1.3 built firmware it worked correctly.

• on zbdongle-e

[viscid swallow]

The bug report form is still not updated with the addon in the list. So there is no way to file issues, https://github.com/home-assistant/addons/issues/new?assignees=&labels=&template=bug_report.yml

[shut crow]

Thread is cool, I’d like to add a otbr setup. I have apple thread things but they have no firewall control so I wouldn’t really want to use them

I don’t want thread devices having internet access without my consent

Altho I’m super satisfied with zigbee too!

[sick swan]

Fixed.

[sick swan]

The error is from CPCd, not much we can do about it 😢

It doesn't seem to bad to me, in the end that is what it is: The firmware speaks a different protocol version than your add-on...

[viscid swallow]

Yeah I get you can’t change it. Thing is as a user I have no clue what cpcd is. “Firmware mismatch, did you forget to upgrade?” Would be much more helpful but I get its out of your control

[tacit gate]

I just got Home Assistant SkyConnect yesterday and wanted to test it out as a Thread Border Router. I tried to mount the SkyConnect into the Docker image openthread/otbr (https://openthread.io/guides/border-router/docker/run), but it seems like it has issues communicating with the dongle, like not finding it. Have anyone managed to get this work? With this Docker image or other? Anyone can share their docker config?

[vapid shell]

Out of the box it’s firmware is zigbee only, how did you upgrade it?

[tacit gate]

Aha, that might be the reason. I did not do any upgrade, but maybe I should? Any tip on how to upgrade/switch SkyConnect to support Thread?

[vapid shell]

the multi-pan firmware update was temporarily disabled, see https://developers.home-assistant.io/blog/2022/12/08/multi-pan-rollback/

there are other ways to do it, but i have not done them myself. if you look at the scrollback in here and #matter-archived / #devs_matter-archived you might be able to find some hints

[tacit gate]

Thanks! Currently I only care about testing out the Thread network, since I already got Sonoff Zigbee dongle which covers my Zigbee devices. So it would be nice if I could switch to Thread-only-firmware in SkyConnect, but that might not be a easy exercise?

[vapid shell]

Same reply as above, people have talked about it in here and the channels i've mentioned. not something i've done, and not something there is currently a 1-click process for.

[tacit gate]

Thanks! Im not expecting a 1-click process while experimenting with Thread and Matter at this point of time, so Im completely fine getting dirty on my fingers 😉

[arctic shore]

Hi All, I have a generic Thread/Zigbee Silabs USB adaper - I flashed some code to it and HA is showing

FATAL in function 'protocol_version_check' in file /usr/src/cpc-daemon/server_core/server_core.c at line #610 : Secondary Protocol v3 doesn't match CPCd Protocol v2

It was working for the last month, until I updated the SiLabs multiprotocol App this morning

[upbeat cairn]

Downgrade the addon to the previous release. There's a bug with the most recent SDK (4.2.0) and we've downgraded the addon to 4.1.4.

[arctic shore]

thanks! glad its not me and the wild mushrooms 😄

[upbeat cairn]

The next release on February 1st/2nd will be based on 4.2.1, which will also fix this bug. Subsequent releases shouldn't require major version downgrades, assuming 4.2.1 is stable.

[upbeat cairn]

If you install the latest version of the multi-PAN addon, it will auto-flash the correct firmware to your stick. It comes with OTBR. You can just ignore the Zigbee portion if you don't need it.

[tacit gate]

MultiPan is currently only supported on HA OS, while Im running HA in Docker. Is it possible to flash the firmware "manually" through CLI?

[upbeat cairn]

Flashing the firmware is easy (https://github.com/NabuCasa/universal-silabs-flasher), it's the multi-PAN libraries and binaries that are the difficult part: https://github.com/home-assistant/addons/blob/master/silabs-multiprotocol/Dockerfile

We'll soon have Thread-only firmware for the SkyConnect, so it can be directly used with OTBR (without multi-PAN).

[subtle smelt]

I think we had a powercut last night (HA reports everything going offline at the same time, ~3.30am) and now some of my thread devices are refusing to rejoin the network. I restarted my homepod, and all that's done is seemingly knock another device off the network!

Offending devices are two nanoleaf bulbs (stopped responding at 3.30am) and an Eve thermo & Eve door sensor (stopped with homepod restart). Interestingly turning one of the lights off and on at the wall made it rejoin the thread network for a matter of seconds, before it dropped off again...

Any tips? https://imgur.com/a/Ma2N1Vf

Edit: updated both homepods, restarted both at the same time, and eventually everything seems to have come back. One of the bulbs now has a "leader" status which I'd not seen before, so that's fun. 🙂

[vapid shell]

Homekit_controller definitely still has some challenges recovering that I’ve not yet got to the bottom of (I’ve seen HA restarts fix things with it). That said, problems recovering when the mesh is disrupted is one of the leading complaints on Reddit with official iOS/Eve/Nanoleaf. There are anecdotes of things taking hours to heal. So it’s possible that at least part of this is outside our control. But I’ve not personally verified those accounts and there are no logs for any of those products so who knows really.

[subtle smelt]

Ah ok, glad to know I'm not alone in this at least I guess!

[hoary harbor]

No pictures allowed so here's a textual representation of the box I got in the mail today with my SkyConnect in it:

▢

And the SkyConnect itself: ▢□

Looking forward to bugging the devs about when multi-pan is gonna work

[upbeat cairn]

Give it a shot, it's in the current beta

[sick sail]

anyone active that can help me with skyconnect? screwed upp my radio i think

[upbeat cairn]

How so?

[sick sail]

activated multi-pan . now my zha devices are not visible

"This entity is no longer being provided by the zha integration. If the entity is no longer in use, delete it in settings."

don't know what to do

[upbeat cairn]

How did you activate multi-PAN?

[sick sail]

in the hardware settings on skyconnect

after i joined the beta version of HA, so everything got messed up.

would like to get back to stable but i guess i can't because the new radio is flashed to skyconnect?

[upbeat cairn]

Have you tried rebooting and unplugging the SkyConnect/plugging it back in?

[sick sail]

not unplugged, gonna give it a try now and reboot also...

shall i restart hassos only or complete reboot of the host?

[upbeat cairn]

How are you running the OS?

[sick sail]

hassos

Home Assistant 2023.2.0b4
Supervisor 2023.01.1
Operating System 9.5
Frontend 20230128.0 - latest

[upbeat cairn]

On what hardware? Pi? VM?

[sick sail]

damn amazing!

haven't even rebooted, unplugged, and back in, it works.

felling stupid right now.. 🙂

[upbeat cairn]

Hmm, that definitely shouldn't need to be done

Did you restart the addon or ZHA before this happened? Or did it just not work after the migration?

[sick sail]

it didn't work after the migration i think, not sure since when i joined the beta i noticed that the energy dashboard din't show any graphs, tried to reboot so after several reboots i noticed that the zigbe devices din't show up also.

[fleet vault]

If you would start from scratch by today, would you try to force to get as much as possible using thread (even though it is still more expensive and not all device types are out to buy yet) or go for good old zigbee to create your mesh?

[quick bronze]

Right now, Zigbee

A year from now... maybe Thread and Matter by then will have matured enough, but I'd not hold out much hope

[fleet vault]

yeah, don't want to rebuy everything in a year 😄

but now it is really hard to find stuff

affordable stuff

[quick bronze]

You're using HA... you can run both

[fleet vault]

yes, just a little fear that both meshes are good enough then

for a house with multiple floors

also very hard to find good switchtes except shellys which are affordable

and they don't help either of both 😄

[hoary harbor]

Gonna disagree on that if you're running your own Thread border router. If you're stuck using Apple stuff then probably agree

I've had no issues running OTBR on a separate RPi with a dev board. Once all this moves out of "dev preview"/alpha state it's gonna be ezpz

[abstract oak]

Howdy all. Anybody know how to change the port Silicon Labs Multiprotocol add on OTBR binds its web interface to?

otbr-web[1004]: [INFO]-WEB-----: Running 0.3.0
otbr-web[1004]: [INFO]-WEB-----: Border router web started on wpan0
otbr-web[1004]: [CRIT]-WEB-----: failed to start web server: bind: Address already in use
[19:28:58] INFO: otbr-web ended with exit code 256 (signal 6)...

Nvm it was the Unifi controller stealing the port

[sick swan]

It is on my todo list to make it configureable.

[little yarrow]

Hi! Is there any word on the SkyConnect firmware update? If I'm correct I currently can only use it to create a Zigbee network, right? Where can I follow the development around SkyConnect? I'm currently a bit frustrated by my Thread devices disconnecting all the time and was hoping to fix this by creating a new network and not relying on homepods and apple tvs... So, any idea when the SkyConnect stick get the fw updates? Thanks 🙂

[vapid shell]

I think latest haos (with latest code) should offer you or have available a multi-pan addon, and that should upgrade the firmware for you

[little yarrow]

Oh, the Silicon Labs one? So install that and I can use the Skyconnect for both at the same time?

[upbeat cairn]

Go to the Hardware configuration and enable multi-PAN through that

It will install the addon and auto-migrate your Zigbee network. Otherwise, you'll have to configure the addon and migrate on your own.

[little yarrow]

oh wow, thank you. I didnt know thats already possible 😅 will try 🙂

[tacit gate]

Great news that multi-PAN is enabled again. However, Im running HA in Docker and the addon is exclusively available in HassOS. Im only interested in Thread and OTBR for ny SkyConnect

[little yarrow]

Okay, installation worked. I now got a thread and thread border router integration visible in my devices. But now I'm lost because I have no idea how to add a thread device... Only one showing up via the Homekit Controller integration. But I guess I dont want to use this anymore right?

And is there some kind of visualizer like the ZHA one?

[vapid shell]

Re homekit_controller. Its complicated. Especially right now. Eg AIUI matter doesn’t have energy monitoring. Homekit controller does.

But I think if either one works there’s no reason not to use it, both are local only protocols running over thread.

[full wharf]

Hello! 🙂 I was wondering if it was possible to run Thread in any way in the X86-64 platform based on containers. Either multi protocol or anything else, having some EFR32MG21 that I can flash with the multi-pan firmware.

[hoary harbor]

Multi-PAN so far not working near as well as separate OTBR

otbr-agent[275]: 00:02:50.640 [W] Platform------: RCP failure detected
otbr-agent[275]: 00:02:50.640 [W] Platform------: Trying to recover (1/100)
otbr-agent[275]: 00:02:52.718 [N] Platform------: RCP recovery is done```

Hella intermittent pings to Thread devices

Yooo my zwave also died and digging into that I found out some idiot (who could that have been?) configured it to a /dev/ttyUSBX path instead of /dev/serial/by-id/

I think that was the hidden cause of random issues I've had in the past

So zwave was trying to open skyconnect port, which I assume it didn't appreciate. Hoping that clears things up

[floral flare]

Any downsides to using an nRF52840 dongle as a thread rcp?

Years ago I planned on flashing my zbdongle-p to thread once master materialized, but it looks like open thread firmware doesn’t fit on the cc2652 memory anymore

[little yarrow]

what is AIUI? I got some lights connected via homekit controller, but they seem to drop the connection from time to time 😦

[vapid shell]

It stands for “as I understand it”

[little yarrow]

🫥 thanks

[vapid shell]

Do you have any logs of it breaking? If you filed a bug I mind be able to help. It’s all still very new.

[little yarrow]

I'll try to get one. But so far I only notice when I try to switch my lights on and the zigbee ones turn on, but the thread/homekit controller ones dont. Thanks for your help, I'll try to get some logs in the next days.

[old basin]

A newbie question, will this thread setup work with Home Assistant running in a Virtualbox environment with bridged network and WiFi ? Is IPV6 supported in a bridged network setup ?

[hoary harbor]

Bridged mode effectively puts the VM right onto your network, so that's the only way it would work

NAT mode would not work

[old basin]

@hoary harbor Thank’s for your answer, I have problems with my web interface for otbr so I was suspecting IPV6 problems ?

[hoary harbor]

What kind of problems? I don't suppose it's that you can't open the topology page?

[old basin]

@hoary harbor Yes, it displays a Ngingx page that says that I have to login to the admin panel to get started also I get otbr-web[394]: [CRIT]-WEB-----: failed to start web server: bind: Address already in use
[20:32:32] INFO: otbr-web ended with exit code 256 (signal 6)...
In the debug log.
But I suppose that everything is not ready yet.

[hoary harbor]

Something else is using the port that OTBR wants to use

[half marlin]

hi there, i just got my thread stick. im wondering is working with thread already?

is there any tut how to use it with thread devices? looks like i can just search for zigbee..

[vapid shell]

It’s also still very early and changing all the time so you likely won’t find resources like you can for zigbee

[half marlin]

well ok, i thought it will enable me to use my thread devices like plugNplay when it plug it in 😦

so as for now its nothing else then a zigbee stick right?

that's FCKn disappointing ...

[vapid shell]

That’s not what I said

[autumn merlin]

WTF? 😄

[old basin]

@hoary harbor Sorry to disturb you more but, I know but I can not find anything about what port it want’s to use so it’s difficult to se what’s going on, I’m running Nginx proxy for external access so the Nginx message confuses me 😃, I know that I use 8123 and 443 and that 8080 points to 8123 in my Nginx proxy. I also have a lot of integrations that uses ports MQTT, Z-wave JS, Mariadb and so on, I hope that more documentation gets available on configuration of OTBR.

[hoary harbor]

You're on the bleeding edge my guy. There is no easy mode and there is no plug and play. Figure it out or wait until general availability

[hoary harbor]

Googling "otbr-web port" gives me this as the first result: https://github.com/openthread/ot-br-posix/issues/280

Without knowing a lot more about your setup, perhaps there's an /etc/default/otbr-web file you can modify

[old basin]

@hoary harbor I’m so greatful to you 😃🙏, with your input I found out that my my Nginx proxy affected the setup 8080, changed it to use port 8082 and changed the router portforwarding, reinstalled the Silicon Labs Multiprotocol add on and now everything seems fine. 🙏🙏🙏

[little yarrow]

I just got this out of the logs. Seems like my thread devices become unavailable for quite some time and will reconnect somehow again after a while... Does this log tell you something? https://logpaste.com/qWMLAQ3Q

And in the Silicon Labs Multiprotocol add-on, do I need to join a network? It shows me a list of 6 in the web UI, but no idea how to join 😄 Will this basically join my homepods/appletv network?

[vapid shell]

That is a bug that I can definitely fix, it’s not handling if a read fails when the encryption session is already invalidated (it’s trying to invalidate it again). That’s probably not the root cause, but we can see what else happens without that in the way.

[little yarrow]

Sounds great, thanks 😄

[vapid shell]

Right now you probably can’t join your network with your HomePods, or maybe you can and it does unexpected things - the thread add-on is thread 1.3 but apple is still 1.2.

I don’t think anyone has made the bit to dump the thread keys out of iOS, which means we can’t try anyway. Although everything is moving so fast it could have happened and I’ve just not noticed yet.

[little yarrow]

Alright, thanks. Should I post my logs somewhere else?

[vapid shell]

No need thx

[little yarrow]

I will keep an eye on the logs and check if anything else will pop up

[hoary harbor]

Someone said one of the device vendor apps—eve or Nanoleaf, I forget which—will show your network key on android

If you wanna be the Guinea pig

[little yarrow]

There's not a single android device in my household unfortunately 😅

[vapid shell]

Annoyingly nanoleaf on iOS will show you the pan id and nothing else

[half bluff]

Has there been any progress on the development of commissioning Apple devices to open thread border router on home Assistant?

[vapid shell]

If you are talking about homekit over thread, I am trying to chip away at a large and painful migration in the BLE backend where it seems at some point we confused the hkid and mac, and that makes it hard to migrate a BLE pairing to a thread pairing (we need a common identifier to be able to reason about both transports). That will move us significantly closer to merging the commissioning PR. In parallel, the HA team is working on a thread integration that had a network store that holds the keys etc of all known networks - the OTBR one commissioned by HA + any that it has learnt from the android/iOS app. We can use that data to make pairing a HK device and get it onto thread pretty seamless.

[kind oracle]

Im trying to use the Thread integration, I have a the Open Thread Border Router addon working with devices comissioned,where can I find the URL for the API Rest?

[vapid shell]

If you are talking about the thread HA integration, and not one of the add ons, there is no REST API. It uses the HA web socket. Also there is no API at all in 2023.2.2, you need to use dev to see the current version. As per the docs it’s just a shell for work that is in progress. Obviously until 2023.3 whatever API there is is in dev is subject to change without breaking change warnings.

[half marlin]

where can i see that skyconnect stick is supporting thread? is there any website i can check frequently?

[vapid shell]

https://github.com/NabuCasa/silabs-firmware has the latest firmware files for thread and for multi-pan. if you are using HAOS then i think you can just go into the hardware tab and it will offer you the multi-pan add-on, which will upgrade the firmware for you as needed.

[errant ingot]

I'm trying to setup my first thread device. I have Home Assistant Blue with Skyconnect connected. I'm running the multipan firmware, I have the Silicon Labs addon installed, along with OpenBorderRouter. Within the OBR webui I have setup a thread network. Now I'm trying to commission a smart plug by Eve, by scanning the QR code from within the Home Assistant app on Android. That's where it fails, it tells me I need a Thread Border router, so it's obviously not recognizing my network on openborderrouter

[boreal crescent]

The Android device doesn't automagically know about HA's Thread network

An option to sync credentials will be added in the future (probably 2023.3 release)

[errant ingot]

Is there any way I can work around this for now and commission it through different means?

[errant ingot]

Nevermind, it worked through Androids built in commissioning dialog

[boreal crescent]

Did you get the option to enter credentials manually or is it using another network now?

The app does use the same data as the built in dialog...

[errant ingot]

I used the qr code for setup and then selected the home assistant app as a border router

and then it connected to HA

and then it broke for some reason and now it doesn't work anymore 😛

[half marlin]

i cannot flash back to the EmberZNet firmware, i always get "Error: Failed top probe running application"

[hoary harbor]

Have you tried turning it off and on again

[upbeat cairn]

Make sure ZHA/the addon aren't running

[low dew]

I've connected a couple Thread devices through the Homekit Controller integration, and my experience has been far from smooth. These devices frequently become unavailable for a couple of minutes at a time. I have a third gen Apple TV 4k 128GB that can act as a Thread border router, but I frankly don't even know if it's doing that right now, other than that I have configured it as a HomeKit Hub. I'd like to know whether I have set something up incorrectly, or whether I should be using a dedicated border router, or whether perhaps I should just wait for things to get better?

[vapid shell]

Hi. It’s all work in progress right now, and the experience differs wildly between environments. For me, with one HomePod as a border router and several Eve accessories using it the experience is mostly fine. Every once in a while the HomePod mini drops off the WiFi and things fail to recover. But that’s clearly the HomePods fault. But I know of others with 5 border routers and they have 5-10 min outages every couple of days.

Some of it is definitely homekit_controller, we are working on it but there are 2 of us with not much spare time. (Yay, kids).

But some of it seems to be the apple border routers, if you believe what you see on Reddit. (Reports of hour long outages if you move or power cycle things, and that’s using iOS not HA)

If you like I can DM you some diagnostics to run when things break so we can get a better idea of what’s going wrong for you.

[digital salmon]

Where can I get these diagnostics? Some days ago two of my three EVE devices with Matter firmware weren’t reachable anymore. EVE support suggested to reset the devices and don’t pair them with Home Assistent at least for the moment. Home Assistant now has Matter server addon 3.0.2. I repaired my EVE Matter devices again. The devices are reachable at least. The entities don’t do what they are expected to do mostly, but the devices are reachable and work with HomeKit.

[vapid shell]

I can only help with homekit_controller. That uses the HomeKit Accessory Protocol to talk to Eve devices over Bluetooth and Thread, not Matter. The diagnostics I want to run would help me to understand any edge cases where homekit_controller lost its connection. Matter is a different beast.

[digital salmon]

Yes, that would be great too. I would be very happy to learn how to analyze Thread Homekit Controller issues. I also have some EVE Energy Thread devices paired via HA HomeKit controller. But they seem to be stable.

I have round about 40 EVE Thread devices, 3 of them with Matter firmware and two of them are directly connected to Home Assistant HomeKit Controller.

[vapid shell]

Right now it's more of a guided joint debugging session on homekit_controller, i'll be happy to help you if you start having homekit problems though.

A good place to start though is always https://apps.apple.com/gb/app/discovery-dns-sd-browser/id305441017, and look at _meshcop._udp and _hap._udp. Also look at the output of ip -6 route from inside your HA container. when you know the addresses of your devices you can ping6 them to make sure they are reachable. it's really hard to say more unless i'm helping you with an actual homekit problem though.

[subtle smelt]

I'm similarly experiencing some issues with homekit stuff at the moment; trying to re-setup my nanoleaf bulbs & eve devices on HA. Made sure they were connected via thread first, removed them from iOS, attempting to reconnect them in HA and getting this:

An unhandled error occurred while attempting to pair with this device. This may be a temporary failure or your device may not be supported currently: [Errno 113] received through errqueue

Did a factory reset on an eve motion sensor, after which HA was then able to pick it up and connect to it (although now it says the thread status is disabled, which makes sense). Now getting that error on a nanoleaf bulb and don't really want to reset that as I find it was worse at joining the thread network. Any suggestions?

[subtle smelt]

I feel you on this btw. I've not yet taken to contributing to HA, but is this something any community member with development skills can poke as well? (Also when the kid allows me some free time, that is 😂 )

[vapid shell]

i usually see Errno 133 when there is ipv6 connectivity issues

is this a HAOS box or Debian or something else

[subtle smelt]

HA on a Pi 4

[vapid shell]

but HAOS or HA Core or

[subtle smelt]

Oh sorry, HAOS I think? "Home Assistant 2023.2.2, Supervisor 2023.01.1, Operating System 9.5." (Let me know if there's somewhere I should be looking for this - it's through however the installation guide for installing on a Pi suggests)

[vapid shell]

Thats HAOS yes

And ipv6 is turned on in HAOS's network settings? Set to auto?

[subtle smelt]

Set to DHCP, other options are static and disabled

(Networking is my weak point, I'm guessing that's the same as auto, but being specific in case it's not)

[vapid shell]

i haven't seen HAOS's settings, but yes i'm hoping thats the right one

have you got SSH working?

[subtle smelt]

I can do shortly

[vapid shell]

grand

[subtle smelt]

Oh wait I have. terminal extension on it already

So yes

[vapid shell]

i need you to get into your HA container (which hass will print /usr/local/bin/hass if you are in the right place) and run ip -6 route

[subtle smelt]

so which hass gives me nothing - should I need to be SSHing using this https://developers.home-assistant.io/docs/operating-system/debugging/ instead of the Terminal & SSH addon?

[vapid shell]

does docker work?

[subtle smelt]

no docker either

ha docker gives me some bits

but none of the usual goodness like exec

[vapid shell]

i was sure someone with just the Terminal & SSH addon had been able to do this before but i have no idea - i run the container directly myself

the OS debugging thing will definitely do the job if you can try that

[subtle smelt]

Sure, it's that or documentation for work, so lemme go find a USB stick lol.

[subtle smelt]

https://pastebin.com/24z2Rv3z

[vapid shell]

can you do apk --no-cache add iproute2 and then repeat the ip -6 route

[subtle smelt]

apk isn't found, one mo

[vapid shell]

if you are inside the HA container it should be

[subtle smelt]

oh yeah duh

https://pastebin.com/b2i9CKqC

[vapid shell]

ok good - 12 border routers are having their RA's processed by your HAOS

[subtle smelt]

12?

[vapid shell]

weirdly the fd8b network has 11

[subtle smelt]

I have two homepods

[vapid shell]

lol

and yet

[subtle smelt]

How is it showing 12 😂

Ok

[vapid shell]

i guess we should figure that out

if you don't have 12, it could mean you have ghost routes that are non functional

can you install https://apps.apple.com/gb/app/discovery-dns-sd-browser/id305441017

and look at _meshcop._udp - that should have all your border routers

should help figure things out

[subtle smelt]

Yep ok

That's just showing the two: fe80::183c:9a18:ed1a:b18b and fe80::c01:b308:f509:dff0, both near the bottom of each list in the pastebin

[vapid shell]

can you ping6 both of those?

[subtle smelt]

Both respond

[vapid shell]

what about the others

im guessing/hoping they don't work?

[subtle smelt]

No response, correct

[vapid shell]

ok

so when RA's are added they are given a lifetime

thats typically 30 minutes

after 30 minutes they should fall out of the route table

if they don't go away, /something/ is adding them

you could restart HAOS entirely and see if they come back

i think if they do go away, you'll be left with 2 functional routes and your problem in HA will go away

i hope, anyway

[subtle smelt]

Ok. I've tried HA restarts before to no avail, so I suspect they might not - let me restart it now and see

Is a restart from the developer tools enough, or should I pull the plug on it for a few seconds?

[vapid shell]

needs to be a full reboot

i think dev tools just restarts the HA code which wont be enough

[subtle smelt]

Alright cool. I'll go restart the pi, sec

lol and now it's failing to boot properly. did have issues with the disk the other day as well - gotta go get a monitor for it, sec

[vapid shell]

hahaha

[subtle smelt]

yeah it's just crashing in the boot cycle and restarting over and over

honestly

-_- I'm going to have to reformat the disk again haha. thank god I enabled auto backups

[serene prawn]

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

[vapid shell]

let it warm up for 10 mins and then check again

only see one via atm, want to see the other homepod show up

then try and set up your homekit device again and see where we are at 😆

@subtle smelt whats it looking like now then 🙂

[subtle smelt]

Looks like just the two at the moment (sorry, was on a client call), so will do the setup again in a moment and see what happens 😄

[vapid shell]

fingers crossed

Baffled how you got up to 12 routes but we need to keep an eye out for that happening again

Stale routes is one of my big concerns for homekit over thread stability with multiple brs- you’d almost be better off with one br :/

[digital salmon]

Ok, thanks! ping6 is a good idea. Ok, lets wait and see.

[flint zodiac]

I suppose I can't just make my iPhone accept HA's border router as stand-in? Apple insists on one of their own devices?

[halcyon quartz]

Had an essentials bulb stop responding. I’ve removed it from hass, reset it and connected to HomeKit. Now when I remove it in home app, HomeAssistant isn’t discovering as it did first time round, any ideas?

My other one of the same bulbs continues to function normally

[vapid shell]

Can you add it back to Home on iOS? There’s a chance it’s not removed from home cleanly and it still thinks it’s paired.

Otherwise there’s a mesh or mdns problem stopping HA from seeing it

[hoary harbor]

If you're using HAP/Thread devices then yeah probably. Matter/Thread supposedly should work with any BR.

[worldly forum]

Hi, is there a recommended way to resolve the port conflict between the unifi addon and the open thread border gateway addon?

[visual badge]

Hey all, a bit confused about the state of matter and thread, what the role of a border router is

I’m expecting some Thread smart blinds soon, and am not sure what I need for them to work nicely in home-assistant.

Is a Thread Border Router what I need?

I have a smartthings hub v3 that I stopped using once I swapped to Home Assisstant, and I read they were adding some combination of Matter and/or Thread support to it. Is flashing that with the latest firmware and plugging it in via ethernet enough for HA to pick up any Thread devices? Or do I need to get a SkyConnect or upgrade my ATV 4K to one that has a built-in border router?

[visual badge]

SmartThings Hub as Thread Border Router?

[viscid swallow]

Can anyone explain what exactly the caveats to having the OTBR web interface actually means and why it means we don’t want it turned on?

[restive fable]

What do I need to be able to use matter and thread? (Currently rpi4 running hassio and an aeotech gen5 dongle)

[autumn merlin]

So, i can now see a thread network in the OTBR web interface… Would i be right that this is the HomeKit one? https://imgur.com/a/P6V6D3m

[viscid swallow]

I can’t tell you if it’s HomeKit but I can tell you it’s not one created by OTBR if that’s your question

[autumn merlin]

Just interesting to see the changes as I could not see anything there before

[tulip oriole]

hey, i tried to activate SkyConnect Multi-PAN but got multiple errors: https://pastebin.com/uPXJaNyg

i tried to migrate the configuration and selected the same (and only) device. now it seems to work fine again

[cobalt solstice]

Hi, how can I connect Google Nest Hub 2 to same thread network as I have created in addon OpenThread Border Router in HA. When I select Join in menu I see all my Hubs which have thread network, but all has own network and I want have one thread network. Thank you.

[viscid swallow]

Anyone?

[vapid shell]

Isn’t it like shipping phpmyadmin with a web app when the user is meant to be using your integrated application aware admin tools?

There didn’t seem to be much to that UI when I looked at it tho

[viscid swallow]

Maybe? I guess I'm asking about However, the web interface has caveats (e.g. forming a network does not generate an off-mesh routable IPv6 prefix which causes changing IPv6 addressing on first add-on restart)

[vapid shell]

Isn’t that just a polite way of saying “it’s going to do broken stuff that just leads to support requests right now”

[viscid swallow]

Perhaps? Reason I was asking is because I don’t understand what it’s saying.

[vapid shell]

Simplifying it a bit but typically you have 2 /64 ipv6 subnets created by your border routers, one on the lan side and one on the thread side. Routes are set up in both directions so network A can reach network B and vice versa. One is the omr. If both don’t exist then you don’t have working bidirectional networking between your LAN and thread mesh.

[vapid shell]

it's kinda like your router made you a new vlan but its DHCP server wasn't started until you rebooted

[autumn merlin]

Hey all - been having some issues with Nanoleaf Essentials light strips connected via thread and home controller. They have been solid for ages and in the last few days I’ve had to reset them several times. Got this error in the logs:

023-02-12 07:44:19.081 ERROR (MainThread) [coap-server] Error received and ignored in this codepath: [Errno 113] Host is unreachable
2023-02-12 07:45:29.935 ERROR (MainThread) [aiohomekit.controller.coap.connection] Decryption failed, desynchronized? Counter=17/18
2023-02-12 07:45:29.937 ERROR (MainThread) [aiohomekit.controller.coap.connection] Failed flailing attempts to resynchronize, self-destructing in 3, 2, 1...
2023-02-12 07:46:27.724 WARNING (MainThread) [aiohomekit.controller.coap.pdu] Transaction 0 failed with error 6 (Invalid request

Any ideas on where to start with this?

[vapid shell]

It’s a sign of network connectivity issues

Do you have multiple HomePods/ATVs?

There are several scenarios I keep seeing. Sometimes Linux just loses the ipv6 route to your BR. They just vanish even though the BR is still reachable. This is outside of HAs control, but still working on finding the root cause.

I’ve seen restarting the border router leave ghost routes that Linux is picking over the valid ones. In the most extreme case there were 12 routes but only 2 border routers. Again, that’s an OS or thread problem not HA.

Another one is where one border router has a bad connection to the mesh. If HA happens to get a good route things will be stable for days. Then one day the OS will decided to prefer the “bad” border router and suddenly your devices go offline every few minutes.

Resetting the devices isn’t fixing the issue, it’s just changing the ipv6 address which just causes the route Linux picks to be different for a short while.

Right now the most stable configs are the ones with the least border routers.

I’m working on some diagnostic tools to detect these scenarios, but not ready yet.

[autumn merlin]

Thanks for the quick replies @vapid shell - i have 2 ATVs, one 1080p one which is on wifi, currently offline (its in our covered outdoor deck and off as there is a storm coming), but also completely removed from HomeKit. And one 4K (not the latest one) which is Ethernet and on 24/7.

[vapid shell]

Funnily enough at least 2 of my outstanding cases are Apple TVs

[autumn merlin]

I also have SkyConnect running Multiprotocol FYI

Further to this, the other day i woke up to both ATVs with red alerts in HA, needing to be reconfigured. And thats also when the issue with the thread lights started happening.

I think 🙂

[vapid shell]

Right now I’m not entirely sure how to get iOS to use the SkyConnect, but I have a branch in flight that will let you pair directly to HA with BLE then migrate it to the SkyConnect. Hoping it will be in 2023.3.

Don’t suppose your ATV is in a cupboard with your other video/audio gear? That’s also a common thread.

[autumn merlin]

Actually no. Behind the TV in the living room.

[vapid shell]

Unfortunately I don’t know how to get any diagnostics out of them so so far it has been manually monitoring route tables, tcp dumping icmp6 packets and pinging all the things.

Somewhat tedious

[autumn merlin]

No problems and thanks again. The pairing and migrate sounds good! On a side note: I have nearly all Hue stuff in the house in terms of lighting, but went with the nanoleaf essentials for our kitchen… i wish i had stuck to hue. Im now looking at replacing them, but some of the stuff is inbuilt.

[vapid shell]

Yeah I’m all hue. Actually was via homekit (we had push events way before the hue integration did 😎)

[half bluff]

How do we setup this branch mode?

[vapid shell]

I’m not ready for testers, please wait a little bit longer.

[half bluff]

Ok

[autumn merlin]

Sorry off topic again in the thread chat, but a quick question: Do you still use the hue bridge or are you all direct to HA

[vapid shell]

I used it with hkc for years, but about a month ago I moved it, Aqara and Hive all from homekit over to a SkyConnect and Z2M.

It seems faster, but is also every so slightly less stable.

[autumn merlin]

The lights just became Unavaialble again. Interesting that a HA restart sorts it out and they are availble again, but sshowing this in the error log: 2023-02-12 11:36:42.643 WARNING (MainThread) [aiohomekit.controller.coap.pdu] Transaction 0 failed with error 6 (Invalid request

[vapid shell]

I wouldn’t worry about that, tbh the log is probably just going to get removed or downgraded.

[royal light]

Is it possible for HA to utilize the Thread radio and BGW on a modern Eero router?

Noticed the network my Nanoleaf Essentials bulbs and the Thread network can be seen via mDNS browsing…

[cobalt crystal]

No sane networking person will suggest an Amazon eero device lol

[cobalt solstice]

how can i setup my google nest hub 2 for thread, in OTBR i can see all my hubs, but all have set same PAN id "0x41D5 " which is wrong, because all devices must have unique id for communication, and another problem, looks like each hub has own tread network a I need set ext PAN id for each device same if I want have all on the same thread network.

[worldly forum]

may have solved this accidentally by getting some nanoleaf shapes

[flint zodiac]

If I have a Homepod on the same WLAN as my HA Yellow, can I make latter use the Homepod as border router? If so, I presume it'll require 2023.3 to match credentials and all that?

[vapid shell]

Maybe. Eventually. If you are lucky. For one thing, right now HomePod is thread 1.2 and HAs OTBR is 1.3.

[flint zodiac]

That much of a problem? Hopefully they'll bump that with the iOS 16.4 line of updates. Something something new Homekit architecture blah blah.

[vapid shell]

No the new homekit architecture is making your HomePods handle the connection to your HomeKit devices

Right now your iOS device directly connects to every pairing

By having your HomePods cache the latest state the iOS app just “pops”

I haven’t seen a pr against the iOS app to sync the thread credentials, that’s a bigger problem in the short term

It doesn’t rule out what you want just the schedule

[flint zodiac]

Well, I kinda still have time. I need/want Matter to support energy metering, anyway. And Aqara didn't release their M3 hub yet, either.

[vapid shell]

Yeah I mean the matter hub update won’t even need thread anyway

Unless you are getting all new Aqara devices?

[flint zodiac]

I have like 20ish of their Zigbee sensors. Probably cheaper to get a hub of theirs and have it translate, and replace them with native ones, whenever they finally break. And they haven't announced a Thread capable temperature/humidity sensor so far, anyway.

[vapid shell]

Indeed

So no rush

Right now when I hate myself I spend my free time supporting users with multiple border routers anyway

[flint zodiac]

I'd have figured that all this Thread business was supposed to avoid any kind of connectivity drama. Oh how naive I am, I guess.

[vapid shell]

Routes via border routers that don’t exist, routes that inexplicably disappear and reappear, devices that fall out of range of one HomePod and not another. None of those cases are especially handled

At least with HomePods

[glass granite]

Not sure if this has been covered, but I do have a SkyConnect with the MultiPan firmware up and running like a charm (I think).

Is there a good way to add Thread devices to HA yet then? I’m looking at adding my Nanoleaf Essentials to the HASS Thread, but not sure what the PSKd is for these devices or how to force the HomeKit controller integration to scan for Thread devices vs the Essentials’ Bluetooth

I do have an AppleTV 4K, and have it paired through that Thread network for a bit but it seems kinda flakey and I’d rather have HA control the bulbs directly vs going through the TV

[vapid shell]

I’m working on a PR that will let you migrate nanoleaf essentials/eve etc homekit devices from ble to thread where supported. It’s working quite well, hoping to get it into 2023.3 in some form.

[glass granite]

If you need testers, let me know! Happy to help and get more devices on Thread

[half bluff]

You get this working and im buying you dinner!

[royal light]

Are there docs on using Google or Apple as border router?

[royal light]

Or just hints as to what to put in which config file to say “hey, I have a border router over there” or “it’s in mDNS go find it”

[hoary harbor]

Working with as much "enterprise grade" software as I do, the development pace of HA is just astounding. The devs do great work.

[hoary harbor]

What're you trying to do?

[royal light]

My eventual endgame is an Eve (Matter) motion sensor and some Nanoleaf Essentials sitting on my Eero-based 802.15.4 Thread network.

Saw a blog entry on some of the progress that mentioned interacting with Thread networks that used Google or Apple devices as border routers, and am assuming getting my Eero working will follow a similar path.

Also, just noticed new core landed than I should update to, says the release notes.

[royal light]

It sorta stands to reason that if I can tell the Matter server the Thread credentials for my existing mesh... shouldn't it be able to reach my existing border router via ethernet PHY?

[royal light]

Or does HASS only know how to be a border router node in Thread?

[hoary harbor]

Do you have a way to get that info from Eero? To commission a thread device via HA & Matter you need the thread “dataset” which has thread name, passkey, etc

[vapid shell]

In the next release of Ha there will be a thread control panel. Where the companion apps can learn about border routers automatically they will sync the creds to HA. Otherwise you’ll able to manually add the creds to HA.

The ultimate plan is that you’ll be able to merge networks from this panel.

For the nanoleafs which can’t support matter, you’ll be able to pair with homekit over Bluetooth and then there will be an extra step to migrate the pairing to the thread network from your thread panel.

If you can get a device onto thread via other means HA doesn’t technically need to know about the network creds

It’s just straight ipv6 after all

[half bluff]

Does this mean they will use the thread router or migrate in the yellow?

[vapid shell]

Not sure I follow the question

[glass granite]

Is there a way to manually do this now? I was diving around OpenThread docs, but I think I may have gotten too in the weeds haha. I have a Thread network already created with my SkyConnect, but not sure how to manually get a Joiner to Join

[royal light]

Interestingly, the Nanoleaf app will let you browse the Eero's Thread network (I only have Essentials bulbs). Their app shows the Name/PAN/ExtPAN and master key.

[royal light]

I have my Nanoleaf Essentials on my Eero thread via their integration. I still love that Eero has a <ul> in their list integrations. 😆 https://support.eero.com/hc/en-us/articles/360000104706-What-is-Thread-

But the lights seem to work well frame both the Nanoleaf app and Apple Home without a HomePod.

[royal light]

Soooo I can see my bulb in _hap._tcp and _hap._udp… and _ltpdu._udp… seems quite findable. Starts Googling

[royal light]

oh, guess someone already reverse engineered those bulb's protocol. https://github.com/roysjosh/nanoleaf-ltpdu
https://community.home-assistant.io/t/homekit-accessory-protocol-hap-over-coap-udp-was-nanoleaf-essentials-bulb-via-thread-coap/335167

[glass granite]

If we have them paired over BLE now to HA, could we just kinda skip the steps listed here starting at step three minus the aiocoap dependency? https://community.home-assistant.io/t/homekit-accessory-protocol-hap-over-coap-udp-was-nanoleaf-essentials-bulb-via-thread-coap/335167

If we wanna feel spicy and be an early adopter

[royal light]

yeah, we found the same stuff... huge threads to read

[vapid shell]

You are talking to one of the maintainers of aiohomekit 😉

In 1 week the beta for the work I already told you about well open (last Wednesday of the month) and then it will be released on the first Wednesday of the month

If your bulbs are listed in _hap._udp but haven’t already been discovered by ha then I guess they are paired to iOS. Unpairing then should make them pop up in HA

You can do that with the current stable HA release. That’s been in prod HA for a few months now.

[vapid shell]

That thread is probably a bit out of date, and you didn’t link to a specific comment so I can’t tell you how out of date. But eg if you want to pair with BLE and then migrate, the branch it mentions in there has changed a lot and also got merged and released so you don’t even need the branch.

[glass granite]

Ah shoot, I’m sorry I meant to link this one: https://community.home-assistant.io/t/homekit-accessory-protocol-hap-over-coap-udp-was-nanoleaf-essentials-bulb-via-thread-coap/335167/93

Would your suggestion be to just wait for the beta then and practice patience? 😅

[vapid shell]

Yes, that one is horrendously out of date lol. All of the manual steps were merged and released many releases ago.

what state are you in right now? you have a SkyConnect, and an OTBR running? are you trying to extend an existing network, or happy just to use OTBR on its own?

[glass granite]

I have a SkyConnect running the Multi-PAN firmware and a thread network made with it, but I guess I’m missing the steps to transfer the Nanoleafs to Thread from BLE

Cuz, lord BLE is slow with these

[vapid shell]

ok good

you are in a different place to kylev, they can probably use the stable release already as their devices are visible via zeroconf already

your setup is similar to the one i'm using for testing the stuff i'm hoping to land today/tomorrow

you probably should just wait for the beta :p

HA is using time based releases, beta always on last wednesday of the month. and its a short month.

[glass granite]

Yeah that’s what I was thinking 😅 I can handle slow lights for another week or so haha. I just miss how fast they reacted when running on Thread

[hoary harbor]

time based releases, with new releases every three days! 😉

[hoary harbor]

Interesting scenario with my Skyconnect. ZHA is configured for channel 25, and seems to be functioning at that channel. But my Thread network I had already created is on channel 11. And the OTBR web UI in the silabs multiprotocol addon does say it's connected to my Thread network

I will say zigbee is suuuper unreliable at the moment, which I assume has to do with this. If I try to change the Thread channel with ot-ctl channel 25 I get "Error 13: InvalidState"

And I'm not sure if I form a "new" Thread network with all the same info but on a different channel whether my devices will follow. I don't see why they would? Unless there's something in the spec where BRs are sought/prioritized

[hoary harbor]

Same ot-ctl channel 25 fails with same error on my own Thread dev board/Pi combo (my old OTBR), so I'm guessing it just can't do it while joined

The Thread spec talks about channel hunting all over but I'm wondering if that's only during the initial commissioning and not once it has an established connection

Good news is zigbee works beautifully now that its configured channel is in alignment with thread. Bad news is I probably have to re-pair my bulbs. Oh well

[normal arch]

I had that issue, I just changed the zigbee channel to match

[royal light]

Alas, deleting the Essentials bulb out of iOS de-provisions its Thread (802.15.4) connection. But, as you mentioned, once out of iOS it was possible to provision with Bluetooth (discovery included). Nice!
I was hoping to trick it into staying on the Eero network in some way. 😆 Didn't realize how inextricably linked to Home the Nanoleaf provisioning is, despite my lack of HomePod. Looking forward to the next release, but now I'm gonna finish setting up my development environment!

[vapid shell]

Very odd, I have 4 different models of device from 3 different vendors (including nanoleaf) and unpairing from the iOS Home app (not nanoleaf app) leaves them on my thread network. I know others with other nanoleaf gear (including bulbs) have had the same. Did you use the home app?

Sometimes the eve ones don’t cleanly unpair over thread and I have to hard reset them, that does obviously remove them from thread.

[royal light]

Yeah, I deleted them in the Home app and they dropped from the Eero network (as can be browsed from the Nanoleaf app). Unless there's something about the Nanoleaf app that relies on an Apple API to inspect the network... anyhow: couldn't see it on the network with vendored tools anymore.

[vapid shell]

Oh so you aren’t looking with a zeroconf tool?

The eve app can only see devices that are currently paired with iOS

So the nanoleaf app is probably not a reliable test

Can you try again but with https://apps.apple.com/gb/app/discovery-dns-sd-browser/id305441017?

[royal light]

I've been using Discovery. What would you like to know? I can see my Eero Thread network in _meschcop._udp. That seems constant.

Right now, with the Essentials A19 hanging off the Pi4's Bluetooth, I see it in _ltpdu._udp and _hap._udp (but not _hap._tcp, that's the HASS Bridge now).

[hoary harbor]

If it’s showing up there it’s on your network

Should show an IPv6 address if you tap on it in discovery

The essentials bulb that is

[royal light]

sure enough!

I'm a little mystified by that... pretty sure I'd done a full reset on the bulb before adding it to HAS. Is the eero advertising the Thread credentials somehow? Or did they survive the on/off reset?
Super excited to have control, tho.

[hoary harbor]

You reset it by toggling power… I wanna say… 5 times?

Flashed red three times after?

That should definitely wipe Thread info

[royal light]

yeah. I'm doubting my recall. gonna call that a ghost sighting.

[royal light]

BWAHAHAHA. I just checked my mail and my SkyConnect arrived. Time to rework the Thread network?!

[vapid shell]

Full reset would have indeed wiped the thread credentials. If you simply remove it from the Home app UI (Apples UI) and you don’t have mesh instability at the time, then the bulbs would be left in pairing mode on their existing thread network. But you absolutely should not be doing the full reset procedure.

Of course sometimes these procedures fail. It’s fairly common with eve battery powered stuff to not cleanly remove itself from home when asked, but iOS drops the pairing anyway. That can leave it paired, but invisible to the nanoleaf and home apps.

It should be super easy to get these onto SkyConnect in next months release.

I would avoid multi-BR setups right now. We are still investigating some weird issues with stale routes and bad routing decisions that are seemingly more noticeable in those setups. At the very least accept right now more BRs does not mean more stability.

[hoary harbor]

Bus 001 Device 012: ID 10c4:ea60 Silicon Labs CP210x UART Bridge```

oh good lol

zooz and skyconnect same ID

[glass granite]

It really throws ProxMox for a damn loop if you try to pass them through lol I had to end up passing through by USB port number

[hoary harbor]

Yep, exactly what I ran into

“Uhh why is HA showing my zooz stick twice?”

[rapid umbra]

Can confirm, been trying to use HA Thread with 5 homepod BRs and its been absolutely dreadful the past few months. Every time one of the homepods restarts/updates the entire network needs to be power cycled

Which means unplugging all the homepods (sometimes only just the active hub is all that’s needed) as well as a hard power cycle on home assistsant (restarting thru the UI isnt enough, it still seems to use stale routes)

I’ve got my skyconnect stick in the box waiting for next month’s release, hoping things will get better when HA can act as a border router itself but seeing your last comment doesnt leave me optimistic

[vapid shell]

you might be interested in this: https://github.com/home-assistant/operating-system/discussions/2333#discussioncomment-5027740 which explains just one of the challenges we are facing

i think a single skyconnect will be better than multi-BR

but i haven't run it enough in production

[rapid umbra]

I will take a look at that topic, it does seem to explain the issues I’ve been facing

I’ve been following along since the early nanoleaf provisioning days on the old COAP thread

Using home assistant OS as well

[rapid umbra]

Will I be able to configure the network so skyconnect will always be the main border router? I’d like to avoid ever having one of the homepods take over as BR if possible

Still want to keep them in as smart speakers/thread extenders but I want HA to be the main thread hub as its hard wired to ethernet and offers more granular control

[vapid shell]

Yes and no

You can’t have them as thread extenders

The fact that they are different versions of thread aside

if you could you would open yourself up to the issues in that link I posted

You’ll be able to configure the SkyConnect as an independent thread network and connect your homekit devices to it

And keep your HomePods as they are

But not part of the new mesh

That will get you working speaks and (probably) working thread

[rapid umbra]

I guess that wouldn’t be the end of the world, as nanoleaf bulbs should be able to make up for the gaps in coverage that the homepods used to cover

As long as the network actually remains stable. As it is now I can’t get everything to run for more than like 2 days at a time until one of the routes goes stale and I have to cycle the entire network

Appreciate all the work you and lambdafunction have been putting in behind the scenes, been keeping up with this development for a while now and it’s been coming together much faster than I expected 🦾

[vapid shell]

Fingers crossed

In the meantime I feel like we are making progress understanding what is going wrong with the apple border routers. Still a way to go, but not as hopeless as I thought

[rapid umbra]

Seems like growing pains to me

No doubt in my mind you guys will figure it out over time, I’m just excited to get this thread network running 100% on skyconnect in the meantime now until that breakthrough is made 👌

[hoary harbor]

Oh hey, I noticed that same thing about the built-in ip not showing the routes properly. I ended up using route -A inet6 to see them

oh weird. the routes to the thread network advertised by apple devices don't show via, but the route from OTBR does?

fd88:fad1:1e70::/64  metric 100
fd9a:793f:4de6:4fac::/64 dev enp0s18  metric 100
fddb:4a27:5079:1::/64 via fe80::ba27:ebff:fe0b:66e0 dev enp0s18  metric 100

you might have already mentioned that so sorry if i missed it

fd88 being apple and fddb being OTBR (running on its own Pi)

[vapid shell]

Is your OTBR on a different box to HA or is it local?

[hoary harbor]

Different box

[vapid shell]

HAOS or Debian/Ubuntu/etc

[hoary harbor]

HA is HAOS on proxmox. OTBR is on its own Pi

[vapid shell]

Yeah that’s pretty weird

[hoary harbor]

Waiting for an RA to come through from OTBR to compare

From HomePod Mini and latest ATV:

        hop limit 0, Flags [none], pref medium, router lifetime 0s, reachable time 0ms, retrans timer 0ms
          source link-address option (1), length 8 (1): a8:51:ab:91:7d:e7
            0x0000:  a851 ab91 7de7
          route info option (24), length 16 (2):  fd88:fad1:1e70::/64, pref=medium, lifetime=1800s
            0x0000:  4000 0000 0708 fd88 fad1 1e70 0000
 00:00:32.282527 IP6 (flowlabel 0x90300, hlim 255, next-header ICMPv6 (58) payload length: 40) fe80::1c55:f720:fd4c:d1d0 > ip6-allnodes: [icmp6 sum ok] ICMP6, router advertisement, length 40
        hop limit 0, Flags [none], pref medium, router lifetime 0s, reachable time 0ms, retrans timer 0ms
          source link-address option (1), length 8 (1): 94:ea:32:8c:6b:b6
            0x0000:  94ea 328c 6bb6
          route info option (24), length 16 (2):  fd88:fad1:1e70::/64, pref=medium, lifetime=1800s
            0x0000:  4000 0000 0708 fd88 fad1 1e70 0000

Apple devices really spam the RAs...

[vapid shell]

Oh

Missing via, I remember

[hoary harbor]

        hop limit 0, Flags [none], pref medium, router lifetime 0s, reachable time 0ms, retrans timer 0ms
          route info option (24), length 16 (2):  fddb:4a27:5079:1::/64, pref=medium, lifetime=1800s
            0x0000:  4000 0000 0708 fddb 4a27 5079 0001

OTBR RA

[vapid shell]

Multiple apple BRs?

[hoary harbor]

Yep, two

[vapid shell]

So they get coalesced into a single route by network manager but busybox ip can’t see them

If you are inside the ha container do apk —no-cache add iproute2

Then run ip -6 route without the grep cos the output is multi line

[hoary harbor]

Ah so it is just a formatting thing

[vapid shell]

Indeed

[hoary harbor]

Well I've got HAOS, OTBR's pi image, Windows, and a bunch of Debian if you want any tests ran

Sounds like your test setup has all that though

Very weird that you can't get multiple routes right through ip!

[vapid shell]

It’s because it’s not ip

It’s busybox ip

[hoary harbor]

Oh that's what you meant. I'm just reading through your notes from yesterday

[vapid shell]

And it’s also this weird next hop group (you can compare the Network Manager and kernel processing the RA into different routes in my post ^^, nm creates a single route with 2 nexthops. The kernel actually creates 2 separate routes)

[hoary harbor]

Yep, exactly what I'm seeing

I think you nailed it with the note about not being able to set separate expirys on each path in a RTA_MULTIPATH

[serene prawn]

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

[hoary harbor]

But your broader observation that NM is simply just not setting routes to expire is also correct

Installed NM on a scratch box and it's also not setting routes to expire there:

fd88:fad1:1e70::/64            fe80::1c55:f720:fd4c:d1d0  UG   100 2      0 eth0

Lowercase "e" = expires. On a box without NM:

root@ansible:~# route -A inet6 | grep fd88
fd88:fad1:1e70::/64            fe80::1c28:5a83:a0e1:b68f  UGAe 1024 3     0 eth0
fd88:fad1:1e70::/64            fe80::1c55:f720:fd4c:d1d0  UGAe 1024 1     0 eth0

iproute2 ip shows no expiry either

root@dev:/var/log# ip -6 route
::1 dev lo proto kernel metric 256 pref medium
CENSORED/64 dev eth0 proto kernel metric 256 expires 86126sec pref medium
fd88:fad1:1e70::/64 via fe80::1c28:5a83:a0e1:b68f dev eth0 proto ra metric 100 pref medium
fddb:4a27:5079:1::/64 via fe80::ba27:ebff:fe0b:66e0 dev eth0 proto ra metric 100 pref medium
fe80::/64 dev eth0 proto kernel metric 1024 pref medium
default via fe80::20e:c4ff:fed2:8995 dev eth0 proto ra metric 1024 expires 1526sec hoplimit 64 pref high

But it does for the RAs from my router?

All very weird. Sorry for the spam but you've definitely got your work cut out for you @vapid shell. God speed.

[floral flare]

Sounds like multi border router is going to be “fun” when eero gets updated for thread 1.3 and/or matter

[floral flare]

I have no thread devices to test with, but the latest eero update does have Thread 1.3

[clever bluff]

What’s the selling point of multi border router?

Seems like it brings more pain than benefit for the vast majority of installations.

[hoary harbor]

The only difference I can find between RAs that get expirations from NM and those that don't is the "router lifetime" on the ICMP6 message itself:

        hop limit 0, Flags [none], pref medium, router lifetime *****0s*****, reachable time 0ms, retrans timer 0ms
          route info option (24), length 16 (2):  fddb:4a27:5079:1::/64, pref=medium, lifetime=1800s

^ gets permanent routing table entry from NM

19:54:58.588079 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 112) fe80::20e:c4ff:fed2:8995 > ip6-allnodes: [icmp6 sum ok] ICMP6, router advertisement, length 112
        hop limit 64, Flags [managed, other stateful], pref high, *****router lifetime 1800s*****, reachable time 0ms, retrans timer 0ms
          prefix info option (3), length 32 (4): MY:IPv6:PREFIX::/64, Flags [onlink, auto], valid time 86400s, pref. time 14400s
          rdnss option (25), length 24 (3):  lifetime 600s, addr: MYDOMAIN
          dnssl option (31), length 24 (3):  lifetime 600s, domain(s): MYDOMAIN.
          mtu option (5), length 8 (1):  1500
          source link-address option (1), length 8 (1): 00:0e:c4:d2:89:95

and this gets one that expires

[hoary harbor]

Meh, probably unrelated, since The Router Lifetime field of an RA indicates whether or not the advertising router will act as a default router for the receiving IPv6 hosts, and if so, for how many seconds it will perform that role, unless it is refreshed by a subsequent RA from the router.

[royal light]

Is there a semi-official way to push a new dataset to my Pi4+SkyConnect to put OTBR and/or Matter on the same settings as my existing Eero thread network?

I'm currently trying to write a test with my Eero dataset from mDNS 😄

[serene prawn]

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

[floral flare]

If you can coax your eeros to update to the new version, it's showing tv=1.3.0 now

Also, at least in the iOS eero app I can see the thread network key, network name, pan ID, ext pan ID, and commissioning credential

[royal light]

yeah, I have them all. but am not sure how to feed that info to the right place in the current release. :/ I only just started getting into the guts of things (and day 3 with my SkyConnect), so I'm probably missing something simple.

And Eero announced their thread upgrade intent several months ago... so not sure why they're dragging on the Matter compatibility. Amazon gonna Amazon.

[vapid shell]

It’s not there yet (maybe in 1.3.1) but there is a thing called TREL which lets the border router use your Ethernet or WiFi as if it was a thread link. So if you have a crap thread mesh that keeps collapsing and partitioning, TREL will compensate using your WiFi/Ethernet instead. I.E your mesh will be stable even if your house is like a faraday cage for the thread signal.

[vapid shell]

Right now it does. But actually some of the things I’m debugging are only debuggable because of multi-br. Which is to say, single BR has them too.

If I don’t have multiple vantage points, I can’t tell the difference between a mesh failure and a problem on your home network. OTBR addon should be better here because it removes a lot of risk areas by running on localhost. And if there is a problem we should have logs to look at.

[hoary harbor]

If you have the name, key, channel, and other info, you just have to pack it into TLV format the Matter addon expects. I hacked together a quick script a while back to pack that data and I can find it if you'd like to give it a shot

[vapid shell]

keep in mind that an HAOS/OTBR only setup probably mitigates various Thread issues that are still in flight. Using Eero with HAOS you are likely opting into some of the behaviour we describe up ^ with other third party border routers - like if your ipv6 addresses change, HAOS may hold on to the old address and continue to try to route thread commands via it.

[rare ibex]

what about the use case of a remote building like a shed or garage that is out of range of wireless. having an ethernet connected border router there would extend thread network there right- at least theoretically?

[clever bluff]

Wouldn’t that just basically be a second mesh?

[vapid shell]

right now it would probably be a second mesh

or worse, if it was marginal it would partition and merge depending on the weather, causing havoc

there is something called TREL that its not a mandatory part of the spec that lets border routers use ethernet and wifi to make up for mesh deficiencies

but its not necessarily turned on in OTBR out of the box, and i'm pretty sure Apple don't given the behaviour we've seen with Apple TV's in cupboards. no idea for other vendors.

[devout iris]

Hi, just got my SkyConnect. I’m pretty happy with my Sonoff Zigbee radio at the moment, so not looking to migrate ZHA right away, but I would like to play with Thread. Is it possible to use the SkyConnect only for Thread and keep ZHA on Sonoff?

[devout iris]

By the way - I have about 30 Eve Energy Thread plugs and about 40 Nanoleaf A19 Thread bulbs with 6 HomePod Minis and 2 Thread-capable Apple TVs. So I can probably help test quite a bit. As you can imagine, my Thread network is a dumpster fire. Discovery app shows Thread is pretty much always in chaos.

I’m pretty sure the Apple Border Router process crashes on a fairly regular basis, forcing border router changes, and sometimes partitioning my thread network.

MDNS and IPV6 have never really played nice together - especially when addresses change. So I’m not surprised there are so many issues.

Oh - and last thing: I have an open channel to Apple HomeKit Engineering team via an Apple Executive Escalation (Group that handles issues with visibility to Apple C suite) - so if we have concrete stuff we think is borked with Apple Border Routers, I can get technical info to Apple HomeKit team and they will not ignore it.

[vapid shell]

Hey @devout iris, I can’t answer your original question with 100% certainty. I don’t see why that would be a problem, but as I haven’t tested that precise setup I can’t make many guarantees.

If you are using haos I think it automatically uses a stable identifier from udev so it doesn’t get the devices mixed up

If you are using the container (like me) you can pick that stable identifier yourself

[devout iris]

Yes, I have HAOS. It does use stable IDs for my ZWave and Sonoff sticks.

I was thinking of just firing up the SkyConnect on a 3rd USB port and see what shows up - but I didn’t see in any docs how to get Thread (beta?) running

[vapid shell]

The beta you probably one comes out later tonight

[molten palm]

Doesn't the Sonoff Zigbee CC2652 have Thread support?

https://openthread.io/vendors/texas-instruments#cc2652

According to this it does 🤷🏼‍♂️

[vapid shell]

With tonight’s beta if you plug in the SkyConnect it should automatically set up an OTBR for you. Then if you hard reset one of your homekit devices and pair it to Ha over Bluetooth it will have a “provision thread” button on its device page. Push it and 30s to 60s later it will be connected to your HAOS over thread.

[devout iris]

Mine is the EZSP - SONOFF Zigbee 3.0 USB Dongle Plus V2

[vapid shell]

I don’t know if other thread sticks trigger all the automatic stuff - I tested homekit_controller with a Yellow which I think is just the same chip as the skyconnect?

[devout iris]

Yes, same chip as Yellow.

[vapid shell]

But it’s all integrated with haos to trigger pulling in addons so if you don’t trigger that happy path it’s more manual

Tonight’s beta also has a new diagnostics tool because of the number of unstable HomePod/ATV setups I’ve being debugging lately 😅

[molten palm]

@devout iris mine.. CC1352/CC2652, Z-Stack 3.30+ (build 20210708)
by Texas Instruments

[devout iris]

Is there a way to join HA to existing thread mesh and then power off all the Apple stuff to force it to take over?

[vapid shell]

Not yet

A few obstacles before we can do that. I don’t think anyone has updated the iOS app yet, so we don’t know your iOS thread network keys

[devout iris]

Dang. Because Apple seems to have mastered how not to play nice in mesh networks.

[vapid shell]

Also different thread versions, apple is still on 1.2.

Don’t know if there are any differences that would stop them coexisting but yeah

[devout iris]

Yeah. And I’m on the new architecture - so I have multiple hap domains in MDNS.

I would happily move all my Nanoleafs over to HA on a different PAN.

They do not play well with HK.

[vapid shell]

So right now there’s a couple of chains of investigation with unstable third party BRs. One is a bug in HAOS. It looks like NetworkManager doesn’t expire stale routes. So if your border router changes ip, HA continues to use the old one.

That obviously isn’t a problem with SkyConnect because there’s no routes

[devout iris]

Well it’s IPV6 - so yeah. Those change when the wind blows.

[vapid shell]

We had one guy get 12 routes from 2 HomePods

2 in 12 chance of packets being delivered

[devout iris]

Haha. I have some Thread devices that have 5-digit sequence numbers in the name.

[vapid shell]

The other issues is border routers still being used when they are off mesh

Apple TVs are seemingly the worst offender

Usually we can stabilise the network by getting rid of them and restarting HAOS

[devout iris]

MDNS and IPV6 are not known to work particularly well together when addresses change.

Yeah, ATVs seem to experience BR crashes more than Homepods - which sucks because they are wired and should be more stable.

[vapid shell]

Of course thread has all the same problems with walls as zigbee… and wires - the most problematic ones seem to be in AV cupboards surrounded by HDMI etc

[devout iris]

I played with adding Nanoleafs to HA after decommissioning them from HK. Worked great for about 8 hours then they would never be found again.

Radio is fine here. I have 80+ zigbee and ZWave devices that work flawlessly.

And I have only one AP on each 2.4 wifi 1-6-11 channel.

Very little interference.

[vapid shell]

What will probably help most is if/when apple implement TREL

Right now the priority is to get NM to respect ipv6 RAs TTL, and for routes that have failed neighbours to get dropped. That should stop devices from permanently disappearing. But right now if an ATV is functional but off mesh there’s no nice way to hint that the route should be avoided.

[devout iris]

So it sounds like if I install tonight’s beta, and I recommission my Nanoleaf’s on HA, I will be on a whole new Thread network and should not have (those) issues.

[vapid shell]

With lots of emphasis on those!

[devout iris]

Yeah, I understand.

[vapid shell]

And you will be among the first people other than me to try it, so go into it expecting fun.

That said if you can get it on to the SkyConnect there are people on the forums with similar numbers of devices and apparently it’s more or less stable for them.

[devout iris]

As long as there’s someone paying attention, I’m happy to help test.

I have been capturing log files for Apple for months. Haha.

[vapid shell]

I am working on this stuff around $dayjob and $child, so I’ll be paying attention but there are no timelines for anything.

[devout iris]

You do network stuff for $dayjob?

[vapid shell]

Infosec

[devout iris]

Oh cool. Research or field?

[vapid shell]

Welllll

Something fun 😆

[devout iris]

So practical research. Haha.

If I wanted to try to fire up Thread on the Sonoff stick - where should I go to study up on how to set it up? (It has a really nice antenna and it's located in a really good spot.)

[clever bluff]

I was going to ask something similar. The Official stick doesn’t look like it has enough of an antenna.

[vapid shell]

I’d start searching for whether it has multi-pan firmware

It might be a one or the other situation

[clever bluff]

Apparently the “E” version shares a chip with the SkyConnect.

So it’s absolutely doable, it’s just a question if someone has done the legwork.

It uses the multi protocol EFR32MG21 chip. Same one that Innoveli is using iirc.

[vapid shell]

I’m not at a computer so I can’t do it for you but I’d probably look at the SkyConnect integration in the main HA code base - I think that’s what triggers the addons to be installed. Not that familiar with that end of the stack tho!

[devout iris]

Does the SkyConnect come with multi-PAN firmware already installed? I have to believe SkyConnect is using an image that would be available in Simplicity Studio - so should be able to flash it onto the Sonoff since it's the same chip.

Maybe I'll plug the SkyConnect into my PC first and see what Simplicty Studio thinks...

[upbeat cairn]

All of the firmware building is open source: https://github.com/NabuCasa/silabs-firmware-builder

That being said, you can just plug in the SkyConnect, manually install the multi-PAN addon, and enable firmware flashing. It will set up the SkyConnect with multi-PAN firmware and enable OTBR, and you can just ignore the Zigbee half.

[rare ibex]

they are not the same chip EFR32 chip, so you can not flash a Sky Connect FW onto a Sonoff-E and expect it to work.

[devout iris]

Fantastic. That's what I was hoping.

[clever bluff]

Huh? They're both EFR32MG21

[rare ibex]

no they are different parts.

there are many models of EFR32MG21 with different ram and storage

[clever bluff]

Ah, different packages.

Got it.

[rare ibex]

in Simplicity you have to chose the board/module/chip you are working with on the project

[devout iris]

So to restate the obvious - don't try to use the Silicon Labs Multiprotocol add-on to flash anything other than a SkyConnect.

[upbeat cairn]

It only auto-flashes the Yellow and the SkyConnect, and has explicit checks for both: https://github.com/home-assistant/addons/blob/3af0ad8a398dd6d969e98ca8a5c5e2ead754f365/silabs-multiprotocol/rootfs/etc/s6-overlay/scripts/universal-silabs-flasher-up#L28-L54

[rare ibex]

also the pins used are likely different as well.

[devout iris]

This example shows how to build the Yellow FW - and it looks like there are different patches for Yellow and SK - so how do you build the SkyConnect FW?

[rare ibex]

the built firmware files are here: https://github.com/NabuCasa/silabs-firmware

[upbeat cairn]

They're also included in the addon

[clever bluff]

Where's the source?

[upbeat cairn]

In https://github.com/NabuCasa/silabs-firmware-builder 😄

[rare ibex]

you can see all he config options used in the wiki too

[devout iris]

Oh - okay build builds everything. The second is to create a project. Got it.

[upbeat cairn]

The builder is only really useful for automating things, you can do everything from within Simplicity Studio if you want to just build your own firmware

[rare ibex]

you can see the options that are changed from the stock examples in the build.yaml

[clever bluff]

Huh, the chips between the ZBDongle-E and SkyConnect are very similar.

The only difference is flash size, as far as I can tell

Skyconnect: https://www.silabs.com/wireless/zigbee/efr32mg21-series-2-socs/device.efr32mg21a020f512im32?tab=specs
ZBDongle-E: https://www.silabs.com/wireless/zigbee/efr32mg21-series-2-socs/device.efr32mg21a020f768im32?tab=specs

Could be wired differently, obvs.

[devout iris]

So in theory, building for the Sonoff is a matter of pulling the configuration from the Sonoff stick, then adapting everything from the Skyconnect project over to a Sonoff project.

[rare ibex]

you also need to know the gpio pinout

on the fw build site those are in the patch files

[devout iris]

And the same for the Sonoff...

[rare ibex]

you maybe able to find them at repos that have fw builds for the sonoff. I haven't looked recently enough to remember. I have my own efr32's to worry about.

[devout iris]

Forgive me since I'm new here - this you? https://tubeszb.com/

[rare ibex]

Yes

[devout iris]

Zigbee2PoE - that's fantastic. That would be especially fantastic if it could do Thread too.

[rare ibex]

It should. Just need some time to fully test but also want things to mature a bit. Plus need some thread device 😂

[devout iris]

How many Nanoleaf A19s do you need? I have a bunch that are being dumb bulbs at the moment because Thread is such a mess. I went hard and bought about 40 of them on sale.

No I'm replacing a lot of them with Sengled endpoint Zigbee bulbs which have been flawless so far.

[rare ibex]

Well I have a pile of sengleds that won’t stay on my network 😂 but time is really the issue

[devout iris]

I really think the OpenThread folks lost the plot by not allowing the end user to provision bulbs as endpoint-only. Too much mesh is a bad thing.

That's funny. I have about 12 Ikea Tradfre outlets around my place and those Sengled Bulbs have absolutely not problem staying online.

Thread escaped the lab too soon. It's definitely not ready for mainstream consumers yet.

[rare ibex]

I have a 140+ device zigbee mesh and sengleds just don’t like it. I think they have a fw flaw but 🤷🏼‍♂️ they end up generating a lot of nwk conflicts and eventually give up on rejoining after wards

[devout iris]

With 70 Thread devices on my network, about 35% of my network traffic is MDNS chatter. Like. WTF?

Yeah, 140 is starting to push the limit. I have 35 ZWave switches, 45 Hue lights, 35 various Zigbee doodads, and about 70 Thread devices. Everything but the Thread stuff works well.

And once you take the Nanoleaf bulbs away, the Eve Thread switches work pretty well. I honestly think a lot of the problems with thread are really problems with MDNS trying to keep everything up-to-date.

MDNS TTLs can keep stale information floating around for hours.

So when somebody turns off a lamp that happens to be the Thread Leader - chaos.

Or when an Apple Thread BR crashes - chaos.

A mesh is great if it can heal in a single-sigit number of seconds. If it takes tens of minutes to an hour... 🤮

[glass granite]

Ok I did just get the beta up and running and minus a couple Bluetooth hiccups, this provision update for HomeKit Thread devices is beautifully easy

[devout iris]

I should listen to you on the Sengleds though. This is how I got in trouble with the Nanoleafs. 10 of them worked fantastic. Once I got to about 25 it started to get shaky. With 40 of them it's pandemonium.

[devout iris]

Is it pushed to the beta channel already?

[glass granite]

Yup! A couple hours ago

Been mashing the refresh button

[devout iris]

Are you running SkyConnect? Thread+Zigbee or just Thread?

[half bluff]

How do you commission homekit thread devices to the yellow thread border router?

[glass granite]

Skyconnect with the MultiPan firmware

[half bluff]

I turned off all my homekit hubs to try and force a commission to home assistant os but it seems that adding the matter device is just stuck on connecting to sensor

[glass granite]

There should be a button in HomeAssistant to provision it over Bluetooth if it’s already been added to HASS

If you click the device and dive into its details

[half bluff]

So you added with apple hub first and then commissioned it over with bluetooth?

[glass granite]

Nope! I added it directly to HASS via Bluetooth (booo) then with the Beta I clicked a button to switch its connection to Thread

[devout iris]

Once you add with Apple Hub, it's joined to that Thread network. If you want a Thread network created by HA, you have to provision it from BT.

[half bluff]

So how do I provision it with bluetooth?

[devout iris]

But then you are free from the tyranny of the Apple Border Router.

[devout iris]

It will just see it.

[half bluff]

I dont want the apple border router to control at all

I am wondering if this works for matter devices?

Let me try my eve room

[devout iris]

I don't think Matter has anything to do with it yet.

It's still a HomeKit bulb - it's just joined to HK Controller Integration as a HomeKit bulb via Thread.

You still need the HK pairing code.

[devout iris]

Matter is a replacement for HomeKit Protocol - Thread is a replacement for Zigbee/WiFi.

[half bluff]

Ok so I reset my stuff and it does not show up in my integrations page?

[devout iris]

If you have the new beta and a SkyConnect flashed with the multi-PAN firmware - you should be able to join a reset Thread Homekit device to HA. It will just show up in discovered devices and ask for the pairing code.

[half bluff]

I have the yellow

and yes it is not showing up

Looks like the nanoleaf bulb is working

I will update if I figure out a solution

[vapid shell]

@half bluff you need to hard reset the device you want to pair with HA so it forgets any existing thread credentials, then it should show up as a discovery in Ha. If not, double check it doesn’t show up if you manually add a homekit_controller integration. If it still doesn’t work, restart HA and/or the device. But in testing nanoleaf and eve, hard resetting the device should do it.

[twin saffron]

I installed the beta and I'm trying to add a Nanoleaf bulb as well. I've got it paired via BlueTooth but don't see a button to add it to Thread.

[half bluff]

I think I might be hard resetting the eve room wrong

[vapid shell]

Then when you have paired go to it’s device page and there is a provision device button

[half bluff]

I will double check

Getting nanoleafs loaded now

[vapid shell]

Press it once, and wait 30 to 60s

[glass granite]

https://www.icloud.com/photos/#0b31iIF0QvXKcb-pemhtMTwSg this should be the button you need to press

[twin saffron]

I think it may be because the Thread network is not setup properly. I do have the SkyConnect with the multi-pan firmware and I've got the silicon labs addon running.

[vapid shell]

And you should see the thread status flip to child or leader, or will probably go unavailable briefly

[glass granite]

Did you create a thread network first?

[vapid shell]

Cheers @glass granite

[twin saffron]

I think that's the part I'm missing. Not sure what I'm supposed to do for that.

[vapid shell]

The docs are half written on my desktop when I get to it in the morning 😅

I think the beta should make one for you now shouldn’t it?

[glass granite]

Ummmm. You do that through the Silicon Labs Multiprotocol add-on but I kinda just mashed keys to get one made 😅

[glass granite]

Oh that would be so nice if it did

[vapid shell]

They are trying to keep us out of the OTBR web interface as much as possible because it’s easy to screw up stuff

My dev env is running with the insecure default key 😂

[twin saffron]

So if I go to the Thread integration page it shows my 5 apple border routers and it shows one for the SkyConnect. It says at the top "You don't have a preferred network yet."

[glass granite]

BRB gonna go mess up Jc2k’s Thread network with hundreds of nanoleafs

[twin saffron]

Do I need to have a preferred network set here? If so, not sure how.

[vapid shell]

So the OTBR broadcasts lies when it’s not activated properly

So it probably looks like it’s a border router but it’s not active

[twin saffron]

Ah okay

[vapid shell]

Otherwise I think HA would have pulled it’s keys and made it the default

[twin saffron]

Okay understood, but not sure what to do at this point.

[vapid shell]

No

I am on my phone so I can’t fry and get my yellow into that state to help

[twin saffron]

okay sorry, no rush

[vapid shell]

You could (a) wait for that, but it’ll be tomorrow (b) try to get into the OTBR web interface

[twin saffron]

I do have the OTBR web interface available

[glass granite]

I really would not recommend the OTBR interface TBH, it’s very not end user friendly if you’re trying to spin up a network

(As an end user at least)

[vapid shell]

💯

[twin saffron]

Okay, I'll hold off on that then

[vapid shell]

I want to try removing the addon and re-adding it

But I don’t know if it will break anything

So will test on my dev env in the morning and let you know if it helped

[glass granite]

Does the Thread integration on the Devices page give any options if you go to “Configure”?

[twin saffron]

Sounds good

[half bluff]

@vapid shell So is there anyway to get thread devices from eve matter provisioned to the home assistant yellow border router?

[twin saffron]

Yes, if I click the "Provision Preferred Thread Credentials" button I get the error "Failed to call service/button press: No thread network credentials available"

[vapid shell]

no idea about matter, sorry

[devout iris]

Only the option to create a new thread border router.

[vapid shell]

whats the wording for that?

[devout iris]

Did your Nanoleaf's popup as "Nan (Lightbulb)HomeKit Controller" when you reset them?

[half bluff]

Yeah

I just rename it

[devout iris]

So I can see the add-on is advertising at core-silabs-multiprotocol.local:49152...

But when I go to configure the bulb, it errors out.

Boo.

Maybe I have to have the bulb closer to the BT antenna on the Pi.

[half bluff]

Make sure the ports 9999 and 8081 are open in addon config for open silicon

Maybe that might help?

[vapid shell]

yeah one of the notes in the docs i have here is that you need to be in BT range.

until you have paired and provisioned the thread creds

alas it landed before i could push them

[devout iris]

Also, I had to manually enter http://x.x.x.x:8081 as the Border Router REST URL. It liked that - so I assumed that was correct.

[vapid shell]

right

quick poke around in https://github.com/home-assistant/core/blob/dev/homeassistant/components/otbr/config_flow.py

the dataset is created when the otbr integration is added

but the otbr integration was added in 2023.2, so if you upgraded from 2023.2 is probably not going to create a dataset automatically

[devout iris]

Do I need to manually do something?

[vapid shell]

i'm trying to work that out

ideally we want to re-trigger whatever HAOS did back in 2023.2

if you delete it and re-add it manually, you have to configure it

[devout iris]

I mean everything appears to be advertising correctly. But the web interface is missing and I can't get this bulb to pair. BRB - gonna go try standing next to the Pi.

[vapid shell]

it sounds like you've already manually set up OTBR here so what i am looking at is not for you, more for @twin saffron

[twin saffron]

And just as a heads up, I tried deleting and re-ading the Silicon Labs add-on and it doesn't appear that triggered anything like you said happened in 2023.2

[vapid shell]

yeah, the thing we need to trigger is in the otbr integration not the otbr addon

im sure there is a meme gif with a dog and some science equipment i should be posting

[twin saffron]

lol

[devout iris]

For me it was the range. Moved closer to BT antenna and it paired right up.

Where can I check to prove it’s paired with the HA border router and not Apple?

[vapid shell]

well from a purely physics + maths point of view

we don't know the secret for the apple network

HA doesnt

ios was not involved in the process

and you did a hardware reset

so it shouldn't be possible

but... if you download the diagnostic report for thread it will tell you the prefix for the thread network

for all of the thread networks

[devout iris]

Gotcha.

[vapid shell]

you can compare that to the addresses in /config/.storage/core.config_entries. look at the AccessoryAddress or AccessoryIP field, i forget the name

[devout iris]

I didn’t realize we didn’t have the credentials for the HK network.

[vapid shell]

it should be possible for the companion app to sync them over, but AFAIK that bits not build yet

its sorta built for android, but still a few weeks off general release

[devout iris]

I guess what I stupidly failed to realize is that the thread network has a key - but as soon as a device joins it’s fair game on the local network via the border router.

So preserving the key and decommissioning from HK left us as a stowaway on the HK thread network. That’s how it worked before…

Well cool. If this bulb stays accessible for longer than 24 hours via HK controller - that will be a record.

So you’re saying the companion app should soon be able to do the BT part and commission them just like the Home App?

Oof. Seems like the Thread antenna in the SkyConnect is not much better than the BLE antenna in my Pi...

Or... Maybe it's just taking a while to actually switch from BT to Thread...

[vapid shell]

ok, for now you need to delete the otbr integration, then re-add it manually. it'll ask for a URL, if you use http://core-silabs-multiprotocol:8081 it should be the same as if it was set up automatically. then it should automatically make a thread network and set it as preferred, which should let homekit use it

talking about how to auto-fix existing installs now

[vapid shell]

no, companion app won't commission them. we'd need to be able to run a substantial amount of python code inside android and ios for that to work. more like, the HA server would be able to add HK devices to the HK border routers, without iOS

[vapid shell]

if it works you will see the status change on the device page. Disabled means its either not got a bluetooth connection yet, or it already gave up. Detached means it's trying to connect to thread but hasn't yet. Child/Leader means its connected to thread and working.

i am going to bed now good luck lol

[twin saffron]

Awesome, that did the trick! Glad it was something so simple. The bulb went from BT to Thread in less than 10 seconds.

[vapid shell]

Nice!

[hoary harbor]

One last little morsel for you jc2k: "from what I remember, NM tracks the lifetime of RA routes internally without setting the lifetime in kernel. You should see that the route goes away if the lifetime expires"

This multi-BR thing is infuriating me so I'm trying to figure out what the heck is going on

[vapid shell]

Hmm

So iirc the lifetimes are about half an hour

And we waited for hours

[hoary harbor]

Yep, 1800 seconds from my Apple devices

I can't even find an nmcli invocation that shows route expirations yet

[vapid shell]

And what happens if NM crashes

[hoary harbor]

It's gotta save its state somewhere I assume? I'm learning a lot about NM very quickly lol

[vapid shell]

If you find out it does save that state I’d love to know

[hoary harbor]

Definitely looks like NM tracks/manages expiry internally: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/main/src/core/ndisc/nm-ndisc.c#L1487

All that ends up in rdata of NMNDiscPrivate, which as far as I can tell is in-memory only: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/main/src/core/ndisc/nm-ndisc.c#L42

Haven't dug into whether there's any kind of recovery or state sync after an NM crash that would clean up those otherwise "infinite" routes that get made in the kernel

[royal light]

Alas, I did a hard reset of my Nanoleaf Elements bulb, failed to pair once in HK, now this:
An unhandled error occurred while attempting to pair with this device. This may be a temporary failure or your device may not be supported currently: Nan: Service 00000055-0000-1000-8000-0026BB765291 not found, available services: ['0000003e-0000-1000-8000-0026bb765291']

[vapid shell]

That’s a bluez problem. Its trying to probe the device but it’s not completing it and is giving up. Not much can be done. Sometimes retrying can help. Sometimes a better bluetooth dongle can help. Sometimes ensuring a better signal can help. Sometimes its a sign your HA instance doesn’t have enough muscle or is overloaded.

[devout iris]

I got this error too. Since your BT adapter is presumably attached to your HA box, it probably does not have the signal strength to talk to your bulb. I brought a small lamp with the reset bulb next to the Pi running HAOS and it paired right up. The SkyConnect adapter will take over once the bulb has provisioned on Thread - and it has a lot more range. We are used to our mobile devices provisioning these bulbs, so proximity to the BT source isn’t much of an issue. Until the HA companion app can use the phone’s BT to provision these, you’ll have to bring the bulb to the HA box. Not ideal - but it’s the limitation of the current state of the platform.

[vapid shell]

It's unlikely that the companion app will ever be used for HomeKit over Thread credential provisioning fwiw. The homekit_controller integration cannot run code on your phone, and a large chunk of it would be needed to do what is happening with homekit_controller right now. So what would really be needed is for the companion apps to support acting as a BTProxy in the same way we use ESP32's to get full house BT coverage.

I suspect that will be a bit too niche to happen

right now if you are having range issues, an ESP32 on your wifi configured as a BTProxy and connected to a battery pack so you can take it room to room might do the job. I haven't specifically tested that, but homekit_controller's BLE support has been tested extensively with them.

[sand sparrow]

So I installed 2023.3.0b0 to test thread, but can't find anywhere any documentation about how to set this up.
I see that OTBR is still a dev add-on and if I configure OTBR with my Nordic usb stick it looks that everything is working. I can see also in integrations > thread the OTBR but I can't connect to it. it just give a error Failed to connect but I can't find anywhere why.

[vapid shell]

If you have a SkyConnect or HA Yellow and HAOs it would auto pull the silicon labs multipan addon, add the thread and otbr integrations, automatically create a dataset (ie a network) for you. I don’t know if there is a “happy path” for other thread sticks and OTBR yet.

I think you need a HA companion update to be able to use that network with android, I’m not sure if that’s in the android beta channel yet

And I’m not aware of anyone doing the work on the iOS side

You can add homekit devices to it directly through HA though.

[hoary harbor]

I'm throwing in the hat, Jc2k. An RA crafted w/ scapy that matches how Apple devices send them is being received by HAOS and properly expired after its expiry time

[sand sparrow]

following the OTBR website they do support the Nordic stick and I also can connect to my OTBR via android Thread app. Just not via HA

[hoary harbor]

Ope dropped in mid-convo

[vapid shell]

The other OTBR add-on isn’t yet integrated with all that

[sand sparrow]

But I just order a SkyConnect should be In tomorrow

[vapid shell]

So you have to set everything up manually

Using the OTBR docs

[sand sparrow]

Yes I did that also tried to install OTBR on RPi

with the stick but add OTBR via the UI just doesnt work somehow

[vapid shell]

Did you see my latest post on the GH ticket, feel like I’m edging closer

[vapid shell]

Yeah the UI isn’t the best unfortunately

Hopefully the other OTBR add on will get the discovery magic before long, and someone will add support for your usb stick. Just more combinations of devices than time right now.

[vapid shell]

I think when a route gets upgraded to a multi nexthop route NM loses sight of it

Keeps trying to add it, and is confused that it already exists

[hoary harbor]

That'd certainly explain it

[vapid shell]

So if your scapy script is only generating a single via, it won’t get upgraded to a multi nexthop route (not the right terminology at all) so Nm can probably see it

So it will expire

I think

[hoary harbor]

RTM_MULTIPATH

Is term

[vapid shell]

It’s so confusing because there are now nexthop objects as a first class object

And it’s not one of those

“Ip nexthop”

Which seems to be a replacement for.. RTM_MULTIPATH?

[hoary harbor]

I'm trying to remember why now but I really thought the multiple vias the full ip tool shows was those multipaths

Either way I do have two dev machines in addition to HAOS box so I'ma see what shows up when I do scapy from both

Which, for posterity is:
(WRONG)

scapy is super neat

[vapid shell]

Yeah I use it a lot for parsing random shit

That could be really useful for getting upstream to understand the sitch without them having to get a working thread network

Set your debug level with nmcli if you haven’t already

I cranked it to debug for everything

[hoary harbor]

Whups my scapy thing was advertising a prefix not a specific route

And I managed to crash ndptool with a buffer overflow. I think that means it's time for a coffee break

[hoary harbor]

This is a replicable bug with NM. You deserve the credit of creating a new issue: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/new

This is the working scapy invocation:

send(IPv6(src=xIP, dst='FF02::1')/ICMPv6ND_RA(routerlifetime=0,reachabletime=0)/ICMPv6NDOptSrcLLAddr(lladdr=get_if_hwaddr(xDEV))/ICMPv6NDOptRouteInfo(plen=64, rtlifetime=10, prefix='dead::'))

Send that from one dev box (other than HAOS VM) at a time and let the route expire and it drops off HAOS as expected

Send it on the second box while the first route is still in HAOS and it does not create the multiple "nexthop via" entries. It seems to delete the first route and add the second

But then if you send that on the first box again, it then creates the "nexthop via" entires

No matter what though, after the second RA is sent prior to the first one expiring, the routes get stuck

[vapid shell]

Nice

Do you want to file? I’m in the garden with a rabbit and my phone. I can +1 it when I’m back at my desk

@hoary harbor I am Johncarr on that gitlab if you want to @ me

[hoary harbor]

Pet rabbit or food rabbit?

But yeah lol I can file it

[vapid shell]

Lol pet rabbit don’t let him hear you say things like that

[hoary harbor]

Patiently awaiting my signup email

[vapid shell]

ah

[half bluff]

@vapid shell I am still running into trouble with that pesky wemo stage controller. It said connected to thread but setting up an automation with the buttons results to no response

Idk what we can do to make it better?

[vapid shell]

Mine is iffy too so it’s one of my priorities

[hoary harbor]

Uh oh, the issue doesn't replicate with NM on Debian Bookworm

[vapid shell]

!

[hoary harbor]

I'm still typing it up since they could at least help point to what in the OS might cause that

[devout iris]

Any recommendation on a packaged solution for BTProxy on ESP32?

[hoary harbor]

Still waiting for them to approve my account. I can just DM you everything I have typed up if you'd like to paste it into your own issue report?

[devout iris]

Is there actually a Web UI for OpenThread add-on? I just get 503 Bad Gateway.

NVM - Figured it out.

[vapid shell]

Lots of reports that the web Ui is broken or just in a very unfinished or polished state - if you feel HA needs you to use that Ui to do something it’s probably something that Ha needs to implement itself

[vapid shell]

Lol. Sure, please do. Might be tomorrow before I’m at a desk again tho.

[vapid shell]

Ccan you try the backport kernel on the bookworm vm

[devout iris]

The Topology map is probably the most useful thing.

Zigbee and ZWave JS UI have maps. So, ya know...

I guess there may be cases where it's useful to join to an existing Thread network as well.

At least once Apple figures out how to make their implementation work.

[vapid shell]

I have a bunch of these - https://shop.pimoroni.com/products/atomu-esp32-development-kit-with-usb-a although most of my homekit estate is on thread or an eve extend, the rest is very near usb bluetooth. So I don’t offer recommendations.

[devout iris]

I'll just live on the edge - ordered the $10 ESP32 board from Amazon.

Of course I guess there's no way to join an Apple Thread network without a Matter or HomeKit code...

[vapid shell]

In theory we just need to update the Ha app to use the thread api to upload and download thread creds

https://developer.apple.com/documentation/threadnetwork/thclient

[devout iris]

Yeah, you just need permission to access Home data and those APIs are just right there.

[vapid shell]

I haven’t seen anyone working on the iOS app to add that yet though

But the new thread integration has an API for receiving them from companion apps

[devout iris]

Hmm. Maybe I'll take a look. Unless it's written in Objective C.

[vapid shell]

If someone gets that to work I’d be happy to put an OTBR on an apple mesh for lols

[devout iris]

Oh hey - it's actually written in Swift... Maybe I'll take a look.

[devout iris]

I mean that could be reaaaaly cool for troubleshooting. Today the only thing we have is the Eve Energy app - and it's pretty limited.

[vapid shell]

I’ve been meaning to slap something together with scapy to ping devices, but with me in control of which BR it’s using so i can at least see if you have a mesh partition

But just the stuff we added to the thread diagnostics download this month covers like 1/3 of my triaging needs

… does traceroute work over thread? Not sure if ttl gets decremented on thread hops

[devout iris]

Oh - question: When we discover a factory-reset Thread HK device via HK Controller, it seems the Device Name is truncated - at least for Nanoleaf A19 bulbs. Have you seen that behavior?

[vapid shell]

Yes. It’s random and depends on you’re env. With a Ha yellow and A CSR ble chip and the device with in 2 metres I see it once in 10 pairings or so. It’s harmless and easy to rename so way down my list.

There’s 2 name fields in BlE and we are just picking up the crap one by fluke IIRC

[devout iris]

Huh. I see it every single time.

[vapid shell]

Which is why I think there’s an environmental element

You are losing a race because something is slower or has less signal

With my precious ble adaptor For Eve I ended up with 8 discoveries that were all just “Eve” 😄

[devout iris]

traceroute6 to nanoleaf-a19-14qx.local (fd36:b67c:xxxx:3d6) from fda6:838f:xxxx:588f, 64 hops max, 12 byte packets
 1  fda6:838f:xxxx:9719  196.734 ms  1.975 ms  1.644 ms
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * *

Not looking good...

[hoary harbor]

I'm already on the testing distro though

[devout iris]

I haven't tried an Eve device yet. They seem to work well with HK directly - so they are lower on my list. The Nanoleaf bulbs are a hot mess - so I want them on their own network to see whether it's them, or something with Apple. Interestingly Apple engineering told me they are working with Nanoleaf on fixing Thread problems with their stuff.

[hoary harbor]

@vapid shell: I'm in! https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1232

Can't @ non project members

[devout iris]

They politely asked me to remove all the Nanoleaf bulbs from my home before running their tests and capturing logs.

Based on my experience with them, I expect Nanoleaf to end support and updates for the current Essentials. If their FW is the issue, I'm not holding my breath for a fix.

Another thing I see a lot of - in _hap._udp. some of my node names have huge sequence numbers after them - like 4 or 5 digits.

Lots have none - and quite a few have sequence numbers of 1 or 2.

[vapid shell]

i saw that when testing with a single device (takes a little while for them to expire out of mDNS, so there be no sequence, 1, 2, 3 and then its like it got bored of adding on 1, and starts doing random names.

not that it matters

[devout iris]

I know at least with AVAHI this is a common problem for IPV6 hosts when they get a new address. They end up seeing a conflict for the name on the old address while trying to register it on the new one - so they pick a new name.

[vapid shell]

we use the id field in the TXT record to find HK devices, so doesn't really matter for us

[devout iris]

It probably does matter to the extent that the node is registered twice until the old name expires.

In other words you'll have 2 records with that TXT id for a period of time - one is stale, and the other is right.

That actually would explain a lot - like why rebooting all of the HomePods would fix Thread devices unreachable - they will lose their cached dns-sd data and get new fresh records.

And yeah, I think the numbering going to larger pseudorandom number is to avoid massive collisions if a whole bunch of hosts register at once with the same default name. Waiting for them all to try and work out unique sequence numbers could take a loooong time.

Which is why it's kind of nice that HK devices have a unique device name out of the box. But they just can't seem to stop conflicting with themselves.

[hoary harbor]

Well that'll give 'em some things to chew on jc2k

Congrats on finding a major bug in a core redhat project

[vapid shell]

Let’s hope they don’t come back and say redundant uplinks are not a feature of NM, wontfix

Or that it’s not like that gstreamer bug I filed that got fixed after 10 years

[hoary harbor]

lol, those ones are always fun

If nothing else I think the inconsistency across platforms will irk them enough to fix that part at least

[vapid shell]

Yeah I’d rather them keep replacing the active route than the current behaviour

[vapid shell]

well, HAOS is on NM 1.34 but 1.42.2 is already out. i know HA will be getting a new one soon, but this complicates things dealing with upstream

released jan 2022 lol

the error message i reported doesn't even exist any more

can you easily repro it with something fresher?

[hoary harbor]

My HAOS was reporting 1.40.10? From nmcli in the terminal addon at least. I guess I didn’t confirm base OS version

[vapid shell]

oh weird

nmcli --version, was that a lie

[hoary harbor]

It replacing routes but at least not losing track in Debian was 1.42

[vapid shell]

# NetworkManager --version
1.34.0

thats on HAOS 9.5 i think double checks

[hoary harbor]

I’ll double check shortly

[vapid shell]

ta

[hoary harbor]

da

Ok base OS says 1.34

1.40.10 in terminal addon indeed

[vapid shell]

silly terminal addon

does nmcli work in the terminal addon?

[hoary harbor]

Worked to change log level at least. That and version check were all I did

Guess I’ll go learn buildroot to upgrade NM in haos

[vapid shell]

\o/

[vapid shell]

i said in ticket, but i'll repeat here - the people i'm helping with lots of homepods and appletvs wont like the new behaviour. 8 homepods and you are going to see the route table flap 2 or 3 times a minute

and if you have some appletvs with a weak mesh connection i guess you'll have downtime for a few seconds every few minutes 😆

[hoary harbor]

You’re sure the weird HAOS behavior is just from old version?

[vapid shell]

you are right

i dont have any proof