MQTT: the two low-tariff-only switches (#274)
Fast low tariff only and SolarGrid low tariff only: what they hold
back, that a wait is not a finished car, and that they start nothing.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
1e61be1
MQTT: the grid tariff's three entities (#265, #273)
Low tariff, Tariff change and Grid price, and why they read unknown
rather than OFF with no tariff set up.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
c636aa7
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>
c0b02c5
Configuration: the manufacturer account is signed in on Car, not Vehicle portal (#227)
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
a090634
Looking at the forecast: /forecast, and what it deliberately does not do
73048cc
Reading the car: an ID.4 or a Škoda, and the key pasted on Vehicle portal (#193)
8201c0e
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.
1016ba1
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.
56e1586
Document the weather recorded with each charging session
0e6c686
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.
8e6aa84
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>
6e84c2b
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>
ab9628d
Document updating a running deployment
The page explained getting a Pi to a first working deploy and stopped
there, though updating is what a reader does repeatedly afterwards.
Covers: that updating is the same command as deploying; that Compose
recreates only what changed; that all state survives, .env included,
because none of it is inside a container; that the pull moves Home
Assistant too on workflow A; that charge control returns to Off across
the restart and a session in progress is closed as ServiceStopped;
pinning and rollback via IMAGE_TAG; and the .env-change case the deploy
script deliberately does not handle.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
20d430c
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>
26c5fbd
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>
e4e17c1
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>
71cfb65
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>
5cabb53
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.
b97cdfe
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>
90d1d2d
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.
9a0b24c