#thread-archived

1 messages · Page 2 of 1

vapid shell
#

guess it is time to learn buildroot

hoary harbor
#

\o/

lusty wind
#

looking for suggesting for a 0-10v dimming controller, would love if it had thread.

visual badge
#

Do I need a thread dongle on my HA box in order to detect other TBRs that are already on my network? Or should HA be able to find them over LAN?

vapid shell
#

it depends on what you are doing. Right now everything is still in an early phase so somethings work, other things will work eventually.

#

Eg you can’t actually have a OTBR in the same network as a HomePod yet.

#

If you are using matter the setup flow uses iOS and Android APIs to get the device onto the mesh so you can only use BRs your phone knows about and has keys for.

#

You can do it either way with homekit, pair directly to an OTBR or use iOS to get it to use your HomePods.

#

Right now, using multiple BRs is not really advised. For one thing, it opens you open to a bug where HAOS doesn’t expire ipv6 routes so you end up with HA trying to connect to the mesh via imaginary ip addresses. This is going to require operating system fixes.

uneven axle
#

anyone have a suggestion what I should enter as Url to connect the HomePod?

hoary harbor
#

Baby's first buildroot

visual badge
# vapid shell it depends on what you are doing. Right now everything is still in an early phas...

My homekit-over-thread devices are paired to HA and are showing as Bluetooth-only right now

the only TBR I currently have is a SmartThings hub v3. I can find it advertising a meshcop network using a bonjour service browser or dns-sd, but my HA instance on 2023.3.b1 can’t find it and the Thread integration setup is just blank

Is that a bug, or do I need a skyconnect? Happy to file a bug report but just not sure if it’s expected or not

Also not sure how to add credentials for it into my iPhone?

vapid shell
#

if someone builds the ios code to sync thread connection details into HA, it will become your "preferred" network and that prompt for a url will disappear.

#

and if you do connect your homepod it will just cause suffering anyway, because we are still working on things like e.g. NetworkManager never releasing old routes, and that makes your devices unreachable.

uneven axle
#

hehe, ok thanks, Ill disable the integration for now then. Had realized it was 'on' at all in the first place, and only noticed while in the Beta now

devout iris
vapid shell
# visual badge My homekit-over-thread devices are paired to HA and are showing as Bluetooth-onl...

Right now you can only move HK over Thread devices to border routers that HA knows the creds for. Right now, that means without updated companion apps the easiest way is with a SkyConnect or HA Yellow, because the "happy path" for those will lead to a working OTBR running on your HAOS, with its creds synced directly from OTBR into HA. Other BR's need companion apps to be updated to sync the connection details from their ecosystem into HA's. I know the work is in progress for Android, but i have not seen any chatter about the iOS version.

vapid shell
devout iris
#

So we could add a companion app section for sharing HK thread data with HA, sort of like how location works todayZ

hoary harbor
#

Some HAP over Thread devices let you pair them with an Apple TBR and then remove them from the Apple Home app without losing their Thread connection. Not sure if that's possible with SmartThings

vapid shell
visual badge
hoary harbor
#

I don't have SmartThings so I don't know the details, but in general you'd connect those devices you want on that Thread network via the SmartThings app, as though you were only going to use them with SmartThings

#

Once a device is commissioned onto a Thread network it's just IPv6

#

It's the commissioning that's the issue

visual badge
hoary harbor
#

uuuuHHHH I'm not sure if all the shenanigans we were doing to push Thread creds over HAP/BLE made it into the live HAP addon

devout iris
visual badge
vapid shell
#

or its been removed since the last nightly i tested

#

or i imagined it

#

i certainly can't find it now ;_;

visual badge
hoary harbor
#

dang, that patch that added a simple service call to send thread info over existing HAP/BLE connection was useful

visual badge
vapid shell
#

right now, interoperability is a lie

#

there is a happy path where OTBR sets up creds and they are available to HA and HA pushes them when you press that button

hoary harbor
#

worth a shot though

vapid shell
#

theres a ok path (kinda sad) where you have homepods and ios and you pair, unpair and repair with HA

#

and right now everything else is a construction site

#

its not buggy, its just not built

hoary harbor
#

the type of person who is into home automation enough to be in the discord for HA doesn't care about "here there be dragons" signs 😉

visual badge
hoary harbor
#

I don't know of such an app even existing currently

#

Wanna become an iOS dev? 🙂

visual badge
#

Haha I do have everything set up to compile for iOS, just don’t know enough to actually get things done

Maybe apple has a sample app for device manufacturers though…

vapid shell
#

let us know if you find it

hoary harbor
#

Be the smart cow

visual badge
#

Seems like there’s a straightforward retrieveAllCredentials method… also a storeCredentials method for my SmartThings situation

Maybe worth letting the android Path pave the way first?

#

I do have an old pixel (and feel more confident with android dev) maybe I can manually add thread credentials there, have them sync into HA, and somehow move my HAP/BLE devices that way?

devout iris
#

But they are also tackling commissioning Matter devices at the same time.

#

Also - notice that the iOS framework also support storing credentials.

#

func storeCredentials(forBorderAgent: Data, activeOperationalDataSet: Data, completion: (Error?) -> Void)

boreal crescent
#

It's not related to Matter otherwise

#

The frontend might add a button to import Thread without starting Matter commissioning in the future, but not in 2023.3

hoary harbor
#

Don't pull an Apple and make it all work automagically except when you have to do any stage of the process in a way other than was planned for 😉

#

I'm gonna find that old patch that added a service call to commission Thread credentials over HAP/BLE because I think that was hugely useful

boreal crescent
vapid shell
#

@boreal crescent cheers for your work on the Android app! A thread sync button sounds like a great idea, we already have non-Matter Thread integrations in HA and right now we can only get them onto SkyConnect or HomePod's easily 😦

visual badge
hoary harbor
#

Yeah, it won't just apply cleanly to current code. But if I remember right it wasn't horribly complex

vapid shell
#

the API in aiohomekit land expects a meshcop TLV, which it re-packs as a Homekit one.

#

all we really need is a service call to add the thread creds to the thread store

hoary harbor
#

Oh yeah, I see your comments on github pull #148

vapid shell
#

if user doesnt have an active border router it should start using whatever you inject there as the preferred router

hoary harbor
#

So really that old patch is totally irrelevant now that the thread component exists to store the dataset

vapid shell
#

yeah

hoary harbor
#

These are some smart architectural decisions

#

You guys seem to know what you're doing 😉

vapid shell
#

whats still up in the air is what to expose to the user, like them manually copying around TLV's is crrraaapppy, which is why we need to companion apps to sync. but thats oversimplifying things a bit, you have to be careful about permissions dialogs, you can't just pull the full set necessarily

hoary harbor
#

It's a breath of fresh air to read through good Python code after trying to dig into NM. That was crazy

#

And yeah, forcing users to copy around TLVs is bad. But so is outright preventing it for us power users

vapid shell
#

i tried to unpick the NM code to get the existing route (the bit that was giving me the error i mentioned) and felt like i was reversing a bunch of java

#

i have a lot of faith/respect in/of the GLib ecosystem, but it does not parse easily sometimes.

hoary harbor
#

Yeah, all those ancient C projects might as well be written in totally different languages with all the customizations and automations and toolkits they've built up over the years

vapid shell
#

no, the hard bit was hidden in aiohomekit

hoary harbor
#

This is actually immediately useful to me for re-pairing my Nanoleaf bulbs onto my SkyConnect

#

So I'll hack something together pretty quick

visual badge
#

Im still confused about if my SmartThings TBR should have been picked up by HA or not

I don’t have it’s credentials on my iPhone, but I CAN see it on my network

hoary harbor
#

That's a question of whether the smartthings app pushes its Thread info into iOS

visual badge
#

Gotcha so it is expected that only thread info available to the mobile device shows up in the HA Thread integration

I was confused because I can definitely attempt to launch the thread integration from web, and I can see the SmartThings hub advertising a meshcop thing over Bonjour/mdns

#

So I wasn’t sure what the discovery mechanism was

vapid shell
#

so if the HA Thread integration can't see it, bonjour/mdns to your HA is broken

visual badge
#

Any way to test that out/repair it? It’s definitely discovered plenty of other wifi devices before (eg chromecasts)

vapid shell
#

its usually VLAN hops or WiFi filtering that upsets things

#

or IGMP snooping

#

(sometimes it needs to be on, sometimes off, depending on the weather)

hoary harbor
#

Well hold on

#

The info from bonjour isn't sufficient to commission a new Thread device. It doesn't contain the full Thread dataset with network key and such

visual badge
#

Right, so does HA just ignore those devices right now? Would be nice to see a “Cant commission without credentials” or something

hoary harbor
#

You're asking if HA is or should be aware of other Thread networks based on the presence of _meshcop in mDNS?

visual badge
#

Yes exactly

hoary harbor
#

Once a device is actually on a Thread network it broadcasts its own _matter._udp or _hap._udp

#

Okay yeah, as far as I'm aware HA isn't paying any attention to _meshcop of other TBRs. I'm not the maintainer/developer of that though, just a fellow user

vapid shell
#

it is

hoary harbor
#

^ Ignore me, talk to this guy

#

Everything is changing so fast on this you gotta get it right from the source

visual badge
#

Lol glad I’m not the only one confused tho

vapid shell
#

the thread integration is now triggered at the sight of a BR, because you might have HA devices connected through a BR that HA doesnt manage

visual badge
#

Can I ssh into my HA and run anything to check mDNS?

vapid shell
#

so can you share a screenshot of your thread panel?

visual badge
#

It’s just blank

vapid shell
#

how blank

#

to you its just blank, to me there might be some clues about the state its in from the type of blankness

#

alternatively, can you post your "thread diagnostics" (its in the ... dropdown on the thread panel)

visual badge
#

Ah ok - I don’t have permissions to upload here and on my phone atm but I’ll get something ASAP

#

Also, what “thread panel” do you mean specifically? Add Integration -> Thread? Or is it somewhere in settings?

vapid shell
#

Integration -> Thread, click on configure

visual badge
#

OH. I’m dumb. It shows SmartThings in there. I hadn’t manually added it or seen it in the Discovered section, so I assumed I had to manually add it

#

Shows it as “1 border router”

vapid shell
#

huzzah. and presumably it says you don't have a network or you don't have a preferred network?

#

and theres an add border router button? but that asks for a url that you dont have?

visual badge
#

Exactly

#

Working As Intended

vapid shell
#

good

#

working as intended.

visual badge
#

If I somehow get credentials for that border router into HA (maybe via this #thread-archived message )

Should I be able to get my HAP BLE devices into there from HA?

vapid shell
#

if you have HAP BLE devices and we are able to import the thread creds into your thread data store, then the "provision" button on the HAP BLE device should just work

visual badge
#

Gotcha! “Thread data store” is mobile only right?

vapid shell
#

if you send me the diagnostics later i can check your border router looks healthy - it can be visible to discovery, but not sending out the right ip6 packets, which is why we added the diagnostics report

hoary harbor
vapid shell
#

the thread data store is part of your HA server

hoary harbor
#

Just curious--not in the same position

vapid shell
#

that URL is for the OpenThread Border Router API

#

if you give it one, it fetches the thread creds from it or if there aren't any, it makes a new thread network and syncs those creds instead

hoary harbor
#

Ahhh

#

The pace of development on this is crazy

vapid shell
#

if you plug in a skyconnect, it triggers the multipan version of the OTBR addon to be installed and then adds the otbr integration with the url already set, which triggers a new network to be made. which is what i call the happy path.

hoary harbor
#

That also explains why the Thread integration just loops for me. 🙂 I have a skyconnect but my OTBR is on its own Pi

vapid shell
#

aside from a glitch migrating users from 2022.2 to 2022.3, people with skyconnect's and yellows should just be able to immediately pair HK BLE devices then mash the "migrate to thread" button and it "just work"

visual badge
vapid shell
#

i've not done any range tests with my skyconnect so i can't tell you what that will be like haha

#

it is running my prod zigbee network which reaches to all corners of my house

#

and the aqara sensors swear they are connecting to it directly

#

from outside

visual badge
#

Nice! I’ve got z2m with a TI chip rn but maybe worth consolidating? Not sure haha

#

Hopefully I can supply the SmartThings hub credentials via whatever service @hoary harbor is thinking of cooking up

hoary harbor
#

You guys have really been planning ahead. Knowledge of multiple datasets built right in. And I remember balloob or someone mentioning some eventual process to combine/reconcile them into one Thread network

#

brb making a donation to HA

#

I love this crap

#

Thread datastore add via service call

hoary harbor
visual badge
#

I have the standard name/key/channel/pan/extpan for my thread border router

Is there a simple tool that lets me generate a TLV from that info?

sand sparrow
#

Another day another try, I have SkyConnect all set up and happy. I moved my NL45 by Nanoleaf to to Thread and is saying Thread Status Router but it's still using BLE to talk to my lamp not thread

serene prawnBOT
#

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

visual badge
#

Would appreciate the script if it’s still handy!

sand sparrow
#

victoraperez 4373 I converted your

hoary harbor
devout iris
#

Hmm. I can't get any of these Nanoleaf A19's to pair using BTProxy. They are identified immediately, but then pairing bombs out:

#

An unhandled error occurred while attempting to pair with this device. This may be a temporary failure or your device may not be supported currently: Bluetooth GATT Error address=DD:FB:F6:AA:94:89 handle=40 error=133 description=Error

visual badge
#

Are you trying to pair them via BTProxy and then immediately move them onto thread?

devout iris
#

Yes - can't make it that far. I have paired 4 of them no problem with built-in BT on the Pi. But BTProxy refuses.

#

Of course bringing 40 bulbs down to the server closet so they can pair is not practical...

#

So BTProxy seems like a good way to do this.

#

I wonder if this is a beta issue...

visual badge
#

Hm yeah, I’m not sure I have anything helpful for you here. I was able to pair my Smartwings Nano (HomeKit over Thread) blinds via btproxy and get them onto my thread network (once I got my thread creds into HA)

#

oh are you on 2023.3.b1?

#

there’s definitely been some thread improvements there, so maybe there are also improvements to the BT flow for thread-capable devices?

devout iris
#

Yeah, that’s the version I’m on - but it seems to have borked ZWave JS UI setup…

vapid shell
devout iris
#

Okay - so I decided to migrate to a Pi4 - ESPHome just couldn't build anything with 1GB - kept running the system out of memory. So I created a full backup and restored to a fresh HAOS build on a Pi4.

#

Unfortunately now the Silicon Labs Multiprotocol add-on fails during startup:

#

Only thing different is it's on a hub on a USB3 port. ZWave and Sonoff sticks are working fine on the same hub though...

quick bronze
#

Are the sticks on USB extension cables?

devout iris
#

Yes.

#

Interesting. Plugged the SkyConnect into a USB2 port on the Pi and now it's working.

#

It was working on the same hub on the Pi3 - of course it was running in USB2 mode.

#

Well - at least OTBR runs now. The OTBR and Thread integrations still won't load.

devout iris
#

Welp, still can't get BTProxy to pair a Nanoleaf bulb. Rebuilt ESP32, moved to Pi4, Verified good connectivity during pairing process. Still the same errors.

#

Gonna try Beta of ESPHome and rebuild everything...

devout iris
#

Nope.

#
[17:03:21][I][bluetooth_proxy:250]: [0] [EB:C5:71:0F:39:4B] Connecting v3 with cache
[17:03:21][D][esp32_ble_tracker:206]: Pausing scan to make connection...
[17:03:21][I][esp32_ble_client:064]: [0] [EB:C5:71:0F:39:4B] 0x01 Attempting BLE connection
[17:03:22][I][esp32_ble_client:141]: [0] [EB:C5:71:0F:39:4B] Connected
[17:03:22][D][esp32_ble_tracker:238]: Starting scan...
[17:03:34][D][esp-idf:000]: W (1044046) BT_HCI: hcif disc complete: hdl 0x0, rsn 0x8

[17:03:34][D][esp-idf:000]: W (1044052) BT_APPL: gattc_conn_cb: if=3 st=0 id=3 rsn=0x8

[17:03:34][D][esp-idf:000]: W (1044056) BT_APPL: gattc_conn_cb: if=4 st=0 id=4 rsn=0x8

[17:03:34][D][esp-idf:000]: W (1044059) BT_APPL: gattc_conn_cb: if=5 st=0 id=5 rsn=0x8

[17:03:34][W][bluetooth_proxy.connection:081]: [0] [EB:C5:71:0F:39:4B] Error reading char/descriptor at handle 0x28, status=133```
#

Every freaking time...

vapid shell
#

Are you using the idf framework for esphome

#

On phone so I can’t search around but there were some version bumps for the idf framework that might help

devout iris
#

No, just beta

#

That didn't work. So I rebuilt it with ESPHome Beta. Same story.

#

On another topic I am still experiencing some weirdness with Multi-PAN/OTBR after a restore to a new machine.

#

Is there an easy way to back up and restore the Thread dataset so I can avoid having to rejoin everything if I delete all of the Multi-Pan addon stuff and start over?

devout iris
vapid shell
#

There is some example yaml in there you can use to force version and platform_version, that’s all you need.

#

I have no idea about OTBR backup/restore, my own OTBR is just a dev env atm so backups haven’t been a priority

hoary harbor
#

There really isn’t anything to “back up” in the zigbee or zwave sense

#

The dataset is just the name, key, channel, etc of your thread network

karmic oar
visual badge
karmic oar
devout iris
devout iris
#

So funny enough, upgrading from a Pi3b to a Pi4 - the integrated BT is enough better that I can pair from much further away. Even though BT proxy is not working to pair, at least I can pair several more areas now anyway. Haha.

devout iris
#

Nice to be able to see the HW Rev on the Nanoleaf bulbs. Now I can confirm that the HW 2.2.5 bulbs are the ones with brighter LEDs.

#

And that you can't tell by the color of the bottom ring. Old ones are white - newer ones are green - but some of the green ones are HW 1.2.4.

#

~~I think the white ones are 1.0.4.~~Some white ones are 1.2.4.

#

So in my collection I have at least 3 different HW versions of the NL45s.

#

Oh - looks like the Nanoleaf app shows theHW version too. Hmm.

hoary harbor
#

Oh dang. Is there a reference somewhere?

#

Of which HW revs exist and their differences

hoary harbor
#

Yeah dang I've got some 2.2.5 bulbs and some 1.2.4

devout iris
#

They don't match color wise. The 2.2.5 bulbs are considerably brighter - especially colors.

#

They also have a different FCC ID.

#

You know what would be cool - a Thread proxy that could take the role of leader so you can hobble certain nodes as child-only.

#

Ugh, who's idea was it to take away the color temp number on the color temp picker in the new beta UI?

hoary harbor
#

@vapid shell outta curiosity, how is the "Migrate network" process gonna work with Thread, on a technical level? Basically, how are you informing the endpoints that're already on a different Thread network about the new one?

sick swan
#

The OTBR knows two dataset, the active and the pending dataset. The pending dataset is meant to get sent out to devices, and gets applied after a delay timer expires.

hoary harbor
#

Ahhh I totally forgot about the pending dataset

#

Could've used that when I moved from my own OTBR to skyconnect

vapid shell
#

theres nothing in homekit (that we know of) to coordinate that, i expect it to happen "underneath me" at a mesh level without hkc being involved, and a device will reappear on a different ip but with the same "id" field in zeroconf.

hoary harbor
#

Yeah that's why I @ you--I figured there had to be something at the application layer

#

That all makes sense though

vapid shell
#

in theory we can write to the same endpoint we do to send the creds in the first place, but do it over CoAP instead of over BLE, and it might work, but its not as safe because theres no fallback. if the thread provision fails the device stays on BLE, and we don't migrate the config entry to CoAP. if a CoAP to CoAP failed, we wouldn't be able to tell, and there'd be no BLE fallback beause we wouldn't have switched the config entry back to BLE mode. so i'm much happier to hand this over to the mesh to deal with.

hoary harbor
#

Yeah, I had tried my thread->thread move by nuking the check that returns "Already on a Thread network" in the code for pushing the thread dataset to a hkc device

#

It actually ended up dropping off old thread network entirely and just not coming up on new

vapid shell
#

which is weird because im pretty sure the method is just empty in the coap backend

hoary harbor
#

Yeah I didn't bother pursuing that further to figure out what was up. Path of least resistance and all that

#

I think you're 100% right to rely on the mesh to handle all that since it's built right in

#

Some smart moves were made with thread, presumably hard-learned lessons from zigbee

devout iris
#

I'm up to 21 Nanoleaf A19's and so far HA OTBR is miles better than Apple.

#

I had a few provisioning failures that were really obvious - device would fail to switch to thread - factory reset and then no problem. That would have just been a laggy, slow device in HomeKit.

#

On the flip side, I just cannot get BTProxy to work with ESP32dev for Thread pairing. It seems to work okay for running a Thread device that's already paired and to push credentials - just fails that initial part.

#

Also, I know it's not HA - but the OTBR topology view is hilariously bad.

#

It seems to be random as to how many routers are listed each time you push the reload button.

#

At various points I see as few as 3 and as many as 13 - and everything in between - all within a few seconds.

devout iris
#

I almost wonder if that topo view is dependent on the immediate ability of the thread leader to share the details quickly.

#

Or maybe it's just a best effort blast of UDP messages that either get back to the topo app or not.

sick swan
#

Can you check if it is the API which really response wonky data or just the frontend which renders it wonky?

hoary harbor
#

I've had the same experience, and it seems like the web UI is using the ot-ctl command directly, since if you have ot-ctl running in REPL mode the web UI errors out

#

ot-ctl neighbor table does show all my devices since they're all routers and all connected to one another. not sure how you'd list child devices connected to other routers

devout iris
vapid shell
devout iris
#

No problem.

#

Haha well that's depressing.

#

Only 3 neighbors and with RSSI between -80 and -83.

#

Should I be worried that dataset just returns Done?

vapid shell
#

does ot-ctl dataset active return anything? (from memory, might not be right)

devout iris
#

Yep.

#

I guess dataset would only work when creating a new one.

sick swan
devout iris
#

Hmm, I guess now I can play with the NS tools and that NRF stick I bought a while back.

sick swan
#

You can just curl the diagnostics info as returned by the OTBR REST API:
curl http://<your-ha-instance>:8081/diagnostics

devout iris
#

I was too lazy to playground the keys out of my Apple thread network before.

devout iris
#

Anyone know the name of the web frontend project on github?

#

Yeah, looks like bugs in the frontend. All of the routes are in the /diagnostics JSON - and even the /node info shows the right number of routers:

#
    "State":    2,
    "NumOfRouter":    21,
    "RlocAddress":    "fd7d:xxxx:xxxx:xxxx:0:ff:fe00:3c18",
    "ExtAddress":    "52954E48XXXXXXXX",
    "NetworkName":    "home-assistant",
    "Rloc16":    15384,
    "LeaderData":    {
        "PartitionId":    1937964234,
        "Weighting":    64,
        "DataVersion":    251,
        "StableDataVersion":    182,
        "LeaderRouterId":    18
    },
    "ExtPanId":    "A683XXXXXXXXXXXX"
}```
devout iris
#

Hmm. So the topo iterates the list of extAddress objects. It's only counting ones returned in any given call to /diagnostics which does appear to be different every time it's called.

#

So maybe not a bug in the frontend...

#

There are some pretty aggressive timeouts clearing out the diagnostic data in resource.cpp.:

#
static const uint32_t kDiagResetTimeout = 3000000;
// Timeout (in Microseconds) for collecting diagnostics
static const uint32_t kDiagCollectTimeout = 2000000;```
#

That's only 2 seconds to collect the diag data - and based on how long the reload operation is taking, it's easily taking that long.

#

And it looks like before it sends anything back, it purges any diagnostic data that's over 3 seconds old:

#
...
auto duration = duration_cast<microseconds>(steady_clock::now() - aResponse.GetStartTime()).count();

if (duration >= kDiagCollectTimeout)    
{       
  DeleteOutDatedDiagnostic();
    
  for (auto it = mDiagSet.begin(); it != mDiagSet.end(); ++it)           
  {
    diagContentSet.push_back(it->second.mDiagContent);        
  }
...
}```
hoary harbor
devout iris
#

My guess is that kDiagResetTimeout was probably intended to be 30 seconds.

#

It would make sense to limit the callback to 2 seconds - but then to only purge data older than 30 seconds from the list.

#

That way if you mash the reload button a few times, you probably have everything.

#

Do we build OTBR from source or do we use official binaries?

devout iris
toxic kiln
devout iris
toxic kiln
#

oh right

#

mb

devout iris
#

FWIW They are working MUCH better on a single OTBR with SkyConnect than they ever worked with HomePod/Apple TV.

#

Well, that's not exactly true. When I had about 20 they were working okay with Apple too now that I think about it. I'm up to 21 - and I have about 9 more to add.

#

No wait - I have 28 online now and stable... Lol. I can't keep track.

toxic kiln
#

lol

devout iris
#

I will have 38 when I'm done.

toxic kiln
#

i've got 21 bulbs in my home, once someone releases a matter-over-thread bulb i'll be switching over

devout iris
#

Then I will let that bake for a week before I start trying to move over my 25 Eve Energy Thread outlets.

toxic kiln
#

right now i'm using a mix of hue and shelly bulbs, the shelly bulbs would be really nice but i keep getting "status became unavailable"

devout iris
#

I don't know. I would honestly say to wait on Matter.

toxic kiln
#

yeah that's the plan

devout iris
#

If you have HA, I think HomeKit over Thread with SkyConnect will be better than Thread/Matter with HomePod.

#

Are yours all WiFi?

toxic kiln
#

well the hue ones are through the hue hub, but i wanna cut down on hubs. the shelly ones are wifi

devout iris
#

I also have 45 Hue bulbs.

toxic kiln
#

i only have a couple shelly bulbs though, bought them to test them out

devout iris
#

and about 20 Sengled Zigbee.

toxic kiln
#

how do you like the sengled zigbee

devout iris
#

I really like them - but there are a couple of catches.

#

First is that they do not act as repeaters for Zigbee. I think a lot of people quit reading right there and say "meh."

toxic kiln
#

i'd probably be the same way, i don't have any zigbee devices right now so i need any new zigbee devices to be repeating

devout iris
#

But if you think about it, having a light bulb (which is probably either on a wall-switch or a lamp) act as a repeater is asking for trouble.

#

So use outlets or just cheap zigbee repeaters.

#

I had 20 bulbs working fine with just 3 Ikea Zigbee repeaters I had lying around.

toxic kiln
devout iris
#

If your bulbs are literally hard-wired then having them be repeaters is fine. The places I put the Zigbee bulbs are in guest rooms on normal wall switches and in lamps. I can't stop guests from turning those things off - and with the Sengled bulbs nothing bad will happen if they do.

#

Not so true with Hue bulbs and especially not so true with Thread.

toxic kiln
#

i wish Shelly would release their products in thread rather than wifi. that'd be ideal

devout iris
#

If you happen to turn off the Thread "leader" node, it can take several minutes for things to start working again.

#

I guess. Thread is still really suffering from teething pains. Zigbee and WiFi have been WAY more reliable than Thread so far for me.

#

I have my fingers crossed that this SkyConnect path will change that. But at the moment Apple's thread support is a dumpster fire - and border router interoperability is a hysterically funny joke - and by hysterically funny joke I mean a bare-faced lie.

toxic kiln
#

lol

devout iris
#

Frankly I think everyone who has waited to release Thread products are the smart ones.

#

Blows my mind Apple actually jumped on the bandwagon early. Historically they wait until they are painfully late to release new technology like this. But then they usually have a really elegant implementation. Lol. They did the exact opposite with Thread.

toxic kiln
#

i kind of appreciate it tbh

#

apple is trying to "lead the charge"

devout iris
#

You know those Shelley bulbs may be able to support Matter over WiFi.

toxic kiln
#

probably eventually

devout iris
#

And bam...

toxic kiln
#

i might try that out just to see if that fixes the whole becoming unavailable issue

devout iris
#

For a long time I had headaches with WiFi stuff - but I finally got it tuned to be reliable.

#

Basically it came down to only having 1 AP per 2.4g channel (1,6,11) to cover the house, and to turn off all of the fancy roaming, streaming, power saving, etc, etc, etc...

#

I have 10 APs - only 3 serving 2.4g - all serving 5g. None overlapping channels.

devout iris
vapid shell
#

No idea what the addons look like

#

I only really contribute to homekit_controller

#

Everything else has been what I’ve needed for that and nothing more

devout iris
#

Gotcha. Addon project looks like a docker build with blobs - but they have issues that sound like they have a forked version they are working on.

#

So HKController question: every time an accessory is reset and discovered, it creates a new “discovered” card. What’s the best way to clear those out?

#

Especially with the Nanoleaf bulbs - sometimes I have to reset them 2-3 times to get them to behave - so I end up with dozens of them.

vapid shell
#

Ideally the zeroconf integration would track discoveries and cancel them when the mdns record goes away

#

in the absence of that, i just restart HA 😱

hoary harbor
#

Clearing all discovered integrations sounds like something spook would do

half bluff
#

@vapid shell I noticed that when I start my home assistant sometimes my thread devices will "fail to set up" in the logs. However, if I manually reload it then they set up fine. Is something stopping the device from reloading to fix the issue?

hoary harbor
delicate mirage
#

Why does the Thread overview (new in beta) show “No border routers found” under My network and then I have 2 Other networks, “home-assistant” with the OpenThreadBorderRouter and “MyHome97” with my 3 Apple border routers? Why is none of them in “My network “? Have Sky Connect.

sand sparrow
#

Why does the Thread overview new in beta

tropic snow
#

Hi everyone! I have a problem that I suspect to be me not understanding what's going on or not understanding the documentation.

The setup:

  • Home Assistant OS 2023.2.5 as a VM, connected via LAN to my WiFi AP
  • Nanoleaf Elements panels, connected via WiFi (further referred to as "panels" so I don't confuse them with the next item)
  • Nanoleaf Essentials Light Strip, connected via Thread to the panels (further referred to as "strip" so I don't confuse them with the previous item)

The goal:

  • Manage the panels via WiFi (Nanoleaf Integration) ✅
  • Manage the strip via Thread, using the panels' built-in Thread Border Router as a gateway (HomeKit Controller Integration, I guess, or whatever else works) ❔

My understanding:
A TBR bridges Thread enabled devices to WiFi, which should then be picked up by Home Assistant.

When trying to add the HomeKit Controller Integration, I get "No unpaired devices found", and trying to use the Thread Integration to add the panels as a TBR fails with an "Unkown Error". So I'm obviously missing something here, some fundamental understanding I think. Anyone got an Idea?

vapid shell
#

hi!

#

i'm one of the homekit_controller maintainers

#

i have panels and a light strip

#

right now there are 2 ways to get your light strip to work. im going to ignore your panels for a moment.

#

the way i got my thread devices working originally was to pair them with ios and verify that they were on thread (you can do this for any homekit device, even nanoleaf, with the eve app). when they are on a thread network and working you remove them from the iOS Home app. its unclear if this is on purpose or not, but that removes the pairing (so the device can be paired again) but leaves teh device connected to thread. then homekit_controller should be able to pair them.

#

that process probably only works with HomePod's and Apple TV's at the moment unless the panels or nanoleaf app have gotten an update to let HomeKit provision things onto them since i last tried.

#

the second approach is not available on 2023.2.5, its in the beta and should be out later today

#

that is to pair the device with bluetooth directly to HA. you need bluetooth working on your HA machine to do that.

#

then a button appears on the device to upgrade it to thread.

#

that button only works if you have thread credentials actually in HA's thread integration.

tropic snow
#

Thanks for the fast feedback 🙂

So, I don't have any apple devices, I just have android and a couple of linux boxes. Nanoleaf app tells me the strips are connected via thread. I'll unpair them and see if homekit_controller picks them up now.

Just for my understanding: The TBR should work via WiFi, or am I missing something still?

As for the beta/bluetooth option: That's not feasible for me personally since the host HA runs on is quite a ways apart from the strip installation, but I'll see if I can wrangle a BT stick close enough via a USB extension if all else fails 🙂

vapid shell
#

it should work with BTProxy too (part of ESPHome) - so in theory you can wander around your house with an ESP32 and a USB battery pack 😆

#

the TBR should work with WiFi but it only works with very simple home networks. it is meant for beginners, not IT experts, so VLANs will break it. certain performance WiFi settings can break it.

#

cheap WiFi repeaters can break it.

#

if you run the beta (or upgrade to 2023.3 later today) there is a thread diagnostic report in the thread integration now and that will let us see if HA can actually see your BR, if it can't you have a network configuration problem.

tropic snow
#

I have a very flat network at home: A single WiFi AP wired to a dumb switch, and from there to my firewall. So it should work for me. I'll try the beta, thanks 🙂

vapid shell
#

@tropic snow you can also use a zeroconf tool to check that the device is visible in _hap._udp. i use this one https://apps.apple.com/us/app/discovery-dns-sd-browser/id305441017, but there should be many similar ones for Android. If you can see it in there, then it is indeed on thread. In which case, you can send me a screenshot of it and i can check everything "looks right" for you

#

you will probably also see your panels - they'll be under _hap._tcp. border routers should also show up under _meshcop._udp

tropic snow
#

since this gets distributed into the wider network, I should see the strips via zeroconf from my linux box too, I think, so I'll have a look

#

@vapid shell I see the strip on Android in zeroconf. What screenshot did you want, exactly? I also see the panels in _hap._tcp

vapid shell
#

so on the iOS app there is a detail view and it shows "properties", they have keywords like "id", "sf", "sh". that view if your app has it.

devout iris
# hoary harbor Ayy I was right `Add service to ignore all discovered devices & services (option...

Seems like a fun integration:

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, but NOT including the right to run, execute or use the Software or any executable binaries built from the source code.

still quiver
#

Hi all, just noticed my thread integration has been activated and it picks up my 4 nest hubs as border routers. It also says "You don't have a preferred network yet.", how do I set this up? I have a SkyConnect on RPi4 HAOS. thanks

#

it ask for a URL

still quiver
#

Ok, I think the issue above is because I have not enabled multi-pan on my SkyConnect which is acting as my ZigBee Coordinator now.

#

I'm kinda of hesitant to enable multi-pan, as I don't want my ZHA network to be impacted....or is now a good time to enable multi-pan on SkyConnect?

vapid shell
#

Honestly i would wait

#

Unless you have a burning need for it

#

If nothing else there are some PRs in flight to make sure that the radio settings for both are aligned otherwise all hell will break loose.

still quiver
#

that is some good advice. Ok, I will wait save me some headache 🙂
thank you for your input

rapid umbra
#

Has anyone tried provisioning a Schlage Encode Plus using OTBR/Thread integration yet?

flint zodiac
#

Changing preferred Thread network isn't something that'll happen in 2023.3, I presume?

hoary harbor
floral flare
#

For those interested, I can confirm that the thread integration picks up my eero network

#

Still no thread devices here so that’s as much as I can report

winter notch
#

im testing right now too

hoary harbor
#

More importantly, an option to download diagnostics has been added in the three-dotted menu in the top right. This will help with finding, triaging, and fixing issues as the development on Thread continues.

#

What're you gonna do with your newfound spare time Jc2k?

#

Instead of teaching people how to use SSH?

winter notch
#

i have a warning unsecure Thread-network settings, what do i have to do?

#

i think its from the OpenThreadDemo, how can i remove the router and add a new one?

vapid shell
winter notch
#

im using the skyconnect

vapid shell
#

You need to delete the addon and the OTBR integration, delete thread.datasets from config/.storage, restart HA, then redo the SkyConnect setup from scratch

winter notch
#

thank you

#

will try it

#

@vapid shell you mean the Silicon Labs Multiprotocol addon, right?

#

ok, I have tried this now and reinstall everything

winter notch
#

ok, did work, thank you.

#

When i now scan for a thread network with the Eve app, it doest not find one 😦 any ideas?

winter notch
#

I also unfortunately can't add it in HA as a Matter Device, with the HA iOS APP it just doesn't recognize the QR code. 😦

When I use the EVE app on an iOS device, the QR code is recognized immediately.

hoary harbor
#

The QR code on the device itself?

winter notch
#

yes

vapid shell
#

That doesn’t work yet

#

I think the HA iOS app needs changes to tell iOS about the thread network password, and those aren’t ready yet.

#

Right now I think the only way to use Eve with SkyConnect is via homekit_controller, not matter, at least until that ^ work is done.

winter notch
#

And why does the Eve App Not find any Thread Network? Is that because i can Not add the matter device to ha?

vapid shell
#

I think the eve app will only show thread networks it can add you to, but I’m more of a homekit expert than a matter expert 🤷‍♂️

hoary harbor
#

Eve will only show you a thread network an Eve device is on, from what I can tell

hoary harbor
#

When you convert it it will give you the matter QR code

winter notch
vapid shell
#

That’s not what I expect but this is all still beta stuff at best so who knows

digital salmon
#

By the way… Now, I have two Thread networks. One is my Apple Thread network, where all my devices reside. And I have my home-assistant Thread network, consisting of two Border routers. One is from my productive/stable KVM HA instance with a SkyConnect and the other one is from my Home Assistant Yellow, which is configured for the HA beta channel.

https://imgur.com/a/YyQ3jJX

What do I have to do to migrate my three Thread devices I already see in Home Assistant via the Apple Thread network to the HA OTBR? Is there any documentation?

#

Another question: Seemingly you deactivated the OTBR WebInterface with the latest HA updates. How can I determine which Thread channels are used by the different Thread networks. It would be nice to know/see the used Thread channels, so I can plan/configure my WiFi 2.4 GHz cells to not interfere with the Thread Networks.

gentle viper
digital salmon
vapid shell
#

If it didn’t do this automatically then your install is in an unknown state. It’s possible there will be other actions required to get it into a clean state

#

If you can post a screenshot we can help figure out what kind of reset you need

digital salmon
#

Yes, in the end I removed all Thread integrations and the Silabs Multiprotocol addon, rebooted the HA Yellow and the VM and Integrations were reinstalled automatically. But this time the OTBR worked as expected.

vapid shell
#

I think the priority right now is to get ZHA and OTBR to coordinate on channels, I think they ended up hardcoding 15 so that it was it a known safe state for both integrations. There are PRS in flight but it involves multiple integrations and people.

vapid shell
digital salmon
vapid shell
#

There is a migration feature built into thread but it requires HA to know the secret key for apples network . That requires iOS app changes that don’t exist yet.

#

It would probably also merge the HK border routers onto the OTBR network too if it did exist

#

HAOS 9.5 has a version of NetwotkManager that never deletes stale ipv6 routes, so when your HomePod changes ip there’s a chance of your network collapsing. HAOS (in dev) has a version of network manager that only has one thread route at a time. With three HomePods you’ll see a route table flap once a minute. These might impact stability. If you don’t see problems already it’s likely your apple BRS have stable wifi connections so don’t change ip often.

digital salmon
# vapid shell I think the priority right now is to get ZHA and OTBR to coordinate on channels,...

Hardcoded 15? Uff, I hope that it’s will be possible to change the channel by user in the future.

15 is in the middle between Wifi 2.4GHz channel 1 and 6, so the interference shouldn’t be that high, but I plan to bring my Thread network to channel 25, where the WiFi 2.4 GHz channel 13 operates. I am using Wifi channels 1, 5 and 9. Here in Europe we can use Wifi channels 1 to 13, if we don’t have any old 802.11b devices. The Wifi channels 1/5/9/13 aren’t overlapping. I don’t use Wifi channel 13. That’s the place (Wifi channel 13 = Thread/Zigbee channel 25) for my Thread (ZigBee) network.

vapid shell
#

It was a compromise until all the APIs are in place to handle multipan

#

Right now it’s easy to set different channels for zha and thread and that doesn’t end well

#

Obviously it will be changable in the future

digital salmon
# vapid shell There is a migration feature built into thread but it requires HA to know the se...

This is not what I want do right now. I only want to bring three Thread devices to the OTBR. Resetting to factory defaults is not a problem. I have a HomeKit Yellow which has an Integrated Bluetooth interface on the CM4 and which is already recognized by the Yellow. So, if I understand you right, it should be possible to pair an EVE device over Bluetooth to HA and after that it should be possible to bring the device to HA OTBR Thread?

vapid shell
#

Yes

digital salmon
vapid shell
#

It should be very easy

#

It’s probably the easiest way to get started with thread

vapid shell
#

And that the controls that you want are still being built

digital salmon
#

Ok, thanks for all the infos, the help and the time you investigate into us users. Very appreciated. 😃 The HA Yellow stands directly next to me. So it should be easy to pair an EVE device via Bluetooth and after that bringing it to Thread.

vapid shell
#

Yes I tested doing that with a yellow and an eve energy 10 times in a row during the beta and it was very reliable

#

The only problematic part is if you have Bluetooth issues (I was using an external Bluetooth dongle)

#

(The pi4 Bluetooth has been crashy for some people but not others. Not sure what the factor is).

digital salmon
#

Do you have an idea, how that will operate with my two OTBRs? Is it possible that my EVE Thread devices communicate through both HA Border routers I have? Will I see the Thread devices in both HA instances or only in the Yellow OTBR instance?

digital salmon
#

As already said, my two OTBRs build one Thread network:

https://imgur.com/a/YyQ3jJX

But what does that mean? In which HA instance do I see the paired devices? Only in the HA Yellow beta instance or also in my stable HA VM?

vapid shell
#

Oh god

#

So happy path

#

2 HA instances sharing a thread network is not it

#

In theory it will all just work and the device will be able to use both OTBRs

#

You will be subject to the haos dead routes thing

#

But both HAs probably think they are in charge of the thread network

#

At a matter and homekit level it really doesn’t matter because they are just presenting a ipv6 network

#

You can bounce one and the other will take over in either direction

digital salmon
# vapid shell HAOS 9.5 has a version of NetwotkManager that never deletes stale ipv6 routes, s...

Thanks for this information. Good to know that it’s already in dev. I don’t have any HomePod at the moment. I only have one Apple TV connected via Ethernet, because I read of all the Thread mess with Apple HomePods… I have Sonos all around and used Alexa in the past. At the moment I don’t use voice assistants. 😃 Not an issue here. Life goes on, even though there is no voice assistant, which doesn’t do what you want… 😂

vapid shell
#

actually Apple TV has been the worst, im surprised to hear its working for you lol

#

(i think people tend to hide their TV stuff in cupboards full of wires and theres no enough signal for it to work)

#

to properly answer your question though

#

right now its like you have 2 WiFI AP's connected to 2 HA's, and roaming is configured.

#

whichever instance you do the bluetooth pairing in, thats where the device will be visible

digital salmon
vapid shell
#

but it will use the WiFi of whichever it feels like

#

it won't ever be visible in the other HA, because the encryption keys needed to control the device are only on the first HA

vapid shell
#

(just like if you had a wifi password and a password to log onto a server, the device has thread secret key and homekit secret key)

digital salmon
vapid shell
#

Ethernet is not usually the factor

#

usuallly homepods over wifi have been doing better than ATV's over ethernet

#

i think its the Thread antennae thats the problem, not the LAN connectivity

#

ah, is your ATV the new model from this year?

#

i think they are meant to be better

#

anyway if it works for you, thats all that matters

#

i have another ATV user who loses mesh connectivity several times an hour

digital salmon
vapid shell
#

so they probably improved the thread radio in that model

#

the 2021 one is the one i usually get issues with iirc

digital salmon
#

But interesting to read your informations. It’s the complete opposite from my understanding and informations. 😂

#

Ok, for the moment, I don’t know how to thank you for all the informations. Thank you so much! 🍻😃👍

#

I will check the Bluetooth pairing within the next days and report back here. Thanks again

digital salmon
rapid umbra
#

Has anyone tried provisioning a Schlage Encode Plus using OTBR/Thread integration yet?

#

The only info I can find about it is related to Wifi setup

vapid shell
#

Is it a homekit device?

#

What have you tried?

#

Have you got a link to something on their site where they talk about thread support?

#

The top google result on their site only seems to cover wifi

#

(Right now for homekit and OTBR you need to pair with HA via Bluetooth, then theres one button on the device page to activate thread, if it’s supported. All you need is working Bluetooth in HA and for OTBR to be configured correctly).

rapid umbra
#

Yeah its a homekit device you can pair directly via BLE provisioning into thread

#

I have my locks still paired directly to apple homepod BRs

#

I plan to try and remove one of the locks to try and bring it over to an OTBR

vapid shell
#

You’ll need to hard reset them to detach them from thread

rapid umbra
#

But with door locks its tricky as I dont want to mess with anything in production when it comes to security

vapid shell
#

Indeed

#

The main risk I’ve seen with homekit and ble locks I’ve seen is that they sometimes need extra help from the vendor app

#

Like an extra secret

#

Without the vendor helping us there is no hope

#

Not all locks are like this and I don’t know how to tell without trying

rapid umbra
#

When I initially paired them I did it all thru the Home app directly, no schlage app needed

#

So that might be some false optimism

vapid shell
#

That’s promising

#

It always makes me laugh because the homekit encryption is pretty solid, it’s usually the physical security that’s the problem so the vendor adding their own crypto is laughable

dusty silo
#

Hi, i am struggleing to understand how the sky-connect USB stick can be included to have a TBR for integrating it into HomeAssistant

vapid shell
#

Do you mean theoretically or are you trying to set one up now? What did you try?

frigid harbor
#

Help! I have a problem..

I tried to enable the multi protocol for skyconnect. That failed an now my zigbee devices don’t respond anymore.

I need to revert it back to zigbee only. But I don’t know how…

vapid shell
#

In what way did it fail?

frigid harbor
#

Setup > Hardware > enabled checkbox > Addon installation > and than it said “The ZHA migration is failed”

#

After “Loading next step for Skyconnect “

#

I deleted the addon but I don’t know the next step

vapid shell
#

So removing the addon to rollback is not enough because enabling multi protocol actually flashed new firmware onto your SkyConnect

#

It’s now no longer able to speak to ZHA like it did before

#

I have not rolled back the firmware or had the ZHA migration fail so I can’t help you with that

#

What I can tell you is that the addon you removed is the thing that allows zha and thread to share the upgraded dongle, so right now there’s no chance of it working because bits are missing

#

Right now the best thing to do is sit tight until someone who knows how to reflash your dongle comes online OR you could try and file a ticket about why the migration failed

#

But best not to poke it too much otherwise you might make it worse

rapid umbra
#

You can reflash the dongle ez using chrome

#

try reflashing on here, pretty sure this is just a zigbee only firmware too

vapid shell
#

Anyone able to confirm it’s the zigbee only firmware?

rapid umbra
#

Before I plugged skyconnect into my HA RPi yesterday I did a chrome flash

#

updated using the Web-Flasher and it worked, but when I plugged into RPi I still needed to enable multi protocol for Skyconnect in System settings

#

so I assume the Web-Flasher only flashed the vanilla zigbee firmware

#

If using windows you need to download this driver first so you can see it on Chrome

#

The Web-Flasher page itself also states "You can also use the web-flasher to flash the Zigbee firmware again if you've previously used the experimental multi-protocol support."

vapid shell
#

Excellent

frigid harbor
#

I did a reflash on the website, deleted the addon, stopped the integration, rebooted system, plugged in the skyconnect, re-enabled the integration and everything is working as before 👍

#

Stupid me.. I just wanted to try Thread integration. But wouldn’t do this anymore. I don’t need it for now

#

I have two Eve Aqua with Thread. I was curious if I was able to connect them directly. Or can I use the existing border routers (HomePod mini) to connect them?

#

Or just use HomeKit integration?

cobalt crystal
#

so if we haven't bought any thread devices and the new thread integration finds our homepods on our lan it's still useless to us right?

#

we just have 3 thread border routers that sit there doing nothing?

rapid umbra
rapid umbra
#

They won't physically be removed from the Homekit thread network, but you'll still be able to view/control the accessories in Home Assistant

autumn merlin
#

Hi All - just after a bit of advice/direction. I have a SkyConnect thats currently running multi protocol. I really bought it for thread moving forward, but also using it for 1 single Zigbee device (Yale door lock). Im going to move the Yale lock to Z-Wave (as i have other Zwave stuff) so no longer wanting to use Zigbee. I have some Thread/BLE nanoleaf essential strips (not the new matter based ones) that i would like to connect to the SkyConnect. Should I just hold off on this at the moment?

hoary harbor
#

@vapid shell got a reply on the NM issue. Anyone on the dev team wanna learn the very specific C tooling built around NM? 😛

autumn merlin
vapid shell
vapid shell
frigid harbor
rapid umbra
#

Yeah it's still using the homepod thread network as before, just being interfaced via Home Assistant instead of the Apple Home app

vapid shell
#

Think of thread as WiFi

#

Anything on your LAN can access it

#

Be warned though, HAOS doesn’t expire old routes so when your HomePod changes ip address it won’t forget the old address

#

HAOS 10 should fix that, or at least swap it for a different bug.

rapid umbra
#

is there a way to set a static ipv6 address for the homepod so it always grabs the same IP after reboots/updates?

vapid shell
#

No

digital salmon
vapid shell
#

I don’t know

digital salmon
#

Round about? 😃

hoary harbor
#

He’s not the maintainer for that

#

Check GitHub

digital salmon
#

Ok, now we are at 9.5. This will take some time… 😉

#

I tried to pair an EVE Energy, which is resetted to factory defaults, with my home assistant yellow. But what do I need to do? The Bluetooth integration doesn’t recognize the EVE device automatically. I think, the CM4 Bluetooth interface doesn’t work as expected, as already stated before. Is there something I need to do to pair a Bluetooth device or should it be found automatically?

vapid shell
#

Do you see any mention of Bluetooth in the list of integrations?

#

There should be a Bluetooth integration

#

It’s possible the yellow doesn’t support onboard Bluetooth (vaguely remember something about needing the uart for something else)

digital salmon
#

I recognized that there is also a „Provision the preferred Thread credentials“ button for Thread devices, that use the Apple credentials and are paired to homekit_controller. Is it possible to move the Thread devices from the Apple Thread network to the OTBR network instead of using the Bluetooth variant?

digital salmon
digital salmon
vapid shell
# digital salmon I recognized that there is also a „Provision the preferred Thread credentials“ b...

The button is temporary until the thread dashboard can see pending devices so I didn’t put much effort into hiding it in difficult scenarios. In theory it might work but in practice it’s hard because there is now fallback. If the migration from BLE to Thread fails there is a working connection via BLE. Thread to Thread? Nope it’s just broken. At best you need to manually edit files to tell HA it’s a Bluetooth device and it might coke back or you might be doing the turn it on for 5s turn it off for 3.5s dance

vapid shell
#

With an internal radio the range could be an issue. Or the chip could just have crashed.

digital salmon
digital salmon
#

I have to buy another Bluetooth stick.

vapid shell
#

You could look in the diagnostics report for Bluetooth to see how many devices it can see. There should be some data structures with max addresses and stuff.

digital salmon
#

Ok, thanks! Will do that tomorrow.

#

Have a nice evening. Good night. 😃

vapid shell
#

Nn

rapid umbra
#

Just spent the day migrating over all my thread accessories to home assistant. Took a few tries & extra factory resets for some of them to provision preferred thread credentials, but eventually all devices have been migrated over

#

total of 6 Eve Doors, 5 Nanoleaf A19s, and 1 Eve Weather

#

decided to leave the Schlage locks on the Apple Thread network for now though, due to the nature of them being bolted into my doors I can't be bringing them close to the bluetooth dongle to provision

#

gonna have to wait until the ios companion app gets updated for those. Thanks for all the hard work @vapid shell, much appreciated!!

vapid shell
rapid umbra
#

They do not, only homekit

#

Just got you a few cups of coffee 😛

#

I do have some ESPhome proxies actually, the range might not be a problem now that I think about it

#

alright yolo, lets try one of the locks

vapid shell
#

Lol

serene prawnBOT
#

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

rapid umbra
#

File "/usr/local/lib/python3.10/site-packages/aiohomekit/controller/ble/pairing.py", line 1135, in _populate_accessories_and_characteristics
accessories = await self._async_fetch_gatt_database()
File "/usr/local/lib/python3.10/site-packages/aiohomekit/controller/ble/pairing.py", line 904, in _async_fetch_gatt_database
service.add_linked_service(accessory.services.iid(iid))
File "/usr/local/lib/python3.10/site-packages/aiohomekit/model/init.py", line 73, in iid
return self._iid_to_service[iid]
KeyError: 0

#

RIP the dream

#

Yeah I think its out of range. I think these bluetooth proxies might not be properly configured

vapid shell
#

ah dang

#

thats so close too

#

it paired over BLE

#

normally the ESP range issues strike before it gets that far

#

so im a bit gutted lol

rapid umbra
#

Got a bluetooth proxy up, gonna give it another shot

devout iris
#

Updated to main version and now OTBR is gone.

#

SI Labs Multiprotocol no longer has option for web interface. No border routers found in Thread integration, and can’t add one:
Already configured. Only a single configuration possible.

#

Log is full of:

[22:58:24:486857] Info : Connecting to Secondary...
[22:58:26:487190] Info : Failed to connect, secondary seems unresponsive
[22:58:26:487230] Info : Connecting to Secondary...
[22:58:28:489431] Info : Failed to connect, secondary seems unresponsive
[22:58:28:489472] Info : Connecting to Secondary...
[22:58:30:489926] Info : Failed to connect, secondary seems unresponsive
[22:58:30:489971] Info : Connecting to Secondary...```
rapid umbra
#

Might need to hard reboot to get the multiprotocol option to show back up in settings

devout iris
#

Like power cycle? Already did a reboot.

rapid umbra
#

You used the chrome web-flasher to flash skyconnect back to stock zigbee firmware?

devout iris
#

No. Still mulitipan. Touched nothing.

rapid umbra
devout iris
#
cont-init: info: /etc/cont-init.d/config.sh exited 0
s6-rc: info: service legacy-cont-init successfully started
s6-rc: info: service banner: starting
-----------------------------------------------------------
 Add-on: Silicon Labs Multiprotocol
 Zigbee and OpenThread multiprotocol add-on
-----------------------------------------------------------
 Add-on version: 1.0.0
 You are running the latest version of this add-on.
 System: Home Assistant OS 9.5  (aarch64 / raspberrypi4-64)
 Home Assistant Core: 2023.3.1
 Home Assistant Supervisor: 2023.01.1
rapid umbra
#

By updating to main you mean just going from 2023.3beta to public release? And OTBR is gone?

devout iris
#

Yes!!

rapid umbra
#

Oof no clue what could’ve caused that…

devout iris
#

And Thread config can’t see border router, but acts like one is already configured if you select add.

#

Ugh. This was working perfect in beta.

#

Is there a way to go back to beta from github link?

rapid umbra
#

I would just do all the dumb IT recommendations and power off, unplug power, unplug skyconnect stick, power back on, try diff USB port etc

#

One clean power cycle with no stick, then another with the stick back in

devout iris
#

I think the pub release didnt include OTBR container.

#

Gonna ssh in and check.

rapid umbra
#

I wasnt on the beta, went from 2023.2 to 2023.3 and have the OTBR integration present

devout iris
#

Container is in a restart loop.

#

Maybe power cycle is the thing…

#

Nope. Same thing. Container constantly restarting.

#

Ugh:

devout iris
#

Well, rebooting got the container running. But now the SI Labs OTBR is showing up outside HA - and HA says no border routers found... OTBR Web UI shows:

#
RCP:State
disabled

WPAN service
offline```
#

🤮

#

Going to sleep. Hopefully someone can help me get this running again from backup data... Really don't want to have to rejoin 30 bulbs. Again.

vapid shell
#

Hey @devout iris. If border router is on a crash loop it won’t be visible in the ui because that is driven purely by _meshcop._udp. The only thing it remembers is the network creds. So it knows something is configured, but not the border routers. So the key is going to be to fix OTBR, not HA etc.

#

The OTBR container is managed separately to HA container. Adding the OTBR integration doesn’t add an OTBR addon, it’s just used to link the addon to ha (mostly accessing creds). The HA container also doesn’t ship with an OTBR so it’s not that.

#

I don’t have enough information to go on to give you clear instructions right now but I want to start by having you running ot-ctl dataset active and checking that matches what’s in the thread panel (the ext pan id should be visible there)

#

If those match then I think there is an api call we can make to just turn the radio back on, which I’ll find when I am done with morning child care

devout iris
#
Error 23: NotFound```
vapid shell
#

Bugger

#

Did you reinstall the addon?

#

That’s the only known thing I’ve got that would have nuked it’s config

vapid shell
#

That should recover without impacting your bulbs

#

I am about 30 mins away from a computer then I can help you with that

devout iris
#

I did not re-install the add-on, but the version did change during the update.

#

Here's what the Thread card looks like:

vapid shell
#

Ok good your TLV should still be in thread.datasets

devout iris
#

It was version 0.13.1 before the update, then version 1.0.0 after.

vapid shell
#

Ok so I guess OTBR changed its config format

devout iris
#

Yeah - like the web ui option is gone.

vapid shell
#

Let me get to office and update my yellow see if it bricks me

devout iris
#

Well the weird other thing...

vapid shell
#

I was literally about to suggest a repair option to push the TLV from Ha back to the OTBR

devout iris
#

I had the SkyConnect on a USB hub.

vapid shell
#

Ah

devout iris
#

When it first died, I was getting the multi-pan container boot loop.

#

Reboot and shutdown+power cycle did not help.

#

So on one attempt I moved the SkyConnect to a direct port, and at least the container came up and stayed up.

#

But the multi-pan configuration was still weird.

#

And the thread card was showing the si-labs network as an "other" network as you see in the picture.

vapid shell
#

So in .0 the br gets discovered by zeroconf when it’s unconfigured

devout iris
#

When the boot loop was happening, the addon kept turning off start-on-boot - which I assume is a safety feature.

vapid shell
#

Which matched with the config being corrupt or missing

#

When it’s unconfigured it’s not got a valid extpanid so it ends up at the bottom like that

#

Ah dataset active might only work if the radio is up

#

Pretty sure I can fix it for you when I’m at a desk

devout iris
#

Any thoughts about why moving the stick from a (powered) hub to the Pi directly fixed the boot loop?

#

My UZB-7 and Sonoff-E are plugged into that hub with no issues.

#

Maybe that's a red herring. I'm going to move it back to the hub and see if I get the container boot loop again.

devout iris
#

Hmm. Seems happy back on the hub. The other thing I changed was turning off auto-flash.

#

Okay, well they did mess with some stuff:

#
1.0.0
-Remove Web UI via ingress (expose ports to use the Web UI, see documentation)
-Change vendor name to "Home Assistant" and product name to Silicon Labs Multiprotocol" (used in OTBR mDNS/DNS-SD announcments)
#

So that explains why the Web UI is gone.

#

(But it's accessible via a configurable port.)

vapid shell
#

Sorry got caught up in rl

#

So is it working now?

devout iris
#

No

#

Still borked - but the container is healthy.

#

Did updating the addon screw yours up?

#

I have a feeling that if I rolled back the addon, everything would start working again.

vapid shell
#

updated HA container first (to 2023.3.1)

#

multiprotocol now

devout iris
#

Yep.

vapid shell
#

its working fine

#

absolutely no problems

vapid shell
devout iris
#

dead beefcake.

#

dead00beef00cafe

#

That's no better than deadbeefbaadf00d

#

My favorite 64-bit number.

vapid shell
#

so yeah, its reset

#

i dunno why

#

its not the upgrade (at least not by design) as it worked here

#

and its not a config compat issue, as it worked here

#

so we are probs just going to have to treat the wound and not the cause and hope it doesnt happen again

devout iris
#

Oof.

#

Alright.

vapid shell
#

so first off, we need to get the tlv

#

its in /config/.storage/thread.datasets

#

i only have one record under data.datasets, and then there is a tlv key

#

if you have loads, look for preferred_dataset to find which one to use

#

then when you have it, flip to your multi protocol add on and do

#

ot-ctl dataset set active 0e0800000tlvgohere00000

devout iris
#

There is no thread.datasets.

vapid shell
#

suspicious face

devout iris
#

Okay, my terminal is off the edge of the screen. Sorry.

vapid shell
#

sage nodding

#

after you've done that, see if ot-ctl dataset active is returning anything

devout iris
#

Yep. Looks legit.

vapid shell
#

any changes in the thread panel in HA?

#

(im not 100% sure if the command stages the new config but doesnt yet apply it, its possible there is anther step to fire up the engine so to speak)

devout iris
#

Yes, the thread card looks right now.

#

HK devices still not loading.

vapid shell
#

can you ping6 them? are they visible in a zeroconf browser?

devout iris
#

Nope. Not in _hap._udp.

#

OTBR Web GUI shows:

#
RCP:State 
disabled 

WPAN service 
offline```
#

Maybe just restart the add-on?

vapid shell
#

ot-ctl thread start maybe?

devout iris
#
> thread start
Error 13: InvalidState```
vapid shell
#

yeah lets restart it and see what happens

#

if we missed whatever secret command is ot-ctl save-new-goddam-config then you can just do the set command again

devout iris
#

The cows are coming home.

#

The horse is back in the barn.

vapid shell
#

phew

devout iris
#

Alright. Well that was fun.

#

I wonder what went wrong.

vapid shell
#

wipes sweat from brow

#

so i wonder if the hub is involved

devout iris
#

So as long as I have that TLV, I can get a BR connected back to the mesh.

#

Yeah, I don't know. It's been a pretty reliable hub - I've had it for a couple years. It's a 7-port powered USB3 hub.

#

I've used it for tons of stuff before I decided to go on this HA adventure.

#

Always with a Pi4.

#

Used it for game controllers, HID devices, displays, SSDs - and there have been zero problems with ZWave and Zigbee.

#

I guess it's possible it supplies power through a reboot that would cycle the direct ports.

#

Maybe the SkyConnect doesn't like that.

vapid shell
#

sorry RL again

#

its not that hub im thinking about exactly

#

one sec

#

so my skyconnect is at /dev/serial/by-id/usb-Nabu_Casa_SkyConnect_v1.0_42302f50b514ed11b693ba8be054580b-if00-port0

#

wondered if changing the usb topology changed that designation

devout iris
#

Yeah, mine looks similar.

vapid shell
#

i assumed if00 and port0 were references to the radio, not to the host though

devout iris
#

I think they are. Mine still shows that whether it's plugged into the hub or direct.

#
➜  ~ ls /dev/serial/by-id 
usb-ITEAD_SONOFF_Zigbee_3.0_USB_Dongle_Plus_V2_20221028201839-if00
usb-Nabu_Casa_SkyConnect_v1.0_c8c3e4d0c342ed11982848ab2a61ed69-if00-port0
usb-Silicon_Labs_CP2102N_USB_to_UART_Bridge_Controller_fe900b92a208ea119885d9812473482f-if00-port0```
#

This is with it plugged into the hub.

vapid shell
#

Shrug then

#

It looked like the radio had crashed

#

It’s a pretty unsatisfying chain of events

#

New version of the software, RCP crash, usb plug events, without being there I got no clue

devout iris
#

Yeah. The original glance at the log when I would restart the addon had it barfing on the auto-flash stuff.

#

So I turned that off.

vapid shell
#

Unless we can make it happen again

#

I want to forget

devout iris
#

I still have auto-flash turned off.

#

I could try turning it on again.

vapid shell
#

There is a button being added to the OTBR integration to automate this repair btw

devout iris
#

That's nice.

#

This is one of those common failures you were talking about.

vapid shell
#

It’ll be able to refresh the creds from OTBR into HA, or force the creds from HA back into OTBR like we just did or reset both and start from scratch

devout iris
#

I don't mind breaking stuff that can be fixed.

vapid shell
#

Should handle most of the issues we have been fighting in support

devout iris
#

My PAF considerations flew out the door long ago.

#

My wife just accepts that she can't ever count on anything working right.

#

For some reason she has an infinite supply of patience for me tinkering with the house.

#

She claims she's writing a book: How to live in a house that's smarter than you are.

#

She has recorded a lot of her arguments with Siri.

vapid shell
#

Lol

#

Once we set the lights to turn off automatically to try and get into healthy sleep habits. Results probably worthy of such a book.

hoary harbor
#

I just get annoyed with my past self for setting up those light off at "bedtime" automations when they do happen in the middle of me working/gaming

#

"Which moron set this stuff up??"

vapid shell
#

Yeah

#

I also have a motion sensor that likes to do a “self test” (false alarm) around bed time but then it’s fine the rest of the night. So lights all come on just as I’m going to sleep.

#

Fuuuuuuuu

devout iris
#

So last night, I learned that my Thread stuff was borked when my wife said "Hey Siri, Goodnight!" All of the lights around the house turned off except my Nanoleaf bulbs. Can you guess where all of them are?

#

So she watched the house outside our room go dark as we lay there bathed in glorious 2700K white light.

vapid shell
#

Nice

devout iris
#

She just rolled onto her side and said goodnight like nothing was wrong.

#

She didn't ask where I was going when I got up and headed to my home automation command station.

#

15 minutes later I came back and manually turned off 5 lamps and 2 wall switches. <sigh>

#

Utterly defeated.

#

She said: "It's okay honey. It just goes to show how nice it is when it does work."

#

I really don't deserve her.

hoary harbor
# vapid shell Nice

I've got some thoughts/questions on that NM bug nonsense. Mind if I DM you?

#

Meant a general @ rather than that specific message but /shrug

vapid shell
#

Lol

#

DM away

#

My inbox is always open etc

rapid umbra
#

Status update on the schlage encode plus ble/thread provisioning, still couldnt get it to pair even with the bluetooth proxy (proxy verified working as well)

#

Ended up just putting it back onto the apple thread network, paired right away no problem

#

So now I have 2 thread networks in my home. home assistant OTBR with all my nanoleaf & eve accessories, and an apple home thread network with 5 homepod BRs and 4 schlage encode endpoints 😅

#

Most stable thread performance I’ve had in a long long time so I think I’m just gonna keep it this way until BLE provisioning comes to the ios companion app

#

Not seeing any interference issues between the 2 thread networks, zigbee and wifi 2.4ghz so far. Zigbee is on channel 25 & wifi on channel 6

vapid shell
#

What’s frustrating is based on the trace back you shared it did actually pair at one point

#

I think before you had the proxies

rapid umbra
#

Yeah that was the furthest I actually got

#

After adding and then later removing the proxy I never got the pairing to even prompt for the homekit code again

vapid shell
#

Bizarre

autumn merlin
# vapid shell You can use nanoleaf strips with homekit_controller and the SkyConnect. It works...

OK! So i just want to make sure i got this right... i plugged in a BLE adapter and configured. Then the Nanoleaf light strip showed up as a new device, clicked configure and got some sort of warning about signal strength. Added a USB 2 extension cable to better position this and did as per above. HA asked for the device code and it has been added now! I can switch it on and off etc. Huzzah! Here is the device info... is this still connected via BLE? https://imgur.com/a/1pawMgU

vapid shell
autumn merlin
# vapid shell Hi! Yes it is! You need to press the “provision preferred thread…” button now, i...

Thanks for the quick reply! Sooo close 😄 FYI, when selecting the provision button... I get the credentials not available error message as per https://github.com/home-assistant/core/issues/88670 + i dont know if this is related, but the SL add-on has the following in the logs "Default: mDNSPlatformSendUDP got error 99 (Cannot assign requested address) sending packet to ff02::fb on interface fe80::3004:bfff:fe1e:39a7/vetha37fd91/41"

vapid shell
#

did you have the skyconnect setup in 2022.2 by any chance?

autumn merlin
#

yes!

#

Sorry.. hang on.

vapid shell
#

so basically when the skyconnect is first configured it runs a setup process one time only. if you did that in 2022.2, that was before the code to automatically make a new network existed.

#

but now it thinks it ran the one time setup, and it doesn't try to do it again 😦

autumn merlin
vapid shell
#

the fix came out on Wed

#

as in, if you had SkyConenct plugged in between 02/02 and 01/03, you got this bug

autumn merlin
#

So i would have been on 2023.2 im guessing?

vapid shell
#

yeah

#

so you can make it work very easily

#

you need to delete the otbr integration (not addon)

#

and then re-add it

#

it'll ask you for a url, which is http://core-silabs-multiprotocol:8081

#

that will force it to re-run the initial setup which will make you a network

autumn merlin
#

Once pressed the light strip changed to Detached, then Child, now Router. BOOM

vapid shell
#

nice!

autumn merlin
solid lantern
#

Is the method to "align credentials" out yet? i.e., can I have my Sky Connect be on the same network as my homepods?

hoary harbor
#

Do you have a way to get the network key and such from your homepods?

vapid shell
#

@devout iris might be useful for you too?

vapid shell
split gazelle
#

I've tried to remove the OTBR (and pretty much any combination of removing services and add-ons).

vapid shell
#

there are reset buttons being added by the HA team which im hoping will be available soon

#

but if you can't wait you need to remove the multiprotocol addon

#

then the otbr integration

#

then delete /config/.storage/thread.datasets

#

then restart HA

#

then re-add the multiprotocol addon (ideally via the hardware settings menu, resut your yellow / skyconnect)

#

then if the OTBR integration didn't get re-added, do so manually. it will ask you for a URL which is http://core-silabs-multiprotocol:8081

rapid umbra
# vapid shell Apparently changing the channel interval can help with your bt proxies.

Well it finally got the homekit code entry to show back up but with this error

An unhandled error occurred while attempting to pair with this device. This may be a temporary failure or your device may not be supported currently: Enc: Service 00000055-0000-1000-8000-0026BB765291 not found, available services: ['0000003e-0000-1000-8000-0026bb765291']

vapid shell
#

It’s from bluez

#

So if you were trying the interval thingy I said last night, it’s still choosing your Bluetooth dongle over your bt proxy

rapid umbra
#

hmm

#

I see some logs in the esp32 when it tries to connect

#

[09:37:10][D][esp32_ble_tracker:238]: Starting scan...
[09:37:23][I][bluetooth_proxy:254]: [0] [EF:BF:F0:92:8A:7B] Connecting v3 without cache
[09:37:23][D][esp32_ble_tracker:206]: Pausing scan to make connection...
[09:37:23][I][esp32_ble_client:064]: [0] [EF:BF:F0:92:8A:7B] 0x01 Attempting BLE connection
[09:37:34][D][esp-idf:000]: W (637327) BT_HCI: hcif disc complete: hdl 0x0, rsn 0x13

[09:37:34][D][esp-idf:000]: W (637335) BT_APPL: gattc_conn_cb: if=3 st=0 id=3 rsn=0x13

[09:37:34][D][esp-idf:000]: W (637339) BT_APPL: gattc_conn_cb: if=4 st=0 id=4 rsn=0x13

[09:37:34][D][esp-idf:000]: W (637341) BT_APPL: gattc_conn_cb: if=5 st=0 id=5 rsn=0x13

#

Also saw this once

[09:38:44][D][esp-idf:000]: E (707680) BT_GATT: GATTC_ConfigureMTU GATT_BUSY conn_id = 3

[09:38:44][D][esp-idf:000]: W (707686) BT_HCI: hci cmd send: disconnect: hdl 0x0, rsn:0x13

#

It basically spins and then times out and says "Cannot add pairing as device can no longer be found"

vapid shell
#

so it looks like the ESP is failing to set the MTU

#

i think its trying to fallback to BlueZ after connection attempt 1

#

just having a quick google for GATTC_ConfigureMTU and GATT_BUSY...

dusty silo
#

Getting Started with thread and sky connect

cold merlin
#

Hi there 👋

I am asking just out of curiosity, after upgrading home assistant to 2023.3.1 and restarting, I got a notification for a "new device on network" that is highlighted as an available Thread integration.

As far as I know I do not have anything that has Thread in it. But I have a Zigbee dongle, and I have an "old" Apple TV 4K (not the new ethernet model, the one before. I know the new is supposed to have a thread radio in there).

How can I know what hardware prompted HA to display this?What should I look for in the logs?

vapid shell
#

If you add the thread integration it will have add a new panel that shows all the border routers you have and what network they are on

#

The “one before” has a not very good thread radio

cold merlin
#

in the "other networks" section

#

I thought the thread radio was a "new feature" of the ethernet version of the new Apple TV 4K

vapid shell
#

I think it’s a better thread radio in the new one but yours definitely has one

autumn merlin
#

So i got everything working well with SkyConnect and my nanoleaf light strips yesterday, however today is rather different. For some reason the SkyConnect add-in is not working and the SkyConnect thread network is missing from the Thread panel in HA. Error message from the add-in https://pastebin.com/XuSgz9ut which because its not running would be the reason why both the OTBR panel is unable to connect? Its also trying to setup the Zigbee part as well, so there maybe something wrong with my Skyconnect?

autumn merlin
hoary harbor
#

How are you?

#

Pi? Virtual machine? What platform

autumn merlin
vapid shell
#

So we had a case yesterday or the day before where the OTBR or dongle crashed and the OTBR ended up forgetting the network

#

I need to see a screenshot of your thread panel to see if yours is in the same state

#

Or possibly the thread diagnostics json

#

You could try unplugging the SkyConnect and plugging it back in if you haven’t then restarting the addon

#

And then the entire machine if that fails

#

(If the flasher service isn’t starting but did previously work, it feels like a problem with the dongle or something OS-y)

autumn merlin
# vapid shell And then the entire machine if that fails

So i rebooted the entire machine and no go. The thread panel shows the Apple one "MyHome310925697" and nothing for HA https://imgur.com/a/ZUGHv13 - the thing is that i had SkyConnect plugged into a USB hub, which is on a 2m extension cable. The same hub has bluetooth dongle and Z-wave stick in it as well as the SkyConnect. All 3 of these were offline this morning but the re-boot got the BT and zwave sticks working again. I think i might move the SkyConnect back to its own USB port and see what happens?

autumn merlin
vapid shell
#

Like, have you gotten shell access and stuff

autumn merlin
vapid shell
#

First thing, I think there is an addon setting for whether auto flashing is enabled, can you turn it off.

#

And reboot the whole machine of you haven’t

#

I might be Afk for a bit but will be back asap

autumn merlin
vapid shell
#

Can you unplug the SkyConnect and plug it back in

#

And then restart the addon

hoary harbor
#

Is the USB hub externally powered? Host power cycle might not have reset the stick

#

Another guy also had one hooked up via hub and it just didn’t want to work

autumn merlin
autumn merlin
autumn merlin
hoary harbor
#

Seems like a safe bet

autumn merlin
#

A question: Once you have on-boarded any thread devices via BT, is there any reason to leave the Bluetooth in active scanning mode?

vapid shell
#

No

#

It’s only used by thread stuff during commissioning

half bluff
#

Should I change my channel for thread and zig bee to 15 from 25?

#

I kind of forced onto 25 when first setup but not sure if that would cause issues

vapid shell
#

we force 15 only because the API's needed to coordinate between ZHA and OTBR aren't ready, and it was better to force them to be same than having them set to something different

half marlin
#

hey, i need some help with the HA thread thing. it looks like my HA has build an own thread network, but i want it to join my existing one from my apple homepods. or do i understand somethign wrong here? https://imgur.com/a/4Wnabpp

#

i also tried to connect my eve motion sensor (thread) to homeassistant, but it come up as homekit controller

regal tapir
#

You can add some devices in multiple ways—if it can connect to HomeKit then HA can pretend to be HomeKit to control the device.

half marlin
#

well yes but i want to make sure its connceted to HA via thread, it does not look like

hoary harbor
#

For the HomePods, unless you have a way to find the network key, you can't combine it with your HA OTBR

#

You wouldn't want to anyway. They're on an older version of Thread

#

And your devices connecting as HomeKit is exactly what you want/expect

half marlin
#

okay i understand, so i want HA to be the boardrouter and every other device to join that one

hoary harbor
#

You also can't make your HomePods join the HA OTBR. They're totally separate for now

half marlin
#

ok

#

how about my nanoleaf blubs wich are also thread?

#

i anyway want to dismiss the homepods from my home

hoary harbor
#

What about the bulbs? And you can't turn off the Thread function of HomePods unfortunately

half marlin
#

ok but the bulbs have thread, i should be able to connect them to HA or not?

hoary harbor
#

You should be able to, yes

#

Probably most of us have nanoleaf bulbs at this point

half marlin
#

and they would then expand the thread network from HA right?

hoary harbor
#

Yep, they can function as Thread routers

half marlin
#

ah ok perfect

#

i will try to pair one then

#

how do i look for thread devices? there is no search for devices button. do they show up without starting a search?

hoary harbor
#

Mine always just showed up. Do you have a Bluetooth adapter connected to HA?

half marlin
#

yes

#

i reset them now and see what happens

#

ah ya they show up, but also via the homekit controller, that will be thread connceted?

hoary harbor
#

Just BLE at first

#

There will be a button to push Thread network info over BLE once it's connected

half marlin
#

ahhh that one ok

#

i clicked that button but what now?

hoary harbor
#

Go make a cup of tea and hope that it's on Thread when you get back

vapid shell
#

It takes 30s so it probably did it while you were asking what now

half marlin
#

okay

#

so just click once and wait, how can i confirm it worked?

vapid shell
#

There’s a thread status sensor. What does it say.

half marlin
#

says deaktivated ^^

vapid shell
#

Then it didn’t work. You didn’t see an error? Nothing in the logs?

half marlin
#

Nanoleaf A19 A67G Provision Preferred Thread Credentials wechselte zu 6. März 2023 um 16:18

Nanoleaf A19 A67G Identify wurde unbekannt

vapid shell
#

I meant the system logs

half marlin
#

where to post them?

#

i just try again with the thread button?

#

mhm tried another blub same problem

hoary harbor
#

You completely reset them? Power cycled 5 times until they flash red?

half marlin
#

yes a second time just now

hoary harbor
#

Weird. The thing that sticks out to me is this:
Accessory with device id 98:bf:aa:8b:3a:36 not found
I'm not sure why it's failing to find your bulb's device ID in your homekit config

#

I know they were dealing with different IDs over BLE vs. CoAP (IP, Thread) for a while but I figured that was resolved now that migrating from BLE to Thread/IP/CoAP is supported

#

Maybe jc2k will have some insight when he gets back

half marlin
#

ok well i dont know ^^

#

mhm its just now working for me, reset now 2 times and also tried another bulb. anything else i can check or try?

vapid shell
#

so what happens is we write the credentials over bluetooth

#

we can't tell if that worked or not

#

unfortunately some manufacturers cough nanoleaf cough just disconnect with no warning

#

and it bubbles up as an error

#

so we ignore that error and instead start a zeroconf scanner looking for _hap._udp

half marlin
#

how do i do that?

vapid shell
#

it does it

#

obviously we don't know whether the command event sent or if your network is working so we don't wait forever

#

so there is a timeout, and thats the timeout you are hitting

#

so we can't tell whether you are simply out of bluetooth range (if you are right on the edge of your network it could be hit and miss and will eventually work if you keep trying)

#

or whether you have network troubles

half marlin
#

mine is 2 meter away from the HA

#

i just paired it via homekit-controller and its now sitting there

vapid shell
#

do the on/off controls work?

half marlin
#

thread status still deaktivated

vapid shell
#

if they work, but provisioning doesn't, then its a skyconnect thing

half marlin
#

no its not turning off/on

vapid shell
#

right

#

then its probably a bluetooth range issue or your bluetooth adapter is a bit crap and crashed

half marlin
#

its the one from my pi4

vapid shell
#

right

#

so its physically close, but its probably suffering a bit from interference

#

and its connected to a serial port, not USB, so HA can't reset it if it goes wrong

half marlin
#

so i make a temp solution and put the bulb directly there for setup?

vapid shell
#

yeah that could work

half marlin
#

or reset my HA and try again?

vapid shell
#

if its not too much of a pain a power cycle is worth trying

half marlin
#

ok

#

wow thats complicated ^^

vapid shell
#

or if you have an esp32 you could try setting up a bluetooth proxy

#

or get a really long usb cable

half marlin
#

what?

vapid shell
#

my own bluetooth dongle is on like a 4m cable

half marlin
#

im very new to the HA universe

vapid shell
#

so HA has a sister project of sorts called ESPhome that lets you configure a chip called an ESP32

half marlin
#

u mean use a random BT dongle and bring it closer to the blub?

vapid shell
#

esphome can be used as a range extender over wifi or ethernet

#

and yes

#

i have a random bt dongle connected by a really long wire

half marlin
#

but i need to install esphome first?

vapid shell
#

i said too much at once and now its turned into a move with a time travel plot 😆

half marlin
#

😄

vapid shell
#

option (1) - use esphome and something called bluetooth proxies. needs a chip called an ESP32, and there are loads of variants. kind of a pain if you aren't already a user

#

option (2) USB bluetooth dongle and a long cable. no esphome.

half marlin
#

ok option2 sounds good to me xD

vapid shell
half marlin
#

i just restarted HA and the blub is not responding at all

vapid shell
half marlin
#

i pluged skyconncet to usb2 on my pi4, thats correct right? with the 2m extensoin

half marlin
#

my BT dongle doesnt show up in HA...

half marlin
#

HA!

#

now it works, i placed the blub much closer to the BT device

#

Thread Status
Kind

hoary harbor
#

It should become a router after a little while

half marlin
#

and then u remove it in the homekit-comtroller?

#

or just leave everything as it is?

hoary harbor
#

Thread is just the network layer. HomeKit is the protocol that sits on top

#

It's like having a device on Wi-Fi. Just because a device can connect to your Wi-Fi doesn't mean HA knows how to talk to it and control it

half marlin
#

but why its so? i dont use it any homekit related? its because the bulb is build on homekit?

hoary harbor
#

A lot of stuff was designed to work with HomeKit, so the HA devs being the smart guys they are, they made it so that HA can pretend to be a HomeKit server

half marlin
#

ok

#

should i update my eve sensors to matter before i add with thread?

hoary harbor
#

Only if you want to lose functionality

#

Eve sensors on the HAP (HomeKit Accessory Protocol) firmware support energy monitoring. Matter as a standard doesn't support that at all yet

half marlin
#

its motion sensors and door sensors so not much funktions there

hoary harbor
#

Oh motion/door

#

I was thinking outlets

half marlin
#

i should be fine using the matter protocol then right?

hoary harbor
#

Probably? I haven't used those particular devices with Matter

#

I feel like Jc2k was just talking about difficulties with those devices in #matter-archived though

half marlin
#

oh ok

#

well then i stick to homekit-controller as everything goes better

#

but very happy i can use thread now in HA, thanks guys

vapid shell
#

Yeah so I like to talk about the happy path

#

For me eve and sky connects happy path is homekit right now

#

Matter has more moving parts.

#

We need permission from apple to integrate thread support into the iOS ha app for example

#

Which we don’t have yet

#

The “integration” part of homekit_controller has been in production for years