Power Tools

BRUH Power Tools are 69 admin services, registered by the brAIn integration under the brain.* domain, that manage the parts of Home Assistant which normally require clicking through Settings: areas, floors, labels, entities (including what a device shows as), devices, integrations, helpers, zones, persons, users, blueprints, statistics, dashboards, and repair issues.

They exist for one reason: so nothing ever has to touch /config/.storage by hand. Every call is validated before anything changes, requires admin rights, and runs through Home Assistant’s own registry APIs. Claude uses them when you ask it to reorganize your home; your automations and scripts can use them too — every service shows up in Developer Tools → Actions with full field pickers.

What this unlocks

All of these work by voice, in the terminal, or in a run_task prompt:

• “Rename all the shelly_1pm_xxxx lights to what they actually are.”
• “Create a Guest Room area, put these three devices in it, and add ‘spare room’ as a voice alias.”
• “Label everything battery-powered, then show me the ones under 20%.”
• “Which automations reference entities that don’t exist anymore?”
• “Import this blueprint from the forum and set it up for the hallway.”
• “Backfill the gas meter history from this CSV.”
• “Build me a manual heating override — a target slider and an on/off toggle — and the automation that uses them.”
• “Make a Guest dashboard with just the lights and the thermostat, and a login for the babysitter.”
• “Install the Mushroom cards and redo my overview with them.”
• “The bedroom fan is on a smart plug — make it show up as a fan, and show the back door sensor as a door.”

Each service page below shows a 🗣️ line: a natural-language phrasing that works anywhere Claude listens.

The catalog

Areas & Floors

15 services: create, delete, rename, icons, voice aliases, floor levels, and device/entity assignment. Reference →

Labels

6 services: create, rename, restyle, and delete labels; apply or remove them on entities, devices, and areas in one call. Reference →

Entities

13 services: rename, change entity IDs, enable/disable, hide/unhide, voice aliases and icons, clean up orphaned registry entries (dry-run by default) — and change what a device shows as: a contact sensor as a door, a smart plug as a fan or a light, a sensor’s decimals and unit. Reference →

Devices & Integrations

9 services: rename and enable/disable devices (with parent-hub cascade); enable, disable, reload, or remove integrations; delete devices and sweep out orphaned ones. Reference →

Helpers

2 services: create and delete all 8 helper types — toggles, sliders, selects, timers, schedules — so an automation and its helpers arrive together. Reference →

Zones & Persons

8 services: create, move, and delete zones; create, rename, and delete persons and manage their device trackers. Reference →

Blueprints & Statistics

2 services: import blueprints from URLs; import or backfill long-term statistics. Reference →

Dashboards

7 services: create, edit, restore, reset to auto-generated, and delete dashboards — automatic backup before every change — and register custom-card resources. Reference →

Users

4 services: create, delete, enable, and disable accounts — with a guard that makes locking yourself out impossible. Reference →

Diagnostics & Repairs

3 services: find references to dead entities; raise and clear custom repair issues. Reference →

Nothing is create-only. Every attribute a create_* service accepts has a service that changes it later, and every registry object that can be created can also be renamed and deleted — so a label created with create_label can be renamed, recoloured, and removed again without ever touching .storage. That isn’t a promise, it’s a test: tests/test_power_tools.py asserts the rename_* and delete_* families are complete, so a create_* service can’t ship without its counterparts. And an update_* writes only the fields you name — pass just color and the icon and description stay exactly as they were.

The safety model

Power Tools are powerful by design, so the guardrails are built into the services themselves — not left to whoever calls them:

Guardrail	What it means
Admin-gated	Calls from non-admin HA users are rejected. Claude, automations, and scripts run as admin. New voice agents start with brain.* ticked in their Blocked services, and a Voice assistant-level agent cannot reach them at all.
Validated first	Every referenced area/floor/label/device/entity/integration id is checked before any change is applied. A typo fails loudly; it never half-applies.
Dry-run defaults	Both sweeps — delete_orphaned_entities and delete_orphaned_devices — only report unless you explicitly pass dry_run: false. find_orphaned_references never changes anything, ever. The targeted deletes (delete_device, delete_integration, delete_label, delete_floor, delete_person), disable_integration and stop_showing_switch_as also accept dry_run, but act by default: you named the thing, so it’s not a sweep.
Safety sensors stay safety sensors	set_device_class refuses to take a smoke, gas, carbon monoxide or leak sensor out of that type without confirm_safety: true, because brAIn’s safety alerts go by it.
Protected entities hold	Called from the chat or the terminal, every Power Tool passes the same checks as any other change: your protected entities are refused, and a switch shown as something else is protected if either half of the pair is.
Lockout-proof	disable_user refuses owner accounts and system-generated users.
Response data	Creation services return the new id (area_id, floor_id, label_id, …) so multi-step workflows chain without guessing.
Namespaced	Everything lives under brain.* — no core services are overridden, and running Spook alongside is perfectly fine.

And the human stays in charge: Claude’s generated context instructs it to confirm with you before disabling devices, integrations, or users, and before deleting anything non-trivial.

How Claude uses them

In the terminal, Claude pairs Power Tools with two MCP tools:

1. get_registry — read-only listings of areas, floors, labels, devices, entities, integrations, and users, with exactly the ids the services need. The safe replacement for reading .storage files.
2. call_service — invokes the brain.* service, with return_response to capture returned ids and reports.

So “move the office lamp to the bedroom and label everything battery-powered” becomes: look up the ids, validate, call the services, report back. No file edits, no restarts, no guesswork. The same services power voice requests and automation tasks — and because they’re real HA services, your automations can call them with no Claude in the loop. Where this layer sits relative to the MCP and CLI tools: How Claude controls your home.

What Power Tools deliberately don’t do: add an integration (config flows are interactive, so Claude walks you to the screen and you click — removing one it can do), or touch credentials and auth internals.

They also don’t reach objects defined in YAML rather than through the UI, and that is a routing detail rather than a limit. A brain.* service edits the registry, and a YAML-defined dashboard, helper or person isn’t in the registry — so brAIn edits the file instead, validates it, and reloads the domain. It gets there either way; only the layer changes. See how the layers fit.

A well-organized registry also improves every analysis brAIn generates — it reads your areas, labels, and statistics.

Credit where due

Power Tools are adapted from Spook by Franck Nijhof (MIT licensed). brAIn renames, consolidates, and hardens that foundation for an AI-operated home: namespaced services, validation-first handlers, response data, and dry-run defaults. If you don’t run brAIn, use Spook directly — it’s excellent.