#thread-archived

1 messages · Page 4 of 1

vapid shell
digital salmon
#

At the moment I only have one Apple TV 4K 2022 Border Router.

#

And my Home Assistant BR.

vapid shell
#

great! don't get any more and HAOS10 will be great for you

digital salmon
#

My HA BR is only for testing purposes at the moment.

#

Thanks for the explanation. 👍

devout iris
#

Well this makes me glad I fired all of my Apple BRs.

#

Right now I'm fighting with my Nanoleaf bulbs to try to keep them from becoming routers. In my experience they are spectacularly bad at being routers.

#

So I created an automation that turns bulbs red when they become a router and have been chasing them around and rebooting them. I'm down to one stubborn bulb that just really can't let go of the dream of being a router.

mental dock
#

I don't have any other Thread network except from the HA one and my BR is the HA Yellow. But apparently I need an Apple Homepod or Apple TV as BR in order to upgrade the Eve Motion's firmware

vapid shell
#

Just use homekit_controller? You pair the eve motion to your ha yellow with Bluetooth, then there is a button to migrate it to thread. It will use your Ha thread network, but just speak a different protocol over it.

#

You’ll need a Bluetooth dongle for the yellow while you are setting it up, but after that it’s all thread.

devout iris
vapid shell
#

No

devout iris
#

What's the missing link?

vapid shell
#

So the devices I’ve looked at that do firmware updates expose extra characteristics and services

#

We’d need to proxy those

#

We’d need to bypass the HA architecture and proxy stuff directly

#

Which wouldn’t be accepted in core

devout iris
#

Here's a fun script to trigger "ID" on all of your thread routers.

serene prawnBOT
#

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

📎 message.txt
devout iris
vapid shell
#

one problem is if you block async_setup_entry then HA won't start up properly

#

it'll be "waiting for loading to finish" until everthing is online

#

so you could try and take the semaphore, but if you can't raise ConfigEntryNotReady

#

then HA will retry in a bit, and you won't block start up

devout iris
#

Okay, so any throttling we need to manage ourselves without blocking async_setup_entry().

#

Oh - so it's HA that manages the retry...

vapid shell
#

at startup it is

#

i forget the reason

devout iris
#

Meaning we could just simply fail if one's in-progress.

#

And HA will handle the retry.

devout iris
#

So maybe just an asyncio.Lock() with a test to raise ConfigEntryNotReady if we're locked.

near python
#

I just had a heck of a time trying to get my zigbee network back up after the Yellow's onboard radio stopped being able to communicate with any of my Zigbee devices. I've gone back to using a separate radio (via ethernet) for Zigbee, but is there a way to use the OpenThread-only firmware on the built-in radio? The OTBR integration wants a socket path, not a tty path.
https://github.com/NabuCasa/silabs-firmware/issues/6

glacial imp
near python
#

I'm using an SLZB-06 Zigbee coordinator via ethernet.

#

So I was hoping to make the onboard radio NOT try to do zigbee, to avoid having it interfere.

#

Fixing my zigbee network required temporarily moving the Zigbee coordinator to a different room, on a POE switch instead of USB power.

#

And the error messages mentioned interference.

glacial imp
#

Oh, I overread that it's all zigbee - you aware that you posted in #thread-archived?

near python
#

I'm asking for help with the Thread radio.

#

I want to make the onboard radio do Thread, and only Thread, not Thread + Zigbee.

sick swan
glacial imp
#

ok maybe I should finish my ☕ first 😄

near python
#

Considering it's past 💤 time for me, I can just wait. I don't actually have any Thread devices anyway.

fickle mantle
#

Hi, For the Multiprotocol Add-On, I have a question about settting the Thread channel number. I currently have zigbee2mqtt using the Multiprotocol Add-On and have set the channel number for it, but would like to set the Tread Channel number to the same. I have played around with the ot-ctl inside the container. I looked at the earlier discussion above (from a few days ago) using channel manager, but I don't think it has been enabled inside the Add-On. I currently don't have any thread devices, so I suppose I could go ahead and set the channel directly using > channel X, but wanted to ask first.

vapid shell
#

The plan long term is that HA will create the thread and zha configurations together and make sure they are on the same channel. In the last stable release the APIs to allow this didn’t exist, so HA hard codes the channel for both.

#

To set the channel right now you’ll have to do it on the OTBR side

#

But that will change your “thread dataset” - if HA has already imported the config from the OTBR then you change the channel and you try to add any devices to thread via HA it will be using the wrong channel

#

The tools to fix this via the Ui don’t exist yet

#

(They are being worked on but not sure of status)

#

Not sure how z2m will slot into this long term, it will be less integrated for sure.

fickle mantle
#

OK, thanks for the response. I was sorta hoping that after making the channel change within the Add-On that the HA Thread/OTBR integrations would re-import the dataset after core restart.

bronze fog
#

I have 2x Apple TV 4Ks with Thread, and a thread Eve smart plug. Would the Sky Connect dongle allow HA to join that thread network, or are there still interop issues?

vapid shell
#

There are still ways to use them with Home Assistant but not with a SkyConnect

#

Eg with homekit_controller you pair the Eve smart plug with iOS first, then unpair it. That leaves it connected to your apple gear, and visible on your ipv6 network. So HA can see it, and pair it a second time.

half bluff
#

My Wemo has now died...

#

I hate this little bugger

vapid shell
#

Yes, I have 2 of the Wemo remotes and I hate them. One didn’t even have the right pairing code.

half bluff
#

The battery drain is unreal

karmic summit
#

I have the SkyConnect dongle and I can not add Eve smart plug to my thread network :/ Is there already a solution to this?

vapid shell
#

it depends on what you are doing! theres so many variables!

#

for a start, are you trying to use HomeKit Controller or Matter?

#

(and in case i am not here when you answer, are you using iOS or Android)

#

@karmic summit ^

karmic summit
vapid shell
#

Correct

#

Right now AIUI Apple have not granted the entitlement needed for us to sync thread credentials between HA and iOS, and the iOS HA app has not been updated to use the thread API's.

#

If you have access to an Android device you can use the Beta app there to get a Matter Eve device using your Sky Connect.

karmic summit
#

Okay, so I need to try this with an Andriod device?

vapid shell
#

Or, if you use Apple's border routers (and not the sky connect) it should work

#

Alternatively, don't use the Matter firmware yet 🙂 homekit_controller can use Eve devices over Thread. You just need a bluetooth dongle in your HA instance to push the thread credentials to it. (You don't need an iOS or Android app in this case)

karmic summit
#

I just bought the new EVE Matter version yesterday for fun 🙂

vapid shell
#

It's not very fun right now (to clarify, people in the Eve Matter beta are surprised they are selling stuff with this firmware version given its state)

#

You can use #matter-archived for Matter specific help, i'm personally not familar with the pairing flows, especially the Android ones.

karmic summit
#

I will try the HomeAssistant Android beta app. Thanks for your help 🙂

karmic summit
wintry aurora
#

Greetings everyone! Currently, I am utilizing a Raspberry Pi 3B+ as a Thread border router while simultaneously running a Home Assistant container in Docker. My aim is to retrieve data from an nrf52840-DK device. Could anyone provide assistance, please?

flint zodiac
#

This Apple bullshit annoys me a great deal.

digital salmon
flint zodiac
#

This API permissions thing that prevents getting Thread credentials to join the networks.

digital salmon
#

I don't understand why Apple is still using Thread version 1.2.0, even though Thread version 1.3.0 was announced as the basis of Matter.

vapid shell
#

The wording is a bit fluffy in places but pretty sure apple is doing quite a bit of that, so maybe it’s a certification thing?

#

Clearly matter devices do work on their happy path

#

I’m more disappointed there isn’t a 1.3.1 or 1.4 that mandates TREL yet

turbid helm
#

is there much of a difference in power usage between thread and zigbee ?

vapid shell
#

Its probably too early to tell

#

Right now you’d be comparing apples and oranges (zigbee is a vastly more mature ecosystem right now)

turbid helm
#

I see

#

so there's the expectation that current threadf hardware is not very power efficient

vapid shell
#

I was more saying that the firmware across all the many different moving parts is still a work in progress

#

So whatever we see now is likely a worst case that will get better

vapid shell
#

In terms of hardware efficiency of course remember that the same radio hardware can be used for both so it should be comparable

kind oracle
#

Hello, How can I access to the open thread configuration page?

#

In the official open thread addon

near python
#

Is a Bluetooth adapter important to have for Thread to work, or is it only for the iOS limitations? I use Android, mostly, and the only devices I have that have mention of Thread are Philips Hue and Amazon Echo.

vapid shell
#

If you have homekit devices that support thread but not matter (nanoleaf, pre-matter eve, airversa, wemo, etc) then HA can use a Bluetooth adapter to provision them directly onto thread without an iOS device (ie android users)

kind oracle
#

How can I join home assistant to another thread network?

#

On the thread integration appears both networks, google nest and home assistant but I cant find a commission or join button

#

I was a bit easier with open thread webui

#

but also I cant find the way to access the openthread webui

vapid shell
vapid shell
# kind oracle On the thread integration appears both networks, google nest and home assistant ...

I don’t know if the ui exists for this yet. If you had added a matter device before setting up OTBR then HA would have pulled the nest credentials and made it the preferred network. Then setting up the OTBR in ha would have autojoined it to the best network. Because you already have a thread network, instead Android would have told google about your otbr when adding a matter device. There was a Ui built to reset this so you can try again but the PR was rejected from a UX point of view. I don’t know if the replacement landed yet.

#

Before the final release of HAOS 10 using external BRs (like nest) will probably be unstable.

lyric oak
# kind oracle but also I cant find the way to access the openthread webui

You can enable web gui in OTBR addon configuration - on bottom of page is "Show disabled ports" and input port number to "OpenThread Web port". I don't know what works - I'm using it to check status.
As I understand connecting both networks isn't straight forward and very depends on google parts (Home app/ Thread SDK). I have similar situation - OTBR on HA and Nest Hub 2. I got it working as one network by:

  • switching off Nest Hub
  • clearing google play services and reinstalling Home app on android
  • deleting OTBR on HA, deleting Thread integration, deleting thread.datasets file, re-enabling them again - with restarting HA between steps. After that I confirmed that in Thread integration network created by OTBR (“home-assistant”) is as “My network”
    Then with Nest Hub 2 still switch off I added matter device to HA using android HA. As I understand that process on cleaned google services phone forced HA to pass OTBR credentials to google services as preferred thread network. My matter device was working for some time so I decided to switch on Nest Hub 2. It connects to OTBR network without any interaction from my side (it takes some time - not immediately after power on). Now they works as one network but I as thread network for matter devices for me it is unusable. Matter device connected on beginning stopped working so I factory reset it and from that time I can’t connect it again. I can’t connect any other from my matter devices. (I’m trying 1 or 2 times a day).
#

I also observed very strange (for me) behaviour of HA about Thread integration. Nest Hub 2 on power on had it’s own thread credentials (“NEST-PAN-E657” network). That credentials were added to thread.datasets file on HA. What I observed in Thread integration (confirmed in OTBR web gui) - the OTBR and Nest are always on the same thread network, but it is not always “home-assistant” network. As you can see sometimes they are as “My network” sometimes not.
https://imgur.com/a/KCWkEfT
https://imgur.com/a/hgPwCps
It is changing without my interaction or without restarting HA.
When I’m using android phone to connect matter device it always send “home-assistant” network credentials to device even if both OTBR and Nest are currently in (“NEST-PAN-E657” network).
My summery for current situation is that OTBR is in beta, thread on Nest in beta, thread on android is beta, matter is beta – all hat as system is for me pre alfa and I accept that. For me personally 2023.2 version was more stable for matter devices than 2023.3, but maybe we have to make one step back to make few steps forward.
For me most stable situation was when I was using OTBR with android phone which didn’t know anything about Nest Hub, as soon as they get to know each other problems starts.

vapid shell
#

External BRs (ie not SkyConnect) will be problematic with any released HAOS

lyric oak
vapid shell
#

Yes. Right now any BR that is not running on localhost of your HA will have reliability issues

#

Even another OTBR

#

You are right about the vision. But we are not there yet.

sick swan
#

10.0.rc3 brings us closer, hopefully 😄

vapid shell
#

Was just about to say

#

@sick swan is having to patch the kernel to make this stuff work.

#

The problem with interoperability of course is the test matrix doesn’t match the marketing

#

Is there someone out there with a HomePod, nest hub and a SkyConnect all on the same thread network?

#

(Probably not, as there is no way currently for me to get the network key for my HomePods network)

vapid shell
# lyric oak What you mean by external BR? Device separated from HA as Nest Hub, or OTBR in H...

To deep dive a bit more, it seems that Linux userspace had a hard time with RFC 4191 (2005). In your environment NetworkManager supports multiple border routers entirely by accident - it tries to remove them but fails. This includes stale routes. Every time your BRs fe80 address changes you’ll get a stake route and your network becomes less stable. Newer NetworkManager “fixes” this by only supporting a single border router. HAOS now has to carry a patch to fix this, which will be in HAOS 10.

#

There is also some disagreements about what is a host and what is a router, so actually neighbour unreachability detection is broken. This means it can take 30 minutes for a stale route to expire (if your stack even manages to expire routes).

#

(Biiig hat tip to @sick swan for coming up with sensible patches for both of these)

#

Right now it looks like NetworkManager, systemd, and the kernel all handle this stuff different of course so it’s a Wild West if you aren’t running HAOS 10

#

Right now your best shot of making this work without HAOS 10 is with a kernel with particular compile flags, sysctl settings, no systemd-networks and no NetworkManager.

#

Funnily enough none of this worked with my Mac dev environment at first. Even their kernel didn’t support the route advertisement mechanism out of the box.

#

Had to use open core legacy patcher to get a kernel that worked

lyric oak
low lotus
#

Hi all, I don't have any thread devices yet but I'm waiting for delivery of some Eve sensors. I want to make sure everything is ok to use them... I just got an update for the multiprotocol add-on that mentioned I needed to manually change the baud rate, so after updating the add-on that is what I did... How do I confirm the firmware on the radio in my yellow got updated to the new one and firmware baud rate and config march?

quiet stirrup
upbeat cairn
hoary harbor
#

So uh.


22:29:55] INFO: Checking /dev/ttyUSB1 identifying SkyConnect v1.0 from Nabu Casa.
[22:29:55] INFO: Starting universal-silabs-flasher with /dev/ttyUSB1
Usage: universal-silabs-flasher flash [OPTIONS]
Try 'universal-silabs-flasher flash --help' for help.
Error: No such option: --ensure-exact-version
#

Is too late to heck with so ima just restore backup. But that’s fresh upgrade to addon 1.1.0

#

Add-on version: 1.1.0
You are running the latest version of this add-on.
System: Home Assistant OS 9.5 (amd64 / qemux86-64)
Home Assistant Core: 2023.3.6
Home Assistant Supervisor: 2023.03.3

echo mirage
#

im getting the same error as above, wont start

#

got it to start by unchecking "automatically flash firmware" and putting baud back at 115200, but my zigbee devices wont respond

upbeat cairn
#

It's a bug with the amd64 addon and the fix should be released some time today. Can you try changing the baudrate back to 460800?

echo mirage
#

If i change it back it "cant connect to secondary" and continues to retry

#

zigbee devices are back online now

plain tide
#

If you want to change the baud rate to 460800, you will have to flash the corresponding fw manually first as the 1.1.0 add-on auto fw update doesn’t work at the moment. I am now on 1.1.0 with auto fw update disabled and manually flash the fw, everything works

half bluff
echo mirage
#

1.1.1 solves it (can reanable automatic fw and put baud back at 460800)

#

Thank you!

small heart
#

Hi, is there anyway to activate the OpenThread WebGUI ?

vapid shell
#

Yes but it’s hidden because parts of it are so broken they make it crash and also it’s very easy to a screw things up or make your home insecure. Right now there’s not any easy way to recover if HA and OTBR end up out of sync.

#

If you absolutely must use it, all you need to do is enable its port in the add on settings. You might need to click a toggle to show disabled ports.

low lotus
low lotus
fickle mantle
#

In the HA Thread Integration, you click on CONFIGURE, select a network and the (i) info circle and you'll see some of the dataset information. One parameter is "Dataset id". I can't find anything about an identifier for a dataset. Does anyone know what "Dataset id" is based on?

flint zodiac
#

Is there any reason why the Multiprotocol add-on seemingly always reverts to v1.0.2?

#

I always update it, but the next time I pay attention to it, it says 1.0.2 again. --edit: Well, the update dialog anyway.

vapid shell
vapid shell
twin saffron
#

I’ve had a different issue with my nano leafs bulbs in HA OS 10.0 rc3. Now instead of bulbs becoming unavailable periodically and then becoming available again a short time later, now it goes unavailable and stays unavailable until I reboot HA. Good news is that I don’t have to reboot the host to restore things, just the simple HA restart. Not sure if homekit controller maybe needs some sort of update to work better with how HA OS 10 handles things?

#

I enabled debug logging in homekit controller and would be happy to send logs if that would help. Just need to know where to go to get those debug logs and where to send them.

wary mountain
#

I'm on 9.5 stable, maybe I need to be on an release candidate.

#

Gotta figure out how to get to the openthread cli

low lotus
vapid shell
#

You don't have to join your OTBR to that network, shouldn't be a problem if you don't

#

Right now HA doesn't know about either network though (as in, it doesn't have the credentials for either network)

#

What should be happening is the credentials should get pulled from the OTBR (or created) when the otbr integration was first added. There was a window where that code didn't exist, if you configured it during that window you'd not get an automatic Home Assistant network, and then you probably created your own in the OTBR UI?

#

There were meant to be some UI improvements on the way to help recover from situations like that but i didn't see anything in the release notes

#

If you don't have any devices, i'd probably remove the addon and re-add it to get rid of the network you made, then delete and re-add the otbr integration to get HA to configure it for you instead.

#

i'd probably want to check what state things were in after you reinstalled the addon and before you reinstalled the otbr integration, just in case things have changed in 2023.4

vapid shell
twin saffron
#

HomePods, I tried the SkyConnect and had problems with that so I switched back. Things were actually working pretty well in 9.5 but still had the occasional issue so I wanted to try 10.0 after rc3 came out based on the conversation here. I enabled it in the UI only.

#

Also, I made a mistake in my earlier statement. The bulbs do become available after anywhere from a couple minutes up to maybe 30 minutes?

#

I was looking at my binary sensor I made that covers all of my nano leaf bulbs that stays off because there is always at least 1 unhealthy bulb.

vapid shell
#

can you send a thread diagnostic dump

twin saffron
#

Sample of one of the bulbs

vapid shell
#

have you updated to 16.4?

twin saffron
#

Yeah, this is on 16.4

#

How do I do the thread diagnostic dump?

vapid shell
#

its on the thread integration

#

on the ... menu

twin saffron
#

Ah okay yeah one sec

#

Should be a config_entry-thread txt file? Just making sure I’m sending the right thing.

vapid shell
#

Huh weird it’s missing you HomePods

#

Right download but can you try again

#

I’ve got a dumpster fire waiting at the office so might not be able to look at this today

twin saffron
#

okay, no worries, I know how that goes!

#

I can keep trying to see if I can get the homepods to show up, what part of the file would have them?

#

oh got it

#

they showed up when I did it from the Thread page rather than the integrations page

#

take your time, no rush

glacial crystal
#

Hello there,
I got a message from OTBR that Thread and ZHA use different channels (15&17, SkyConnect) and that I shall activate Multiprotocol in the Hardware section to fix this (use same channel). Thing is this is already activated from the beginning I guess and nevertheless they do indeed use those different channels.
I assume I could fix this by resetting either or both of the implementations, but is there maybe an easier way? Can I simply change the channel somewhere?
Thank you in advance. #zigbee-archived

vapid shell
#

AIUI the thread stuff forces channel 15 because the API's needed to coordinate with ZHA don't exist yet

#

So right now there isn't an easy way

vapid shell
twin saffron
twin saffron
#

Everything became healthy again within a few minutes of unplugging the next HomePod in the living room. Going to give it a bit before I plug the other one and the ATV back in and see how that goes.

twin saffron
#

Plugged the ATV back in and lost a few bulbs. Unplugged it again and still hasn’t recovered after 20 minutes. Going to continue with unplugging the others.

fickle mantle
# glacial crystal Hello there, I got a message from OTBR that Thread and ZHA use different channe...

Some others asked the same on the Forum today, and they said did Thread-Integration->CONFIGURE->3dots->Reset Border Router. https://community.home-assistant.io/t/otbr-and-zha-share-the-same-radio-but-use-different-channels/556634 I really don't know what it means to reset the BR. I also took a look at some of the code, and the OTBR integration can now ask the ZHA integration what channel it is on, and somehow between it and the Thread integration can issue the warning.

digital salmon
# fickle mantle Some others asked the same on the Forum today, and they said did Thread-Integrat...

How many thread devices have you paired to Home Assistant? If you don’t have any, you can reset the border router. Go to „Devices & Services - Thread - Configure“. There you see your HA Thread Network and the „…“ menu, where you can reset your border router. If this doesn’t work and you don’t have any Thread devices paired to your HA, you can delete your Thread Service. It reinstalls automatically.

unborn thorn
#

Does Thread need different hardware, than wi-fi router? For sure it will not work, because it needs different software, but does it use exactly the same hardware as wi-fi?

brave gazelle
#

I had a thread integration pop up, and it asks me to add an open thread border, then below it says "other networks" and there is my Amazon Echo device but i cant Select it. How do i get the rest api url for that device? Did not work typing the ip adress.

vapid shell
vapid shell
#

This only works if Eero will tell you the TLV of course, not every BR does

#

If you add a matter device on android and the android device knows about the eero, then HA will sync it during the commissioning phase.

vapid shell
#

That said I don’t think we’ll see wifi routers getting flash updates to turn them into thread hotspots as well, unless they already had dedicated thread radios hidden on board

#

You’d kill performance switching between the 2

#

If it was hypothetically possible then it’d be a chip that let you turn off most of the dedicated WiFi decoding hardware and drive the radio directly. If there was a radio that could do that we’d probably have seen or heard about it on hackaday.

unborn thorn
#

Can thread work in that way:

  1. device -> thread border B -> ethernet -> matter
    or
  2. device -> thread border B -> ethernet -> thread border A -> matter

here are really 2 questions:
a) if makes sense to have multiple thread border routers pointer to 1 matter controller?
b) if it doesn't work like that and everything should go into thread border A to go into matter, then can it go through ethernet between thread border routers?

vapid shell
#

So matter and thread are separate things. You can have matter devices that don’t use thread at all.

#

Matter controllers might not have thread at all. Eg, the matter integration doesn’t know about thread directly

#

Think of BRs as similar to (but different to) WiFi access points

#

Some people only need 1

#

Some people need many

#

If you mean “phone” or “ha” in your diagram it’s more like

#

iPhone > WiFi > Thread BR (A or B) > Matter device

#

You’ll only see thread BR A talk to BR B over ethernet if they both support TREL which is a way to extend the range of thread. TREL is not common right now.

unborn thorn
#

let me ask in other way:
if I will have
1 matter controller on ground floor
2 thread routers (ground floor + 1st floor)

can I make thread connection by ethernet on each floor?

#

I understand your answer as:
thread routers are not designed to talk to each other by ethernet, they use radio for that purpose. There is exception TREL, but it is very rare feature right now.

#

So 1st floor thread will communicate to ground floor thread by radio to communicate to ground floor matter

Is it correct?

vapid shell
#

Sort of

#

Don’t forget that all mains powered thread devices can act as routers

#

Indeed the “leader” might not be a border router

#

So the path can be

#

iPhone > WiFi > Ground Floor BR > First Floor Eve Energy > Eve Door Sensor

#

And the BR that is chosen might be unrelated to your physical location

#

So you could be downstairs and you could want to turn a light off downstairs, but the ipv6 networking stuff doesn’t know that so it uses the upstairs BR

unborn thorn
#

thank you

fierce ruin
#

sorry for the need of an ELi5, i have an appletv with thread support, can the appletv act as a hub and i can connect any thread supported device to it? Something like an RGB light bulb.

#

and then i link the HA thread intergration to the appletv?

#

and finally, is it all ipv6, no ipv4?

unborn thorn
#

I don't know too much about Thread, but as I understand:
you can think about each device power connected (not battery) as a repeater to increase range of communication.

if you have Thread device in HA to get / send signal, then it can get it from any device. Also from tv.

From google I understand it as: it support only ipv6, not support ipv4 in Thread. Thread network is not wi-fi network, so it doesn't affect your wi-fi if you use ipv4.

fierce ruin
#

how do they communicate if they arent on the same network?

unborn thorn
fierce ruin
#

i feel kinda stupid not being able to understand the thread concept from reading articles about it.

unborn thorn
#

thread router is is kind of a bridge between networks

fierce ruin
#

does the thread network have a network key or something?

#

ah, that's a good read, thanks

unborn thorn
#

not your fault, I do IT about 20 years and I still have a problem to understand all this things. This is because everything is new, changing fast and people do bad job about explaining how it works. It will change with commercialising 🙂

fierce ruin
#

how do you pair devices from different manufacturers?

#

say i have a router from apple and a light bulb from philips

#

do i need to use an app from philips to connect it to apple home kit or how does it work?

unborn thorn
#

disclaimer: so far I use zigbee and I prepare to use Thread + Matter. I didn't use it so far.

#

if you use matter + thread, then in theory you should click button on device which you want to pair and it will semi-automate the job by bluetooth.

#

if you use only thread I guess you have to do it manually by choosing device from network.

#

how do you pair devices from different manufacturers?
for this one it will better if someone else answer. theory is not practice

#

oh and there is important thing which is always silently omitted in all YT videos:

#

very often if you have a device with dedicated phone app, then other integrations are limited with functions. For example with roomba you have a lot of options to set in dedicated app, but with HA or google home you have only option to start / stop vacuuming which is not really how you use roomba.

fierce ruin
#

i see

unborn thorn
#

and the last one is a big issue. At least for me

fierce ruin
#

thank you very much, doesnt sound that appealing, ill stick to zwave

unborn thorn
#

oh, but the last one is not only for Thread, it is for all kind of integrations which not use dedicated app

#

is it not really about network itself, but about integration

#

but it ends in the way you have for example HA, but on the end for some devices you use dedicated app anyway - this is the point of what I wanted to say

#

another example for YT this time: device to power on / off in google home integration has on / off, but in dedicated app also show power usage etc.

#

but this is not related to Thread network

fierce ruin
#

I see, all i need is an RGB light bulb (which zwave doesnt have support for, only strips)

#

and i thought i could make that happen with the apple tv

#

but seems like a lot of work for little gain.

#

was thinking of using an RGB bulb in the entrance to turn it red when the alarm is triggered.

unborn thorn
#

I would say it mile stone here is to add Thread to HA and it should be straight forward way to accomplish that from that moment.

fierce ruin
#

does the border router do ipv4 to the HA integration? else im screwed either way, i dont have ipv6 on my network.

unborn thorn
#

I think you can buy dongle USB for HA

#

again I remind I didn't make it myself yet

#

I am not 100% sure it works, but I doubt using ipv4 in your wi-fi / ethernet will be a problem

#

I bet there is ipv6 <-> ipv4 translation between networks

#

but again someone later can confirm this things

#

this is not true, but in very simple thinking way for this context ipv6 and ipv4 assign different IP based on MAC address. So the same MAC address can have IP in ipv6 and ipv4.

vapid shell
#

You don’t need ipv6 in your LAN

#

The Br advertises its own ipv6 network regardless of what you have

#

(The border router and HA need to be on the same vlan tho)

fierce ruin
vapid shell
#

(It’s not always clear otherwise)

half marlin
autumn merlin
#

Uh oh... Nanoleaf lights inactive, OTBR unable to connect and the ZHA retrying setup... any ideas on where to start with this one? 😄 https://pastebin.com/Cgch8stH

autumn merlin
upbeat cairn
autumn merlin
split gazelle
#

Hi there. I'm trying to use the OpenThread Border Router addon with SkyConnect. But it just loops when "Starting otbr-agent". The error message I get is a timeout and "RadioSpinelNoResponse". Anyone had this problem? (I'm not using the ZigBee part of SkyConnect, and I have Multiprotocol enabled).

#

sigh Never mind me. I already have a border router in HA....

vapid shell
#

I'm sure this is what you mean you figured out, but: the multiprotocol addon is an OTBR add-on that works with multi-protocol devices. The OTBR add-on is for dedicated thread dongles.

worn plinth
#

can you turn the skyconnect into a dedicated thread dongle by flashing the otbr firmware to it? i wasn't sure what host to connect the otbr integration to in that case

vapid shell
#

yes, the otbr addon will flash dedicated thread firmware to a SkyConnect (if you don't have a conflict with teh multiprotocol addon)

#

the addon should also trigger the otbr integration to be installed with the right settings

worn plinth
#

got it. i haven't had much luck with the otbr addon so far. seems to fail on the probe step:

Error: Failed to probe running application type
s6-rc: warning: unable to start service universal-silabs-flasher: command exited 1

but i'll just try flashing directly instead of with the addon! skyconnect is currently flashed with multiprotocol, so i'll just try undoing that and going straight to otbr unless there's a good reason to stay with multiprotocol

worn plinth
#

flashing directly worked just fine 🙂

small heart
languid parrot
#

do you guys have any thread devices youre actually using. i've got the integrations set up with skyconnect multiprotocol but i cant see any thread devices worth buying over zigbee right now

hoary harbor
#

Nanoleaf bulbs working great for me

vapid shell
#

Eve Energy and Eve Thermo (with homekit over thread, not matter) and Wemo stage controller are all on my production network

#

Nanoleaf Ls1 (also homekit) works but it’s just a device I test code changes with

half bluff
#

Anyone want some Nanoleaf bulbs im sellin?

#

@vapid shell For the Eve Room. Is there any way to get the option to change the display of the device from Celsius to farenheight like in the eve app? My HA data shows temperature in farenheight but my device is stuck on Celsius with no way to change it.

vapid shell
#

Maybe

#

There is a homekit characteristic for that

#

(In the spec I mean)

#

Can’t remember if it’s thermostat only

#

If you send me a diagnostics file for an eve room I should be able to tell

#

If not it’ll be still be possible but it’s blocked on some other work some eve settings don’t get their own characteristics, they share one. A fair bit of faff is needed to get them wired up in the current code. But I’m working on it for my eve smoke alarm (so I can test it in HA) and eve thermo (so I can set the orientation setting). Will be easy when I’ve got those working.

rich cove
half bluff
flint zodiac
#

I presume keeping my Homepod powered next to running OTBR is just me making my life miserable attempting things with Eve?

vapid shell
#

i'm sure your life will be miserable regardless

half bluff
#

Got em

vapid shell
#

in general, it shouldn't matter if you have a HomePod and an OTBR running side by side

#

they'll each generate their own ULA ipv6 network and advertise it to the whole LAN

#

so you might end up with your interface having a GLA from your ISP, an f80 link local, a privacy preserving link local, a ULA from the OTBR and a ULA from your homepod

#

but despite your ip assignments list disappearing off the screen, things should still work

#

last i heard the HA iOS app did not have the thread entitlement and hence was not updated to try to sync creds from HA

#

so you can't accidentally cross the streams

flint zodiac
#

Yeah, IDK. Everyone seems to be able to commission their Eve plugs just fine. There's even a demo video on the HA site. But mine is just being an obstructionist or something.

vapid shell
#

i've lost track.. Matter or HomeKit? HAOS? iOS or Android? Are you expecting to use the OTBR?

flint zodiac
#

Matter.

#

On iOS.

half bluff
#

You trying to connect to Homekit or share homekit to HA?

flint zodiac
#

I mean, ideally it'd bind to OTBR, but I'm not expecting much. I can set it up in Apple Home as a Matter plug just fine. But doing the multi-fabric stuff doesn't seem to work. I get always unable to pair.

half bluff
#

If you want directly to HA OTBR you need android device

flint zodiac
#

Oh OK.

half bluff
#

Apple will only share it to HA with using its own OTBR from Homepod

vapid shell
#

if it works in iOS but not HomeAssistant and you are using the "Share" approach, you might have an ipv6 connectivity issue

#

if you paste your thread diagnostics file i can check the common stuff

flint zodiac
#

Yeah, I guess I have to check whether my router does peculiar things. It's a Fritzbox and does funny business in regards to IPv6. Like blocking Teredo by default, which breaks games using Xbox networking stuff.

vapid shell
#

your router shouldn't matter

#

well

#

unless you have isolation on WiFi

#

the HomePod sends its own RA's, so even if ipv6 was turned off on the Fritzbox it would still work

#

And FW doesn't normally kick in unless the traffic is leaving the subnet (like you have vlans etc or when it hits the internet interface)

half bluff
#

When you are adding it from Apple Home to HA make sure to use the shared code produced from Apple Home when you click get shared code

vapid shell
#

if you send your thread diagnostics i'll be able to tell immediately if your HA isn't seeing the RA's from the HomePod

flint zodiac
vapid shell
#

so if you look at the HomePod section

half bluff
#

And then in HA when add matter device say I dont have a qr code and then more options, then paste code and paste it

vapid shell
#

prefixes is empty

#

so that means your HA can't use the HomePod as a thread BR

flint zodiac
#

I guess I need to figure out how to fix that.

vapid shell
#

first thing - check your HA IP settings

#

ipv6 must be DHCP

#

static breaks it unfortunately

#

and obv off doesnt work

sick swan
vapid shell
#

yes

#

lol

flint zodiac
#

Ah I have it set to static, so that I can put my own ULA in and set up a fixed host name on my DNS server.

#

Hope my router does DHCP-PD, so that the Yellow keeps the same host part.

vapid shell
#

DHCP should still handle RA's

#

its just a bad name in UI

sick swan
#

The value underneath is auto actually, it is really just the UI string

flint zodiac
#

OK, the HomePod section also lists prefixes now. Thanks for the help.

vapid shell
#

👍

half bluff
#

@vapid shell Sent you the diag file

light herald
#

Guys, quick question:
I saw you all talking about the topology page, is it only available if HA is running OTBR?
My HA doesn't run OTBR, so I only have a Thread network that uses HomePods as BRs, I can't see its topology, is that right?

vapid shell
#

Correct

#

Even if you did, it’s hidden by default because it’s jittery and crashes 🙂

quiet stirrup
#

is there plans to make it a dev only enabled feature/beta feature eventually?

vapid shell
#

Not a dev on it, but given it’s ability to cause me support tickets I hope not 😄

#

I hope something equivalent to the topology view is integrated directly into Ha eventually really

quiet stirrup
#

would be nice really, almost like what eve does but with more detail to the end user

digital salmon
#

Is there any way to find out which channel/frequency is used by my Apple Thread network?

#

Do we know anything about how Apple Thread Border Routers choose a channel for the Thread network?

#

Is it possible to change that channel somehow?

#

I know, these question not directly related to Home Assistant. 😃

quiet stirrup
#

i belive you can, but you need something that can read the spectrum (5ghz), it should read as the vendor being Wi-Fi Alliance

vapid shell
#

If we can get apple to extend our BR then we’ll be able to using “pending datasets” to coordinate every device on the mega switching channel.

#

Without that, probably not

quiet stirrup
#

that will be done through the skyconnect if it is possible?

vapid shell
#

Or another compatible thread radio

digital salmon
digital salmon
quiet stirrup
#

wait, yeah. i realised that after doing more investgation. just ubiquti things

#

just didnt update my message

digital salmon
digital salmon
quiet stirrup
#

just realised it doesnt show any infomaiton regarding devices that doesnt have a SSID or sometimes a macID

#

really gotta get a old android device, might come in handy

digital salmon
quiet stirrup
#

from my understanding it is, but ill grab a 2nd device and see how it goes

digital salmon
#

Aha, ok, didn’t know that.

#

Interesting, maybe it’s a viable feature request to ubiquiti to show us Thread devices.

quiet stirrup
#

its possible, but their environment scan is only meant to be for other wifi enabled devices

digital salmon
#

But at the moment they aren’t in control of them, because the have no thread border routers… 😃

#

Ok, I think now I understood what you meant… 😂

tired surge
#

Hello

#

I'm looking for how to join an OpenThread network with an RCP Thread (not Skyconnect) in HomeAssistant.

#

Could you tell me where to look?

tired surge
#

I found what I was looking for

wary mountain
tired surge
# wary mountain Always helpful to post the link or the solution.

Home Assistant Add-on: OpenThread Border Router
Installation
Follow these steps to get the add-on installed on your system:

Navigate in your Home Assistant frontend to Settings -> Add-ons, Backup & Supervisor -> Add-on Store.
Click on the top right menu and "Repository"
Add "https://github.com/home-assistant/addons" to add the "Home Assistant Add-on Repository for Development" repository.
Find the "OpenThread Border Router" add-on and click it.
Click on the "INSTALL" button.

wary mountain
#

I'm on "OTBR and ZHA share the same radio but use different channels". The "repair" option that comes up isn't really related and doesn't do anything. Going to try messing with the OTBR.

#

I don't actually need a zigbee network, but the openthread firmware for my skyconnect didn't seem to work.

#

I'm afraid to do much, because this is the farthest I've gotten with my thread network. Tempted to try "migrate radio" on the Skyconnect configure page.

#

I've run into this before and couldn't find a way to set a channel on either zigbee or thread.

tired surge
#

I am using the nRF52840 Dongle, low-cost USB dongle.

#

This avoids multi-protocol issues

wary mountain
#

You'd think when I have the most standard hardware you can get that it'd work a little more smoothly.

#

OTBR is configured with a Thread network on channel 15, ZHA is configured with a Zigbee network on channel 11.

#

and there's no reasonable way to fix it.

#

I don't even want a zigbee network

vapid shell
#

You are trying to get on a plane as it’s still being built

#

When the OTBR integration was added ZHA didn’t have a way for other integrations to query what channel it was using

#

The first PR locked it to channel 15 to try and match the default for ZHA

#

The 2nd picks the channel ZHA uses at the time your thread network is created

wary mountain
#

So if I could just recreate the thread network

vapid shell
#

Yes

wary mountain
#

But to do that, I need to remove the zigbee network as well. I can't seem to decide the order.

vapid shell
#

That repair button wasn’t there last month and I haven’t had time to update my yellow and see what made it into this months release

wary mountain
#

"Provide URL for the Open Thread Border Router's REST API"

vapid shell
#

But we were talking about having a repair button that reset OTBR

#

And re-ran the initial setup

wary mountain
#

I haven't been able to re-run the initial setup without removing SkyConnect Multi-PAN

vapid shell
#

Right so that’s probably not being finished yet then

#

Or it’s not in the bit of Ui you are looking at

wary mountain
#

I just wish I understood this well enough to work on it. I am a professional dev, theoretically.

vapid shell
#

It’s just lots of moving parts and when you fall off the happy path… you find yourself in part of the plane with no seats

wary mountain
#

I did try a reformat, went from Ubuntu to Unraid. Hit the same issue.

#

And from a container to hassos

vapid shell
#

Hassos is pretty much a requirement for things to take the happy path

#

Some people manually flashed the thread firmware on to their SkyConnect and then run the upstream OTBR code on a separate computer

#

That works but there’s no automation

wary mountain
#

Oh, interesting. Maybe I'll try that path.

vapid shell
#

If you can manage to flash that firmware then plug it into haos you should be able to use the OTBR add on and not the multi protocol one

#

The OTBR one won’t trigger zha

wary mountain
#

The openthread firmware

vapid shell
#

Yeah

wary mountain
#

I've tried that before, but no harm in trying it again.

#

I think I get stuck on the " Open Thread Border Router's REST API URL"

#

But this IS the OTBR, so maybe it's asking what to set it to now and not looking for it to already exist.

vapid shell
#

You want the addon

#

That URL is a question from the integration

#

The addon should auto install the integration

wary mountain
#

Makes sense. Flashed to OpenThread and will try the addon. With a hassos restart for good measure.

vapid shell
#

Toddler breakfast time Bbiab

wary mountain
#

Nanoleaf app sees the thread network name and channel 15, but the OTBR and the app show different Pan ids and extended pan ids.

#

The addon also installs the SkyConnect integration with a big Configure button. I think if I hit that configure button to set up skyconnect it flashes the firmware back to Multi-PAN.

vapid shell
#

So ignore that SkyConnect integration

#

All it does is trigger the happy path (multi protocol addon and default zha)

wary mountain
#

Seems weird that I'm showing different PAN IDs. Where would nanoleaf get that info if not from the active OTBR?

vapid shell
#

Well the ext pan Id is visible in zeroconf

wary mountain
#

Clearing the data from the app rn

vapid shell
#

HA uses zeroconf data to link the BR to the thread network in the thread configure panel

#

So sometimes when things have gone wrong you see them unlink

wary mountain
#

How do I access zeroconf data?

#

I think I got it. I didn't understand that the Thread, Configure page was showing more than one home-assistant network.

#

Until I added an additional network and had 3.

#

At which point I was able to identify the correct network and move my OTBR to it.

#

Oh shit, that did it! I have a nanoleaf A19 bulb working on the SkyConnect OTBR.

vapid shell
#

Nice

wary mountain
#

I've been fighting this for months, fiddling with it, waiting for patches, and watching for forum threads. Thank you for all the help. Probably tomorrow I'll document what I did and post it somewhere relatively quiet and unofficial.

frozen gale
#

Hi all, i've got the skyconnect set up in home assistant and have a zigbee device registered with it, however i'm trying to set up the multiprotocol support for thread, and when i try in the hardware settings, it says "The hardware options can only be configured on HassOS installations."
please tell me that thread isn't only for the purchased hardware
I am running my instance in docker

autumn merlin
vapid shell
#

If you are running on docker HA can’t install extra containers for you. If you are running HAOS it can.

#

Right now the focus is on providing a seamless experience on HAOS (because that’s where it can be seamless)

light herald
#

Can bulbs be routers in Thread?
In zigbee I’ve seen bulbs that can only be endpoints and bulbs that can be routers (hue bulbs).
Looks like my Nanoleaf bulb is showing as an endpoint in Thread, want to know if it’s possible for bulbs to be routers.
My guess is there is no limitation, all up to what the manufacturers decide to do?

prime sky
quiet stirrup
#

I’m pretty sure it’s basically a big no no to make a thread router something that is battery powered

turbid helm
#

think thread will be integrated into devices like phones so bluetooth/wifi isn't necessary for direct comms?

prime sky
#

No there's really no point in adding thread to phones, think of thread more like a wifi network for low power low bandwidth devices and a thread border router as router for those devices to your normal network and the internet

delicate drum
#

There’s plenty of thread hubs in the home, Apple TVs, smart speakers and displays. As long as your phone of choice can talk to the thread mesh via IP no need for it in the phone. I have thread hubs and now multiple thread networks from eeros, echos, nest hubs, appletvs. None of them talk to each other yet but my thread devices are accessible to everything.

languid parrot
#

Adding thread to phones honestly seems silly. Like what's the point

hoary harbor
#

Yeah, kinda like adding zigbee

#

Why bother

near python
#

Oh good, the single-protocol firmware for thread is out now. I have my Zigbee on a separate device, so it's nice to not have an unnecessary extra Zigbee running.

rapid umbra
#

Anyone else experiencing the issue where all their mains powered thread devices work fine but the battery powered sleepy child devices tend to fall off the network?

#

Using skyconnect on an rpi4, ha os 10 core 2023.4.6

#

All my nanoleaf bulbs are fine but all eve door sensors and eve weather sensor have fallen off with no return even after power cycling the rpi

#

Relevant log:

Logger: aiohomekit.controller.coap.connection
Source: components/homekit_controller/connection.py:775
First occurred: 10:56:01 AM (57 occurrences)
Last logged: 2:39:47 PM

Decryption failed, desynchronized? Counter=0/4
Decryption failed, desynchronized? Counter=27/29
Decryption failed, desynchronized? Counter=42/45
Decryption failed, desynchronized? Counter=98/101
Decryption failed, desynchronized? Counter=0/2

vapid shell
#

No

#

My eve thermos are battery powered

#

They do fall off from time to time but Ha restart sorts it consistently

rapid umbra
#

Just did another power cycle and the child devices started adding back again

#

2 of them were still having issues so I pulled the batteries from them, that fixed it for one

#

The other one’s battery was just dead, probably from constantly trying to reconnect with no success. Swapped out the battery and we’re back up and running 100%

autumn merlin
#

Hmm - im getting the same thing (2023-04-24 09:25:52.534 ERROR (MainThread) [aiohomekit.controller.coap.connection] Decryption failed, desynchronized? Counter=1348/1350) - however i only have 3 Nanoleaf light strips, no battery thread devices. Any idea what this error is and do i even need to worry about it?

rapid umbra
#

Power cycle everything and wait for the network to rebuild seems to be the way

light herald
digital salmon
#

I think @vapid shell already gave me the answer…

digital salmon
digital salmon
digital salmon
quiet stirrup
#

Feels bad with the 4 pings..

hoary harbor
#

Oh snap it supports the nRF52840 DK

#

I know what I'm working on next

light herald
#

https://reddit.com/r/Nanoleaf/comments/12j4eyw/_/jfwkmo2/?context=1

In this post, the paragraph above TLDR stated that:

all of Apple’s devices … are stuck at Thread v1.2. v1.3 is required for all vendors to share a single Thread Network instead of creating a bunch of networks that can’t communicate.

Is this true? Because I already have multiple vendors’ devices in the same Apple Thread network. Some are matter, some are only HAP. Even for matter I have 2 venders’ devices: Eve and SwitchBot.
Am I misunderstanding the above post? Or the post is simply wrong?

prime sky
#

also thread 1.3 doesn't really add any credential sharing per say it, thats still up to each vendor to give access to their apis to share credentials

hoary harbor
#

The only thing preventing other TBRs from joining Apple's Thread network, or vice versa, is Apple refusing to grant the entitlement that lets apps read the Thread network dataset

prime sky
#

^

light herald
hoary harbor
#

I'm boutta jailbreak an old iPhone and do it that way tbh

#

Because it's annoying

prime sky
#

just not easy unfortunately

hoary harbor
#

How?

prime sky
#

modified the matter example light app to print out the thread networkkey and flashed my nrf52840 with it

#

actually now that I think about it, it might just be possible to get the thread credentials without needing a device that joins the network I just need to trick apple into thinking my matter device is thread enabled

light herald
prime sky
#

currently I know it works if you are going from apple to google, amazon and HA but I dont know if it works the other way around with apple

#

thats only because recently google and amazon removed the artificial requirement for border routers on devices that are already connected to the network

light herald
prime sky
#

yeah anything to apple probably wont work till they release a new ios update

#

unless you have an apple compatible border router then it should work

light herald
#

Gotcha, thanks Arturo, lots of good info!

hoary harbor
#

Apple seems to be the sole exclusion in making it a pain to do so, but as Arturo showed it's doable

#

And once a device is connected to any TBR on your network, any other platform's software/hub/whatever can discover it. It's just IPv6 right on your home network at that point

#

And it's up to the platform at that point as to whether they support Matter/HomeKit/whatever protocol is riding on top of Thread

light herald
hoary harbor
#

Do Nest hubs let you choose to join an existing Thread network if the information for one is in your Android device?

light herald
light herald
hoary harbor
#

Based on "v1.3 is required for all vendors to share a single Thread Network" being wrong I don't really trust that source

light herald
#

Right, a comment below and Artura mentioned that 1.3 doesn’t really fix that.

light herald
light herald
#

Another question. What might they have meant in this comment https://reddit.com/r/Nanoleaf/comments/12j4eyw/_/jfx7m34/ by saying:

Thread 1.3 adds support for mDNS, which is required for Matter to work correctly.
1.3 white-paper also mentioned that one of 1.3’s use cases is “Enabling Matter”
Doesn’t Matter already work with Thread 1.2?

half bluff
prime sky
#

yeah im going to try that out in a bit hopefully im able to get the credentials without having to flash anything

prime sky
hoary harbor
# 
devices as of Thread Specification 1.3.0. There must exist a Service Registry, maintained by a border router. SRP clients on the mesh
network can register to offer various services. An SRP server accepts DNS-based discovery queries and additionally offers public key
cryptography for security, along with other minor enhancements to better support constrained clients```
#

Specifically SRP though

#

Avahi/mDNS/etc. is independent of the transport layer

near python
#

How do I tell what device is hosting the random thread network my OTBR gateway web UI is offering to join?

#

I have a Google Home devices, but only the Mini, so likely not Thread, and we have Alexa devices too, one of which is the spherical one with a Zigbee radio.

prime sky
digital salmon
light herald
#

Following the nRF52840 dongle thing 👀

digital salmon
#

Ok, I flashed the firmware to the dongle via the programmer. Now I want to configure Wireshark for Thread. But I need the decryption keys. @prime sky 😃

prime sky
#

Let me see if I still have the compiled binaries I used

#

If not I’ll modify the matter example again

digital salmon
#

Thank you so much. But no rush. It’s late here in Germany. 😉

light herald
#

I wish Discord let us put our local time in profile.

digital salmon
#

😃

languid parrot
#

one of my least favorite things about thread discourse is everoyne like "thread doesnt require a hub, unlike zwave or zigbee, you just need a thread border router!"

#

like this is the kind of shit that makes thread confusing to non techies

#

probbalby sme of the most confusing marketing jargon ive ever heard

quiet stirrup
languid parrot
#

yeah and its at least kind of excusable here. thread functions differently than one might expect, but this is a case of people getting too technical when they dont need to

#

like, all they need to say is that you need a matter hub and a thread hub and maybe its not technically accurate but most people dont need to know that stuff and honstly probably dont care to

languid parrot
#

so, i was curious to see if i could bring my old smartthings hub in as a border router and carelessly plugged in a 12v cord to the 5v device for 10 minutes before i realized what i did. pretty sure i fried it

quiet stirrup
#

Tried it again on 5v?

languid parrot
#

yep

#

no light even

hoary harbor
#

RIP in peace 🪦

bronze fog
#

What's the current status of Skyconnect USB and getting HA connected to an Apple Home thread network?

vapid shell
#

The easy way is blocked on an entitlement from apple, and then some code changes to the iOS app to sync thread credentials.

#

That’s ignoring the fact that they are different versions of thread (apple is still on 1.2, sky connect is 1.3).

#

But people have made their own matter Devices that dump the secrets.

#

So they flash their own firmware into a microcontroller (with a thread radio), pair that to Apple Home and they then have the thread secrets, so can join their OTBR to that network

twin saffron
#

I’m trying again to migrate my nano leaf bulbs over from my home pods / ATV network (which has actually been fairly stable lately) to my skyconnect OTBR network and so far with only 4 of the 20 or so bulbs setup, I’m already seeing 3 of the bulbs becoming unavailable more often than they are available. Anyone had any better luck than me that could offer some tips? These are the older non-matter versions.

vapid shell
#

Could it be a range issue? Are they the 4 closest to the OTBR and each other?

#

When they are not working do you see any evidence of them with a zeroconf tool

#

Can you reach them with ping6

twin saffron
#

Yeah I’ve been wondering if maybe it’s a range issue. The 1 bulb that is having no problems is right next to the skyconnect and the other 3 are grouped together in a nearby bathroom vanity that is maybe only 4 meters away. But maybe the range is more sensitive with this setup.

#

So I’ve been using that app to monitor the bulbs and they do show up but I’ve noticed the numbers after the name changing for the problematic bulbs. What does that mean? For example, one of them that wasn’t working last night had 54587 at the end of the name and this morning when it seems to be staying connected that number is gone.

#

And the one that has been cutting in/out this morning currently shows a 1 after the name.

#

Running a ping6 right now to that one and while the latency seems in line with the other bulbs, there appears to be about a 30% packet loss.

#

It went unavailable just now mid ping and it is still visible in the app with the same name. So it seems like it’s probably just having trouble with all the dropped packets.

twin saffron
#

Maybe if I migrate more of my bulbs and build out the mesh a bit more, that will help with the packet loss?

#

Lastly, not sure if this matters at all, but I can't ping the bulbs using the DNS name that are using the SkyConnect as the names don't resolve. This works fine when pinging the bulbs connected via the homepods.

twin saffron
#

Now I'm getting about 2% packet loss to that same wonky bulb and it is available and working fine. Definitely seems to be the culprit, I just have no idea what is causing the intermittent packet loss.

vapid shell
#

You should probably try adding more bulbs to build out the mesh

twin saffron
#

Okay thanks, will do that later today and let you know how it goes. Appreciate the help!

twin saffron
#

Adding even just 2 more bulbs seems to have solved all packet loss issues. 0% across the board and also a much lower latency. Going to continue to gradually migrate the remaining bulbs and hopefully all stays well.

languid parrot
#

thats actually crazy, like i ehard thread mesh got way better with more devices but only 2 additional thats kinda insane

#

how many devices do you have total connected through thread

twin saffron
#

15 total and they are all nanoleaf A19 bulbs. All were setup and working decently via 4 homepods and 1 ATV thread network but I'd still have the occasional issue that required resetting things and futzing around with it for a while until it was solid again. Getting tired of that so I wanted to give the SkyConnect another try so that I only have 1 border router which sounds like it will play nicer with HA. And yeah going from 4 to 6 devices seems to have helped and continues to stay solid so far but time will tell.

#

The odd thing was that the 2 newly added bulbs are in the same room as the 1 working bulb and the SkyConnect but actually further away from the 3 that were having problems. /shrug

languid parrot
#

what makes you say that less border routers would play better, i would think the opposite

hoary harbor
#

Short version is in that HAOS 9, multiple border routers would leave you with stale routes and all your stuff would lose comms. In HAOS 10 you don't get stale routes anymore, but (as of like 3-4 weeks ago so probably even changed since then) you only get one route to your Thread network at any one time. The last border router to advertise it wins

#

Theoretically/eventually multiple TBRs should provide redundancy, but until then one is best

vapid shell
#

HAOS 10 is better in that regard (it has ipv6 unreachability detection, so it shouldn’t use stale routes) but people don’t understand that physical locality is not represented by ipv6.

#

So right now we keep seeing ATVs in a media cupboard surrounded by hdmi and usb and power that were barely on the mesh getting chosen as a valid BR by the ipv6 routing stack. You get lots of packet loss in that scenario (multiple outages an hour).

#

TREL helps by letting BRs use your Ethernet and WiFi as a backhaul, so even if your packet goes to an unsuitable BR it is forwarded to a better BR

#

But TREL is not available on Apple or HAOS. I’m not aware of anyone shipping it yet. You’d see a trel zeroconf record if you had it iirc.

#

What people don’t understand is that while adding more BRs does technically add more router nodes (just like adding more light bulbs adds more router nodes) that doesn’t really help with routing to your LAN

#

It’s complicating routing (and it seems neither the kernel, network manager or systemd work out of the box with this kind of routing).

#

For theoretical improvements in some outage scenarios

#

It’s not improving latency or adding bandwidth or anything like that

#

My take is that many failure scenarios my SkyConnect box will face will also take out my HA

#

(There are some benefits, like hardware failures, but for me the trade off of not having weird routing shit.. I’ll take stable most of the time please!)

#

(The scenario above, with upstream NetworkManager and none of the patches HA had to make, is that you get one route at a time. Every 3 minutes a BR sends an RA and then it becomes the active BR for HA. But if you have 3 HomePods your Ha is doing a route change once a minute. And those might not be atomic. That’s a lot of chaos getting injected.

hoary harbor
#

I was hoping Thread would make HA HA more possible since having multiple TBRs should let me fail over automatically at a platform level (proxmox), which is totally impossible with zig*wave (maybe possible with expensive network USB stuff?)

#

Alas we are not yet there

#

But I compare it to 10 years ago when I was trying to get any level of home automation whatsoever with an Insteon serial->powerline device and I don't even remember which software package and I am reminded to be all the more grateful for what we have available today

vapid shell
#

Yeah

#

Does proxmox do clustered FS or do you have to provide your own HA storage?

hoary harbor
#

It natively supports ceph but that's overkill for even my home lab

#

I do the "ZFS pool on each node and scheduled replication (zfs send/recv)" approach, which at worst would lose up to REPLICATION_FREQUENCY data, and really only recorder data at that

vapid shell
#

Ah nice

hoary harbor
#

I've also had several tabs open for a while now on setting up a Galera cluster so even that bit of potential data loss would be eliminated

vapid shell
#

I’m always trying to strike a balance

#

I don’t have time to babysit DB clusters

#

That’s time I could be hacking on this shit

hoary harbor
#

TRUE. You should do nothing that prevents you from working on HA 😄

vapid shell
#

I want just enough resilience

hoary harbor
#

On an unrelated topic I have a great recipe for rabbit stew...

#

The proxmox ZFS thing does work really well honestly. I replicate every 15 mins and it takes basically no time to do so, and I can live with at most 15 mins data loss

vapid shell
#

And I can arrange for metric tons of rabbit shit to arrive to your home lab

hoary harbor
#

lmao

vapid shell
#

Yeah I love zfs send/recv

#

Would be great if there was a k8s CSI that could do a pull before starting a pod…

near python
#

That mesh I'm seeing is definitely the Amazon Echo. It matches one of the TXT fields of the _meshcop._udp services.

#

But I don't really know what to do with Thread yet; I don't think I have any actual Thread devices.

jaunty cobalt
#

I installed on my Yellow the add-on for openThread and now the ZHA is not working anymore.... I cannot connect to all the zigbee devices which were connected. What did I do wrong?

vapid shell
#

There is a multiprotocol addon and a thread addon, both will flash new firmware. The thread one does not have zigbee support.

jaunty cobalt
vapid shell
#

Does thread work?

jaunty cobalt
#

i can see 2 border routers (both apple devices)

vapid shell
#

They are being detected over wifi, not thread

#

What thread devices are you hoping to use? Right now you can’t use thread with ha yellow for matter anyway.

#

(Working out if it’s easier to revert the change or fix things)

jaunty cobalt
#

Yeah... I thought I should install it. That was not a good choice because non of mine zigbee devices (all my lights in house) do not work now

#

I think I have to revert it

vapid shell
#

So with SkyConnect you can plug it into your Mac/windows/Linux box and use web flasher to revert the firmware upgrade

#

I don’t actually know what the process is on ha yellow, sorry

jaunty cobalt
#

there is a instruction website of hass for the yellow. I can find that. Thanks for your help

upbeat cairn
jaunty cobalt
half bluff
#

Interesting Discovery. Apple has finally adopted thread version 1.3.0

vapid shell
#

Out of interest so you see any _trel._udp.local zeroconf entries ?

#

(I expect not)

half bluff
#

Huh?

#

Trel?

vapid shell
#

Yes, trel

half bluff
#

No

vapid shell
#

Trel would solve the case where an ATV with poor mesh connectivity can still get picked by Linux as a valid router and then drop packets

half bluff
#

Does this mean that we can mesh border routers together with HA?

vapid shell
#

Border routers can already mesh with each other via thread radio when they have the same credentials, HA or not

#

TREL means they can use WiFi or Ethernet to bridge gaps that thread cannot

#

Which can improve coverage, and it can mean that some mesh transmissions are offloaded to WiFi and Ethernet instead of thread, which can reduce load on your mesh.

#

AFAIK it’s done automatically between BRs that support it (so there would really be user facing changes) and the hope was that it would be mandatory in 1.3.1.

#

It should eliminate problems where meshes keep partitioning and merging, which is I suspect one of the causes of frequent but short bouts of unavailability

#

Or where some devices are online and some aren’t

#

(Hence why I am more excited by whether apple added it than 1.3.0)

half bluff
#

I see. Well until next year lol. Doubt apple will make it a priority

#

When is 1.3.1 coming out?

vapid shell
#

Don’t know

digital salmon
#

WOOOHOOOO!!!! With the latest beta Apple brings Thread 1.3.0 on the way:

#

Upps…, didn’t read the latest messages… 😂

light herald
#

Can someone remind me what 1.3.0 means? Working together with non-Apple BRs in the same Thread network? I heard this won't be achieved by 1.3.0

vapid shell
#

What’s needed to have apple and non apple BRs on the same network is to have the secrets for their network or be able to get them to use ours, which is unrelated to 1.3.0.

light herald
#

that's my impression too, thanks for confirming.

delicate drum
#

yeah I have 4 thread networks in my house. AppleTV4k on one. Alphabet google nest hub 2nd for another, then I have two echos forming a third, and another echo and my Eeros forming fourth. No way, it seems to merge them manually.

nova swan
#

Anyone come across nifty devices that use Matter & Thread?

stoic whale
#

Any tips for troubleshooting a HomeKit over thread setup for my Smartwings Nano blinds using the SkyConnect?
I have:

  • Bluetooth Proxy via ESPHome on a M5Stack Atom lite
  • Skyconnect flashed with OpenThread RCP
  • OpenThread Border Router pointing directly to the Skyconnect

I was able to use the bluetooth proxy to add the blinds via the HomeKit Controller, and then click the "DUC Blinds EC18 Provision Preferred Thread Credentials" button, but now the blinds show as unavailable.

vapid shell
#

So first step is to get a tool for checking zeroconf or mdns and look for _hap._udp

#

If you can see it in there then the thread migration worked

#

But either you have ipv6 issues or it was very slow

#

If it’s not there then it’s not connected by thread.

stoic whale
#

Do I need ipv6 up and running on my home network for thread to function or should it work if the only ipv6 stuff is happening on my HA box?

simple yew
stoic whale
#

Well, the good news is they're discoverable:

#

on the HA Logs: Config entry 'Dining Room Blinds 5' for homekit_controller integration not ready yet: failed to connect; Retrying in background

vapid shell
#

Can you ping6 the addresses in mdns?

stoic whale
#

yep! just tried it in HA:

  Home Assistant URL:       http://homeassistant.local:8123
  Observer URL:             http://homeassistant.local:4357
➜  ~ ping6 fdc4:4845:e8b7:1:dfb1:59bc:4982:f373
PING fdc4:4845:e8b7:1:dfb1:59bc:4982:f373 (fdc4:4845:e8b7:1:dfb1:59bc:4982:f373): 56 data bytes
64 bytes from fdc4:4845:e8b7:1:dfb1:59bc:4982:f373: seq=0 ttl=64 time=1074.038 ms
64 bytes from fdc4:4845:e8b7:1:dfb1:59bc:4982:f373: seq=1 ttl=64 time=81.572 ms
64 bytes from fdc4:4845:e8b7:1:dfb1:59bc:4982:f373: seq=2 ttl=64 time=1589.097 ms
64 bytes from fdc4:4845:e8b7:1:dfb1:59bc:4982:f373: seq=3 ttl=64 time=595.723 ms
stoic whale
stoic whale
#

well: after deleting the blind and my OTBR install and redoing booth, I can confirm it now works!

magic trail
#

Is there a way to choose which of my thread router devices should be my leader? (Using nanoleaf bulbs via SkyConnect multi protocol)

boreal crescent
#

AFAIK it'll always be the first router in your Thread network

vapid shell
#

When a router eligible device joins the network it will become leader if there isn’t one. But other routers can take over (if it falls off), so realistically you can’t

magic trail
#

Thank you, both. @boreal crescent and @vapid shell I did a reset of the leader, because it was the furthest away from the border router and always slow in responding. Now all bulbs have a good speed, but I noticed that I can't remove the old instance of the resetted device and I have no leader device anymore. They are all routers now.

rapid umbra
#

Is it too optimistic of me to think that one day we’ll be able to join our skyconnect BR to apple’s thread network and have access to all thread accessories that way?

#

Having everything paired directly to skyconnect is proving too unstable for me so I’m very tempted to just repair everything to the apple network and hope we can just pair the skyconnect BR to the existing apple network someday down the line

#

All of my thread accessories in the house have all been demoted to non-critical functions anyway that don’t need any robust automations, so homekit is fine for my use case

#

Just tired of the constant disconnects and needing to restart HA just for my utility closet light to turn on when I open the door

vapid shell
magic trail
#

@vapid shell ah, good to know that a b-router can also be a leader. Would fit. It's sitting in a good middle position.

vapid shell
#

I probably wouldn’t bother with a hybrid setup

#

Iirc, otbr “routes” are “on link” so kernel is likely (tho I haven’t verified) to assume that local otbr is always the best route

#

So if your otbr is overloaded now, probably will still be overloaded with a hybrid setup?

#

Tho if you can get the apple creds you can add it to Ha without any otbr, so no real need at that point

bronze fog
#

So tvOS and HomePod OS 16.5 are probably going to get Thread 1.3 (it's in the beta/RC), which should come out next week. If that's true, how does that change, if at all, the future of the Skyconnect Thread/Matter support and using the same Thread mesh network as the Apple Home devices? My understanding is 1.3 should enable multi-vendor Thread network interop on the same mesh network.

#

Ideally I'd like my HA Skyconnect to join the same Thread network as my Apple hubs so HA can talk directly to my Matter thread devices without relying on the Apple hubs for the RF portion of the comms. My understanding is that's theoretically possible if each router/border router supports 1.3.

#

Or does Thread 1.3 only enable disparate ecosystem border routers to talk to each other but maintain separate Thread RF networks?

junior raft
bronze fog
vapid shell
#

Yeah, unless there is a mechanism we are allowed to use we can’t join any apple thread network. Aiui, apple has not yet given us the iOS entitlement to get their thread network key. It’s possible they will actually approve the request when the next iOS is out. But people already have it working with thread 1.2 (they had to make a custom matter device to extract the apple key)

bronze fog
tacit gate
#

Does anyone know the current dev status on Thread support with SkyConnect in HA (running in docker container)? I dont bother about using SkyConnect for Zigbee, as I already got separate stick for it. Wanted to play around with Thread, Matter and HA if possible. Workaround are also welcome to get something up and running.

vapid shell
#

So you need to install OTBR somewhere

#

It’s not really a ha dev issue

#

If you have a properly configured OTBR then it’s like having a HomePod or Amazon echo and Ha can use it already

nova swan
spice grove
#

just got an Aeotec branded SmartThings hub -- my Home Assistant 'Integrations' area discovered the "Thread" portion of the hub, and asked me to setup. It's now asking me to "...Provide URL for the Open Thread Border Router's REST API..." -- I have the IP address of the Hub, but don't know the URL convention for the OTBR REST API URL. Anyone?

#

if I go to the IP followed by :8081, I get:

{
"ErrorCode": 404,
"ErrorMessage": "404 Not Found"
}

vapid shell
#

It’s not an OTBR

#

You need the “meshcop TLV”for the device

#

It might not show it anywhere

#

If you can add a matter device to it through your phone you should be able to share it to HA without adding the BR to HA at all

spice grove
#

I know some of those words

#

Thanks @vapid shell I’ll look into this from that angle

#

This all started because I ordered these Juno Connect Downlights (zigbee) that wouldn’t work well to save their lives when bound to zigbee2mqtt, ZHA, deconz, nothing… so I call Acuity (who makes these Downlights) and they claimed these will only work with specific hubs (e.g. Aeotec SmartThings, Alexa Hub, and one other)… so I caved and got this Aeotec thing, which I’ll then integrate into my HA, but when I saw this hub get discovered by HA and ask me to set it up via the Matter integration, it made me wonder if I can use this Hub and keep it all local and not need cloud connectivity on the Hub, which I’d prefer

#

Of course Philips Hue came out with comparable canless Downlights, but I already have 8 of these Juno Connect ones, and I don’t feel like swapping them with expensive ass Hue canless Downlights

#

#endrant

tacit gate
vapid shell
#

Good job 👍

quiet stirrup
#

New eve thread devices, eve flare and eve shutter switch. Interesting

#

*this was known through the new eve app update

spice imp
#

Can someone tell me if its currently possible to comission a thread matter device with a phone with a custom br? Or do i need to have a Apple or Google br? I know there are other ways to commision devices, but is this case supported on any platform at the moment?

bronze fog
spice imp
vapid shell
#

If it’s a pre-matter thread homekit device then you can pair it to ha with Bluetooth, then HA can send it the thread credentials directly. With no phone app at all.

#

If it’s a matter device and you have a google phone you can use the Ha app. It will use a google API and load the thread creds onto your phone, which will push them to the device

#

Right now you can’t do similar with apple - there’s app changes needed and an entitlement needs to be granted first.

#

I don’t believe you can pair a matter device with your own BR without an android app right now

spice imp
#

But isn't it possible to comission using the matter container directly assuming you have bluetooth forwarded to it?
Is it apple being slow with grating the entitlements at the moment? I can see google has not implemented the function to commission thread devices using their home app on ios either

vapid shell
spice imp
spring bramble
# spice imp Yeah, the best Way would probably be to implement it into the matter sdk so it w...

No, Matter works differently and does the initial commissioning over bluetooth. You can use your phone's bluetooth for that.
So on your phone the phone's apis will be used to do the initial bluetooth handover of credentials after which the connection works on your local wifi/thread network.

Except we are not yet ready with a OTBR only (so no google and/or apple BR present) setup but that will come soon

spice imp
spring bramble
#

exactly out of scope. Some nice idea somewhere in the horizon would be to use HA bluetooth proxies for this but that is a really wild idea still

bronze fog
vapid shell
#

The "OTBR only" case is also when you have an iOS device but no Apple Thread network at all

bronze fog
fierce dust
vapid shell
#

have you bind mounted the dongle and configured OTBR to use it?

fierce dust
#

Ive run the following docker command, but if theres more that I need to do I am not aware of it

docker run --sysctl "net.ipv6.conf.all.disable_ipv6=0 net.ipv4.conf.all.forwarding=1 net.ipv6.conf.all.forwarding=1" -p 8082:80 --dns=127.0.0.1 -it --volume /dev/serial/by-id/usb-Nabu_Casa_SkyConnect_v1.0_54d7510bf025ec11a55e63c0a8a1c857-if00-port0:/dev/ttyACM0 --privileged openthread/otbr --radio-url spinel+hdlc+uart:///dev/ttyACM0
spice imp
#

Not sure if that’s the problem, but maybe worth a try

#

Look at the options in step 8

fierce dust
#

hey that did it! changing that last bit to: spinel+hdlc+uart:///dev/ttyACM0?uart-baudrate=460800 got it working

fierce dust
#

Any id what the rest API URL would be to add it to HA? lol

spice imp
fierce dust
#

yes, but that didnt work for me. localhost:9091 or 10.0.0.5:9091 doesn't do anything, while going to http://10.0.0.5:9091/node does return node info

#

This error shows up in the HA logs whenever i try though
Received error: [Errno 19] No such device, transport: <_SelectorDatagramTransport fd=65 read=polling write=<idle, bufsize=0>>, socket: <asyncio.TransportSocket fd=65, family=AddressFamily.AF_INET, type=SocketKind.SOCK_DGRAM, proto=0, laddr=('0.0.0.0', 57011)>

spice imp
#

How did you start home assistant? With docker? If yes, then you can probably connect trough the docker network, so “containername”:9091/node . Otherwise you need to forward the port to your host from the otbr container. The address you send doesn’t look like a standard docker network ip.

fierce dust
#

It’s not, HA is in docker on host mode, the 10. Is the address of the host.

vapid shell
#

You don’t need to though, you can set up your thread network yourself and then use the “ot-ctl dataset active -x” command to get the TLV, which you can add to HA through its thread panel. That’s all the integration does anyway.

#

Then next time you try to add a matter device with android, HA will sync that TLV to android. And your phone will set it to the matter device.

fierce dust
#

Cool I’ll give it a shot once my thread device arrives Monday

feral leaf
#

Anyone got recommendations for smart outlets that work with thread and home assistant?

#

Home assistant doesn't seem to be as well marked on products as google, siri, and alexa

quiet stirrup
#

Well, most devices now are getting a matter update

spice imp
delicate drum
#

Onvis

gentle mica
# spice imp <@849830549634809937> this is maybe relevant to your question in the matter chan...

Thanks for the pointer! When I first setup my Eve Shade, it was popping up as an option to add with HomeKit Controller, but no longer is. When I tried (I assume it was trying to via Bluetooth), it was getting an error message about not having an available slot or something of that nature. I'm wondering if I need to somehow get it in a pairing mode or something again to where it advertises itself again? I've never worked with HomeKit stuff before so I'm still learning. Was excited to get this shade due to the advertisement of coming soon Matter support, but I'd love to get it connected to HA right away if there is a way. I'm wondering if it is just too far from my RaspPi for Bluetooth without any repeaters/proxies in between? I think my biggest hang up right now is figuring out how to get the shade to show as an option to include via HomeKit Controller again. Wish I understood why it is no longer presenting as an option...

spice imp
gentle mica
#

I can move my RaspPi, temporarily, directly under the shade, and also have a spare ESP32 I can try to setup as a BT proxy. I think I just figured out how to get it to present itself to HomeKit Controller again. I just set the shade to "Transport Mode"/turned off motor and then turned that off again and it is presenting. Now I'll troubleshoot a possible range issue. It does have several walls away, so I'm guessing that may be the issue. Thanks again!

spice imp
gentle mica
# spice imp if you get some full thread devices, aka thread devices that have permanent powe...

I got it working!! I really appreciate your help! I setup my first ESPHome BT Proxy and it then connected up. Once connected via the HomeKit Controller I was able to click the button to switch it to Thread and then shutdown the Bluetooth proxy! I'm really pumped that this works even before the Matter upgrade was released! Now to order them for the rest of the house! No more free shows for the neighbors! 🙂

spice imp
#

also didn't know that you are able to commission homekit thread devices directly to ha before i saw it on discord

#

Its not that clear in the documentation, not sure how to formulate it better though. The problem is probably that they mention only apple devices as thread boarder routers

vapid shell
#

Yes

#

When I wrote the docs, the other method hadn’t been implemented yet

#

The update to add this way is sat on my iMac waiting for me to have time to finish it

#

Along with 3 PRs that I need to review 😂

vapid shell
#

I think for one guy he had to have in 10cm away because he didn’t have a real antennae

gentle mica
#

I had mine directly under the shade (about 4' from the shade antenna) for what it's worth...

vapid shell
#

That’d do it 😂

spice imp
vapid shell
#

On phone with toddler so can’t check on how good a draft but there /was/ a couple of months back

spice imp
vapid shell
#

Ah no I literally mean I have a draft written on my desktop. It’s not online anywhere.

quiet stirrup
#

Anyone know how I can get Eve room with thread into home assistant?

digital salmon
vapid shell
#

If the apple way, you need to make sure your HA and Apple TV/HomePod (all of them with a thread radio) are on the same vlan. If you are not using HAOS there will be manual configuration to get ipv6 working properly.

#

If the OTBR way, 90% of the problems with the initial Bluetooth pairing are range. You’ll also want to do a hard reset if it’s already connected to a different thread network and you want to migrate to OTBR.

quaint osprey
#

I have an HomePod Mini, but no Thread dongle to Home Assistant yet.

In the future with 1.3.0 will I be able to use HomePod Thread instead of buy a new Thread USB dongle to HASS?

#

I mean, will I be able to use HomePod thread network even without no Thread dongle to HASS?

quiet stirrup
#

Not to my understanding, personally matter over thread worked, but without a dongle I was never able to see thread only devices

outer relic
#

Hello everyone, actually i'm working on a project smart home i'm using home assistant on raspberrypi 3 and Pic18F45k22 (microcotroller), so i want to keep a communication between this two system ( for receive and read data), what do you suggest to me , using esp32 or i2c protocol ? Thank you

quaint osprey
quiet stirrup
#

Unless you have a HA yellow, if not your out of luck I believe)

#

(Unless you buy a dongle ofc)

vapid shell
#

Unless I’ve misunderstood the question

quiet stirrup
#

He had a HomePod mini, will he be able to connect to thread devices

vapid shell
#

I have been using a pair of HomePods and no thread dongle for over 6 months now

#

It’s what homekit over thread is primarily developed against

#

And matter over thread currently only works with apple border routers if you have an iOS phone AIUI

#

With the latest apple BR updates I’ve also heard people are going back to HomePods because for their homes they are now more stable than a dongle

quiet stirrup
#

If you don’t have the thread dongle, how does it communicate with thread devices? Through the homepod over wifi?

vapid shell
#

Yes

vapid shell
#

Even a thread dongle

#

With BRs, they send icmp6 broadcasts to your LAN that announce they are the router for an ipv6 subnet. Any device on that LAN that had working ipv6 can now talk to devices on that thread network.

#

With a thread dongle that’s still how it works, OTBR sends those icmp6 messages to your network.

#

But if your HA runs locally, on same box as your thread dongle and OTBR, the TCP and UDP packets don’t come in from your LAN they come from localhost. But as far as the thread stack is concerned it could have been from a different device on your LAN entirely

#

Thing I’m looking forward to: Future versions of thread have something called TREL that uses your LAN/WiFi as a backhaul (as it’s faster and has more capacity). So you might be running HA and OTBR locally but the packets could be sent to another BR over WiFi and then that BR sends them over thread. This will reduce thread partitions as a source of connectivity issues).

#

The thing that is a problem for us with Apple BRs is accessing the thread network key. Now this is not necessarily a big deal. You don’t need the thread network key to talk to a device on thread, because your BR does know the key. It’s like having a camera on WiFi and your HA on Ethernet. Your HA doesn’t need the WiFi password.

#

The problem is telling the camera the WiFi creds in the first place. Because apple decides the thread network key, we don’t know it, so we can’t join devices to it ourselves. But if the device can join the network we can have packets routed to it.

#

Homekit over thread (either by design or by luck) doesn’t forget it’s thread network when it’s unpaired. So you can pair a thread device to homekit, unpair it, then pair it to Ha. iOS will add it to thread. HA can use it over the existing thread network.

#

Matter also has helpers in core iOS and Android that can add a device to thread for us, then we can pair over ipv6.

#

So when is it a problem? When you have an android device, an apple BR and a matter accessory. We don’t know the thread key so android can’t commission it for us.

#

When you have a homekit over thread device, and apple BR, but no iOS device. We don’t know the key so we can use our own Bluetooth code to provision it.

#

Both of those are edge cases. Try to get an apple BR running without iOS.

#

That leaves running OTBR and Apple BRs on the same thread network.

spice imp
vapid shell
#

thats exactly what some people have already done

#

IIRC, i believe one of the matter contributors has an OTBR and Apple BR hybrid mesh after doing it

#

but last i heard, getting the entitlement needed wasn't a complete dead end

#

just slow compared to open source

#

i think the entitlement is also needed for if you have iOS but no Apple TV and no HomePod (so we can push the OTBR thread cred into iOS?), so we need that "angle of attack" anyway

spice imp
#

Yeah okay, I can just imagine apple being really hesitant giving the entitlement. It’s hard enough to already to create a stable thread boarder router. Giving out the operational dataset would be adding another variable that is out of control for apple

vapid shell
#

Yeah, they've made it pretty clear that its only for people making border routers

#

But, its not like HA/Nabu Casa is an unknown. They are in the matter alliance. They do have a shipping product that acts as a BR.

#

I wouldn't be surprised if there were other requirements to make sure your secret keys don't end up on pastebin.ru etc

spice imp
#

Yeah, but isn’t it two different teams? Considering how much apple the contributed to the development of the matter sdk it’s surprising to see that they first now are upgrading their thread br to 1.3

vapid shell
#

I mean i imagine you have to convince a lower paid 3rd team that you are allowed to even ask the thread team for the entitlement

#

They aren’t going to give it out like conference T-shirts for sure

#

But it’s not like a 50 user open source project is asking either. It’s not free to be in the alliance. They have calls with google about thread.

spice imp
#

😂😂 probably not

#

It’s probably just like in any other big company, a lot of bureaucracy. So at some point HomeAssistant will probably get the entitlement.

#

Kind of seems like Google doesn’t have it for their Google home app either at this point

quiet stirrup
#

I get the hesitancy on apples behalf

#

This is new tech, and the security risks that can come along with it is crazy

#

Along with the fact that it’s only been a few months of consumer end devices being released/updated

vapid shell
#

Exactly

#

1.3 graduating to stable is probably an internal gate as well

spice imp
quiet stirrup
spice imp
#

It’s not much different than giving a wifi password out.

#

Part of matter is that the traffic between your devices actually is encrypted, so you can’t do anything with the network key to your thread network

#

I think part of the problem is more that if you end up allowing random devices and so on that don’t act like you expect for whatever reason. It might cause problems with stability and reliability.

vapid shell
#

I’d definitely want apps accessing my WiFi password to be limited to be honest.

#

So you know in computers the user is generally the enemy, honestly.

#

If you give a tech savy person a foot gun, they will shoot themselves in the foot and then probably in the hand.

#

So if Apple is taking it slowly and carefully with Thread till they understand real world use cases better, thats great

#

I don't want my key on pastebin.ru because they rushed 🤷‍♂️

#

If they are doing it to be anti competitive, screw them

#

If they replicated what they do for wifi, then you'd get a system modal asking if it was OK to share it with whatever device. That might be OK. But people don't understand Thread very well. They don't understand its similar to giving out your WiFi password (in so much as there are cases where a thread device could SSH into your HA instance over ivp6, etc). They don't understand what is Matter or Thread etc. And in Apple world, they largely don't have to understand it, because its all managed for them.

#

and Apple's approach to protecting key material seems to be to default to over cautious rather than under cautious

spice imp
#

Its fair enough to be overprotective, but at the same time they are allowing devices that arent’t signed with official certificates to be comissioned. But i might go a bit off topic here.

#

In the end I just hope HA gets access to the credentials

#

And that Matter is not ending up being an empty promise because of things like there

vapid shell
#

Yes

#

I mean we can’t speculate about this because there is an absence of information on their actual motives

#

The entitlement requirement could have just been an overzealous security guy and now the App Store review team are defending it to the last and there’s actually no /real/ decision or requirement

#

Large organisations be dumb like that

#

But given they have things like lockdown it could be their threat model is not our thread model

#

Or you know. A certain Linux company used to delay patches going upstream to give their desktop product an edge, why wouldn’t others try the same trick.

half bluff
#

Do we know what channel # of thread apple uses?

fierce dust
#

So Ive been messing with a Matter/Thread nanoleaf bulb to play with the technology and so far the Matter side of things has been great. I just hit add device on my phone and it showed up in HA working fast and well.
But HA joined it to the Apple Thread network, not one made by OTBR and my skyconnect.
Using the upstream OBTR docker, not the addon because im not using supervised, im not sure how to connect it really. Also I dont think the thread networks are surviving container restarts. I probably have a mount a volume but no idea where to mount what inside the container.
Anyone have any advice or links to documents I can try to use to figure this out?

#

Or join the OTBR to the Apple thread network? I have no problem with that, but Id like the skyconnect one to be one so that if wifi isnt working and HA cant talk to the Apple BRs it can talk to the Skyconnect one thats connected via USB

spice imp
spice imp
#

I just bought an android device as a workaround 😂

fierce dust
#

Oh so when I added the Matter device using my iPhone, iOS magic in the background joined it to the apple thread network then?

spice imp
#

Yea exactly

vapid shell
quaint osprey
spice imp
quaint osprey
#

😓😞

half bluff
#

Does anyone know how to force OTBR to use a different channel rather than the default one?

rapid umbra
#

New Nanoleaf Essentials firmware for Homekit over Thread

#

1.6.49

2023-05-26

What’s New

Adds a gentle 0.5s ramp when turning on / off
What’s Changed

Fixes an issue where Thread networks could stop working with many Border Routers
Fixes an issue where devices could become non-responsive on Thread
Fixes security issues

#

That half second ramp feature has me tempted to update but the amount of work it takes to unpair, update and re-pair is ughhh

half bluff
#

Wow I am suprised they added the ramp up

half bluff
#

Anyone know how to force thread to use its dataset?

#

I have it setup in my HA but for some reason it states as false when “thread_credentials_set: false”

fickle mantle
half bluff
#

I am on channel 25

#

And I have the active dataset but when I ask the console from the internet it states the thread_ceredentials_set: false

fickle mantle
#

BTW I should have noted, that this is in regards to Matter Server getting the Thread dataset.

half bluff
#

Yeah that’s the one I was talking about

#

I followed that

woven oxide
#

I'm having trouble keeping HomeKit thread devices (Eve Switch) connected to my skyconnect thread network... after a few hours they go offline/unresponsive to both HA and Homekit. Matter thread devices work great, though. Has anyone had any long-term stability with this kind of setup yet?

vapid shell
#

My Eve Thermo and Eve Energy connected by HomeKit over Thread by a HomePod have been stable since the last HomePod update.

#

Don’t have an Eve Switch for conparison

half bluff
#

I have found that apple border routers use channel 25 just for peoples information

woven oxide
quiet stirrup
#

they are on the latest firmware for both my tv and homepod

bronze fog
#

My Eve Matter devices on TVoS 16.4 and 16.5 have been ROCK solid

digital salmon
# bronze fog My Eve Matter devices on TVoS 16.4 and 16.5 have been ROCK solid

How many devices? Where is your Thread network (Apple, Google, HA…)?

Since xOS 16.5, EVE firmware 3.2 (21 devices) and Nanoleaf firmware 3.5.10 (2 bulbs) my Matter/Thread network is also stable/reliable now. Before all these releases I had reliability issues every now and then.

I have only 1 AppleTV and no further Thread Border Routers.

9 of my Matter over Thread devices are paired to HA.

My EVE HomeKit devices were always rock solid. No restart needed ever.

bronze fog
digital salmon
#

With earlier xOS versions I was stuck at round about 15 Matter over Thread devices. But now I am slowly expanding…

autumn merlin
rapid umbra
#

The firmware update is done via BLE so I don’t think it’s possible at the time

#

Gotta unpair, upgrade and re-pair

autumn merlin
sick swan
#

Someone claimed it should be possible without using the Nanoleaf app? 🤔

autumn merlin
half bluff
#

You just add the bulbs from the Nanoleaf app and you can upgrade the firmware

#

Even if they are connected to a thread network

#

Click manage devices add new essentials and search it then just click the bulb that shows up and show the matter code and then firmware upgrade

autumn merlin
half bluff
#

Ahh I see yeah it might be different

worldly portal
#

if i have an existing thread network using apple based border routers and i want to pair some of the thread devices to home assistant instead of homekit, do i need a separate border router or can i just use the devices on that network?

#

i’ve read that i can remove them from homekit and then quickly add to home assistant. but it’s not clear if they would then lose connection to that thread network

worldly portal
#

i tried it - the device connects, however i'm not sure if it's BLE only now or still using thread. however it's super slow to respond

autumn merlin
#

FYI the only way I can get this to update is remove the device, add it to the nanoleaf app, update, remove and re-add to HA.

normal arch
#

I was able to update my homekit thread nanoleaf bulb firmware via the android nanoleaf app, while the bulb was connected thread. I added it to the app, it connected via BLE and performed the update.

vapid shell
#

From what I remember you can only use the android nanoleaf app to do the update

#

The iOS one must use homekit, so you have to disconnect from HA first

#

At least that’s how it was when the homekit stuff was written a year ago

vapid shell
# worldly portal i tried it - the device connects, however i'm not sure if it's BLE only now or s...

What you said is correct. From testing, when you remove a device from the Apple Home app, it stays on the thread network. This is tested to work with a bunch of Eve, Nanoleaf, Wemo and airversa devices. If HA can see the same device by thread and Bluetooth it should prefer thread. You should be able to see the thread status of TH device on its device page, and you can double check which transport HA is using in the “download diagnostics” JSON.

worldly portal
#

so if it says thread status: child, that means it's using thread?

vapid shell
#

In testing it seemed like my eve devices weren’t available over BLE if they were on thread but there’s no public spec so it’s unclear if that’s guaranteed

#

The diagnostics download is definitive

worldly portal
#

the wemo switches just seem to have worse performance then - they're slow in any config I have tried

vapid shell
#

Have you checked the diagnostics file?

worldly portal
#

the diagnostics file is where is says thread status child. but wasn’t sure if there’s something else to look for in that file, it’s quite big

vapid shell
#

Or AccessoryAddress / AccessoryPort

worldly portal
#

ah, ok, I see "Connection": "BLE" there

#

I guess it is BLE :/

#

so I probably have to disconnect it, then connect to homekit, then disconnect it again, then re-pair with homekit controller? or is there a better way to get it back on thread?

vapid shell
#

Then use the Eve app, you should be able to find the thread status for the device in that app.

#

Make sure it’s showing as child their, then remove it again.

#

Then try pairing it again with HA

#

It tries thread before BLE, so if it still doesn’t work it might mean your HA is having intermittent problems with ipv6 or zeroconf.

#

Or the other thing is I’ve seen some battery powered devices power down their thread radio.

#

So when pairing Eve Thermos I actually press the temperature up/down button to wake them, then immediately start the pairing process

worldly portal
#

oh, maybe I have to do the same changes on my ha box that I did to get the matter server working. ideally i could pair a thread border router to my apple thread network and then IIUC the open thread border router has a rest api for home assistant to use?

vapid shell
#

No to open thread BR

#

With homekit over thread, the thread credentials are sent over Bluetooth. For OTBR we know the creds, so can do that. For apple BR, we don’t so can’t.

#

In order to add an OTBR to apples network we need the creds. When we have the creds there is no role for the OTBR, we can write the creds directly.

#

The OTBR rest api is purely used to create and manage thread networks on the OTBR. It can’t talk to or commission thread devices on our behalf. The actual comms to the device are the same for OTBR or Apple.

worldly portal
#

hmm. ok. unfortunately my ha box is on a separate vlan from the thread network right now and that’s probably the issue. I kind of need a hap to matter proxy or something to avoid moving the ha server

vapid shell
worldly portal
#

or ndp proxy - which seems to do route propagation of sorts for ipv6

#

macvlan? is that specific to containers?

#

i guess i can bind a second interface to the same ethernet port

vapid shell
#

Technically not, but I’m not sure what the use case would be

worldly portal
#

i’m running ha on a raspberry pi - no containers

vapid shell
#

It’s a kernel driver that lets you stack virtual nics on top of another nic

#

So each container can have its own MAC address on a layer 2 network

#

But like having a bridge but less moving parts and it’s layer 2 not 3

#

If bare metal pi you’ll have to set up multiple vlans on a single port then

#

Thread is designed for consumer ipv6 networks, you are on your own trying to work round their flat L2 assumptions

worldly portal
#

i guess a super simple hack would be connect the wifi to the iot vlan

vapid shell
#

Yeah

flint zodiac
#

Commissioning Matter/Thread devices with the iOS app getting added to a Homepod regardless instead of say my Yellow is "by design" due to Apple and so forth?

vapid shell
#

Yes

flint zodiac
#

Guess imma get a cheap AF Android phone.

spice imp
#

you can add everything to HA with matter that is using thread. So unless you have some thread homekit devices or something similar there is no reason not to use apples boarde router

bronze fog
#

@spice imp Exactly. I have a number of Thread/Matter devices (All Eve), and they work perfectly via ATV Thread and with HA. Rock solid.

half bluff
#

I think the only reason before to use yellow otbr was because of thread 1.3.0 but now that apple uses it as well no difference

vapid shell
#

Before HAOS 10, OTBR bypassed ipv6 issues that we were having with Apple. Again less reason now.

#

That might change again if OTBR has TREL before Apple, and you have multiple OTBRs.

bronze fog
#

I have two ATV 4Ks with Thread and tvOS 16.5. My Eve thread/matter devices are working flawlessly with HA via onboarding in Apple Home app. I have an unused Skyconnect. Is there really any benefit of down the road using the Skyconnect + 2x ATVs on the same Thread network whenever that becomes possible when Apple allows Thread credential sharing? I guess HA could then directly control Thread devices but doesn't seem like that buys much.

vapid shell
#

Yes, iOS 16.4 and 16.5 seem to have fixed lots of bugs. Compared to last year, where I wanted to ditch apple thread asap I’m no longer in any rush.

worldly portal
#

there is an api in apples docs to get the thread credentials, but apparently you need an entitlement to use it. has anyone successfully applied for the entitlement?

#

I tried, but they responded that my use case was invalid

bronze fog
#

@worldly portal Apple Entitlements were discussed a few weeks ago. Might search ...don't recall the outcome.

#

I don't think the HA developers applied for the entitlement, but I could certainly be wrong about that.

vapid shell
#

Iirc they have applied a few times now

spice imp
vapid shell
#

Nice

spice imp
digital salmon
spice imp
digital salmon
#

This is really cool! I really need an OTBR in my barn and I don’t want to place an AppleTV or a HomePod there… 😃

half bluff
#

Question. If Apple eventually down the line could link the thread network with home assistant on let’s say channel 25. Would the zigbee channel 25 on the multi protocol of yellow/sky connect interfere with the thread network at all?