Zigbee2MQTT’s scene_recall has no dedicated MQTT response that confirms every target applied the scene. You can see a state update or a success log without having that assurance. The official scenes documentation describes the command payload; it does not define a recall-confirmation topic.
This matters when an automation needs to know whether the lights reached the expected brightness or colour. Check the device state, but also check where that state came from: Zigbee2MQTT can publish values saved with a scene before a fresh device report arrives. The explanation below is based on documentation, source code and the linked issue reports; we have not bench-tested scene recall.
What scene_recall actually does
To recall a scene, Zigbee2MQTT expects a payload of {"scene_recall": SCENE_ID} published to zigbee2mqtt/[FRIENDLY_NAME]/set, where the friendly name is either a group or an individual device. That’s the whole interface. Zigbee2MQTT translates that MQTT message into a Recall Scene command from the standard Zigbee Scenes cluster and sends it to the target group or device.
There is no documented MQTT response specific to this command. State messages may follow, but they are not a result tied to your recall request. For the relationship between /set, /get and state topics, see our MQTT topics and attribute output guide.
The confirmation gap: why an already-active scene stays silent
In issue #17161, a user reported no group-topic message when recalling an already-active scene on a single-light group. That is a useful example of the confirmation gap, but it is an older report, not a promise that every current recall stays silent when nothing changes.
Device and group topics carry state, rather than an acknowledgment identifying the scene command. A new value may be a device report, a cached value or an optimistic update. The current scene converter can return locally saved scene values after sending the recall, including saved values for group members. That does not establish what each light physically did.
This is also a different layer from MQTT delivery guarantees. A QoS 1 or 2 publish confirms the broker got your message, not that a light applied a scene. Our Zigbee2MQTT QoS explainer covers where that guarantee stops.
The misleading log line: “successfully recalled” isn’t proof of anything
If you’ve gone looking in the Zigbee2MQTT log instead of MQTT topics, there’s a worse trap. GitHub issue #17820 reports that Zigbee2MQTT logs “Successfully recalled group scene” even when the targeted scene ID doesn’t exist. The reporter’s reproduction is simply to recall an ID that was never stored. The current group converter still logs that line after sending the command; it does not check that every member applied the scene.
Use the log to diagnose command handling and errors, but do not use that string as an automation’s success condition. A group command being sent is different from all its members reaching the requested state.
Put together, neither the MQTT topics nor the application log give you a trustworthy signal that a scene recall did what you asked.
Both issues closed “not planned”: what that means for you
Issues #17161 and #17820 were opened in March and May 2023 and are closed as “not planned”. A closed issue is not a statement that the behavior can never change. The current documented interface still has no recall-confirmation topic, and the converter still cannot prove that a group recall reached every light.
Build around the interface available now. If a future release adds a response, check precisely what it confirms before relying on it for physical-state verification.
What to monitor instead: state-based verification, not command-based
Watch the individual devices the scene is supposed to affect. Decide which values count as success, such as state, brightness and color_temp, and how long you will wait for them. Checking members is more useful than relying on an aggregate group entity; issue #15305 reports group-state update problems following a recall.
For a display or a routine lighting automation, matching Home Assistant entities may be sufficient. For a stronger check, request a fresh read of the relevant attributes where the device exposes /get, or inspect fresh attribute reports. For example, a device that supports reading state and brightness accepts {"state":"","brightness":""} on its own zigbee2mqtt/[FRIENDLY_NAME]/get topic. Check the device’s Exposes page first: a property must support GET, and colour temperature may require a separate read.
- Cached values can satisfy a wait immediately. A Home Assistant
wait_templatesees the current entity value, even if it was already correct before the command or came from an optimistic update. It checks a value; it does not prove fresh device feedback. - A fresh report or read confirms state, not cause. If the light was already at the requested setting, a matching read is still useful, but cannot prove the recall caused it. Another automation or a physical switch can also change the same light.
- Keep the wait bounded. Allow time for the scene transition and device reporting, then record an unknown or failed check if the deadline expires. If you configured
debounce, allow for its additional delay; our debounce versus throttle guide explains that behavior. - Check every relevant member. One responding light does not establish that the whole group applied the scene. State messages do not carry a recall transaction ID that correlates them with your command.
This is an automation pattern based on the available state interface, not a scene-confirmation feature. Our groups versus scenes guide covers scene storage and Home Assistant integration if your problem starts before the recall itself.
FAQ
Why doesn’t my automation know whether a recall worked? Zigbee2MQTT has no dedicated MQTT acknowledgment saying that all targets applied scene_recall. A successful publish or a matching cached state is not that acknowledgment.
Does a scene activation produce a state message? It may. The converter can restore locally saved scene values, and devices may send attribute reports. Neither guarantees a new message for every already-active scene or every group member.
How can I check the result? Check the expected attributes on each member, preferably using fresh reports or supported /get reads when you need stronger assurance. Apply a timeout and account for transitions. A matching state confirms the result you can observe, not which command caused it.
Why does the log say “successfully recalled” for a missing scene? Issue #17820 documents that behavior. The group converter logs success after sending a recall, without establishing that each light had the scene and applied it.
What should Home Assistant wait for? The device attributes the scene should set, with a bounded timeout. Remember that a wait_template can already be true and that entity state can be cached or optimistic.
What this piece verified, and what it didn’t
The command format and absence of a documented recall-response topic were checked against Zigbee2MQTT’s scenes documentation. The source code explains the saved-state updates and group success log. Issues #17161, #17820 and #15305 provide user reports of the practical limitations; their symptoms should be read with their reported versions in mind.
No physical lights or coordinator were tested for this article. The state-checking pattern above is a suggested way to observe the outcome, with its limits stated explicitly. It cannot prove which command caused a matching state.