Z2M, Philips Hue, and updating brightness without turning on

Configuration
1

Hello everyone,

I’m looking for some guidance on a specific automation challenge I’m facing with my Home Assistant setup.

I have a number of Philips Hue lights connected through Zigbee2MQTT (Z2M). I’m trying to create a script that adjusts the brightness of these lights without turning them on if they are currently off.

My current script uses light.turn_on which, as expected, turns the light on and sets the brightness. I

I tried, since I’m using Z2M, to send a direct MQTT command to bypass this behavior, but it doesn’t work. The MQTT message contains “status:ON” which seems to turn on the light. Writing “off” keeps the light turned off, or turns the light off, and disregards the brightness level.

Do you have any suggestions on how achieve with a script as follows;

If light is on, change brightness
If light is off, change brightness but don’t turn the light on yet, make sure they when light turns on, the new value of brightness is taken

Thanks!

1 Like
2

Send an MQTT message to zigbee2mqtt/Friendly Name/set with payload {"state":null, "brightness": 254}

2 Likes
3

I’m not sure if all (or any) Hue lights support changing the brightness while the light is off.

If you’re not seeing that functionality working with "state": "OFF" or with "state": null (the latter as suggested above), you might need to use a scene that is programmed with Z2M.

1 Like
4

Thank you!

I managed to change indeed the brightness value while OFF, and also in the Z2M user interface the new value of brightness is visible - however, when turning the light on, it picks up the former value, not the current one…

Any idea what else I could do?

An alternative would be to edit helper values:

  • if light is ON, an Automation would update the brightness of the light
  • if light is OFF, a dedicated script would turn on the light with a pre-defined value of brightness taken from the helper

I’d like to avoid it because of the hassle in maintaining all those helpers.

Thanks!

1 Like
5

Like Dominic said before, not all devices support this feature. I used it with IKEA lights running on latest firmware (ZB3). I read somewhere that newer Hue lights (with BT) also support this, but I never use it myself.

Try also to send this payload to zigbee2mqtt/Friendly Name/set:

{"level_config": {"execute_if_off": true}}

This needs to be done just once. I believe that the outcome of this option is to write value 0x01 to attribute 0x000F of Zigbee cluster 0x0008 to enable pre-staging. If your device does not support this, I expect that you should get some error in the Z2M logs.

Hope this helps.

Edit: To enable color / color temperature pre-staging use this payload:

{"color_options": {"execute_if_off": true}}

Or combine both in a single payload:

{"level_config": {"execute_if_off": true}, "color_options": {"execute_if_off": true}}
1 Like
6

I have a definitive solution for you that works for hue lights and - excitingly - allows them to be locally bound to [Inovelli] switches and works seamlessly, with no log errors/light staggers/duplicate commands. (Ataraxia Lighting is my own internal name ;))

This blueprint is a setup blueprint that configures hue lights from scratch for my preferences. It creates the correct settings for each of your lights to accept and report light and color commands while off. FYI read through the full blueprint to understand what all it does. zigbee2mqtt required. Make sure your lights have the latest firmware.

You need to run this once and select your lights. It does not need to be run on reboot as far as I can tell.

https://raw.githubusercontent.com/mnestrud/ha_random/refs/heads/main/Ataraxia%20Lighting%20-%20Hue%20Defaults.yaml

I recommend that anyone who uses this adopt it as their own - in other words expect it to change without warning.

Next, in whatever adaptive loop you have, send this mqtt publish command when it is on:

Base Topic/My Light/set

{
  "state": "ON",
  "brightness": <bri>,   // 1–254
  "color_temp": <mired>  // 153–500 mireds
}

and this one when it is off:

Base Topic/My Light/set

{
  "state": null,
  "brightness": <bri>,   // 1–254
  "color_temp": <mired>  // 153–500 mireds
}

You can validate all this with developer tools → actions and select mqtt.publish.

I have the default adaptive lighting hacs plugin running with no light targets to calculate my brightness and color settings and then a master loop that goes through my rooms and runs one of these commands every 90 seconds, pulling the correct brightness and color from the adaptive lighting plugin switch. (Separate configuration and commands are required to get the inovelli switches working)

1 Like
7

Thank you ataraxia and dandanache! I’ll try both!

8

Thanks a lot!
It works like a charm, and now I can implement automatic color temperature changing