Cuts 0.18.0: config.yamlversion 0.17.0 -> 0.18.0 and a closed ## 0.18.0 CHANGELOG section. No code change. Not merged, no tag, no deploy.
Version: 0.18.0 (minor). New behaviour from OPT-17, SAFETY-112, OPT-15, MAINT-11, PRICE-01 and OPT-20, and three new options (83 -> 86): pv_forecast_entities, pv_forecast_tomorrow_entities (default []) and price_service_token (password, default empty). price_provider also accepts the new value price_service; its default is unchanged. No option removed or renamed, no default of an existing option changed. Existing installs need no option change.
Option diff vs 0.17.0 (e36565f):config.yaml +3 option keys, +3 schema keys, one enum value; translations/en.yaml and nl.yaml +3 entries each; app/validate.py adds start-up refusals only for the new keys (price_service with no token or a bad one; a forecast single key and list both set). No other option read or default changed in app/.
Offline checks (goodwe-addon-checks:1, --network none): test_version_gate, test_docs, test_defaults_pin, test_validate, test_tool_inputs pass. predeploy_check.py --deployed-version 0.17.0 on the live options: REFUSED before the bump (no-op), CLEARED after it, no warnings.
Deviations from docs/RELEASE.md (same as 0.17.0)
release/1.0 is protected, so the bump goes through this PR.
The CHANGELOG section is written to the CI gate (test_version_gate part 11).
No tag made.
predeploy_check was run at cut time, offline only.
CHANGELOG section (verbatim)
0.18.0
A minor bump: new behaviour, three new options and one new value for an
existing option. No option was removed or renamed, and no default of an
existing option changed (83 options -> 86). Existing installs need no option
change: options that start 0.17.0 also start 0.18.0, and the new options are
off or empty until you use them. The changes below apply with one inverter or
two, unless a line says "Two inverters".
New options, and what they do if you leave them alone:
the single forecast sensors work as before (OPT-17)
price_service_token
empty
not used; it is read only with price_provider: price_service (PRICE-01)
price_provider also accepts a new value, price_service. Its default is
unchanged, so the price source stays as it is.
Price service. The new price source price_service reads prices from the
add-on's price server, with the token you were given. If it does not answer,
prices come from energy-charts.info, then from the prices the add-on saved.
Sites on the Home Assistant price sensors or a fixed tariff need no change. To
move a site over, see DOCS.md, "Moving a site from the Home Assistant price
sensors to price_service".
Contents of this release, in merge order since 0.17.0 (e36565f):
3050fa5
The solar forecast can come from several sensors, added up, for example one per inverter. If one of them has no reading, that day's forecast is not used, and the status says which one. The single sensor still works (OPT-17)
e3e4ba6
While Home Assistant is still starting, the page now says "Waiting for Home Assistant" and the log says the add-on waits, instead of looking like a fault. Control itself is unchanged: it starts when Home Assistant answers (SAFETY-112)
79dd077
Battery modes on only: a charge in a cheap run no longer stops at the start of a new 15-minute period, and with two inverters a battery that refused to charge is tried again every 15 min. In one test, the export at the end of a charge was 48 W where the code before this fix gave 746 W (OPT-15)
0ce7d35
Two inverters: each battery card has Start cycle and Stop cycle buttons, so you can start or stop the cycle on the battery you choose. Only one battery can cycle at a time, and a second start is refused with a short message (MAINT-11)
bf9019e
New price source price_service. If it fails, prices come from energy-charts.info, then from saved prices. With no price at all and the monthly cycle on, a notice shows and the cycle waits (PRICE-01)
004f859
Two inverters, battery modes on: the 15-minute retry of a battery that refused to charge now asks that battery for 200 W, and no longer puts the rest of the charge on another battery. In the test, without this fix, a battery in its maintenance charge took about 2,300 W for about 34 s at each retry (OPT-20)
Known issues
A false "Battery is not keeping up" can still show when the peak guard pauses a maintenance charge (SAFETY-92).
A battery capped at a low limit with a perfectly flat reading can still trip the stale check (SAFETY-74).
A battery whose reading at rest is beyond about ±175 W is still not caught when it refuses (SAFETY-97).
The peak guard can still back off near the end of a 15-minute period when a meter reading is late, by less than 30 s (SAFETY-99).
Two inverters: the maintenance charge can switch on and off while the house is above the peak aim (SAFETY-88).
Two inverters: the "circulating" figure counts a battery's reading at rest (SAFETY-98).
Two inverters: a drain that starts during a big step in house use can send the other battery to full power, and about 1 kW goes to the grid for about 10 s (SAFETY-104).
Two inverters: when a battery comes back during a maintenance charge, the grid can step by several kW at once (SAFETY-101).
Two inverters: when a battery drops out during a solar surplus, the others can swing by up to 1.5 kW in a simulation (SAFETY-105).
Two inverters: after a drain ends, a change in house use can go unanswered for about 9 s, because some readings are old (SAFETY-106).
Two inverters: when one battery's level is missing, both batteries are held at 0 W, and for about 15 s the last command stays on (SAFETY-108).
Two inverters: if one battery's level stays missing for 12 h, the other battery's cycle can be marked failed, with a 7-day wait and a notice, though it is healthy. This comes from reading the code; it has not been seen on a site (MAINT-17).
When the 15-minute demand forecast sensor counts the battery's own charge, the maintenance charge runs at about half the power the peak limit leaves, so it takes about twice as long. Seen on a site: about 1.2 kW instead of 2.5 kW, and the peak limit was kept (SAFETY-111).
One inverter: after a link drop, the battery's own safety stop to 0 W can be taken as a refusal, and the site stays at 0 W for up to 15 min (SAFETY-102).
After a Home Assistant restart, control still waits until Home Assistant has finished starting, which can take several minutes, though the readings are already there (SAFETY-115).
While Home Assistant is not answering, the page can list inverters as refusing commands and sensors as missing, and send you to Developer Tools, though they are fine (UX-37).
If Home Assistant hangs or stops, the page keeps saying "Waiting for Home Assistant" and never turns into an alarm (SAFETY-113).
Right after Home Assistant has started, the page can say for about 4 s that an inverter cannot be controlled, and the first command can come late (SAFETY-114).
After a Home Assistant restart, the controller status sensor can still say "running" while the add-on cannot control. It was seen once, and the cause is not known (SAFETY-116).
Battery modes on: after a planned top-up from the grid, the Batteries screen can say "Enough sun is forecast" (UX-32).
Battery modes on: the forecast line "we count on" can show more sun than the plan counts, because the plan takes house use off first (UX-33).
Battery modes on: before a planned top-up, the Today list shows a smaller "gives" amount than the plan will use; it grows as the charge happens (UX-34).
Two inverters, battery modes on: while the other battery is in its maintenance charge, a battery's card can say it charges from the grid while it stays at 0 W (OPT-18).
Two inverters, battery modes on: while a battery refuses to charge in a cheap run, the action log on the page gets about 8 lines an hour for its retries, and the page hint says "waiting for a better price" (UX-38).
A battery in a safety stop, or one the add-on cannot reach, can still be started for a cycle, and its drain then waits about 12 h and ends in a failed-cycle notice. This comes from reading the code; it has not been seen on a site (MAINT-19).
On the Settings page, the rows of the solar forecast lists are labelled "Phase 1", "Phase 2" instead of "Sensor 1", "Sensor 2" (UX-27).
In the solar forecast list, a blank or repeated row makes "source 2 of 2" count differently from the rows on the Settings page (UX-28).
The solar forecast message says "has no reading" also when the sensor shows a number that is too old or in the wrong unit (UX-29).
If you use only the forecast lists, two Settings notes sit on the single-sensor field, and one of them tells you to set that field (UX-30).
After a restart during a price outage, the "No prices" message can say "yet" when prices did come in earlier (UX-39).
On the new settings page, you cannot see whether a price service token is set. Check the Configuration tab (UX-41).
On the classic settings page, the first click on Save after editing a field can do nothing. Click again (UX-42).
If you are crossing from a version older than 0.10.0
## 0.10.0 below can refuse an old config: slew_w above its limit, and the
withdrawn price_provider ids engie_dynamic, totalenergies_dynamic and eneco_eddy. Read it before you update. Run tools/predeploy_check.py with the
bare options (jq '.data.options') first.
Cuts **0.18.0**: `config.yaml` `version` 0.17.0 -> 0.18.0 and a closed `## 0.18.0` CHANGELOG section. No code change. Not merged, no tag, no deploy.
**Version: 0.18.0 (minor).** New behaviour from OPT-17, SAFETY-112, OPT-15, MAINT-11, PRICE-01 and OPT-20, and **three new options** (83 -> 86): `pv_forecast_entities`, `pv_forecast_tomorrow_entities` (default `[]`) and `price_service_token` (password, default empty). `price_provider` also accepts the new value `price_service`; its default is unchanged. No option removed or renamed, no default of an existing option changed. **Existing installs need no option change.**
**Option diff vs 0.17.0 (`e36565f`):** `config.yaml` +3 option keys, +3 schema keys, one enum value; `translations/en.yaml` and `nl.yaml` +3 entries each; `app/validate.py` adds start-up refusals only for the new keys (`price_service` with no token or a bad one; a forecast single key and list both set). No other option read or default changed in `app/`.
**Offline checks (`goodwe-addon-checks:1`, `--network none`):** test_version_gate, test_docs, test_defaults_pin, test_validate, test_tool_inputs pass. `predeploy_check.py --deployed-version 0.17.0` on the live options: REFUSED before the bump (no-op), CLEARED after it, no warnings.
## Deviations from docs/RELEASE.md (same as 0.17.0)
1. `release/1.0` is protected, so the bump goes through this PR.
2. The CHANGELOG section is written to the CI gate (test_version_gate part 11).
3. No tag made.
4. predeploy_check was run at cut time, offline only.
## CHANGELOG section (verbatim)
## 0.18.0
**A minor bump: new behaviour, three new options and one new value for an
existing option.** No option was removed or renamed, and no default of an
existing option changed (83 options -> 86). **Existing installs need no option
change:** options that start 0.17.0 also start 0.18.0, and the new options are
off or empty until you use them. The changes below apply with one inverter or
two, unless a line says "Two inverters".
New options, and what they do if you leave them alone:
| option | default | left alone |
|---|---|---|
| `pv_forecast_entities`, `pv_forecast_tomorrow_entities` | `[]` | the single forecast sensors work as before ([[OPT-17]]) |
| `price_service_token` | empty | not used; it is read only with `price_provider: price_service` ([[PRICE-01]]) |
`price_provider` also accepts a new value, `price_service`. Its default is
unchanged, so the price source stays as it is.
**Price service.** The new price source `price_service` reads prices from the
add-on's price server, with the token you were given. If it does not answer,
prices come from energy-charts.info, then from the prices the add-on saved.
Sites on the Home Assistant price sensors or a fixed tariff need no change. To
move a site over, see `DOCS.md`, "Moving a site from the Home Assistant price
sensors to `price_service`".
Contents of this release, in merge order since 0.17.0 (`e36565f`):
| | |
|---|---|
| `3050fa5` | The solar forecast can come from several sensors, added up, for example one per inverter. If one of them has no reading, that day's forecast is not used, and the status says which one. The single sensor still works ([[OPT-17]]) |
| `e3e4ba6` | While Home Assistant is still starting, the page now says "Waiting for Home Assistant" and the log says the add-on waits, instead of looking like a fault. Control itself is unchanged: it starts when Home Assistant answers ([[SAFETY-112]]) |
| `79dd077` | Battery modes on only: a charge in a cheap run no longer stops at the start of a new 15-minute period, and with two inverters a battery that refused to charge is tried again every 15 min. In one test, the export at the end of a charge was 48 W where the code before this fix gave 746 W ([[OPT-15]]) |
| `0ce7d35` | Two inverters: each battery card has Start cycle and Stop cycle buttons, so you can start or stop the cycle on the battery you choose. Only one battery can cycle at a time, and a second start is refused with a short message ([[MAINT-11]]) |
| `bf9019e` | New price source `price_service`. If it fails, prices come from energy-charts.info, then from saved prices. With no price at all and the monthly cycle on, a notice shows and the cycle waits ([[PRICE-01]]) |
| `004f859` | Two inverters, battery modes on: the 15-minute retry of a battery that refused to charge now asks that battery for 200 W, and no longer puts the rest of the charge on another battery. In the test, without this fix, a battery in its maintenance charge took about 2,300 W for about 34 s at each retry ([[OPT-20]]) |
### Known issues
- A false "Battery is not keeping up" can still show when the peak guard pauses a maintenance charge ([[SAFETY-92]]).
- A battery capped at a low limit with a perfectly flat reading can still trip the stale check ([[SAFETY-74]]).
- A battery whose reading at rest is beyond about ±175 W is still not caught when it refuses ([[SAFETY-97]]).
- The peak guard can still back off near the end of a 15-minute period when a meter reading is late, by less than 30 s ([[SAFETY-99]]).
- Two inverters: the maintenance charge can switch on and off while the house is above the peak aim ([[SAFETY-88]]).
- Two inverters: the "circulating" figure counts a battery's reading at rest ([[SAFETY-98]]).
- Two inverters: a drain that starts during a big step in house use can send the other battery to full power, and about 1 kW goes to the grid for about 10 s ([[SAFETY-104]]).
- Two inverters: when a battery comes back during a maintenance charge, the grid can step by several kW at once ([[SAFETY-101]]).
- Two inverters: when a battery drops out during a solar surplus, the others can swing by up to 1.5 kW in a simulation ([[SAFETY-105]]).
- Two inverters: after a drain ends, a change in house use can go unanswered for about 9 s, because some readings are old ([[SAFETY-106]]).
- Two inverters: when one battery's level is missing, both batteries are held at 0 W, and for about 15 s the last command stays on ([[SAFETY-108]]).
- Two inverters: if one battery's level stays missing for 12 h, the other battery's cycle can be marked failed, with a 7-day wait and a notice, though it is healthy. This comes from reading the code; it has not been seen on a site ([[MAINT-17]]).
- When the 15-minute demand forecast sensor counts the battery's own charge, the maintenance charge runs at about half the power the peak limit leaves, so it takes about twice as long. Seen on a site: about 1.2 kW instead of 2.5 kW, and the peak limit was kept ([[SAFETY-111]]).
- One inverter: after a link drop, the battery's own safety stop to 0 W can be taken as a refusal, and the site stays at 0 W for up to 15 min ([[SAFETY-102]]).
- After a Home Assistant restart, control still waits until Home Assistant has finished starting, which can take several minutes, though the readings are already there ([[SAFETY-115]]).
- While Home Assistant is not answering, the page can list inverters as refusing commands and sensors as missing, and send you to Developer Tools, though they are fine ([[UX-37]]).
- If Home Assistant hangs or stops, the page keeps saying "Waiting for Home Assistant" and never turns into an alarm ([[SAFETY-113]]).
- Right after Home Assistant has started, the page can say for about 4 s that an inverter cannot be controlled, and the first command can come late ([[SAFETY-114]]).
- After a Home Assistant restart, the controller status sensor can still say "running" while the add-on cannot control. It was seen once, and the cause is not known ([[SAFETY-116]]).
- Battery modes on: after a planned top-up from the grid, the Batteries screen can say "Enough sun is forecast" ([[UX-32]]).
- Battery modes on: the forecast line "we count on" can show more sun than the plan counts, because the plan takes house use off first ([[UX-33]]).
- Battery modes on: before a planned top-up, the Today list shows a smaller "gives" amount than the plan will use; it grows as the charge happens ([[UX-34]]).
- Two inverters, battery modes on: while the other battery is in its maintenance charge, a battery's card can say it charges from the grid while it stays at 0 W ([[OPT-18]]).
- Two inverters, battery modes on: while a battery refuses to charge in a cheap run, the action log on the page gets about 8 lines an hour for its retries, and the page hint says "waiting for a better price" ([[UX-38]]).
- A battery in a safety stop, or one the add-on cannot reach, can still be started for a cycle, and its drain then waits about 12 h and ends in a failed-cycle notice. This comes from reading the code; it has not been seen on a site ([[MAINT-19]]).
- On the Settings page, the rows of the solar forecast lists are labelled "Phase 1", "Phase 2" instead of "Sensor 1", "Sensor 2" ([[UX-27]]).
- In the solar forecast list, a blank or repeated row makes "source 2 of 2" count differently from the rows on the Settings page ([[UX-28]]).
- The solar forecast message says "has no reading" also when the sensor shows a number that is too old or in the wrong unit ([[UX-29]]).
- If you use only the forecast lists, two Settings notes sit on the single-sensor field, and one of them tells you to set that field ([[UX-30]]).
- After a restart during a price outage, the "No prices" message can say "yet" when prices did come in earlier ([[UX-39]]).
- On the new settings page, you cannot see whether a price service token is set. Check the Configuration tab ([[UX-41]]).
- On the classic settings page, the first click on Save after editing a field can do nothing. Click again ([[UX-42]]).
### If you are crossing from a version older than 0.10.0
`## 0.10.0` below can refuse an old config: `slew_w` above its limit, and the
withdrawn `price_provider` ids `engie_dynamic`, `totalenergies_dynamic` and
`eneco_eddy`. Read it before you update. Run `tools/predeploy_check.py` with the
bare options (`jq '.data.options'`) first.
Co-authored by Claude.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
https://claude.ai/code/session_01Bdqr7PiaHcBnzPituu2yTC
config.yaml version 0.17.0 -> 0.18.0 and a closed ## 0.18.0 CHANGELOG
section for OPT-17, SAFETY-112, OPT-15, MAINT-11, PRICE-01 and OPT-20.
No code change.
Co-Authored-By: Claude <noreply@anthropic.com>
Model-router T48 (dev round 1, Sonnet): PASS from Opus verifier on e7c83d3. CI run 1292 checks/unit and 1293 infra-pin green on e7c83d3. Next: Opus review.
Model-router T48 (dev round 1, Sonnet): PASS from Opus verifier on e7c83d3. CI run 1292 checks/unit and 1293 infra-pin green on e7c83d3. Next: Opus review.
OPT-15 and OPT-20 rows: the retry is two inverters only, and OPT-20 no
longer claims no other battery moves. SAFETY-111 added to known issues.
MAINT-19 marked as from code reading. Wording fixes in the SAFETY-112 and
MAINT-11 rows, UX-38 and the price service note.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
REL-0.18.0 review, round 1 (reviewed e7c83d3; fixes pushed as 44cd1fd).
Checks 1, 2, 5, 7 and 8 pass on the dev's head: only config.yaml and the new section changed; options 83 -> 86 (pv_forecast_entities, pv_forecast_tomorrow_entities, price_service_token), price_provider gains price_service, nothing removed or renamed, no default changed, validator refusals only for the new keys, so minor is right and "no option change" holds. The table lists exactly the six first-parent changes. Kept known issues are word for word 0.17.0's, all still To Do (SAFETY-97 Done, but IDLE_MAX_W 75 + REFUSED_BELOW_W 100 are unchanged).
Findings, all in goodwe_controller/CHANGELOG.md, all text, fixed in 44cd1fd:
F1 (medium, OPT-15 row): the 15-minute retry is two inverters only (main.py_probing needs len(self.inverters) > 1; OPT-15 dev report says so). The row did not say so, and the header says rows apply to one inverter or two. Now "with two inverters a battery that refused to charge is tried again every 15 min".
F2 (medium, OPT-20 row): "Battery modes on only" -> "Two inverters, battery modes on" (same reason). "moves no other battery" overstated: a battery that is giving power to the house still rests for the probe window (OPT-20 test check 4, same as base). Now "no longer puts the rest of the charge on another battery". "for 34 s each time" -> "for about 34 s at each retry" (33-34 s in the test).
F3 (medium, known issues): SAFETY-111 (To Do, filed after the 0.17.0 cut, seen live) was not considered: the maintenance charge runs at about half the room under the peak limit when the demand forecast counts its own charge. Added.
F4 (low, MAINT-19): the card comes from the MAINT-11 review (code reading), not a run. Added "This comes from reading the code; it has not been seen on a site", as for MAINT-17.
F5 (low, SAFETY-112 row): the log does not say "Waiting for Home Assistant"; only the page does. Now "the page now says ... and the log says the add-on waits".
F6 (low, MAINT-11 row): "so you choose which battery gets the monthly cycle" -> "so you can start or stop the cycle on the battery you choose". The buttons start or stop a cycle now; the scheduled cycle still picks its own battery.
F7 (low, UX-38): "the log" -> "the action log on the page"; the add-on log writes nothing for an unanswered probe (OPT-15 test check 6).
F8 (low, price service note): "your own price server" is not true for a client site; it is the add-on's server. Now "reads prices from the add-on's price server, with the token you were given".
Known issues: the dev added 18, not 23 (13 kept + 18 = 31; with SAFETY-111, 32). I agree with the judgement calls UX-38, UX-28, UX-33 and UX-34 (each shows a wrong number or hint on the page) and with every left-out card. UX-26 was not listed by the dev: its text is in a log line only (maintenance.py:637), so it stays out.
The PR body's verbatim section is updated. Merge once checks / unit is green on 44cd1fd.
**REL-0.18.0 review, round 1 (reviewed e7c83d3; fixes pushed as 44cd1fd).**
Checks 1, 2, 5, 7 and 8 pass on the dev's head: only `config.yaml` and the new section changed; options 83 -> 86 (`pv_forecast_entities`, `pv_forecast_tomorrow_entities`, `price_service_token`), `price_provider` gains `price_service`, nothing removed or renamed, no default changed, validator refusals only for the new keys, so minor is right and "no option change" holds. The table lists exactly the six first-parent changes. Kept known issues are word for word 0.17.0's, all still To Do (SAFETY-97 Done, but `IDLE_MAX_W` 75 + `REFUSED_BELOW_W` 100 are unchanged).
Findings, all in `goodwe_controller/CHANGELOG.md`, all text, fixed in 44cd1fd:
- **F1 (medium, OPT-15 row):** the 15-minute retry is two inverters only (`main.py` `_probing` needs `len(self.inverters) > 1`; OPT-15 dev report says so). The row did not say so, and the header says rows apply to one inverter or two. Now "with two inverters a battery that refused to charge is tried again every 15 min".
- **F2 (medium, OPT-20 row):** "Battery modes on only" -> "Two inverters, battery modes on" (same reason). "moves no other battery" overstated: a battery that is giving power to the house still rests for the probe window (OPT-20 test check 4, same as base). Now "no longer puts the rest of the charge on another battery". "for 34 s each time" -> "for about 34 s at each retry" (33-34 s in the test).
- **F3 (medium, known issues):** SAFETY-111 (To Do, filed after the 0.17.0 cut, seen live) was not considered: the maintenance charge runs at about half the room under the peak limit when the demand forecast counts its own charge. Added.
- **F4 (low, MAINT-19):** the card comes from the MAINT-11 review (code reading), not a run. Added "This comes from reading the code; it has not been seen on a site", as for MAINT-17.
- **F5 (low, SAFETY-112 row):** the log does not say "Waiting for Home Assistant"; only the page does. Now "the page now says ... and the log says the add-on waits".
- **F6 (low, MAINT-11 row):** "so you choose which battery gets the monthly cycle" -> "so you can start or stop the cycle on the battery you choose". The buttons start or stop a cycle now; the scheduled cycle still picks its own battery.
- **F7 (low, UX-38):** "the log" -> "the action log on the page"; the add-on log writes nothing for an unanswered probe (OPT-15 test check 6).
- **F8 (low, price service note):** "your own price server" is not true for a client site; it is the add-on's server. Now "reads prices from the add-on's price server, with the token you were given".
Known issues: the dev added 18, not 23 (13 kept + 18 = 31; with SAFETY-111, 32). I agree with the judgement calls UX-38, UX-28, UX-33 and UX-34 (each shows a wrong number or hint on the page) and with every left-out card. UX-26 was not listed by the dev: its text is in a log line only (`maintenance.py:637`), so it stays out.
The PR body's verbatim section is updated. Merge once `checks / unit` is green on 44cd1fd.
admin
merged commit a0e091cca3 into release/1.02026-10-15 23:17:11 +02:00
Merged with head_commit_id pinned to 44cd1fd (HTTP 200). checks / unit (pull_request) succeeded on 44cd1fd in run 1294 (22:35:53 to 23:16:10, a real run), and infra-pin / fresh succeeded in run 1295. Merge commit a0e091c, with parents 004f859 and 44cd1fd. ls-remote: release/1.0 a0e091c, release-0.18.0 44cd1fd, master 1b6f16d (unchanged). No tag, no master PR, no deploy.
**Merged** with head_commit_id pinned to 44cd1fd (HTTP 200). checks / unit (pull_request) succeeded on 44cd1fd in run 1294 (22:35:53 to 23:16:10, a real run), and infra-pin / fresh succeeded in run 1295. Merge commit a0e091c, with parents 004f859 and 44cd1fd. ls-remote: release/1.0 a0e091c, release-0.18.0 44cd1fd, master 1b6f16d (unchanged). No tag, no master PR, no deploy.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Cuts 0.18.0:
config.yamlversion0.17.0 -> 0.18.0 and a closed## 0.18.0CHANGELOG section. No code change. Not merged, no tag, no deploy.Version: 0.18.0 (minor). New behaviour from OPT-17, SAFETY-112, OPT-15, MAINT-11, PRICE-01 and OPT-20, and three new options (83 -> 86):
pv_forecast_entities,pv_forecast_tomorrow_entities(default[]) andprice_service_token(password, default empty).price_provideralso accepts the new valueprice_service; its default is unchanged. No option removed or renamed, no default of an existing option changed. Existing installs need no option change.Option diff vs 0.17.0 (
e36565f):config.yaml+3 option keys, +3 schema keys, one enum value;translations/en.yamlandnl.yaml+3 entries each;app/validate.pyadds start-up refusals only for the new keys (price_servicewith no token or a bad one; a forecast single key and list both set). No other option read or default changed inapp/.Offline checks (
goodwe-addon-checks:1,--network none): test_version_gate, test_docs, test_defaults_pin, test_validate, test_tool_inputs pass.predeploy_check.py --deployed-version 0.17.0on the live options: REFUSED before the bump (no-op), CLEARED after it, no warnings.Deviations from docs/RELEASE.md (same as 0.17.0)
release/1.0is protected, so the bump goes through this PR.CHANGELOG section (verbatim)
0.18.0
A minor bump: new behaviour, three new options and one new value for an
existing option. No option was removed or renamed, and no default of an
existing option changed (83 options -> 86). Existing installs need no option
change: options that start 0.17.0 also start 0.18.0, and the new options are
off or empty until you use them. The changes below apply with one inverter or
two, unless a line says "Two inverters".
New options, and what they do if you leave them alone:
pv_forecast_entities,pv_forecast_tomorrow_entities[]price_service_tokenprice_provider: price_service(PRICE-01)price_provideralso accepts a new value,price_service. Its default isunchanged, so the price source stays as it is.
Price service. The new price source
price_servicereads prices from theadd-on's price server, with the token you were given. If it does not answer,
prices come from energy-charts.info, then from the prices the add-on saved.
Sites on the Home Assistant price sensors or a fixed tariff need no change. To
move a site over, see
DOCS.md, "Moving a site from the Home Assistant pricesensors to
price_service".Contents of this release, in merge order since 0.17.0 (
e36565f):3050fa5e3e4ba679dd0770ce7d35bf9019eprice_service. If it fails, prices come from energy-charts.info, then from saved prices. With no price at all and the monthly cycle on, a notice shows and the cycle waits (PRICE-01)004f859Known issues
If you are crossing from a version older than 0.10.0
## 0.10.0below can refuse an old config:slew_wabove its limit, and thewithdrawn
price_provideridsengie_dynamic,totalenergies_dynamicandeneco_eddy. Read it before you update. Runtools/predeploy_check.pywith thebare options (
jq '.data.options') first.Co-authored by Claude.
🤖 Generated with Claude Code
https://claude.ai/code/session_01Bdqr7PiaHcBnzPituu2yTC
Model-router T48 (dev round 1, Sonnet): PASS from Opus verifier on
e7c83d3. CI run 1292 checks/unit and 1293 infra-pin green one7c83d3. Next: Opus review.REL-0.18.0 review, round 1 (reviewed e7c83d3; fixes pushed as
44cd1fd).Checks 1, 2, 5, 7 and 8 pass on the dev's head: only
config.yamland the new section changed; options 83 -> 86 (pv_forecast_entities,pv_forecast_tomorrow_entities,price_service_token),price_providergainsprice_service, nothing removed or renamed, no default changed, validator refusals only for the new keys, so minor is right and "no option change" holds. The table lists exactly the six first-parent changes. Kept known issues are word for word 0.17.0's, all still To Do (SAFETY-97 Done, butIDLE_MAX_W75 +REFUSED_BELOW_W100 are unchanged).Findings, all in
goodwe_controller/CHANGELOG.md, all text, fixed in44cd1fd:main.py_probingneedslen(self.inverters) > 1; OPT-15 dev report says so). The row did not say so, and the header says rows apply to one inverter or two. Now "with two inverters a battery that refused to charge is tried again every 15 min".Known issues: the dev added 18, not 23 (13 kept + 18 = 31; with SAFETY-111, 32). I agree with the judgement calls UX-38, UX-28, UX-33 and UX-34 (each shows a wrong number or hint on the page) and with every left-out card. UX-26 was not listed by the dev: its text is in a log line only (
maintenance.py:637), so it stays out.The PR body's verbatim section is updated. Merge once
checks / unitis green on44cd1fd.Merged with head_commit_id pinned to
44cd1fd(HTTP 200). checks / unit (pull_request) succeeded on44cd1fdin run 1294 (22:35:53 to 23:16:10, a real run), and infra-pin / fresh succeeded in run 1295. Merge commita0e091c, with parents004f859and44cd1fd. ls-remote: release/1.0a0e091c, release-0.18.044cd1fd, master1b6f16d(unchanged). No tag, no master PR, no deploy.