Building without an error is not the same as working correctly

This group of domains spans meanings that have almost nothing in common. media_player has volume and playback. select has options. valve has an open and a closed state. event has only events, nothing persistent at all. script triggers an action and forgets about it. Where Matter has no matching device type for any of that, Home Assistant Matter Hub reaches for the closest thing it does have: Mode Select, Generic Switch, On/Off Plug-in Unit, or Robotic Vacuum Cleaner.

So a tile turning up in the controller is not proof that support is complete. Whether that tile stays on. Whether it can only be pressed once. Whether off really calls a Home Assistant action, or does nothing at all. Whether the controller can even render a Mode Select. Whether the device would be better off as a standalone node. Every one of those is a separate question, and this chapter walks through them domain by domain.

Alarms, sirens, valves, water heating and robots all act on the real world. Confirm each one first with a read-only state and a low-risk command, then decide separately whether to expose it to voice control or to a household with more than one person in it. Matter Hub is not a safety interlock, and it is not a personal-monitoring system.

The 17 HomeAssistantDomain values this chapter covers

Stable 2.0.55 defines 27 HomeAssistantDomain values in total. Earlier parts of this guide covered 7 of them for control devices and 3 for sensors and energy. This part covers the remaining 17, so no domain is left unaccounted for.

domainToDefaultMatterTypes is the candidate matrix that the picker consults, not the literal name of the final endpoint for every domain. The candidates for automation, scene and script all say on_off_switch, while the legacy implementation actually builds on an On/Off Plug-in Unit device base and keeps the momentary off semantics described later in this chapter. A description of the observable behavior and the underlying class are two different things, and this guide tries not to put them on the same level.

media_player, valve and water_heater, and the overrides that reuse them

If a media_player has device_class TV, it automatically uses basic_video_player; an explicit speaker override bypasses that TV detection. A speaker drives OnOff as a power control only when it supports both TURN_ON and TURN_OFF; otherwise, where it has a mute capability, mute takes that place instead. VOLUME_SET adds a 0–254 compatibility volume control, SELECT_SOURCE adds input sources, and PLAY or PAUSE adds playback control.

A valve can add a Power Source from a battery attribute or from batteryEntity. Open and close call the matching HA valve actions, and opening and closing show as Transitioning. When a pump comes from a switch override, the turn_on and turn_off behavior of the source integration is still what counts — the override changes the Matter type, not the underlying safety logic. Boost on a water heater involves energy use and a scalding risk, so whether the controller happens to show a button is not how you judge that using it is safe.

Where a Mode Select stands in for something Matter does not have

select and input_select build a Mode Select out of a non-empty options list, and find the current option case-insensitively; with no options at all, no endpoint is built. If the controller cannot render Mode Select, set selectExposeAsSwitch and name selectSwitchOnOption and selectSwitchOffOption explicitly, which folds two options into a persistent On/Off. Beyond two modes, this workaround no longer fits the domain.

alarm_control_panel has no dedicated Matter security-panel type, so a Mode Select carries the HA support bits instead: Disarmed, Armed Home, Away, Night, Vacation, Custom. The in-between states — arming, pending, triggered — do not map to a fixed mode. On platforms that cannot support Mode Select there is an On/Off fallback: on arms in the order Away, Home, Night, and off disarms. That loses the extra modes, and if the real integration needs extra authentication, the controller command can simply fail.

event defaults to a Generic Switch and detects double, triple and multi press from the event_types names. The doorbell override is an experimental Matter 1.4 type inside Stable; the source note says only SmartThings renders it today, and other platforms fall back to a plain Switch at best. It is not the Camera Plugin, and it carries no video.

siren is a persistent state: on and off call siren.turn_on and siren.turn_off, so do not confuse it with a momentary event. Testing a siren can disturb the neighbors or cause panic. Check in HA first whether a silent test is possible, and if it is not, only cross-check the endpoint rather than starting it remotely.

dishwasher, vacuum, lawn_mower and the Service Area they build

dishwasher is an optional Matter override for switch, with maturity stable, but Apple and Google are no and Alexa and Aqara are unknown; the pinned source note says platform support for appliances generally is thin. Labeling an arbitrary switch as a dishwasher adds no cycles, no door lock and no finish time — it only changes the device type shown to the controller.

vacuum builds a Robotic Vacuum Cleaner with an operational state, a run mode, a Power Source, a Service Area, and a clean mode that is always present. OnOff is not part of the standard RVC device type and is not added by default, because a non-conformant endpoint makes Alexa reject the device outright; it is added only when the vacuumOnOff feature flag is explicitly turned on. robot_vacuum_cleaner itself is yes for Apple, Google, Alexa and Aqara — but Apple voice control and Alexa discovery are better served by the standalone route later in this part.

Service Area can come from cleanAreaRooms, customServiceAreas, resolved rooms, or roomEntities; with no rooms configured at all, a single default area is still created. vacuumIncludeUnnamedRooms controls whether unnamed rooms are included, and vacuumRoomSwitches can create one momentary switch per area for platforms that do not render array commands. Linked options such as cleaningModeEntity, suctionLevelEntity and mopIntensityEntity decide the clean mode, and a similar-sounding entity name is not a reason to assume the right one got picked.

lawn_mower has no native Matter mower type; Stable 2.0.55 represents it as a Robotic Vacuum Cleaner and reuses the mower's run and operational states. robotic_lawn_mower is yes for Apple and Alexa, and unknown for Google and Aqara — and the controller UI will genuinely look like a robot vacuum. A Power Source is added only where a battery attribute or a mapping actually exists.

The line every special device sits on one side of

A persistent state always reflects the device's current value — input_boolean, remote, siren, valve and select, for example. On and off usually each have their own HA action, and after the controller changes something you should expect to wait for the source state to be reported back.

A momentary action only fires: automation calls trigger, scene and script accept turn on only, and button and input_button only press. They normally sit off; when an on arrives they act once, and the controller should not treat that as something that keeps running.

flowchart TD
  A["A domain in this chapter"] --> B{"Does its state reflect the device's current value, after you act on it?"}
  B -->|"yes"| C["Persistent: input_boolean, remote, siren, valve, select and alarm_control_panel"]
  B -->|"no"| D{"Does it only ever fire once and settle back to off?"}
  D -->|"yes"| E["Momentary: automation, scene, script, button and input_button"]

The momentary behavior of script, scene, automation and input_button optimistically reports on and then returns to off after about a second, so the controller does not look stuck. button is different, and always reports off, never set to true. Some Echo devices get stuck on the unrequested on→off report pair. The entity mapping option disableMomentaryFlip genuinely skips the flip for the first four domains, but for button it only skips a timer that never changed the state anyway — the underlying HA action still fires either way. This is a workaround for one particular controller, not a way of turning a momentary action into a persistent one, and it should not be switched on globally without looking at what it actually touches.

flowchart TD
  A["A momentary action fires"] --> B{"Which domain?"}
  B -->|"automation, scene, script or input_button"| C["Optimistically reports on, then off about a second later"]
  B -->|"button"| D["Always reports off. Never set to true"]
  C --> E{"Is disableMomentaryFlip set on this entity?"}
  E -->|"yes"| F["The on-then-off flip is skipped for that entity"]
  E -->|"no"| G["The flip happens as described above"]
  D --> H["disableMomentaryFlip only skips a timer that was never changing the reported state"]

A device inside a bridge is not the same as a standalone node

A standard bridge hangs several bridged devices off a single aggregator endpoint. Server Mode instead puts the device endpoint straight onto a Matter ServerNode, removes the bridged-device identity, and makes it look like a standalone Matter device in its own right. That matters most for types such as the robot vacuum, where a controller will only offer voice control or discovery on a standalone node.

The Dashboard page at /standalone-devices calls each Server Mode configuration a standalone device. Underneath, it still uses one set of bridge data, a filter, a port, a persistent identity and a commissioning state — but the code path it starts is ServerModeBridge, not the standard Aggregator Bridge.

This part treats standalone devices as a planning and risk exercise. Nothing here asks you to press Create, Pair or Delete on a live system, and nothing shows a QR code, a manual pairing code, or any identifying data. The actual commissioning and the safe multi-fabric procedure belong to the next part of this guide.

Nodes, endpoints and identity

Apart from vacuums, most domains first reuse the same LegacyEndpoint mapping described earlier in this guide, then use asStandaloneEndpointType to strip out bridgedDeviceBasicInformation. Vacuums use a dedicated ServerModeVacuumDevice / endpoint, which likewise carries no bridged identity and, by default, adds no OnOff cluster that would not conform to the RVC spec.

So standalone is not a second list of supported domains. Lights, sensors, fans, selects and everything else remain bound by the same HA device class, Matter override and controller device-type support limits covered earlier. Server Mode changes only the node structure; it cannot make a controller suddenly support a type that is marked no.

flowchart TD
  A["A Matter Hub bridge configuration"] --> B{"Standard bridge, or Server Mode?"}
  B -->|"Standard bridge"| C["One ServerNode holds an Aggregator endpoint"]
  C --> D["Each bridged device hangs off the aggregator, carrying Bridged Device Basic Information"]
  B -->|"Server Mode"| E["Entity endpoints sit straight on the ServerNode. No aggregator is built"]
  E --> F["The bridged identity is removed. The first matching entity becomes the primary and drives the node's own identity"]

Ten at most, and the first one is primary

The Standalone Devices create form takes exact entity IDs, each one shaped domain.object_id. Wildcards are not allowed, and a duplicate value is rejected outright. Frontend and backend both cap it at ten rows / ten endpoints; if the backend somehow receives more, it skips the surplus and reports it under failed entities.

The first entity the include matcher matches is the primary. Its HA device, friendly name, Entity Mapping identity override and Matter device type drive the root node's identity and its advertised device type; the other entities — up to nine of them — are flat sibling endpoints attached directly to the same node. Anything with more than one entity is still explicitly experimental inside Stable.

If a sibling is already absorbed by the primary's own mapping — a vacuum that automatically links a battery or a mode select, say — the backend marks the duplicate "Already exposed through …" instead of building a second endpoint. A disabled entity keeps its identity number but is listed as a failure, so that a reversible disable does not cause everything after it to renumber.

flowchart TD
  A["An entity listed in the create form"] --> B{"Already exposed through the primary's own mapping? A vacuum's linked battery, say"}
  B -->|"yes"| C["Marked Already exposed through... No second endpoint is built"]
  B -->|"no"| D{"Is the ten-entity cap already reached?"}
  D -->|"yes"| E["Skipped, and listed as a failed entity"]
  D -->|"no"| F["Built as a flat sibling endpoint on the same node"]

What each button actually does, and which controllers this actually helps

What Create, Edit, Reorder and Delete each affect

Create means the Add device form on the Standalone Devices page takes a name and one to ten exact entities. On submit, the backend assigns an available port, builds the filter include rows, and sets serverMode to true. That creates a new Matter node and persistent data; it is not a read-only preview.

Edit and Reorder mean that opening details and pairing on a list card takes you into an existing configuration, where the standard bridge detail and edit routes manage the filter and Entity Mapping. The standalone create dialog itself has no drag-and-drop editor for a node that already exists. To change the primary you have to change the order of the include matcher and assess the effect on identity and on controller caches; to change the Matter type, use Entity Mapping rather than editing the HA entity ID.

Delete means the list has a delete button and a confirmation dialog. The pinned UI text says it plainly: it deletes the Matter node and removes the commissioning from the controller, and it cannot be undone. Deleting is not a routine troubleshooting step. Before running it, back up the persistent storage and the configuration, record every controller that has joined, and confirm the maintenance window for rebuilding and re-commissioning.

Vacuums, mowers, and which controllers actually need this

The source code states the purpose of a Server Mode vacuum outright: avoid Bridged Device Basic Information so it appears as a standalone device, which is what Apple Home Siri commands and Alexa discovery need. The frontend's Filter Preview also suggests considering Server Mode when a standard bridge includes a vacuum. That is a device-specific compatibility strategy, not a blanket yes for Server Mode across every controller.

Service Area, Clean Mode, Operational State and Power Source on a vacuum follow the same logic described earlier in this part. Room, button, suction, mopping and charging links can still absorb other entities; if you then list those linked entities as siblings as well, the backend refuses the duplicate exposure — the same rule the diagram above already showed you. A mower only gets a Power Source when battery information exists, and a controller may still call it a robot vacuum.

Commissioning, in outline

Every standalone device is its own Matter node, so it has its own commissioning entry point, its own fabric relationships, its own sessions, and its own device record on the controller. Opening details and pairing on a list card is only a way in — you still have to confirm the network, IPv6, mDNS, the permissions on the controller account, and the maintenance window first.

The safe procedure has four parts: create and start the node, look at its commissioning state, join it on the controller side, and finally come back to Matter Hub to verify the fabric and the subscription health. QR codes and manual pairing data are secrets. Show them only briefly on a screen you control — do not screenshot them, do not paste them into a ticket, do not write them into this guide, and do not use a real example anywhere.

Multi-fabric means joining the same node to a second controller ecosystem, not building a second standalone device. Whether you can open a new commissioning window, how the controllers share it, and what removing a fabric does are all covered by the fixed procedure in the next part of this guide. Do not use Delete Standalone Device to remove a single controller, because Delete removes the whole node.

Server Mode has no plugins

A Server Mode bridge in Stable 2.0.55 does not provide pluginInfo, and it has no plugin enable / disable methods. The plugin API skips Server Mode in its listing, and answers a plugin operation on a single Server Mode bridge with not supported, rather than installing the plugin.

So even though the Camera and Security plugins have routes inside the Stable channel, their product maturity is still experimental, and they are not available on standalone devices or in Server Mode. Do not treat the experimental doorbell covered earlier in this part as a Camera Plugin — the doorbell only gives you an event or switch type, with no video. And do not use a multi-entity standalone device to try to "compose" a camera, a doorbell and a lock as a way around the limit.

Server Mode does not support composed mappings either: set composedEntities or climateExposeFan and the code logs a warning and falls the primary back to a flat endpoint. Automatic links such as a battery or a vacuum mode can still attach to that endpoint, but that is not the same as an arbitrary composed device parent.

The smallest workflow for a special device, and for a standalone node

Mapping a special device

1. Step 1

   Classify it as a state, a mode or an action

   In HA, first work out whether the entity is a persistent state, a Mode Select or a momentary action. Record it with a placeholder such as script.example_action, so no live environment data ends up in your notes.

2. Step 2

   Look at the default mapping in Devices

   Search for the entity on the Matter Hub Devices page and cross-check the domain against the automatic type. For a media player, also check device_class and the supported features; for a vacuum, check the room and mode attributes.

3. Step 3

   Compare it against the target controller

   Support for Mode Select, speaker, TV, valve, water heater and appliance types varies widely. Check the matrix first, then decide whether you need a fallback or a standalone node.

4. Step 4

   Change one mapping at a time

   Set speaker, pump, water valve or select-as-switch where you need them; for momentary entities, turn on disableMomentaryFlip only once you have confirmed a controller is actually getting stuck. Write down the original value before you save.

5. Step 5

   Start with a read-only or low-risk check

   Compare modes, volume, areas and states; for buttons, use a test action that does no harm. Sirens, water heating, pumps, valves, vacuums and lawn mowers need someone present and a way to stop them.

6. Step 6

   Confirm the controller command and what HA reports back

   For persistent types, test on and off; for momentary ones, test a single on and confirm the action fired exactly once. If it fails, roll the mapping back rather than resetting the fabric first.

Planning a standalone device, without touching a live one

1. Step 1

   List the target entities and controllers

   In an offline change ticket, use documentation placeholders such as vacuum.example_cleaner and mark each device type yes / partial / no / unknown. Do not paste in a live entity list or network data.

2. Step 2

   Decide between one entity per node and a small group

   Give a vacuum or a mower its own node first. If you plan a group instead, keep it to ten or fewer, and put in only entities with a similar support profile.

3. Step 3

   Set the primary and the order

   Put the entity that should drive the name, the identity and the advertised type in the first row. Record both the original order and the intended order, and assess the effect on controller caches.

4. Step 4

   Locate it in the UI, read-only

   Confirm that Standalone Devices is in the navigation, and look at the name, entity summary, status and entity problems on the existing cards. You may open details to read the status, but in this dry run do not press Create, Pair or Delete, and do not save an edit.

5. Step 5

   Finish the backup and recovery plan

   Write down the Matter Hub storage and configuration you need to back up, the controllers already commissioned, the window for stopping and restarting, and how you would restore the original include order if a change of primary goes wrong.

6. Step 6

   Leave the actual work to the commissioning procedure

   Once you have approval, follow the fixed procedure in the next part of this guide, run it inside a controlled window, and keep secrets on the local screen only. Without approval or a backup, the safe finish line for this exercise is "planned, not submitted."

The symptom you see, and the setting that explains it

Questions people ask

Where to go from here