I have AL mostly pointed to z2m groups (for an entire room’s downlights), but also a few individual bulbs that aren’t in groups (e.g. floor lamps, sconces).
From that trace, it looks like you’re using the first version of the automation I posted. Try the second one, since the original author made it a little cleaner and I added a few more checks.
Do you have any AL instances that don’t control any lights at all? I wonder if that would cause the undefined attribute error you’re getting.
Thanks. I am still getting the same error. I copied your second one exactly. I have all of my AL instances pointed at the groups since they are all connected to a dimmer switch with one exception where I have a light on the nightstand that just has a Hue bulb.
I did verify that all of the instances are pointing to something. I may just try to recreate them all. For each instance, I have the adapt_color and adaptive_lighting switches turned on. Adapt_brightness and sleep_mode are turned off.
I will have to dig into this error with chatgpt and see if I can find the issue. I also published the execute_if_off command for each of my light groups. I can’t see anywhere if it took, but the commands ran with no error. No idea if that will help or not. Just a wild stab I took.
By the way, I do appreciate all of the help and will work on this some more. Thanks again.
So I think I may have found my issue. When I look at the configuration attribute of the Adaptive Lighting switch I just see {} and no actual lights. I tried to define one of my instances in yaml and there was no change. Still shows the same in the Developer Settings. Not sure what is going on.
Your current trace error is slightly different, right?
The screenshot you shared before showed a step Define variables adaptive_lighting and adaptive_lighting_lights, but those variable names don’t exist in the newer script (they should be adaptive_lighting_entity and lights_currently_off_and_controlled_by_adaptive_lighting_entity in the new one).
I can maybe help prevent some burning of unnecessary cloud computing cycles by pointing to the spots to investigate.
There’s only one place in the automation an attribute named lights is being used: line 16 state_attr(adaptive_lighting_entity, "configuration").lights. That means one of the items in your enabled_adaptive_lighting_entities list doesn’t have a lights attribute. That list is being created by getting all of the entities provided by the AL integration, filtering so that their names start with “switch.adaptive_lighting_” but not “switch.adaptive_lighting_adapt_” or “switch.adaptive_lighting_sleep_mode_” (see the definition of the enabled_adaptive_lighting_entities variable). Maybe look at all of the entites in HA developer tools that match those criteria and see if they all have lights attributes and nothing else looks fishy?
Oh, and to answer the question about z2m groups – this automation will push { execute_if_off: true } to each light/group controlled by AL. So your groups will get that once the script successfully runs. I don’t believe that will then cascade down to the lights within the group, but it sounds like you’ve already got the property set on those.
I deleted all of my AL instances and created a new one. Still see no lights in the integration and getting the same error as belore. I tried both the group and the individual lights. No change in the error.
I get what you are seeing. I think it is because you have switches in the groups like I do. I am trying to find the right place to filter to only lights. As an example, NOT sure this works yet:
variables:
configured_light_entities_provided_by_mqtt: |-
{{integration_entities("mqtt") |
select("match", "^light\.") |
expand |
map(attribute='entity_id') |
list}}
enabled_adaptive_lighting_entities: |-
{% set ns = namespace(entities=[]) %}
{% for entity in integration_entities("adaptive_lighting") |
select("match", "^switch\.adaptive_lighting_adapt_color_.*") |
expand |
selectattr("state", "==", "on") %}
{% if state_attr(entity.entity_id, "configuration") is defined and
state_attr(entity.entity_id, "configuration").lights is defined %}
{% set _ = ns.entities.append(entity.entity_id) %}
{% endif %}
{% endfor %}
{{ ns.entities }}
I will try that when you get a chance. Although I tried with just the bare bulbs and got the same error. In Developer Settings, what do you see for your adaptive_lighting switches. This is what I see.
I have Inovelli switches controlled by some of my Adaptive Lighting components. The switches are HA light entities, so they should appear in the AL entity’s lights list. But the switches don’t accept color_temp commands. The original version of the script would run fine, update color on all of the color lights, and log z2m errors for brightness-only entities. The current version filters out any light entities that don’t accept color_temp, so no unsupported commands are sent.
I have light groups assigned in the Adaptive Lighting.
There will be another error later on that I will need to work through. The code assumes that zigbee2mqtt is the mqtt topic, but I have multiple zigbee networks and will need to have it adjusted based upon the specific lights that are pulled into the script.
And in the states explorer under developer tools, your AL switch’s configuration attribute is {} like larryo108’s instead of something like this?
Are you guys configuring your AL entities with the GUI, or some other way? I’m not sure why the configuration attributes aren’t in there for you.
For multiple base topics, that sounds tricky. Is there a way to look up the mqtt info of a HA light entity? I’d think you’d need to do that, because AL only knows about the HA light entities. Maybe the original author of this automation has an idea (see the link to AL’s github in my post from this morning)
Oh my. This sent me down a rabbit hole. I had no idea that mqtt allowed setting values while off. That’s pretty nice. I don’t want to switch over from ZHA, so I did some digging and found a lot has been uncovered since I last tried to change Hue light settings while they’re off.
I just finished it, so I’ll come back and update it if I find any problems. Thanks for the continued discussion here!
Edit 3/21 at 11:15am: Move code to a Gist (the link is to the version discussed in this post, but it’s since been enhanced to support brightness for non-smart loads).
Well now that I’ve got something to adjust Hue bulbs that are off, I’m anxious to try to get something similar for the Inovelli switches that control dumb, dimmable bulbs.
My switches are still configured with the default for parameter 13 which means they revert to the prior dimming level. I can think of two ways to “adjust” these switches while the load is off:
Change parameter 13 to match the brightness defined by Adaptive Lighting. This seems like it may be error prone and/or get the switch stuck in a state of restoring a brightness that I don’t really want it to be in.
Determine some custom Zigbee command that can be sent to let the switch know that the last brightness level should be some other value. I don’t know what this command would be nor where to find it. I’ve looked a bit in the ZHA and z2m source for possibilities, but didn’t see much that looked promising.
THANK YOU!!! That was it. I never would have thought of that. I am seeing it all in Developer Settings now. This is what I am seeing in the automation trace now. Next step to figure out.
That’s also what my trace timeline looks like in my (working) setup.
Do you have any lights that are off right now that were last set at a different AL temperature? My guess is you can turn them on without a color shift.
If not, maybe open up your Z2M logs and watch them as you manually trigger the automation?