Koenkk / Koenkk/zigbee2mqtt

Shelly Dimmer Gen4 - no Zigbee message sent on local button press despite correct binding/reporting config

Open
#32,890 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

problem
Dominant language
TypeScript
Stars
15.7k
Forks
2k
Avg merge
18h 55m
Merged PRs (30d)
35

Description

What happened?

On/off and dimming via the physical button connected to a Shelly Dimmer Gen4 (S4DM-0A101WWL, running Zigbee firmware) work correctly, and the state change is reflected immediately in the Shelly app (read locally). However, Zigbee2MQTT and Home Assistant (via Z2M) do not receive any update when the state is changed locally via the button. The state shown in Z2M/HA only updates when a command is sent from Z2M/HA itself, and even then it's only an optimistic echo of the sent command, not a device-originated report.

The device has full native support in Zigbee2MQTT (model S4DM-0A101WWL, "Native support" confirmed in the frontend — not an externally/auto-generated definition), so this does not appear to be a device-support/converter gap.

Binding and reporting are confirmed correctly configured:

  • Endpoint 1 is bound to the Coordinator for clusters: genOnOff, genLevelCtrl, haElectricalMeasurement, seMetering
  • Reporting configured for genOnOff/onOff (min 0s, max 65000s) and genLevelCtrl/currentLevel (min 5s, max 65000s, min change 1)

Device firmware is confirmed up to date (20260710-101113 / app version 2.0.0, g87fbfa4).

Z2M log evidence: when pressing the physical button, no incoming MQTT/Zigbee message from the device appears in the log at all. Only outgoing .../set commands sent via the Z2M frontend are visible, and the device's "Aktuelle Aktivität" (last activity) in the frontend only reflects that same remotely-triggered change (state ON → OFF at the exact timestamp of the outgoing command), not the button press. This suggests the local button handler on the device firmware does not trigger any Zigbee transmission at all — despite correct binding/reporting on a natively supported device.

Note: Availability tracking ("Zuletzt gesehen") is currently disabled for this device, so it's possible the device silently loses its Zigbee connection between commands — though the physical button and app control keep working via a different local channel (likely BLE), which is why the failure isn't otherwise noticed.

What did you expect to happen?

I expected that pressing the physical button on the Shelly Dimmer Gen4 would trigger a Zigbee attribute report (onOff / currentLevel) to Z2M, updating the state in Z2M/HA to match what the Shelly app shows.

How to reproduce it (minimal and precise)
  1. Pair Shelly Dimmer Gen4 (Zigbee firmware) with Z2M
  2. Confirm binding (Coordinator, endpoint 1, clusters genOnOff/genLevelCtrl) and reporting configuration
  3. Toggle/dim the light using the physical button connected to the device
  4. Observe: Shelly app updates instantly; Z2M log shows no inbound message; Z2M/HA state does not update
Zigbee2MQTT version

2.13.0

Adapter firmware version

7.4.5 [GA]

Adapter

Sonoff Zigbee/Thread PoE Dongle Max (EmberZNet)

Setup

Home Assistant OS Add-on, running on Raspberry Pi 5 (arm64).

Device database.db entry

No response

Debug log

No response

Notes

No response

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reproducing the physical-button toggle on the Shelly Dimmer Gen4 with Zigbee2MQTT 2.13.0, checking the Z2M log, binding, and reporting configuration described in the issue. Compare device-originated traffic with outgoing frontend commands and determine whether the native S4DM-0A101WWL support receives a report; done means local button changes produce matching Z2M and Home Assistant state updates.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
backend, networking
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.