Software Beta for Nanoleaf Essentials Matter

[boreal surge]

Yes, eventually. The only way now though is to submit the form again, and I'll scrap the older submission (sorry!).

[brazen canyon]

@boreal surge any outlook on the matter 1.2 FW to test over the weekend 👀 🙏

Although I'll say the current one is fairly stable as is

[boreal surge]

We're getting very close. I don't want to pull bad juju in and totally jinx it by saying yes... but we're getting very close 🙂

[feral steeple]

Ill see if there are any logs i can grab when it happens next.

[feral steeple]

@boreal surge Not sure what I can provide you on this to log a bug, but 5 out of 8 lights in my kitchen area are currently online. Went in there and it triggered turning them on, the 5 ones responding all turned on, then 4 of them just flashed out to black and giving no light.
They are still reporting as turned on in both Home Assistant and the nanoleaf app and say they are on at like 50% brightness, but definitely not on. Turn off and repeat and the 5 that are not unavailable turned on as normal.
No logs in HA that seems to indicate they reported back that it failed or anything.
/shurgs. but hopefully something useful?

Also on the light randomly changing colour. From the home assistant side, it just has the turn on and set colour same as all the other lights, it seems the bulb itself has decided to change colour so there is nothing on my logs that indicate much here. I have turned debugging on to see if it gives me anything more, but suspect its happening locally and I wont be able to see anything

[shell vigil]

Same

[vital stump]

Fwiw I had nanoleaf go back and forth for a couple weeks with 3 days between replies and my return window closed, meaning I can no longer return, which is why I’m here. It worked fine the first few weeks then had severe problems. I have since encouraged others having problems to not use support but return the bulbs immediately if they have any issues. It’s been a subpar user experience which is a bummer because when they do work they’re great bulbs. I think it’s okay to admit that things are in a tough spot but also that they’re working to fix them. They are certainly not fixed or a reasonably good product at the moment, especially on the release firmware. It’s also a bit of a bummer for people who have a substantial investment in light bulbs to have a frustrating experience and be a bit disappointed the company isn’t putting, in their opinion, enough resources in to fixing the existing product, while also spending resources in new products. It feels a bit dismissive. I also understand it’s a good sized company with many departments, and it’s not all hands on deck to fix a $13 light bulb.

There’s a wide range of reasons to be upset or frustrated, your dismissive tone isn’t particularly helpful. I also agree to remember the developers are here and also human, so to try to be concise and useful in the frustration.

[main matrix]

You can't please everyone, unfortunately. I agree with @plain kettle's stance that if it doesn't work, return it and move on. A decent chunk of us are willing to persist with the bugs and assist where possible (gluttons for punishment, if you will), without getting into any politics of whether these issues could have been handled better (there's always room for improvement).

Getting frustrated over something like a $13 light bulb isn't worth it for most people and the sane thing to do would be to get your money back and move on.

[vital stump]

Agree except the canned responses from support over the course of weeks means you can’t return it once the window closes. We should encourage more people to return the bulbs.

[plain kettle]

sorry what? are you american by chance?

the rest of the world has really good consumer law when it comes to defective products

[vital stump]

Amazon has a 30 day window in the US

[plain kettle]

its not hard to skirt the rules and call it defective

[vital stump]

That’s a really terrible policy.

And definitely leads to unhappy users and brand recognition

[plain kettle]

they know that, why do you think we are here, and nanoleaf are trying their best

the subreddit is full of hate about this

[shell vigil]

I agree with TD on se points.

If the customer service is transparent with what is happening

And sharing with the customers reaching them with complains about the real issue

[vital stump]

I agree they are and I think it’s great they are. It’s disappointing that the recommendation is “try to lie and get your money back”

I’m hopeful in the next version or two that it’s a viable product.

[shell vigil]

The overall frustration globally would be much less and customers would tolerate the company

And would not return the products

Most of the would wait

But honestly I have reached personally to the support and they have some horrible answers that even frustrates me more

[vital stump]

Just put a one liner on Amazon stating “this is cutting edge tech and we’re excited to be pioneers! We’re excited you’re joining us for the ride, even if the software is a bit bumpy for a bit!”

[shell vigil]

1- sending templates of answers
2- sorry for that try to turn off and on your device

3- try resetting

Bla bla bla , instead sharing that we are aware of this issue and working on solving it,

On the same time the whole product team is working on solving the issue in here which is fantastic move from their side. I really think the cuskmter service should change the strategy

And the company should actually write a blog and statement that these are buggy and we apologise for this ( like press release)

[vital stump]

If the reply was to join this chat I would have liked the product more! It’s cool to see the iterations of improvement.

[plain kettle]

This isnt "offical" per say

[main matrix]

That would be more problematic, as that would read "here, join a chat where you bulbs may act worse than they already do". It's beta testing for a reason.

[vital stump]

“We are aware of this bug, however it’s fixed in the beta software but may also have new issues. If you join this chat on discord it may be useful, otherwise it will be 30-45 days before we release our next firmware update which we believe will fix these issues”

[plain kettle]

and risk bricking the device?

dude, a few weeks ago they had no idea where the root of the issue was

[vital stump]

I’ve told multiple friends to buy Phillips at the moment because of the state of the Nanoleaf bulb. Not sure the current position is making them more money. Regardless I’m not a product manager for Nanoleaf so it’s their call in the end.

[plain kettle]

not long ago we were having to test if voltage fluctuation were the root cause in it.

No its not, but they are working on it?

[vital stump]

Would have preferred to know that before I bought them. Lesson learned 🙂 fingers crossed they get it straightened out.

[plain kettle]

well, you live and you learn, its not hard these days to get a refund/return of an item though retailers like amazon

[vital stump]

It is. They already said no.

[plain kettle]

well, sucks to be living in america then 🙃

[vital stump]

Cool 👍 I’m sure that will help their product.

[plain kettle]

No it wont. but it is a solution to who's devices are not reliable, and need a fix

[eternal hill]

have you tried the latest beta firmware or are you still on the "normal" releases?

I think for most people the latest beta is a big improvement.

[feral steeple]

Any updates when we may get the next beta?

[brazen canyon]

#1184371187464290344 message

[feral steeple]

Thanks, My discord seems to struggle with putting me back to where I was up to reading (or im using discord wrong) Completed missed that post

[brazen canyon]

No 1.2 today I guess 😔

[shell vigil]

😦

[midnight solstice]

Question for the Unifi guys: my ISP does not support ipv6, wondering if this is why I'm having trouble. I previously had my IOT network configured like this:

Interface Type: Static

IPv6 Address
fd00:11::
Netmask
64

Gateway IP/Subnet
fd00:11::/64

SLAAC
DNS: Auto
RA: On
RA Priority: High

Right now, I have:

Interface Type: None

is this a factor in the "special" problems I am having?

[plain kettle]

You should have a local link address

[midnight solstice]

right now, I don't have anything configure in Unifi

[plain kettle]

Does your PC/laptop get a local link address when connected to the network?

[midnight solstice]

yes, the PC I'm on gets
Link-local IPv6 Address . . . . . : fe80::d507: ...

[plain kettle]

And what ecosystem are you using? Apple home or home assistant?

[midnight solstice]

HA gets a couple of addresses:
IP Address: fd70:a255: ... /64, fe80::a0ec: ... /64

HomeKit, HA, SmartThings

[plain kettle]

You got mDNS turned on in the settings?

Network settings of UniFi

[midnight solstice]

mDNS and IGMP Snooping are disabled

[plain kettle]

Dude. You need mDNS

that is how matter works

And thread

Lmao

[midnight solstice]

everything is local on the subnet

everything I read says turn that stuff off on Unifi

don't want it going across subnets

[plain kettle]

Oh god

[brazen canyon]

This isn't right

[midnight solstice]

what am I missing?

[plain kettle]

Wait are you doing intervlan?

[plain kettle]

Hmmm?

[midnight solstice]

HA, HomeKit BR's, NL, all on the same subnet

[plain kettle]

Your phone you are commissioning with?

[midnight solstice]

iPhone is also on that subnet

[brazen canyon]

IGMP snooping off
MDNS enhancement off
IpV6 needs to be enabled (there's a check box for ipv6 support or something similar)

Also all BR and matter same VLAN

[midnight solstice]

this is the guide I've been referencing; is this misinformation?
https://www.derekseaman.com/2023/10/part-3-smart-home-matter-and-thread-deep-dive.html

[plain kettle]

Ah yeah that one

[midnight solstice]

MDNS Enhancement, that's a setting on Wifi, not Networks. That is off as well.

I'm intrigued by the reaction from Poshy /wrt mDNS. I know it is required, but it is a broadcast on the subnet. Why does unifi need to have mDNS enabled? I was following the advice of that blog, is that really something I should change?

Oh, I see, Adequate-Spectre was agreeing it should be off.

[plain kettle]

Mdns in network settings is on or off?

[brazen canyon]

There's no mDNS on/off, BUT there are mDNS enhancement settings and all those need to be off

[brazen canyon]

This looks good

[brazen canyon]

Yes

[midnight solstice]

Ok back to my original question, my Cable ISP doesn't support IPv6 for whatever silly reason. My options are limited here.

I've seen some discussion about SLAAC and Router Advertisements being relevant this to work correctly. Is this a problem the way I have it configured?

[plain kettle]

I swear that multicast DNS setting in the global network settings is meant to be on, yeah right

[brazen canyon]

SLAAC and whatnot is only relevant if you have actual ipv6 from isp

[plain kettle]

Ah wait, network MDNS is across networks, not on/off

[vital stump]

Currently on latest beta, it’s better but at any given point in time about 20% of my bulbs don’t respond.

[plain kettle]

I guess it can’t hurt to have it on?

[vital stump]

As mentioned before you’ll still have link local addressing should start with FE80::

May not be visible on your phone.

[brazen canyon]

I just double checked, mine's off (mobile UI and desktop UI are different)

[midnight solstice]

Ok thanks for the confirmation. I'm still at a loss why my HA refuses to work with my matter bulbs with the latest updates.

[plain kettle]

Yeah right, the more you know

[brazen canyon]

I think multicast DNS is related to vlans in this context somehow

it mentions "dns across multiple networks" in the tooltip

if you don't have ipv6 i would set the network interface to none for the network then

[plain kettle]

Thing is that should still allow a local link address

[vital stump]

The host should assign it without any interaction with the network

[plain kettle]

Yeah

[vital stump]

If you have two devices you should be able to ping6 between them

[brazen canyon]

I had issues with HA getting the correct ipv6 when ipv6 was enabled (like from my ISP) so turning it off should potentially avoid that headache

[midnight solstice]

Yes, that's what I have. Prefix Delegation isn't available since I don't have it on my WAN, and I was previously doing Static (maybe 2 weeks ago when HA's Matter Server 5.1 blew up my config).

yeah everything is getting LLA's

Static introduces ULA's, which would never work for any of this stuff anyway, so simpler is better

[plain kettle]

You on the newest matter server update for HA?

[midnight solstice]

yeah I installed 5.2.0 earlier, no change

well thanks for the Unifi config audit

[plain kettle]

Have you only got HA? No other ecosystem?

[midnight solstice]

I have HA, HomeKit, and SmartThings

[plain kettle]

And you shared the pairing code? Not scanned the code on the device?

[midnight solstice]

Initially paired with HomeKit using the NL code, then paired using codes from HomeKit for ST and HA. That was painful especially with SmartThings.

[plain kettle]

Yeah right, so the device is currently paired with HomeKit?

[midnight solstice]

yes

[manic plover]

On Unifi, try disabling IPv6. Yes, I know Matter works on IPv6, but just give it a shot - disable it in both network and internet settings and power cycle all your devices, including border routers.

[plain kettle]

Hmm, that proves it’s not a network issue

[midnight solstice]

interesting suggestion; is that how you're setup?

[manic plover]

Yes. I've been battling it for days and this is what solved my issue. Nothing else worked.

[midnight solstice]

I will give it a whirl and report back; thanks for the idea!

[midnight solstice]

Well IPv6 is disabled, everything got a power cycle, bulbs included. Right now, 5/7 are alive in HA, we shall see if they stay that way, and perhaps the last 2 wake up.

[brazen canyon]

That one won't wake up since it's not in the fabric anymore

[midnight solstice]

after HA restart, they all look like that for a while

what do we do if a device is in that state? this is basically what I've been seeing all along. they seem to randomly come and go based on restarts or power cycles.

[brazen canyon]

You shouldn't need to keep rebooting your matter server under normal circumstances. If you see this and you've power cycles you'll have to re-pair the bulb, although this behavior shouldn't happen

A bulb being unavailable isn't the same as a missing node (what you're seeing)

[verbal drift]

Morning!! Got up to this, these are all matter devices, no reason for them to be off. Must of have happened overnight

[plain kettle]

rebooted all your home hubs?

[verbal drift]

Nope, do I need to do that (I know I shouldn’t need to) ?

[plain kettle]

try it maybe? might bring them back online? or even the devices itself

[verbal drift]

I have found power cycling for 10 secs or more brings them back

[ornate obsidian]

With the latest HA Matter update, this is the first morning (ever) I've woken up to all my bulbs in HA available (and appearing to have been available overnight) which is awesome. Weirdly, one bulb which is controllable in HA, is unavailable in HomeKit (which hasn't happened before)

[bitter compass]

Ditto - latest matter server update won't see ANY nanoleaf light

(onvis sockets still shows up without issues, and everything exposed through the switchbot hub 2 still shows up)

rebooting both Google Homes again. Because there is stuff offline in there too, and although the essentials strip says it is online in Google the state of it is not correct

[brazen canyon]

Sounds like a different issue outside of HA

[bitter compass]

They have all come back - but it took about an hour for all of them. It's definitely a HA issue because they all popped up back in Google again pretty much immediately after the hubs rebooted. But the matter server is FULL of errors about CASE subscription errors and timeouts. It will say it discovered a node via mDNS and then all it's attempts to subscribe timeout.

[brazen canyon]

There's several people that tested the latest and found it worked fine. Could be an issue pertaining to multi admin with Google home as I think most use apple home

[craggy plaza]

My 48 Matter over Thread (16 Nanoleafs bulbs, 32 EVE devices) devices are still all available in Home Assistant and Apple Home since the last HA Matter server update. But I saw a lot of re-meshing. After 2 or 3 hours my Thread network starts to re-mesh lately. I didn’t have that issue before the last HA Matter server update. After such a re-mesh procedure Apple Home and Home Assistant always find all devices and everything is back online after maybe 10 minutes. But the re-meshing starts every 2 or 3 hours. This is not very stable at the moment. Not only Nanoleaf re-meshes, also EVE devices are involved. I also connected two more Nanoleaf bulbs after the HA Matter server update in the middle of the house and in the middle of the Thread mesh network. I removed them again. Maybe these two bulbs are the problem. I will report back here in the evening. We still need bulbs that do not crash every now and then. I think that is the reason for the re-meshing.

[bitter compass]

Ah, realised OTBR had started running again - so have stopped that running, my thread network is always much more unstable when OTBR is involved (which is something the devs mentioned in one of their previous streams. OTBR is OK on it's own, but is not recommended when there are other border routers)

[brazen canyon]

I think at some point we should make a concentrated effort to document the OTBR issues cause I have two and it runs fine for me

I'm sure the devs could knock it out if we could ever narrow it down 🧐

[bitter compass]

Are you running OTBR with other routers though?

[brazen canyon]

Yep. I'm running 2 OTBRs (one HA, one espressif), 2 Google BRs and 1 NL BR

[bitter compass]

And did you join the OTBRs to the Google network?

[brazen canyon]

Yeah

[brazen canyon]

Guess my house faces a different direction than yours

[verbal drift]

Power cycling the lamps made little difference. So the answer was to reboot all my Apple HomePods

[midnight solstice]

Quick update on my tale of woe; after wasting way too much time with network and HA troubleshooting, I finally went scorched earth with the NL bulbs with factory reset.

Re-paired each of my BR30's and A19's methodically via the latest GA NL app, each bulb was already on firmware 3.6.136. After connection in NL app, I followed the prompt to connect to HomeKit. After everything was confirmed good in HomeKit, each bulb was paired to Home Assistant (using Apple's Home app and Home Assistant companion app on iOS).

The experience in the NL app is MUCH improved, and went without a hitch for me this time through.

Been over 48 hours for at least one of the bulbs, and everything is stable and responsive so far. HA history shows no time period where a bulb has gone unavailable.

[wild oracle]

any Home Assistant users know if HA uses matter toggle to do basic control of lighting devices? or perhaps in automations?

[boreal surge]

Interesting. Did this behaviour persist beyond the one time? If so, can you send in a bug report with the relevant details? This sounds like an issue that was previously unknown. It's also possible that the build with Matter 1.2 we're releasing to testers this week will help (build v 3.6.151 is undergoing internal QC before we release to you folks).

[boreal surge]

Do you have a ticket number / case number that I can take to the team lead for a conversation? This isn't the type of experience that we want for the community, please accept my apologies.

[eternal hill]

https://github.com/home-assistant/core/blob/4624c859e152fa0f04e5805f0e5dd2c1c943ab6a/homeassistant/components/matter/light.py#L254

Does not seem like toggle is used anywhere.

[vital stump]

One I opened never actually heard back on thus no ticket number. (Figured it out myself later that you have to add to apple home first rather than nanoleaf software first)

Second time I contacted support I got ticket number 29309

Appreciate the follow up on this and the desire to make the experience better 🙂

[boreal surge]

Thank you! Appreciate you bringing it up. There are always things that we can improve on, I'll chat with our team about this later today.

[dull dagger]

hi, any plans to make the 4D a thread border router?

[manic plover]

Hey @boreal surge, I've been wondering, do you have an "update queue" feature somewhere on your roadmap? For those of us with a high number of devices it can take hours to update everything, even in an ideal scenario where all updates succeed.

[boreal surge]

Hiya! As a matter of fact, this is on our roadmap now. Don't have a timeline yet, but sometime in the next couple of months I'd guess.

[manic plover]

Not sure if possible, but lifting the limit of 3 devices at a time would also be a good alternative, or even both! 😊

[boreal surge]

Yeah the three device thing is a hassle, but there's a technical dependency that we have to kowtow to. So, we'll just create a sequential queue in the UI so it's not a pain in the butt for y'all 🙂

[brazen canyon]

I can't even get 1 at a time reliably so

[manic plover]

I promise to buy more bulbs when this lands 🎉 Feel free to quote me in the spot bonus for engineers implementing it ❤️

[boreal surge]

They'll love that lol

[feral steeple]

Yes it has occurred a few times. Have not been able to consistently replicate it. I think it may happen more often if they get turned on shortly after being turned off

[boreal surge]

OK, thanks. Anything that you can provide in a bug report will be useful. When we release the next build to beta, let me know if you still observe the issue after updating. Should be soon.

[wild oracle]

3.6.152 Beta Release Notes

#1184371187464290344 Thanks for your patience, devoted beta testers. This build brings Matter 1.2, which more importantly has some key reliability fixes we inherit. Please keep us posted if you observe any devices becoming unreachable in Matter. We've held off releasing for NL65 (Downlight) as we need to run a few more tests.

We believe we've also solved the random turn on issue in this build based on our test environments (no partner tradeoffs either). Please let us know if you see otherwise.

We continue to track the GU10 flickering issue, which has been difficult for us to reliably reproduce in our test beds.

[plain kettle]

What is the current beta for the downlights? Just curious as mine is sitting at 3.5.45 on the beta (don’t think in gave the S/N for the alpha/testing)

[swift phoenix]

Woah… these lights are more snappy now. I have never seen them react this fast 🥹

https://tenor.com/view/fast-car-gif-22098603

[slow wedge]

Nanoleaf these beta updates changed my life. im considering buying more nanoleaf now. thank you nanoleaf.

[swift phoenix]

I am noticing a very slow time to reconnect to Home assistant or the lights not reconnecting at all. But the response is fast when they are on

2024-02-27 00:33:23 core-matter-server chip.native.DMG[226] CHIP_ERROR Time out! failed to receive report data from Exchange: 6928i

2024-02-27 00:31:20 core-matter-server chip.native.DMG[226] CHIP_ERROR Failed to establish CASE for re-subscription with error 'src/protocols/secure_channel/CASESession.cpp:553: CHIP Error 0x00000032: Timeout'

[wind finch]

I guess that’s due to Bluetooth. Ideally, the updates should be delivered via thread and AppleHome /matter OTA like Eve does, so that I don’t need to walk around my house for 45 mins standing pointlessly at each location, updating lights. 😜

[plain kettle]

*via the matter OTA spec, but i guess they also update their own stack, which i dont think can be done through it

[wind finch]

I had the same for one of my lights directly after the update, wasn’t responding in HA or Apple Home.
I just turned the light on via the Nanoleaf app and it immediately came back to life in both HA and AppleHome.

My other 13 devices (lightstrips, e27’s gu10’s) all went through without any issues, and appeared just fine after the update.

[eternal hill]

i think it can. But then it just works for fx apple home. Also im pretty sure that it probably is a bit more complicated to release beta updates through it.

[upbeat mica]

After updating to 3.6.152, I factory reset all 8 of my GU10 bulbs and set them up again. I think there’s slight improvement. Right now “only” 3 out of 8 bulbs are having issues (flickering/incorrect color/won’t dim or brighten). It’s always the same 3 that are the worst offenders though so idk if it also could be some hardware issue? Other bulbs are not perfect, but are at least somewhat reliable. Also, the “identify” function in Apple Home when setting up the bulbs is broken on this beta.

[worthy grove]

Updating all of my 16 bulbs (15x GU10, 1x E27) to 3.6.152 went smoothly. All bulbs reconnected back to thread without problems. The on/off dimming is faster, which is really nice. Switching a group of 8 bulbs is also now noticeable faster and consistent. 👍

[brazen canyon]

There really needs to be some effort put into improving the update process, it takes forever for me

My workflow is probably different in that I don't keep bulbs stored in the NL app on a day-to-day basis and I only add them when I need to update

[brazen canyon]

@bitter compass you have a pixel right? Do you have these issues?

[bitter compass]

I have a pixel yes, but I didn't know there was a beta update until right now - let me go and install

I'm only updating one at a time this tme though to give the mesh time to recover between each light rebooting

OK so the essentials light strip went all the way to 100% but the strip did not reboot and the app still says it needs updating.....

[brazen canyon]

I had own strip that did update but required repairing

[bitter compass]

trying an A19

[main matrix]

Seems for me for whatever reason, this beta update has been anything but smooth; Most of my lights updated (went from 3.6.136 to 3.6.152). All bar two (of 25) updated. After that it went downhill.

GH won't interact with ~70% of the lights, HA is behaving similar but can see some globes GH cannot, and vica versa. Host server, VM and GHubs have been rebooted upteenth times, all lights have been offlined at the switch for over an hour, and thus far only 4 A19s and 4 GU10s are functional in the last 5 hours (the rest have disappeared to Narnia). Not overly chuffed, but I'll persevere.

[bitter compass]

Had to power cycle the essentials strip to get it to accept the update. But all devices are back online, and re-appeared in Home Assistant within 30 seconds of being updated. The Nanoleaf app is a bit odd though as even though lights were back online in Home Assistant - the app was claiming the lights were only reachable by Bluetooth and refused to admit that they were back on Thread. The app took about 5 minutes to accept that the lights were now back on the Thread network - EVEN the thread network page only showed the border routers no matter how many times I clicked refresh. @boreal surge

[ornate obsidian]

All my Nanoleaf devices came back immediately in Apple Home and HA - so far so good - no dropoffs

[craggy plaza]

I also had issues with updating 4 of my 16 paired bulbs. But the update mostly worked, after a second or third try. Except one bulb didn’t do anything. I had to reset that bulb to factory defaults. After that I could update the bulb.

Then I was in the situation, that all bulbs were available in Apple Home and all but one bulb were available in Home Assistant. No re-meshing. Power cycling the one unavailable bulb didn’t work. I waited one hour. But it didn’t come back. Besides a lot of bulbs were available, but they didn’t react or it took a lot of time (more than 30 seconds).

So, I decided to reboot my 7 Apple Thread Border Routers. When all devices were back online in Apple Home, I rebooted my dedicated Home Assistant machine (HA Yellow). But 8 of my 16 bulbs didn’t come back by themselves. I waited two hours. So, I am now power cycling these bulbs one after the other and they come back to Apple Home and Home Assistant.

The bulbs that are already available are really snappy and switching them on/off is awesome fast.

After rebooting my Apple Thread Border Routers and my HA Yellow my 32 EVE Matter over Thread devices became available on its own. No power cycling needed.

All bulbs are available now.

[worthy grove]

I've also seen issues with unavailable bulbs in HA after updating and restarting the HA Matter Server. I don't know if I've messed up my HA Matter Server because all of my 16 bulbs are working in Apple Home and Homey without unplugging any of them. Even after restarting Homey the bulbs reconnect fast. So at the moment HA is the only ecosystem with problems for me.

[feral steeple]

I leave them in the nanoleaf app just for the updates 😛 Dont have many issues with the updates via Galaxy S21

[wind finch]

In HomeAssistant, I see the NL devices still do not have an IP address advertised. Just a FYI. Doesn’t appear to cause any issues for me. But I thought maybe with a newer matter version, some things would happen automagically 😜

[wind finch]

Can Homey join the existing AppleHome thread network? Or are you only using the Matter part of it?

[worthy grove]

You can't join an existing thread network at the moment. Homey is also using its radio for Zigbee and Thread, so this would change the Zigbee channel. I'm just sharing the devices from Apple Home to Homey because I have a good thread network with 6 BR's (Apple & Google) and have no need for Homey as another BR.

[brazen canyon]

The NL app has a history of crashing bulbs so I don't trust it

[grim obsidian]

After updating, I'm currently seeing all of my essential a19 bulbs inside my house connected to my nest hub Gen 2 (This is a huge improvement). Home assistant with my sky connect can see some of the inside lights (no change here). Most of my lights outside are still not reachable on either app. I only have 1 thread network.
I wish I could get a thread border router closer to my outside lights but that's just not realistic with what's available today.

[eternal hill]

Did you reinterview the bulbs?

[wind finch]

Yes, I did try that

[brazen canyon]

This FW is a big L for me. Not a single bulb is reachable via HA anymore. Guess I get to repair my entire house again

[worthy grove]

Do you still get the "(re)discovered on MDNS" message for unavailable bulbs? Seems that all of my bulbs are discovered on MDNS but HA can't connect to them.

[brazen canyon]

Yeah I do but I just get "timeout waiting on response from peer"

[worthy grove]

I only see "(re)discovered on MDNS" every few minutes. But it's only HA for me a the moment. They are working fine in Apple Home and Homey. 🧐

[feral steeple]

Im seeing similar, updated 1 room and most are unavailable. Restart matter server didnt make much difference, restart OTBR, similar. Going to do a full system restart and give them a few hours in case they all just need to remesh and work their stuff out.

Actually as I type this, 4 out of 8 have come back up after about 5mins from the OTBR restart

[brazen canyon]

Just FYI I had to re-pair ALL my bulbs

[bitter compass]

Hey @boreal surge you wanted to know about any matter issues So here you go. Although the lights initially came back to Home Assistant, after a Home Assistant OS update, everything BUT the Nanoleaf lights came back. So I rebooted the Google Home hubs. And then when they were all back on Thread I looked at mDNS. This Is what mDNS showed.

[brazen canyon]

Similar to @bitter compass my other devices were fine

[feral steeple]

Think im going to give it some time, they seem to slowly be coming back online.

[bitter compass]

https://pastebin.com/VUgp5ksj

however after power cycling all the nanoleaf lights, there were entries in the mDNS.

https://pastebin.com/FkFQ68mE

[brazen canyon]

@boreal surge problem with the strips. Sometimes they don't turn off despite sending a turn off command. Instead they just go to 1%. Strip on/off behavior is really weird now -- very jerky transition compared to previously smooth. A19 seems unaffected

[bitter compass]

from the nanoleaf app, home assistant, google home?

[brazen canyon]

HA, haven't tried the NL app yet (it's super unreliable)

Well, the NL app is irrelevant since it doesn't use matter anyways

Might have to try GH

[bitter compass]

let's us know if it's a generic firmware problem with controlling the light, or something that only happens on the matter side of things.

[feral steeple]

Yep, they are all back online in HA again now 😄 yay no repairing

[bitter compass]

I should also probably show this error.

2024-02-27 14:18:10 core-matter-server matter_server.server.device_controller[126] INFO Node 3 (re)discovered on MDNS
2024-02-27 14:18:10 core-matter-server matter_server.server.device_controller.[node 3][126] INFO Setting up attributes and events subscription.
2024-02-27 14:18:11 core-matter-server chip.native.SC[126] CHIP_ERROR Received error (protocol code 4) during pairing process: src/protocols/secure_channel/CASESession.cpp:1981: CHIP Error 0x000000DB: The Resource is busy and cannot process the request
2024-02-27 14:18:14 core-matter-server matter_server.server.device_controller[126] INFO Attempting to resolve node 3... (attempt 2 of 2)
2024-02-27 14:18:35 core-matter-server matter_server.server.device_controller.[node 3][126] INFO Subscription succeeded

Also worth pointing out that when the lights couldn't be found in Home Assistant, if I went into the Google Home app and went in to "linked apps and services" section on any of the nanoleaf lights, no linked fabrics showed up with it eventually coming up with an error. I assume because the mDNS entries were missing?

[wind finch]

Has anyone shared a light to HA using the new firmware? I have two GU10’s installed new, updated. Now if I try share to HA, copy code then enter code in HA, it doesn’t see the device…

Usually, the device that you copied the code for is shown as a nearby device…
Now it’s only shown as all devices… and they all have the same name there so I don’t know which one it is 🥲

It’s as if pairing mode does not turn on.

If I check in the thread section of the NL app, all lights are listed as “Mesh Extenders”, except these two. They are listed as “Child”. Unsure if it’s related, but it’s a difference.

[wild oracle]

this is really useful insight that GU10 flickering may be specific to certain devices. does this match your experience @steel hemlock @shell vigil or anyone else seeing flickering

[wild oracle]

This is a known issue we're working on. should be fixed before production release. note that i think HA should list currently used IP, but they currently arent. it will be useful when devices have multiple IPs on multiple interfaces

[shell vigil]

I haven’t reset the bulbs , but they are still flickering and from time to time@dimming and color is not fixed. There is a light improvement though.

[eternal hill]

i have a similar feeling.

Maybe they are too busy routing traffic instead of turning on and off 😄

[shell vigil]

@wild oracle one bulb is completely off and not turning on anymore … this one was the most flickering (I didn’t reset it though)

[steel hemlock]

I haven’t reset my bulbs neither.
The flickering seems to happen random for me. I have already exchanged the bulbs that were flickering and it keeps appearing. I cannot recognize any pattern.

[boreal surge]

Thank you

[feral steeple]

Have more unavailable than usual since updating them all 😦 Will give it 24hours and see if it just takes a while to settle like last update.

[craggy plaza]

I had one bulb that didn’t want to update. The procedure didn’t start. After removing it from my Matter fabrics (AH and HA) I resetted it to factory defaults, updated it, paired it to AH and shared it with HA. To share it with HA, I needed two tries.

[craggy plaza]

I have 5 GU10, but never recognized flickering.

[craggy plaza]

I also had one bulb that became unavailable in HA and AH. A power cycle brought it back in both ecosystems.

[shell vigil]

It is available in Apple home@and NL app but no action and reaction always off whatever you choose

[craggy plaza]

Ok, so that’s another issue.

[wind finch]

Yeah I now got it working. I just rebooted the closest AppleTV, and then they showed up as “Neraby Devices”, and it all went smoothly

[brazen canyon]

So what's the endgame with the software beta program? What's the conditions for releasing a build to the general channel?

[craggy plaza]

So, I rebooted everything (7 Apple TBRs and a HA Yellow) 10hours ago:

• 8 of 16 Nanoleaf bulbs didn’t come back to HA, but worked in fine in AH
• 32 EVE Matter over Thread devices worked fine
• 2 hours later, I started power cycling the 8 bulbs, they all came back to HA and AH
• another hour later, I lost one bulb in AH and HA
• waited another hour, but the bulb didn’t come back
• power cycled the bulb and it came back immediately

Since that moment everything seems stable, I looked through the HA logbook and only see 2 short dropoffs for 2 bulbs in HA. It feels good at the moment. But the complete procedure was not so good.

[dull dagger]

i had to power cycle my TBRs to get them all on thread (both NL app said it was a on BT and HA said unavialable)

[boreal surge]

This is on our roadmap for this quarter, but no firm date available yet. Would you be interested in beta testing a firmware candidate in the near future? 🙂

[dull dagger]

you bet! Count me in.

[shell vigil]

@boreal surge would you know why one bulb died ? I reset it it works but then I connected again and there is no light from it but it’s connected and reachable

[opal sparrow]

Huh. I'm having a really weird issue with one E26 bulb that I'm trying to set up (for the first time). I initially used the NL app to connect to it and perform firmware updates over bluetooth. It's currently on 3.6.152. It looks like the NL app set up Thread credentials, and the bulb has joined my thread network - I can see it in the OTBR api topology response, and I can ping the bulb's IPv6 address. But the bulb doesn't seem to be registering any services with the border router (no mdns), the NL app can't communicate with the bulb over thread, and matter commissioning doesn't work. This behaviour persists over a reset. Any ideas?

(my other two bulbs are both working fine, both NL app and Home Assistant can talk to them over thread)

[boreal surge]

That's unusual. Is the behaviour the same when trying to issue instructions from the Nanoleaf App versus GH / HomeKit / etc ?

[boreal surge]

Awesome! If you haven't already, can you sign up for the general program here : https://research.nanoleaf.me/beta-program-signup/

Make sure to fill out the Discord username field, so I can match your profile when the time comes 🙂

[shell vigil]

Yep

It started when the bulb started dimming to white color around 50% and get stuck

And then lost it

I have this behaviour as well now starting with another bulb

[boreal surge]

Weird alright, I don't think that we're currently tracking an issue that sounds like this. Would you mind filling out a bug report, noting any reproducibility steps if there's a pattern? https://research.nanoleaf.me/upcoming-quests/chip0001-3-xx-thread-beta-software/ ( page password is CHIP0001 )

[opal sparrow]

I'll see what I can do, but this is only happening with one of three bulbs that I purchased together in a pack, the other two connected fine :/ I suppose I could try resetting and reconnecting one of my other bulbs to see what happens.

[boreal surge]

Hmm. Seems a bit of a stretch for the same behaviour on different devices to be a hardware issue this close to a substantial firmware update. Can you fill out a bug report?

[boreal surge]

Great, much appreciated. We'll take whatever information you can provide—the bug report format helps us bucket and classify issues efficiently, removes a bit of the 'fog of war' so to speak.

[shell vigil]

The one thing in common between both is flickering 🙂 both flicker one died one for the first time today got stuck in 50%

[boreal surge]

Blech, that's annoying. I'll chat with the embedded team in the morning and see if we can narrow down some additional actions for reproduction or further investigation. Bit of an eyebrow waggler for me.

[wind finch]

Ah, I actually decided not to buy one (yet) because it wasn’t a border router… However, knowing this, I’ve pushed it up my to-do list and just ordered one 😉

[wind finch]

Is the Discord part new? I don’t remember seeing it before

[opal sparrow]

Well, uh, I'm not sure what I'm going to be able to report now. I left the bulb unpowered for a few hours while I was doing some other things, and now that I turned it back on again, everything's working fine - NL app connects over thread, and Matter comissioning worked :( I guess I should have left it running in the broken state…

I'll still report what information I have about the actions I took, since it was a pretty annoying experience in the initial setup.

[boreal surge]

Bah, gaslighting. Yeah if the behaviour repeats itself in the future, it'd be great if you could run it in the broken state and collect some more information. Regardless, we've got a note about that now so it's on our radar anyway.

[boreal surge]

We have your username on your quester profile 🙂

[craggy plaza]

I filled the form again. There are also some new questions.

[plain kettle]

I mean, I already got into the new HW beta coming up without putting my disc username in, so no doubt it just helps to have as wide of a range of items as possible

[boreal surge]

Yup, in most cases 🙂 we're just thinking ahead a bit... we want to noticeably scale up the beta initiatives which we run across hardware, software, and firmware products. For most tests, the more devices the better. But for some, we actually want to have a cross-section of testers with very simple environments and a lower level of technical understanding (helps establish a control group in certain types of studies). Having an understanding of each tester's environment helps us select a representative groups based on a number of different factors.

For Thread and Matter, it'll almost always be highly technical testers right now. The technologies just aren't mature enough right now for primetime with everyday users.

[brazen canyon]

@boreal surge I asked this above, but what's the end game for this software beta look like? What has to happen for a firmware to be ready for the general availability branch?

[opal sparrow]

Anyways, now that all my bulbs are connected, I guess it's time for me to poke into Home Assistant's Matter stack to see if I can get color and brightness transitions working there. I made a post over at https://forum.nanoleaf.me/forum/developer-requests/nanoleaf-essentials-bulb-add-states-transitions-support-with-matter#post_3764 with the results of my testing - the bulbs support transitions (although the transition quality/smoothness isn't great), it's just that HA isn't telling the bulbs to do them.

[feral steeple]

I had this same issue and they had to send me a replacement.

[brazen canyon]

HA has transitions implemented they're just not in core yet. You can check it out here
https://github.com/home-assistant/core/blob/dev/homeassistant/components/matter/light.py

I'm not sure how it's going to be exposed.

They suck though (thanks Matter!) So idk why you'd want them anyways. The nice transitions you see in the NL app are from the proprietary stack

[opal sparrow]

honestly, the most useful thing I learned is that setting the OnOffTransitionTime attribute to 0 gave me the behaviour I desired of instant turn on but transition turning off, which is what I wanted (tho this actually seems like a bug)

[feral steeple]

So 6 out of my 24 GU10's have been unavailable a bit after updating htem. strangely, 5 of the 6 are showing up as they are no longer being provided by the matter integration, so I dont know if they just wiped their matter admins or something?
Connecting it to Google home then adding to HA fixed it again (still showed HA as a linked app so deleted that first) So not sure if this is a NL things or a HA issue :S?

Wondering if anyone else has seen similar

[opal sparrow]

The quality of the transitions seems to be a firmware limitation rather than anything inherent about the matter apis? The matter apis just request a transition from one state to another over a duration, and it's up to the bulb firmware to make that look nice :/

(I am annoyed that matter didn't fix the issue inherited from zigbee that there's no way to set level and color temp in a single command with one transition tho)

[brazen canyon]

No that's not true, you can do a quick sanity check and see how the transitions look in other ecosystems (Google home, etc) they suck too.

There's a header in the matter stack that defines steps per second to be 10, so if you have a 0.5s transition, it's only 5 steps which looks trash. I'll find it for you

[craggy plaza]

Did you try to power cycle them? 8 of my 16 bulbs became unavailable. Power cycle always helped to get them back.

An hour ago I had another unavailable bulb in HA, while available in Apple Home. After 45 minutes I power cycled the bulb and it came back immediately.

[opal sparrow]

right, but that's an issue with the implementation not with the API itself. It is annoying that its an issue in the generic matter code being provided for venders to build on tho :/

[brazen canyon]

https://github.com/project-chip/connectedhomeip/blob/6d8613dfb673d3419d9ed0802db5e7c36069b935/src/app/clusters/color-control-server/color-control-server.h#L36

[opal sparrow]

I guess in order to make a bulb with high quality transitions, a vendor would need to throw out the provided color control server code and implement it themselves :(

like, I've been playing around with the ESP32-H2 devkits recently, and their hardware pwm generator has builtin transition support with gamma correction, there's no reason to do any stepping in software :(

[brazen canyon]

You know that NL doesn't fork the matter stack themselves right? It's implemented by the vendor of the SoC

In your example it would be NL using the s3-h2 in their bulbs and using espressif's devkit

They do have nice transitions in their app, but that's through their proprietary protocol not the matter stack

[eternal hill]

they still modify this

[plain kettle]

they can, but i dont think they are in the ball park to be doing that yet

[opal sparrow]

From what I've seen about the Matter stack, there's nothing that would prevent using a custom ColorControlServer from your own code, but it does look like some of the soc vendor sdks bury things a bit in a way that makes it harder :( I guess part of the reason they built it like that is so the values retrieved from the attributes for current level or color will always match what the bulb's currently displaying (a lot of zigbee bulbs... don't)

[plain kettle]

they could, but i think they just rely on their own stack for it, and havent really focused on implementing it via the matter spec

there are bigger issues related to the bulbs at the moment that this 😅

[opal sparrow]

it would be kind of unfortunate if the other issues are also caused by code in the matter stack or soc vendor stack; either waiting for an upstream fix to make its way down or forking things to work on them yourselves... at the expense of getting out of sync for updates and/or trying to push things to upstream repos yourself.

[brazen canyon]

They already mentioned earlier that there were issues resulting from upstream vendor libraries

If you have a good idea of how to implement things differently in HA and are motivated, I'm sure they would accept your contribution.

But I'm pretty sure it's something NL would have to implement

It would be interesting to see if any of the other matter bulbs do transitions differently

[opal sparrow]

yeah, i rather doubt there's much that could be done differently from the HA side after looking at the code in https://github.com/home-assistant/core/pull/109803 - that's more or less the work that I expected would be needed there. The PR has a note about transitions on/off not being supported, but those are configurable by writing the OnOffTransitionTime (or separate OnTransitionTime / OffTransitionTime ) attributes, if supported. It's not something you'd want to set every time for one-time transitions, but it would be nice for HA to expose a way to configure that staticly.

(In ZHA, that sort of configuration attribute is exposed as entities; the Matter integration should probably do the same thing)

[lone iris]

I am also having some issues with mine after the most recent update, can't add 1 of my lights to my apple home and 2 of my other lights arent responding with apple home

[feral steeple]

yea power cycled all after doing a full HA reboot. The ones that are saying they dont exist in matter server anymore are the strangest part :S
Linking a couple of them to Google home, they are coming up as offline, but showing online and responding in NL app on thread.
So something odd is happening

[feral steeple]

I haven't reset them yet, was trying to avoid doing that.

Seems to be something with the bulb as HA is finding it again, but just doesnt come back online.
2024-02-28 01:08:48 core-matter-server matter_server.server.device_controller[126] INFO Node 51 (re)discovered on MDNS

[lone iris]

I restarted my Apple HomePod and it fixed it actually

[dull dagger]

my HAOS system crashed (with elevated CPU) and the last 20 logs or so were related to matter (only have the 5 NL Thread devices).
http://pastie.org/p/6hRRJoyZlHjXzcoODl5lMW

I realize this is a home assistant issue but because I am beta testing the firmware ill report it here too

[brazen canyon]

I've got the same issue 😵‍💫

In my case they aren't even reported as offline, but nonetheless don't respond

[main matrix]

as an update; my lights have all finally come back into the fold, however it took 8 of them 17 hours before they became responsive (left them on overnight after being off an hour or so). About 5 minutes ago, they just "appeared" 😕 .

Seems stable for now, but no idea what caused the almost day delay in being reachable again.

[swift phoenix]

Same here. Had to wait hours for mine to reconnect. They eventually did tho

[lime willow]

Can confirm exact same behaviour with my light strips on .152 now. Brightness adjustments are very jerky, when turning on a group they’ll go to an arbitrary brightness, and they often seem to get stuck at 1% when turning off.

[craggy plaza]

Over night I lost one of my 16 bulb in Home Assistant and Apple Home. It is not controllable anymore, it’s unavailable. But it works in the Nanoleaf app.

Besides that, I also had one bulb that switched on by its own.

CHIP-1236 for a GU10 bulb

[plain kettle]

Ah, appears that 3.6.152 is now on the downlights, nice!

[brazen canyon]

This update did not fix CHIP-1307 FYI

[dull dagger]

According to Marcel, the logs are a result of the system crashing, but not the cause of the crash.

[wind finch]

Yup, same for me with the lightstrips

[boreal surge]

We're discussing this topic this morning, I'll post and pin an update later today.

[boreal surge]

Can you fill out a bug report with reproduction steps as able? https://research.nanoleaf.me/upcoming-quests/chip0001-3-xx-thread-beta-software/ ( password is CHIP0001 ) @wind finch as well—we're having trouble reproducing here.

[boreal surge]

Thank you—we're tracking this as CHIP-1312 now with additional information from other testers and internal reproduction (have clarified the research page)

[grand pilot]

So far with the recent bulb update and home assistant matter update, 2 out of 3 of my matter bulbs have been pretty spot on, they've been online every time I've checked in the home assistant app, but there is 1 light that does seem to stay offline untill I power it off and on.

[wind finch]

What's the maximum distance of the e27 bulbs? I just added two which are +- 10 meters between the next NL device (and border router).... it is in a separate room with a garden in between (it is open, no plants or anything in the way). But they seem to be on Bluetooth 9 times out of 10. I've never added devices there before, hence my question about the range...

[ornate obsidian]

@boreal surge - just FYI - all A19s holding steady in HomeKit and HA (8) - updated the night after you released

best firmware i've had yet

[eternal hill]

What is your wall made out of? I have some walls that block everything, while others are fine.

[wind finch]

Bricks? 🙃 and 1x HR++ window

[eternal hill]

For me the disco mode also happens when powering off the device. I once even had it happening to a bulb that was not turned on (even though it should have been). When homeassistant then send the power off command, it also flashed before turning of again. Or has this one been fixed already?

[eternal hill]

I also don't know too much about walls, but some block a lot. Maybe its when they have metal in them

[wind finch]

Probably need to look for a border router for there, or try get more devices in between

I had some Zigbee devices there before, just assumed the NL devices would pick things up fine. 🤷🏻‍♂️

[eternal hill]

i think zigbee needs less bandwith

And i have also moved my border routers to better positons and most of my bulbs have been stable the last 1.5 months

[boreal surge]

What's Next for the 3.6.x Thread Beta

Before releasing a fw candidate to production, we're mostly focused on ensuring that there aren't major regressions in overall performance and reliability compared with the production 3.5.x releases. So, we're really looking to this group to call out challenges still faced (via Discord and bug reports).

Before concluding this beta and deploying the fw to production, we want to wrestle down open issues related to :

• GU10 flashing
• Lightstrip to 1% output issue
• Issues reported when working with multiple fabrics

We're also working on issues related to :

• Bulbs don't report IP addresses to Matter server

If are seeing issues that feel like regressions please either tag or DM me.

[shell vigil]

Few more issues:
1- the bulbs doesn’t always show the correct color chosen (mainly with the flickering bulbs)
2- controlling more than around 10 bulbs on the same time crash the thread network
3- some of the bulbs get stuck on a dimmed level and became uncontrollable despite being available and be able to control them

[tranquil pollen]

This latest firmware update might be the best one yet. At least for me it seems that way. My kitchen consists of 3 x A19 bulbs and 4 x Downlights. I’m running them on HomeKit and Home Assistant and can’t remember the last time I had them all working and connected to both systems.

I’m using the adaptive lighting 3rd party integration in HA to control the color temp and brightness of the kitchen lights and cutting power with dumb light switch at night. With the adaptive lighting, it’s obvious when things aren’t communicating right.

I’ll give it a few more days to see how they do, but so far so good.

[feral steeple]

Since sorting out the initial connection issues after the update, its been 16 hours and none of my 24 have gone unavailable. This is the longest period of time I have had since having Nanoleaf that I have not had lights dropping off 😛
Hopefully dont jinx it, but see how the next few days go.

Definitely seems like more steps in the right direction

[frozen crystal]

Wow this is staggering. I now have every GU10 in my home online simultaneously… all 63! Big achievement. Well done, guys

[frozen crystal]

Is there a systematic approach which we should now be taking for stress testing?

[swift phoenix]

Im still having issues with the bulbs not wanting to reconnect with HA again

Only happens with NL bulbs

[boreal surge]

Try and break stability 🙂

For a network with as many devices as yours, I think we'd be looking at seeing what happens when you flood out instructions... start with smaller groups then increase to the whole network (hit 6 devices, 12, 30, 60, etc). See at what point latency and reliability starts to get shoddy. It would be really great if we could either validate performance is great at all 63 or identify a scaling point where it gets dodgy.

[shell vigil]

It broke after 10 with me, the bulbs became unreachable, I tried with 35 it didn’t work and I saw all my devices went unreachable@

[boreal surge]

Can you provide a bit more information on the specifics of unreachability? This article has some guidance : https://research.nanoleaf.me/2024/02/verifying-unreachability-issues/

[frozen crystal]

Well, I think I just killed it by asking for 25 to do turn on simultaneously. Let’s see how quickly the mesh heals itself. The thing which really broke groups before was making colour and brightness adjustments to groups of bulbs

[boreal surge]

Would also be great if you could document reproduction steps... so we can then say 'stability broke at 25 devices when I tried to change a scene from warm white to aurora borealis' for example. We have a mesh in our test environment here with a couple of dozen devices, so we can attempt to repro when we have clear steps to follow (this really gets us closer to zero'ing in on root causes in a lot of cases).

[boreal surge]

Yup, that's great detail to capture when you're beating up the network.

[frozen crystal]

Ok I’ll have fun with this when my wife is out 🤣

[shell vigil]

Hahahaha

[frozen crystal]

The mesh healed very quickly. It’s interesting that when I ask some of the impacted bulbs to turn on again the brightness level they’re reporting in Apple Home is clearly inaccurate. Adjusting it immediately brings it back to accuracy

Only some of them…

[upbeat mica]

I also have number 1 and 3 issues with my bulbs

[feral steeple]

Please let me know if thats still the case in a couple days. I have been avoiding plugging my 12 other ones back in while having all these issues

[craggy plaza]

@boreal surge Which ecosystems do you use in your test environments? Can you please install Home Assistant, if this is not already the case? Thanks

[craggy plaza]

WOW this is a really big setup! Great, that it works! Which ecosystems are your bulbs paired to?

[feral steeple]

My 3 rooms are close together and motion activated. 8 gu10 in each room, if I walk through them quickly. First comes on as normal, second a little delayed, 3rd took about 5 seconds till the lights came up

[frozen crystal]

Apple Home

[craggy plaza]

OK, only one eco system. Thanks

My 16 bulbs are paired with Apple Home and Home Assistant. With the latest firmware:

• 2 bulbs became unavailable in HA and Apple Home, but they were controlable through the Nanoleaf app (had to reset and re-add them)
• 5 bulbs became unavailable in HA only and they did not become available (already resetted and re-added 3 of them, now they work again)
• 1 bulb became unavailable in HA, Apple Home and in the Nanoleaf app (will try to reset and re-add it later)

and one GU10 switched on by itself. The HA devs developed new betas the whole day and we also tested the whole day. But the 5 bulbs didn't get back to HA by themselves.

[verbal drift]

I think you need to put your bulb count up to 100 because you can, just don’t tell your wife lol

[craggy plaza]

I have a total of 36 Nanoleaf bulbs, but only 16 are paired. That won't change until they stop becoming unavailable in Home Assistant.

[frozen crystal]

If I turn off 22 GU10s (plus some HomeKit Thread lights) in one hit, everything goes off over a couple of seconds but then a few Matter bulbs drop from the mesh for a minute or two

If I adjust the colour of a group of 9 GU10s they typically all change but usually one or two lag a few seconds behind. Sometimes one or two bulbs then need to be targeted individually with a second command

This is all using Siri

[boreal surge]

Out of curiousity, what motion sensor are you using? (I don't think that's the issue—just personal curiousity)

[frozen crystal]

Mine work very nicely in a couple of tiny rooms with the Onvis motion sensor.

I have the Aqara FP2 hooked up in one room with some HomeKit Thread bulbs. It’s a super demo showing how fast the sensor and bulb react by changing colour depending upon which seat you’re on

[feral steeple]

Just basic zg-204zl.
If i walk slowly across the rooms they all come on within the typical time frame

[frozen crystal]

A fun stress test of both will be trying an Aqara FP2 in a larger room where it only turns on the GU10 you’re standing beneath. Like a spotlight mode

[feral steeple]

Ill have to get one of these sensors to play with

[frozen crystal]

They’re very impressive indeed

You have to RTFM though. I’ve seen too many posts by impatient folk who clearly haven’t bothered to tell it the room layout etc.

[brazen canyon]

This is CHIP-1318, ive seen the same thinf

[frozen crystal]

Ah gotcha. At least it recovers fairly rapidly now. The house is functional for a normal human being

[brazen canyon]

I feel like the regressed LED strip behavior needs to be on here (choppy on/off transition) and sometimes not turning off and instead going to 1%

Those are regressions from last build

[lyric panther]

I've updated my one A19 matter bulb to 3.6.152 and I'm still unable to add it to HomeKit. Tried both the NL and Home apps. A nice change from a month or so ago is that it at least starts the setup process. With prior firmware versions, attempting to connect would immediately fail.

[main matrix]

so this update seems to have introduced a bug with my A19s; at least 8 of them in the last 24 hours have retained power, but Nanoleaf, GH and HA apps all show the light to be 'off'. It's literally "the light is on but noone is home".

Removing power from the affected lights turns them off (obviously), but if I turn them back on straight away, none of the apps can see them (not Bluetooth, not Thread). It's only after the power has been removed for over an hour that they phone home again.

Not sure how much worth it is to submit a bug report per se, as there's no logs I can see to suggest why this would be a thing.

[peak belfry]

How did you generate this visualization? HA?

[plain kettle]

OTBR add-on has a gui, in that

its not at all reliable tho

[peak belfry]

Just found the answer at #1184371187464290344 message, a few messages later 👍

[plain kettle]

ahaha yeah, knew i posted it before somewhere 🤣

[peak belfry]

How are you observing cycling through offline/BT/Thread if you're 100% Apple HomeKit? (I am too, I want to check if this is happening in my setup too.)

[plain kettle]

you can see the connection method on the nanoleaf app

[verbal drift]

I could see this in the Nanoleaf app, but since I have upgraded to latest F/W this has now gone away.

[peak belfry]

This is an excellent observation! I can add something to this.

• I have 6 A19s/E27s with zero reliability issues kinda evenly spread around the house (the older HomeKit ones though, not the newer Matter version)
• I also have 3 Light Strips with zero reliability issues kinda evenly spread (again HK-only)
• I have 9 GU10s (obviously Matter), with 1 on one end of the house, the other 8 in an area of approximately 5 by 5 meters. And 7 of of those 8 in an area of 3 by 3 meters (3 in hallway, 3 in bathroom, 1 in toilet).

Of those 8 GU10s in close proximity, the ones with the most significant problems (most easily observable at least) are the 7 in closest proximity.

[peak belfry]

But that only allows observing per-bulb, and only the moment you're observing? I'm wondering how you can automatically monitor/log this for all bulbs 🤓

[peak belfry]

This sounds related to the GitHub issue reported by @brazen canyon a few comments higher: Home Assistant is using mDNS incorrectly. A trivial dns-sd -B (or Avahi equivalent) triggers them to be rediscovered instantaneously. The reason Home Assistant loses track of these bulbs is those bulbs rebooting/disconnecting-and-reconnecting frequently though. So it's both a bug on Nanoleaf's end (unstable bulbs), and Home Assistant (should be more resilient for unstable devices or unstable networks). The fix has been merged in Home Assistant though, so I bet this problem will disappear soonish 😊

Indeed, I'm really curious whether this first Sense+ device will support Matter Binding. Because that is one potential way to reduce reliability issues, mitigate SPOF (Single Point of Failure) and decrease latency.

For context: I currently have a GU10 bulb in my toilet. There's an Eve Motion sensor (Thread, HomeKit firmware still). It worked flawlessly for >1 year, when I still had a Philips Hue GU10 bulb. After switching all Hue GU10s to Nanoleaf GU10s … the light just won't turn on. If I look at the Eve app, motion has been detected … but the automation won't trigger. My only possible conclusion are: 1) caused by Nanoleaf GU10s, 2) they probably cause the notification to somehow never arrive due to the Thread network being made unreliable.

🙈 So can I pretty please test the Sense+ if it has Matter Binding support so the unfortunate situation of … "ending a toilet visit" … doesn't have to happen in the dark? 💩🤣🙏

[peak belfry]

👋 Hi everyone! Just joined this Discord a few days ago. I've read literally every message since December 20, to check if somebody's reported the problems I've been seeing.

One problem I've seen only kinda implicitly reported: a bulb that won't respond to commands. In my bathroom, I have 3 GU10s. It often happens that one doesn't react as it should: it doesn't turn on or off. All three bulbs have done this, so it's not isolated to a single bulb.

A problem I've not seen anyone report is the consequences of adding GU10s on previously-working-flawlessly other Thread devices (in my case all Thread+HomeKit, not Thread+Matter). In my case: Eve Motion. That's what I described in detail in the message just before this one. My dozen or so Thread-based Eve Energy devices continue to work fine, but they're not in as close proximity to the GU10s, so probably are routed through others.

(@craggy plaza — you have 32 Eve devices. What devices are they? Are some of them routed through GU10s? Do they trigger HomeKit automations for you?)

[versed vault]

They’ve confirmed it won’t have binding support, at least at launch.

[peak belfry]

Yep, saw that a few messages later. 👍 Hoping they'll add it post-launch indeed.

[brazen canyon]

If you have HA you can use OTBR cli commands in the container and either tail them or log them that way. Would take some work but not too difficult

[feral steeple]

May or may not help, but i had a similar issue with a couple of my automations and i had to pick a different trigger device, save it, then pick the motion sensor again and save it and it started working again for me

P.s. I am now 36 hours with 0 out of 24 GU10's going unavailable! This is very promising

[boreal surge]

Yup, agree. We have one bug report from yesterday about it—I'm going to DM you for collect anything specific from your experience that might enrich that issue ticket.

[tranquil pollen]

FYI, there’s a new Matter server update for HA.

[grand pilot]

With this update all my bulbs show IP addresses now

[tranquil pollen]

Interesting. Not for me. Even after rebooting HA I got nothing.

[boreal surge]

By chance, can you drop the link to the github issue for us to review? Might have some relevance for our own implementation.

[main matrix]

The update just appeared for my HA install. 5.3.0.

[brazen canyon]

It's been resolved but sure

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

[craggy plaza]

It should be this: https://github.com/home-assistant-libs/python-matter-server/pull/585

It’s already part of the latest Matter beta server, that I use at the moment since yesterday evening. But I also don’t see IP addresses.

[brazen canyon]

I don't really have the great experience everyone else does. I can case subscriptions being opened and some bulbs just never respond

[craggy plaza]

Ufff, I looked at my devices and recognized that two bulbs became unavailable 30 mins ago.

[opal sparrow]

hmm. I assume the reason HA doesn't show IP addresses after the matter server update is that it must have the old status (with no ips) cached. i wonder what might cause that to refresh.

[brazen canyon]

It doesn't show them because NL doesn't supply them

[opal sparrow]

after the linked pr, it shows the ip addresses retrieved from mDNS instead of the ones pulled from matter attributes

[brazen canyon]

Looks like NL did update the attributes

[opal sparrow]

honestly, the weirdest thing that I found poking around in the matter attributes is that the E26 bulbs have a "Fixed Label Cluster" populated with some sdk sample data: room="bedroom 2", orientation="North", floor="2", direction="up" :) [edit: I filed an issue for this with Impact on Enjoyment set to Cosmetic just so it's something that can be tracked]

[scenic grove]

interesting evening. It's very possible we had a power outage that had the lights turn on and off 5 times in the right timing as it was a high wind night and the power ultimately went out. We saw the flickers happening. All of my bulbs for matter seemed to manage to reset in all the excitement inflicted by the storm. I was able to remove/re-add them back to Home and the Nano app this am without any issue.

[feral steeple]

Not sure if i am game to try it yet 😛

[opal sparrow]

with a small number of e26 bulbs, the update was uneventful :)

[alpine ore]

Is it safe to upgrade my 21 GU10s from 3.6.136 to 3.6.152? Atm, only 4 of them (my bedroom ceiling) are connected to NL, and they've worked flawlessly (I control the rest via Siri). If there's been reduced stability, I may want to hold off until the next release. What do you guys think?

[alpine ore]

I've upgraded the 4 in my bedroom, and all seems to be well. @boreal surge it seems like turning them on is more snappy via NL app, but it's as it was before via Matter… not sure if that's intended.

[feral steeple]

Yes, do it, they are much better on 152.

[gilded void]

A19s are noticeably faster and more stable/reliable on .152 for me. I’ve 10 over the network. My 8 GU10s though are demonstrating worse performance. Slow to respond. Delayed commands with bulbs randomly turning on. Worst of all, turning off or on seems to crash the entire thread network. The entire thread network is more stable with the gu10s powered off.

[feral steeple]

I have not had any of my 24x gu10's randomly turn on with the new firmware.

[bitter compass]

So.....

updated to the latest Matter server.
everything came back, except one A19 bulb.
Have power cycled it.
Have run the mDNS command to list all devices.
Nothing.
It refuses to come back online in Home Assistant. It IS online in Google though.

(And for anyone who has updated to the latest Home Assistant Matter server - please tell me, does ping work for you? Because my ping now always come back with a green tick, and the exact same IPv6 address no matter which device I choose to ping)

[opal sparrow]

hmm, it is returning the same ipv6 address for all devices for me, too. looks like a bug - it seems to be caching the ipv6 address of the first device you try to ping, and then using it for all devices

(that's a pretty common bug in python code - it's easy to accidentally initialize multiple instances of an object to point to a single shared array, for example)

[peak belfry]

I did that multiple times. Those automations always stop working within at best days, at worst hours.

[opal sparrow]

(that doesn't look like what happened here tho, it does seem to be initializing the cache separately?)

[bitter compass]

looking at the logs I can at least see the real IP addresses that are being used that is good. I'm going to try restarting the add-on as right at the startup of the addon I can see it found all the nodes, but there are no error messages after resolving node 16, but also no success messages either. It's like the thread setting up node 16 has just hung and nothing is attempting to resolve the node.

[opal sparrow]

ah, so it might just be a display issue on the home assistant side? hmm.

[bitter compass]

2024-02-29 16:41:04 (MainThread) INFO [matter_server.server.device_controller] Node 16 (re)discovered on MDNS
2024-02-29 16:41:05 (MainThread) INFO [matter_server.server.device_controller] Setting-up node 16...
2024-02-29 16:41:05 (MainThread) INFO [matter_server.server.device_controller.node_16] Setting up attributes and events subscription.
2024-02-29 16:41:22 (Dummy-2) CHIP_ERROR [chip.native.EM] Failed to Send CHIP MessageCounter:261980181 on exchange 10940i sendCount: 4 max retries: 4
2024-02-29 16:41:53 (Dummy-2) CHIP_ERROR [chip.native.SC] CASESession timed out while waiting for a response from the peer. Current state was 3

the problem with that error message is that there are 2 nodes not available, and I have no idea which node that error refers to

[opal sparrow]

actually, looking at the debug logs, after i ping one device, ha doesn't send ping commands for any others (it just displays the result of the first ping you did)

[wind finch]

That’s a UI cache issue, I already reported it. It basically has the previous result cached. Just refresh your browser (or pull down refresh if you are in the app), then ping the next device.

https://github.com/home-assistant/frontend/issues/19752

[bitter compass]

does anyone know if there is a dns-sd or equivalent command I can run inside the matter container? I've tried both avahi-browse and dns-sd but neither are installed. I know you can run one of those commands in the OTBR container but I don't have that running

[mellow nimbus]

Hi, I`ve had my bulbs running okayish in home assistant for about a week. the ninstalled the latest beta update yesterday and all bulbs are now unreachable in home assistant. they work fine via thread in the nanoleaf app though? here are some screenshots from my app, what would be the debugging steps?

[brazen canyon]

There's a b0 bandaid available, if it goes well it will be released as 3.7.1

[mellow nimbus]

so this is a known fault? any time estimate? i can only downgrade to non beta, which was absolutely unstable right? 😄

[brazen canyon]

Do you mean the HA matter server? You can swap from beta to production and back at any time

Well 5.7.1 was just released so very soon

[feral steeple]

Anyone seeing a similar issue.
I have 2x gu10 bulbs that i just cannot get to add anywhere. They show on and on thread in the NL app, but going to google home it adds them and they are just offline. Going to HA it adds the device but the process fails and its just unavailable completely. So maybe hardware related? I have reset it a couple times and same result.

[brazen canyon]

More than half of mine are offline and stay offline so

And it's only NL devices that have problems for me

[main matrix]

I've had 6 fallen out of sync completely, and some reporting false statuses (ie. on at the physical light, but off in NL/GH/HA).

the NL app is also now reporting the same lights that were connected to a Matter fabric as ready to connect to a new fabric (ie. previously the 'Connect to Matter' button was greyed out as the light was identified in HA, which is correct. Now, without doing a reset or anything different, they are now reporting 'Connect to Matter', like everything has been wiped). And yet, the light still 'identifies' as being attached to a Thread mesh...

[brazen canyon]

Don't know if it's too late but the answer is no. You'd have to do it through zeroconf (python) I believe

[peak belfry]

AFAIK the Nanoleaf app never uses Thread. It uses Bluetooth, and does not communicate with the bulbs via Matter/HomeKit/… but via a proprietary protocol. This allows them to ensure that the bulbs can be controlled even in homes without a smart home hub.

For the Thread network functionality in the app, they must be querying this through the smart home hub (or perhaps a Nanoleaf border router if you have one — I don't).

[plain kettle]

yes

[mellow nimbus]

Still works if I turn of Bluetooth though

[mellow nimbus]

With the Bandaid were you talking about nanoleaf bulb firmware or regarding matter server ?

My problem is I can't access the bulbs through home assistant any more. And that there are these timeout errors in the matter server log

[azure fox]

Just updated to 3.6.152 and thread does not work anymore. All Thread lamps logged out over night and not reconnected. I’m only able to control them with Bluetooth …

[brazen canyon]

The matter server. There's a bandaid in there for the fact that this NL firmware seems bad

[plain kettle]

The whole reason the push for getting the IP from mdns was from sillabs not playing nice with the diagnostics cluster

[bitter compass]

Mine has shown the "connect to matter" button ever since the first beta firmware. It was previously greyed out before that.

[wind finch]

Today I had 2x lightstrips and 1x A19 (e27) that were unresponsive in HomeAssistant (although they were shown under the thread network page in the NL app), but working in AppleHome. Turning the light on and off via Apple Home Caused them to become available again for the lightstrips. The e27 has not yet come back to HomeAssistant.

It's the first time this has happened to me, although I see it being widely talked about 🙂

[wind finch]

with a bit of investigation using the Discovery / Flame apps on iOS, I found that the device was still visible on the network (using Dicovery) under the service _ltpdu._udp, so I used this to find it's .local name in Flame. And in there, I found that it was not bradcasting the _matter._tcp / _matterc._udp services like all of the other devices. After a power cycle of the bulb, the services were again visible, and HomeAssistant found it again immediately. I took screenshots of before and after if you need them.

Assumption is that it was still working with AppleHome because I hadn't restarted all of my Apple Devices yet, and therefore maybe still knew "where" it was

[haughty grove]

Yes, seeing same behaviour with my GU10. 3 out of 6 refuse to connect to matter, even after power cycling.

[azure fox]

Regarding my last message, i think, i have the same issue with my gu10 lamps. Nanoleaf App shows, that they are only connected with Bluetooth.

[wind finch]

are they still seen in the Thread Network menu?

[wind finch]

Just had a second A19 do the same thing. A restart of the bulb brought all the services back, then it worked fine after that.

[dense maple]

All of my a19 bulbs have now been bluetooth only according to the NL app for a few days now

[vagrant flower]

updated from a previous beta - x.x.64 maybe? - and have not been able to reconnect my bulb to the thread/matter network. i've tried repairing it and restarting it multiple times but it just refuses to connect

[dull dagger]

Hi, Ijust wanted to add my 2 cents for 3.6.152: its a regression. My lights are going offline (off thread) in NL and HA. Look forward to find the bugs. thanks

[feral steeple]

Sounds like HA have sent some specific issues to NL to fix in the latest firmware, so hopefully that is useful info for them to sort it quickly

[finite vale]

Just reporting in my experience going from the previous 3.6.xxx to 3.6.152: my setup is HA as border router with 12 bulbs. Before the upgrade all but one bulb was quite rock solid. Upgrading was rough, with a lot of failures and repeat attempts. Now 9/12 bulbs are on 3.6.152. upgrading has caused some brutal connection instability but response time when connected does seem faster. I've pretty much resigned myself to needing to unpair, reset, and repair the bulbs to get them to a stable state and once doing so, they seem pretty good. Relatively smooth pairing process compared to earlier revisions (still some hiccups) but I have not yet gone through and done every bulb.

Previous firmware (barring one bulb) seemed more reliable but I have a suspicion that once I go through and re-pair each bulb the new might end up working better. Slowly going through that process as doing them all at once wears me down.

[brazen canyon]

I don't think re-pairing will help. I nuked my entire thread network and matter server, started from 0, and had the issues persist so you'll probably need to wait for a FW update

[wind finch]

Now that I’m paying closer attention, this is actually the case for all my lights which go unavailable A19 / GU10 / lightstrip.

10% of the time, if I trigger the device somehow, they come back for some reason. But usually, a reboot is the only solution.

[manic plover]

Some feedback from my end on 3.6.152:

I have ~50 GU10 and 4 E27. Updates all but 3 to the new firmware. None of the updated bulbs reconnected after the update. A few days later, there are 7 which have a connection. The situation seems rather stable, the bulbs which have connected remain connected, the others are not.

Seems much worse than the previous beta, I had nearly all connected (although they were often disconnecting after executing commands).

Also, the LED strip got disconnected. I never had an issue with it on any of the previous betas, this one LED strip was my bastion of stability 😊

[craggy plaza]

@manic plover Which ecosystem(s)?

[manic plover]

Google Home.

Nest Hub gen 2 as a border router.

[craggy plaza]

Ok, so you do not use the Multi-Admin feature.

[manic plover]

No, I don't.

[craggy plaza]

Look at this post:

#1184371187464290344 message

He has over 60 GU10 and has good results. My personal results are mixed, some bulbs are often unavailable.

[feral steeple]

FYI, the latest HA updates make things really crappy with NL. (HA core 2024.2.5, otbr 2.5.0, matter server 5.4.0 (which is python matter server 5.8.0)

I have reverted back to HA core 2024.2.4, Matter server 5.2.0, OTBR 2.4.7 and just about all my NL bulbs have come back online again.

[boreal surge]

Can you check in Service Browser (or a similar network sniffer tool) and see if the devices are listed in _ltpdu._udp and _matter._tcp ? I'm wondering if the app is reporting connection type incorrectly, seems unusual for reconnection to Thread to misbehave like this. And just to confirm, your Nanoleaf devices are running 3.6.152 firmware version?

[boreal surge]

On 3.6.152, have you seen pairing failures via Google Home? cc @wild oracle

[feral steeple]

I have had multiple bulbs when connecting to google home, it completes successfully but then they are just offline

[brazen canyon]

Core shouldn't impact your experience, but OTBR might (not likely) but surprised you had a better experience with an older version of the matter server

[feral steeple]

I figured core shouldnt, but just wanted to be safe and put it back to when all 24 lights were stable.
Since going back, all but 2 back online and happy again. Will readd the 2 that are unavailable if they dont connect in a couple hours.
Its been way better than the latest updates thats for sure.

[brazen canyon]

Yes but for how long 🧐

[feral steeple]

well last time it was about 40hrs since the new beta update that none had dropped off, then i did HA updates and had endless issues since then... And I have now restored the versions and all my bulbs are back online again.... so take from that what you will 😄

Could be purely coincidental.... could be some new stuff in the matter update that NL is lacking in the firmware causing more problems :S

[brazen canyon]

Most of the new stuff was bandaids for the existing FW but I think you're out of time for now to provide feedback on that I'm afraid

[feral steeple]

Sounds like Marcel found some things related to NL anyway, and im much more confident in him understanding what was not working than I am haha

[mellow nimbus]

what were you guys solutions to getting bulbs to show up in ha again?

[feral steeple]

After updating, I had about 4 that didnt want to show up, I removed and commissioned them from google home again and it was happy since that. (Some times I had to restart the OTBR before it would successfully commission to HA again though).

[dense maple]

I left them off for a few hours along with the thread router then powered back up and they now show Thread again.

[manic plover]

I haven't tried to pair them again, or reset and pair. I had them paired and on previous betas I didn't have a need to reset or re-add to the network. Unfortunately I'm traveling abroad for the next two weeks, so I won't have a chance to test it.

[plain kettle]

Wait you have a single border router for like 54 bulbs?

[manic plover]

Yes.

[brazen canyon]

I mean technically the limit is 511 right lol

[plain kettle]

Well, with anyone one else for Nanoleaf that’s true 🙈

[craggy plaza]

So, I updated all to the latest version (addon 5.4.0, server 5.8.0), all bulbs came back and it was possible to pair last remaining bulb again… Yeah… 🙃 Have a nice weekend!

[vagrant flower]

i've updated everything and still cannot pair this bulb to home assistant at all

[craggy plaza]

One bulb? How did you pair to HA? I did the following:

• resetted the bulb
• paired to HA directly
• shared from HA to Apple Home
• paired to the Nanoleaf app

[vagrant flower]

step two is what fails. i can't add it directly (via home assistant triggering android pairing flow) or via android pairing flow itself

[craggy plaza]

Yeah, that was the issue, I had before the updates to the latest version. After the update to the latest Matter server/addon, I rebooted HA. Maybe that is the key.

[vagrant flower]

did that, too

¯_(ツ)_/¯

[craggy plaza]

Sorry, so, I can’t help you.

[bitter compass]

end devices yes. But only 32 routers. So that means we are relying on the thread part of the NL firmware behaving properly. If it's refusing to stop being a router, then that would cause dropouts

[peak belfry]

Because the "Thread Network" view on your phone doesn't use Bluetooth. It talks to your smart home hub, either via WiFi or mobile data.

I've updated all my (EU) GU10s to 3.6.152. Except for 3. These 3 refuse any and every update. They don't even begin to update: I never get to see "0%" even! Tried over a dozen times.

This was already happening before 3.6.152. I've opted them out of beta and re-opted in, to no avail. Anybody else who's seen this?

(Hardware version 1.1.7, like all others. firmware version 3.5.41, like all others were. The one unique thing about them: their serial numbers all start with E2327.)

[craggy plaza]

I had the same issue with two bulbs. If I remember right, I rebooted my iPhone, Did you try that?

[plain kettle]

And is your app up to date?

[peak belfry]

@craggy plaza Will try rebooting phone next. Thanks. But it's odd that literally every other bulb was able to update? 🤔

@Poshy App is up-to-date AFAICT. 10.4.1 (588)

[plain kettle]

Do not use the TestFlight version

[craggy plaza]

Yeah, had the same issue with 2 of 16 bulbs.

[peak belfry]

TIL. Why not?

[plain kettle]

They can’t keep both versions up to date, TestFlight is a revision behind

It’s wack, but oh well

[peak belfry]

Same result on stable 10.4.2, both before an iPhone reboot and after. 😬

For every other firmware update I've ever done for Nanoleaf devices, within seconds it starts to say 0%. But for these 3 bulbs, all I'm ever getting is a spinner that goes on for ~30 seconds before I see the errors in the screnenshot above.

[bitter compass]

My essentials light strip refused the 3.6.x update - it went all the way to 100% but did not reboot, and after getting to 100% I was just back to to the update button again. I had to turn the light off for 30 seconds and then turn it back on - and then it updated happily

[craggy plaza]

Yes, that is what I also did.

[manic plover]

Are you able to update via Thread? It doesn't work for me at all, since many betas already. By "at all" I mean 100% reproducible across all 54 lights. I always need to turn off the border router and update via Bluetooth.

[peak belfry]

Updating firmware never happens via Thread, always via Bluetooth. But no, I've still not been able to update. next thing I'll try: removing power from these bulbs for several hours 🤷

[manic plover]

Interesting. Then in my case I'm never able to update any bulb if they are connected to the thread network. It starts "processing" and then I get an error.

[peak belfry]

This one? #1184371187464290344 message

[manic plover]

Yes, this one.

I need to turn off the border router and wait for the blue Bluetooth icon to appear, then they update just fine.

Since I have more bulbs than Bluetooth can handle at once (be connected to), I have to flip the breakers of some portion of my lights, so that only about <20 have power.

[dull dagger]

Okay I think my problems were network-related. I rebooted my router because the Wi-Fi in my house was kind of wonky when I rebooted my router all the devices came back online. It's possible to thread border routers were having sketchy network connection so that could possibly explain why all my thread devices were not on thread

So that's another variable to add to the mix LOL

[peak belfry]

Update: I just had all the problematic bulbs disconnected from power for >1.5 hours. They've just had >30 mins to join the Thread network again etc. Result:
– only 1 of the 3 bulbs is reachable … both in the Nanoleaf app and in Apple Home

• the sole reachable bulb failed to update in the exact same way again

What else can I possibly try? 💩🥹

[craggy plaza]

Maybe try the following:

• remove all your Matter over Thread bulbs from current
• remove all your Thread Border Routers from current until Apple Home shows you the message that it can’t reach any Apple Home Hub
• install one Matter over Thread bulb directly next to one of your Thread Border Routers
• power up your Thread Border Routers
• wait until all your (Thread) devices are available in Apple Home (Thread meshing procedure completed)
• maybe reboot your iPhone
• try to update that bulb
• if the update worked, install the next bulb directly next to your Thread Router
• wait until all devices are available in Apple Home
• try to update that bulb
• if the update worked, install the next bulb directly next to your Thread Router
• repeat it for all other Matter over Thread bulbs

If this doesn’t work for you I am out of ideas.

[craggy plaza]

@peak belfry Did you already try to factory reset those bulbs?

After that you can pair the bulbs to the Nanoleaf app only, do the firmware update and then pair it to your Matter fabric.

[mellow nimbus]

just got my bulbs back up again in homeassitant after the firmware upate. Steps:

Remove them from the nanoleaf app

reset the bulb by switching it on and off 5 times

Delete it from home assistant if it was there previously

Follow the steps on how to add a device via bluetooth and the websocket server that is described over here by user Kolbusa:

https://community.home-assistant.io/t/thread-border-router-required-with-eve-and-matter/562937/60

[craggy plaza]

I also resetted and readded some of my bulbs to get them back to HA. But they became unavailable again and mostly do not come back. Sometimes they frequently come and go. Sometimes they are unavailable for hours, sometimes they do not come back. I also had the issue again, that some of my bulbs are not available in Apple Home. All my 48 Matter over Thread devices are paired to Home Assistant and Apple Home. The firmware 3.6.152 made my Thread mesh unstable. All devices started to remesh, after a day or so. I decided to remove 6 of my 16 bulbs from current. My mesh seems to be more stable now. At least all devices incl. EVE devices stopped getting unavailable since I removed the 6 bulbs 4 hours ago. If my Thread mesh gets wonky again, I am going to remove more bulbs, maybe all. I will do more tests with the next firmware. For the moment it makes no sense to me to use them in my house. It's more bad than good.

[peak belfry]

I have not tried that to get the firmware updated, no. It involves unscrewing each of the 3 problematic GU10 bulbs from the ceiling mounts and doing the 5-times-on-off thing by twisting them manually, because there are no light switches connected to them anymore.

I'd rather wait for @Paul from Nanoleaf to tell me what info he needs to gather the necessary debug info for him to rectify this huge problem in the firmware.

(For context: I have 3 Nanoleaf E27/A16 bulbs in spherical fixtures 6 meters/18 feet high. I literally cannot replace them without renting scaffolds to physically get to them! Fortunately those aren't the 3 that are malfunctioning! A firmware may be bad, but a firmware refusing to update is the equivalent of data loss: utterly unacceptable in even beta-level software. Or at least, that's how we treat this level of malfunction in my $DAYJOB 😅)

[craggy plaza]

I am in the same situation. All my bulbs are directly on current. No real light switches. To reset Nanoleaf A19/E27 and GU10 I bought the following:

https://amzn.eu/d/6GWIXpt

https://amzn.eu/d/frgPAAT

Maybe you want to try the procedure with one bulb at least.

[bitter compass]

ooooo

the nest hub update brings TREL!

[craggy plaza]

That doesn’t help us with the Nanoleaf issues. 😉 I have 7 Apple Thread Border Routers, that already use TREL. But good to know that Google now also goes that route (again).

[bitter compass]

Apple have had their own issues too though in the past with Thread, which is surprising given they have been using it for much much longer. But it's not that long ago (last year) that people were constantly have to reboot their Apple devices to make Thread stable again - IIRC it had a lot to do with the Apple 4K

Here are some other Google fixes though:

Matter
Added support for Air Quality Sensor.
Added support for subscribing to all device fabrics.
Added support for Matter update group.
Added transition time handling for commands related to color.

[craggy plaza]

Yeah, I read a lot about it on Reddit. At the time I had 1 hardwired AppleTV 4K that worked as expected. When Apple fixed their issues and launched the OS with TREL support I bought a second AppleTV. 2 or 3 month ago I exchanged some of my Sonos speakers with Apple HomePods (v2/Mini).

[eternal hill]

Have you verified that?

Does not seem like it’s active for me

[bitter compass]

I have verified that that is what they say in their changelog, but like you I do not see Trel when I look in my mDNS entries

[plain kettle]

No, they use fuchsia, but for some reason hasn’t enabled trel despite it apparently able to be enabled

There is no doubt a reason, but it’s just strange

[bitter compass]

they may be waiting to turn it on - they do have a habit of doing that. Slow rollout to watch out for complaints about stuff breaking.

same when they rolled out Thread 1.3

[main matrix]

FWIW, the TREL specific entry: https://fuchsia.dev/whats-new/release-notes/f16

Rolled out TREL which aims to reduce Thread partition and reduce Thread network usage when possible.```

The FW version matches what Google indicated from their FW releases (https://support.google.com/googlenest/answer/7365257#zippy=%2Ccurrent-preview-program-firmware-version%2Ccurrent-production-firmware-version), but it's also not active on my 4 nest hubs gen 2s either.

[plain kettle]

Yet that is

The hubs run fuchsia, but no doubt their is a simple true false command for trel which google can enable when it’s ready

[wild oracle]

@main matrix how has your experience been since this post? we have one user reporting cases where all matter._tcp records disappear (but not ltpdu), so we're seeing if there are other cases. symptom would look like matter control dropping off for one or all multi-admin fabrics.

[main matrix]

@wild oracle All the lights participating in the beta did eventually update, but the last 3 I had took several attempts before the update was accepted (over a dozen attempts from 3 different devices. All Android FWIW).

I had a power outage this morning though. Once power was restored, HA couldn't interact with 12 of my 25 lights (they all displayed as if they had no fabric). To limit the lights ability to communicate with multiple environments, I've now gone HA only for Matter integration, but still using 4 Google Nest Hub Gen 2s as the Matter controllers.

As for services missing, I just had a look at mDNS Discovery and can also confirm all the matter._tcp records disappeared. The only way I've seen to resolve this for now is to have the power off at the light switches for over an hour, and turn back on. Give it 5 minutes and the lights return to the fold.

It's not to say it's without errors though; the lights that returned are throwing resubscription errors within HAs Matter Integration. This may be in conjunction with the timeouts that HA was experiencing trying to poll lights that had no power to them, but can't say for sure.

Happy to provide the HA Matter logs specifically to the Nanoleaf lights that tried to resub (either PM or here, doesn't bother me). My only concern is that I don't know whether the issue stems from Nanoleaf to HA or from HA to Nanoleaf (the HA Matter section of their Discord channel seems to indicate that there are issues specifically with Nanoleaf lights tying into HA Matter, so it may just result in finger pointing, which helps noone).

[wild oracle]

ill DM you

[topaz harness]

Hey @wild oracle on the previous 3.6.xxx release my bulbs were finally stable and I no longer lost connection with Google Home. Now with 48 hours of upgrading to 3.6.152 all my bulbs show offline in Google Home. Are you aware of any issues going on. I have two Google Home Hubs, a Google Wifi Router and a Samsung SmartThings Station all supporting Thread so I don't feel like this should be some sort or range/connectivity issue.

[plain kettle]

Are they all merged into a thread network?

Also, what firmware version is your nest hubs?

[plain kettle]

your google nest devices are on fuchsia firmware 16.xxxx arnt they?

[robust kernel]

I just updated one A19 bulb to the latest beta, I can still reach it through thread on the nanoleaf app, but it is now unavailable in home assistant. Installed version is 3.6.152

[plain kettle]

thread on the nanoleaf app? it talks over BLE if it cant be reached

[robust kernel]

in the connection type section in device settings it says thread

[plain kettle]

you got it paired to google home/apple home?

[robust kernel]

home assistant matter server

[plain kettle]

that it?

[robust kernel]

yes

I've restarted otbr, matter server and home assistant os as a whole in the order of writing with no change in symptom. I have reset the bulb by turning it off 5 times, the bulb flashed red, is not reachable through nanoleaf app and pairing it through home assistant companion does not find the device 🚀

ok, i had to cut power to the bulb once more it seems to connect again.

the pairing failed, and now I'm trying resetting and pairing for the 3rd time without success 🤯

[plain kettle]

You got no other border router?

[robust kernel]

no, I am evaluating matter with one nanoleaf bulb and one eve smart socket and one border router in only home assistant.

pairing failed again with "An error occured". I am pairing from an android tablet running home assistant companion.

[plain kettle]

Same vlan and all that?

Also, have you synced thread credentials in the companion app?

[robust kernel]

as simple as possible, it has worked fine before the latest beta update

[plain kettle]

Ok, so have you synced thread credentials recently on the companion app?

[robust kernel]

not recently, currently trying that

same result after re-synching thread credentials: "an error has occured". The device shows up in ha but is unavailable.

I just spent 45 minutes trying to fix this (beta version before was working fine), I don't have any more time to spare. fortunately this is a non essential bulb. I'll come back later.

[brazen canyon]

@opal sparrow I was testing some other matter lights this weekend and it seems you're right that the SDK can be modified by the vendor to implement transitions

[feral steeple]

I have found if matter server gets restarted its a bit sketchy to get them all connected again. I have had to power off most bulbs and let them reconnect in groups to get them all connected, if i leave all 24 online and restart the server it can be a few hours and random ones still just not connected. but if I leave 8 powered on, wait for it to reconnect, turn another 8 on and wait then the last, they all connect and are happy.

So i guess thats still a big issue in the firmware when something like that happens. makes me nervous to reboot HA. But now I have had 100% uptime for a few days ill try updating matter server and see how it goes.

And just turning off and on some lights all came back but 1, and HA matter server says. So seems something the bulb isnt doing right

2024-03-04 12:59:24 core-matter-server matter_server.server.device_controller[130] INFO Node 23 (re)discovered on MDNS
2024-03-04 13:05:48 core-matter-server matter_server.server.device_controller[130] INFO Node 23 (re)discovered on MDNS
2024-03-04 13:17:00 core-matter-server matter_server.server.device_controller[130] INFO Node 23 (re)discovered on MDNS
2024-03-04 13:27:09 core-matter-server matter_server.server.device_controller[130] INFO Node 23 (re)discovered on MDNS

@boreal surge and one interesting thing that may be helpful. When i had some bulbs that would just not reconnect to HA, when i went into nanoleaf and connected them to google home, they came back online in HA. so I am guessing something got the bulb to respond to a command or something to come back online :S

[robust kernel]

My problem from a little above persists after a cooldown. I've checked the matter server log and indeed there is an error:

2024-03-04 15:16:22 (MainThread) INFO [matter_server.server.device_controller] Starting Matter commissioning using Node ID 7 and IP fd42:9c9e:8ea6:1:1856:c2a8:edb1:64d2 (attempt 1/3).
2024-03-04 15:16:25 (MainThread) INFO [matter_server.server.device_controller] Matter commissioning of Node ID 7 successful.
2024-03-04 15:16:25 (MainThread) INFO [matter_server.server.device_controller] Interviewing node: 7
2024-03-04 15:16:27 (MainThread) INFO [matter_server.server.device_controller.node_7] The SDK is communicating with the device using fd42:9c9e:8ea6:1:1856:c2a8:edb1:64d2
2024-03-04 15:16:27 (MainThread) INFO [matter_server.server.device_controller] Setting-up node 7...
2024-03-04 15:16:27 (MainThread) INFO [matter_server.server.device_controller.node_7] Setting up attributes and events subscription.
2024-03-04 15:16:31 (Dummy-2) CHIP_ERROR [chip.native.EM] Failed to Send CHIP MessageCounter:68460922 on exchange 30872i sendCount: 4 max retries: 4
2024-03-04 15:16:34 (Dummy-2) CHIP_ERROR [chip.native.DMG] Time out! failed to receive report data from Exchange: 30872i

[boreal surge]

Hey there! Please submit a bug report here : https://research.nanoleaf.me/upcoming-quests/chip0001-3-xx-thread-beta-software/ ( password is CHIP0001 ). The bug report form collects the information which we need; but of course add anything else in that's relevant to what you've encountered.

[robust kernel]

you want me to do that as well or do you think there's a way to remedy my problem? my bulb is unusable as per now ...

is there maybe a way to downgrade it without being paired to a thread network? it was working with the previous version ...

[boreal surge]

Yeah, please submit a bug report—this helps us contain all information needed in troubleshooting in one place (a Jira issue, which different product teams work from together).

[robust kernel]

looking at the home assistant discord it seems 3.6.152 breaks home assistant compatibilty (specifically the ability to addd the device to the matter server). just as a word of warning for other people contemplating to update their bulbs.

[topaz harness]

Yes they are on the latest GA builds

[rocky quail]

I'm in a similar situation. 1 out of 6 a19 essentials is still communicating with Google Home Nest over matter thread after a few hours. Saturday, when I upgraded to that latest 152 beta, I had to delete and factory reset all the bulbs to add them to matter. They initially worked great and were quick to respond.

[topaz harness]

Ya I regret taking this latest beta the build before seemed rock solid

[rocky quail]

136 was pretty solid on GH Nest. We may also be experiencing beta version release issues with fuchsia, my Nest Hub Max's and Gen 2 Nest Hubs are on 16.20231130.3.59 https://9to5google.com/2024/03/01/fuchsia-16-nest-hub-whats-new/

[craggy plaza]

Which HA Matter addon/server version are you using? For me it definitely works since I updated Matter to the latest versions (addon 5.4.0, server 5.8.0).

My pairing procedure is:

• delete from Nanoleaf app and all your ecosystems
• reset the bulb to factory defaults
• pair the bulb with HA directly
• share the bulb from HA to Apple Home or other ecosystems

It seems that pairing to HA first it made completely reliable for me. In the past, when it was not possible to share from HA to other ecosystems, I had a lot of problems especially with Nanoleaf bulbs to share from Apple Home to HA.

Did you try that?

[robust kernel]

I have no updates available, matter server is 5.4, i honestly don‘t know how the check the version of the integration, but as mentioned, there‘s no updates available. I only use HA so I can only pair it with HA. I‘ve described my exact procedure above.

[main matrix]

I had a couple of power outages yesterday that knocked out my host and HA VM. Since then, 6 lights haven't come back to life and another 3 are having intermittent connectivity. Interestingly with the intermittent ones; I'm getting ~20% packet loss to the v6 IP for the bulb, but the "stable" ones are < 1% (pings from HA SSH):

1336 packets transmitted, 1050 packets received, 21% packet loss
round-trip min/avg/max = 29.524/152.511/1320.952 ms

--- fdd9:8fb3:82a:1:7ec4:c09e:eaaf:b55 ping statistics ---
1018 packets transmitted, 1000 packets received, 1% packet loss
round-trip min/avg/max = 40.443/72.071/420.377 ms```

Not exactly sure where the packet loss is originating from, but the first pinged light above falls in and out of being reachable in HA every half an hour or so, and has done for the last 12 hours.

[feral steeple]

It took 7 hrs for my one to come back online after it got powered off and on again. The 1 that just wouldnt respond yet HA kept discovering it and trying to connect to it

[wild oracle]

@iron trench @rocky quail you thumbsupped this. does this mean you are also seeing this issue? @topaz harness is this still in the same state for you?

[upbeat mica]

@boreal surge @wild oracle Are there any indications that some of the issues with the GU10 bulbs, like flickering, won't color and dimming, are hardware related?

[topaz harness]

Yes I have lost all control via both Google Home App and the SmartThings App, the only way I can control my bulbs right now is thru your app which means all of the automations and things I have in place or broken at this time.

[wild oracle]

i'll DM you

[wild oracle]

our working theory is that prevalence is related to something hardware specific as it is not reproducible on all GU10s (especially the ones we have to debug with). does that match your observation

[upbeat mica]

I have been thinking lately that it might be. I have 3 bulbs that are really problematic. 2-3 bulbs that have some issues but usually work as intended. And 2-3 bulbs that are solid. It's always the same ones regardless of the beta updates or how many times I factory reset them.

[shell vigil]

@wild oracle same here, sole@bulbs are rock solid and never flickered but some flickers and doesn’t stick to the correct color and 2 of them died completely unless I hard reset them but they will die again

[feral steeple]

Not sure if its related, but the 1 bulb I had that took 7hrs to come back on, if i turned it on and off with nanoleaf app, it was also doing the flickering.

[rocky quail]

I'm still effected. Google Home app can control 2 of the 6 A19 essentials. Earlier today it was just 1 out of 6. They are fine in the Nanoleaf app.

4 Nest Hubs version 16.20231130.3.59

2 Google Wifi model H2D software 14150.882.9

[iron trench]

Yes. All my A19 on my Google Hub Max won’t connect. Only works on NL app and Apple Home.

[feral steeple]

I'm working on a new theory.... My fiance has some kind of weird electric magnetic field going on....
She was away for the weekend and i had 100% connection from the 24x gu10s. Since she has been back have had 3 different bulbs go unavailable over the last 24 hours.... Lol

[rare quail]

2 essentials bulbs out of 3 died in my bedroom after 152 update. Unable to even reset them. 1 resets fine but 2 are dead ☠️ I opened a ticket with support TICKET NO.: 37431

[dull dagger]

Got my thread switch. Thanks NL, waiting for the next instructions...can't open the box, yet. Don't ask 😀

BTW. My led lights strips dropped off thread on 152, but my A19s still holding strong

[frozen crystal]

Yesterday 2 of my 63 bulbs on the latest firmware fell off of the mesh. I left them overnight but had to power cycle them to recover. Perhaps there’s a longer term bug. Has anybody else seen this?

[eternal hill]

I have had the same expirience with my GF. Everything works 100% when she's gone. As soon as she is back home some bulbs start reacting a bit slower and so on

Still not sure if its her or the bulbs that will have to go

[craggy plaza]

This can no longer be a coincidence. I've also noticed that when my wife comes home, some of the lights become unavailable.

[idle tendon]

Just updated to the latest beta firmware for my a19 bulbs and for some reason I can control them perfectly fine in the nanoleaf app but they are ALL unavailable in google home. All connected to thread with google home hubs btw.

[idle tendon]

Same here

[tranquil pollen]

Matter light transitions are coming in the next version of Home Assistant Core!

[brazen canyon]

Btw you should temper your expectations as they are pretty blocky on the NL lights as it uses the default SDK implementation

They won't be smooth like the on off transitions

[wild oracle]

@brazen canyon in terms of "blocky" can you elaborate? have you tested certain transitions that you've seen blocky? note we have at least 1 fix incoming in build hopefully today for beta. not sure if thats related to whaat you're alluding to

[brazen canyon]

The on/off transitions for the bulbs are pretty smooth over the 0.5s interval (popping issue not withstanding)

But color/brightness transitions when the bulb is on is kinda blocky and not smooth.

This is because I'm assuming you're using the default SDK implementation which defines a variable like "stepsPerSecond" to be 10. So if you have a 0.5s transition, by default there's only one step on the transition.

I verified this using websocket commands via HA and also using Google Home (which already has a non-zero transition time).

I've tested other matter bulbs, some have this issue, some don't. So I'm assuming you have to modify the SDK on your end.

After all, there's no transition time available on the admin side for on/off yet there's a nice 0.5s ramp

[rare quail]

any other way to reset it other than off for 3 sec and back on 5 cycles? 2 bulbs are complitely died after 152 update

[wild oracle]

so to briefly summarize, you're doing color transitions over 0.5s and you can see stuttering?

[brazen canyon]

Yeah but "stuttering" isn't quite accurate because it's not a processing issue. It's simply the bulb is only executing one intermediate step between current and new brightness/color

It's easy to reproduce. Set color/brightness using NL app. Set a new color/brightness using the app and observe the smooth transition.

Do the same using a matter admin and you'll see how it's not smooth. I tried on HA and Google Home and the results were the same. I can't comment on Apple Home.

Here's the relevant part in the SDK I mentioned:

https://github.com/project-chip/connectedhomeip/blob/7bf764ab05eb4ef52b007666e822ba963f643922/src/app/clusters/color-control-server/color-control-server.h#L36

Since it's steps per second, you can set a long transition time and it looks quite nice but then it takes forever to perform

[wild oracle]

yup. not sure if you're a chip-tool user, but thats the least overhead and easiest to disambiguate the many possibly problems coming from ecosystems 😄 so trying to get simplest steps to observe equivalent

thanks for reporting.

[opal sparrow]

I've also confirmed this when testing with chip-tool; it's very noticeable if you try to do a transition over, say, 10 seconds that does a large change in brightness or colour.

(I posted about my experiences testing transitions with the A19 bulbs over in https://forum.nanoleaf.me/forum/developer-requests/nanoleaf-essentials-bulb-add-states-transitions-support-with-matter#post_3764 )

I've noticed that it actually seems worse with longer transitions than short transitions, it almost seems like some logic is backwards so instead of doing 10 steps per second, it's doing 10 steps over the entire transition length or something like that?

should try to capture some video, i guess, but it's quite easy to reproduce with chip-tool; just gotta remember that the transition duration parameter to all the matter commands is in deciseconds, so you have to write '300' to do a 30 second transition.

[brazen canyon]

That must be new. I haven't looked at this issue in a few firmwares but when I tried it worked well over long lengths

[wild oracle]

3.6.159 RC Release Notes

Hi #1184371187464290344 we've got our next release that should hopefully address some reported issues:

1. Added proactive Matter resume when booting up or restarting for any reason
2. Fixed an issue where matter or ltpdu records could disappear (please let us know if you still see this! it looks like some or all of your Matter device becoming unreachable eventually)
3. Adjusted Matter reporting timing to avoid unnecessary session disconnects when using multiple fabrics
4. Fixed an issue where matter ramp transitions would look slow/stuttery sometimes (on/off)

We're still working hard on the GU10 flickering issue. Hoping to have an update soon.

We consider this a release candidate, so please let us know any places where you're seeing signficant regressions.

[shell vigil]

Fantastic!!! Good luck, one tip from my side, I have my home being on 2 iPhones and 1 iPad, I have installed the NL app on the 3 devices and set up (just scanning the matter code) on each device to make it available for update and I used 3 devices to update my bulbs …. This just because I have around 35 NL devices 🙂 so it’s 3 times faster … PS the update on iPad is the fastest

[opal sparrow]

ooh, I'll definitely re-test transitions on 3.6.159; i noticed the stuttering/stepping on both on/off (when i increased the on/off transition time above default) and on other transitions, so the cause might be the same for both.

[wild oracle]

@opal sparrow this won't affect what you mentioned i don't think. only on/off ramps (we wer eseeing cases where it became unexpectedly slow sometimes)

although I won't dissuade you from double checking

[opal sparrow]

always found it kinda interesting that you can do updates without the light turning off - i guess you've figured out a trick to leave the hardware pwm controller running while you reboot? ;)

alright, got my 3 bulbs updated. got worried for a moment since one of them didn't immediately re-appear on thread, but it came back on its own after less than a minute.

ah, nice, this appears to also include the fix to return ip addresses in the general diagnostics cluster.

[plain kettle]

Good work siliconlabs 🙃

[opal sparrow]

still has the sample data (room: "bedroom 2", floor: "2", etc) in the Fixed Label cluster, but i haven't seen anything actually use those, so... :)

[plain kettle]

Eventually something will and we start the cycle again

[wild oracle]

yes, i neglected to include that 😉 if you're curious there was also a problem around EUI64 in diagnostics cluster

[wild oracle]

this should be removed. where are you seeing it? chip-tool? or some other ecosystem

[opal sparrow]

I can see those with chip tool, or by running home assistant's Matter device "download diagnostics" which fetches the values of all attributes.

ok, something weird going on… home assistant can't turn off my lights. HA thinks the lights are turned off, but they don't turn off completely - they still glow dimly. the nanoleaf app says they're at 3%.

[plain kettle]

You got any “custom” BR’s; Skyconnect etc etc?

[opal sparrow]

my only BR is the ESP32 devkit.

(so very much "custom", heh)

checked with chip-tool, the bulb is reporting its On/Off Cluster OnOff attribute as false despite still glowing.

using chiptool to turn the bulb on and off with chip-tool onoff on 42 1 then chip-tool onoff off 42 1 gives the exact same behaviour; bulb dims down to a low level but stays lit.

and reports itself as off over matter, but on (now at 1%) in the nanoleaf app

I think the on/off ramps work might have broken something :(

[plain kettle]

Yeah, seems to be real jank now, I’m seeing the same issues

[opal sparrow]

some bugs in the Level Control cluster too; the CurrentLevel is getting stuck at the minimum value despite the spec saying that it should return either the value of OnLevel or a stored value after the transition time completes

[shell vigil]

Managed to crash it

[plain kettle]

Any reasoning for how?

[shell vigil]

I have scene that control all of the bulbs on the same time@

I turned it on and off couple of times

The third time they started to become@unresponsive

After the first attempt I saw 3-4 bulbs non responsive but getting back on track

The third time with the big number unresponsive above

The thread network is not fixing itself

[opal sparrow]

If i had to guess what's going on with the on/off here, it seems like something's breaking in the matter stack in the process of turning the bulb off where once the transition to minimum level completes, it's not continuing to the steps of actually turning the bulb off or updating the Level Control cluster CurrentLevel attribute as required.

[plain kettle]

That’s about the only logical reason I can see without having access to the bulbs source code

[opal sparrow]

this only affects the On/Off cluster commands - using the Level Control cluster MoveToLevelWithOnOff does turn the bulb off.

[plain kettle]

im assuming nanoleaf have some QA testing with some test setups before releasing it. bit suprised it wasnt caught

[opal sparrow]

anyways, i guess i'll file a JIRA so this doesn't get lost on discord.

[plain kettle]

no doubt other people will realise later in the day

[opal sparrow]

oh, got the logic of CurrentLevel wrong. since the bulbs support OnLevel, it's expected that CurrentLevel will be reported as MinLevel after the bulb transitions to off.

[shell vigil]

Now I understood@this

These shows as turned off in my home app

Not in my NL app though

[opal sparrow]

ok, this is weird - now that I've turn off the bulb once with MoveToLevelWithOnOff, it no longer exhibits the behaviour where it stays on when i call Off.

[plain kettle]

yeah, the nl app connects over BLE and completly bypasses the matter stack, so makes sense

[opal sparrow]

the one bulb where I ran MoveToLevelWithOnOff now properly turns on/off with the on/off cluster commands.

well, even when the NL app connects over Thread it still bypasses the matter stack :)

[plain kettle]

oath

[opal sparrow]

i guess one more thing to try, since i have three bulbs - i'll turn one of the bulbs off via the nanoleaf app and see if that fixes the on/off state.

oh, this is fun. i didn't do anything to 2 of the bulbs, but now all of them are turning on/off properly.

[idle tendon]

just updated some of my bulbs to 3.6.159 and they are now consistently unavailable in the google home app.

[plain kettle]

restart your border routers

are they on fuchsia 16.xxxx?

[idle tendon]

Yes

[opal sparrow]

... and now the onoff bug is back in all the bulbs.

[idle tendon]

is fuchsia 16x not working well with them?

[plain kettle]

did it come back after a reboot of all of your BR's?

[opal sparrow]

ok, it turns out that they don't turn off completely with levelcontrol either; it's just kinda inconsistent.

[idle tendon]

No, one or two of them come back online but never all of them

[plain kettle]

is google the only BR's you have?

[opal sparrow]

hmm. changing the setting of OnOffTransitionTime affects the behaviour.

[idle tendon]

Yes. 2 Nest Hub Max and 1 Nest hub gen 2

[dull dagger]

hey does this deal with the eventual offline of the device.
Fixed an issue where matter or ltpdu records could disappear (please let us know if you still see this! it looks like some or all of your Matter device becoming unreachable eventually)

just making sure

as this is the only issue I've beeing seeing

[plain kettle]

somewhat

just do note, if you use HA you might have some issues (as seen above w/ MoveToLevelWithOnOff)

[opal sparrow]

yeah, tricky thing about that is it's really inconsistent :/

it looks like a workaround might be to set the OnOffTransitionTime to 0 - which does not disable transitions like it's supposed to, but instead means you get a really nice smooth off transition instead of the kinda jerky one that you get when a non-0 value is set.

[plain kettle]

doesn't help trying to debug the issue when it sometimes works and sometimes doesn't

[opal sparrow]

(my bulbs came from the factory with the OnOffTransitionTime set to 1 which is supposed to mean 100ms)

there's also another bug in there, setting OnOffTransitionTime only affects the off transition, but not the on transition

[opal sparrow]

alright, if i put a bunch of traffic on the bulbs (apply constant brightness/color updates before turning them off) it happens more often.

[dense maple]

.

[plain kettle]

They have been shipped?

[dense maple]

.

[plain kettle]

Also, you may need the latest TestFlight build of the Nanoleaf app

[plain kettle]

Ah right, I guess they haven’t been certified in Australia yet, hence them not being shipped yet 😅

[dense maple]

.

[opal sparrow]

they haven't posted any instructions yet - they said wait for an email which should be sent this week

[dense maple]

Thanks! I’m just excited to try it out already.

[opal sparrow]

(I can make a pretty good guess on how you're intended to set it up, but they might want us to do something like a field firmware update before anything else. so i'll wait.)

[dense maple]

.

.

[plain kettle]

@boreal surge speaking of, any update for the shipments outside of the US?

[swift phoenix]

These transitions are janky 🥹

[opal sparrow]

hmm, that's weird. while trying to reproduce the on/off issue, i think i crashed one of the bulbs with thread traffic, and now home assistant can't talk to it - doesn't get a response to its attribute and event subscription requests (but i can still control the bulb with chip-tool)

[main matrix]

anyone else noticed that HA seems to sometimes misreport light statuses with this beta/3.6.152? ie. I've had a light off at the switch for the last couple of hours, but HA seems to think it can interact with it. NL app knows it's off, but HA just throws "timeout" errors in the logs, which is correct... but it should also be registering as unavailable, not off.

[plain kettle]

Scroll up

We think we got the root cause of it

[main matrix]

I must be blind :\ only thing I can see if for light transitioning, not full power off at mains.

[plain kettle]

Hmm right

[main matrix]

in my case, the light switch has been off for over 2 hours, and HA just thinks it's fine but just timing out

[plain kettle]

Ah, would be interesting to see if that is HA’s fault with its timeout bounds

[main matrix]

yeah maybe. stupid thing is, the one switch in my case controls 4 lights. 2 are reporting as unavailable (correct), 1 as "off" but has no power (incorrect) and the other has dropped off the Matter fabric completely (???)

also seeing a flurry of resubscription succeeded errors in the logs too, but they have been around for at least 3 betas so am assuming that's a HA thing.

oh good, sporadic light turning on is a thing again. Never had an issue with it in the other betas (I know others have). 🙃

[brazen canyon]

I mean it seems like there's a lot of hand engineering going on the HA end for these NL-specific problems

Before this RC there was a lot of problems reported even with other ecosystems so it will be important to see if that was improved (if so then yeah maybe HA specific issue)

[opal sparrow]

i do have one bulb now which ha can't talk to, but chip-tool can, but i'm gonna leave it to tomorrow before i try to debug that :)

(i'm not hitting "sporadic light turning on", i'm hitting "sporadic light not turning off")

[main matrix]

I've had one light do the same directly after the RC update, but hasn't happened since.

[shell vigil]

Hey Guys with the new firmware did anybody had turned on lights during the night ? I think is one of the issues that came back

[main matrix]

have had one light do it so far, twice, but that's only 1 out of 25 (in my case anyway)

[shell vigil]

Had 3 on this night

With white light

With full brightness

[main matrix]

ouch

[plain kettle]

Feels bad

[shell vigil]

Above my head 😂😂

[main matrix]

https://tenor.com/view/richard-little-richard-light-see-the-light-gospel-gif-16284443

my main problem at the moment is lights not responding to commands :\ (tell it to turn on or off manually, it doesn't).

[shell vigil]

https://tenor.com/view/flashlight-light-flare-darkness-gif-12002582

[shell vigil]

Same here

Constantly from time@time has this bulb is not responding@

[main matrix]

have lodged a JIRA/bug report for it, so might be worth you doing the same.

[shell vigil]

Will do

[craggy plaza]

I also had one bulb that switched on while updating another bulb. Short before I went to bed, a bulb directly in front of me switched on without me doing anything and two bulbs switched on over night.

[wet girder]

Reliability so far on the newest beta has been good after removing from Google home and connecting with matter via the nanoleaf app to the Google home app. Just putting it out there for anyone in a similar boat.

[wind finch]

I still have a number of lights where the _matter services have gone AWOL

For these same lights, HomeAssistant wasn't showing the correct status (ie, on when it was in fact off).

[swift phoenix]

The flashback is back

https://tenor.com/view/guy-fieri-throws-a-flashbang-flash-bang-throw-flash-bang-throw-flashbang-gif-1624218626717156128

[wet girder]

Just had the same thing happen. Woke up to one of my ceiling lights turned on

[wet girder]

And anotha one

[opal sparrow]

Turns out this wasn't true - Home Assistant seems to have just had the old data cached. The updated firmware no longer has the Fixed Label cluster present at all.

[wild oracle]

thanks for confirming 🙂

[dense maple]

I had multiple bulbs turn on even after turning them off and I've only been using the NL app and don't have Home Assistant at all

Started happening after firmware update yesterday

[idle tendon]

Same here. What border routers do you use?

[dense maple]

Eero Pro and Pro 6

[wet girder]

Interesting... I am unfamiliar with eero or how they interact with thread products. Is there a way to control them via your eero app?

[dense maple]

Only options I have are turning thread on or off in the Eero app

[opal sparrow]

So, I managed to reproduce the issue I'm having with Home Assistant not being able to connect to one of my bulbs using chip-tool. It's getting a timeout when attempting to subscribe to all attributes on the light device endpoint. The command to run is chip-tool interactive start then any subscribe-all 0xffffffff,0xffffffff 0xffffffff 0xffffffff 0 60 <deviceid> 1,1 (subscribe to all attributes and events on the Light device endpoint). That sends a big SubscribeRequest, and in response the lightbulb sends a ReportData message with "MoreChunkedMessages = true". chip-tool replies to with a StatusReponse message. At this point, the bulb is supposed to continue with another ReportData message, but it never does and the SDK fails the transaction with a timeout. Interestingly, subscribing to all the attributes on the base device endpoint (use 0,0 on the end of the subscribe-all command) does work.

[opal sparrow]

(filed a Jira issue with the commands that I'm running and the full chip-tool output)

[robust kernel]

Is there a way to update a bulb without it being paired to a thread network? The recent beta broke pairing for one of my bulbs and I only use home assistant with matter server and otbr ...

[opal sparrow]

bulbs can only be updated over bluetooth, thread isn't used at all

[robust kernel]

well it still shows up as not connected in my nanoleaf app

despite being freshly reset

[opal sparrow]

hmm, so that means that the nanoleaf app can't communicate with the bulb over bluetooth either :/

oh, if you reset it then you might need to re-pair in the app?

[robust kernel]

it wont

since last update i have not been able to update the bulb in any way

[dull dagger]

ok, so its not just me about the new FW and weird On/Off with the devices.

BUT they are staying connected 🙂

[robust kernel]

oh, on the second try it seems to work now

[grand pilot]

With the latest beta I've seen the bug where turning off only dims it, but it only affected one light and only through Google Home. Home Assistant and the Nanoleaf app fully turned it off, and after a bit the Google Home app started to fully turned it off also.

[opal sparrow]

@grand pilot nanoleaf app isn't affected since it doesn't use matter apis. I found it happens most often if you turn the bulb off immediately after sending other commands, such as color or brightness updates.

[grand pilot]

Yup, I've tried a bunch of random stuff like rapidly activating different scenes in different orders and all that

[opal sparrow]

i got it to happen about 25% of the time by putting 3 bulbs into an ha group, rapidly sending a few brightness/color updates to the group, then immediately turning off all the bulbs in the group.

(that is, 25% of the time at least one bulb would be affected)

... and then one of my bulbs broke in a weird way and stopped talking to home assistant ;)

[grand pilot]

Do you have a big thread network? Mine is only 3-4 devices so I might not be able to stress it enough to replicate

[opal sparrow]

only 3 devices (all nanoleaf a19s) and one thread border router.

[grand pilot]

What's your tbr

[opal sparrow]

esp32 devkit

[grand pilot]

I have a sky connect, 2 nest hubs, and a nest WiFi

[opal sparrow]

btw, if you're ok with using chip-tool, you can work around the turn off issue by setting the levelcontrol attribute on-off-transition-time to 0. By spec that's supposed to disable on/off transitions (set the duration to 0) but on these bulbs it causes you to get perfectly smooth on and off transitions that match the nanoleaf app's behaviour.

my guess is that there's a conflict in their code in the turn off transition between their own transition code and the matter sdk trying to run the transition configured in matter.

[grand pilot]

I'll have to look into that. I've only heard about it yesterday

[robust kernel]

so i finally managed to update my failed bulb to 3.6.159, but I am still unable to add it to home assistant. It will show up in ha as unavailable, and the pairing process says that an error has occured. so 159 is still broken with HA for me.

[wild oracle]

#1184371187464290344 quick update - we have what we expect will fix GU10 flickering. Based on a number of your reports and our own overnight testing, it seems some of the changes in 159 broke or reopened some latent issues, so we'll revert some of the changes. Hoping to release again today.

Most critical issue for us right now is missing matter mDNS records (the case we fixed isnt the only one apparently), so if you know you see that and I havent already reached out to you in DM, please DM me.

Otherwise, i'll likely work with Paul to get a survey to help us zero in further on that outstanding issue

[craggy plaza]

I am unsure, if I have the same issue like you. I am not able to pair any bulb with any firmware to HA anymore. I resetted a bulb yesterday evening that was unavailable since the complete day. I paired the bulb to the Nanoleaf app again, updated it to the 3.6.159 firmware and resetted it again. After that I tried to pair it to HA directly and also paired the bulb to Apple Home and tried to share it with HA. Both didn’t work. After that I tried to pair completely new bulbs with HA. That also didn’t work.

[dull dagger]

Could you or someone tell me how to check for this? thanks
Most critical issue for us right now is missing matter mDNS records (the case we fixed isnt the only one apparently), so if you know you see that and I havent already reached out to you in DM, please DM me.

[opal sparrow]

@dull dagger https://research.nanoleaf.me/2024/02/verifying-unreachability-issues/ lists a few apps for checking mDNS on some different operating systems/devices.

[wild oracle]

yes, in addition to those instructions, Flame is very useful for correlating different services to their common hostname. ltpdu is the easiest to search for (device ID in our instructions). so filtering in flame by device ID is helpful :https://apps.apple.com/ca/app/flame-services-browser/id325206381?l=sv

[opal sparrow]

if you're on a linux cli, avahi-browse -a is the easiest tool for this :)

[wild oracle]

does this work? this is a sample output i see on an openwrt device:

no way to know who that guy is?

of course, if you konw the exact node id you're looking for, its fine - but i highly doubt anyone but the most advanced HA users will (luckily HA increments monotonically)

[opal sparrow]

well, avahi-browse will show the _ltpdu._udp stuff too

[wild oracle]

yes, but matching the services to device is key in being able to know if/what is missing. for example: in this i can clearly see theres 2 services for this device. so if i expect 3 (e.g. 2x Apple + 1x HA) i know something is amiss

[opal sparrow]

it is unfortunate that the matter dns-sd entries are unpredictable, and you can't associate them with a device unless you know the id that device has within a specific fabric.

(could go backwards by matching ip addresses against the _ltpdu entries, but that's more work; i guess that's one of the nice filtering features this flame tool has?)

[wild oracle]

yes, we previously had to manually match against IP addresses, which was a PITA. this flame browser is much easier (although not very performant)

[opal sparrow]

hmm. looks like if you run avahi-browse --resolve _ltpdu._udp -t then avahi-browse --resolve _matter._tcp -t you'll get all the info needed to correlate them by matching on the hostname or ip. Won't correlate them for you, but the information's there.

[upbeat mica]

Also having this issue. Random lights turning on at different times throughout the day with no trigger

on the latest beta RC

[boreal surge]

@everyone sorry for the at-blast, folks 🙂

For everyone who's been poking at test devices running 3.6.152 or later, can you help us get a contextual view of the impact and fill out this survey? (2-3 mins). Page password is CHIP0001 . Thanks for your help! cc @wild oracle

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

[robust kernel]

@boreal surge can you elaborate on what exactly you mean with "Are you able to check mDNS service presence?"?

[bitter compass]

.... "or later" - and this is the point I discovered that there are firmware updates.....

[civic elbow]

Apparently I need a password?

[boreal surge]

CHIP0001

[civic elbow]

Thank you

[boreal surge]

And, thank you 🙂

[bitter compass]

The Home Assistant build that is rolling out tonight (in about 15 minutes) will support light transitions for matter, so I'm going to update to that and then update the nanoleaf lights - is that ok @boreal surge ? I can fill in the survey after that

[boreal surge]

Yup! If you have tooling available on your network to sniff out mDNS entries... I use ServiceBrowser for Android, Nathan mentiond Flame above, I've seen a few other folks note CLI commands.

I guess what I was trying to ask is, "are you comfortable enough with diag tools to sniff the network?" If no, skip the question 🙂

[boreal surge]

Cool, sounds good. Would you mind just noting that you applied that update in the open comments question at the very end of the survey?

[manic plover]

I've filled in the form, but I sent it too fast, should have added a comment 🙂 Out of ~50 lights on 3.6.152, I have only 11 connected to Thread for about a week now (since the release). It's been much better on previous versions.

[bitter compass]

(on 152 all my A19 bulbs and my matter light strip have been stable and online since I power cycled them all after the update - but they DID all need to power cycled after the update to make them work)

[boreal surge]

Thanks!

[iron pawn]

Filled in the form, my device has been stable with the new firmware & Home Assistant so no complaints.

[grim obsidian]

I filled out the form but forgot to mention one of my lights is exhibiting the 1% on bug. Depending on what app I open I'm getting a different report of what the bulb is doing

[opal sparrow]

hmm, i didn't mention that either since it was asking only about connectivity.

[lethal prism]

Has anyone with 3.6.152 had it start turning on in a real “jerky” mode. Like instead of the power on transition being smooth like it has been, it’s very definite when you can see it go up in brightness. This is on the strips

Oh 3.6.159 was just released I’ll have to try that out when I get home

[true fable]

Weird, I was hoping this latest update would allow me to control my lights via Google Home again, but still nothing. Control in the Nanoleaf app works great, but nothing from Google.

[bitter compass]

OK @boreal surge filled that in. Not an amazing experience so far......

[boreal surge]

What's the firmware version on the lil' bugger?

[frozen crystal]

Oh dear. 159 is a bit of a mess, I’m afraid. Random light turn ons have returned and my mesh will not stabilise at all. It’s a big retrograde step for me, unfortunately (Apple Home including 63 GU10s)

[bitter compass]

(and and the reasonably new ping feature in Home Assistant, does in fact happily ping the essentials light strip. So at this point I'm suspecting that the light strip has simply forgotten all it's matter credentials)

[grim obsidian]

3.6.159

[frozen crystal]

Shame as the previous build was very stable. I really regret upgrading the half I managed to get through 🤦‍♂️

[boreal surge]

Could you note that in the open comments section of the survey? Or, file a bug report? We're actively looking for folks who are having issues with GH fabric.

[true fable]

Sure, no problem!

[grim obsidian]

I don't know what I just did but the 3 of the 4 lights on the outside of my garage are finally controllable through home assistant and Google home over matter. All I did was turn on the lights using the nanoleaf app. Before that they weren't showing up on home assistant or Google home.

And I had updated all the bulbs to 159 last night

[bitter compass]

this is definitely a device that has lost all its matter credentials right?

2024-03-06 22:38:32 (MainThread) INFO [matter_server.server.device_controller.node_16] Unsubscribing from existing subscription.
2024-03-06 22:38:32 (MainThread) INFO [matter_server.server.device_controller.node_16] Setting up attributes and events subscription.
2024-03-06 22:38:33 (Dummy-2) CHIP_ERROR [chip.native.SC] Received error (protocol code 4) during pairing process: src/protocols/secure_channel/CASESession.cpp:1981: CHIP Error 0x000000DB: The Resource is busy and cannot process the request
2024-03-06 22:38:33 (MainThread) WARNING [matter_server.server.device_controller] Unable to subscribe to Node 16:

[frozen crystal]

Urgh, the random turn on thing is certainly back with 159… any chance you could reissue the old build please? 🤷‍♂️🤦‍♂️🤣

[bitter compass]

(nevermind the essentials strip came back eventually)

[wild oracle]

3.6.161 Beta Release Notes

#1184371187464290344 another night, another release:

1. GU10 - now flicker free (pending your verification, of course)
2. Reverted some changes we suspect caused random turn ons (this one's been Sheldon Cooper in a ballpit, but not so funny)
3. The above revert should also get rid of janky transitions some of you noted

Remaining known issues:

1. Matter services disappearing (see Paul's message for lending a hand: #1184371187464290344 message)
2. Sometimes theres slow/stuttery transitions to off which can result in light @1% (already solved, just not in this build). Work around is just to turn the light off again.

If any of you see other unexpected 1% issues beside the one noted above (coinciding with stuttery ramp), please let us know!

[wild oracle]

no. it suggests the deviec is busy. @main matrix has seen it. its unclear so far if it resolves itself (e..g works on next attempt) or if its "terminal" (meaning device must be power cycled)

[wild oracle]

i presume this was related to previous and it resolved itself

[bitter compass]

yes it eventually fixed itself. I had tried power cycling it 3 times and I had rebooted the Google Hubs. Normally one of these 2 things fixes it. But neither did. So I don't know what it was doing while it was "busy"

[main matrix]

Not sure if related still, but every day or so I lose 8 NL bulbs from HAs fabric (usually always 8 and without power outages) every 12-16 hours or so. Yes it's a bit of a broad time frame, but of those 8, I need to cut the mains to the lights for an hour (any sooner and it won't rejoin the fabric).

It happened again just before the announcement of the new beta, and using flame, all of those lights had the .matter services removed.

I'll test and monitor again with the new beta once all the lights have it installed

[dull dagger]

Hi all, So I updated to 161, and it seems HA also had a matter update. My lights are mostly offline in HA but, fine the NL app. So, HA broke something now? Anyone see this, also?

[plain kettle]

No, it’s an issue on NL end

I’ll grab some logs when I get home and update them

[scenic grove]

I updated all our bulbs 6 A19 type to .161 tonight. We’ve been woken up twice to lights turning on by themselves randomly since. Anyone else? Was solid here for us for the last two builds.

[shell vigil]

Woken up 4 times !! Turned them off 6 times this night and I. Total around 7 bulbs were turning on

At the end I turned the switch off

That’s what I am going to do today

[plain kettle]

Geez, that sucks

I dim mine to 1% before I go to bed, so then if they turn on I’m not woken up

[plain kettle]

This not released for the downlights?

[frozen crystal]

Turning a bug into a feature: if you’re going on holiday soon, just schedule a turn-off routine every hour or two, then the random turn-ons will make your house look inhabited 🤣

[main matrix]

just an update; all lights updated to .161 successfully first time (which is a nice change to trying the same light 900 times and failing). Completed the HA Matter server update as well, and lights went offline (expected). Needed to reboot my 4x GHubs for the lights to interact again, but they're all up and running so far.

Seems either the NL beta or the HA Matter update has removed the IP addresses from the lights again, though. BUT, the resubscription errors I was getting flooded with are no longer a thing, so... small wins?

[wind finch]

Mine still shows the IP’s. But I think there is a change in that it used to show them all, now it only shows the main one.

[main matrix]

hmm, just rebooted HA and yeah they do come back. Not sure about the "main" one but I think multiple IPs appear if they're on different ecosystems at the same time (multi-admin)

mine is only 1 set of IPs now that its HA only

[verbal drift]

So upgraded to .161 and gu10's dropped off. Power cycled and now a few are requiring setup through the nanoleaf app. Which is annoying and what is really interesting the lamps were set to 75% and now the ones working are showing 74% which is weird.

[plain kettle]

it will always be one set of ips now

they get the ip from mdns, mostly due to paticular vendors like you know who not following the diagnostics cluster

[plain kettle]

Well this is a first

Don’t think the downlights had wifi 🙃

[scenic grove]

Yeah we had quite a few more last night. Whack a mole with lights 🙂

[robust kernel]

I am still unable to pair my bulb with home assistant and otbr. I am able to pair the bulb through the nanoleaf app onto the home assistant otbr thread network, but not with home assistant. I also notice it's nowhere mentioned in the known issues?

[grim obsidian]

I'm guessing this is related to the stuttery ramp, but after updating to 161, 2 of my 9 A19 bulbs are showing 1% on. They were off when I did the upgrade. I checked Google home and home assistant and they're showing the same thing. Turning the lights on and off in the nanoleaf app was slow to respond at first but eventually became near instant

Those 2 bulbs are now showing as offline in home assistant and Google home

[wild oracle]

likely a consequence of a different fixed bug in 161.

[wild oracle]

feel free to DM me with any logs you may have. there is a known issue we've been working together with HA on. its unclear if any of the issue is due to our firmware - just unfortunately uncharted territory.

[wild oracle]

possible due to known issue.

[dull dagger]

This would be great to confirm. Because all my lights are unavailable in HA but they show that they're connected to a thread Network in the NL app. I've restarted matter server ha and even my thread border routers

[opal sparrow]

@dull dagger to see if your situation matches a known issue, it would be good to check MDNS to see if the _matter._tcp entries for your bulbs in HA are present. Please also check the HA "Matter server" add-on logs for any messages like "Time out! failed to receive report data from Exchange <number>"

[dull dagger]

Hey thanks for that information! I'm not at home to check the actual device but on my matter server logs I do see what you're talking about for example

CHIP_ERROR [chip.native.DMG] Time out! failed to receive report data from Exchange: 23534i

[opal sparrow]

ok, that means you might be hitting the issue I reported where the bulb is having a message sequencing issue when ha attempts to subscribe to all attributes/events on the bulb. If you can set log_level_sdk in the matter server add-on config up to "progress", look for a sequence of messages like this: 2024-03-07 10:19:48 (Dummy-2) CHIP_PROGRESS [chip.native.EM] >>> [E:64716i S:14375 M:124410467 (Ack:260687188)] (S) Msg RX from 1:0000000000000002 [F1B5] --- Type 0001:05 (IM:ReportData) 2024-03-07 10:19:48 (Dummy-2) CHIP_PROGRESS [chip.native.EM] <<< [E:64716i S:14375 M:260687189 (Ack:124410467)] (S) Msg TX to 1:0000000000000002 [F1B5] [UDP:[fda9:d862:9078:1:c50b:f556:e6be:fce7%enp8s0]:5540] --- Type 0001:01 (IM:StatusResponse) 2024-03-07 10:19:48 (Dummy-2) CHIP_PROGRESS [chip.native.EM] >>> [E:64716i S:14375 M:124410468 (Ack:260687189)] (S) Msg RX from 1:0000000000000002 [F1B5] --- Type 0000:10 (SecureChannel:StandaloneAck) 2024-03-07 10:20:01 (Dummy-2) CHIP_ERROR [chip.native.DMG] Time out! failed to receive report data from Exchange: 64716i 2024-03-07 10:20:01 (Dummy-2) CHIP_PROGRESS [chip.native.DMG] Will try to resubscribe to 01:0000000000000002 at retry index 7 after 123186ms due to error src/app/ReadClient.cpp:638: CHIP Error 0x00000032: Timeout

(This isn't HA specific, although I suppose HA is kinda special in that it does a subscription on all attributes/events; i've reproduced it with chip-tool)

[swift phoenix]

Same message here. Found that restarting matter server will sometimes correctly pair with bulbs but most of the time not

[opal sparrow]

(this issue can be summarized as follows: during the subscription process, the bulb says "heres some report data, oh and i have some more to send", the controller goes "ok, got that report data, send the next set of data", and then the bulb… never does)

[verbal drift]

Office lights set off but still on, turned off with Apple and showing 1% on Nanoleaf app

[dull dagger]

ok, I upped to sdk logs and I see this... what is interesting is that is says it sees all devices discovered on MDNS (5 nodes), but still not avialable in HA. it just repeats the time out failed
http://pastie.org/p/7fo6krVQzf4itG7ghqQXA9

[tranquil pollen]

These two latest releases have been a step backwards. Connectivity issues and random power losses.

[bitter compass]

had multiple not available in home assistant issues today, each time it's taken a reboot of the Google Home hubs to bring them back into Home Assistant. They didn't stop being available in Google Home at the time. @wild oracle @boreal surge

[main matrix]

currently doing that for mine at the moment 😦 - went from 3 unavailable, to 7, to 15...

[dull dagger]

at least they come back for you...mine are 100% down in HA

even after device, TBR and HA reboots

usually, the first 2 would do it

[bitter compass]

I had that yesterday, I just had to leave it - device reboots and thread router reboots made no different - Home Assistant complained that the device was "busy" (and then went on to say the subscription succeeded even though it didn't). But after about 2 hours, magically devices came back on their own 🤷

[main matrix]

curious; have any of the lights unavailable still show up in Flame? (if you have anything iOS to check).

at least 2 A19s (for me anyway) have lost ALL service records (not just matter, but ltpdu as well)

[bitter compass]

I'm Android. But the lights do show up in Service Browser - which makes sense, because Home Assistant constantly "finds" them on mDNS, but just can't do anything once it's found them

[main matrix]

I'm also Android, but found an iPhone in a drawer (that I thought I threw against a wall at some point, still works 🤷‍♂️ ).

[bitter compass]

That happened to me on the first v1.2 matter update we got for these lights. The lights were intiially available after the update, but there must have been cached discovery information in the border routers for them. Once that expired all the lights went unavailable until after a power cycle

[main matrix]

HA logs for mine at the moment are a wash of timeouts, returning cached IP results and failed to receive report data.

[main matrix]

right. the usual power cycle or leave off for an hour and turn back on had fixed it in the past

not so lucky now... some have been off for over 6 hours and just turned them back on, and noone is home

[bitter compass]

and to make things worse - both my Onvis sockets were offline this morning when I woke up too - which never happens until the Nanoleaf bulbs start misbehaving, they clearly aren't routing thread traffic sometimes

[main matrix]

yeah, my Aqara P2s started doing similar

[bitter compass]

I guess if they are too busy to respond to home assistant, they must be too busy to route traffic too

[main matrix]

Seems that way 😦

guess I'll just leave them and hope for the best

[bitter compass]

concerning though that a single dodgy thread device can bring the whole network down, not quite as resiliant as I was lead to believe the network was

[main matrix]

yeah, though that's a whole other conversation 🙃

[bitter compass]

I just have to remind myself - Zigbee was like this at the start..... So it'll get better

[main matrix]

yeeeeeep; my 38 Zigbee devices are just sitting in the background laughing while eating popcorn as they have been reliable as ever.

[bitter compass]

and to a lesser extent - even my zwave stuff is still happily doing it's thing, slower, than zigbee but still stable

[versed vault]

Seeing the same with one of my essentials bulbs on 161

[opal sparrow]

I should note that if you're seeing messages like Time out! failed to receive report data from Exchange in the HA Matter server logs, that means discovery is working and HA is able to talk to the bulb over the thread network. It has to have exchanged several messages with the bulb to authenticate and ask the bulb to send report data before it can timeout waiting to receive report data.

[dull dagger]

so is the firmware the cause?

[opal sparrow]

it looks like a firmware problem with how wildcard subscriptions are handled, yeah. matter has pretty strict limits on number of concurrent subscriptions and number of attributes monitored per-subscription, and HA wants all the data updated constantly, so they currently do one wildcard subscription per device.

i narrowed it down a bit in my testing; a wildcard subscription on endpoint 0 (the root device, where basic information, network provisioning, diagnostics, etc. are located) works fine, but a wildcard subscription on endpoint 1 (the light device, with the on/off state, brightness, color, etc.) doesn't work.

[opal sparrow]

kinda suspiciously, the report data commands during the subscription on cluster 1 return all the data upto but not including the manufacturer extension cluster 0x115a_fd01

[wild oracle]

may be invalid unless you're seeing it on only some of your devices. note that in 3.6 we've introduced a custom cluster on endpoint 1. for chip-tool i believe you need custom changes in order for it to deal with things possibly

sounds like you've come to possibly the same conclusion.

for HA, it definitely works sometimes. i believe marcel will open up a ticket somewhere with more details

[opal sparrow]

i can read the attributes on the manufacturer extension cluster fine with stock chip-tool using chip-tool any read-by-id 0x115afd01 0xffffffff 43 1 (it doesn't know how to format them when printing the logs, but the debug output dumps the binary data).

oh, now this is interesting. The bulb that I had with this issue was part of 2 matter fabrics - HA and chip-tool. I added chip-tool to a second bulb to investigate what was different - and now i see the same problem on the second bulb

I unpair chip-tool, and the bulb starts working again in HA

so the trigger for this might be that a bulb is part of more than 1 matter fabric?

... i unpair chip-tool from the bulb that was initially having this issue, and home assistant picked it back up too

so the initial cause of the issue was the fact that i paired a bulb to chip-tool when investigating the "stays on at 1% when turned off via matter" issue; after pairing to chip-tool, home assistant was no longer able to do its wildcard attribute subscription.

[brazen canyon]

Pretty sure there was already speculation that multi fabric was causing issues since it's more taxing on the hardware

[feral steeple]

Guess ill wait for the next update with all these issues reported! Will do a couple bulbs to test. On 152 and mostly good with the new HA matter server update, and they show the ipv6 addresses for the bulbs with the new matter update, so thats nice.

[plain kettle]

Would be nice to update them if the down lights had the new update

[upbeat mica]

@wild oracle So after updating to 3.6.161 I noticed quite a few changes with my 8 GU10 bulbs. I factory reset all my bulbs after the update. Setting up the bulbs is really fast, but I did get a "could not execute" or something similar in Apple Home when renaming the the bulbs, but it worked if I just tried again. The "identify" function now works again.

As for the performance of the bulbs. They're very snappy and responsive. Most of the flickering is gone, however, my problematic bulbs are still very problematic, and even more so now. Bulb nr 2 will sometimes not respond, take forever to get to the correct color, still flickers a bit and will dim randomly. Bulb nr 3 will flicker a bit and dim and brighten randomly quite often, it's also hard to get it to display the right color. Bulb nr 7 is now in constant dim mode and is also not always showing correct color, it does not flicker though. I think bulb nr 6 might flicker a little bit, but that's about it. The rest of my bulbs seems to be working very well after this latest beta. *knock on wood.

I do think that my problematic bulbs are not going to get better regardless of the firmware though. I feel like they're just bricked or there's some hardware issue. Would it be possible to arrange an exchange of new bulbs if you get my problematic ones in return? Feel free to DM me

[wild oracle]

if the bulbs were not problematic on 3.5, there should be a software approach to ensure they remain that way on 3.6. this continues to be our top priority. we have some further differences we did not account for in 161, especially as it relates to random turn ons. hoping to release again today in a few hours

[shell vigil]

That’s great!!

[wild oracle]

the changes incoming relate to timings, so its possible it may help to address the flickering. the only unit we have that we were developing with today had the state evaporate. so if anyone knows of reliable methods to force GU10s back into this state, that would be great

[upbeat mica]

They have been problematic since I got them and through all the betas. But if you think another beta or two is worth the wait I'm willing to wait.

Like I don't remember exactly how they were at the start of all this, but for many betas they've been problematic.

[wild oracle]

yes, the GU10 flickering issue was identified for us at the beginning of feb. we've never (TMK) had reports of it in the field (3.5), so given its prevalence here, we're pretty confident its a regression introduced by software. Matter 1.2 sped things up (which helps in some areas, but oobviously hurts in others)

so far we had no confidence in a GU10 fix until 161, and the only reason we think the next build MAY help is because there were some more timing related things we found as differences between 3.5 and 3.6 - but i can't assure you of the fix this time.

we had a unit we were about to test, but the original problem evaporated before we could try the new code.

[shell vigil]

I had flickering before feb

[wild oracle]

i am presuming you did not have it until first coming to the beta though

[shell vigil]

But I didn’t know about discord back then

Plus o thought that was a normal behaviour from time to time 🙈

[upbeat mica]

I'll wait another beta or two then. But if it's still isn't fixed, by then, on my problematic bulbs, would it be possible to get them exchanged?

[plain kettle]

you live in the US or elsewhere?

[upbeat mica]

Norway

[plain kettle]

ah no stress then, you can just go back to where you brought them from and exchange them then

unless you got them from the nl website

[upbeat mica]

I'm not sure if the retailer would be so keen on replacing bulbs 6 months after purchase, but I will try if Nanoleaf won't do it with me directly.

[plain kettle]

i would just say they are faluty and you would like a replacement, that normally does the charm

[bitter compass]

I hope this is not the case, since we are talking about just 2 fabrics, and I believe the bare minimum that should be supported is 3 but the recommended is 5. If it is causing issues at 2, that's a huge issue.

[wild oracle]

3.6.165 Release Notes

1. Reverted some additional changes that may have caused random turn ons. Also added stronger protections where we suspect its coming from (yet another issue that's eluded our debug bulbs)
2. Reverted some changes that were leading to janky transitions
3. Eliminated flickering ramps that could occur in some scenarios

Known Issues:

1. GU10 flickering.
2. Matter services can sometimes disappear
3. HA subscription error can block pairing or connectivity: https://github.com/project-chip/connectedhomeip/issues/32493
   #1184371187464290344

[plain kettle]

is this one gonna be released on the downlights as well 🙈

[wild oracle]

its there? not showing for you?

[plain kettle]

Not sure if it’s related to how it thinks it’s paired or not?

Best way just to factory reset them?

[wild oracle]

hmm. is this ios or android?

[plain kettle]

ios, on the testflight bulid

10.5.0 (595)

[wild oracle]

try just jumping to re-pairing direct with Nanoleaf app (no reset needed perhaps). there was a bug on 159 that broke connections (dedup) with Apple Home.

[plain kettle]

ah yep, that was it 😅

cheers!

[dull dagger]

Thanks the new FW update

Is this issue the reason why I don't see any of the devices in HA?
https://github.com/project-chip/connectedhomeip/issues/32493

[plain kettle]

it is possible

[main matrix]

I wouldn't think so; if that were the case, there should be a lot more reports of NL lights going AWOL. All 25 of mine appear just fine.

[verbal drift]

.161 for me broke a lot of things
.165 I think is a little better in terms of connectivity. Although I have two GU10's not responding in apple home, but showing ok in NL app.

[frozen crystal]

Good luck. I’m regretting moving so many bulbs on from .152 which had proven pleasantly stable. Now attempting .165

The mesh stability and rebuild speed on .152 seemed very good

I also have one GU10 which refuses to update even though it has connectivity. I feel another reset coming on…

[plain kettle]

Yeah, this build is all around much better

[wraith bear]

Hey team, how are the new nanoleaf 3.5 inch downlights, in terms of the hardware itself vs the matter bulbs. Any improvements?

[plain kettle]

good

[wraith bear]

Better hardware?

[plain kettle]

i dont wanna open mine

but it would run a similar siliconlab SOC

if not the same

[wraith bear]

Ohh, so pretty much same stuff

[plain kettle]

yeah, we know the bulbs run the MG24,

[wraith bear]

I hope it's a capable chip? These things run really hot btw

[plain kettle]

its rated for a much higher temp that what it runs at, heat really isnt an issue

[wraith bear]

Ohh that's promising, I was getting worried lol

[wraith bear]

Jeez, 125 degrees is hot.... i could cook eggs on it

Btw how often do we see beta updates?

I'm new here. I'm enabling beta tomorrow

[plain kettle]

every few days

one got released a few hours ago

[wraith bear]

Ohh that's a good thing then, I guess that will reciprocate to the downlights also?

[plain kettle]

yes