Home Assistant Switch Manager: button presses as configuration instead of automation

The deprecation notice comes before the features

The first block of the Switch Manager README is an important notice, and it is not a routine one. The repository is now deprecated in favour of the macpit/Home-Assistant-Switch-Manager repository, with credit to that maintainer for picking the work up, and the original author describing having pushed the project to the side.

What follows is unusually candid. The author says they spent many years on the project, were excited about it, and were trying to implement something they felt Home Assistant would eventually do themselves, and that this did not happen. Development became more of a chore, because the Home Assistant team need to change things on almost every update, breaking the tiniest of things, which the author calls a well known issue with their development and constant unnecessary changes. The author also mentions finding moderators and admins on forums toxic on occasions, which diminished their care for the project.

The stated reasons are personal as much as technical. Other life things came up, and there was no reward in returning to study the changes Home Assistant had made and keep fixing things when everything was working well. The hope expressed is that the community could pick up what was started, and the author says they found the integration very convenient for switches.

For an adopter this is the most consequential paragraph in the file. A deprecated Home Assistant integration is not a stable dependency, and the fork that supersedes it is a different codebase with a different maintainer, so a project that started here should start there instead.

What the component actually does with button presses

Switch Manager is a centralised component to handle button pushes for wireless switches, and the scope covers anything passed through the event bus, with MQTT named explicitly in the repository description as well.

The mechanism is a blueprint per switch. The component relies on switch blueprints, which are made so that switches and their button pushes can be configured through a GUI, and the stated benefit is that this removes clutter from the automations view, because the button handling is done independently by the component.

So the division of labour is this. The automations you write handle the consequence of a press, a light turning on or a scene starting, and the identification of which physical button was pressed, its identifier or topic, is handled by Switch Manager through a blueprint. That is a real simplification for a house with a dozen switches, where the same physical button appears in several automations and the identifier block would otherwise be repeated in each one.

The README is explicit that the same switch can be defined multiple times, but not for different services, because the services differ in their event data. That is a small constraint that comes straight from the data model rather than from a design choice, and it means the blueprint set has to be organised per integration rather than per physical device.

Installing it as a custom component

The installation path is a manual copy into the Home Assistant configuration directory, and the README lays it out in four steps. You download the component from the releases page, you place the folder into the custom_components path of your Home Assistant installation, you restart Home Assistant, and then you go to the configuration, add the Switch Manager integration, and find it in the list.

The folder that gets copied is named switch_manager and it goes under the custom_components directory of your config path:

1. Place the folder `custom_components/switch_manager` into the `config/custom_components/` path of your home assistant installation
1. Restart Home Assistant

Once the integration has loaded, a folder of blueprints is created in the config/blueprints/switch_manager path in your Home Assistant installation, and you can add or create extra blueprints in that path. That last point is the one that matters for anyone extending it: the blueprint set is not sealed, and a blueprint you write yourself sits alongside the ones the component ships with.

There is a HACS badge in the README, so the component is also available through the Home Assistant Community Store, which is the route most users will take rather than downloading a release by hand.

The documentation shows a YouTube introduction and two screenshots of the switch editor page and the index page, and the workflow the README describes starts from the side panel: you go to Switch Manager, click Add Switch, and select the switch blueprint for the service or integration the switch is on.

Identifiers, topics and the auto discovery problem

Once a blueprint is selected you land in the switch editor, and the identifier is the thing that has to be right. The identifier or MQTT topic input box is opened from the top right menu, and you can either type the identifier by hand or press the auto discovery button and then press a button on the physical switch to fill the value in.

The documentation is refreshingly honest about the failure mode. There is a possibility that an identifier from some other device for the event is discovered if that device sent an event before your button push, and if the button helper is not getting the right identifier then you have to find the information manually, by clicking the Event or MQTT tool link and listening for the event type or MQTT topic you need.

There are two documented ways to do that. For an event, you can use the Event Tool link in the identifier dialog, or go to Developer Tools, then Events, start listening, using a wildcard if you are unsure of the event type, push a button, stop the listener and read the identifier's value out of the event data. For MQTT, you can download MQTT Explorer, which the README prefers, or listen to all topics using the MQTT integration's own listener, or follow the MQTT Tool link and listen to the wildcard topic, which means all topics. You can cross reference the MQTT discovery topic and the blueprint against the captured MQTT data if you want to be certain.

One warning is set in bold, and it is a real one. If you have changed the default MQTT base topic for a service or integration and you are using a blueprint provided by Switch Manager, you have to enter that topic manually, because discovery will not work. A default base topic is what makes the auto discovery path usable at all.

Buttons, actions, and the device action warning

The interaction model is visual. Depending on the blueprint and the actions the switch supports, you select buttons by clicking on them from the image that is displayed, and each button can have multiple actions, for example press, double press and hold. The README also insists on saving before leaving the page when changes have been made, and then testing to confirm everything works.

There is a warning about one API that the component deliberately does not support. The device sequence action is currently unsupported, and the instruction is to use service and action calls instead, on the grounds that this should be used throughout Home Assistant anyway, since you can do everything device actions can do and more by using the standard actions. The README links to a community thread on why you should avoid device ids in automations and scripts, which explains the reasoning behind the choice.

That is a good example of the component taking a position rather than trying to wrap everything. Device ids are the most direct way to address a specific device, and they are also the identifiers most likely to change between versions of an integration, so a component built on blueprints avoids depending on them.

The project is distributed under a custom licence that GitHub cannot classify, with a LICENSE file in the repository, and it is published through HACS with the Default badge, so the default HACS repository lists it.

Where this component is the wrong choice

The first limitation is the one the deprecation notice states plainly. This repository is no longer the place to start, and the fork that supersedes it is a separate codebase with its own maintainer and its own release cycle. A new installation belongs there, and a fork is not a drop-in replacement in general, so anyone migrating needs to check what changed in the blueprint format rather than assuming the files carry over.

The second limitation is the dependency on the identity of the event source. Switch Manager needs to know which identifier or which topic belongs to which physical button, and the automatic path for that is to press a button and hope the device that was discovered is the right one. In a house with a single switch, that is a one-off annoyance. In a house where several integrations publish similar events, the manual path through the Event Tool or MQTT Explorer is the realistic workflow, and the README is clear that this is where the time goes.

The third limitation is that the component does not remove the need for automations. It relocates the button identification out of them, which is a real reduction in duplication, but the actions that follow a press are still automations you write. A project whose problem is that the automations list is unreadable is well served. A project whose problem is that the logic of reacting to presses is complicated is not, because that logic is untouched.

The real alternative, and the difference in approach is what the deprecation notice is really about, is waiting for the platform to grow the capability natively. The author's stated ambition was to implement something that Home Assistant would eventually do itself, and the upstream churn that made the custom component expensive to maintain is the same churn that would have made a native implementation authoritative. For a team evaluating this today, the sensible comparison is against building the same thing as a local blueprint in your own configuration, which costs you the centralised editor and the switch index page but keeps everything in files you control, with no custom component to update when the platform moves.

Editorial conclusion

Read the Switch Manager README as a case study in why a Home Assistant custom component gets deprecated, because the author's account of breaking upstream changes and the handover to a community fork is more useful than the component itself. Do not start a new deployment on this repository, since it is deprecated in favour of the macpit fork, and do not adopt either version without checking how much of the blueprint format has changed. Before installing the fork, read the section on identifier discovery, because the auto discovery can pick up an identifier from another device, and confirm that your MQTT base topic is the default, since a changed base topic disables discovery and has to be entered by hand.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. Sian-Lee-SA/Home-Assistant-Switch-Manager on GitHub