efab8cd0a0 fix(genetic): keep fitness-cache memory within pymalloc and release arena after each run (#1353)
* fix(genetic): keep fitness-cache memory in pymalloc and release arena after each run

At fine time resolution (interval_sec=900, ~192 control slots over a multi-day
horizon) the fitness-cache keys are ~1.6 KB int tuples, above CPython's 512-byte
pymalloc threshold, so they are served by glibc malloc in the optimization worker
thread's arena and are not returned to the OS on `self._fitness_cache.clear()`.
With re-optimization every 15 min, RSS stair-steps up to the memory limit within
about a day (OOM / forced restart). At hourly resolution the tuples stay < 512 B,
so pymalloc reclaims them and the effect is negligible. See #1352.

- Store the cache key/genome compactly as bytes (1 byte per gene, 8-byte fallback
  for larger state spaces) so entries stay within pymalloc regardless of resolution.
- After each optimization run, gc.collect() + malloc_trim(0) (guarded, glibc-only)
  to return freed arena pages to the OS.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

* fix(genetic): pack fitness-cache genome as bounded chunks

Storing the genome as a single bytes object still exceeds pymalloc's
512-byte threshold once the genome grows: at 15-min resolution over a
60 h horizon with EV genes the key is ~480 genes, so even the one-byte
encoding is 481 bytes (514 with the object header) and any value >255
switches the whole genome to 8 bytes per gene. Such keys land in glibc
malloc, which does not reliably return the pages (malloc_trim is
glibc-only, absent on musl) — the platform-independent guarantee did
not actually hold for supported settings.

Encode the genome (key and FitnessCacheEntry.genome) as a tuple of
bounded byte chunks instead — 256 one-byte genes or 32 signed-64-bit
genes per chunk, 256 bytes each — built per chunk so the encoder never
materialises an oversized temporary. Every object then stays inside
pymalloc regardless of horizon, on every platform. malloc_trim after a
run is kept as a secondary release for the rest of the run's heap.

Tests: round-trips incl. 480-gene narrow/wide and negative genes, and
sys.getsizeof for the key AND every chunk at 480 genes in both
encodings.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
2026-09-26 12:39:29 +02:00
2025-01-24 20:08:48 +01:00
2025-04-07 22:23:35 +02:00
2024-05-03 10:43:31 +02:00
2024-11-15 22:27:25 +01:00

AkkudoktorEOS AkkudoktorEOS

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:

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.

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

Supports aarch64 Architecture Supports amd64 Architecture

To install the Akkudoktor-EOS add-on in Home Assistant:

Open your Home Assistant instance and show the add add-on repository dialog with a specific repository URL pre-filled.

  1. Add the repository URL:

    In Home Assistant, go to:

    Settings → Add-ons → Add-on Store → ⋮ (top-right menu) → Repositories
    

    and enter the URL of this Git repository:

    https://github.com/Akkudoktor-EOS/EOS
    
  2. Install the add-on:

    After adding the repository, the add-on will appear in the Add-on Store. Click Install.

  3. Start the add-on:

    Once installed, click Start in the add-on panel.

  4. Access the dashboard:

    Click Open Web UI in the add-on panel.

  5. Configure EOS (optional): In the dashboard, go to:

    Config
    
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

  1. EOSdash (Recommended) - Web interface at http://localhost:8504
  2. Manual - Edit EOS.config.json directly
  3. 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.

Contributors

License

This project is licensed under the Apache License 2.0 - see the LICENSE file for details.

S
Description
This repository features an Energy Optimization System (EOS) that optimizes energy distribution, usage for batteries, heat pumps& household devices. It includes predictive models for electricity prices (planned), load forecasting& dynamic optimization to maximize energy efficiency & minimize costs. Founder Dr. Andreas Schmitz (YouTube @akkudoktor)
Readme
46 MiB
Languages
Python 99.7%
Makefile 0.2%
Dockerfile 0.1%