Files
EOS/docs/akkudoktoreos/configtimewindow.md

850 lines
13 KiB
Markdown
Raw Normal View History

fix: automatic optimization (#596) This fix implements the long term goal to have the EOS server run optimization (or energy management) on regular intervals automatically. Thus clients can request the current energy management plan at any time and it is updated on regular intervals without interaction by the client. This fix started out to "only" make automatic optimization (or energy management) runs working. It turned out there are several endpoints that in some way update predictions or run the optimization. To lock against such concurrent attempts the code had to be refactored to allow control of execution. During refactoring it became clear that some classes and files are named without a proper reference to their usage. Thus not only refactoring but also renaming became necessary. The names are still not the best, but I hope they are more intuitive. The fix includes several bug fixes that are not directly related to the automatic optimization but are necessary to keep EOS running properly to do the automatic optimization and to test and document the changes. This is a breaking change as the configuration structure changed once again and the server API was also enhanced and streamlined. The server API that is used by Andreas and Jörg in their videos has not changed. * fix: automatic optimization Allow optimization to automatically run on configured intervals gathering all optimization parameters from configuration and predictions. The automatic run can be configured to only run prediction updates skipping the optimization. Extend documentaion to also cover automatic optimization. Lock automatic runs against runs initiated by the /optimize or other endpoints. Provide new endpoints to retrieve the energy management plan and the genetic solution of the latest automatic optimization run. Offload energy management to thread pool executor to keep the app more responsive during the CPU heavy optimization run. * fix: EOS servers recognize environment variables on startup Force initialisation of EOS configuration on server startup to assure all sources of EOS configuration are properly set up and read. Adapt server tests and configuration tests to also test for environment variable configuration. * fix: Remove 0.0.0.0 to localhost translation under Windows EOS imposed a 0.0.0.0 to localhost translation under Windows for convenience. This caused some trouble in user configurations. Now, as the default IP address configuration is 127.0.0.1, the user is responsible for to set up the correct Windows compliant IP address. * fix: allow names for hosts additional to IP addresses * fix: access pydantic model fields by class Access by instance is deprecated. * fix: down sampling key_to_array * fix: make cache clear endpoint clear all cache files Make /v1/admin/cache/clear clear all cache files. Before it only cleared expired cache files by default. Add new endpoint /v1/admin/clear-expired to only clear expired cache files. * fix: timezonefinder returns Europe/Paris instead of Europe/Berlin timezonefinder 8.10 got more inaccurate for timezones in europe as there is a common timezone. Use new package tzfpy instead which is still returning Europe/Berlin if you are in Germany. tzfpy also claims to be faster than timezonefinder. * fix: provider settings configuration Provider configuration used to be a union holding the settings for several providers. Pydantic union handling does not always find the correct type for a provider setting. This led to exceptions in specific configurations. Now provider settings are explicit comfiguration items for each possible provider. This is a breaking change as the configuration structure was changed. * fix: ClearOutside weather prediction irradiance calculation Pvlib needs a pandas time index. Convert time index. * fix: test config file priority Do not use config_eos fixture as this fixture already creates a config file. * fix: optimization sample request documentation Provide all data in documentation of optimization sample request. * fix: gitlint blocking pip dependency resolution Replace gitlint by commitizen. Gitlint is not actively maintained anymore. Gitlint dependencies blocked pip from dependency resolution. * fix: sync pre-commit config to actual dependency requirements .pre-commit-config.yaml was out of sync, also requirements-dev.txt. * fix: missing babel in requirements.txt Add babel to requirements.txt * feat: setup default device configuration for automatic optimization In case the parameters for automatic optimization are not fully defined a default configuration is setup to allow the automatic energy management run. The default configuration may help the user to correctly define the device configuration. * feat: allow configuration of genetic algorithm parameters The genetic algorithm parameters for number of individuals, number of generations, the seed and penalty function parameters are now avaliable as configuration options. * feat: allow configuration of home appliance time windows The time windows a home appliance is allowed to run are now configurable by the configuration (for /v1 API) and also by the home appliance parameters (for the classic /optimize API). If there is no such configuration the time window defaults to optimization hours, which was the standard before the change. Documentation on how to configure time windows is added. * feat: standardize mesaurement keys for battery/ ev SoC measurements The standardized measurement keys to report battery SoC to the device simulations can now be retrieved from the device configuration as a read-only config option. * feat: feed in tariff prediction Add feed in tarif predictions needed for automatic optimization. The feed in tariff can be retrieved as fixed feed in tarif or can be imported. Also add tests for the different feed in tariff providers. Extend documentation to cover the feed in tariff providers. * feat: add energy management plan based on S2 standard instructions EOS can generate an energy management plan as a list of simple instructions. May be retrieved by the /v1/energy-management/plan endpoint. The instructions loosely follow the S2 energy management standard. * feat: make measurement keys configurable by EOS configuration. The fixed measurement keys are replaced by configurable measurement keys. * feat: make pendulum DateTime, Date, Duration types usable for pydantic models Use pydantic_extra_types.pendulum_dt to get pydantic pendulum types. Types are added to the datetimeutil utility. Remove custom made pendulum adaptations from EOS pydantic module. Make EOS modules use the pydantic pendulum types managed by the datetimeutil module instead of the core pendulum types. * feat: Add Time, TimeWindow, TimeWindowSequence and to_time to datetimeutil. The time windows are are added to support home appliance time window configuration. All time classes are also pydantic models. Time is the base class for time definition derived from pendulum.Time. * feat: Extend DataRecord by configurable field like data. Configurable field like data was added to support the configuration of measurement records. * feat: Add additional information to health information Version information is added to the health endpoints of eos and eosDash. The start time of the last optimization and the latest run time of the energy management is added to the EOS health information. * feat: add pydantic merge model tests * feat: add plan tab to EOSdash The plan tab displays the current energy management instructions. * feat: add predictions tab to EOSdash The predictions tab displays the current predictions. * feat: add cache management to EOSdash admin tab The admin tab is extended by a section for cache management. It allows to clear the cache. * feat: add about tab to EOSdash The about tab resembles the former hello tab and provides extra information. * feat: Adapt changelog and prepare for release management Release management using commitizen is added. The changelog file is adapted and teh changelog and a description for release management is added in the documentation. * feat(doc): Improve install and devlopment documentation Provide a more concise installation description in Readme.md and add extra installation page and development page to documentation. * chore: Use memory cache for interpolation instead of dict in inverter Decorate calculate_self_consumption() with @cachemethod_until_update to cache results in memory during an energy management/ optimization run. Replacement of dict type caching in inverter is now possible because all optimization runs are properly locked and the memory cache CacheUntilUpdateStore is properly cleared at the start of any energy management/ optimization operation. * chore: refactor genetic Refactor the genetic algorithm modules for enhanced module structure and better readability. Removed unnecessary and overcomplex devices singleton. Also split devices configuration from genetic algorithm parameters to allow further development independently from genetic algorithm parameter format. Move charge rates configuration for electric vehicles from optimization to devices configuration to allow to have different charge rates for different cars in the future. * chore: Rename memory cache to CacheEnergyManagementStore The name better resembles the task of the cache to chache function and method results for an energy management run. Also the decorator functions are renamed accordingly: cachemethod_energy_management, cache_energy_management * chore: use class properties for config/ems/prediction mixin classes * chore: skip debug logs from mathplotlib Mathplotlib is very noisy in debug mode. * chore: automatically sync bokeh js to bokeh python package bokeh was updated to 3.8.0, make JS CDN automatically follow the package version. * chore: rename hello.py to about.py Make hello.py the adapted EOSdash about page. * chore: remove demo page from EOSdash As no the plan and prediction pages are working without configuration, the demo page is no longer necessary * chore: split test_server.py for system test Split test_server.py to create explicit test_system.py for system tests. * chore: move doc utils to generate_config_md.py The doc utils are only used in scripts/generate_config_md.py. Move it there to attribute for strong cohesion. * chore: improve pydantic merge model documentation * chore: remove pendulum warning from readme * chore: remove GitHub discussions from contributing documentation Github discussions is to be replaced by Akkudoktor.net. * chore(release): bump version to 0.1.0+dev for development * build(deps): bump fastapi[standard] from 0.115.14 to 0.117.1 bump fastapi and make coverage version (for pytest-cov) explicit to avoid pip break. * build(deps): bump uvicorn from 0.36.0 to 0.37.0 BREAKING CHANGE: EOS configuration changed. V1 API changed. - The available_charge_rates_percent configuration is removed from optimization. Use the new charge_rate configuration for the electric vehicle - Optimization configuration parameter hours renamed to horizon_hours - Device configuration now has to provide the number of devices and device properties per device. - Specific prediction provider configuration to be provided by explicit configuration item (no union for all providers). - Measurement keys to be provided as a list. - New feed in tariff providers have to be configured. - /v1/measurement/loadxxx endpoints are removed. Use generic mesaurement endpoints. - /v1/admin/cache/clear now clears all cache files. Use /v1/admin/cache/clear-expired to only clear all expired cache files. Signed-off-by: Bobby Noelte <b0661n0e17e@gmail.com>
2025-10-28 02:50:31 +01:00
% SPDX-License-Identifier: Apache-2.0
(configtimewindow-page)=
# Time Window Sequence Configuration
## Overview
The `TimeWindowSequence` model is used to configure allowed time slots for home appliance runs.
It contains a collection of `TimeWindow` objects that define when appliances can operate.
## Basic Structure
A `TimeWindowSequence` is configured as a JSON object with a `windows` array:
```json
{
"windows": [
{
"start_time": "09:00",
"duration": "PT2H",
"day_of_week": null,
"date": null,
"locale": null
}
]
}
```
## TimeWindow Fields
Each `TimeWindow` object has the following fields:
- **`start_time`** (required): Time when the window begins
- **`duration`** (required): How long the window lasts
- **`day_of_week`** (optional): Restrict to specific day of week
- **`date`** (optional): Restrict to specific calendar date
- **`locale`** (optional): Language for day name parsing
## Time Formats
### Start Time (`start_time`)
The `start_time` field accepts various time formats:
#### 24-Hour Format
```json
{
"start_time": "14:30" // 2:30 PM
}
```
#### 12-Hour Format with AM/PM
```json
{
"start_time": "2:30 PM" // 2:30 PM
}
```
#### Compact Format
```json
{
"start_time": "1430" // 2:30 PM
}
```
#### With Seconds
```json
{
"start_time": "14:30:45" // 2:30:45 PM
}
```
#### With Microseconds
```json
{
"start_time": "14:30:45.123456"
}
```
#### European Format
```json
{
"start_time": "14h30" // 2:30 PM
}
```
#### Short Formats
```json
{
"start_time": "14" // 2:00 PM
}
```
```json
{
"start_time": "2PM" // 2:00 PM
}
```
#### Decimal Time
```json
{
"start_time": "14.5" // 2:30 PM (14:30)
}
```
#### With Timezones
```json
{
"start_time": "14:30 UTC"
}
```
```json
{
"start_time": "2:30 PM EST"
}
```
```json
{
"start_time": "14:30 +05:30"
}
```
### Duration (`duration`)
The `duration` field supports multiple formats for maximum flexibility:
#### ISO 8601 Duration Format (Recommended)
```json
{
"duration": "PT2H30M" // 2 hours 30 minutes
}
```
```json
{
"duration": "PT3H" // 3 hours
}
```
```json
{
"duration": "PT90M" // 90 minutes
}
```
```json
{
"duration": "PT1H30M45S" // 1 hour 30 minutes 45 seconds
}
```
#### Human-Readable String Format
The system accepts natural language duration strings:
```json
{
"duration": "2 hours 30 minutes"
}
```
```json
{
"duration": "3 hours"
}
```
```json
{
"duration": "90 minutes"
}
```
```json
{
"duration": "1 hour 30 minutes 45 seconds"
}
```
```json
{
"duration": "2 days 5 hours"
}
```
```json
{
"duration": "1 day 2 hours 30 minutes"
}
```
#### Singular and Plural Forms
Both singular and plural forms are supported:
```json
{
"duration": "1 day" // Singular
}
```
```json
{
"duration": "2 days" // Plural
}
```
```json
{
"duration": "1 hour" // Singular
}
```
```json
{
"duration": "5 hours" // Plural
}
```
#### Numeric Formats
##### Seconds as Integer
```json
{
"duration": 3600 // 3600 seconds = 1 hour
}
```
```json
{
"duration": 1800 // 1800 seconds = 30 minutes
}
```
##### Seconds as Float
```json
{
"duration": 3600.5 // 3600.5 seconds = 1 hour 0.5 seconds
}
```
##### Tuple Format [days, hours, minutes, seconds]
```json
{
"duration": [0, 2, 30, 0] // 0 days, 2 hours, 30 minutes, 0 seconds
}
```
```json
{
"duration": [1, 0, 0, 0] // 1 day
}
```
```json
{
"duration": [0, 0, 45, 30] // 45 minutes 30 seconds
}
```
```json
{
"duration": [2, 5, 15, 45] // 2 days, 5 hours, 15 minutes, 45 seconds
}
```
#### Mixed Time Units
You can combine different time units in string format:
```json
{
"duration": "1 day 4 hours 30 minutes 15 seconds"
}
```
```json
{
"duration": "3 days 2 hours"
}
```
```json
{
"duration": "45 minutes 30 seconds"
}
```
#### Common Duration Examples
##### Short Durations
```json
{
"duration": "30 minutes" // Quick appliance cycle
}
```
```json
{
"duration": "PT30M" // ISO format equivalent
}
```
```json
{
"duration": 1800 // Numeric equivalent (seconds)
}
```
##### Medium Durations
```json
{
"duration": "2 hours 15 minutes"
}
```
```json
{
"duration": "PT2H15M" // ISO format equivalent
}
```
```json
{
"duration": [0, 2, 15, 0] // Tuple format equivalent
}
```
##### Long Durations
```json
{
"duration": "1 day 8 hours" // All-day appliance window
}
```
```json
{
"duration": "PT32H" // ISO format equivalent
}
```
```json
{
"duration": [1, 8, 0, 0] // Tuple format equivalent
}
```
#### Validation Rules for Duration
- **ISO 8601 format**: Must start with `PT` and use valid duration specifiers (H, M, S)
- **String format**: Must contain valid time units (day/days, hour/hours, minute/minutes, second/seconds)
- **Numeric format**: Must be a positive number representing seconds
- **Tuple format**: Must be exactly 4 elements: [days, hours, minutes, seconds]
- **All formats**: Duration must be positive (greater than 0)
#### Duration Format Recommendations
1. **Use ISO 8601 format** for API consistency: `"PT2H30M"`
2. **Use human-readable strings** for configuration files: `"2 hours 30 minutes"`
3. **Use numeric format** for programmatic calculations: `9000` (seconds)
4. **Use tuple format** for structured data: `[0, 2, 30, 0]`
#### Error Handling for Duration
Common duration errors and solutions:
- **Invalid ISO format**: Ensure proper `PT` prefix and valid specifiers
- **Unknown time units**: Use day/days, hour/hours, minute/minutes, second/seconds
- **Negative duration**: All durations must be positive
- **Invalid tuple length**: Tuple must have exactly 4 elements
- **String too long**: Duration strings have a maximum length limit for security
## Day of Week Restrictions
### Using Numbers (0=Monday, 6=Sunday)
```json
{
"day_of_week": 0 // Monday
}
```
```json
{
"day_of_week": 6 // Sunday
}
```
### Using English Day Names
```json
{
"day_of_week": "Monday"
}
```
```json
{
"day_of_week": "sunday" // Case insensitive
}
```
### Using Localized Day Names
```json
{
"day_of_week": "Montag", // German for Monday
"locale": "de"
}
```
```json
{
"day_of_week": "Lundi", // French for Monday
"locale": "fr"
}
```
## Date Restrictions
### Specific Date
```json
{
"date": "2024-12-25" // Christmas Day 2024
}
```
**Note**: When `date` is specified, `day_of_week` is ignored.
## Complete Examples
### Example 1: Basic Daily Window
Allow appliance to run between 9:00 AM and 11:00 AM every day:
```json
{
"windows": [
{
"start_time": "09:00",
"duration": "PT2H"
}
]
}
```
### Example 2: Weekday Only
Allow appliance to run between 8:00 AM and 6:00 PM on weekdays:
```json
{
"windows": [
{
"start_time": "08:00",
"duration": "PT10H",
"day_of_week": 0
},
{
"start_time": "08:00",
"duration": "PT10H",
"day_of_week": 1
},
{
"start_time": "08:00",
"duration": "PT10H",
"day_of_week": 2
},
{
"start_time": "08:00",
"duration": "PT10H",
"day_of_week": 3
},
{
"start_time": "08:00",
"duration": "PT10H",
"day_of_week": 4
}
]
}
```
### Example 3: Multiple Daily Windows
Allow appliance to run during morning and evening hours:
```json
{
"windows": [
{
"start_time": "06:00",
"duration": "PT3H"
},
{
"start_time": "18:00",
"duration": "PT4H"
}
]
}
```
### Example 4: Weekend Special Hours
Different hours for weekdays and weekends:
```json
{
"windows": [
{
"start_time": "08:00",
"duration": "PT8H",
"day_of_week": "Monday"
},
{
"start_time": "08:00",
"duration": "PT8H",
"day_of_week": "Tuesday"
},
{
"start_time": "08:00",
"duration": "PT8H",
"day_of_week": "Wednesday"
},
{
"start_time": "08:00",
"duration": "PT8H",
"day_of_week": "Thursday"
},
{
"start_time": "08:00",
"duration": "PT8H",
"day_of_week": "Friday"
},
{
"start_time": "10:00",
"duration": "PT6H",
"day_of_week": "Saturday"
},
{
"start_time": "10:00",
"duration": "PT6H",
"day_of_week": "Sunday"
}
]
}
```
### Example 5: Holiday Schedule
Special schedule for a specific date:
```json
{
"windows": [
{
"start_time": "10:00",
"duration": "PT4H",
"date": "2024-12-25"
}
]
}
```
### Example 6: Localized Configuration
Using German day names:
```json
{
"windows": [
{
"start_time": "14:00",
"duration": "PT2H",
"day_of_week": "Montag",
"locale": "de"
},
{
"start_time": "14:00",
"duration": "PT2H",
"day_of_week": "Mittwoch",
"locale": "de"
},
{
"start_time": "14:00",
"duration": "PT2H",
"day_of_week": "Freitag",
"locale": "de"
}
]
}
```
### Example 7: Complex Schedule with Timezones
Multiple windows with different timezones:
```json
{
"windows": [
{
"start_time": "09:00 UTC",
"duration": "PT4H",
"day_of_week": "Monday"
},
{
"start_time": "2:00 PM EST",
"duration": "PT3H",
"day_of_week": "Friday"
}
]
}
```
### Example 8: Night Shift Schedule
Crossing midnight (note: each window is within a single day):
```json
{
"windows": [
{
"start_time": "22:00",
"duration": "PT2H"
},
{
"start_time": "00:00",
"duration": "PT6H"
}
]
}
```
## Advanced Usage Patterns
### Off-Peak Hours
Configure appliance to run during off-peak electricity hours:
```json
{
"windows": [
{
"start_time": "23:00",
"duration": "PT1H"
},
{
"start_time": "00:00",
"duration": "PT7H"
}
]
}
```
### Workday Lunch Break
Allow appliance to run during lunch break on workdays:
```json
{
"windows": [
{
"start_time": "12:00",
"duration": "PT1H",
"day_of_week": 0
},
{
"start_time": "12:00",
"duration": "PT1H",
"day_of_week": 1
},
{
"start_time": "12:00",
"duration": "PT1H",
"day_of_week": 2
},
{
"start_time": "12:00",
"duration": "PT1H",
"day_of_week": 3
},
{
"start_time": "12:00",
"duration": "PT1H",
"day_of_week": 4
}
]
}
```
### Seasonal Schedule
Different schedules for different dates:
```json
{
"windows": [
{
"start_time": "08:00",
"duration": "PT10H",
"date": "2024-06-21"
},
{
"start_time": "09:00",
"duration": "PT8H",
"date": "2024-12-21"
}
]
}
```
## Common Patterns
### 1. Always Available
```json
{
"windows": [
{
"start_time": "00:00",
"duration": "PT24H"
}
]
}
```
### 2. Business Hours
```json
{
"windows": [
{
"start_time": "09:00",
"duration": "PT8H",
"day_of_week": 0
},
{
"start_time": "09:00",
"duration": "PT8H",
"day_of_week": 1
},
{
"start_time": "09:00",
"duration": "PT8H",
"day_of_week": 2
},
{
"start_time": "09:00",
"duration": "PT8H",
"day_of_week": 3
},
{
"start_time": "09:00",
"duration": "PT8H",
"day_of_week": 4
}
]
}
```
### 3. Never Available
```json
{
"windows": []
}
```
## Validation Rules
- `start_time` must be a valid time format
- `duration` must be a positive duration
- `day_of_week` must be 0-6 (integer) or valid day name (string)
- `date` must be a valid ISO date format (YYYY-MM-DD)
- If `date` is specified, `day_of_week` is ignored
- `locale` must be a valid locale code when using localized day names
## Tips and Best Practices
1. **Use 24-hour format** for clarity: `"14:30"` instead of `"2:30 PM"`
2. **Keep durations reasonable** for appliance operation cycles
3. **Test timezone handling** if using timezone-aware times
4. **Use specific dates** for holiday schedules
5. **Consider overlapping windows** for flexibility
6. **Use localization** for international deployments
7. **Document your patterns** for maintenance
## Error Handling
Common errors and solutions:
- **Invalid time format**: Use supported time formats listed above
- **Invalid duration**: Use ISO 8601 duration format (PT1H30M)
- **Invalid day name**: Check spelling and locale settings
- **Invalid date**: Use YYYY-MM-DD format
- **Unknown locale**: Use standard locale codes (en, de, fr, etc.)
## Integration Examples
### Python Usage
```python
from pydantic import ValidationError
try:
config = TimeWindowSequence.model_validate_json(json_string)
print(f"Configured {len(config.windows)} time windows")
except ValidationError as e:
print(f"Configuration error: {e}")
```
### API Configuration
```json
{
"device_id": "dishwasher_01",
"time_windows": {
"windows": [
{
"start_time": "22:00",
"duration": "PT2H"
},
{
"start_time": "06:00",
"duration": "PT2H"
}
]
}
}
```