feat: add Home Assistant and NodeRED adapters (#764)

Adapters for Home Assistant and NodeRED integration are added.
Akkudoktor-EOS can now be run as Home Assistant add-on and standalone.

As Home Assistant add-on EOS uses ingress to fully integrate the EOSdash dashboard
in Home Assistant.

The fix includes several bug fixes that are not directly related to the adapter
implementation but are necessary to keep EOS running properly and to test and
document the changes.

* fix: development version scheme

  The development versioning scheme is adaptet to fit to docker and
  home assistant expectations. The new scheme is x.y.z and x.y.z.dev<hash>.
  Hash is only digits as expected by home assistant. Development version
  is appended by .dev as expected by docker.

* fix: use mean value in interval on resampling for array

  When downsampling data use the mean value of all values within the new
  sampling interval.

* fix: default battery ev soc and appliance wh

  Make the genetic simulation return default values for the
  battery SoC, electric vehicle SoC and appliance load if these
  assets are not used.

* fix: import json string

  Strip outer quotes from JSON strings on import to be compliant to json.loads()
  expectation.

* fix: default interval definition for import data

  Default interval must be defined in lowercase human definition to
  be accepted by pendulum.

* fix: clearoutside schema change

* feat: add adapters for integrations

  Adapters for Home Assistant and NodeRED integration are added.
  Akkudoktor-EOS can now be run as Home Assistant add-on and standalone.

  As Home Assistant add-on EOS uses ingress to fully integrate the EOSdash dashboard
  in Home Assistant.

* feat: allow eos to be started with root permissions and drop priviledges

  Home assistant starts all add-ons with root permissions. Eos now drops
  root permissions if an applicable user is defined by paramter --run_as_user.
  The docker image defines the user eos to be used.

* feat: make eos supervise and monitor EOSdash

  Eos now not only starts EOSdash but also monitors EOSdash during runtime
  and restarts EOSdash on fault. EOSdash logging is captured by EOS
  and forwarded to the EOS log to provide better visibility.

* feat: add duration to string conversion

  Make to_duration to also return the duration as string on request.

* chore: Use info logging to report missing optimization parameters

  In parameter preparation for automatic optimization an error was logged for missing paramters.
  Log is now down using the info level.

* chore: make EOSdash use the EOS data directory for file import/ export

  EOSdash use the EOS data directory for file import/ export by default.
  This allows to use the configuration import/ export function also
  within docker images.

* chore: improve EOSdash config tab display

  Improve display of JSON code and add more forms for config value update.

* chore: make docker image file system layout similar to home assistant

  Only use /data directory for persistent data. This is handled as a
  docker volume. The /data volume is mapped to ~/.local/share/net.akkudoktor.eos
  if using docker compose.

* chore: add home assistant add-on development environment

  Add VSCode devcontainer and task definition for home assistant add-on
  development.

* chore: improve documentation
This commit is contained in:
Bobby Noelte
2025-12-30 22:08:21 +01:00
committed by GitHub
parent 02c794460f
commit 58d70e417b
111 changed files with 6815 additions and 1199 deletions

View File

@@ -0,0 +1,23 @@
% SPDX-License-Identifier: Apache-2.0
(adapter-page)=
# Adapter
Adapters provide simplyfied integrations for home energy management systems. Besides
the standard REST interface of EOS, the adapters extend EOS by specific integration
interfaces for Home Assistant and NodeRED.
:::{admonition} Warning
:class: warning
Adapter execution is part of the energy management run. The adapters are only working
properly if cyclic energy management runs are configured.
:::
```{toctree}
:maxdepth: 2
:caption: Adapters
adapter/adapterhomeassistant.md
adapter/adapternodered.md
```

View File

@@ -0,0 +1,126 @@
% SPDX-License-Identifier: Apache-2.0
(adapter-homeassistant-page)=
# Home Assistant Adapter
The Home Assistant adapter provides a bidirectional interface between
**Home Assistant (HA)** and the **Akkudoktor-EOS (EOS)** energy optimisation system.
It allows EOS to:
- **Read** entity states and attributes from Home Assistant
- **Write** optimisation results and control instructions back to Home Assistant
This enables EOS to integrate seamlessly with Home Assistantmanaged devices,
sensors, and energy meters, while keeping EOS device simulations and optimisation
logic decoupled from HA-specific implementations.
## Configuration entity IDs
EOS can synchronise parts of its configuration from Home Assistant entity states.
This is particularly useful for **device (resource) parameters** that are already
provided by Home Assistant integrations, such as:
- Battery capacity
- Maximum charge or discharge power
- Nominal device ratings
These configuration values are typically consumed by EOS **device simulations**
during optimisation.
### Entity state conversion rules
When reading configuration values from entity states, the adapter applies the
following heuristics to convert the HA state into a suitable EOS value:
- **Boolean `True`**: `["y", "yes", "on", "true", "home", "open"]`
- **Boolean `False`**: `["n", "no", "off", "false", "closed"]`
- **`None`**: `["unavailable", "none"]`
- **`float`**: if the value can be converted to a floating-point number
- **`str`**: if none of the above apply
## Device instruction entity IDs
After each energy optimisation run, EOS produces **device instructions** for the
controlled resources. These instructions are written back to Home Assistant via
dedicated entities.
- The **entity state** represents the selected **operation mode** of the device.
- **Entity attributes** provide additional parameters for the operation mode, such as:
- `operation_mode_factor`
- Power or rate limits
- Mode-specific control parameters
Home Assistant automations or device integrations can then react to these entity
updates to perform the actual control actions.
## Device measurement entity IDs
Before starting an energy optimisation run, EOS retrieves **measurement values**
from Home Assistant that describe the *current state* of devices.
Typical examples include:
- Battery state of charge (SoC)
- Current power or energy levels
- Device availability or readiness indicators
These measurements are used as input for EOS **device simulations** and strongly
influence optimisation results.
## Load EMR entity IDs
Load **Energy Meter Readings (EMR)** are used to adapt and refine the **load
prediction**.
EOS retrieves these readings from Home Assistant **before** each energy management
run to align forecasts with actual consumption.
## PV production EMR entity IDs
PV production **Energy Meter Readings (EMR)** are used to adapt and refine the
**photovoltaic generation forecast**.
EOS retrieves these readings from Home Assistant **before** each optimisation run
to improve forecast accuracy based on real production data.
## Solution entity IDs
Each energy management run produces an **optimisation solution**.
In addition to device-level instructions, EOS can publish solution-level details to
dedicated Home Assistant entities. These entities are useful for:
- Debugging and validation
- Visualisation and dashboards
- Gaining deeper insight into optimisation decisions
EOS updates these entities **after** each energy management run.
## Entity state and value conversion
To adapt, scale, or transform Home Assistant entity values to match EOS
expectations, it is recommended to use
[template sensors](https://www.home-assistant.io/integrations/template/#sensor).
This allows value conversion to remain fully within Home Assistant, keeping the EOS
configuration clean and consistent.
### Example: Battery SoC conversion
Convert a battery state of charge from percentage `[0..100]` to a normalised factor
`[0.0..1.0]`:
<!-- pyml disable line-length -->
```yaml
template:
- sensor:
- name: "Battery1 SoC Factor"
unique_id: "battery1_soc_factor"
state: >
{% set bat_charge_soc = states('sensor.battery1_soc_percent') | float(100) -%}
{{ bat_charge_soc / 100.0 }}
state_class: measurement
```
<!-- pyml enable line-length -->

View File

@@ -0,0 +1,4 @@
% SPDX-License-Identifier: Apache-2.0
(adapter-nodered-page)=
# NodeRED Adapter

View File

@@ -1,7 +1,7 @@
% SPDX-License-Identifier: Apache-2.0
(configuration-page)=
# Configuration Guideline
# Configuration Guide
The configuration controls all aspects of EOS: optimization, prediction, measurement, and energy
management.

View File

@@ -36,7 +36,8 @@ Through an iterative process of selection, crossover, and mutation, the algorith
more effective solutions. The final result is an optimized control strategy that balances multiple
system goals within the constraints of the input data and configuration.
:::{note}
:::{admonition} Note
:class: note
You dont need to understand the internal workings of the genetic algorithm to benefit from
automatic optimization. EOS handles everything behind the scenes based on your configuration.
However, advanced users can fine-tune the optimization behavior using additional settings like

View File

@@ -51,13 +51,16 @@ A dictionary with the following structure:
```json
{
"start_datetime": "2024-01-01 00:00:00",
"interval": "1 Hour",
"interval": "1 hour",
"<prediction key>": [value, value, ...],
"<prediction key>": [value, value, ...],
...
}
```
If `start_datetime` is not provided EOS defaults to the `start_datetime` of the current energy
management run. If `interval` is not provided EOS defaults to one hour.
#### 2. DateTimeDataFrame
A JSON string created from a [pandas](https://pandas.pydata.org/docs/index.html) dataframe with a
@@ -402,10 +405,11 @@ represent equal angular distance around the horizon. For instance, if you have 3
point is due north, the next is 10 degrees east of north, and so on, until the last point, 10
degrees west of north.
---
![Userhorizon PVGIS](../_static/horizon_eyefish_en.png)
Most of the configuration options are in line with the
[PVLib](https://pvlib-python.readthedocs.io/en/stable/_modules/pvlib/iotools/pvgis.html) definition for PVGIS data.
[PVLib](https://pvlib-python.readthedocs.io/en/stable/_modules/pvlib/iotools/pvgis.html) definition
for PVGIS data.
Detailed definitions from **PVLib** for PVGIS data.
@@ -413,12 +417,14 @@ Detailed definitions from **PVLib** for PVGIS data.
Tilt angle from horizontal plane.
![Tilt PVGIS](../_static/slope.gif)
- `surface_azimuth`
Orientation (azimuth angle) of the (fixed) plane. Clockwise from north (north=0, east=90, south=180,
west=270). This is offset 180 degrees from the convention used by PVGIS.
---
![Azimuth PVGIS](../_static/azimuth.gif)
### PVForecastAkkudoktor Provider

View File

@@ -253,6 +253,6 @@ the home appliance can be operated in two operation modes:
|-----------------------|-------------------------------------------------------------------------|
| **RUN** | The home appliance is started and runs until the end of it's power |
| | sequence. |
| **IDLE** | The home appliance does not run. |
| **OFF** | The home appliance does not run. |
The **operation mode factor** (0.01.0) is ignored.