GX03 (_TZE284_8zizsafo): incoming /set via friendly_name topic silently ignored, IEEE address topic works

What happened?

What happened?

For device GIEX GX03 (manufacturer _TZE284_8zizsafo, model GX03), publishing a /set command to the topic based on the device's friendly_name is silently ignored (no reaction, no log output whatsoever, even with full debug logging enabled). The exact same payload published to the topic based on the device's IEEE address works correctly and switches the valve as expected.

Outgoing state publishes (device → MQTT) correctly use the friendly_name topic (zigbee2mqtt/Ventil_2er_1). Only the incoming direction (/set) for this specific friendly_name topic is affected.

What did you expect to happen?

Publishing to zigbee2mqtt/<friendly_name>/set should behave identically to publishing to zigbee2mqtt/<ieee_address>/set, since the documentation states: "The FRIENDLY_NAME is the IEEE-address or, if defined, the friendly_name of a device or group."

How to reproduce it (minimal steps)

1. Device is paired and has a friendly_name configured in configuration.yaml:

   devices:
     '0x781c9dfffe13d95e':
       friendly_name: Ventil_2er_1
   

2. Confirm the device publishes state correctly under the friendly name:

   mosquitto_sub -h <broker> -t 'zigbee2mqtt/Ventil_2er_1/#' -v
   

   → State messages (including valve_1, valve_2, etc.) are published correctly under this topic.
3. Send a set command using the friendly_name topic:

   mosquitto_pub -h <broker> -t 'zigbee2mqtt/Ventil_2er_1/set' -m '{"valve_1":"ON"}'
   

   → No reaction. No corresponding log entry appears even with:

   advanced:
     log_level: debug
   

   (initially also tested with log_namespaced_levels: z2m:mqtt: debug explicitly set, after discovering it was previously set to warning — still no entry for the incoming message).
4. Send the exact same payload using the IEEE address topic instead:

   mosquitto_pub -h <broker> -t 'zigbee2mqtt/0x781c9dfffe13d95e/set' -m '{"valve_1":"ON"}'
   

   → Works immediately. Valve switches on, confirmed both physically and via subsequent state publish on zigbee2mqtt/Ventil_2er_1.

Troubleshooting already performed (to rule out other causes)

• Confirmed via MQTT broker's own client/session list: no duplicate/zombie MQTT client connections.
• Confirmed Z2M's MQTT subscription is a broad wildcard zigbee2mqtt/# (via broker's own SUBSCRIBE log), which covers the friendly_name topic.
• Confirmed via a neutral third-party mosquitto_sub client that the broker correctly delivers messages published to zigbee2mqtt/Ventil_2er_1/set to all subscribers.
• Confirmed Z2M does receive and process other incoming MQTT messages from the same broker connection without issue (e.g. zigbee2mqtt/bridge/request/permit_join works immediately).
• Confirmed no duplicate/stale device entry in database.db for this IEEE address (grep -c returns exactly 1 match).
• Confirmed no duplicate/conflicting entry in configuration.yaml (single, correctly formatted friendly_name entry, same format as all other working devices).
• Confirmed the device is not a delayed-delivery "sleepy end device" issue: tested immediately after the device sent an unsolicited Zigbee message (proving it was awake/reachable) — friendly_name /set still had zero effect.
• Compared against Z2M's own frontend: When switching via the Z2M web UI (which works correctly), the browser's WebSocket traffic shows it publishes to 0x781c9dfffe13d95e/set (IEEE address) — not the friendly_name topic. This suggests the frontend itself may be working around the same underlying issue, rather than confirming friendly_name-based /set as untested-but-working.

Zigbee2MQTT version

Please fill in: <run 'zigbee2mqtt/bridge/info' or check frontend footer>

Adapter firmware version

EmberZNet, coordinator firmware 7.4.4 [GA] (from zigbee2mqtt/bridge/info → coordinator.meta)

Adapter

EZSP/EmberZNet (Silicon Labs based coordinator)

Setup

• Zigbee2MQTT running as a systemd service, connecting to a self-hosted MQTT broker (FHEM MQTT2_SERVER).
• Device joined and renamed via configuration.yaml devices section (not via zigbee2mqtt/bridge/request/device/rename MQTT API — unclear if this is relevant).

Device

• Model: GIEX GX03 (2-zone watering timer)
• Manufacturer: _TZE284_8zizsafo
• IEEE address: 0x781c9dfffe13d95e
• Zigbee model: TS0601

Additional context

This is a fairly unusual and hard-to-reproduce symptom since it only affects the friendly_name-based /set direction for this one device, while every other direction/topic (state publish, bridge commands, IEEE-based /set) works normally. Happy to provide further debug logs, database.db excerpt, or configuration.yaml excerpt if helpful — already have full command-by-command reproduction history from an extensive support session.

What did you expect to happen?

No response

How to reproduce it (minimal and precise)

No response

Zigbee2MQTT version

2.12.1

Adapter firmware version

EmberZNet, coordinator firmware 7.4.4 [GA]

Adapter

EZSP/EmberZNet (Silicon Labs based coordinator)

Setup

Zigbee2MQTT running as a systemd service, connecting to a self-hosted MQTT broker (FHEM MQTT2_SERVER).
Device joined and renamed via configuration.yaml devices section (not via zigbee2mqtt/bridge/request/device/rename MQTT API — unclear if this is relevant).

Device database.db entry

'0x781c9dfffe13d95e': friendly_name: Ventil_2er_1

Debug log

No response

Notes

No response

Reproduce the behavior with the friendly_name and IEEE-address MQTT commands, using the configuration.yaml friendly_name and the matching database.db entry described in the report. Trace the incoming MQTT topic handling and friendly-name lookup; done means the friendly_name /set command produces the same valve reaction and logging behavior as the IEEE-address topic.