8224c64654
* feat: adapt configuration for multi optimization algorithms Decouple configuration from optimization algorithm parameters. Add to_[algorithm]_param() methods to the configuration that derive optimization algorithm specific parameters from the configuration. Add x-scope tags to the configuration options that describe for which specific algorithms the configuration option is for. The whole device settings are restructured. There are now general settings for the device classes with the afore mentioned to_[algorithm]_param() methods. The general device settings got their own directory `devices/settings`. By this the parameter class also does not have to be a pydantic model which can be used for future optimization/ simulations speed up. Also the parameter class for a device is now part of the device module. This better decouples and also is the natural place for parameters of a device. Besides this feature there are also fixes and improvements: * feat: extend home appliance time window settings and simulation Home appliance can now be configured for multiple runs with per-cycle allowed time windows. The number of remaining cycles to plan is determined at runtime by reading the ``cycles_completed_measurement_key`` from the measurement store. * feat: specialiced CycleTimeWindowSequence for time window sequences Sequence of time windows associated to cycles. This model specializes ``ValueTimeWindowSequence`` so that the ``value`` field of each ``ValueTimeWindow`` encodes the **cycle index** (0-based integer) the window belongs to. Typical use: an appliance that must run ``n`` times per day, each run constrained to a distinct time window. Assign ``value=0`` to windows for the first cycle, ``value=1`` for the second, and so on. Multiple windows may share the same cycle index (their allowed regions are unioned). Windows with ``value=None`` are silently ignored by all cycle-aware methods. * fix: Make test_configmigrate also regard the _ANY_SENTENIEL in key values * chore: Make devices configurations a map instead of a list This makes config paths stable regardless of declaration order and lets each device settings class build its own config path from ``self.device_id`` without needing an external index. Tests are adapted likewise. Devices configurations are automatically migrated from lists to maps. * chore: rename levelized_cost_of_storage_kwh to levelized_cost_of_storage_amt kwh This better fits in the naming scheme and also makes clear the costs are money. Signed-off-by: Bobby Noelte <b0661n0e17e@gmail.com> * fix: runtime config update ignored by config file Runtime settings were handed back to pydantic-settings as init settings, which rank below the config file and the environment. Any key already present in EOS.config.json or in the environment silently discarded the update, so a bulk PUT /v1/config returned 200 without applying anything, while the granular PUT /v1/config/{path} endpoint kept working. Add a dedicated runtime settings source ranked directly below the command line arguments and record granular updates there as well, so both endpoints share one store that survives re-evaluation of the settings sources. Environment variables keep precedence over the config file for all keys that were not set at runtime. Also repairs revert_settings() and update(), which passed their data through the same init settings. Closes #1303 * fix: env vars ignored on first config build ConfigEOS.__init__ passed self as first positional argument to _setup, which forwards it to pydantic_settings.BaseSettings.__init__. Its first positional parameter is _case_sensitive, so the environment source matched the upper case variable names against the lower case field names and returned nothing. Environment settings only took effect after the next configuration setup. * docs: changelog for config priority fixes * fix(config): preserve device identities and storage costs during migration * fix(devices): preserve charge-rate typing and public import compatibility * ruff format fix * fix(config): satisfy typed device conversion and migration contracts * docs(config): refresh validated configuration prerequisite schemas --------- Signed-off-by: Bobby Noelte <b0661n0e17e@gmail.com> Co-authored-by: Bobby Noelte <b0661n0e17e@gmail.com> Co-authored-by: r0b2g1t <r0b2g1t@users.noreply.github.com>
4.4 KiB
% 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.
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.
:::{admonition} Note
:class: note
Configuration changes inside EOS are updated in memory, meaning all changes will be lost upon
restarting the EOS REST server unless the configuration is saved to the EOS configuration file.
This can be done manually or is done automatically by default.
:::
Save Configuration File
Configure EOS for AUTOMATIC (vs. MANUAL) configuration file update in case of configuration
changes.
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:
Command Line Arguments: Provided at startup of the REST serverSettings: Provided during runtime by the REST interfaceEnvironment Variables: Defined at startup of the REST server and during runtimeEOS Configuration File: Read at startup of the REST server and on requestDefault Values
Runtime settings are kept until they are reset by POST /v1/config/reset. All other sources are
re-evaluated on every configuration change, which keeps environment variable changes effective for
all configuration keys that were not set during runtime.
Runtime Config Updates
The EOS configuration can be updated at runtime.
Use the following endpoints to change the current runtime configuration:
PUT /v1/config: Update the entire or parts of the configuration.
:::{admonition} Note
:class: note
Those updates are not persistent automatically. However it is possible to save the configuration to
the EOS configuration file. See Save Configuration File above.
:::
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:
- The directory specified by the
EOS_CONFIG_DIRenvironment variable - The directory specified by the
EOS_DIRenvironment variable - A platform-specific default directory for EOS
- 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.
:heading-offset: 1
:relative-docs: ..
:relative-images: