Software Beta for Nanoleaf Essentials Matter

[brazen canyon]

Mine don't show an update most of the time even

[craggy plaza]

Some minutes ago I updated the last of my currently paired 11 bulbs to 3.5.134 and then saw the popup, that there is a new update. At the moment I update one bulb after the other.

How do you update your bulbs, one after the other or in parallel? If in parallel, how many devices can be updated in parallel?

@wild oracle Is there any recommendation?

[feral steeple]

It only lets you do 3 at a time max

[craggy plaza]

I already have 4 bulbs updated from 3.6.134 to 3.6.136…

[wild oracle]

for now, no, but its coming.

[craggy plaza]

And did this work for you in the past? I am afraid that this takes down the Thread mesh, when I update more than one bulb at once, because of re-meshing.

[wild oracle]

3.6-122 paths have been added. there should be a hotfix on android coming through play beta, but even with the issue, i think updates should be unlocked for Android users

[wild oracle]

generally speaking, removing a bulb from the mesh will cause brief instability, but it should recover pretty quickly in most cases. if you see triggers that lead to everything going unreachable (especially with a matter controller, DM me as there may be other issues we've been tracking.

[craggy plaza]

Ok, that was the case in the past, why I nowadays update one bulb after the other. But I am going to try this with last bulbs.

[brazen canyon]

No options to update 🥲

Maybe the app update will help

[midnight solstice]

Sticking with 3.6.134 for tonight; after going 3 rounds with Home Assistant post-patch issues, I have NL Matter bulbs active in HA for the first time in days. Only 6/7 at the moment, but I'm going to leave it be and hope it settles down overnight. Glad to see the updates are all converging in the right direction... 🙂

[feral steeple]

FYI Still cannot seem toupdate these ones showing as -122. and beta android app as well

[craggy plaza]

Ok, the first 6 bulbs were updated one after the other. Then I updated 3 GU10 in parallel and after that 2 A19 in parallel.

All bulbs are still available in Apple Home and Home Assistant. No remeshing, they were unavailable for some seconds to a minute and came back by themselves. I am unsure, if I ever had this awesome situation after updating all my currently paired bulbs. 😃

At the moment, it feels like you're on the right track. Let’s look how it feels tomorrow. 😉

[wild oracle]

try again. missed a character.

[midnight solstice]

Well that was short lived; my NL Matter devices in HA are slowly going back to unavailable again. Updated one to 3.6.136, and it stayed unavailable. The same devices paired in HomeKit and SmartThings all seem pretty stable.

[main matrix]

I've had 4 go unavailable in the last 15 minutes (3x A19s, 1x GU10, all on 3.6.134).

[alpine ore]

Hi there. To confirm, are those the only issues being actively worked on?

(Just trying to gauge how long it’ll be before this is addressed. #1184371187464290344 message)

[shell vigil]

Hey everyone, any feedback on the newest beta ? .136 ? My 134 is pretty stable and I am hesitating to update it to 136

[blazing meadow]

With the latest Android beta app I see the firmware version correctly and can access the advanced properties again.
As for .136, I still have a A19 that almost never connects to GHome but always does to SmartThings (it has roughly the same distance to both Nest and ST Station), but besides that it seems OK (too early to tell).
Another A19 (closer to the ST Station) connects to both border routers fine, so I wonder if some device placements are causing issues.

[brazen canyon]

That fixes it. Well kinda. Still really unreliable.

[feral steeple]

There was a matter server update to 5.1.1 20mins ago so I think they have found some issues in the HA update if you are on it. im just installing to test

[brazen canyon]

I had one bulb that was perpetually crashing on 3.6.134 that 136 fixed it seems

[feral steeple]

How do you tell if its crashing? Or is that it becoming unavailable?

[main matrix]

Looks like the struggle is real; not one of my lights will update to. 136 after an hour of trying..

[feral steeple]

After i got the new beta app on android, they are all updating for me

and can see device property pages again, even of the .134's

[main matrix]

Already on the beta to my knowledge? (10.4.0)

[feral steeple]

10.4.1 (385) is what mine shows

[main matrix]

Interesting..

[feral steeple]

I only updated it about 40mins ago when it showed in google play

[main matrix]

No updates were available in general, until I loaded the nanoleaf app specifically and there it was. Looks like you're spot on though as they are now updating.

Thanks for that

[midnight solstice]

So here is an interesting observation, I have one BR30 that has given me more trouble in HA than the others. When I ask HA to ping it, it comes back with a green check, comm is good. However, HA reports the firmware as 3.5.41, while NL app reports 3.6.134. I trust what the NL app says, but is this a clue about what is going wrong in HA? The device can be reached, but maybe there is a device interrogation that throws an exception, so HA just throws up its hands and marks it unavailable?

[feral steeple]

ignore that completely. I just reported it to HA.

The IP addresses dont show up, and I tested it with one that is off at the power point and HA still said ping complete with a tick

[midnight solstice]

My other bulbs report the correct firmware version, that's the point of my observation. At some point HA was able to complete device interrogation on .134

[feral steeple]

Did you update to matter server 5.1.1 which came out like an hour or so ago? That seems to have stabilised most of my network now, along with .136

[midnight solstice]

yes, it was out last night actually

[brazen canyon]

You can see in the server logs that the mDNS entry for the node is vanishing

[feral steeple]

I updated to 5.1.0 which was out last night, and this patch for it only showed up 40mins ago for me to 5.1.1, guess I missed it being patched last night

[midnight solstice]

hmm let me double check, maybe I'm misremembering

[feral steeple]

It didnt show up for me till i went to system and checked for updates

[midnight solstice]

Ha, I just did a test too... cut power on one of the lights, and the ping still shows the green check. :/

[brazen canyon]

Check the logs

[midnight solstice]

so I guess ping is useless

[plain kettle]

It’s not the best indicator

It’s something, but it can be a bit hit and miss sometimes

[feral steeple]

I dont know if the ping issue is because they are not showing any IP's to begin with, and they didnt put in something to say if an ip doesnt exist, it means the ping has failed

[plain kettle]

do you not get a list of ip's?

[feral steeple]

Nope.

[plain kettle]

hold up, HA doesnt report any IP's for you, are you on the latest version of the matter server @midnight solstice ?

oh wait nevermind

yeah that explains it

[brazen canyon]

It's a NL issue, my other matter devices report IP but not bulbs

[feral steeple]

@wild oracle , can you make sure reporting the IP addresses gets fixed up in the next firmware please 🙂

[midnight solstice]

so is that part of the issue? HA is expecting the device to report that and its not?

[brazen canyon]

Not necessarily, it's likely just not in the report schema

Doesn't mean you can't control the device

[midnight solstice]

I'm bumping all my bulbs to .136 now, and yes it seems there was a second Matter Server update that I didn't spot, thanks for that callout @feral steeple

at some point I have to quit fiddling with lightbulbs and go work... 🙂

[main matrix]

fiddling > work

[feral steeple]

I hear that! Hopefully we are on a relatively stable mix of things with the new matter server and 136. So far its the best my environment has looked in a long time.

[midnight solstice]

anybody else have a spouse that thinks you are crazy and likes to ponder what is wrong with a light switch?

[feral steeple]

Not quite cause mine values being able to do colour etc, but the comment has more been, "Should have just gone with Hue"

[main matrix]

https://tenor.com/view/hue-huehue-huehuehue-duck-laugh-gif-4916860

[feral steeple]

Wow, doing the connect from the nanoleaf app to HA to add the bulb is finished in like 15seconds now

[main matrix]

yeah I've noticed that too. it's pretty great.

one thing I have just noticed that I don't like so much is my 4x GU10s appear to be dead :\

no power, no light emitting from the bulbs, and they all appear to have failed within a few seconds of each other (based on HA logs from when they were last reachable). Changing downlight outlets doesn't change the outcome either.

[midnight solstice]

Oh, new module says Python Matter Server bumped to 5.5.2; those release notes usually say nothing... but there are a couple of interesting entries
#540 - Use previous available state (@marcelveldt)
#541 - Ignore MDNS removal messages (@marcelveldt)

that sounds really promising

[stable drift]

Latest update for bulbs seems a lot more stable!

[feral steeple]

45mins with none of the dropping off, definitely promising

[dull dagger]

Good news! All my lights are still connected overnight on 136.

They still disconnect and connect several times an hour (in HA) but they come back.

Also, no random on overnight either. On the previous beta, an A19 turned on twice overnight.

[midnight solstice]

In my case I have 0/7 showing in HA; hopeful that it will sort itself out in the coming hours but at this point it seems like a coin flip.

[main matrix]

Welp, in my case the update to .136 was definitely not smooth sailing. Thread network crashed several times (half expected I guess), all my GU10s are no longer responding to power/inputs (not sure if related to .134 as that was last FW to successfully install on them) and 3x A19s out of 24 are refusing to communicate with GH or HA after the .136 update. 😐

Will give it overnight and see if it automagically fixes itself.

[feral steeple]

are you on the latest HA update? the matter server 5.1.1 (which i had to do a check updates to see a couple hours ago) made a massive difference

[main matrix]

yeah, everything is up to date for HA and the Nanoleaf app

[feral steeple]

kk. Cause the 5.1.0 that was out last night, was just a nightmare for me haha

[main matrix]

and in a cruel twist of irony, 5.1.0 was more stable for me 🙃

[feral steeple]

go figure!

[main matrix]

who needs consistency anyway..

[feral steeple]

I think you just jinxed me! 😛

[stark crystal]

Try rebooting Home Assistant.

[main matrix]

Already have

when an addon/integration goes through an update, I reboot as a precaution

[wild oracle]

Hows everyones overnight experience with 136? Any devices turning on unexpectedly? My setup has stayed off so far

[main matrix]

I initially misinterpreted those as chess pieces (until I looked closer) 🤣 nice light farm!

experience has been hit and miss for me, but others seem to have had better experience. my GU10s are kaput and 3 A19s are not responding to the Nanoleaf app, Google Home or Home assistant.

[plain kettle]

Wow, I’m really not sure what I expected a light farm to look like, but that is certainly impressive

[dull dagger]

Here's my overnight prognosis...looking good.

#1184371187464290344 message

[swift phoenix]

If things are stable the next thing I would like to see is to fix the popcorn affect with lights turning on. Seems a bit less snappy in this beta but more stable

[brazen canyon]

Wasn't able to update until today so don't know

[brazen canyon]

Pretty sure that's an admin thing

I'm not sure maybe NL has something set on the HW side

All I know is transitions on the matter end suck

[wild oracle]

to clarify, with 136, the issue we're most concerned with seeing (an absence of) is the random turn ons. we've made over reaching changes to eliminate the last thing we can think of that might cause it, so if we're wrong, we still need to hunt (we consider turning lights on unexpectedly a "cardinal sin"). unfortunately, I can't say that 136 will bring any significant enhancements to overall reliability yet (compared to most previous 3.6 builds)

[wild oracle]

not familiar with this one. can you direct me to anything more comprehensive (whether link or DM)

[dull dagger]

Thanks very much. So far 14 hours into 136 and I haven't had a random on which is an improvement already. Of course time will tell over the next couple of days

Can I ask a side question is there any plans for making the 4D a thread border router? Or does it simply not have the hardware to do so?

[shell vigil]

I had 134 and nothing turned on at night

Updating now to 136 as I heard some good feedback around it

Hopefully as well will help keeping the thread network connected if multiple bulbs are activated on the same time

[boreal surge]

@spice harness @wild oracle ref: CHIP-1295.

[plain kettle]

on HA's end it is just eaiser to line up nodes w/ devices if the IP is known

also, hard to tell if any other vendors use that information or not, or just rely on the routing table

[feral steeple]

Is what Paul sent an answer to this? If not, ill check with the HA guys for some direction.

It seems other matter devices are showing their ip's in HA from their screenshots

[craggy plaza]

Hi, after the update of my 11 bulbs tonight, I switched off some bulbs before going to bed. But one bulb dimmed to round about 20% and stayed there. At this time it got unavailable to Home Assistant and Apple Home. I left it in that state and went to bed. It came back to Apple Home after some minutes, but not to Home Assistant, when I woke up in the morning. I removed the bulb from current and it came back to Apple Home and Home Assistant. Since that point all my Thread devices are working absolutely reliable:

Matter over Thread (paired to Apple Home and Home Assistant):

• 24 EVE devices (13 FTDs, 11 MTDs)
• 11 Nanoleaf bulbs (6 A19-E27, 5 GU10)

HomeKit over Thread (paired to Apple Home only):

• 13 EVE devices (1 FTDs, 12 MTDs)

I use the following Apple Home Hubs / Thread Border Routers:

• 2 AppleTV 4K 3rd Gen
• 4 HomePod Mini
• 1 HomePod v2

I will try to pair more bulbs tonight. Everything feels snappy and reliable at the moment. I didn’t have bulbs switching on by themselves since the latest beta update.

[brazen canyon]

@wild oracle for some added context to some of these reports, HA added some diagnostic tools (like directly pinging devices) and mDNS discovery for resubscription yesterday. So you might see different issues reported as a result.

[boreal surge]

No, that's an internal tracking code for a Jira issue which I opened for this. By all means, please do send over any materials you might have on it 🙂 (which I'll add to our internal issue)

[brazen canyon]

Okay so I think to follow up on what @swift phoenix said, and I know this is a lower priority issue.

But if lights haven't been turned on in a while they kinda "pop" on. If they have been turned on recently, they'll ramp up smoothly over about 0.5s (here by turn on I mean using a matter controller to turn on, not a physical switch)

[craggy plaza]

Yes, I also recognized that issue in the past, now where you describe it… But I can’t say, if this is still there with the latest 3.6.136.

[brazen canyon]

I just tested it about 5 min ago, still exists

[dull dagger]

When you say pop on do you mean like you want to turn it on at say 50% brightness but it briefly turns on at 100% And then drops to 50% is that what you're saying?

[plain kettle]

I found the case that it just immediately lights up to 100%, rather than a gradual ramp up

[brazen canyon]

No what @plain kettle mentioned sums it up

It's very strange. I've got hallway lights that always pop and others do it sometimes but not always

[craggy plaza]

I also recognized that. It was never a priority thing for me. As long as the bulbs are available and switch on and off, I was happy in the past. But the better the firmware gets, the higher the requirements become. 😃

[swift phoenix]

I have noticed the same behavior on my end.

If you haven’t used in a while sometimes they just bounce to 100% like the HomeKit versions used to do. But if you test again after that they do the fade off and on affect

Not sure what it might be

[main matrix]

Just did some testing with my thought-to-be dead A19s, and it seems the beta update to 3.6.134 somehow broke the lights ability to turn on (even from the Nanoleaf app as it wasn't even showing a BLE connection). No amount of removing current from the light and leaving it off for x amount of time would make the light respond. When current was applied, the light flickered for half a second then remained "unpowered". It wasn't until I reset the light at the switch did it respond and emit 100% brightness. After re-pairing it to the Nanoleaf app, it then identified as 3.6.134, and prompted an update to 3.6.136.

Hoping the GU10s met the same fate, but won't be able to test for a while.

[dull dagger]

more good news....lights are still connected and available. Since Matter update in HA to 5.1.1 (4hrs ago)...no hourly disconnects/reconnects, either.

[wind finch]

It should ping the IP addresses listed. Since none are listed, I don’t think it did anything.
Sorry if other people have already mentioned this, I’m working my way down the messages 😄

[plain kettle]

spot on

[wild oracle]

thanks - its unclear if this is our issue (without IP addresses, matter never works). so seems like HA bug, feel free to DM if you think there's something we're missing.

[plain kettle]

its an issue on your end by the looks of it, ill try and find some documention somewhere regarding it

[brazen canyon]

Likely on your end, other vendors I have (tplink, aqara, yale) all report it

[feral steeple]

I have just asked HA if they can point to any doco,

[wild oracle]

lmk if you have any open issues or questions - we have contacts with HA and can chat directly

(urls i mean, just for quick context)

[plain kettle]

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

(It’s the home assistant discord)

[feral steeple]

marcelveldt said that if a device is nto reporting its IP, its a device bug. Devices are required to report their IP's

[plain kettle]

The main 2 people are @pulsar rock and @neon rain

Or I can pass along on their emails if ya want?

[wild oracle]

i know marcel

[plain kettle]

Ah dope, yeah he is the main guy running the matter server/deployment in HA so any specific questions are prolly better off going direct to him

[eternal hill]

Aren’t all bulbs able to directly connect to the BR like this and are therefore not routing traffic for other bulbs?

[plain kettle]

Ehhhh, possibly? But the same sentiment about devices randomly turning on and off is shared by everyone

[brazen canyon]

To be more specific:

Since all these bulbs are in a close array, it's likely they are directly connecting to a BR and are not going to show instability from routing traffic, which many have reported

[plain kettle]

I certainly would not run that long term for pre-release testing, rather spread them around the place if possible (like all around the work office)

by the looks of it, appears to be the NetworkInterface struct of the General Diagnostics Cluster.

https://csa-iot.org/wp-content/uploads/2022/11/22-27349-001_Matter-1.0-Core-Specification.pdf

see 11.11.6.5

could be wrong, but this seems the most likley

(dont have access to the 1.2 core spec atm)

IPv6Addresses field

The IPv6Addresses field SHALL provide a list of the unicast IPv6 addresses that are currently
assigned to the network interface. This list SHALL include the Node’s link-local address and
SHOULD include any assigned GUA and ULA addresses. This list SHALL NOT include any multicast
group addresses to which the Node is subscribed.

[feral steeple]

If it helps or means anything, this is what my topology shows.

23 gu10's connected

[plain kettle]

yeah, thats so wrong. the gui isnt the best to tell in terms of if a device is connected

[feral steeple]

Seems about right, Marcel also just said - Matter core specification. A device must report its IP addresses in the diagnostics cluster.

[feral steeple]

Each time i have looked at thread topology it just looks useless vs what zigbee looks like haha.

[plain kettle]

google and co are apparently working on it, but it isnt really meant to be used by the end user at all

[eternal hill]

There is a limit to how many other routers a router can be connected to directly

[feral steeple]

And does the nanoleaf FW determine what it should be doing there?

[plain kettle]

no

it just follows the thread spec

its either an end device or router

[midnight solstice]

Which tool generates that topology map?

[plain kettle]

uhhhh its the offical OTBR software that runs on all border routers, at the moment its only exposed if you run it locally, or use the OTBR software in home assistant

https://openthread.io/guides/border-router/web-gui

no vendor currently exposes to the end user (for good reason as it can be more harm than good if you dont know what your doing)

[midnight solstice]

Ok, I picked up a SkyConnect and played with it, but disabled it all when it made things worse. Haven’t revisited it yet.

Time consuming hobby, home automation is

[plain kettle]

oh right yeah, so when you run the OTBR add-on, the gui is exposed on port 8080, and the API on port 8081 (by default)

[plain kettle]

@wild oracle root of the issue with the no ip address in HA is this:

11.11.6.5 of the 1.0 spec is the NetworkInterface struct, which HA uses to display diagnostic info. ID 6 of that being the IPv6Addresses field which i think you guys have as empty and/or are pointing it to a wrong network interface? but regardless thats why

maybe have a look on your end, and report it upstream if not?

[shell vigil]

Guys who has flickering bulbs and using Apple home ?

I tried one thing in Apple home and I don’t have this flickering anymore

[feral steeple]

Especially when you decide to go for the new matter tech and then also get the nanoleafs not knowing there was issues as you get more on the network haha. But at least its forced me to learn a whole lot about HA/zigbee/thread since I bought this stuff at the start of Jan

[shell vigil]

I went inside Apple home and chose the bulb which is flickering , I chose temperature mode and slided the color from warm to cold and cold to warm left right right left. Then I have turned off the bulb and back on did the same thing with moving it from left to right and right to left and suddenly turned off and on and the flickering stopped. When selecting scenes now afterward the transition of the lights is normal and no flickering is happening, additionally the colors are accurate @spice harness @wild oracle fyi

[spice harness]

How long has it been since you tried this and it fixed things? I'm curious if those devices will spontaneously re-enter the flickering state or if you've somehow resolved them permanently with this trick. This seems to imply a possibly invalid state with one of the colour control parameters that the light had previously been stuck in... very strange.

And apologies if you already told us this, but did the flickering only occur when controlling via Apple Home or via the Nanoleaf app as well?

[shell vigil]

Just now, I was talking to Nathan as I noticed the flickering is with the white led not the rgb one. And wanted to look from which white color warmth they start flickering (the dot in the picture moving right they start flickering) I made this move left and right and turned off and it stopped flickering

Turning on and off from the app is barely working and it’s crashing the app

Ok I tried the bulb now

When changin the white hue it flickers at some point form the Nanoleaf app

But not from Apple home

@spice harness dm

[plain kettle]

Poor Ben

😔✊

[alpine ore]

Ugh, went from all my lights working via Siri yesterday to now only 1 of them working. I don’t understand this instability fr

Doesn’t work via Nanoleaf either

[shell vigil]

How ?

I have updated and I have 35 bulbas

I have been selecting scenes for@the past 4 hours to try to break the thread and it’s not breaking

How many bulbs you’re controlling on the same time ?

[plain kettle]

Uhh that’s a bit unnecessary, but each to their own ig

[shell vigil]

I think it’s the most stable firmewear for me

[plain kettle]

Siri? So Apple HomeKit?

[shell vigil]

What is IG

[plain kettle]

I guess

[shell vigil]

No I meant I was trying to break the thread network I have myself and it didn’t

[shell vigil]

Yes Siri is Apple home

I have HomeKit (Apple home ) myself that’s why I asked how many bulbs , I did some tricks that might help

[craggy plaza]

Great information. Scenes with 35 bulbs without breakibg the Thread network is a big step forward!!! You are on a good way to get it sorted. Well done Nanoleaf! 😃👍

[shell vigil]

Yes but the scenes are not working 😂

I have to click 2-3 times to make it work

But the thread is not breaking at least

[craggy plaza]

😂 Ok, but that’s another issue. First step is to get stability.

[shell vigil]

I have scenes with 7-8 bulbs each

I was pressing these small scenes very many times

And each time it’s working perfectly

Found a way to fix the flickering as well

I am never moving away from this firmwear

[feral steeple]

something seems to happen almost every 2 hours and most of the bulbs drop off and slowly reconnect

[iron trench]

After resetting and setting up bulbs again in Nanoleaf app, then Connecting to Matter for HomeKit, the bulbs say to “set up” again about 15mins later. They show they are connected with Thread, but when I go to Thread Network, it only shows my Border Routers. When trying to “setup” again, Nanoleaf never finds the bulbs after scanning QR code. Anyone else have this issue?

[wind finch]

How did you get the Google and Apple on the same network?

[plain kettle]

@iron trench might know an easier way than this, but do you have a skyconnect with home assistant @wind finch ?

[wind finch]

Yes, and I can move it between networks

I have the credentials for both Apple and Google, but it doesn’t let me move the Google around

[plain kettle]

you got an android?

or only ios?

[worthy grove]

Nest Hubs will join an existing thread network automatically at setup. This only works since Google also supports Thread 1.3. I had to re-setup mine because it formed its own thread network before 1.3

[plain kettle]

really? they do that now? do you have to re-input credentals at all anywhere?

did you just factory reset them or what?

[worthy grove]

I‘ve setup my hubs through the Google Home App on iOS and then it joined my existing Apple Thread network.

[wind finch]

Both, and imported the credentials for both

[worthy grove]

Before that I had to reset them to factory defaults.

[plain kettle]

ah right, intresting!

[wind finch]

Ugh… factory reset

Suppose I need to do all of them at the same time, otherwise the Google network will still exist

[worthy grove]

Think so

[plain kettle]

could just unplug them all, and work on bringing them up one at a time

[iron trench]

I don’t. Only have Apple Home and Google Home :/

[plain kettle]

how did you do it then? or did it just join automatically?

[alpine ore]

21 overall but 7 are usually off, 9 + 4 + 4 grouping

Plus lines and canvas

[alpine ore]

Matter via Apple HomePod mini yea

[iron trench]

I factory rest the bulbs. Setup up in NL app. Then Connect them to Apple Home from NL app where it says connect to Matter. They all paired to Apple Home fine and NL app showed Thread network with all the bulbs and everything. Then after about 15 mins the NL app says to setup bulbs again and the Thread Network only shows the Border Routers, no bulbs. When I click to setup bulb again, I scan the QR code and it says it can’t find bulbs to setup and try again.

[dull dagger]

my lights have not disconnected for 8 hrs now.

[wind finch]

Where does the Google Nest fit into this story?

[wild oracle]

thanks for the detail. we've logged. quite likely it may already be solved in the 1.2 code we're trying to roll up to. we'll double check

note that if its blocking features you want to use in HA, i told them they should add the IP they are using to communicate (implicit knowledge).

the matter diagnostic field won't give a user any more usable info i dont think

[plain kettle]

its more for the admin/controller, and who knows when apple, smarthings, google or amazon will implement debugging mechanisms based on diagnostics cluster.

[iron trench]

Nest Hub Max I have. It’s on the same WiFi so automatically shows up as thread border router.

[plain kettle]

we both more or less meant in the same thread network, but appears that you just set the nest hub up after your apple device

[iron trench]

Yeah, I haven’t added any NL products to Google Home after doing the beta. Trying to keep everything to just NL and Apple Home until later on. Would the Nest Hub have anything to do with the bulb issues I’m having not showing up in Thread network and still saying “setup” in NL app?

[wind finch]

My Google’s are on a separate network to my Apple devices, so my NL’s don’t interact with them at all.

In general, I’d say that having them in the same network should be better.

But I know that Apple uses TREL and Google does not yet… so I’m not sure if that affects the way things work (I wouldn’t think so anyway, but I don’t know for sure).
In my head I see this as Apple being a traffic cop 👮‍♂️ , directing all the cars, and Google is just some clown 🤡 in the intersection 😬

[plain kettle]

google does and did, but unfortuantly its only enabled by cil or a feature flag

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

Updated TREL to be disabled unless enabled by feature flags or CLI.

[wind finch]

Why did they disable it though…

[iron trench]

If I factory reset my bulbs again, what do y’all think should I do differently with NL/HomeKit setting up the bulbs so they don’t keep saying “Setup” and actually stay in my Thread Network list?

[plain kettle]

i dunno, ask the Fuchsia devs

its manditory in thread 1.3.0, so it will eventually return

there hasnt been a nest firmware release since the start of december, so they are for sure cooking something

[eternal hill]

I don’t think that they activated it/deactivated it it on purpose

[eternal hill]

It’s not

[plain kettle]

oh wait duh

[feral steeple]

I seem to have a few bulbs still causing issues, What is useful to provide to you? A few of mine have gone unavailable and just staying that way. Also do not come connected on the nanoleaf app. Without turning power off and on. Im guessing its the bulb crashing and not recovering? 5 out of 23 that just dropped and have not come back online

[boreal surge]

Hey folks, we've got a barebones bug reporter and list of known issues reported through this channel up and running. Reporting bugs / issues through the bug reporter will help increase our throughput for resolution. Any feedback you have on the reporting tool itself is also most welcome, feel free to DM me (it's an mvp for sure). Password for the page below is CHIP0001

https://research.nanoleaf.me/upcoming-quests/chip0001-3-xx-thread-beta-software/

[steel hemlock]

Good morning Paul. I am not quite sure if it is still an issue (done the update to the latest beta this night, so I will monitor it). But is the "color changing issue" still existent and/or tracked?

[verbal drift]

upgraded to .136 - had to power off devices for 5 sec or more, then I am seeing the GU10's doing the cycle from offline, BT, Thread this happened on .126 then after a few hours they settled down. After upgrading my other A19 matter lamps they also needed a powercycle.

It is only the GU10's that are cycling through the off, bt, thread.

100% Apple Eco system

[eternal hill]

for me the reachability got way better in the latest two betas

I have bulbs in a lamp where i even had problems with ikea zigbee bulbs, that finally started working well now.

[eternal hill]

Right now i have problems with bulbs that i remove from apple home. It does not seem like their fabric gets deleted. Neither when i remove them through apple home or the nanoleaf app.

So i have to factory reset them to add them to Apple Home again.

Idk if it always has been there, but i dont think so.

[verbal drift]

https://tenor.com/view/facepalm-really-stressed-mad-angry-gif-16109475

Random GU10 light turned off

[plain kettle]

F

[worthy grove]

Short feedback from me for the .136 firmware: None of my 9 GU10’s turned on itself in the last 24h. All bulbs are available in Apple Home and HA and react instantly. No reporting of unavailable bulbs in HA over the last hours. I still had seen flickering with one bulb. It occurred after playing with the colors and went away itself. Power loss recovery is untested and switched off at the moment. Overall the last two firmware versions are a step in the right direction for me. I‘ll add more bulb back to the network today.

[steel hemlock]

I totally agree.
The only thing, that I can still monitor, is the flickering and sometimes the change to a wrong color when the GU10s are turned on by automation.

[brazen canyon]

So here's my thoughts about .136

I think this is likely the most stable firmware I've seen in months. I had 0 issues with lights being unreachable. In fact, I deployed all the bulbs I had in the house, including ones in boxes (about 22). After some remeshing I didn't have any issues with lights being unreachable.

I have a mixed setup with Google, nanoleaf, skyconnect (OTBR) and espressif (OTBR) BRs.

Ive not seen the spontaneous light turn on this firmware yet

[bitter compass]

Does anyone here have a Essentials Light Strip AND any matter diagnostics in Home Assistant for it? I have the matter diagnostics for my A19 bulbs, but the matter diagnostics section doesn't even show up for the light strip

[plain kettle]

Wait for the 2024.2.1 update to go live in a bit then try, if not report it to the HA devs

[brazen canyon]

Mine shows up minus the IP

[wind finch]

FYI, I tried this. My NExt Hub cabe back, and just made a new Google Thread Network. When I turned the others back on, it then moved back into the old network. Sort version, factory reset is not the solution.

[plain kettle]

Huh right

[wind finch]

I don't have the diagnostics sections for any of my NL devices (Lightstrips / E27 / GU10), only for Eve

[bitter compass]

I've updated to the latest HAOS - and the full restart of the entire system has made it show up, so it's probably just that the matter server AND Home Assistant needed a restart

[wind finch]

Which specifically do you mean, this diagnostics?

Or soemthing else?

[plain kettle]

No.

Not that one

That’s only for eve

[wind finch]

You mean the Device info then?

[craggy plaza]

This is meant: https://www.home-assistant.io/blog/2024/02/07/release-20242/#matter-diagnostics-and-actions

[bitter compass]

Now the only thing to address (not here) - is this......

[craggy plaza]

@wind finch Look at the 3 dot menu. 😉

[plain kettle]

This is known about

We believe it’s an upstream issues with sillabs

[bitter compass]

Oh good, because the Onvis socket does not have an app, and thus there is no way to update it to a newer firmware unless they have implemented the OTA over matter feature.....

[plain kettle]

Yeah right

Wait you are getting an ip address

Eh, it’s an issue on onvis’s end,

It’s not going to effect anything

[bitter compass]

yeah I am getting IP addresses but the primary one - is not valid, and it has no mac address

[plain kettle]

That doesn’t really matter, they just must not supply it to the diagnostics cluster

[brazen canyon]

I took a quick look and it looks like the submission form is pretty detailed which should help more than our casual convos on discord

Also existing issue tracker is nice

[eternal hill]

For a matter device to be certified you need some kind of update mechanism

[plain kettle]

Onvis Home app?

[bitter compass]

looks like they don't have an Android one. Before the S4UK Matter socket - it looks like they were Apple Home Kit only.

[bitter compass]

Yeah. Just noticed that I can't find them on the CSA certified products site....

[plain kettle]

That’s bad

[bitter compass]

On the plus side. They are rock stable. All they have to do is turn on and off. And They only started becoming unstable when Nanoleaf stuff started becoming unstable (I suspect the issue is Home Assistant constantly trying to reach bulbs that had fallen offline - was causing a lot of Thread traffic).

[plain kettle]

Yeah honestly I would never buy something that isn’t CSA certified, but that’s just me

The unreliability of any long term support is wack

[eternal hill]

If they ship with matter on the box they are certified

They might be white label products though

Or it’s just the chip that is certified(I’m not sure how that works though)

[steel hemlock]

I am not able to update one GU10 from 3.5.41 to 3.6.136. It is always failing at some point during the process.
Does anyone have an idea?

[eternal hill]

How close are you standing to the bulb?

[steel hemlock]

Almost next to it.

[eternal hill]

For me it usually works without any problems on IOS by standing next to it and making sure the screen stays on and I stay in the app the whole time.

[steel hemlock]

Will give it a try again.

[craggy plaza]

That’s my procedure, too.

[craggy plaza]

Maybe you want to try it with another iPhone/iPad just for testing purposes.

[steel hemlock]

Avoiding the screen lock did the trick.

[eternal hill]

I hope they add ota over matter soon.

Would be so much better when it works

Especially for many devices

[boreal surge]

Good afternoon! For colour-changing, does this sound like what you're seeing ?

"On off requests do not make the light turn on/off until a color change request was sent"

[shell vigil]

Yes but there is more to it

More like :
1- turn on and off and changing to color or white make the bulbs flicker
2- on off request with a specific scene in some bulbs (mostly the flickering ones) do not stabalize on the correct color chosen

3- white hue changing make the bulb flicker and have wierd colors specially when cool white switches on

As a summary, there is something very common with the white led when it’s triggered for brightness or change it does make things flicker or have a wrong color

[boreal surge]

Great, thanks for the feedback. I recognize it would get tedious to fill in multiple bug reports with this tool over time, I'll be looking at methods to prefill / use conditional logic in the future to streamline the process.

[steel hemlock]

It is more like: "Automation is triggered. 3 bulbs (e.g. the light has 3 bulbs) are turned on. 1 of 3 bulb is turned on in the wrong color. Every x seconds after that the same bulb is set to a different color, never to the one that is configured in the automation".

[boreal surge]

@shell vigil @steel hemlock hmm. That looks related to a couple of things we've logged in Jira, but not quite a clean match. Could I trouble you both to fill out a bug report with your respective experiences, and I'll add to the issue tracker on the beta page?

[steel hemlock]

For sure!

[steel hemlock]

Bug report done! 🙂

[frozen crystal]

I echo those comments about the white hue issues, particularly from automatons, and flickering.

[bitter compass]

HA users, 2024.2.1 wants you to update to Matter Server 5.5.1 (quite a jump from 5.1.1). All running happy here.

[dull dagger]

only 1 of my lights has disconnected and remains disconnected (in HA), an LED strip. The rest are doing well, no random on or disconnects. For the one that is disconnected, it is furthest from another device/TBR. I still don't have a clear idea about what is considered too far for it to be an issue.

overall, this FW release has been the best so far for my system

[dull dagger]

this is great BUT I wanted to mention, do you have also a setup where lights are scattered over distances (i.e. like in real-home setup)? I would image this would have excellent meshing due do the short distances between the bulbs.

[peak mesa]

my nanoleaf downlights (v 3.6.79) just wont update to .136, i click update but it fails. Already restarted all borders and the bulbs. What can i do?

[boreal surge]

Would you mind following the diagnostic steps in this article, and sending me the results in DM? I'll add that to the ticket you opened (thank you).

https://research.nanoleaf.me/2024/02/verifying-unreachability-issues/

[verbal drift]

Of course I will! However it’s all stabilised. Will try to replicate

[boreal surge]

Hey, if it's stabilized we'll take it 🙂 if the issue you faced repeats, just DM me with the outcome of those diagnostic steps. That would be very helpful, thanks.

[verbal drift]

Yeah no problem, it was only after the update to .136 not sure if it’s related

[wind finch]

Stand next to the lights and update

[boreal surge]

Hi MarVin! A few things to confirm/eliminate :

1. Is your mobile device in close proximity to the downlights? (5m / 10ft max with no obstructions like walls in the middle, but the closer the better)
2. You've power cycled the downlights / tried again? (leave them off at the switch for ~10s, then wait for them to be reachable in app before trying to update again)

If the above don't get it through, guidance from our team is to reset the downlights, re-pair them, and initiate update again. To reset : https://helpdesk.nanoleaf.me/en-US/how-to-factory-reset-your-nanoleaf-essentials-15597 (same steps as the A19).

If still a failure, could we trouble you to submit a bug report? https://research.nanoleaf.me/upcoming-quests/chip0001-3-xx-thread-beta-software/ with page pw CHIP0001

[peak mesa]

does not help, and its really aniong to reset an repair them because tahts also fails many times...

[shell vigil]

Hey @boreal surge @spice harness

All my bulbs are requiring now to be setup again

They are working well though

[scenic grove]

Mine are also asking for setup today

[rare aspen]

Same here. The bulbs were setup and paired in Apple home.

[alpine ore]

Same here

[frozen crystal]

I had that setup thing the other day. It wasted a load of my time one evening to type in all of the pairing codes… no other harm done

[wind finch]

I had that for 1 bulb, but it disappeared after a few seconds

[frozen crystal]

It still does it for a few seconds whenever the app loads

[rare aspen]

as an information, even on .136, if I pair the bulb on Apple Home, then NL app ask for this "setup". If I perform the setup on NL app, eventually the bulb becomes unreachable, for whatever unknown issue.

[shell vigil]

Thanks for that, so do you recommend not to click on setup and set it up again ? It’s working in Apple home@perfectly

[frozen crystal]

The “Setup” is to configure to bulb within the Nanoleaf app, so I believe that what you describe is to be expected. I set up all of my bulbs in NL first then added them to Apple Home and almost all of mine are currently available.

[brazen canyon]

So it seems I'm still having issues with bulbs dying and not coming back without a power cycle

[alpine ore]

So would you recommend setting up via Matter first then connecting to the NL app afterwards? Or does the NL app just break it regardless once introduced into the equation?

[brazen canyon]

136 is still more stable than previous but devices still dying

[scenic grove]

I put in a bug for the reasking for “setup” on their new bug form.

[worthy grove]

I‘ve setup all of my bulbs in the NL app and connected them from the app to Apple Home. For some bulbs I updated them first in the app before connecting them to Apple Home, some after. I shared them after all from Apple Home to HA. Alle bulbs stay connected for the moment.

[rare aspen]

Every time i have done the setup in NL app, it broke the bulb’s connectivity, even making bulbs unavailable in NL app.

[rare aspen]

I wouldn’t recommend since i experienced this issue

[midnight solstice]

Since I’ve installed .136, I have 5/7 of my bulbs working perfectly across NL, HomeKit, SmartThings, and Home Assistant. The last 2 are (1 BR30 and 1 A19) working everywhere except Home Assistant. No idea what is different about them right now, especially since they have worked in the past. This last issue feels like some strangeness with mDNS, though I have restarted my BR’s and even my network gear to flush any cached entries.

The Matter Server log in HA is the same as we talked about previously

ERROR Failed to establish CASE for re-subscription with error 'src/lib/address_resolve/AddressResolve_DefaultImpl.cpp:119: CHIP Error 0x00000032: Timeout'

[boreal surge]

Would you mind submitting a bug report for this? I don't see anything in our open issues that resembles that error message.

[iron trench]

I did last night too 👍🏻

[scenic grove]

The power of two Kyle’s coming together to solve the worlds problems one at a time!

[iron trench]

I set mine up in NL first. Then paired via Matter to Apple Home. I still get the “Setup” bug 🫠

[scenic grove]

Same here NL app first then just used the pass through from the app to Home

[frozen crystal]

Same as me. One day I suddenly had about 30-40 bulbs complaining. It was a painful evening to fix it all

[iron trench]

Oh damn! It’s for sure getting fixed now 😂

[brazen canyon]

@boreal surge I've got the flickering bulb problem for some colors here in the US. Mentioning it since it was thought to be a EU problem

I don't typically use the RGB but was testing something and get flickering for some lights on blue

[iron trench]

Of course we would have done the same process 😅 #MindOfKyle

[scenic grove]

#KylesOfTheWorldUnite

[midnight solstice]

I just found some chatter in the Home Assistant project issues where this may be a problem they are working on their side; in fact there are new HA and Matter Server versions posted again. Seems like a lot of patching related to Matter this week!!

Handle Matter nodes that become available after startup is done (@marcelveldt - #109956)

Let me run those updates and see if the issue goes away; will log an issue if it persists.

[brazen canyon]

Probably won't fix your problem. I have the same log from time to time. Bulbs die then don't come back and it leads to communication error

[boreal surge]

Thank you, I'll add this to the open ticket. Yes, our issue report notes this currently as an EU model problem. Much appreciated!

[boreal surge]

Very much appreciated, if you do log an issue would you also mind including links/screenshots (if appropriate) in the bug report? It's good context for our embedded team, even if the external chatter doesn't result in a fix.

[feral steeple]

Things do seem a lot better in 136 still. i still have a lot of drop outs, but largely useable at least.
Giving it a few days to see how it goes.

[mighty abyss]

I have an issue with one of 7 essentials bulbs. There is nothing unique about it and it's the same model as most of the others. However I was able to opt in every other one into the beta but this one never shows up in the list to be opted into beta.

It didn't show up when I first opted in all the lights a month or so ago and it's still not in there.

However it's working in the app and in home assistant and good otherwise

[main matrix]

Something I've found with my GU10s on either .134 or .136; it seems the flickering issues people are reporting doesn't seem to be specific to specific countries (I've read it seems to mainly affect those in EU or US). I'm in AU and am starting to get flickering when changing to any colour within the Nanoleaf or HA apps. If I select White only, it doesn't flicker.

[swift phoenix]

So this .136 beta I have some bulbs temporarily kicking off my HA network. Not sure if that’s because of new HA update recently or something else

[edgy tusk]

Bruh

[main matrix]

had the same problem. make sure you're on the latest beta Nanoleaf app for Android (10.4.1). I was on 10.4.0 at the time and they all failed until the app was updated.

I assume it might be something similar for Apple, but I don't use it so 🤷‍♂️

[iron trench]

What helped mine was to turn the switch off for 10 seconds. Turn back on. Open NL app with Bluetooth on and start updating 1, after it starts showing progress then click another one to update, etc up to 3 at a time.

[worthy grove]

Seems that .136 still has issues when bulbs are connected to multiple ecosystems. Did some stress tests with switching the active Apple Home Hub / remeshing. All of my 15 GU10‘s resubscribed to Apple Home (some really quick, some of them slower). I had only 9 bulbs shared to Home Assistant at that moment, but 4 bulbs struggled reconnecting back to Home Assistant and stayed unavailable. In the log you can see that all bulbs are discovered in mDNS but after that the following error „Time out! failed to receive report data from Exchange“. Unplugging the bulbs for ~10s did not help.

But I could pair these 4 bulbs and another 2, which were still available in HA, to a third ecosystem (Homey) and control them from Homey and Apple Home. So I tried restarting my Thread Border Routers again. After that all 6 bulbs, which were now also paired to Homey, stayed unavailable in HA and 2 of them now also in Apple Home. I thought what a mess and began removing them from Homey and suddenly all 6 bulbs became instantly available in HA again. Unfortunately the 2 bulbs stayed unavailable in Apple Home. Bulbs that were only connected to Apple Home were stable at all times.

[frozen crystal]

A bulb being in multiple ecosystems causing “no response” issues is an interesting observation. All of mine are in Apple Home and Nanoleaf, so that I can update the firmware. Let’s hope that this is a quick fix

[haughty grove]

Another night without spontaneous bulbs turning on. .136 is definitely an improvement!

[brazen canyon]

I can second this ^ I haven't seen any spontaneous turn on on 136

[frozen crystal]

I can third this

I am just bored of the “no response” thing. I hope we can help the team get to the bottom of it

[dull dagger]

No spontaneous on here either. Just 2 of my a19 have been unavailable for hours in HA. Power cycling the bulbs usually works but not this time. 🤔

[rare aspen]

I have the same issue after proceding with "setup" in NL app on Bulbs that paired in Apple Home.

[wind finch]

I don’t know exactly what that “setup” does, but I’d assume that it’s rather something with the local app. If I setup a light on my iPhone, then on my iPad it will show the setup and visa versa (or if someone else in my family with the Nanoleaf app looks on their device, it also shows setup). Everything still works 100% though.

[wind finch]

This setting keeps getting turned off for me… anyone else?

[dull dagger]

I restarted the matter add-on in home assistant and then power cycle the lights and they're all back into home assistant now

So definitely 136 so far has been the best firmware to date probably the others have some bugs to deal with too

[craggy plaza]

Ok, but the goal is not to power cycle them after restarting our Matter Hubs. They should get back on their own. 😉

[dull dagger]

I agree 👍

[brazen canyon]

Yeah I noticed today some in my kitchen go down when I use the microwave and require a power cycle to come back 😔

[craggy plaza]

Yeah, I also had to power cycle some of them in between. But hey, they do not witch on anymore. 😃

[eternal hill]

How old is the microwave?

Also my gf is reporting there are still ghosts in the appartment

On 136

[brazen canyon]

2015

[eternal hill]

Maybe put some tin foil around it

[eternal hill]

Nvm, shes just dramatic. False alarm

[magic tartan]

mhmm weird i'am not able to add them to HA on 136

tried power cycling and resetted the bulbs

[craggy plaza]

Ok, my got unavailable in Home Assistant without using a microwave…

[plain kettle]

Why is the code part blank? How are you commissioning them?

[magic tartan]

with HA app on IOS

[magic tartan]

debug log wasn't enabled

another questation, i got a new Unify Express Router, this week do i need to enable IPv6-DHCP for Matter to work?

[plain kettle]

Do you have working ipv6 local link in your network?

[magic tartan]

My Computer have a local IPv6, on my old router it was already configured

[plain kettle]

Do you have working ipv6 on your home assistant instance

[magic tartan]

How can I check, i'am a programmer not so deep on networking, xD

[plain kettle]

And you don’t have any vlans or anything?

[magic tartan]

No vLANs yes

[plain kettle]

System > network

What is your IPV6 set to? Automatic?

Also down in your network adapter, so you see any v6 addresses?

[magic tartan]

Yes

[plain kettle]

What border routers do you have?

[magic tartan]

i guess it was coincidence that the bulbs didn't work after setting up the new router

[magic tartan]

3 Nest Hub Gen. 2

[plain kettle]

Hmm ok, and you aren’t doing anything to block mdns?

[magic tartan]

no nothing

[plain kettle]

Is your bulb in another ecosystem?

[magic tartan]

No i removed it from Nanoleaf app

in the NA app Thread was working fine, but the NA app ist not a godd reference

[plain kettle]

Try factory resetting the bulb and adding it to HA, and also make sure in your UniFi settings, have multicast DNS as on, and IGMP snooping off

[magic tartan]

i have also 2 NAnoleaf light strip, the old one with only Thread no matter, they also not working over thread since the bulbs were not reachable

i have them connected with bluetooth proxy. When iy try to add them to Thread in HA they crash and again not reachable

[high atlas]

poshy___ has been warned

Reason: Bad word usage

[plain kettle]

Ah that might be it, try to be near it when you commission it

Just factory reset them, go near to the bulb and add them to HA

[magic tartan]

okay

and the thing with the strips

would be nice if they were also in thread network

[plain kettle]

Do you gave have multicast DNS as on, and IGMP snooping off?

It’s in the network settings

Of the UniFi console

[magic tartan]

OMG i found the problem xDDDD

[plain kettle]

What was it

[magic tartan]

The network cable of my HA instance wasnt plugged in for any reason and HA was over WiFi.

[plain kettle]

Sheeesh

That might be it?

[alpine ore]

@boreal surge how does power loss recovery actually work? wondering if it can cause any errors to persist after power loss

[magic tartan]

I found out a few weeks ago that at least for me the Matter server does not work properly when the HA instance is running via WiFI, I will now try to connect the light bulbs again

[plain kettle]

Okie

Make sure your network adapter has a local link address

[magic tartan]

Yes, it worked immediately xDD. that hurts now

[plain kettle]

Haha all good dude, happens to the best of us 🙈

[craggy plaza]

It should be the other way around:

mDNS = off
IGMP Snooping = on

mDNS allows multicast traffic to transmit across multiple networks. This is what we not want with Matter.

IGMP Snooping improves network efficiency by allowing switches to identify multicast groups so that packets are only forwarded to intended network devices. This setting should be fine.

At least that’s the configuration, that works for me. 😉

[plain kettle]

IGMP used to be super broken with UniFi, hence me having it off 😅

[craggy plaza]

Ok, it works here.

This is what Marcel also recommended.

[craggy plaza]

For me it was never broken. At least I did not recognize it. 😉

[magic tartan]

okay, guess i change nothing on my site cause it working now xD

[alpine ore]

I’ve been adding all my lights back after resetting them on 136, and they worked perfectly when paired via Apple Home (Matter) first. Scanning the QRs in Nanoleaf worked for my first group of 4 GU10s (bedroom), but then beyond that when I started scanning the QRs in Nanoleaf for my my living room GU10s everything started becoming unreliable and disconnecting from both Nanoleaf and Matter.

Scanning the QRs seems required for them to show up on the same thread network in Nanoeaf, as otherwise they show up under ‘Unknown Network’.

And the same goes for many of their special functions like scenes, etc.

So I’m considering either resetting them again and connecting them to Matter but not Nanoleaf, or just not using them until there’s new firmware, as I imagine I’ll have to pair with Nanoleaf to update them anyway?

[brazen canyon]

Pretty sure the recommendation was also IGMP off for unifi 🧐

[plain kettle]

IGMP can do more harm than good typically

[edgy tusk]

What exactly does that do?

[plain kettle]

Recovers the previous state after a full power loss

[craggy plaza]

Where is the source for that statement? 😃

Here is what Marcel said: #1049765219565576234 message

[plain kettle]

You missed the “if” there

It used to be bad, but must be better now

I know for sure when 1.0 dropped, it had terrible support and rarely worked, but things must of changed since, mb

[craggy plaza]

No, what is wrong with the unifi implementation? Again, it works here.

• UDM-SE
• USW-Aggregation (core switch)
• USW-Enterprise-24-PoE
• 4 U7-Pro
• 2 U6-Pro

[plain kettle]

It used to be janky as, and rarely worked and would drop stuff, again. UniFi could of rectified it in the last year or so, but I have always just kept it off

[craggy plaza]

I had it always active for years. Then I disabled it for testing purposes, but it’s enabled again now. And everything works as expected.

[craggy plaza]

Maybe, I can only speak for my own setup. 😉

Maybe you can try it again and report here, if you see any difference? 😃

[plain kettle]

Eh alright, I’ll flick it on and see how it goes

[dull dagger]

Anybody know if version 1.2 will allow support for scenes/effects like in the NL app?

[plain kettle]

according to this, no

https://csa-iot.org/newsroom/matter-1-2-arrives-with-nine-new-device-types-improvements-across-the-board/

looking at the github repo, its looking more like 1.3 or .4

[dull dagger]

Ah. OK not yet then. Thanks

[frozen crystal]

Well, hopefully it will happen this calendar year

[main matrix]

Has anyone else noticed that with these betas, the lights no longer respond to physical switches? ie. previously I was able to turn a light off and on at the switch if HA or GH was playing up, for example. Now, the lights are only controllable by GH or HA, which works fine for those that are tech savvy but I have people in my household that turn off and on lights at the switch, and recently the light has not been responding when current is applied at the switch.

It ends up that they turn it off and on 5 times to make it work, which then resets the light...

[brazen canyon]

So you turn current off then back on and it doesn't turn on?

[main matrix]

correct; the light flashes for half a second, then nothing

after the light is reset, it will go on and off, but it seems that as soon as it's tied to an ecosystem, that function is no longer present. has happened to all my A19s (21x) and GU10s (4x).

I'm all for tinkering, but resetting 25 globes every other day becomes tedious, especially when you're not the only one in the house..

[brazen canyon]

I've not had that issue personally

[main matrix]

trying to work out when and why it does it. some of the globes will stop communicating to the Nanoleaf/GH/HA apps after pairing to an ecosystem, some will stay for a few hours then go unavailable and never recover

[frozen crystal]

I do not have that issue either

[main matrix]

I have tested the light sockets with standard run-of-the-mill E27s and GU10s, and haven't been able to replicate, which makes me believe it is the Nanoleaf lights doing something. I don't recall having this issue on the non-beta firmwares, but again can't reliably replicate it.

[bitter compass]

Nanoleaf did say this - power MUST be off for at least 5 seconds.

#1184371187464290344 message reminder

[main matrix]

power has been off for several hours on some of them, doesn't make a lick of difference.

[bitter compass]

for turning it back on?

[main matrix]

yep

[frozen crystal]

I currently have 63 GU10s powered up, and they haven’t crashed my Thread network (mixture of Matter sensors and NL HomeKit). Only 7 are “No Response” in Apple Home. It took a few hours overnight for the mesh to build. This scale and stability is super progress. It was impossible until 136. Keep up the good work! 🥳😎

[bitter compass]

Agreed, this firmware is so stable for me, that I might never update to another version

[plain kettle]

I would certainly update if they have a 1.2 spec updated released to everyone

[bitter compass]

I'd be tempted but I would be worried that we would back to square one - having to iron out bugs again

[frozen crystal]

What’s the best way to resuscitate a No Response bulb without risking the rest of the mesh? Power cycle it individually, if possible?

[eternal hill]

Why?

[steel hemlock]

What are the next steps regarding the upcoming releases? As many other mentioned 136 is a good way but still not perfect.

[feral steeple]

After a few days on 136, a lot more stable, average about 3 out of 23 going unavailable at any given time

[frozen crystal]

Interesting/coincidental that it’s a similar proportion for me

[frozen crystal]

This didn’t work

[frozen crystal]

Assuming that the implementation isn’t awful (big assumption for this group, of course) I would be most interested in the promise of performance improvements over 1.1

[midnight solstice]

Since updating to .136, I still see the occasional unavailable on HomeKit for some of my 7 bulbs. Same bulbs in SmartThings have been solid and reliable, so I have repointed all of my HA automations back there, and things have been VERY stable thus far. I have NOT seen any random turn on/off events.

The latest HA and Matter Server updates have completely eliminated my ability to control the bulbs via HA. Paul asked for a problem report about my experience with "unavailable" bulbs in HA, but the problems may be self-inflicted. HA had two interfaces, the secondary was on same subnet as Matter bulbs, and in previous versions, it seemed to work well. I have been working on simplifying the network for HA (which was a lot harder than it should have been, oddities with QNAP networking, long story). Waiting for the dust to settle on all of that.

Overall, very happy with my experience with the .136 firmware.

[shell vigil]

Do you think that it would happen ever to control them all using 1 scene ?

[frozen crystal]

Goodbye or goodnight scenes turn off all, or almost all, of the lights. I haven’t stress-tested these yet under the new firmware. I should do, you’re right

[shell vigil]

It doesn’t work@

[shell vigil]

I have 2 scenes I have them but don’t use them because it never worked

Bulbs become@unreachabke

I have 40 Nanoleaf devices to control on the same time

[frozen crystal]

The biggest network load seems to be when adjusting colour or brightness. I haven’t tried to configure any of those yet as I didn’t think that they would work yet. The performance isn’t good enough at the moment

[shell vigil]

Nope they don’t , I have one scene that dim all on warm white 50% brightness for all of them@

Never worked from@the first shot

Maybe from the third shot but then I see 23 devices unreachable

[frozen crystal]

Well, at least they’re not all permanently disconnected. It’s a start…

“It’s easy to sell features. Hard to sell performance…”

[shell vigil]

Dm

[frozen crystal]

I still have the no response on Bluetooth or Thread bug on at least 1 bulb. Interestingly it’s a bulb which exhibited it on an earlier firmware too

In other words, either it’s a big coincidence or whatever is causing the issue wasn’t cured by a master reset and firmware update

[feral steeple]

The ones going unavailable seem totally random. Initially I thought maybe ones furthest from the BR, but nope, some almost next to it will randomly start going unavailable, so I am assuming it must be bulbs crashing still. Sometimes connecting back up, sometimes being just unavailable until restarts of BR's or matter server etc.

[blazing meadow]

I still have one permanently unavailable A19 bulb from GHome (despite adding it there first), but SmartThings sees it perfectly (same Thread network).
Weirdly, with the latest beta firmware I get a "Not on Thread" warning on both A19s from the desktop app while both are seen from the Android app (same Wifi network).
EDIT: "Not on Thread" error on desktop fixed for both A19s -> I didn't notice the app logged me out of my account, so it didn't receive the updated info of the bulbs I've reset.
So the last issue I have is only with GHome and one specific A19, so CHIP-1280 but with 3.6.136.

[feral steeple]

It seems like when they go unavailable and dont reconnect, they dont come back on until restarting OTBR and matter server. So who knows if its a HA or a nano problem there 😦

[blazing meadow]

Following https://research.nanoleaf.me/2024/02/verifying-unreachability-issues/ I see the "faulty" one with nRF Connect on Android with the same ~200ms latency as the other one.
Using Bonjour Browser on Windows ( https://hobbyistsoftware.com/bonjourbrowser ) I also see both mDNS services under _ltpdu._udp. but that app doesn't show the IPv6 as it only seems to support IPv4.

[blazing meadow]

Thread weirdness.
I added to the Thread network a bulb that I removed from it a few months ago (it's switched on/off manually, and with more devices on the Thread network the "power on" phase took too much time), and with the changing topology the previously offline bulb (again, only from GHome's POV) got promoted to "Leader" (according from the Android Nanoleaf app) and suddenly got recognized again by GHome.

After updating the "new" A19 from 3.5.41 to 3.6.136 it still takes ~4secs to turn on after being powered on, but I guess it's another issue completely.
I wonder if my Lines and Shapes border routers have a negative impact on the whole topology, if the bulb becomes unreachable again I'll try unplugging them.

[dull dagger]

Day three here and all my lights are still connected and still working. And they don't even disconnect anymore

I have noticed that pop on that people talk about it's weird it doesn't do it all the time

[rare aspen]

I would personaly upgrade as long as it offers Sync+ capability 🙂

[frozen crystal]

Overnight another two lights have gone “No Response”. It’s now 9/63

[main matrix]

I'm having at least two A19s go unresponsive for extended periods. One will recover after a few hours, one requires a complete reset and add back into HA from scratch. If this particular lights drops off again, no amount of rebooting/resyncing fixes it. Always requires a reset. Total of 25 lights (21 A19s, 4x GU10s).

[verbal drift]

63 holy $hit balls, no wonder you were having a headache mate!!

[tranquil pollen]

So I was playing around with Home Assistant and Apple fabrics. I saw a few mention that running the bulbs on one fabric improved reliability. That wasn’t the case for me.

I originally reset all my bulbs that were paired with HA and Apple, but I factory reset them and paired them with HA only. After that air lost Nanoleaf app control and I could never get them to connect to the NL app.

So now I’m back to HA and Apple paired bulbs and the NL app works again.

[tranquil pollen]

Forgot to mention this is on .136 for A19 and downlights. Not using the beta app either on iOS.

[boreal surge]

Could you DM me the serial number of the bulb which can't opt in?

[boreal surge]

At a high level, when the Power Loss Recovery (PLR) feature is enabled, the device will save its state to local memory on the device (brightness, colour, scene, etc). In the event of a loss of power to the device, that state information is available to the device when power returns to the device in the future. The feature was meant to ensure consistency in behaviour despite power interruptions, and avoid a situation where if a device was "off" before a power loss it turns "on" when power is restored.

[frozen crystal]

It will be 69 or 70 by the time I’m done 🤣🤦‍♂️

[verbal drift]

Fair play, when they work they are awesome

[frozen crystal]

Opportunistic timing of a whole-house refurb… 😬

[swift phoenix]

So I have not had any bulbs turn on which is good news. However, I have had disconnects of bulbs for a period of time. Hopefully they are close to finding the middle ground between these 2 issues.

[steel hemlock]

Info: since today, one light is not responding any more. I do not know why.

[frozen crystal]

Yes it seems that we are finding that bulbs eventually drop off and do not reconnect

[steel hemlock]

Further on, for my EU bulbs the flickering (when getting turned on or off) is happening more often again.

[shell vigil]

I am not having any issues 🙈 just flickering and wrong colors . Sometimes bulbs get disconnected but connect fast again

[steel hemlock]

Is there already a fix known?

[frozen crystal]

Not that I am aware of

[boreal surge]

Hey folks, now that we're deeper into the more ambiguous issues that are a challenge to solve for, I'd like to start measuring reliability over time to help us put some data behind improvements or regressions at a high level. Can you please visit the beta landing page here, and fill out the reliability poll? It's a four question poll, shouldn't take more than 30s to complete. Max one entry per person per day. It'd be spectacular if you could fill out the poll after fiddling around with your test setup each day 🙂

(I'll negotiate with NanoBot to send out daily convenience reminders, and perhaps ask her nicely to ease up on the bad word scolding)

Password is CHIP0001 :

https://research.nanoleaf.me/upcoming-quests/chip0001-3-xx-thread-beta-software/

[verbal drift]

What’s the password again sorry

[plain kettle]

CHIP0001

[verbal drift]

Of course thanks mate

[boreal surge]

My bad, have added it to the pinned message 🙂

[brazen canyon]

Is this poll live? Maybe I'm too dumb to see it but all I see is the big report form

Oh weird must have been a cache issue

[boreal surge]

Perhaps clear your browser cache, we shipped the reliability poll maybe two hours ago.

[brazen canyon]

Yeah was cache

I think reachability is poorly worded.

Time for an app to recognize a device is reachable? Don't app front ends just check in with the matter server which should be near instantaneous?

A better metric would be reliability -- the amount of uptime of a device and the speed with which it reconnects if it goes unavailable

"connectivity" should just be "latency" and connectivity encompasses more than just latency and latency is the only thing listed in the description

I'd think categories are

Device Reliability (how often devices are connected and how quickly they reconnected)

Latency (perceived delay between issuing command and response)

Pairing reliability

Consistency (how often does the device respond correctly and as expected. Low consistency would be bulbs turning to the wrong color or exhibiting inconsistent behavior to same command)

[frozen crystal]

I agree

Those categories capture four big issues which had been driving us nuts

[boreal surge]

@brazen canyon @frozen crystal thanks for the feedback 🙂 I worded the questions through the contextual framework of the Nanoleaf App—I think that what you've suggested is a bit better for the Matter ecosystem. Will fold those in for tomorrow.

[brazen canyon]

I'd also add a not applicable for matter or NL app exclusive questions in that case. Some people just use the NL app or not at all

[boreal surge]

Yup, good point

[plain kettle]

not that you have to, but maybe add how many ecosystems and/or what ecosystems the devices are currently/are connected to?

as diffrent ecosystems and yeild some massively diffrent results

[magic tartan]

So to sum up the last few days for my setup, the bulbs have never worked as well as they have in the last few days, they were almost always accessible, only sometimes 2 bulbs were sometimes not accessible, which was easily fixed by power cyceling.

i'am on version .136. Well done guys, keep at it

[plain kettle]

(may be offline for one, and online for another etc etc)

[magic tartan]

Good point, that was missing in the survey

[frozen crystal]

Yes this is an excellent point. For instance, I currently have a bulb which NL thinks is on the Thread network but Apple has it as No Response

[brazen canyon]

Fine line between a quick check in and getting enough info tho. Id say for a quick check in that doesn't matter too much.

You could just see if the spread in "matter stability" responses was big then you could infer that there's platform specific issues

[craggy plaza]

Today I had to restart my Home Assistant server. Not all Nanoleaf devices came back and it didn’t always help to power cycle them. Some came back, others not. A few power cycles brought other devices into the unavailable state, maybe the power cycled devices were mesh extenders / routers.

The devices always were back to Apple Home instantly. After some power cycles of Nanoleaf bulbs I decided to wait. Now (10hours later) I had a look at my Nanoleaf devices paired to Home Assistant.

• one bulb took 3,5 hours to get available for Home Assistant
• another bulb took 2,5 hours to be available for Home Assistant

I think this what others already reported here. The periods of unavailability in HA got increased. But I still had not a single bulb that switched on by itself.

[brazen canyon]

I wouldn't say unavailability in HA availability has increased across the board. Mine are very stable and although I do have drops they are usually ~seconds and almost never 1+ hour

[craggy plaza]

Ok, that’s interesting. Your bulbs are paired to Home Assistant and Google, right?

My bulbs are paired to HA and Apple Home. My HA is in a Debian KVM. I have 7 Apple Thread Border Routers, no SkyConnect. It feels much better than ever. But I wouldn’t say ‘availability has increased across the boards.’ Typically I loose some bulbs, when I have to restart HA.

Also others here already reported the same behavior. 😉

[brazen canyon]

HA only, bare metal RPI. I do have a skyconnect also but 5 BR total

[craggy plaza]

Maybe that’s the difference. My HA is a virtual machine and yours is bare metal.

@brazen canyon How many Nanoleaf bulbs do you have paired currently? I am at 14 bulbs.

[brazen canyon]

18

[craggy plaza]

Ok, so you've already exceeded the limit of 11 bulbs. 😃

[ornate obsidian]

My setup is similar to yours except HA is on the Yellow - I’m not currently using the sky connect. I’m having bulbs in HA drop in and off all day (even had a moment earlier today where all bulbs were available). Home app in iOS doesn’t appear (but also does track 24/7) to have the same drop offs - as I can control the bulbs from the Home app even when unavailable in HA

[craggy plaza]

Oh, thanks for the acknowledgment. Can I ask you how many bulbs/led strips and thread border routers you have? So you only have Apple thread border routers? Do you know how long they drop off in HA before they come back?

[feral steeple]

I think you need to add some extra questions or make a split on % of bulbs that had problems.
Maybe even just one to get an idea of the split. I.e. for the last 24 hours 4 out of 24 bulbs have mostly been unreachable, so for those I would consider reachbility and connectivity poor, but the 20 bulbs only 2 dropped out for small periods of time so for those i would consider them good reachability and connectivity.
So im torn on how I should answer the survey

[craggy plaza]

I have also canceled the survey for today. But there were already some good suggestions in the discussion here. I'll join in tomorrow.

[craggy plaza]

So I looked through the logbook of my bulbs and recognized that two more bulbs have ‘became unavailable‘ logs:

• one bulb became unavailable for 9 seconds
• another bulb became unavailable for 34 minutes

But hey, they came back on its own. 😉

@brazen canyon Did you ever reboot your HA machine with this latest firmware? This is where I had issues with bulbs needed hours to get available again.

[brazen canyon]

I have done that yeah but usually a power cycle got them to come back. There was a lot of initial instability but seemed to mesh well after about 24 hours

[craggy plaza]

So, the question is, how long it will take for the bulbs to get available in HA, when we do not power cycle them after a Home Assistant reboot. Everybody wants to get them back to available without waiting. So we power cycle the bulbs. But that’s not the solution. 😉

[feral steeple]

I have multiple times. Has largely not been an issue. Some random bulbs go unavailable and dont come back, sometimes power cycling them gets them back, The ones that get stuck offline typically need the bulbs power cycled and dont check back in, which makes me think this is still firmware issues

[brazen canyon]

I mean you can see in the logs it's for one of two reasons 1) bulb ends up not re-subscribing or 2) mDNS vanish.

chip.DIS[126] ERROR Timeout waiting for mDNS resolution.
2024-02-13 18:21:18 core-matter-server chip.DIS[126] ERROR OperationalSessionSetup[1:000000000000000A]: operational discovery failed: src/lib/address_resolve/AddressResolve_DefaultImpl.cpp:119: CHIP Error 0x00000032: Timeout
2024-02-13 18:21:18 core-matter-server chip.DMG[126] ERROR Failed to establish CASE for re-subscription with error 'src/lib/address_resolve/AddressResolve_DefaultImpl.cpp:119: CHIP Error 0x00000032: Timeout'```

That's a log where the bulb subscription died and it's unreachable

[craggy plaza]

Yeah, this is not solved and was never promised with this firmware:

#1184371187464290344 message

[boreal surge]

A new version of the reliability poll has shipped, you may need to clear your browser cache to see it.

[brazen canyon]

Could you clarify the "percentage affected" is that for any of the above issues?

[boreal surge]

@brazen canyon That's correct, yes. The UI for the underlying data toolset is a bit limited for this type of aggregation (I might build something custom later). What I envision with this is that it's a quick snapshot of the overall experience—if you want to submit a couple of different polls to segment the experience in different ways, you can (ex Nanoleaf app vs other or 40% affected vs 60% affected). If you want to look at it as the total experience and wash the good with the bad, that's OK too. This is supplementary data for us, I don't want to become so granular that checking in is burdensome to you folks.

[brazen canyon]

Sounds good; just wanted to make sure I understood what was being asked

[feral steeple]

I think you already have this on a list somewhere, but commissioning to HA from the nanoleaf app fails most of the time, but if i commission to google home then HA it works fine. So i think its something screwy.
Only difference i see is when doing it from nanoleaf app the first failure is ERROR Time out! failed to receive report data from Exchange: where that does not happen when going from google home

[brazen canyon]

What about commissioning directly to HA?

NL -> HA: Bad
GH -> HA: Good
HA: ?

[feral steeple]

That was working doing direct to HA the other day, but one dropped out of HA for some reason (said This entity is no longer being provided by the matter integration. If the entity is no longer in use, delete it in settings.), so was trying to connect it without resetting it.
Google home showed it was still linked to HA matter so not sure why that happened.

[ornate obsidian]

I have 13 HomePods and 3 AppleTVs operating as Border Routers, no non-apple devices. Looking at the logs it’s all over the place - sometimes it’s a few minutes and other times it’s hours

[ruby urchin]

I have the same problem. In my case it is a downlight. But the device is still on 3.5.7 and has never received the update to 3.5.41 or 44. Did you solve it somehow?

[craggy plaza]

@boreal surge

Hi, I filled the daily reliability poll. It’s much better now, but I need an optional multi line text field to describe the issues in more detail. I know, it’s not measurable.

For example… Today, 2 of my 14 bulbs became unavailable in Home Assistant:

• one bulb became unavailable 8 hours ago, I will wait until tomorrow, before I am going to power cycle it
• anther bulb became unavailable while switching it off via an Home Assistant automation. The bulb didn’t switch off completely. It stayed at 5%. In Apple Home it looked as follows. The bulb works fine in Apple Home, but is unavailable in Home Assistant since 1 hour. Maybe the bulb crashed while switching it off.

Any idea how to bring such informations into your poll?

2 of 14 bulbs have issues. So I have to choose: > 10% < 50% of affected devices. The two described issues are from the category ’connection reliability’. But what would be the right choice (good, poor or terrible? definitely not excellent).

[brazen canyon]

You should see if you can ping the bulb. I don't have as many go down as you so I can't test myself

[boreal surge]

@craggy plaza Thanks ! I'd say adding a multiline open input is too much granularity for a poll to track (as you say, not measurable, which is the purpose of the poll). To judge Excellent / Good / Poor / Terrible in any category, base it on how the problem makes you feel about your experience and the network overall. If you experience brutal latency on only 5 of 30 devices and it makes you really mad, choose 'Terrible'. For issues which are specific and there's reproduction data you can share to add nuance to the problem, add it to a bug report. Having duplicate bug reports is OK, we screen them and add the additional information to the original issue ticket 🙂

How we "feel" certainly isn't scientific, but is important.

[craggy plaza]

Ok, thanks

[dull dagger]

136 still going strong here 💪

No issues to report about connectivity

[feral steeple]

still about 10-12% of devices that just randomly dont connect, but largely connected so things mostly work. hope the next update makes it better again

[manic plover]

Is there some news on Matter 1.2 and the "good" library?

[plain kettle]

Hey lads, just got some more downlights and would love to enrol them into the alpha fw/beta. just curious as to who is managing all of that now?

[deep notch]

For the first time since 3.6.136 update, a device powered up during the night

[deep notch]

Sorry, wrong info, when looking at my security camera footage, it seems like it didn't power off, so maybe a disconnection instead

[verbal drift]

Good morning, reliability poll has been filled, one GU10 didn't turn on this morning, had to switch all GU10's off for 10 secs and it came back on, totally unrelated a A19 lamp is showing as 'unresponsive' which has just been sat there and no commands sent to it, I am confident a power-cycle will address this issue. Just for more context.

[feral steeple]

Strange issue i noticed today. 6 out of 8 bulbs when they turned on just flashed and then went dark. Reporting as turned on, but no light. Turn them off and on again and they were fine, but strange.

Noticed another one do it in another room too

[brazen canyon]

I'm not sure they're still doing the alpha branch, but regardless, the current beta branch is pretty stable

[plain kettle]

ah wait, duh. the down lights are only on 3.5.45 which from what ive seen isnt on the same chain as the other ones

[silk owl]

I wanted to try my hand at the GU10 firmware update via the iOS app, am running 10.4.1. (588) via TestFlight. No options to update the firmware there though - all A19/GU10 lights were commissioned via Nanoleaf and the last GU10 upgrade to 3.5.41 worked well via app (back in Nov/Dec). Am I missing out on something?

[brazen canyon]

You have to opt in for the beta on individual bulbs via the website on the pinned post

[silk owl]

Thank you, missed that indeed! I hoped to get around having to open a Nanoleaf acct, based on the company’s reliability track record in this home so far my trust in their cloud infrastructure is also quite limited… but I might try.

as I understand the discussion here the 3.6.xx beta firmware seems, well, quite beta still - is it broadly recommendable as an improvement over the old stable 3.5.xx?

[brazen canyon]

Well it's because it's opt in and they need to push the FW to a specific serial number / device so cloud is required.

The current 3.6.136 is very stable for most and a big improvement over 3.5.x

[silk owl]

Am updating right now, fingers crossed 😎

[brazen canyon]

FYI you'll see the biggest boost if you update them all with the beta

[steel hemlock]

Is there a "timeline" or something like that for the next beta release? Maybe with Matter 1.2?

[brazen canyon]

@boreal surge I've been able to force devices offline by issuing large amounts of commands at once. I have about 20 bulbs and issuing turn on or turn off to all of them at once will cause bulbs to crash and go offline for some time. In my case, they do come back after some time, but I'm not going to triage / try to figure out why they might not (others have said their bulbs don't come back). The fix here is to make sure they don't crash in the first place. This could have cascading effects and relates to CHIP-1280. Probably why the GU10 owners see more errors than everyone else as they're likely controlling larger sets of bulbs at once than people using just a19 or br30. I'll file a report this afternoon, but just FYI.

[boreal surge]

That's a great observation, thanks.

[wild oracle]

iOS 10.4.1 Released

We’ve resolved an issue causing Essentials Matter devices to become unreachable from the Nanoleaf App if you also have some of our Panel products. Make sure to update if you’ve been seeing this issue.

#1184371187464290344

[silk owl]

Update worked, yay 🥳 a few GU10 decided to not re-join the thread network, they are still reachable via HomeKit app though. Maybe this irons out after a few hours?

I also wonder if the delays in response time can be fixed in a future update… right now controlling the GU10 from any app does not feel too smooth. With my setup being rather small (11x GU10, 12xE27/A19, 3 light strips, 2 HomePod mini, a few Eve Energy plugs) i i guess it would not be an Infrastructure issue.

[feral steeple]

Ill try this tomorrow if i remember and see if i get the same experience. Have 24 GU10's connected currently

[brazen canyon]

You're running HA right? Put them all in a light group and see if they explode when you turn them all on or off at once

[feral steeple]

Yea, I have 3 light groups with 8 in each currently. So may be part of when some of them have issues is if I walk through all 3 rooms in a short period of time.

[craggy plaza]

I share this experience, but my groups are much smaller. 2 or max 3 bulbs in one group.

When this Nanoleaf beta phase started in December 2023, I created the following thread I the HA discord Matter channel:

#1186401600521117746 message

Nobody wanted to talk about this at that time. Maybe I was a little ahead of the time. 😃

[feral steeple]

You were a month before I had HA or nanoleaf 😛 Went down the rabbit hole in Dec and ordered it all haha

[plain kettle]

Yeah, I got a group of 4 bulbs and they just do not turn on via automation

[shell vigil]

That caused all my thread network to crash and my bulbs to become unreachable

The network is building up again

[brazen canyon]

Ahead of your time 😎

[plain kettle]

when they crash, do you manage to get any of them to turn on?

not even runnning them in parallel works

or as a 4x individual in a single call

[brazen canyon]

Yeah they all do

[brazen canyon]

I have 4 in a light group and it works fine for me

You'll see them dropping in the matter logs if they crash

[craggy plaza]

I have 6 light groups, 4 with 2 bulbs and 2 groups with 3 bulbs. 5 of them are running since the first 3.6 beta release. They mostly work. But when a bulb crashes, it took hours to see them back or they never came back by themselves.

One of my automations to switch more bulbs on by pressing a button on one of my Philips Hue Dimmer Switches, looks as follows.

When I configured that group in December 2023 I recognized that I can run 2 maybe 3 commands in parallel without a crash. So I grouped it that way. The device “Wohnbereich Lichterkette“ is a dumb light, behind an EVE Energy Matter over Thread plug. I thought, that it may also influence stability when switching all the lights on.

[brazen canyon]

Why not just use a group for spot 1 and spot 2?

[craggy plaza]

Nothing Nanoleaf related. I do not find the helper groups within an automation. But I have real HA light groups, which I bridged to Apple Home. Now you or anybody else can ask, why I don’t use Apple‘s groups. The answer is also easy. When you group bulbs in Apple Home, you can only control the group, but not every single bulb anymore. So, I found this as an acceptable workaround for me. Where do I find the light groups in an automation?

[brazen canyon]

You call light.turn_on on the helper entity

Example:

service: light.turn_on
metadata: {}
data: {}
target:
  entity_id: light.sink

[craggy plaza]

Ok, I am relatively new to HA, a bit more than a year now. I do most things via HAs web interface. But I already understood how I can do things with yaml. Thanks

Ok, now I found it also via the web interface. Maybe I was blind… Will try that tomorrow.

[plain kettle]

just curious, when a single bulb out of the group is down, do all of yours fail to execute?

[brazen canyon]

No the ones that are connected execute for me

[brazen canyon]

Yeah you can do it all in the web UI I'm just used to screenshots being blocked in the HA discord

So I sent the code

[craggy plaza]

Here you find a good description about group behavior:

https://www.home-assistant.io/integrations/group/

[stark crystal]

Explode as in?

[plain kettle]

crashes

[humble whale]

I am not participating in the beta. Just wanted to say that seeing Nanoleaf developers actively work with users and iterate gives me a lot of confidence in the future of the software.

[quiet sky]

I cannot ad my nanoleaf essentials to Home Assistant with Matter. Are there tips and tricks to do this?

[brazen canyon]

You need to ask/troubleshoot in the home assistant discord since it's probably an issue with your setup

[verbal drift]

Things must of improved for people as this is the quietest I have seen this forum!

[steel hemlock]

Well. On the one side things improved. On the other side it doesn't make much sense to ask every day for an update regarding the same issues (for me it is the flickering).

[craggy plaza]

As long as I have to power cycle one or two bulbs over the day, it’s not production ready for me. But yes, things really improved. Imo best firmware ever. The switching on issue can be closed:

• CHIP-1236 : A19 Devices still seem to turn on randomly on 3.6.x

[midnight solstice]

In terms of my experience with the firmware, I agree it is WAY better overall.

I'm still seeing odd behavior at times where a light will appear unavailable on either HomeKit or SmartThings, and when I go check the bulb in the NL app, it shows connected to Thread, but the network says "Unknown." I haven't noticed others discussing that kind of problem, so might be unique to my network situation, which is WAY simpler than it was previously.

My final comment, I was having a devil of a time with HA being able to control the NL bulbs. I was suspicious that it was more to do with some kind of corruption in my HA server. After simplifying things, wiping the configuration completely for OTBR, Thread, Matter, and then rebuilt it all from scratch. Net result is the bulbs re-paired to HA easier than ever, and I was even able to confirm that HA can control a bulb even if all of my Apple BR's are unplugged.

But it seems it's still not quite right, as HA can control bulbs on/off just fine. But the state is currently only showing up correctly for a single light (MR Light 1). Very strange:

[alpine ore]

One of my GU10s has straight up stopped turning on. Like, it’ll respond to commands and show up (it’s added via Matter only, not NL), but the light itself doesn’t turn on.

@boreal surge any idea what’s going on? ^

Wondering if it blew a fuse while resetting it… 💀 The other lights on the same circuit turn on, just that one doesn’t work.

[midnight solstice]

Ok I restarted HA, and MR Light 1 still seems good. However all of the rest of the lights showed a message like below. Over the course of maybe 10 minutes, 4/7 of the seven are coming to life. Matter logs show 4 corresponding" INFO Subscription succeeded" messages.

Maybe I just have to be patient, or perhaps power cycle the bulbs? (Although I'm hesitant to do that because it seems like a coinflip sometimes if they come reconnect to thread without additional fiddling).

[brazen canyon]

Edit: dead bulb was resurrected after leaving off current for an hour

[brazen canyon]

Open a mDNS service browser and browse for the matter service, after that, check and see if they have come back

[eternal hill]

Im really happy to not be one of the nanoleaf devs. The stress from angry costumers + people internally in nanoleaf must be a lot.

[midnight solstice]

In Flame, I see all 7 devices, each with 5 services. Yet HA still shows 3 of them unavailable.

mDNS is such a PITA

I've had to shutdown all my BR's so many times to clear out issues just to re-pair devices. Getting my steps up and down the stairs!

[brazen canyon]

I say that because there's some issues with mDNS and polling them can get them back in HA

Really the problem is the bulbs are still crashing in some instances

[midnight solstice]

I may have missed a DIY fix for that: issues with mDNS and polling them can get them back in HA

Can you elaborate?

[dull dagger]

So one of my devices went offline in HA (after about 5.5 days of being available). Unplug and plugged back in and it's online. The NL app said it was on thread so not sure of this is a NL or HA or Google (TBR) problem.

[midnight solstice]

Might want to click settings and see if it reports to the correct Thread network. That's the issue I have been seeing, the network said Unknown.

[dull dagger]

Ahh good idea. Let me check that next time it happens. Thanks.

You mean in the app or HA?

[midnight solstice]

NL App

[swift phoenix]

Same here

[dull dagger]

The connection symbol was in thread mode, that's all I remember

[midnight solstice]

As Adequate-Spectre mentioned, the bulbs are probably crashing, and it puts them in an unstable state. It'll have the Thread icon like it's connected, but in my case it should be connecting to my HomeKit thread network. But it didn't show the panel at the top for "Connect to Matter" at all, and the "Thread Network" said Unknown.

I'll get a screenshot if it happens again.

[dull dagger]

Okay I will keep on eye out for this next time it happens and report back here with this thanks

In this case my device was the LED essential strip

[brazen canyon]

In my case, just calling avahi-browse -rtp _matter._tcp from a Linux device in the same VLAN as HA/matter gets them back

[dull dagger]

Where do you put this?

[midnight solstice]

Oh, I like it; let me give that a try

[brazen canyon]

It's unconfirmed, so if it works for you, let me know

[midnight solstice]

well it certainly wasn't an instant fix

I get lots of output, as you would expect

[brazen canyon]

So, in the matter logs, did it rediscover any of your devices?

(HA matter logs)

[midnight solstice]

nothing new in matter logs, just every 10 minutes seeing something like this
2024-02-17 12:46:54 core-matter-server chip.DMG[125] ERROR Time out! failed to receive report data from Exchange: 10358i

[brazen canyon]

Interesting I wonder what's going on on my end then

[midnight solstice]

maybe a coincidence

I'm going to power cycle one of these bulbs, see if that wakes it up

[brazen canyon]

No it's not a coincidence as it's repeatable

For me

[midnight solstice]

avahi-browse that should be a passive command

not sure how that would affect mDNS resolution on a completely different device

to be clear, for me, this is a completely different linux host on the same network as HA and my bulbs

[brazen canyon]

Yep same for me, but when I call avahi-browse I can see that the mDNS service is update and devices are rediscovered

HA uses a ServiceStateChange monitor and it triggers for me when I call avahi-browse

[midnight solstice]

where do I look for that ServiceStateChange?

yeah, power cycling did nothing

[brazen canyon]

Here's the specific code
https://github.com/home-assistant-libs/python-matter-server/blob/4100c0c08e01fbd9b13419f0d83c944f715bfec4/matter_server/server/device_controller.py#L125

I made a script that did that basically

You should double check the mDNS record output from avahi-browse to make sure your bulbs are actually there if you haven't already

[midnight solstice]

the top bulb from my earlier screenshot has 8 entries

HA needs to give us a way to check this sort of thing for debugging

[brazen canyon]

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

😉

[midnight solstice]

nice, that's a start. I was talking about mdns in particular, since that seems to be the root of an awful lot of evil here.

[brazen canyon]

They only added mDNS discover like two weeks ago. Yeah there's some bugs but the problem is more that the NL bulbs get disconnected (often by crashing) then the server has to sort it out... The real fix is stable devices. I rarely have issues with my other matter over thread devices

[midnight solstice]

SmartThings and HomeKit are both more stable and forgiving for the same Matter devices. Certainly bulbs that don't crash will help, but there certainly seems to be some HA unique funkiness here too.

probably will come with time, as you say it has come a long way in a short while already

[brazen canyon]

I've only got 4 for mine so that might be your issue

[brazen canyon]

Who knows how many devs apple and Samsung can afford to put on their matter controllers. Apple also develops the matter SDK as well.

[midnight solstice]

curious, the linux server that you run avahi-browse on
Mine is Ubuntu 18.04.6 LTS
been meaning to upgrade

you using something else?

[brazen canyon]

I run 22.04 but I don't think that matters

[midnight solstice]

well maybe newer version of the utility does trigger something on the network, e.g. not passive

let me look into that

[eternal hill]

They also still have the thing with the ipv6 routes that have to be fixed in the kernel.

[midnight solstice]

yes, that would be nice. but all my stuff is all single network now, so in theory not an issue

[eternal hill]

Your thread border router basically rotates its ipv6 prefix

And it takes some time before the Old prefix is removed without the kernel fixes

From what i can remember

[brazen canyon]

Isn't that fixed in HAOS though?

[midnight solstice]

you mean the link local address, that's changing periodically?

[eternal hill]

Yes, but if hes running ubuntu 18.04 that still would have the problem

[midnight solstice]

Home Assistant is HAOS

different server

[eternal hill]

You cant access thread devices using linklocal

[brazen canyon]

I think 18.04 is just the host he's using browse from

[midnight solstice]

yes, it's a separate linux device

[eternal hill]

Okay, just be aware that there could be some problems.

You can also just open a Shell in tje matter or thread docker containers

In hasOs

[midnight solstice]

yeah I read a little about the challenges with thread ipv6, it's a mess

[eternal hill]

Its just that thread is the first thing using ipv6 in this way

Until now some of the stuff has just been specs, so it has not been tested.

But for debugging the dns stuff, you can ssh into the openthread addon (if you have it) and use dnssd to browse services.

The matter container might have it too now.

Then you are actually able to see what the Matter server should see.

[midnight solstice]

interesting, I'll look into that

[brazen canyon]

I was never able to start the avahi daemon in the matter container but I never tried too hard either. I just saw errors and decided it wasn't worth my time

It's not installed in the container so it has to be added

[eternal hill]

I’m pretty sure that Avahi-browse is actually active and asks “is anyone there”. But I also think there is also an option to dump the cached entries.

https://linux.die.net/man/1/avahi-browse

[eternal hill]

Yeah, that’s where you can use dns-sd instead

That’s installed in the otbr container for sure

[brazen canyon]

What I suspect is at least in some instances, bulbs are crashing, triggering HA to say node offline, but then rebooting, but rebooting so fast the mDNS record is never updated and never triggers the node discovery handler

But that's just speculation on my part until someone else can corroborate the behavior

[eternal hill]

Tbh I think the mdns entry should always be updated. Your device can also change its ip address. So the active connection should start communicating the new ip address.

I’m not sure how it really works in detail though

I can try to check if I can trigger something similar

[brazen canyon]

I can dump my python script here later. I can crash my bulbs on demand by issuing on/off commands to all 20 at once. I start the python zeroconf listener, crash the bulbs, the note that there's no state changed update. After calling avahi-browse I see the state change update and offline bulbs are discovered via mDNS.

Here's the GitHub issue if you end up finding anything

https://github.com/home-assistant/core/issues/110721

[eternal hill]

So basically you don’t see a broadcast of the bulbs new mdns entry when it crashes?

[midnight solstice]

yeah, I'm not seeing one after a power cycle either

[eternal hill]

Have you had your listener script active on one machine and check if running browse from the other machine makes the entry pop up on the first machine?

And is the old mdns entry the same as the new one? Could be some kind of denouncing happening

[brazen canyon]

I haven't yet checked the cached entries when the listener was running

I only noted that avahi-browse causes it to trigger the update handler

[eternal hill]

Maybe just start it before crashing the bulb then

[midnight solstice]

I'm updating my Ubuntu just to see if I can reproduce that behavior here. For what it is worth, I'm on a Ubiquiti network here, which has some eccentricities of its own.

[eternal hill]

You should be able to see if you actually get any mdns entry send

[eternal hill]

Yeah, it could be UniFi just filtering the broadcast

[brazen canyon]

I started the listener before the crash yes

I'm also running ubiquiti

All mDNS and igmp stuff off

[midnight solstice]

Ok good to know. I originally had IGMP Snooping off, but based on a recent debate on here, I turned it on

ah hah

so I should turn that back off to match your situation

that's probably more relevant than Ubuntu version

[brazen canyon]

I'm running whatever the general release is

[midnight solstice]

same here, NanoLeaf is the only place I'm in beta land, and that's just to preserve what's left of my sanity... 🙂

[eternal hill]

Would be interesting to run the same test on a not UniFi setup

I should invest in some non UniFi Poe switches 😂

[brazen canyon]

I've had a good experience with my unifi gear so I'm not so eager to throw them out especially when it's some niche matter issue

[eternal hill]

@brazen canyon maybe add a more detailed explanation how to reproduce the issue. (How to crash the bulbs, your setup and what you have exactly tested

[eternal hill]

It took them years to fix mdns for AirPlay and chrome cast

Their vpn crashes constantly on my mac

The web interface on one of my networks is basically unusable

And a lot of small stuff

[brazen canyon]

Guess none of that impacted me since I have phones + casting devices on same VLAN and I don't use their VPN feature

[midnight solstice]

I've turned off IGMP Snooping again, and before upgrade happened, still no immediate impact to avahi-browse for me. Probably have to power cycle everything again to trust that result.

[brazen canyon]

Could be you're also having a different issue

here's my listener script:

from zeroconf import ServiceBrowser, ServiceListener, Zeroconf, ServiceStateChange


class MyListener(ServiceListener):

    def update_service(self, zc: Zeroconf, type_: str, name: str) -> None:
        print(f"Service {name} updated")

    def remove_service(self, zc: Zeroconf, type_: str, name: str) -> None:
        print(f"Service {name} removed")

    def add_service(self, zc: Zeroconf, type_: str, name: str) -> None:
        info = zc.get_service_info(type_, name)
        print(f"Service {name} added, service info: {info}")
    
    def state_change(self, zeroconf: Zeroconf,  # pylint: disable=unused-argument
        service_type: str,
        name: str,
        state_change: ServiceStateChange) -> None:
        print("Received %s MDNS event for %s", state_change, name)



zeroconf = Zeroconf()
listener = MyListener()
browser = ServiceBrowser(zeroconf, "_matter._tcp.local.", listener)
try:
    input("Press enter to exit...\n\n")
finally:
    zeroconf.close()

[midnight solstice]

Whatever the root cause is, up to 5/7 bulbs active for me in HA now.

[craggy plaza]

I do not recognize any difference. I tested a long time with IGMP Snooping enabled and now since one week it’s disabled. Nothing changed. So, it shouldn’t harm to have it enabled.

[craggy plaza]

I am also a Unifi user. mDNS and IGMP Snooping are disabled. I have a Ubuntu 22.04. in my network. avahi-utils were already Installed. I executed the avahi-browse command, but the bulbs didn’t come back. @brazen canyon

[brazen canyon]

Maybe it's Google specific or something with my network then

[ornate obsidian]

I have no idea of this is a placebo effect or not, but running @brazen canyon 's script seemed to bring back bulbs for me as well - I'm also have Unifi

[brazen canyon]

Are you on HA ?

[ornate obsidian]

Yes and Apple

Eve and Nanoleaf devices

Way too many border routers - AppleTV and HomePod

[brazen canyon]

Okay well perhaps there's multiple problems going on and you have the same problem as I did/do

[eternal hill]

Does a power cycle result in the same thing as a crash?

[brazen canyon]

You mean does a power cycle result in the device going offline?

Depends how long the bulb is off. If it's marked offline, then power is restored, it's rediscovered via mDNS.

If the bulb is off and then turned on before it's marked offline, then I'll see errors about subscription failure with a follow up resubscription succeeded (achieved without mDNS discovery)

[eternal hill]

Yeah, im thinking about turning the bulbs on and off.

Are you actually sure that the bulbs are crashing?

(There is a reboot counter in Matter, it should increase if the bulb actually "crashes" and restarts)

[brazen canyon]

How do I access this?

[eternal hill]

you can probably see it in homeassistant

[brazen canyon]

I'm reasonably sure that the bulbs are crashing since, when I pass commands to many bulbs at once, I see subscription time out errors then nodes are marked offline.

2024-02-18 10:00:57 core-matter-server matter_server.server.device_controller.[node 59][126] INFO Previous subscription failed with Error: 50, re-subscribing in 0 ms...```

[eternal hill]

idk if you need to "reinterview" the device to get that cluster updated though.

[eternal hill]

Might be that the packages just are dropped because 20 bulbs answer at the same time

[brazen canyon]

Do you know what attribute it is?

[eternal hill]

no, need to search in the spec for that 😄 i can do it later if you cant find it

[brazen canyon]

I'll have to spend some time looking later. It's the rebootcount in generaldiagnostics but I have to read through to see what the specific socket command is

[brazen canyon]

I didn't see the reboot increment but I'm also not confident it's implemented correctly. Some of the bulbs report more than 500 reboots and the counter is supposed to have reset after every hard reset, for me, that's only been 2 weeks or so for certain nodes. Hard to believe it's reboot 500+ times

[feral steeple]

@boreal surge I didnt notice this in the CHIP list, but the last couple days I have had random lights just turn to a different colour. Already on with the others in its group and then just 1 of them changes to a different colour like a white or blue. Thought I would mention it.

Any of the HA users update to OTBR 2.4.7 yet that came out a couple days ago?

[brazen canyon]

I'm up-to-date and haven't seen any new issues

[midnight solstice]

I've gone round and round with HA + OTBR + Matter Server, and I just cannot seem to get to the bottom of why my bulbs go unavailable yet work fine on the other platforms. For a brief moment yesterday, I had 7/7 available in HA. But as soon as I pointed all my automations over, they all dropped back to unavailable. None of the tricks that work for others to wake them up seem to work here.

I pulled OTBR out of the mix to simplify, and now the only bulb working in HA is the first node that was re-paired yesterday.

I cannot tell if this is a problem with NL, HA, or more fundamental problem in my ipv6 network. So I'm throwing in the towel for now, just going to live with the mostly working SmartThings integration. I have the HA version of the devices, will keep an eye on them as updates are released.

Thanks for all the suggestions yesterday; if nothing else it was a fun learning exercise!

[stark crystal]

I'm surprised SmartThings of all things works for you. Their Matter implementation is the absolute worst.

[bitter compass]

For what it's worth, I pulled OTBR out of the mix, and then rebooted my Google Homes and everything was stable after that. OTBR definitely seems to cause issues for me

(probably something to do with OTBR having Trell enabled and Google not)

[bitter compass]

For what it's worth - it's not a placebo thing. My Home Assistant crashed hard tonight. I had to reboot the VM. When it was finally all up and running, all devices except the Matter light strip came back. All my A19's came back. But the essentials light strip did not. I ran the avahi-browse -rtp _matter._tcp command on a raspberry Pi - and within 30 seconds the matter light strip came back online in HA

it's making me wonder - if I should setup a cronjob to run once an hour or maybe once every 3 or 6 hours or something, definitely at least once a day.....

[main matrix]

seems to have a better effect for some than others; I've had an A19 and a GU10 unavailable for the last 24 hours. Running the command for me from an Ubuntu VM in the same VLAN hasn't helped. The problem is, the last time this kind of issue happened for me, the lights had to be completely reset and re-paired with HA.

[bitter compass]

OK I will provide more networking layout info to see if we can determine a common pattern.

[main matrix]

FWIW, I'm using OPNSense for my router and TPLink Omada gear for the rest (EAPs, Jetstream switches etc). The Jetstreams have IGMP and MLD Snooping enabled). Also have 4 Google Hubs as Matter controllers.

[bitter compass]

I run pfSense as my router. I run PiHole and AdGuard for DNS. I run Unifi Access points. I do not have any VLANS. I have all multicast enhancements turned off on the Access points. I do not have the OTBR running. My Thread network is provided by 2 Google Hub Gen 2's

[main matrix]

Hmm, sounds similar then. I swapped from Unifi to Omada as I was having a boat load of issues with MDNS (as were others). Since the swap MDNS issues disappeared.

I do have VLANs, but all my HA gear is in a single VLAN so there's no network traversal between the other VLANs.

When I run that command, there is a load of output which seems to correlate with all the lights Avahi-browse can see, but doesn't seem to wake up the two lights that are giving me grief

[bitter compass]

if the lights are showing up in the mdns browser than it's the Home Assistant matter server that is the problem - especially if the lights DO show up in Google

[main matrix]

I'll have to double check the output against each light. I think they appear, but I did this at 4am so wasn't exactly paying too close attention 🙃

[bitter compass]

yeah - to be fair - there is nothing in the output that actually identifies WHAT it can see - just the mDNS entry. I have an app on the laptop and an app on the phone - and it's basically impossible to actually tie an entry to any particular device. I can locate my Google Hubs and my Switchbot Hub - only because they have both an IPv4 and an IPv6 address wheras the thread stuff only has IPv6 - but figuring out which thread device is which..... nope

[main matrix]

it's interesting you say that re: IPv6; I'm getting v4 entries on the lights as well as v6

at least according to avahi-browse

[bitter compass]

...but .... Thread is IPv6 exclusively.

[main matrix]

this I know 🙂

^ as an example

ah, interesting; it seems that if I look further down, the IPv4 component appears to be translating back to the Google Hubs

[bitter compass]

yeah I notice something on my end

I guess that makes sense - because it needs to speak to that IP address in order to contact the Thread network

[main matrix]

yeah

have also noticed something else; do your SAI and SII values change depending on type of light you have?

[bitter compass]

all mine appear to be 800

[main matrix]

so all A19s then?

[bitter compass]

I have a light strip too

[main matrix]

ah

I don't know enough about the data output to interpret what it means, but for me at least, I have 4 entries that are different from the rest. I have 4x GU10s in the mix, so was hoping that I could correlate the two

[bitter compass]

might be worth asking @boreal surge about that - they will better be able to answer that

is that all you have on your matter network - purely nanoleaf stuff?

[main matrix]

with the exception of two Aqara P2s, yes

I do also have a Nanoleaf light strip just haven't added back into HA yet

[bitter compass]

just wondering because I have way more entries that say 800 for both values - than I have actual lights. I've got 2 Onvis thread sockets and a blind tilt, lock, temperature and humidity exposed via Switchbot hub. And as far as I can see - everything is 800

[main matrix]

hmm, look like they might be sleep interval values

https://cookie-daily.life/src/matter/matter_html/Chapter 4. Secure Channel.html (third party I know, so take the info with a grain of salt)

Example: SII=5300 to override the initial retry interval value to 5.3 seconds.

The optional key SAI indicates the SLEEPY_ACTIVE_INTERVAL of the Node. This key MAY optionally be provided by a Node to override SED defaults. If the key is not included or invalid, the Node querying the service record SHALL use the default MRP parameter value. The SAI value is an unsigned integer with units of milliseconds and SHALL be encoded as a variable- length decimal number in ASCII encoding, omitting any leading zeros. The SAI value SHALL NOT exceed 3600000 (1 hour in milliseconds).

Example: SAI=1250 to override the active retry interval value to 1.25 seconds.```

[bitter compass]

oh so 800 is 800ms ?

[main matrix]

seems that way

[bitter compass]

thats.... chatty lol

[main matrix]

would probably need the Matter devs to confirm though

yeah, a bit

[bitter compass]

guess it's probably tiny amounts of data though

[main matrix]

true, but on larger networks it may play a factor

[bitter compass]

right time for bed lol

[brazen canyon]

The node is actually listed there in the mDNS browser, just hex encoded

The entries with all the leading zeros, that's the node id in hex

[bitter compass]

but the part that is confusing -

=;eth0;IPv4;0DAA1FA9C5C4C44E-000000007B322F7D;_matter._tcp;local;64E833E56FE0.local;192.168.2.191;5540;"T=1"

if i convert that to decimal - 2066886525 I don't have a nodeid of that. My highest node (according the matter server) is 16

[dull dagger]

I'm having random unavailable for one of my devices now. Where do type this command?

[brazen canyon]

It's a Linux command, you should be to use any mDNS browser though including one on your phone

[edgy tusk]

Do you listen to Caravan Palace?

https://open.spotify.com/track/4hB9jKT8PkbNwfJ5N9BY05?si=DmC3pciZTMOZrGLGef64yw&context=spotify%3Aalbum%3A5a9UEwUEN7LsTsRXWPOQtC

[bitter compass]

I just used a random Raspberry Pi that is just sitting being a NAS

[upbeat mica]

Any ETA for the next beta?

[humble whale]

Today is a holiday in Canada, btw — Family Day.

[boreal surge]

Very unlikely that this is a software issue without seeing the behaviour on other devices. Can you swap the troublesome bulb into another another fixture to see if the behaviour persists? (preferably one which is on another ciruit). If it still persists, DM me and we'll sort out the next steps. Thanks 🙂

[boreal surge]

This is what I've come to think of as the "Thread Gaslighting Effect".

[boreal surge]

Yes, this doesn't fit neatly into open issues which we're tracking from beta. Would you mind capturing details and any reproducibility steps in a bug report (as possible)?

[boreal surge]

We ran our automated QA suite over the weekend on a release candidate which includes Matter 1.2 and fixes from the nastier reported issues here. We're still chasing down a couple of deal-breaker issues before we release to you folks. Knock on wood, this week. We're trying to avoid reliability regressions, of course 🙂

[dull dagger]

FYI. 136 started really well, but now, after about 1 week, lights are dropping for hours and rejoining again. thanks

[bitter compass]

I see a blog about getting diagnostics for reachbility issues - but it looks like that only applies if the device is actually connected to Thread in the first place? One of my A19 bulbs has fallen off thread today and is only reachable on Bluetooth. It's been fine on Thread for over a week so it's definitely not a signal issue. I would like to get diagnostics for you - but I really the light to work so I will have to power cycle it I'm afraid. (I really wish the app had a reboot button for lights lol)

[shell vigil]

Agree it’s actually worst after a while. My observations.

1- more lights are flickering than before, nearly half of my 35 bulbs
2- the flickering lights are giving very wrong colors much more in previous betas, example I choose violet it gives green.
3- started 2 days ago,
A-one of the flickering bulbs decide to turn on by itself
B- the bulb is connected to thread and can be controlled but no reaction . Example: the color is stuck on blue , connected to thread , shows off when you turn off in the NL and Apple Home apps but meanwhile while it’s showing off in reality it is still on and blue. Whatever setting chosen there is no reaction.
4- bulbs reaction to commends are slow. With scenes it takes a while to react and act.

[midnight solstice]

Now that I’ve moved on from trying to get my NL bulbs to work in HA, I noticed something that might amount to a clue. Maybe you all know this already, and I’ve just not seen it discussed… apologies if that is the case. And of course this is likely only one of many active problem scenarios…

Some of the bulbs that seem to be working fine in HomeKit and SmartThings are actually showing signs of distress.

In Flame, when everything is healthy, I see 5 service advertisements for each bulb:

1 x _ltpdu._udp.
4 x _matter._tcp.

I assume the 4 Matter advertisements correspond to each paired Matter platform: NanoLeaf, HomeKit, SmartThings, and HomeAssistant.

Right now, I have 3/7 bulbs only reporting a single advertisement for _ltpdu._udp. in Flame.

I noticed this last night, and it took multiple power cycles to wake them up and advertise everything that they should.

I’m starting to suspect that the bulbs that go unavailable over time is because of the missing advertisements that eventually age out of the services cache on the various matter controllers…

It seems to be the case that even though the problem bulbs no longer actively advertise as a matter service, they continue to respond to commands normally if a matter controller has them cached.

Anybody else notice this behavior with the bulbs that are misbehaving?

[brazen canyon]

ltpdu would only impact the NL app behavior

[midnight solstice]

Yes, I get that. But that’s the ONLY advertisement showing up for bulbs that I can still control via Matter in HomeKit and SmartThings.

[eternal hill]

I have taken out my main fuse, so my thread network was offline when the bulbs became online. Since the restart some of my bulbs won’t connect to my thread network anymore (it’s been 2 days now). It’s eu GU10 bulbs. I powercycled 2 of them and they instantly became available in Apple home and HomeAssistant again.

Also when pairing one gu10 bulb to Apple home the Color suddenly changed with no apparent reason.

And some of my bulbs still go into disco mode when being turned on and off (2 out of 5 bulbs or sth when changing all at the same time in HomeAssistant). Idk if that’s an HomeAssistant issue though.

I also love that I put Shellies in front of my Nanoleaf bulbs in case they need to be powercycled. Now both my Nanoleaf bulbs and the Shelly in one of my rooms have crashed 😂😂

[brazen canyon]

Can you elaborate? Don't think I have that issue

[eternal hill]

They change colors really fast

And have another one than the rest

And I think it’s always the same

It has not always been like this

[brazen canyon]

What do you mean by on and off? Current or in app?

[eternal hill]

In HomeAssistant

When I turn then on

And also off

[brazen canyon]

Oh okay mine don't do that fortunately

[eternal hill]

I can take a video later

Maybe the bulbs are broken or sth

[brazen canyon]

I had an issue with some popping on all the time and a re-pair fixed that. Now they just pop in in the morning. Who knows.

Could be related to the EU flickering problem

[eternal hill]

Now I tried to film it and it’s stopped happening 😂

[shell vigil]

There you go on your behalf

Is this what is happening to yours ?

This is controlling group of 3 bulbs

They should have the same color when on it they have different ones and they actually sometimes turn off when I turn them on

[eternal hill]

Yea

Mine don’t always

But maybe this is actually an HomeAssistant issue?

Is this Apple home or HomeAssistant?

[shell vigil]

Mine always, there is a way to fix it for some times but eventually if you turn them off and on multiple times they will do that again

[shell vigil]

I control via Apple home and same issue with NL

[eternal hill]

Have you grouped them?

I think grouping should use 1 multicast “command”

[shell vigil]

Yes

[shell vigil]

I did

But even if I control 1 alone it will make the same@

My observation with the flickering is when the cold white led is controlled there is this issue that pops up

Sometimes it fixes when you try to change all white spectre in Apple home then it works well for a while but then after a while it flickers

[main matrix]

Certainly do.

[boreal surge]

I'm organizing an upcoming hardware beta for something we've been working on, anyone interested in fiddling about with it? Includes an integrated PIR sensor and some other goodies. You can sign up here : https://research.nanoleaf.me/beta-program-signup/?referral-code=CHIP0001

[plain kettle]

is it the Sense+ control thingy that was announced a few years ago?

[boreal surge]

It's the first device in Sense+ to be hitting primetime, yes. There are quite a few in the pipeline.

[frozen crystal]

Great. I had been waiting for this to come around!

[brazen canyon]

Can you comment if these are hard wired or not? When the announcement came out it CES it looked like there was a hardwired variant and a remote variant

[quiet sky]

Fix the essential light bulbs first before introducing new products. Connectivity is terrible!

[plain kettle]

Dude, not everyone works on the same product?

[quiet sky]

This group is about software beta and not hardware beta, so whats your point??

[plain kettle]

He is posting it here because many of us have experience in debugging devices, and clearly wants some of us to try it out (as many of us have a ton of edge cases Nanoleaf can’t hit in QA testing)

They are doing their best

[quiet sky]

I believe they are doing their best, but they need to try harder. Their software is really terrible. Thats not what i paid for. My previous lights from Tuya were always connecting. Never had any issues with them for five years. The essentials lights are totally unreliable.

[plain kettle]

Tuya is wifi bud, this is matter over thread, a spec that is just over a year old

You clearly fail to understand the fundamentals of this device compared to others, and it shows.

If you are really dissatisfied with the device, just return them? Otherwise stay on the beta firmware and wait for a new release

[quiet sky]

So?? Why release products that are not functional?

[plain kettle]

It was functional when it was HomeKit over thread

[quiet sky]

What are the fundamentals of this product then? Enlight me?

[plain kettle]

It’s using a spec that was only released a year and a bit ago, and SOC makers are still trying to get their implementations up to scratch.

Eve systems, who use Nordic has issues for 6+ months after release and only recently have been better

If you have such an issue, return your device. It’s that simple

[high atlas]

poshy___ has been warned

Reason: Bad word usage

[plain kettle]

These devs have (recently) been nothing but supportive of everyone debugging these devices and trying to catch the root of the issue

[steel hemlock]

I am watching the same behavior. The stability is decreasing again, unfortunately.

[brazen canyon]

@steel hemlock @shell vigil make sure to put that in the daily poll as I'm sure they want to know about it

[brazen canyon]

Similar to @bitter compass I had a bulb fall of thread and not reconnect. It's no longer broadcasting mDNS for either matter or ltpdu

[bitter compass]

Did a 30 second power cycle bring it back? Mine did. Both Google and Home Assistant picked it up immediately when it came back online, so Home Assistant's recent change for monitoring mDNS seems to be working well.

[brazen canyon]

Yes but its part of a light fixture and now the other light is stuck offline 😅

[shell vigil]

I already mentioned about this since day 1 🙂

[boreal surge]

This is the wireless variant (remote).

[boreal surge]

I can appreciate your frustration, trust me. No one sets out to design and release products which behave this unpredictably... lighting should be simple, and just work. That's what running a beta like this with input from customers is for, to try and identify/fix problems and improve the overall experience for folks now and in the future ones. For us, choosing to get on board with new technologies (Matter and Thread) is a double-edged blade. The new innovations can lead to convenience, efficiency, and enjoyment which aren't possible with mature technologies... but it's sometimes a real bumpy road getting there. This road's bumpy, but we're still driving it.

It'd be mighty helpful if you can catalogue unexpected behaviour and submit a bug report (https://research.nanoleaf.me/upcoming-quests/chip0001-3-xx-thread-beta-software/ - pw CHIP0001). I'm happy to chat with you over Zoom or similiar if you'd like to vent a bit, or talk about specific product challenges that you're running into. Just DM me and we can set something up.

[quiet sky]

Thanks for the response Paul. I appreciate it! Maybe we could chat over Zoom. I will DM you!

[boreal surge]

I'd like that 🙂 it's nice to chat in person, and I definitely want to hear about your experiences (I know they're not positive, but we can't improve without understanding the pain).

[quiet sky]

True. There is some frustrating from my side, but would like to have a chat and hopefully improve things 🙂

[boreal surge]

Great, DM and we'll pick out a time that works best for you. I'm in Toronto (eastern time, UTC-5) but don't mind chatting earlier in the morning or evening.

[lime willow]

Bit of a weird experience with my two lightstrips this past week.

Both on .136 since release. They started off working perfectly, then after about a week both appeared as needing to be “Setup” in the NL app (but still worked perfectly in Apple Home). Then yesterday one became 100% unresponsive; it wouldn’t power on even with the physical buttons. I had to unplug it from power for a few seconds to get it to come back to life, but still no control over HK or NL app. I had to factory reset it.

After factory reset, it’s back to working perfectly.

[midnight solstice]

Glad this is not just me! I have 4 BR30’s on a light switch and there is always 1 that does not power up correctly!

[stark crystal]

We are all curious what wireless protocol would be used for it... Also if it can control a light directly (Matter Binding).

[shell vigil]

Hey everyone, I have one bulb gu10, it’s getting stuck each day into 1 color and I can’t control it anymore until I cut the power from it. Is this happening to any of you ?

[dull dagger]

hey, any plans for getting the 4D to act as a thread border router? thanks

[daring marsh]

Any idea when the latest stable a19 will come out of beta?

[plain kettle]

Thanks @boreal surge for accepting most of us here into the hardware program, your gonna get some good debugging help 😛

[verbal drift]

What an excellent offer and support. Thanks Paul

[boreal surge]

Interesting, that's not something that I've run into before. If the issue crops up again, would you mind capturing any notes or reproduceability steps that you can and fill out a bug report? https://research.nanoleaf.me/upcoming-quests/chip0001-3-xx-thread-beta-software/ ( pw - CHIP0001 )

[boreal surge]

For the purposes of this beta with the preproduction hardware we're sending out, it's communication over Thread and no support for Matter Binding. Final specs are still being settled—with input from the beta, of course 🙂

[stark crystal]

Interesting. I actually don't know of any device that supports Matter Binding today.

[grand pilot]

https://help.inovelli.com/en/articles/8705901-white-series-2-1-switch-manualbil

Inovelli does but they say no hubs currently support it

[main matrix]

Eve's upcoming Thermo Control is also meant to support Matter Binding as well.

But alas, not currently available.

[eternal hill]

Why are not Matter binding available? Because of the limitations of fx Google Homes current api and so on?

Also does nanoleaf need to recertify every update with the CSA? (besides the beta ones)

[craggy plaza]

Is it Matter over Thread or proprietary Nanoleaf over Thread?

[boreal surge]

Great questions 🙂 let's hold on to them for the private beta channel that will be opened for the other beta, so that the folks in this channel who aren't that interested are spared the chatter.

[stark crystal]

I'm sad I didn't get in the hardware beta but I understand.

[brazen canyon]

@boreal surge another question relating to the beta, are you going to continue to solicit other HW betas here? I have no interest/use case for the remote but would be interested in helping on the wall switches for example

[craggy plaza]

Even though I have use cases for the remote, I also need the wall switches. 😃

[boreal surge]

By chance, did you fill out this form yet to indicate interest? https://research.nanoleaf.me/beta-program-signup/?referral-code=CHIP0001

If so, DM me your email address—the submission may have been caught erroneously by a spam filter. Everyone participating in this beta (CHIP0001) meets the requirements we have for the button beta and I think would be a great fit for it—so anyone here who's interested is most welcome.

The only folks that we can't accept for the button beta right now are those who live in South America, the Middle East, or Africa (simply because we don't have hardware certifications for those regions yet, meaning we can't export devices to them which will be allowed through customs).

[boreal surge]

Awesome. I'll post in Discord channels occasionally about upcoming betas, but I'd suggest "signing up" here : https://research.nanoleaf.me/beta-program-signup/

We're starting to build out the capabilities needed to run much larger beta initiatives over time (hundreds to thousands of concurrent testers in some cases). Eventually, we'll begin to create segments of test candidates based on this information which match a proposed beta, and send them invitations by email. The signup form itself collects very little PII, we're mostly looking at geography, devices, and network characteristics at this early stage.

[brazen canyon]

So you'd suggest signing up here even if we wouldn't be interested in testing all potential products? (Not sure how it's divided up behind the scenes who tests what)

[boreal surge]

Yup, I'd suggest signing up there—think of it like filling out a profile. When there are matches between the profile of a tester and the requirements of a beta, an email invitation will be sent out. If you're not interested in that particular beta (hardware or software), it's OK not to accept the invitation. We won't be putting in place acceptance metrics or anything like that to determine which testers are invited to betas.

If I recall, there's also a question in the signup that asks generally what type of things you're interested in (hardware, software, UX research, etc).

[eternal hill]

Is there a way to update your choices?