The InfluxDB that wasn't: long-term Home Assistant metrics with VictoriaMetrics and Grafana

I wanted long-term graphs of my home’s energy use and temperature. Every guide I found said the same thing: install the InfluxDB add-on. That add-on no longer exists. This is what I did instead, and the one discovery that made the whole afternoon worth it.

The ten-day problem

Home Assistant records everything your home does into a local SQLite database and, by default, throws it away after ten days. That is fine for “was the heating on last Tuesday?” and useless for “did the new AC schedule actually save me money?”

I already had Grafana installed as an add-on, sitting there with nothing to read. The usual fix is to push the data into a time-series database that keeps it for years. Every tutorial points at InfluxDB.

There is no InfluxDB add-on any more

I had tried this once before and failed, with an error I skimmed past:

Failed to call /addons/…_influxdb/info - App …_influxdb does not exist

I assumed I had mistyped the slug. I hadn’t. The community add-on repository removed InfluxDB. There is no older version to roll back to. Search the add-on store and nothing comes up.

I mention this because the internet has not caught up. Search results, video walkthroughs and forum threads still tell you to install an add-on that is not there. If you follow a 2024 guide in 2026, this is where it breaks.

What replaced it is VictoriaMetrics. It lives in the same community repository, uses far less disk, and it understands InfluxDB’s line protocol. Home Assistant’s existing influxdb: integration writes to it without changes, so most of an old InfluxDB configuration carries over.

The setup

Four steps. About twenty minutes if nothing goes wrong, which for me it did.

1. Install VictoriaMetrics

Settings, Add-ons, Add-on Store, then search for VictoriaMetrics. The default retention is three years. If you have no certificates in /ssl, switch ssl off. The traffic never leaves your machine anyway.

Do not skip this part. In the add-on’s Network section, map port 8428. Leaving it blank does not mean “internal only”. The add-on’s web server never binds the port at all, and nothing can reach it. Not even Grafana, which runs on the same internal network. This cost me a wasted restart and a very confusing Connection refused.

2. Create a service account

VictoriaMetrics has no user accounts of its own. It checks every request against Home Assistant. So create a dedicated user under Settings, People, with administrator switched off, and give it a name that future you will recognise. Mine is called VictoriaMetrics Service.

Put the credentials in secrets.yaml, never inline in your configuration.

3. Point Home Assistant at it

influxdb:
  host: <the add-on hostname>
  port: 8428
  ssl: false
  api_version: 1
  username: !secret victoriametrics_username
  password: !secret victoriametrics_password
  database: home_assistant
  measurement_attr: entity_id
  tags_attributes:
    - friendly_name
  include:
    domains: [sensor, binary_sensor, climate, switch, light]

Use the add-on’s internal hostname rather than your Home Assistant IP address. Both containers share a network, and the traffic stays inside the box.

My first attempt used host: http://<my-ip-address>. The host field wants a bare hostname. With the prefix, Home Assistant tries to resolve a machine literally named http and fails with a DNS error that explains nothing. Oops.

4. Add it to Grafana

Connections, Add data source, Prometheus. VictoriaMetrics answers the same query language. Server access, basic authentication, the same service account.

The data source is the plain Prometheus type. Server URL and account name blurred. The password field only ever shows "configured".

After a day of collecting, the first dashboard looked like this.

Current readings, indoor versus outdoor temperature, and an AC runtime timeline. The dashed line is outdoors. On this day it stayed above the living room all afternoon.

Five things that cost me time

1. Restart order matters

VictoriaMetrics validates credentials against Home Assistant. If you restart while Home Assistant is still booting, that check fails with a 401, and it looks exactly like a wrong password. It is not. Wait a minute, then restart once more.

2. Metric names contain dots

Entity IDs become metric names such as sensor.living_room_temperature_value, and a dot is not valid in a bare PromQL identifier. Every copy-pasted example trips on this. Select by label instead:

{__name__="sensor.living_room_temperature_value"}
{friendly_name="Living Room Temperature"}
{domain="light"}

3. Never tick “Instant” on a panel

Home Assistant pushes data when a state changes, not on a timer. A temperature sensor can go twenty minutes without an update, and instant queries only look back five. The panel shows “No data” for a sensor that is working perfectly. Use range queries with a Last reducer.

4. The state is not always the number you want

My air conditioning entities are named …_room_temperature, but their state is the on/off mode. So the obvious metric reads 0 whenever the unit is off, and it looks like a dead sensor. The actual reading lives in a separate attribute series ending in _current_temperature. Always check what you are graphing.

5. Filter at the source

VictoriaMetrics stores numbers. Your phone’s Wi-Fi name, the app in front, its IP address: all strings, all written and then silently dropped. Exclude them in the influxdb: configuration instead of shipping them across for nothing.

The part that made it worth it

Nobody told me this, and I think it is the best kept secret in Home Assistant.

Home Assistant purges raw states after ten days, but it never purges long-term statistics. A separate table quietly stores hourly averages for every sensor that supports them, and it goes back to the day each sensor was added.

I opened mine expecting a handful of rows. I found 353,912 datapoints going back to 1 January. Eight months of temperature and energy data I thought I had lost.

You can read it straight out of the recorder database and push it into VictoriaMetrics through its bulk import endpoint. If the labels match what the live integration writes, old and new data become a single continuous series and the graphs just work across the join. Get the labels slightly wrong, as I did on the first try, and every sensor shows up twice.

Outdoor temperature, weekly average. Thirty-five weeks recovered from long-term statistics. None of this was being collected an hour before the chart was drawn.

The energy data is what I actually care about, and it showed something a ten-day window never could. Consumption peaks twice a year: once for heating, once for cooling, with a mild spring in between where the flat costs almost nothing to run.

Electricity consumption by month, in kWh. Heating in January costs about the same as cooling in August. March is a quarter of either.
The same data in Grafana: humidity, CO₂ as a ventilation cue, and the energy counters. Account identifiers and balances blurred.

What I would tell someone starting today

Skip any guide that opens with “install the InfluxDB add-on”. The add-on has been removed, and there is nothing to work around. VictoriaMetrics is the current answer. It takes the same configuration and it is lighter.

Then, before you accept starting from zero, go and look at your statistics table. You may be sitting on months of your own history without knowing it. I nearly built a dashboard that started at “today” with eight months already on disk.

Running on Home Assistant OS on a Home Assistant Green. Add-on slugs and hostnames differ between installs, so check yours in the add-on’s own configuration page rather than copying mine. Most of the digging was done with my friend Claude over an SSH bridge, which deserves a note of its own.

← Back to index