v0.21.0 – capacity suggestion respects battery efficiency

What's new

The capacity suggestion now respects your battery's efficiency. The "Wolta measured a different battery capacity" repair no longer offers to raise your configured capacity when your battery's round-trip efficiency is low. Wolta estimates usable capacity from your charge/discharge data assuming ~95 % charge efficiency; on a low-efficiency system — where parasitic/standby losses are high (e.g. some Emaldo setups) — that estimate overshoots, so adopting it would inflate your capacity and unfairly lower your grade. A suggestion to lower capacity still appears (your real usable is then even smaller). Thanks to @leifkristianssonl for surfacing this in #1.

Re-authentication keeps your full configuration. When your profile token is rotated or purged and the integration re-authenticates, it now recreates the profile with all your settings — reserve %, purchase price, tariffs and nameplate — instead of only the battery basics. Previously those silently reset on the server until you reopened Configure. (A plant-scoped price from a linked web profile is intentionally left to the website, where it's edited.)

Upgrading

Update via HACS and restart Home Assistant. No configuration changes needed.

v0.20.0 — Bearer token transport

The integration now sends your profile token in the Authorization: Bearer header
instead of the URL path. Tokens no longer appear in server access logs, proxies or
browser history. No action needed: your existing token keeps working, nothing about
the connection changes. Requires wolta.se API 0.44.0 or later (already deployed).

v0.19.0 – preliminary grades show up after a week

v0.19.0 – preliminary grades show up after a week

What changes

wolta.se now computes a first, preliminary optimisation grade after about 7 days of
data instead of 30 (api v0.43.0). The integration surfaces it:

• Optimisation grade shows the preliminary score as soon as the backend has one. Two
  new attributes let dashboards and automations tell the difference: preliminary
  (true until the plant has 30 days of data) and n_days (how many days the grade is
  based on). A preliminary score can swing from day to day — treat it as an early
  indication, not a verdict.
• Battery value per year keeps requiring a mature grade for its measured figure —
  a preliminary grade has a real score, but its yearly battery value is still a short
  window multiplied up to a year (the v0.18.1 problem in new clothes). The modelled
  fallback is unaffected.
• Measured-parameter repairs (adopt measured capacity/power/efficiency) wait until
  the grade is mature: a week of data systematically underestimates what the battery can
  do, and acting on it would suggest wrong values.

The economy sensors (plant savings, IRR, payback, actual savings) are unchanged — they
still require 30 days, because they are built on annualised absolute figures that do not
tolerate short windows.

Requires wolta.se API v0.43.0 for preliminary grades; with an older server everything
behaves exactly as before.

v0.18.1 – no annualised battery value from immature data

v0.18.1 – no annualised battery value from immature data

What changes

Battery value per year no longer shows a measured figure until the plant's
optimisation grade exists (at least 30 days of data — the same maturity bar as the grade
sensor).

Before this fix, a plant with only a few days of history could show a "measured" yearly
battery value that was really those few days multiplied up to a year — three summer days
× 122 presented as an annual figure, with the source attribute claiming measured.
Found on a 3-day-old plant the day after v0.18.0 shipped.

The modelled fallback (the decision engine's battery share) is unaffected and still shows
when available; the source attribute now tells the truth in that state (modelled).
With neither a mature grade nor a modelled value, the sensor is unavailable — consistent
with every other Wolta sensor on a young plant.

v0.18.0 – view-only mode for plants that stream another way

v0.18.0 – view-only mode for plants that stream another way

What changes

Pasting a token for a plant that already streams to wolta.se through its own connection —
the Sonnen webhook or a Reduxi bridge — no longer stops with an error. The flow now offers
to add the plant in view-only mode:

• You get all the Wolta sensors (optimisation grade, battery value, plant savings, IRR,
  payback, result status, data status) and the recompute button.
• Home Assistant never uploads anything to the plant: no sensor selection, no data writes.
  The plant's own connection keeps owning the data, exactly as before.
• Removing the entry never deletes anything on wolta.se.

If the saved token ever stops working (for example because you created a new one on
wolta.se), re-authentication simply asks for a fresh token instead of creating a new
profile.

Background

v0.17.0 blocked these plants outright to prevent two sources writing the same hours. The
block was correct but blunt — there was no way to just see such a plant in Home
Assistant. View-only mode is that way.

Requires wolta.se API v0.42.0 or later (the transport field and the server-side write
guards it builds on).

v0.17.0 – linking stops early when a plant already streams another way

v0.17.0 – linking stops early when a plant already streams another way

What changes

The "link an existing profile" flow now checks how the plant already gets its data. If the
plant streams to wolta.se through another connection — the Sonnen webhook or a Reduxi
bridge — the flow stops at the token step with a clear explanation, instead of asking you
to pick Home Assistant sensors.

Why

Completing that flow used to be possible, and it would have made two sources write the same
hourly rows on wolta.se: the existing connection and Home Assistant, each with its own
meters. The last writer would win hour by hour, so the stored data — and the optimisation
grade computed from it — would silently become a mixture of both.

If you want Home Assistant to stream instead, disconnect the other connection on your plant
page on wolta.se first, then link the profile here.

The server refuses these cases too (wolta.se API v0.42.0), so older versions of the
integration are also stopped — this release simply gives you the real explanation instead
of a generic error.

Nothing else changes

Creating new profiles, linking web-created or HA-streamed profiles, re-authentication and
all sensors behave exactly as in v0.16.0.

v0.16.0 – your plant keeps its identity when you set it up again

v0.16.0 – your plant keeps its identity when you set it up again

What changes

The integration now sends wolta.se a stable, random identifier for the plant it manages. The
backend never sees it in the clear beyond the request itself: it is salted and hashed into a
"plant fingerprint" and only ever used to recognise a plant it has already seen.

Two things get better as a result:

• Re-authentication keeps your history. If your profile ever needs re-authenticating,
  wolta.se can now tell that it is the same plant instead of quietly starting an empty one.
• The public statistics stop double-counting. wolta.se compares your grade against the
  median of all shared plants. A plant that was set up twice used to appear as two plants —
  once with a full history, once nearly empty — which dragged that median around.

Nothing to do

Existing installations are unaffected and need no action. The identifier is created when a new
entry is set up; entries created before this version derive theirs from their own config entry
id the first time they re-authenticate, and store it from then on.

Note on the identifier

It is a freshly generated 128-bit random value, not your Home Assistant instance id and not
anything derived from your entity names. It identifies one Wolta config entry and nothing else,
and it is not reused across integrations.

Removing and re-adding the integration produces a new identifier. For an entry Home Assistant
created, that is the whole story — removing it also deletes the profile on wolta.se, so there is
nothing left to recognise. For a profile you linked from wolta.se the profile deliberately
survives removal (it is yours, not ours to delete); re-linking it sends the new identifier and
wolta.se rebinds the same plant to it, so your history stays with you either way.

Requires wolta.se API v0.38.0 or later.

v0.15.0 – device link to the plant hub + nameplate power field

v0.15.0 – device link goes to the plant hub + nameplate power field

"Visit" link now opens your plant hub

wolta.se reorganised its pages in July 2026: everything about your stored plant — the
grade, economy, expansion calculator and all editing — now lives in a dedicated hub at
/anlaggning, while /optimeringsbetyg is the public landing page. The integration's
device link ("Visit" on the Wolta device page) previously pointed to the old address and
relied on a server-side redirect; it now goes straight to the plant hub with your profile
token, landing you on the overview of your own plant.

Nameplate power (kW) field

Parity with the nameplate capacity field from v0.13.0: the setup flow and the Configure
dialog (Battery section) now accept an optional nameplate power — the
manufacturer-rated kW figure. The grade itself is unchanged and always uses the
deliverable AC power you enter in the regular power field; the rated figure lets wolta.se
explain the difference when the power measured at your meter is lower than the brochure
number (inverter losses, derating). Optional and clearable, synced with your wolta.se
profile like every other field — set or clear it on either side and the other follows.

Requires nothing new on the backend side — the field has been live on wolta.se since
2026-07-15.

v0.14.0 – capex_scope attribute + whole-plant price safety in the options form

v0.14.0 – capex_scope attribute + whole-plant price safety in the options form

Companion release to the wolta.se backend's cost_scope work (2026-07-18): the backend now
records whether a profile's scalar purchase price covers the battery alone or the whole
plant (solar + battery), instead of every client having to guess.

capex_scope attribute on the IRR and payback sensors

The backend (2026-07-18) now tells clients which capital base the decision block's IRR and
payback figures are attributed to: battery (the battery alone – the norm for HA-created
profiles, whose cost field is battery-only) or plant (the whole plant, solar + battery –
profiles created in the wolta.se guide with a combined purchase price and later adopted into
HA). The sensors expose this as a capex_scope attribute so automations and dashboards can
label the figure correctly. On older backends the attribute is simply omitted.

Battery cost field hidden for whole-plant-priced profiles

For adopted wolta.se profiles whose stored purchase price covers the whole plant, the
options form's "Battery purchase price – battery only" field no longer applies: editing it
would silently reinterpret a whole-plant figure as battery-only. The field is now hidden for
those profiles (the economy section explains why) – the price is edited on your wolta.se
profile page, where the labels match the stored semantics. Profiles with a battery-only
price (all profiles created in HA) are unaffected.

v0.13.0 – Optional nameplate capacity field

v0.13.0 – Optional nameplate capacity field

Adds an optional Nameplate capacity (kWh) field to the plant setup step and the battery
section of the options form.

Why. Battery capacity means two different things: what the manufacturer prints on the
datasheet (nameplate) and what the battery actually delivers to your house on a full discharge
(usable). Some brands market the nameplate figure (a sonnen 10p/22 is "22 kWh" nameplate,
20 kWh usable), others market usable (a Tesla Powerwall 3 is "13.5 kWh" usable). The
integration's capacity field has always meant usable — that's what the grade benchmark
plays with, and that's what the measured-capacity Repair adopts.

Wolta's battery expansion calculator ("Is expanding worth it?" on wolta.se), however, prices
capacity the way the market does: per nameplate kWh. Without knowing your nameplate figure
it had to assume nameplate = usable, which understates the cost of real deliverable capacity
for batteries like sonnen's. With this release you can record both, and the expansion sweep
compares candidate sizes fairly: prices per nameplate kWh, value from the usable window.

What to do. If your battery's rated capacity differs from what it delivers (check your
datasheet), open the integration's options (or your wolta.se profile page) and fill in the new
field. If your battery is marketed by usable capacity, leave it empty — nothing changes.

Compatibility. Requires the wolta.se backend from 2026-07-14 or later (API 0.24.0); on
older backends the field is ignored. The usable-capacity field, the grade, and all Repairs
behave exactly as before. The field is optional and cleared the same way as the reserve floor:
empty the field and save.