Add CLI Console: run companion commands with visible output from the dashboard

[drewmccal]

What

Adds a CLI Console for the local companion radio: run SDK commands and see their responses in a persistent on-dashboard transcript, with a clear button and an event for automations.

execute_command already returns structured responses in the Actions dev tool, but there was no way to see command output in the UI or for non-admins. This adds that visibility layer without changing the existing service.

Changes

• Services: cli_command (wraps execute_command, records to a transcript, fires meshcore_cli_response, returns the response), cli_command_ui (reads the text.meshcore_command helper, runs it, clears the input), cli_console_clear.
• MeshCoreCLIConsoleSensor (new): rolling transcript (last 50 lines) exposed via state + transcript/history attributes for a markdown card. Off the device page by default.
• button.py (new): "CLI Run Command" and "CLI Clear Console" button entities (compact entity rows, not full-width cards). Off the device page by default.
• Structured contact errors: contact-resolution failures now return {error: ..., command, argument, detail} instead of silent None, so the console shows why a command failed (pubkey_prefix_too_short, contact_not_found, not_connected).
• Docs: new cli-commands.md reference (explains the SDK-method vocabulary vs iOS-app/meshcli/repeater-CLI naming), plus dashboard/services/events docs.
• Config: cli_console_enabled toggle in global settings.
• Tests for the three services and the structured contact errors.

🤖 Generated with Claude Code

[dida886]

@awolden When will this feature be approved? I'm waiting for it for my Meshcore-card project https://github.com/dida886/meshcore-card/tree/main.

[awolden]

Nice work, this is well put together and the structured contact errors are a win on their own. Two changes before merge:

1. Fold the wrapper services into a flag. Instead of cli_command/cli_command_ui, add an optional record_to_console: true boolean to execute_command and execute_command_ui. When set, record the command/response pair to the transcript and fire meshcore_cli_response, exactly what cli_command does today. That keeps one command API instead of two parallel ones (the docs currently have to explain the difference), and the Run button just calls execute_command_ui with the flag set. cli_console_clear stays as-is. The sensor, docs, tests, and error handling all carry over, this mostly deletes code from your diff.

2. Keep the transcript out of the recorder DB. Add _unrecorded_attributes = frozenset({"history", "transcript", "last_response", "last_command"}) to the console sensor (select.py:268 has the pattern), and use a neutral state like command count or last-run timestamp instead of the raw command string. Right now every command rewrites the full 50-entry transcript into the DB (a single get_contacts response can be tens of KB), and the state can land secrets like send_login <contact> <password> in recorder history.

Non-blocking: consider attaching the sensor and buttons to the root device so the entity ids are findable without Dev Tools. The buttons work fine from a device page even if the transcript card doesn't render there.

[drewmccal]

@awolden Thanks for the review! Both blocking items are addressed in 59ac044.

1. Folded the wrapper services into a flag. Removed cli_command / cli_command_ui and added an optional record_to_console boolean to execute_command and execute_command_ui. When set, the command/response pair is recorded to the transcript and meshcore_cli_response fires — exactly what cli_command did. The Run button now calls execute_command_ui with the flag; cli_console_clear is unchanged. This deleted the parallel command API along with its schema, services.yaml, translations, and unload entries (net −328/+230). Docs and tests carried over.

2. Kept the transcript out of the recorder DB. Added _unrecorded_attributes = frozenset({"history", "transcript", "last_response", "last_command"}) to the console sensor, and changed the state from the raw command string to a neutral command count — so the always-recorded state can no longer land secrets like send_login <contact> <password>, and the tens-of-KB transcript is no longer rewritten to the DB on every command.

All 222 unit tests pass, and I deployed to a live HA instance and confirmed the flag, the Run button, the fired event, and the neutral sensor state all behave as expected.

Non-blocking (attach the sensor/buttons to the root device): left as a potential follow-up for now, happy to fold it in if you'd like it in this PR.

[awolden]

Fast turnaround, all addressed cleanly. Thanks for the extra negative test and the dead code cleanup.

[dida886]

@drewmccal hi.

How I can read the response of CLI ?

I thought the answer would be in the logbook

[dida886]

[dida886]

It seems to me that instead of incrementing the count, responses from the CLI should appear.

[drewmccal]

Hi @dida886 — good news, it's actually working. The number that keeps incrementing is the sensor's state, and that's intentional: it's just a command counter, not the output.

The command and its response are deliberately kept out of the state (and out of the recorder database). The state gets written to history, and a command like send_login <contact> <password> would otherwise store your password in the database in plain text — so the state is a safe, neutral count instead.

The actual CLI output lives in the sensor's attributes, not the state and not the logbook:

• transcript — a ready-to-display log of recent command/response pairs
• history — the same thing as a structured list
• last_response / last_command — just the most recent one

To see it on your dashboard, add a markdown card that renders the transcript attribute:

type: markdown
content: |

{{ state_attr('sensor.meshcore_XXXXXX_cli_console', 'transcript') }}

(Replace meshcore_XXXXXX with your node's prefix — find it in Developer Tools → States, filter cli_console. Use a literal block |, not >, or the newlines collapse onto one line.)

The logbook won't show responses — for automations, use the meshcore_cli_response event instead, which carries command / response / is_error.

For your meshcore-card project: read state_attr(entity, 'transcript') (string) or 'history' (list of {timestamp, command, response, is_error}), or 'last_response' for just the latest reply.

[drewmccal]

@awolden I pushed documentation changes to this feature branch