Pular para o conteúdo

Home Assistant

Este conteúdo não está disponível em sua língua ainda.

The smart home behind the dashboard: whether Home Assistant runs or started in recovery mode, entities that are unavailable or unknown by domain, low batteries, updates waiting (core, operating system, add-ons, device firmware) and the open repairs.

From the DumbMonit server (or its relay agent) to the device:

PortProtocolPurpose
8123TCPWeb UI, REST and WebSocket API (HTTP, default)

DumbMonit reads Home Assistant’s REST API with the long-lived access token of a dedicated user without administrator rights, and the list of repairs over the WebSocket API. It never calls a service, never fires an event and never changes a state.

The failure worth watching is not “Home Assistant does not answer” (a website check already sees that) but Home Assistant answers and something behind it stopped working: an integration whose entities all turned unavailable after an update, a Zigbee stick that fell off the USB bus, a door sensor whose battery reached 5%, a repair waiting for weeks.

All metrics are prefixed dumbmonit_homeassistant_.

MetricWhatLabels
infovalue 1version
running1 when the core state is RUNNING, 0 while it starts or stops
recovery_mode1 in recovery mode (or safe mode on older versions): the configuration could not be loaded
entitiesentities by domaindomain
entities_unavailable, entities_unknownentities in that state, by domaindomain
entity_unavailablevalue 1 per unavailable entity, at most 50entity, name, domain
batteriesbattery sensors and battery binary sensors
batteries_lowbatteries below the threshold, and battery binary sensors that are on
battery_lowone series per low battery, value = its level in percent (0 for a binary sensor), at most 50entity, name
updates_availableupdate.* entities that are on
update_availablevalue 1 per update waiting, at most 50entity, name, installed, latest
repairsopen repairs (neither ignored nor dismissed) by severity: critical, error, warningseverity
repairvalue 1 per open repair, at most 50issue, domain, severity
scrape_errorscalls that failed on the last probe

Some domains rest in the unknown state by nature: a button never pressed, an event never received, a notification or speech service. They are not counted as unknown: button, input_button, event, scene, notify, tts, stt, conversation, wake_word, ai_task, person. The Domains left out option removes further domains (for example device_tracker or media_player for devices that are often off) from the unavailable and unknown counts.

Repairs are not in the REST API: DumbMonit opens the WebSocket API, sends repairs/list_issues and closes it. A user without administrator rights may list them. The Read the repairs option turns this off.

The built-in rules that apply: Home Assistant in recovery mode, Home Assistant not running, Home Assistant entities went unavailable, Home Assistant battery low, Home Assistant update available, Home Assistant repair to address, plus Monitor unreachable.

Every phone and tablet signed in to the companion app (the mobile_app integration) is published under the generic family shared by every DumbMonit integration that tracks client devices — dumbmonit_client_device_*, prefixed without homeassistant, documented in full under Client devices:

MetricWhatLabels
last_seen_timestamp_secondsLast update of the device’s device_tracker entitydevice, type (Mobile), os (empty), user (the person it is linked to, if any), kind
stale_secondsPositive once a device has gone past device_stale_days (3 by default) without an update; drives the Client device stale ruledevice, type, os, user, kind, signal (always connection: Home Assistant has no backup to report)

How a device is recognized: /api/states does not say which integration created an entity — that needs the entity registry, which the REST API does not serve. The companion app’s device_tracker is the only one that sets a battery_level attribute; third-party location integrations (Life360, OwnTracks, the demo integration used in testing) set at most battery. A third-party integration that happened to copy that exact attribute name would be mistaken for the companion app; conversely, a companion-app device with battery reporting turned off is missing from the table rather than shown wrongly. The device’s account, when known, comes from a person.* entity whose device_trackers attribute names it.

The panel above the charts reads what the probe stored; opening the page never queries Home Assistant. It says what is wrong first (recovery mode, repairs of error severity, entities unavailable), then the low batteries by level, the updates waiting with their versions, the entities by domain, and the table of companion-app devices with their last connection.

Against Home Assistant 2026.9.4, with the long-lived token of a user without administrator rights: configuration, entity states of the demo integration and of template sensors (battery levels, a battery binary sensor, an unavailable sensor), update entities and the repairs list over the WebSocket API. The companion app’s device_tracker attributes (battery_level, source_type) were checked against the mobile_app integration’s source, not against a live phone.

Create a dedicated user and a long-lived token in Home Assistant

Section titled “Create a dedicated user and a long-lived token in Home Assistant”
  1. Open Settings → People → Users → Add user (turn on Advanced mode in your profile if the tab is missing), name the user as follows and give it a long random password.

    dumbmonit
  2. Log in as that user, open its profile (bottom of the sidebar) → Security → Long-lived access tokens → Create token, name it and copy it: it is shown only once.

  3. In DumbMonit, enter the Home Assistant address (for example homeassistant.local, port 8123) and paste the token.

  • Regular user (Administrator toggle off) — Reads every entity and the repairs list

Vendor documentation: Home Assistant REST API.

A regular user can read every entity and the list of repairs, and cannot change the configuration. DumbMonit only reads /api/config, /api/states and, over the WebSocket API, the list of repairs. It never calls a service, never fires an event and never changes a state.

Batteries under 20% count as low; the Low battery threshold option changes that. Every phone and tablet signed in to the companion app (the mobile_app integration) appears in the Devices table with its last activity; it is optional and silent without that app.

CredentialFields
Long-lived access tokenA token of the dedicated user, sent as Authorization: Bearer.

Address: a host name or IP (homeassistant.local), host:port, or a full URL (https://ha.example.net, with a path prefix behind a reverse proxy); a trailing /api is accepted. Options: protocol (HTTP by default), port (8123), certificate check, request timeout (10 s), low battery threshold (20%), domains left out (none), repairs (read) and device staleness (device_stale_days, 3 days by default).