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>
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.
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.