- 4058075729025 (E27 RGBW) — ✅ fix landed upstream: PR #13322, merged and released in
zigbee-herdsman-converters26.114.0 (zigbee2mqtt ≥ 2.14.2). Nativepower_on_behaviorexpose now available — this script is no longer needed for this model on an updated installation. - 4058075729087 (E14 Tunable White, "B40 TW T") — ⏳ same symptom confirmed via manual testing (this repo), upstream fix not yet applied. Workaround still required.
This workaround is intended only for older or otherwise compatible LEDVANCE SMART+ Zigbee devices that support the standard StartUpOnOff attribute but do not expose the power_on_behavior option in zigbee2mqtt.
If power_on_behavior is already available in the device exposes, use the native zigbee2mqtt option instead.
A small Python utility that sets the Zigbee StartUpOnOff attribute on compatible LEDVANCE SMART+ bulbs through zigbee2mqtt and MQTT.
Some older-generation LEDVANCE SMART+ Zigbee bulbs, such as model 4058075729025 (SMART+ E27 RGBTW), do not expose a power_on_behavior option in zigbee2mqtt. After a power outage, they may always turn on when power is restored.
LEDVANCE support confirmed that this behavior is not configurable through the product interface and that no firmware OTA update was planned for this product generation.
The missing option in zigbee2mqtt is a converter/exposes limitation for the affected model; it does not necessarily indicate that the bulb lacks the underlying Zigbee capability.
The bulb can implement the standard Zigbee Cluster Library StartUpOnOff attribute in the genOnOff cluster (0x0006, attribute 0x4003). zigbee2mqtt can read and write this attribute through its raw MQTT command, even when the friendly power_on_behavior property is not exposed.
Possible values for startUpOnOff:
| Value | Behavior after power is restored |
|---|---|
| 0 | Stays off |
| 1 | Turns on |
| 2 | Toggles the previous state |
| 255 | Restores the previous state |
This workaround has been tested with older-generation LEDVANCE SMART+ RGBW E27 and Tunable White E14 bulbs whose zigbee2mqtt exposes did not include power_on_behavior.
Compatibility with other devices is possible, but must be verified individually.
- Python 3.
- A running zigbee2mqtt installation.
- MQTT access to the zigbee2mqtt broker.
- A compatible Zigbee device that supports genOnOff / StartUpOnOff.
- The device must already be paired to the Zigbee network.
The project uses a Python virtual environment. The environment is created locally and is intentionally not included in the repository.
From the project directory:
python3 -m venv venv
source venv/bin/activate
python -m pip install -r requirements.txt
Create the local configuration file:
cp config.py.example config.py
Edit config.py and enter the MQTT broker settings. Do not publish this file: it may contain credentials.
To verify the installed dependency:
python -m pip show paho-mqtt
From the project directory:
py -m venv venv
.\venv\Scripts\Activate.ps1
python -m pip install -r requirements.txt
Copy-Item config.py.example config.py
Edit config.py with the MQTT broker settings.
To verify the installed dependency:
python -m pip show paho-mqtt
The current release uses paho-mqtt 1.x. The dependency is constrained in requirements.txt to versions greater than or equal to 1.6 and less than 2.0:
paho-mqtt>=1.6,<2.0
This constraint avoids the callback API changes introduced in paho-mqtt 2.x. The virtual environment ensures that the project uses the declared dependency instead of a globally installed Python package.
Activate the virtual environment before running the script.
Set the behavior for one device:
python fix.py --device Z2M_BulbName --value off
Set the behavior for multiple devices:
python fix.py --device Z2M_Bulb1 Z2M_Bulb2 --value previous
Accepted values for --value:
- off
- on
- toggle
- previous
The device names must match the friendly names configured in zigbee2mqtt.
Before using the script, you can test the device directly from the zigbee2mqtt Dev Console.
In the Dev Console, the zigbee2mqtt/ base prefix is implicit and must not be included in the Topic field.
Topic:
<FRIENDLY_NAME>/set
Payload:
{"write":{"cluster":"genOnOff","payload":{"startUpOnOff":0}}}
The read command reads directly from the device rather than from a cached state.
Topic:
<FRIENDLY_NAME>/set
Payload:
{"read":{"cluster":"genOnOff","attributes":["startUpOnOff"]}}
The result should appear in the zigbee2mqtt log, for example:
zhc:tz: Read result of 'genOnOff': {"startUpOnOff": 0}
Version v1.0.0 of the script sends the write command but does not verify the Zigbee write automatically. After running the script, check the zigbee2mqtt log for a message similar to:
zhc:tz: Wrote '{"startUpOnOff":0}' to 'genOnOff'
If zigbee2mqtt reports UNSUPPORTED_ATTRIBUTE, the specific device firmware does not support this workaround.
The script confirms that it sent the MQTT message, but that is not the same as confirming that the bulb accepted the Zigbee attribute write.
The setting affects the device behavior after power is restored; it does not change the normal on/off command behavior during regular operation.
- v1.0.0: write-only operation with manual verification.
- v1.1.0: optional automatic verification through zigbee2mqtt/bridge/logging, requiring debug logging to MQTT to be enabled.
MIT - see LICENSE.