#thread-archived

1 messages · Page 3 of 1

vapid shell
#

It’s only the thread bit that’s newish

#

So eg I’ve had eve motion, smoke, thermo, energy, room etc all connected to an eve extend

#

For years

#

The data model when we migrate to thread is the same, we are just shuffling bits over udp instead of tcp

half marlin
#

well the first 2 bulbs went well, but now it come up with errors when connection first time with homekit-controller

#

it shows up as "Nan (Lightbulb)"

hoary harbor
#

They told me that it’s only for border router devs apparently?

#

I’m gonna see how far I can get with their Thread API without that

#

The entitlement or whatever

half marlin
#

Beim Koppeln mit diesem Gerät ist ein nicht behandelter Fehler aufgetreten. Dies kann ein vorübergehender Fehler sein oder das oder dein Gerät wird derzeit nicht unterstützt: Nanoleaf A19 72TT: Service 00000055-0000-1000-8000-0026BB765291 not found, available services: ['0000003e-0000-1000-8000-0026bb765291']

#

it always says that when i try to connect another bulb

#

the first 2 work just fine....

#

can i clear the cache from homekit-controller?

devout iris
#

I will give it a shot. Thanks!

#

Not so sure. I had SC, ZW, Zig on one POWERED hub and only the SC went nuts.

half marlin
#

i allways have to restart HA BT and bulb reset and then maybe i can add another one

#

very strange i think its about my BT module

vapid shell
half marlin
#

ya

#

can u tell me what 5.3 dongle is fine for HA? in the list of good one are only 4.0 ones

vapid shell
#

Its like it times out when bluez is enumerating it

#

No

#

They are the only ones that a Bluetooth developer has verified in a controlled environment

half marlin
#

ok

vapid shell
#

Any with Linux drivers should work with similar problems

#

So no Realtek ever

half marlin
#

ok

vapid shell
#

Broadcom more likely to need firmware, and it’s more likely to be missing from haos

half marlin
#

u have one works anytime?

vapid shell
#

Can’t make promises, but this one worked well for me personally - Kinivo BTD-400 Bluetooth 4.0 USB Adapter (Low Energy Wireless Dongle) - Windows 10/8.1/8 / 7 / Vista, Raspberry Pi, Linux, Mac (2011 & beyond) and Stereo Headset Compatible https://amzn.eu/d/bvLSbSq

half marlin
#

ok thanks i will give it a shot

vapid shell
#

This one is Realtek but it worked well enough for me to pair a nanoleaf light strip 10 times in a row without problems at 2m distance https://amzn.eu/d/0EuHzuv

#

This first one I have on the really long usb cable

half marlin
#

ok

#

finaly added 6 bulbs successfuly, took me 2hrs

winter notch
#

im using this one, works very good with HA OS and Ubuntu

half marlin
#

u need any driver or configuration or it works plug and play?

vestal shuttle
#

Hi peeps! I'm new here and I joined because I want to know something about this new technology! My first question is: are nanoleaf essential (bulbs) compatible with HA+skyconnect via thread?

half marlin
#

yes

#

i just setted them up

#

reset them and add them with bluetooh. they will popup in HA as homekit-controller. then go inside there config and click the "Provision Preferred Thread Credentials" button. then it should join ur thread network

#

make sure the blub is close to ur BT device when setting up

winter notch
half marlin
#

ok

vestal shuttle
half marlin
#

maybe ur BT module is better then mine

winter notch
#

has worked for me just as without problems the first time. thanks to @vapid shell for his great support.

half marlin
#

is it better to use a 5m cable extension for the skyconnect then a 2m?

upbeat cairn
#

It won't hurt if you use a longer one, as long as the longer one is shielded

real ibex
#

hey there! I have a couple thread devices (some plugs) that are currently integrated with my SmartThings Hub, and they work perfectly fine. In home assistant, with the Thread integration, I see my smartthings hub but can't see any devices from it. I have both matter and thread set up. Any ideas?

#

I read about the SkyConnect, do I need a skyconnect if the smartthings hub is already a boarder router?

#

I don't need HA to be a boarder router

winter notch
half marlin
#

anyone try to connect eve thermo via thread?

#

i think its not supported right?

vapid shell
vapid shell
#

Even for SkyConnect, the thread integration only cares about your border routers. There is a separate OTBR integration (that’s the name of the border router software) that is able to actually see any detail about the network.

#

Matter is slightly more tricky than homekit_controller right now. HA can’t teach iOS about thread secrets it knows. On android you need to use the beta HA app. I can’t help you with that.

half marlin
#

can i still update my nanoleaf essensials bulbs with the nanoleaf app?

half marlin
vapid shell
vapid shell
#

The problems I do have are to do with HomePods and multi-br etc, and happen to every device I have. Probably don’t impact SkyConnect

half marlin
#

okay

rapid umbra
#

Attempt #3 on provisioning a schlage encode plus via bluetooth proxy

#

got an extension cable and put the esp right up to the lock before beginning to pair

vapid shell
#

Lol nice

half marlin
#

is there any thread "shelly dimmer2" alternative?

rapid umbra
#

I also disabled the bluetooth integration on the rpi and dongle

#

still verified I'm getting bluetooth temp updates on the mijia sensors so the proxy is working

#

just never progresses to the point where it prompts for the homekit code to be input

#

homekit controller spins and eventually times out with "cannot add pairing as device can no longer be found" even with the esp32 right up against the lock

vapid shell
#

Grr

rapid umbra
#

what's strange is when I go to add the lock back to the apple thread network it works right away, like instantly

#

but thats obviously thru my phone, not the esp

vapid shell
#

Yeah

#

I wonder if it has a hard coded MTU or something

#

Worth filing an esphome bug maybe

#

In the meantime all I got is really long usb cable

rapid umbra
#

lol that might be my next plan of attack honestly

#

the usb dongle is what I paired all the other thread devices with in the first place

rapid umbra
#

dunno about any thread relay products on the market tho

half marlin
#

i already have zigbe but i want to have a thread one

#

but ya looks like there is none

half marlin
rapid umbra
#

once you pair them with home assistant thread network they won't show up in the eve app anymore

half marlin
#

thats very bad for updates xD

rapid umbra
#

true, I'm honestly content with things just working

#

if they add a path for firmware updates in the future then great but for now I'm cool with stability

half marlin
#

well ya thats true. all this will change when matter support is better

rapid umbra
#

matter stands to improve the alexa/google experience the most I think

#

if you're on home assistant with your own thread network then none of that stuff really matters currently, pun intended

half marlin
#

ya but u can connect them to both and this way u can make updates

#

both = HA and Eve

rapid umbra
#

I personally have no plans to update any of my eve stuff to matter

#

at least not any time soon, based on how bad the beta firmware feedback has been

half marlin
#

ya time will tell

rapid umbra
#

especially for a straight loss in features like energy monitoring on the plugs

#

the nanoleaf a19 bulbs also have 0 plans on updating to matter

#

just gonna keep everything stable on homekit over thread handled thru home assistant for the foreseeable future and let the industry sort itself out over all this matter bs on their own

half marlin
#

right

rapid umbra
#

nanoleaf issuing a firmware update to a19 would probably be a downgrade in all likelyhood anyway given their track record 😅

vapid shell
#

I don’t have a thread one to test but that’s how the Bluetooth one works

#

If it doesn’t make sure your homekit bridge is configured to export binary_sensor

half marlin
#

okay and it should work the same so i can update them?

vapid shell
#

You can’t update them that way

half marlin
#

ah ya ok

vapid shell
#

Homekit only allows one pairing at a time

#

In theory you can dump the encryption keys from iOS, but it’s really hard and I’ve not tested it with thread

#

I did that to get my Hive heating working with homekit_controller as I didn’t have a setup code for it

half marlin
#

ya i will wait for better matter integration and more updates from eve. then i connect them over matter instead of homekit

hoary harbor
# 

Thank you
Apple Thread Network Support Team
#

So that's why there's no Thread diagnostics apps currently

vestal shuttle
vapid shell
#

The thread integration is only used to get them onto your thread network after which homekit can reach them over the network

vestal shuttle
#

so... how my HA communicate with thread bulbs without thread hardware to do it?

vapid shell
#

The addon is still running

#

The addon works like your home router

#

It makes your thread devices visible on your network just like they were on a different vlan

#

If you want to check if it really worked, there should be a thread sensor on the device page. If it says disabled, it failed. If it says router or child or leader it worked

#

The other tell tale sign is how fast it is. Thread will fast. Bluetooth can be fast, but it after 30s the connection will drop and then it will be quite slow.

vestal shuttle
#

ok, I stopped the multiprotocol addon to test it 😄 ... anyway, thank you @vapid shell for the explanation!

vapid shell
#

If it didn’t work (the sensor says disabled) and you are using SkyConnect then the most common problem is Bluetooth range or interference blocking the request to join thread.

#

The nanoleaf firmware always throws an error when asked to join thread

#

So we have to ignore the error and then wait to see if it appears on thread

#

But that means we can’t tell what went wrong very easily

#

It’s using the same api as it uses to control the light. So if it ignores on/off commands, it’s definitely a problem with the Bluetooth connection.

#

The other thing can go wrong is if the thread integration doesn’t know the network details. You can tell that in the thread panel. If will try to use your preferred network. If you don’t have one it won’t work.

digital salmon
#

Hi, yesterday I installed a new Bluetooth dongle to my HA Yellow. After that I activated/configured the HA Bluetooth Integration for this dongle, resetted one of my EVE Energies and saw the device popping up through the homekit_controller integration.

Ok, I didn’t know, that it uses the homekit_controller integration to pair Bluetooth devices. I thought it gets a new device via the Bluetooth integration. I am new to Home Assistant…

So, I removed the Bluetooth Dongle, removed the Bluetooth integration for this Dongle and tried the same thing again. The CM4 Board of my HA Yellow has Bluetooth and Wifi integrated.

This time I wanted to use the CM4 onboard Bluetooth. I resetted the EVE device to factory defaults again, and tadaa the EVE Energy is recognized by the homekit_controller. Yehaa…, so the extra Bluetooth Dongle is not needed for my HA Yellow testing machine. But it has its purpose. I maybe need it for my server, where I use a SkyConnect. 😃

Now I paired the EVE Energy via the integrated Bluetooth of the CM4, changed the device to use the preferred thread network instead of Bluetooth and 💥 it was connected via Thread. 😃👍

Great, but now I am unsure, if I really want it that way. My Apple Thread network is absolutely stable. I don’t want to loose the update capability of my 35 EVE devices and I don’t want to have two Thread networks. I think I am going to wait for Apple using Thread 1.3.0, HAOS 10 and credential sharing between Apple TBR and Open TBR.

devout iris
#

If it's doing everything through DNS-SD - why wouldn't it be able to perform a FW update?

vapid shell
#

Yes you do

#

Homekit by design only allows a single controller

#

Firmware update is also not standardised by homekit so we can’t easily do firmware updates ourself

devout iris
#

Is Nanoleaf different? The Nanoleaf app acts like it would be able to update bulbs - it reports the correct version - even of the ones on HA OTBR. Of course it thinks they are connected via BT - but that's understandable.

vapid shell
#

Nanoleaf android app probably could do an update

#

But not over homekit

devout iris
#

I'm not sure the Nanoleaf iOS app does FW updates via HK.

#

It reports the FW version - but I have never seen it go through the Home App downloading, etc process. Update FW from Home app launches Nanoleaf app.

#

Plus I'm 100% certain it does them from phone via BT.

vapid shell
#

Is it seeing the homekit bridge version of your light ?

#

What’s the serial number?

#

If it’s like light.something then no

devout iris
#

Yes, it's the HA entity ID. But... If I go into the Nanoleaf App, I can see all of my bulbs.

vapid shell
#

If the nanoleaf app is seeing your homekit bridge bulbs (and it would, it sees my hue bulbs) then it won’t be able to map that back to an ip or Bluetooth MAC address so I don’t see how updates would work

devout iris
#

That makes sense.

#

I thinks it can update them - but when it actually tries to connect it will probably crash.

#

That's usually what happens with the Nanoleaf app. Anything remotely off the happy path and exit to desktop.

#

In other news it looks like this SkyConnect barfing on soft reboot issue is somewhat repeatable.

#

The happy news about that is simply unplugging and replugging the SkyConnect and then restarting the add-on fixes it.

#

So basically, if I reboot with SC connected directly to Pi - no problem. If I reboot with SC connected to powered hub - the SC requires a hard power cycle before it will work again.

#

Seems like a SC firmware bug.

#

Sonoff Zigbee and SI Labs ZWave sticks handle the same scenario with aplomb.

#

Also it seems there is a startup race condition with HK.

#

If the HK bridges for Zigbee and ZWave start before Zigbee and Zwave services, HomeKit thinks those bridges are "not responding" until I reload that bridge.

half marlin
#

can i group 6 bulbs into one? my light needs 6 bulbs but i want to controll them like its one

serene prawnBOT
half marlin
#

thanks just found it ;D

#

sorry for being lazy

devout iris
#

@vapid shell I have a new one - one of my Nanoleaf bulbs is showing "unavailable" in the HK Controller integration - but it's very much alive in Discovery and I can ping it no problem. Reloading the HK Controller does not help. I can't point to a specific event that may have caused it. I guess it's possible HA was restarted while it was physically powered down - but I'm pretty sure I've had other bulbs recover fine from that issue.

#

It's the only one out of about 30 of them that has had an issue since I started testing with the beta.

#

Restarting HASS fixed it.

foggy dawn
#

Anyone here know if it's possible to hack insignia smart things to work with home assistant?

#

Haven't been able to find much help on the internet and thought it would be nice to be able to use these plugs that have been sitting around with the insignia app getting closed

devout iris
foggy dawn
#

I don't know, model number is NS-SP1X7

devout iris
foggy dawn
#

Yea

devout iris
#

Which is kind of a weird choice for a smart plug. Usually those are used in android devices and even some routers.

#

I don’t see any Home Assistant references to it. Expensive MCU for an outlet.

foggy dawn
#

Any chance of flashing something useful onto it you think?

devout iris
#

Well, it’s a pretty old module - and the fact there’s nothing out there for it probably means it’s not opensource-based.

#

Unless there is an SDK and compiler out there in the public domain - probably not.

#

Looks like it was used in some infineon products years ago.

#

I think their SDKs are all private.

foggy dawn
#

I had taken one apart yesterday and saw the ampak chip and also an STM32 F030C6T6 chip and figured the ampak one was the wifi controller and the stm one was the main processing unit

#

But I'm not as well versed in the hardware side of computer science as I am the software side

devout iris
#

Huh. Surprised they would need more than the MCU for a smart plug.

#

Does it do power monitoring?

#

Either way, if you want to hook up UART pins from those chips to a Pi or USB UART bridge, you can probably dump the firmware off of them and get some idea what’s going on… But with 2 controllers and one of them being an older proprietary platform…

#

No wonder they discontinued it. They were probably spending a fortune on parts and dev resources when everybody else was dropping a cheap ESP module in there and calling it a day.

vapid shell
# devout iris <@245932454391709696> I have a new one - one of my Nanoleaf bulbs is showing "un...

Wanted to ack this before it dropped too far into the scroll back. Probably not going to have much time to dig in for a week or two, but if it is recurring I’d be interested debug logs. Wait until it breaks then turn them on through the Ui. I need about 2 minutes worth to make sure I see at least one poll attempt. It’s going to be noisy as hell with 30 devices. For this I wouldn’t do it through configuration.yaml because it’s so noisy and we don’t know how long to the next failure.

#

I’m interested in whether it’s ip has changed and Ha hasn’t picked it up OR whether it’s getting into a state where it’s trying to use stale encryption keys and not getting fresh ones.

#

Or some other state that I can’t imagine!

foggy dawn
foggy dawn
devout iris
#

The basic circuit is dead simple - chip RX/TX reversed to Pi RX/TX, connect ground - and done.

#

Of course there is stuff you have to do to make the Pi UART available and not a console terminal - it’s pretty easy too.

solid lantern
dusty bay
#

Hey does anyone know how to setup nanoleaf lightstrips via thread if so can you help me?

vapid shell
#

You set them up with homekit_controller. It’s pretty easy, lots in this channel have done it if you scroll back.

#

If you have a HA Yellow or SkyConnect that is set up correctly and working Bluetooth on your HA then you can pair the light strip over Bluetooth and then there is a button to transition it to your thread network.

#

If you have iOS and a HomePod or Apple TV that is working as a border router then you pair the light strip with iOS, verify it’s connected to thread, then unpair it from the iOS app. Do not reset it, if your network is working properly ha will see it immediately.

#

There are other options if you have other network gear

devout iris
#

I'm sure it's primarily a security concern - if they open Pandora's box to anyone who wants to peek at Thread datasets, lots of ... things could happen. And ultimately HA is playing in the same space with anyone currently working on a Thread/Matter hub - which presumably is who they give this entitlement to.

hoary harbor
#

Does Android make you request permission to use their thread API?

boreal crescent
#

No, any app can interact with it on Android

#

It will ask you, the user, for permission before the app receives data

hoary harbor
#

Dumb that Apple is so uptight about it then

west jetty
vapid shell
#

The eve app (which works for any homekit stuff) can tell you about he thread connection

west jetty
vapid shell
#

In the iOS app, go onto settings and then “Remove Xxxx from Home”

west jetty
vocal stream
#

I've been reading about skyconnect and am a bit confused about the current state of affairs. I read that the multi function (concurrent zigbee and thread) requires HA os and wouldn't initially work with core installs. However, I see that it works for zigbee alone in core. My question is, does it (or would it) work for thread alone in core?

vapid shell
#

Thread and zigbee are similar but at the same time also quite different. But with thread you need something to act as a router that forwards ipv6 packets between your lan/wifi and the thread mesh.

#

That’s the border router (and we need to use your SkyConnect to build a border router)

#

So you can use any border router, as long as you have a way to provision devices onto the same thread network as that border router.

#

Then any WiFi or Ethernet devices on the same vlan as the border router can access them. That includes haos or ha core.

#

To make a border router with SkyConnect without HAOS you need to use OTBR

#

You’ll also need to install thread compatible firmware on your SkyConnect.

#

it ships with zigbee firmware.

#

The reason we say it’s haos only is because on HAOS the ultimate experience will be you plug in your SkyConnect, press one button and it will be flashed with multi-pan firmware. The HA version of OTBR will be installed and configured. A new thread network will be added to the OTBR and HA will import it. ZHA will also be configured for multi pan. That’s orchestrating the setup of like 4 different integrations and addons.

vocal stream
#

Thanks so much for the detailed explanation and pointing me in the right direction. I'll read up more on otbr

rapid umbra
#

Think something’s jacked up with my thread network

#

Noticed most devices were down, tried to reload OTBR integration after rebooting a couple times and it failed

#

Took a look at the silicon labs multiprotocol addon logs and it was completely filled with

2023-03-12 19:14:59 core-silabs-multiprotocol universal_silabs_flasher.cpc[238] WARNING Failed to parse buffer bytearray(b'\x14\x0cj\x00\x00\xc4\x9e\xa0\x06qI\x00A\xd8\x9a\xa9\x86\xff\xff\x01\x82\xf0\xcf\xe6\x8aV\xee\x7f;\x01\xf0MLML\x08\x04\x00\x151\xa3\x00\x00\x00\x00\x00\x00\x01\x99\x05\xdf\x1b\xf1>\xb4\xd11\xf7\xf5(r\x03y\xe0<\xf9\xd3\x15m%\x02\xe7\xb6\xdcO[\xba\xb62\x1c\x02\x06\xd3\x00\x00\xb7\x80\x00\x00\n\x00\x0f\xce\xd34N\x0e\x00\x00\x00\x00\x01\x00\x00\x05\x00\x00\x00\x00\x00\x00\xfdi'): ValueError('Unsupported frame type: <FrameType.INFORMATION: 1>')

#

I went to the addon configuration and disabled “Automatically flash firmware”

#

And then after restarting the logs seem to be fine until it gets to this and then keeps repeating forever

[19:18:43:100877] Info : use_noop_keep_alive = false
[19:18:43:100879] Info : reset_sequence = true
[19:18:43:100882] Info : uart_validation_test_option =
[19:18:43:100884] Info : stats_interval = 0
[19:18:43:100886] Info : rlimit_nofile = 2000
[19:18:43:100889] Info : ENCRYPTION IS DISABLED
[19:18:43:100891] Info : Starting daemon in normal mode
[19:18:43:117406] Info : Connecting to Secondary...
[19:18:45:118156] Info : Failed to connect, secondary seems unresponsive
[19:18:45:118200] Info : Connecting to Secondary...
[19:18:47:118438] Info : Failed to connect, secondary seems unresponsive
[19:18:47:118467] Info : Connecting to Secondary...

#

Running on

Home Assistant 2023.3.3
Supervisor 2023.03.1
Operating System 9.5
Frontend 20230309.0 - latest

upbeat cairn
rapid umbra
#

I have, still no dice

#

2023-03-12 19:49:37.379 WARNING (MainThread) [homeassistant.components.hassio] Could not fetch stats for core_silabs_multiprotocol: 404 Client Error for http+docker://localhost/v1.41/containers/addon_core_silabs_multiprotocol/json: Not Found ("No such container: addon_core_silabs_multiprotocol")
2023-03-12 19:54:43.274 WARNING (MainThread) [homeassistant.components.hassio] Could not fetch stats for core_silabs_multiprotocol: Can't read stats from addon_core_silabs_multiprotocol: Expecting value: line 1 column 1 (char 0)

#

Only other relevant home assistant logs I could find

#

seems like something with the OTBR docker container might be messed up?

dusty bay
#

does anyone know how to update nanoleaf lights when they are connected through homekit controller through thread

vapid shell
normal arch
#

@rapid umbra looks like your add-on container is broken. Try disabling the ZHA integration, stop the add-on (if started), backup your config if required, delete the add-on. Reboot the host, re-add the add-on, configure it, start it then re-enable ZHA.

vapid shell
#

Note that if you do ^ and don't backup and restore your core_silabs_multiprotocol data volume this will likely cause you much upset:

  • HA can't sync the thread credentials back from HA to the now unconfigured OTBR, so all of your devices will remain unreachable until you reset them and re-pair them
  • The thread integration will have a preferred thread network that no longer exists. The UI elements to switch preferred networks don't exist yet.
  • The otbr integration will also be in a weird state. it should try to pull the latest credentials from the OTBR at start up but (A) your OTBR is now unconfigured and (B) because you already have a preferred network, the new one won't replace your old one. So even if you manually configure the OTBR, it won't help.
#

I think the previous case, a full HAOS power cycle and unplugging and replugging the skyconnect was all that was needed to recover.

twin geyser
#

I have HA in docker. So cannot use the add-on for openthread. However, have installed the OTBR docker from https://openthread.io/guides/border-router/docker i am able to get it running with nrf rcp. I am also able to commission another node via the ot-cli. But when integratiing to Home assistant, it requires api endpoint - ot docker has only the web ui endpoint not api. Any suggestion on how do i connect to HA?

vapid shell
#

Strictly speaking as long as your ipv6 setup is sound and you are happy maintaining OTBR manually you don’t need the OTBR integration.

#

I would add the thread integration

#

Then get the active dataset with ot-cli - I think it’s ot-cli dataset active -x

#

Then in the thread dashboard there should be a menu option to add that hex string

twin geyser
#

okay I am happy managing the OTBR, but in the thread integration in HA, it asks for the OTBR's API. The OTBR from openthread image does not have any API endpoint that I know of

sick swan
#

That should be the OTBR integration. The thread shouldn't ask for an OTBR API, afaik?

#

The OTBR integration uses the REST API on port 8081, but we had to extend it. So if you installed it from vanilla upstream, the REST API won't be enough.

twin geyser
#

In the thread integration in HA - it asks for OTBR - "Provide URL for the Open Thread Border Router's REST API" . Ah I think it is the same thing, Since this thread has no network and needs to connect to OTBR. So the question is back to sqaure one. How do I connect to vanilla OTBR via HA

sick swan
#

Right, I see, that is part of the the Thread integration (which really confuses me, but that is another topic)

#

So currently, addiing OTBR is really the HA OTBR flavor (with the extended REST API). If you built your own, you can add your network but you have to use the TLV method

twin geyser
#

ah okay. but where do you get this option? in the Thread configuration card there is no such option that I see - I can see only Download diagnostics

vapid shell
#

That menu item is the one I meant. Don’t know why you can’t see it.

#

There was talk of it being unexpectedly missing around the March release, I assumed it was fixed (as it clearly does work for some people)

twin geyser
#

thanks. let me load like this to see if it works.

west jetty
# vapid shell In the iOS app, go onto settings and then “Remove Xxxx from Home”

Update. When I removed from home in Eve, HA immediately showed it as a new device that could be configured. As soon as I clicked to configure, I was met with a screen asking for my pairing code and met 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: [Errno 113] received through errqueue". Should I take that at face value? I do have SkyConnect with multipan and a homepod, and HA sees both border router networks. I tried with just one, same issue. Needless to say entering the pairing code didn't do anything.

vapid shell
#

Errno 113 is usually a sign of bad ipv6 or multicast networking

#

I can talk you through the usual things but I’ll be slow as about to leave for work

#

I need to see your thread diagnostics download to start with

west jetty
half marlin
#

i keep getting errors in my logs

Logger: aiohomekit.controller.coap.pdu
Source: components/homekit_controller/connection.py:244
First occurred: 17:53:33 (27 occurrences)
Last logged: 17:55:07

Transaction 0 failed with error 6 (Invalid request

AND ---------------------

Logger: aiohomekit.controller.coap.connection
Source: components/homekit_controller/connection.py:244
First occurred: 17:54:17 (8 occurrences)
Last logged: 17:54:43

Decryption failed, desynchronized? Counter=0/1
Failed flailing attempts to resynchronize, self-destructing in 3, 2, 1...
Decryption failed, desynchronized? Counter=7/8

AND ---------------------

Logger: homeassistant.config_entries
Source: config_entries.py:1244
First occurred: 17:54:06 (10 occurrences)
Last logged: 17:54:33

Config entry 'Eve Motion E09C' for homekit_controller integration not ready yet: failed to connect; Retrying in background
Config entry 'Nanoleaf A19 699Y' for homekit_controller integration not ready yet: failed to connect; Retrying in background
Config entry 'Nanoleaf A19 85JR' for homekit_controller integration not ready yet: failed to connect; Retrying in background
Config entry 'Nanoleaf A19 0622' for homekit_controller integration not ready yet: failed to connect; Retrying in background
Config entry 'Nanoleaf A19 2YVW' for homekit_controller integration not ready yet: Decryption of PDU POST response failed; Retrying in background

#

anyone can help me with that, im kinda less experience with thread and Homeassistant...

quick bronze
#

@half marlin please... use a code share site for walls of text/log like that - see #rules

half marlin
#

ah ok sorry

quick bronze
#

It's a really shit thing to do to mobile users - or anybody with a smaller screen/larger fonts

half marlin
#

sure i understand

vapid shell
#

Check your OTBR logs (in ha addons)

halcyon quartz
#

Just wanted to thank you for these instructions - solved my problem!

devout iris
#

Anyone have any experience building OTBR with gecko libs from code?

autumn merlin
#

Hi All - Should i have Automatic flash firmware enabled in the SL add-on? I notice we have an update this morning (note using the multi Multiprotocol firmware).

half marlin
half marlin
vapid shell
half marlin
#

ok

vapid shell
half marlin
#

well then idk whats the prob

#

ah ok

vapid shell
#

So lots of errors routing traffic to the mesh.

half marlin
#

ya but why?

#

its all fresh setup with a clean HA installation

vapid shell
#

Computers

#

Doesn’t matter how fresh it is

half marlin
#

its maybe because the skyconnect is at the very end of my home?

#

i should position it more in the middle of everything?

vapid shell
#

Maybe

#

Like it should work as long as the mesh hasn’t partitioned

#

But there are so many moving parts

half marlin
#

so where i start troubleshoot, and how to monitor it?

vapid shell
#

There’s a limit to what you can do

#

It could be a bug in one of the devices that means that they run out of memory or get slower at routing

#

obviously we don’t have logs for random vendors devices

half marlin
#

thats all nanoleaf bulbs and eve motions

#

but there has to be something i can try?

vapid shell
#

I’m on my phone so I need a moment to actually type stuff 🙂

half marlin
#

ok ^^

vapid shell
#

Eve motions won’t act as routers (they are battery powered)

#

So really it’s about the nanoleafs

#

We know they are using a crap cpu because it’s too slow for matter

half marlin
#

ah ok

devout iris
half marlin
#

so everybody should see this errors when using anoleaf

vapid shell
#

No

#

It could be a combination of interference on the channel you are using, the weather, the distance between your devices, the topology they have formed

halcyon quartz
half marlin
#

so its a good try to move the BR in the middle of all devices?

vapid shell
#

It’s worth a shot

#

It’s also worth power cycling the bulbs

half marlin
#

did that allready

devout iris
half marlin
#

powercylce

devout iris
#

How far from your SC to the nearest bulb?

half marlin
#

6 are in the same lamp and this lamp is just 3m away without walls

#

then the next are 4m and then 4m and so on

#

but SC is and the very end of all blubs, think about it like a long line instead of a cycle

#

my whole HA is full of errors.....

devout iris
#

Here's what I would do: Power off all thread accessories. Power up only the nearest one to the SC. Test, give it some time. Test again. Add the next closes POWERED accessory. Rinse, repeat. If you are still okay, then power up the battery-powered ones.

#

It really shouldn't matter unless you have like tens of hops. And at the distances you are talking about they can for sure all see the SC without a problem.

half marlin
#

to see its a range problem right?

devout iris
#

Yeah, I really doubt that.

#

Could be interference - but likely not range.

half marlin
#

but what interferance, its really not much here, even my wifi is very well optimized with the ppl around me

devout iris
#

More likely something's in a weird state and bringing them on one at a time could help either isolate or eliminate the weirndness.

#

Also, you are forcing a re-selection of the leader - and it will be one that's really close to the SC. Which is good.

half marlin
#

or is rasPI to weak for my thread network?

devout iris
#

Which Pi?

half marlin
#

4

devout iris
#

You can monitor the CPU/Mem under hardawre settngs to see if you are puhing the limits - but the OTBR project largely uses Pi3 as a dev/test platform.

half marlin
#

i will power on anly the nearest bulbs and kill all the other to see the issue persits

devout iris
#

Give it several minutes between adding each successive one.

half marlin
#

?

devout iris
#

Add the closest one. Wait...

half marlin
#

sorry my english sometimes lags ^^

devout iris
#

Add the net one. Wait...

half marlin
#

sure just thes ones for the next 30 min

devout iris
#

Also, you should probably wait until the dns-sd entries time out for all of them before you add the first one back.

#

Do you have iOS or Android?

half marlin
#

ios

#

??

#

still waiting for erors, right now only the closest blubs (6) are connected. fine so far.

#

my log is full of thes ones:

#

otbr-agent[305]: 00:41:32.865 [W] Mle-----------: Failed to process UDP: Duplicated
otbr-agent[305]: 00:41:32.970 [W] Mle-----------: Failed to process UDP: Duplicated
otbr-agent[305]: 00:43:03.351 [N] MeshForwarder-: Dropping (reassembly queue) IPv6 UDP msg, len:246, chksum:333d, ecn:no, sec:yes, error:ReassemblyTimeout, prio:net, rss:-69.0
otbr-agent[305]: 00:43:03.351 [N] MeshForwarder-: src:[fe80:0:0:0:9468:5bfa:348a:ce93]:19788
otbr-agent[305]: 00:43:03.352 [N] MeshForwarder-: dst:[ff02:0:0:0:0:0:0:1]:19788

#

i can read that, but i dont know what it means...

#

i will reenable ipv6 on the ips router, i think that...

vapid shell
#

The ipv6 packets don’t leave your HA box so@it won’t help

half marlin
#

ok...

#

i disabled all the thread devices and i keep getting errors

vapid shell
#

Well yeah

#

Ha is presumably trying to send udp packets to devices that aren’t there

#

Then OTBR is trying to forward them to mesh nodes that aren’t there

half marlin
#

ah ok, well thats the deactivated ones then?

#

ok then its normal, i missunderstood

vapid shell
#

I don’t know for sure without mapping out every device, but we are going to be trying to@reconnect in the background for every unplugged device

#

The reassembly bit I’m unfamiliar with

#

But I do know that packets get duplicated if they aren’t delivered

half marlin
#

puufff i dont know.. its frustrating...

vapid shell
#

In case radio transmission fails@

half marlin
#

well but there are no other errors, exept the one i posted lately

#

i maybe activate another bulb?

#

i can somehow see the topology of the thread network?

#

like u can see it in the eve app, its very nice there..

half marlin
#

wow ok u made that one? nice...

devout iris
#

Lol. Finally figured out how to build everything on an nRF52840 board. Fired up OTBR on my test Pi, joined the network, and my new OTBR immediately took over.

devout iris
#

Okay, after a restart they seem to be peacefully co-existing...

vapid shell
#

Nice

devout iris
#

Would be nice to show the OT logo next to any OTBRs detected - like HA and Apple routers show.

#

also there is a new meshcop record for this BR - omr.

#

Suspicions confirmed on the diagnostics REST stuff. The timeouts were waaay out of whack.

#

Setting a 2-minute expiration time for diagnostics data results in much better stability for topo GUI.

#

The default is 3 seconds.

#

I learned a lot today.

#

Like, if you flash the cli image onto your SOC - it does everything it's supposed to when you connect with screen but OTBR only wants to talk rcp - which is not included in the cli firmware.

#

How do we determine the appropriate time after which dns-sd forgets about a thread node?

#

Seems like that would be an appropriate diagnostics timeout value.

#

It would be nice to be able to map RLOCs to HASS devices somewhere sort of the way Zigbee and ZWave UIs work.

vapid shell
#

It’s a little bit tricky with thread because of the separation of the mesh and app protocols

#

Like homekit_controller creates the devices in Ha but it doesn’t know whether there is even thread involved much less what network or what rloc, it’s just spewing udp to some rando address from zeroconf

#

I was thinking of wiring it up in the homekit diagnostics so if it was using an OTBR that Ha had access to we’d get the same stuff that’s in the topology view, as there are less ux concerns there

twin geyser
#

The OTBR is the official openthread version - rcp is nrf52840 dongle - running as a docker container with network host. There is another dongle flashed with ot-cli-ftd (running on another machine)- which is correctly connected to OTBR when the data set is provided i.e., it shows up on the topology of the web hosted by otbr (see image above). In HA, again on a different machine, but the same dataset provided for the HA, does not seem to recognize the OTBR. I also don't see any logs in OTBR container. All the three machines are in the same network. I somehow don't see any logs related to OTBR connectivity in HA. Any suggestions for debugging?

twin geyser
devout iris
vapid shell
#

Make sure you are using host mode networking

twin geyser
devout iris
vapid shell
#

Your OTBR should be broadcasting a _meshcop._udp service, if it’s not your OTBR won’t be seen by ha

devout iris
#

OTBR needs the mdns daemon as well - and the OTBR project has everything built and configured from those scripts.

twin geyser
vapid shell
#

No if it’s a network issue there are no logs for data that ha hasn’t see because by definition it doesn’t know what it doesn’t know.

twin geyser
vapid shell
#

Use a zeroconf browser to check for meshcop services

twin geyser
devout iris
#

Yeah - look at the raspberry pi tutorial on the openthread.io site.

#

If you attach to the docker container and run tail /var/log/messages | grep otbr you should see if there are issues.

#

Use thier scripts.

#

Use bootstrap and use setup

#

Also, you should see happy messages when you look at:

twin geyser
#

okay let me check, since I have been running that OTBR from earlier and it used to connect to other various nrf52840 dongles for the custom temp and humidity sensors. I thought HA would be just another client connecting fine.

#

my zeroconf browser seems to have problem loading. Let me fix that first

devout iris
# 
sudo service mdns status
sudo service otbr-agent status
sudo service otbr-web status
#

And the RCP firmware needs to be the same version as OTBR.

twin geyser
#

thanks. will check - since I am running OTBR as a docker, those status not available. but will setup after i checked on the zeroconfig

devout iris
#

make sure your etc/default/otbr-agent is correct as well.

#

What do you get if you run sudo ot-ctl state

twin geyser
devout iris
#

You can also quick check zeroconf with 'dns-sd -B _meshcop._udp.'

#

Oh - well that's good.

twin geyser
devout iris
#

Hmm. OTBR seems happy.

#

Oooh.. That's another machine.

#

So your issue is that HA Thread integration doesn't show your OTBR?

twin geyser
#

So here is the setuip

  1. MAchine 1: OTBR running as a docker container. Connecting to nrfdongle 1 as a RCP
  2. Machine 2: Just a nrfdongle 2 with screen and connected as child / router to Machine 1. I can send UDP messages fine. In fact i have bunch of other custom written temp and hum sensors
  3. Machine 3: HA runnnig as docker in network mode: host and connected via eth. to this network. HA does not have any nrfdongle
twin geyser
devout iris
#

Yeah. Hmm. @vapid shell is the real expert on that integration. I've never tried it without the SI Labs add-on - so I can't really comment on what it should do. But you're right - OTBR seems happy otherwise.

twin geyser
#

I was hoping that if HA recognizes the OTBR, I could then connect my nrfdevices with temp and humidity and they would show up in HA

twin geyser
devout iris
#

Ultimately it shouldn't make a difference because OTBR will route your mesh to your infra network. HA doesn't really care whether you are using its OTBR or another one.

#

But HA not seeing it is a symptom of something.

#

Oh - I have a thought. Docker is a hot mess with IPV6.

#

It's possible there's no IPV6 connectivity between your HA docker and your OTBR.

#

I could never get Thread to work with HA Docker.

twin geyser
#

maybe. but it is in the same network (hosted by pfsenses) as other machines, so if other nrfdevices - running as FTD, MTD are able to communicate, not sure why HA cannot. I run my other custom application also in docker which takes in this ipv6 data. So not sure why HA docker would have problem. Anyway, one more thing to check

devout iris
#

Can you do a dns-sd name resolution of your OTBR from within the HA docker container?

twin geyser
#

ah! why haven't I tried that yet

devout iris
#

In my case it was Synology - which was at least part of the issue with docker and IPV6.

#

So I just built HAOS on a Pi4 and called it a day. Never looked back. haha.

#

And if that works - try to ping6 one of your thread devices.

twin geyser
#

this docker thing is dev ops part only before I shift them to k3s

devout iris
#

Because that's all that thread is really accomplishing anyway - to get those thread devices reachable from your local network.

twin geyser
#

you were correct, the HA container does not see the machine hosting otbr container. In the otbr container, I see these, so thats the root cause potentially

Mar 15 23:47:45 raspberrypi avahi-daemon[132]: Host name conflict, retrying with raspberrypi-163
devout iris
#

Well now at least you know what you need to fix

#

Kudos for getting all of the OTBR stuff built and running.

twin geyser
#

yep. wonder how the machine 2 with just nrf was able to connect....edited Ignore, this is directly connecting over air

devout iris
#

Going to be away until tomorrow. Best of luck!

twin geyser
#

thanks!

toxic kiln
#

theoretically, "ESPHome-over-Thread" should be a thing that's possible, right?

#

maybe if you squint your eyes a little?

rare ibex
toxic kiln
#

oh that's awesome

rare ibex
#

there is a thread over in the esphome discord in the dev channel. its a single developer who seems to work on it in spirts.

twin geyser
twin geyser
#

So moving on after OTBR is installed, is there a way to connect the sensors in my thread devices (custon ones) to create entity in HA? I assume i will have to use COAP? Is mqtt-sb used? and how to enable?

vapid shell
#

personally i'd like to see a thread version of ESPHome that spoke ESPHome protocol over thread, so we could leverage the ESPHome integration for them. but thats not possible right now.

twin geyser
#

Thansk for the detailed reply. I do have my own custom server which accepts the UDP, from the thread devices. Let me now work on matter examples and try to implement

#

And will check that esphome om thread that tube shared

devout iris
#

That would at least give us a device name.

vapid shell
#

Yep, that’s exactly what I’ll do for diagnostics probably. But for anything in the Ui we’ll need to define a proper api boundary between thread/OTBR/homekit_controller/matter

devout iris
#

Sure sure. I'm really only thinking in terms of diagnostics and monitoring.

#

And once you have a device name, you can look it up in HK.

#

Just thinking we could have a really nice thread browser utility. Something better than the Eve app.

#

Heck, that would be really easy even now from an Apple device with the REST interface on OTBR.

#

We could have something that rivals the network tab for Zigbee or ZWaveJSUI

warm hedge
#

Hello, I'm having issue with some nanoleaf bulb becoming unavailable and after few moment change status to thread router by it's own. Has anyone had this problem before?

vapid shell
#

hi there! there are lots and lots of variables, so depending on what networking gear you use, how you run HA, and many other things... the answer might be yes or it might be no!

#

if things keep changing status between child and router/leader, it means your mesh is re-organizing itself. its not neccesarily a problem.

#

unfortunately things going unavailable in the first place is much tougher to answer.

#

if you have e.g. HAOS and homepods or ATV's you might have the "ghost routes" problem (NetworkManager on Linux can't remove expired border router routes so linux keeps trying to use stale ip addresses until you reboot the entire OS)

#

but it could also just be mesh signal quality issues too - we've seen turning off appletvs "fix" mesh stability issues.

warm hedge
#

I see. I'am running a supervised HA on my NAS true a VM. I'm using a homepod mini as thread router. I also have some hue device which are working without any issue. Only nanoleaf bulb are having this issue. I also have an eve motion sensor on the thread network without any issue.

vapid shell
#

the eve motion sensor is also connected to HA?

#

you can look at your thread diagnostics during an outage to see if you have the ghost routes problem - there is a key that says "unexpected_routers", it should be empty. because of the way linux routing works you might consistently hid a bad route for one ip and a good route for another, which could explain the differences. if thats the case i'd expect rebooting the whole vm to resolve the issue for a little while

#

if you only have a single homepod, making sure you have NM 1.40 (i think) or greater should resolve the problems.

warm hedge
#

Yes, I have it running with HA for days before reinstall everything yersterday. I decide to add only one nanoleaf bulb to check if the issue will be resolved by reinstalling everything but it's seem not. For now eve motion & my other bulb are one homekit

vapid shell
#

(with ghost routes, not all the other problems)

#

unfortunately the iOS Home app is not a reliable indicator of your thread networks reliability.

#

HA helpfully compiles a database of when things were down for you to look at at your leisure

warm hedge
vapid shell
#

where as Home, you have to look at it during an outage

#

NM = NetworkManager

#

if you use HA Core, you don't use NetworkManager and don't have the ghost routes bugs

#

if you use HAOS, you'll get the fixes in HAOS 10

#

for supervised... i have no idea how you get NetworkManager

warm hedge
#

I have installed it on the linux debian machine before installing the supervised version on it

vapid shell
#

So what version is it?

warm hedge
#

let me check

#

1.30.6

vapid shell
#

Right so that’s pretty old, I’m pretty sure you’ll have the ghost routes bug

warm hedge
#

Ok, I will update and tell you if it resolve the issue

devout iris
#

Getting slow thread response and some troubling HK controller log entries…

# 
Logger: aiohomekit.controller.coap.connection
Source: components/homekit_controller/connection.py:770 
First occurred: March 17, 2023 at 9:03:30 AM (26753 occurrences) 
Last logged: 9:34:15 AM

Decryption failed, desynchronized? Counter=12/13
Decryption failed, desynchronized? Counter=11/12
Decryption failed, desynchronized? Counter=0/2
Failed flailing attempts to resynchronize, self-destructing in 3, 2, 1...
Decryption failed, desynchronized? Counter=9/10```
vapid shell
#

Don’t worry too much about the logs

devout iris
#

But everything also really slow.

vapid shell
#

Yeah

#

So those logs can be a sign you are seeing packet loss

#

The HK encryption uses a counter

devout iris
#

And setting attributes on light group helper only partially complete.

vapid shell
#

Every packet bumps the counter

#

So in effect each packet gets a new key

#

Same in reverse too

#

Because of packet loss we sometimes guess neighbouring encryption keys to compensate for lost packets

#

If too many packets were lost we drop the session key entirely and reconnect

#

So from hkc point of view we are behaving normally despite adverse network conditions

devout iris
#

Also seeing a bunch of these

Logger: aiohomekit.controller.coap.pdu
Source: components/homekit_controller/connection.py:770 
First occurred: March 17, 2023 at 9:04:31 AM (12230 occurrences) 
Last logged: 9:33:25 AM

Transaction 0 failed with error 6 (Invalid request)```
vapid shell
#

Now the thread tier that’s a different kettle of fish

#

That’s also harmless

#

We are trying to read a write only characteristic

#

Just need to find time to add it to the skip list

devout iris
#

And then there is…

Logger: homeassistant.components.homekit_controller.connection
Source: components/homekit_controller/connection.py:770 
Integration: HomeKit Controller (documentation, issues) 
First occurred: March 17, 2023 at 12:24:54 PM (12 occurrences) 
Last logged: 8:08:04 AM

Unexpected exception from <bound method HKDevice.async_update of <homeassistant.components.homekit_controller.connection.HKDevice object at 0x7f9dc8f2e0>>
Unexpected exception from <bound method HKDevice.async_update of <homeassistant.components.homekit_controller.connection.HKDevice object at 0x7f8ed69900>>
Unexpected exception from <bound method HKDevice.async_update of <homeassistant.components.homekit_controller.connection.HKDevice object at 0x7f86aca9b0>>
Unexpected exception from <bound method HKDevice.async_update of <homeassistant.components.homekit_controller.connection.HKDevice object at 0x7f80c9f3a0>>```
vapid shell
#

Not enough context to be sure

#

The full trace back might help

#

Given the number of different HKDevice object addresses (ie implying it’s a problem with multiple devices at once)

#

I’m guessing also a symptom of mesh instability

#

Like a timeout is getting raised

#

And nothing is handling it so it just bubbles up to that method

devout iris
#

ValueError: 7 is not a valid PDUStatus

#

That’s the last item in the trace back.

vapid shell
#

I’d be interested in seeing what your OTBR error metrics looked like

devout iris
#

Like the Mac counters?

vapid shell
#

But I won’t be able to look at any of this properly now for a few weeks

#

Yeah there’s a bunch of error counters for every device, I think mac is one.

devout iris
# 
"MACCounters":    {
            "IfInUnknownProtos":    0,
            "IfInErrors":    6082,
            "IfOutErrors":    205232,
            "IfInUcastPkts":    4139591,
            "IfInBroadcastPkts":    1953202,
            "IfInDiscards":    167643,
            "IfOutUcastPkts":    4017138,
            "IfOutBroadcastPkts":    123807,
            "IfOutDiscards":    647
        }
#

For example…

vapid shell
#

Bit useless without it being in Prometheus

#

Are the error counts going up?

devout iris
#

Yeah, so this may have started when I added that other OTBR.

#

Beware the Ides of March…

devout iris
#

Welp. I can reliably crash OTBR in the latest add-on update by spamming the reload button on the topology Web UI.

#

That's new behvior.

half bluff
#

I noticed that before as well. How did you get the topology web ui to appear again?

vapid shell
#

It’s hidden because of quality issues. I think there’s no longer an ingress for it either. But you can enable to port in the addon settings.

devout iris
#

But it's really garbage.

normal arch
#

Where is that setting to turn it on? I don't have the option in my silabs multiprotocol add-on.

half bluff
zenith tusk
#

kinda a newbie question, if i have a nest hub, does that mean i can control devices that are set up with thread with it from ha? i googled it and it sounds like although i cant really use it as the main network i could use devices from it or something? idk

half bluff
#

@vapid shell I just wiped out my OTBR and started with a fresh install. When I try to provision thread devices it said it worked and its a child or router but as soon as I disable bluetooth they all become unavailable. Is the homekit devices supposed to show up without rasp pi bluetooth enabled? Because mine only show up in inegrations page when I enable rasp pi bluetooth

vapid shell
#

So probably what is happening is your devices have formed their own mesh without a border router

#

So they are connected to a thread network but you are connected to them by Bluetooth

half bluff
#

How do I get them back on OTBR?

vapid shell
#

I can’t help you right now, Mother’s Day

half bluff
#

Oh shoot

#

Im sorry

vapid shell
#

But I need to check you have reset OTBR and ALL the integrations properly

#

And then hard reset your devices at worst

vapid shell
#

So theory 1 is your preferred thread network is still the old one. Right now there isn’t Ui to change this so I’d expect you to be in this state unless you manually removed the thread.datasets file (and restarted ha)

#

You should be able to confirm this on the thread ui

#

Can you send me a pic?

devout iris
half bluff
#

Do I need the bluetooth integration enabled for provisioning?

vapid shell
#

Yes

half bluff
#

Ok. Should I turn off my apple home hubs before provisioning

vapid shell
#

HA doesn’t know the keys for that so it doesn’t matter

half bluff
#

I uninstalled the addon and removed all the devices. Reboot HA and started fresh so I am hoping the thread.dataset files were wiped clean

#

The thread integration shows OpenThreadYellow "No border routers found", then the 3 apple border routers, then OpenThread "Silicon Labs Multiprotocol homeassistant.local"

devout iris
#

What devices?

half bluff
#

nanoleaf bulbs

#

I have HA Yellow

devout iris
#

Did you remove them from HA Yellow, or from Apple Home?

half bluff
#

The yellow

devout iris
#

And you don't have a backup of the Yellow with the old thread data?

half bluff
#

Umm I did a full backup of home assistant

#

But is the data in there?

devout iris
#

Yeah, it's in there. What were you trying to solve by removing them?

half bluff
#

My ZHA devices were bugged out. So I wanted to install fresh and change to channel 15 the default

#

So I just nuked my setup and restarted

devout iris
#

Oooh, you are running both zigbee and thread from the SI Labs radio...

half bluff
#

Yeah

devout iris
#

That's above my pay grade.

#

You could try a restore and then reset the zigbee stuff without nuking thread.

#

How many devices are we talking about?

#

Because I know what a pain it is to pair thread devices - especially those Nanoleafs.

half bluff
#

9 devices

devout iris
#

I guess if it were me, I would just start over for 9 devices too. Does that include the Zigbee ones?

half bluff
#

Lol no

#

I got the zigbee all paired. I will try it again later today

devout iris
#

Oof. Yeah. Blowing things away is an extreme measure for sure. There's almost always a way to fix stuff.

#

Of course my problem is this:

# 
[11:06:53] INFO: Setup OTBR firewall...
[11:06:53] INFO: Starting otbr-agent...
otbr-agent[151757]: [NOTE]-AGENT---: Running 0.3.0
otbr-agent[151757]: [NOTE]-AGENT---: Thread version: 1.3.0
otbr-agent[151757]: [NOTE]-AGENT---: Thread interface: wpan0
otbr-agent[151757]: [NOTE]-AGENT---: Radio URL: spinel+cpc://cpcd_0?iid=2
otbr-agent[151757]: [NOTE]-ILS-----: Infra link selected: eth0
otbr-agent[151757]: 50d.06:18:32.256 [C] Platform------: mCpcBusSpeed = 115200
[11:06:53:523484] Info : New client connection using library v4.2.2.0
[11:06:53:530592] Info : Opened connection socket for ep#12
[11:06:53:530758] Info : Endpoint socket #12: Client connected. 1 connections
otbr-agent[151757]: 50d.06:18:36.276 [W] Platform------: Wait for response timeout
otbr-agent[151757]: 50d.06:18:36.277 [C] Platform------: HandleRcpTimeout() at radio_spinel_impl.hpp:2297: RadioSpinelNoResponse
[11:06:57] INFO: otbr-agent ended with exit code 6 (signal 0)...
#

Over and over and over...

#

Acting like the SC is bad or something.

serene prawnBOT
#

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

📎 message.txt
devout iris
#

Lucky I have an experimental OTBR running on a Pi3 that seems to be happy to connect and take over...

#

But the SI Multi-pan addon has not been stable for me since the last update.

vapid shell
#

I it sounds like what I think but I won’t be able to help you for a few hours

serene prawnBOT
#

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

📎 message.txt
half bluff
#

I think it is using the old one.

zenith tusk
devout iris
zenith tusk
#

could you elaborate?

#

how would the devices get pulled into ha?

devout iris
#

Once they are attached to a working thread mesh with a BR (in your case Nest Hub) they are just network devices on your LAN.

zenith tusk
#

so would they be auto-discovered separately?

devout iris
#

If they announce themselves, and HA undestands how to talk to them - then you are in busines.

#

Yes - the zero-conf stuff.

#

But AFAIK the only ones HA understands today is HomeKit - and experimentally, Matter.

zenith tusk
devout iris
#

Yeah, Matter is still really, really new. A lot of the promises of interoperability are not working yet.

#

Are they Matter devices?

zenith tusk
#

wait i think i confused matter with thread

#

facepalm

#

uhhh

devout iris
#

Right - think of Thread as another radio spec like WiFi.

zenith tusk
devout iris
#

There are a couple of ways to enroll Thread devices onto a Thread mesh. Once they are on the mesh, they are just IPV6 devices like anything else.

zenith tusk
#

interesting

devout iris
#

What devices specifically?

zenith tusk
#

i dont have any, was just curious what the place of the nest hub was

devout iris
#

Ah. Well the way things will eventually work, the Nest Hub is a Border Router - so it can participate in a Thread mesh and forward traffic from the mesh to your LAN.

zenith tusk
#

from ha blog

Matter works, including Thread devices via Thread border routers from Apple and Google.

#

so yeah

devout iris
#

And with Matter over Thread - your Nest Hub will be able to enroll accessories onto Thread.

#

I meant yes it works - but it's pretty fragile in some ways. Like today it would be more accurate to say it will work with border routers from Apple or Google. The different brands of border routers don't all exactly play nice with each other yet.

#

But the nifty thing with HA is you can use HomeKit Thread devices today - without Apple border routers.

zenith tusk
#

i know this is kinda channel mixing but why do you need the matter server? is it to accept connections?

devout iris
#

Matter server is the software part that knows how to speak Matter protocol. It doesn't care about Thread.

#

Matter can work over WiFi as well. So a WiFi Matter device still needs to talk to a Matter Server.

#

The Matter Server is the in-home smart thing that makes your Matter devices work with other applications and the cloud. It serves the same purpose as an Apple Home Hub.

zenith tusk
#

and it makes sense to not make it part of ha core

devout iris
#

Or a SmartThings Hub, or whatever kind of smart hub.

zenith tusk
#

also the add matter device button says that you need the ha companion app, even though am using it and i have the latest version

devout iris
#

I think that's because you need a camera to scan a barcode.

zenith tusk
#

the phone im using it on does have a camera

devout iris
#

I've never tried it... Let's see what happens...

#

Oh I see your confusion about core and server...

#

Core is for integrations - which are the client-side parts that are bound to an accessory.

tardy thicket
devout iris
#

The server-side parts, like Matter Server are built as add-ons. Same for Zigbee, ZWave, etc.

zenith tusk
#

i think my phone just doesnt support matter

#

the error message could be better

tardy thicket
#

Some one probably needs to pin that image in here as well

half bluff
#

Ok I can get 1 device on thread but when I add a second nanoleaf the orignial one just disconnects

devout iris
half bluff
#

Yeah. But it just stops working with BLE as well

#

really weird

#

It like kicks it off

zenith tusk
devout iris
#

When it switches, there is a gap - the device goes unresponsive for several seconds, and then pops up on Thread. Every now and then it doesn't make it.

half bluff
#

I know that. This is just flat out error

devout iris
#

When that happens - you have to delete the HK Controller object, reset the device and try again.

#

So for the first device, you could control it in HA and it showed as Thread Leader (or at least Router?)

serene prawnBOT
#

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

📎 message.txt
half bluff
#

Yeah so it becomes router and works. I then add second nanoleaf and provision. That new one becomes router and old one just stops responding

devout iris
#

Never seen that happen. Usually when one is no longer responding, the HK Controller is confused and reloading it will straighten things out. I've seen that happen quite a bit soon after a device is added. Especially if you change the name.

half bluff
#

Yeah thats how it used to be. After nuking my setup this weird stuff happens

devout iris
#

What do you see in the SI-Labs Add-on Logs?

#

That's really the OTBR logs...

serene prawnBOT
#

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

📎 message.txt
devout iris
#

Hmm.

#

Just out of curiosity do you have "auto flash" turned off?

half bluff
#

no

devout iris
#

Can you capture what happens with OTBR when you restart the add-on?

#

Looks like my OTBR reboot loop was caused by my failure to update firmware on the last Add-on update...

half bluff
#

Idk. It is like the same stuff above

#

I had both working for a second and then when I reboot home assistant they show greyed out. The integration states everything is fine but the bulbs are greyed out

#

Only when I turn on BLE do they pop up again

#

I believe its still using Bluetooth even though it sais its connected to thread as router

devout iris
#

When you turn on BLE, can you actually control them, or are they showing as available when they really aren't?

half bluff
#

I can control them with BLE on

devout iris
#

And do you see the HA border router in the Thread configuration card?

half bluff
#

Yep

devout iris
#

If provisioning them with preferred credentials isn't working, you'll probably have to wait for @vapid shell to come back and walk you through getting things straightened out.

half bluff
#

Yeah I think so

devout iris
#

Hmm. It's rebooting less now - but it's still rebooting.

vapid shell
vapid shell
#

the preferred dataset is also "wrong" (has the old channel) so we can't roll back

#

unfortunately there isn't UI to recover from this state

#

im hoping in the next release there will be

#

but for now you need to delete /config/.storage/thread.datasets

#

then restart HA

#

then look at the thread integration. theres a possibility that this alone will be enough to get HA to pull the latest thread dataset from OTBR

#

if its showing no preferred network at this stage, you'll need to delete the otbr integration (not addon)

#

and then add it back

#

it'll ask you for a url which is http://core-silabs-multiprotocol:8081 (note, no trailing /)

#

if you look at the thread integration now, your preferred network should be called something to do with Home Assistant, and it should have a border router. if it doesn't, something above ^ has failed and we'll need to try again.

#

the state you are in now (where the thread integration thinks you have no border routers) means that its pointless to try anything in homekit_controller. it will not work until we have fixed that.

#

to try and help understand some of the weirdness you are seeing, some devices will turn off BLE when they are connected to thread. but that doesn't mean connected to HA. it doesn't mean connected to a border router. it means connected to a mesh. and 2 devices can form a mesh, even without a border router.

#

when the mesh fails, they'll fall back to BLE

#

this also means that they can report they are "leader" and still be only be connected to HA by BLE. they are leader of the completely isolated mesh.

devout iris
#

@vapid shell I'm pretty sure I've exceeded the capacity of SkyConnect.

#

After going from 31 to 62 thread devices, I can't keep the HA OTBR running for more than about 80 seconds.

devout iris
#

However, an OTBR running on a Pi3 with the nRF52840 Dongle works like a champ.

#

So for now I've unplugged the SkyConnect and left the add-on installed.

#

There is an older Thread boot loop GH issue from a couple weeks ago, but the logs from that one look completely different than mine.

#

Also, I'm pretty sure I can now reliably recreate an issue where HK controller will never connect to a working HK Thread device that is working fine, until you either reboot or reload the HK Integration for the device.

half bluff
#

@vapid shell It worked. Thanks Buddy!

vapid shell
#

That bug definitely exists but it takes over a week to happen naturally here

#

Which is inconvenient

devout iris
#

When a thread device becomes unavailable and then available again, it’s very likely to happen. (Disappears from _hap._udp. then re-appears.)

#

It may also be the case that it’s when the device gets a new name in dns-sd. Haven’t confirmed that.

#

But rebooting OTBR and switching to a new one a few times made it happen a lot.

#

Also may be related to slowness. It takes my OTBR about 60-90 seconds to register all 62 devices with dns-sd on restart. But it takes HA instance about 10-15 minutes for all the HK Controllers to come up.

#

And you should see the 'tail -f /var/log/messages | grep otbr'

#

It’s an insane amount of traffic on startup.

#

Several hundred messages per second for minutes.

#

I think the otbr devs could learn a lot just building a mesh with the devices I have. Apple too. It’s just a crippling amount of dns-sd multicasts.

#

And the idea that all of this is squeezing through a 115200bps UART channel on the SkyConnect. Lol.

#

Pretty sure a majority of mesh traffic is getting dropped - compounding the problem.

#

But once everyone is advertised and running steady state it’s not too bad.

#

Until you run a few scenes that touch most of the devices…

#

Anyway - the nRF528xx rcp firmware seems to handle it more gracefully than EFR32 multi-protocol.

#

It’s hard to imagine this ever scaling to large numbers of devices using multicasts the way hap does. I think MQTT is a much better protocol for this stuff.

#

Curious if Matter will be any better than hap.

vapid shell
#

We can probably reduce HAP traffic a lot but might be hard to avoid start up storm

#

Like we need to get the initial state for 60 devices

#

Right now we poll all of them@at once

devout iris
#

Might be an algorithm to hash a slot time for each device.

#

Or you could just queue them.

#

But yeah - polling all at once appears to be problematic with so many devices.

#

You could queue them and put any that don’t resolve back at the end of the queue and double the wait time each time through the queue.

#

Sort of a group exponential backoff retry.

devout iris
devout iris
vapid shell
#

8 on android

rapid umbra
#

🥶

devout iris
#

Yeah - that makes little sense to me.

#

Why would Android and iOS be any different with Thread?

vapid shell
#

Different protocols?

#

Android doesn’t use hap over thread

#

So it would have to use nanoleafs own protocol

devout iris
#

Did you say HA team is working on OTBR that can potentially work with any OT compatible RCP?

#

At this point I wish I could plug my nRF52840 dongle into my HAOS box and call it a day until the kinks get worked out of Skyconnect.

#

Also, <rant> I feel like the OTBR project is whistling past the graveyard with their perf testing.

#

Their reference test is only 12 nodes.

#

And the last time they updated the tests and results on the project page was over a year ago...

#

Plus, none of their automated tests are populating in the dashboard. For a protocol that is only supposed to start assigning child nodes once 16 routers are running, I feel like a 12-node perf test is pretty darned meaningless as well.

#

The deeper I dive into OpenThread to more I'm starting to think Zigbee is the way to go for the foreseeable future. The project doesn't feel particularly well-funded or organized considering who-all is supposedly supporting it - and considering how important it is supposed to be to the success of Matter.

devout iris
#

Like it's pretty clear Apple never bothered to test HomeKit over Thread with 50+ devices before they released it. And this is supposed to compete with Zigbee? </rant>

vapid shell
devout iris
#

It doesn't seem like it would be too hard. If you have a spinel-compatible device that the OTBR can see, it should pretty much just work.

vapid shell
#

Yeah I think it’s just priorities

#

Death by a thousand paper cuts

devout iris
#

Yeah. I was really hoping the Skyconnect would be a solid offer. It's a really cool idea to be able to run multi-protocol with one radio - but I've read more and more stuff about problems with EFR32 and thread - and more and more about how nRF528xx is solid.

vapid shell
#

When I’ve got some time (probably a few weeks away) I’d like to get you a tweaked homekit_controller that disables most of the polling.

#

Events should be enough

#

And 60 devices polling is always going to suck

devout iris
#

If you can give me a general idea how you might approach it, I can fork it and take a whack at it.

#

I took a peek at it already. Obviously coming into it cold there's a lot I don't understand yet. But it's some of the better structured and commented code I've seen in the project.

vapid shell
#

Hkc is permanently in a state of flux

#

Im trying to put 2 genies back in a bottle

#

It was originally Tcp only

devout iris
#

Yeah, saw a lot of thread-specific stuff in there.

vapid shell
#

So forcing an abstraction retrospectively is hurting

#

And trying to push more of the client out of HA and into the library, so the abstraction is more useful

#

Right now Ha has to know too much about hap

devout iris
vapid shell
#

Yeah

devout iris
#

I don't suppose there's any secret architecture manifesto for HKC?

vapid shell
#

In there you should have a pollable and watchable characteristics, the brute force test is just to disable the code where pollable characteristics get added

devout iris
#

Yeah - and I saw it looks like there's an unavailable state after 3 retries - but it wasn't obvious how that gets revisited.

vapid shell
#

There’s a lot of Bluetooth optimisation that nicks done so it’s changed a lot recently

devout iris
#

You know that's a good point. Eve outlets have 12 entities each.

#

I'm also blissfully ignorant about the internals of hap. I've skimmed the spec - but there's enough there that it would take a serious read for me to really feel I have a grasp on it.

#

And there was stuff in there that just pissed me off. Like you can't have both color_temp and color_hsv services on the same accessory. WTF Apple?

#

Like literally if you ask Siri to change a bulb to a white color - it is the accessory's job to recognize that the particular HSV can be mapped to Kelvin/Mired and then to keep that in synch with HSV...

#

What a dumpster fire.

vapid shell
#

HAP is pretty easy at high level. Services and characteristics like BLE. You can read, write and watch a characteristic. They have metadata like data type and range. Some chars are optional. Some aren’t. There’s some swanky encryption.

sick swan
vapid shell
#

Ah I was looking in the addons repo and wondering where it was

sick swan
#

I'll probably promote it into the main repo once flashing is in.

devout iris
#

Oh hell yeah!

#

Will it have its own dataset - or will it share nice with the multi-protocol addon?

vapid shell
#

HA only has one preferred dataset

devout iris
#

So I could install that add-on and be off to the races.

vapid shell
#

You’d need to reinstall the OTBR integration potentially

#

Yeah, it had the url for the old addon so it’ll need re-adding with new addon url

devout iris
#

I mean it doesn't really need an integration does it?

vapid shell
#

Well if you do that it will pull the dataset out of HA and push it into OTBR

#

You could do it manually instead

devout iris
#

Oh I see.

#

I guess that's how enrollment works too huh?

#

Need the thread credentials to push over BLE.

vapid shell
#

That’s the thread integration, so should work as it does now

devout iris
#

Oh, the Thread integration has the TLV with everything it needs.

vapid shell
#

Yep

devout iris
#

Will stuff break if I install Pure OTBR while Multi-pan is still installed?

#

Because as it happens, I have 2 nRF52840 dongles. I just need to flash the 2nd one.

devout iris
devout iris
# vapid shell Yep

Okay so it's running and talking to the dongle - but Web UI says RCP State is Disable and WPAN is Offline. It shows up in the Openthread integration under the Apple OTBRs with no information. The active one at the top is still my external OTBR.

#

Do I just join it via the Web GUI?

devout iris
#

Took the plunge and copied and pasted the TLV from dataset active -x from the external OTBR and ran dataset set active XXXXX in the docker OTBR.

#

Magic. Seems to be working...

#

I see both OTBRs at the top of the Thread integration now.

#

So in theory I'm in business.

#

Maybe with 2 OTBRs running I will have fewer issues?

#

Hmm - _hap._udp. seems to have reset... Uh oh.

#

Looks like there can be only one. I stopped my external one and now things are coming back.

#

Oh my - this is working WAY faster than the SkyConnect.

#

Seems like after starting OTBR with the nRF dongle it advertises 62 devices in dns-sd quite a bit quicker than Skyconnect advertised 36. Of course Skyconnect couldn't manage it at all with 62 devices...

sick swan
sick swan
devout iris
#

On Skyconnect?

#

No, nRF52840 dongle.

#

I built the ot-rcp FW a few days ago and have been running it on a Pi since I couldn't keep Skyconnect running at all.

#

Of course now that I restarted HA, it seems everything is borked.

# 
otbr-agent[137]: 00:13:59.306 [N] MeshForwarder-: Dropping rx frag frame, error:Drop, len:88, src:0x6002, dst:0x0001, tag:5715, offset:552, dglen:679, sec:yes
otbr-agent[137]: 00:13:59.321 [N] MeshForwarder-: Dropping rx frag frame, error:Drop, len:39, src:0x6002, dst:0x0001, tag:5715, offset:640, dglen:679, sec:yes
otbr-agent[137]: 00:13:59.447 [N] MeshForwarder-: Dropping (reassembly queue) IPv6 UDP msg, len:679, chksum:188c, ecn:no, sec:yes, error:ReassemblyTimeout, prio:normal, rss:-57.0
otbr-agent[137]: 00:13:59.447 [N] MeshForwarder-:     src:[fd7d:e897:7f23:a698:5f3a:1c1d:318b:7819]:39181
otbr-agent[137]: 00:13:59.447 [N] MeshForwarder-:     dst:[fd7d:e897:7f23:a698:2685:96:ee3f:b369]:53537
otbr-agent[137]: 00:13:59.447 [N] MeshForwarder-: Dropping (reassembly queue) IPv6 UDP msg, len:195, chksum:b170, ecn:no, sec:yes, error:ReassemblyTimeout, prio:normal, rss:-57.0
otbr-agent[137]: 00:13:59.447 [N] MeshForwarder-:     src:[fdd1:96d0:8cc2:1:9123:4cd2:e0bc:f586]:5683
otbr-agent[137]: 00:13:59.448 [N] MeshForwarder-:     dst:[fdd1:96d0:8cc2:1:1f81:6f01:ab1e:594c]:57238
otbr-agent[137]: 00:13:59.448 [N] MeshForwarder-: Dropping (reassembly queue) IPv6 UDP msg, len:679, chksum:d4b1, ecn:no, sec:yes, error:ReassemblyTimeout, prio:normal, rss:-58.0
otbr-agent[137]: 00:13:59.448 [N] MeshForwarder-:     src:[fd7d:e897:7f23:a698:ffd5:ea2:a7ba:639d]:15797
otbr-agent[137]: 00:13:59.448 [N] MeshForwarder-:     dst:[fd7d:e897:7f23:a698:2685:96:ee3f:b369]:53537
otbr-agent[137]: 00:13:59.950 [N] MeshForwarder-: Dropping rx frag frame, error:Drop, len:88, src:0x0805, dst:0x0001, tag:2661, offset:200, dglen:679, sec:yes
#

Everything is getting dropped.

#

Hmm. It appeared to be working until I restarted...

#

I'm going back to external OTBR for now...

#

Yeah that's weird. Getting a lot of unknown neighbor messages on the external OTBR - but at least it's registering hap services.

#

I'll take another run at this tomorrow. Seems like I'm close...

devout iris
#

With Skyconnect I was running the multi-pan firmware - but only for Thread. I have ZHA running on a Sonoff EFR32 dongle.

devout iris
devout iris
#

Okay - so I left it off overnight and fired it up again this morning and it seems happy. It's showing as bbr state Secondary. Not sure why, but the last time I restarted it, _hap._udp. completely disappeared and all I was getting were errors in the log.

devout iris
#

I re-flashed the nRF sticks to use 460800bps. Group operations are a bit faster - but startup of HASS still takes forever. So far no instability or weirdness running at a faster interface rate.

#

If I could figure out how to build the Skyconnect firmware...

upbeat cairn
devout iris
#

I'll be darned. I didn't realize they had an RCP-only build.

#

Why is multi-pan built for 115200?

upbeat cairn
#

I don't think we saw a reason to build it with a higher baudrate at the time, but we're probably going to also bump it up to 460800

devout iris
#

I would expect multi-pan it's even more important since you're juggling traffic across multiple meshes - potentially more traffic.

#

At any rate - thanks for the link! This version so far seems to be working. True test is a restart - multi-pan firmware crashes every time. So I'll give that a shot now.

#

So far so good.

#

The RCP-only FW is working way better than the multi-pan in a mesh with 62 devices.

#

If I fork that FW Build repo - will workflows build all the different FW versions?

#

Okay - I see the patch that does it:

# 
--- a/config/sl_uartdrv_usart_vcom_config.h
+++ b/config/sl_uartdrv_usart_vcom_config.h
@@ -24,7 +24,7 @@
 // <h> UART settings
 // <o SL_UARTDRV_USART_VCOM_BAUDRATE> Baud rate
 // <i> Default: 115200
-#define SL_UARTDRV_USART_VCOM_BAUDRATE        115200
+#define SL_UARTDRV_USART_VCOM_BAUDRATE        460800
 
 // <o SL_UARTDRV_USART_VCOM_PARITY> Parity mode to use
 // <usartNoParity=> No Parity
devout iris
#

Is there a reason OTBR does not have channel manager enabled?

vapid shell
#

What does it do?

devout iris
#

Monitors channels for interference and moves mesh to a better channel if necessary.

#

So I forked core and I'm trying to get set up for debugpy to play with HK Controller... Do you use VSCode?

vapid shell
#

I do use vscode but I don’t use a debugger or the dev container stuff

#

I just stare at things angrily

#

Seems to do the job

devout iris
#

Do you get this error: ModuleNotFoundError: No module named 'aiohomekit'

vapid shell
#

No

#

Ha should install it automatically at start up when there is a hk device added

devout iris
#

Yeah, it's a pylint error.

vapid shell
#

Sometimes I manually pip install it if I need to update it for tests or something

devout iris
#

For me, running the debugger will be good for learning the code.

#

so just pip install aiohomekit?

#

Hmm.

#

That seems to have made pylint happy anyway.

#

Anyway - yes channel manager is an optional build option for OTBR.

#

It's off by default though. Just seems like it might be nice to have thread automatically find quieter channels to avoid interference.

#

Can you give me a high-level hint about what order things happen in __init__.py and connection.py during startup?

vapid shell
#

Start in init and there should be something like async_setup_entry

devout iris
#

So HA just calls that once for each HK integration at startup?

vapid shell
#

Once for each config entry

#

There is a async_setup for the integration too

devout iris
#

Okay. And does it get called again on Reload?

vapid shell
#

I think there is an unload handler in init, and reload is just unload and then setup again

devout iris
#

Tantalizingly close to being able to debug my live instance... I feel I'm missing something obvious.

devout iris
vapid shell
#

Indeed

devout iris
#

So I flashed my Skyconnect to the RCP version of the firmware with faster UART speed and my crashing problem is resolved.

#

But I still have not been able to get things running stably with multiple OTBRs. Seems one of them is always having trouble forwarding when they are both active. Either one works fine by itself.

vapid shell
#

I’d be interested in cross checking your mdns records ip addresses with the routes you are getting

#

And because one of the OTBRs is on localhost, you’ll have very different routing to if you had 2 external brs

#

Like I don’t think you get a via route for the /64, iirc you get onlink wpan0 routes?

#

You probably are subjecting yourself to risk of ghost routes too (where fe80 of external br rolls over, haos never expires the old ip because network manager)

devout iris
#

Lots to go wrong...

normal arch
#

@upbeat cairn good to know about the uart speed, i'll update my builds to use the new baud rate

digital salmon
# devout iris It's off by default though. Just seems like it might be nice to have thread auto...

Channel Manager seems to be a great addition. But I really want to hard configure the channel Thread has to use. Non-Overlapping 2.4GHz channels (1/6/11, Germany: 1/5/9/13) are configured for Wifi manually here in my environment. I don’t use Wifi channel 13 here. That’s the area where I want to see my Thread network in the future. Now there is my Philips Hue ZigBee network (ZigBee channel 25).

devout iris
#

It supports preferred and allowed channels.

digital salmon
devout iris
devout iris
#

By default it runs the auto-selection logic every 3 hours.

#

I just built my reference OTBR with the flags to turn on both Channel Manager and Channel Monitor to play around with them.

#

Kind of neat.

serene prawnBOT
#

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

📎 message.txt
devout iris
#

So for example, based on that monitor output, I could set mine up like this:

# 
> channel manager supported 0x7FFF800
Done
> channel manager favored 0x1040800
Done
> channel manager
channel: 0
auto: 1
delay: 120
interval: 10800
cca threshold: 0x23d6
supported: { 11-26 }
favored: { 11, 18, 24 }
Done
#

I think it's showing channel 0 at the moment because it hasn't actually done anything yet.

#

But it uses the pending dataset to coordinate the channel change with a default delay of 120 seconds from the time it requests the channel change until it commits that dataset. At least that's how I read it...

#

So this could be fertile ground for a fun little bit of functionality for the OTBR add-on to support. Ability to record the channel history; ability to set allowed/preferred channels; ability to turn on/off the automatic channel management; ability to manually select channel, etc.

devout iris
#

Of course the smart default settings for the US would be something like:

# 
> channel manager favored 0x6108000
Done
> channel manager
channel: 0
auto: 1
delay: 120
interval: 10800
cca threshold: 0x23d6
supported: { 11-26 }
favored: { 15, 20, 25, 26 }
Done
#

Which favors the channels "between" the 2.4ghz WiFi Channels 1, 6, 11.

vapid shell
#

How does all that work with multi-pan?

#

(Aside from the fact that right now multi-pan can’t coordinate a single channel between thread and zha and just sets it to 15).

#

I think zigbee can change channel right? But some devices don’t support it or something

#

What happens if your device is off during the pending dataset period? Can it recover?

#

What happens if there are multiple OTBR with this on? Do they agree a best channel together? Do that elect a leader and that runs this process? Do they fight over the channel?

#

I’d really like to see TREL get turned on by default 🙂 then there’s be some real benefit to multi br

digital salmon
vapid shell
#

That’s kinda my point

#

From a reliability pov I hate questions

digital salmon
# vapid shell I think zigbee can change channel right? But some devices don’t support it or s...

I don’t use ZHA. But on a Philips Hue Bridge you can change/configure the ZigBee channel manually. Philips Hue is the only ZigBee I have and I don’t plan to buy more. I plan to change Philips Hue ZigBee lights to Thread/Matter lights, if this gets more stable. I also plan to buy some Nanoleaf Matter bulbs, when they are available for testing purposes. But when I exchange my Philips Hue environment to Thread devices, I have round about 80 to 90 Thread devices. It seems to be too much for the current Thread/Matter status. 😂

upbeat cairn
devout iris
#

They could be set up to fight - all they do is poke a new channel into a pending dataset and send it out.

#

It would probably be best to only have it set to Auto on one OTBR at a time.

#

In theory, multi-pan would sort itself out since OTBR would move to a better channel if Zigbee was too noisy.

#

I think the hiccup with Zigbee is that some devices can take a LONG time to figure out the channel has changed.

#

With Thread, it's all handled pretty neatly with a pending dataset and timestamp.

#

Anyway, I don't think there's too much harm in building OTBR with those features enabled in the dev build. The reason it's off by default isn't clear to me - could be because it's a recent "optional" feature - like the new meshdiagnostics - but that one is enabled by default.

#

Obviously it's overhead - but the features themselves can be disabled so they are only taking up a little bit of code space when disabled.

#

After running for a while - this is what my 16-minute channel window looks like:

serene prawnBOT
#

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

📎 message.yaml
devout iris
#

You can see that there is some pretty meaningful interference on WiFi channels 1 (Thread 12-13) and 11 (Thread 22-23) which makes sense based on the positioning of my APs that are on 2.5g WiFi.

#

But 15, 20, 25 and 26 are pretty quiet - those are the ones in-between WiFi channels.

#

Anyway, I'm going to play with it and see how it behaves. Right now I have bbr and br functions turned off on this OTBR (it doesn't play nice with the mdns on the HA instance) but it can still see what's going on and still runs channel manager.

#

But for whatever reason, my Thread network defaulted to Channel 19 - which is actually a pretty terrible place to be because of WiFi channel 6. I'm pretty curious to see whether CM will move it, and if so, whether my response times will subjectively improve.

#

Theoretically I will find out in less than an hour when it hits the 3-hour mark.

devout iris
#

Technically all a Thread device need to find its way home is the key.

devout iris
#

Eventually things would settle down to a channel that is not above the threshold interference - or it would keep trying to move to the least noisy one it sees every couple hours.

#

So even if they fight, it's unlikely they would keep fighting.

#

If they did - you have site problems bigger than fighting channel managers.

devout iris
#

A fun project my be to do an expresshome OTBR with a nice HA UI.

#

Sort of a Thread version of BTProxy.

digital salmon
devout iris
#

espressif has a few modules that support Thread and WiFi...

#

2 modules... But hey.

rare ibex
digital salmon
# devout iris 2 modules... But hey.

I am unsure, if I want this kind of devices/modules. I need at least a normal case/chassis for these modules… 😉 I don’t own a 3D printer. I want to buy a complete hardware set. Maybe something like this:

https://www.kirale.com/products/ktbrn1/

I am also unsure about Wifi/Ethernet. I would like to see a hardwired connection to my network instead of a Wifi connection.

devout iris
devout iris
#

In Thread 1.4, there should be a way to command any REED to be reconfigured as a FED. I'm looking at you Nanoleaf.

#

There is such a thing as too many routers - and there is such a thing as a device the owner knows is likely to lose power (still looking at you Nanoleaf)

#

If I could - I would take away router ability from all of my Nanoleaf bulbs.

#

I solved this problem with Zigbee by buying Sengled bulbs - and it works great.

#

Retrofit bulbs should be able to be configured as FED. Change my mind.

#

I would even be okay if it was determined as part of commissioning - here are your Thread credentials - and by the way, you are not a REED, you are a FED.

digital salmon
digital salmon
digital salmon
#

On Reddit I asked about the Nanoleaf limitation:

Does it still have this limitation?
——
Max bulbs paired via Thread: Unlimited. Performance may decrease in large networks of 20+ devices.

https://www.reddit.com/r/Nanoleaf/comments/11yn9ri/you_can_preorder_matter_supported_devices/jd9k8xr/?utm_source=share&utm_medium=ios_app&utm_name=ioscss&utm_content=1&utm_term=1&context=3

JohnNanoleaf (I think he works for Nanoleaf) answered the following:

Hello! The limit would be the same for thread and matter devices as they both use thread. Hope that helps!

https://www.reddit.com/r/Nanoleaf/comments/11yn9ri/you_can_preorder_matter_supported_devices/jdjk9ty/?utm_source=share&utm_medium=ios_app&utm_name=ioscss&utm_content=1&utm_term=1&context=3

What do you guys think about this Nanoleaf limitation and the answer from JohnNanoleaf?

quiet stirrup
#

I mean, it’s more or less a limitation from the protocol itself

#

Not much they (Nanoleaf) can do, as they only comply with the standards

mental dock
#

Is there a Thread console on HA frontend? If yes, how can I access it? I'd like to connect my Eve Motion sensor to HA Thread network

devout iris
#

You can enable the Web UI and see some stuff that way.

#

You can write your own scripts to call the OTBR ReST API and see even more stuff that way.

#

Or you can ssh into HA and then exec a shell on the OTBR container and run OTBR CLI commands.

#

But as far as connecting your Eve sensor - be sure you really want it on the HA thread network and understand what you're asking for there. If you already have an Apple or Google BR that it is connected to and there are other devices, you would be losing the benefits of that mesh unless you move other mesh devices too.

#

I did this because I am a glutton for punishment. I have 60+ Thread devices and Apple BRs just couldn't even. So I moved them all. It was not an exercise for the impatient.

#

I should probably write a post: So You Think You Want a Home Assistant Thread Network?

devout iris
#

And yes - performance does start to suffer past a point.

#

I've only really been playing with HAP devices on Thread so far - and from what I've seen, things can be reasonably performant with 60 or more devices given a few caveats.

#

Border routers need a high-enough speed connection to their Thread radio. The original Skyconnect firmware didn't do this and it cause problems. It's been fixed and is either already released or will be soon.

#

Who knows whether Apple or other Thread BR/Matter Hub vendors have this problem?

#

Also, things are fast as long as there's not a lot going on. However, if you add a bunch of new devices, things can be slow for a while. Also, if you reboot a BR, things will be slow for a while.

#

There is a lot of room for improvement.

#

But the good news is that most of the improvement is possible with firmware updates and with future versions of Thread.

#

Thread today is not "as good" as the latest versions of ZWave or Zigbee in terms of performance and stability.

#

But eventually it should get there.

#

I will say this: Anyone who decides to outfit their entire place with Thread devices and expects 50 or more devices to work as well as a small handful will be sorely disappointed.

#

If I had it all to do over again, I would have gone 100% Zigbee.

#

And I would just play with Thread on the side as a hobby because it's neat.

#

But I'm too cheap to divest of over $3000 worth of Thread stuff and replace it with Zigbee at this point.

digital salmon
devout iris
#

And anybody who tells you: "WiTh ThReAd ThE MoRe DEviCeS YoU HaVE tHe BetTer iT iS" - Well that's just absolutely wrong.

#

Lol.

#

Exactly. That's true to a small degree up to a very limited number of devices. After that you have to muscle your way through all sorts of muck to get things working well.

#

To me, a "large installation" is one that approaches the limits of other technologies. So take Zigbee or ZWave. 128-255 is a large network.

#

For Hue, Large is approaching 50.

quick bronze
#

128 isn't the limit for Zigbee 3.0

devout iris
#

Apparently for Thread, large is 20 according to Nanoleaf.

quick bronze
#

200 is the limit for purely Zigbee 3.0 devices, but you can have many many more Zigbee 1.2 devices on the same mesh

digital salmon
#

Ok, as already said, I have round about 40 EVE Thread devices and 40 Philips Hue ZigBee devices. The plan was to sell the Hue stuff to have one big Thread network… I think, I am not going to do that this year… 😂🤨🥲

digital salmon
devout iris
#

Yes. Do not do that this year.

#

Hue stuff is fantastic in my experience. Even though it's older Zigbee stuff - they have done a really nice job with it.

devout iris
# quick bronze 200 is the limit for purely Zigbee 3.0 devices, but you can have many _many_ mor...

Thanks - there's a lot of dumbed down information out there that seems more anecdotal than anything. I've only recently started seriously adding Zigbee stuff - and I've been careful to limit the number of router devices - and limit then only to non-switched power sources. So for example I use the child-only Sengled Zigbee bulbs and use a small number of smart plugs as routers. Rock solid. Hands down better than Thread.

quick bronze
#

Yeah, I've got 90 or so Zigbee devices and it's snappy

digital salmon
#

For me it gets more and more normal that every device in my house is „smart“ (more or less). I have a relatively normal house, 120qm. I have round about 100 to 120 smart devices incl. ZigBee, Thread and Wifi devices. Nanoleaf states 20+ devices as a large network. Crazy…

devout iris
#

IPV6 and dns-sd have a lot of overhead - and when your radio is limited to 250kbps and your protocols rely heavily on IPV6 multicasts - well... Not snappy.

digital salmon
devout iris
#

Yeah, I think Nanoleaf is being short-sighted - and to some degree so is OpenThread an Matter. Smart devices are still fairly new - so mfgs are trying to solve the retail onesy-twosy consumer use case.

#

The real future is homes built from day one with 100% IoT accessories. That means bulk commissioning, consistent network management, bespoke network design...

#

And supporting 100s of accessories flawlessly.

digital salmon
#

Yep, that’s it! 😃👍

devout iris
#

Like how stupid is it that Apple and Matter's design says that if I want to outfit a new home with 200+ devices, I have to go around to each device scan a bunch of barcodes one at a time? I should be able to install all of the devices, throw all of the credentials into a provisioning tool (bulk scan the barcodes or even get a JSON file with all of them in each bulk package.) And then I should be able to push "go" and everything should be on the network.

#

After that, I can simply play hide-and seek looking for the next blinking light to associate each device with its location in the home - and it's remembered in the provisioning tool so I never have to do that part again. Even if I reset a device.

#

If I scan a matter or HK barcode, it should just go into the database immediately with the option for me to add/activate later. And if I say activate now, it should happen in the background whenever I power up the device.

#

The current system was not designed by users. It was designed by engineers.

digital salmon
#

This all needs a lot of time…

#

😉

devout iris
#

Yeah. It will happen eventually. Most of this is Application stuff. In fact, there's nothing stopping someone from implementing everything I just said in HA.

#

Now if I could just get the stupid python remote debugger working I could start hacking away at it...

digital salmon
#

I recognized that Home Assistant OS 10.0.rc1 is on the way:

https://github.com/home-assistant/operating-system/releases

One of the most relevant changes for us here is the NetworkManager update as already said by @vapid shell:

NetworkManager 1.40.10 with bug fixes and improved IPv6 Neighbor Discovery Protocol support (required for Thread)

My Home Assistant Yellow is configured for the beta channel. When is it available on my HA Yellow?

vapid shell
#

Note that this doesn't fix IPv6 NDP

#

It should stop ghost routes, which is a big problem, but it might exacerbate other problems

#

With NM 1.40, the active route changes every time a BR does an RA (every 3 minutes for Apple)

#

so with 3 HomePod's your default route will change once a minute

#

If that route swap is atomic (thats when the old value gets replaced by the new value with no outage) AND your mesh is solid, thats not really an issue (apart from some edge cases around failover)

#

if its not atomic, once a minute there is a chance you'll lose a packet

digital salmon
vapid shell
#

if your mesh is not solid, theres a chance that for 1 minute in 3 you'll be connected to the "worst" BR

#

Old NM had faulty NDP in that in that when it found a new route and added it, the route became a multi-path route. then when it tried to remove the old route it couldn't find it. because it was looking for a "normal" route not a multi-path route.

#

New NM has no support for multi-path routes at all. "Most recent wins". It means that only one BR is active at once, and it keeps changing