NanoLeaf matter bulbs won’t dim .196

@support-agent I’ve just updated to .196 and found I can no longer dim my NanoLeaf matter bulbs from Hubitat.

They turn on and off without issue, they just won’t dim.

I’ve just upgraded my HomePods to v18.0, but that didn’t make any difference. Dimming worked/s fine from Apple Home, just not Hubitat.

@bobbyD @gopher.ny

Ok, a reboot didn’t solve it, so I rolled back to .193 and dimming works perfectly again.

@gopher.ny

What specific model are these, and what driver are you using? How are you specifically trying to dim? Any errors in Logs? (Enabling debug logging also can't hurt but probably won't show anything helpful here.)

I value my marriage, so Im not re-upgrading to .196 just to collect logs.

Im using the default Hubitat drivers and the Bulbs are Nanoleaf Essentials Matter version paired via Apple Home (I have multiple HomePod Mini's).

This question was intended to verify that you are using Generic Matter RGBW Light, as I'm not familiar with their entire product line and it's possible they have others. From the limited description, I assume the A19 RGBW bulbs that I also have and can test with (and am pretty sure I did).

Also, I'm still wondering: what specifically are you doing? For example, using a dashboard, the mobile app, or "Set Level" directly from the device detail page?

If you had errors, they may still be in your Past Logs at this point, so it's still worth a look.

Yes, that is the default and works great prior to .196 - all 6 bulbs look like this:

That's just it, there were Zero errors, it simply didnt change the level.

All of the above - I'm in IT (I run a Change, Incident & Problem function), and I'm not a hubitat n00b (I support multiple Hubitat device integrations).

I am asking these questions because I was the last person to modify the driver and need to confirm which driver it was and what you are actually doing, not as an assessment of anyone's skill level. Thanks for the confirmation!

2 Likes

Sorry for the grouchy response, Im tired and need more coffee ... it's been a long week and it's only wednesday.... :persevere:

1 Like

I've found a problem in the Generic Matter RGBW Light driver, a two-character "typo" leftover from a change I made when testing both some driver changes and a proposal for changes in the underyling Matter code. FWIW, there would indeed have been an error logged for this (a groovy.lang.MissingMethodException).

Other drivers were not affected even though they have similar changes.

This should be fixed in the next build. Thanks for the report!

3 Likes

I went through the logs and did not see this at all.

Awesome, thank you.

I just had another look, and the only odd entries I found looked like this:

Im blaming a lack of Caffeine for missing these...... :man_facepalming:

1 Like

I don't see anything odd with those, nor do I see use of "Set Level" as mentioned above (which is what I fixed), only "Set Color Temperature." I did not have any problems with that command in my testing (anymore; there was a fix for either CT or level actually not being set if the bulb was off to start--forget which), though I do see a similar issue to the one I was trying to fix before where a rate of 0 is probably ignored and using the default instead, so I'll look at that, too...

If anyone is having problems with this, the same information as above would be helpful to troubleshoot. :slight_smile:

The very first line (at the bottom of the list) = "Rumpus Room Lamp was set to 58%".

Now who needs caffeine? :wink:

I still don't see it. That's just a report from the device. From the rest of the log entries, you appear to have debug logging enabled, which would show the corresponding command being run. That is what I don't see (normally would be the line right before this). It would look something like setLevel(100).

Such a report could come in for a variety of other reasons, including a refresh, periodic report (if configured), or other command that sets level, like Set Color Temperature.

Hmmm, apparently I didn't look back far enough. :man_facepalming:

I dont see any level set commands tho - I was trying all sorts of things, device, dashboard etc. So I asume that the level changes are reports from me chaging it via HomeKit.

Still not seeing my particular error, but what I found was definitely something that was a problem that should be fixed. :slight_smile:

Your error in this screnshot is something else; you must have been using a custom driver for this device before, one that scheduled a job (some community Zigbee drivers do; haven't seen this for Matter but I haven't looked at any, and it's possible) that does not exist in the stock driver, so you'll need to go to Logs > Scheduled Jobs to remove it for this device if you want that to stop, among other ways you can do the same. This would only cause this error in your logs, not any other problems -- though I suspect you'd still see one like mine (a missing exception involving "setLevel") if you have logs far enough back to show it, and that one was probably causing your problem.

1 Like

I've never used community drivers for NanoLeaf bulbs, I simply havent had a need to - the Official matter driver has been excellent from day 1.

Something like that has to have happened, even if that was an accident -- there are no scheduled jobs made in the built-in Matter RGBW Light driver (but that method name is a popular one for community drivers that do the same, hence my guess as to what it was). In any case, the solution for that is as above — though again, the only real issue here is the log entry itself letting you know this scheduled job isn't doing anything.

Closest I can give to proof if anyone wants it :D

No worries, maybe it was due to Daylights trying to change the CT.

Reminds me I need to make similar changes to allow 0 transition times in the CT drivers... :slight_smile:

2 Likes