80bfe4d0f0
* Move the caching module to core. Add an in memory cache that for caching function and method results during an energy management run (optimization run). Two decorators are provided for methods and functions. * Improve the file cache store by load and save functions. Make EOS load the cache file store on startup and save it on shutdown. Add a cyclic task that cleans the cache file store from outdated cache files. * Improve startup of EOSdash by EOS Make EOS starting EOSdash adhere to path configuration given in EOS. The whole environment from EOS is now passed to EOSdash. Should also prevent test errors due to unwanted/ wrong config file creation. Both servers now provide a health endpoint that can be used to detect whether the server is running. This is also used for testing now. * Improve startup of EOS EOS now has got an energy management task that runs shortly after startup. It tries to execute energy management runs with predictions newly fetched or initialized from cached data on first run. * Improve shutdown of EOS EOS has now a shutdown task that shuts EOS down gracefully with some time delay to allow REST API requests for shutdwon or restart to be fully serviced. * Improve EMS Add energy management task for repeated energy management controlled by startup delay and interval configuration parameters. Translate EnergieManagementSystem to english EnergyManagement. * Add administration endpoints - endpoints to control caching from REST API. - endpoints to control server restart (will not work on Windows) and shutdown from REST API * Improve doc generation Use "\n" linenend convention also on Windows when generating doc files. Replace Windows specific 127.0.0.1 address by standard 0.0.0.0. * Improve test support (to be able to test caching) - Add system test option to pytest for running tests with "real" resources - Add new test fixture to start server for test class and test function - Make kill signal adapt to Windows/ Linux - Use consistently "\n" for lineends when writing text files in doc test - Fix test_logging under Windows - Fix conftest config_default_dirs test fixture under Windows From @Lasall * Improve Windows support - Use 127.0.0.1 as default config host (model defaults) and addionally redirect 0.0.0.0 to localhost on Windows (because default config file still has 0.0.0.0). - Update install/startup instructions as package installation is required atm. Signed-off-by: Bobby Noelte <b0661n0e17e@gmail.com>
4.7 KiB
Energy System Simulation and Optimization
This project provides a comprehensive solution for simulating and optimizing an energy system based on renewable energy sources. With a focus on photovoltaic (PV) systems, battery storage (batteries), load management (consumer requirements), heat pumps, electric vehicles, and consideration of electricity price data, this system enables forecasting and optimization of energy flow and costs over a specified period.
Documentation can be found at Akkudoktor-EOS.
Getting Involved
See CONTRIBUTING.md.
Installation
The project requires Python 3.10 or newer. Official docker images can be found at akkudoktor/eos.
Following sections describe how to locally start the EOS server on http://localhost:8503.
Run from source
Install dependencies in virtual environment:
Linux:
python -m venv .venv
.venv/bin/pip install -r requirements.txt
.venv/bin/pip install -e .
Windows:
python -m venv .venv
.venv\Scripts\pip install -r requirements.txt
.venv\Scripts\pip install -e .
Finally, start the EOS server:
Linux:
.venv/bin/python src/akkudoktoreos/server/eos.py
Windows:
.venv\Scripts\python src/akkudoktoreos/server/eos.py
Docker
docker compose up
If you are running the EOS container on a system hosting multiple services, such as a Synology NAS, and want to allow external network access to EOS, please ensure that the default exported ports (8503, 8504) are available on the host. On Synology systems, these ports might already be in use (refer to this guide). If the ports are occupied, you will need to reconfigure the exported ports accordingly.
Configuration
This project uses the EOS.config.json file to manage configuration settings.
Default Configuration
A default configuration file default.config.json is provided. This file contains all the necessary configuration keys with their default values.
Custom Configuration
Users can specify a custom configuration directory by setting the environment variable EOS_DIR.
- If the directory specified by
EOS_DIRcontains an existingconfig.jsonfile, the application will use this configuration file. - If the
EOS.config.jsonfile does not exist in the specified directory, thedefault.config.jsonfile will be copied to the directory asEOS.config.json.
Configuration Updates
If the configuration keys in the EOS.config.json file are missing or different from those in default.config.json, they will be automatically updated to match the default settings, ensuring that all required keys are present.
Classes and Functionalities
This project uses various classes to simulate and optimize the components of an energy system. Each class represents a specific aspect of the system, as described below:
-
Battery: Simulates a battery storage system, including capacity, state of charge, and now charge and discharge losses. -
PVForecast: Provides forecast data for photovoltaic generation, based on weather data and historical generation data. -
Load: Models the load requirements of a household or business, enabling the prediction of future energy demand. -
Heatpump: Simulates a heat pump, including its energy consumption and efficiency under various operating conditions. -
Strompreis: Provides information on electricity prices, enabling optimization of energy consumption and generation based on tariff information. -
EMS: The Energy Management System (EMS) coordinates the interaction between the various components, performs optimization, and simulates the operation of the entire energy system.
These classes work together to enable a detailed simulation and optimization of the energy system. For each class, specific parameters and settings can be adjusted to test different scenarios and strategies.
Customization and Extension
Each class is designed to be easily customized and extended to integrate additional functions or improvements. For example, new methods can be added for more accurate modeling of PV system or battery behavior. Developers are invited to modify and extend the system according to their needs.
Server API
See the Swagger API documentation for detailed information: EOS OpenAPI Spec