Bobby NoelteandGitHub
7554e2dc47
delete_by_datetime() with no bounds was documented as "delete all
records", but db_delete_records() assumed that
_db_ensure_loaded(start=None, end=None) loads every record into memory
before building the delete list. That is wrong: _db_ensure_loaded()
implements a NONE -> INITIAL -> FULL phase machine, and with both bounds
None in the NONE phase it loads only an *initial window* and leaves the
phase at INITIAL. Records outside that window never enter
_db_sorted_timestamps, so they are never marked for deletion and survive
in the physical store. Symptom: after a "wipe", db_count_records() still
returned N records (observed: 4 leftovers from a previous dense fixture).
A second delete_by_datetime() call happened to escalate INITIAL -> FULL
and deleted the rest, which is why the bug looked intermittent and why
stacked test runs accumulated rows.
Fix: in db_delete_records(), when both bounds are None, call
self._db_load_full() directly; otherwise keep the existing
_db_ensure_loaded(start, end) path. The delete list is then complete and
the "wipe" fixture actually wipes.
delete_by_datetime() remains a soft delete (rows are only added to
_db_deleted_timestamps; the physical DELETE happens on the next flush),
unchanged by this commit.
Besides this an additional fix was added:
* fix(tests): assert UTC-instant ordering in test_timestamps_remain_sorted
The test asserted `dts == sorted(dts)` on seq.records[].date_time, which
are tz-aware DateTime values in Europe/Berlin. Compaction buckets on a
UTC grid but records are materialized in local time, so across a DST
fall-back the local wall-clock sequence is non-monotonic even though the
UTC instants are ordered (e.g. 00:45 UTC -> 02:45 CEST, 01:00 UTC ->
02:00 CET). sorted() compares wall-clock fields, so it flags the pair at
the seam (index 1248 on 2026-10-25 for Europe/Berlin) as out of order.
The assertion is unsatisfiable for any 15-min grid spanning a fall-back
boundary when records are labelled in local time.
The actual invariant is "ascending by UTC instant", which is what
_db_sorted_timestamps guarantees and what the adjacent alignment tests
already assert via int(rec.date_time.timestamp()). Change the assertion
to compare integer UTC epochs:
epochs = [int(r.date_time.timestamp()) for r in seq.records if r.date_time]
assert epochs == sorted(epochs)
Note: this test was seasonally flaky. It only fails while a DST
transition lies inside the [now - 4 weeks, now] window used by
dense_energy_seq, which is why it newly started failing without any code
change. Upstream should ideally emit compacted records in UTC (or order
by UTC instant) so that wall-clock ordering is not silently assumed.
Signed-off-by: Bobby Noelte <b0661n0e17e@gmail.com>
Build optimized energy management plans for your home automation
AkkudoktorEOS is a comprehensive solution for simulating and optimizing energy systems based on renewable sources. Optimize your photovoltaic systems, battery storage, load management, and electric vehicles while considering real-time electricity pricing.
Why use AkkudoktorEOS?
AkkudoktorEOS can be used to build energy management plans that are optimized for your specific setup of PV system, battery, electric vehicle, household load and electricity pricing. It can be integrated into home automation systems such as NodeRED, Home Assistant, EVCC.
🏘️ Community
We are an open-source community-driven project and we love to hear from you. Here are some ways to get involved:
-
GitHub Issue Tracker: discuss ideas and features, and report bugs.
-
Akkudoktor Forum: get direct suppport from the community.
What do people build with AkkudoktorEOS
The community uses AkkudoktorEOS to minimize grid energy consumption and to maximize the revenue from grid energy feed in with their home automation system.
- Andreas Schmitz, the Akkudoktor, uses EOS integrated in his NodeRED home automation system for OpenSource Energieoptimierung.
- Jörg, meintechblog, uses EOS for day-ahead optimization for time-variable energy prices. See: So installiere ich EOS von Andreas Schmitz
Why not use AkkudoktorEOS?
AkkudoktorEOS does not control your home automation assets. It must be integrated into a home automation system. If you do not use a home automation system or you feel uncomfortable with the configuration effort needed for the integration you should better use other solutions.
Quick Start
Upgrading an existing installation?
The next release includes a substantial energy-planning update: 15-minute GENETIC plans, EV departure targets, flexible household loads, optional battery export, and better measurement and PV-forecast tools. These features are currently unreleased.
Existing Home Assistant automations, Node-RED flows and custom API clients may need changes.
Devices now use stable IDs, the new optimizer reads hardware settings from EOS configuration,
and incomplete forecasts or outdated battery measurements can stop a run. The legacy
POST /optimize remains available with GENETIC0; the new POST /v1/optimize has a different
request format. Back up your configuration and data before updating.
Read the upgrade guide and changelog before switching an existing installation.
Start with Docker
Run EOS with Docker (access dashboard at http://localhost:8504):
docker run -d \
--name akkudoktoreos \
-p 8503:8503 \
-p 8504:8504 \
-e OPENBLAS_NUM_THREADS=1 \
-e OMP_NUM_THREADS=1 \
-e MKL_NUM_THREADS=1 \
-e EOS_SERVER__HOST=0.0.0.0 \
-e EOS_SERVER__EOSDASH_HOST=0.0.0.0 \
-e EOS_SERVER__EOSDASH_PORT=8504 \
--ulimit nproc=65535:65535 \
--ulimit nofile=65535:65535 \
--security-opt seccomp=unconfined \
akkudoktor/eos:latest
System Requirements
- Python: 3.11 or higher
- Architecture: amd64, aarch64 (armv8)
- OS: Linux, Windows, macOS
Note
: Other architectures (armv6, armv7) require manual compilation of dependencies with Rust and GCC.
Installation
Home Assistant add-on
To install the Akkudoktor-EOS add-on in Home Assistant:
-
Add the repository URL:
In Home Assistant, go to:
Settings → Add-ons → Add-on Store → ⋮ (top-right menu) → Repositoriesand enter the URL of this Git repository:
https://github.com/Akkudoktor-EOS/EOS -
Install the add-on:
After adding the repository, the add-on will appear in the Add-on Store. Click Install.
-
Start the add-on:
Once installed, click Start in the add-on panel.
-
Access the dashboard:
Click Open Web UI in the add-on panel.
-
Configure EOS (optional): In the dashboard, go to:
Config
Docker (Recommended)
docker pull akkudoktor/eos:latest
docker compose up -d
Access the API at http://localhost:8503 (docs at http://localhost:8503/docs)
From Source
git clone https://github.com/Akkudoktor-EOS/EOS.git
cd EOS
Linux:
python -m venv .venv
.venv/bin/pip install -r requirements.txt
.venv/bin/pip install -e .
.venv/bin/python -m akkudoktoreos.server.eos
Windows:
python -m venv .venv
.venv\Scripts\pip install -r requirements.txt
.venv\Scripts\pip install -e .
.venv\Scripts\python -m akkudoktoreos.server.eos
Configuration
EOS uses EOS.config.json for configuration. If the file doesn't exist, a default configuration is
created automatically.
Custom Configuration Directory
export EOS_DIR=/path/to/your/config
Configuration Methods
- EOSdash (Recommended) - Web interface at
http://localhost:8504 - Manual - Edit
EOS.config.jsondirectly - API - Use the Server API
See the documentation for all configuration options.
Port Configuration
Default ports: 8503 (API), 8504 (Dashboard)
If running on shared systems (e.g., Synology NAS), these ports may conflict with system services. Reconfigure port mappings as needed:
docker run -p 8505:8503 -p 8506:8504 ...
API Documentation
Interactive API docs available at:
- Swagger UI:
http://localhost:8503/docs - OpenAPI Spec: View Online
Resources
Contributing
We welcome contributions! See CONTRIBUTING for guidelines.
License
This project is licensed under the Apache License 2.0 - see the LICENSE file for details.