Repository navigation
Drivers follow the Core release: remaining steps #1423
Description
Activity
Status, 2026-09-25. The owner set the rule: an owner picks which signed driver version runs, and nothing changes without that choice. The release carries a tested baseline set, which stays bundled so an update or rollback moves a known pair and a box starts offline. Settings lets the owner fetch and run another signed version of one driver.
drivers-stablefollows stable Core: open. As a one-off, the owner promoteddrivers-stableto 489c937 today, so easee_cloud 1.3.3 reaches 2.x and 3.x ([bug] FTW v3.8.0-beta.1 – periodic EV charging interruption #1415).- Pin bumps as PRs: open.
- Native UI: changed by the owner. Keep the per-driver version picker in Settings → Devices, and do not remove it. Next: show the release's version on the bundled row (the catalog now reports
release_version), and list beta versions in the same picker, labelled as beta. - Bugs:
beta_availablewith!==: fixed in fix(drivers): keep the owner's driver choice and meet both id spellings #1426.- The beta channel ignoring
enabled: false: fixed in fix(drivers): keep the owner's driver choice and meet both id spellings #1426. One manifest fetch per open tab every 3 h is left as is. - A managed artifact missing from the manifest fails to start: checked. The device-drivers build carries every earlier entry into
history, so only a channel reset can cause it. It stays fail-closed. use_bundledand the id spellings: fixed in fix(drivers): keep the owner's driver choice and meet both id spellings #1426. A first install now also reaches the running instance.- The note in
BUNDLED_SOURCE.json: fixed in fix(drivers): keep the owner's driver choice and meet both id spellings #1426.
- Version lineage: open. It is safe: a lower bundled version keeps the override. With
release_versionvisible, sdm630 will show channel 2.0.1 over release 1.1.1 until device-drivers decides on one lineage.
The watchdog default on driver start (#1421) was fixed in #1425.
Status, 2026-09-25 (later the same day):
- One id and one version per driver: done. Give every driver one id and one version device-drivers#132 and PV twin intercept drifts, biasing daytime predictions #134 are merged, PV twin predicts non-zero PV at night (Model.Predict returns Beta[0]) #133 removed the package pilot, and FTW pins 43710c8 in fix(drivers): one id per driver, from the bundled copy to the channel #1429. FTW's identity rule is gone.
- drivers-stable: kept simple. No automation. After a stable Core release, run the existing promotion command; it is step 5 of the native release path in AGENTS.md.
- A selection is never lost: done (fix(drivers): never lose a driver selection to a Core update #1428).
driver-repository/effectiveis derived from the owner's selections and the release's drivers, so an update, a failed trial or a rollback keeps the choice. - One place in the UI: feat(drivers): one place to see and choose a driver version #1427. It is rebased and waits for the owner's look in a browser.
- Reviews. Codex and an independent review agent found issues in the premature driver history, the esphome-dsmr stranding, destructive retirement, choice tracking, beta outages and matching by basename. All of them are fixed in the PRs above.
- Still open:
- removing Device Support coupling from FTW (
sourceful.gopackage format, the CI contract job); - folding
esphome-dsmrintoesphome_dsmr, which needs its own migration; - rebasing the owner's heishamon drafts feat(heishamon): report heat-mode power with independent freshness device-drivers#60 and feat: setup wizard frontend #66.
- removing Device Support coupling from FTW (
Owner decision, 2026-09-25, after the Easee night (#1417): drivers reach users with the Core release. One version, and
ftw update/ftw rollbackcover the drivers. A driver fix is a pin bump indrivers/BUNDLED_SOURCE.json, shipped in the next beta. The signed channel serves installs that cannot take a new Core (1.x–3.x) and expert overrides. An override ends when a release catches up.Why: on the home box a managed easee_cloud 1.3.2 kept running over the bundled 1.3.3 in v0.136.4-beta.1. Precedence goes by file existence, not by version, and nothing told the owner.
drivers-stable(f18ceef, 2026-09-08) is older than the bundled pin (489c937).Done in #1422:
ftw statuslists driver versions and overrides;Remaining
drivers-stablefollows stable Core. Promotion is a manual dispatch today. It covers the whole catalog, needs drivers-beta to name the exact commit, and has no cadence. Proposed: whennative-release.ymlpublishesvXstable, promotedrivers-stableto the commit in that release'sBUNDLED_SOURCE.json. That needs a device-drivers workflow change, because the pinned commit is usually not the current beta head.bundled-driver-pin.ymlonly opens an issue when the pin falls behind. Let it open a PR that moves the pin, runsscripts/sync-bundled-drivers.shand adds a changeset.web/update-badge.jscomputesbeta_availablewith!==, so it offers an older beta as an update.ChannelCatalogandInstallChannelignoredevice_repository.enabled: false, and every open tab fetches the beta manifest every 3 h.driversandhistoryfails to start (driverrepo/sourceful.go). The channel history must never drop a version that is installed somewhere.use_bundledreturns "no bundled file declares driver easee_cloud" on the home box. The bundled source declaresid = "easee-cloud", and about 25 bundled drivers spell their id differently from the channel.BUNDLED_SOURCE.jsonsays channel artifacts are write-inert; drivers markedcontrol: truekeep their control path.DRIVER.versiondifferent from their channel version, for example sdm630 at 1.1.1 against 2.0.1. The split is deliberate (tools/ftw_repository.py, "two lineages"). Now that drivers follow the release, decide whether the channel should take its version and id from the source. Until then a managed install of those five is never retired, which is the safe direction.