CHANGELOG.md

# Changelog

## v3.0.101 (2026-08-17)

### Clearer message when the provider temporarily blocks sign-in

Kia/Hyundai's login can reject a sign-in as an "abusing request" after several
attempts from the same connection in a short time. Instead of a raw technical
error, the setup now recognises that page and explains what happened and what
to do — wait a bit and try once more, or use the manual paste option (which
runs the login in your own browser).

## v3.0.100 (2026-08-16)

### Signing in a Kia/Hyundai car is finally simple

The guided sign-in used to squeeze the login browser into a small embedded
frame inside the setup dialog — which on many setups showed nothing at all,
leaving you stuck on "please sign in" with no browser in sight. It now opens
the login browser as a full, real page in a **new tab**, with a large,
always-visible **"Open login window"** button as a guaranteed fallback if the
tab is blocked. Sign in there; the app keeps waiting and moves on by itself the
moment the connection succeeds.

### Connecting a car you already added is no longer a dead end

Two gaps made an *added-but-not-signed-in* car impossible to finish. The setup
wizard only appeared on a completely empty install, so once a car existed —
even one that was never connected — it never came back to help. And the
sign-in control on the Settings page started the login but never actually
opened a browser. Now the wizard reappears whenever no car is **connected**
yet and jumps straight to the sign-in step for the car that is waiting, and the
Settings sign-in opens the very same login window. Either path gets you signed
in.

### Cancelling the sign-in now closes the browser reliably

Cancelling the guided sign-in (or closing the dialog) left the login browser
running until its five-minute wait timed out — and a quick retry could stack a
second one on top. Cancel now force-closes the login browser right away. Under
the hood the sign-in page loads with an "eager" strategy plus a load timeout so
it no longer parks itself waiting for the page's trackers/reCAPTCHA to settle,
and cancel closes the browser at the process level rather than relying on the
busy automation session to notice.

### Fix: the Report page crashed before your first charge

Opening **Report** on a brand-new install — one that had recorded GPS trips
but no completed charge yet — returned an *Internal Server Error*. The page's
"is there any data to show?" check used an invalid query for the trips table,
which raised as soon as it ran (it only ran when no charges existed yet). The
check is now a plain, guarded count, so the Report page loads from the very
first day regardless of whether charges or only trips are present.

## v3.0.94 (2026-08-15)

### LUKS is now optional — new installs run unencrypted, existing ones keep it

Full-disk encryption of the data volume is no longer a requirement. A fresh
install keeps its SQLite database under the plain `data/` directory and never
sees anything LUKS-related; an install that already sits on an encrypted
`/dev/mapper/evdata` mapping keeps every LUKS feature exactly as before.

The app decides this from a single signal — whether the `evdata` device
mapper node actually exists (`setup_service.luks_in_use()`). Nothing is
configured or toggled by hand.

What changes on an unencrypted install:

* **First-run wizard** skips the "change the LUKS passphrase" step entirely.
  The welcome screen no longer lists it, the progress bar drops its pill, the
  device footer is hidden, and the wizard goes straight to creating the web
  login. Completion no longer waits on a passphrase change that can't happen.
* **Settings** hides the "LUKS passphrase" and "LUKS auto-unlock" cards and
  their sidebar entries.

Encrypted installs are unaffected: the passphrase step, the auto-unlock
controls, and the change-passphrase card all show up as they always have.

## v3.0.93 (2026-08-14)

### Fix: the CO2 self-heal now actually runs after an update

The previous release taught the backfill to heal charges that were left without
CO2, but nothing triggered it on a normal update. The backfill only started
from a one-time historical cleanup (which runs once and never again), a CSV
import, or the manual button in settings — so simply deploying the new version
left the missing days untouched.

The backfill is now kicked automatically on every boot. It is a cheap no-op
when nothing is missing, respects the bounded attempt counter so a genuinely
unavailable date is not re-polled forever, and will not spawn a duplicate
worker if the historical cleanup started one in the same tick — the running
flag is now claimed synchronously before the thread is spawned.

## v3.0.92 (2026-08-14)

### Fix: days with no CO2 on charges now self-heal from the charge time

Some charges were showing no CO2 intensity at all. The cause was the ENTSO-E
backfill's "mark as attempted" behaviour: after a single failed lookup it wrote
`co2_g_per_kwh = 0` onto the charge. That was wrong twice over:

* A grid charge is never actually 0 g/kWh — even a near-100% renewable hour
  carries some fossil generation — so the value was physically impossible and
  quietly under-counted the total CO2 in reports and stats.
* A charge created before ENTSO-E had published its data (the grid figures
  arrive with a delay of a day or two) got frozen at that fake 0 and was
  **never re-fetched**, so the whole day stayed without a real value.

The backfill now treats a charge as "missing CO2" when its value is `NULL`
**or** `0`, so previously-poisoned rows heal themselves on the next run. Instead
of poisoning, a failed lookup increments a new `co2_attempts` counter and the
charge is retried on later runs until the data appears, up to a bounded number
of attempts so a genuinely unavailable date is eventually left alone.

Every lookup keys off the charge's own date and charging time, with an
escalating fallback so a missing bucket for the exact hour still yields a
sensible value from the same day's grid mix: time-weighted charging window →
the charging start-hour snapshot → the daily average.

## v3.0.91 (2026-08-08)

### Add: eight more EV battery OBD decode profiles

The OBD reader previously knew three battery maps (Kia/Hyundai, XPENG and the
generic SoH-only fallback). It now ships documented community maps for a wide
range of other electric cars, each transcribed from an open reference
implementation and carrying its source in a code comment:

* **Jaguar I-Pace** — BECM on 7E4/7EC, UDS service 22 (source: OpenVehicles/OVMS).
  Full SoC, SoH, pack voltage/current, min/max cell voltage and pack temps.
* **MG / SAIC** — ZS EV and MG5 on 781/789, plus a separate **MG4/MULAN** map
  on 7E5/7ED (sources: community Torque PID lists, OBDb, the MGEVs project).
* **BYD** — Atto 3 and Dolphin on 7E7/7EF (sources: OVMS, WiCAN, community PID
  list). Note: these use little-endian scalars, now supported by the decoder.
* **Nissan Leaf / e-NV200** — LBC on 79B/7BB using KWP service 21 group reads;
  full 96-cell voltage array and pack thermistors (source: OVMS, CanZE-style
  decoders). SoC/health scalars use the 2018+ layout.
* **Renault Zoe** — both the Ph1 (79B/7BB, service 21) and ZE50/Ph2 (29-bit
  extended addressing, service 22) battery controllers (source: CanZE).
* **VW MEB platform** — ID.3/4/5, Škoda Enyaq, Cupra Born, Audi Q4 e-tron on
  29-bit addressing, service 22 (sources: the VW-MEB UDS PID lists, evDash).

To support these the decode engine gained: little-endian field byte order, the
`(raw − k) × scale` encoding convention, multi-byte and per-cell-offset cell
arrays, KWP service 0x21 group reads, and 29-bit extended CAN addressing. The
ECU discovery scan now also probes the new 11-bit BMS addresses (MG, BYD, Leaf,
Jaguar) and recommends the matching profile. Every brand still maps to its best
default profile automatically, and any alternative stays selectable in the UI.

As with the existing maps, these byte offsets are community-sourced and not
bench-verified on the developer's own car, so every raw frame is stored and can
be re-decoded if a value looks wrong. Tesla is intentionally not included: it
exposes no standard UDS battery PIDs — its pack data is only reachable by
passively sniffing the raw vehicle CAN bus with a model-specific harness, which
a browser-driven ELM327 cannot do.

## v3.0.90 (2026-08-08)

### Change: reconcile the certificate SoH from both independent signals

The battery certificate previously headlined the coulomb-counted SoH from the
charge history on its own. That figure is optimistically biased and noisy —
charging-loss modelling and ±1 % SoC quantisation push it up, and on a real
read its per-session spread was wide (e.g. 49–70 kWh), so the median could land
at a falsely perfect **100 %**.

* **Cap the measured SoH at 100 %.** A *measured* usable capacity above nominal
  is a measurement artefact, not a battery healthier than new, so the coulomb
  count can no longer read above 100 %.
* **Reconcile two independent signals.** When both a solid coulomb-count and a
  direct OBD BMS-register read exist, the headline SoH is now the **mean** of
  the two — the independent charge-history measurement and the car's own
  considered estimate. Averaging cancels part of the coulomb bias and is more
  defensible than trusting either alone. The cloud-API BMS value is
  deliberately excluded from the mean (it is baseline-scaled and can read
  >100 %, which is unphysical); it is still printed separately for reference.
* Both source values remain listed on the certificate, so the reconciliation
  is fully transparent. When only one signal is available the behaviour is
  unchanged.

## v3.0.89 (2026-08-08)

### Add: live OBD dashboard — every sensor, graphically

The OBD page now has a **live view** that reads the whole battery PID set on a
loop and renders every sensor the car reports as its own gauge tile — value,
a coloured meter bar and a rolling sparkline of the recent history — grouped
into Battery, Power, Cells, Temperature and More. It shows SoC (BMS + display),
SoH, pack voltage/current, instantaneous **power (kW, derived from V × A)**,
cell average/min/max/spread/count, pack temperatures and the 12 V battery, plus
the live per-cell voltage chart updating in real time — a continuous
diagnostic-tool-style readout, in the browser over the same USB/BLE adapter.

* **Connect once, poll in a loop.** The read sequence was refactored into
  shared `initProfile` + `pollFrames` helpers so the one-shot read and the live
  loop share the exact same init and framing (ISO-TP length byte under
  `ATCAF0`, stray-frame skipping) — a fix in one benefits both.
* **Decode without persisting.** A new `POST /api/vehicles/<id>/obd/live`
  endpoint decodes each poll and returns the sensor values but stores nothing,
  so a long live session doesn't fill the database. A **"save snapshot"** button
  replays the last captured frames through the normal ingest path to store the
  current state as a measurement that feeds the certificate.
* Adjustable refresh (as-fast-as-possible / 1 s / 2 s / 5 s), a live status
  pill, poll counter and per-cycle timing. New strings added in all six
  languages.

## v3.0.88 (2026-08-08)

### Fix: correct Kia/Hyundai battery decode + per-cell certificate chart

A live read from a real Kia Niro EV (awake, ready-to-drive) exposed two decode
bugs that made the result "look decoded but wrong" — SoH 3481.9 %, a 5.100 V
cell, most pack values missing:

* **Stray frame clobbered the main PID.** The `220101` reply arrived with a
  queued DTC single-frame (`7EC 03 59 02 …`) printed *ahead* of the real
  `62 01 01 …` answer. ISO-TP reassembly took that first single-frame as the
  whole message and threw the rest away, so SoC, pack voltage/current, pack
  temperatures, the 12 V reading and the cumulative counters all came back
  empty ("much more data should be read"). Reassembly now takes the request
  PID and skips any frame whose service echo isn't the one it asked for, so the
  real answer is reassembled regardless of what the adapter queued in front.

* **Every Kia/Hyundai field was one byte off.** The real reply carries an extra
  status byte after `62 01 01`, so the community offset table sat one byte too
  low across the board. Corrected and cross-checked field by field against the
  capture: SoC 66 %, pack 376.0 V, 12 V 14.8 V, cells 3.82–3.84 V, temps
  28–29 °C, SoH 94.7 %, display SoC 68 %. The cell block now reads
  max/max-no/min/min-no exactly, and cell voltages start at the byte that holds
  the real 3.82 V run instead of the trailing `0xFF` that decoded as a bogus
  5.10 V cell. A regression test pins the whole capture.

### Add: per-cell voltage chart

The battery certificate now renders one bar per cell with its voltage and its
deviation from the pack mean (in mV and %), colour-coded so a weak or runaway
cell stands out — the "each individual cell" view. The OBD page shows the same
strip inline right after a read, and the certificate preview now refreshes with
the freshly read cells instead of the stale page-load state. New strings added
in all six languages.

## v3.0.87 (2026-08-08)

### Change: no battery certificate without an actual state-of-health

A battery-*health* certificate is only meaningful if it can state a real SoH.
Until now the certificate was issued even when no SoH could be determined at
all — it simply printed an "n/a" grade. For a car whose cloud API never reports
a BMS SoH (e.g. ev-mike), that produced a certificate with no health figure,
which is worse than none.

The certificate is now refused outright when **none** of the three SoH sources
yields a value:

* the car reports no BMS SoH over the cloud API, **and**
* no OBD/ELM327 reading is on file, **and**
* there aren't enough wide-window charge sessions to coulomb-count a measured
  SoH from the charge history.

Charge and drive data alone remain fully sufficient the moment they produce a
measured SoH — that path is unchanged and still issues a certificate without any
dongle. Only the genuinely empty case is blocked. When it is, the OBD page and
the export button both explain that the vehicle reports no SoH via the API and
the charge history isn't enough to measure one, and point the owner to reading
the battery with an OBD dongle (or logging more near-full charges).

`compute_battery_health` now exposes a `can_certify` flag; the inline preview,
the export route and `generate_certificate` all gate on it. Messages updated in
all six languages.

## v3.0.86 (2026-08-08)

### Fix: battery reads returned "NO DATA" on a fully awake, drive-ready car

The real cause of the persistent `NO DATA` — seen even with the ignition on and
the car ready to drive — was in how requests were framed, not the profile or the
car being asleep. Every read profile initialises the ELM327 with `ATCAF0` (CAN
auto-formatting off) so the app can reassemble multi-frame replies itself. But
with auto-formatting off the ELM327 also stops adding the ISO-TP PCI length byte
to what it *sends*. A request such as `220101` then went on the wire as
`22 01 01 …`, whose leading nibble reads as a "consecutive frame" marker rather
than a valid single-frame request — so the battery control unit silently dropped
every query and answered nothing.

The reader now prepends the length byte itself whenever auto-formatting is off,
turning `220101` into `03220101` (and `0100` into `020100`, etc.). This applies
to both the normal read and the ECU scan probes, which were malformed the same
way. Replies are still keyed by the logical PID, so decoding is unchanged. A
correctly matched profile on an awake car now gets real frames back instead of
`NO DATA`.

## v3.0.85 (2026-08-08)

### Fix: "NO DATA" now points at the most common cause first (car asleep)

When every battery query comes back `NO DATA`, the reader used to send the user
straight to the ECU scan, implying the profile addressed the wrong ECU. For a
correctly matched profile that is rarely the reason: a parked car puts its
battery control unit to sleep, and an asleep BMS answers nothing on any address.
The all-`NO DATA` hint now leads with that — switch the ignition on (accessory
position) so the BMS wakes, then read again — and only falls back to "run the
ECU scan to find the right address" if waking the car does not help. Text
updated in all six languages. No behaviour change beyond the guidance copy.

## v3.0.84 (2026-08-08)

### Fix: XPENG battery read returned only "NO DATA" + new ECU scan

The OBD reader connected to the dongle fine and the ELM327 answered every AT
command, but each battery query came back `NO DATA`. The cause was the profile:
XPENG was falling back to the Kia/Hyundai map, which addresses the BMS at header
`7E4` with PIDs `2201xx`. XPENG does not answer there — its BMS lives on header
`704` (response `784`) and uses UDS data identifiers of the form `2211xx`. Every
request therefore hit an address no control unit replies on.

- **New XPENG decode profile** (`services/vehicle/obd_decode.py`) — request
  header `704`, UDS service 22 identifiers `221101/03/05/06/07/08/09` and
  `22110A` for pack voltage/current, cell min/max voltage, min/max temperature,
  SoC and SoH. The init sequence pins ISO-TP flow control to the `704` header
  (`ATFCSH`/`ATFCSM1`) and filters replies to `784` (`ATCRA`), so multi-frame
  identifiers come back reliably instead of silently timing out. XPENG vehicles
  now auto-select this profile. The byte offsets follow the only public XPENG
  reverse-engineering (G6) and are labelled experimental/unverified — as with
  every profile, the raw frames are stored so a capture can be re-decoded once
  cross-checked against a reference read.
- **ECU scan** — a new "No data? ECU scan" button diagnoses a car that answers
  nothing. It auto-detects the CAN protocol, enumerates which control units are
  alive on the bus (functional `0100`), then probes the known EV battery
  addresses and reports which one responds — telling apart "704 answered, use
  the XPENG profile" from "the OBD port is gateway-locked, battery data isn't
  reachable." When a normal read comes back all-`NO DATA`, the reader now points
  straight at the scan instead of saving an empty reading. If the scan finds a
  match it offers a one-click "apply recommended profile & read".
- **Decode engine** — field specs gained an `offset` term (`raw * scale +
  offset`) for encodings like the XPENG pack current (`raw * 0.5 - 1600`).
- Full translations for the new strings across all six languages; new unit tests
  for the XPENG layout, the `offset` term and the scan classifier/interpreter.

## v3.0.83 (2026-08-08)

### Fix: Bluetooth-LE dongles that connect but report "0 services"

Some BLE adapters — notably the Vgate iCar / vLinker family that enumerates as
"IOS-Vlink" — paired successfully but then stalled with "Connected, but no
readable OBD service found" and the blue LED still blinking. The cause was in
`templates/obd.html`: Web Bluetooth only ever exposes services that are declared
up front in `optionalServices`, and `getPrimaryServices()` returns just that
allow-listed subset — never every service on the chip. Adapters whose service
UUID was missing from the list therefore connected but showed zero services.

- **Broader service allow-list** (`templates/obd.html`) — added the Vgate
  iCar / vLinker virtual-serial UUID (`e7810a71…`), the iCar Pro 2S service
  (`000018f0…`) and a couple more common clone UUIDs. Fixed a malformed entry
  (`18f0e400…`) that could never match.
- **Self-healing re-grant** — a dongle remembered from an earlier session keeps
  the service allow-list it was first granted with, so a previously-paired
  adapter could stay serviceless even after the list was widened. When that
  happens the chooser now re-opens once automatically so a fresh grant picks up
  the current UUID list; after that it connects straight through.
- Corrected the misleading in-code comment that claimed the fallback
  enumerated every service.

## v3.0.82 (2026-08-08)

### Live pairing feedback so connecting is never a silent box

Connecting a dongle used to jump straight from "Connecting…" to either a result
or "Failed", with nothing in between — no sign the pairing was running, which
device was chosen, or how far it got. The OBD page now narrates every phase.

- **Connection-state pill** (`templates/obd.html`) — a coloured badge above the
  progress bar always shows the current phase (Ready → Connecting → Pairing →
  Connected → Reading → Done, or Failed), with a spinner while work is in
  flight and a green check when it succeeds.
- **Which device** — the name of the adapter actually being talked to is shown
  next to the badge (the Bluetooth device name, or the USB vendor:product id),
  so it's obvious the right dongle was picked.
- **Step-by-step Bluetooth trace** — pairing now reports each stage as it
  happens: connecting to the adapter, searching for OBD services, how many
  services were found, and confirmation once a readable data channel is open.
  A patience hint reminds the user that first-time pairing can take a few
  seconds while the blue LED is still blinking.
- **Full 6-language parity** — 15 new strings added to all of de/en/es/fr/it/nl
  (1285 keys each).

## v3.0.81 (2026-08-08)

### Reliable Bluetooth dongle discovery + auto-reconnect

A blinking-blue BLE dongle that "isn't found" traces back to two gaps in the
in-browser reader: it probed only four hard-coded service UUIDs and gave up if
none matched, and it re-showed the device chooser on every visit. Both are now
fixed so the same adapter connects on the next try without fuss.

- **Wider BLE service discovery** (`templates/obd.html`) — the known-UUID list
  grew (fff0/ffe0/ffb0/ffc0/ffd0/ffe5 plus the Nordic UART service), and when
  none of the named services is present the reader now enumerates *every*
  primary service the device exposes and picks the first one with a writable
  characteristic, subscribing to its notify/indicate channels. This makes
  practically any Bluetooth-LE ELM327 usable regardless of its UUID.
- **Connect retry** — cheap clones routinely reject the first GATT connect
  while the LED is still blinking; the reader now retries the connection a few
  times with backoff before failing.
- **Remembered adapter, no more picker** — once an adapter is granted, USB
  `getPorts()` / Bluetooth `getDevices()` hand it straight back, so the next
  read connects directly without the chooser dialog. A "choose a different
  device" link forces the picker again when needed.
- **Actionable failure hint** — if a device connects but exposes no readable
  OBD service, the message now explains the blinking-blue (not-connected)
  case and that classic-Bluetooth dongles can't be reached from a browser.
- **i18n** — four new `obd.*` keys across all six languages (full parity,
  1270 keys each).

## v3.0.80 (2026-08-08)

### OBD adapter picker with a remembered preferred dongle

The OBD page listed effectively a single generic adapter. It now offers a
curated dropdown of adapters known to work for in-browser battery reads, and
the chosen one is remembered and pre-selected on every future visit.

- **Dongle catalog** (`services/vehicle/obd_decode.py`) — a data-driven list of
  ~13 adapters: OBDLink SX/EX/CX, Vgate vLinker FD+/MC+ and iCar Pro BLE,
  Veepeak OBDCheck BLE/BLE+, plus generic ELM327 USB/BLE entries. Each entry
  carries its transport (`usb` / `ble`), the recommended USB baud rate, and a
  `recommended` quality flag. Classic-Bluetooth (e.g. OBDLink MX+) and WiFi
  adapters are listed but flagged `supported: false`, because a browser can
  only reach Web Serial (USB) and Web Bluetooth (BLE) — never classic BR/EDR
  or WiFi.
- **Preferred-adapter selection** (`templates/obd.html`, `app.py`) — picking an
  adapter presets the USB baud rate, steers the user to the correct connect
  button (USB vs Bluetooth), greys out USB-only fields for BLE adapters, and
  shows a clear warning for adapters a browser can't reach. The choice is
  persisted server-side (`AppConfig` key `obd_preferred_dongle`, new
  `POST /api/obd/dongle`) so it is always pre-selected afterwards.
- **i18n** — nine new `obd.dongle*` keys translated across all six languages
  (full parity, 1266 keys each).

## v3.0.79 (2026-08-08)

### English changelog + README refresh for the new features

Documentation pass, no behaviour change.

- **`CHANGELOG.md`** — the recent entries (v3.0.74–v3.0.78) were still in German;
  translated to English so the whole changelog is one language. The last
  third-party trademark references were removed as well (`grep -i` now finds
  none anywhere in the repo), and the personal-name attributions ("… asked/
  wanted …") were dropped from the entries — the changelog describes *what*
  changed, not who requested it. The `ev-robert` install hostname stays where it
  appears in production incident notes, since it is a technical identifier.
- **`README.md`** — documented the features shipped since the last README update:
  the **self-generated battery-health certificate** (coulomb-count method, A–F
  grade + benchmark, net-referenced SoH), the **in-browser OBD/ELM327 readout**
  (Web Serial / Web Bluetooth, per-family PID table), the **certificate inline
  on the OBD page** with export button, and the new **first registration** +
  **net/gross capacity** vehicle settings. The i18n note now reflects **full
  6-language parity** (1257 keys each) instead of the old "~800 strings, de/en
  only" wording.

## v3.0.78 (2026-08-08)

### View the battery certificate right on the OBD page (+ export button)

The battery certificate can now be seen behind the OBD menu item, the way the
PDF looks, with an export button. Below the OBD readout area there is now an
**embedded live preview of the certificate** — the **real PDF** is shown inline
(not a rebuilt HTML copy), so it looks **exactly the way it prints/exports**,
with no risk of the preview and the PDF drifting apart. The most recent
measurement read via OBD/ELM327 is pulled in automatically.

- **New inline delivery of the certificate route** (`app.py`,
  `/vehicles/<id>/certificate.pdf`): the query parameter **`?inline=1`** serves
  the PDF with `Content-Disposition: inline` for embedding; without the
  parameter it stays a download (`attachment`) — the export button uses exactly
  that.
- **OBD page** (`templates/obd.html`): new "Battery certificate" section with a
  **grade badge** (grade + SoH in the grade colour), the embedded PDF
  (`<object>` with `<iframe>` and text fallback), **"Open in new tab"** and
  **"Export as PDF"**. If there is no data basis yet, a hint appears instead of
  the preview.
- **`obd_page` route** (`app.py`): computes the (cheap) health metrics via
  `compute_battery_health` and shows the preview only when there are charges,
  syncs or an OBD reading (`cert_available`).
- **i18n**: 6 new keys (`obd.cert_title`, `obd.cert_subtitle`,
  `obd.cert_export`, `obd.cert_newtab`, `obd.cert_none`,
  `obd.cert_pdf_fallback`) in **all 6 languages** (parity of 1257 keys per file).

## v3.0.77 (2026-08-08)

### Remove a third-party trademark name from the certificate (trademark protection)

A third-party trademark name must not appear in the app for trademark-protection
reasons. The foreign brand name was removed **completely** from the app — not
just from the visible PDF text, but also from all inline fallbacks, comments,
docstrings and the changelog. The methodology itself (coulomb counting,
SoH = usable / nominal) is unchanged; only the wording is now generic.

- **Visible certificate text (`cert.basis_line`, `cert.limits`)** reworded in
  **all 6 languages**: "premium full-discharge lab test" → "professional battery
  test via full discharge"; the branded example in "(e.g. …, TÜV)" was dropped
  down to "(e.g. TÜV)".
- **`services/battery_cert_service.py`** — docstring, grade comment and the
  three German inline `default=` texts (`cert.basis_line`, `cert.limits`,
  `cert.limits_with_obd`) neutralised.
- **`app.py`** — docstring of the certificate route de-branded.
- **`CHANGELOG.md`** — the v3.0.73 entry and the v3.0.75 terminology note
  de-branded.

## v3.0.76 (2026-08-07)

### All 6 languages at full parity (standing order "translate everything")

Translate everything, always — standing order. Until now only **de/en** were
kept at full parity; **fr/es/it/nl** ran as "best-effort" with a historical
backlog of **293 keys** each, bridged by the German fallback of `t()`. That is
no longer a valid policy: **all 6 languages are fully translated and kept at
parity**.

**What was done:**
- **293 missing keys** in **fr, es, it, nl** fully translated
  (dash/edit/err/flash/input/maint/msg/raw/report/set/trips) — covering, among
  others, the complete **report**, the **CSV import wizard** (preview, modes,
  warnings), the **trip/stop editor**, the **charging-operator management**,
  **vehicle raw data** and the location pickers.
- Two orphaned wizard keys (`wiz.step_1_of_2`, `wiz.step_2_of_2`) from an
  earlier 2-step wizard removed (long gone in de/en, no longer referenced
  anywhere).
- **Result:** de, en, fr, es, it, nl now sit at **1251 keys each** — identical
  key sets, **zero** missing keys across all languages.

**Side finding + fix (placeholder bug):** the parity check surfaced three
pre-existing placeholder divergences in fr/es/it/nl:
- `flash.vehicle_test_ok` wrongly contained `{info}` even though the caller
  (`app.py:2595`) only passes `name=` → `str.format()` raised `KeyError`, and
  the string was shown unformatted with a visible `{info}`. **Fixed.**
- `flash.vehicle_sync_no_data` (missing `{name}`) and `flash.vehicle_sync_ok`
  (missing `{summary}`) silently lost their values → placeholders restored.

**Policy update (in force from now on):** new/changed user-facing strings are
added in **all 6 languages**, not just de/en. Inline `default=` stays a
last-resort stopgap, not a substitute for real keys.

## v3.0.75 (2026-08-07)

### i18n follow-up for the certificate + OBD

The question was whether the last changes (v3.0.73 battery certificate, v3.0.74
OBD/ELM327 + net/gross) had accounted for **i18n**. Answer: only partly — the
follow-up is now complete.

**What was missing:**
- The entire **OBD page** (`obd.html`) had all its text only as German
  `default=` inline fallbacks — there were **no** `obd.*` keys in a single
  language file. English (and all other) users saw German.
- In the OBD page's JavaScript the **result-tile labels** ("cell spread",
  "cells", "temperature", "12V battery" …) plus two status/log strings were
  **hard-wired in German**, bypassing `t()` entirely.
- **7 keys** (`nav.obd`, `set.fleet_field_battery_gross`, …) were in `de.json`
  but missing from `en.json`.

**What is done now:**
- All hard JS labels of the OBD page run through a `t()`-fed `T.res`/`T.fields`
  object (new keys `obd.res_*`, `obd.profile_load_failed`, `obd.log_error`).
- **35 `obd.*` keys** (page + result labels) added to `de.json` **and**
  `en.json`; the 7 missing `set.*`/`nav.obd` keys backfilled in `en.json`
  → **de and en back at full parity** (1251 keys each).
- All **101 keys of the recent changes** (`cert.*`, `flash.cert_*`, `obd.*`,
  new `set.fleet_*`) propagated with clean translations to **es, fr, it, nl** —
  including correctly preserved placeholders (`{n}`, `{name}`, `{e:.1f}` …) and
  technical terms (SoH, BMS, kWh, CO₂, TÜV).

**Note:** es/fr/it/nl have a **pre-existing** backlog of ~291 keys (not from
these changes); the German fallback of `t()` still covers those. The backend
additions (XPENG connector, brand names) need no i18n.

## v3.0.74 (2026-08-07)

### First registration + net/gross capacity, and OBD/ELM327 readout in the browser

Three related additions around the battery certificate: (1) one must be able to
enter the **age / first registration**, (2) a Kia has **64 kWh net / 67.3 kWh
gross** — does that need to be accounted for in the test/processing?, and (3) an
**ELM327 OBD dongle** (CarScanner) already reads everything from cell voltage to
temperature — that should be possible directly in the EV Tracker app in the
browser.

**Net vs. gross (the answer):** SoH is *always* referenced to the **usable net
capacity** (64 kWh), never to gross. Both the coulomb counting and the BMS value
measure the usable window — referencing them to 67.3 kWh gross would
systematically produce a too-low SoH. `battery_kwh` therefore stays the net
number (basis for kWh, cost, CO₂, loss, SoH); gross is only carried
informationally and printed on the certificate (buyers expect both numbers).

- **`models/database.py`**
  - `Vehicle.first_registered_at` (first registration) — the *calendar clock*
    the battery actually ages on. Drives age + degradation benchmark on the
    certificate. `acquired_at` stays the start of ownership.
  - `Vehicle.battery_kwh_gross` — optional gross capacity (buffer info).
  - **`ObdReading`** — new table: a cell snapshot straight from the BMS
    (SoH register, cell voltages min/max/avg + spread in mV, pack
    voltage/current, temperatures, 12V battery, full cell/temp arrays and the
    raw frames for later re-decoding).
- **`services/vehicle/obd_decode.py`** — new, pure decoder: ISO-TP reassembly of
  the ELM327 frames + a **data-driven PID table** per vehicle family
  (`kia_hyundai_ext` for Kona/e-Niro/Soul on header 7E4, plus a generic
  `generic_ev` fallback over standard PID 015B). Offsets follow the community
  map (EVNotify/SoulEV/CarScanner) and live in *one* clearly commented place;
  the raw frames are stored in case an offset needs to be corrected for a model.
- **`templates/obd.html` + `/obd` page** — the browser as transport: connect an
  ELM327 via **Web Serial (USB)** or **Web Bluetooth (BLE)**, initialise, query
  PIDs, post raw text to the server. Live progress, raw-data log, result cards
  (SoH, cell spread with a traffic light, temperatures, pack, 12V). "As easy as
  possible": plug in → button → values. (Chrome/Edge desktop + Android; iOS
  cannot do Web Serial/BLE.)
- **`app.py`** — `GET /api/obd/profile/<id>` (profile/init/PID list),
  `POST /api/vehicles/<id>/obd/ingest` (decodes + stores, returns the values),
  `/obd` page. The migration adds the two Vehicle columns; `obd_readings` is
  created by `create_all()`.
- **`services/battery_cert_service.py`** — the certificate now uses the first
  registration for the **battery age** (fallback: start of ownership), shows
  **net/gross** separately, and pulls in the **latest OBD reading**: a new "cell
  data (OBD)" section with cell spread/temperatures (exactly what the
  charge-data-only certificate explicitly *could not* do before), and the BMS
  SoH via OBD counts as its own, prioritised SoH source. The limitations text
  adapts depending on whether cell data is present.
- **`templates/settings.html`** — form fields for first registration + gross
  battery (with net/gross hints), an OBD button per vehicle row, and the
  open-ev-data lookup also fills in gross when available.
- **`services/vehicle/build_ev_specs.py` / `ev_specs_service.py`** — the spec
  extract now carries `gross_kwh` (when ≠ net).
- **Tests** — `tests/test_obd_decode.py` (ISO-TP reassembly, signed/unsigned
  extraction, Kia profile round-trip, generic fallback, partial data);
  `tests/test_battery_cert.py` extended with first-registration age, net/gross
  and OBD-fed certificates.

## v3.0.73 (2026-08-07)

### Battery-health certificate (self-generated)

When selling or archiving a vehicle, the goal was a self-created battery
certificate — like an independent professional battery test — that can be
handed to a buyer, runnable at any time. A professional full-discharge test
measures usable capacity by integrating the energy delivered over a full
100→10 % discharge and dividing by the pack's nominal capacity
(`SoH = usable_now / nominal`); a quick/flash test just reads the BMS' own
SoH. We already log *thousands* of
charge sessions, so we reconstruct the same measurement without a lab
discharge: every charge with a wide-enough SoC window is a partial
capacity sample, and the median over many sessions cancels the noise.

- **`services/battery_cert_service.py`** — new service.
  - `_measured_capacity()`: coulomb/energy counting per charge —
    `net_kWh / (SoC_window/100)` extrapolated to a full pack, where
    `net = kWh_loaded − loss_kWh`. Only counts windows ≥ 25 % SoC (small
    windows amplify the ±1 % SoC quantisation into huge capacity error),
    rejects per-session capacities outside 40–115 % of nominal, and takes
    the **median** so outliers don't move the number. Splits early-vs-
    recent thirds for a degradation trend.
  - `compute_battery_health()`: assembles the certified SoH (measured
    when ≥ 3 samples, else the baseline-scaled BMS SoH), an A–F grade,
    the age/mileage benchmark vs the ~2.3 %/yr fleet mean, warranty-floor
    headroom (70 %), charging-stress factors (DC share, equivalent full
    cycles, deepest logged discharge, avg window) and the data basis.
    Degrades gracefully — sparse cars still get a certificate that marks
    SoH "not determinable".
  - `generate_certificate()`: renders a signed-style FPDF certificate
    (grade badge, both SoH signals, benchmark, usage, SoH-trend chart,
    methodology + honest limitations note — cell-level voltages/balancing
    are explicitly out of scope as they need direct BMS/OBD cell access).
- **`app.py`** — `GET /vehicles/<id>/certificate.pdf` streams the PDF for
  any vehicle (active *or* archived), available on demand at any time.
- **`templates/settings.html`** — a certificate (badge) button on every
  row of the Fahrzeuge table.
- **`translations/de.json`, `en.json`** — full `cert.*` string set (other
  languages fall back to German).
- **`tests/test_battery_cert.py`** — seeds an in-memory fleet and verifies
  the coulomb-count math, the narrow-window/outlier filters, the grade,
  PDF rendering and the sparse-data fallback.

## v3.0.72 (2026-08-07)

### Add XPENG vehicle brand via the Enode aggregator API

XPENG ships no public brand SDK (its open platform is geo-restricted and
account-gated), so — like the community Home Assistant integrations and
Homey's XPENG Car Manager — this connects through the Enode aggregator's
documented OAuth2 + REST API.
- services/vehicle/connector_xpeng.py: new XpengConnector. OAuth2
  client_credentials against Enode (HTTP Basic with the app keys) yields a
  Bearer token, cached module-side until ~60 s before expiry, then
  GET /vehicles enriched with chargeState/odometer/location/information.

## v3.0.71 (2026-08-06)

### Report: Zusatzkosten tile sub-line no longer shows cryptic "S €… / B €…"

The secondary "Zusatzkosten" KPI tile broke its total (`€1,99`) down by component in the sub-line, but prefixed each component with a bare, unexplained single letter — `S €1,99` for the start fee, `B €…` for the blocking fee. With only a start fee present that read as "S €1,99" directly under "€1,99", which looks like nonsense rather than a breakdown.

- **`templates/report.html`** — the sub-line now uses the already-loaded, translated labels `T.start_fee` ("Startgebühr") and `T.block_fee` ("Strafgebühr") instead of the hard-coded `S` / `B` letters, matching the labels used on the Zusatzkosten chart legend. No new strings, no backend change.

## v3.0.70 (2026-08-04)

### Open Charge Map: auto-suggest the operator from the charge location

Evaluated the `juherr/awesome-ev-charging` list for anything usable here (full writeup in `docs/awesome-ev-charging-evaluation.md`). Conclusion: it's an infrastructure/protocol list (OCPP, OCPI, ISO 15118, Eichrecht, wallbox firmware, CPO/EMSP backends) — ~90 % irrelevant to a vehicle-side consumption tracker. The one clean, on-pattern win is **Open Charge Map**, a free open registry of ~600k charging stations with operator + coordinates. It slots directly onto features we already have: the charge form captures the car's GPS, reverse-geocodes it via Nominatim, and auto-fills price from the operator directory. OCM lets us derive *which CPO* that coordinate belongs to and pre-fill the operator field.

- **`services/openchargemap_service.py`** — mirrors `geocode_service.py`: process-wide rate limiter, permanent DB cache (`OcmCache`, auto-created by `create_all()` — no migration), every failure path degrades to `None` so the charge form never hangs on a third-party API. Nearest-station selection recomputes distance locally via haversine rather than trusting OCM's unit-dependent `Distance` field. Placeholder operators ("(Unknown Operator)" etc.) are treated as no-operator. Pure logic is offline unit-tested in `tests/test_openchargemap.py` (15 checks).
- **`GET /api/locations/operator?lat=&lon=`** — read-only, analogous to `/api/locations/reverse`. Returns `{operator: null}` on no-key / unreachable / nothing-close, so it's always safe to call.
- **Charge form** (`input.html`) — after the car-GPS or phone-GPS button sets coordinates, it asks the endpoint and, **only if the operator field is still empty and the station is within 150 m**, pre-selects the operator (which then triggers the existing price auto-fill). A manual pick always wins. Fully additive, `try/catch`-guarded — if the suggestion path throws, the GPS/geocode flow is untouched.
- **Settings** — optional Open Charge Map API key (`AppConfig['ocm_api_key']`), sitting next to the ENTSO-E token. OCM now gates its API behind a free key; without one the feature simply does nothing (no regression). New i18n strings added to all six locales.

### Deployment: Dockerfile

Added a `Dockerfile` (+ `.dockerignore`) that runs the app on its canonical internal port 7654 in HTTP mode (`python app.py`; `APP_HOST`/`APP_PORT` overridable), with `data/` declared as a volume so charge history survives container replacement. TLS is expected to be terminated by the deployment's reverse proxy.

## v3.0.69 (2026-07-30)

### SoC-rise fallback detector no longer walks over is_charging=True rows

Follow-up bug uncovered a day after v3.0.68 shipped. Observed on the Kia install 2026-07-30 06:00: the overnight wake-up sync arrived at the same SoC as the previous day's charge-end (both 87 %). The `_detect_auto_charge_from_soc_rise` fallback — meant for Skoda/VAG where cached polls rarely include an `is_charging=True` frame — walked back through the *entire* is_charging=True run of yesterday's charge to the valley at the actual charge-start (37 %), matched yesterday's `needs_review=True` Charge on SoC-range overlap, and rewrote the merge target's `charge_end_hour` (14 → 6) and `created_at` (yesterday-14:03 → this-morning-06:00) via the merge path. The Charge displayed in the UI as a 20-hour session from "10:00 to 06:00".

**Root cause**: the walk-back loop only checked `recent[1].is_charging` (the immediate previous sync) before entering — it didn't check for is_charging=True rows deeper in the traversal. A day-boundary sync at the same SoC as the previous day's charge-end lands with `recent[1]` being yesterday's non-charging tail, but the walk continues past the entire charging run underneath.

**Fix**: bail from the SoC-rise detector if *any* is_charging=True row is encountered while walking back to the valley. The primary `_detect_auto_charge` owns those windows (it fires on the 1→0 transition when the charge ended); running the fallback over the same session either produces a duplicate row or, worse, mutates the primary's Charge via the un-reviewed merge path.

Skoda's normal case is unaffected: when the cloud never publishes an is_charging=True frame during a charging session, the walk-back sees only False rows and the detector runs as before.

**Retroactive**: the wrecked Charge id=505 on the Kia install (charge_end_hour, created_at) was restored manually before the version bump — SoC bounds and kwh_loaded were untouched by the mutation, only the timestamps.

## v3.0.68 (2026-07-29)

### Charge auto-detect: guard against stale-cached pre-charge SoC echo

Observed on ev-robert on 2026-07-29: the car was driven ~236 km (SoC dropped from 97 % → 37 %), parked, plugged in, and charged for 3.5 h back to 87 %. But the BlueLink/UVO cloud kept echoing the pre-drive SoC of 97 % on every cached poll for the full 15 h between the drive-end and the next force-refresh. When motion was finally detected and a force-refresh landed, the odometer jumped +236 km and is_charging flipped to True in the same tick — with SoC correctly reporting 37 %. The next non-charging sample after the session ended showed SoC 87 %, giving a real +50 % / ~32 kWh charge that the auto-detect nonetheless silently dropped.

Root cause: `_detect_auto_charge` walks back from the charge-end sync to find the last `is_charging=False` row and uses its SoC as the "before charging" starting point. That row (10:22:33 in this incident) still carried the stale 97 % cache echo. The detector then computed `soc_to - soc_from = 87 - 97 = -10 %`, which is well below the +3 % minimum-gain threshold, and returned silently without a log line — leaving the whole 32 kWh charge unrecorded and no forensic trail.

Analogous shape to v3.0.32 (BlueLink echoing the charge-START SoC on the first `is_charging=0` sample after a charge ended). Same defense pattern applied to the pre-charge side:

- **Stale-echo guard** at the pre-charge sample: if `pre_charge_row.soc_percent` is **higher** than the first `is_charging=True` sample's SoC, treat it as a stale cache echo and use the first-charging sample as the starting SoC instead. That's within ~1 % of the real start value (one poll-interval into the session at most), which is well inside the noise floor of a charge estimate. Emits an INFO log line when it triggers so the correction is visible in the journal.
- **Silent-return breadcrumbs**: the two "SoC bounds missing" and "gain below threshold" early returns in `_detect_auto_charge` now log an INFO line with the values that caused the skip. Previously the detector could refuse to create a charge with no observable trace — this session's diagnosis required pulling raw sync rows out of the DB to reconstruct why. Future misfires show up directly in `journalctl -u ev-tracker.service | grep 'Auto-charge skipped'`.

Retroactive: the missing 2026-07-29 charge on ev-robert was inserted manually before the version bump (id=505, 38.15 kWh AC, SoC 37→87, 111 g/kWh CO2, `needs_review=True`).

## v3.0.67 (2026-07-06)

### Kia/Hyundai bg-loop hang recovery: bounded SDK-call timeouts + heartbeat watchdog

Observed on ev-robert on 2026-07-06: the bg-loop ticked normally through the 06:00 morning wake-up window (smart→force + three follow-up cached ticks), then went silent from 06:30:46 until 15:51:27 — nine and a half hours of no syncs while the systemd process reported "active (running)" the whole time. Same symptom shape as the MySkoda hang v3.0.59 addressed, this time on the Kia/Hyundai path: the underlying `hyundai_kia_connect_api` has no socket-level timeout, so a stalled cloud response wedges the calling thread on a socket read forever. v3.0.5's watchdog only covered the `force_refresh_vehicle_state` path; the cached-mode calls that fire every 10 min during the smart window (`check_and_refresh_token`, `update_all_vehicles_with_cached_state`, `update_vehicle_with_cached_state`) had no protection.

Two-layer fix:

1. **SDK-call deadlines** in `connector_hyundai_kia.py`. A module-level `_sdk_call_executor` (ThreadPoolExecutor, 4 workers) runs every BlueLink/UVO call with a 60 s hard wall-clock deadline via `_call_with_deadline(fn, *args, label=…)`. On timeout the future is abandoned (rogue thread leaks — same pattern the force-refresh executor already uses; can't interrupt a Python thread), and a `TimeoutError` propagates up to the sync loop's outer try/except which sets `_last_bg_loop_outcome = 'error'` and continues on the next tick. Applied at three previously-unbounded call sites: token refresh (including the retry-after-clear path), initial vehicle list fetch, and per-tick cached-state fetch.

2. **Heartbeat watchdog** in `sync_service.py`. New `_sync_watchdog_loop` thread started alongside `_sync_loop` in `start_sync`. Every 60 s it checks `_last_bg_loop_tick` age; if the heartbeat is more than 20 min stale while `_sync_running` is True, it respawns `_sync_thread` on a fresh stack, resets `_last_bg_loop_tick`, and increments `_watchdog_respawn_count` (exposed via `get_bg_loop_health` for observability). The old thread is abandoned. 20 min covers the smart-mode 10 min interval plus one 60 s SDK-call timeout plus generous margin. Belt-and-braces for hangs in code paths we haven't wrapped (DB lock, parking-hook edge cases, etc.).

Threads are now named (`sync-loop`, `sync-nightly`, `sync-watchdog`, plus `sync-loop-respawn-N` after a watchdog trip) so `ps H` / `top -H` reads clearly.

Mike (Skoda) already had this coverage via v3.0.59's MySkoda `ClientTimeout` + `asyncio.wait_for`; the new watchdog benefits him too as a generic safety net.

## v3.0.66 (2026-06-14)

### PV settings: ask for actual kWh produced per year, not per-kWp math

The old PV settings asked for "Jahresertrag (kWh/kWp)" — yield *per kWp installed*. To enter sensible data the user had to either look up their region average (≈950 in DE) or do mental arithmetic on the inverter app's annual total divided by their installed kWp. Predictable result: the field gets misused, the formula misfires. Both production hosts had this exact failure mode — one had the regional average copied in without checking, the other had the system's total annual production typed into the per-kWp field.

The new flow asks for the two numbers the user actually knows from their inverter app or utility meter:

- **Installierte Anlagengröße (kWp)** — peak capacity from the module datasheet
- **Tatsächlicher Jahresertrag (kWh)** — total annual energy production

Formula: `g/kWh = prod_co2 (kg/kWp) × kwp × 1000 / (annual_yield × lifetime)` — derives correctly without the user touching arithmetic. Live preview underneath the form updates as you type.

Backwards compatibility: `_get_pv_co2` falls back to the legacy per-kWp shape when the new fields are empty, so installs that haven't visited Settings since the upgrade keep producing values. The new "Jahresertrag (kWh)" input pre-fills from whichever legacy value the install has on hand:

- Both `pv_kwp` and `pv_yield_per_kwp` set → `kwp × per_kwp` (correct cross-multiplication).
- Only `pv_yield_per_kwp` set → use that value directly (the common case: users typed their full annual into the per-kWp field).
- Neither → empty.

Save handler clears the legacy `pv_yield_per_kwp` key so the new Path A always wins going forward. The existing PV-charge cascade still re-runs on save, so every PV row immediately reflects the new value.

## v3.0.65 (2026-06-13)

### PV CO2 unit bug + full-history grid CO2 re-backfill + history-modal end-hour field

Three follow-ups to v3.0.64:

1. **PV CO2 was always 0 g/kWh on default settings.** `_get_pv_co2` computed `prod_co2 / (yield × lifetime)` and `int(round(...))`. With defaults 1000 kg / 950 kWh/y / 25 y that's `0.042` → rounds to `0`. A hardcoded `return 42` only fired on the `ValueError` path, so the bug only surfaced for users running the formula. Missing the kg→g conversion: the correct formula is `prod_co2 × 1000 / (yield × lifetime)`, which yields 42 g/kWh with the legacy defaults and ~23 g/kWh with the modern (700/1000/30) defaults. Net effect on the two affected hosts: every PV charge had been silently storing 0 kg CO2 saved.

2. **The boot cleanup needs to cover the full charge history, not just the last 7 days.** v3.0.64 only nulled `needs_review=True` charges from the last 7 days — but the 441 g/kWh ghost can ride on any reviewed entry from any date. v3.0.65 broadens the scrub to *every* non-PV charge and kicks the backfill thread immediately so ENTSO-E re-queries history end-to-end under the new window logic. Bounded by ENTSO-E's 2 s per-request rate limit, so a few-hundred-charge install takes several minutes to finish — runs as a daemon, doesn't block anything.

3. **History-page inline edit modal now has the end-hour selector** too (`templates/_history_section.html`). v3.0.64 only added it to `input.html` + `edit.html`. The history modal's JS hydrate also reads `charge_end_hour` from `/api/charges/<id>`.

## v3.0.64 (2026-06-13)

### CO2 intensity: time-weighted across the full charging window + no more ghost values

The 441 g/kWh that wouldn't go away was not an ENTSO-E reading — it was the **previous** charge's CO2 value, copied forward by a v3.0.15 fallback whenever ENTSO-E hadn't published the current hour yet. Combined with charge_hour = single start hour (so a charge running 12:00–18:00 was attributed to the 12:00 grid mix even though most of the energy actually flowed during the 14:00–17:00 solar peak), the displayed CO2 had two independent ways to drift far from reality.

Fix (three things):

1. **`get_co2_intensity_window(start_dt, end_dt)`** in `services/entsoe_service.py`. For each 15 min / 1 h ENTSO-E generation bucket that overlaps [start, end], we compute the per-fuel weighted intensity and the seconds the charge actually overlapped that bucket; the final number is the bucket-time-weighted average. A charge that runs across the solar peak now gets a number that reflects the high-PV middle of the window, not just the start hour.

2. **`charge_end_hour` column on `Charge`**. Auto-detect populates it from the end-of-charge sync. Manual `/input` and `/edit` forms expose an optional end-hour dropdown next to the existing start-hour dropdown. When both are set, the server averages across the window; when only start is set we fall back to the single-hour query as before (legacy compatibility).

3. **Drop the "previous charge's CO2" fallback**. Auto-detect and `/input` no longer copy forward an old CO2 value when ENTSO-E is silent — they leave `co2_g_per_kwh = NULL` and the existing background backfill thread retries later when ENTSO-E has the data. This kills the ghosting.

PV CO2 defaults updated. The legacy 1000 kg/kWp production + 950 kWh/y yield + 25 y lifetime → 42 g/kWh was based on early-2010s European LCAs. New defaults reflect post-2020 silicon: 700 kg/kWp + 1000 kWh/y/kWp + 30 y → ~23 g/kWh. Users with explicit settings keep their values (they can recompute by re-saving the PV section in Settings).

One-time boot cleanup: charges from the last 7 days with `needs_review=True` (the auto-detected ones most likely to carry a ghosted CO2) get their `co2_g_per_kwh` cleared so the backfill thread refreshes them under the new window logic. Every PV charge gets its CO2 recomputed from current settings so the new defaults (or any user override) cascade through history.

## v3.0.63 (2026-06-12)

### Bg-loop heartbeat: refresh during inner sleep so the overnight close doesn't fake a dead loop

The dashboard's sync badge reads `_last_bg_loop_tick` and goes yellow at 30 min stale, red at 60 min. The bg-loop set that tick at the top of every iteration — but each iteration runs `_compute_sleep_secs` and sleeps the returned duration in 10 s slices. During the smart-window overnight close (default 22:00 → 06:00 next day = 8 h) the loop enters the sleep slice loop at 22:00 and doesn't re-tick until 06:00, so the dashboard sees the tick going stale and starts alarming red around 23:00 every night.

The inner 10 s sleep loop now refreshes `_last_bg_loop_tick` every minute. The thread proves it's alive without burning any extra API quota — the sleep cadence and wake-up logic are unchanged. Net effect: the dashboard stays green through the overnight close, and a *real* hang (loop thread actually wedged inside `time.sleep` or stuck before the inner loop runs at all) still surfaces as stale within the existing 30/60 min thresholds.

## v3.0.62 (2026-06-12)

### Trip edit modal: pin dialog to visualViewport on iOS portrait

v3.0.61's `modal-dialog-scrollable modal-fullscreen-md-down` was a partial fix — the save button stayed reachable in landscape but slid behind Safari's address bar in portrait. Bootstrap's `modal-fullscreen-md-down` sets the dialog to `height: 100%`, which on iOS Safari resolves against the *layout* viewport (always full screen including Safari's chrome). In portrait the address bar is much taller, so the dialog ended up taller than the visible area and the footer sat behind it.

Fix: when the modal opens, JS reads `window.visualViewport.height` — the actual visible-pixel height excluding browser chrome — and pins the `.modal-dialog`'s `height`/`maxHeight` to that value on phone-sized viewports (`window.innerWidth < 768`). A `visualViewport` `resize` listener re-applies whenever Safari's address bar slides in/out (and `orientationchange` retriggers it 200 ms after rotation). Desktop modals are untouched.

Combined with the still-present `modal-dialog-scrollable`, the body scrolls and the footer is now always anchored to the actual visible bottom of the modal in both orientations.

## v3.0.61 (2026-06-12)

### Manual trip-log edits for SDK-only trips + iOS save button reachability

Two reports from the Skoda host:

1. Tapping a trip endpoint opens the editor, the user fills in label / address / coordinates, hits **Speichern** — page reloads, nothing was saved.
2. On iPhone, the Speichern button itself is partly hidden behind Safari's bottom address bar, even though the modal footer had a sticky position + safe-area padding.

**(1) is a silent-skip bug in the save handler.** Most rows on the Skoda host are SDK-only fallback trips (MySkoda historical backfill) with no backing `ParkingEvent` for either endpoint. The template was rendering `data-from-id="None"` (Python's `None` → string `"None"`), the click handler parsed that to `NaN` and passed `null` for both ids, and the save loop's `if (id == null) continue;` skipped both sides — but the success status was still set and the page reloaded, so the user thought it had saved.

Fix:
- Trip rows now carry `data-sdk-trip-id` when the trip is SDK-only.
- When the user saves a trip whose `from_id` and/or `to_id` are null, the editor first POSTs to a new endpoint `/api/trips/sdk_create_pes` that materialises single-instant `ParkingEvent`s anchored on the SDK trip's `start_time` / computed `end_time`. The standard per-side save then runs against real ids.
- The save loop now tracks whether any side was actually saved and surfaces a `no_endpoint` error instead of fake-success if neither side has an id and there's no SDK trip to back it.
- Empty `tr.from.id` / `tr.to.id` now render as `""` instead of `"None"` (Jinja `|default('', true)` semantics via `or ''`).

**(2) is a Bootstrap modal mode mismatch.** The modal used the default mode where the *page* scrolls and the footer was sticky-positioned. iOS Safari's address bar floats over the page, not the modal frame — so a page-sticky footer slides under it. Switched to `modal-dialog-scrollable modal-fullscreen-md-down`: the modal body scrolls inside a fixed-height dialog and the footer is anchored to the dialog frame, which lives above Safari's overlay. Combined with the existing `env(safe-area-inset-bottom)` padding the button is now always reachable.

## v3.0.60 (2026-06-12)

### Quiet the MySkoda VEHICLE_IN_MOTION log spam

While the driver is on the road, the Skoda v3 API returns a privacy-shaped `{"errors":["VEHICLE_IN_MOTION"]}` payload from `/v3/maps/positions/.../parking`. The myskoda lib doesn't model that case as a clean None — instead `mashumaro` fails to deserialize and the lib's `myskoda.rest_api` logger paints an ERROR + traceback on every poll (the bg-loop hits the endpoint every 10 min during the active window). Our wrapper then added its own WARNING on top. Net result on the morning commute: a long red wall in the /logs feed for the user's normal driving.

Two filters:

- A `logging.Filter` on `myskoda.rest_api` that drops records containing `VEHICLE_IN_MOTION` or `Field "parking_position"` — those are the API's normal "no parking data right now" responses, not faults.
- The wrapper's own `get_parking_position` / `get_positions` exception path now logs at DEBUG (not WARNING) when the exception text matches the VEHICLE_IN_MOTION shape, and at WARNING otherwise so real errors still surface.

Functional behaviour unchanged: VehicleSync just gets `GPS=no` for that tick, the next sync after the car parks fills it in.

## v3.0.59 (2026-06-11)

### MySkoda client: bounded timeouts so a stalled call can't wedge the bg-loop

Symptom on the Skoda host: bg-loop ticked once at service start, then went silent for 70+ minutes. Dashboard badge went red ("bg_loop_silent_for_69min"). User-triggered `src=dashboard` syncs still worked; only the background loop was stuck.

Root cause: `aiohttp.ClientSession()` was constructed with no timeout (the lib defaults to "wait forever"), and `asyncio.run(coro)` had no outer deadline. The first MySkoda call after each service restart hits a cold refresh-token cache and does the full OAuth handshake; when one of those round-trips stalled (network blip, server-side hang), the bg-loop's `_maybe_post_move_reconcile` call sat forever waiting and never returned to the loop's sleep-then-tick rhythm.

Two layers of timeout now:

- `aiohttp.ClientTimeout(total=60, sock_connect=20)` on the session — every individual HTTP request bounded.
- `asyncio.wait_for(..., timeout=90)` wrapping the whole connect-then-call-then-disconnect sequence — guards against deadlocks deeper than the HTTP layer (firebase-messaging import side-effects, anything that might still wedge under `mqtt_enabled=False`).

A hang now surfaces as a `TimeoutError`, the wrapper logs a `WARNING`, and the bg-loop continues its normal 10-min cadence instead of getting stuck forever.

## v3.0.58 (2026-06-11)

### SDK-fallback destination: cap PE-after lookup to 12 h

On a fresh Skoda install whose ParkingEvent timeline only has its first PE (the one that opened when the user finally enabled bg-sync), every historical MySkoda trip ending before that PE was rendered as "Nach Zuhause" — because `_find_pe_after` returned the first PE in the timeline regardless of how many days separated the trip's end from the PE's `arrived_at`.

`_find_pe_after` now requires the candidate PE to open within `max_gap_hours` of the trip's end (default 12 h). 12 h covers the worst case where a trip ends late in the evening, the smart-window goes to sleep at 22:00, and the next morning's first sync (~06:10) opens the destination PE — without bleeding into "next-ever PE wins" for trips weeks earlier.

Polled (PE-pair) trips are unaffected; this only changes the SDK-only fallback path used when no PE pair brackets the drive window.

## v3.0.57 (2026-06-11)

### Self-heal: auto-enable background sync when credentials exist but the toggle was never set

The Skoda host (ev-mike) had `vehicle_sync_enabled=false` from day one — the setup wizard never sets the flag, and the user has to find the "Auto-Sync" checkbox in Settings → Fahrzeuge to opt in. Symptom: no `src=bg-loop` entries in the logs, no GPS in any VehicleSync, 0 ParkingEvents, and every Fahrtenbuch row stuck on "Ort unbekannt" even though MySkoda was returning data fine.

Fix in `start_sync()`: distinguish "key unset" from "user said false". When at least one fleet vehicle has API credentials and `AppConfig.vehicle_sync_enabled` is `None` (key absent), auto-flip to `'true'` once and start the loop. An explicit `'false'` from the user still wins — only the unset case gets healed.

Manually applied to ev-mike during diagnosis (flag set, service restarted) — first bg-loop sync caught GPS, PE#1 created at home (label='home'). This release ships the same self-heal to every install so the next provision doesn't repeat the symptom.

## v3.0.56 (2026-06-10)

### Skoda: subscription-tier endpoint probing + import path fix

Live shake-out of v3.0.55 on the reference Enyaq 60 install surfaced two issues:

- **`OffsetType` import path was wrong** — the enum lives in `myskoda.rest_api`, not `myskoda.models.trip_statistics`. Caused every aggregate-stats fetch attempt to ImportError; the wrapper swallowed it as a generic warning, so the regen/consumption columns silently stayed None even on cars where the endpoint would actually work.
- **Probe-and-cache for endpoints that aren't on the user's subscription tier.** The reference Enyaq 60 returns 403 on `get_trip_statistics` (the day-aggregate endpoint that feeds regen + consumption) and 500 on `get_charging_history` / `get_all_charging_sessions`. Working endpoints: `get_single_trip_statistics` (per-trip detail), `get_parking_position`, `get_positions` (live — deliberately unused), `get_driving_score`. Two new AppConfig pairs — `skoda_aggregate_supported_<vid>` / `skoda_charging_history_supported_<vid>` plus a `_last_probe_<vid>` date — gate the unsupported endpoints to one weekly re-probe instead of one failed HTTP request per post-move backfill. If the user upgrades their subscription, the weekly probe picks it up automatically.

Net effect for the Enyaq 60: trip detail (km, drive time, avg speed) and parking position keep flowing into the Fahrtenbuch on every drive; regen falls back to the configured km × `recuperation_kwh_per_km` until the aggregate endpoint becomes available; charging-history backfill returns `{error: 'unsupported_cached'}` until a weekly re-probe confirms a status change.

## v3.0.55 (2026-06-10)

### Skoda: auto-backfill after every drive + daily reconcile + regen/consumption + charging history

Following v3.0.53/54, the Skoda integration now matches the Kia/Hyundai pattern as closely as the MySkoda API allows. **All API calls go through MySkoda's cloud cache — the car is never woken up.**

- **Auto-backfill after every drive.** `_trip_info_vehicles()` now also picks up `api_brand='skoda'` rows. The existing `request_post_move_reconcile()` hook (fired by the parking pipeline when a PE transition is detected) dispatches to either `trip_log_fetch.backfill` (Kia/Hyundai) or `skoda_trip_fetch.fetch_skoda_trips` (Skoda). One day of trips is pulled within a couple of minutes of every drive, no extra polling needed.
- **Daily reconcile.** The 03:00-ish nightly tick that walks Kia/Hyundai through `gap_days_since_last_reconcile` now also walks Skoda through a 14-day window, gated by a separate 20 h cooldown (`AppConfig skoda_last_daily_reconcile_<vid>`) so it can't loop. PE-pair `departed_at` realign is skipped for Skoda — MySkoda's `end_time` is only HH:MM, not ms-precise.
- **Recuperation + consumption from the daily aggregate.** MySkoda doesn't expose per-trip regen or kWh consumed, but the day-level `StatisticsEntry` carries `average_recuperation` and `average_electric_consumption`. New `VehicleTrip.regen_kwh_per_100km` / `consumption_kwh_per_100km` columns (with a SQLite ALTER migration) carry the day's averages on every trip row; `trips_service.get_trips()` prefers them over the static km × recuperation_kwh_per_km fallback when present. The Fahrtenbuch regen column for Skoda now reflects the car's own measurement.
- **Charging-history backfill.** New `POST /api/charges/skoda_backfill {days: N}` calls `get_charging_history` and inserts any session we don't already have as a `Charge` row (date + charge_hour from `start_at`, kwh_loaded from `charged_in_kwh`, charge_type from `current_type`, `needs_review=True`, `notes='[MySkoda-Historie]'`). Dedup window ±2 h on charge_hour against existing rows for the same vehicle on the same date — the auto-detection's canonical Charge always wins. Default 180 days, capped at 365. **No price comes from MySkoda — backfilled rows stay flagged for review.**

12 V hygiene: nothing here pings `get_positions` (the live-driving endpoint that would wake the car). Position data still comes only from `get_parking_position` (passive cloud cache, refreshed by the car on its own schedule).

The `data/myskoda/<email>.refresh_token` cache means each backfill is a single HTTP round-trip after the first OAuth handshake — measured at ~600 ms wall-clock for the 1-day post-move pull.

## v3.0.54 (2026-06-10)

### Skoda trip backfill: fix end_time parsing + auto-discover VIN

Two follow-ups to v3.0.53 found during the first live run on the Enyaq install:

- **end_time is `HH:MM`, not a full ISO timestamp.** The previous version tried to `datetime.fromisoformat(end_time)` and silently dropped every trip (81 trips returned, 0 written). The day comes from the enclosing `DailyTrip.date`; the new helper combines them. First live backfill landed all 81 trips across 39 days (1931 km, 73 h driving) into VehicleTrip.
- **VIN auto-discovery + persistence.** `Vehicle.api_vin` was empty on the Skoda row (the user never entered it; `carconnectivity` discovers it implicitly via `garage.list_vehicles`). The backfill now calls `MySkoda.list_vehicle_vins()` when no VIN is configured, takes the first hit, persists it back onto the Vehicle row, and uses it for the rest of the run. Saves a round-trip on every subsequent fetch.

## v3.0.53 (2026-06-10)

### Skoda: surface position + trip statistics via the dedicated MySkoda v3 API

`carconnectivity-connector-skoda` exposes SoC / odo / charging state but doesn't map the v3 endpoints for position, parking, or trip statistics. v3.0.53 adds a thin sync wrapper around the standalone `myskoda` Python lib (the one the Home Assistant integration uses) and grafts it onto the existing SkodaConnector for two concrete surfaces:

- **Parking position** (`get_parking_position`) — `SkodaConnector.get_status()` now fills `location_lat` / `location_lon` from the last known parking spot. The existing VehicleSync → ParkingEvent → Trips-pair pipeline picks it up automatically and starts producing a Fahrtenbuch with actual addresses (Nominatim geocode plus the formatted address MySkoda itself provides). No car wake-up — parking position is served from the cloud cache.
- **Trip statistics** (`get_single_trip_statistics`) — new endpoint `POST /api/trips/skoda_backfill {days: N}` pulls the per-trip detail (mileage, drive time, avg speed) for the last N days into `VehicleTrip` with `source='myskoda'`. The trips_service overlay already consumes VehicleTrip rows, so they show up in the Fahrtenbuch with the cloud-check icon and surface the SDK-style stats even on days where no ParkingEvent pair was captured. Default 90 days, capped at 365.

Feature matrix update: `skoda.location` → `partial` (the parking spot is cached and reliable; live driving GPS needs the car awake).

The refresh token from `MySkoda.connect()` is cached in `data/myskoda/<email>.refresh_token` (mode 0600) so subsequent calls skip the full OAuth dance. Import is lazy and the import failure is logged but tolerated — non-Skoda hosts don't need the lib installed. The Skoda host (Enyaq install) does: `pip install myskoda aiohttp`.

Charging-history (`get_charging_history`) is wired up in the client wrapper but not yet routed to a UI endpoint — next step.

## v3.0.52 (2026-06-10)

### Charge input: Start/Stop removed — auto-detection owns live sessions

The "+ Neue Ladung" modal no longer offers Start/Stop buttons, a live timer, the active-session badge, the localStorage `ev_charge_session` round-trip, or the intermediate-save / saved_id flow. Auto-detection (`_detect_auto_charge` for is_charging 1→0 transitions, the v3.0.47/v3.0.49 SoC-rise fallback for brands like Skoda) now reliably catches active sessions and writes the canonical Charge row itself, so the manual UI's job is reduced to **retroactive manual entry** — adding a charge after the fact with all fields (date, start hour, SoC range, kWh, €/kWh, charge type, operator, location, fees, notes, CO2). The Cancel button and the server-side 90 s double-submit fold both stay; ~590 lines of session-restore / timer / auto-poll / retry-loop JS plus the `?saved_id=X&active=1` server path are gone.

### Fahrtenbuch: live-patch "Adresse wird ermittelt…" without a reload

When the page rendered before the background geocoder had caught up, address cells showed "Adresse wird ermittelt…" until the user navigated away and back. A new lightweight `POST /api/trips/parking_addresses` returns currently-resolved addresses for a given set of parking-event IDs; the trips page polls every 2 s (max ~60 s) and patches each cell in place as Nominatim results land. The page-load background geocode is also bumped from `limit=50` to `limit=200` so it covers the full visible window in one shot.

### Skoda: yes, the v3 API exposes location + trips + charging history

Spot-research (no code change). The MySkoda v3 API exposes `get_positions` (live GPS), `get_parking_position` (last known parking spot + formatted address), `get_single_trip_statistics` (per-trip detail), `get_trip_statistics` (week/month aggregate), `get_charging_history`, `get_all_charging_sessions`, `get_charging_statistics`, and `get_driving_score`. The dedicated `myskoda` Python lib wraps all of them and is used by the Home Assistant integration. Our connector goes through `carconnectivity-connector-skoda` instead, whose README explicitly says "Not all items that are presented in the data from the server are already implemented" — i.e. the data does arrive, just unmapped. Surfacing it locally would mean adding a parallel `myskoda` adapter for the Skoda brand. Privacy precondition: the in-app "Share my position" setting must be enabled.

## v3.0.51 (2026-06-08)

### Charge edit views: operator pick now auto-fills the price

Follow-up to v3.0.50. That release fixed the operator → price auto-fill on the new-charge form, but the same logic was duplicated in two other places:

- `edit.html` (full-page edit of a saved charge) — same `lastAutoFilled` guard as input.html, but the field is always pre-filled with the existing charge's price, so the guard always bailed and the price never updated when the operator was changed.
- `_history_section.html` inline-edit modal (opened by clicking a row in the history list) — had **no** price auto-fill at all on operator change.

Both edit paths now mirror the input form: user-driven operator changes force-overwrite the price; passive paths still keep what's there.

## v3.0.50 (2026-06-08)

### Charge input: operator pick now always overwrites the price field

v3.0.46 added a "don't clobber a user-typed price" guard so the auto-fill wouldn't wipe a value the user had already entered. The guard was too broad: it also blocked the auto-fill when the user *consciously* switched the operator dropdown — if the price field already had any value (from `pre_charge.eur_per_kwh`, the auto-location service, or a restored form-cache entry), the new operator's configured price never landed.

User-driven operator changes (dropdown `change`, custom-field `blur`) now force-overwrite the price field. Passive paths (initial render, no explicit user action) still respect the guard so a value the user actively typed in a prior session is preserved.

## v3.0.49 (2026-06-08)

### Auto-charge detection: SoC-rise detector ran amok during multi-step rises

A 24→68 % home charge on one car and an 11→100 % charge on another both produced the canonical full-session Charge row PLUS a chain of 10 %-step "shard" rows (40→50, 50→60, 60→70 …). Two compounding bugs:

1. `_detect_auto_charge_from_soc_rise` (v3.0.47) compared each new sync to the *immediately preceding* one. A continuous charge session that sampled every 40 min produced one candidate per sync, each abutting the previous (`30→40`, `40→50` …). The dedup check `c.soc_to <= soc_from` lets abutting candidates slip through — there's no overlap, so a new row gets created on every step.
2. The same detector also fired *during* an active charge (with `is_charging=1` on the syncs), competing with the primary `_detect_auto_charge` handler that owns the `1→0` session-end transition. The primary handler's merge logic then absorbed one shard but `break`-ed out of the loop, leaving the rest as orphans.

Fixes:

- SoC-rise detector now anchors on the **SoC valley** — walks back through recent syncs to find where the current rise actually started, instead of using just the last sync. A continuous session therefore produces ONE candidate (`valley → current peak`) that grows in place on every poll.
- SoC-rise detector now **skips entirely** when `end_sync.is_charging` or the immediately previous sync's `is_charging` is true. Primary detector owns those windows.
- SoC-rise detector now **extends** an existing un-reviewed auto Charge on overlap instead of bailing — symmetric with the primary detector's merge behavior, so the row grows with each poll rather than ping-ponging.
- Primary detector now **absorbs every overlapping un-reviewed shard** at session end (oldest row wins, others get deleted), so residue from the buggy code path gets cleaned up automatically on the next real charge.

Garbage rows from the bug remain in already-shipped databases; remove them manually (`needs_review=1` rows from 2026-06-08 with the SoC-rise notes string).

## v3.0.48 (2026-06-02)

### SoC-rise auto-charge — date anchor + cross-day dedup fix

Follow-up to v3.0.47. The detector dated its inferred Charge on `end_sync.timestamp.date()`, which for the common overnight-charge case is the morning-after day. Users usually log the charge under the day it started, so the dedup query against an already-logged same-day charge missed and the detector would have created a duplicate.

- Anchor `Charge.date` on `prev.timestamp.date()` (the "before-charge" sample).
- Dedup query now spans both `prev` and `end` dates so a charge logged on either side of midnight pre-empts the inference.

## v3.0.47 (2026-06-02)

### Auto-charge detection: SoC-rise fallback for non-charging-aware brands

Skoda / VW Group cars (and any other brand whose cloud only updates state on key events, not continuously) usually have their actual charge window entirely outside the polling cadence — by the time the next cached sync arrives, MySkoda already reports `is_charging=false` again. The v3.0.18 detector relies on observing a `is_charging=1→0` transition, so on these brands an everyday home top-up was silently missed.

Added a fallback path that watches consecutive syncs for a SoC jump:

- Min gain: 8 % (configurable, kept well above the BMS recalibration noise floor of ±2-3 % on a parked car).
- Max gap: 36 h between samples — beyond that two syncs can't reliably bracket a single charge.
- Tolerates driving between samples: subtracts an estimated drive consumption (18 kWh/100 km, fits Niro EV / Enyaq within ±2 %) from the apparent SoC delta before applying the threshold, so a 9 % net rise across a 46 km drive (~13 % consumed = 22 % charged) still counts.
- De-duplicates against any same-day Charge whose SoC range overlaps — so the existing `is_charging`-transition detector and a manually logged Charge both pre-empt this fallback.
- Reconstructs the SoC bounds by assuming all driving happened before the charge (worst case for "where was the user when they charged?"); user can correct on review.

Inserts `needs_review=true` rows with the notes field calling out the inference path so the user knows what to verify.

### VAG (Skoda / VW / Seat / Cupra) tokenstore — out of `/tmp`, properly persisted

Two related fixes to stop the connector running a full OAuth dance on every poll:

1. Moved the tokenstore from `/tmp/ev_tracker_cc_{brand}_tokens.json` to `data/cc_tokens/{brand}_tokens.json`. systemd's `PrivateTmp=yes` wipes `/tmp` on every service restart so the file never survived a deploy, and CarConnectivity then re-ran the identity-server consent flow on every fetch.
2. Added an explicit `cc.persist()` call after `fetch_all()`. CarConnectivity loads the tokenstore on `startup()` but only writes it via `persist()` — and our connector instance lives for exactly one sync, so without the explicit call the file was never actually written even when the path was stable. The "Could not use tokenstore from file …" warning that was logged on every poll is now expected only on first run (and on tokenstore rotation).

## v3.0.46 (2026-06-02)

### Charge input: operator price now auto-fills on initial render

If the charge form opens with an operator already pre-selected — because the user has an in-progress saved charge or because the auto-location service matched a known operator — the price field stayed empty even when a `€/kWh` was configured for that operator in settings. Reason: the auto-fill JS only listened to the `change` event on the operator `<select>`, and no `change` fires on initial page render.

The IIFE that owns the operator dropdown now runs one auto-fill pass on load if the dropdown already has a selected value (or the free-text input is non-empty). The existing "don't clobber a user-typed value" guard still applies, so a manually-entered price won't be overwritten.

## v3.0.45 (2026-06-01)

### Trip split: km / SoC for manual stops — user input + time interpolation fallback

The v3.0.44 manual-split worked structurally (the new PE was inserted and trip endpoints extended), but the km and SoC came out wrong: the server only used the *nearest* VehicleSync regardless of how distant it was in time. For a stop placed at 06:50 on a day where polling didn't run until 15:35, "nearest" was hours away and the odometer reading belonged to a completely different driving phase. Result: one trip showed `NULL → 84986 km` (rendering as blank) and the other showed `84986 → 84986 = 0 km`, even though ~39 km were actually driven.

Two changes:

1. **User overrides** (optional). The manual panel now also has two extra inputs: *km am Stopp* and *SoC am Stopp*. When filled, the server uses those values directly (applied to both arrival and departure).
2. **Time-fraction interpolation** when neither a user value nor a sync within 10 min of the chosen timestamp is available. The new PE's odometer and SoC are linearly interpolated between the parent PEs based on where the stop's timestamp sits in the (possibly extended) trip window — so total trip km / SoC drop are preserved, just split proportionally.

The two resulting trips now always render with a non-blank km column.

E2E-tested:
- explicit `odometer_arrived: 85025` + `soc_arrived: 70` → values used as-is
- no user values + no nearby syncs, stop at 50 % time fraction → interpolated to 85020 km / 70 % (= exactly 50 % between 85000/85040 and 80/60)

## v3.0.44 (2026-06-01)

### Trip split: manual mode for zero-duration legacy trips

The v3.0.40 trip-too-short rejection was a dead-end — the user still wanted to log stops on those legacy trips, just with custom times. Added a manual mode:

- When `GET /api/trips/.../split_data` returns `422 trip_too_short`, the modal no longer locks. The map stays visible, a yellow alert explains the situation, and a small panel appears with two `datetime-local` inputs (arrival + departure at the stop). A tap on the map sets the stop's location; the inputs default to the broken endpoint time and the user edits them to whatever the real arrival was.
- Save POSTs the stop with `{force: true}`. The server skips the strict in-window check and **auto-extends the parent PEs' timestamps** (sliding `from.departed_at` backward and/or `to.arrived_at` forward with a 60 s cushion) so the new PE has somewhere to live without breaking the `prev.departed_at < curr.arrived_at` invariant the trip renderer relies on. Adjacent trips are untouched.

End-to-end tested with a synthetic zero-duration trip: server returned 422 on `split_data`, then accepted a force-mode POST and correctly extended the to-PE while leaving the from-PE alone (since the new stop sat strictly after it).

## v3.0.43 (2026-06-01)

### /input resume banner: removed

After v3.0.35 / 38 / 39 / 40 / 41 / 42 the banner kept resurfacing in stuck states. Removed the feature entirely:

- The `<div id="resumeChargeBanner">` element is gone from the template.
- The `syncResumeBanner` IIFE is replaced with a minimal `purgeStaleChargeKey` IIFE that just nukes the localStorage entry when the server reports no recent charging activity (or when its `startTime` is older than 6 h).
- Discard endpoint and `dismissed_charge_session_ids` AppConfig stay in the codebase for now (no harm) but are no longer driven.

The intermediate-save flow still works — Zwischenspeichern still redirects with `saved_id`, the form still pre-fills from `pre_charge`, localStorage still restores in-progress field values. The user just doesn't get a top-of-page reminder anymore. To finalise a half-saved charge, click its row in the history table; the existing edit modal opens with everything pre-filled. This trades one UI affordance for not having a phantom banner the user couldn't get rid of.

### Trip split: trip-too-short screen no longer shows misleading hint

The "tap a candidate or anywhere on the map" empty-stops hint kept rendering below the trip-too-short alert even though there was nothing tappable. Suppressed when the trip is rejected as too short.

## v3.0.42 (2026-06-01)

### /input banner: localStorage path also auto-cleaned

v3.0.41 fixed the URL-driven path (server-side auto-dismiss for orphan/stale `saved_id`), but a third path was still live: `localStorage.ev_charge_session` carrying a fresh `startTime` from an old Start tap that was never finished. The 6 h TTL would have purged it eventually, but the user was rightly losing patience.

The route now also reports `no_recent_activity` (no `Charge` row created in the last 2 h and no `VehicleSync` with `is_charging=True` in the last 2 h). When that flag is true, the client purges `CHARGE_KEY` on render — no tap, no confirm, just gone. Combined with v3.0.41's server-side decision, every path to a stuck banner is now closed at the source:

- URL has params → server auto-dismisses orphans / >6 h-stale ids
- URL clean + localStorage fresh + no real charging → client auto-purges localStorage
- Explicit Verwerfen → still does its thing

### Trip split: visually disabled Save button

Bootstrap's `disabled` attribute on `btn-warning` only drops opacity to 0.65, which barely reads as "off" on a phone screen — users were tapping a button that looked active. When the trip is too short to split, the Save button now also gets `btn-secondary` (grey) until the modal is reopened with a usable trip.

## v3.0.41 (2026-06-01)

### /input banner: idiot-proof server-side auto-dismiss

The user's iPhone Safari was still serving cached HTML from an earlier version on every visit, so the v3.0.40 Discard button (which calls the server endpoint) was never running — and the `dismissed_charge_session_ids` list stayed empty no matter how often the user tapped Verwerfen. The banner was driven purely by stuck URL params that the server kept honouring.

The route now actively decides whether the banner should be allowed *at all*, not just whether to honour a dismissal:

- **Orphan** (`saved_id` points to a charge that doesn't exist) → suppress + auto-add to dismissed list.
- **Stale** (charge exists but `created_at` is more than 6 h ago) → same. A genuine in-progress session would have been finalised long before then; anything older is leftover from an abandoned Zwischenspeichern.
- **Explicitly dismissed** → suppress as before.
- **Otherwise** → render the banner.

Self-heals: the dismissal is persisted on the server during the render itself, so subsequent visits stay clean even from older clients that don't even know about the dismiss endpoint.

### Trip split: cleaner zero-duration error UI

The 422 *trip_too_short* path used to render the same explanation twice — once as a yellow alert in the candidate-list panel and again as orange status text below — while still showing an empty grey map area. Tightened to one alert in the candidate panel, the map div is hidden, Save stays disabled, status line is cleared.

## v3.0.40 (2026-06-01)

### /input resume banner: dismiss is now genuinely permanent

Three prior attempts (v3.0.35 / v3.0.38 / v3.0.39) all relied on client-side state to suppress the banner — and all three failed in the field because iOS Safari kept serving a stale HTML page where the fix wasn't loaded yet. Discard would clear localStorage, but on the next visit Safari served the cached HTML, the URL still carried `?saved_id=X&active=1`, and the banner came right back.

Two changes finally pin this down:

1. **Server-side persistent dismissal**: a new `POST /api/charges/dismiss_session` endpoint appends the dismissed `saved_id` to `AppConfig.dismissed_charge_session_ids` (capped at 200). The `/input` route consults this list and forces `active_session = False` for any id present — so even when the URL params survive in browser history, the server refuses to ever render the banner for that id again.
2. **No HTTP caching of dynamic HTML**: an `@app.after_request` hook now sets `Cache-Control: no-store, must-revalidate` on every `text/html` response. Static CSS / JS / images are untouched; only the dynamic pages stop being cached. This is what finally lets the fix actually reach the user's browser.

The Discard button now: calls the server endpoint, then mirrors the dismissal into `localStorage` for the offline-fast-path, then strips the URL params, then hides the banner — in that order, so a hand-off between any two layers still leaves the dismissal recorded.

### Trip split: zero-duration legacy trips refuse to open

ev-robert has five ParkingEvent pairs with `departed_at == arrived_at` (a quirk of how the state machine flushed flush-on-stop on a single sync long before v3.0.32). The splitter modal used to open on these, show an empty map, and silently fail with a confusing warning on every map tap because there's literally no time interval to insert a stop into. The endpoint now returns `422 trip_too_short` upfront with the actual endpoint timestamps; the modal renders a clear "fix the endpoint timestamps first" message and locks the Save button so the user knows what's required.

## v3.0.39 (2026-06-01)

### /input resume banner: Discard now actually sticks

The v3.0.38 attempt at persistent Discard via `dismissed_ids` had a fatal ordering bug: the `ingestSavedId` IIFE strips `saved_id` and `active` from the URL via `history.replaceState` *before* the `syncResumeBanner` IIFE reads them. By the time the Discard handler ran, `url.searchParams.get('saved_id')` was always `null`, so the dismissed list never actually received the id — and the next render with the same URL (browser-history / cached navigation) brought the banner right back.

Fix: the server now also renders the active `saved_id` into a `data-saved-id` attribute on the banner element. The Discard handler reads from that attribute first, with URL and `localStorage.chargeId` as fallbacks. The dismissed list gets populated reliably, and subsequent renders for the same id are suppressed client-side.

### Trip split: clearer manual hint

The empty-candidates message told the user to "tap a grey sync point" — but on short trips with no intermediate polling there are no sync points to tap. Reworded to "tap any point on the map" in all six languages, matching what the click handler actually accepts (any lat/lon, timestamp inferred from the geographically nearest sync or trip midpoint).

## v3.0.38 (2026-06-01)

### Trip split: fix UTC-shift bug on manual map taps

A user tap on empty map (no candidate, no sync circle) generated a midpoint timestamp via `new Date(...).toISOString()`, which converts to UTC and appends "Z". The server then stripped the "Z" and treated the UTC value as naive local time, shifting the timestamp by the user's timezone offset (2 h in CET summer) — pushing it outside the trip's window and triggering `split_outside_window`. Replaced the conversion with a naive-ISO formatter that uses local components directly, so the server reads back the same wall-clock value it originally serialised.

Added a client-side `isInsideWindow` guard too: any stop whose timestamp would fail the server check is rejected up front with a clean message instead of a generic "Fehler".

### /input resume banner: dismiss is now permanent per saved_id

The resume banner was reported reappearing on ev-robert even after clicking Verwerfen. Root cause: server-side `active_session` is driven purely by URL params (`?saved_id=X&active=1`), and a stuck bookmark / browser-history entry kept reloading those params. The old `window.location.replace` reload also occasionally came back from iOS Safari's cache with the params re-attached.

Reworked Verwerfen:

- Stores the dismissed `saved_id` in `localStorage.ev_charge_dismissed_ids` (capped at 50).
- Hides the banner immediately, no reload — fixes the iOS cache issue.
- Strips URL params via `history.replaceState`.
- Future page loads where the URL carries the same `saved_id` suppress the banner client-side, even when the server still wants to show it.

## v3.0.37 (2026-06-01)

### Trip split: multi-pin + click-anywhere on map

Two real-world reports against the v3.0.36 splitter:

1. **`invalid_trip_window` rejection**: a handful of legacy ParkingEvent pairs have `prev.departed_at == next.arrived_at` (zero-duration "pass-through" trips the state machine flushed onto a single sync). The v3.0.36 validation used `>=` and rejected them; relaxed to `>` so equal timestamps go through.
2. **Trips without auto-detected stops were unsplittable**: the only clickable affordances were sync circles and candidate pins. Trips with sparse syncs or no qualifying stationary clusters had nothing to tap.

Reworked the modal into a multi-pin picker:

- **Tap anywhere on the map** to drop a new stop. The timestamp is inferred from the geographically nearest sync; lat/lon come from the click.
- Tap a sync circle or candidate pin → also adds a stop (same data shape).
- **All chosen stops appear in a list** below the map with their times and a remove button. The map shows them as green pins; tap a pin again to remove.
- One Save click POSTs all stops in chronological order — server inserts N new ParkingEvents in a single transaction, so the user can log a whole Home → Bakery → Doctor → Home loop in one go.

The single-stop POST shape (`{at_arrived, …}`) is still accepted for backwards-compat; the UI now always sends `{stops: […]}`.

## v3.0.36 (2026-06-01)

### Trip log: split clustered trips into two

When two short drives happen back-to-back with only a brief stop in between, the parking-event state machine sometimes never opens a new event for the middle stop — the GPS hadn't moved enough or the stationary window was below the 100 m threshold. The result is a single "trip" in the Fahrtenbuch that's really two: e.g. *Home → Hardware store → Home* shows up as one *Home → Home* loop.

New **Split** action (scissors icon at the right edge of every trip row, only visible for ParkingEvent-pair trips) opens a mobile-friendly modal with:

- A map showing the full trip route (blue line) plus every intermediate VehicleSync point (small grey circles you can tap).
- **Auto-detected candidate stops** as numbered orange pins + a list below — any cluster of consecutive syncs that stayed within ~150 m of each other for ≥ 5 min becomes a candidate, with the cluster's classified label (Home / Work / Favorit / Sonstiges) and duration already shown.
- Manual fallback: tap any sync point on the route to set the split exactly there.

Saving inserts a fresh ParkingEvent at the chosen point with arrival + departure timestamps, odometer and SoC pulled from the nearest sync, and the label auto-classified against the user's configured home / work / favorites. The trip list re-derives from PE pairs on reload, so one entry becomes two without any other state to migrate.

Backed by two new endpoints:

- `GET /api/trips/<from>/<to>/split_data` — returns the route's syncs + detected candidates.
- `POST /api/trips/<from>/<to>/split` — performs the insertion, validates the timestamp falls strictly inside the trip window.

## v3.0.35 (2026-06-01)

### /input: no more auto-opening on landing + zombie session escape hatch

Some users reported "tote Ladungen" — opening the Charge tab on the phone and being dropped straight into the new-charge modal even though they had never started one. Root cause: the v3.0.25 auto-open used a stale `localStorage` flag from an abandoned earlier session (`startTime` set, never Stopped or Saved). Every subsequent visit then re-opened the modal indefinitely.

Reworked the landing behaviour:

- **No auto-open.** Tapping the Charge nav entry always lands on the history list. The modal opens only when the user taps the "+" button, a history row, or the resume banner.
- **Resume banner.** When the server reports an active session (saved via *Zwischenspeichern*) or `localStorage` holds a fresh session, a yellow alert appears above the history with one tap to resume.
- **Verwerfen / Discard.** The banner ships with an explicit "X / Verwerfen" button that nukes the stored session after a confirmation. No more workaround-by-restarting.
- **Stale TTL = 6 h.** Anything older than 6 h in `localStorage` is treated as a leftover and purged on page load — long enough for any realistic overnight AC charge, short enough that an abandoned tab on the phone doesn't haunt the user the next day.

### Trip edit: pick from known favorites instead of free-text

The Startpunkt / Zielpunkt → *Art* → *Favorit* picker previously showed only an empty text input — the user had no way to see which favorites they already had configured, so the field invited typos that broke the location classifier. Replaced with a dropdown of all configured favorites (`AppConfig.favorite_locations`) plus a "+ Neuer Favorit" entry that re-reveals the text input for first-time names. Adding the same favourite to a second event now keeps it linked via the canonical name.

## v3.0.34 (2026-05-30)

### Edit modals: stop iOS Safari from zooming on input focus

Tapping into any field inside the charge / trip / maintenance edit modals on iPhone made Safari zoom hard into the input, leaving the cursor offset and the modal partly off-screen. The cause is a long-standing iOS behaviour: whenever a focused `<input>` has a computed font-size below 16 px, Safari treats it as "too small to type into" and auto-zooms. Bootstrap's `form-control-sm` (which all three modals use to keep the form compact on mobile) renders at 0.875 rem ≈ 14 px — exactly in the zoom-trigger range.

Added a mobile CSS rule (`@media (max-width: 768px)`) that lifts every text/number/select input back to 16 px. Pinch-zoom still works for the rest of the page; only the auto-zoom on focus is gone.

## v3.0.33 (2026-05-30)

### Edit/new charge: allow 4-decimal price per kWh

The price-per-kWh input on all three forms (new charge, in-page edit modal on /input and /history, full-page /edit) had `step="0.01"`, which forced the browser to reject any value that didn't round to two decimals. Auto-detected and reconstructed entries store the operator price as-configured (e.g. `0.3287 €/kWh`), so the user couldn't save them without manually rounding first — for the reconstructed v3.0.32 entry the form simply refused with *"ungültiger Wert"*. Relaxed `step` to `0.0001` so any tariff with up to four decimal places submits cleanly while the spinner still works.

A retrospective sweep of the last 14 days of vehicle-sync data turned up one further missed charge: ev-dirk on 2026-05-22 at work (50→90 %, ~31.4 kWh AC). The sync log was clean, so this predates the v3.0.32 cloud-echo fix and was likely missed by an earlier detector version. Reconstructed as `needs_review`.

## v3.0.32 (2026-05-30)

### Auto-detect: defend against the cloud's SoC-echo at charge end

Real report: a 50→82 % home charge finished, but the auto-detection produced no entry. The BlueLink/UVO cloud occasionally echoes the charge-*start* SoC on the very first `is_charging=0` response after a charge ends — so the 1→0 transition arrived with `soc=50` instead of `82`. The detector computed `soc_to − soc_from = −3`, the gain was below the 3 % threshold, and it silently bailed. Eight minutes later the cloud sent the real `soc=82` reading, but `is_charging` was already 0 at that point so no new transition fired and the whole charge was missed.

`soc_to` is now floored at the highest SoC observed during the charging run. A glitchy echo can no longer sink the end-SoC below what the car physically reached, so the detection captures the full window even when the cloud lies on the very last sample.

The missed 2026-05-30 ev-robert charge (50→82 %, ~24.3 kWh, home) was reconstructed manually as `needs_review` so the user can confirm and edit if needed.

## v3.0.31 (2026-05-29)

### Nav-menu label: "Charge" instead of "New Charge"

The top-nav `nav.input` entry kept the old "Neue Ladung" / "New Charge" label in all six languages — out of sync with the page heading + "+" button which were already renamed to just "Ladung" in v3.0.24/27. Renamed across DE, EN, ES, FR, IT, NL so the menu matches the page.

## v3.0.30 (2026-05-29)

### Maintenance: same row-click modal pattern as trips and charges (phase 2)

The maintenance page is rewritten to match what trips and charges already look like:

- Heading **Wartung** on the left, **"+ Neue Wartung"** green button on the right.
- Below: the existing due-items alert (unchanged), then the entry list — full width, no separate left-column form, no trailing trash column.
- **Clicking a row** opens an in-place modal pre-filled with that entry. The same modal also handles the **"+"** path; the only difference is whether the red Delete button at the bottom-left is visible.
- The form posts to `/maintenance` (create) or `/maintenance/edit/<id>` (update). Delete uses the existing `/maintenance/delete/<id>` route via a confirm + synthesized form, same as on the charge list.

The auto-fill heuristic that picked next-due km / date from the chosen type still works — its `#itemTypeSel` listener moved into the modal but the id is preserved. Modal sizing follows the v3.0.26/28 conventions: `modal-fullscreen-md-down` so it's full-screen up to 768 px, form is `d-flex flex-column flex-grow-1 overflow-hidden` so Save / Delete stay pinned to the bottom on mobile.

The backend endpoints (`GET /api/maintenance/<id>` and `POST /maintenance/edit/<id>`) shipped inert with v3.0.26; v3.0.30 wires the UI to them.

## v3.0.29 (2026-05-29)

### Charge list shows full data on mobile too

Loss and CO₂ used to be `d-none d-lg-table-cell` — hidden below ~992 px — so phones and small tablets saw a charge row stripped of half its useful figures. Both columns are now `d-md-table-cell` (visible from 768 px up). Below 768 px, where dedicated columns still don't fit, a compact muted summary line appears under the date / operator: e.g. `84.499 km · 50→90% · 12.0% Verluste · 13.3 kg CO₂`. Same data, one readable line, no horizontal scroll required.

## v3.0.28 (2026-05-29)

### Edit modal: Save reachable + no horizontal slide on mobile

**Save / Cancel slid off the bottom on small screens.** The edit modal wrapped `modal-body` + `modal-footer` in a `<form>`. The form was a plain block element between `modal-content`'s flex children, so the body wasn't constrained to the available height — its content grew past the viewport and pushed the footer (with Save and Delete) below the visible area. The form is now `d-flex flex-column flex-grow-1 overflow-hidden` so it takes over the flex column role: body grows + scrolls inside it, footer stays pinned at the bottom.

**Modal could slide horizontally on small screens.** `overflow-x: hidden` on the modal-body of both the charge-edit and the new-charge dialogs prevents a stray-wide element (Lat/Lon input group, Bootstrap row gutter) from creating a horizontal scroll axis.

## v3.0.27 (2026-05-29)

### Hotfix: /input was 500-ing after v3.0.26, button label corrected

The v3.0.26 comment in `_history_section.html` quoted `{% block content %}` literally inside a JS comment. Jinja2 happily parsed that as a real block-open tag, then ran out of template before finding the matching `{% endblock %}` and threw a `TemplateSyntaxError` — every GET on `/input` returned HTTP 500. The comment now describes the same situation without the literal tags.

The "+ Neue Ladung" button (and modal title) is renamed to just **"Ladung"** to match the page heading — that was the original v3.0.24 rename intent, accidentally re-introduced as "Neue Ladung" via a new key in v3.0.25.

## v3.0.26 (2026-05-29)

### Hotfix: charge row click + smaller charge modal

**Row click did nothing.** The history-list `<script>` lives inside `{% block content %}`, which is rendered *before* `base.html` loads `bootstrap.bundle.js`. The `typeof bootstrap === 'undefined'` guard at the top of the row-click setup therefore always tripped on first execution, no listener got attached, and clicking a charge row was a no-op (regression introduced in v3.0.24). Setup is now wrapped in a `DOMContentLoaded` hook so it runs after Bootstrap is in scope.

**Charge modal too big on small screens.** The new-charge modal carried `modal-lg modal-fullscreen-sm-down`, which left tablets and split-screen phones between 576 px and 768 px viewing an 800 px modal that overflowed. Both the new-charge and the edit modals now use `modal-fullscreen-md-down` (full-screen up to 768 px, default 500 px above) — fixes the cramped tablet view without affecting desktop.

## v3.0.25 (2026-05-29)

### New-charge form moves into a "+" modal (phase 1b)

The `/input` page is now just the charge list with a "+ Neue Ladung" button above it. Clicking the button opens the full new-charge dialog — vehicle picker, AC/DC/PV, Start/Stop/Live-Timer, all fields, Save — in a Bootstrap modal. The page itself stays calm and list-focused; the charging UI only appears when you're actually entering one.

To keep this low-risk, the modal wraps the existing form contents *in place*: every input keeps its original `id` so the ~700 lines of session/timer/polling/restoreSession/auto-stop/auto-persist/CO₂-fetch/operator-autofill JS that has accumulated over v3.0.15–v3.0.22 attaches to the same DOM nodes without changes. Only the outer card wrapper changed.

An auto-open hook makes sure the modal pops up whenever there's an in-progress charge — server-rendered `active_session=True` from the intermediate-save round-trip, or a `startTime` in `localStorage`. The "Ladung läuft" badge sits in the modal header so you see it as soon as the modal opens.

Same interaction pattern as the trips log and the v3.0.24 row-click editor — that's the consistency goal.

## v3.0.24 (2026-05-29)

### Charges: row-click → in-place edit modal (phase 1a)

The charge history list now follows the same interaction pattern as the trips log: clicking a row opens an in-place modal with all the fields editable + a red Delete button at the bottom-left. The dedicated pencil/trash column on each row is gone. After save or delete the user lands back on the page they came from (Referer-aware redirect) instead of being bounced to /history.

- New endpoint `/api/charges/<id>` returns a Charge as JSON for the modal to populate from.
- The modal is included in `_history_section.html` so both `/input` and `/history` get it.
- The `/input` page heading is renamed from "Neue Ladung erfassen" → "Ladung" (matches the trips/Fahrtenbuch tone). All six languages.
- Filled in the previously-missing `input.operator*` keys in es / fr / it / nl (they were quietly falling back to German).

The new-charge form (Start/Stop/Live-Timer) above the list stays in place for this phase. Phase 1b will move that into a "+" modal in v3.0.25.

## v3.0.23 (2026-05-28)

### Trip-edit map: both endpoints are always visible

The trip-edit map's initial `fitBounds` ran before the Bootstrap modal had finished its slide-in animation, so Leaflet measured a 0×0 / mid-animation viewport and the resulting zoom was off — one of the two markers often landed outside the visible area. The map's `shown.bs.modal` handler already calls `invalidateSize` to correct the dimensions, but it did not re-apply the fit. It does now: the last fit is replayed after the dimensions are correct, with generous padding (60 px) and a moderate `maxZoom: 13` so both blue and red markers always fit comfortably with surrounding context.

## v3.0.22 (2026-05-28)

### Auto-stop a manually-started charge actually works again

A charge started via the Start button is supposed to auto-stop when the car finishes charging. The old implementation polled `/api/vehicle/status` every 10 minutes, which both burned API quota and lagged the user by up to 10 min plus the cloud cache lag — long enough that the feature looked broken in practice.

The auto-poll now hits a new lightweight DB-only endpoint `/api/vehicle/last_sync` (no cloud call, no quota cost) on a **60-second cadence**. The background sync loop already updates the DB on a 10-min cached read, so the same `is_charging` 1→0 flip is now picked up by the form within ~60 s of the bg loop seeing it. An immediate first tick on session start also catches charges that ended *before* the user opened the page.

### Hard cap on a single charge's kWh

A charge entry can no longer exceed `battery_kwh × 1.3` — i.e. capacity plus the worst-case AC charge losses plus a small margin. The form's `max=` attribute reflects this so the browser blocks an over-typed value, and a server-side check rejects on save with a clear flash message. Catches typos (e.g. 333 kWh on a 64 kWh car) that would otherwise wreck stats and the self-calibrating efficiency baseline.

## v3.0.21 (2026-05-28)

### New-charge form: location, operator + price pre-filled from GPS

Starting a fresh charge entry now mirrors what the auto-detection (v3.0.18/19) does on charge-end: the latest vehicle sync's GPS is classified against home/work/favorites, and the form arrives with **location name + operator + per-kWh price** already filled in when the car is parked at a known spot. Lat/Lon are always pre-filled when GPS is available (useful at public chargers too), and the operator is only auto-selected when it has a configured price in Settings — otherwise the dropdown filter would hide it. Everything is editable, and an in-progress session's localStorage restore only writes into empty fields, so the pre-fill never overrides what you typed.

## v3.0.20 (2026-05-28)

### Trip-edit dialog — mobile-focused cleanup

Each endpoint card in the trip editor now shows only the timestamps/odometer/SoC that actually belong to it: **Abgefahren** + departure odometer/SoC on the start card, **Angekommen** + arrival odometer/SoC on the destination card. The other half — the previous parking's arrival on the start side, and the next trip's departure on the destination side — was confusing context for a single trip's editor and is gone from the UI (the underlying values are preserved unchanged on save).

The duplicate "Auf Karte wählen" chip in each card header is removed; the two clearly-labelled "Startpunkt/Zielpunkt auf Karte wählen" buttons below the map remain. The map now caps zoom at 14 when fitting both endpoints, so two close-by markers no longer snap into street-level tree pixels.

## v3.0.19 (2026-05-25)

### Auto-detect: one charge per session, realistic loss

Two fixes to the v3.0.18 auto-detection:

**Triple entries for a single charge.** A single physical charge often reports several `is_charging` 1→0 blips — the cloud briefly says "not charging" mid-session while the SoC keeps climbing. Each blip fired the detector with a fresh, *non-overlapping* SoC slice (e.g. 63→78, 78→92, 92→99), and the old overlap-only de-dup never caught them, so one charge became three rows. The detector now folds a new slice into a recent un-reviewed auto charge when their SoC ranges are contiguous (within 5 %) and they're within 90 min of each other — extending the existing row instead of adding another. Reviewed/manually-logged charges are still never touched.

**Implausibly low loss.** When slices were merged (or an auto entry was edited), `loss_kwh` could keep a stale per-fragment value, leaving a charge showing ~6 % loss against a far larger gross. Merging now resets the loss and re-derives it over the full span. The self-calibrating efficiency baseline also no longer learns from un-reviewed auto entries (whose loss is itself an estimate), so it can't drift.

## v3.0.18 (2026-05-23)

### Auto-detect forgotten charges (red "review" entries)

If the car charges somewhere but you forget to start a session in the app, the charge is now detected automatically and added to the history — flagged red ("Prüfen") so you edit/confirm it before it counts as final.

Detection runs on the `is_charging` 1→0 transition (charge just ended): it walks back over the charging run, takes SoC-before-charge → SoC-at-end, and only fires when the gain is ≥ 3 %. Using the `is_charging` flag as the trigger inherently filters out the stationary SoC re-calibration the cars occasionally do (that never sets `is_charging`); the 3 % floor is a second guard.

The reconstructed entry derives: charge type (DC if observed power > 25 kW, else AC), gross kWh (incl. loss via the per-vehicle efficiency for AC), location + operator/price from the start GPS (home/work/favorite), and a CO₂ fallback. It's de-duplicated against any charge already overlapping that day's SoC window, so a manually-logged or auto-persisted charge is never doubled. Editing + saving the entry clears the red flag.

## v3.0.17 (2026-05-23)

### Auto-persist on Stop — charges can no longer be lost

The biggest data-loss trap in the charge flow: **Start and Stop are client-only**. A charge was never written to the database until the user *also* pressed the green Save button. Users reasonably assumed Stop = saved and lost whole charges (field report: an 82→94 % home charge with Start+Stop pressed but no row in the DB — confirmed by zero `/input` POSTs in the logs).

Now clicking Stop (or an automatic stop at the SoC limit) immediately submits an intermediate save, so the charge lands in the DB the moment it ends. The form is restored after the redirect so the user can still refine operator/price/notes and Save again — that folds into the same row (charge_id round-trip + the v3.0.15 90 s server-side dedup). One-shot guard (`_autoPersisted`) prevents a resubmit loop.

The lost charge from the field report was reconstructed from the vehicle sync history (SoC 82→94, 15:38–16:57, home, 9.13 kWh gross / 1.45 kWh loss).

## v3.0.16 (2026-05-19)

### Live charge counter now counts GROSS (loss included) for AC/PV

The running counter in the new-charge form recorded the loss-free theoretical energy and projected SoC as if 100 % of the wall energy reached the pack — so `kwh_loaded` collapsed the loss to 0 and the live SoC over-stated.

Using the v3.0.15 self-calibrated per-vehicle charge efficiency (`CHARGE_EFF`), for AC/PV:
- **`kwh_loaded` is now GROSS** (meter/wall energy). The SoC-delta paths (`calcKwh`, `doStop`) compute `net ÷ efficiency`; the live AC timer already used time × charger power (gross) and now labels the implied loss %.
- **SoC projection uses the NET fraction** (`gross × efficiency`) so the evolving SoC target during a charge no longer over-states.
- The kWh hint shows the applied loss %, e.g. `(~12.3 kWh @ 11 kW · −15% Verlust)`.

DC is intentionally excluded (current swings too much for a fixed-efficiency estimate). A manually typed meter reading still wins over the estimate. New `input.loss_label` key in all six languages.

## v3.0.15 (2026-05-19)

### Charge flow hardening — loss, double-submit, 12 V stop, CO₂, operator list

A batch of fixes after field reports that the new-charge flow misbehaved (loss not calculated, duplicate rows from triple-tapping Stop, missing CO₂, unusable provider dropdown).

**Charge-loss auto-calc (real root cause).** `calculate_fields` now treats a stored `loss_kwh = 0.0` as "unset" and re-derives it (a real charge never has exactly zero loss — 0.0 only ever came from the auto-calc collapsing when `kwh_loaded` was filled with the *theoretical* SoC-delta and then freezing via the intermediate-save round-trip). When the gross−net difference collapses, loss is recovered from a **self-calibrating per-vehicle charge efficiency**: the median net÷gross of that vehicle's recent real AC/PV charges (2–40 % band), clamped 70–97 %, default 0.88 until there's enough history.

**Double-submit guard.** The Stop+Save buttons had no debounce, so a 3× tap inserted 2–3 near-identical rows. Now: the Save button disables on first submit with a spinner (re-enables after 8 s as a safety net), and the server folds any second submit without a `charge_id` into a row created in the last 90 s with the same vehicle/date/SoC window — so even racing requests can't duplicate.

**12 V lockout no longer "kills" the Stop button.** With the v3.0.12 lockout, `POST /api/vehicle/status?force=1` returns 423 when 12 V < 70 %. The input page didn't handle that, so the Stop button appeared dead (the user's "had to tap 3×"). Now it surfaces a confirm ("12 V low — fetch anyway?") and on decline falls back to the last cached SoC so the charge can still be stopped and saved manually.

**CO₂ never empty.** ENTSO-E often has no intensity for the current hour yet during an active charge — that's why CO₂ was "sometimes missing". When the lookup yields nothing, the charge now inherits the CO₂ value of the vehicle's most recent non-PV charge (flagged as estimated) instead of being left blank.

**Operator dropdown.** Favorites ("Zuhause"/"Arbeit") are pinned to the top; third-party operators without a configured €/kWh price are hidden (you can't pick a provider whose price isn't maintained — it would silently log a €0 charge). The location generics and the currently-selected operator on an edit are always kept.

## v3.0.14 (2026-05-10)

### Fix: charge-loss auto-calc no longer silently zeroed

`calcKwh()` on the input form filled `kwh_loaded` with the theoretical loss-free energy `(socTo − socFrom)/100 × battery_kwh` and overwrote it on **every** SoC change — with no `dataset.manual` guard, unlike the time-based estimator right next to it. So if the user typed the real charger kWh and then nudged a SoC field, their value was clobbered with the theoretical one, and `loss = real − theoretical` collapsed to exactly 0. Auto-loss now survives a manual kWh entry: `calcKwh()` bails out when `kwh_loaded` was hand-edited.

### Settings → operator list readable on mobile, no more horizontal scrollbar

The operator/CPO editor was a 4-column table wrapped in `table-responsive`. The `€/kWh` / `€/Mon.` input-group suffixes ate so much width that the price fields were unreadable on a phone, and `overflow-x:auto` produced the intermittent horizontal scrollbar. Replaced with a wrapping grid: operator name on its own line, price and monthly fee side-by-side at half width each, units moved into the field labels. No fixed widths, no `table-responsive`, so it reflows down to ~320 px without a scrollbar. Add/remove-custom-row JS updated for the new DOM (div list instead of `<tbody>`).

## v3.0.13 (2026-05-10)

### 12 V chart — visualise the 70 % lockout threshold

The 12 V history plot on the dashboard now draws a dashed red line at 70 % so the user can see at a glance how close (or far) the battery is to the force-refresh-lockout threshold introduced in v3.0.12. The legend below the chart names the threshold so it can't be mistaken for some other reference. Same line shows up in the fullscreen / clone view of the chart.

Implemented as a flat dataset spanning the chart's time range (no chartjs-annotation plugin dependency) — the threshold pattern is now generic on every `CHART_DEFS` entry, so adding similar lines to other plots is a one-field change.

## v3.0.12 (2026-05-10)

### 12 V battery lockout — block automatic force-refresh below 70 %

Each force-refresh wakes the AVN over cellular and pulls non-trivial current from the 12 V auxiliary battery. The main pack only top-charges the 12 V intermittently while parked, so a stretch of repeated force-refreshes (witnessed in v3.0.10 — 17 wakes in 2 h 47 min on a stationary car) can flat-batter it. v3.0.11 fixed the underlying loop trigger; v3.0.12 adds a hard floor in case any other code path produces too many force-refreshes.

**Backend lock**: when the latest sync's `battery_12v_percent` is below 70 %, the bg-sync loop demotes any `force=True` decision (smart→force OR queued triggered-force) to a cached sync and logs the suppression. `last_12v_lockout_at` is stamped in AppConfig for visibility. The threshold is a const for now (`LOW_12V_THRESHOLD_PERCENT = 70` in `services/vehicle/sync_service.py`).

**API gating**: `/api/vehicle/status?force=1` and `/api/trips/sync_now` now return `423 Locked` with `{error: 'low_12v', battery_12v: N, threshold: 70}` when 12 V is below threshold and the caller hasn't passed `confirm_low_12v=1`. Any other code that wants to wake the car has to surface the warning to the user explicitly.

**Dashboard UX**: a yellow banner appears at the top of the dashboard when the lockout is active (12 V %, hint that automatic force-refreshes are paused). The "Live" button still works, but on click it now catches the 423 response, opens a confirmation modal explaining the trade-off, and only re-fires the force-refresh with `confirm_low_12v=1` after the user clicks through. The sync-health chip escalates to yellow with a `low_12v_lockout_Npct` reason so it's visible from any page where the chip renders.

8 new translation keys (`dash.low_12v_*` and `common.cancel`) in all six language files.

## v3.0.11 (2026-05-07)

### Stop the stationary-car force_refresh loop (12 V battery saver)

Severe bug: an overnight-parked car had its AVN woken **17 times in 2 h 47 min** the morning after the smart window opened — every 10 min, on the dot.

Root cause: the smart→force decision uses the timestamp of the most recent GPS-bearing `VehicleSync` row to compute staleness. A force_refresh on a stationary car returns *identical* values (same SoC, same odo, same GPS coords), so `_save_vehicle_sync.differs_from(last)` skips the insert and no new row is written. The "last GPS row" timestamp therefore never advances, every subsequent 10-min tick re-evaluates as "stale", and the loop fires the force_refresh again. AVN wake-up = 12 V drain — overnight this can flat-batter a car.

Fix: a per-vehicle `last_gps_poll_ok_at` AppConfig anchor is now stamped whenever a force_refresh returns a status with GPS, regardless of whether the resulting row is deduped. The staleness check anchors on `MAX(row timestamp, AppConfig timestamp)` so the loop breaks after the first successful force_refresh of the morning.

## v3.0.10 (2026-05-06)

### synthesize_day — distinct marker so cleanup queries don't hit polled-unknown PEs

`synthesize_day` previously stamped `lat=0.0, lon=0.0, label='unknown'` on its synthetic rows. The parking hook's `_open_unknown` placeholder (created when an odo-advance closes the previous PE but no fresh GPS is available to anchor the new location) uses the same sentinel coordinates and label. A cleanup query against `lat=0,0 AND label='unknown'` would silently delete real polled-unknown PEs along with the synth ones.

Synthetic PEs are now tagged `favorite_name='_synth'` in addition to the lat/lon sentinel. The marker is masked out in `_event_to_dict` so it never leaks into the trips API or the template. Cleanup queries can now safely target `favorite_name='_synth'` to drop only the synthetic rows.

## v3.0.9 (2026-05-06)

### synthesize_day — anchor selection scoped per target_date

The v3.0.6 anchor logic used `events[-1]` (the chronologically latest PE) regardless of which day was being reconciled. That works for the wedged-mid-day case (where the latest PE is on the target_date) but silently no-ops for lock-gap backfills: when reconciling a day the VM was LUKS-locked, the latest PE is days in the future, so the cursor-time skip drops every orphan and nothing gets synthesised.

Reworked: prefer the latest PE that already exists ON `target_date`, fall back to the latest PE strictly BEFORE `target_date`, and only then bail out. With this fix, running `synthesize_day` for an old offline-day correctly chains off the last pre-lock PE.

## v3.0.8 (2026-05-06)

### Fahrtenbuch — gap-aware regen / SoC estimation, consistent home/work labels

The v3.0.7 regen fix only kicked in when the trip's PE rows still had `label='unknown'`. Polling re-classifies synthetic PEs as soon as new GPS lands at one of their coordinates — within minutes of a sync resuming, all the synth labels become `home`/`work`/`other`/`favorite`, the predicate stops matching, and the broken cum-delta path takes over again. Each trip in the wedged window then gets the same multi-hour regen attributed to it (~4.23 kWh in the test data).

Replaced the label check with a **sync-gap check**. Pull the snapped sync-row timestamp at each trip endpoint; if either gap exceeds 30 min, the cum-delta is treated as unreliable and the trip falls back to km × recuperation rate. Same gap logic now drives **SoC estimation** — when the start-of-trip sync is more than 30 min before the actual departure, we estimate `soc_used` from `km × consumption_kwh_per_km / battery_kwh × 100`. Consumption rate comes from the most recent SDK 30-day rolling average for the active vehicle, or 0.18 kWh/km as global fallback.

Trips show an asterisk indicator when either value is estimated, with localised tooltips in all six languages.

### Fahrtenbuch — translate home/work labels at render time

Old PEs carry the historical `home_label` / `work_label` strings from when the user first set them up ("Home" / "Work" / "Zu Hause" / "Arbeit"), which produced a mix of languages on a single page when the user later switched UI language or was looking at data from multiple installs. Drop the stored name for `label='home'` and `label='work'` so the template's translation fallback (`t('trips.home')` / `t('trips.work')`) always wins. `label='favorite'` keeps its user-defined name.

## v3.0.7 (2026-05-06)

### Fahrtenbuch — use km × rate for synthetic-PE trips, not the cumulative delta

When a Fahrtenbuch trip touches a synthetic PE (label='unknown' from `synthesize_day`), the cum-regen delta lookup snaps to the last pre-hang sync and the first post-hang sync, so the entire afternoon's recuperation gets attributed to whichever single synthetic trip happens to span that window. The other synthetic trips end up with the same delta or zero.

For trip pairs where either endpoint is synthetic, skip the cum-delta path entirely and use km × the configured per-vehicle recuperation rate. That's the canonical regen value when there's no nearby sync to measure against — same fallback the existing logic already applies when measurement comes back as zero, just enforced earlier so the wrong delta never gets stored.

## v3.0.6 (2026-05-06)

### synthesize_day — fix odometer ordering when chaining off a closed PE

The v3.0.5 chain anchor used "the latest PE whose arrived_at ≤ first orphan trip" — which on a real install picked yesterday's home stop as the base, ignored the morning commute (already paired), and produced an odometer regression: synth PE#94 odom=83681 vs real PE#92 odom=83700.

Reworked: walk forward from the **latest** PE (real or synthetic) and skip any orphan trip older than that PE's arrival. Trips chronologically before the latest known PE are dropped — without GPS we can't tell where the car was when the trip started, and inserting them out of order corrupts the chain. They still show up as SDK-only rows in `vehicle_trips` for stats, just not in the Fahrtenbuch.

## v3.0.5 (2026-05-06)

### Background sync watchdog + Fahrtenbuch gap-fill from SDK trips

A wedged BlueLink/UVO `force_refresh` call on a Kia install left the background sync thread silently hung for two days — no crash, no log, just no more polling. With polling stopped, ParkingEvent transitions are no longer detected and the Fahrtenbuch shows only whatever pairs were closed before the hang.

**Watchdog around `force_refresh_vehicle_state`** — the SDK call now runs in a long-lived `ThreadPoolExecutor` with a 120 s timeout. On timeout we log a warning, fall back to cached state, and the bg-sync loop continues on the next tick. The runaway worker thread leaks (the SDK has no cancellation hook) but the loop is no longer wedged.

**Dashboard sync-health badge** — small chip next to the live/cached buttons that polls `/api/sync/health` every minute. Green when the bg-loop ticked recently and no recent timeouts, yellow on overdue ticks or a recent timeout, red when the loop has been silent for >60 min. Tooltip carries the full payload (last tick age, last force-refresh outcome, 24 h timeout count) so the user can see at a glance what the watchdog is doing.

**Fahrtenbuch gap-fill from SDK trips** — when the SDK has trips that no PE pair can claim (because polling missed the transitions), `synthesize_day` now chains synthetic PE rows with `label='unknown'`. No GPS, but the times and distances are minute-accurate, so the missing drives at least show up in the Fahrtenbuch. Phantoms (0 km / sub-2-min ignition cycles) are filtered out. Hooked into the daily reconcile so it runs automatically each night and on every gap-aware backfill.

## v3.0.4 (2026-05-01)

### Settings → LUKS-Passphrase ändern

The setup wizard could already change the LUKS passphrase (during the initial "set your real passphrase" step), but post-setup there was no way to rotate it from inside the app — users had to SSH in and run `cryptsetup` by hand.

New Settings card with old / new / confirm fields. Reuses the existing `services.setup_service.change_luks_passphrase` helper (which is already wired up to the `/sbin/cryptsetup luksChangeKey` sudoers entry).

**Auto-unlock-aware:** if auto-unlock was on when the passphrase change happens, the stored keyfile gets refreshed with the new passphrase right after `cryptsetup` succeeds. Without this the next reboot would fail to auto-unlock with the stale stored key, locking the user out until they manually unlock.

If the keyfile refresh fails (rare — would mean the brand-new passphrase doesn't validate against the LUKS header, which shouldn't happen) the response carries a warning so the user knows the change went through but auto-unlock is now stale.

## v3.0.3 (2026-05-01)

### LUKS Auto-Unlock — opt out of the passphrase prompt

For VMs running in trusted environments (home network behind a router, on-prem hosting), the LUKS unlock prompt after every reboot is more friction than security — anyone with disk access in those scenarios is the operator anyway. v3.0.3 adds an opt-in feature to skip the prompt:

**Settings → Auto-Unlock beim Boot** card with a toggle. When enabled the user enters their current LUKS passphrase once, the wrapper verifies it via `cryptsetup --test-passphrase`, then writes it to `/etc/ev-tracker/luks-keyfile` (mode 0400, root-only). On the next boot `ev-unlock-web.service` reads that file and unlocks the volume without showing the web UI at all — `ev-tracker.service` starts immediately, the app is ready in ~10 s instead of waiting for someone to enter the passphrase.

**Setup wizard step 1** now also has a checkbox for the same thing — first-time installers can pick "no passphrase prompt after reboots" right when they set their LUKS passphrase.

**The trade-off is shown explicitly** in the UI: anyone with disk access can now read the passphrase, and the LUKS layer effectively no longer protects data at rest. Suitable for VMs where stolen-disk is not in the threat model.

**Implementation:**
- New root-owned wrapper `/usr/local/bin/ev-luks-autounlock` with sub-commands `enable | disable | status | try-unlock`. Sudoers grants `ev-tracker` NOPASSWD on each.
- `/usr/local/bin/ev-unlock-web` patched to call `try-unlock` at boot before serving the web UI; on success it skips the UI entirely.
- New API: `GET /api/luks/auto-unlock/status`, `POST /api/luks/auto-unlock/enable` (body `{passphrase}`), `POST /api/luks/auto-unlock/disable`.
- 17 new translation keys across all 6 languages.

System-side scripts (`ev-luks-autounlock`, the patched `ev-unlock-web`) and the sudoers drop-in must be installed once per host with root — they're not part of the standard tar-pipe deploy. The fresh VM image bundled in v3.0.3+ ships with them included.

## v3.0.2 (2026-05-01)

### Trip-info reconcile — gap-aware backfill on startup

Pre-fix the nightly + startup catch-up always walked back exactly 3 days. After a long offline gap (e.g. an EV-tracker VM that was LUKS-locked for a week, common with the LUKS-encrypted-volume install), trips from days 4-N were silently dropped even though the Kia/Hyundai SDK still has them server-side for ~30-90 days.

Now `gap_days_since_last_reconcile(vehicle_id)` reads `last_reconcile_at_<vid>` and returns the actual gap, capped at 30 days (the SDK retention floor). The daily reconcile loop uses that instead of the hard-coded 3:

- 1 day gap → 3 days (default minimum)
- 5 day gap → 5 days
- 25 day gap → 25 days
- 90 day gap → 30 days (cap)
- fresh install → 3 days (no timestamp yet, default)

API quota is fine: `day_trip_info` costs 1 call per day, even a 30-day walk only burns 30 of the daily 200/vehicle quota.

## v3.0.1 (2026-05-01)

### Tailscale post-boot kick (3× netcheck in first 90 s)

After a VM reboot tailscaled often comes up before the LAN/DHCP is fully stable, ends up cached on a stale path (DERP-only or no UPnP), and only re-evaluates 30 minutes later on its own. `create_app()` now spawns a daemon thread that runs `tailscale netcheck` at 15 s, 45 s and 90 s after service start to force fresh path discovery. Errors are swallowed so non-Tailscale deploys (Synology/bare-Pi installs without `tailscale`) ignore this silently.

For LUKS-encrypted-volume installs there's now also a separate root-owned systemd unit `tailscale-kick.service` (installed manually, see commit notes) that runs the same kick *before* LUKS unlock, so the unlock page itself stays reachable even after a 3 a.m. unattended-upgrade reboot.

## v3.0.0 (2026-04-29)

Major release: multi-vehicle / fleet support. The app moves from "one car, one set of stats" to "any number of cars, each with its own history, sync schedule, and per-vehicle settings". Single-vehicle installs are auto-migrated and keep working unchanged — the migration seeds a single `Vehicle` row from your existing AppConfig and stamps every existing charge / sync / parking event / trip / maintenance record with that vehicle's id.

> **Backup recommended before update.** The migration is idempotent and well-tested but the schema change is substantial (new `vehicles` table + `vehicle_id` foreign key on five existing tables). If anything goes wrong you'll want a known-good DB to roll back to.

### Multi-vehicle / fleet (Phase 1)

- New `vehicles` table with per-vehicle hardware (battery_kwh, SoH baseline, battery production CO₂, max-AC kW, fossil-CO₂/km, recuperation kWh/km), API credentials (brand/user/pw/pin/region/VIN/auto_sync), color, icon, and lifecycle metadata (acquired_at / retired_at / archived / notes).
- `vehicle_id` foreign key added to `charges`, `vehicle_syncs`, `parking_events`, `vehicle_trips`, and `maintenance_log`. Every existing row is auto-stamped with the migration-seeded primary vehicle so single-car installs see no change in their data.
- **Navbar fleet picker** with a "Whole fleet" view + per-vehicle filter. Every dashboard / history / trips / maintenance / report page respects the picker; switching vehicles is one tap from any page.
- **Fleet CRUD section in Settings** — add, edit, archive, restore, delete vehicles. Per-vehicle test-connection + sync-now buttons. Archived vehicles still contribute to fleet-wide aggregates so a sold car's lifetime kWh / km / cost stays visible.
- **Setup wizard step 3** — first-install flow now lets you register multiple vehicles in one shot before the app opens.
- **Per-charge vehicle dropdown** on the new-charge form, with the per-vehicle battery + max-AC values feeding the SoC / time / kWh estimators in real time.
- Vehicle column appears in history / trips / maintenance / report tables when the picker is on "whole fleet"; hidden when a single vehicle is selected (no redundant column).

### Multi-vehicle / fleet (Phase 2)

- **Per-vehicle simultaneous sync** — each vehicle has its own daily API quota counter (200/day for Kia/Hyundai), its own smart-window state machine, its own force-refresh queue, and its own daily SDK trip-info reconcile.
- All stats helpers (SoH baseline, recuperation rate, regen totals, fossil CO₂ comparison) became vehicle-aware: pass `vehicle_id` for one car, omit for fleet-wide totals.
- Token-fetch (Kia/Hyundai OAuth refresh-token helper) operates on the picker-active vehicle and writes to that vehicle's `api_password`.
- Per-vehicle THG-Quote (German EV emissions certificate payouts) — quotas are bound to one vehicle, the dashboard / yearly chart / report all filter by the picker, and the year-end reminder warns only when a non-archived vehicle is missing the previous year's payout.

### Connector install flow — clean restart instead of broken reload

After `pip install`-ing a new vehicle brand (VW Group, Tesla, Renault, MG, Polestar, Smart, Porsche, …), the API endpoint used to call `importlib.reload(services.vehicle.registry)` to make the freshly-installed connector visible. That wiped the brand registry to an empty dict and could not repopulate it (the connector modules were already imported, so their module-level `register(...)` calls didn't fire on a no-op `__import__`). Result: every subsequent vehicle sync raised "Unknown vehicle brand: kia" until the service was restarted out-of-band.

Now: a successful install schedules a 1-second-delayed systemd restart in a daemon thread (same pattern as DB-backup-import) and returns `restarting: true`. The settings install button polls `/api/health` until the worker is back, then reloads — no more reload-races-restart connection error.

This applied to **every** brand, not just VW. The fix is registry-wide.

### PV (photovoltaic) charges — settings cascade onto existing rows (was v2.28.64)

User report: setting the PV-Strompreis to €0,00 in Settings still left the report showing €0,30/kWh on every PV charge.

Two reasons, both fixed:
- Saving the PV settings did not cascade onto existing PV rows. Each `Charge` stores `eur_per_kwh` snapshot-style at insert time, so changing the global PV price later left every previously-saved PV charge at its original price. The `save_pv` action now updates `eur_per_kwh` + `co2_g_per_kwh` on every existing PV charge and recalculates `total_cost`.
- `_get_pv_co2()` returned the legacy 42 g/kWh fallback when the user explicitly zeroed yield or lifetime. The check now treats explicit zero as "user wants 0" and returns 0; the 42 fallback only fires on truly unparseable input.

### Report Preis-Plot — show PV charges as €0,00 dots, color-coded (was v2.28.65)

The price chart used to filter out zero-priced charges entirely, which left only the rare paid AC/DC dots in the plot. For users with mostly-PV data this looked like the chart was claiming they paid that price across the board.

Now: every charge with a non-NULL `eur_per_kwh` is plotted, split into one dataset per charge type (AC / DC / PV) using the existing TYPE_COLORS palette. PV charges sit on the x-axis at €0,00 and the legend makes the breakdown explicit.

### Mobile UX

- Vehicle CRUD form's API row was `col-md-1` for PIN / region / VIN — ~80 px wide on tablets, unusable. Re-flowed to `col-12 / col-sm-6 / col-md-3-or-4` so fields breathe at every breakpoint.
- Setup wizard step 3 (vehicle registration) uses `col-12 / col-6` grid throughout — already mobile-friendly.

### i18n — backfilled all v3.0 keys across six languages

87 v3.0 strings (fleet section, navbar picker, setup wizard step 3, sync section, vehicle install restart message, per-vehicle THG label, …) were missing in `es / fr / it / nl`. Without these the strings fell through to German per the i18n fallback chain, so Spanish / French / Italian / Dutch users were seeing German UI text. All localised properly.

## v2.28.65 (2026-04-29)

### Report Preis-Plot — show PV charges as €0,00 dots, color-code by charge type

Follow-up hotfix to v2.28.64. After PV charges were correctly cascaded to €0,00 in the database, the report's "Preis pro kWh" plot still looked like the user was paying €0,30 across the board — because the chart was filtering out zero-priced rows entirely. With mostly-PV data, only the rare paid AC/DC dots remained visible.

Fix: include zero-priced rows, split into one dataset per type with a legend.

## v2.28.64 (2026-04-29)

### Report tab — every plot is clickable to open fullscreen, like the dashboard tiles

User report: the dashboard's "click any chart to fullscreen" UX is much nicer for inspecting data; the report tab should work the same way.

Implemented the same pattern from `templates/dashboard.html` (`makeExpandableChart` / `openDashFullscreen`). Each plot card on `/report` is now clickable / keyboard-accessible: pressing Enter / Space or clicking anywhere on the card opens a Bootstrap fullscreen modal that re-renders the chart at full window size with the same data + options.

Implementation details:

- New JS helpers `makeChart(canvasId, cfg)` and `openReportFullscreen(canvasId)` mirroring the dashboard's helpers. Configs are deep-cloned before stashing so Chart.js can mutate the modal copy without affecting the inline tile.
- Every chart-creation site (`makeBar`, doughnut, line, scatter, dual-axis, stacked) now flows through `makeChart` and gets the click-handler + expand-icon wiring automatically.
- Card-headers gain a `bi-arrows-fullscreen` icon on the right side, and the card itself becomes `tabIndex=0` for keyboard navigation. Click is suppressed on form-element children so embedded controls (range picker etc.) keep their normal behaviour.
- Click + keyboard listeners are wired once per card (guarded by `card.dataset.reportFsWired`) so range changes don't pile on extra handlers.
- New shared modal `#reportFullscreenModal` at the bottom of the page; on close, its chart is destroyed cleanly.

## v2.28.62 (2026-04-27)

### Report tab — secondary KPI cards same height; empty plots hidden entirely

User report: the "Zusatzkosten €0,00" card was a different height to its row-mates, and the v2.28.60 "Keine Daten" badge wasn't what was wanted — empty plots should disappear from the page entirely until data shows up.

Two fixes:

- Secondary KPI row (Verlust / Rekuperation / Zusatzkosten / Ø Preis) gains `h-100` on each card plus `d-flex flex-column justify-content-center` on the card-body, so all four cards stretch to the row's tallest sibling regardless of how much sub-text each carries. The Zusatzkosten card with no breakdown text no longer sits short.
- Empty plot cards now have their entire `col-lg-6` wrapper toggled with `d-none` instead of carrying a centred "Keine Daten" badge. Switched `setEmpty()` to walk up to the grid column and hide it; `destroyAll()` re-shows everything before the next render so range changes re-evaluate. The badge CSS is gone with the behaviour.

## v2.28.61 (2026-04-27)

### Report tab — uniform plot card sizes + 16th plot to balance the grid

User report after v2.28.60: the Zusatzkosten plot was visibly narrower / shorter than the Rekuperation plot, and other cards weren't all the same size either.

Two causes:

1. `.plot-card .card-body` had `min-height: 260px` rather than a fixed height. Cards with bottom legends (Zusatzkosten stacked bar, day-of-week dual-axis) grew taller than cards without legends; cards alone on a row didn't stretch against a row-mate. Switched to `height: 320px` (fixed) plus `canvas {width:100% !important; height:100% !important; max-height: none !important}` so every plot card is the exact same size regardless of content.
2. After v2.28.60 added 3 new plots, the total was 15 — odd count meant the last `col-lg-6` row had Rekuperation alone next to an empty column. Added a 16th plot — Aktivität pro Bucket (Anzahl Ladungen als Bar links, Anzahl Fahrten als Linie rechts, dual axis) — uses the existing `series.charges_count` / `series.trips_count` data, no backend change. Now 8 rows of 2 cards each.

New translation key `report.plot_activity` in all six languages.

## v2.28.60 (2026-04-27)

### Report tab rework: empty plots get a "no data" badge, plus three new statistics

User report: several plots on `/report` rendered as completely blank cards. The Preisentwicklung chart was particularly egregious — it used `type: 'time'` on the X-axis but the Chart.js date adapter (`chartjs-adapter-date-fns`) wasn't loaded, so it errored out silently and never drew anything. Other plots (Effizienz, Operatoren, Standorte, Lade-Typen) skipped rendering entirely on empty datasets, also leaving silent blank cards.

Fixes:

- **Empty-state badge** centred over every plot whose dataset is empty (`<i class="bi bi-bar-chart">` + "Keine Daten in diesem Zeitraum"). Renders for buckets that exist but have zero values *and* for plots whose data list is empty. Cleared on every render so range changes re-evaluate per plot.
- **Preisentwicklung** switched from `type: 'time'` to a category x-axis with the date strings already coming from the backend — no adapter dependency, renders reliably on every range. Tooltip carries date + price to 4 decimals.
- **Top-Standorte plot** sourced from `Charge.location_name` within the report range (was previously parking destinations, which the user couldn't influence directly). Tooltip now shows kWh and count. Falls back to parking destinations when no charge has a location_name.

New plots and KPIs (more statistics):

- **Verlust pro Bucket** — `Charge.loss_kwh` summed per bucket. Empty-state when no losses recorded.
- **Zusatzkosten pro Bucket** — stacked bar, Startgebühr (orange) + Strafgebühr (red), driven by the v2.28.59 columns. Stacked so total is the height; tooltips show breakdown.
- **Rekuperation pro Bucket** — sum of trip-log `regen_kwh` per bucket (measured + km × static-rate fallback). Stays consistent with Fahrtenbuch and dashboard's "Rekuperation nach Zeitraum".
- **Secondary KPI row** with four compact cards: Verlust (kWh + Ø %), Rekuperation (+ kWh/100km), Zusatzkosten (€ + breakdown), Ø Preis (+ Anzahl Ladungen).
- **Cheapest-charge highlight card** added next to the existing biggest-charge / longest-trip / cost-saved cards. The four highlight cards now share a 4-up grid on desktop, 2-up on mobile.

Backend `build_report()` extensions: `series.loss_kwh`, `series.extras_start`, `series.extras_block`, `series.regen_kwh` (per bucket); `summary.total_loss_kwh` / `avg_loss_pct` / `total_extras_eur` / `total_start_fee_eur` / `total_blocking_fee_eur` / `total_regen_kwh`.

New translation keys (12) added to all six languages.

## v2.28.59 (2026-04-27)

### Zusatzkosten on the input form: Startgebühr + Strafgebühr

User report: providers with start fees, blocking penalties, or contract base fees couldn't be tracked alongside the per-kWh price. Cost/100km and total-spend KPIs were systematically too low.

Charges gain two new fields:

- `start_fee_eur` — Vorgangskosten or share of a monthly base fee
- `blocking_fee_eur` — penalty for overstaying / blocking the bay

Both fold into `Charge.calculate_fields()` so `total_cost` becomes `eur_per_kwh × kwh_loaded + start_fee + blocking_fee` (with a graceful path for charges that have only fees and no kWh-based cost). All downstream KPIs (`avg_eur_per_kwh`, `cost_per_100km`, monthly aggregates, PDF report totals) automatically reflect the extras since they sum `total_cost`.

UI:

- /input form has a collapsed "Zusatzkosten" section under €/kWh + kWh, expanded automatically when the saved charge already carries fees so the user sees them without an extra click.
- Live calc-price label shows the breakdown: `€42.50 (38.50 + 4.00 Zusatzk.)` when extras are non-zero.
- Both fields are part of the `formCache` localStorage round-trip from v2.28.56 — intermediate-save preserves them like any other field.
- /edit form has the same pair of inputs in the same row as Verlust + CO₂.
- /settings → Anbieter table gains a new "Grundgebühr / Monat" column per operator (stored in `operator_monthly_fees` JSON config). The monthly fee isn't auto-attributed to charges yet — it's surfaced as a configuration value the user can manually distribute via `start_fee_eur` on the relevant charge. Auto-attribution can come later once usage patterns are clearer.

Schema migration `ALTER TABLE charges ADD COLUMN start_fee_eur REAL` + `blocking_fee_eur REAL` runs on first boot. Translations in all six languages.

## v2.28.58 (2026-04-27)

### Dashboard "Rekuperation nach Zeitraum" panel — sourced from the trip log

User report after v2.28.57: dashboard's "Gemessene Rekuperation" panel still showed today's value way under what was actually driven. Cause — the bucket totals (`today` / `this_week` / etc.) were `cum_now - cum_at(bucket_start)` over the SDK-side `regen_cumulative_kwh` series, which is delta-walked from Kia's rolling 3-month `total_regenerated_kwh` field. That field doesn't update on every drive — it lags by hours and sometimes by entire trips. So the panel sat at 0 for half the day even though the user drove 18 km in the morning, and only caught up once the cloud's rolling value advanced.

**Fix**: bucket totals now sum the trip log's `regen_kwh` values for trips ending in each bucket. The trip log already runs the measured-or-`km × static rate`-fallback logic per trip, so the dashboard is automatically aligned with what the user sees in the Fahrtenbuch — and it doesn't depend on Kia's lagging rolling-window number being current. Lifetime stays anchored on the SDK cumulative (most stable long-horizon read). Same `regen_stats` payload, so `/report` PDF renders consistently too.

The panel was renamed `Gemessene Rekuperation` → `Rekuperation nach Zeitraum` (drop "Gemessene") because the value now combines measured + km × rate fallback. PDF report section and dashboard card header updated in all six languages.

The vehicle-history chart `vhRegen` (cumulative regen-since-tracking-started) keeps showing the SDK monotonic series — that's still the right surface for the long-term trend; only the bucket totals needed the trip-log fix.

`get_regen_stats()` no longer returns `None` purely because the brand has no SDK regen reporting (Skoda/VW Group): if there are completed trips, the panel renders the trip-summed estimates. `first_sync` may be `None` in that case; the dashboard guards against rendering it.

## v2.28.57 (2026-04-27)

### Trip log — regen fallback now also kicks in on flat-zero measurements

User report after v2.28.56 deploy: ev-robert's morning commute (2026-04-27 06:48, km=18) still showed Recup 0.0 instead of the new estimate. The v2.28.56 fallback only triggered when the measured value was `None`; trips where `cum_arr - cum_dep` collapsed to exactly 0 (e.g. the departure-side sync snapped to the first sync AFTER drive start, so the delta vanished) bypassed it.

**Fix**: condition is now `regen is None OR regen == 0` (combined with `km > 0`). Any real drive with km ≥ 1 recuperates non-zero — a measured zero is broken-measurement-shaped, so we'd rather show the estimate. Same change in the SDK-only path.

### History tab removed from nav

Now that `/input` shows the full history table below the new-charge form, the standalone History tab is redundant. Nav link removed; the input link's `active` state extends to `endpoint == 'history'` so deep links to `/history` still highlight the right tab. The `/history` route itself stays for bookmarks.

## v2.28.56 (2026-04-27)

Four user-reported items from a single morning's friction:

### Trip log — recuperation falls back to configured rate when measurement is missing

User report: a trip on the Kia install rendered with empty Recup column even though it had a real km value. Same risk on the Hyundai install. Cause — the trip-row regen calculation depends on the difference between cumulative-regen sync rows at the trip's start and end timestamps. If smart-mode polling missed either window (overnight idle, manual mode, brand without regen reporting), the lookup returns None and the cell renders blank.

**Fix**: when the SDK-derived regen is unavailable, fall back to `km × Settings/Vehicle/Recuperation/recuperation_kwh_per_km` (default 0.086, user-editable). Marked with a small asterisk icon in the table so estimated values are visually distinguishable from measured ones — title attribute spells out the source. SDK-only trips (Skoda/VW Group, no regen telemetry) now also get the estimate instead of always-empty cells. Backfill is implicit: the change is in the read path, so every historical trip gets the fallback on the next render.

### Input — auto-fill "loaded %" while a charge is running

The kWh field already auto-evolves during an AC session (`elapsed_hours × max_ac_kw`). The "SoC bis" field didn't, so the user saw the kWh estimate climb while the SoC field stayed on the start value. Now SoC-to mirrors the same time-based estimate (`soc_from + kWh_estimate / battery_kwh × 100`, capped at 100 %), and the 10-min auto-poll pins it to the polled vehicle SoC for an accurate live value. Manual edits stick (dataset.manual flag like kWh).

### Input — intermediate save no longer drops field values

User report: filling all fields, clicking Speichern during an active session, and the next render came back with eur_per_kwh empty. Other fields could be affected too. Repro path is unclear — server stores the value but the round-trip occasionally lost it (browser autofill, validation reject, redirect race).

**Fix**: belt-and-suspenders cache. Every editable form field is mirrored to `localStorage.ev_charge_session.formCache` on every input event during the session. On page load, after pre_charge fills, any field that's still empty gets restored from the cache. Programmatic value changes (PV-radio price/CO2 prefill, operator price autofill, GPS button, timer) also hit the cache. Form gains `autocomplete="off"` to keep iOS Safari out of the way.

### History moves under New Charge

`/input` now renders the full history table (filters, bulk-action bar, paginated rows) below the new-charge form, Fahrtenbuch-style. `/history` keeps working as a standalone page — both routes share a `_history_section.html` partial. Removed the redundant "letzte Ladung" snippet from the input page since the table covers it.

## v2.28.55 (2026-04-25)

### Input — recover from "phantom charge" lockout

User report on the Skoda install: a charge session was stuck in the stopped-but-unsaved state. Both Start and Stop rendered greyed out and there was no obvious way out — only the small Cancel button at the right of Save would have wiped it.

Cause is the input page's session state machine: once `doStop()` runs (manual stop or auto-poll detecting `is_charging=false` with rising SoC), `localStorage.ev_charge_session.stopped` is set. On the next render `restoreSession()` disables both buttons. The user can still click Save (commit) or Cancel (discard), but on small viewports those weren't visible without scrolling, so the page looked frozen.

**Fix**: in the stopped state, leave Stop greyed but re-enable Start as a "discard & restart" recovery path. Clicking it prompts `Beendete Ladung verwerfen und neue starten?`, then wipes the session in localStorage, clears the form fields the previous session populated (SoC, odometer, kWh), resets the hidden charge_id so the next save creates a fresh row, and falls through to the normal start-with-retry flow. New translation key `input.discard_stopped_confirm` in all six languages.

The auto-stop heuristic (`is_charging=false` AND current SoC > start SoC) is unchanged for now — if the brief disconnects on the Skoda's CarConnectivity feed turn out to over-trigger it, we'll tighten that separately. The recovery path means a false trigger is no longer a hard lockout.

## v2.28.54 (2026-04-24)

### Fahrtenbuch — PE ``soc_arrived`` / ``soc_departed`` now match trip-row consumption

User report: in the Fahrtenbuch, trip consumption delta was correct but the per-PE start/end SoC shown in the edit modal was wrong — e.g. a 5 % drive rendered as "67 → 67 %" in the modal because ``soc_arrived`` kept the first post-drive sync's cached pre-drive SoC.

Root cause — the Kia/Hyundai cloud usually returns the new odometer + new GPS on the first post-drive sync but keeps echoing the pre-drive SoC for a few seconds to a few minutes, then sends a second "partial" sync (``gps_ts = None``) with the real post-drive SoC. The existing trust gate correctly rejects that partial sync for GPS/location purposes (to avoid coord echoes at origin), but the same gate silently blocked the SoC update too — so ``soc_arrived`` stayed on the echo. The trip row used ``_soc_min_in`` to bypass the echo on the fly; the stored field didn't.

Three fixes:

1. **New ``recompute_pe_soc(evt)`` helper** that derives ``soc_arrived`` / ``soc_departed`` from ``VehicleSync`` using the same logic the trip row already uses (``_soc_min_in`` over the first 30 min after arrival; ``_soc_before`` for departure). Called at every PE close (odo-advance, odo-jump split, distance-threshold move) so newly-closed PEs have correct values immediately.

2. **Arrival-echo correction at sync time.** Within the first 30 min of a PE's lifetime, any sync whose odometer matches the PE's (proof the car is parked there, not mid-drive) may pull ``soc_arrived`` DOWN regardless of ``gps_ts`` freshness. Catches the "second partial-fresh sync with real post-drive SoC" without weakening the GPS/location freshness gate.

3. **New repair endpoint** ``POST /api/trips/repair_soc``. One-shot maintenance that walks every PE and realigns stored SoC with ``VehicleSync``-derived values. Safe to run repeatedly; only writes on actual differences.

## v2.28.53 (2026-04-24)

### Hyundai Fahrtenbuch — stamp the newly opened PE, not the closing one

Observed on the Hyundai install: a short Home → nearby → favorite → other → Work chain rendered with every destination label shifted one PE upstream — nearby became favorite, favorite became other, other became Unknown, and all downstream arrivals were equally off by one. Hyundai had delivered one extra SDK trip (the 4-minute Home → nearby hop) but the GPS-side state machine was assigning each PE the *next* PE's coord.

Root cause: ``_stamp_closed_pe`` was built around Hyundai's 1-step-behind cache pattern — at odo-advance, write the freshly-arrived GPS onto the *closing* PE as its retroactive identity. That's correct when the fresh coord is an origin echo (cloud still returning the previous location for a few minutes after a move). When the cloud actually delivers the new destination coord promptly — which Hyundai does more often than we assumed — the same logic silently mis-assigns every label down the chain.

**Fix**: stamp the newly-opened PE with the fresh-GPS, not the just-closed one. The echo check stays, but its role flips: if the fresh coord matches the closing PE's coord (when labelled) or its most recent labelled predecessor (when Unknown), the stamp is skipped and the new PE opens Unknown — destination will be stamped later via the upgrade path once Hyundai catches up. No-match cases skip the upgrade-path wait and open a labelled PE directly.

Trade-off: the "close PE retroactively identifies its own location" pathway is gone, so when Hyundai stays stuck in echo mode for an entire short hop (origin coord both at arrival AND at the next departure), the PE stays Unknown instead of being guessed from the following odo-advance. Accepted because the previous behaviour silently shifted whole evenings of driving to the wrong destinations.

Existing wrongly-labelled PEs on the affected install were corrected in place via direct SQL — no replay, so manual edits on older PEs are preserved.

## v2.28.52 (2026-04-24)

### Report — donut chart labels in-place, trip-edit buttons wrap on narrow screens

**Report page**: the AC/DC/PV charge-type doughnut now writes each segment's label (AC/DC/PV) directly onto the arc with a contrasting outline, and the kWh total appears underneath the label when the arc is large enough (≥42 px arc length and ≥34 px thickness). Narrow segments show just the label; very thin segments fall back to the legend alone. Custom Chart.js plugin — no extra dependency.

**Trip-edit modal**: the new above-map pick buttons were getting clipped on narrow phone widths (≤340 px) because they stayed side-by-side. Switched to `flex-wrap` with a `160 px` minimum basis so they stack vertically on small viewports instead of being cut off, and added `white-space: normal` so long translations wrap inside the button rather than overflowing.

## v2.28.51 (2026-04-24)

### Fahrtenbuch edit modal — mobile-friendly layout

Three fixes for the trip-edit modal on small screens:

**1. Save button is now sticky** at the bottom of the modal, with an iOS safe-area inset so the button stays clickable even when the browser's own bottom chrome (address bar, gesture hint) overlays the page. Previously it was at the very end of a long-scrolling body and disappeared under the browser bar on short displays.

**2. Pick-on-map buttons are now prominent and full-label** instead of a tiny bullseye icon hidden in the card header. Each card's header shows a proper "Auf Karte wählen" button with sufficient tap-target height (≥38px). The card-header button stays as a secondary option.

**3. A dedicated pick-side button pair now sits directly above the map itself**, so when the user scrolls down to the map they can tap "Startpunkt auf Karte wählen" or "Zielpunkt auf Karte wählen" without scrolling all the way back up to the card header. Both button pairs (card headers + above-map) are visually synchronized — clicking either arms the map for that side and highlights the active state on both.

New translation keys in all six language files: ``trips.edit_pick_from_here``, ``trips.edit_pick_to_here``.

## v2.28.50 (2026-04-24)

### Intermediate save + start retry on vehicle communication failure

Two input-page robustness fixes observed in the field:

**1. Save no longer cancels an active charge session.** Previously, clicking Speichern while a charge was running cleared the session timer and the next page load started fresh — so mid-charge annotations (operator, location, price) required choosing between "save now and lose the timer" or "remember to come back and save later". Now a save performed during an active session is an *intermediate save*: the charge row is written (or updated, if saved once before in the same session), the session timer keeps running, the redirected page pre-fills every field from the saved row, and the Speichern button relabels to "Zwischenspeichern" with a "Ladung läuft" badge in the card header. The session only ends when the user clicks Stop. Backend tracks this via an optional ``charge_id`` form field — subsequent saves within the same session update the same row instead of creating duplicates.

**2. Start button now retries when the car is temporarily unreachable.** Both Kia and Hyundai cloud APIs regularly return transient errors immediately after the car has reported new state (the cloud is busy ingesting the update and locks the status endpoint for a few seconds to a few minutes). Clicking Laden during that window used to hard-fail with an alert. Now the click timestamp is stored as the charge start time up-front and a retry loop polls ``/api/vehicle/status?force=1`` every 30 s for up to 20 minutes. The button shows "Warte auf Fahrzeug… (Nm)". On eventual success the form fields are filled as normal and an alert confirms "Kommunikation wiederhergestellt — Ladung rückwirkend ab HH:MM gestartet" so the user knows the timer is anchored at the click moment, not the successful-fetch moment. After 20 min the loop gives up with a retry-manually message.

New translation keys in all six language files: ``input.save_intermediate``, ``input.active_session``, ``input.waiting_for_car``, ``input.started_retroactively``, ``input.retry_failed``, ``flash.charge_intermediate_saved``.

## v2.28.49 (2026-04-22)

### Hyundai Fahrtenbuch — teleport guards on the PE-upgrade path

Observed on 22.04: the morning 9 km commute rendered as ``Home → Home`` — a physically impossible teleport. Root cause: when the new PE opened Unknown at the odo-advance, a subsequent fresh-GPS sync echoed the origin coord (Home), and ``_upgrade_unknown`` naively stamped it without checking whether the car could plausibly have gotten there.

Two new guards on the upgrade path — both apply only when the open PE is Unknown:

1. **Teleport guard** — if the fresh-GPS coord matches the most recent labelled PE within ``SAME_PLACE_M`` AND the odometer advanced between them, the car cannot have returned to the spot it just left. Coord is a cache echo; reject the upgrade, stay Unknown.

2. **Same-odometer flip guard** — if an EARLIER fresh-GPS sync in this Unknown PE's own lifetime reported a different coord at the same odometer reading, two disagreeing fresh fixes without any movement mean at least one is an echo. Refuse to pick either one; stay Unknown.

Also tightened the 1-step-behind ``_stamp_closed_pe`` rule at the odo-advance: dropped the ``drive_km < 2`` discriminator that let longer same-coord stamps through as "legitimate round trips". The car can't teleport regardless of drive length — Unknown is better than a wrong guess.

Consequence: when Hyundai Bluelink fails to ever deliver a fresh-GPS for a drive's true destination, the destination renders as Unknown instead of whatever coord the cloud happens to echo. Two consecutive Unknowns for a day's commute are accepted as the cost of honesty.

## v2.28.48 (2026-04-22)

### Hyundai 1-step-behind: drive-distance discriminator instead of in-lifetime fresh check

v2.28.47's in-lifetime fresh-GPS check had a subtle bug: the sync that TRIGGERS the odo-advance of the following PE falls inside the newly-opened PE's window after SDK reconcile snaps ``arrived_at`` backwards (trip end) — so the opening sync's own fresh-GPS counted as in-lifetime confirmation, and the repeat-echo guard never actually fired. The result: PE#20 still got stamped as Ponytruppe on the Hyundai install.

Replaced the in-lifetime check with a much simpler discriminator: the odometer distance of the drive that triggered this odo-advance. A same-coord stamp candidate is skipped only when the preceding drive was shorter than 2 km (Hyundai's cache occasionally returns the previous coord a second time on in-area hops of a few hundred meters to a kilometre; legitimate same-coord round trips — overnight parking at Home with a real out-and-back during the day — are always longer). Picked from the Hyundai install's observed data: trip#137 at 1 km was the artefact, trip#138 at 9 km was the real round trip, so 2 km splits them cleanly.

Also removed the now-unused ``_has_in_lifetime_fresh_at`` helper.

## v2.28.47 (2026-04-22)

### Hyundai 1-step-behind: repeat-echo guard on retroactive stamping

v2.28.46's stamp rule always wrote the odo-advance sync's fresh-GPS coord onto the just-closed Unknown PE. That worked when Hyundai Bluelink served a different coord than last time, but when Hyundai returned the SAME coord twice in a row — a second-level echo where the cache still holds the previous location after the car has moved to yet another spot — the rule stamped PE#20 as Ponytruppe when it was actually Einkaufen, producing a nonsense ``Ponytruppe → Ponytruppe`` trip.

The stamp call now checks the previous labelled PE's coord. If the incoming fresh-GPS matches within ``SAME_PLACE_M`` and no in-lifetime fresh-GPS during THIS PE's life confirmed that coord, the stamp is skipped and the PE stays Unknown. Legit same-coord PEs (e.g. morning stay at Home after overnight stay at Home) are preserved because the in-lifetime fresh-GPS check confirms the car genuinely was at that spot, not just Hyundai re-serving the old cache.

Two new helpers in ``trips_service``: ``_previous_labelled_pe`` (finds the most recent non-Unknown PE before a given PE) and ``_has_in_lifetime_fresh_at`` (checks whether any ``VehicleSync`` row inside the PE's lifetime had a fresh-GPS fix at the candidate coord).

## v2.28.46 (2026-04-22)

### Hyundai 1-step-behind rule: stamp closed PE retroactively at odo-advance

Each Hyundai Bluelink sync's fresh-GPS represents the car's LAST KNOWN location — i.e. where the car was DURING the now-ending PE, not where it arrived after the current drive. Every previous PE-labelling strategy we tried was one step off: opening the new PE with the fresh-GPS coord labelled the drive's destination as the drive's origin. User's Fahrtenbuch read like ``Home → Work → Ponytruppe → Ponytruppe → Unknown → Home`` instead of the actually-driven ``Home → Unknown → Ponytruppe → Einkaufen → Home``.

The odo-advance block now treats the arriving fresh-GPS as the *retroactive* identity of the just-closing Unknown PE: ``_stamp_closed_pe`` writes the fresh coord/label/favorite onto the closed PE. The new PE always opens as Unknown — its real destination will be stamped at the NEXT odo-advance (when the next sync's fresh-GPS becomes THIS PE's retroactive identity) or in-place via ``_upgrade_unknown`` if the car sits parked with subsequent fresh-GPS syncs. Applies only to Hyundai.

The v2.28.44 echo-distance heuristic (< 80 m → Unknown) is subsumed by this: under the new rule the new PE is always Unknown regardless of coord match, so the echo check is redundant and removed.

## v2.28.45 (2026-04-22)

### Hyundai silence degradation: skip when odometer is stable

v2.28.43's silence degradation masked the origin label of a trip when the origin PE had no fresh-GPS contact for > 60 min before departure. This over-triggered when the car sat parked at a labelled spot for hours — odometer was demonstrably constant during the PE lifetime (car didn't move) but the label still got replaced with Unknown at render time. Today's example on the Hyundai install: 17:41 Home → Work rendered as "unknown → Work" because PE#22 (Home) had its last fresh GPS fix at 08:30 while the actual departure was at 17:41, 9 h of silence — but ``odometer_arrived == odometer_departed == 50792`` proved the car never moved.

The silence degradation now checks odometer stability first: if ``odometer_arrived == odometer_departed`` on the origin PE, the car provably didn't leave, so the label stays. Otherwise (e.g. the car moved but we never got a fresh coord for the new spot), the Unknown mask still applies.

## v2.28.44 (2026-04-22)

### Hyundai: detect departure-echo fresh GPS at odo-advance

Hyundai Bluelink has a subtle pattern observed across every install's history: when the car leaves a spot, the server keeps echoing the just-departed coord with a fabricated-fresh ``gps_ts`` for a while. The odometer already reflects the completed drive, so our state machine saw ``odo-advance + fresh-GPS at spot-X`` and opened a new PE at spot-X — but the car had actually LEFT spot-X and was somewhere else. The "arrival" we were reading was in reality the past departure from that spot.

The odo-advance branch now compares the purportedly-fresh GPS coord against the just-closed PE's coord. If the distance is within ``SAME_PLACE_M`` (80 m), the fresh fix is treated as a departure echo and the successor PE opens as Unknown instead. The existing ``_upgrade_unknown`` path then handles the real arrival: when a later fresh-GPS sync lands with a *different* coord (the actual destination), it stamps coords + label in place on the Unknown PE. Kia is unaffected (Hyundai-only brand gate).

In Fahrtenbuch: a 17:41 Home → Home (9 km) rendering on the Hyundai install today — the classic same-spot-echo artefact after a Home → Work drive whose arrival GPS hadn't caught up yet — now resolves to Home → Work as soon as sync #72 delivers the real Work coord. Overnight same-spot echoes (``Ponytruppe → Ponytruppe`` 1 km, the shopping-round-trip artefact from yesterday) similarly resolve to ``Ponytruppe → Unknown``, honestly reflecting that we don't actually know the shopping destination.

## v2.28.43 (2026-04-22)

### Hyundai Fahrtenbuch: trip origin degrades to Unknown after long GPS silence

When a Hyundai PE was open for hours without a fresh-GPS confirmation — the ``last_seen_at`` stayed frozen at the last legitimate fix while every subsequent Bluelink read echoed the cached coord with a stale ``gps_ts`` — the trip origin still rendered with the stored label (e.g. "Ponytruppe → Home" after a 12 h overnight parking spell). The label reflected what the car was at *last confirmed GPS contact*, not necessarily where it was at drive start. Per the user's rule "without a fresh GPS lock, render origin as Unknown".

``get_trips`` now measures the silence window ``departed_at − last_seen_at`` and, for ``brand == 'hyundai'`` only, masks the origin's label / name / coords to Unknown when the silence exceeds 60 min. Timestamps and the km/SoC/regen figures are unchanged — only the rendered origin label degrades. Kia is not affected: UVO updates its GPS on every cached read, so ``last_seen_at`` stays current and the silence window is always small.

## v2.28.42 (2026-04-22)

### Fix: VAG ``is_charging`` was permanently stuck at True (substring bug)

``connector_vag.py`` decided whether the car was charging with ``'CHARGING' in str(ch.state.value).upper()``. The carconnectivity ``ch.state.value`` is an ``EnumAttribute``-wrapped enum member, not a plain string; ``str(ChargingState.OFF)`` renders as ``'ChargingState.OFF'``, and ``'CHARGING'`` is a substring of ``'CHARGINGSTATE'``. Every Skoda/VW/SEAT/Cupra/Audi sync whose ``charging`` object existed at all was stored with ``is_charging = 1`` regardless of actual state — the dashboard on the Skoda install showed "lädt" while the car sat parked with ``charging.state = 'off'`` and ``charging.power = 0.0 kW``.

The check now reads the enum's underlying string via ``state.value.value`` and compares exactly to ``'charging'``. When the state field is missing or unknown the code falls back to ``charge_power > 0.1`` — power flowing is ground truth. Applied to every existing VAG sync on deploy so the dashboard reflects reality without waiting for the next poll.

## v2.28.41 (2026-04-22)

### History: per-page selector (50/100/200/All)

The ``/history`` filter row gained a per-page dropdown with fixed choices 50, 100, 200 and All. Changing it auto-submits the form so the new page size takes effect immediately. ``all`` is handled server-side by sizing the paginator to ``max(total, 1)``, so the standard ``has_prev``/``has_next``/``iter_pages`` machinery keeps working without a special code path. The selection flows through the same ``history_url`` macro as the other filters, so it rides along with every pagination link and stays in effect while the user moves between pages.

## v2.28.40 (2026-04-22)

### History: filter-preserving pagination + multi-select bulk type change

Pagination links on ``/history`` now carry the current filter through a single ``history_url`` Jinja macro that URL-encodes values and skips empty ones, instead of the old inline ``?page=N&type={{charge_type}}&year={{year}}`` concat (which on some edge cases left filter params in a shape the dropdown re-render logic didn't recognise). One source of truth for pagination URLs means every link — prev, next, numbered pages — stays on the same filter.

Every row now has a checkbox plus a header "select all", and a bulk-action bar appears above the table once at least one row is selected: pick a target charge type (AC / DC / PV) and hit Apply to change every selected row in one call. Typical case: reclassify a batch of miscategorized AC rows to PV.

New endpoint ``POST /api/charges/bulk_type`` accepts ``{ids: [...], charge_type: "PV"}``. CO2 adjusts at the PV boundary: switching to PV overwrites ``co2_g_per_kwh`` with the configured PV intensity from the Anlagen-Settings (``_get_pv_co2``); switching away from PV clears ``co2_g_per_kwh`` so the ENTSO-E backfill loop refills it with the correct grid value for the charge's date/hour. AC↔DC transitions leave CO2 unchanged (both already use grid intensity). The backfill starts automatically when any row was cleared.

## v2.28.39 (2026-04-22)

### Dashboard: hide tiles the brand connector doesn't populate

Skoda (and the rest of the VAG connector family — VW/SEAT/Cupra/Audi) only exposes SoC, odometer, charging state, charge power and estimated range. Every other dashboard tile — 12 V battery, climate, AC/DC charge limits, charge-ETA, SoH, regenerated kWh, doors, tires, 30-day consumption, portable charger, location — was previously rendered with a permanent ``—`` placeholder for these brands because the template had no brand-awareness.

The dashboard's vehicle-live-status card now consults ``services.vehicle.feature_matrix.get_features(brand)`` and wraps each optional tile in ``{% if vehicle_features.get('key') != 'no' %}``, so tiles for fields the connector doesn't populate are not rendered at all. The three fixed ``.row``s became a single wrapping row — hidden tiles no longer leave empty row remnants. Mandatory tiles (SoC, range, odometer, status, registration date) are always shown. The feature matrix gained three new keys (``charge_limits``, ``charge_eta``, ``portable_charge``) so the Bluelink/UVO-specific tiles can be gated precisely; ``get_features`` now merges with a defaults dict so brands whose entry predates a new key report the new feature as unsupported by default. JS renderer uses safe ``setText`` / ``setHtml`` wrappers that no-op when the tile was gated out, so the same render code works for every brand.

## v2.28.38 (2026-04-22)

### iOS Safari CSV picker: overlay the input on the button, drop ``d-none``

v2.28.37 moved the file input inside a ``<label>`` button and hid the input with Bootstrap's ``d-none`` (``display: none !important``). iOS Safari has a long-standing quirk: a ``<input type="file">`` that is ``display: none`` doesn't open the native picker even when its associated label is tapped — the tap highlights the button (field turns gray) and then nothing happens. The reliable fix is to keep the input in the layout but transparent. The input now sits inside the label as a ``position-absolute``, ``opacity:0`` overlay filling the whole button, so the tap lands directly on the file input itself.

## v2.28.37 (2026-04-22)

### CSV import on mobile + hide export buttons on empty DB

Two fixes to the Settings → Database card and related export entry points.

**Mobile CSV picker didn't open.** The ``<input type="file" class="form-control form-control-sm">`` inside a form didn't reliably launch the native file picker on iOS Safari (the small-sized Bootstrap control renders the tap target inconsistently) and ``accept=".csv"`` alone is too restrictive — iOS filters by MIME type and grays out the Files picker when only an extension is specified. The input is now visually wrapped in a ``<label class="btn btn-outline-secondary">`` button, with the actual ``<input type="file">`` hidden via ``d-none``. The whole button becomes the tap target, which iOS handles consistently. The ``accept`` attribute was broadened to ``.csv,text/csv,text/plain,application/csv,application/vnd.ms-excel``. A tiny JS listener reflects the chosen filename in the label.

**Export on empty DB.** Both the Settings "CSV Export" button and History's "CSV Export" link returned a valid but near-empty CSV (just the header row); the Report's "PDF Export" redirected to ``/report`` with a flash error when there was nothing to export. On a freshly-installed instance this looked like a broken button. The three export buttons are now gated server-side by the relevant data check — ``total_charges > 0`` for Settings, ``charges.total > 0`` for History, ``has_any_data`` for Report — so the entry point disappears while there is nothing to export.

Added ``set.db_import_choose_file`` translation key to all six language files (de/en/es/fr/it/nl).

## v2.28.36 (2026-04-21)

### Hyundai: odometer-advance + Unknown PE placeholder

Hyundai Bluelink's cloud keeps serving a cached origin-GPS fix with an hours-old ``gps_ts`` long after the car has driven somewhere. The odometer update lands first, GPS catches up later. The PE state machine's top-level stale-GPS gate was bailing on exactly this sync, and the same-place odo-jump split (v2.28.33) was never reached because its own ``gps_fresh`` precondition excluded that path. Result: the morning round trip's ``departed_at`` on the origin PE was never set from the sync stream — Fahrtenbuch relied on the nightly SDK reconcile and nothing during the day.

The state machine now promotes odometer-advance to a top-level check that runs before the stale-GPS gate. When an open PE's ``last_odo + 1 km`` is met, the PE closes at its ``last_seen_at`` and a successor PE opens: at the sync's real coords if the sync has fresh GPS, otherwise as an "Unknown" placeholder PE (sentinel lat/lon ``0.0``, label ``'unknown'``). Should a fresh GPS fix arrive while the Unknown PE is still open, the coords and label are stamped onto the existing PE in-place (``_upgrade_unknown``) — no new PE is created, ``arrived_at`` stays at the odo-advance moment. Same-odo syncs on an Unknown PE still extend ``last_seen_at`` / ``soc_departed`` so the next drive's departure time reflects the actual leave moment, not when the PE opened. Gated to ``brand == 'hyundai'`` — Kia pushes fresh GPS with every update and never hits this data shape.

Why not just anchor the successor PE at the stale-GPS cache-echo coords? Because the echo often still points at the origin while the car is actually somewhere else, producing phantom ``Home → Home`` round trips when the real trip was ``Home → Unknown → Work``. The Unknown label is an honest "we don't know yet" that SDK reconcile can time-snap without lying about location.

``_is_fresh_gps`` is strict: a missing ``location_last_updated_at`` is treated as not-fresh. Secondary Hyundai cache-echo syncs (the same cached coord re-served a minute after a stale-gps-ts primary) come back with no ts at all, so trusting them would re-introduce the echo-upgrade bug.

UI: the ``/trips`` map marker feed and ``/api/trips/export.gpx`` now drop ``label == 'unknown'`` entries (no ``0, 0`` pin in the Atlantic). Nominatim reverse geocode queue also skips them. Fahrtenbuch text row already rendered ``trips.unknown_location`` via the existing template branch; the translation key was present in de/en and has been added to es/fr/it/nl.

## v2.28.34 (2026-04-21)

### Endpoint inference walks the full PE timeline, not the since-filtered slice

`get_trips(since=…)` filters its `events` list to PEs that arrived within the since window. The v2.28.30 endpoint inference walked that same filtered list, which meant a PE that opened BEFORE the window but still covered an SDK trip's timestamp was invisible — rendering the trip as `unknown → other` instead of the correct `home → other`. The inference now loads the full PE timeline from the DB when `since` is set, using the filtered `events` otherwise.

## v2.28.33 (2026-04-21)

### Three tightenings of the PE state machine around `last_seen_at`

**(A) Regen lookup no longer reads `last_seen_at`.** The departure-side regen lookup in `get_trips` used `prev.departed_at or prev.last_seen_at`. The surrounding pair-iteration loop already skips pairs where `prev.departed_at is None`, so the fallback branch was never actually reached — dead code. Removed to make it explicit that Fahrtenbuch arithmetic never touches `last_seen_at`.

**(B) State-machine close path uses `sync.timestamp`, not `last_seen_at`.** Previously a detected move closed the current PE with `departed_at = last_seen_at or sync.timestamp`. Under the Hyundai cache-echo pattern (same-place updates from a sync whose GPS timestamp had been advanced past the real leave-moment), `last_seen_at` could poison the departure time. Kia/Hyundai trip reconcile immediately snaps this to `sdk.start_time` anyway; for brands without tripinfo, the first-at-new-location sync timestamp is a safer single-source anchor (slightly overestimates drive time rather than silently using possibly-corrupted data).

**(C) Odometer-jump PE split.** When a fresh-GPS sync lands on the same spot as the open PE but `odometer_km` has advanced ≥ 1 km since the last at-spot reading, the car took an invisible round trip (left and returned before any move could be observed — e.g. the Hyundai install 19.04. PE#10 where `odometer_arrived=50648` / `odometer_departed=50663` collapsed a 15-km round trip into a single "Home" entry). The state machine now closes the current PE at its prior `last_seen_at` / `arrived_at` and opens a fresh one at the same coord. The gap between the two PEs becomes a visible slot that the SDK trip reconciler can bind a matching trip to, and the Fahrtenbuch endpoint inference (v2.28.30) surfaces it as a `Home → Home` loop with correct km. Queues a post-move reconcile immediately.

## v2.28.32 (2026-04-21)

### Retroactive GPS backfill from delayed-fix syncs

Hyundai Bluelink (and occasionally Kia UVO) ships cached GPS fixes whose `location_last_updated_at` is minutes or hours BEFORE the sync's own timestamp — the cloud's last good position, replayed on the next poll after a sleep window. Earlier syncs during that sleep window often have `location_lat = NULL` because the cloud didn't have fresh GPS at the time.

`_save_vehicle_sync` now retroactively stamps the incoming fix onto any earlier VehicleSync row within ± 5 min of the fix's `location_last_updated_at` whose own `location_lat` is NULL. Tight window prevents attributing a stationary fix to in-flight drive moments. Fahrtenbuch's endpoint-inference (v2.28.30) then surfaces the filled-in position automatically.

## v2.28.31 (2026-04-21)

### Remove /trips page auto-force-refresh (stop draining 12 V on every visit)

The `/trips` route used to kick off a background `get_status(force=True)` whenever the last GPS sync was > 2 h old. With the user opening Fahrtenbuch repeatedly from the phone during the day, each visit that passed the 5-min debounce turned into a car wakeup and a 12 V aux battery hit — five wakeups on the Kia install today alone (log source `trips-auto`). Fahrtenbuch is a history view; fresh GPS isn't needed to render it.

The background sync loop (smart mode) already wakes the car at most once per `smart_force_max_hours` window (default 6 h) and on explicit state transitions (motion detected). The manual "Jetzt synchronisieren" button is unchanged for on-demand pulls.

## v2.28.30 (2026-04-21)

### SDK-only trips infer endpoints from surrounding PE context

When an SDK trip has no matching PE pair (typical Hyundai Bluelink morning: GPS unavailable across the commute), the Fahrtenbuch used to render both endpoints as `unknown → unknown`. We now walk the PE timeline around `sdk.start_time` / `sdk.end_time`:

- The PE whose `[arrived_at, departed_at or now]` window contains the trip start → origin.
- The PE whose window contains the trip end, or the first PE opened after it → destination.

If both resolve to the same PE (round trip that left and returned before any new PE was opened), origin = destination = that PE's label — e.g. `Home → Home` instead of `unknown → unknown`. Later arriving GPS data (car reaches a new location, opening a new PE) automatically surfaces as the destination of earlier unattached SDK trips without any migration or re-reconcile. Falls back to the old `unknown` rendering only when no PE covers the trip's time window at all.

Trip row gains an `inferred_endpoints` flag the UI can use to distinguish PE-anchored rows from inferred ones.

## v2.28.29 (2026-04-21)

### Charging gate now also covers CLI / SSH deploys

v2.28.28 gated the HTTP endpoint `/api/update/install` against mid-charge rollout. Dev-side SSH/CLI calls that invoke `apply_update()` directly (bypassing the endpoint) still went through. `apply_update(zip_url, new_version, force=False)` now performs the same check itself by reading the latest `vehicle_sync.is_charging` row from SQLite directly — no Flask app context required. Caller passes `force=True` to bypass (emergency path). The HTTP endpoint keeps its own gate + UI override and passes `force=True` down because it's already authorised by that point.

### `/live-logs` highlights direct-to-vehicle fetches

Kia UVO / Hyundai Bluelink force-refresh (`force_refresh_vehicle_state`) **wakes the telematics unit** and drains the 12 V aux battery. Cached polls don't touch the car. The connector now emits a WARNING-level log line every time a force refresh runs — the `/live-logs` page styles WARNING prominently so it's immediately obvious which syncs cost battery energy.

## v2.28.28 (2026-04-21)

### Update install refuses while the vehicle is charging

Applying an update restarts the Flask app (and the background sync loop) for a few seconds. If that happens mid-charge, the automatic charge-end detection can miss the transition. `/api/update/install` now checks the latest `VehicleSync.is_charging` and responds `409 vehicle_charging` when active. The settings-page updater button surfaces the message and exposes a "Trotzdem installieren" button that re-submits with `?force=1` to bypass the gate.

## v2.28.27 (2026-04-21)

### PE same-place updates: trust only freshly-timestamped GPS

Observed on the Kia install (Kia): the first sync after the overnight smart-window re-opens sometimes carries `gps_ts=None` with the **origin's GPS** (home coords) while the car has already started the morning commute. Because the coords match the open Home PE, the same-place path happily overwrote `soc_departed` with the mid-drive SoC reading (50 % → 45 %, where 50 % was the true pre-drive value and 45 % the in-progress drive value). The Fahrtenbuch then showed the trip as "left Home at 45 %", which is just the Work-arrival SoC bleeding backward.

The odometer is unchanged across these echo syncs (origin's cached odo), so they can't be distinguished by coord alone — but the missing `gps_ts` is the tell. v2.28.27 gates the same-place update on `location_last_updated_at` being present AND within the 30-min staleness window. If not: the function returns the open PE unchanged, skipping the `soc_departed` / `odometer_departed` / `last_seen_at` writes. Missing-ts syncs are still written to the VehicleSync table (so regen / SoC lookups can find them), just not allowed to rewrite PE state.

## v2.28.26 (2026-04-21)

### PE state machine: reject GPS moves when odometer hasn't advanced (Hyundai cache-echo fix)

Observed on the Hyundai install (Hyundai Bluelink): cloud occasionally serves a stale GPS reading with a deceptively fresh timestamp (4 min old, below the 30-min staleness gate) that points at an earlier location (e.g. the morning's Work coord after the car has long since been Home). The PE state machine would interpret this as a real move — closing the current Home PE and opening a phantom Work PE — even though the car never physically moved. Once reconcile ran, the phantom PE paired with the next morning's genuine Home sync to render as a bizarre multi-hour `work → home` "trip".

Ground truth is the odometer. Every legitimate move must advance it. `update_parking_from_sync` now requires `sync.odometer_km` to differ from the open PE's last-known odometer (`odometer_departed or odometer_arrived`) by ≥ 1 km before accepting the GPS-based move; otherwise it ignores the sync and keeps the current PE intact. No impact on Kia — its cache echoes haven't shown this pattern; the guard is just a belt-and-suspenders check.

## v2.28.25 (2026-04-21)

### Widen reconcile arrival-tolerance from 20 min to 4 h (fixes Hyundai 14-hour phantom trips)

When Hyundai Bluelink stops returning GPS for a sleeping car, our PE state machine correctly ignores those syncs — but the car then gets detected at B only on the next GPS-bearing poll, which can be many hours after the physical arrival. Result: a PE pair whose `arrived_at` was 2 h+ later than the SDK-reported trip end. The old 20-min reconcile tolerance couldn't match that, so the trip double-rendered as:

- A polled PE pair with grossly wrong timestamps (e.g. `17:03 yesterday → 10:39 today`, 14 h for 9 km).
- A duplicate SDK-only row with correct times but no location.

Tolerance is now 240 min. The physical conflict check (`sdk.start_time ∈ (prev.arrived_at, curr.arrived_at]`) plus the km-matching guard keep cross-pairing from happening; the greedy allocator scores by closest time-delta so the right SDK trip still wins when multiple fall in the window.

## v2.28.24 (2026-04-21)

### Skoda (and all VAG brands): fix `'Drives' object is not subscriptable`

`carconnectivity >= 0.11` changed `vehicle.drives` from a subscriptable list to a `Drives` container object whose payload lives in `.drives: Dict[str, GenericDrive]`. Our connector still did `vehicle.drives[0]`, which raised `'Drives' object is not subscriptable` and turned every Skoda/VW/Seat/Cupra/Audi status call into a settings-page error banner.

`connector_vag.get_status()` now pulls `vehicle.drives.drives`, prefers the drive whose `type.value` ends in `ELECTRIC` (matters for hybrids), and falls back to the first drive otherwise.

### Silence CarConnectivity MQTT push-channel noise

The Skoda/VW/Seat/Cupra/Audi MQTT connectors log `Could not connect (Not authorized)` at ERROR level every ~2 s when the MQTT broker rejects the push token. We poll via HTTPS and don't rely on MQTT push, so the failure doesn't affect data — but the spam flooded the `/live-logs` page. All four brand-MQTT loggers are now pinned to CRITICAL in `app.py`.

## v2.28.23 (2026-04-21)

### Two Fahrtenbuch-correctness fixes (Kia + Hyundai)

**1) Regen correctly anchors on SDK-reconciled departure.**
The v2.28.22 fix handled the arrival side but regen still read zero whenever the first post-drive sync hit `prev.last_seen_at` with fresh cumulative counters and stale GPS — both brands ship those transitional syncs where position says "still at home" but odo/regen already reflect the finished drive. Departure lookup now prefers `prev.departed_at` (which the reconciler snaps to the real SDK drive-start) and always uses `strict=True`, so the regen reading is always a sync strictly BEFORE the drive — never the ambiguous transitional one.

**2) Trip reconcile no longer waits for 03:00.**
New `request_post_move_reconcile()` flag in sync_service. The PE state machine sets it the moment a new parking event is opened (car arrived somewhere new). The sync loop picks the flag up within ~10 s, runs a one-shot `backfill(days=1)` (which internally reconciles the day), and clears it. Before this patch the just-ended trip would show its pre-reconcile state — often a 19-second "trip" at 07:05:19 → 07:05:38 if the force-refresh burst pulled departure and arrival in the same window — until the 03:00 nightly task realigned it. Now departed_at/arrived_at snap to the SDK timestamps minutes after the drive, not hours.

## v2.28.22 (2026-04-21)

### Fix: regen values collapsed to 0 after v2.28.20 arrived_at snap

v2.28.20 moved `curr.arrived_at` EARLIER (to the SDK-derived physical arrival moment, typically 3–7 min before the first at-destination sync). `trips_service._cum_regen_at(lookup, arrived_at)` still used `bisect_right - 1`, which now landed on the last PRE-drive sync — the car was still at origin, so `cum_regen` at that point equaled `cum_regen` at departure, and the diff was zero. Every reconciled trip's regen dropped to `0.00 kWh` overnight.

Fix: new helper `_cum_regen_at_or_after(lookup, ts)` picks the first sync at-or-after `arrived_at` (i.e. the first at-destination regen reading). Departure side unchanged — `prev.last_seen_at` is still a real poll timestamp, not touched by reconcile. Affects Kia UVO and Hyundai Bluelink trips (anywhere reconcile runs).

## v2.28.21 (2026-04-20)

### Log daily reconcile: include arr_applied counter

v2.28.20 added arrival-timestamp correction but the daily-loop log line still only reported the `departed_at` counter. Now emits `dep=N arr=M conflicts=K` so the new counter is visible in journal logs.

## v2.28.20 (2026-04-20)

### Reconcile arrival timestamps from SDK trip data (Kia + Hyundai)

Until now, `ParkingEvent.arrived_at` was the timestamp of the first at-destination poll — up to ~10 minutes after the car actually stopped (sync cadence in smart mode). Only `departed_at` was being snapped to the SDK start-time; the PE arrival kept the poll-lag error, so Fahrtenbuch drive durations looked a few minutes too long.

SDK `day_trip_info` has minute-accurate `start_time + drive_minutes + idle_minutes` per trip, which gives the real end-of-drive timestamp. `services/trip_reconcile.py` now additionally sets:

```
curr.arrived_at = sdk.start_time + drive + idle
```

Guarded by `new_arr < old_arr`: first-parked-sync is by definition at-or-after the physical arrival, so we only ever shift EARLIER — never later (that would be spurious clock noise). Same logic and tolerance window (`±20 min`) as the existing `departed_at` correction; runs for both Kia UVO and Hyundai Bluelink since both brands ship the endpoint.

Summary dict gains `arr_applied` / `total_arr_applied`; log line now reports both counters (`N departed_at + M arrived_at corrected`).

## v2.28.19 (2026-04-20)

### Fahrtenbuch table: drop redundant edit-button column (iPhone 17 Air fits without scrollbar again)

User report with screenshot: on iPhone 17 Air (~400 px viewport) the Fahrtenbuch table overflowed the screen — the right-most edit-button column got cut off and `table-responsive` showed a horizontal scrollbar.

Fix: removed the edit-button column entirely. The button was redundant — Von/Nach cells already had `role="button"` plus an identical `openTripEditor(fid, tid)` binding, i.e. they triggered the exact same modal. 6 columns instead of 7 → table fits without horizontal scroll.

## v2.28.18 (2026-04-20)

### Background maintenance for long-form geocode cache entries

v2.28.17 introduced the short-address format, but the bulk post-deploy migration (44 PE on the Kia install, 16 on the Hyundai install) triggered a Nominatim 429 rate-limit block — three hosts in parallel bursts hammered past the 1 req/s policy. Individual hosts retrying afterwards inherited the same block for hours.

v2.28.18 shifts the migration into a background thread so it can never spike:

- New thread `geocode-maintenance` starts inside `create_app()` alongside the vehicle-sync thread.
- **Idle**: no legacy entries (`raw_json IS NULL`) in the cache → 10 min sleep, next probe.
- **Pending**: rebuild *one* row, 2 s sleep, next row. Fixed-slow — Nominatim can't be overloaded.
- **Nominatim error** (e.g. the initial 429 block): 60 s backoff, retry. Self-heals when the block lifts.
- After each successful rebuild, cascades the new short address onto every `ParkingEvent.address` whose rounded coords match — no manual `geocode_missing_events` pass needed.

The remaining ~10 legacy entries per host trickle through in 20–30 min without further user action. Future-proof: any transient Nominatim failure (timeout → `raw_json IS NULL` stays) gets retried on the next wake-up.

## v2.28.17 (2026-04-20)

### Short, readable addresses in Fahrtenbuch (POI / street / postcode / city)

Until now the geocoding cache stored Nominatim's verbose `display_name` (`"1, Street, Suburb, City, State, Postcode, Country"`). On /trips that column ate most of the width and the at-a-glance "where was that?" failed.

### Short format

`services/geocode_service._format_short()` parses Nominatim's structured `address` object and builds:

- **POI** (shop / amenity / leisure / tourism): `"Lidl, 12345 City"`, `"IKEA, 12345 City"`, `"Kirche St. Anna, 12345 City"`
- **Street**: `"Hauptstraße 42, 12345 City"`
- **Fallback**: `"12345 City"` when nothing more specific is known.

The full Nominatim response now persists in a new `geocode_cache.raw_json` column — the short format can be re-derived any time from the raw data without another API call (rate-limited to 1 req/s anyway).

### Favorites / home / work preserved

The short format only replaces `ParkingEvent.address`. The `label` field (`home` / `work` / `favorite` / `other`) and `favorite_name` are untouched — the UI still renders favorites with their user-assigned name; the address only falls back in for `label == 'other'`.

### Migration

`rebuild_legacy_entries()` re-fetches every cache row without `raw_json` once via Nominatim (rate-limited). Then `PE.address` gets cleared and `geocode_missing_events()` runs — that copies the now-short addresses out of the freshly filled cache into the PE rows, without another API call. One-shot after deploy across all three hosts.

## v2.28.16 (2026-04-20)

### Hide phantom trips from the driving log

v2.28.15 made phantom trips visually identifiable (0 km + no SDK stats). User's follow-up: "phantom fahrten gleich entfernen, die braucht keiner." Done.

`get_trips` now drops any PE pair that has **both** `km ∈ {0, None}` **and** no matching SDK trip. A real drive always either moves the odometer or produces a `/tripinfo` record (usually both) — anything satisfying neither is GPS-jitter noise: the car briefly appearing at a distant spot for a handful of seconds, then going back where it actually was. The underlying `ParkingEvent` rows stay in the database (useful for diagnostics and for any future reconcile heuristics that want to fix rather than hide); only the `/trips` rendering filters them out.

Also: `pe_covered_dates` now gets filled *after* the phantom filter, so days where the only PE pair was a phantom cleanly fall through to the SDK-only fallback path — rare, but keeps the driving log honest on "polling missed everything, only SDK trips exist" days.

Read-only — no DB migration, no replay.

## v2.28.15 (2026-04-20)

### SDK-stats dedup + reconcile conflict-check refactor

Two related bugs surfaced on the Hyundai install: a phantom Home→Work PE pair (GPS-jitter "trip" of 0 km right after a real Work→Home drive) was inheriting the *real* drive's SDK stats (drive_minutes / idle_minutes / avg_speed / max_speed all identical to the line above). Looked like a duplicate entry.

### Bug 1 — `_find_sdk_stats` had no dedup, 60-min tolerance

```text
PE1 Work→Home  depart 16:23  → SDK trip X (drive 29, idle 11, max 83)
PE2 Home→Work  depart 16:53  → SDK trip X (same!)
```

Both pairs' `departed_at` were within the old 60-min tolerance of the same SDK trip's start, and `_find_sdk_stats` took the closest for *each* pair independently. Two PE pairs, one SDK trip, stats duplicated on both.

**Fix**: tightened tolerance to ±20 min (consistent with `trip_reconcile`), and `_find_sdk_stats` now accepts an `exclude_ids` set. `get_trips` maintains a `used_sdk_ids` set as it iterates, so each SDK trip binds to at most one PE pair. After v2.28.12 reconcile, real pairs have `prev.departed_at == sdk.start_time` exactly — delta 0, so they always outscore any phantom competitor. Phantoms now render with no stats attached, making them easy to spot.

### Bug 2 — reconcile greedy-allocator burned SDK on conflicted matches

While investigating, found a latent issue in `trip_reconcile.reconcile_day`: the greedy allocator marked `(pair, sdk)` as "used" before checking adjacency conflicts. If the best-delta candidate conflicted (e.g. the phantom pair won the score sort because its `curr.arrived_at ≈ sdk.end_time` was tighter, but applying `new_dep = sdk.start_time` violated `new_dep >= prev.arrived_at`), the SDK got marked used but never applied — and the valid alternative pair couldn't claim it on its next iteration.

**Fix**: moved the conflict check *inside* the greedy allocator, before `used_sdk.add(si)`. Rejected candidates now leave the SDK / pair slots open for the next-best match.

### Rollout

- `services/trips_service.py` — tolerance tightened, `exclude_ids` plumbed through, `used_sdk_ids` in `get_trips`.
- `services/trip_reconcile.py` — conflict check relocated; apply loop simplified (no longer re-checks).
- Both changes read-only in data terms; rerun `reconcile_range(days=30)` on hosts so existing PE pairs that were previously blocked by the greedy-allocator bug get their `departed_at` corrected.

## v2.28.14 (2026-04-20)

### Fahrtenbuch trip-end SoC — ignore cache-echo on arrival

v2.28.13 fixed the start-SoC side. Debugging the remaining "0 % consumption" trips on the Kia install (Kia) surfaced a mirror-image bug at the *other* end. Example: PE#28→#29 on 2026-04-16, 30 km drive, start SoC 51 %. The first at-destination sync (15:39:22) reported SoC = **51 %** — identical to the pre-drive value. The next sync (15:48, 9 min later) reported SoC = **43 %**. That's the real trip end. 51 − 43 = 8 % consumption (≈ 2.7 %/10 km, plausible for an e-GMP 64 kWh battery).

### Cache-echo at arrival

Both Kia UVO and Hyundai Bluelink sometimes upload fresh GPS / odometer but lag on SoC: the first sync at the destination carries the SoC value the ECU held *before* the drive, the true post-drive SoC lands a few minutes later. Taking `curr.soc_arrived` at face value on those trips produces `start_soc == end_soc` → `soc_used = 0`.

### Fix

Trip-end SoC now reads `min(soc) in [curr.arrived_at, curr.arrived_at + 30 min]` via a new helper `_soc_min_in()`. If any sync in that window has a lower SoC than the arrival echo, it's the real value. Safe under destination charging: charging only raises SoC, so the minimum window stays below the eventual at-destination SoC — but *is* the real trip-end. Fallback to `curr.soc_arrived` if the window is empty (edge case only).

Combined with v2.28.13 (start-SoC from VehicleSync), the driving log now reports realistic consumption on both brands regardless of cache-echo quirks at either end of the trip. Read-only — no DB migration, no PE replay.

## v2.28.13 (2026-04-20)

### Fahrtenbuch SoC — read from VehicleSync, not from PE.soc_departed

Follow-up to v2.28.11/v2.28.12: one more blind spot became visible once the timestamps were correct. The `soc_used` column in the driving log was showing 0 % for trips that obviously consumed energy. Example: park at home Fri 34 %, PV-charge to 100 % over the weekend, drive out Sun with 100 %, arrive 85 %. Expected: 15 % used. Shown: 0 %.

Root cause: `PE.soc_departed` only advances when `update_parking_from_sync` decides the sync is an at-spot sync. Since v2.28.11 the staleness filter discards cached-echo Hyundai syncs before they reach that branch — and Kia behaves similarly because deep-sleep responses return `location = null`. Net effect on both brands: no at-spot sync advances `soc_departed`, so it stays frozen at `soc_arrived` for the entire parking spell. Meanwhile the SoC on those same filtered syncs is perfectly fresh (the ECU reports SoC correctly even when it doesn't re-broadcast GPS), and every one of those SoC readings lives in the `VehicleSync` table regardless of whether the PE hook used it.

### Fix

`get_trips` now uses `_soc_before(prev.departed_at)` as the *primary* source for trip start SoC, with `prev.soc_departed` and `prev.soc_arrived` as fallbacks only when no earlier sync exists at all. `_soc_before` reads directly from `VehicleSync` and picks up every SoC update, including ones from syncs that the PE hook correctly ignored on GPS grounds.

After v2.28.12, `prev.departed_at ≈ sdk.start_time` (the ECU's own record of when the drive began), so "last SoC strictly before departed_at" is a clean anchor: any charging session that ended before the drive gets reflected, any ongoing session up to the moment of departure gets reflected, and nothing from the drive itself leaks in.

### Effect

- Both brands (same read-path) — PV-charge scenarios now show correct consumption.
- Drives with no mid-park charging are unchanged (VehicleSync's last SoC before departure equals the arrival SoC in that case).
- Read-only fix — no DB migration, no PE replay; just redeploy and restart.

## v2.28.12 (2026-04-20)

### Correct `departed_at` on **both** Kia and Hyundai — "car sleeps at origin" fix

Even after v2.28.11 killed the GPS cache-echo artefacts, one structural problem remained on *both* brands: the PE `departed_at` column is set to `last_seen_at` — the last sync that confirmed the car was still at the origin. When the car sleeps at the origin through the entire smart-window (user parks at home 18.04 12:42, drives away 20.04 06:30), there are zero intermediate at-spot syncs, so `last_seen_at = arrived_at` and closing the PE records `departed_at = 18.04 12:42` — a full 42 h before the actual departure. Both brands exhibit this: Kia returns `location = null` during deep-sleep, Hyundai returns a stale cache echo (which v2.28.11 now filters out) — in *both* cases there are no real at-spot syncs to advance `last_seen_at`.

The live-polling side has no way to observe an actual drive-off moment: by the time the car pings fresh GPS, it has already been moving for a while. But the SDK's `/tripinfo` endpoint reports the exact minute the car's ECU started the trip. We already pull it nightly (v2.28.10). v2.28.12 rewires `trip_reconcile` to use it.

### What changed

**Anchor flipped: match by arrival, not departure.** Before v2.28.12 the reconcile matched an SDK trip to a PE pair by comparing `sdk.start_time` with `prev.departed_at` (±20 min). Since `prev.departed_at` can be days off, matches were getting lost exactly when they were most needed. Now the anchor is `sdk.start_time + drive + idle ≈ curr.arrived_at` (±20 min) — `arrived_at` is the reliable end of a PE pair (set by the first live at-destination sync, typically within ~10 min of actual arrival).

**Write semantics: correct `departed_at` only, never touch `arrived_at`.** The PE arrival came from a real sync; it's the best signal we have. v2.28.11 was overwriting *both* ends with SDK-derived values, which could subtly shift a correct arrival timestamp in either direction. v2.28.12 rewrites only `prev.departed_at = sdk.start_time`.

**Brand gate: Kia + Hyundai both qualify.** Previously guarded by `_is_hyundai()`. Both brands expose `update_day_trip_info`; both exhibit the "sleep at origin → stale departed_at" failure mode. The gate is now `_brand_supports_trip_info()` and admits both.

**Pair selection widened.** Old code only considered PE pairs whose `prev.departed_at.date() == target_date`. With stale departed_at values that excluded the exact pairs that needed the most correction. Now: pair qualifies if either end (`prev.departed_at` OR `curr.arrived_at`) falls on the target date.

### Rollout

- `services/trip_reconcile.py` — new matching logic, new brand gate, reduced write scope
- `services/vehicle/trip_log_fetch.py` — inline reconcile after each fetch runs for both brands (no more Hyundai-only `_is_hyundai` check)
- `services/vehicle/sync_service.py` — renamed `_maybe_daily_hyundai_reconcile → _maybe_daily_trip_reconcile`, comments updated

All three production hosts: wipe + replay ParkingEvents under v2.28.11's staleness filter, then `reconcile_range(days=30)` with the new anchor. Both the Kia install and the Hyundai installs benefit — same code path, same correction.

## v2.28.11 (2026-04-20)

### GPS staleness filter for ParkingEvent — fixes phantom transitions on Hyundai

Two cars feeding into the same parking-event state machine were producing wildly different trip logs: Kia was clean, Hyundai e-GMP full of phantom stops and 0-km trips. Forensics on the raw responses revealed the root cause is **not** in our processing of the data but in what each brand actually sends:

- **Kia UVO** returns `vehicleLocation.coord = null` when the car is deep-sleeping (35 % of syncs over a 3-day window had no lat/lon).
- **Hyundai Bluelink** *always* returns a lat/lon — but when the car is asleep, it's the cached last-known position, sometimes hours old (observed: 40 min, 229 min, 344 min, 404 min GPS ages on otherwise-healthy syncs).

The existing PE guard `if sync.location_lat is None: return None` was meant to catch the "no GPS" case. It did its job on Kia (which honestly signals "no fix"), but on Hyundai it never triggered because Hyundai lied about having a fresh fix. PE accepted every cached echo as if it were live and built a fantasy timeline out of them.

### The fix

**New column** `vehicle_syncs.location_last_updated_at` (DateTime, nullable). Captures the ECU-side GPS timestamp — i.e. when the car last actually reported a position, as opposed to when we polled. Populated by a new parser `_extract_location_last_updated(status, raw_json)` that prefers the SDK's `Vehicle.location_last_updated_at` attribute (already datetime-typed) and falls back to `data.vehicleLocation.time` (`YYYYMMDDHHMMSS` string) in the raw payload.

**New staleness gate** in `services.trips_service.update_parking_from_sync()` — added right after the existing `location_lat is None` guard:

```python
if sync.location_last_updated_at is not None:
    age_min = (sync.timestamp - sync.location_last_updated_at).total_seconds() / 60.0
    if age_min > STALE_GPS_MAX_MIN:   # 30.0 by default
        return None
```

30 min is generous — smart-mode polls run every 10 min so legitimate fresh data is typically 0–20 min old. Anything older has a very high prior of being a cache echo. Legacy rows with `location_last_updated_at = NULL` fall through to the old behaviour (trust the GPS), which keeps things working during the backfill transition.

**Migration** follows the existing `_new_sync_cols` idiom in `app.py`. Column addition is idempotent on every boot.

**Dedup unchanged:** `VehicleSync.TRACKED_FIELDS` is deliberately *not* extended with the new column. Staleness should never drive "a new sync row must be persisted" — only actual movement of the tracked fields (lat, lon, soc, odo, etc.) should.

### Effect on the two brands

| | Kia | Hyundai |
|---|---|---|
| Syncs where column would help | ~1–2 per week | ~4 per day |
| Expected impact on PE | near-zero | dramatic reduction in phantom events |

Post-deploy: one-time backfill populates `location_last_updated_at` from existing `raw_json` rows, and a PE replay (wipe + `backfill_parking_events`) on Hyundai-heavy installs rebuilds the trip log under the new filter. Kia hosts get the column filled but are expected to produce the same PE set as before.

## v2.28.10 (2026-04-20)

### Nightly reconcile fires at 03:00 local instead of "first sync tick"

v2.28.9 hung the daily Hyundai PE↔SDK reconcile off the main sync loop: it ran on the first sync tick of a new calendar day, which in smart mode means 06:00 at the earliest (whenever the active window opens), later on cached/force modes. That's "sometime in the morning," not a deterministic time.

Moved to a dedicated thread (`_nightly_maintenance_loop`) that wakes at **03:00 local** regardless of sync mode or smart-window settings:
- Hyundai has yesterday's `/tripinfo` fully populated by then (the car uploads trip records within minutes of engine-off).
- The car is almost certainly parked / asleep, so the passive SDK pull doesn't collide with live polling.
- Well before smart-window start → main sync cadence is undisturbed.

Startup catch-up: if the service comes up past 03:00 on a day where the reconcile hasn't run yet, it fires once immediately instead of waiting until 03:00 the next morning.

Brand gate (`_is_hyundai()`) is still checked inside `_maybe_daily_hyundai_reconcile`, so Kia installs just no-op each wake-up. The thread itself runs everywhere — there's no point gating the wake, because the cost of a wake + no-op is effectively free (one AppConfig read per day).

### Confirming both sources in the DB

Side-note for anyone reading this via the settings UI: this repo *always* stores both the polling-based view (`ParkingEvent` table — GPS, time, SoC, odometer, labels) and the Hyundai server view (`VehicleTrip` table — `/tripinfo` rows with minute-accurate start / drive / idle / distance). Neither replaces the other. The reconcile just aligns the PE timestamps to SDK where a clean 1:1 match is found — it does not merge, split, or delete PE rows.

## v2.28.9 (2026-04-20)

### Daily PE ↔ SDK trip reconcile (Hyundai only)

On Hyundai e-GMP installs, ParkingEvent timestamps (`departed_at` = last at-spot sync, `arrived_at` = first sync at new spot) run several minutes to several hours off real drive start / end — the polling cadence is coarse and smart-mode syncs can be 10 min apart. Meanwhile the Hyundai server's `/tripinfo` endpoint returns minute-accurate start / drive-time / idle-time / distance per trip (we already store this in `VehicleTrip`).

New module **`services/trip_reconcile.py`** greedy-matches PE pairs to SDK trips — strict tolerances (±20 min on start_time, km delta within 25% or ≤3 km absolute), each SDK trip binds to at most one PE pair, and matches that would cross adjacent-event boundaries are skipped. When a clean 1:1 match lands, we overwrite `prev.departed_at = sdk.start_time` and `curr.arrived_at = sdk.start + drive + idle`.

**What this does NOT do:** merge PE pairs that split across a single SDK trip (GPS-jitter artefacts), split PE pairs that merged several short SDK trips (below-threshold stops), or backfill missed trips. Those represent different views of the same journey and can't be reconciled without data loss.

**Brand gate:** runs only when `vehicle_api_brand == 'hyundai'`. Kia (the Kia install reference install, 400 V platform) is untouched — the `_is_hyundai()` check short-circuits every entry point. Tested both branches locally.

### Trigger points

1. **Inline after SDK fetch** (`trip_log_fetch.fetch_day_trip_info`): whenever a day's SDK trips are pulled fresh, the same day's PE pairs are reconciled immediately. Wrapped so a reconcile failure never blocks the fetch result.

2. **Daily from the sync loop** (`sync_service._maybe_daily_hyundai_reconcile`): once per calendar day, after a normal sync tick, backfill the last 3 days of SDK trips and reconcile. `last_reconcile_at` in `AppConfig` prevents same-day re-runs. The gate `should_run_daily()` is Hyundai-only.

### What a typical run looks like on the Hyundai install

Runs recorded (2026-04-20): 17 PE pairs on the last 5 days, 2 applied (PE#3→#4 arrived_at 12:48 → 10:45, PE#5→#6 overnight arrival 06:01 → 00:16), 1 skipped conflict, 14 unmatched. The unmatched cases are legitimate structural mismatches — PE merging multiple short SDK trips or PE splitting via GPS jitter — not cases we should be touching.

Daily API budget impact: +3 calls/day (three days of `backfill`) on Hyundai hosts. Kia hosts: zero extra calls.

## v2.28.8 (2026-04-20)

### Dashboard SoH: kill the bogus consumption-based fallback that always showed ~125 % on e-GMP

Root cause of the "SoH still shows 125 % after the v2.27.0 baseline fix" that survived even v2.28.7's localStorage cache bust:

The dashboard JS has had, for a long time, a fallback path when `/api/vehicle/status` returns `battery_soh = null`:

```js
const soh = (consumedKwh / 1000 / battKwh * 100).toFixed(1);
```

This is *not* SoH — it's "lifetime energy drawn / nominal pack capacity × 100", i.e. how many nominal-full-batteries-worth the car has consumed over its life. For an Ioniq 5 with ~904 kWh lifetime consumption and a 72.6 kWh pack, that's `904.6 / 72.6 ≈ 12.46`, scaled to a percent somehow lands at ~125 %. Total coincidence that it looks like a plausible SoH; it has nothing to do with battery health.

It fires whenever the connector returns `battery_soh_percent = None`, which on Kia/Hyundai is the common case — the API only includes SoH on force-refresh responses, not on cached ones. So every non-force dashboard poll silently rewrote the SoH card with this fake number.

### Fix

1. **Backend** (`/api/vehicle/status` in `app.py`): when the connector's fresh `s.battery_soh_percent` is `None`, fall back to the most recent `VehicleSync` row that carries a non-null SoH. This means cached polls still surface the last-known SoH (via `scale_soh()`) instead of sending `null` downstream.

2. **Frontend** (`templates/dashboard.html`): remove the consumption-based fallback branch entirely. If the backend can't provide a SoH even from DB history, we show `—` instead of inventing one.

Force-refresh behaviour is unchanged: when the API does return a fresh SoH, that's what surfaces.

## v2.28.7 (2026-04-20)

### Dashboard: version-key the vehicle localStorage cache

Companion to v2.28.5's update-banner cache fix. The dashboard's live-vehicle card caches the full `/api/vehicle/status` response in `localStorage['ev_vehicle_data']` so page loads render instantly from the previous fetch. Key was fixed (no version suffix), so any semantic change to the payload survived across versions: after v2.27.0 introduced display-time SoH baseline scaling, users on the Hyundai install kept seeing the pre-scaling raw 125 % because the old cached value was rendered on page load and — depending on polling state — never got replaced.

Keying the cache on `Config.APP_VERSION` (same approach as `ev_update_check_cache_v2_…` in v2.28.5) means every deployed version sees its own slot. An applied update auto-orphans the prior slot. One-shot cleanup on load removes the legacy unkeyed entry and any previous-version slots so `localStorage` doesn't grow one entry per release.

After deploying, **a single browser reload** is enough — the new version's JS starts writing to the new key immediately, the old key gets removed on first visit.

## v2.28.6 (2026-04-20)

### Settings → Gefahrenzone: "Komplett zurücksetzen" Button

Until now, repurposing an install (getting it back to a freshly-provisioned state — no password, no DB, no credentials, no settings) meant shell access: `rm data/ev_tracker.db && systemctl restart ev-tracker.service`, or a full reinstall. Convenient for admins, not for the actual user. New UI path:

**Settings → Gefahrenzone → "Komplett zurücksetzen …"** opens a modal that asks for the current web-UI password (if auth is enabled) and a typed `RESET` confirmation, then wipes:

- `data/ev_tracker.db` entirely (all tables, including `AppConfig`, so password + API credentials go with it)
- `data/notify.json` if it exists

Before wiping, the server writes a timestamped copy to `data/backups/ev_tracker-pre-factory-reset-YYYYMMDD-HHMMSS.db` — not surfaced in the UI, just sitting on disk as an "oh shit" rescue. After the wipe, the backend disposes the SQLAlchemy engine, schedules a systemd restart (same mechanism as backup-import), and `os._exit(0)`s as a belt-and-suspenders so a supervisor still brings us back if the sudo-restart fails.

On the restart, the app comes up with an empty DB, `is_auth_enabled()` returns False (the flag was in `AppConfig`), and the user lands on `/` with an unlocked dashboard — exactly the state of a fresh install right after the first visit, before any password has been set.

**This does not touch LUKS, the venv, or the repo** — it's purely an app-data wipe. Anything outside `data/` (updates/, logs/, /srv/ev-data's mountpoint setup) is untouched. If you need to reset the *LUKS volume* because you've forgotten the passphrase, that remains a shell-only operation (documented in `deploy/README.md`).

Twenty new translation keys (`set.danger_*`) in all six languages.

### Safety gates

Three gates prevent accidental / drive-by resets:

1. **Login required** when auth is on (standard auth guard already handles this)
2. **Typed confirmation**: the request body must contain `confirmation: "RESET"` verbatim — no variations, no checkboxes. Any JSON submission that skips this gets a 400 `confirmation_mismatch` before any file is touched.
3. **Password re-verification**: if auth is enabled, the current password is re-checked server-side via `verify_credentials()`. Wrong password → 401 `wrong_password`, no wipe happens.

Installs without auth (opt-out configurations) skip the password step but still require the typed confirmation.

## v2.28.5 (2026-04-20)

### Dashboard update-banner: bust cache after an applied update

The dashboard's update-check banner (`templates/dashboard.html`) caches the `/api/update/check` response in `sessionStorage` for 30 minutes to avoid spamming GitHub. The cache key was just `ev_update_check_cache_v1` — version-agnostic — so after a successful update, the stale cache entry (with `update_available: true`) kept showing the banner until either the TTL expired or the user closed the tab. A plain page reload does NOT clear `sessionStorage`, so reloading didn't help the confused user.

Keying the cache on `{{ config.APP_VERSION }}` makes every version see its own cache slot: the moment the app restarts on a new version, the old key is orphaned and a fresh fetch happens on the first dashboard load.

## v2.28.4 (2026-04-20)

### Trip log: decouple `departed_at` from next `arrived_at` + motion-triggered force-refresh

v2.28.3 fixed *what* `soc_departed` / `odometer_departed` contained, but their **timestamp** — `prev.departed_at` — was still `sync.timestamp` of the *first sync at the new location*. Because that's the same sync that opens the next ParkingEvent, `prev.departed_at == curr.arrived_at` in every case: the trip-edit modal showed identical timestamps on both sides, and the "time the car spent driving" was structurally 0 min.

**Fix:** when closing the event on move detection, set `departed_at = last_seen_at` (the last sync while still at the old spot), not the post-drive sync timestamp. Now `prev.departed_at < curr.arrived_at`, and the gap reflects the actual blind window between "last known at origin" and "first known at destination" — i.e. drive time plus any poll-interval slack.

### Trip-list SoC/km calc simplified

`get_trips()` now uses `prev.soc_departed` and `prev.odometer_departed` directly as the origin values (post v2.28.3 they hold the last at-spot readings). `_soc_before()` drops to fallback status for legacy events that still hold pre-v2.28.3 capture data. Kilometrage similarly prefers `prev.odometer_departed` over `prev.odometer_arrived`.

### Motion-triggered force-refresh

The original user concern — "the system should get a fresh SoC before I drive" — can't literally be met: we can't predict departure. But we *can* make the **arrival** side fresh. When `update_parking_from_sync()` detects a move (GPS jump ≥ 100 m), it now calls `sync_service.request_force_refresh('motion_detected')`, which queues a force-refresh on the next sync-loop tick. The sleep loop breaks out within ~10 s so the follow-up wake happens quickly. This ensures `curr.arrived_at` / `soc_arrived` / `odometer_arrived` reflect a fresh reading even if the sync that detected motion was cached.

### Data-gap hint in the trip-edit modal

Between the Startpunkt / Zielpunkt cards there's now an info banner showing the drive window: "Fahrt: ca. 34 min — Abfahrt 11:56 → Ankunft 12:30. Während dieser Zeit keine Sync-Daten (Fahrt-Intervall)." Makes the polling-interval uncertainty explicit so the user knows how fresh the endpoint data is. Two new i18n keys (`trips.edit_gap_short`, `trips.edit_gap_hint`) in all six languages.

### Migration

Existing ParkingEvents still have `departed_at = post-drive sync timestamp`. Run **Fahrtenbuch → "Aus Historie nachbauen"** (with wipe) once after updating to rebuild the event chain with the new logic. New events captured from this release onward are already correct.

## v2.28.3 (2026-04-20)

### Trip edit modal: fix SoC/km on `departed` side + clearer labels

Two closely related issues in the trip-edit modal:

1. **`soc_departed` / `odometer_departed` captured the wrong sync.** `_maybe_update_parking_event` in `services/trips_service.py` only wrote these fields at the moment the car was detected at a new location — meaning the values came from the *first sync at the destination*, not the last sync while still at the origin. The trip's SoC drop and drive-km delta ended up attributed to the *origin parking event* instead of the trip. Example from the field: Elbepark showed arrival 81 % → departure 67 % (14 % "lost while parked"), while the subsequent drive to home showed 67 % → 67 % (zero SoC used for a 20 km trip).

   Fix: update `soc_departed` / `odometer_departed` on every same-place sync so they continuously hold the last-known at-spot values. On move detection, don't overwrite — the fields already contain the correct pre-departure state. `_open_event` also initialises `*_departed = *_arrived` so single-sync events still have meaningful data.

   The displayed trip consumption in the table was already correct (uses `_soc_before()` via `VehicleSync`), so only the edit modal and the raw `ParkingEvent` values needed the fix. Existing events can be repaired with the **"Aus Historie nachbauen"** button (wipe + replay).

2. **Labels "Angekommen / Abgefahren" were ambiguous.** On the Startpunkt card, "Angekommen" means the previous trip's end, and "Abgefahren" is this trip's start — on the Zielpunkt card it's the opposite. Same label pair in both places, with the trip-relevant one flipping sides. Users had to infer from context which field mattered.

   Added a coloured subheader on each card ("Fahrtbeginn — Abfahrt von diesem Ort" / "Fahrtende — Ankunft an diesem Ort") and a small `(Fahrtbeginn)` / `(Fahrtende)` suffix in the trip's primary colour on the trip-relevant field labels. The non-trip-relevant column stays neutral. Four new translation keys (`trips.edit_trip_start`, `trips.edit_trip_end`, plus `_hint` variants) in all six languages.

## v2.28.2 (2026-04-19)

### Installer auto-picks a free port; `APP_PORT` env var overrides

Running the installer on a machine that already had something on port 7654 failed with `Address already in use` right after the file swap, because the systemd unit hardcoded the port and the installer had no fallback. Now:

- `Config.APP_PORT` reads from the `APP_PORT` env var, falling back to `7654` (same for `APP_HOST`).
- `deploy/install.sh` checks whether 7654 is free before writing the systemd unit. If it's taken, it walks 7655 → 7700 and picks the first open port. The chosen port is injected into the unit via `Environment=APP_PORT=<n>`.
- `EV_APP_PORT=<n>` env override lets you pin a specific port for the installer (skip auto-discovery).
- The Tailscale-serve step and the "fertig" banner at the end both use the actual chosen port, not a hardcoded 7654.

`deploy/ev-tracker.service` was updated to include an `Environment=APP_PORT=7654` line as the default; the installer overwrites it with whatever port it picked.

## v2.28.1 (2026-04-19)

### Installer: show pip progress instead of silent hang

v2.28.0 passed `--quiet` to `pip install` in `deploy/install.sh`, which suppresses the download/build output entirely. On slow networks or ARM hardware where pandas/matplotlib/numpy take several minutes, the installer looked hung between `Baue Python-venv & installiere requirements.txt …` and the next line. Dropped `--quiet`, added `--progress-bar on`, and preceded the step with a "kann 2–5 min dauern" log line so expectations are set. Also split pip-upgrade and requirements install into two log blocks for clarity.

## v2.28.0 (2026-04-19)

### One-shot installer for new hosts

Bringing up a new install used to mean manually stepping through: apt-get the right packages, create the `ev-tracker` user, clone the repo, build a venv, drop the systemd unit in place, write the sudoers file, enable and start the service. That's about 20 lines of shell and two or three things that are easy to get subtly wrong.

Now it's one command. On any fresh Debian/Ubuntu host:

```bash
curl -fsSL https://raw.githubusercontent.com/robeertm/ev-charge-tracker/main/deploy/install.sh | sudo bash
```

The installer lives at `deploy/install.sh` and ships alongside three configuration artefacts (`deploy/ev-tracker.service`, `deploy/sudoers.ev-tracker`, `deploy/ev-unlock`) plus a README with env-var overrides, non-interactive usage, and LUKS setup notes. It's idempotent — rerunning it on an existing install pulls latest code and re-runs pip without touching the database.

Tailscale install + `tailscale serve --https=443` is offered as an optional step at the end. Skip with `EV_WITH_TAILSCALE=0` or accept the interactive prompt.

**What the installer does NOT do:** LUKS volume setup (the installer detects `/srv/ev-data` as an existing mount point and leaves the filesystem alone, but it won't create the encrypted volume for you), Debian base install, fail2ban rule tuning. Those are pre-install steps documented in `deploy/README.md` for the full-paranoia setup the reference installs use.

## v2.27.1 (2026-04-19)

### Translate `set.soh_baseline` / `set.soh_baseline_hint` into ES/FR/IT/NL

v2.27.0 only added the two new SoH-baseline strings to the DE and EN files. The i18n fallback chain in `services/i18n.py:t()` goes `current_lang → de → key`, so any install running in Spanish/French/Italian/Dutch ended up rendering the German hint text verbatim on the Settings page — the exact "hardcoded German leaking through" regression v2.25.3 was supposed to prevent. Added native translations for the remaining four languages; key counts now DE/EN = 897, ES/FR/IT/NL = 605.

## v2.27.0 (2026-04-19)

### Battery SoH baseline — realistic percentage for Hyundai/Kia e-GMP

On the Hyundai install (Ioniq 5 AWD LR, 800 V e-GMP platform) the dashboard has been showing SoH values around 125 % for the past months. Not a bug in our code — the Hyundai/Kia BMS on e-GMP vehicles reports `ev_battery_soh_percentage` against an internal warranty-floor reference (≈ 80 % of gross capacity), so a fresh battery reads ~125 % and degrades toward 100 % as it ages out of warranty. The vehicle_raw detail page already annotated this ("kia_soh_over_100" note), but the user-facing number was still the raw reading. Older 400 V platforms (Kia Niro EV) report against nominal capacity and show correct 100 %-ish values, so the quirk is specifically e-GMP.

Added a user-configurable `battery_soh_baseline` setting (default 100; 125 for e-GMP). Scaling happens at display time (`scale_soh(raw) = raw / baseline * 100`) in `services/stats_service` — no DB migration, existing historical values in `vehicle_syncs.battery_soh_percent` stay raw and get rescaled on every render. Changing the baseline retroactively re-scales the whole history graph, so switching from 100 → 125 on an e-GMP install immediately makes the dashboard read ~100 % and the history curve shows the real degradation slope.

Wired at:
- `/api/vehicle/status` (`battery_soh` in the dashboard JSON)
- `services.stats_service.get_vehicle_history` (`series.soh[]` and `summary.last.soh`)
- `/vehicle/raw/<id>` (normalized panel now shows scaled + raw + baseline side-by-side)

New Settings field in Vehicle section with a hint explaining the 100 vs 125 choice. Two new DE/EN translation keys (`set.soh_baseline`, `set.soh_baseline_hint`) — both keyspaces at 897 now.

The Hyundai install is pre-configured to `battery_soh_baseline=125` as part of this deploy.

## v2.26.0 (2026-04-18)

### Trip log: ParkingEvent-primary again, SDK demoted to manual backfill

v2.24 had made the Kia/Hyundai `update_day_trip_info` SDK endpoint the *primary* source for the trip list, with ParkingEvent pairs doing GPS enrichment underneath. In steady state this worked, but whenever polling was sparser than the SDK's trip count — either because smart-sync was narrowed, or simply because short back-to-back trips clustered faster than the poll interval — the unmatched SDK rows fell through to "Ort unbekannt" instead of a real address. The user reported this as a regression: the pre-v2.24 ParkingEvent-pair view had shown fewer (merged) trips but *every* trip had a location.

Back to ParkingEvent pairs as the source of truth. `services/trips_service.get_trips()` now iterates `parking_events` pairwise exactly like it did in v2.23, and only falls back to SDK `vehicle_trips` rows on dates where zero ParkingEvent pairs exist (i.e. historical days from before polling was on). Where a polled trip's `departed_at` lines up within 60 min of an SDK row's `start_time`, the SDK row's stats (drive/idle minutes, avg/max speed) ride along as extra detail on the polled trip — best of both worlds.

**SoC calculation bug fix.** While rewriting `get_trips` I noticed the pre-existing SoC delta was wrong: it used `prev.soc_arrived` (SoC when the car arrived at the *start* location, possibly captured pre-charge) minus `curr.soc_arrived` (SoC at trip end). If the user charged between arriving at and leaving the start location, the "used" SoC included the charge and got clamped to 0 by the `max(..., 0)`. Changed to `prev.soc_departed` (SoC captured by the sync that first noticed the car leaving), falling back to `prev.soc_arrived` only when no departure sync fired. Values now match what the Bluelink/UVO app reports.

**Auto-fetch disabled.** `maybe_auto_fetch()` was called from `services/vehicle/sync_service._save_vehicle_sync` after every successful poll (rate-limited to 1×/h), silently pulling SDK trip-info. Since the SDK rows now only show as a fallback, there's no reason to keep burning API calls on auto-fetches for days that already have polling coverage. Removed the hook from the sync loop; the "Vom Fahrzeug-Server laden" button in Settings → Trips still works for manual backfilling of historical days. Corresponding helpers `fetch_recent` / `maybe_auto_fetch` and the `TODAY_REFRESH_AFTER_MIN` constant were deleted from `services/vehicle/trip_log_fetch.py`.

**Dead code removal.** `_assign_events_to_trips` (the 2-pointer merge introduced in v2.24.3), `_sdk_trip_to_dict`, `_load_sync_gps`, `_nearest_sync`, `_sync_point_to_dict`, and the `_SYNC_ENRICH_TOLERANCE_MIN` / `PARKING_MATCH_TOLERANCE_MIN` constants all supported the SDK-as-primary flow that no longer runs. Stripped them out. `_event_to_dict` simplified — no more need to handle `evt is None`.

**Template.** `templates/trips.html` used to show the cloud-check icon only on `source == 'sdk'` rows; now it shows whenever `drive_min` is present, i.e. on polled trips with SDK stats attached *and* on SDK-only historical rows. The tooltip also picks up `avg_speed_kmh` / `max_speed_kmh`.

**User-observed effect.** On the Kia install today the log shows 2 PE-pair trips (home → shopping → home) instead of the 1 consolidated SDK round-trip — matches what polling actually captured. On the Hyundai install where polling is sparser (smart-mode never got turned on explicitly), some days will now show fewer PE-pair trips than SDK had on record; user can enable smart-mode for denser polling, or manually backfill historical days if needed.

## v2.25.3 (2026-04-17)

### i18n audit: translate everything the user actually sees

The user flagged that charge operators show up in German regardless of the configured language. Audited the whole project and fixed every user-visible hardcoded German string.

**Charge operators.** `DEFAULT_OPERATORS` in `app.py` mixed real brand names (IONITY, EnBW, Aral pulse, Tesla Supercharger, etc. — culture-neutral, stay as-is) with three generic labels ("Zuhause / privat", "Arbeit", "Sonstiges") that were only sensible for German. Split the list into `_DEFAULT_OPERATOR_BRANDS` (hardcoded) plus `_DEFAULT_OPERATOR_GENERICS` (translation-keyed via `set.op_home_private` / `set.op_work` / `set.op_other`). New `get_default_operators()` function resolves the generics at call time so the dropdown always matches the current UI language.

**API error / success responses.** Thirteen `jsonify({'error': 'German string'})` and five `{'message': 'German string'}` strings in `app.py` covered the auth / password / database-import / update / MQTT / trip-backfill flows. All now route through new `err.*` and `msg.*` translation-key namespaces (13 error keys, 5 message keys, German + English).

**Maintenance reasons.** `services/maintenance_service.py` emitted "X d überfällig" / "in X d fällig" / "X km überfällig" / "in X km fällig" strings directly. Moved to four `maint.overdue_days|overdue_km|due_in_days|due_in_km` keys with `{days}` / `{km}` placeholders.

**Dashboard regen window.** "(3 Mon.)" suffix next to the regeneration counter was hardcoded. Now `dash.regen_window_short` — "(3 Mon.)" in German, "(3 mo)" in English.

**Token-fetch step instructions.** The three-step instructions in Settings → Vehicle API for the manual refresh-token flow were pure hardcoded German; their JavaScript status messages ("URL leer", "Tausche Code gegen Token...", "Token gespeichert...", "Fehler") same story. All translated now via six new `set.api_token_step{1,2,3}_{title,body}` keys plus four `set.api_token_paste_{url_empty,exchanging,saved,error_generic}` keys wired through the existing T JS object.

**Verification.** Ran a parity check after: DE 895 ↔ EN 895 keys, zero orphans either side. All four primary pages (/, /settings, /trips, /report) render 200 in both languages.

What's still German on purpose: real brand names in DEFAULT_OPERATORS (IONITY, Tesla etc.), "Stadtwerke" (German near-brand for municipal utilities with no snappy English equivalent), German comments in the source. The legacy PDF report generator (`services/report_service.py`) and the token-fetch Selenium helper (`services/vehicle/token_fetch.py`) still contain hardcoded German — both run in rare one-off flows (PDF download, initial setup) rather than the daily UI, so they're deferred.

## v2.25.2 (2026-04-17)

### Report: localise week / "all time" / month-name labels

The v2.25.0 report page leaked three hardcoded German strings through its JSON payload: the week-preset label (`KW 16/2026`), the all-time label (`Gesamtzeitraum`), and the per-bucket weekly chart label (`KW16`). On top of that, `strftime('%B %Y')` for the month-preset label depended on the server's LC_TIME locale, which isn't what the app language is actually set to.

Moved all four into a `_LABELS` pack keyed by language inside `services/report_range.py` with explicit month-name arrays for DE and EN, so "April 2026" renders as "April 2026" (both languages — coincidentally identical) while "KW 16/2026" becomes "Week 16/2026" in English and "Gesamtzeitraum" becomes "All time". `resolve_range()` and `build_report()` now accept a `lang` kwarg; the `/api/report` route pulls it from `AppConfig['app_language']` and passes it through.

No other v2.23–v2.25 changes had hardcoded user-visible German — verified by grepping the touched files for umlauts and German word tokens.

## v2.25.1 (2026-04-17)

### Warn users that narrowing the smart-sync window degrades trip location data

The smart-sync window controls when the background polling loop actually runs (default 06:00–22:00 every 10 min). Tightening it — starting later, ending earlier, or polling less often — has a subtle downstream effect on the v2.24+ trip log: the **SDK trip list itself stays accurate** because it's fetched from the Kia/Hyundai server's cache independently of our polling, but the **From/To address labels** come from `parking_events` / `vehicle_syncs`, which are only populated while the poll loop is active. Trips happening outside the active window therefore get "Ort unbekannt" / "Unknown location" instead of a real address.

Added an inline warning banner in Settings → Vehicle API that appears the moment any of the three smart-window selects deviates from the 06:00 / 22:00 / 10-min default. The banner explicitly calls out that trips will still be **detected** (SDK-sourced, polling-independent) but that their **location labels** will often be blank, and offers a one-click "Restore default" button that snaps all three selects back to the recommended values (the user still has to hit Save to persist the change).

The check fires on every `change` event on any of the three selects, and re-evaluates when the user toggles between cached / smart / force modes — so switching back to `smart` immediately re-runs the validation.

## v2.25.0 (2026-04-17)

### Report: new interactive page with period picker and twelve colourful plots

The old `/report` endpoint used to hand out a PDF immediately, which meant two pain points: no way to pick a time range, and no way to see the numbers without a round-trip through a 10-page document. Rebuilt as a proper interactive view.

**Period picker** at the top: Today, Week (current ISO week), Month, Quarter (current calendar quarter), Half-year (H1 / H2), Year, and "All" (earliest recorded charge/trip through today). Plus a custom-range picker with two date inputs when none of those fit. The bucket size for the X-axis adapts automatically — ≤14 days renders daily bars, ≤95 days weekly (KW-NN), longer spans monthly — so a year chart doesn't become 365 illegible bars and a week chart doesn't collapse to a single one.

**Four headline KPIs:** total kWh, total cost (with €/100 km avg), distance driven (with avg consumption in kWh/100 km), and CO₂ saved vs. an equivalent-distance ICE using the user's configured `fossil_co2_per_km`.

**Three highlight cards** underneath: Euros saved vs. ICE (computed against `ice_cost_per_100km`, default €11.55 — configurable in future), biggest single charge in the window (date, kWh, type, cost), and longest single trip (date, km, minutes, max speed when the SDK reports it).

**Twelve plots**, laid out in a responsive 2-column grid:

1. kWh per bucket — blue bar
2. Cost per bucket — red bar
3. km per bucket — green bar
4. CO₂ per bucket — orange bar
5. AC / DC / PV split — doughnut, with kWh + count in the tooltip
6. Consumption over time (kWh/100 km per bucket) — purple filled line
7. Hour-of-day charging pattern — cyan bar (0 – 23)
8. Day-of-week pattern — dual-axis bar (kWh) + line (trips), Mon – Sun
9. Trip-length distribution — green bar (<5 / 5–20 / 20–50 / 50–100 / 100+ km buckets)
10. Electricity price per charge over time — red scatter, €/kWh on Y
11. Top charging operators — horizontal bar by kWh, tooltip shows cost and count
12. Most-visited locations — horizontal bar by parking-event count (home/work/favourite/address)

All plots are rendered client-side via Chart.js 4.4.6 (already a page dependency); the `/api/report?preset=…` endpoint returns a single JSON payload with every series pre-aggregated and pre-rounded so the frontend just has to paint.

**PDF export is preserved** as a "PDF" button on the page — still the original generator at `/report/export.pdf`, so nothing that worked before is gone. The button sits next to the range label so users can download a printable copy of whatever window they have open.

The navbar icon flips from the misleading `bi-file-earmark-pdf` to `bi-bar-chart-line` and the link finally gets a label ("Bericht" / "Report") instead of just "Report". New translation keys: about 45 of them, all under the `report.*` namespace in both `de.json` and `en.json`.

## v2.24.3 (2026-04-17)

### Trip log: sequential 2-pointer matcher fixes adjacent-trip cross-matches

v2.24.2's enrichment looked up the nearest-by-abs-delta parking event for each SDK trip independently, which broke down when two short trips boundaried each other inside the 60-minute matching tolerance. Concrete case from 2026-04-17: the 15:47 trip latched onto the 15:32 `work.departed_at` (polling lag from the previous trip leaving work), pushing the 15:03 trip into the sync fallback and surfacing a visible "home/work" mismatch on consecutive rows.

Replaced the independent per-trip search with an **ordinal two-pointer merge**:

1. Sort SDK trips by start_time.
2. Sort parking events by departed_at (and separately by arrived_at).
3. Walk both lists in lockstep. For each trip, advance the event pointer past events whose timestamp is more than 5 minutes BEFORE the current trip (can't belong to us). If the current event is within the 60-minute forward tolerance, claim it and advance both. If not, leave the trip without a parking match (falls to VehicleSync fallback → 'unknown').

Why this works: our parking-event timestamps always LAG the SDK's authoritative trip boundary (polling notices movement N minutes after it happened). That's an asymmetric relationship, not a symmetric one — a proper matcher has to respect the order. Each parking-event endpoint is consumed at most once per side, so adjacent trips can never fight over the same event.

Verified against the Kia install: consecutive-pair label consistency jumped from 8/13 to 12/13 across the last 14 days. The remaining mismatch on 2026-04-16 is a legitimate data gap (the SDK doesn't report a trip between the "other" arrival at 15:52 and the "home" departure at 16:10 — which would imply a 3rd trip the server didn't record). That's a question for the Bluelink server, not the matcher.

## v2.24.2 (2026-04-17)

### Trip log: honest "unknown location" + VehicleSync fallback for SDK trips

Backfilling 30 days of Bluelink/UVO trips on a host that had the background sync disabled (the Hyundai install before v2.23.2) exposed a gap in the SDK-trip enrichment path: the only location data we store outside the SDK is `parking_events`, and that table was almost empty for the backfill window, so most historical SDK trips couldn't be matched. The UI then fell through to the "Adresse wird ermittelt" branch and sat there forever — not because geocoding was broken, but because there were no coordinates to geocode in the first place.

Two fixes:

**VehicleSync as the second-chance source.** When a SDK trip's start/end doesn't line up with any `parking_events` row (±30 min), we now look for a `vehicle_syncs` row with GPS within ±2 hours. For the "from" endpoint we prefer a sync at or before the trip start; for "to" we prefer one at or after the trip end. That avoids using a mid-trip sync (smart-mode polling at 10-min cadence inside a drive) as a trip endpoint. When we find one, we reverse-geocode via the existing Nominatim-backed address cache — essentially free after the first call per coordinate.

**Explicit "unknown" label.** When neither a parking event nor a nearby sync exists, the endpoint stub now carries `label='unknown'` instead of the generic `'other'` the old code used. The template renders it as `bi-geo-alt-slash` + "Ort unbekannt" / "Unknown location" so users see an honest "we have no GPS for this trip" instead of a perpetual "resolving address". This shows up on the Hyundai install's March-era backfill where the car was driven but no polling data was captured.

The SoC/regen columns continue to work whenever both endpoints match a parking event, which is the common recent case. Nothing changes for users on hosts with a fully populated parking-event history.

## v2.24.1 (2026-04-17)

### Hotfix: 30-day SDK backfill crashed on the first clean day

The `backfill()` helper checked `r.get('skipped_reason', '').startswith(...)` to detect API-quota stops — but the normal-case code path explicitly sets `skipped_reason` to `None`, so `dict.get(key, '')` happily returned `None` (the present-but-None case), and the `.startswith` call blew up on the first successful day. The 30-day button therefore never got past the first fetch.

One-line fix: `reason = r.get('skipped_reason') or ''` before the `startswith` check, so both "key absent" and "key is None" resolve to an empty string.

## v2.24.0 (2026-04-17)

### Driving log: pull trips directly from the Kia/Hyundai server

Until now the driving log was derived from our own GPS polling: every time the car changed location between two syncs, we closed the previous parking event and opened a new one. That works as long as polling is frequent enough to catch every stop. On a Hyundai install where the background sync was disabled, a week's worth of trips collapsed into four parking events, one of which claimed the car had driven 51 km while sitting at home. This release fixes that at the source.

**What changed.** The `hyundai_kia_connect_api` SDK we already depend on exposes `update_day_trip_info(vehicle_id, yyyymmdd)`, which hits the same `/spa/vehicles/<id>/tripinfo` endpoint the Bluelink and UVO mobile apps use when you open the driving log. The car uploads a trip record at the end of every drive as part of its normal telemetry — that upload is independent of anything we do — and the manufacturer's server caches the list. Pulling it costs one API call per day requested (counted against the existing 200/vehicle daily budget) and **does not wake the car**: no cellular modem activation, no 12V battery drain. It's the same data the Bluelink app shows, just pulled from the server instead of the car.

Each trip comes back with a start time (HH:MM:SS), drive and idle minutes, distance in km, and average/max speed — no GPS coordinates, since those live behind a separate endpoint we don't need. We store the trips in a new `vehicle_trips` table and match each one up with the nearest `parking_events` row (±30 minutes tolerance) to fill in the "from" and "to" location labels our UI already shows.

**When it runs.** The background sync loop now calls `maybe_auto_fetch` after every successful vehicle sync, which refreshes today and yesterday at most once per hour — two API calls per day in the steady state. A manual "Vom Fahrzeug-Server laden" / "Load from vehicle server" button in the trips toolbar pulls the last 30 days on demand, useful for first-time setup or after a gap; it stops early if the daily quota is about to run out so it can't lock the user out of the normal polling path.

**How the fallback works.** The existing polling-derived view still runs on any day the SDK didn't return data (or the brand doesn't support the endpoint — currently only Kia and Hyundai do). That keeps historical dates intact and means users on other brands see no regression. Days that have at least one SDK-sourced trip suppress the polled trips for the same day, so there are no duplicates.

**UI.** SDK-sourced trips get a small cloud-check icon next to the timestamp with a tooltip explaining the source. The trip edit button is suppressed for SDK trips whose end couldn't be matched to a parking event (the underlying parking-event edit flow doesn't apply). Everything else — the map, km/SoC/regen totals, CSV/GPX export — works unchanged.

**Why this solves the Hyundai-merges-trips complaint.** Kia and Hyundai use the same SDK, so the same code path serves both. The merged-trip appearance on the Hyundai install was caused by polling being disabled there combined with our polling-only trip derivation. With the SDK pull, the trip log becomes server-authoritative and matches what the Bluelink app shows, regardless of how often we poll for GPS.

## v2.23.2 (2026-04-17)

### Dashboard: all remaining charts are now click-to-enlarge

The vehicle-history tiles already supported a click-to-fullscreen flow in previous versions, but the six "stats" charts on the same page did not — clicking them did nothing. Those are now all expandable too:

- Weather correlation (kWh vs temperature per month)
- Monthly cost
- Cumulative cost
- Monthly kWh
- Monthly CO2
- Cumulative CO2 savings vs battery-production break-even

Implementation is a single helper `makeExpandableChart(canvasId, cfg, title)` that wraps every `new Chart(...)` call. It keeps a deep-cloned copy of the config (preserving callback functions via `typeof` sniffing, since `structuredClone` won't copy them), adds a fullscreen icon to the card header, wires a click + Enter/Space handler on the whole card, and lazily opens a shared Bootstrap fullscreen modal that spins up a fresh Chart.js instance from the cloned config. The main chart stays live underneath; the modal chart is destroyed on close.

One subtlety worth noting: the weather chart is built inside a `fetch().then()` callback, so by the time the callback runs the scripts block at the bottom of the page has already defined the helper — safe to reference by bare name. The five stats charts live in the same scripts block and see the helper directly.

A separate `#dashFullscreenModal` sits outside the `{% if vehicle_history %}` guard so it's available even on installs where the car-history row isn't rendered (no Kia/Hyundai API configured, insufficient samples, etc).

## v2.23.1 (2026-04-17)

### Settings sidebar: scroll-spy fixes

Two scroll-spy regressions reported immediately after v2.23.0 rolled out:

- **Clicking "HTTPS Security" jumped to "Notifications"** on Tailscale hosts, because the SSL card is `{% if not hide_ssl_card %}`-gated and isn't rendered at all — but the SSL entry in the sidebar nav was still there. Clicking the orphan link fell through to the next visible card. Fix: on page init, walk the nav links and hide every entry whose target id isn't in the DOM (or has zero height).
- **Clicking "System Updates" highlighted "Backup"** in the sidebar. The IntersectionObserver picked whichever card had the highest intersection ratio inside a narrow viewport band, which for short cards meant the *next* short card would beat the one just clicked. Fix: replaced IntersectionObserver with a deterministic "last card whose top has crossed the sticky-nav line" computation on scroll, and added a 700 ms spy-suppression window after a click so smooth-scroll can't be overruled mid-flight.

Also: the alternating tint stripe is now computed on the filtered (visible) card list rather than the raw list, so hiding the SSL card doesn't break the two-tone pattern below it. And the manual scroll now subtracts the live navbar + mobile-tab-bar height, so target cards land cleanly under the sticky header on both breakpoints instead of relying on CSS `scroll-margin-top` alone.

## v2.23.0 (2026-04-17)

### Settings page: sidebar navigation, scroll restore, alternating section tint

The settings page had grown to fifteen cards stacked in a single long column. Finding a specific section meant scrolling, and saving inside a section always bounced the user back to the top of the page. Both are fixed.

**Navigation.** On screens ≥ 992 px a sticky left-hand sidebar lists all fifteen sections (Language, Vehicle, THG, Locations, PV, API, ENTSOE, Operators, Database, SSL, Auth, Notifications, System Updates, Backup, About). Clicking an entry jumps to the section; as the user scrolls, the active entry highlights via IntersectionObserver. Below 992 px the sidebar collapses into a horizontally-scrolling tab bar pinned under the top navbar — no dropdown, no hamburger, just a swipeable strip.

**Scroll restore on save.** Every form inside a settings card now includes the section id on submit, either as a hash appended to the form action (for POSTs that render the page directly) or as a hidden `return_section` field (for the two handlers that redirect — `save_language` and the vehicle-API refresh flow). After the round trip, the browser lands back on the section the user was editing, not at the page top. Section ids are validated server-side against a simple `sec-<alphanum>` whitelist to keep the redirect URL safe.

**Alternating tint.** Every second card gets a subtle background tint (`--bs-tertiary-bg` in light mode, a hair-thin white overlay in dark mode), making the boundaries between sections obvious at a glance.

**Anchor-link compatibility.** Legacy anchors `#updaterCard` (dashboard's update banner) and `#thg` (the THG reminder banner) have been updated to the new scheme (`#sec-app` and `#sec-thg`). External bookmarks to the old names will no longer scroll to the card but will still land on the settings page — the fallback is graceful.

Reference layout borrowed from the Shelly Energy Analyzer project's settings page, adapted to Bootstrap 5 / Jinja instead of the JS-rendered schema used there.

**Deployment note.** This rolls out to the primary install only for initial testing. The other installs stay on v2.22.2 until feedback comes back; GitHub release and tag are held until the bundle grows.

## v2.22.2 (2026-04-17)

### Hotfix: Favorites invisible + add-button dead on Tailscale hosts

Users on Tailscale peers (all three installs, accessed via the internal VPN) reported existing favorites not rendering in Settings → Locations, and the "add favorite" flow doing nothing. Two separate-sounding symptoms, one root cause.

**Root cause:** The HTTPS/SSL controls card is intentionally hidden when the request comes from a Tailscale peer (the VPN already provides transport encryption, so the self-signed-cert UI is just clutter there). The SSL-setup JavaScript lives in an IIFE that is historically nested **inside** the Locations IIFE. When the SSL card is absent, every `document.getElementById('btnSslSave')` etc. returns null, and the first `addEventListener` call throws a TypeError. Because the SSL IIFE is nested, the throw escapes into the outer Locations IIFE and aborts it mid-flight — before `loadFavs()` is called and before the add-favorite click handler is wired up.

That's why existing favorites stay invisible (`loadFavs()` never runs, so the `<ul>` stays empty) and why clicking the add button does nothing (the listener was never attached).

**Fix:** Early-return guard at the top of the SSL IIFE:

```js
if (!document.getElementById('btnSslSave')) return;
```

One line. The SSL IIFE now exits cleanly when its card isn't present, the outer Locations IIFE continues, `loadFavs()` runs, the add-favorite handler is registered.

Hit all three production hosts in the same rollout. Verified by fetching the rendered `/settings` page on each and confirming the user-configured favorites now show up in the list markup.

---

## v2.22.1 (2026-04-17)

### Mobile fix: operator picker as a real dropdown

A user reported that the operator picker did not work on mobile — "it's not a dropdown there". The cause was the `<input list="operatorsList">` with an HTML `<datalist>`: on iOS Safari it did not render a dropdown at all, and on Android the behaviour was inconsistent.

**Fix:** On the charge form (`/input`) and the edit form (`/edit/<id>`), replaced it with a native `<select>` that uses the native picker on every mobile browser. The last option is labelled "Custom operator (free input)…" — if selected, a text field appears below for free input. A hidden input `name="operator"` is kept in sync by JS so the backend POST stays unchanged.

When editing a charge with a custom operator (not in the list), "Custom operator" is preselected and the text field is prefilled with the existing value.

Price autofill still hangs off the resolved operator value.

---

## v2.22.0 (2026-04-17)

### Trip log: all fields editable + map picker + favorites editing

Follow-up on v2.21.0 following user feedback: "all fields should be editable, start/stop time, km, SoC, regen. from/to selectable via the map. location favorites can't be edited".

**1. Trip editor rebuilt: two columns, all fields**

The old modal only edited the label/favorite name/address of a single stop. The new one edits the entire trip — both the start AND the destination stop in two columns side by side. Per side, editable:

- Label (Home/Work/Favorite/Other) + favorite name
- Address
- Arrival time + departure time (datetime-local)
- Odometer on arrival + on departure
- SoC % on arrival + on departure
- Coordinates (lat/lon) — type directly or pick via map

Derived values (trip km, SoC consumption, recuperation) are **not** edited separately — they are automatically recalculated from the saved odometer/SoC/time values. A hint text below the map explains this.

**2. Map picker in the modal**

A Leaflet map is now shown below the two columns. Both markers (blue = start, red = destination) are draggable. Each side also has a "Pick on map" button — clicking it puts the map into selection mode and the next map click sets the coordinates of that side. The modal calls `invalidateSize()` on `shown.bs.modal` so Leaflet does not render tiles at 0x0.

**3. Favorites editable in settings**

The list previously only had delete. Now there are three action buttons per favorite:

- **Rename** (pencil): opens an inline input with check/cancel, Enter = save, ESC = cancel. Clicking the name also opens the same edit mode.
- **New position** (pin): the map enters selection mode, the next click sets the new coordinates of this favorite.
- **Delete** (trash): unchanged.

### New endpoints / API changes

- `POST /api/parking_event/<id>` now additionally accepts `lat`, `lon`, `arrived_at`, `departed_at`, `odometer_arrived`, `odometer_departed`, `soc_arrived`, `soc_departed`. An empty string for `departed_at` clears the column (for "currently parked" entries). `arrived_at` is mandatory.
- `PUT /api/locations/favorites` — new endpoint: `{index, name?, lat?, lon?}` patches a single favorite. Missing keys are left alone (partial update).

### Server protection

The 7-day check (409 when `confirm_old` is missing) is unchanged — still applies to all POST modifications.

### No migration

No schema change. No breaking change for old clients — the existing POST fields (label/favorite_name/address) still work the same.

---

## v2.21.0 (2026-04-17)

### Four UX improvements following user feedback

**1. Log charge: cancel button + "My location" now comes from the car**

Previously the form had no way to discard entered values — you had to navigate back and ignore browser warnings. Now: an explicit Cancel button next to "Save" which optionally prompts (only if something has actually been entered) and also clears the local timer session.

The "My location" button previously pulled `navigator.geolocation` from the smartphone — which requires HTTPS and usually failed silently, and did not reflect the charging location anyway (phone is at home on the table, the charge happened at IONITY on the A4). Now the button fetches the **last GPS position reported by the car** from `vehicle_syncs` via a new endpoint `/api/vehicle/last_gps`. Works without HTTPS. The smartphone GPS is preserved as a secondary button, but the default is now the vehicle.

**2. Operators in settings: proper table instead of a textarea + price autofill**

Instead of "Custom operators as free text" there is now one row per operator (built-in + custom) with name and price per kWh. Prices are stored as JSON in `operator_prices`. In the log-charge form, the matching price automatically fills the `eur_per_kwh` field when the operator is selected — but only if the user has not yet touched the field themselves (prevents unwanted overwrite). Same logic in the edit form.

**3. Trip log: edit stops after the fact with a 7-day guard**

Each stop cell (from/to) is now clickable and opens a modal for editing the label (Home/Work/Favorite/Other), favorite name and address. Coordinates and timestamps stay immutable — they come from the car and changes would invalidate the derived km/SoC statistics.

Entries older than 7 days require an explicit confirmation checkbox ("Entry is older than 7 days — really change?"). The check also runs server-side in `/api/parking_event/<id>` — a hand-crafted modal call without confirmation gets a 409 back. Warns with the day count and a hint about retroactive effects on the statistics.

**4. Settings → Locations: clearer operation**

The Save buttons only had a disk icon without text — easy to overlook, which explains the "missing" save button in the user's report. Now: explicit "Save" on Home and Work buttons, separate "Pick on map" button, favorites button with hint text below (Name → Button → Map), and a numbered 3-step instruction at the top of the card.

### New/changed endpoints

- `GET /api/vehicle/last_gps` — last known GPS position from the car
- `GET/POST /api/parking_event/<id>` — view/edit a stop (with 7-day guard)
- Settings POST `action=save_operators` now accepts parallel arrays `op_name[]`/`op_price[]`/`op_builtin[]` instead of one textarea blob

### Data model

No schema change. New config keys are created lazily: `operator_prices` (JSON dict).

---

## v2.20.4 (2026-04-17)

### Hotfix: Dashboard crash for charges without a cost value

A production user reported "Internal Server Error" when opening the dashboard, could no longer get into the app.

**Cause:** In [services/stats_service.py:268](services/stats_service.py#L268) the monthly statistics computation for `cost_per_kwh` only checked whether `r.kwh > 0`, not whether `r.cost` is NULL. As soon as a charge with `kwh_loaded` but no `total_cost` is in the DB (typical for PV charges or a price not yet entered), the division blows up:

```
TypeError: unsupported operand type(s) for /: 'NoneType' and 'float'
```

The dashboard handler aggregates monthly statistics on render → every request → 500.

**Fix:** Check extended to `if r.cost and r.kwh and r.kwh > 0` — when the cost value is missing, `cost_per_kwh: 0` is returned, analogous to the existing `round(r.cost or 0, 2)` one line above.

No DB migration needed. No breaking change. A single line.

Affected: all users with at least one charge where `total_cost` is NULL and `kwh_loaded > 0`.

---

## v2.20.3 (2026-04-16)

### Vehicle history: real frames per plot, fullscreen works, map also appears in cached sync

Three follow-up bugs from v2.20.1/.2 addressed after the user reported "all plots need their own frame, location also not showing yet and zoom doesn't work".

#### 1. Click → fullscreen actually works now

Cause (deeper than the ID collision in v2.20.2): `bootstrap.bundle.min.js` is loaded in [templates/base.html:106](templates/base.html) **after** `{% block content %}`. But my inline script in the vehicle-history card ran **during** content parsing and called `new bootstrap.Modal(modalEl)` immediately — at that point `bootstrap` was not yet defined. ReferenceError → rest of the IIFE aborted → no click handler, no map.

Fix: The modal is now created **lazily** on the first click via a `getModal()` helper. By then `bootstrap` is long since available. The `hidden.bs.modal` listener is attached once at the same opportunity.

#### 2. Each plot now has its own frame

The 7 charts used to be bare `<div>`s with a label + canvas in a shared `.row`. No visual separation. Now a Jinja loop over a `vh_plots` tuple list wraps each plot in its own `<div class="card h-100 vh-chart-tile shadow-sm">` with:
- **Card header** (white, narrow) with title + fullscreen icon on the right
- **Card body** with the chart canvas
- `shadow-sm` and `h-100` so heights are uniform in the row
- Whole card is the click target (`role="button"`, `tabindex="0"`, `cursor:pointer`)

The location map gets the same card styling + the geo icon in the header.

#### 3. Map also appears in Kia/Hyundai "Cached" mode

The map card was previously gated on `vehicle_history.summary.last.lat` — i.e.: only if the **very last sync** delivered GPS. Under Kia/Hyundai Cached mode the API usually does not deliver GPS, so the map was permanently missing.

Now: a new server helper in the [app.py](app.py) `dashboard` route scans the `series.lat/lon` arrays backwards and takes the **last known** GPS point. The result ends up as a `vehicle_history_last_gps` dict in the template with `{lat, lon, stale, at}`. `stale=True` when the point was not the most recent sync row → the UI then shows "last known position" behind the location label.

The Leaflet asset include in the `<head>` is now also gated on this new variable instead of `summary.last.lat`, so the assets are loaded for Cached-mode users.

#### Side note: Jinja template trap

A comment in the JS contained the literal `{% block content %}` as an explanation, which Jinja mistakenly interpreted as a block open → `TemplateSyntaxError`. Reworded the text so the parser leaves it alone. Classic "didn't see that coming" trap with template engines.

#### Verification

- `py_compile` clean on app.py
- Dashboard renders with status 200, 63k chars
- Exactly 7 `card h-100 vh-chart-tile` frames in the HTML
- `function getModal()` in the bundle, **no** eager `new bootstrap.Modal` anymore
- Scenario A (latest sync has GPS): map renders normally, no "stale" badge
- Scenario B (only earlier sync has GPS, latest does not): map renders with last-known coordinates, "last known position" label in the header
- Scenario C (no GPS at all): map block simply gone, rest of page renders without crashing

## v2.20.2 (2026-04-16)

### Hotfix: Vehicle history — ID collision broke several plots simultaneously

In v2.20.1 I named the new period dropdown `<select id="vhRange">` — but the **range chart canvas** carries the same ID `<canvas id="vhRange">`. With two identical IDs, `document.getElementById('vhRange')` returns the **first** element in the DOM: the select (in the card header, comes before the canvas). Chart.js then calls `getContext('2d')` on a select element → TypeError → the rest of the IIFE does not run:

- Range chart is not drawn (that's the chart with the broken ID)
- All charts after Range are also not drawn (IIFE aborted)
- Location map is not drawn (initialized after the chart loop)
- Click-to-fullscreen handlers are never registered (done at the very end of the IIFE) → "Enlarge doesn't work"
- Dropdown change handler is also missing

That explains the three symptoms at once: "enlarge doesn't work · range is missing · location is missing · all plots somehow hang together".

**Fix:** Renamed the select to `vhRangeSel`. Pulled the JS reference to the dropdown location along. Canvas still keeps `id="vhRange"` as expected in `CHART_DEFS`, so the render loop stays unchanged.

Automatic verification in the dashboard HTML:
- `id="vhRange"` now appears exactly once (canvas)
- `id="vhRangeSel"` appears exactly once (select)
- JS contains `getElementById('vhRangeSel')`, no longer `getElementById('vhRange')` on the dropdown path
- All 7 chart IDs are in CHART_DEFS
- Modal + 7 clickable tiles in the DOM

## v2.20.1 (2026-04-16)

### Vehicle history: click → fullscreen + period selection

Two requested usability improvements to the vehicle history card on the dashboard:

**1. Each plot is clickable → opens a fullscreen modal.**
All 7 mini charts (SoC, range, odometer, 12V, SoH, recuperation, consumption) now have a fullscreen icon hint in the top right corner and are click- (and Enter/Space-) active. A click opens a Bootstrap `modal-fullscreen` with a larger version of the same chart: thicker line, more axis ticks (12 instead of 5), grid visible, data points as small circles, tooltips with Intersect-off mode for easy hovering. ESC / click outside closes.

**2. Period dropdown in the card header row.**
New choices: **24h · 7 days · 30 days · 90 days · 1 year · All**. On change, `/api/vehicle/history?days=N&persist=1` is called via AJAX, the charts are destroyed and redrawn with the new data — loading overlay with spinner during the request. The choice is persisted in `AppConfig` under `dash_history_days`, the next page load shows the same range directly.

**Default range is now 30 days** (previously "all"). For accounts with many months of data, 30 days is more readable; anyone who wants more clicks "1 year" or "All" in the card — that then sticks for future visits too.

**Technical:**
- [app.py](app.py) new route `/api/vehicle/history?days=N[&persist=1]` with clamp on 0..10 years, calls the existing `get_vehicle_history(days=...)` — no change to the stats service needed.
- Dashboard template refactored: chart configs now live in a `CHART_DEFS` list with `id`, `field`, `color`, `fmt`, `label`. The `renderAll(series)` function destroys old chart instances (`charts[id].destroy()`) and rebuilds them, so range switches are clean and have no memory leaks.
- Fullscreen modal reuses `buildChartConfig` with a `{fullscreen: true}` flag, which enables larger font sizes, grid and points. A second chart instance is drawn on `#vhFullscreenCanvas`; on modal close it is destroyed again. Chart.js needs a visible container to measure, so `setTimeout(..., 120)` after `modal.show()`.
- 8 new i18n keys in de + en (`dash.vh_range_title`, `dash.vh_range_{1d,7d,30d,90d,365d,all}`, `dash.vh_click_fullscreen`).

**Verified:**
- py_compile clean
- Dashboard renders with dropdown + modal + 7 clickable tiles
- `/api/vehicle/history?days={1,7,30,90,365,0}` delivers the correct shape for all values (`days`, `series`, `summary`), `series` has 11 expected fields
- Unknown `days=abc` clamped to 30
- `persist=1` updates `AppConfig['dash_history_days']`
- Server render selects the saved option correctly
- No data / empty range: API returns `series=null`, JS guarded with `if (data && data.series)`, no crash

## v2.20.0 (2026-04-16)

### Automatic rollback on broken updates + dashboard update banner

Two user-requested features that belong closely together: the update experience becomes more visible (anyone not checking settings sees the new version) and safer (broken updates don't leave the user in an app that won't start).

#### 1. Automatic rollback

**Problem:** If an update introduces a bug that prevents the app from starting (migration crashes, import error, missing dependency), the user was left with a dead app and no fallback. systemd tries to restart, crashes each time, gives up — the only remedy was SSH + manual git checkout.

**Solution:** A small state-machine guard that runs on every app boot (`services/update_service.py:pre_boot_rollback_check`).

**Flow:**
1. Before every update file-swap, a **backup of the files to be overwritten** is created in `updates/backup_pre_v<OLD>/`, plus an `UPDATE_PENDING.json` marker with old/new version, backup path and attempt counter.
2. On app boot, `pre_boot_rollback_check()` reads the marker. Three cases:
   - **No marker** → normal boot, nothing to do.
   - **Marker present, `attempts < 3`** → bump the counter, start a verification timer that deletes the marker after 60 seconds of successful uptime.
   - **Marker present, `attempts >= 3`** → rollback: swap the backup back, write `LAST_ROLLBACK.json`, `os._exit(0)` — supervisor restarts with the old code.
3. Second line of defense: after the restart, `updater_helper.py` watches port 7654 for 60 seconds for binding. If it doesn't → direct rollback without waiting for the boot counter.

**Why 3 attempts instead of 1?** Transient errors (port briefly occupied, race on sqlite open) should not falsely trigger a rollback. Only when **three** starts in a row fail before the 60s timer fires is the new version truly broken.

**Platform-agnostic:** The mechanism needs nothing but a supervisor that restarts on crash. Works under systemd (`Restart=always`), under macOS Terminal+nohup, under Windows (if anyone uses that).

**Data-safe:** `data/`, `venv/`, `.git/`, `logs/`, `updates/` are never touched by the backup/restore. The user's SQLite DB stays untouched no matter what happens.

**Manually confirmed with an end-to-end simulation:**
- Real Flask app copied into a temp dir
- Backup created, `app.py` replaced with a broken version where `create_app → RuntimeError`
- Three boot attempts each run into the exception, counter goes 1, 2, 3
- Fourth boot triggers rollback: `app.py` restored, marker gone, `LAST_ROLLBACK.json` written
- Afterwards the app boots successfully again. DB file size unchanged the whole time.

**Test suite (18 tests across 4 scenarios, all green before release):**
- `/tmp/test_rollback.py`: 10 tests of the decision logic (no marker, attempts 1→2→3, rollback fires, missing backup, corrupt JSON, read/clear API, backup pruning)
- `/tmp/test_helper_rollback.py`: 5 tests of the duplicated backup/restore paths in the helper + port watch
- `/tmp/test_e2e_rollback.py`: real Flask-app boot simulation with a deliberately broken `create_app`
- API + template smoke test: `/api/update/last-rollback` GET/DELETE, settings banner rendering

#### 2. Dashboard banner for available updates

At the top of the dashboard there are now two banners filled in via JS/AJAX after load:

- **Update banner** (yellow, refresh icon): appears when `/api/update/check` reports a new version. Shows "New version available v2.X.Y". **Click jumps directly to `/settings#updaterCard`** — the app-info card now has the anchor ID and the browser scrolls there automatically.
- **Rollback banner** (blue): only appears once if the app automatically reverted to the old version on the last boot. Explains from/to which version. Dismissible with "X" button — `DELETE /api/update/last-rollback` clears the `LAST_ROLLBACK.json`.

The update-check response is cached in `sessionStorage` for 30 minutes so clicking between pages does not call `/api/update/check` on every page load.

**Settings page** additionally gets:
- Anchor ID `updaterCard` for the deep link from the banner
- Permanent hint under the buttons: "Before every update, a backup is created. If the new version doesn't come up, it automatically reverts to the previous one."
- Info box with details if a `LAST_ROLLBACK.json` exists

#### Technical

- New file [services/update_service.py](services/update_service.py) — single source of truth for the decision logic (`MAX_ATTEMPTS=3`, `VERIFICATION_DELAY_S=60`).
- [updater.py](updater.py) `_inline_swap` (systemd path): before the file swap, `create_pre_update_backup()` + `write_pending_marker()` are called.
- [updater_helper.py](updater_helper.py) (non-systemd path): duplicated stdlib-only implementation of the same backup/restore paths plus port watch after restart. Duplication intentional — the helper must run even if the venv is broken.
- Pre-boot check as the first statement in [app.py:create_app()](app.py) — BEFORE `db.create_all()`, because a broken migration is exactly the kind of thing that should trigger a rollback.
- At most 3 backups are kept in parallel (oldest pruned by mtime).
- 5 new i18n keys (de + en): `dash.update_available_title/hint`, `dash.rollback_title`, `set.app_last_rollback_title`, `set.app_rollback_safety_hint`.

**Important note about the first rollout:** This release v2.20.0 brings the protection mechanism. That means concretely: **the update FROM v2.19.x TO v2.20.0 is not yet protected by rollback** (the old v2.19.x updater does not know about the backup step yet). From v2.20.0 → v2.20.1 onwards the mechanism kicks in automatically on every update.

## v2.19.2 (2026-04-16)

### CSV import preview: see what happens before it happens

Previously the import was a leap into the unknown: upload, choose mode, click — and hope that the columns were recognized correctly and nothing important went wrong. Now there is a preview step.

**Workflow:**
1. User chooses CSV + mode → clicks **Preview** (no longer direct Import)
2. Browser fetches `POST /api/import/preview` via AJAX — the backend analyses the file without importing it and returns structured JSON
3. UI renders:
   - **Info row**: detected delimiter, whether a header was detected, how many rows are already in the DB
   - **Column table**: each CSV column with index, header name, auto-detected mapping (as a dropdown, **changeable**), and a sample value
   - **Missing app fields**: which of our logical fields (e.g. operator, charge location) the CSV does not contain — these remain empty
   - **Summary**: total rows / new / updated / duplicates / empty / errors
   - **Sample rows** (first 20) with an action badge per row (`new`, `update`, `duplicate`, `empty`, `error`)
   - **Error list** with row numbers, if any occurred
4. User can **change the column mapping via dropdown** if auto-detection mapped a column incorrectly. The overrides end up in a hidden `column_override` form field.
5. Satisfied → **Import** button (the previous one) — the POST carries the `column_override` along and applies it during the real import.

**Architecture:**
- Refactor in [import_gsheet.py](import_gsheet.py): shared helpers `_analyze_csv`, `_parse_one_row`, `_classify_row`. Both `preview_csv_data()` (new function, DB-read-only) and `import_csv_data()` (commit path) go through the same code path, so the preview is guaranteed to show the same result the import will later produce.
- New route endpoint `/api/import/preview` (POST multipart form) → JSON with columns, samples, summary, errors.
- `import_csv_data(column_override=...)` now optionally accepts an override dict `{logical_field: col_index}` that patches auto-detection. `null` unmaps a field.
- The POST `action=import_csv` in the settings handler also parses `column_override` as JSON from the form and passes it through.
- Settings template gets JS that AJAX-fetches the preview, renders a complete UI (tables + badges + dropdowns), and on dropdown change writes a correct `column_override` JSON back into the hidden field.
- 49 new i18n keys in de + en (preview labels, action labels, and user-friendly field labels like "Operator" instead of `operator`).

**Verification:**
- Preview unit test with 3-row CSV (2 valid, 1 bad date) → summary correct, samples correct, unmapped CSV columns detected
- Column-override unit test: CSV with "My Special Field" header, auto = None → override to `operator` → correctly parsed as operator
- End-to-end API test: `POST /api/import/preview` returns valid JSON with all fields
- End-to-end import test: upload with `column_override='{"date":0,"operator":1,"kwh_loaded":2}'` through `/settings` → data correctly saved with mapped operator
- Regression: existing import without override keeps working (dedup kicks in, import counts correct)

## v2.19.1 (2026-04-16)

### Fix: Vehicle sync crash "Object of type DailyDrivingStats is not JSON serializable"

The enriched `raw_data` dump from v2.19.0 could not serialize the Kia/Hyundai `daily_stats` field (a list of `DailyDrivingStats` objects from the SDK).

**Root cause**: My introspection check in [connector_hyundai_kia.py:_dump_vehicle](services/vehicle/connector_hyundai_kia.py) tested serializability with `json.dumps(val, default=str)` — but `default=str` silently stringifies **every** unknown object and the check always passed. What got saved was then the original object; only when `json.dumps(raw_data)` was later called without the default argument did it blow up.

**Fix**: The introspection now does a real round-trip `json.loads(json.dumps(val, default=str))` — which produces a truly JSON-safe copy (nested `DailyDrivingStats` → string repr). As a belt, all five call sites of `json.dumps(raw_data)` (in `services/vehicle/sync_service.py` and four places in `app.py`) additionally get `default=str`, so a future regression doesn't crash the sync again.

Regression-tested with a mock vehicle that carries `daily_stats = [DailyDrivingStats(...), …]` plus a nested dict with objects in it → dump now fully JSON-safe, no more exceptions.

## v2.19.0 (2026-04-16)

### Big update: CSV import data safety, raw-data viewer, complete edit page, operator dropdown

Production release — every feature was verified with a Python syntax check, migration test, template smoke test and end-to-end unit tests for the import logic before tagging.

#### 1. CSV import is now safe and tolerant

The old importer [import_gsheet.py](import_gsheet.py) was **position-based** and had only one mode (`replace=True` → `DELETE FROM charges`, then re-insert). That meant: **charges manually added after the fact were simply deleted on re-import**. For a production tool users actively rely on, that's a data loss risk.

New:

- **Columns are detected by header**, not by position. Fuzzy matching (case-insensitive, typos via `SequenceMatcher` ratio ≥ 0.82) against an alias table: `Datum` / `date` / `tag` / `day` all hit the same logic, likewise `EUR/kWh` / `€/kWh` / `preis`, `Uhrzeit` / `zeit` / `hour`, `Anbieter` / `provider` / `cpo` / `betreiber`, etc.
- **Delimiter is autodetected**: semicolon (our own export), comma (Google Sheet), tab, pipe. The character with the highest median column count across the first 5 rows wins.
- **Date format is autodetected**: `YYYY-MM-DD`, `DD.MM.YYYY`, `MM/DD/YYYY` (Google Sheet US), and as fallback `DD/MM/YYYY`.
- **Legacy fallback**: if no header row is found (Google Sheet export starts directly with date rows), the old position-based mapping runs.
- **Four import modes** instead of one boolean:
  - `skip` (default) — rows with the same `(date, charge_hour, kwh_loaded)` as existing entries are skipped. **Manual data is never overwritten.**
  - `update` — no duplicate is created, but if the CSV has fields that are empty in the existing entry (e.g. operator or location), they are filled in. Existing values are left untouched.
  - `append` — everything is inserted, including exact duplicates. For advanced users.
  - `replace` — the old nuclear behaviour. Now shows a red warning box with a mandatory checkbox (`replace_confirm`). Before the delete, **a DB backup is automatically written** to `data/backups/pre_import_YYYYMMDD_HHMMSS.db`; the last 5 backups are retained.
- **Export is lossless again**: the own CSV export (`/api/export/csv`) now contains all fields including time, odometer, operator, location, lat/lon. A round trip (export → re-import in skip mode) leads to 0 new entries and 0 errors — tested with the live DB (474 entries).

#### 2. "Edit entry" finally shows all fields

The old [edit.html](templates/edit.html) was incomplete — neither location nor operator were shown, and the backend POST handler in [app.py:edit_charge](app.py) ignored the fields even if they were set in the input form (data was lost on every edit).

- All location fields (name, lat, lon) are now on the edit page
- **Inline Leaflet map picker** (like in settings): "Map" button unfolds an OSM map, click sets the marker position, marker is draggable, coordinates are written live into the lat/lon fields
- Quick buttons "Home"/"Work" take the coordinates from settings
- Backend saves `location_name`, `location_lat`, `location_lon`, `operator`

#### 3. Operator field (CPO) on every charge

New column `operator` (VARCHAR(64), nullable) on the `charges` table — migration runs automatically on first start after update via `ALTER TABLE`, idempotent.

- Input form and edit page have a `<datalist>` field with 19 built-in operators (IONITY, EnBW mobility+, Aral pulse, Tesla Supercharger, Shell Recharge, Allego, Fastned, Elli (VW), EWE Go, Maingau, Lidl, Kaufland, Aldi Süd, REWE, Mer, Stadtwerke, Home / private, Work, Other). The user can type freely or choose from the list.
- New settings card **"Charging station operators"** with a textarea for custom entries (newline- or comma-separated). Custom entries appear in addition to the built-in list. Stored as JSON under AppConfig key `custom_operators`.
- History table shows operator + location as a small second line under the date (`…` if too long, full text in tooltip).

#### 4. Raw-data viewer for all vehicle brands

New routes `/vehicle/raw` (list of all syncs) and `/vehicle/raw/<id>` (details of one sync row). Reachable via a "View raw data" button in the vehicle API card as soon as a brand is configured.

- Detail page shows **all normalized fields** (as stored in the DB) above and **the complete raw API dump** as pretty-printed JSON with a scroll container + copy-to-clipboard button.
- `raw_data` of the Kia/Hyundai and VAG connectors was expanded from `{'vin': …}` to **full introspection**: all public, JSON-serializable attributes of the Vehicle object end up in the dump (primitive types directly, `datetime` → ISO string, nested objects stringified with a length cap). That's what makes the viewer useful in the first place.
- **SoH banner for Kia/Hyundai**: if `battery_soh_percent > 100` is in a snapshot, a blue info box appears explaining why — the API measures against the factory-released usable capacity, while the battery still has physical reserve. New batteries typically show 110–125 %, the value drops with ageing towards 100 %.

#### 5. Migrations & backwards compatibility

- `charges.operator` is idempotently added via `ALTER TABLE ADD COLUMN operator VARCHAR(64)` on the first start with v2.19.0. Existing rows have `operator = NULL`, which is handled consistently everywhere (history shows nothing, CSV export writes empty, edit page renders as an empty field).
- The old `replace=True` parameter to `import_csv_data()` still works (maps to `mode='replace'`), so existing callers don't break.
- i18n: 62 new keys in `de.json` and `en.json` — both files have identical key sets.

#### Verification

Before commit:

- `python -m py_compile` on all changed Python files — clean
- CSV import unit tests with 6 format variants (semicolon+header, re-import dedup, update mode manual-protection, legacy comma-no-header, ISO-date+tab, replace-with-backup) — all green
- App boot test: migration runs, `charges.operator` exists, all core routes return 200
- Edit POST round-trip: operator + location are persisted
- Raw viewer: handles invalid/null raw_json gracefully
- CSV round-trip: own export (474 rows) → re-import in skip mode → 0 new, 0 errors

## v2.18.3 (2026-04-16)

### Fix: Hyundai Selenium waited for a non-existent button even though the login chain was already through

Screenshots from the user showed the cause of the 5-min timeout: **The browser lands on Hyundai directly on the final URL** `prd.eu-ccapi.hyundai.com:8080/api/v1/user/oauth2/token?code=...&state=ccsp&login_success=y` — that is, with a valid CCSP code in the address bar. But Selenium was waiting for the CSS selector `button.mail_check, button.ctb_button`, which does not exist at all on this JSON response page. Result: 300 seconds of idling despite successfully obtained code.

The research agent verified against the upstream script [`hyundai_kia_connect_api/Hyundai Token Solution/hyundai_token.py`](https://github.com/Hyundai-Kia-Connect/hyundai_kia_connect_api/tree/master/Hyundai%20Token%20Solution): the selectors `button.mail_check`/`button.ctb_button` **are not in the upstream code**. Upstream uses a terminal `input("Press ENTER after login is complete...")` gate, no Selenium wait. So the selectors were a homegrown construction that searched on a page the browser had long since left.

Fix: Instead of waiting for a CSS selector, we now wait on the **URL pattern** — either the browser lands directly on the `redirect_final` host (Hyundai: auto-chain via session cookies) or on the `login_redirect` host (Kia: intermediate landing on kia.com, after which step 2 is needed). The logic distinguishes the two cases and jumps directly to code extraction when the chain is already through, or performs the second `driver.get()` otherwise. Kia's `a[class='logout user']` selector stays as an additional trigger for the oneid flow.

Second fix in the same pass: the manual paste-URL validation rejected URLs with `login_success=y` as "step 1" — but `login_success=y` also appears in the final `prd.eu-ccapi` URL. Now the distinction is made only by **host** (`ctbapi.hyundai-europe.com` = step 1, otherwise accepted).

## v2.18.2 (2026-04-16)

### Fix: Step-2 URL with unencoded redirect_uri triggers 400 Bad Request

Clicking the Step-2 link in the manual instructions produced "400 Bad Request — Invalid request". Cause: the `redirect_uri` query parameter contained an unencoded `https://...:8080/api/v1/user/oauth2/token`. If you send the URL through Selenium's `driver.get()`, Chromium normalizes it automatically — but on an `<a href>` click from the UI, the browser sends the URL raw, and Hyundai's OAuth server is strict enough to reject the request.

Fix: `get_manual_step2_url()` now uses `urllib.parse.quote(cfg['redirect_final'], safe='')` for the `redirect_uri` value. The same URL is used in the Selenium path (`_do_fetch`) too — previously this path had a separate builder, which was risky for future changes. Now one builder, one source of truth.

## v2.18.1 (2026-04-16)

### Manual token flow: 3-step instructions with clickable step links

The user pasted the **ctbapi URL** in the manual paste flow (Stage 1, the login result with `?code=...&login_success=y`). The code there is issued for `peuhyundaiidm-ctb` — the token endpoint rightfully says "code is not exist in redis" because it is not known for the API client `6d477c38-...`. But that message doesn't help the user at all.

Two improvements:

**1. ctbapi URL is explicitly intercepted.** `exchange_manual_url()` now checks `'ctbapi.hyundai-europe.com' in url` or `'login_success=y' in url` and returns a clear message: "This is the login URL (stage 1), not the final token URL (stage 2). Next step: open this URL in the same browser...".

**2. UI shows 3-step instructions with clickable links.** When the user expands the "Manual" details, the page loads via `GET /api/vehicle/token/manual/step_urls?brand=...` the two step URLs:
- **Step 1**: login URL → user opens in their own browser, logs in
- **Step 2**: CCSP authorize URL → user opens *in the same browser*. Due to the IdP session cookie from step 1, this URL automatically redirects via 302 to the final URL with `?code=Y` (the correct CCSP code)
- **Step 3**: user copies the final URL from the address bar and pastes it in

Both links are directly clickable (`target="_blank"`), the placeholder in the paste field is dynamically set to `prd.eu-ccapi.hyundai.com:8080/.../token?code=...` (Hyundai) or `.../redirect?code=...` (Kia).

## v2.18.0 (2026-04-16)

### Manual URL paste as fallback for Kia/Hyundai token + better InvalidSessionId message

Two topics:

**1. InvalidSessionIdException handling.** If the user closes the browser window in noVNC during the Selenium flow (or Chromium crashes), Selenium throws `InvalidSessionIdException` with a long stack trace. Previously the raw stack trace ended up in the UI. Now: specific detection of the error plus friendly message "Browser session ended. Please do not close the browser window while the token is being fetched."

**2. Manual paste fallback.** If Selenium crashes, hangs or gets killed by the user for any reason, previously the whole process had to be restarted. New: under the "Fetch token" button there is a collapsible `<details>` element "Manual fallback: paste URL with code". Workflow:
1. User opens Kia/Hyundai login in their own browser (Mac/iPhone, wherever)
2. Logs in, lets the flow run through, lands on the URL with `?code=...` (for Hyundai: `prd.eu-ccapi.hyundai.com:8080/.../oauth2/token?code=...`)
3. Copies the URL from the address bar
4. Pastes it into the new text field in the app, clicks "Fetch token from URL"
5. App extracts the code via regex, POSTs to the token endpoint, saves the refresh token in the password field

Completely independent from the Selenium path, also works when Chromium/noVNC are down, ARM hosts where ChromeDriver has issues, etc. New route `POST /api/vehicle/token/manual`, new function `exchange_manual_url()` in `token_fetch.py`. 3 translation keys per language.

## v2.17.7 (2026-04-16)

### Hyundai token fetch: missing 2nd authorize step (final fix)

After verbatim comparison with two working upstream scripts (`Hyundai%20Token%20Solution/hyundai_token.py` by the library authors and `RustyDust/bluelinktoken.py`) it was clear: the CTB flow has **two authorize steps**, just like Kia. My code never did the second step.

**The actual flow:**
1. User logs in via `login_client_id=peuhyundaiidm-ctb` → browser lands on `ctbapi.hyundai-europe.com/api/auth?code=X`. `button.mail_check` / `button.ctb_button` appears — that's where the browser stops.
2. The script must **programmatically** navigate to a second authorize URL: `idpconnect-eu.hyundai.com/.../authorize?response_type=code&client_id=6d477c38-...&redirect_uri=prd.eu-ccapi.hyundai.com:8080/.../oauth2/token&state=ccsp`. Thanks to the IdP session cookie from step 1, this URL immediately 302-redirects to the final URL with the CCSP code Y.
3. Extract code Y, exchange for token.

In v2.17.2 I mistakenly replaced the CSS selector wait with a URL wait on prd.eu-ccapi — but the browser never navigates there by itself, hence the "permanent hang". Now: CSS wait → driver.get(redirect_url) → 15-second poll on URL match. The entire CTB special case is gone, Kia and Hyundai now run through the same code path.

## v2.17.6 (2026-04-16)

### Fix: Hyundai token fetch — wait for CCSP code, not for ctbapi code

Revert of v2.17.5 plus root cause. The Hyundai CTB flow has **two codes** in the redirect chain:
1. `ctbapi.hyundai-europe.com/api/auth?code=X` — code for `client_id=peuhyundaiidm-ctb` (the login client). This code does NOT belong to the token POST.
2. Then a server redirect to `prd.eu-ccapi.hyundai.com:8080/.../oauth2/token?code=Y` — Y is the CCSP code for `client_id=6d477c38-...` (the API client). This is the code the token endpoint expects.

In v2.17.4 I loosened the URL check to "contains `code=`" — Selenium consequently grabbed code X from ctbapi. My v2.17.5 attempt with `redirect_uri=ctbapi` on the token POST failed because the API client does not have ctbapi registered as a redirect at all (→ "Invalid redirect uri").

Correct fix:
1. Wait condition reverted to **URL contains `prd.eu-ccapi.hyundai.com` AND `code=`**. So Selenium waits for the second redirect and gets the correct CCSP code Y.
2. Token POST again uses **`redirect_uri=redirect_final`** (matching the URL against which the CCSP code was issued). v2.17.5 branching rolled back.
3. Error message on wait timeout now explicitly shows which URL was reached, so in a log case we can immediately see whether it got stuck on a third redirect host.

Kia (oneid, 2-step authorize) unchanged.

## v2.17.5 (2026-04-16)

### Fix: Hyundai token POST uses wrong `redirect_uri`

Hyundai token endpoint returned 400 with `"Mismatched token redirect uri. authorize: https://ctbapi.hyundai-europe.com/api/auth token: https://prd.eu-ccapi.hyundai.com:8080/api/v1/user/oauth2/token"`. OAuth2 requires that the `redirect_uri` parameter on token exchange is **exactly** the same as on the preceding authorize request.

My code blindly used `cfg['redirect_final']` for the POST — that's correct for Kia (whose second authorize step actually runs with `redirect_final` as redirect_uri), but not for Hyundai CTB. Hyundai has only **one** authorize step with `redirect_uri=login_redirect` (`ctbapi.hyundai-europe.com/api/auth`). The browser subsequently lands on `prd.eu-ccapi.hyundai.com:8080/.../oauth2/token?code=...` (that's the CTB display URL), but the code was issued by idpconnect against `ctbapi...`.

Fix: on the token POST, decide per flow — `ctb` → `login_redirect`, `oneid` (Kia) → `redirect_final`. Kia stays byte-for-byte the same.

## v2.17.4 (2026-04-16)

### Hyundai token fetch: URL match more robust + better error messages

Two fixes in one release:

**1. URL match relaxed.** In v2.17.2 the wait required the final URL to start with `https://prd.eu-ccapi.hyundai.com` **and** contain `code=`. In practice the browser sometimes lands on `ctbapi.hyundai-europe.com/api/auth?code=XXX` instead of directly on prd.eu-ccapi depending on the flow variant — my match did not accept that and ran until the 5-minute timeout. Now it suffices: URL contains `code=`, no matter on which host.

**2. Empty error messages resolved.** The user reported a red "message:" display without further text next to the token button — that was either a Selenium `TimeoutException` with an empty message, or a swallowed exception body. All error paths in the token fetch flow now explicitly return `{type}: {message}`, plus context (last URL on timeout, HTTP body on token POST error, etc.). On a completely empty `str(e)` the code falls back to the exception type name. Additionally, the complete traceback is logged on the server (`journalctl -u ev-tracker.service`) so server-side diagnosis is also possible.

Kia path unchanged.

## v2.17.3 (2026-04-16)

### Fix: VAG connector — import path for the CarConnectivity class

In `carconnectivity >= 0.11` the `CarConnectivity` class is no longer in the top-level package but in the submodule `carconnectivity.carconnectivity`. The old import `carconnectivity.CarConnectivity(...)` threw: `module 'carconnectivity' has no attribute 'CarConnectivity'` — which only became visible at all with v2.17.1 (the error-surfacing fix); in v2.17.0 and earlier, the generic "check username and password" flash hid the actual error.

Fix: Import with fallback — first try the new submodule, then the old top-level import. Works on both library versions.

## v2.17.2 (2026-04-16)

### Fix: Hyundai token fetch hangs in Selenium wait

v2.17.0 waited for `button.mail_check` or `button.ctb_button` as the "login detected" condition for Hyundai — selectors from the RustyDust script, but they sit on an intermediate confirmation page that Hyundai apparently **skips** in some flows. The browser lands directly on `prd.eu-ccapi.hyundai.com:8080/api/v1/user/oauth2/token?code=XXX` and shows the JSON body `{"result":"E","data":null,"message":"url is not defined"}` — which is, incidentally, **not an error** but the expected end state (the server strips the `code` query param when rendering). But Selenium kept waiting for buttons that never come, and ran into the timeout after 5 min.

Fix: per-flow logic in `_do_fetch()`. For the CTB flow (Hyundai), don't wait on DOM elements but on the URL change — as soon as `driver.current_url` starts with `prd.eu-ccapi.hyundai.com` and contains `code=`, the login is through. Selenium extracts directly from the URL and skips the separate `driver.get(redirect_url)` step (which Hyundai already performs itself in the CTB flow). The Kia oneid flow stays 1:1 as before: CSS wait on `a.logout.user`, then manual navigation to the CCSP authorize endpoint.

## v2.17.1 (2026-04-16)

### Fix: VAG (VW/Skoda/Seat/Cupra/Audi) shows the real error instead of generic "check password"

VW Group's identity server (`identity.vwgroup.io`) regularly — after password changes, T&C updates or new data protection provisions — requires **renewed acceptance** by the user. The CarConnectivity library throws in that case an exception with the exact URL to accept (`Try visiting: https://identity.vwgroup.io/...`). Previously `VAGConnector.test_connection()` silently discarded this exception with `except Exception: return False` and the app flashed the generic "Connection failed. Check credentials." — whereupon every user naturally thought the username/password was wrong, which then triggered login throttling on testing.

Fix: `test_connection()` no longer catches the exception, lets it propagate to the app route, which outputs it with `flash.error` in the flash message — including the consent URL. `authenticate()` (used for the background sync) stays defensive and now additionally saves `self._last_error` as a hint for log analysis.

**User-side**: if the error comes up again, the flash message now contains the URL the user needs to open in a browser, log in and click the consent. Then the Skoda/VW/Audi/Seat/Cupra connection works again.

## v2.17.0 (2026-04-15)

### Hyundai refresh token: correct OAuth URLs (CTB flow)

The "Fetch token" button now works for Hyundai EU too. Background: in v2.16.0 and earlier, `services/vehicle/token_fetch.py` simply copied the Kia configuration for Hyundai and only swapped the domain — which could never work because Kia and Hyundai EU use **completely different OAuth flows** even though they both belong to the same parent company and build on the same `hyundai_kia_connect_api` library.

**The differences:**

| Field | Kia EU (oneid) | Hyundai EU (CTB) |
|---|---|---|
| Flow | oneid/online-sales on kia.com | CTB (Connected Car Telematics Business) on ctbapi.hyundai-europe.com |
| `login_client_id` | `peukiaidm-online-sales` | `peuhyundaiidm-ctb` |
| `login_redirect` | `www.kia.com/api/bin/oneid/login` | `ctbapi.hyundai-europe.com/api/auth` |
| `state` | Base64-URL + `_default` suffix | Short country code + `_` (e.g. `EN_`) |
| `redirect_final` | `.../oauth2/redirect` | `.../oauth2/token` |
| `client_secret` | Literal string `"secret"` | Real 48-character key `KUy49Xx...` |
| User-Agent | Mobile Android | Desktop Chrome |
| Extra authorize params | none | `connector_client_id`, `captcha=1`, `ui_locales`, `nonce` |

The old config had six out of seven fields wrong — only `client_id` was correct. The token exchange also always failed on the hard-coded `client_secret: 'secret'` because Hyundai's endpoint returns 401 on a wrong secret.

**Fix:**

- `services/vehicle/token_fetch.py` — `BRAND_CONFIG['hyundai']` completely replaced, `BRAND_CONFIG['kia']` explicitly given `client_secret: 'secret'` (previously hard-coded, now consistent). New field `user_agent` per brand (mobile for Kia, desktop for Hyundai, both retain the `_CCS_APP_AOS` suffix that bypasses the "use the app" block). New field `flow` per brand as discriminator. New helper function `_build_login_url(cfg)` builds the login URL per flow — CTB needs `connector_client_id`, `captcha=1`, `ui_locales` etc., which the Kia oneid flow doesn't know at all. The token exchange POST now pulls `cfg.get('client_secret', 'secret')` instead of the hardcoding.
- `services/vehicle/connector_hyundai_kia.py` — docstring updated, both connectors (Kia + Hyundai) again share the refresh token flow, but still have separate `credential_fields()` overrides for clean labels.
- `templates/settings.html` — `updateVehicleFields()` back to `isKiaHyundai` for the token-hint section and the refresh-token label. Hyundai users see the "Fetch token" button again (it was mistakenly hidden in v2.16.2, because at the time I thought Hyundai worked with password login).

**Sources**: two independent working scripts from the hyundai_kia_connect_api community (Hyundai Token Solution subfolder in the upstream repo + RustyDust/bluelink_refresh_token) confirm all values identically. Plus the library source itself (`KiaUvoApiEU.py`) with `CCSP_SERVICE_ID` and `CCS_SERVICE_SECRET` as runtime constants — they are validated on every subsequent API call, so guaranteed to be current.

The Kia flow stays **1:1 unchanged** except for the extraction of `client_secret` into the config — the working path is not touched.

## v2.16.2 (2026-04-15)

### Hyundai: login with password + PIN instead of refresh token

Until now, the app required a refresh token for both Kia and Hyundai (both ran through `CREDENTIAL_FIELDS` with the label "Refresh token"). For **Kia EU** that has been mandatory since 2025 because reCAPTCHA blocks direct password login, but for **Hyundai EU** the classic flow with email + password + 4-digit PIN still works.

Fix: split credential_fields per brand.

- `services/vehicle/connector_hyundai_kia.py` — two separate lists: `KIA_CREDENTIAL_FIELDS` (refresh token, help text refers to the token fetch button) and `HYUNDAI_CREDENTIAL_FIELDS` (normal password field). Both connector classes override `credential_fields()` with their own list.
- `templates/settings.html` — frontend logic in `updateVehicleFields()` splits `isKiaHyundai` into `isKia` and `isHyundai`. Token-hint section and "Refresh token" label now only for Kia (and Tesla) — Hyundai shows a normal "Password" field, no "Fetch token" button.
- Kia flow stays **exactly** as it is (untouched, works).

If Hyundai EU enables reCAPTCHA at some point too, this will surface with an auth attempt error and we'll have to push Hyundai into the token flow. For now user + password is enough.

## v2.16.1 (2026-04-15)

### Fix: /api/system/updates/status crashes on permission-denied on UU log

`/var/log/unattended-upgrades/unattended-upgrades.log` is by default `root:adm` with mode 640 — the ev-tracker user cannot read it. In v2.16.0 my code caught `PermissionError` only on `open()`, but not on the preceding `.is_file()` on the Path object (which also blows up on a 640 directory). Result: 500 on the status route, the card stayed at "Status is being loaded…".

Fix: `.is_file()` removed entirely, instead direct `open()` with a broad `except (FileNotFoundError, PermissionError, OSError)`. If the log is unreadable, the card just shows "never" as the last run — that's not an error, because the `pending_count` from the dry-run delivers the current info anyway.

## v2.16.0 (2026-04-15)

### System updates (Debian security-only) in the settings menu

New settings card "System updates (security)" between notifications and backup. Debian security updates can now be manually checked, installed from the browser, and a required reboot can be triggered — with minimal attack surface.

**Design decision: strict security-only.** No full apt access from the web UI. Reason: whoever cracks the web login would otherwise effectively get root on the OS (apt can install arbitrary packages + run post-install scripts as root). Instead, on the VM the Debian standard tool `unattended-upgrades` is set up, which pulls exclusively from `${distro_id}:${distro_codename}-security`. The sudoers rule allows the ev-tracker user exactly **one** command: `/usr/bin/unattended-upgrade -v`. An attacker with web login can at best trigger a security patch run — not install any package of their choice.

**New features:**

- Card shows: number of available security patches, date of last automatic run, "reboot required" warning banner when `/var/run/reboot-required` is present
- "Install security updates now" button starts `unattended-upgrade -v` in a background thread. The UI polls the status every 2.5 s and shows the log live.
- "Restart now" button only appears when a reboot is needed, with double confirmation (user has to re-enter the LUKS passphrase after boot)
- Unattended-upgrades continues to run normally on its own via Debian's `apt-daily.timer` and `apt-daily-upgrade.timer` — the UI is only the manual override plus status display

**Technical:**

- `services/system_update_service.py` — encapsulates reading the UU log (`/var/log/unattended-upgrades/unattended-upgrades.log`), counting pending updates (via `unattended-upgrade --dry-run -v`), the background thread runner for apply, and the reboot scheduler. State lives in a thread-safe module dict, no DB entry needed.
- `app.py` — new routes: `GET /api/system/updates/status`, `POST /api/system/updates/apply`, `POST /api/system/reboot`. All three behind the auth guard.
- `templates/settings.html` — new card plus a separate `<script>` block (following the same pattern as the notify card in v2.15.2, so a JS error higher up doesn't kill the sysupd handlers)
- **19 new translation keys** (`set.sysupd_*`) in all 6 languages

**Setup on the VMs (paste block as root):**

- `apt install -y unattended-upgrades` if missing
- Enable `/etc/apt/apt.conf.d/20auto-upgrades` (`APT::Periodic::Update-Package-Lists "1"; APT::Periodic::Unattended-Upgrade "1";`)
- Check `/etc/apt/apt.conf.d/50unattended-upgrades`: `${distro_id}:${distro_codename}-security` must be active, other origins must stay commented
- Add sudoers lines: `/usr/bin/unattended-upgrade -v`, `/usr/bin/unattended-upgrade --dry-run *`, `/sbin/shutdown -r now`

## v2.15.2 (2026-04-15)

### Fix: Notify card handlers no longer ran at all

v2.15.1 removed the `<form>` and switched the save button to `type="button"`. That prevented the reload, but now **nothing** happened on click — the button did not respond. Safari console confirmed: button element exists, but the click handler was not attached. That means: the IIFE did not run through to the `addEventListener`.

Cause likely: in the large `<script>` block of `settings.html`, Leaflet, location map and various forms run higher up. An error somewhere earlier blocked the parse of the notify IIFE in Safari. Backup form happened to still be OK (maybe a different code path), notify not.

Fix: the notify handler was pulled completely out of the large script and now runs in **its own `<script>` block at the end of the page**. No IIFE pyramiding, no Promise-based `.then()` instead of `async/await` (in case Safari has an edge case there), explicit `credentials: 'same-origin'` in the fetch calls, plus console.log at strategic points (`[notify] init start`, `[notify] handlers attached`, `[notify] save click`) so at the next problem, one immediately sees in the console what's happening.

## v2.15.1 (2026-04-15)

### Fix: Notifications card did not save

In v2.15.0 the notifications card was built as a real `<form>` element with a `<button type="submit">`. For reasons not yet understood, the JS submit handler did not fire in Safari (probably an ordering problem with a preceding IIFE in the same `<script>` block which in certain cases aborts further parsing). Effect: on click on "Save", the browser did a native form submit (GET without body), the page reloaded, the fields were empty again — even though the backend code and routes worked fine (verified directly via fetch from the DevTools console: POST and GET return `{ok:true, ...}`).

Fix is pragmatic rather than surgical: `<form>` → `<div>`, `<button type="submit">` → `<button type="button">` with a direct click handler. No more form-submit event = no possible reload, no matter what else happens in the script. Functionally identical, just without the hidden reload trap.

## v2.15.0 (2026-04-15)

### Push notification on VM restart (ntfy.sh)

The VMs on the NAS come back up automatically after a reboot (power outage, NAS update, manual restart), but the LUKS volume is sealed afterwards — the user has to manually open the unlock page in the browser and enter the passphrase. Problem: without a back channel, the user only notices that when he next opens the app. This version builds a lightweight push channel via **ntfy.sh**:

- New settings card **"Notifications"** (between access protection and backup). Checkbox to enable, field for the ntfy topic name, optional custom ntfy server, save and test button. The topic name is freely chosen; it is the only "secret" of the push channel — the UI explicitly notes to choose a hard-to-guess name.
- The user installs the free **ntfy app** (iOS/Android), subscribes to the same topic name there — done. No account, no server, no fees.
- **Config lives outside the LUKS volume** at `/var/lib/ev-tracker/notify.json`. That's important because the unlock helper (`ev-unlock-web`) runs exactly when LUKS is sealed — it could not read any config from the app DB. The folder is owned by `ev-tracker:ev-tracker` with mode 0750, so neither sudo nor root is needed. Trade-off: the topic name is in plaintext outside the encryption. Whoever has root on the VM can read it — but whoever has root has already won anyway, so that's acceptable.
- Technical: `services/notify_service.py` encapsulates reading/writing the JSON file (with fallback to `data/notify.json` for local development) and the actual HTTP POST via `urllib.request` — no curl, no additional dependency. New routes `GET/POST /api/settings/notify` (load/save config) and `POST /api/settings/notify/test` (test message).
- **15 new translation keys** per language in all 6 languages (`set.notify_*`).

**Setup on the VMs (paste block as root):**

Since the actual push has to fire from the boot path (before LUKS is unlocked, so outside the app updates), a small new systemd unit `ev-notify-boot.service` plus the helper script `/usr/local/bin/ev-notify-boot` comes with it. The unit runs as a oneshot before `ev-unlock-web.service`, but only if LUKS is still sealed (`ConditionPathExists=!/srv/ev-data/app/venv/bin/python`). It reads `/var/lib/ev-tracker/notify.json`, and if `enabled:true` and a topic is set, sends a single POST to `<server>/<topic>` with hostname + time in the message. If the POST fails → exit 0, so a down ntfy server can never block the boot.

## v2.14.0 (2026-04-15)

### Wizard step 2 becomes "create web login" + backup/restore feature

**Wizard rework**

The setup wizard on freshly provisioned VMs now has a different second step. Previously it wanted to change the `ev-tracker` unix SSH password, which cut exactly the admin SSH connection and made maintenance unnecessarily harder. Instead:

- **Step 1** stays: change the LUKS passphrase. User must perform this.
- **Step 2 NEW**: the user creates a **web UI user + web UI password**. The option to change the shell password is removed entirely — the shell user is left untouched, so the admin can still get onto the VM via SSH with the ev-provision temp password for maintenance. The web login is from now on the only way into the dashboard.

Technical details:

- `templates/setup.html` — step 2 completely reworked: input fields for username + password + confirm, submit now calls `POST /api/setup/create_web_login`. Progress pills and the step-welcome list name the new step. The wizard header now also shows the app version as a badge.
- `services/setup_service.py` — `change_user_password()` and the sudoers dependency on `chpasswd` are gone. Wizard state key is now `weblogin_done` instead of `password_done`. The module docstring is updated and explicitly states that the wizard **does not** touch the unix login.
- `app.py` — new endpoint `POST /api/setup/create_web_login` replaces `POST /api/setup/change_password`. It calls `auth_service.set_credentials()` (which automatically arms the guard), logs the user in directly, and cleans up the setup marker on completed wizard state combination. `app_version` is now also passed through to the wizard template.

Settings → access protection stays unchanged and allows the user at any time to change, add or deactivate his web user/password.

**Database backup & restore**

New feature for VM migrations, backups and recovery after errors:

- New settings card "Backup & restore" (placed between access protection and app info).
- **Export**: `GET /api/backup/export` flushes the SQLite WAL via `PRAGMA wal_checkpoint(TRUNCATE)` and sends the complete `data/ev_tracker.db` as a download with timestamp in the filename (`ev-tracker-backup-YYYYMMDD-HHMMSS.db`). Contains absolutely everything: charges, trip log, maintenance log, AppConfig (incl. vehicle API credentials, home/work coordinates, ENTSO-E key, THG quotas, access-protection hash, session secret), geocode and weather cache, VehicleSync history. A single file.
- **Import**: `POST /api/backup/import` as multipart upload. Validates the file as a real SQLite DB and checks that the required tables `charges`, `app_config`, `vehicle_syncs` are inside. Before overwriting, creates a safety copy of the current DB in `data/backups/ev_tracker-pre-import-<ts>.db`, then closes the SQLAlchemy engine (important on POSIX, otherwise the old inode keeps the DB alive) and copies the new DB over. Then background thread with 500ms delay → `sudo systemctl restart ev-tracker.service`. The browser reloads automatically after 4.5 seconds.
- **Warning in the UI** is deliberately drastic: the import overwrites access-protection credentials and vehicle API keys. After an import, the web login from the backup applies, not the previous one.

New in `config.py`: `DATA_DIR` is now exported so `app.py` can resolve the DB path cleanly for the export/import routes.

**Translations**

25 new keys in all 6 languages (de/en/fr/es/it/nl): `wiz.welcome_step1_luks`, `wiz.welcome_step2_weblogin`, `wiz.weblogin_title`, `wiz.weblogin_desc`, `wiz.weblogin_username`, `wiz.weblogin_password`, `wiz.weblogin_password_hint`, `wiz.weblogin_password_confirm`, `wiz.weblogin_info`, `wiz.weblogin_submit`, `wiz.status_creating`, `wiz.err_user_empty`, and 13 `set.backup_*` keys.

**Upgrade on running VMs**

The old tags v2.11.x / v2.12.0 / v2.13.0 were deleted and `main` was reset to the v2.9.0 commit. Running VMs that previously had one of these versions can no longer get to the current main via `git pull` (history has been rewritten). Instead `git fetch origin && git reset --hard origin/main` — see the upgrade paste block in the release notes.

## v2.9.0 (2026-04-14)

### Translations for all v2.7.x/v2.8.x features + HTTPS autohide + README

- **60 new translation keys** in all 6 languages (de/en/fr/es/it/nl) — covers the setup wizard (`wiz.*`), the login page (`login.*`) and the access-protection block in the settings (`set.auth_*`). With that, all new features from v2.7.0–v2.8.1 are fully localized.
- **Setup wizard (`templates/setup.html`)** now uses `t()` instead of hardcoded German — title, welcome, both wizard steps, done screen, error messages and button texts.
- **Login page (`templates/login.html`)** is fully translated including footer text.
- **Access-protection block in settings** translated including error messages and disable-confirm dialog.
- **HTTPS autohide**: If the request comes from the Tailscale CGNAT range (`100.64.0.0/10`), `/settings` hides the entire HTTPS card. Tailscale already encrypts the transport — a self-signed certificate on top is just noise. Direct LAN or localhost access still sees the card as before.
- **README updated** with sections on web UI login, first-run setup wizard, VM deployment flow and the systemd awareness of the in-app updater. String count updated to ~540 per locale.

## v2.8.1 (2026-04-14)

- **Dashboard: average line in the SoH plot** — The SoH chart in the vehicle history gets a horizontal grey dashed line with the mean of all displayed measurement points. Makes drift/trends visible at a glance. The mean is shown in the legend below the chart as `Ø xx.x%`. Only active when ≥3 data points are present. Other charts stay unchanged.

## v2.8.0 (2026-04-14)

### Optional: Web UI login as a gatekeeper page

Tailscale protects network access — but whoever knows the share link and is in the tailnet lands in the dashboard without further hurdles. This release brings a built-in password gatekeeper page as defense-in-depth:

- **Optional**: off by default. Whoever wants it enables it in Settings → "Access protection". Existing installs are unchanged after update, nobody is locked out of their own app.
- **Integrated**: part of the app, not shoved in front of the app. Updates from the GitHub repo roll through normally and don't break auth.
- **Session cookies**: Flask sessions with a per-install generated 32-byte secret persisted in AppConfig (see `services/auth_service.py:get_or_create_session_secret`). 30-day lifetime.
- **Password hashing**: Werkzeug `generate_password_hash` / `check_password_hash` (bcrypt-compatible). Plaintext never lands on disk.
- **Simple UX**: simple username+password login, no email, no account management. Single flow for the one-person case.

New endpoints: `/login`, `/logout`, `/api/auth/enable`, `/api/auth/disable`, `/api/auth/change_password`. Guard runs as a `before_request` hook in parallel with the setup-wizard guard — setup has priority, so a freshly provisioned user can first get through the wizard without already being auth-configured.

The prerequisite for real security is still that the VM is only reachable via Tailscale (UFW only on `tailscale0`). The app login is the second layer after the VPN.

## v2.7.4 (2026-04-14)

- **Setup wizard: LUKS device detection without root privileges** — `get_luks_device()` previously called `cryptsetup status evdata`, but that has to open `/dev/mapper/evdata`, which on Debian belongs to `root:disk 660`. The app user `ev-tracker` is not in the `disk` group, so the call failed with Permission denied. Consequence: the wizard footer showed "LUKS device: (unknown)" and — much more seriously — the actual passphrase change aborted with "LUKS device not found". Now the path is resolved via **sysfs**: `/dev/mapper/evdata` → `dm-N` → `/sys/block/dm-N/slaves/` → parent block device. Sysfs is world-readable, so this needs neither sudo nor group membership.

## v2.7.3 (2026-04-14)

- **Setup wizard: make the browser redirect reliable** — The `before_request` hook checked the `Accept` header to distinguish browser accesses from API calls. That was too fragile: depending on browser/Accept header, the user landed on the JSON response `{"error":"setup_pending",...}` instead of the wizard. Now it's simple: all GET requests are redirected to `/setup` during setup, only non-GET (POST/PUT/DELETE) still get the JSON 503 response for API clients.

## v2.7.2 (2026-04-14)

- **Setup wizard explicitly restricted to Linux** — `is_setup_pending()` now hard-returns `False` on macOS and Windows, without even checking the marker path. In practice that was already the case (the path `/srv/ev-data/.setup_pending` doesn't exist on non-Linux hosts anyway), but now it's also clearly documented in the code that the wizard is VM-specific. Additionally protects against the edge case where somebody accidentally creates a file under the path and thereby triggers the wizard even though the necessary `sudo cryptsetup`/`chpasswd` commands don't exist.

## v2.7.1 (2026-04-14)

- **Setup wizard: second step for the SSH login password** — The first-run wizard now takes, alongside the LUKS passphrase, a new login password for the `ev-tracker` user. Under the hood calls `sudo chpasswd` (needs an additional NOPASSWD sudoers entry for `/usr/sbin/chpasswd`). Wizard progress is tracked in `/srv/ev-data/.setup_state.json` so a mid-wizard reload puts the user seamlessly at the next open step instead of asking for LUKS again. Only when both steps are done is the marker deleted and the dashboard released. With that, the admin can forget both temp credentials after provisioning — the user is fully self-sufficient.

## v2.7.0 (2026-04-14)

### First-run setup wizard for VM deployments

Previously the end user of a freshly provisioned VM had to SSH in and manually run `sudo cryptsetup luksChangeKey /dev/sdb` to replace the temporary LUKS passphrase. That was a big hurdle for non-technical users. Now a setup wizard automatically appears on first browser access:

1. The provisioning pipeline (`ev-provision`) creates a marker `/srv/ev-data/.setup_pending` at the end.
2. A `before_request` hook redirects all non-setup requests to `/setup` as long as the marker exists.
3. The wizard (a single-page HTML wizard UI in `templates/setup.html`) prompts for the temp and the new passphrase, calls `sudo cryptsetup luksChangeKey` on the device from the running `cryptsetup status evdata`, and removes the marker on success.
4. After a successful change, the user has "arrived" — from that moment on nobody but the user knows the passphrase, not even the admin.

The wizard is German-only in its text (setup is a one-time flow and the target audience is German users), the rest of the app stays translated as before. Non-VM hosts (e.g. developer laptops) are unaffected because the marker never exists.

**Requirement for live operation**: `ev-provision` has to create the marker at the end and set the sudoers rule for `cryptsetup luksChangeKey`. Both are documented in the admin guide; for existing VMs, retrofit once.

## v2.6.0 (2026-04-14)

### Fix the in-app updater under systemd

On Linux installations with `ev-tracker` as a systemd service, the update button via the app UI effectively did nothing: click → brief "Update is being installed" display → after refresh still the old version. Root cause: the updater spawns a detached `updater_helper.py` process that is supposed to do the file swap after the Flask process exits. Under systemd, the helper lands in the **same cgroup** as the service — and when systemd kills the service for restart, the helper is dragged along **before it has swapped the files**. Result: service restarts, nothing has changed.

Fix: systemd is now detected (via `INVOCATION_ID` or `/run/systemd/system`), and in that case the file swap runs **inline in the Flask process** before it exits. Python bytecode is already in RAM, so overwriting the `.py` files on disk is safe. `pip install -r requirements.txt` runs synchronously, then `os._exit(0)` — and `Restart=always` in the systemd unit ensures the service comes back up with the new code.

For standalone installations (macOS, Windows, or Linux without systemd), the existing helper path stays unchanged.

## v2.5.9 (2026-04-13)

- **Kia/Hyundai token fetch: Selenium flow made fit for headless Linux environments** — On VMs without a DBus session (e.g. server installs with Xvfb+noVNC for the login flow), the Selenium-based token fetch stumbled several times: (1) Chromium crashed with "DevToolsActivePort file doesn't exist" due to missing `--no-sandbox` / `--disable-dev-shm-usage` flags, (2) `webdriver-manager` pulled an outdated ChromeDriver version (max 114) that didn't fit modern Chromium 147, (3) Debian's Chromium lives under `/usr/bin/chromium` instead of `/usr/bin/chrome`, which Selenium didn't find automatically.
- Fix: `webdriver-manager` completely removed in favour of the built-in **Selenium Manager** (from Selenium 4.11), which pulls the matching ChromeDriver automatically. Chromium binary path is now automatically detected from `/usr/bin/chromium|chromium-browser|google-chrome`. Sandbox and shared-memory flags are always set. Requirement bumped where needed to `selenium>=4.11`.

## v2.5.8 (2026-04-12)

- **Trip log: regen column was always empty** — On every movement detection, `prev.departed_at` and `curr.arrived_at` are the same sync timestamp (the moment movement was detected), so the cumulative regen delta was always 0. The departure now anchors on `prev.last_seen_at` (last confirmed sync at the old spot before departure), the arrival stays `curr.arrived_at` — so the delta calculation spans two different syncs.

## v2.5.7 (2026-04-11)

- **Charge and regen cycles as whole numbers** — `charge_cycles` and `recup_cycles` in `get_summary_stats` now round to whole cycles instead of one decimal place. Fractional cycles make no intuitive sense; a whole cycle is the unit.

## v2.5.6 (2026-04-11)

### Hybrid recuperation: keep the km × 0.086 estimate, layer measured on top

v2.5.4/5 replaced the full lifetime recuperation with the tiny measured cumulative (6.92 kWh for the first 92 km of tracking), which threw away years of historical km where the old `km × 0.086` estimate was the best number available.

This release uses a hybrid:

- **km before the first vehicle sync** → `first_sync_odometer × static_rate` (default 0.086 kWh/km, still configurable in Settings)
- **km from that point on** → real measured `regen_cumulative_kwh` from the vehicle API

Result on a real Kia Niro dataset: `82217 × 0.086 + 6.92 = 7077.6 kWh` — matches the pre-v2.5.4 lifetime total, and from here on grows only via measured values as the car drives.

- The Recuperation KPI card now shows `7.071 + 6.9 (kumuliert)` to make the split obvious.
- The measured rate (0.075 kWh/km from the last 90d) is still shown with the broadcast icon — that's the *current driving efficiency*, separate from the historical baseline.
- The "Gemessene Rekuperation" card remains unchanged: it only shows real per-period measurements and never touches the historical km × 0.086 portion.

## v2.5.5 (2026-04-11)

### Regen scale hotfix: raw is Wh, not hundredths of kWh

v2.5.4 divided the raw Kia/Hyundai `total_power_regenerated` by 100, which still left values 10× too high. The actual unit is **Wh** (watt-hours) for a rolling 3-month window — the correct divisor is **1000**. On a real Kia Niro EV dataset the v2.5.4 values showed a regen rate of 0.75 kWh/km (physically impossible); after this fix the rate settles at ~0.075 kWh/km (matches the car's spec).

- **`_build_vehicle_sync`** now divides by 1000.0 instead of 100.0.
- **New migration `regen_scale_fix_v2`** applies a second `/10` pass on `total_regenerated_kwh` — so pre-v2.5.4 rows (already `/10`'d by v1) land on `/100` total, and v2.5.4 rows land on `/10`. Both converge on the correct `raw/1000` kWh scale.
- **`regen_cumulative_kwh` is wiped and recomputed** after the v2 migration so the monotonic series matches the corrected inputs.
- Live vehicle widget and dashboard "Gemessene Rekuperation" card now show realistic numbers.

## v2.5.4 (2026-04-11)

### Rekuperation: korrekt interpretiert, kumuliert, pro Fahrt

The Kia/Hyundai API returns `total_power_regenerated` as **hundredths of kWh for a rolling 3-month window** — not lifetime, not tenths. Every stat that touched that value was previously off by a factor of 10 and mistook the rolling window for a cumulative total. This release fixes the interpretation and builds real per-period / per-trip statistics on top of it.

#### Data fix
- **Divisor corrected** in `_build_vehicle_sync` ([app.py](app.py)): raw value is divided by **100** (not 10). A raw reading of `21534` now stores the correct `215.34 kWh` instead of `2153.4 kWh`.
- **One-time migration** on startup divides every existing `vehicle_syncs.total_regenerated_kwh` by 10 to retroactively fix rows written under the old scale. Gated by `regen_scale_fix_v1` in AppConfig so it only runs once.
- **New column `regen_cumulative_kwh`** on `vehicle_syncs` — monotonically increasing "measured regen since first sync". Built from delta-walking the raw series: positive deltas add up, rollovers (new raw < previous raw, meaning a month fell off the 3-month window) contribute 0. Backfilled for existing rows automatically on first boot after upgrade.

#### Dynamic recuperation rate
- **`kWh/km` recuperation rate is now measured from the last 90 days of vehicle syncs** (cumulative regen delta / odometer delta) instead of the hardcoded `0.086`. Falls back to the configured static value when there's no vehicle data. Settings page shows a green "automatisch" badge + the measured rate when in use.
- `get_summary_stats` now prefers the real measured lifetime cumulative over the extrapolated `total_km * recup_rate` estimate whenever vehicle history is available.

#### New `get_regen_stats()`
- Returns measured recuperation aggregated by: **today, this week, this month, last 30d, last 90d, this year, lifetime**, plus `km_equivalent` (lifetime regen converted to km at the car's actual consumption).
- Uses `bisect` lookups against a single sorted pull of the cumulative series — O(log n) per query.

#### Per-trip recuperation
- Each trip in `get_trips()` gets a `regen_kwh` field via cumulative-at-timestamp lookups at `departed_at` and `arrived_at`.
- Trip summary (`get_trip_summary`) adds `total_regen_kwh` and `regen_per_km` across the visible window.
- New **Rekup** column in the `/trips` table and in the PDF Fahrtenbuch table (80 most recent trips).

#### Dashboard
- New **"Gemessene Rekuperation"** card directly under the KPI grid: 6 period cards + km-equivalent, only shown when vehicle sync data exists.
- **Recuperation KPI card** now shows the measured `kWh/km` rate instead of the configured one, plus a `bi-broadcast` icon when the rate is being pulled live from the car.
- **Vehicle-history Regen chart** switched from the rolling 3-month raw value (which fluctuates month-to-month) to the monotonic cumulative, so the line actually grows instead of wiggling.
- **Live vehicle widget** label updated to `Rekuperiert (3 Mon.)` and the double `/10` bug fixed — the widget now shows the correct kWh value.

#### PDF report
- New page **"Gemessene Rekuperation"** with an 8-cell KPI table (today / week / month / 30d / 90d / year / lifetime / km-equivalent) + the auto-detected rate.
- Fahrtenbuch table gets a **Rekup** column (column widths adjusted).
- Vehicle-history "Rekuperation gesamt" chart title updated to "Rekuperation (gemessen, kumuliert)".
- `regen_delta` summary line on the vehicle-history page is now labelled "Rekup. kumuliert".

#### Translations
- 13 new keys × 6 languages for the regen period cards, the settings badge, and the trips column.

## v2.5.3 (2026-04-10)

### Cross-platform polish

- **Windows: startup banner & emoji log lines** — `app.py` reconfigures stdout/stderr to UTF-8 with `errors='replace'` at import time, so `python app.py` in a legacy cmd code page no longer raises `UnicodeEncodeError` on the "⚡ EV Charge Tracker" banner. `start.bat` already set `chcp 65001` for its own window, but manual launches from an unconfigured shell now survive too.
- **Linux: IP discovery in `start.sh`** — now tries `ip -4 -o addr show scope global` first (modern distros), then `hostname -I` (glibc), then `ifconfig` (BSD / macOS / older). Each branch is tolerant of missing binaries. Previously Alpine/BusyBox machines saw an empty "Smartphone-URL" line for no good reason.
- **Updater: restore exec bit after update** — GitHub source zips strip the POSIX exec bit, so after an in-app update `./start.sh` was no longer directly executable on Linux/macOS. [`updater_helper.py`](updater_helper.py) now `chmod +x`'s `start.sh` and `start.command` right after the file swap on non-Windows platforms.
- **`datetime.utcnow()` → timezone-aware** — `services/ssl_service.py` replaces the deprecated call with `datetime.now(timezone.utc)` for cert generation. `get_cert_info()` also handles both `not_valid_before`/`after` (cryptography <42) and `not_valid_before_utc`/`after_utc` (>=42) so it works across versions without a DeprecationWarning.

## v2.5.2 (2026-04-10)

### Unified vehicle sync log line
- **Every vehicle sync now logs the same structured one-liner** regardless of which code path triggered it:
  ```
  Vehicle sync [smart->force, src=bg-loop]: SoC=73%, odo=14283km, GPS=yes, charging=False, api=34/200
  ```
- **mode** reflects the actual API mode that was used:
  - `cached` / `force` for the straight modes
  - `smart->cached` (smart mode ran cached because GPS fresh or car charging)
  - `smart->force` (smart mode escalated to force because GPS stale and not charging)
- **src** reflects the caller, so you can tell which trigger caused the call:
  - `bg-loop` — background sync service (the 10-min smart cadence)
  - `trips-auto` — auto-fresh on `/trips` page load (background thread)
  - `manual` — "Jetzt synchronisieren" button on the trips page
  - `settings` — "Sync (Cached)" / "Sync (Live)" buttons in Settings
  - `dashboard` — the cached/live refresh on the dashboard widget
- **GPS=yes/no** — whether the response carried a location (important for the Fahrtenbuch; Kia cached mode usually returns `no`).
- **api=N/200** — current daily API counter right after the call, so you can see budget burn in real time in the `/logs` feed.
- New helper `log_sync_result()` in [services/vehicle/sync_service.py](services/vehicle/sync_service.py) is the single source of truth — all five call sites now route through it.

## v2.5.1 (2026-04-10)

### Live log viewer
- **New `/logs` page** with its own nav entry. Shows whatever the app's Python loggers emit: vehicle sync activity, parking hook decisions, Nominatim reverse lookups, updater events, ENTSO-E calls, errors — everything that used to only be visible in the terminal.
- **In-memory ring buffer** (last 2000 records) via a custom `RingBufferHandler` attached to the root logger on startup. Thread-safe, zero disk I/O, zero config. New file: [services/log_service.py](services/log_service.py).
- **Live polling** every 2 s via `/api/logs?after=<last_id>` — only new records cross the wire, so the tab stays cheap even when it's sitting open all day. Delta-based, not a full re-fetch.
- **HTTP access logging is opt-in**, toggle in the toolbar. Off by default (keeps the feed clean); flip it on and every `GET /api/...` line from werkzeug shows up too. The preference is persisted in AppConfig (`log_show_requests`) so it survives restarts.
- **Toolbar controls**: auto-refresh on/off, auto-scroll on/off, level filter (DEBUG+ / INFO+ / WARNING+ / ERROR+), free-text filter (matches logger name + message), clear, download as `.log` file.
- **Color-coded by level** — DEBUG grey, WARNING amber, ERROR red, CRITICAL bold red — in both light and dark mode. Monospace font, timestamp with milliseconds.
- `POST /api/logs/clear` and `POST /api/logs/requests` round out the API.

### Translations
- 11 new keys × 6 languages.

## v2.5.0 (2026-04-10)

### Fahrtenbuch: honest numbers, smarter sync, real addresses

#### Dropped misleading trip duration / avg-speed
- **Trip duration, "Fahrzeit" KPI and "Ø km/h" column removed.** With any realistic polling cadence the "arrived_at" of the next parking event is off by up to the sample interval, so any duration/speed number was a fiction. What we report now is what we actually know: **km from the odometer** and **SoC used**.
- PDF "Fahrtenbuch" table drops min / km-h columns and widens From / To columns instead.
- Highlights page drops "Schnellste Fahrt"; "Längste Fahrt" shows km only.
- CSV export drops the dauer/km-h columns.

#### Smart-sync active window
- **New `smart_active_start_hour` / `smart_active_end_hour` / `smart_active_interval_min`** AppConfig keys (defaults 6 / 22 / 10). Fully configurable from Settings → Vehicle API (the new row appears when `Smart` mode is selected).
- Smart mode now runs **every 10 min between 06:00 and 22:00 by default** and **does not sync at all at night** — better granularity for catching real movement without burning the 190/200 daily Kia quota and without waking the car's 12V battery while you sleep.
- With the default 10 min × 16 h = ca. 96 cached calls/day plus the existing "force if GPS stale >6 h and not charging" logic for the Live upgrades. Settings hint shows the math next to the row.
- `_compute_sleep_secs()` in [services/vehicle/sync_service.py](services/vehicle/sync_service.py) handles both smart-window and the legacy hourly cadence for `cached`/`force` modes. Outside the window the loop sleeps until the window opens without firing any API calls.
- Interval options: 5 / 10 / 15 / 20 / 30 / 45 / 60 min. Minimum hardcoded to 5 min.

#### Unknown locations are always resolved to an address / POI
- **No more raw `53.12, 10.45` coordinates** in the Fahrtenbuch. Every parking event gets its `address` field populated via Nominatim reverse-geocoding. POIs (shops, restaurants, parking lots) are captured too because Nominatim's `display_name` leads with the POI name when one exists.
- **Background worker** fires on every `/trips` page load and fills addresses for any parking event that doesn't have one yet (up to 50 per run, 1 req/s per Nominatim ToS, permanent DB cache → after the first full pass it's a no-op).
- **New `POST /api/trips/geocode_missing`** for manual re-trigger.
- Trips table now shows: 🏠 Zuhause / 💼 Arbeit / ⭐ Favorit / full street address — never raw coordinates. While a new event is waiting to be resolved, the row shows "Adresse wird ermittelt…".
- New `geocode_missing_events()` helper in `services/trips_service.py`.

### Translations
- 8 new keys × 6 languages (`trips.home`, `trips.work`, `trips.resolving`, `set.api_smart_window_label`, `set.api_smart_from`, `set.api_smart_to`, `set.api_smart_every`, `set.api_smart_hint`).

## v2.4.3 (2026-04-09)

### Trips page is fast again
- **Background auto-fresh** — the live vehicle sync that runs when you open `/trips` no longer blocks page rendering. It now runs in a daemon thread, so the page renders in ~12 ms instead of 5-10 s waiting for Kia to wake the car. The page will show whatever GPS data we already have; the background sync drops in updated data that will appear on the next reload.
- **Threshold raised** from 30 minutes to 2 hours. With smart-mode enabled and the background-fresh debounce, the API counter doesn't get burned on every visit during the day.
- **5-minute debounce** so two `/trips` visits in quick succession only kick off one background sync (and the second one isn't told a stale "in flight" sync was a fresh sync).
- **GPS freshness indicator** in the toolbar: "GPS vor 12 min", "GPS vor 3 h", "GPS vor 2 Tagen". You can see at a glance how stale the map data is and decide whether to hit "Jetzt synchronisieren" manually.

### Translations
- 3 new keys × 6 languages.

## v2.4.2 (2026-04-09)

### Fahrtenbuch — actually working with sparse Kia polling

This release fixes a stack of subtle bugs that prevented parking events from being created on a real-world database with the Kia/Hyundai cached-mode sync.

#### Root cause fix
- **Parking hook now runs on EVERY save**, not only when `differs_from(last)` returns True. Previously, a force-refresh that delivered the *same* GPS coordinates as the existing latest row (because the car hadn't moved) would skip the hook entirely — so no parking event was ever created. Fixed in `_save_vehicle_sync` ([app.py](app.py)).

#### Backfill
- New `backfill_parking_events()` in `services/trips_service.py` replays every existing `VehicleSync` row chronologically through the parking hook. This catches up databases populated before v2.3.0 (no hook) or after weeks of cached polling where the hook only fired occasionally.
- **Auto-runs on startup** if the parking_events table is empty AND there is at least one VehicleSync row with GPS data.
- **`POST /api/trips/backfill`** for manual triggering. New "Aus Historie nachbauen" button on the `/trips` page.

#### Smart sync mode
- New `'smart'` option in Settings → Vehicle API alongside `cached` and `force`.
- Smart mode runs cached by default but **upgrades to a force-refresh when the latest GPS-bearing sync is older than 6 h** (configurable via `smart_force_max_hours`) and the car is not currently charging. This catches movement without burning the 12V battery on every cycle.
- Tracks `last_force_refresh_at` so the smart-mode decision logic has something to compare against.

#### Tighter trip durations
- New `last_seen_at` column on `parking_events` is updated on every sync that confirms the same position. The trip-duration calculation now uses `last_seen_at` of the previous event as the lower bound instead of `arrived_at`, which would have overstated the trip duration by the entire parking spell.
- Auto-migrated on startup.

#### Trips page auto-fresh
- Opening `/trips` automatically triggers a force vehicle sync if all of these are true: a brand is configured, auto-sync is enabled, the brand supports GPS (per the feature matrix), the latest GPS sync is >30 min old, and the daily API counter is below 180/200. Skipped silently otherwise. Means the map is current the moment you open the page.

#### Manual sync button
- **"Jetzt synchronisieren"** button on `/trips` triggers an immediate force refresh and reports back whether GPS came through or not.

#### Settings UX
- **Warning banner** when sync mode is `cached` and brand is Kia/Hyundai: "GPS für Fahrtenbuch erfordert Smart oder Live, oder manueller Sync (Live)".
- Last-sync line in Vehicle API card now shows a 📍 icon when the most recent row has GPS data.

### Translations
- 13 new translation keys × 6 languages.

## v2.4.1 (2026-04-09)

### Restart button
- **New "App neustarten" button** in Settings → App-Info, plus an inline "Jetzt neustarten" button that appears after saving HTTPS settings or generating a new certificate. No more manual `start.command` after switching HTTPS mode.
- **Restart-only mode** for `updater_helper.py`: `--staging-dir` is now optional. Without it the helper skips the file swap and the pip install, just waits for the parent PID and spawns a fresh `venv/bin/python app.py` with the same nohup-wrap, env-strip, and health check as the update flow.
- **`POST /api/restart`** triggers the same delayed-shutdown pattern as `/api/update/install`, and the Settings page polls until the app is back online and reloads the browser.

## v2.4.0 (2026-04-09)

### HTTPS / TLS support
- **Self-signed certificate** auto-generation via the `cryptography` library (preferred) or `openssl` CLI (fallback). Cert is stored in `data/ssl/server.{crt,key}` and reused across restarts. SAN entries cover `localhost`, `127.0.0.1`, and the LAN IP, so the same cert works on desktop AND smartphone.
- **Three modes** in Settings → "HTTPS / Sicherheit": `off` (HTTP), `auto` (self-signed), `custom` (paths to your own Let's Encrypt cert).
- **Cert metadata viewer** — subject, valid-until date, SHA256 fingerprint shown in the UI. Parsing falls back from `cryptography` to `openssl x509 -text` so it works without the library.
- **"Cert herunterladen"** button serves the public cert as a `.crt` download — install it on your iPhone/Android via Profile to get rid of browser warnings permanently.
- **HTTP/insecure warning** banner in Settings if the user accesses the app over HTTP from a non-localhost address (Geolocation API and PWA features won't work over plain HTTP).

### Brand feature matrix
- New `services/vehicle/feature_matrix.py` with hand-curated capabilities for all 14 brands across 10 features (SoC, GPS, 12V battery, SoH, recuperation, 30-day consumption, doors/locks, climate, tire pressure, live status).
- **`/api/vehicle/features/<brand>`** returns the matrix for the selected brand.
- **Settings → Vehicle API** shows a 10-item grid with green/yellow/red indicators when a brand is picked. No more "wait, why isn't my Polestar showing recuperation data" surprises.

### Tesla connector expansion
- **Tire pressure warnings** computed from `tpms_pressure_*` vs `tpms_rcp_*_value` recommended pressures.
- **Climate detail**: defrost, rear window heater, steering wheel heater.
- **Software update detection** via `vehicle_state.software_update.status`.
- **Charging session detail**: `minutes_to_full_charge`, `charge_energy_added`, charger voltage and current — exposed in `raw_data`.
- **Sentry mode state** for the security-conscious.

### Manual location for charges
- **Charge form** ([templates/input.html](templates/input.html)) gets a new "Standort der Ladestation" section with:
  - Free-text location name (e.g. "Aldi Berlin Mitte", "Ionity A2")
  - Lat/lon fields
  - **"Mein Standort"** button uses the browser's Geolocation API (works on smartphones over HTTPS or on localhost)
  - **"Zuhause"** / **"Arbeit"** quick-fill from your saved Settings locations
  - Reverse-geocoding via Nominatim auto-fills the name field if you didn't type one
  - **Clear** button
- Captured charges feed the existing `Charge.location_lat/lon/name` columns, which the **charging stations memory** in the highlights service already groups by location for "cheapest stations on my regular routes".

### Database
- New `AppConfig` keys: `ssl_mode`, `ssl_custom_cert`, `ssl_custom_key`. Auto-created on first save.

### Dependencies
- Added `cryptography>=42.0.0` to `requirements.txt` (previously optional via openssl CLI).

### i18n
- 47 new translation keys × 6 languages.

## v2.3.4 (2026-04-09)

### Favorites picker — visible feedback + diagnostics
- **Crosshair cursor + blue outline** on the map when in pick mode (home/work/favorite). Previously the user had no visual confirmation that the map was waiting for a click.
- **Console logging** of every step in the favorites flow (pickMode transitions, map clicks, POST results) so issues can be debugged from browser DevTools.
- **`e.preventDefault()` + `e.stopPropagation()`** on `btnAddFav` click — defensive against any parent form swallowing the event.
- **Auto-focus the name field** when "Bitte Name eingeben" warning fires.
- **Status message includes coordinates and name** after a favorite is saved, so the user sees concrete confirmation.
- **Refactored map click handler** into a named `handleMapClick` function with explicit early returns per branch — easier to reason about and reduces the chance of state bleed between branches.

## v2.3.3 (2026-04-09)

### The actual updater fix (root cause)
- **`debug=True` → `debug=False` in `app.py`** — the Werkzeug auto-reloader passes a listening socket to its child via the `WERKZEUG_SERVER_FD` environment variable. That env var was propagating from the dying Flask through `os._exit` → `updater.py` → `updater_helper.py` → freshly-spawned Flask, where `socket.fromfd(WERKZEUG_SERVER_FD)` then crashed with `OSError: [Errno 9] Bad file descriptor`. For a self-hosted app, debug mode is the wrong default anyway.
- **Helper strips `WERKZEUG_*` env vars** before spawning, as belt-and-suspenders for older `app.py` files that still have `debug=True`.

### Fixes
- **Favorites can now be set on the map** — the `btnAddFav` button was missing `type="button"` and used a brittle one-shot click handler. Both fixed: button now has explicit type, and the favorites flow uses the same `pickMode` pattern as home/work picking. Pressing Enter in the favorite name field now also triggers add-mode. Errors are logged to status with the actual response code.

## v2.3.2 (2026-04-09)

### Updater fixes (the actual restart problem)
- **`nohup`-wrap the new Python process**, not just the bash launcher. macOS Terminal.app sends SIGHUP to *every* process in its session when the window closes, even processes that called `setsid`. The v2.3.1 fix bypassed `start.sh` correctly but the bare `python app.py` was still vulnerable. v2.3.2 wraps it in `/usr/bin/nohup` which sets `SIG_IGN` for SIGHUP — survives terminal close.
- **Health check after spawn** — the helper now waits 4 seconds, verifies the spawned process is still alive (`p.poll() is None`), and probes port 7654 with a TCP socket. Failure is logged with the exit code instead of being silent.
- **More verbose logging** — every step in `_restart_app` is timestamped so future failures are debuggable from `updates/restart.log` alone.

## v2.3.1 (2026-04-09)

### Updater fixes
- **Helper restarts the app reliably** — `updater_helper.py` now spawns `venv/bin/python app.py` directly instead of going through `start.command` → `start.sh`. This bypasses the redundant pip install loop and the `set -e` shell pitfalls, dropping restart latency from ~15 s to ~3 s.
- **Port-release race fix** — wait 2 s after the parent Flask process dies before binding the port again, so we can't hit `EADDRINUSE`.
- **Restart log** — every restart attempt is logged to `updates/restart.log` with timestamps and stdout/stderr of the spawned process. Previously failures were silent because output went to `/dev/null`.
- **`_spawn_helper` prefers the staging helper** — `updater.py` now launches `staging/.../updater_helper.py` (the new release) instead of the in-place helper, so future updater bugfixes take effect on the very first update that ships them.

## v2.3.0 (2026-04-09)

### New Features

#### Driving log / Fahrtenbuch
- **Auto-detected parking events** — every vehicle sync hooks into a new `ParkingEvent` log. The car's location is checked against the last open event; >100 m means "moved", a new event is opened, the previous one is closed with arrival/departure odometer + SoC.
- **Home / Work / Favorites picker** — click on a Leaflet/OpenStreetMap card in Settings to set your home and work coordinates (drag-to-fine-tune supported). Optional named favorites for parents, vacation home, etc. All parking events are auto-classified as `home`/`work`/`favorite`/`other` with a 200 m radius. Reclassification runs whenever you change a location.
- **Trips page** at `/trips` — KPI cards (count, total km, drive time, commute km), Leaflet map with marker clustering colored by location label, full trips table with from/to/km/duration/avg-speed/SoC.
- **CSV + GPX export** — `/api/trips/export.csv` for the tax advisor, `/api/trips/export.gpx` for Google Earth / Komoot / OsmAnd.
- **PDF report** gets a new "Fahrtenbuch" section with the last 80 trips and a header showing home↔work km (relevant for German Pendlerpauschale).

#### Maintenance log / Wartungs-Logbuch
- **New `/maintenance` page** — track inspections, tires, brakes, wipers, 12V battery, cabin filter, MOT/TÜV with date, odometer, cost and free-text notes.
- **Smart reminders** — every entry can have a `next_due_km` and/or `next_due_date`. The page surfaces a "due soon / overdue" banner; the form auto-fills sensible defaults (e.g. inspection = 12 months / 30 000 km).
- **PDF report** gets a "Wartungs-Logbuch" section with the full history and total cost.

#### Charging stations memory
- **Lat/lon/name on `Charge`** — the input form now optionally captures the location of a charge.
- **`/api/highlights` returns charging stations** grouped by rounded coordinates with cheapest €/kWh, total kWh, count and last-used date — for finding the cheapest stations within your usual routes.

#### Range calculator
- **Realistic range estimate** at `/api/range` — uses live SoC, the configured battery capacity, the 30-day average consumption from the API (or fallback to lifetime average), and the current outdoor temperature from Open-Meteo at your home location. Applies a temperature penalty (1.30× below 0°C, 1.18× < 10°C, 1.06× < 20°C, 1.10× > 30°C). Shown as a dashboard card.

#### Weather correlation
- **Open-Meteo integration** — `services/weather_service.py` fetches daily mean temperatures for your home location with DB caching (no API key, no rate-limit issues for normal usage).
- **Dashboard chart** — bar (kWh/month) + line (avg outdoor °C) showing exactly why winter is more expensive.

#### Highlights / fun facts
- **Dashboard "Highlights" card** — cheapest charge, most expensive charge, biggest single charge, longest trip (km), fastest trip (avg km/h), longest park (days). Also rendered on a dedicated page in the PDF report.

#### Reverse geocoding
- **Nominatim integration** — `services/geocode_service.py` resolves coordinates to street addresses, with a permanent DB cache and a 1-second rate-limiter (Nominatim ToS). Used by parking events on demand.

#### THG quota reminder
- **Banner** between January 1 and March 31 if no THG quota is logged for the previous year — direct link to Settings.

### Database
- New tables: `parking_events`, `maintenance_log`, `geocode_cache`, `weather_cache` — auto-created on startup.
- New columns on `charges`: `location_lat`, `location_lon`, `location_name` — auto-migrated.

### i18n
- **83 new translation keys** in all 6 languages (DE, EN, FR, ES, IT, NL) — every new page, banner, button and tooltip is fully localized.

## v2.2.0 (2026-04-09)

### New Features
- **Real in-app updater** — the "Update verfügbar" button in Settings now actually rolls out the update on the user's machine instead of opening the GitHub release page in a browser. Click → confirm → the app downloads the new release zip, stages it, hands off to a detached `updater_helper.py` process, gracefully shuts itself down, the helper swaps files (preserving `venv/`, `data/`, `.git/`), runs `pip install -r requirements.txt` and re-launches the app via the platform start script. The settings page polls until the app comes back online and reloads the browser automatically.
- **`POST /api/update/install`** and **`GET /api/update/check`** routes drive the new flow.

### How it works
The trick is the detour through a standalone `updater_helper.py` script: the running Flask process cannot safely overwrite its own `app.py` and templates while still serving requests, so the helper runs in a separate detached subprocess that waits on the parent PID, then performs the file swap. Pattern adapted from `shelly-energy-analyzer`.

## v2.1.1 (2026-04-09)

### Fixes
- **Updater** — version comparison now uses semver tuples instead of plain string inequality. A user on a later dev version no longer sees an "update available" pointing at an older release, and `2.10.0` correctly sorts above `2.9.0`.

## v2.1.0 (2026-04-09)

### New Features
- **Vehicle history tracking** — every vehicle sync now persists battery (SoC), range, odometer, 12V battery, calculated SoH, total recuperated kWh, 30-day kWh/100km consumption, and GPS location. New rows are only stored when at least one tracked value has changed (compact, audit-friendly history).
- **Dashboard vehicle history widget** — 7 compact time-series mini-charts (SoC, range, odometer, 12V, SoH, recuperation, consumption) showing the evolution of all tracked metrics.
- **Vehicle location map** — small Leaflet/OpenStreetMap card on the dashboard showing where the car was last seen, with marker and zoom.
- **PDF report extended** — new "Fahrzeug-Historie" section with all 7 time-series charts, summary KPIs (km driven, SoH delta, recuperation delta) and the last known GPS position.

### Database
- New columns on `vehicle_syncs`: `battery_12v_percent`, `battery_soh_percent`, `total_regenerated_kwh`, `consumption_30d_kwh_per_100km`, `location_lat`, `location_lon` (auto-migrated on startup).

## v2.0.0 (2026-04-09)

### New Features
- **Multi-language support** — Deutsch, English, Français, Español, Italiano, Nederlands. Switchable in Settings → Sprache. 286 strings per locale, JSON-based fallback to German.
- **Marketing-ready README** — badges, screenshots section, problem/solution table, "why this app" pitch, GitHub topics for discoverability (electric-vehicle, ev-charging, kia, hyundai, tesla, …).

### Improvements
- Lightweight i18n service (`services/i18n.py`) with `t()` global, per-request language selection, format-string support.

## v1.9.0 (2026-04-09)

### New Features
- **6 additional vehicle brands** via API connectors:
  - **Tesla** (`teslapy`, OAuth refresh-token, miles → km auto-convert)
  - **Renault** & **Dacia** (`renault-api`, async)
  - **Polestar** (`pypolestar`, async)
  - **MG / SAIC** (`saic-ismart-client-ng`)
  - **Smart #1/#3** (`pySmartHashtag`)
  - **Porsche** (`pyporscheconnectapi`)
- Modular connector architecture preserved — Kia/Hyundai integration untouched, no token loss.
- All packages installable from Settings → Vehicle API UI (no terminal needed).

### Improvements
- **Dark / Light mode** toggle in navbar, inline boot script avoids flash, synced across browser tabs via `localStorage` storage event.
- **Local timestamps** — `datetime.utcnow` replaced with `datetime.now` everywhere; "Letzte Sync" no longer shows UTC.
- **Repo cleanup** — `.DS_Store`, `.claude/`, `*.command` added to `.gitignore` and untracked.
- **Dynamic copyright year** — footer no longer hardcoded to 2025.

## v1.8.4 (2026-04-08)

### Fixes
- Reverted experimental client-side OAuth wizard — Selenium-based token fetch (v1.5.4) is back as the only reliable approach for headed environments.

## v1.8.3 (2026-04-08)

### Fixes
- **SoH fallback** — when the EU API does not populate `BatteryManagement.SoH.Ratio` (most non-Kona vehicles), SoH is computed from `total_consumed_kwh / battery_kwh` and shown in the dashboard widget.

## v1.8.2 (2026-04-08)

### Fixes
- **Kia API unit conversion** — `totalPwrCsp` and `regenPwr` empirically use 0.1 kWh units (not Wh as the upstream library docs claim). Recuperation now matches dashboard expectations (~7.072 kWh, not 21.011).

## v1.8.1 (2026-04-08)

### Fixes
- **PDF "Gesamtübersicht" layout** — replaced overlapping manual y-positioning with a clean bordered KPI table.
- **Dashboard auto-refresh** — vehicle widget now actually fetches fresh cached data on page load (was only restoring from localStorage cache).
- **SoH on dashboard** — added new "SoH %" tile to the live vehicle widget.

## v1.8.0 (2026-04-08)

### New Features
- **PDF Report** — new "Report" button in navigation, generates multi-page PDF with:
  - KPI overview (costs, kWh, CO2, savings, consumption, recuperation)
  - 10 colorful charts (monthly costs/kWh/CO2 with averages, cumulative cost/kWh, CO2 break-even, price trend, charge count, AC/DC/PV pie charts, yearly comparison)
  - Detailed tables (AC/DC/PV statistics, yearly overview, monthly breakdown)
  - Auto-generated filename with car model and date

## v1.7.0 (2026-04-08)

### New Features
- **Start/Stop charge tracking** — buttons on input page trigger force-refresh from vehicle, auto-fill date/time/SoC/odometer
- **Live charge timer** — shows elapsed time, estimates kWh from time × AC power
- **Auto-stop** — polls every 10 min during charging, auto-stops when SoC reaches charge limit or car stops charging
- **CO2 from time range** — calculates weighted average CO2 from ENTSO-E for the charge period (start to end hour)
- **API rate limiter** — tracks daily Kia API calls (190/200 limit), counter shown on dashboard, auto-reset at midnight
- **Session persistence** — charge session survives tab switches and page reloads via localStorage

### Improvements
- Charge poll interval: 10 min (was 5 min) to respect Kia EU 200 calls/day limit
- Auto-sync minimum interval: 1 hour (was 30 min)
- Sync service respects daily API limit
- Settings: vehicleCredentials and syncSection render server-side when brand configured

## v1.6.0 (2026-04-08)
- **Cached vs Live refresh** — two buttons on dashboard: "Cached" reads server cache, "Live" wakes the car for fresh data
- **Force refresh fallback** — if Live returns null values (odometer, range, 12V), last known values are preserved
- **Settings sync modes** — "Sync (Cached)" and "Sync (Live)" buttons, auto-sync mode selector (Cached/Live)
- **Input force refresh** — vehicle fetch button in "Neue Ladung" always wakes the car
- **localStorage cache** — vehicle data persists across tab switches, no re-fetch needed
- **Hyundai token support** — token fetch now works for both Kia and Hyundai with brand-specific OAuth URLs

## v1.5.5 (2026-04-07)
- **Full vehicle live dashboard** — all available data from Kia/Hyundai displayed in 3-row widget
- **New data points** — doors/trunk/hood status, tire pressure warnings, 30-day consumption, Schuko charge time, registration date, Google Maps location link
- **Extended API** — `/api/vehicle/status` returns all vehicle data

## v1.5.4 (2026-04-07)
- **One-click Kia/Hyundai token fetch** — opens Chrome with mobile user-agent, user logs in + solves reCAPTCHA, token is auto-captured and saved
- **Working OAuth flow** — uses `peukiaidm-online-sales` client for initial login, then exchanges for CCSP refresh token
- **Clean settings UI** — brand selection, install buttons, delete/reset, manual token entry as fallback

## v1.5.1 (2026-04-07)
- **One-click package install** — install vehicle API packages directly from settings UI (no terminal needed)

## v1.5.0 (2026-04-07)

### New Features
- **Vehicle API integration** — connect your car to auto-fetch SoC, odometer, charging status
- **Supported brands** — Kia (UVO), Hyundai (Bluelink), VW (WeConnect), Skoda (MySkoda), Seat (MyCar), Cupra (MyCupra), Audi (myAudi)
- **Auto-fill on input** — "Von Fahrzeug abrufen" button fills SoC and odometer from vehicle API
- **Background sync service** — periodic vehicle status polling (configurable 1h–12h interval)
- **Vehicle sync history** — all synced data points stored in database
- **Settings UI** — Fahrzeug-API card with brand selection, credentials, connection test, manual sync, auto-sync toggle
- **Modular connector architecture** — plugin-based design, new brands can be added easily
- **Optional dependencies** — vehicle API packages only needed when used (graceful degradation)

## v1.4.4 (2026-04-04)
- **Average lines in all monthly charts** — dashed Ø lines for costs, kWh, and CO2

## v1.4.3 (2026-04-04)
- **Average line in monthly cost chart** — dashed line showing Ø cost per month

## v1.4.0 (2026-04-04)
- **Auto CO2 backfill** — missing CO2 values are automatically fetched from ENTSO-E after CSV import
- **Manual backfill button** — "CO₂ nachladen" in ENTSO-E settings with live progress
- **Background processing** — rate-limit aware with automatic retries

## v1.3.1 (2026-04-04)
- Fix uniform chart heights across all dashboard rows

## v1.3.0 (2026-04-04)

### New Features
- **PV charging** — third charge type "PV (Solar)" alongside AC/DC
- **PV system configuration** — kWp, annual yield, lifetime, production CO2 in settings
- **Auto-calculated PV CO2** — from system specs (e.g. 10kWp → ~42 g/kWh)
- **PV auto-fill** — selecting PV pre-fills CO2 and price fields
- **AC/DC/PV comparison** — dashboard table includes PV column when data exists
- **PV filter** — history filterable by PV charge type
- **Mobile-friendly charts** — responsive sizing, fewer ticks, smaller fonts, shorter legends on small screens

## v1.2.1 (2026-04-04)
- **CSV import via web UI** — upload Google Sheet CSV directly in settings (no CLI needed)
- Refactored import logic into reusable `import_csv_data()` function

## v1.2.0 (2026-04-04)

### New Features
- **Vehicle configuration** — car model, battery capacity, max AC power editable in settings
- **THG quota management** — add/delete yearly CO2 bonus payouts, deducted from total costs
- **Odometer tracking** — km field per charge, inline editing in history view
- **Charging hour** — select hour (00-23) for hour-specific ENTSO-E CO2 data
- **Recuperation tracking** — configurable kWh/km rate, total energy recovered, extra km, recuperation cycles
- **CO2 break-even chart** — cumulative CO2 savings vs. battery production with break-even line
- **Well-to-wheel CO2** — configurable fossil car WTW emissions (default 164 g/km DE average)
- **Auto-calculated charging losses** — from SoC difference and battery capacity when not manually entered
- **New dashboard KPIs** — net costs (after THG), consumption kWh/100km, cost per 100km, charge cycles, recuperation stats
- **CO2 charts** — monthly CO2 emissions bar chart, cumulative CO2 savings line chart
- **Improved dashboard layout** — AC/DC and yearly tables separated, full-width cost chart

### Fixes
- Fix ENTSO-E connection test button (hidden input override)
- Fix GitHub username in settings template and update checker
- Auto-migrate database schema (adds columns without data loss)

## v1.1.0 (2026-04-04)
- Vehicle configuration in settings
- THG quota tracking

## v1.0.2 (2026-04-04)
- Fix GitHub username in update checker and settings link

## v1.0.1 (2026-04-04)
- Fix ENTSO-E connection test button

## v1.0.0 (2026-04-04)
- Initial release