Unable to set previous in Color temp startup

[jintaojie]

What happened?

Unable to set previous in Color temp startup，clicking the button did not send the corresponding command to the device

What did you expect to happen?

No response

How to reproduce it (minimal and precise)

No response

Zigbee2MQTT version

2.12.0-1

Adapter firmware version

2025101

Adapter

snoff-e

Setup

virtual machine

Device database.db entry

No response

Debug log

No response

Notes

No response

[jintaojie]

log.log

[jintaojie]

Root Cause Analysis:

The error from the log:

z2m: Publish 'set' 'color_temp_startup' to '0xb40ecfd314d70000' failed: 
'Error: Status 'INVALID_VALUE' startUpColorTemperature requires max of 65279'

In zigbee-herdsman 10.x, a local attribute value validation was added to the endpoint.write() path. The startUpColorTemperature attribute definition includes max: 65279 along with special: [["SetColorTempToPreviousValue", "ffff"]].

When the user selects "previous" in the frontend, zigbee2mqtt correctly maps it to value 65535 (0xFFFF) and calls entity.write("lightingColorCtrl", {startUpColorTemperature: 65535}). However, before the ZCL write frame is actually sent over the air, zigbee-herdsman's local validation checks the value against the attribute's max field. It finds 65535 > 65279 and throws an INVALID_VALUE error immediately — the packet is never sent to the device.

The bug is that the validation logic enforces the max boundary but does not exempt values defined in the special array. Per the ZCL specification, 0xFFFF is a legitimate special value for startUpColorTemperature meaning "restore previous color temperature on power on", and should bypass the max: 65279 range check.

Fix direction: In zigbee-herdsman's attribute write validation, when a value exceeds the [min, max] range, it should also check whether the value matches any entry in the attribute's special list before rejecting it.

[andrei-lazarov]

• duplicate of startUpColorTemperature requires max of 65279 #31452

I'll try to fix