The product vision sets the direction. This roadmap turns it into user outcomes and acceptance evidence. It is not a list of shipped features or permission to start every track at once.
Fredrik chooses the next bounded change. Check current code, tests, open PRs and site evidence before claiming a gap or completion. Preserve established behaviour while simplifying the product. Bug fixes, security, recovery and necessary maintenance continue alongside product work.
The owner reviewed Core, the webapp, the native app, drivers and the website on 12 September 2026 and chose the delivery order below. The first delivery, #1170 and #1199, closed the confirmed control and Lua-host gaps and is merged. The settings stack for roof geometry and panels (#734, #735, #826, #1052) and the retired Python optimizer work stay out of Core; new solver work belongs in Energyplan.
| Area | What the baseline contains | What remains |
|---|---|---|
| Mixed equipment | Separate SolarEdge legacy and Pixii drivers exist. Their published evidence and Pixii metadata still say experimental; the legacy header and declared curtail capability also need to agree. | Reconcile known field runs with the catalog, then verify the named inverter + battery + charger combination. Distinguish measured telemetry, verified commands and unverified control. Metadata is not evidence that no user has ever run the hardware. |
| Setup and usable power | Discovery, fingerprinting and per-device settings exist. Planner battery limits use configured limits or a 0.5C estimate, then an aggregate fuse cap. | A guided commissioning result and measured usable-power learning are still missing from the reviewed setup path. Read verified limits first; learn response within them. A capacity-derived estimate is not a learned power limit. |
| Forecasts and defaults | PV learning needs no panel geometry or rating. Cold-load selection keeps the site prior until learning, and load/net-risk tests cover uncertainty. Charge and discharge efficiency are included. The minimum arbitrage spread defaults to zero. | Verify first-day and learned performance on held-out site periods. Keep the separate opt-in wear-cost requirement open; a minimum arbitrage spread is not a general wear model. Align all persisted defaults and worker support before exposing such a setting. Do not rebuild cold-start support already delivered in #1204. |
| Daily charging | The webapp panel already saves SoC on slider release, changes schedules without a Save button and supports Charge now. | Now normally opens that panel after a charger tap or notification link. Bring the relevant SoC action directly into the post-plug-in entry experience. Complete the goal → plan → delivered-energy flow on real chargers, including offline cars and restarts. |
| Notifications | Core and the webapp implement subscription, charging connection/completion/interruption events and device alerts. See the shared push catalogue and rule defaults. | There is no dedicated predicted-missed-departure event in that catalogue. Add an actionable goal-risk notification and make activation clear during charging setup, with user consent. Verify delivery while the app is closed; an interrupted-session alert alone does not cover a future shortfall. |
| Live trust and expert access | Flow exists. LivePanel already puts a recent one-second trace behind each energy bubble and freezes it on silence. Core stores plan diagnostics and issued forecasts. | Join request, accepted intent, command response and measured effect in the normal experience and a structured analysis API, across drivers and different sample cadences. Stored diagnostics and live watts are useful parts, not a complete proof of causality. Measure response time on a target box. |
| External control and agents | Protocol command IDs and authorization leases, scoped operations, bounded battery holds, schedule APIs and encrypted sessions exist. HASS callbacks persist modes and grid targets. | Define renewable external control separately from durable goals. Losing HASS does not currently expire its saved mode. Existing authorization leases do not supply that policy. Build structured agent reads first, then permitted schedule/plan writes and a cloud MCP endpoint using the same Core checks. |
| Savings | The API explicitly reports site_total against no_pv_no_battery_vehicle_energy_at_daily_average. Actual import cost and export revenue are available. |
Make the scope clear on each surface that says “saved”. Then add and validate the same-hardware self-consumption counterfactual, including EV behaviour and stored-energy accounting. Do not relabel the current figure as FTW's incremental benefit. |
| Heat and settings | Thermal contracts and an explicitly opted-in solar feed already exist. The on-box planner settings and webapp use different levels of technical language; the on-box minimum SoC still says “House reserve”. | Keep existing opt-ins explicit while phase one uses heat data for planning. Align basic controls around user goals and distinguish operating limits from forecast caution. Audit stored settings before removing or hiding them. Active tank/hot-water optimization remains a later bounded outcome. |
These are the selected priorities, with no dates promised to users. Complete one bounded outcome at a time. Each delivery should have a focused PR and a clear result that the owner can review.
| Order | Delivery | Done when |
|---|---|---|
| 1 | Close the confirmed legacy control and host gaps in #1170 and #1199. | Done: both merged on 12 September. Physical safe-default qualification continues on target boxes. |
| 2 | Complete everyday charging. | Plug in → open app → correct SoC → see accepted plan takes no extra navigation or Save. Recurring weekday goals, Charge now, restart recovery and goal-risk notifications work together on a named charger and offline-car setup. |
| 3 | Complete first-day commissioning and simple defaults. | A new mixed site reaches safe automatic operation with confirmed fuse/meter, minimal required input and a receipt for observed control. Wrong starting ratings and failed integrations have clear handling; learned power does not replace hard equipment limits. |
| 4 | Share live evidence with people and agents. | One structured path explains intent, command result, freshness and measured outcome. Both normal Flow and an authorized analysis agent can use it. Target-box latency and differing sampling rates are measured; forecast evaluation covers cold start and learned periods. |
| 5 | Complete external authority and fair value as separate focused changes. | Temporary control expires to a defined local default; durable goals persist; schedule/plan access can be revoked; cloud MCP does not expose data to the relay. Separately, the validated self-consumption comparison reports FTW's incremental value and missing evidence honestly. |
| Later | Bounded thermal control and further expert extensions. | A named tank/hot-water use case meets comfort, hardware and failure requirements without making ordinary household setup harder. Native expansion still follows its existing Pair + Now verification gates. |
Battery and inverter learning should build on the existing per-battery response model. The digital-twin target needs tests for separate kW and kWh inputs, reported versus observed limits, partial delivery confirmed by the site meter, charge/discharge and state-of-charge-dependent response, temperature and mode changes, stale samples and model recovery. Show source and uncertainty before using an estimate in planning. A model prediction must never verify itself or raise a safety limit. These are acceptance requirements, not shipped support.
Necessary safety, security, recovery and support fixes continue throughout. Correct misleading value labels when their scope is known; that need not wait for the new counterfactual model. Reading and analysis access for agents can also support the evidence work before agents receive control authority.
Make discovery, planning, control and feedback fit together for mixed hardware and for both novice and expert users. Minimize setup and routine decisions. Complete a user flow across Core and clients when needed, using paired PRs for shared contracts.
Every row below is a target. Existing code contains parts of these flows; the row is complete only when its evidence exists for the version under review. This replaces older dated status snapshots. It does not reset completed work or reopen closed issues.
| Outcome | Product requirement | Acceptance evidence |
|---|---|---|
| Simple setup and first-day value | Discover mixed equipment. Confirm the main fuse and site meter. Read battery capacity where possible and ask for kWh when needed. Power settings and solar kWp are optional where safe device information and learning allow. Provide useful initial load and PV forecasts. | A fresh install reaches useful automatic operation without panel drawings or expert settings. Missing data and wrong start estimates have tested behaviour. Record device identity, known limits and uncertainty. Validate on named hardware combinations as well as simulators. |
| A clear commissioning result | Check commands and measured response within known limits. Distinguish working telemetry from working control. Exclude failed control from both the plan and dispatch. | Show request, device response, measured effect and timing. Cover delayed response, refusal, disconnect, stale site data and recovery. A short commissioning test does not claim full hardware qualification. |
| Verified control: “Are we in control?” | Keep the fast local feel. Make request, acceptance, command, response, physical effect and freshness visible in the normal Flow experience. | Browser review on desktop and mobile, timing measurements on a target box, and traces with different sampling rates. A successful call, echoed setpoint or old reading never appears as a verified physical result. Test accepted, measured and confirmed evidence per device, and the status each one shows. Confirm one device while another is offline; keep unavailable background flows in the residual. Show overview status, alarm on lost measured proof after the response wait, and clear it on measured recovery. Include direction, tolerance, response delay, simultaneous load/solar changes, shared measurement sources, overridden setpoints, device limits and recovery. A reduced request remains visibly limited even when the device follows the reduced command. Examine existing Live and Flow views before deciding their final layout. |
| Good automatic planning | Use site physics and charge/discharge efficiency. Default wear cost is zero; users may opt in. Keep hard SoC limits separate from forecast-based caution and explicit backup needs. | Cold-start and learned forecasts, stale inputs, multiple assets and unavailable optimizer paths have tests. Backtests use held-out periods and report uncertainty. Defaults and persisted settings agree across UI, Core and worker. Site runs establish practical benefit. |
| Reliable daily charging | Persistent weekday target and deadline. Offline-car estimates. Direct SoC slider after connection, no extra save, prompt replanning, one-action Charge now and notifications when action is needed. | Test from app intent to charger/car response and delivered energy, including missed-goal risk, absent vehicle cloud, unknown SoC, reconnect and restart. Test notifications with the app closed. Confirm physical charging separately from simulation. |
| Useful analysis and fair savings | Keep enough provenance to explain plans and outcomes. Main savings target compares with ordinary self-consumption on the same installation. | Actual cost reconciles with measured import/export and prices. Specify EV behaviour, initial and final stored-energy accounting, efficiency and coverage. Show missing and negative results. Label the current no-PV/no-battery comparison as total site value until replacement is verified. |
| External automation and agent access | Give authorized clients structured analysis data, schedule/goal changes and proposed-plan submission. Temporary external control expires; durable goals persist. Support local access and secure cloud MCP access. | Paired Core/client contract tests cover permissions, expiry, replay, rejection, revocation and reconnect. An agent can trace a request through to measured outcome. Prove local fallback when the caller disappears. Reuse the session/relay where suitable and verify that relay and escrow remain blind. Cloud MCP is a target, not a claim of a shipped endpoint. |
| Less configuration, reliable operation | Every normal setting serves a user need. Keep expert controls discoverable. Installation, updates, backup and recovery remain part of the finished experience. | Audit settings and feature use before removal. Test migration of stored choices so hidden settings cannot keep directing behaviour. Verify restart, upgrade and restore on a target box and review affected UI flows. |
| Updates the owner runs | The owner operates the host; FTW supplies the steps. ftw update runs unattended, falls back on its own when a new release does not stay up, and makes a verified full backup before a change to stored data. The same steps are API calls, so owners and their agents can wrap them. On native, the web UI shows the version and the release notice only. The installer and the Docker migration produce one native layout. |
The evidence list in ADR 0007, on the home box and one other site: update and rollback timings, a crash during and just after the trial, a slow first start, a state-schema change and its way back, an unattended run, disk use after ten updates, a fresh Raspberry Pi OS card, and a Docker 2.x or 3.x box moved to native with a tested return to its old installation. The new setup paths ship now; guided transfer of old data remains unshipped. 2.x and 3.x receive no further updates. |
Safety is part of each row. Core remains the only dispatch authority, every plan is untrusted input, stale required site-meter data stops dispatch, and failed devices receive their safe default where reachable.
The next planner work should improve both the time to a valid plan and the time to prove its quality. These are future development goals, not measured production guarantees. Keep the Energyplan contract as the shared boundary: Core validates plans and owns dispatch.
| Order | Goal | Acceptance evidence |
|---|---|---|
| 1 | Explain where planning time goes. | Separate model preparation, first valid plan, improvement, proof and the full request time. Record memory use and deadline overruns on a named ARM64 box, for cold starts and repeated planning. |
| 2 | Expand independent comparisons. | Compare equivalent models against HiGHS, SCIP and a commercial reference. Match budgets, thread counts and tolerances; repeat runs and keep held-out cases. Treat license limits and unfinished proofs as missing evidence. Source, algorithms and raw benchmarks stay in the private Energyplan repo or private test artifacts. |
| 3 | Reduce work on difficult household plans. | Improve tariffs, tight grid limits and multiple assets without changing the physical model or weakening result claims. Keep a change only when independent replay, exact small cases and held-out comparisons confirm both correctness and a useful gain. |
| 4 | Return safely under load or interruption. | Cover the whole request budget, memory pressure, malformed requests, cancellation, restart and changing measurements. Preserve the best valid candidate for the current request; return an explicit error if none exists. Test Core rejection and fallback separately. |
| 5 | Prove value on the target box. | Run held-out household traces and rolling replanning on physical ARM64, then verify plan acceptance and measured device behaviour at named sites. Report cost, missed charging goals and uncertainty; solver timings alone do not establish household savings. |
Initial calibration targets remain a valid plan within 100 ms at p99 and proven optimum in at least 99% of feasible standard cases within 2 s. The standard class is one battery, one or two EVs, and a 48-hour horizon with 15-minute slots. Freeze the cases, hardware and numerical tolerances first, and collect enough observations for tail measurements. Report difficult cases separately. These targets need ARM64 evidence before they become a service promise; a short time limit cannot guarantee an exact answer for every model.
Every step must preserve physical limits, honest feasible/optimal status,
explicit failure and the local operating path. Keep solver implementation and
its detailed development plan in private Energyplan. Core receives compiled
workers and integration evidence through paired PRs.
First read heat-pump and heating data to improve load forecasts and planning. Leave comfort control with the heat pump. The battery and other flexible assets serve the household's needs.
A later control case is a buffer tank or hot-water store charged during cheap periods. It needs known temperature and storage bounds, safe defaults, verified hardware control and a user goal. Do not imply active heat support from a telemetry-only driver or require every house to supply a thermal model.
| Repository | Responsibility in this direction |
|---|---|
srcfl/ftw |
Core safety, state, commissioning, dispatch, on-box UI, history, API and shared product direction. |
srcfl/energyplan |
Private solver and forecast implementation; defaults and model quality must match Core's contract. Only compiled artifacts and public integration metadata go to Core. |
srcfl/device-drivers |
Mixed-device support, stable identity, trustworthy readings, declared limits, structured command results and hardware evidence. |
srcfl/ftw-webapp |
Fast everyday UI, charging interaction, intent/result feedback, notifications and encrypted client/session contracts. |
srcfl/ftw-app |
The same product principles, with current Pair + Now verification gates preserved before expanding native scope. |
srcfl/ftw-web |
Explain the product and contribution route accurately. Separate available behaviour from product goals. |
Contributions are welcome, preferably based on an issue. Broad ideas may start as short Markdown PRs; concrete fixes can include code and relevant test evidence. Hardware claims need hardware results. Work is agentic first: make the problem, scope and results clear enough for people and agents to assess and continue. Fredrik sets priority; Sourceful reviews and maintains changes. An accepted issue or proposal does not promise delivery.
For each selected change, state the household need, the behaviour to change, the existing work it touches and the evidence that will establish completion. Keep details in the issue and PR. Do not create another feature inventory or long-lived agent work plan beside this roadmap.
Decide exclusions as concrete needs arise. Existing proposals, including the tariff and demand discussion, remain evidence to assess; they are neither blanket implementation bans nor delivery promises. An older PR's title or approval is not proof it still fits current code or direction. Coordinate changes with its author and preserve unique work before any owner-authorized closure.