|
2 | 2 |
|
3 | 3 | ## Summary |
4 | 4 |
|
5 | | -This release introduces a number of breaking changes in the config manager, the new `ComponentId`/`MicrogridId` types and the `numpy` version update. It also includes bug-fixes to the component graph and power management. |
| 5 | +<!-- Here goes a general summary of what this release is about --> |
6 | 6 |
|
7 | 7 | ## Upgrading |
8 | 8 |
|
9 | | -* Includes a major update of the numpy dependency to v2.x. |
| 9 | +<!-- Here goes notes on how to upgrade from previous versions, including deprecations and what they should be replaced with --> |
10 | 10 |
|
11 | | -* The logging configuration was changed, and now the logger name needs to be specified explicitly (the configuration key was used as the name before). This is to be compatible with configuration generated by the UI, which doesn't quote sub-key properly. |
| 11 | +## New Features |
12 | 12 |
|
13 | | - - Before: |
14 | | - |
15 | | - ```toml |
16 | | - [logging.loggers."frequenz.sdk.config"] |
17 | | - level = "DEBUG" |
18 | | - ``` |
19 | | - |
20 | | - - Now: |
21 | | - |
22 | | - ```toml |
23 | | - [logging.loggers.frequenz_config] |
24 | | - name = "frequenz.sdk.config" |
25 | | - level = "DEBUG" |
26 | | - ``` |
27 | | - |
28 | | -* The logging configuration now uses a separate class for the root logger configuration: `RootLoggerConfig`. |
29 | | - |
30 | | - - Before: |
31 | | - |
32 | | - ```py |
33 | | - LoggingConfig(root_logger=LoggerConfig(level="ERROR")) |
34 | | - ``` |
35 | | - |
36 | | - - Now: |
37 | | - |
38 | | - ```py |
39 | | - LoggingConfig(root_logger=RootLoggerConfig(level="ERROR")) |
40 | | - ``` |
41 | | - |
42 | | -* The SDK now depends on the `frequenz-client-microgrid` v0.7.x series. The main change is now all component and microgrid IDs need to be passed using the wrapper classes `ComponentId`/`MicrogridId` instead of `int`. |
| 13 | +<!-- Here goes the main new features and examples or instructions on how to use them --> |
43 | 14 |
|
44 | 15 | ## Bug Fixes |
45 | 16 |
|
46 | | -- The power manager used to just forgot components when all proposals to them are withdrawn, leaving them at their last set power values. This has been fixed by getting the power manager to set the components to their default powers, based on the component category (according to the table below), as the last step. |
47 | | - |
48 | | - |
49 | | - | component category | default power | |
50 | | - |--------------------|-------------------------------------------| |
51 | | - | Battery | 0.0 | |
52 | | - | PV | Minimum power (aka max production power) | |
53 | | - | EV Chargers | Maximum power (aka max consumption power) | |
54 | | - |
55 | | -- PV Pool instances can now be created in sites without any PV. This allows for writing generic code that works for all locations, that depends on the PV power formula, for example. |
56 | | - |
57 | | -- `Success/PartialFailure` results from `PVPool.power_distribution_results` now report correct `succeeded_power` values. |
58 | | - |
59 | | -- The `find_first_descendant_component` method in the component graph was allowing non-root components to be used as the root component during traversal. This was leading to confusing behaviour when the root component couldn't be identified deterministically. For example, if the root category was specified as a meter, it could start traversing from a different meter each time. It is no-longer possible to specify a root category anymore and it always traverses from the `GRID` component. |
| 17 | +<!-- Here goes notable bug fixes that are worth a special mention or explanation --> |
0 commit comments