when it has been working properly the

[flat delta]

It are 2 diferent scenarios. When you add from nother ecosystem you share it from one controller to another, hence the other code

It really should not matter how you add the device

I have been testing with the Nanoleaf devices last couple of days a lot and I can confirm that all these 3 options work:

1. add to Nanoleaf app first (that is NOT using matter for communication) - from there share to HA

2. Add to Apple Home or Google Home or any other matter controller) first and then shar eto HA

3. Add directly to HA out of the box - after that you can also import it to the NL app if you want for firmware updates etc

[fallen cosmos]

RE: 1), can you elaborate on that?

[flat delta]

The real issue with these Nanoleaf bulbs (at least with non-Nanoleaf border routers in use) is their stability... they drop off the network very often and even cause instability of the Thread mesh

[fallen cosmos]

and also, do your Thread details on the Thread addon in HA match what your iOS/Android Nanoleafs present as the commissioning credentials?

[flat delta]

Nanoleaf uses a vendor-specific protocol to communicate with the devices, it even falls back to bluetooth. Its not using Matter.

[fallen cosmos]

interesting. I'm seeing matter-specific protocols used in the handshaking when adding the bulbs via the App to Matter and via HA companion app.

[flat delta]

I'm in the iOS ecosystem so I can't confirm that but this afternoon I'll do some more testing with Android to see if there is a difference.

[fallen cosmos]

what vendor-specific protocol are you referring to?

[flat delta]

Yes, via the app to matter - I was talking about the app itself

[fallen cosmos]

the initial BLE pairing?

[flat delta]

Nanoleaf itself does not use Matter to control their bulbs but just their own protocol, probably the one that is also in non-matter bulbs - so you enable "Matter mode" on a device to make it ALSO talk matter.

These are not pure Matter devices

Which is probably also the reason they're so problematic, my assumption is that the device just does not have enough power to run both stacks at the same time, but now we're drifting a bit off topic.

FYI: Lot's of users report stability issues with the NL devices and we're in contact with Nanoleaf itself investigating it

[fallen cosmos]

I see

to be honest, part of the reason I'm wanting to shift to Matter over Thread Nanoleaf bulbs is because the Homekit over Thread bulbs are very unstable. Logs are always showing something to do with the Homekit Accessory Protocol dying repeatedly. Matter on the other hand, once the initial commissioning headache is over have been a hell of a lot more stable.

[flat delta]

More stable ? In that case your homekit bulbs must have been crazy awful 😂

[fallen cosmos]

Source: components/homekit_controller/connection.py:836
First occurred: 17:22:01 (65 occurrences)
Last logged: 20:22:09

Decryption failed, desynchronized? Counter=65/67
Decryption failed, desynchronized? Counter=181/183
Decryption failed, desynchronized? Counter=180/182
Decryption failed, desynchronized? Counter=184/186
Decryption failed, desynchronized? Counter=197/199```

every time it fails, the light becomes unresponsive

30 homekit Nanoleaf lights in the house, doing this every few minutes

🤷‍♂️

[flat delta]

And you have enough border routers as these are also Thread lights, correct ?

[fallen cosmos]

Skyconnect is it. I don't particularly want to go out and spend hundreds of $$$ on something that serves a single purpose (the existing TBRs that I know of are Aeotec Hub, Amazon, Apple crap, Google Hubs, Nanoleaf shapes/lines/elements and Samsung hub).

all of those devices here are several hundred $au. Skyconnect is $70.

[past vine]

Sounds like you just have an unstable thread network.

Shifting the protocol on top of the network probably wont change a lot about that.

[fallen cosmos]

fair enough

latest change I've done (because it seems to be the "recommended" thing to do) is split Zigbee and OTBR duties to two different devices. That's made things so much worse, as Zigbee is now throwing near 100% channel utilisation warnings (only occurred after the split, didn't get it one when Skyconnect was doing both). Seems what works for some doesn't work for others 🤷‍♂️

[flat delta]

Multiprotocol is very experimental and unfortunately suffers from some issues we need to solve, on top of the fact that Thread (and matter using it) is new in general so to keep things easier in terms of support/diagnosing, for now we kind of recommend to use Apple or Google Border router(s) as those will give the most stable experience.

If you don't have any of those, you can use the SkyConnect in Thread mode only (so not multiprotocol) but that is only available when using the HA Android app and still has a few issue son its own. Its all very early and a lot of stuff needs to be worked out but we're getting there step by step. Most important step will be enhancing the onboard experience as well as diagnostics so we can better help out in case of trouble and make a better overview of the thread network in relation to matter devices.

The Thread radio in the SkyConnect is sensitive to distortion and you need to make sure to have devices very close by. You could maybe enhance the result by getting a USB over ethernet extender thingie to get the skyconnect closer to your devices.

As you have told that you have 30+ Zigbee devices, my general recommendation will be against Multiprotocol in general as the radio is shared between the two, just make sure both have a separate stick, away from eachother and both on a seperate channel and be careful with overlap of WiFi channels.

For example set the Zigbee channel on 11 (which sits between WiFi channel 1 and 6) and the Thread channel to 25 (which is just outside WiFi channel 11) and make sure to set your WiFi at 20Mhz channel width and not 40 mhz.

[flat delta]

ZHA is throwing those channel utilization warnings most probably because the Thread radio next to it is using the same channel. So, see my recommendation above and change the channel of either the Thread radio or the Zigbee one.

[fallen cosmos]

noted, thanks.

for all intents and purposes, sounds like my use case is pushing things to a limit that hasn't been explored by many, so I'm on my own until things mature a bit more.

[past vine]

I mean there your have your problem. There is too much noise on the channel. With multiprotocol you just are sharing the bandwith between thread and Zigbee, so its less visible

I would probably buy a lan Zigbee adapter and put it somewhere else. Then you at least dont have “centers” of both of your mesh networks right next to each other.

[past vine]

Wireless interference has also not a lot to do with things being mature. Its like a bottle of water that is filled up.

[fallen cosmos]

It's hard to gauge a problem if you're not advised of one being there. If zigbee and thread share the same radio, then I'd expect a similar logging function to indicate something is close to being over utilised. This did not occur so I would have never known if I didn't split the device duties. That's basically asking someone to mind read.

[past vine]

Well how are you being notificer by a bad wifi connection? Its also just Netflix that is lagging.

And here your network was unstable.

[fallen cosmos]

we'll agree to disagree and move on from the topic. thanks for your help.

[past vine]

My point is just that even it could be Nice to be “notified” its hard to do that reliable. I know its annoying but on the other hand you also cant show too many information. The Channel might be fully utilized for short periods without having any impact for the user.

Where do you draw the line?

[fallen cosmos]

that is a gross overgeneralisation, but I understand your point.

[fallen cosmos]

you don't, but you adapt instead. some things work better in one place, some work better in another. you determine what works for you and share feedback as required.

I am well aware (as it has been repeated umpteenth times at this point) that this entire scenario is experimental/bleeding edge/still being worked on. I get that what works for me may not work for some and not others. What I don't get is why some thought processes are so linear that it's implied it must work this way. Of the countless hours of forum scrolling/post digging/reading others comments, the scenarios people have marked as working for them have not worked for me (ie. commissioning Matter devices by websocket. That has been the MOST reliable way of commissioning Nanoleaf bulbs, and yet is undocumented and therefore unsupported, which in turn means it's not considered as a viable option).

[past vine]

And in that case you Can look in the logs and see if there is something that points to the problem.

I think one the reasons that it is not documented and supported is that its supposed to work the other way. There are limited ressources available and instead of focusing on getting a “hack” to work it’s probably better to use the time on fixing the right way of doing it.

And right now it apparently messes with other Bluetooth integrations to do it this way.

Another thing is that as soon as it’s documented, people expect support for it. And suddenly you have a ton of people wanting help on interacting with a websocket api and complaining about it not being easier.

[fallen cosmos]

ok