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>
Swap the inverter and EV charger addresses; they were reversed
192.168.2.6 is the EV charger, 192.168.2.10 is the inverter. Every page
carrying the example addresses had them the wrong way round.
Get started also gains the reason it matters: both devices answer Modbus
on 502, so a reachability check passes either way, and getting it wrong
produces confusing symptoms rather than a failure -- SOC frozen at a
constant, solar and grid at 0, the charger permanently "Unknown". The
charger's own web page identifies it, so that is now the check.
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>
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.