Looking at the forecast: /forecast, and what it deliberately does not do
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.
Document the weather recorded with each charging session
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>
Pi 5 is the reference board; scope the Pi 3 claims that differ
Follows the repo change. The architecture diagram and Home page said
Raspberry Pi 3 B; the memory table's "sized for a 1 GB Pi 3 B" now also
says what that means on a 4 GB board, and why keeping the limits is still
worthwhile there.
Platforms gains the detail that cgroup memory accounting is not merely
off by default -- the firmware prepends cgroup_disable=memory, so it
appears in /proc/cmdline while no file on the boot partition mentions it,
and appending to cmdline.txt works because the later parameter wins.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Web UI default port moves from 8080 to 8090
Follows the repo change: 8080 collides with Kodi's HTTP remote-control
interface and with most other things that assume 8080. Updates the
Web__Port default, the docker run -p examples, the architecture diagram
and the log lines quoted in Troubleshooting.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Document the web UI as on by default, with the password as an advanced option
Follows the repository change (mpospisil/solax-controller#59): Web:Enabled
defaults to true, docker-compose.yml publishes 8080 itself, and configuring
Web__PasswordHash is what turns the login on -- unset RequireAuthentication
now means "follow the password" rather than "required".
Configuration: the settings table stops calling the UI off-by-default and
marks the two auth variables advanced; the section drops the
appsettings.json-vs-Development split, which no longer exists, in favour of
one default everywhere, and gains the full RequireAuthentication table
including the one combination that refuses to start.
Docker: the first `docker run` now publishes 8080 and reaches a working UI
with no extra flags, so "adding the web UI" becomes "putting a password on
it", plus a short note on running headless.
Full stack: the .env example no longer suggests WEB_ENABLED or COMPOSE_FILE,
and carries a note telling upgraders to delete the COMPOSE_FILE line -- it is
obsolete and merging it does nothing.
Get started, Home, Troubleshooting: no environment-dependent default to
explain any more; an unreachable :8080 is now a fault rather than a missing
setting, so the troubleshooting rows say what to look for instead.
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.
Document compose profiles, the deploy.sh split, and the self-hosted UI-only deployment
Home Assistant and the broker are now opt-in (issue #51), chosen by which deploy script runs
(deploy.sh vs. deploy-controller-only.sh) rather than a .env setting, so the wiki needs to describe
running controller + web UI with neither.
- Full stack: rework the diagram, mark the broker/HA sections as conditional on deploy.sh, add the
memory-budget table and the controller-only walkthrough.
- Configuration: document Web__* variables and the hash-password command.
- Home / Get started: light touch-ups reflecting the web UI as a first-class, independent control
surface.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
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.