Standalone Devices and Server Mode
Understand the experimental Server Mode inside Stable 2.0.55: every configuration is its own Matter node, it holds at most ten flat entities, and the first entity drives the identity. Plan the architecture and the controller fit without creating, commissioning or deleting anything on a live system.
A device inside a bridge is not the same as a standalone node
A standard bridge hangs several bridged devices off an aggregator endpoint. Server Mode puts the device endpoint straight onto a Matter ServerNode, removes the bridged device identity, and makes it look like a standalone Matter device. 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 chapter is a planning and risk walkthrough. It never asks you to press Create, Pair or Delete on a live system, and it shows no QR code, manual pairing code or identifying data. The actual commissioning and the safe multi-fabric procedure belong to the next chapter.
Nodes, endpoints and identity in Server Mode
| Item | Standard bridge | Server Mode / standalone |
|---|---|---|
| Matter structure | One node holds an aggregator and bridged child endpoints. | Entity endpoints are added straight to the ServerNode, with no aggregator. |
| Device identity | Every child carries Bridged Device Basic Information. | The bridged identity is removed; the root node carries the main identity. |
| How many | Planned from the size of the bridge and the capacity of the controller. | A hard limit of ten entities per node. |
| Primary entity | The bridge's own identity is separate from each child. | The first available entity the include matcher matches is the primary, and it drives the node identity and the advertised device type. |
| Composed devices | autoComposedDevices and a user composed endpoint are available. | No composed shape is supported; it falls back to a flat standalone endpoint. |
| Plugins | A standard bridge can use the plugin surface, subject to the feature and its maturity. | Not available; a Server Mode bridge has no pluginInfo and no enable/disable methods. |
Apart from vacuums, most domains first reuse the same LegacyEndpoint mapping as Chapters 9–11, then use asStandaloneEndpointType to remove bridgedDeviceBasicInformation. Vacuums use a dedicated ServerModeVacuumDevice / endpoint, which likewise carries no bridged identity and by default does not add an 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 the rest are still bound by the same HA device class, Matter override and controller device-type support limits. Server Mode changes only the node structure; it cannot make a controller suddenly support a type that is marked no.
Ten at most: the first is primary, the rest are siblings
The Standalone Devices create form takes exact entity IDs. Every row has to match the domain.object_id shape, wildcards are not allowed, and a duplicate value is rejected. Frontend and backend both cap it at ten rows / ten endpoints; if the backend 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 identity and the 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 experimental inside Stable.
| Grouping strategy | Fits | Does not fit |
|---|---|---|
| One entity per node | Vacuums and mowers, anything that needs a clearly separate identity, and problem isolation. | Large numbers of simple sensors; it raises the cost of commissioning and of managing nodes. |
| One primary plus a few siblings | Devices with the same purpose and the same controller support profile. | Mixing an EVSE, a rare detector, media and ordinary lights; controller discovery can fail, or the UI can end up confusing. |
| Filling all ten | A controlled setup you have tested, where the controller displays everything reliably. | Doing it only to save on node count; ten is a hard limit, not a target to aim for. |
If a sibling is absorbed by the primary's 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 renumbering.
What Create, Edit, Reorder and Delete each affect
What 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. This chapter only has you prepare the name and the order on paper or in a change ticket, and never asks you to submit on a live system.
What Edit and Reorder mean: Open details and pairing on a list card takes you into an existing configuration, and 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.
What 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 you run 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.
| Change | Possible impact | Safe fallback point |
|---|---|---|
| Adding a node | A new port, storage, a commissioning state and a device on the controller. | Cancel before you submit; after submitting, stop it rather than deleting it outright, and confirm the configuration backup. |
| Adding or removing a sibling | The endpoint structure changes; the controller re-discovers, or keeps a stale cache. | Change one thing at a time and keep the original include order. |
| Reordering the primary | The root identity and the advertised device type can change. | Restore the original order first; do not rename or change an override at the same time. |
| Deleting a node | The commissioning is removed and cannot be undone; you have to build it again and commission it again. | Only a backup made beforehand and a rebuild plan; once you confirm, there is no undo. |
Vacuums, mowers and controller fit
The source code states the purpose of a Server Mode vacuum outright: avoid Bridged Device Basic Information so that it appears as a standalone device, which is what Apple Home Siri commands and Alexa discovery need. The frontend 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.
| Type | Pinned device-type support | Server Mode planning |
|---|---|---|
robot_vacuum_cleaner | Apple, Google, Alexa and Aqara yes. | For Apple voice and Alexa discovery, prefer one vacuum per node; keep the standard RVC and do not turn OnOff on blindly. |
robotic_lawn_mower | Apple and Alexa yes; Google and Aqara unknown. | It still shows as an RVC type. A standalone node helps with isolation, but it does not produce a mower-specific UI. |
evse | Aqara yes; Apple, Google and Alexa no. | Do not put it into Alexa just because it is standalone; the sources note that a bridged EVSE can break Alexa recognition. |
air_purifier / fan | Apple no; Google, Alexa and Aqara yes. | A standalone node still cannot change Apple's no. |
mode_select | Apple, Google and Alexa no; Aqara unknown. | Standalone does not fix the UI gap; you need a two-state switch fallback, or you keep it in HA. |
Service Area, Clean Mode, Operational State and Power Source on a vacuum follow the same logic as Chapter 11. 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. A mower only gets a Power Source when battery information exists, and a controller may call it a robot vacuum.
Commissioning and multi-fabric concepts
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. Open 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 Chapter 13. 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 in Chapter 11 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.
| Feature | Standard bridge | Server Mode |
|---|---|---|
| Legacy entity mapping | Available | Available, converted to the standalone endpoint type. |
| Dedicated vacuum endpoint | Bridged RVC | Standalone RVC, which suits Apple Siri and Alexa discovery. |
| User composed device | Needs autoComposedDevices and similar conditions | Not available; it falls back to flat. |
| Camera and Security plugins | The feature itself is experimental inside Stable | Not available. |
A planning dry run that never touches a live node
List the target entities and controllers
In an offline change ticket, use documentation placeholders such as
vacuum.example_cleanerand mark each device type yes / partial / no / unknown. Do not paste in a live entity list or network data.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, keep it to ten or fewer, and put in only entities with a similar support profile.
Set the primary and the order
Put the entity that should drive the name, the vendor identity and the advertised type in the first row. Record both the original order and the intended order in the change ticket, and assess the effect on controller caches.
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.
Finish the backup and recovery plan
Write down the Matter Hub storage and configuration you need to back up, the kinds of controller already commissioned, the window for stopping and restarting, and how you would restore the original include order if a change of primary goes wrong.
Leave the actual work to the commissioning procedure
Once you have approval, follow Chapter 13 and run it inside a controlled window; secrets stay on the local screen. Without approval or a backup, the safe finish line for this chapter is “planned, not submitted”.
Server Mode pitfalls and safe fallback points
The Standalone Devices route does not exist
First cross-check that the version really is Stable 2.0.55, and check the frontend routes. Do not work from a screenshot of another channel, and do not guess the route name. A route existing does not mean the feature maturity is already stable.
It shows no entity, or an entity problem
Check whether the include is an exact entity ID, whether the entity was renamed, removed or disabled, and whether the HA registry is available. An empty registry delays reconciliation while HA restarts, so do not delete the endpoint straight away.
The eleventh entity was not built
Ten per node is a hard limit; anything above it is listed as a failed entity. Move the extra entities to another node instead of working around it with a wildcard — the frontend forbids wildcards anyway.
The wrong entity drives the controller name or type
Check the first include matcher, and the first endpoint that actually built successfully. Plan to restore the original order; do not delete the node, change the custom name and commission it again all at once.
The vacuum builds but voice or discovery does not work
Confirm that it really is in Server Mode, that it uses the standard RVC clusters and has no unnecessary OnOff, and check the controller's device-type support. Server Mode itself is still experimental; it guarantees nothing about every platform version.
You cannot find the plugin actions
This is a design limit, not a permissions error. Server Mode does not host plugins. Use a standard bridge to assess an experimental plugin, or leave the feature on its original platform.
You are about to delete something to fix a caching problem
Stop. Delete removes the node, drops the commissioning on every controller, and cannot be undone. Back up first, collect redacted diagnostics, and restore the most recent mapping and order. Only an approved rebuild plan gets as far as deleting.
FAQ
Is Server Mode a production feature in Stable 2.0.55?
Can a standalone device hold only one entity?
Is reordering only a change to the list?
Can standalone make Apple show an air purifier or a fan?
Can I install a Camera or Security Plugin on a standalone device?
Can I press Undo after deleting?
Stable 2.0.55 pinned sources
- The Standalone Devices route
- The create form, the limit of ten, the primary and the delete warning
- The Server Mode endpoint manager, ordering and the limit
- ServerModeBridge nodes, sessions and identity
- The endpoint conversion that removes the bridged identity
- Server Mode provides no plugin surface
- The serverMode feature flag and its experimental note
- Pinned add-on mirror
Every source is pinned to an exact commit. This chapter contains no real commissioning secrets, no live node identifiers and no environment data.