Software Beta for Nanoleaf Essentials Matter

[swift phoenix]

Because Aqara has not updated the Fp2 yet for it. I figured it didn’t make it

[opal sparrow]

the aqara p2 is a native matter/thread device that's a presence sensor

[swift phoenix]

Nah FP2

Not p2 door sensor

[opal sparrow]

i'm talking about the "Motion and Light Sensor P2", a PIR motion sensor.

[swift phoenix]

Yeah it doesn’t have matter

[opal sparrow]

no, that's a native matter device.

[swift phoenix]

One sec

https://www.aqara.com/us/product/presence-sensor-fp2/

This ain’t got it

[opal sparrow]

yes, the FP2 doesn't have matter support

https://www.aqara.com/en/product/motion-and-light-sensor-p2/ does tho

[swift phoenix]

Yeah got that

But the FP2 is mmWave presence sensor

I don’t think matter supported that device type

[opal sparrow]

nah, there's a "presense sensor" framework that supports multiple sensor types, including pir and mmwave

[swift phoenix]

I could have sworn it wasn’t released in 1.2

[opal sparrow]

i'd bet the challenge in the fp2 is probably mostly firmware-wise, to deal with the fact that they have dynamicly available clusters based on configured zones

[swift phoenix]

I guess that might be it

[opal sparrow]

huh, looking closer, the matter spec doesn't actually have a sensor type for mmwave; i thought it did

if they wanted the FP2 to be a matter device, it would have had to pretend to be an ultrasonic sensor :/

(1.2 only has "PIR", "Ultrasonic", and "Physical Contact" occupancy sensor types)

i dunno if there's still any work pending there - the CSA keeps all their spec discussion and wip development private - but the matter sdk's 1.3 branch still doesn't have mmWave added yet https://github.com/project-chip/connectedhomeip/blob/v1.3-branch/data_model/clusters/OccupancySensing.xml#L72 :/

[humble whale]

I only want smart devices built with no expectation of internet access in my home, so WiFi is not an option. It's too bad Nanoleaf is not sticking with Thread in its new products.

[green frost]

You can have WiFi without Internet. My entire home us built on the premises of not outside access.

[frigid saddle]

Unless Nanoleaf removes the Thread Border router functionality from the shapes/lines then they have to provide wifi and/or ethernet connections as one of the main functions of a TBR is to bridge the Thread network ipv6 traffic of thread routers and end devices over to Wifi/Ethernet.

as to the new outside string lights, I get the decsion to go wifi there as wifi has extended range over thread andd allows for placing those lights outside farther away from the main house and maintain a reliable collection. they are also plugged in so no real issues with the more power hungry wifi radio.

[plain kettle]

i doubt nanoleaf will remove it, but i also doubt they will expand on the TBR capibilities, it seems to be running on a rather old version, and also doesnt support newer "features" like trel

[frigid saddle]

Yeah seems reasonable to pause any decision on what/how to use their TBR until the next major version of 2 of the thread spec is in use by at least a few of the major ecosystems (or at least apple as they strangely are the vanguard) and at least thread credential sharing becomes more automatic/ubiquitous allowing for shared multi-manufacturer thread networks by the less than tech savvy.

Or they do nothing and let the TBR continue to wither like a vestigial appendage. 🙂

[plain kettle]

eh, it has value at the moment, just sucks you are stuck with the default creds from apple keychain/google pay services

[humble whale]

That's impressive. I just don't want to be policing my WiFi or fighting with devices that need Internet to work. Even if it is a less mature protocol, Thread's locality is a major advantage, in my opinion.

[green frost]

Thread is but you still need to communicate with the edge router and many times that requires Wi-Fi.

[plain kettle]

there is quite a few ethernet thread border routers

and yeah, thread was built from the ground up to be local and privacy focused

[humble whale]

I have more trust in my Home Assistant than in smart device firmwares.

[plain kettle]

You got a thread dongle hooked up to HA?

[humble whale]

HA Yellow

[plain kettle]

Nice!

The thread firmware (OTBR add on) is pretty solid, and has the benefit of trel

It’s a absolute tank for all your thread needs

[humble whale]

Yeah. I switiched it from multiprotocol to thread-only.

[plain kettle]

Yeah, multi-pan, what a cluster that is 😅

[green frost]

The biggest issue with Thread firmware is the disagreement on how to implement the layer. If you have all Nanoleaf you should not have any issues.

The other issue is with manufacturers creating the edge router. Many have to write their own based on their interpretation of the documentation.

[plain kettle]

Creating their own? They all use the OTBR firmware from the alliance/google. They obv need custom implementation to get it to work in their devices

They all fundamentally run the same firmware

[green frost]

Are you willing to bet your life on that statement? What if the firmware is written in a language different than that of which your products are currently developed with?

[green frost]

For an edge router that I could send my own commands to, I went with this hardware solution.
https://github.com/farmjenny/FarmJenny_LTE_Border_Router_HAT

[eternal hill]

Thats like 99% of all prodcuts

Do you think all JavaScript libs are written in js?

All Python libs in Python?

All vendor libraries in matter written in C++?

[green frost]

Some of us still write ASM.

[opal sparrow]

it's honestly more likely that someone will use OTBR and add an adaptation layer to the language their code is written in than to write a custom thread border router implementation from scratch.

[green frost]

Probably and most likely true.

[opal sparrow]

(although you'd need to be running on a pretty powerful system if the language you're using ends up being anything other than C/C++/(your choice of other compiled or assembled language that can link to C code))

[eternal hill]

What kind of argument is that?

[green frost]

It's not an argument.

[eternal hill]

Lets just stop using software since some products are moving to pure hardware implementations

[green frost]

Why is that?

[eternal hill]

Because they have all kind of “Nice” stuff like garbage collectors and idk what

[opal sparrow]

my thread border router's running OTBR on an ESP32-S3 + ESP32-H2, which have a combined 832KB of ram (iirc, it's using FreeRTOS). there's not a whole lot of room on these things for languages that require any significant runtime :)

that reminds me, i should send espressif a pr to increase the default number of mdns entries their sample border router code can handle.

[green frost]

That's what I'm getting at. One needs to build efficiently so new features can be added. Byte code is always the most efficient though it may not be the easiest.

[opal sparrow]

not sure what you're getting at. byte code is not very efficient in most cases, since it requires a byte code interpreter that needs additional ram space and runs slower than native code. To build efficiently, you use a language that can be compiled to native code.

[green frost]

Byte code will be the processor's native code.

[opal sparrow]

"byte code" has a specific meaning in language/compiler development that is separate from native/machine code.

[green frost]

Fine, ML byte code.

[opal sparrow]

that's not a term that's commonly used, so it remains confusing.

[green frost]

It's not my fault that byte code has been redefined. I started on the IBM 360 then moved to a Super Cray. We had to write in byte code.

[opal sparrow]

heh, i guess they called it "byte" code on the 360 because that's when they switched to an 8 bit word size.

i started on microcomputers from the late 70s / early 80s, where the terms "machine code" or "machine language" were common for writing processor instructions directly.

[green frost]

It's sad that too few know how to directly control a processor.

Norton would roll over in his grave.

[opal sparrow]

(amusingly, the first computer I used, a TRS-80 Color Computer - in addition to having a basic interpreter in rom, also could run OS-9, where it had a language called BASIC09 which compiled to an interpreted bytecode.)

[green frost]

My first was Altair 8800.

A pita to program but fun to play with.

[feral steeple]

Have we got any updates on fixing the flashing issue? Seems to slowly be impacting more and more of my bulbs 😦

[craggy plaza]

What do you mean by flashing?

[green frost]

It will be helpful if you post a short video and details (firmware version and bulb type) of the bulbs.

[feral steeple]

Flickering is probably the better term 😛
But sitting there then suddenly will go bright then low again or similar. Or goes on then flicks to another colour.
I did send a number of videos to support, and the ones that come on and go to a super low brightness and wrong colour when they turn on.

https://productivuspte-my.sharepoint.com/:v:/g/personal/leon_productivus_co/EZNs6RqPKzJMtBkN6kDYIocBl5u5KV2ERrc7X6dvcT-dPg
https://productivuspte-my.sharepoint.com/:v:/g/personal/leon_productivus_co/ESHmaMe0guRHirY13wbyG74ByyaiCcHLueAoRZ6xdMMGdA?e=vK3lah

[green frost]

Wow! That is definitely an issue. I don't know how you put up with it. I'd rather use a flash light. Are those the A19 or the floods?

[opal sparrow]

is this the GU10 bulbs? Seems to me like there must be a hardware issue, since the software should be fairly similar to the other bulbs which don't have this issue :/

[feral steeple]

yea gu10's

sadly stuck with lots of gu10's. Dont know why they put downlights in newer apartments, they suck to begin with.

[craggy plaza]

How many GU10 do you have? I have 5 GU10 and 11 A19-E27. I never saw such an issue.

[green frost]

I have never seen GU10 bulbs used in ceiling lights. But, if they are bad, Nanoleaf should replaace them.

[craggy plaza]

Is it possible that the GU10 Connector of this light has an issue? How many of your lights have this issue?

[feral steeple]

It slowly seems to be happening to more of them, so dont think its a connector thing. There is a couple that do it permanently, but then a handful of others that will randomly do it one time when turning on then being fine the next time.

UK Seems to use a lot as ceiling lights and they suck 😦

[feral steeple]

Nanoleaf are, its just taking a while to sort out. Paul here from NL is getting me sorted though

[opal sparrow]

yeah, i wouldn't be surprised if you got some bulbs with a bad batch of power supply components or something :(

[green frost]

That's good. I thought, from your message, that this is the first time you have delt with the issue. Nanoleaf is a good company and does stand behind the products.

[craggy plaza]

Yeah maybe…

[opal sparrow]

if you can do electrical work where you live, something to consider would be switching out the GU10 light fixtures for nanoleaf downlights :)

[green frost]

I think he indicated it is an apartment and not his to change.

[feral steeple]

yea, unfortunately an apartment that I cant do anything about 😦

[craggy plaza]

How do you control your bulbs? This seems to happen when you switch on a group of bulbs. Which ecosystem do you use to control light groups? Does it also happen, when you switch the group via the Nanoleaf app? If it also happens with the Nanoleaf app, it is more likely that it is a hardware fault.

[craggy plaza]

What is wrong with GU10? It’s a widespread standard here in Europe.

[opal sparrow]

it's just not a form factor designed with LEDs in mind, so there's space and heat dissipation constraints that make it hard to build good, long lasting LED bulbs

[green frost]

Are the bulbs constantly powered of are they controlled by a light switch?

[craggy plaza]

GU10 bulbs can be replaced much easier than Downlights.

[feral steeple]

There is a light switch, but its constantly on and managed by HA

[feral steeple]

crappy light output, not very nice lighting (helps with colour and brightness changes)

[opal sparrow]

sure, but the expected lifetime of the downlight is longer since it can sink heat away more easily.

[craggy plaza]

My Philips Hue GU10 bulbs already work since more than 6 years without a single issue. 😉

[green frost]

GU10 bulbs have been LED for a long time. There are hundreds different ones from dozens of sellers on Amazon.

[feral steeple]

Thats exactly why I regreted not getting Hue again haha. But no, decided to try NL and Matter lol shouldnt of adopted early

[opal sparrow]

tho i suppose the main benefit is that they use the extra heat sinking space to make the downlights brighter than the GU10s :)

[craggy plaza]

Yeah, I am in the same boat. My house is full of Philips Hue, but I wanted Matter over Thread. Since 3.6.173 I am happy with the Nanoleafs.

[feral steeple]

Same, other than the handful that are screwy, the rest have been pretty good since the update

[opal sparrow]

to get some idea of the trade-offs: hue gu10s are advertised as 350 lumen at 6W, nanoleaf's gu10s are advertised as 400 lumen at 5W, nanoleaf downlights are advertised as 700 lumen at 6W.

[green frost]

I guess that depends you what it is that you refer to as a 'downlight.' In this case the GU10 is a downlight.

[craggy plaza]

Yeah, but again, GU10 is widespread here in Europe. You do not need to do anything to install GU10 bulbs, if you already have the GU10 connectors in the wall or ceiling. If I understand it right, this is not so easy with Downlights. I do not have any Downlights and was never interested. So I am bit unsure about my statement… 😃

[opal sparrow]

yeah, the bulbs are available simply because the fixtures are common, but trying to get lots of light out of a led bulb that small means efficiency is pretty bad :(

[craggy plaza]

Ok, but we are talking about the Nanoleaf Downlights:

https://nanoleaf.me/de-DE/products/ceiling-lights/downlight/matter-lightstrip-3-downlight-eu/

[opal sparrow]

interesting, the downlight product is different in europe vs north america. here I get https://nanoleaf.me/en-CA/products/ceiling-lights/downlight/

er, that's the "Matter Ultra Slim 4″ Recessed Downlight"

[craggy plaza]

Yes, that’s true. I do not have many GU10. There is one room with 5, three rooms with 3, and one room with 2 GU10 bulbs.

[green frost]

In the U.S. we call those recessed lights. We put then in the ceiling and walls.

[opal sparrow]

the EU version's 550 lumens at 6W apparently.

so still better than the GU10s, but not as much better as the north american downlight.

[craggy plaza]

The Ultra Slim version is not available here in Europe. Never seen it before. Looks interesting, but I use GU10 here. 😂

[opal sparrow]

the north american one matches the form factor of common non-smart LED fixtures that are available here.

the EU one is presumably designed to replace the GU10 fixtures :)

[craggy plaza]

@feral steeple How many Nanoleaf Matter over Thread bulbs do you have? How many GU10, A19, whatever?

[craggy plaza]

Yeah, that maybe true. But when you already have the GU10 fixtures/connectors, you use them instead of buying Downlights. That’s maybe the issue. 😉

[green frost]

What do you use for uplights?

[craggy plaza]

What are uplights?

At the moment I only have GU10 and A19 (E27) bulbs from Nanoleaf and Phlips Hue, but I plan to buy some strips…

[opal sparrow]

but yeah, the tricky thing about these "ultra slim" north american downlights that's not obvious in photos is that they actually include a separate junction box. https://images.homedepot.ca/productimages/p_1001157030_alt_HLBSL4069FS351EMWR_jbox_1000.jpg?product-images=l (that's true of the nanoleaf one as well). kinda tricky reasons about that regarding electrical codes.

an "uplight" is… a light that points up. In other words, a lamp designed to shine light on the ceiling, which then reflects down.

[green frost]

That isolates the 120Vac from the 12Vdc.

[craggy plaza]

Yeah, that’s what I already saw in the past. GU10 doesn’t need something like this. It’s connected to 230V directly. Everything has its pros and cons.

[feral steeple]

Oh yea that type of downlight is way better than the gu10's, half the problem is they are up in their holder so the bulbs lose even more of their light output.

[green frost]

That also allows the LED lights to be installed in wet areas.

[craggy plaza]

My GU10 aren’t up in their holder. They fit perfectly fine.

[opal sparrow]

I think most of the time they do put the voltage conversion in the junction box on these downlights, but the main reason for it is actually legal/code stuff. The connections between house wiring and a fixture, plug, or switch must happen inside a junction box, so you can't just have a light that clips into a hole in the ceiling with high voltage wires connecting directly to terminals on the device.

traditional ceiling downlights are designed to be installed in a metal "can" in the ceiling, where that can is the junction box, so the connections can happen directly.

[feral steeple]

Oh that design is way better than what is in mine 😦 They are all sunk into the holder by about 2-3cm so drops the spread of the beam by a lot and cuts it off 😦

[green frost]

That is normal for ceiling lights in the U.S. The bulb sits up inside the can.

This is what has been used in ceilings for years here.
https://www.homedepot.com/s/ceiling can?NCNI-5

I have installed several of these in my house. just over 20, I think. This is a 6" can.

[feral steeple]

So its like a larger downlight with a decent bulb?

Mine are like these and sit up in teh holder too far

[green frost]

Yes, I think you can call it that. It is just called a 'housing' for a light bulb.

If you have an interest, this might explain more.

[green frost]

The can above has an adjustable platform to raise and lower the socket.

[craggy plaza]

This is how it looks here:

https://amzn.eu/d/80QRAx7

We do not necessarily need that can. It’s only the fixture with a GU10 connector:

https://amzn.eu/d/9wo44kV

[craggy plaza]

Yeah, that’s it. Maybe it’s possible for @feral steeple to lower the socket.

[feral steeple]

Would need to replace the holder, or find something to hold the light in without it. Too much effort when i dont own the place 😛 Its alright with the NL bulbs (when they work properly haha)

[green frost]

Every time I see 'NL' my mind reads Netherlands. Then my mind thinks Nanoleaf should be 'N' since it's one word.

[feral steeple]

Thats a fair comment! haha

[feral steeple]

30 connected and 8 I still havent been game to connect in the bedroom after all the initial firmware drama.
All GU10's

[opal sparrow]

I just noticed something odd about the 3.6.173 firmware on my light strip. Home Assistant's matter server is reporting that its subscription report interval is [0, 5] (i.e. it will send subscription reports at least once every 5 seconds). This seems rather short, especially since HA is requesting an report interval max of 60 seconds.

no functional problem, but means it's generating more thread traffic than is necessary.

[woven scaffold]

The SmartThings community has also found this issue. They are discussing it. I will send it when I find Link.

[opal sparrow]

i haven't tried yet, but it should be easy to reproduce this with chip-tool.

[green frost]

Why would you want to reproduce it. Seems to me one would want to changhe it.

[opal sparrow]

Providing a method to reproduce an issue is an important step in the process of finding out the cause of an issue so it can get fixed. The problem is in the firmware, it's not something we can change.

Home assistant requests subscription reports with a [0, 60] second interval. The device says "nope, gonna give you updates with a [0, 5] second interval instead".

Hmm. if the CHIP0001 issue report form is still open, i guess I should use that to report the problem.

[green frost]

I see, you want to prove the issue.

[green frost]

Where is this SmartThings community?

[opal sparrow]

oh, yeah, the spam when doing transitions is another issue separate from the maximum subscription report timer

running simultaneous transitions on multiple nanoleaf bulbs can severely degrade the thread network :(

[green frost]

I'm interested in the SmartThings community. I have not found it.

[woven scaffold]

This is a screenshot of me a long time ago. When I find the website, I will share it with you.

[green frost]

Yes, please. Thank you.

[opal sparrow]

I'm pretty sure the nanoleaf bulbs send subscription reports at extremely short intervals when running a transition even if none of the attribute values have changed (for example, if you do a multi-second transition between two color temperatures that are very close)

like, the way i have adaptive lighting being done in HA sometimes sends a command to change the color temp by 1 mired over 5 seconds.

there's no reason to send multiple reports per second for that.

I wouldn't be surprised if that's related to the cause of the issue that their matter transitions aren't very good in general, like a brightness transition via matter only does 1% steps, or the inability to do a transition when switching between color temp and xy or hue/saturation color modes.

[green frost]

Nanoleaf reports its status for every change, which I think is overkill.

[opal sparrow]

that is what the matter spec says to do. the fact that they're also sending reports when there is no change is pretty bad tho, and i think the matter spec's recommendation for updates is kinda problematic.

[green frost]

If a bulb, or group of bulbs, is instructed to go from off to 100% full bright over 3 seconds., that is a huge load of data that will flood the mesh network. What's the purpose?

[opal sparrow]

so this is a tricky thing. controllers will basically always set the minimum report interval to 0, since they want to find out about changes immediately when they happen, and having a longer minimum report interval is problematic for devices because it means the the device is required to buffer/collect changes while waiting for the interval to expire, which uses more ram. If ram is short, devices sometimes go "i give up tracking attributes, just re-report the entire cluster", which will also cause increased thread traffic :(

(that tracking needs to happen separately per fabric too, since each controller might have a different minimum report interval)

[green frost]

If I (or Home Automation) send a command to a group (10) of bulbs, I am only interested that each bulb acknowledges the command and that the bulbs report the status ay the end of the command. I really don't care about each status in the middle.

[opal sparrow]

The matter spec should honestly redefine the Level Control cluster CurrentLevel attribute, and the Color Control cluster's various Current* attributes to have the "Quieter Reporting Quality", and define conditions under which they're reported.

right now, by spec, they're normal reporting attributes which means every change needs to be reported, at the negotiated minimum reporting interval.

that would allow them to define that the attribute must be reported when a running transition finishes, for example, but doesn't need to be reported during intermediate states.

[green frost]

I think I understand the information you are trying to present. If so, I do agree that changes must be made. I have to wonder if those writing this protocol have actually worked out in the real world or only in their labs.

[feral steeple]

Hopefully the next firmware will help with lots of commands getting processed. (Or maybe a HA update that will send some kind of group command instead of individually?)
If i walk through 3 rooms (like from office through living to the kitchen) it gives 24 gu10s a turn on signal, and there is usually about a 5 second delay for the kitchen lights to eventually turn on.

[opal sparrow]

yeah, nothing the bulb firmware can do about that, each bulb just turns on when it receives the command directed to itself. really need the matter controller to set up groups and use group commands.

[feral steeple]

Ahh good to know, thanks for the info

[plain kettle]

They seem to be more focusing their man power towards all the new hardware stuff they have down the pipeline, if anything we might see a few smaller patches via upstream fixes (or updating the the newest 1.2 SDK release there was)

[green frost]

Product Development is focusing on the new products.
Product Managers are focusing on their products.
Software Development is focusing on enhancement and issue reports from the Product Development team and Product Managers.

[opal sparrow]

well, the new sdk release is 1.3 now; they just finished getting 1.2 out :)

[green frost]

Are you of the opinion that adding Matter takes only a day?

[plain kettle]

we are not saying adding matter at all

just the newer minor version of the sdk out

i personally havent seen the 1.3 docs to what improvements it would provided to nanoleaf/others specifically, but i dont think any companies like apple/google/amazon have updated their matter server with it yet

[opal sparrow]

none of the major headline features in the matter 1.3 spec would make a difference to any of the released nanoleaf stuff, but iirc there are some bug fixes in the attribute reporting code in the sdk

[green frost]

Where are you seeing this SDK?

[plain kettle]

CSA website

https://csa-iot.org/developer-resource/specifications-download-request/

you could just make a fake company & email up to get the forms

[green frost]

I have all that. It's a crap load of documentation. More than most books have. It's huge.

[plain kettle]

yes

but if you know where to look its alright

[green frost]

But that is not a Software Development Kit.

[plain kettle]

most of the dev kits/documentation are locked behind soc makers, like silicon labs, nordic

you could go digging, and no doubt youll find something somwehre

[green frost]

Even in the repositories, while there is code and mention of several SDK, it is mostly documentation with some loosely written test code.

I did find something interesting in the documentation. Someone mentioned that everyone uses the OTBR. The documentation on the CHIP tool recognizes that not every one does use the OTBR.

[plain kettle]

there is alternatives, as you posted, but in comparision to how mature OTBR is in respect to the other solutions, its like nothing

tho i reckon apple uses their own solution?

[opal sparrow]

The matter sdk is https://github.com/project-chip/connectedhomeip if you're curious, although most people will end up using modified versions of it included with development environments from their soc vendor

[green frost]

I would think that all of the big guys use their own. Most likely optimized for their products. Especially IC makers.

[opal sparrow]

hmm? no, they all use the same matter sdk, just modified slightly to integrate with drivers and libraries for things like their own radios.

[green frost]

I am aware of that and the other repositories and while there is code and mention of several SDK, it is mostly documentation with some loosely written test code. I

[opal sparrow]

a lot of those changes have been integrated into the main matter sdk tho, to reduce maintenance effort

https://github.com/project-chip/connectedhomeip/tree/master/examples/lighting-app - their example lighting app covers most of the platforms that use the sdk

[green frost]

I have spent hours reading and educating myself on that repository, and I have discovered that it is nearly impossible to pick out the code to actually produce a working SDK. Then there is the issue of code pages written is several languages. The provided code is written in the language that the developer uses. While that code is readable, it is code many developers won't know how to compile it, so that may have to rewrite it.

[plain kettle]

ehhhhhh

[opal sparrow]

i have no idea what you're talking about. "how to compile it"? you run the provided build system using the instructions they provided.

i think you missed a bunch of the repo, but also note that a not insignificant amount of the code is generated by processing the xml versions of the cluster definitions.

most of the code implementing interesting parts of the matter sdk is located in the src/app directory

tho the controller stuff, protocol encoding/decoding, and encryption/authentication stuff is split up into other directories.

[green frost]

Exactly. There is a LOT of code that will not be relevant to every project. Hopefully the tools provided will actually ignore all the unneeded code. However, one would expect an SDK to be a separate repository to make updates and pull requests easier.

[plain kettle]

you quite literally have this many bulids + tests and tools in the one repo,

its easy to understand if you work with it

obv from the outside looking it can be "confusing" but the people who are actually in the CSA slack channels/meetups and forums know about it and each aspect of it

[green frost]

Yes, and that requires days, maybe weeks, of research before one even tries to build a useable test case.

[plain kettle]

no diffrent to other large scale projects

[opal sparrow]

certainly far less time and work than it would take to implement the specification from scratch. you're benefiting from work that a lot of people have already put in.

and honestly, start with one of the sample apps and you can get something basic up and running in hours.

[green frost]

Unlike most large programs, in this case, it has been created as, One Size Fits All. It could have been in separate repositories that could be picked from that which is needed.

[plain kettle]

i mean, you can whinge about how confusing it is, and all that. but you arnt in the CSA and have very limited information regarding why they are doing what they are

[opal sparrow]

actually, quite a bit of it is in separate repos. Like their entire thread stack is loaded from the openthread repo

[plain kettle]

no diffrent from lets say the home assistant core repo

[green frost]

Pointing out deficiencies is not 'whining.'

[plain kettle]

point out what you want, its not going to change

[opal sparrow]

and if you think that literally the entire codebase is built and included in every device, that's a misunderstanding about how the build system works. it does not do that; only cluster implementations related to the device being built are compiled and included.

[green frost]

Also, I have not been able to find an index of changes from 1.2 to 1.3. Maybe it just hasn't been uploaded but I can't find it.

[opal sparrow]

https://github.com/project-chip/connectedhomeip/releases

oh, huh, they don't have 1.3 there

weird

[plain kettle]

https://github.com/project-chip/connectedhomeip/releases/tag/v1.3.0.0

[green frost]

I think I just mentioned that above. I know about the tools to select what is wanted.

[opal sparrow]

they've tagged it but haven't yet written up the notes as a release in github

[plain kettle]

yeah, would be WAY to long to fit within github notes

tagged uup, i guess silion labs drives the release notes

[opal sparrow]

hilariously, the release notes for 1.2.0.1 say they added some matter 1.3 features

[plain kettle]

yeah. almost 2k commits since the last latest w/ notes, they are not fitting all that in

[opal sparrow]

i mean, you don't describe every change when writing good release notes, just a summary of major things.

[plain kettle]

yeah, but someone gotta keep track over the last 8 months

👀

[green frost]

That is a lot of files to read through. I do wish they had separated the documents from the code.

[opal sparrow]

but it can be summarized as "implement the matter 1.3 spec and bugfixes"

keeping documents with code is very useful, since it means you can be sure you have the correct documents for the code that you're using.

often it helps to make sure that a pull request that changes code also includes the matching documentation updates

[green frost]

I have had discussions with Nanoleaf about releases. I don't like
Enhancements and bug fixes.
Fortunately, all the data is stored in Zendesk and should be easy to pull out into a change log.

[opal sparrow]

zendesk is a customer support system, it looks like they use jira for internal dev issue tracking.

[plain kettle]

its just whoevers job it is to add it to their zendesk stuff (consumer facing)

[opal sparrow]

at my work, our zendesk and jira are integrated with each-other tho, so we can create jira issues from customer support tickets so we can plan work :)

[green frost]

It is so simple to pull both repositories at the same time and get all updates.

[opal sparrow]

pull "at the same time" is actually kinda hard - you just get lucky since it's usually close enough. and pulling a specific version of one repo and finding the matching version in another repo is even harder unless you're using a tagged version and the other repo has matching tags.

easier to use one repo to coordinate things.

[green frost]

The do. Zendesk contains the issue reports and the the logged issue number
Jira is used as normal and Nanoleaf works on a two week sprint.

[green frost]

We will just have to disagree on that.

[opal sparrow]

eh, it's pretty common practice in many projects. not all, since opinions do vary, but pretty common.

an interesting thing that i learned from looking at the matter sdk repo is that you can have private issues on a public repo. There's a bunch listed in https://github.com/orgs/project-chip/projects/93/views/1. Seems like they mostly use that for issues related to unpublished specification work, which is something that you have to pay to become a member to participate in.

[green frost]

Most of my wok is done on Atlassian simply for the reason that there are so many tools integrated on the platform. I am able to commit pages or comments that only the project owner can see.

[plain kettle]

ahhh Atlassian, what a scum of a company they were to intern for 🙃

glad there are alternatives now to them, god their sydney offices were terrible

ah well anyways, yeah. GW is more refering to systematic issues within the CSA and the github repo, which aint ever gonna be "fixed"

[green frost]

Offices, foreign to the main, are often poorly ran. There is also the mindset that, 'we do it better than (the main office). I saw that here in the US where the home office was in Europe. The managers that they new better then Home.

[plain kettle]

yeah, and australia doesnt have a massive intern culture like the US, and many companies are trying to inject it through the unis, and its a bit hit and miss lmao.

ah well

[opal sparrow]

a lot of the issues are simply due to the way the project is structured as a whole, i think. it's a kind of weird semi-private, semi-public thing, so you quite simply can't see the whole project and the direction of development from the open source point of view

[green frost]

My thought on that is it should have been in a private repository. But I'm just an old developer.

[opal sparrow]

the spec is in a private repository, the sdk is public, and i think it makes sense for it to be public.

but the split leads to annoying things like what happened in https://github.com/project-chip/connectedhomeip/issues/33467 where someone reports an issue, they go "oh, that's a spec issue, it's a private issue now" and it gets closed :/

[plain kettle]

yeah, but from what ive seen, most people reporting issue/pulls are actually somwhere involved with one of the CSA members

[green frost]

I would be worried they might make changes and leave something out of the public side.

[opal sparrow]

anyways, if i report that thing about the attribute report update rate causing too much thread traffic, i'm betting it's just gonna be "that's a spec issue" and close it :/

[plain kettle]

like marcel said, you could try to make a pull fixing it, but no doubt it will get shifited away/closed

[opal sparrow]

well, can't make a pull request fixing it because it's a spec issue and the spec is in a private repo :)

[plain kettle]

im surprised the CSA doesnt have educational institutes as involved as something like the thread group do

[opal sparrow]

and it wouldn't make sense to leave a change out of the public repo, because everyone building matter devices is doing so using the public repo.

i haven't worked with other vendor sdks, but e.g. the espressif sdk literally pulls in the matter sdk as a git submodule referencing the public repo for example.

[plain kettle]

like, its super hard to break into the industry starting with thread/matter, 2 subscription fees the moment you release the product

i gotta commend that dude behind the tuo buttons

[opal sparrow]

it's at least possible to build random open source stuff using the development vendor ids and kinda use it with some platforms, but still quite a pain.

and yeah, getting the ability to use the matter and thread logos on a product is a lot of work and up front investment :(

[spark cypress]

Hi where and when i get my code for Testflight?

[plain kettle]

https://testflight.apple.com/join/e6YpifHl

[rare aspen]

Hello team, is there now a plan to move forward with Essential FW that would make them compatible with Sync+ over Nanoleaf 4D kit (currently, sync+ is only available with Nanoleaf Desktop) ?

[wraith bear]

Hey guys, have there been any recent beta updates apart from the last big one that we had?

[plain kettle]

No

[wraith bear]

Oh dayum

It's been a while 😅🥺

[eternal hill]

Well i think that there is something really wrong if you need constant software updates for your bulbs.

Same as for the Shelly relays, where the CEO complains about the price for software updates. Maybe just ship a finished product

[undone spire]

If you are investing in a ecosystem, then you kind of want it to improve over time with optimisations and new features.

[green frost]

Thread and Matter are currently changing to improve the services. Therefore Nanoleaf has to change. And it is beta firmware so no one is forced to use it.

As for Shelly, that's an issue with her company model. Poor planning in the structure of the company.

[eternal hill]

The point i was trying to make is that a bulb(and also a smart relay) is a rather simple product, where the most important aspect is that it "just" works.
So i don't think that there should be constant software updates to "improve" the product, potentially breaking them. And yes, matter changes, but i have not seen any important new features for lights. Therefore i just think its a bad consumer mindset to see it as a bad thing if your bulbs did not have a software update for a few months

[opal sparrow]

There are still a bunch of known issues with the matter firmware for nanoleaf essentials products that I'd really like to see fixed, but it seems like their firmware devs are busy on other stuff at the moment now that most of the immediate stability concerns have been dealt with.

(most of the issues are regarding behaviour of transitions)

specifically: matter on/off transitions have been disabled in favour of using a fixed transition (to work around a bug where bulbs would sometimes stay on dimly when turned off via matter), transitions between tunable white and full-color mode don't work, and transitions run in large steps (e.g. 1% steps on brightness) rather than smoothly using the full capabilities of the bulb.

also, they generate way too many subscription report messages when running a transition - which can clog up the thread network when you run transitions on a room full of bulbs - but that's actually a matter spec problem (and partly an sdk-level issue, 1.3 might help a bit)

[craggy plaza]

@boreal surge and @wild oracle Any idea when we will see the next (beta) firmware that solves the issues described by @opal sparrow? Thanks

[frozen crystal]

I am very eager to hear the answer to this too. Unfortunately the current firmware does not scale well at all for house-sized deployments. For instance, commands which turn off many devices at once, such as my “goodnight” scene, simply crash the whole mesh, forcing a lengthy rebuild. Nanoleaf needs to fix this asap or releasing all of these new products will only generate more bad press.

[plain kettle]

That’s less of a Nanoleaf thing and more of a thread thing, try only doing a room at once, wait maybe a half a second and do another room etc etc

[frozen crystal]

That is what I have to do

[plain kettle]

In home assistant you can do that with a single automation, don’t think you can with Apple home/gooogle

[frozen crystal]

I am hopeful that Matter 1.3 will alleviate some of this as groups of lights will only require one command, not 14

[frozen crystal]

I could use Apple shortcuts to hack it, like in HA. Either way, it’s a hack which ought not be required

[wild oracle]

3.6.196 Beta released

• Fixed an issue affecting setup in very busy Thread environments
• Reduced reporting interval when using longer color temperature transition times in Matter
• Fixed a number of other minor issues

[wild oracle]

3.6.196 will address some of them, in particular slow color temperature transitions.

@opal sparrow are you able to elaborate more on the other transition issues you see?

1. for ct > hs (or xy) transitions, its unclear to me from spec what is expected. on the one hand, "always smooth" is obvious user expectation. on the other hand, if you go from HS to a long lived color temperature transition, it may leave the light in an undesirable state for an extended period. so this seems perhaps a spec shortcoming? feel free to elaborate on your persppective.
2. for choppy transitions, can you provide more detail on how you reproduce them and if you're observing them when using things other than chip-tool?

[wild oracle]

would love to have more details on this. DM may be better, as i expect extended back/forth. generally, there should never be a reason the whole mesh should need to be rebuilt, so will need more info to zero in on if this is a device issue, a BR issue, or a matter hub issue

[opal sparrow]

I recall choppy transitions are most noticeable when doing a transition between nearby colors over a relatively long period of time. For example in white mode, set brightness to 15% then transition to 20% over 10 seconds. I can't confirm the exact details atm since I'm not currently at home, but my recollection is that this resulted in 5 distinct brightness steps

[wild oracle]

code behaviour should expect 5*254/100.

[opal sparrow]

And yeah, for CT -> RGB transitions, spec say to switch to the nearest available color to the current color in the new mode, then transition to the dest color. I guess this is mostly an issue for you since the xy mode doesn't blend in the white LEDs? Is there power limits in running RGBWW for an extended period?

[wild oracle]

are you able to link to spec section?

seems you may refer to:

3.2.11.1. Generic Usage Notes
When asked to change color via one of these commands, the implementation SHALL select a color, within the limits of the hardware of the device, which is as close as possible to that requested. The determination as to the true representations of color is out of the scope of this specification
if so, i don't think that applies to this case. it's only referring to end-states. the spirit of what it says is definitely applicable, but i still think there is ambiguity

[opal sparrow]

3.2.11.2 is applicable here

The first action taken when any one of these commands is received is to change the ColorMode attribute [...]. Note that, when moving from one color mode to another [...], the starting color for the command is formed by calculating the values of the new attributes [...] from those of the old attributes [...].

which doesn't necessarily require a smooth transition here

that would just be nice to have if the hardware is capable :/

(which it is capable; since it can do smooth transitions when changing colors between modes in the nanoleaf app)

they have a big old "behaviour is manufacturer dependent" note for when the starting color can't be represented in the new color mode which gives a lot of leeway.

[opal sparrow]

even if there's ~250 brightness levels available during transitions, that's still not great, since it seems like the bulbs are capable of finer steps in hardware :/

(I've seen 0.1% advertised in a few places, which is ~4x as many steps)

But yeah, the issue with subscription reports during transitions is definitely a matter spec issue. The spec says that during transitions, the RemainingTime and "Current" attributes on the LevelControl and ColorControl clusters are updated "as fast as practi­cal" - but they're normal reporting attributes, which means that subscription reports for them are sent as soon as the attributes change. My opinion is that those attributes should be redefined with the "quieter reporting" (Q) quality, and some language added to the spec to say that changes to those attributes which occurred due to an ongoing transition won't be reported immediately.

(specifically, i'd suggest wording that requires sending a report for these attributes when a command is received that either immediately changes color, starts a transition/move, or stops a transition/move, requires sending a report for these attributes when a transition ends (i.e. RemainingTime changes to 0), and allows including the attributes in reports sent for other reasons or when the maximum report interval is reached.)

(for reference, "Quieter Reporting" is 7.7.8 in the matter 1.3 core specification)

[wild oracle]

right. yeah that was the specific mention i missed while skimming. so spec is not ambiguous, just says its up to us. i've logged it. let me know if you think its specifically relevant to QoL when using certain ecosystem features.

[wild oracle]

our current approach opts not to report changes to remainingtime and only changes to CCT. let us know if 3.6.196 meets your expectations

[wild oracle]

yup, not a defence, just matching up expectations. i assume that's what you're seeing

[green frost]

The specification is overly complicated. It's like it was written by someone that likes to write using as many words as possible to confuse the reader and obscure to details.

Like those ads and videos that tell us something important is coming buy that keep stating the same thing over and over to keep us reading or watching and yet just don't get to the point that we want to know so by the end we are confused or lost interest which causes us to forget why we were reading or watching and then we wander off to something else and stop reading or watching so we miss the important pat.

[wild oracle]

yeah, welcome to the joy of standards. theres many sections where i had to read things 10x over before i understood what they were trying to say

[green frost]

I've been dealing with obscure 'standards' since my military days with Unix. It's crazy that the situation has not improved in the past 80 plus years.

If only examples were included, it might make a little more sense.

[opal sparrow]

Yeah, I ran into this when looking into some sky light simulation stuff where I want to use color temp mode when possible, and switch to xy for out of range colors (e.g. sky/shade blue or deeper oranges/reds for sunset). The transition was quite jarring.

[craggy plaza]

I installed the firmware on 13 of my 21 bulbs (6x A19-E27, 7x GU10).

I have an Apple Thread network with 7 TBRs (2x hardwired AppleTV 4K 3rd Geb, 4x HomePod Mini, 1x HomePod v2) and 55 Matter over Thread devices from Nanoleaf and EVE paired to Apple Home and Home Assistant.

At the moment everything looks good. When I find the time and these already updated bulbs are stable, I am going to update the other 8 bulbs tomorrow.

[wild oracle]

interesting usecase. so as i've reflected on what the "manufacturer specific" behaviour, the best i've arrived at is something like a short, but smooth transition to get to the closest point. this will likely look like a hockey stick transition. it eliminates the "jarr", but otherwise may not be what you're looking for? further, it seems the spec basically actively discourages these types of transitions, which to me implies the app layer should instead be more explicit in definining shorter intervals (e.g. calculate first the closest HS value to CCT you're coming from, and THEN define an HS transition).

[opal sparrow]

Yeah, in my use case I'd be transitioning from CT to RGB with a fairly short transition. Like a 5s transition from CT to a nearby XY color. But I think the main improvement available would be in making <1s transitions between arbitrary CT and RGB colors look smooth for when people switch from normal lighting to a scene with accent lighting.

For that, a direct crossfade where you fade out the WW and fade in the RGB at the final color would probably look best

Which I think is already the behaviour when you switch between modes in the nanoleaf app

I just have no idea what the current color attributes should report during a transition like that. Having it report the final color while the transition is running wouldn't be that bad imo.

[edgy tusk]

Can you give me the link to manage individual products for the software beta?

[craggy plaza]

https://helpdesk.nanoleaf.me/en-US/how-do-i-sign-up-for-beta-software-updates-for-my-nanoleaf-lights-341522

[craggy plaza]

One Evening later… Everything works as expected. All lights are available and react as expected. IMO they are a bit faster, when switching on/off.

Anybody else here, who installed the beta software? 😃

[swift phoenix]

I am getting bunch of chip errors when running lights on and off

[plain kettle]

Got the logs? (Of the chip error)

[swift phoenix]

Sure one sec

https://dpaste.org/P8Z9c

https://discord.com/channels/330944238910963714/1244695124638826639

Also here got some logs too

[green frost]

When you have time, please list the bulb type and the firmware that is installed.

[swift phoenix]

The A19’s and the latest beta firmware 3.6.196

[plain kettle]

Yeah, Ill help ya out in the HA discord when I’m off of work, looks simple enough to see if it’s a HA issue or NL

[green frost]

I take it that those are the new A19 bulbs.

[plain kettle]

Yes, MG24 based ones

[swift phoenix]

Im gonna be out of town for a week so I might not be able to do too much testing. I could always try to just remote connect and see the logs though

[green frost]

The $24 question is, do they work with the Nanoleaf application. How many Thread Border Routers do you have? (please say it's only two)

[plain kettle]

It’s all mDNS debugging, hard when you are away hahaha, all good tho I’ll ping you in the HA discord when I figure out what the issue may be

[plain kettle]

I’ve seen people with over 15 TBR’s and no issues, the number as long as it’s not higher than 20 or so don’t really matter as much

[green frost]

There is no reason to have more than two. For each, it adds doubles the traffic of one. The more end devices and routers the traffic can cause big issues.

[plain kettle]

🙄

Trel exists you know

[plain kettle]

3.6.196 Beta released

• Fixed an issue affecting setup in very busy Thread environments
• Reduced reporting interval when using longer color temperature transitiontimes in Matter
• Fixed a number of other minor issues

[swift phoenix]

#1184371187464290344 message

[plain kettle]

yep

huh weird

im seeing chip errors now

[swift phoenix]

Sums it up

[plain kettle]

nah coz xiaomi, are you able to use proxy to outside the mainland?

[woven scaffold]

Yes I do,but something wrong

[plain kettle]

might have to ask your mate @tiny galeto borrow his creds and use his proxy 🙃

[woven scaffold]

The firmware update option appeared for 5 seconds, and then disappeared.

[plain kettle]

does the proxy work for other apps?

[woven scaffold]

I only need Nanoleaf's server in mainland China to synchronize the latest beta firmware in time, instead of needing a global agent.

The current experience makes me deeply realize that mainland China is suffering unfair treatment.

[plain kettle]

you would know best out of anyone in this server, isnt it due to xiaomi's restrictons?

[woven scaffold]

This has nothing to do with Xiaomi. I don't care about Xiaomi at all. I have my own global agent. It's the Nanolaef App that has the problem.

Nanoleaf staff from China told me that mainland China has local servers, but they don't keep up to date with the latest Beta firmware updates.

[plain kettle]

Strange how your global agent/proxy doesn’t work but ward’s does

[woven scaffold]

This made me realize whether I should sell all my mainland China products and switch to foreign regions in time.

[plain kettle]

From what I’ve seen, stuff being sold in Taiwan even is the international version

That would be a ton easier to import than stuff from Australia or nearby counties (for hard wired/non battery devices)

[woven scaffold]

I think this is not just a proxy issue. I can easily have a global proxy, but this is obviously not in line with normal usage habits & norms.

[plain kettle]

Hmm right

[high atlas]

shadoxity has been warned

Reason: Bad word usage

[feral steeple]

Bad word?

[plain kettle]

They are strict on some things and not on others 😔

[main matrix]

classic bot discrimination 🙃

[woven scaffold]

I’m in

[plain kettle]

Ha nice work!

[green frost]

Dumb bot.

[feral steeple]

Anyone have feedback on the new firmware? im going to update my ones that are playing up the most to see if it improves it and leave the ones that are largely stable

[woven scaffold]

3.6.196 Firmware, after the experience, for me, there is no improvement in visual transition. Switching different colors in Apple Home, there are still no transition effects.

[green frost]

Are you able to try using the Nanoleaf application?

[woven scaffold]

The transition effects in the Nanoleaf App are normal. I mean it is not normal in the Matter Platform(Apple Home)

[green frost]

That is what I mean. Good with Nanoleaf application, bad with Apple Home. In about 10 hours I will have my test rig setup and will test with Amazon. I expect to get the same results as yours.

[plain kettle]

That uses the Bluetooth cluster (Nanoleaf one) not the matter one

[green frost]

Are you using the Nanoleaf Desktop or Phone application? If phone, can you turn off Bluetooth and use Wi-Fi only?

[woven scaffold]

Shockingly, this means that my Nanoleaf Matter over Thread product, Thread is only used for On/Off communication, while the color transition uses Bluetooth?

[plain kettle]

Well, it does use the matter stack, but as you know it’s gotta fit within the spec and it can be jank

But if you use the app, it uses Bluetooth/custom spec, but Apple home uses the matter/thread spec for communication

[green frost]

No. It should be using Wi-Fi.

[plain kettle]

Huh? It’s a matter over thread device

[woven scaffold]

I have another Matter over Thread (MG24) spotlight in my hand, which does a good job in color transition. For Nanoleaf, I don't know what the difficulty is?

[plain kettle]

Yeh, silicon labs fixed most of the issue a few months ago in one of the RC releases

[plain kettle]

You work out what SDK version that uses?

[woven scaffold]

Phone App and WiFi Only(BT is turn down)

[green frost]

Great. Thank you. So that bulb now has the Nanoleaf firmware and the current CSA firmware on it.

[woven scaffold]

No,I don’t know

[plain kettle]

Current CSA version? Nanoleaf are using matter 1.2 SDK

[plain kettle]

Nah all good, it’s a bit complex to find out (not as easy as grey market Chinese vendors lol)

[green frost]

It only uses the firmware which is published in that SDK tome.

[woven scaffold]

I will consult the person in charge of this brand (Energy Magic Cube), also MG24, about why they can do a good job in Apple Home.

[green frost]

Maybe get their expert and Nanoleaf to talk. It might speed up the process.

I am scheduling a trip to Hong Kong and Shenzhen in July, to vist for a week. Then on to one of the factories in Vietnam and a well needed vacation. I'm hoping to get a good insight into the magic.

I wonder if I can get a new spectrum analyzer at a good price. Test equipment is getting very expensive here.

[woven scaffold]

Yeh, I saw this kind of thing in their laboratory(Energy Magic Cube)

[woven scaffold]

I’ll try

[green frost]

I just can't justify $20K for an HP 8565E. And I can't keep borrowing one from the avionics lab. Why was I not born into money? LOL

[green frost]

Where are you located?

[woven scaffold]

Mainland China

[green frost]

Which city. Please say Shenzhen.

[woven scaffold]

Fine, I will go there in July, but not now…

[woven scaffold]

Shandong Province

[green frost]

I haven't been that far north. Only as far as Shanghai, which I found delightful and beautiful.

[woven scaffold]

Will you go to the Matter Open Day in Guangzhou in July?

[green frost]

I didn't know about that. I will look into going. So much to plan for.

[woven scaffold]

@green frost I learned that, as you guessed, the Matter lighting manufacturers from China have some private code optimization independent of the Matter standard lighting specification, so they have made exclusive optimization of the transition special effects between different colors for a better experience. However, once the standard specification optimizes this function in the future, they will quickly OTA

I can understand that the Nanoleaf Matter lighting series only follows the Matter standard specification and does not do some optimization independent of the Matter lighting standard?

[plain kettle]

They do, they have their own stack that does most of the stuff within the ecosystem, unfortunately it’s pretty intensive and would cause the matter stack to crash (stop advertising mdns) in the early firmware versions

[woven scaffold]

OK…

I guess, is this related to Nanoleaf's early RAM & Flash selection error of MG24? This has led to their at a loss: not only to take into account the exclusive features of the Nanoleaf App, but also to be compatible with the Matter specification. Has the Flash capacity of MG24 reached the limit that makes it impossible for them to add any Matter transition optimization?

I want to know if the MG24 configuration of Nanoleaf Matter over Thread Essential Series is 256 KB RAM & 1.5 M Flash?

[green frost]

If you spend a week reading the documentation without going mad, it's still confusing. It is going to take longer for Nanoleaf to work through the code for each type of bulb. I don't fault them for any of the issues. It's a mess.

[woven scaffold]

If Nanoleaf really can't add any optimization code, I personally suggest that Matter over Thread Essential Series should remove the exclusive features compatible with Nanoleaf App and completely make a pure Matter over Thread lighting device (because we don't need a complex Matter lighting device at all, because if we need complex lighting effects, there is no reason to choose Matter. PS:Especially when the Matter lighting specification is not perfect.)

[woven scaffold]

I fully understand your feelings.

[green frost]

I would think any optimization will come last.

[woven scaffold]

OK, I will give enough patience to expect Nanoleaf to be top enough in Matter over Thread lighting.

[green frost]

One thing I don't like about Matter is, No custom key value pairs. Even W3 conceded that custom key value pairs are necessary.

I'm so glad I moved out of hardware. Software is exponentially easier.

[woven scaffold]

I think you should talk to the team leader of the Matter Lighting Tag Team and the top 3 brands.

Govee is brainlessly launching a large number of Matter over WiFi lighting products. I want to know if this affects the power of Nanoleaf's firm Matter over Thread Essential lighting series optimization.

[green frost]

That's up to the product managers. I know there are some independent developers that have a grasp of this. I've been following Universal Devices and their work seems very productive. I want to see this thing ironed out. Matter and Thread need to simplify their work. Tread should be simple. It should have one Master and X Slaves. That would cut the traffic considerably. Thread needs optimized. Matter needs to decided precisely on how to shorten the status reporting. Tell a bulb exactly what to do and the bulb reports OK when complete or ERROR if it ran into an error while preforming the command. That would be a start.

Goovee is trying to be first to market on a lot of new products. A lot of their hardware is crap. And some of their hardware is best in the market. Goovee just can't decide what their market is.

[woven scaffold]

At present, some companies have shown me that a TBR equipped with MG24 can drive the smooth control of 254 lighting devices. I want to wait for the accurate implementation of Matter 1.3 and the release of Thread 1.4. We can expect some better improvements.

[green frost]

I never did like Thread but it's here. Wi-Fi is so on everything so it's easy to use. If Nanoleaf built a Wi-Fi to Thread hub it might solve a few issues.

[woven scaffold]

Yeh, I also think Govee is rubbish, but their predecessor is Anker. They are just a trading company that can only create a lot of chaos.

[green frost]

I did not know that. I never bothered to research the company.

Their high end light pole is nice. Nanoleaf has all the parts to build one.

[plain kettle]

Yeah basically

[green frost]

Does Goovee actually build anything?

[plain kettle]

They are basically just a OEM seller

[woven scaffold]

I won't do too much in-depth research on Govee unless they plan to launch a large number of Matter 1.2&1.3 appliances later.

[green frost]

Interesting. I like searching Amazon and finding the exact item offered from several companies, all claiming to have built the product. And then getting them into a pricing war.

I need to strip some Goovee products and trace back to the factory.

[woven scaffold]

The Matter over WiFi market is full of a large number of low-priced Beken & RealTek, which leads to very chaotic. It is hoped that Nanoleaf will continue to adhere to the Matter over Thread product line.

The factory of GE Lighting is in China.

[green frost]

I think too much is in China. I remember when it was all in Japan.

[opal sparrow]

fwiw, if you scroll up in the chat I recently had a conversation with one of the Nanoleaf folks about some of the issues, including the problems with transitioning when switching color modes. They're aware of it and seem to be open to making use of a spec allowance for "manufacturer-specified behaviour" to allow enabling smooth transitions, at least for the case of short transitions like when activating a scene.

note that the nanoleaf private protocol does run over thread too, not just bluetooth. That's what the _ltpdu._udp mdns service is for.

it doesn't seem like they want to support long transitions between color modes which might leave both the RGB and WW LEDs on for an extended time. Unclear why. My speculation is power/cooling issues.

[woven scaffold]

Get

[opal sparrow]

I'm not sure what you mean by this. matter supports custom attributes within clusters, custom clusters, custom commands, etc. by namespacing the names (keys) using the vendor id. some vendors have used this to implement functionality that was missing or not yet ratified in matter (e.g. eve energy smart outlets used custom attributes for energy usage reporting with matter 1.2 before it was added to the standard in 1.3)

in some of the earlier 3.6 beta firmware, it looked like nanoleaf was preparing to add some matter extensions (they had added a few custom attributes to one of the clusters on the lighting device endpoint), but that change got reverted because it needed more work in the multi-admin subscription handling.

[opal sparrow]

the entire point of network protocols like thread and zigbee (which are both based on the same underlying radio standard) is that they can use extremely low power radios, but still reach everywhere in a building by relying on externally-powered devices forming a routing mesh to relay messages. That means some complexity in the protocol is necessary so devices have an idea of the "shape" of the network so minimum relaying is done and loops are avoided. separate from thread, I agree that matter has some specification issues resulting in too many messages being sent, I've talked about this before.

note that because matter is multi-admin, it's important that if one fabric (e.g. apple home) changes the color of a light, a notification is sent to other fabrics (e.g. google home) to let them know that the color has changed.

[opal sparrow]

hmm, actually, thinking about multi-admin… the new 3.6 beta firmware changed the handling of reporting the RemainingTime attribute during transitions. I should poke at that, see what the behaviour is with multiadmin - when one fabric starts a transition, is the other fabric informed that a transition is running?

[plain kettle]

To add onto this, companies do use this, Eve. Used it to bypass no power/monitoring cluster by just dumping the information within the custom cluster and allowing third party providers, like the Eve app, or HA, or smartthings to read from it.

More towards GW, not you kep 🙃

[opal sparrow]

there is a downside to the way eve implemented that; meant that the data wasn't included in subscriptions. Home Assistant had to add some extra code to manage polling it at a reasonable rate :/

[plain kettle]

That’s true, but hence why Eve didn’t really “announce” it, more provide it and make the matter server/s manage it

[opal sparrow]

(That's coming in HA 2024.6; https://rc.home-assistant.io/blog/2024/05/29/release-20246/#updates-matter )

[plain kettle]

Yep, just pending an Eve update, which from what I’ve heard on the grapevine is getting close

Those Nordic SOC’s are beasts

[undone spire]

Isn't that exactly what they have done with the announced but unreleased Nala Learning Bridge. Judging from the timeframes in the ces 2023 announcement and the light switches being tested in the wild, it shouldn't be to much longer before they start testing the bridge if they haven't been already.

[plain kettle]

Yeah, the bridge seems to be an attempt to rival what Aqara are doing

But issue is, Nanoleaf are a lighting company, not a IOT/sensor company like they are

Will be interesting to see how it happens

[opal sparrow]

I have confirmed - only 100 discrete brightness steps during transitions. The matter brightness value updates through the 254 values, but the bulb brightness only actually changes on some of the steps not others (specifically, bulb brightness only changes when round(N/254*100) changes, for some definition of round that doesn't exactly match home assistant's display).

[green frost]

That would be mostly correct. From off to full bright in 1% steps. While the bulb or switch uses a byte of memory (0 to 255), levels are set in percent. Therefore the need for the calculation and rounding. That's been the standard since v1 of the X10 protocol.

[opal sparrow]

there's no requirement in the spec for levels to be set in percent; The 1.3 Application Cluster spec 1.6.4.2 just says that 1 is minimum level, 254 (0xFE) is maximum level, and "All other values are application specific gradations from the minimum to the maximum level."

[green frost]

There are no requirements not to. Setting as a percent has been used since the 1990s.

[opal sparrow]

Additionally, 1.6.7.1.1 (The MoveToLevel) command says "The movement SHALL be as continuous as technically practical, i.e., not a step function"

[plain kettle]

youd swear the csa are addicted to using shall with the amount they use it 😅

[opal sparrow]

They do something similar to what the IETF does - it's a keyword with specific meaning.

SHALL indicates a behaviour that is required for certification.

[green frost]

Even if it were to use 0 to 255, it is still in steps.

[opal sparrow]

"as continuous as technically practical" means that the transition can be in finer steps than the resolution of the CurrentLevel attribute.

[plain kettle]

this hasnt changed from 1.0 yeah?

[opal sparrow]

Pretty sure it's unchanged since zigbee

[plain kettle]

sounds similar to what i was reading a few months ago when this whole thing with the trash fimrware was coming to light

[opal sparrow]

I just referenced a particular spec version since section numbers can change between them.

[plain kettle]

i mean zigbee and matter share some pretty big similarites, other than one is ip based and the other isnt*

atleast in the 1.0 spec it did

[green frost]

Yes, and I agree with that but, 0 to 100 is not wrong as that is how switches currently handle settings.

[opal sparrow]

the matter spec is explicitly based on the zigbee cluster library, yeah. The lighting-related clusters are practically identical.

the behaviour of only being able to set brightness to 100 distinct values is fine. I'm talking about transitions.

[green frost]

You may not agree with Nanoleaf using 0 to 100 but if that is what they consider practical, then it is correct.

[opal sparrow]

(In fact for clusters copied from ZCL, the version numbering is continuous from ZCL to Matter; typically the version as standardized in matter has the version number increased by 1)

Here's the thing: The bulbs support finer steps in transitions. We know they do, because the transitions are visibly smoother when triggered by the nanoleaf app.

[green frost]

You can make the case that it should be 0 to 255, and you probably should.

[opal sparrow]

(I can't find the exact spot where I saw this, but they explicitly advertised 0.1% in a few places)

Matter spec says if the hardware can do better than that, then transitions should be smoother than that.

The "0.1%" makes me suspect that they're running 10-bit PWM (1024 brightness levels)

[plain kettle]

well yeah, but thats just coz they can kinda just "do what they want" when it comes to controlling their own bulbs over thread, no need to conform to the spec and bounds of matter

[opal sparrow]

Anyways, I don't care about getting more precision in the set value of brightness. 100 values is fine. I just want smooth transitions - and the matter spec says transitions should be smooth, and the hardware supports smoother transitions.

[green frost]

You and I don't even know the percentage of power needed to even energize the lights. I have some LED bulbs that won't even show until it gets to 16%.

[opal sparrow]

Oh, for sure, a minimum brightness and application of a gamma curve to the values can cause the actual usable range to be reduced compared to the available PWM steps. But regardless of that, the bulbs are capable of smoother transitions than are currently available via the matter API, and the matter spec says, as I quoted, "The movement SHALL be as continuous as technically practical, i.e., not a step function"

right now it is not as smooth as is technically practical, and is visibly a function with a series of steps.

[green frost]

A huge problem is going from full on white like (6500k) to 50% yellow. The math is simple enough but I do not think everyone will agree on how it should be done.

[opal sparrow]

Transitions between CT and RGB modes are a separate issue that I've discussed with some Nanoleaf folks earlier.

[green frost]

The best I found with the GU10 bulbs is to reduce the light to 50% in smooth steps then set the color and bring it up while bring the white down.

[opal sparrow]

They seem to be open to the idea of using a statement regarding manufacturer-specified behaviour in the matter spec to allow a crossfade between CT and RGB colors when transitioning between modes, at least for short transitions like activating scenes. This would match the behaviour of the Nanoleaf app.

[green frost]

If changing RGB from color A to color B there are a few methods. I liked adjusting the RGB levels in steps until arriving at the new color.

( I should have put this in two paragraphs.)

If you have a good solution for a smoother transitions, work out the math, build a formula and submit it to Nanoleaf.

[opal sparrow]

Matter spec specifies a few specific methods for transitioning between two different RGB colors, and Nanoleaf follows those.

(The methods depend on whether the X,Y or Hue/Saturation methods are used to specify a color)

You keep bringing up different topics. I was originally talking about Brightness transitions, then you brought up CT to RGB transitions, and now RGB to RGB transitions.

[green frost]

Even with brightness transitions, no ten people will all agree on the same formula.

[opal sparrow]

All 10 people will agree that a transition triggered on a nanoleaf bulb via matter - especially a relatively slow one at mid-low brightness levels - is visibly not smooth.

[plain kettle]

i wonder what silicon labs recommend, obviously the would have a few demos for the MG24 and i wonder if nanoleaf has kinda just bulit off of that

[opal sparrow]

That's all I'm asking for. Make it smooth. The hardware is capable, the spec says not only that it's allowed but that they SHALL do it.

[green frost]

To me, brightness should be controlled by voltage. Color set with RGB.

What would be better is set brightness based on lux. Then bulbs of different wattage could be set to the same brightness based on the lowest common wattage. Does that make sense to you.

[opal sparrow]

@GW That's irrelevant to anything i've been talking about, and you can't actually talk about brightness and color separately.

[plain kettle]

its not linear, you cant just increase the lux without the colour "changing"

[opal sparrow]

You know how you set a color on an RGB bulb? By individually changing the brightness of each of the R, G, B color channels.

(similarly, color temperature is set by individually changing the brightness of the warm white vs. cool white LEDs)

[green frost]

Yes. I understand that. Once I have yellow, I should be able to control the brightness of that yellow.

And I know that is not currently available in an RGB bulb.

[opal sparrow]

I have no idea what you're talking about. Adjusting brightness of a color using the LevelControl cluster in Matter works perfectly fine on existing RGB bulbs including Nanoleaf's

[green frost]

Anyway, back to your want, if you have an idea on a smoother transition, tell Nanoleaf.

[opal sparrow]

Keep in mind that matter does not allow you to specify RGB colors directly. You can only specify the "color" via hue+saturation, or x,y chromaticity coordinates.

I already have.

[plain kettle]

i mean, we have. but obviously we have no idea how deep-rooted this issue is

[opal sparrow]

I suspect they have some challenges from how they seem to have added the Matter stack on top of their existing firmware, and communication between the two sides is a bit odd

[green frost]

How many users know the "hue+saturation, or x,y chromaticity coordinates" vs the users that know RGB.

[plain kettle]

they dont need to "know", but every so often you see complaints about it on reddit or on some forum, so "normal consumers" are aware of it

[opal sparrow]

Doesn't matter. The end result is that the bulb receives separately information about the color vs brightness, and you can freely change the brightness while maintaining the same color.

And then the bulb calculates the relative values of the brightness of each LED to achieve the desired color at the desired brightness.

[green frost]

Fortunately, Nanoleaf already does the translation with the tiles so I hope that will be built into all the new products.

[plain kettle]

tiles are not conforming to the matter spec?

thats the root issue here, the hardware and the spec both have the ability to do this

[opal sparrow]

Nanoleaf already does high quality smooth transitions between CT and RGB, and between RGB and RGB on their essentials bulbs too. Just it's not available via Matter.

(actually, the RGB to RGB seems fine)

I suspect that the RGB to RGB and CT to CT transitions might still be happening in steps, but the different units and attributes used for color selection mean that the steps aren't visible.

a change of 1mired in color temperature is just barely on the "not noticeable difference" side, so stepping in 1mired increments will look smooth.

[green frost]

Users will care that purple is purple. They will expect the Shapes and bulbs be the same purple. That's all they will care about. Most won't care if a transition is off.

They will also care that strips and bulbs have the same colot temp and brightness.

[opal sparrow]

Several people have come into this and other channels on the server complaining that their bulbs aren't able to transition smoothly between white and color light when activating a scene, compared to bulbs from other vendors. This is quite frustrating, when the hardware is obviously capable.

[green frost]

You are talking a very small percentage of the users. 99% of Nanoleaf customers don't even use Discord.

[opal sparrow]

I use the lights to do a "sunrise simulation" thing where they slowly increase in brightness in the morning as part of my alarm, and it's kind of annoying that there's visible steps in that increase which should be fairly smooth.

[plain kettle]

for sure, run it via the NL app, no visible stepping at all

this would be present for all the current, and in production devices that use matter, so the whole essential lineup, those new string lights and more.

[opal sparrow]

(Also, color accuracy on my Essentials light strip is terrible)

Dunno if i just got bad hardware or what.

[plain kettle]

last i heard the matter version and homekit version was using basically the same SOC and lighstrip, just upgraded controller firmware

[green frost]

@opal sparrow You and I are the exceptions. We want it all and we want now. I wish that could happen. Nanoleaf can't expend recourses to satisfy us. First the need a viable product on the market. When time permits, then they can work on fine tuning the operation.

[opal sparrow]

From what I've seen now and in the past, you've been asking for things that are either unrealistic or impossible within the scope of a product built on matter and thread. I'm asking for some relatively small fixes to do things which their hardware and firmware are already known to be capable of, and would bring the product in line with how a matter device should behave (and indeed, in some cases, how devices from other vendors do behave).

[plain kettle]

i mean, we all know nanoleaf are a hardware as a service company, but thats no excuse for what should be (depending on how they implemented it) a simple fix

[green frost]

There are/have been issues with the light strips. I don't know the outcome, but the color is not as it should be.

[green frost]

Yes, I ask for a lot. I want simplicity. I want the products to work together without the need of third party hardware. And I demand that products work well with NO Internet connection.

[opal sparrow]

(The only thing I've been asking about which isn't supported by the Matter spec is regarding subscription attribute reporting - and amusingly that's something they've already been working on, with some related changes included in the 3.6.196 firmware)

[green frost]

A subscription will be very nice. I'd rather have the bulbs just report their status in the same way that Canvas, Shapes, Lines and other tiles do.

[opal sparrow]

The reason that I'm a proponent of matter is explicitly that it allows devices to interoperate with third party hardware in a standard way, locally (no internet connection). For a single-vendor system there's no reason to use matter at all, and indeed nanoleaf has a non-matter protocol that they use for their own stuff.

[plain kettle]

how does the essentials lineup currently do the interaction? Invoke?

[green frost]

Poorly.

[plain kettle]

well yeah i know that, but what method?

[opal sparrow]

Well, in matter, "Invoke" just means a transaction which sends a command, so yeah - that's how all control is done.

[green frost]

I like Matter. It's a good idea.

The original Essentials just used Bluetooth and you had to use the application to control them.

[opal sparrow]

And "Subscribe" interactions to receive events and attribute updates.

I thought the original Essentials were Homekit over Thread devices?

people still use those with Home Assistant since it can speak the homekit protocol directly, heh.

[green frost]

You are correct.

I'm looking at the box on my desk.

[plain kettle]

you dont even need a apple home hub if you use the homekit intergration, and you get all the functionality, its pretty neat the work j3ck put into it over the years

[opal sparrow]

It can even do the thread network provisioning over bluetooth to a non-apple thread network, yeah.

[green frost]

I don't have any Apple products and Nanoleaf didn't have a method to the the Shapes to tell the Essentials what to do. That was my complaint. Eski and I had a lot of discussions abnout that.

[plain kettle]

doesnt the shapes have a thread border router?

[opal sparrow]

Is the problem that the nanoleaf app on android can't provision the old homekit essentials bulbs to a thread network, like it can do with the newer matter ones?

[green frost]

Yes. But that's it. There is no way to talk to Shapes to tell the border router what to do.

[plain kettle]

hmm?

[opal sparrow]

border router's don't... "do" anything. they just route.

[plain kettle]

rightio

yeah, its just a router at the end of the day

[opal sparrow]

That said, some commands are useful in order to get a border router to join an existing thread network rather than form its own.

(and newer thread specs are supposed to help that happen automatically... eventually)

[plain kettle]

yeah, its a shame nl never exposed the internal API, even over their webserver

[green frost]

Yes. There is no way to talk to Shapes to tell it to route the instructions to the border router.

[plain kettle]

i mean, back in the day the only way to get the TLV of a apple network was through the nanoleaf app 🤣

what does the shapes need to tell your other lights? i dont get it

when you commission the device, assuming you have the credentials to that thread network on your phone it will just join

[opal sparrow]

Maybe this is a terminology problem? The border router isn't a separate thing, it's part of the firmware of the Shapes device.

[plain kettle]

sounds like you getting mixed up here....

no diffrent to the apple homepod having a border router, or the apple tv, or the google nest devices

[green frost]

The key word is Phone. I want to push a button on a Stream Deck and have the Shapes and light strips do something.

[plain kettle]

right. now i got you

no the phone is just for commisioning

to send the credentials to the thread network (to the lights)

[green frost]

The phone is good for setting up the product. You generally have to use the phone to set the IP address of most items.

[opal sparrow]

right, and that requires sending commands to shapes, and separately to the light strips (which happens to be routed through the border router running on the shapes device). If the light strips are connected to thread and mdns + ipv6 routing is working in your network, that should all be fine.

[plain kettle]

maybe the NL app or whatever doesnt support it?

i have no idea, i use HA + the streamdeck app through that

i get why it might not, i dont think the OTBR/thread br api is exposed over the local shapes API/webserver

i have talked to paul may times about atleast exposing the API for it, but got nowhere it seems lol

[opal sparrow]

You don't send commands to Shapes to control other devices. You send commands to other devices, which due to the IPv6 routing table get send to them via the Shapes device as a thread border router.

[plain kettle]

should work even using NAT64

[green frost]

Ideally, Nanoleaf will produce a 'Hub" that is configured once and all new devices will see the hub and automatically connect to the correct network.

[plain kettle]

yeah, idea of matter is to reduce the needs for hubs...

maybe nanoleaf do what aquara has with the M3? but dunno how well it would sell and if the demand is even there

[green frost]

The devices will still need to be configured initially. Otherwise, your neighbor will be able to control your lights.

[opal sparrow]

A "hub" is just something that combines multiple separate pieces of functionality. In matter terms, usually it's a device which combines a controller and a thread border router (and optionally it can also be a matter bridge, with other radios like zigbee or z-wave)

[plain kettle]

well yeah, but you use your phone. exactly just like how the shapes are set up now (over homekit)

you just have the thread credentials on your phone (apple keychain) over bluetooth to the device

[opal sparrow]

As far as I know, only Amazon has really succeeded in selling devices which are pre-paired to the network of the person who bought them :/

[green frost]

The problem with the Phone is it stays with me. I needed a simple way for others to control the lights.

[plain kettle]

yeah. you just use multi-admin and share it to another ecosystem (apple homekit, google home, home assistant) and then share to users from there

you are not pairing it to the phone

[green frost]

Pretend you have never heard of Home Assistant

[plain kettle]

huh?

its a valid ecosystem that many people use nowdays for local control

[green frost]

Hang on. I am not saying it isn't. For this discussion, you do not use Home Assistant.

[plain kettle]

why not?

amazon alexa

any of them

they all support matter as a protocal

samsung smart things

all ecosystems that support multiadmin

you pair the device (light) to any of them

and allow you users to control the IOT device throught that

[green frost]

Let's say Shapes and Essentials is the first thing you bought and you have never considered anything else.

[opal sparrow]

Also, all of these ecosystems support having multiple users connect to the controller, and control all of the devices that the controller is connected to. They do indeed all currently require a piece of hardware on the network, tho.

[green frost]

Come on. Play along.

[plain kettle]

yep, so when you install the shapes. assuming that is your first thread network. that should be put into the keychain/play services (for android)

so then when you pair the essentials lights to say apple home, those credentials for how to join the lights to the thread network are sent, and they join (over bluetooth)

[green frost]

At this point, you don't even know what a Thread network is.

[plain kettle]

ah wait, shapes arnt a matter controller

[opal sparrow]

The only time there's a problem is if you don't have a third party controller for some smart home ecosystem.

[green frost]

Exactly.

[plain kettle]

well yeah, thats nanoleaf just not using a matter server.

but the packaging does say you need a matter controller

[green frost]

All you know is you want to push a button on a remote and have the shapes and bulbs turn on.

[opal sparrow]

Since in order to share devices with another person, you either need to pair them (separately) to that person's ecosystem/phone, or use a controller that all devices connect to and provides a multi-user management interface.

[green frost]

That's is going to be a lot of the customers. We don't have those issues. But there are many that will.

[opal sparrow]

Well, given that nanoleaf doesn't (yet) sell a remote, currently the only way to do that is with a third party remote connected to a separate smart home controller which also controls nanoleaf devices.

[plain kettle]

to be fair, they do tell you on the box you need a home hub, aka a matter controller

[green frost]

Who actully understasnds that. \

[plain kettle]

it sends you to a link, which makes it pretty clear the requirements

no different to zigbee end devices , can make the same mistake there

[green frost]

Mother is shopping for a birthday gift for her son. She knows he likes light.

[opal sparrow]

This is something that, imo, IKEA actually did a really good job at. They sold at launch both remotes and lights which supported zigbee light link to pair directly with each-other without a coordinator, and even sold them pre-paired.

and then the coordinator/hub was an optional add-on for more functionality

[plain kettle]

yep. and its super easy to add third party devices to that zigbee network

[opal sparrow]

(notably, without the hub, there was no way to control the lights from a phone; you could only use the remotes)

[green frost]

The industry needs to make this friendlier. Yes, IKEA had the best idea.
Now, my point is that Nanoleaf should move towards that.

[plain kettle]

i know aquara do that for thier more expensive door locks

little E1 usb hub, so you dont need to have a exisiting zigbee network

[opal sparrow]

FWIW, the fact that nanoleaf has a private bluetooth interface does mean there's potential for them to set up a thread network without a border router between devices. I wonder if they'll ever try to do that.

[green frost]

@opal sparrow You get frustrated over the technical side of transactions. Imagine the poor first time user.

[plain kettle]

i mean, no reason they couldn't stuff in a matter controller into their controllers for the shapes/lines etc 😛

[green frost]

That's a great idea.

[opal sparrow]

the press releases on the Nala products suggest that some Nanoleaf devices with border routers might gain controller functionality as an update.

[green frost]

Just a small hub for those that need it and grow the customer base. Philips did it with Hue.

[plain kettle]

no one is disagreeing with you, its just how much demand there is for it

[opal sparrow]

I mean, they've already announced that device.

the "Nala Learning Bridge".

[plain kettle]

they announced the sense+ 3 years ago and CES and its not even out yet, R&B limbo

[green frost]

@plain kettle We are the 1%. The other 99% will need it.

[plain kettle]

i dont reckon the % is that high, tons of houses atleast have a single google, apple or amazon smart device, atleast in australia they do

[opal sparrow]

of the 99%, most of the people interested in smart lights probably already have a matter controller from another vendor like apple, google, amazon, samsung available.

[plain kettle]

yep

[green frost]

This is the conversations I had with Eski about four years ago. Long before he got married and found a life outside Nanoleaf.

[opal sparrow]

hilariously, google home lets you add matter devices to your home via the a phone when you don't have a device that can act as a google matter controller.

they show up in home, but just greyed out and unavailable

[plain kettle]

ahaha sounds about right

glad they are opening the whole ecosystem up with fuchsia 18+

https://fuchsia.dev/whats-new/release-notes/f18

[opal sparrow]

it's actually still useful somehow, tho, since in that state it lets you remove the google matter fabrics from the device (which happens directly from your phone)

[plain kettle]

better than apple hogging 2 of the 5 slots, thanks apple keychain

[opal sparrow]

I thought 3 was the min number of slots

[plain kettle]

they do a good job at allowing removal of admins on their settings

[opal sparrow]

2/3 is even worse ;)

[plain kettle]

i thought the cap was 5?

[opal sparrow]

gonna have to look that up. but i recall that matter devices are required to support being connected to at least 3 fabrics concurrently.

[plain kettle]

it might depends on the SOC honestly

i remeber eve (nordic) being 5(?) or a figure around that when i last asked them

[opal sparrow]

Hmm, no, you're right. The minimum value for SupportedFabrics is 5.

[opal sparrow]

These release notes don't really say anything about matter or ecosystem stuff? Just that the fixed an issue with matter devices with multiple ip addresses.

I'd assume that the changes for google home local control and such are all happening at the application level rather than os level.

[manic plover]

Delivered on the promise today - EUR 850 purchase made 😊 Keep the improvements coming, I'll keep scaling up 🤝

[plain kettle]

Google doesn’t release any notes about the software improvements (not even fuchsia really you have to go know where to go to look)

So anything could be possible

[opal sparrow]

Yeah, i'm just saying that the link doesn't support your statement that "they are opening the whole ecosystem up with fuchsia 18+"

[green frost]

I have nine GU10 bulbs online and updating to 173. One is being stubborn.

[manic plover]

Do you have them on the same circuit?

If not, try powering off other bulbs, and keeping a bare minimum on (in terms of supplying electric power).

[manic plover]

Mixed experience with 3.6.196:

Nearly lights appear to be online in the Nanoleaf app. Less, but still more than on 173, appear online in Google Home. But the lights don't respond to commands from Google Home (sometimes few bulbs do, but for the most part it doesn't work). However, they respond to commands from the Nanoleaf app - although with a significant delay (3-8 seconds).

I haven't seen this discrepancy between the Nanoleaf app and Google Home before.

[craggy plaza]

Hi @boreal surge and @wild oracle,

Nanoleaf Matter bulbs are all updated to the latest beta 3.6.196. In daily use I do not recognize any issue, as long as I do not use the Nanoleaf app. Everything works fine in Apple Home and Home Assistant.

My setup is:

Thread Border Routers:

• 2 hardwired AppleTV 4K 3rd Gen
• 4 HomePod Minis
• 1 HomePod v2

Devices:

• 11 Nanoleaf A19-E27
• 10 Nanoleaf GU10
• 14 EVE Energies
• 9 EVE Thermos
• 7 EVE Door & Window
• 3 EVE Motion
• 1 EVE MotionBlinds

In the screen record, you can see that all my devices are connected in Apple Home and everything is fine. There is one device (it’s a heater, which is switched off), so it’s not reachable for Apple Home. After that I open the Nanoleaf app and you see all devices are connected to Thread. Some seconds later, while scrolling up and down, you some bulbs going offline or connecting via Bluetooth. Then I go to Apple Home again and you see some devices are offline. IMO my Thread network starts remeshing, because some minutes later all devices are back online again.

I don’t think that this related to 3.6.193, because I already noticed this 3.6.173. But I use the Nanoleaf app not very often. So it’s not a major issue for me. I think the issue is the app and not the firmware. What do you think about it?

Thanks Hoppel

[worthy grove]

This issue could also be related to high load on your Thread network. I think the app tries to query the devices and produces too much traffic. I see the same behavior if I open the Matter Accessories Section in iOS settings. This also queries all Matter devices and and produces „No Response“ messages, especially if you have a lot of devices and multiple controllers.

[craggy plaza]

Moin Keule, high load? I have 7 TBRs that make use of TREL. So, high load shouldn’t be the problem. I also do not have many Matter fabrics, Apple Home (incl. Apple KeyChain) and Home Assistant. But yes, I always had these issues with the Matter accessories section when I had more than 10 devices. So I also do not use it.

Besides I configured my WiFi not to use 2.4GHz WiFi channel 11 anymore, to reduce interferences with the Thread network on channel 25, only channel 1 and 6 in use. My HueBridge uses channel 20.

However the Nanoleaf app worked as expected since month. I think there was an an app update that made the behavior worse.

But I find it very interesting to see that you have similar issues. I also recognized this in the HA discord. Do you have Apple TBRs only or is there any third party TBR in your Thread network? How many TBRs and MoT devices do you have?

I am also under the impression that Apple OS 17.5 made it worse, but I am unsure…

My MoT bulbs/devices are reliable and very responsive (instant).

[plain kettle]

Just an update regarding Nanoleaf’s updates, they now release the updates to the DCL, so no need for the Nanoleaf app to update them!

[stark crystal]

What is DCL?

[plain kettle]

https://csa-iot.org/certification/distributed-compliance-ledger/

basically the "List" of firmwares/devices etc etc

so apple home, and other matter server vendors can poll the device and compare it to the DCL and update the device

(like how eve does it currently)

basically elminating the need for the app for basic funcations/updating

[stark crystal]

Oh that's useful!

[worthy grove]

I've got 60 Matter over Thread devices (Eve, Nanoleaf, Aqara, tado & Tridonic) on 2x Apple TV's 4K 3rd gen & 2x Homepod Mini. All devices except the Eve Energy's are also paired to HA. My feelings are that Apple got worse since 17.5. My network is quite stable most of the time but there are moments when the hole thread network collapses and never recovers itself. I can only recover it by unplugging all TBR's. Maybe the TBR's are running into timeouts and that crashes things on Apple's side. I also noticed that the polling of the Eve Energy's has a lot of impact to the network. After removing them from HA the devices in Apple Home gets almost instantly refreshed after opening the app. Offen you even don't see the refreshing in the app. Keep in mind that managing devices from two controllers also doubles the traffic in your thread network and that not only the TBR's are involved in routing the traffic.

[plain kettle]

if you have it connected to apple home, you are using 2/5 of the multi-admin slots 🙃

one for apple home, other for apple keychain

[worthy grove]

Yeah, thats right. But I don't know if it really makes a difference because apple keychain is not actively controlling the devices.

And I think that apple keychain does not subscribe to events

[plain kettle]

ah yeah duh

[craggy plaza]

Yep, that’s my understanding, too.

[craggy plaza]

How does this work with beta firmware for the Nanoleaf bulbs?

[plain kettle]

doesnt

wait maybe it can*

ill ask stef. he would know/know who to ask to find out

[craggy plaza]

EVE can do it. You have to give them your AppleID and then you get the beta updates.

[worthy grove]

I think he's using special beta DCL's?

[plain kettle]

maybe?

[craggy plaza]

Yeah maybe…

[plain kettle]

he would have more access to it being a CSA memeber

[craggy plaza]

Is there any other platform besides Apples that supports it nowadays?

[plain kettle]

HA will soon it seems (draft PR), and google home have shown interest

[craggy plaza]

Ok, great news. Where do I find this PR?

[plain kettle]

i have no idea if 3.6.196 is in beta or not still

[plain kettle]

https://github.com/home-assistant-libs/python-matter-server/pull/709

it also is planned to support non-DCL updates which is sick for non-certified people/companies

[worthy grove]

I think so. Nanoleafs support website states 3.6.173 as latest firmware.

[plain kettle]

that website is slow to update tho 😅

[craggy plaza]

My 21 bulbs are all on 3.6.196 and work fine.

[craggy plaza]

Where is this screenshot from?

[plain kettle]

https://webui.dcl.csa-iot.org/compliance

vendor ID 0x115A

product ID (essentials): 0x36

there is also more products, which i assume is the stuff in the HW beta atm

[craggy plaza]

So, you have a similar setup to mine. The polling of the EVE Energies makes some trouble. Yes. So, you removed them all from HA. I will wait until the next HA Core version gets released under see how it works. Release day is tomorrow, right?

[worthy grove]

I don't know if the new Matter Server is also released tomorrow. I've switched back to stable atm.

[craggy plaza]

Awesome! Well done Nanoleaf!

[craggy plaza]

I am on stable the whole time. Too many things changing at the moment. 😃

[worthy grove]

Yeah, I hope that things get better with the release of tv/HomePod OS 17.6. Rumors say that Apple updates to Matter 1.3 with this release.

[plain kettle]

#1049765219565576234 message

[plain kettle]

Seems like it is according to the SDK (should be this week?)

[craggy plaza]

Yeah, I also read about those rumors. I am unsure, if Matter 1.3 solves unreliabilities in regards to Multiadmin, when you have a lot of devices. What I recognized is (when I made the screen record above), that Apple Home looses connection to EVE devices only, when I open the Nanoleaf app > my devices. I have to check it again, but in that case, we maybe also need a new EVE firmware >=1.2.

Nanoleaf now seems to have a more stable firmware than EVE. 😃👍

[plain kettle]

To be fair, I don’t think Eve have released an update since they initially released the matter firmware to the public (matter 1.1?)

[worthy grove]

Could be or they simply are busy with routing traffic from your nanoleafs app query. Sometimes I've seen such resource/device busy messages in HA's Matter Server too.

[plain kettle]

it appears this is the beta/testing DCL

https://testnet.iotledger.io/

[craggy plaza]

Yeah, Sonora time to rollout a new firmware with at least Matter version 1.2. Nanoleaf did it. 😉

[plain kettle]

there is one in the beta, via the Testnet DCL turns out

(1.3 w/ energy tracking)

[craggy plaza]

Yeah, I also saw this busy messages. Maybe the next HA Core and Matter server solves this issue.

[craggy plaza]

Wooohooo… Let’s see how much time it will take, until we see a release.

With energy tracking is meant to use the Matter 1.3 conform variant?

[plain kettle]

i think?

havent really looked into it

as like, HA is the only matter controller to support 1.3

[craggy plaza]

Maybe Apple is the next one with OS 17.6… 😃

[jolly fable]

Opting into the beta for my devices but just wanted to ask before I do... It's possible to downgrade firmware, right? If I ever needed to?

[opal sparrow]

no, downgrades are not possible.

[jolly fable]

By choice?

[plain kettle]

there is a way, but requires manual intervention from what i understand

but some upgrades are irreversible

[jolly fable]

Opening it up? Or putting ip in an app

[jolly fable]

I suppose security is important

[plain kettle]

No, as in the devs doing it

[opal sparrow]

the matter ota mechanism enforces no rollbacks. in theory nanoleaf's update mechanism could bypass that, but they don't currently allow it.

to do a rollback, the devs basically have to re-release an old version except with a higher version number.

[plain kettle]

yeah. they do not want downgrades, rather figure out whats wrong with it

yep that

[jolly fable]

I wonder what that mechanism does in failed upgrades

Like no A/B blocks to switch back to avoiding bricks?

[plain kettle]

i dont think ive ever seen a "failed" update

[opal sparrow]

matter updates pretty much require A/B firmware partitions

[jolly fable]

Thats good enough for me, A partition with old firmware, B with new one

I wonder if thread firmware does the same

[plain kettle]

what is the current firmware?

[jolly fable]

I just got one today but no changelogs

It was from third party app though

[opal sparrow]

what do you mean by "thread firmware"?

[jolly fable]

3.6.196

[plain kettle]

ok thats the latest beta fw as well

[jolly fable]

(198340)

[jolly fable]

I wasn't in beta when I did it, smartthings just pushed it out

[plain kettle]

it wasnt smart things, nanoleaf updated the DCL and obv smatthings caught it and updated/prompted

[jolly fable]

Well thread doesn't always use matter, sometimes it's independent of it. That makes me think it uses separate firmware. Like zigbee does. Or whatever else works on top of 802.15

Thread should really mandate a minimum Bluetooth coprocessor version . Even if end device is not currently supported by matter. Helps to have upgradability to homekit/matter down the road

[plain kettle]

it doesnt already?

to be fair, there has been a ton of vendors with homekit/thread that have pulled out of matter OTA updates

belkin is a big one ive seen (atleast in AU)

[jolly fable]

I've tried looking into it, I thought it doesn't need matter nor Bluetooth support on their radios

[opal sparrow]

The devices have a single firmware image that contains all of the components together.

[jolly fable]

But can't find where, even in new 1.3.0 specs

[plain kettle]

yeah, silicon labs would package it together within their SOC "package"

[green frost]

It doesn't. Thread operates on 2.4GHz.

[jolly fable]

So... No separate software handling the different parts?

I shouldn't have based my idea off of how Home Assistant handles it 😅

[plain kettle]

nah thats alright 🤣 i dont blame ya

HA is basically a bunch of "packages" or like containers

however you wanna think of it

[opal sparrow]

Thread-only devices need some way to provision the network credentials so they can join the thread network, and since Thread and Bluetooth (BLE) use the same frequency range and channel size, in many SOCs there's actually a single radio that does both.

[jolly fable]

But as a side device? I know matter mandates it (for commissioning in their case) but not if thread does when not using matter at all

I didn't mean to communicate over though

[opal sparrow]

A firmware image is basically like an entire OS/disk image, it can contain multiple components/applications all bundled together.

[plain kettle]

matter is built on thread (for matter over thread).

you are thinking it being hand in hand, its not so much

[jolly fable]

Wait one radio can do both thread and Bluetooth? 🤯

...how about 2.4ghz Wi-Fi 👀

[plain kettle]

the MG24 does both thread and ble on a single radio from what little specs i could find out

[opal sparrow]

wi-fi uses a different channel size, so some companies make radios that can only do thread/ble but not wifi

[jolly fable]

Ahh, gotcha

[opal sparrow]

in some cases the wifi and thread/ble will be in the same device but technically be separate radios sharing the same antenna.

[jolly fable]

Does anybody know changelog for latest build?

[plain kettle]

ill get it, was posted a while ago on some chinese forum

[jolly fable]

I wanna see if I got thread 1.3 +trel

[plain kettle]

Poshy — 05/30/2024 10:00 PM
3.6.196 Beta released
Fixed an issue affecting setup in very busy Thread environments
Reduced reporting interval when using longer color temperature transitiontimes in Matter
Fixed a number of other minor issues

[jolly fable]

Although not sure if TREL infrastructure is just for hubs

[plain kettle]

huh? you wont get trel

[opal sparrow]

Release notes are in pinned messages in this channel

[plain kettle]

trel is only for hubs/TBR

[jolly fable]

My bad

[opal sparrow]

trel is only for thread border routers*

[jolly fable]

I forgot this is just for essentials too

How about 1.3? 👀

[plain kettle]

i know google and fuchsia dropped trel support for a good 2-3 months for no apparent reason 😅

[jolly fable]

Oh yeah I noticed that when checking my network

Apple and Google show up with it

Samsung on the other hand still locking themselves off from my network. Home Assistant can't interact with it either.

[opal sparrow]

I don't think there's anything in thread 1.3 that really affects nanoleaf essentials devices.

but i don't know exactly what thread version they're using.

[plain kettle]

lemme have a look

[jolly fable]

My apologies if I went off-topic with the thread certification requirements on Bluetooth btw. I've just always been curious and couldn't find an answer if it was mandated or not. (Even if never used for anything by certain manufacturers)

[plain kettle]

could always ask in the fuchsia server, quite a few guys in there who are active in the thread group

[opal sparrow]

yeah, i don't think thread specifies any required method for provisioning thread credentials on a device, and as such doesn't mandate bluetooth or whatever. That's all up to the application protocol built on top of thread.

both homekit and matter require bluetooth for thread provisioning.

[jolly fable]

And matter is struggling at getting the ball rolling too

Guess homekit is what gets people prepared after all. Apple been very surprising in their home networks, I would've expected them to do what Amazon and Samsung sorta did

[green frost]

The 2.4GHz frequency allocation has a very wide bandwidth. There is a lot of room for channels of different sizes. Bluetooth, Wi-Fi, Zigbee operate in the 2.4GHz allocation but at different carrier frequencies.

[plain kettle]

Apple loves the consistancy and reliablity they had with homekit and thread

huh i dont think the thread version is sent in the ThreadNetworkDiagnostics cluster

[opal sparrow]

But yeah, an interesting thing about Zigbee is that (for most devices) they use in-band provisioning, where devices are discovered and set up though the zigbee protocol itself. Either by resetting a device to put it into discovery/pairing mode, or by using "touchlink" which requires devices to be in very close proximity.

[jolly fable]

Wait, we can check enddevices with it? Or are you checking the nanoleaf border routers

[plain kettle]

end devices

[opal sparrow]

nanoleaf border routers aren't matter devices (yet); ThreadNetworkDiagnostics is a Matter cluster.

[jolly fable]

Zigbee has a network addressable variant for smart meters right? 👀

Imagine it was paired with Bluetooth commissioning... And that matter could work over it

Just seems weird how some zigbee stuff was able to be converted to thread and work with matter but zigbee itself doesn't

[plain kettle]

depends on the SOC i guess, and also how much the vendor actually wanted to adopt the new tech

zigbee is much more mature at the end of the day

[opal sparrow]

whether it could be converted depends mostly on: does the device have enough flash to fit the (usually larger) matter firmware with a dual-partition setup? Does the device have enough ram to run the matter firmware, which often needs more ram? And also, is there a bluetooth radio available.

the bluetooth radio is usually available, so it's normally the first two things that prevent upgrades.

[jolly fable]

Woulda been nice to have zigbee devices but I only get matter supported devices in my home atm

Which limits me to Tuo matter-thread buttons, some lights from Wiz and Nanoleaf, Eve & Wiz plugs, and Eve radiator controller with beta firmware

[plain kettle]

how are you finding the tuo stuff?

[jolly fable]

I woulda thought Bluetooth was the big stopper

[plain kettle]

a ton of people are waiting weeeeeeks to receive products from tuo lmao

[opal sparrow]

Nope. flash and ram size are the main things. most zigbee capable socs can do bluetooth.

[jolly fable]

It's amazing, especially on home assistant

Automations let me switch between every light by pressing it 1, 2, or 3 times within a second
And then again to toggle them

[plain kettle]

huh right, ceo must of got some more people on board to the project

[jolly fable]

And it's the only matter over thread button I could find

Although Google home doesn't like buttons and doesn't know how to class it. Like I'm pretty sure I could even set it to washing machine... Which I didn't know was a category that could be selected for unknown devices

Still paired though, would love if nanoleaf made something like this

[plain kettle]

nanoleaf have the sense+ stuff coming out soon, but it seems to keep being delayed and delayed

[opal sparrow]

the thing is that these little SoCs with low power radios are actually made to be as general as possible so they can be sold in lots of different kinds of devices without having to make separate chips for each. It turns out that a lot of those little random bluetooth-only things that you see actually have radios capable of zigbee and maybe thread builtin :/

[jolly fable]

Wait, it's possible in theory for a Bluetooth device to be converted to thread & zigbee!?

I knew 802.14/15 or whatever the number was had some sort of over lap but that's quite a shocker

[opal sparrow]

(certainly not that many of them tho; bluetooth-only chips are pretty common)

[jolly fable]

Ohhh so only some of em that used very specific parts

[opal sparrow]

depends on the soc, and of course if the device doesn't have any way for you to flash firmware and the manufacturer doesn't care...

[jolly fable]

And I know I'm ignoring the ram and processing side

[opal sparrow]

i might have overstated that a bit, tbh

[jolly fable]

But if I can grab a Bluetooth radio device and flash firmware to make it thread/zigbee compatible... That's pretty big news

[plain kettle]

well, yes no maybe, depends on it

[jolly fable]

And again I'm ignoring the ram and processing power side

[opal sparrow]

you probably won't in general; requires they're using a modern soc that has a radio that supports both, and that you have a way to flash firmware to it.

[plain kettle]

you arnt gonna find some random bluetooth IOT device on aliexpress and flash a new firmware on it and its magically gonna work 😅

tho, there is a guide somwhere on some cheap stuff that can be reflashed somewhere

[jolly fable]

But how about sort-of work? 👀

[plain kettle]

[green frost]

That will depend on the radio being able to change the carrier frequency and bandwidth.

[opal sparrow]

in particular, i wouldn't be surprised if a lot of random bluetooth iot devices are using stuff like older model esp32s that don't have 802.15.4 radios.

[jolly fable]

I should look at how common that is in modern radios now

[plain kettle]

modern radios? pretty common, just the older/cheaper stuff that you might have an issue

[opal sparrow]

ble channels and 802.15.4 channels are the same carrier frequencies and channel widths, fwiw, that's why vendors making iot chips can have a single radio that does both.

[jolly fable]

Esp32-S3 usb dongle

Geek something is the brand, time for me to get to work cracks knuckles

[opal sparrow]

s3 does not have an 802.15.4 radio

[jolly fable]

Poop.

Wait so Bluetooth comes under that standard? Or just BLE

Cause I coulda sworn that was a separate 802 number

[opal sparrow]

esp32-c6 is wifi+802.15.4+bluetooth, esp32-h2 is 802.15.4+bluetooth only

bluetooth and bluetooth low energy are technically completely different protocols under the same brand name.

But you'll probably find that many devices support both, and they do use the same channels, in different ways.

[jolly fable]

NRF52840 is another one I had... And seemingly bricked trying to downgrade softdevice firmware

But that's already thread and zigbee

BT 5.2 last version to support AMP (Alternative MAC & PHY)

Ok now I'm definitely getting off topic again, sorry. Very bad adhd meds day for me 😅

I promise I'm not usually like this and I usually think in more sensical terms

But @plain kettle if you do find out what version of thread these radios use, id be really interested in knowing 👀

[plain kettle]

i mean, hard to tell. i dont think its actually sent in any of the clusters (if it was it would def be in ThreadNetworkDiagnostics)

you can look yourself in HA by going to the webgui they have in the add-on page

and just selecting a matter device

[opal sparrow]

I'd be surprised if the essentials devices implement anything other than thread 1.3, tbh

was probably included along with the matter 1.2 stack update

[plain kettle]

yeah, its been out for so long, and the last minor update to the spec was like late 2023?

[jolly fable]

My HA is really bugged atm but will try from the matter addon if its loaded

[plain kettle]

how is it bugged? 😅

[opal sparrow]

(in particular, matter requires the thread service registration protocol, which i believe was standardized in thread 1.3)

[jolly fable]

I may have broke the OS by adding usb storage, takes a day to load into emergency mode and barely loads anything but supervisor errors on the screen

But it works for the most part eventually

[plain kettle]

geez dude

[jolly fable]

And to top that off I thought switching to dev builds to install an update on top would fix it... I was wrong

[plain kettle]

love the casual 400G enum 😛

[jolly fable]

But I am confused again now, Nanoleaf devices have matter software on them?

The essentials?

[plain kettle]

yeah

the whole essentials lineup

[opal sparrow]

the (current) essentials devices have firmware which provides matter control api; older ones provided homekit instead. They additionally include a private nanoleaf api used by the nanoleaf app.

[jolly fable]

So it's not just the Hubs that get matter 1.3 updates. It's the devices aswell.

Which makes sense now that I say it out loud because they'd need to communicate in a different way given the (somewhat confusingly written) spec changes

[plain kettle]

yeah, but the spec is designed to be backward compatible/foward compatible

[jolly fable]

Which explains the Bluetooth to control them as a fallback

[plain kettle]

so you could have a 1.2 controller, and a 1.3 end device

[opal sparrow]

like, i think updating to matter 1.3 would have been basically no change on essentials devices; the basic thread stuff didn't change for end devices, and they were already using the service registration protocol since it was required by matter.

[jolly fable]

Yeah.... Hopefully 😅
Already seen people complaining about the missing parts and some parts having swapped identifiers etc

[plain kettle]

ah here you go!

[jolly fable]

But I refuse to 😛
Hence the weirdest controller setup up for my small home and even smaller room

[jolly fable]

Nanoleaf essentials? Oh right I forgot they have dev documentation and I was literally scrolling past the talks about it when opting into beta lol

[plain kettle]

no this is matter 1.3 spec (would be similar to 1.2)

[jolly fable]

Oh

[opal sparrow]

ah, in the network commissioning cluster.

[jolly fable]

So they reference thread 1.3? Or require it...

Atleast for new Matter-over-Thread updates and stuff

[opal sparrow]

In Matter 1.3 they provide a way for devices to say which thread version they implement.

[jolly fable]

Ohhh

[plain kettle]

yeah, seems like for matter 1.3, thread 1.3 is pretty much reccomended

[jolly fable]

Or even assumed

[opal sparrow]

thread 1.3 is mostly important for thread border routers, doesn't really matter for matter end devices.

(an interesting thing they've been working on is making "thread border router" be a matter device type, which is kinda interesting since it would potentially allow using the matter provisioning flow to connect a thread border router to your existing thread network)

[plain kettle]

they gotta come up with some way to sort out this everyone to themselves idea that each vendor has with their existing tbr's

tho, 1.3 introduced credential sharing, so its a ton easier to merge than it used to be. and its super easy when you set up your devices, as you can just import the credientals from the keychain/play services now

[jolly fable]

It's a shame about the minimised influence on commissioning for thread.

Like sure, people should be allowed to do whatever they want. And they can't exactly mandate matter compliance since that would destroy adoption.

But can pressure them to be compatible by saying they should enable a minimum Bluetooth versik as a fallback or even recommend specific radio/SoC's if their proprietary higher-level API/Protocols etc don't work. That way every device certified for Newer Thread+ versions would have the door wide open for Matter down the road as they add more supported device types... Assuming they didn't skimp out on the main parts like storage and ram. But Homekit already pressures them to do better on that front.
And If they refuse to do it? They can be stuck on their old Thread 1.0 cert but if they do it on future product certifications that they need to obtain, then they can advertise Thread+ or whatever they wanna call it ...even if they don't utilise the Bluetooth as their main connection for commissioning and opt for closed company protocols/higher level API's. It would be so much better for open-standards going forward if it was still there to connect to as a fallback or for third-party apps. Or updates/recovery.

Forgive me if i misuse terminology btw I tend to focus on different sides to these things and learn by being corrected on what I read 😅

[opal sparrow]

The thing is … a "Thread" device on its own is like saying a "WiFi" device.

there's no standard for how to provide wifi credentials to a wifi device either

[plain kettle]

You all have to agree on a set of rules to make a device work together, hence the thread group

[jolly fable]

Don't Google basically have it settled? And apple too pretty much.

Just Samsung (for now) and amazon

[plain kettle]

Ehhhhh, sorta?

It’s kinda complex and there is no simple answer

[opal sparrow]

The standards that define a type of devices which happen to use thread (possible as one of several) network connection types are responsible for defining how to provision thread devices, and there's no reason that they have to use Bluetooth for that.

[jolly fable]

Apple joins existing networks and Google lets other stuff join their networks and configure what device (Edit: Hub) used for credentials

It's weird how Google doesn't like to support every matter and/or thread device type

I woulda thought matter forced Hubs to recognise every new device. Hence how slow they're being with it.

[opal sparrow]

Thread has nothing to do with device types; thread is just a low level network protocol like ethernet or wifi. Anything higher level like a "device type" comes from a protocol running on top of thread.

[plain kettle]

Not really

A matter controller doesn’t have to support every cluster type

[jolly fable]

Isn't that weird?

[plain kettle]

There is a TON of clusters to be fair

[jolly fable]

Seems like they take ages to allow more device types in matter

[plain kettle]

I dunno, that’s just up to them I guess

[jolly fable]

I assumed it was so everyone has a simple way to work with it

With the exception of cameras, where everyone seems to argue on it

[plain kettle]

HA are pretty up to date with it all *using the example clusters and also diagnostic info if you get a device without the clusters added

[opal sparrow]

taking ages to add device types is just a side-effect of Matter's behind-closed-doors design-by-committee approach to writing the spec.

[plain kettle]

Yep

[jolly fable]

Wow, so not them just being careful and planning it all to work properly.

And even then, they can't even get everyone to support the devices in their Hub ecosystems. Like you'd assume connecting a lazy matter button would be a core/simple thing to support at the end of the day

Matter was not as well put together as I thought then 😅

Atleast we got Matter Casting over WiFi

[opal sparrow]

I mean, Google not supporting buttons is all on Google. They just have been really bad at supporting Google Home in general, really :/

I assume that all the people who worked at Google on getting matter into Google Home got promotions after the feature release and moved to different projects, so nobody was left to keep working on it. That seems to be how stuff at Google goes in general.

[plain kettle]

They have sacked like 18% of fuchsia staff, who knows how much of google’s home staff

[jolly fable]

I kinda wish they'd stuck to an android/Linux base

[plain kettle]

Most of googles nest devices are being pulled from shelves (nest mini 2nd gen)

[plain kettle]

Fuchsia is Linux

[jolly fable]

...I thought it used a different kernel

[opal sparrow]

no, Fuchsia is not linux, completely independent kernel and os

[jolly fable]

Little kernel/Zircon or whatever its called

[plain kettle]

[jolly fable]

Or was it called magenta... So many names

[plain kettle]

This is why I don’t tech talk at 2am 😔

[opal sparrow]

https://fuchsia.dev/fuchsia-src/get-started/sdk/learn/intro

[jolly fable]

Dahlia is Linux tho, which hurt me

[plain kettle]

It used to be Linux based that’s right

[opal sparrow]

google products that now run fuchsia may have previously been linux based

[jolly fable]

Yup like speakers

And nest hubs

And now they're Fuschia

[plain kettle]

Speakers don’t run fuchsia?

[jolly fable]

Cause... Reasons

[plain kettle]

I thought only the 3 nest displays ran it

[jolly fable]

They're still on CastOS?

[plain kettle]

Iirc they are

https://support.google.com/googlenest/answer/7365257?hl=en-AU#zippy=%2Ccurrent-preview-programme-firmware-version

[jolly fable]

Atleast there's that then

Wonder if any of them work as controllers/hubs

[plain kettle]

Not thread or matter

[jolly fable]

Oh... Back to sad then

[opal sparrow]

but yeah, i remember when google initially announced zircon, and everyone was wondering what they were doing writing an os kernel from scratch.

[jolly fable]

They got bored

[opal sparrow]

but it's almost certainly just "with android and chromeos, etc, we've gotten rid of all the gpl stuff except the kernel; now lets get the last gpl bit out too"

[jolly fable]

[jolly fable]

Doesn't that mean everything they built needs porting? Including community apps?

Not like they can copy their proprietary work over, right?

[opal sparrow]

i think their sdk provides a sufficiently posix-like interface for userspace apps built for linux to be ported to run on fuchsia/zircon without much difficulty. But it does seem like they've reimplemented quite a bit too.

[wild oracle]

indeed added in 1.3. although not overly useful (yet). all matter thread products require Thread 1.3. There have been other improvements since, not tied to a Thread version bump. For context, Thread version is already advertised internally over Thread. But if you care to know, this is helpful:
For example, Thread 1.3.0 would have ThreadVersion set to 4. You can just assume everything is "4" if thats helpful 😉

[plain kettle]

Haha thanks 🤣

[swift phoenix]

Will Group Scenes be coming to HA also? @wild oracle

[green frost]

Eh?

[wild oracle]

In the context of 10.8, group scenes is what we call a collection of preset states across multiple devices. So in large part, thats already possible in HA.

Are you asking about a convenience function to copy to HA?