SC500ZB blinds endpoint not writeable anymore

[dmbuil]

What happened?

In the past, I used this workaround to overcome the accumulated calibration drift when handling the blinds on LoraTap SC500ZB.

It is a Home Assistant automation that, whenever 0% is reached, sends a MQTT message to overwrite the SC500ZB currentPositionLiftPercentage so that the position is reset.

The automation stopped working some time ago (don't know when exactly: the drift depends on the blinds' usage), as the endpoint is not writeable anymore:

[8/1/2026, 0:00:27] z2m: Publish 'set' 'write' to 'lora_blinds_3' failed: 'Error: Attribute currentPositionLiftPercentage (8) is not writable'

What happened? Any ideas for a workaround?

What did you expect to happen?

The endpoint to be writeable back again.

How to reproduce it (minimal and precise)

Send a MQTT message:

• topic: zigbee2mqtt/<device-id>/1/set
• payload: {"write":{"cluster":"closuresWindowCovering","options":{},"payload":{"currentPositionLiftPercentage":10}}}

It will fail

Zigbee2MQTT version

2.7.2

Adapter firmware version

20210708

Adapter

sonoff ZBDongle

Setup

Home-Assistant Green, Add-On

Device database.db entry

No response

Debug log

[8/1/2026, 20:23:58] z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/lora_blinds_1', payload '{"backlight_mode":"ON","calibration":"OFF","calibration_time":20,"calibration_time_to_close":20,"calibration_time_to_open":23,"calibration_to_close":"OFF","calibration_to_open":"OFF","indicator_mode":"off","linkquality":36,"motor_reversal":"OFF","moving":"STOP","position":7,"state":"OPEN","switch_type_curtain":"flip-switch"}'
[8/1/2026, 20:23:59] z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/lora_blinds_1', payload '{"backlight_mode":"ON","calibration":"OFF","calibration_time":20,"calibration_time_to_close":20,"calibration_time_to_open":23,"calibration_to_close":"OFF","calibration_to_open":"OFF","indicator_mode":"off","linkquality":33,"motor_reversal":"OFF","moving":"DOWN","position":7,"state":"OPEN","switch_type_curtain":"flip-switch"}'
[8/1/2026, 20:24:00] z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/lora_blinds_1', payload '{"backlight_mode":"ON","calibration":"OFF","calibration_time":20,"calibration_time_to_close":20,"calibration_time_to_open":23,"calibration_to_close":"OFF","calibration_to_open":"OFF","indicator_mode":"off","linkquality":36,"motor_reversal":"OFF","moving":"STOP","position":0,"state":"CLOSE","switch_type_curtain":"flip-switch"}'
[8/1/2026, 20:24:00] z2m: Publish 'set' 'write' to 'lora_blinds_1' failed: 'Error: Attribute currentPositionLiftPercentage (8) is not writable' # <--- Here the automation is triggered
[8/1/2026, 20:24:02] z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/lora_blinds_1', payload '{"backlight_mode":"ON","calibration":"OFF","calibration_time":20,"calibration_time_to_close":20,"calibration_time_to_open":23,"calibration_to_close":"OFF","calibration_to_open":"OFF","indicator_mode":"off","linkquality":36,"motor_reversal":"OFF","moving":"STOP","position":0,"state":"CLOSE","switch_type_curtain":"flip-switch"}'

Notes

No response

[Nerivec]

Per Zigbee specification, this attribute should be not writable.

We introduced Zigbee specification enhancements on clusters (attributes/commands) in last release to prevent uncontrolled behaviors.
For example, with TRV devices, we've found that while you can write any value to some attributes (according to data type), devices will internally change them to the supported range...
This can result in inconsistencies or even truly undesired effects. The new behavior will catch this at the lower levels of Z2M instead and alert the user to the problem. Of course we can adjust said behavior depending on devices, some may go off-spec and customize ranges and such...

However, in the case of this attribute, write being allowed sounds more like a firmware bug. The percentage is a calculated value based on open/close limits and current position. Writing it would likely mess with the internal state... with unknown results.

[dmbuil]

Thank you very much for the thorough explanation, @Nerivec. I didn't know about the last update.

Thing is, the SC500ZB-v4 allegedly has end stop as per the product info, but it seems there is some issue with it, so the HA automation was the only workaround I came up with.

I'll try to fine-tune calibration times separately for up and down, but most probably I will have to perform a full cycle every couple of days to force a reset.

[huco95]

Per Zigbee specification, this attribute should be not writable.

We introduced Zigbee specification enhancements on clusters (attributes/commands) in last release to prevent uncontrolled behaviors. For example, with TRV devices, we've found that while you can write any value to some attributes (according to data type), devices will internally change them to the supported range... This can result in inconsistencies or even truly undesired effects. The new behavior will catch this at the lower levels of Z2M instead and alert the user to the problem. Of course we can adjust said behavior depending on devices, some may go off-spec and customize ranges and such...

However, in the case of this attribute, write being allowed sounds more like a firmware bug. The percentage is a calculated value based on open/close limits and current position. Writing it would likely mess with the internal state... with unknown results.

I'm having this issue with other devices. Is there any workaround to still be able to write to those attributes?

[sortns]

I have also issue with a few devices which stopped to be writable. Surprisingly cause it works perfectly before.
Should we roll back to previous "non-fixed yet" version?

p.s. works again after roll back to 2.7.1. Seems to need to wait until we get fix for "fix" :)

[Koenkk]

Fixed! (if not provide the data/database.db entry of your device).

Changes will be available in the dev branch in a few hours from now and in the next release which is every 1st of the month.