Develco/Frient KEYZB-110: Status LED never lights up because GetPanelStatus command is ignored (FW 2.0.6, converter still affected)

What happened?

The Develco/Frient KEYZB-110 keypad correctly arms/disarms via Alarmo, the buzzer works correctly (confirmed after firmware v2.0.6 + PR #12328), and battery/tamper/linkquality all report normally. However, the status LED never lights up, regardless of firmware version or how the panel status is confirmed back to the device.

Setup

• Zigbee2MQTT 2.14.1 (zigbee-herdsman-converters 26.105.0)
• Home Assistant OS, MQTT integration
• Alarmo for alarm state management
• Custom automation that publishes to <friendly_name>/set:

  {"arm_mode": {"transaction": <matching action_transaction>, "mode": "<matching action>"}}
  

  immediately upon receiving a keypad action/action_transaction/action_code — verified via trace that the transaction number matches exactly.

Troubleshooting already done

1. Confirmed the correct MQTT arm_mode payload (matching transaction and mode) is published immediately on every keypad action.
2. Confirmed via zigbee2mqtt/<name> topic that the device receives and processes commands (state changes correctly, arming/disarming works via Alarmo).
3. Updated firmware from 2.0.5 (131077) to 2.0.6 (131078) via custom OTA URL — this fixed the buzzer regression described in #31761 / PR #12328, but did not fix the LED.
4. Confirmed no open sensors / arm_failed conditions were interfering (alarmo_failed_to_arm cases were separately ruled out and resolved).

Suspected root cause

Looking at src/devices/develco.ts, the KEYZB-110 definition includes:

fz.ignore_iasace_commandgetpanelstatus

This means Zigbee2MQTT explicitly ignores the device's GetPanelStatus command (IAS ACE cluster) rather than responding to it. Per the Zigbee IAS ACE spec, the keypad appears to rely on a GetPanelStatusResponse (not just an unsolicited panelStatusChanged) to correctly drive its LED indicator. Since Z2M never answers this request, the LED may simply never receive the information it needs, regardless of what arm_mode payloads are published separately.

This would also explain why the LED reportedly works when the device is paired to Develco's own gateway or other systems that fully implement the IAS ACE handshake, but not through Zigbee2MQTT.

What did you expect to happen?

The status LED should light up correctly when armed/disarmed, matching the behavior described in the technical manual and observed with the manufacturer's own gateway.

Suggestion

Consider replacing fz.ignore_iasace_commandgetpanelstatus with an actual commandGetPanelStatus → iasGetPanelStatusResponse handler (similar to what's already used for consistent audiblenotif responses per PR #12328), so the device receives a proper panel status response instead of having its request silently dropped.

Related issues

• #28118 (closed as stale, same underlying symptom on FW 2.0.5)
• #31761 (buzzer regression on FW 2.0.6, fixed via #12328)

---

What did you expect to happen?

The status LED should light up correctly when armed/disarmed, matching the behavior described in the technical manual and observed with the manufacturer's own gateway.

How to reproduce it (minimal and precise)

see above

Zigbee2MQTT version

newest

Adapter firmware version

newest

Adapter

sonoff

Setup

ha green

Device database.db entry

No response

Debug log

No response

Notes

No response

Start in src/devices/develco.ts and trace the KEYZB-110 definition, especially fz.ignore_iasace_commandgetpanelstatus. Compare the existing audiblenotif response handling and the suggested commandGetPanelStatus to determine how the IAS ACE response is wired. Done means the keypad's status LED reflects armed and disarmed states while preserving the existing arm_mode behavior.