[Bug] Sinope TH1123ZB-G2 & TH1124ZB-G2 backlight auto dim off doesn't work

[lemoinem]

What happened?

When trying to set my TH1123ZB-G2 & TH1124ZB-G2 to backlight auto dim off, it remains as sensing. The off value simply doesn't work. I've tried both the UI and through Developer Tools, Actions.

What did you expect to happen?

I expect the thermostat's backlight to remains ON at all time when backlight auto dim is set to off.

How to reproduce it (minimal and precise)

1. Set a TH1123ZB-G2 or TH1124ZB-G2 to backlight auto dim off.
2. Turn off the light in the thermostat's room.
3. BUG: The display's backlight turns down.

Zigbee2MQTT version

2.6.3 (unknown)

Adapter firmware version

{"build":0,"ezsp":13,"major":7,"minor":4,"patch":5,"revision":"7.4.5 [GA]","special":0,"type":170}

Adapter

EmberZNet

Setup

os: #1 SMP PREEMPT Tue Nov 4 14:31:07 UTC 2025 - 6.12.51-haos - arm64
node: v22.16.0
ha: true

Device database.db entry

I don't know how to find the database.db file

Debug log

[25/11/2025, 22:54:22] zh:ember:uart:ash: <--- [FRAME type=DATA]
[25/11/2025, 22:54:22] zh:ember:uart:ash: <--- [FRAME type=DATA ackNum=3](ackRx=3 frmTx=3)
[25/11/2025, 22:54:22] zh:ember:uart:ash: <--- [FRAME type=DATA ackNum=3 frmNum=5](frmRx=5) Added to rxQueue
[25/11/2025, 22:54:22] zh:ember:uart:ash: ---> [FRAME type=ACK frmRx=6](ackRx=3)
[25/11/2025, 22:54:22] zh:ember:ezsp: <=== [CBFRAME: ID=69:"INCOMING_MESSAGE_HANDLER" Seq=146 Len=38]
[25/11/2025, 22:54:22] zh:ember:ezsp: ezspIncomingMessageHandler: type=UNICAST apsFrame={"profileId":260,"clusterId":2820,"sourceEndpoint":1,"destinationEndpoint":1,"options":320,"groupId":0,"sequence":24} packetInfo:{"senderShortId":55946,"senderLongId":"0xFFFFFFFFFFFFFFFF","bindingIndex":255,"addressIndex":255,"lastHopLqi":255,"lastHopRssi":-27,"lastHopTimestamp":0} messageContents=18180a0b05293500080521d200
[25/11/2025, 22:54:22] zh:controller: Received payload: clusterID=2820, address=55946, groupID=0, endpoint=1, destinationEndpoint=1, wasBroadcast=false, linkQuality=255, frame={"header":{"frameControl":{"frameType":0,"manufacturerSpecific":false,"direction":1,"disableDefaultResponse":true,"reservedBits":0},"transactionSequenceNumber":24,"commandIdentifier":10},"payload":[{"attrId":1291,"dataType":41,"attrData":53},{"attrId":1288,"dataType":33,"attrData":210}],"command":{"ID":10,"name":"report","parameters":[{"name":"attrId","type":33},{"name":"dataType","type":32},{"name":"attrData","type":1000}]}}
[25/11/2025, 22:54:22] z2m: Received Zigbee message from 'basement.office.thermostat', type 'attributeReport', cluster 'haElectricalMeasurement', data '{"activePower":53,"rmsCurrent":210}' from endpoint 1 with groupID 0
[25/11/2025, 22:54:22] z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/basement.office.thermostat', payload '{"backlight_auto_dim":"off","current":0.21,"enable_outdoor_temperature":null,"energy":null,"keypad_lockout":"unlock","linkquality":255,"local_temperature":19.2,"main_cycle_output":"15_sec","occupied_heating_setpoint":19,"outdoor_temperature_timeout":7200,"pi_heating_demand":20,"power":53,"running_state":"heat","second_display_mode":"auto","system_mode":"heat","temperature_display_mode":null,"thermostat_occupancy":null,"thermostat_outdoor_temperature":3,"time_format":"12h","voltage":null}'

Notes

Last health check

time: Tue Nov 25 2025 23:27:52 GMT-0500 (Eastern Standard Time)
os.load_average: 0, 0.02, 0.05
os.memory_percent: 24.9177
process.memory_percent: 2.722
process.uptime_sec: 1811

[lemoinem]

The issue seems to be that the codes for sensing and off are reversed. Setting the backlight to sensing actually gives the off behavior.

I'll check if I can provide a PR later.

[nongagf]

@lemoinem I believe the fix caused a regression for all other Sinope models with auto-dimming. The TH1320ZB-04 for example only has on_demand and sensing (no off option).
I get this error when trying to set backlight_auto_dim to sensing:

z2m: Publish 'set' 'backlight_auto_dim' to 'plancher_sdb' failed: 'Error: ZCL command 0x500b91400006650f/1 hvacThermostat.write({"SinopeBacklight":2}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"reservedBits":0,"manufacturerCode":4508,"writeUndiv":false}) failed (Status 'INVALID_VALUE')'

[scoulombe79]

Same regression here since the last upgrade...

z2m: Publish 'set' 'backlight_auto_dim' to 'Thermostat (office)' failed: 'Error: ZCL command 0x500b91400001c6dd/1 hvacThermostat.write({"SinopeBacklight":2}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"reservedBits":0,"manufacturerCode":4508,"writeUndiv":false}) failed (Status 'INVALID_VALUE')'

[lemoinem]

Uh. Sorry about that. I'll try to prepare a PR to revert my change and offer a better fix in the next few days. Would you be able to test it? Since I don't have the devices, I can't test it myself.

…

On Fri, Jan 2, 2026, 9:58 AM scoulombe79 ***@***.***> wrote: *scoulombe79* left a comment (Koenkk/zigbee2mqtt#29828) <#29828 (comment)> Same regression here since the last upgrade... z2m: Publish 'set' 'backlight_auto_dim' to 'Thermostat (office)' failed: 'Error: ZCL command 0x500b91400001c6dd/1 hvacThermostat.write({"SinopeBacklight":2}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"reservedBits":0,"manufacturerCode":4508,"writeUndiv":false}) failed (Status 'INVALID_VALUE')' — Reply to this email directly, view it on GitHub <#29828 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABZL4GSJ5O3LIRXAOENZXD4E2BPPAVCNFSM6AAAAACNG5RUVOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTOMBVGUZDSNRQG4> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[nongagf]

I won't be home to test until mid-January. But I was able to force-set {"SinopeBacklight":1} in the Dev Console and can confirm that the auto-dimming now behaves like it should in sensing mode (always on, auto-adjusting intensity).

[xetalx]

Exact same issue here. I cannot fall back to sensing anymore on the TH1300ZB. Note that some thermostats have 3 toggles and some other have only two. Example :

The ones with only two options are broken now and cannot go back to "sensing".

[xetalx]

Uh. Sorry about that.

I'll try to prepare a PR to revert my change and offer a better fix in the
next few days.

Would you be able to test it?
Since I don't have the devices, I can't test it myself.
…

Uh. Sorry about that.

I'll try to prepare a PR to revert my change and offer a better fix in the
next few days.

Would you be able to test it?
Since I don't have the devices, I can't test it myself.
…

If you revert the change it will test it for you no issues at all before.

So you know, since this change i have 3 thermostats with dim screens and i cannot put them back to sensing.

Merci beaucoup !

[lemoinem]

Hey everyone,

I'm so sorry for breaking all your configs. I have sent Koenkk/zigbee-herdsman-converters#11236 in order to revert my change.

I'll try to setup a new fix when time permits and will request feedback here once the fix is ready so it can be properly tested with your devices.

If you have been affected by the change (either positively or negatively) and would like to test the new fix, please keep an eye on this issue.

[lemoinem]

@Koenkk I'm trying to find a way to implement a better fix for this.
Essentially, I'm thinking into providing some options/parameter to fzLocal.thermostat and tzLocal.backlight_autodim so I can pick which version of the enum to use. Then I could adjust the -G2 thermostats (and those only) so they use the new enum.

If other devices need to switch device (based on community feedback), I'll address that as separate PRs if needed, I guess. Or it should be easier for other contributors/users to submit such PRs themselves. But at least I won't break everyone's device again (I want to renew my apologies for that by the way, both to you and the community at large).

tzLocal.backlight_autodim is easy-ish, because I can just have a separate converter backlight_autodim2 or something. Although I'd prefer a similar approach for both tz and fz converters. Seems easier to follow what's happening.

But the the fzLocal seems harder to me. There are the meta and options parameters, but I'm not sure where the data in there come from and whether I could use it. But it feels like the best avenue.

I don't know if I could convert it into a factory closure? It seems overkill and could impact a lot of devices.
Splitting away the common part and having two separate fzLocal seems a tad difficult to do. It doesn't seem to be designed for modularity.

I'm looking for advice and open to suggestions on how to implement this the cleaner way, essentially. Especially since I can't really test the code with my setup, I'd like to minimize back-and-forth.