Add Tag Historian to Home Assistant with a picker, not YAML

What this adds

• No YAML, no restart. Entity selection is a picker, and changing it later is a picker again — one restart at install, and never again for a config change.
• The picker is a short list. A normal Home Assistant install has several hundred entities and almost none of them are worth a tag. What you get is the things whose job is to report something — sensors, binary sensors, numbers, counters — with the best ones already ticked. The list is decided by what each entity is, not by what it happens to read at that moment, so a flat battery never removes anything from it. Everything else is one toggle away, not gone.
• The quota is visible while you choose. Tag Historian charges by the number of tags, not by how much data they hold, so which entities you send is the decision that matters. This shows you the budget as you spend it, and refuses to let you sail past it without saying so.
• It can tell you why data stopped arriving. The built-in integration cannot: it has one failure mode, it never reads the Retry-After header, and it has no notion of the API's “some of that batch was refused” answer. This one turns each of those into a Repairs card that says which problem it is and what to do — a revoked key, entities beyond your plan's tag count, the daily reading allowance being spent, or Tag Historian simply being busy. The last two are different problems and are never described as the same one.

1. Install through HACS

1. HACS → the three-dot menu (top right) → Custom repositories.
2. Repository: https://github.com/softi-dev/tag-historian-clients. Category: Integration.
3. Install Tag Historian, then restart Home Assistant.

Prefer not to add a custom repository? Copy custom_components/tag_historian/ from the same repository into your Home Assistant config/custom_components/ directory and restart — HACS just automates that copy and keeps it updated for you.

2. Get an API key

Create an account and an API key first. The free plan is €0 and takes an email address — no card — and gives you 5 tags and 50,000 readings a day. Then create the key on the Settings page in Tag Historian Explorer — and the scope you give it is not a detail.

The key is shown once. Copy it straight into the Connect screen when you add the integration — if you lose it, generate a new one rather than hunting for the old one.

3. Set up the integration

Settings → Devices & services → Add integration → Tag Historian. Three screens, and the last one recomputes from what you actually picked:

Connect

Host (leave the default alone unless you self-host) and your API key. The key is checked against your account before anything is saved, so a typo — or a key with the wrong scope — is caught here rather than a week later.

Choose

The entities whose job is to report something — sensors, binary sensors, numbers, counters — with the best candidates already ticked and spread across your devices, cut off at the number of tags your plan has left. Things you operate rather than measure — lights, switches, locks, automations, scripts, update entities, the sun — stay out of the list until you tick Show every entity, which puts every entity in the install back into it, unfiltered. There is also a minimum interval, which is how you stop a chatty sensor spending your daily reading allowance.

A sensor with no device class and no state class is listed but left unticked — Home Assistant knows nothing about those either way, and a few of them report a word instead of a number. See what one entity costs for what happens if you tick one of those anyway.

Review

The same sums, recomputed from what you actually ticked. If everything fits, that is all the screen says. If your selection needs more tags than you have left, it says so instead and offers to trim it back for you — removing the lowest-ranked entities that need a new tag, and never one whose tag already exists, because that one was costing you nothing. If your account has no free tags at all and everything you picked would need one, setup stops and says so rather than finishing with an empty selection.

Change any of it later: Settings → Devices & services → Tag Historian → Configure.

What one entity costs

One selected entity is exactly one Tag Historian tag — no more, no asterisks. The integration sends at most a single numeric reading per state change and never a second tag for the same entity, so the count on the Review screen is the count you will be billed for.

Only the entity's own state is sent, never its attributes. A reading is therefore a number, or one of a small set of words that are a number in disguise: on/off for a light, a switch, a fan, an automation, a helper or a binary sensor, open/closed for a cover, above_horizon/below_horizon for the sun. Those become 1 and 0.

Everything else stores nothing at all, and the ones that catch people out are worth naming:

The last three are the reason the rule is about the domain rather than the word. A lock, a person and a plain sensor can each report a word this integration recognises and several it does not, so translating only the recognised ones would produce a chart that jumps to 1 for one state and shows nothing for the rest — a series that looks like data and is not. Storing nothing at all is the honest answer, and each of those state changes moves the readings dropped counter, which also names the offending entity in its attributes. If you want a number out of one of these, make a template sensor that exposes it as its own entity, and select that instead.

An entity that is unavailable or unknown when you open the picker is still listed, and one you have already selected stays selected — its state right now decides whether there is a reading to send, never whether you are allowed to choose it. unknown and unavailable are never sent, and never counted as dropped either: they are Home Assistant saying it has nothing to report. A gap in the chart means exactly that — Tag Historian never stores an invented zero.

Sensors it adds

The last one is there on purpose: nothing is dropped silently, so if data is missing there is always a counter that moved. Its state adds up every way a reading can fail to become history:

entities_storing_nothing names the entities behind that last one, so a chart that stays empty says why. dropped_rate_limited is on the attributes too but is deliberately not in the total — those are the readings your minimum interval skipped, which is what you asked it to do.

The counters keep their values across a reload, so fixing a Repairs card does not erase the evidence of what it was telling you about. A Home Assistant restart clears them: they are held in memory, next to the buffer they describe. Anything the restart could not deliver is written to the log as well as counted, and the log is the half that is still there afterwards.

When something goes wrong

Everything below shows up in Settings → Repairs.

What this is not

• It does not read back into Home Assistant. There is no query API and no Flux here either — data comes out through the Tag Historian API, its charts, and exports to CSV, JSON or Parquet.
• It is not a replacement for the recorder. Home Assistant still keeps its own database and still draws its own charts from it. This is a copy that outlives the box.
• Strings and attributes are not stored. Only numbers, and the booleans this integration converts to 1 and 0.

Prefer the built-in YAML integration instead?

Home Assistant's own influxdb integration talks to Tag Historian too — no HACS, no restart per change, just a block of YAML and a restart once. That path, and the four settings that decide whether it works, are on the YAML guide.