Configuration: the manufacturer account is signed in on Car, not Vehicle portal (#227)
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Reading the car: an ID.4 or a Škoda, and the key pasted on Vehicle portal (#193)
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 weather recorded with each charging session
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.
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.