Return core Home Assistant configuration: version, location name, time zone, unit system and the list of loaded integrations/components. A good first call to understand the instance.

Fire a custom event on the Home Assistant event bus (advanced). Useful for triggering event-based automations during testing. Requires writes to be enabled.

Reload automations from configuration without restarting Home Assistant (calls automation.reload). Requires writes to be enabled.

List entities with their current state. Filter by domain (e.g. 'light'), a free-text search over entity_id and friendly name, and/or an area (id or name). This is the fastest way to discover what exists before calling services or editing automations.

Get the full state and attributes for one or more entities. Use this to read exact current values before changing them or writing template/automation logic.

Get historical state changes for one or more entities over a time window. Times are ISO 8601 (e.g. 2026-06-05T06:00:00+00:00). Defaults to the last day if no start_time is given; with a start_time and no end_time it runs up to now (Home Assistant on its own would stop 24 hours after the start).

List callable Home Assistant services. Without a domain, returns every domain and its service names. With a domain, returns that domain's services including their fields/parameters so you know what data to pass to ha_call_service.

Call a Home Assistant service to change state (e.g. domain='light', service='turn_on', data={ brightness_pct: 60 }, target={ entity_id: 'light.kitchen' }). Refused unless writes are enabled, and blocked for denied domains. Returns the entities that changed.

List all Home Assistant areas (rooms/zones) with their ids, names and floor. Use the area_id or name to filter other tools.

List Home Assistant devices from the device registry. Optionally filter by area (id or name) and/or a search string matching name, manufacturer or model.

Inspect the entity registry: platform, area, device, unique-id metadata and whether entities are disabled or hidden. Useful for finding disabled entities or the area/device an entity belongs to.

Render a Home Assistant Jinja2 template against live state and return the result. Ideal for iterating on template sensors, automation conditions and value_templates until they produce the expected output. Example: "{{ states('sensor.outside_temp') | float < 5 }}".

List all automations with their entity_id, unique id (needed to read/edit config), on/off state and last triggered time.

Get the full configuration (triggers, conditions, actions) of an automation. Accepts either the entity_id (automation.xxx) or the unique id.

Create or update an automation by unique id. 'config' is the automation body (alias, trigger, condition, action, mode). Home Assistant reloads automations automatically after saving. Requires HA_ALLOW_WRITE=true and HA_ALLOW_CONFIG_WRITE=true.

Delete an automation by its unique id. Requires HA_ALLOW_WRITE=true and HA_ALLOW_CONFIG_WRITE=true.

Manually run an automation's actions now (automation.trigger). Accepts entity_id or unique id. Set skip_condition=false to also evaluate conditions. Requires writes to be enabled.

List Home Assistant Lovelace dashboards (url_path, title, mode, sidebar visibility). Works in direct HA mode and VomeHome brokered mode.

Get the full Lovelace configuration for one dashboard (views, cards, etc.). Use url_path from ha_list_dashboards — e.g. 'lovelace' for the default overview, or a custom path like 'sam-energy'.

Save (create or replace) the Lovelace configuration for a dashboard. 'config' is the dashboard body (title, views, …). Requires HA_ALLOW_WRITE=true and HA_ALLOW_CONFIG_WRITE=true.

Register a new storage-mode Lovelace dashboard. After creating, call ha_save_dashboard to set its views/cards. Requires HA_ALLOW_WRITE=true and HA_ALLOW_CONFIG_WRITE=true.

Delete a storage-mode Lovelace dashboard by its id (from ha_list_dashboards or ha_create_dashboard). Requires HA_ALLOW_WRITE=true and HA_ALLOW_CONFIG_WRITE=true.

Validate the current Home Assistant configuration (equivalent to Developer Tools -> Check configuration). Returns 'valid' or the specific errors. Run this after editing YAML and before reloading.

Home Assistant's deduplicated error store: one record per distinct problem, with level, logger, source file:line, occurrence count and first/last seen. Prefer this over ha_get_error_log — 20 grouped issues instead of 200 raw lines. Filter by minimum level, logger name or free text. Full tracebacks are omitted by default (you still get the final exception line); set include_exception=true, usually narrowed with 'contains', to read a whole stack.

Empty Home Assistant's structured error store. The point is the debug loop: clear, reproduce the problem, then ha_get_system_log shows only what your reproduction caused. Does not touch home-assistant.log on disk. Requires HA_ALLOW_WRITE=true in direct mode.

Raise or lower logging for one integration (or several) at runtime, via logger.set_level. Use this before reproducing a problem — debug on one integration, rather than global debug that drowns the log. Bare names are treated as core integrations ('hue' -> homeassistant.components.hue); anything containing a dot is used as-is ('custom_components.vomesync'). Levels reset on restart. Requires HA_ALLOW_WRITE=true in direct mode.

Return the tail of the raw Home Assistant error log. ha_get_system_log is usually the better first stop (grouped and structured); reach for this one when you need the raw ordering, or lines the structured store drops.

Tail the logs of an add-on, Home Assistant Core, the Supervisor itself, or the host — for problems that never reach HA's own error log (an add-on crash-looping, a failed install, host-level trouble). Requires a Supervised / HAOS install. Works through the VomeHome broker too (read scope).

Return human-readable logbook entries (what happened and when), optionally filtered to a single entity and time window. Times are ISO 8601; with a start_time and no end_time it runs up to now (Home Assistant on its own would stop 24 hours after the start).

Return a camera's current still as an image you can see — to check framing, exposure, or what the camera shows. For a camera entity that shows the latest snapshot file, this is that snapshot. Home Assistant scales it to 'width' pixels wide (default 1024). Through VomeHome the API key needs Cameras ticked under Sensitive devices.

A camera's current still decoded and shrunk to at most width x height pixels, returned as RGB bytes (base64, 3 a pixel, row by row): for a client that draws pictures in text, such as a dashboard pane in a terminal (two pixels a character cell with half blocks). To look at a camera yourself, use ha_camera_image. Through VomeHome the API key needs Cameras ticked under Sensitive devices.

List recent runs of an automation or script: when it ran, whether it finished, and how it stopped ('failed_condition' means a condition blocked it). Omit 'item' to list runs across everything in the domain. Home Assistant keeps a limited number of traces per item (5 by default), and none from before the last restart.

Step-by-step detail for one run: what triggered it, every condition and action in order with its result, and 'failed_at' naming the first step that errored or evaluated false. This is the tool for 'why didn't my automation run' — logs usually stay silent about a condition returning false. Give 'item' and omit run_id for its most recent run, or give a run_id from ha_list_traces (item is then optional — the run's own item is looked up). Summarised by default; set full=true for the raw trace including the config (large).

Report whether ESPHome is reachable and what is possible right now — listing and editing configs, and the streaming commands (validate/compile/upload/logs/clean). ESPHome is reached through a VomeHome relay-connected Home Assistant running the Vome add-on; when that is in place everything is available. Call this before telling a user that flashing or log-reading is unsupported — it usually is not.

What the ESPHome build commands (validate, compile, upload, logs) started in this session are doing: each running or recently finished job with its newest output lines. Pass back the returned 'seq' as 'since' to get only lines produced after it. For watching a long build while it runs; the build tools themselves return the full output when they finish.

List devices/configurations known to the ESPHome dashboard, including their configuration filenames (needed by the other ESPHome tools).

Read the YAML for an ESPHome configuration file (e.g. 'living-room.yaml').

Report the ESPHome spellings a device's YAML still uses that have since been renamed — the same 'Config migration available' notice the ESPHome dashboard shows in its own UI, which is otherwise invisible from here. Each entry names the old and new spelling and the ESPHome release that changed it.

required: true means the installed ESPHome already rejects the old spelling, so the config will fail to compile until it is fixed; otherwise it still works but is on borrowed time. Apply a rename by editing the YAML with esphome_save_config.

Write YAML to an ESPHome configuration file, whole: for a new file. To change part of an existing one, use esphome_edit_config. Requires HA_ALLOW_WRITE=true and HA_ALLOW_CONFIG_WRITE=true. Follow with esphome_validate to confirm it compiles, then esphome_upload to flash it.

Change part of an ESPHome configuration file in place: each edit replaces one exact piece of text with another, and must match exactly once. Prefer this to esphome_save_config for any change to an existing file: a real device's YAML runs to thousands of lines, and resending all of it to change a few is slow and risks a slip anywhere in it. Nothing is saved unless every edit applies. Requires HA_ALLOW_WRITE=true and HA_ALLOW_CONFIG_WRITE=true. Follow with esphome_validate, then esphome_upload to flash it.

Validate (compile-check) an ESPHome configuration and return the output. The fast way to confirm a YAML edit is correct before compiling or flashing. Runs over the VomeHome relay — no ports to open. If a call reports that ESPHome is unreachable, run esphome_dashboard_info to see why rather than telling the user this is unsupported.

Compile firmware for an ESPHome configuration and return the build output. Can take several minutes. Runs over the VomeHome relay — no ports to open. If a call reports that ESPHome is unreachable, run esphome_dashboard_info to see why rather than telling the user this is unsupported.

Compile and flash firmware to a device over the air. This is how you update an ESPHome device — no cable, no manual step in the ESPHome UI. 'port' is the device address or 'OTA' (the default). Requires write access. The build runs first and a failed build never reaches the device. Runs over the VomeHome relay — no ports to open. If a call reports that ESPHome is unreachable, run esphome_dashboard_info to see why rather than telling the user this is unsupported.

Stream the live logs from an ESPHome device and return what was captured. This is the way to see what a device is actually doing — boot messages, wifi/API connection problems, sensor readings, crashes and reboot reasons. Use it after flashing, or whenever a device is behaving oddly. Returns once the timeout elapses, so set timeout_seconds to how long you want to watch. Runs over the VomeHome relay — no ports to open. If a call reports that ESPHome is unreachable, run esphome_dashboard_info to see why rather than telling the user this is unsupported.

Delete the cached build files for a configuration. Use this when a compile fails for reasons the YAML does not explain — a stale build directory after an ESPHome version change is the usual cause. Then compile again. Runs over the VomeHome relay — no ports to open. If a call reports that ESPHome is unreachable, run esphome_dashboard_info to see why rather than telling the user this is unsupported.

Get the full Node-RED flow configuration (the JSON array of all nodes across every tab) plus the current revision string. Pass that 'rev' back to nodered_set_flows to avoid clobbering a concurrent change. Prefer nodered_get_flow / nodered_update_flow for single-tab edits.

Get a single Node-RED flow (one editor tab) and its nodes by flow id. Use nodered_get_flows first to discover tab ids and labels.

List the installed Node-RED node modules and the node types they provide (the palette). Use this to check which node types are available before writing a flow that references them.

Add a new Node-RED flow (a new tab) with its nodes, leaving existing flows untouched. The 'flow' object should have a 'label' and a 'nodes' array (Node-RED node objects). Requires HA_ALLOW_WRITE=true and HA_ALLOW_CONFIG_WRITE=true. Safer than nodered_set_flows because it cannot disturb other tabs.

Replace a single Node-RED flow (one tab) and its nodes by id, leaving other tabs untouched. Read it first with nodered_get_flow, edit, then send the whole flow object back. Requires HA_ALLOW_WRITE=true and HA_ALLOW_CONFIG_WRITE=true.

Delete an entire Node-RED flow (one tab) and all of its nodes by id. This cannot be undone from here. Requires HA_ALLOW_WRITE=true and HA_ALLOW_CONFIG_WRITE=true.

Replace the ENTIRE Node-RED flow configuration and deploy. This overwrites every tab — prefer nodered_create_flow / nodered_update_flow unless you really mean to rewrite everything. Pass the 'rev' from nodered_get_flows to avoid clobbering a concurrent change. deployment_type controls how Node-RED applies it ('full' restarts all flows; 'flows'/'nodes' restart only what changed; 'reload' re-reads from storage). Requires HA_ALLOW_WRITE=true and HA_ALLOW_CONFIG_WRITE=true.

List the Home Assistant instances on your VomeHome account, with status, tier, HA URL and (where available) live health. Requires VOMEHOME_TOKEN.

Switch which VomeHome instance the Home Assistant tools target. Subsequent ha_* calls (states, services, automations, templates, check_config) operate on this instance, and write/config permission follows that instance's own flags (declared in VOMEHOME_INSTANCES, the default instance, or auto-granted on create). An undeclared but reachable instance inherits the global default, which in brokered mode defers to the API key's server-side scopes.

Get one VomeHome instance by id, including live status and the Home Assistant URL. Requires VOMEHOME_TOKEN.

Which Home Assistant setup-wizard steps are still outstanding on a VomeHome instance. A newly provisioned home has its owner account created but the location, analytics and integration steps left for a person to choose, so it shows the wizard instead of a dashboard until they are done. Requires VOMEHOME_TOKEN.

Finish the outstanding setup-wizard steps on a VomeHome instance, so it opens on a dashboard rather than the wizard. Intended for a home being set up for other people to look at — a demo should not greet a stranger with a setup form. Provisioning deliberately never does this: location and analytics are the owner's choice, so only run it for a home whose setup you are responsible for. Pass core_config to set the location and units first; omit it and Home Assistant keeps what it detected, which is a safer default than a confidently wrong location. Needs ha:config.

Reboot a VomeHome Home Assistant instance (reboots the underlying VM). In brokered mode the API key's ha:write (or instances:write) scope is authoritative; an optional local VOMEHOME_INSTANCES write:false only adds a client-side block.

Create a new Home Assistant instance on VomeHome — useful for spinning up a throwaway test/sandbox install. In brokered mode the API key's create scope is authoritative (no local env flags required). Optionally set VOMEHOME_ALLOW_CREATE=false to block creation locally. The creating API key is granted full Home Assistant access on the new instance (ha:read, ha:write, ha:config, ha:files) and it becomes the active target.

Get a one-click login URL that opens your VomeHome Home Assistant already signed in. Present the returned URL to the user as a link to open in a new browser tab/window. The URL embeds a short-lived credential, so treat it as a secret and do not log it. Requires VOMEHOME_TOKEN.

Create a non-admin (unless admin=true) Home Assistant user for this instance, plus a one-click login URL for it — self-serve, revocable sharing without handing out the owner's own login. Only works for Vome-hosted instances (not self-hosted/relay ones): minting a token for someone other than the owner needs direct network access to the VM.

Home Assistant's permission model is coarse. A non-admin guest is locked out of Settings and Developer Tools, but can still call services on any entity the dashboard shows them — there is no per-entity guest scoping in Home Assistant itself. This is safe on a dedicated demo/sandbox instance built to be poked at. It is not a substitute for real access control on somebody's actual house — do not point a guest link at one.

The link expires automatically (default 24h, max 30 days) and can be revoked early with vomehome_revoke_guest_link. Treat the returned URL as a secret; do not log it.

List guest links created for this instance, including already-revoked ones (with revoked_at set). Never returns the login URL again — only enough to identify and manage each link.

Revoke a guest link immediately: deletes its Home Assistant user, which invalidates every credential and token attached to it in one step. Safe to call on an already-revoked link (no-op).

How CHAP stands for an instance: whether it is enrolled, its pair (main install, standby, which one runs the home, the kind of pair), whether the two are paired and in step, each part's state as the CHAP page's picture shows it, and actions — what can be done now. Asked of a standby, it says which main install it belongs to.

The user's other house installs, connected to Vome and not in a pair, that could be this home's standby. Use an id from here with vomehome_chap_link_standby.

Turn on CHAP for an instance: heartbeats and outage alerts. Needed before a standby can be linked.

Make another of the user's house installs this home's standby (for a home hosted by Vome: its local fallback). Then call vomehome_chap_pair to pair both and fill the standby. The standby must already be connected to Vome and running the Vome CHAP add-on.

Stop using the linked house standby or local fallback. Refused while it is running the home. Its Home Assistant stays stopped until the user starts it.

Pair both installs with Vome and fill the standby from a one-off backup of the main install, then keep it in step. Takes a few minutes; follow it with vomehome_chap_status.

Move the home to the standby on purpose (for maintenance): the main install's latest changes go across first, then the standby starts and the main install stops. Pass cancel=true to call off a switch still waiting for the changes. Ask the user before switching a real home.

Move the home back to its main install. By default the standby's changes go back first; now=true switches back at once and leaves anything changed on the standby since its last sync behind — for emergencies only. Ask the user first.

Set the house-network address (e.g. 192.168.1.15/24) that follows whichever install runs the home, so phones and dashboards need no change after a switch. address=null stops moving it.

Call a Supervisor endpoint through Home Assistant's supervisor/api WebSocket command (e.g. /addons, /store/addons, /store/repositories). Requires a Supervised / HAOS install and ha:config for mutating methods. Use this for add-on store operations.

Developer helper: add the VomeSync GitHub add-on repository to the Supervisor store (if missing), install the Vome add-on, and start it. Requires HAOS/Supervised. In brokered mode the API key's ha:config scope is authoritative — no HA_ALLOW_WRITE env flag needed. After install, restart Home Assistant once so custom_components/vomesync is loaded, then add the Vome integration.

List installed Home Assistant config entries (integrations). Optional domain filter, e.g. vomesync.

Permanently delete one config entry (integration instance) by id. This is the fix for orphaned or duplicate entries — the kind left behind when a device's original config entry never got cleaned up, so a re-added device's entities pick up a '_2' (or higher) suffix because the old entry is still holding the original entity_id. Get entry_id from ha_list_config_entries; match on name/domain/state to find the stale one before deleting.

There was previously no way to do this outside the Settings → Devices & services UI. Requires ha:config. The response's require_restart says whether Home Assistant needs a restart to fully drop the entry.

List config flows Home Assistant has started but not finished — chiefly integrations discovered on the network and waiting to be added. Each row carries the discovery context (host/IP, device id, model, serial) the integration matched on, so this answers 'what has HA found that is not set up yet?'. Optional domain filter.

Add or configure an integration via Home Assistant's config flow API. Start: pass handler (domain). Continue: pass flow_id + user_input for the current step. Requires ha:config (brokered) or HA_ALLOW_CONFIG_WRITE (direct).

Open a config entry's options flow — the per-integration settings panel — and optionally submit answers to it. Call with entry_id alone to see the current form and its fields, then again with user_input to set them.

This is the only way to reach switches that exist nowhere else in the API. The one asked for most: ESPHome's 'allow the device to perform Home Assistant actions' (field allow_service_calls), which a device needs before it can call HA services and which is buried several clicks deep in the UI. Also on that form: subscribe_logs. Get entry_id from ha_list_config_entries (domain=esphome).

Submitting a form sets every field it contains, so read it first and send the values back with only the ones you mean to change altered — omitting a field is not the same as leaving it alone.

Ensure the Vome custom component is set up as a config entry: start the vomesync config flow and submit defaults (new signing key + default sync.vome.io URLs). Idempotent if an entry already exists. Requires Core restart after the add-on first installed custom_components/vomesync. Needs ha:config.

List the helpers Home Assistant stores — input_boolean, input_number, counter, timer and the rest. These are the ones created through the UI (or by ha_set_helper); helpers defined in configuration.yaml are not returned here, because Home Assistant keeps those separately and they cannot be edited at runtime.

They are kept separately but they are NOT independent: both kinds share one id namespace and one entity-registry slot per id. A row listed here can therefore be a phantom whose entity actually belongs to a configuration.yaml helper of the same id — see ha_delete_helper.

Omit 'kind' to list every type. Types: input_boolean, input_number, input_text, input_select, input_datetime, input_button, counter, timer, schedule.

Create a Home Assistant helper, or update one that exists. This is how to add a helper without editing configuration.yaml — that file is not reachable from here and would need a restart; a helper created this way is stored by Home Assistant and its entity exists immediately.

Omit 'helper_id' to create; pass the id from ha_list_helpers to update. The new entity is ..

Fields per kind — Home Assistant validates and will name anything wrong: • input_boolean: name; optional icon, initial • input_number: name, min, max; optional step, initial, mode (box|slider), unit_of_measurement, icon • input_text: name; optional min, max, initial, pattern, mode (text|password), icon • input_select: name, options (array of strings); optional initial, icon • input_datetime: name, and at least one of has_date / has_time; optional initial, icon • input_button: name; optional icon • counter: name; optional initial, step, minimum, maximum, restore, icon • timer: name; optional duration (HH:MM:SS), restore, icon • schedule: name; optional monday…sunday (arrays of {from, to}), icon

Delete a stored Home Assistant helper by id (from ha_list_helpers). The entity disappears immediately, and anything referencing it — automations, dashboards, template sensors — will start reporting an unknown entity, so check what uses it first.

A helper defined in configuration.yaml can be destroyed by this. Stored helpers and YAML helpers share one id namespace and one entity-registry slot, and Home Assistant deletes by that slot. Deleting a stored helper whose id matches a YAML helper's key removes the YAML entity's registry entry as well, and the entity goes with it. Reloading will NOT bring it back — a reload sees an id it already has and changes nothing. Only a full restart recreates the entity. This tool checks for that before deleting and refuses when it finds it; pass confirm_shared_id to go ahead anyway.

An id that is not in ha_list_helpers is refused: a helper defined only in configuration.yaml is removed by editing that file and restarting.

List a directory under Home Assistant's config directory. Omit 'path' for the root, where configuration.yaml lives.

Requires the ha:files scope, which covers reads as well as writes because these files hold credentials. Home Assistant's internal .storage is never listed.

Read a file under Home Assistant's config directory — configuration.yaml, a package, an included YAML file, or (with encoding='base64') a packaged binary asset such as an icon or a data file a custom integration ships.

Read this before writing it: ha_write_config_file replaces the whole file, so the way to add a section is read, append, write back. Requires the ha:files scope.

Write a file under Home Assistant's config directory. Defaults to UTF-8 text; pass encoding='base64' to write a binary file (an icon, a data file a custom integration ships) — content is then the base64 of the bytes, not the bytes themselves.

This edit is checked and reversible. After the write, Home Assistant's own configuration check runs, and if it fails the previous contents are put straight back — a bad edit cannot leave Home Assistant unable to start. The result says whether it was verified and whether it was rolled back. Editing configuration.yaml this way is the normal, supported route for a home the user has authorised; it is how a hosted install is configured at all, since there is no SSH into one. (check_config only ever validates YAML, so it says nothing about a binary write; verify defaults to off for encoding='base64' for that reason.)

It replaces the entire file — read it first with ha_read_config_file and send back the full content with your change applied, or you will delete everything else in it.

Pass verify=false when writing several files that are only valid together, then call ha_check_config yourself at the end.

A successful write does not apply the change: restart Home Assistant, or reload the relevant domain, for it to take effect.

Requires the ha:files scope. Prefer a purpose-built tool where one exists: helpers via ha_set_helper and automations via ha_set_automation both apply immediately and cannot break startup.

Change part of a text file under the config directory: each edit replaces one exact piece of text with another, and must match exactly once. Prefer this to ha_write_config_file for any change to an existing file: resending a 70 KB file to change three lines is slow and risks a slip anywhere in it. Nothing is written unless every edit applies. Afterwards the configuration is checked and the file put back if the edit broke it, as with ha_write_config_file. Requires the ha:files scope.

Delete one file under the config directory — a throwaway test file, a superseded package, something you wrote and no longer need. It deletes a single file only, never a directory. The Vome component on the home refuses configuration.yaml, secrets.yaml and Home Assistant's database (also through a link with another name), anything outside the config directory, and .storage.

There is no undo, so read the file first if its contents might be wanted, and ask the owner before deleting anything you did not create. If something !includes the file, remove that reference first or Home Assistant will fail its configuration check. Requires the ha:files scope.

Whether HACS is installed and its version, configured country, and whether it has pending background tasks. Returns an error if HACS is not installed on this instance.

List repositories HACS knows about — both custom and default-store ones it has fetched metadata for. Each row includes id, full_name, category, installed, and whether it's custom. Use this to find a repository's id before calling ha_hacs_download_repository or ha_hacs_remove_repository.

Add a custom repository to HACS by GitHub 'owner/repo' (or its URL) and category (e.g. 'integration', 'plugin', 'theme', 'python_script', 'appdaemon', 'netdaemon', 'template'). This only registers it with HACS — call ha_hacs_download_repository afterwards to actually install it. Requires ha:config: this is how a repository HACS doesn't already list (a fork, a private project, one not yet in the default store) becomes installable at all.

HACS reports success on this call even when the add silently failed, so this tool confirms by re-listing repositories and checking the new one actually appears.

Install or update a repository HACS already knows about — this is the step that actually writes its files into the config directory and, for a brand-new integration, reloads HACS's entities. Accepts either the repository id (from ha_hacs_list_repositories or ha_hacs_add_repository) or its 'owner/repo' full name. A newly installed custom integration or add-on domain still needs a Home Assistant restart before it can be set up; a plugin/theme/dashboard resource does not. Requires ha:config.

Uninstall a HACS-managed repository's files and stop HACS tracking it as custom. Accepts either the repository id or its 'owner/repo' full name. Safe to call on a repository that was never installed (it just stops tracking it). Requires ha:config.

List every user on this Home Assistant instance: id, name, username (if they have a local login), role (from group_ids), is_active, is_owner, and whether they're system-generated (Supervisor's internal users — leave those alone).

Create a new Home Assistant user with no login yet — call ha_set_user_credentials afterwards to give them a username and password, or they exist but cannot sign in.

A user this creates is a standing account on the home, independent of any API key. Deleting the token that created it does not remove the user. Choose 'role' deliberately: 'admin' grants full control of this Home Assistant, equivalent to the owner. Requires ha:config.

Change a user's name, role, active state, or local-only restriction. Omit a field to leave it unchanged. Setting is_active=false disables sign-in without deleting the account. Cannot modify the owner's active state, or any system-generated (Supervisor) user. Requires ha:config.

Permanently delete a user and any login credentials attached to it. Cannot delete the account currently in use (the broker's own owner account) or a system-generated user. Requires ha:config.

Create a local username/password login and attach it to an existing user that has none yet (use ha_create_user first). Fails if that username is already taken, or the user already has a login (use ha_change_user_password instead).

This mints a standing Home Assistant login independent of any VomeHome API key — revoking the key that called this does not revoke the login. Only do this for an account the home's owner actually wants to exist. Requires ha:config.

Reset the password for a user that already has a local login (created via ha_set_user_credentials or Home Assistant's own UI). Only works when the broker is acting as the home's owner account, which is how it always authenticates. Requires ha:config.

Remove the local username/password login from a user, without deleting the user record itself. The user still exists (and keeps any other login method) but can no longer sign in with this username. Use ha_delete_user to remove the account entirely. Requires ha:config.

Create a non-admin Home Assistant login for a program (an MQTT client such as Zigbee2MQTT or an energy manager, an ESPHome device, a bridge), generate its password here, and write it straight into where that program reads it: an add-on's options and/or a secrets file. The password is never returned — not to you and not to the owner — so you never have to choose, see or type one. The Mosquitto add-on accepts Home Assistant logins, so this is all an MQTT client on this home needs.

Ask the owner before calling it: it creates a standing account on their home that outlives the API key that made it. Every delivery target is checked before anything is created; a new login that could be delivered nowhere is deleted again. Use rotate=true to issue a new password to a login this tool created earlier (the old one stops working); it refuses any other account. A program outside Home Assistant with neither add-on options nor a secrets file cannot be reached from here — ask the owner to set its login. Revoke with ha_delete_user. Requires ha:config, plus ha:files for secrets_file targets.

Get a script's full configuration (alias, sequence, fields, mode). List scripts with ha_list_entities domain='script'.

Create or update a script by id. 'config' is the script body ({ alias, sequence, fields, mode, ... }); Home Assistant reloads scripts after saving. Use it for a step several automations share, then call it from each with action 'script.'. Requires HA_ALLOW_WRITE=true and HA_ALLOW_CONFIG_WRITE=true.

Delete a script by id. Automations that call it will fail at that step, so remove those calls first. Requires HA_ALLOW_WRITE=true and HA_ALLOW_CONFIG_WRITE=true.

Change an entity's registry entry: its display name, its entity_id, its area, its icon, or whether it is disabled or hidden. Omit a field to leave it alone; pass null for name, area_id or icon to clear it back to the default. Renaming the entity_id does not update automations, scripts or dashboards that use the old one, so check those first (ha_list_automations). Disabling stops the entity being created at all; hiding only keeps it off auto-generated dashboards. Requires HA_ALLOW_CONFIG_WRITE (ha:config).

Remove an entity's registry entry, for cleaning up orphans: an entity whose integration no longer provides it (status 'unavailable' with restored: true), or one left behind by a deleted device. An entity its integration still provides comes straight back, so disable it with ha_update_entity instead. Requires HA_ALLOW_CONFIG_WRITE (ha:config).

Ask a Matter device to describe itself again — the device page's Re-interview button. Do this after a firmware update, or when a button, endpoint or feature stopped appearing: Home Assistant only learns about changed endpoints when it asks. A battery device may need waking (press a button) first. Takes the Home Assistant device id from ha_list_devices. Requires HA_ALLOW_CONFIG_WRITE (ha:config).

Vome's health score for this Home Assistant, out of 100, with everything its check found: each finding has a severity (warn, advice, info), a title, the evidence, a recommendation and often the exact entities involved — devices flooding the recorder, entities left behind by removed integrations, automations that are off or never run, batteries not reporting, error noise. Use it to see what is wrong with a home and fix it, finding by finding; then vome_health_check re-scores it. It needs the Vome integration (the Vome app in Home Assistant, or Vome from HACS); vome_health_check runs a first check.

Start a fresh Vome health check on this Home Assistant: after fixing findings, this is how the score catches up. It runs at Vome and takes a couple of minutes; the new report replaces the old one, so read it with vome_health_report (its generated_at changes when it lands). On a home not linked to Vome yet, the integration opens a temporary link first (deleted after a day unless someone signs in). Requires write access. It needs the Vome integration (the Vome app in Home Assistant, or Vome from HACS); vome_health_check runs a first check.

In one call, everything a dashboard view shows: the state and attributes of each entity, each Markdown template rendered, history as a few points per series, and camera stills as small RGB grids. For a client drawing a dashboard (such as a pane in Claude Code); to read a few entities yourself, ha_get_state is simpler. Parts that fail carry an error; the rest still answers. Camera stills need the key's Cameras tick through VomeHome.

Wait up to wait_seconds for any of these entities to change, and return what changed: for a client showing live states (a dashboard pane) instead of polling. The first call returns every entity's current state; pass back the returned cursor to get only changes after it. Through VomeHome only (the home's Vome component sends the changes); the key needs ha:read on the home.