mirror of
https://github.com/Akkudoktor-EOS/EOS.git
synced 2025-04-19 08:55:15 +00:00
Added new instruction.md, changed index.md accordingly and deleted the no longer needed about.md of new documentation structure. Refinement of differences to other solutions and features of EOS. Co-authored-by: Eric Hirsch <git@familie-hirsch.net>
181 lines
8.4 KiB
Markdown
181 lines
8.4 KiB
Markdown
% SPDX-License-Identifier: Apache-2.0
|
||
|
||
# Introduction
|
||
|
||
The Energy System Simulation and Optimization System (EOS) 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.
|
||
|
||
After successfully installing a PV system with or without battery storage, most owners
|
||
first priority is often to charge the electric car with surplus energy in order to use
|
||
the electricity generated by the PV system cost-effectively for electromobility.
|
||
|
||
After initial experiences, the desire to include battery storage and dynamic electricity
|
||
prices in the solution soon arises. The market already offers various commercial and
|
||
non-commercial solutions for this, such as the popular open source hardware and software
|
||
solutions evcc or openWB.
|
||
|
||
Some solutions take into account the current values of the system such as PV power
|
||
output, battery storage charge level or the current electricity price to decide whether
|
||
to charge the electric car with PV surplus or from the grid (e.g. openWB), some use
|
||
historical consumption values and PV forecast data for their calculations, but leave out
|
||
the current electricity prices and charging the battery storage from the power grid
|
||
(Predbat). Others are specialiced on working in combination with a specific smart home
|
||
solution (e.g. emhass). Still others focus on certain consumers, such as the electric car,
|
||
or are currently working on integrating the forecast values (evcc). And some are commercial
|
||
devices that require an electrician to install them and expect a certain ecosystem
|
||
(e.g. Sunny Home Manager).
|
||
|
||
The Akkudoktor EOS
|
||
|
||
- takes into account historical, current and forecast data such as consumption values, PV
|
||
forecast data, electricity price forecast, battery storage and electric car charge levels
|
||
- the simulation also takes into account the possibility of charging the battery storage
|
||
from the grid at low electricity prices
|
||
- is not limited to certain consumers, but includes electric cars, heat pumps or more
|
||
powerful consumers such as tumble dryers
|
||
- is independent of a specific smart home solution and can also be integrated into
|
||
self-developed solutions if desired
|
||
- is a free and independent open source software solution
|
||
|
||

|
||
|
||
The challenge is to charge (electric car) or start the consumers (washing machine, dryer)
|
||
at the right time and to do so as cost-efficiently as possible. If PV yield forecast,
|
||
battery storage and dynamic electricity price forecasts are included in the calculation,
|
||
the possibilities increase, but unfortunately so does the complexity.
|
||
|
||
The Akkudoktor EOS addresses this challenge by simulating energy flows in the household
|
||
based on target values, forecast data and current operating data over a 48-hour
|
||
observation period, running through a large number of different scenarios and finally
|
||
providing a cost-optimized plan for the current day controlling the relevant consumers.
|
||
|
||
## Prerequisites
|
||
|
||
- Technical requirements
|
||
- Input data
|
||
|
||
### Technical requirements
|
||
|
||
- reasonably fast computer on which EOS is installed
|
||
- controllable energy system consisting of photovoltaic system, solar battery storage,
|
||
energy intensive consumers that must provide the appropriate interfaces
|
||
- integration solution for integrating the energy system and EOS
|
||
|
||
### Input Data
|
||
|
||

|
||
|
||
The EOS requires various types of data for the simulation:
|
||
|
||
Forecast data
|
||
|
||
- PV yield forecast
|
||
- Expected household consumption
|
||
- Electricity price forecast
|
||
- Forecast temperature trend (if heatpump is used)
|
||
|
||
Basic data and current operating data
|
||
|
||
- Current charge level of the battery storage
|
||
- Value of electricity in the battery storage
|
||
- Current charge level of the electric car
|
||
- Energy consumption and running time of dishwasher, washing machine and tumble dryer
|
||
|
||
Target values
|
||
|
||
- Charge level the electric car should reach in the next few hours
|
||
- Consumers to run in the next few hours
|
||
|
||
There are various service providers available for PV forecasting that calculate forecast
|
||
data for a PV system based on the various influencing factors, such as system size,
|
||
orientation, location, time of year and weather conditions. EOS also offers a
|
||
[PV forecasting service](#prediction-page) which can be used. This service uses
|
||
public data in the background.
|
||
|
||
For the forecast of household consumption EOS provides a standard load curve for an
|
||
average day based on annual household consumption that you can fetch via API. This data
|
||
was compiled based on data from several households and provides an initial usable basis.
|
||
Alternatively your own collected historical data could be used to reflect your personal
|
||
consumption behaviour.
|
||
|
||
## Simulation Results
|
||
|
||
Based on the input data, the EOS uses a genetic algorithm to create a cost-optimized
|
||
schedule for the coming hours from numerous simulations of the overall system.
|
||
|
||
The plan created contains for each of the coming hours
|
||
|
||
- Control information
|
||
- whether and with what power the battery storage should be charged from the grid
|
||
- when the battery storage should be charged via the PV system
|
||
- whether discharging the battery storage is permitted or not
|
||
- when and with what power the electric car should be charged
|
||
- when a household appliance should be activated
|
||
- Energy history information
|
||
- Total load of the house
|
||
- Grid consumption
|
||
- Feed-in
|
||
- Load of the planned household appliances
|
||
- Charge level of the battery storage
|
||
- Charge level of the electric car
|
||
- Active losses
|
||
- Cost information
|
||
- Revenue per hour (when fed into the grid)
|
||
- Total costs per hour (when drawn from the grid)
|
||
- Overall balance (revenue-costs)
|
||
- Cost development
|
||
|
||
If required, the simulation result can also be created and downloaded in graphical
|
||
form as a PDF from EOS.
|
||
|
||
## Integration
|
||
|
||
The Akkudoktor EOS can be integrated into a wide variety of systems with a variety
|
||
of components.
|
||
|
||

|
||
|
||
However, the components are not integrated by the EOS itself, but must be intergrated by
|
||
the user using an integration solution and currently requires some effort and technical
|
||
know-how.
|
||
|
||
Any [integration](#integration-page) solution that can act as an intermediary between the
|
||
components and the REST API of EOS can be used. One possible solution that enables the
|
||
integration of components and EOS is Node-RED. Another solution could be Home Assistant
|
||
usings its built in features.
|
||
|
||
Access to the data and functions of the components can be done in a variety of ways.
|
||
Node-RED offers a large number of types of nodes that allow access via the protocols
|
||
commonly used in this area, such as Modbus or MQTT. Access to any existing databases,
|
||
such as InfluxDB or PostgreSQL, is also possible via nodes provided by Node-RED.
|
||
|
||
It becomes easier if a smart home solution like Homa Assistant, openHAB or ioBroker or
|
||
solutions such as evcc or openWB are already in use. In this case, these smart home
|
||
solutions already take over the technical integration and communication with the components
|
||
at a technical level and Node-RED offers nodes for accessing these solutions, so that the
|
||
corresponding sources can be easily integrated into a flow.
|
||
|
||
In Home Assistant you could use an automation to prepare the input payload for EOS and
|
||
then use the RESTful integration to call EOS. Based on this concept there is already a
|
||
home assistand add-on created by [Duetting](#duetting-solution).
|
||
|
||
The plan created by EOS must also be executed via the chosen integration solution,
|
||
with the respective devices receiving their instructions according to the plan.
|
||
|
||
## Limitations
|
||
|
||
The plan calculated by EOS is cost-optimized due to the genetic algorithm used, but not
|
||
necessarily cost-optimal, since genetic algorithms do not always find the global optimum,
|
||
but usually find good local optima very quickly in a large solution space.
|
||
|
||
## Links
|
||
|
||
- [German Video explaining the basic concept and installation process for the early version of EOS (YouTube)](https://www.youtube.com/live/ftQULW4-1ts?si=oDdBBifCpUmiCXaY)
|
||
- [German Forum of Akkudoktor EOS](https://akkudoktor.net/c/der-akkudoktor/eos)
|
||
- [Akkudoktor-EOS GitHub Repository](https://github.com/Akkudoktor-EOS/EOS)
|
||
- [Latest EOS Documentation](https://akkudoktor-eos.readthedocs.io/en/latest/)
|