The setup assistant only covered the location, the horizons and the energy
management, and sent the user to the Config page for everything else.
Add the steps PV system, weather, prices and fees, load, devices and
measurements, each with an explanation, an example and a check of what is
still to do.
Add a Home Assistant step after the measurements step that explains what EOS
reads from and writes to Home Assistant, with a template sensor and an automation
as example. Its status reports a missing state of charge mapping, missing instruction
entities and an adapter that is selected while EOS does not run as an add-on. The
measurements step keeps the choice of the adapter.
Add examples for an inverter, an electric vehicle and a home appliance.
A step can now show configuration values depending on the value of another
one (WizardChoice), so that only the settings of the selected provider are
shown. The horizon of the selected optimization algorithm uses the same
mechanism instead of a placeholder in the configuration name.
Describe the profiles, point to the Profiles page and use the
profile_adjustment settings in the examples. The packaged profiles are
generic and give no size, so the devices step now reports a battery,
electric vehicle or inverter whose effective nominal capacity or power is
unknown. The changelog entry names the Home Assistant step.
Signed-off-by: SchaafAlexander <86607129+SchaafAlexander@users.noreply.github.com>
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
Assisted-by: Claude Code (claude-fable-5-2)
New users have to find the settings EOS needs among all configuration values
on the Config page, without a hint which ones matter or what is still missing.
The new Setup page takes the user through the configuration step by step.
Each step explains a few settings, gives an example, reports what is still to
do and shows the configuration cards of exactly these settings. The cards are
the ones of the Config page; the code that creates a card and sends an update
moved out of Configuration() into config_card() and config_update().
The assistant keeps no state: the step travels with the requests and the
status is derived from the EOS configuration, which is read and written
through the EOS server only.
First steps: location, horizons and energy management, save the configuration.
Signed-off-by: SchaafAlexander <86607129+SchaafAlexander@users.noreply.github.com>
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
Assisted-by: Claude Code (claude-fable-5-2)
The browser test read the content area right after the tab's response
arrived. htmx swaps the response in after that, and wait_for_load_state()
did not wait for it, as the page itself was loaded long before. For the
large configuration tab the content area was sometimes still empty, so
the test failed in CI.
Wait until the content area is filled again after a successful response.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Run EOSdash in a headless Chromium browser for testing. Every menu tab must
load with HTTP 200 and render content, in light and dark mode, without
JavaScript errors.
Additional changes
Enable the browser tests by --browser-test (marker browser), skip them otherwise
Add the CI job browser-test that installs Chromium and runs them
Add the make target test-browser, run with --extra dev so playwright is installed
Add playwright to the dev dependencies
Document how to run the browser tests with --extra dev, incl. the browser system
libraries on Linux
Accept a child PID of the started server in the server startup checks, on Windows
only: there the venv python.exe runs the real interpreter as a child process
Share one Chromium per test class, so Playwright stops before other tests run
Request chromium before servers so a missing browser fails before EOS starts
Make the missing-browser hint platform neutral (Linux: add --with-deps)
Set PYTHONIOENCODING=utf-8 for the test server to avoid encoding errors on Windows
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
