Zigbee2MQTT Groups vs Scenes: Why Scenes Don’t Show in HA

If you’ve moved past single-device automations in Zigbee2MQTT, you’ve probably tried to control several devices at once and hit a fork: groups or scenes. They sound like they might overlap, but they solve different problems, and one of them has a specific Home Assistant integration gap that catches a lot of setups off guard. A scene you just created in Z2M doesn’t show up as a scene entity in HA the way a Z2M group shows up as a light or switch entity.

Both features run entirely on your local Zigbee network under Z2M, no cloud dependency involved either way. The gap here isn’t a privacy problem, it’s a UI-expectation problem: HA discovers Z2M groups automatically over MQTT, but Z2M scenes don’t get the same treatment. This covers how each works, why the asymmetry exists, and the community workaround for the scenes side.

The short version: groups control, scenes recall

A Zigbee2MQTT group is a container. Add multiple devices to it, and one command addresses all of them together. A Zigbee2MQTT scene is a snapshot, a saved set of states (on/off, brightness, color) that you recall on demand. They’re complementary, not competing, and a scene can even target a group directly, so every light in that group gets its own stored state and transition timing when the scene fires.

How Zigbee2MQTT groups work, and why HA sees them automatically

You can create a Z2M group three ways: through the Zigbee2MQTT frontend (the simplest path for most setups), by sending an MQTT command to zigbee2mqtt/bridge/request/group/add, or by defining it statically in configuration.yaml with a numeric group ID and a friendly name.

What happens when you actually command a group is worth understanding, because it explains group behavior later on. Z2M broadcasts the group command to the network, and each member device decides for itself whether it belongs to that group and should act on it. The coordinator isn’t consulting a central membership table before forwarding traffic. The devices hold that decision individually.

Because group membership maps cleanly onto lights, switches, and covers, Home Assistant’s MQTT discovery picks up a Z2M group the same way it picks up an individual device. Once you’ve added members, the group appears in HA as a normal entity you can put on a dashboard or call from an automation like anything else. No extra configuration needed on the HA side.

Since membership is decided per device rather than tracked centrally, a device that misses the broadcast, because it’s in a weak spot on the mesh, simply won’t act on the group command, and there’s no bridge-side log entry telling you it got skipped. If group members are intermittently not responding, that’s a mesh-health signal worth chasing on the coordinator and routing side, rather than a sign the group itself is misconfigured.

Zigbee2MQTT scenes: scene_store vs scene_add

Scenes are created one of two ways. scene_store captures whatever state the device or group is currently in and saves it under a scene ID. scene_add lets you specify the exact state you want (brightness, color, on/off) plus a transition time, up front, without needing the device to already be in that state. Both are commands you publish to zigbee2mqtt/[FRIENDLY_NAME]/set.

// Store the lamp's current state as scene 1
{"scene_store": 1}

// Recall it later
{"scene_recall": 1}

// Remove one scene, or every scene on this device
{"scene_remove": 1}
{"scene_remove_all": ""}

Unlike scene_store, which takes a bare scene number, scene_add takes a nested object. You give it a scene ID, an optional name, an optional transition in seconds (default 0), and whichever attributes you want stored: state, brightness (0–254), and either color_temp (0–500) or a color object, but not both at once. Any attribute you leave out keeps whatever value the device happens to have when the scene is recalled.

// Define a scene explicitly, with a 3-second fade-in
{
  "scene_add": {
    "ID": 3,
    "name": "Evening",
    "transition": 3,
    "state": "ON",
    "brightness": 254,
    "color_temp": 370
  }
}

Scenes can also be scoped to an individual device within a group, by passing a group_id to scene_add for that device. That’s what lets a single scene fire across a whole group while each light in it ends up at a different brightness, color, or transition speed, rather than every member snapping to the same identical state.

The gap nobody documents: why your scene never becomes an HA entity

Here’s the asymmetry that catches people mid-project. Add a device to a Z2M group, and Home Assistant discovers it automatically over MQTT and exposes it as a normal light, switch, or cover entity you can use anywhere in HA. Create a Z2M scene the same way, and nothing comparable happens. There’s no HA scene entity, no dashboard card, no service-call target. The scene exists on the devices and in the Z2M frontend, and that’s it.

This isn’t a misconfiguration you can fix with a discovery toggle. It’s a real gap in what Zigbee2MQTT exposes to Home Assistant, tracked in an open GitHub issue (#18481) that’s still unresolved as of this writing, with no committed fix timeline.

Worth knowing: if an entire device is missing from Home Assistant rather than just a scene, that’s usually a different problem, often tied to a missing or failing external converter rather than this scene-visibility gap. A “no converter available” error in the Z2M log is the usual signature there, and it’s a separate fix from anything in this article.

The workaround: trigger scenes via MQTT instead of waiting for an entity

Since there’s no native HA scene entity to call, the workaround people have converged on is to skip waiting for one. You publish the scene_recall MQTT payload directly, from an HA script or automation, to the group or device’s set topic. The scene_recall command itself is documented Zigbee2MQTT; what isn’t official is wiring it through Home Assistant’s MQTT publishing as a stand-in for the scene entity Z2M never exposes. It’s a community-documented pattern, not a maintained blueprint, and it exists because it’s the only reliable way to reach the same result inside HA today.

{"scene_recall": 2}

The exact HA-side blueprint, which service, which fields, isn’t authoritatively documented anywhere in Z2M’s own docs, so it isn’t reproduced here beyond the concept: an HA script or automation publishes an MQTT message carrying the scene_recall payload to the same topic you’d use to trigger the scene from the command line. If you’re already comfortable with HA’s MQTT publishing tools, that’s the shape the workaround takes.

I think Zigbee2MQTT would save a lot of people this detour by shipping even a minimal, manually-triggered helper entity for scenes, rather than leaving the entire bridge-side pattern for individual users to wire up over raw MQTT.

Zigbee2MQTT groups/scenes vs Home Assistant’s own groups and scenes

There’s a second decision layered on top of all this: even where HA’s own native groups and scenes exist as an alternative, should you use those instead of Z2M’s? The two operate at different layers. Z2M groups and scenes run at the native Zigbee protocol level, a single broadcast or multicast command reaches every member device directly. HA’s own groups and scenes issue individual unicast commands to each device, one at a time, from HA itself. Community discussion comparing the two at the network-traffic level describes the Z2M-native path as more efficient, particularly as an installation grows.

If you’re running a large mesh and choosing coordinator hardware with this efficiency question in mind, our SMLIGHT SLZB-06 Zigbee2MQTT setup guide walks through a specific coordinator setup. If most of what you’re controlling together is pure Zigbee gear, staying on Z2M’s native groups and scenes keeps the traffic on the mesh instead of routing back through HA for every member device.

FAQ

Why don’t my Zigbee2MQTT scenes show up in Home Assistant? Because Z2M doesn’t currently expose scenes to HA as entities, only groups get that treatment via MQTT discovery. It’s a tracked, open gap (GitHub issue #18481), not a setting you’re missing.

Should I use Zigbee2MQTT groups or Home Assistant groups? If everything you’re grouping is Zigbee hardware already on Z2M, native Z2M groups are the more efficient path, one broadcast command instead of HA sending a separate command to each device. Reach for HA’s own groups when you need to mix Zigbee devices with other integrations in a single group.

Can a Zigbee2MQTT scene apply different settings to each light in a group? Yes. Passing a group_id to scene_add for an individual device lets that device store its own state and transition under the same scene ID the rest of the group uses, so the scene doesn’t force every light to the identical brightness or color.

How do I add a transition time to a scene created with scene_store? scene_store itself has no transition parameter. The documented approach is to first create the scene with scene_add using the transition you want, then overwrite the stored values with scene_store on the same scene ID. The transition timing persists through the overwrite.

Do Zigbee2MQTT groups reduce network traffic compared to controlling devices individually? Community reporting on Z2M groups versus HA-side groups and areas describes the native Z2M path as more efficient at the traffic level, since one broadcast reaches every member instead of the coordinator sending separate commands per device.

Whether Z2M eventually closes the scene-visibility gap on its own is still an open question worth watching in issue #18481. Until then, the MQTT workaround above is the practical path, not a permanent fix.

What’s verified, what stays local, what to check yourself

The mechanics of group creation, group broadcast behavior, and the scene_store/scene_add/scene_recall/scene_remove commands come directly from Zigbee2MQTT’s own groups and scenes documentation pages, not from bench testing on this site. The HA-exposure gap for scenes is confirmed by an open, unresolved GitHub issue, not a support-forum guess. The traffic-efficiency comparison between Z2M-native and HA-native groups is drawn from a Home Assistant Community discussion, described here as reported community observation rather than an independently benchmarked result.

Everything discussed here, groups, scenes, and the MQTT workaround, runs entirely on your local Zigbee mesh through Z2M. No cloud service is involved in any of it.

What wasn’t extended past its sourcing: the HA-side workaround is described at the concept level (publish the scene_recall payload to the group or device topic) rather than as a specific, exact HA service-call syntax, since no source here documents one authoritatively. The scene_add, scene_store, and scene_recall payloads themselves come straight from Zigbee2MQTT’s scenes documentation. If you build the workaround into your own automations, treat the MQTT topic and payload shown above as the stable part, and expect to fill in your own HA-side call structure around it.