MQTT: the Forecasted mode's settable numbers are the SOC floor and resume margin (#217, #249)
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Document the car, and correct keys that now refuse to start
The `Ev` section (#124) describes what the car is -- its pack, and the
currents and phases it will actually accept -- as distinct from the
`Vehicle` feed that reports on it. `Phases` gets the warning it needs:
without it the controller uses the wallbox's count, and a single-phase
car behind a three-phase box has every power figure overstated
threefold.
Also corrected, because the table was actively harmful: it still listed
`Solax__Inverter__Host`, `Solax__EvCharger__Host`, `Weather__Latitude`
and `Weather__Longitude`, all retired by #111. Following the page as
written produced a controller that refuses to start, naming a
replacement the page never mentioned. Added the upgrade note that lists
every key that has moved.
Document the fast charge's amount, its departure and its hold
The fast mode grew three things the wiki did not mention: an amount to
stop at (#119), a departure that defers the charge so it finishes just
in time (#122), and a discharge hold the owner can now switch off
mid-charge.
- Home: the capability bullet says what the mode can be asked for.
- MQTT: two new sections. "Fast charging: how much, and when" covers the
four entities and the button that applies them, including why a
departure is worth wanting -- it is the pack, not the price. "The
battery hold during a fast charge" covers who owns the switch and the
two consequences that would otherwise be surprises.
- Deployment: corrected "What appears in Home Assistant", which still
described the Charge mode *select* retired in #89.
Charging is started by a button, and add the targeted mode
The wiki was last touched on 2026-08-16 and has since fallen behind two
shipped changes.
MQTT.md described the device as offering a Charge mode *select*. That was
replaced by buttons in #89/#90: a select is a statement of intent that waits
for the world to agree with it, and picked while the charger sat in Green it
did nothing at all -- the most common "it isn't working" report the project
produced. Charge mode is now a read-only sensor reporting what a button did.
Home.md listed four capabilities and not the fifth: targeted charging, which
shipped in #86 and has been reworked since to pace the charge across the
window rather than run flat out.
Document stopping the service, and correct the restart policy
The controller can now be stopped from the web UI or Home Assistant, and
stays stopped until it is started again -- so the wiki's `--restart
unless-stopped` examples were actively wrong: under that policy the Stop
button is a restart button. Docker.md and Platforms.md now show
`on-failure`, which reads the exit code the worker sets deliberately: 0
for a requested stop (stays down), 143 for a SIGTERM (reboot, daemon
restart: comes back), non-zero for a crash or power cut (comes back).
Deployment gains a "Stopping and starting the controller" section: the
three ways to ask for a stop, what the graceful path does that killing the
process doesn't (the charger is released -- otherwise the car keeps
drawing at the last setpoint), how to start it again, and why a reboot
still recovers on its own.
Also documented: the Stop service button in MQTT and Deployment's HA
entity summary, the closing log line as a diagnostic in Troubleshooting
and the startup-log section (a log ending without it is a run that died --
on the Pi the journal is RAM-only, so these files are the only account
that survives), and the 10-second charger-release deadline, whose warning
means a car may still be drawing.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Restructure deployment around two workflows; rename Full-Stack to Deployment
The page documented both deployments but was called "Full stack", so the
lighter one read as a footnote to the heavier. It now opens with the
choice and the hardware requirement that decides it:
A full stack, with Home Assistant 2 GB minimum, 4 GB recommended
B controller and its web UI only 1 GB is enough
Workflow B gains its own required-settings block -- the site addresses
are the whole list -- and the .env example marks the MQTT block as
workflow A only. The broker-credentials section is scoped to A.
Renamed Full-Stack.md to Deployment.md, since a page covering both was
misnamed, and updated the sidebar and all seven cross-references. The old
URL will 404; the sidebar carries readers across.
Board models are gone in favour of RAM figures, matching the repo docs:
"on 1 GB" rather than "on a Pi 3 B", and cgroup memory accounting is
"required on every board whatever its memory".
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Make building from source the documented default, and correct the Web defaults
Get started assumed Docker and a pulled image, which put a container runtime and
a registry between a new reader and their first telemetry. It now covers the
path that needs neither: clone, set the two device addresses, build, run, open
localhost:8080. The image-based instructions move to a new Docker page, and Home
and the sidebar split the pages into a first-pass set and an advanced one, so
MQTT, Home Assistant and Compose read as the opt-ins they are.
Corrections against main, all verified in the repo rather than assumed:
- The web UI defaults are split by environment, not shipped on: appsettings.json
has Enabled false / RequireAuthentication true, and appsettings.Development.json
flips both, so a clone serves the UI without a login while the image starts
headless. An earlier draft of these pages described the reverse.
- The docker run example gains a separate "adding the web UI" block. Enabling
the UI without a password hash trips the deliberate fail-fast in
WebUiHost.ValidateAuthenticationConfig, so publishing the port alone would
have produced a container that refuses to start.
- The Solcast refresh interval is 3 hours, not 12, and has been since da05f39
(PR #23) in both appsettings.json and the SolcastOptions default. The quota
warning was reasoning from the old figure.
- Every platform is built on dotnet/aspnet since the web UI landed, not
dotnet/runtime.
Troubleshooting gains the failures that only bite when running from source: an
unreachable device, an older SDK, implausible register values, and the two ways
to end up with nothing on port 8080.
Add project wiki: overview, Docker get-started, configuration, platforms, MQTT and Solcast
Covers what the controller is and how to run it in Docker on linux/amd64,
linux/arm64 and Windows Nano Server, plus the configuration reference, the
full Compose stack, the MQTT integration and optional Solcast forecasting.