Skip to content

Sensor availability

Jump to bottom
Jan edited this page Aug 26, 2026 · 5 revisions

Sensor availability

Brunata sensors stay available for as long as they have received at least one valid reading. They do not go unavailable when a poll fails.

This is deliberate, and it has a visible consequence: a sensor can sit on the same value for hours or days without anything being broken. This page explains when that is normal, and how to tell the difference.

When a sensor is unavailable

There are two cases, and neither is a failed poll:

Situation Why
The meter has never reported a reading There is no value to show yet. It resolves itself as soon as Brunata publishes one
The meter has been dismounted Brunata drops it from the payload. The sensor going unavailable is the honest answer — the alternative is a device sitting in Home Assistant showing its final reading forever, indistinguishable from a working one

Meters are replaced every 8–10 years, so the second one is rare — but if a sensor goes unavailable and stays that way, check whether the meter was replaced.

Why a failed poll doesn't make sensors unavailable

Meters that count — water, energy and heat cost allocators — use state_class: total_increasing, which feeds Home Assistant's Long Term Statistics: the data behind the Energy dashboard and long-range history.

Long Term Statistics are written as the state changes. If a sensor goes unavailable, no statistics are recorded for that period, and the gap cannot be filled in afterwards. Restoring it would mean re-inserting historical statistics by hand, which Home Assistant deliberately makes difficult.

A Brunata outage of a few hours would therefore leave a permanent hole in a dataset that is meant to span years. Holding the last known value costs nothing by comparison: meters report infrequently anyway, so a held value is usually still the correct one.

Meters that measure rather than count — temperature, humidity, CO₂, pressure, flow — use state_class: measurement instead. They are recorded in Long Term Statistics too, as min/max/mean rather than a sum, and the same reasoning applies: a gap can't be filled in afterwards.

Telling stale data from fresh data

Every sensor carries these attributes:

Attribute What it is
reading_date The date of the last reading Brunata returned
placement The label you set on the meter in Brunata Online. Absent if the meter has none
transmitting Whether Brunata considers the meter to be reporting

Fresh: reading_date advances as new readings arrive.

Stale: the sensor value looks normal, but reading_date has stopped moving while the state itself hasn't changed either.

To see it, open the sensor in Developer Tools → States, or add it to a card:

type: entities
entities:
  - entity: sensor.YOUR_METER_consumption
    type: attribute
    attribute: reading_date
    name: Last reading

Note

Finding your entity ID

Home Assistant builds it from the device name, so it follows the placement label: a meter shown as Water - Koldt vand becomes sensor.water_koldt_vand_consumption, and one without a placement becomes sensor.water_7822808_consumption. Look yours up under Developer Tools → States rather than guessing.

The ID is fixed when the entity is first created. Renaming a meter in Brunata Online updates the device name on the next poll, but not the entity ID.

Alerting on stale data

If you want to be told when readings stop arriving, use a template sensor on reading_date rather than on availability:

template:
  - binary_sensor:
      - name: "Brunata readings stale"
        state: >
          {% set last = state_attr('sensor.YOUR_METER_consumption',
                                   'reading_date') %}
          {{ last is not none and
             (now().date() - (last | as_datetime).date()).days > 7 }}

The is not none check matters: a meter that has never reported has no reading_date at all, and the template would otherwise throw an error.

Adjust the threshold to your meter. Heat cost allocators and water meters often report only every few days, so a short threshold will produce false alarms.

The transmitting attribute is Brunata's own view of whether the meter is reporting, and is worth checking alongside the date — a meter that stopped transmitting will go stale, but the attribute says so first.

What a real outage looks like

A failed poll is logged, not surfaced as unavailability. To see what the integration is doing:

  1. Settings → Devices & Services → Brunata
  2. Three-dot menu → Enable debug logging
  3. Reproduce, then disable it again — Home Assistant offers the log for download

The failure modes are handled differently:

Situation Behaviour
Cannot reach Brunata Last known values are kept, sensors stay available
Brunata returns an error The update is marked failed; values are still held
A meter is dismounted That sensor goes unavailable; the rest are unaffected
Credentials no longer accepted Home Assistant prompts you to re-authenticate

Only the last one requires action from you.

Related

Clone this wiki locally