#thread-archived
1 messages · Page 2 of 1
\o/
looking for suggesting for a 0-10v dimming controller, would love if it had thread.
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?
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.
anyone have a suggestion what I should enter as Url to connect the HomePod?
Baby's first buildroot
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?
thats not possible yet. you can't connect to a homepod with the otbr protocol.
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.
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
How would you envision this working? It would be pretty easy to add HK Thread credentials as a Companion app “sensor” but that’s not really the design intent of those sensors. Also, is there a preferred way to pass secrets from the companion app to an add-in for stuff like this?
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.
Theres a new API in the HA websocket connection for interacting with the thread dataset store.
So we could add a companion app section for sharing HK thread data with HA, sort of like how location works todayZ
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
you can see what the Android peeps are working on by looking at e.g. https://github.com/home-assistant/android/commit/25dd8692729bbe21bf9ca0b2ab5b65b2b8f53c8a
I’m not sure if the SmartThings hub TBR credentials even made it into my device… is there an app I can run to check what TBRs I have credentials for?
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
Alternatively, it looks like their app will show the network key and PAN ID and such? https://www.reddit.com/r/SmartThings/comments/y928ma/thread_enabled/
Oh just got to that page! Any way to manually add that into HA?
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
That’s cool. They are also handing off Matter commissioning from the Android app with this change. But it looks like all of the core plumbing is there.
I’m on 2023.3.b1 if that helps - saw the commit for HomeKit via thread devices made it into there
no, it has to go via the thread integration now. there is a menu to add a meshcop TLV to the datastore manually, but weirdly i think i can only get to it if i have a yellow.
or its been removed since the last nightly i tested
or i imagined it
i certainly can't find it now ;_;
Should the thread integration be detecting all meshcop udp things on the network? Mines showing blank even though I definitely have a SmartThings one.
Happy to file a bug but just not sure if it’s actually not working as intended
dang, that patch that added a simple service call to send thread info over existing HAP/BLE connection was useful
My HAP/BLE devices have a “provision preferred thread credentials” button if that’s what you mean?
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
on the mobile app i assume? if and only if the smartthings app has pushed its thread network info into your phone's data store will that work
worth a shot though
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
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 😉
Yeah on the iOS home assistant TestFlight
The issue is that SmartThings hasn’t added its credentials and I can’t find any apps to manually add credentials even tho the SmartThings app is telling me the credentials
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…
let us know if you find it
Ah of course you need to request access https://developer.apple.com/documentation/bundleresources/entitlements/com_apple_developer_networking_manage-thread-network-credentials
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?
They are already doing it - see link above.
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)
👋 as the dev who implemented the Android change you've mentioned: Thread credentials are updated when you start Matter commissioning because that is currently the only point at which it is relevant for the app
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
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
Manual controls in the future when the frontend allows for it 🙂
@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 😦
If you can find it, please link it! Seems like what I needed for my HAP/BLE -> thread on SmartThings situation
It will need re-working
Yeah, it won't just apply cleanly to current code. But if I remember right it wasn't horribly complex
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
Oh yeah, I see your comments on github pull #148
https://github.com/home-assistant/core/blob/dev/homeassistant/components/thread/dataset_store.py - DataStore.async_add with the thread creds
if user doesnt have an active border router it should start using whatever you inject there as the preferred router
So really that old patch is totally irrelevant now that the thread component exists to store the dataset
yeah
These are some smart architectural decisions
You guys seem to know what you're doing 😉
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
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
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.
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
So, there doesn't seem to be a whole lot to adding a service call to HA? https://github.com/home-assistant/core/compare/dev...roysjosh:core:hap-thread-provision
no, the hard bit was hidden in aiohomekit
This is actually immediately useful to me for re-pairing my Nanoleaf bulbs onto my SkyConnect
So I'll hack something together pretty quick
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
That's a question of whether the smartthings app pushes its Thread info into iOS
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
so if the HA Thread integration can't see it, bonjour/mdns to your HA is broken
Any way to test that out/repair it? It’s definitely discovered plenty of other wifi devices before (eg chromecasts)
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)
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
Right, so does HA just ignore those devices right now? Would be nice to see a “Cant commission without credentials” or something
You're asking if HA is or should be aware of other Thread networks based on the presence of _meshcop in mDNS?
Yes exactly
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
it is
^ Ignore me, talk to this guy
Everything is changing so fast on this you gotta get it right from the source
Lol glad I’m not the only one confused tho
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
I don’t have any VLANs
Can I ssh into my HA and run anything to check mDNS?
so can you share a screenshot of your thread panel?
It’s just blank
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)
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?
Integration -> Thread, click on configure
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”
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?
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?
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
Gotcha! “Thread data store” is mobile only right?
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
What URL is that asking for btw?
the thread data store is part of your HA server
Just curious--not in the same position
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
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.
That also explains why the Thread integration just loops for me. 🙂 I have a skyconnect but my OTBR is on its own Pi
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"
Dang maybe that’s worth the cost vs this SmartThings situation, but my pi is literally as far as possible from the two thread devices I have 😅
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
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
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
Closing/merging/whatever the HAOS buildroot thread to figure out whether a new version of NM on HAOS would still have lost/stale IPv6 routes, we determined that NM 1.40.10 on HAOS does /not/ have the same issue. So, HAOS issue opened here: https://github.com/home-assistant/operating-system/issues/2367
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?
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
@sand sparrow I converted your message into a file since it's above 15 lines :+1:
Would appreciate the script if it’s still handy!
victoraperez 4373 I converted your
Annnd consolidating the "Thread add dataset via service call" thread: https://github.com/home-assistant/core/pull/88723
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
Are you trying to pair them via BTProxy and then immediately move them onto thread?
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...
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?
Yeah, that’s the version I’m on - but it seems to have borked ZWave JS UI setup…
You might have more luck in the esp logs.
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...
Are the sticks on USB extension cables?
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.
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...
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...
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
No, just beta
I started with the generic version on https://esphome.github.io/bluetooth-proxies/
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?
I guess I can try the developer version next...
This change is the important one, I dunno if it’s in beta or not - https://github.com/esphome/esphome/pull/4254
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
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
how are you finding the SmartWings Nano over Thread?
They’re my first smart blinds so I don’t have much to compare them to, but they’re working pretty well!
Can you send the device page from home assistant?
I have 1 of their zigbee models, but need to buy quite a few more so I'm with curious
This was my bad. I used an IP address when I set up the OTBR API url. When I moved to a new box it was of course a different ip. Solved.
Also, looks like dev is already using that one.
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.
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.
Oh dang. Is there a reference somewhere?
Of which HW revs exist and their differences
Yeah dang I've got some 2.2.5 bulbs and some 1.2.4
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?
@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?
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.
Ahhh I totally forgot about the pending dataset
Could've used that when I moved from my own OTBR to skyconnect
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.
Yeah that's why I @ you--I figured there had to be something at the application layer
That all makes sense though
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.
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
which is weird because im pretty sure the method is just empty in the coap backend
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
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.
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.
Can you check if it is the API which really response wonky data or just the frontend which renders it wonky?
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
I might compare/contrast it with this: https://infocenter.nordicsemi.com/index.jsp?topic=%2Fug_nrf_ttm%2FUG%2Fnrf_ttm%2Fttm_introduction.html
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
ot-ctl child table doesn't specifically say it's only directly-attached children, I guess: https://openthread.io/reference/cli/commands#child_table
I assume it's the frontend since everything is hunky dory with the devices on the mesh. Is there an easy way to get to ot-ctl via ssh?
you need proper ssh access (https://developers.home-assistant.io/docs/operating-system/debugging/), then docker ps to find the silabs container, docker exec -it id-go-here sh to get into it, then ot-ctl away
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?
does ot-ctl dataset active return anything? (from memory, might not be right)
Afaik, it uses the same unix socket as the CLI tool ot-ctl is using but not ot-ctl directly
Hmm, I guess now I can play with the NS tools and that NRF stick I bought a while back.
You can just curl the diagnostics info as returned by the OTBR REST API:
curl http://<your-ha-instance>:8081/diagnostics
I was too lazy to playground the keys out of my Apple thread network before.
Hmm, lots of route IDs - those look right.
Anyone know the name of the web frontend project on github?
The docs page for it on Github looks way out of date - Nov 2021: https://github.com/openthread/ot-docs/blob/main/site/en/guides/border-router/web-gui.md
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"
}```
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);
}
...
}```
That makes a lot more sense
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?
Anyways... : https://github.com/openthread/openthread/issues/8816
nanoleaf's thread bulbs came out?
They have always been Thread - you're probably thinking of Matter.
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.
lol
I will have 38 when I'm done.
i've got 21 bulbs in my home, once someone releases a matter-over-thread bulb i'll be switching over
Then I will let that bake for a week before I start trying to move over my 25 Eve Energy Thread outlets.
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"
I don't know. I would honestly say to wait on Matter.
yeah that's the plan
If you have HA, I think HomeKit over Thread with SkyConnect will be better than Thread/Matter with HomePod.
Are yours all WiFi?
well the hue ones are through the hue hub, but i wanna cut down on hubs. the shelly ones are wifi
I also have 45 Hue bulbs.
i only have a couple shelly bulbs though, bought them to test them out
and about 20 Sengled Zigbee.
how do you like the sengled zigbee
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."
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
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.
i've got my bulbs wired to be always on, right now i'm using hue wall modules with the switches
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.
i wish Shelly would release their products in thread rather than wifi. that'd be ideal
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.
lol
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.
You know those Shelley bulbs may be able to support Matter over WiFi.
probably eventually
A little of this: https://github.com/arendst/Tasmota/discussions/17872
plus a little of this: https://templates.blakadder.com/shelly_DUO.html
And bam...
i might try that out just to see if that fixes the whole becoming unavailable issue
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.
Do you build the ot-br-posix project as part of the add-on?
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
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.
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 😱
Clearing all discovered integrations sounds like something spook would do
@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?
Ayy I was right
Add service to ignore all discovered devices & services (optionally by domain). #byebluetooth
For those who haven't had the joy of learning about spook: https://github.com/frenck/spook
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.
Why does the Thread overview new in beta
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?
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.
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 🙂
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.
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 🙂
@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
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
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.
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.
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
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?
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.
that is some good advice. Ok, I will wait save me some headache 🙂
thank you for your input
Has anyone tried provisioning a Schlage Encode Plus using OTBR/Thread integration yet?
Changing preferred Thread network isn't something that'll happen in 2023.3, I presume?
It's doable manually if you have the dataset for the one you want to change it to
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
im testing right now too
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?
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?
Teach them how to use ping6
im using the skyconnect
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
thank you
will try it
@vapid shell you mean the Silicon Labs Multiprotocol addon, right?
ok, I have tried this now and reinstall everything
ok, did work, thank you.
When i now scan for a thread network with the Eve app, it doest not find one 😦 any ideas?
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.
The QR code on the device itself?
yes
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.
And why does the Eve App Not find any Thread Network? Is that because i can Not add the matter device to ha?
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 🤷♂️
Eve will only show you a thread network an Eve device is on, from what I can tell
That’s also the wrong QR code if you’ve converted it to matter
When you convert it it will give you the matter QR code
ah thank you, that makes sense of course.
That’s not what I expect but this is all still beta stuff at best so who knows
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.
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.
May i ask how you set up a broader router mine an the yellow asks for a URL which for the life of me cant work out
@vapid shell posted it yesterday in the Matter channel:
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
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.
I believe that the web interface was hidden because it lacks a lot of safety checks and is generally very glitchy and broken. I’d expect the channel to be surfaced in the HA thread panel sooner or later, if it’s not visible on the little (i) icon already l.
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.
There isn’t an easy way to migrate networks right now. In fact the only way I know to get eve onto OTBR with homekit_controller is to hard reset it, pair it with HA over Bluetooth and then use the provision button.
Sadly it’s not visible on the little (i) icon. It would be nice to see this information there or somewhere else in the future.
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.
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.
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
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?
Yes
I don’t want to configure different channels for Thread and ZigBee. I only want to be able to configure the channel both operates on.
I’m not saying you do, just that HA has prioritised “user safety” over enabling advanced users to poke around on the insides
And that the controls that you want are still being built
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.
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).
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?
Yes, I read about it. I have to test it.
As already said, my two OTBRs build one Thread network:
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?
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
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… 😂
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
Ok, I have to play with it, to understand how it works or not.
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
Ok, I understand.
(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)
No, problems here. It works fine, but as already said, it’s connected via Ethernet not via Wifi.
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
Yes, it’s the latest Apple TV 4K 2022 128GB Ethernet model.
so they probably improved the thread radio in that model
the 2021 one is the one i usually get issues with iirc
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
In my opinion it has a really good coverage in my house. But there are also 20 EVE Thread routers.
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
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).
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
You’ll need to hard reset them to detach them from thread
But with door locks its tricky as I dont want to mess with anything in production when it comes to security
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
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
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
Hi, i am struggleing to understand how the sky-connect USB stick can be included to have a TBR for integrating it into HomeAssistant
Do you mean theoretically or are you trying to set one up now? What did you try?
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…
In what way did it fail?
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
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
You can reflash the dongle ez using chrome
try reflashing on here, pretty sure this is just a zigbee only firmware too
Anyone able to confirm it’s the zigbee only firmware?
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."
Excellent
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?
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?
If you dont have any accessories connected basically, yeah
If they're connected via thread to your Homepod mini already and you just want to see their status in home assistant, you can remove the accessory from the Apple Home app and then it should pop up in Home Assistant auto discovery
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
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?
@vapid shell got a reply on the NM issue. Anyone on the dev team wanna learn the very specific C tooling built around NM? 😛
Note strips are currently connected to homekit_controller with a Apple TV 4K in the mix
You can use eve stuff with homekit_controller and multi protocol add on or HomePod. HomePods are problematic because of NetworkManager bugs but things do mostly work.
I saw, ffs
You can use nanoleaf strips with homekit_controller and the SkyConnect. It works quite well, but I have only used it when there wasn’t a zigbee network involved.
That worked! Thanks. So now it’s automatically using thread through the HomePods?
Yeah it's still using the homepod thread network as before, just being interfaced via Home Assistant instead of the Apple Home app
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.
is there a way to set a static ipv6 address for the homepod so it always grabs the same IP after reboots/updates?
No
When will we see HAOS 10? 😃
I don’t know
Round about? 😃
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?
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)
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?
Yes, it’s there. I already deleted and reinstalled the integration.
Yes, I also remember something like that.
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
If the integration is there and the eve is reset it should pop up. For me with a yellow it happened within seconds not a reset.
With an internal radio the range could be an issue. Or the chip could just have crashed.
Ok, thanks you answered all my questions. This is not the way to go.
The HA Yellow was in direct range and the EVE Energy also, maybe two meters, no wall. But after factory reset of the EVE Energy no popup.
I have to buy another Bluetooth stick.
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.
Nn
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!!
Do the locks support matter? (No companion apps are gonna help homekit_controller with Bluetooth range, you need ESPHome proxies)
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
Lol
@rapid umbra I converted your message into a file since it's above 15 lines :+1:
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
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
Got a bluetooth proxy up, gonna give it another shot
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...```
Might need to hard reboot to get the multiprotocol option to show back up in settings
Like power cycle? Already did a reboot.
You used the chrome web-flasher to flash skyconnect back to stock zigbee firmware?
No. Still mulitipan. Touched nothing.
Mb, misunderstood this
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
By updating to main you mean just going from 2023.3beta to public release? And OTBR is gone?
Yes!!
Oof no clue what could’ve caused that…
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?
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
I wasnt on the beta, went from 2023.2 to 2023.3 and have the OTBR integration present
Container is in a restart loop.
Maybe power cycle is the thing…
Nope. Same thing. Container constantly restarting.
Ugh:
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.
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
Error 23: NotFound```
Bugger
Did you reinstall the addon?
That’s the only known thing I’ve got that would have nuked it’s config
HA still has the TLV that OTBR was using. So we should be able to tell it to join that TLV
That should recover without impacting your bulbs
I am about 30 mins away from a computer then I can help you with that
I did not re-install the add-on, but the version did change during the update.
Here's what the Thread card looks like:
Ok good your TLV should still be in thread.datasets
It was version 0.13.1 before the update, then version 1.0.0 after.
Ok so I guess OTBR changed its config format
Yeah - like the web ui option is gone.
Let me get to office and update my yellow see if it bricks me
Well the weird other thing...
I was literally about to suggest a repair option to push the TLV from Ha back to the OTBR
I had the SkyConnect on a USB hub.
Ah
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.
So in .0 the br gets discovered by zeroconf when it’s unconfigured
When the boot loop was happening, the addon kept turning off start-on-boot - which I assume is a safety feature.
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
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.
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.)
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.
just updating it now
updated HA container first (to 2023.3.1)
multiprotocol now
Yep.
what do you get from ot-ctl extpanid
dead beefcake.
dead00beef00cafe
That's no better than deadbeefbaadf00d
My favorite 64-bit number.
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
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
There is no thread.datasets.
suspicious face
Okay, my terminal is off the edge of the screen. Sorry.
sage nodding
after you've done that, see if ot-ctl dataset active is returning anything
Yep. Looks legit.
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)
can you ping6 them? are they visible in a zeroconf browser?
Nope. Not in _hap._udp.
OTBR Web GUI shows:
RCP:State
disabled
WPAN service
offline```
Maybe just restart the add-on?
ot-ctl thread start maybe?
> thread start
Error 13: InvalidState```
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
phew
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.
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
Yeah, mine looks similar.
i assumed if00 and port0 were references to the radio, not to the host though
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.
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
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.
There is a button being added to the OTBR integration to automate this repair btw
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
I don't mind breaking stuff that can be fixed.
Should handle most of the issues we have been fighting in support
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.
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.
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??"
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
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.
Nice
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.
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
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
Cheers for the updates!
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
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
Bizarre
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
Hi! Yes it is! You need to press the “provision preferred thread…” button now, if your sky connect is plugged in and ready
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"
did you have the skyconnect setup in 2022.2 by any chance?
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 😦
I got the SkyConnect in 02/02/2023 and keep things updated all the time...
the fix came out on Wed
as in, if you had SkyConenct plugged in between 02/02 and 01/03, you got this bug
So i would have been on 2023.2 im guessing?
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
OK! Thanks sooo much... now in the Thread panel, its showing home-assistant as My network, which it was showing as other before.
Once pressed the light strip changed to Detached, then Child, now Router. BOOM
nice!
Thats very very slick. Nice work!
Is the method to "align credentials" out yet? i.e., can I have my Sky Connect be on the same network as my homepods?
Do you have a way to get the network key and such from your homepods?
Apparently changing the channel interval can help with your bt proxies.
@devout iris might be useful for you too?
As @hoary harbor says, we need the credentials. Ideally the iOS companion app would get them for us but that’s not done yet. But even if it was possible, right now adding BRs is not necessarily a good idea. For one thing apple is a version behind (thread 1.2 vs 1.3). For another, we are still hitting bugs with NetworkManager that get worse as you add more BRs.
I tinkered a bit before 2023.3, and ended up with a network, which I want to remove now and use the default. How do I fix the situation from the screenshot?
https://filebin.net/tuwslc9z9lv7oaeb/2023-03-04_09-04.png
I've tried to remove the OTBR (and pretty much any combination of removing services and add-ons).
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
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']
I recognise that error -_-
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
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"
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...
Getting Started with thread and sky connect
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?
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
Ah, my Apple TV is shown as a "border router", and appear with it's bonjour/mdns URL
in the "other networks" section
I thought the thread radio was a "new feature" of the ethernet version of the new Apple TV 4K
I think it’s a better thread radio in the new one but yours definitely has one
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?
How are you running HA OS?
Yes.
Running on its own dedicated hardware: Dell Optiplex. Home Assistant 2023.3.1, Supervisor 2023.01.1, Operating System 9.5, Frontend 20230302.0 - latest
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)
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?
"Crawls back under house" 😄
Cheers. How tinker-y have you gotten so far?
Like, have you gotten shell access and stuff
Not further than the above as yet. Got shell access etc and am ok with cmd line stuff
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
Turned off and restarted the add in... https://pastebin.com/QdRNCU3z PS I have yet to unplug etc the Skyconnect. Have already power cycled the machine.
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
Yea it was working yesteday, but not now. There is SkyConnect, BT and Z-Wave sticks in the hub... not powered. Im going to move the SkyConnect to its own USB cable and see how it goes from there.
Moved the SkyConnect frpom the hub to its own USB extension cable. Everything working as expected now.
I wonder if its not getting enough power with multiple devices plugged into a non-powered hub.
Seems like a safe bet
A question: Once you have on-boarded any thread devices via BT, is there any reason to leave the Bluetooth in active scanning mode?
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
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
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
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.
well yes but i want to make sure its connceted to HA via thread, it does not look like
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
okay i understand, so i want HA to be the boardrouter and every other device to join that one
You also can't make your HomePods join the HA OTBR. They're totally separate for now
ok
how about my nanoleaf blubs wich are also thread?
i anyway want to dismiss the homepods from my home
What about the bulbs? And you can't turn off the Thread function of HomePods unfortunately
ok but the bulbs have thread, i should be able to connect them to HA or not?
and they would then expand the thread network from HA right?
Yep, they can function as Thread routers
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?
Mine always just showed up. Do you have a Bluetooth adapter connected to HA?
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?
Just BLE at first
There will be a button to push Thread network info over BLE once it's connected
Go make a cup of tea and hope that it's on Thread when you get back
It takes 30s so it probably did it while you were asking what now
There’s a thread status sensor. What does it say.
says deaktivated ^^
Then it didn’t work. You didn’t see an error? Nothing in the logs?
Nanoleaf A19 A67G Provision Preferred Thread Credentials wechselte zu 6. März 2023 um 16:18
Nanoleaf A19 A67G Identify wurde unbekannt
I meant the system logs
where to post them?
i just try again with the thread button?
mhm tried another blub same problem
You completely reset them? Power cycled 5 times until they flash red?
yes a second time just now
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
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?
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
how do i do that?
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
mine is 2 meter away from the HA
i just paired it via homekit-controller and its now sitting there
do the on/off controls work?
thread status still deaktivated
if they work, but provisioning doesn't, then its a skyconnect thing
no its not turning off/on
right
then its probably a bluetooth range issue or your bluetooth adapter is a bit crap and crashed
its the one from my pi4
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
so i make a temp solution and put the bulb directly there for setup?
yeah that could work
or reset my HA and try again?
if its not too much of a pain a power cycle is worth trying
or if you have an esp32 you could try setting up a bluetooth proxy
or get a really long usb cable
what?
my own bluetooth dongle is on like a 4m cable
im very new to the HA universe
so HA has a sister project of sorts called ESPhome that lets you configure a chip called an ESP32
u mean use a random BT dongle and bring it closer to the blub?
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
but i need to install esphome first?
i said too much at once and now its turned into a move with a time travel plot 😆
😄
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.
ok option2 sounds good to me xD
i use both options, my main bluetooth is connected with https://www.amazon.co.uk/gp/product/B019E0LIH0/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1
i just restarted HA and the blub is not responding at all
and i got BLE adaptors from this list: https://www.home-assistant.io/integrations/bluetooth/#known-working-high-performance-adapters
i pluged skyconncet to usb2 on my pi4, thats correct right? with the 2m extensoin
i have to try what i got here in stock ^^
my BT dongle doesnt show up in HA...
HA!
now it works, i placed the blub much closer to the BT device
Thread Status
Kind
It should become a router after a little while
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
but why its so? i dont use it any homekit related? its because the bulb is build on homekit?
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
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
its motion sensors and door sensors so not much funktions there
i should be fine using the matter protocol then right?
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
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
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