Dashboard

HA NOVA Dashboard

Scope

Storage dashboard work only:

• list dashboards
• read one dashboard config
• list Lovelace resources
• inspect the current dashboard structure: views, cards, badges, header cards
• create a new storage dashboard shell
• update dashboard metadata
• create, update, and delete Lovelace resources
• find a specific dashboard element before changing it
• add, update, move, and delete cards inside existing views
• delete an existing storage dashboard

This skill is safety-first:

• always resolve the target from lovelace/dashboards/list
• only write/delete when the dashboard mode is storage
• always read the full current dashboard before any content write
• always save the full merged config, never a guessed partial fragment
• always read back and verify the intended change

Not in scope:

• raw broad Lovelace editing without a concrete requested change
• view create/delete/reorder
• non-storage dashboard writes/deletes
• freeform new custom-card creation
• energy dashboard preferences

If the user asks for a broad redesign instead of a concrete safe change, narrow the request first. Do not guess.

Bootstrap (once per session)

Verify relay CLI: ha-nova relay health If this fails: ha-nova setup

Relay Contract

Use file-based WS requests only:

• ha-nova relay ws --data-file
• ha-nova relay ws --data-file --out
• ha-nova relay ws --data-file --jq-file

Relevant WS types:

• lovelace/dashboards/list
• lovelace/dashboards/create
• lovelace/dashboards/update
• lovelace/dashboards/delete
• lovelace/config
• lovelace/config/save
• lovelace/resources
• lovelace/resources/create
• lovelace/resources/update
• lovelace/resources/delete

Critical behavior:

• lovelace/config/save is a full-document overwrite
• there is no partial update endpoint
• omitted views/cards are lost
• lovelace/dashboards/list is the source of truth for dashboard_id, url_path, and mode
• lovelace/config/delete is not the dashboard delete path for this skill
• lovelace/resources shows installed Lovelace resources, but that alone is not proof that a custom-card schema is safe to invent

Flow

1. Resolve the dashboard target.

• Always list dashboards first with lovelace/dashboards/list.
• Match by url_path, title, or current identity.
• Keep both identifiers:
• dashboard_id for lovelace/dashboards/update|delete
• url_path for lovelace/config|save
• Ask one blocking question only if more than one dashboard still matches.

1. Check write/delete eligibility.

• use the matched dashboard mode from lovelace/dashboards/list
• only mode=storage is writable/deletable here
• if mode is not storage, stop and explain that this skill will not write or delete it

1. Choose the mutation path.

• create shell: preview title, url_path, icon, require_admin, show_in_sidebar, then call lovelace/dashboards/create
• metadata update: preview the exact metadata fields, then call lovelace/dashboards/update with dashboard_id
• only send changed metadata fields supported there: title, icon, show_in_sidebar, require_admin
• do not resend url_path, mode, or unrelated config fields in the update payload
• resource inventory: use lovelace/resources
• resource create/update:
• preview res_type and url
• call lovelace/resources/create|update
• resource delete:
• preview the exact resource identity
• require exact token confirmation confirm:
• call lovelace/resources/delete with resource_id
• content update / card operation:
• read the current dashboard config with lovelace/config
• build a compact inventory of views, cards, badges, and header cards
• resolve the exact target by view, title/heading text, entity reference, card type, or explicit position
• merge the requested change in memory
• preview a concise diff/excerpt
• save the full merged config with lovelace/config/save
• new cards may be created only from this built-in allowlist:
• entity, entities, button, tile, gauge, sensor, markdown, history-graph
• existing custom cards may only be moved, deleted, or shallow-updated when the exact field already exists
• delete:
• preview the exact dashboard identity
• require exact token confirmation confirm:
• call lovelace/dashboards/delete with dashboard_id

1. Read the current dashboard when content changes are involved.

• use lovelace/config with the chosen url_path

1. Read back and verify:

• create / metadata update / delete: verify through lovelace/dashboards/list
• resource create/update/delete: verify through lovelace/resources
• content update: verify through lovelace/config
• content update must confirm both the intended field change and unrelated-view survival

1. If verification fails, stop and report the mismatch. Do not retry by guessing.

Output Format

For list/read:

• Dashboard
• Target
• Summary
• relevant config or inventory excerpt only

For create/update/delete:

• Dashboard
• Mode
• Planned change
• Verification
• Next step

Do not dump the full dashboard JSON/YAML by default.

Safety

• No guessed url_path or dashboard_id values.
• Create/update uses natural confirmation after preview.
• Dashboard/resource delete uses exact token confirmation only.
• If the requested change would require a broad re-layout instead of a targeted edit, say so before writing.

Guardrails

• Never call lovelace/config/save with a partial config.
• Never use lovelace/info to decide whether a dashboard is writable.
• Never use lovelace/config/delete as the dashboard delete path.
• Never verify only by save success; always read back the dashboard.
• Never probe a different dashboard's config just to infer behavior for the target dashboard.
• Never invent a new custom-card schema just because a resource exists.
• If the dashboard target is still ambiguous after one clarification, stop and explain the remaining ambiguity.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: markusleben
• Source: markusleben/ha-nova
• License: MIT
• Homepage: https://github.com/markusleben/ha-nova

Install and usage instructions live in the source repository linked above.