mirror of
https://github.com/Akkudoktor-EOS/EOS.git
synced 2026-01-01 08:16:18 +00:00
58d70e417b
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
98 lines
3.8 KiB
Markdown
98 lines
3.8 KiB
Markdown
% SPDX-License-Identifier: Apache-2.0
|
|
(configuration-page)=
|
|
|
|
# Configuration Guide
|
|
|
|
The configuration controls all aspects of EOS: optimization, prediction, measurement, and energy
|
|
management.
|
|
|
|
## Storing Configuration
|
|
|
|
EOS stores configuration data in a `nested structure`. Note that configuration changes inside EOS
|
|
are updated in memory, meaning all changes will be lost upon restarting the EOS REST server if not
|
|
saved to the `EOS configuration file`.
|
|
|
|
Some `configuration keys` are read-only and cannot be altered. These keys are either set up by other
|
|
means, such as environment variables, or determined from other information.
|
|
|
|
Several endpoints of the EOS REST server allow for the management and retrieval of configuration
|
|
data.
|
|
|
|
### Save Configuration File
|
|
|
|
Use endpoint `PUT /v1/config/file` to save the current configuration to the
|
|
`EOS configuration file`.
|
|
|
|
### Load Configuration File
|
|
|
|
Use endpoint `POST /v1/config/reset` to reset the configuration to the values in the
|
|
`EOS configuration file`.
|
|
|
|
## Configuration Sources and Priorities
|
|
|
|
The configuration sources and their priorities are as follows:
|
|
|
|
1. `Settings`: Provided during runtime by the REST interface
|
|
2. `Environment Variables`: Defined at startup of the REST server and during runtime
|
|
3. `EOS Configuration File`: Read at startup of the REST server and on request
|
|
4. `Default Values`
|
|
|
|
### Runtime Config Updates
|
|
|
|
The EOS configuration can be updated at runtime. Note that those updates are not persistent
|
|
automatically. However it is possible to save the configuration to the `EOS configuration file`.
|
|
|
|
Use the following endpoints to change the current runtime configuration:
|
|
|
|
- `PUT /v1/config`: Update the entire or parts of the configuration.
|
|
|
|
### Environment Variables
|
|
|
|
All `configuration keys` can be set by environment variables prefixed with `EOS_` and separated by
|
|
`__` for nested structures. Environment variables are case insensitive.
|
|
|
|
EOS recognizes the following special environment variables (case sensitive):
|
|
|
|
- `EOS_CONFIG_DIR`: The directory to search for an EOS configuration file.
|
|
- `EOS_DIR`: The directory used by EOS for data, which will also be searched for an EOS
|
|
configuration file.
|
|
|
|
### EOS Configuration File
|
|
|
|
The EOS configuration file provides persistent storage for configuration data. It can be modified
|
|
directly or through the REST interface.
|
|
|
|
If you do not have a configuration file, it will be automatically created on the first startup of
|
|
the REST server in a system-dependent location.
|
|
|
|
To determine the location of the configuration file used by EOS, ask the REST server. The endpoint
|
|
`GET /v1/config` provides the `general.config_file_path` configuration key.
|
|
|
|
EOS searches for the configuration file in the following order:
|
|
|
|
1. The directory specified by the `EOS_CONFIG_DIR` environment variable
|
|
2. The directory specified by the `EOS_DIR` environment variable
|
|
3. A platform-specific default directory for EOS
|
|
4. The current working directory
|
|
|
|
The first configuration file available in these directories is loaded. If no configuration file is
|
|
found, a default configuration file is created, and the default settings are written to it. The
|
|
location of the created configuration file follows the same order in which EOS searches for
|
|
configuration files, and it depends on whether the relevant environment variables are set.
|
|
|
|
Use the following endpoints to interact with the configuration file:
|
|
|
|
- `PUT /v1/config/file`: Save the current configuration to the configuration file.
|
|
- `PUT /v1/config/reset`: Reload the configuration file, all unsaved runtime configuration is reset.
|
|
|
|
### Default Values
|
|
|
|
Some of the `configuration keys` have default values by definition. For most of the
|
|
`configuration keys` the default value is just `None`, which means no default value.
|
|
|
|
```{include} /_generated/config.md
|
|
:heading-offset: 1
|
|
:relative-docs: ..
|
|
:relative-images:
|
|
```
|