Repository navigation
Add preset temperatures and weekly schedules for Adam zones - #937
MartvanMale wants to merge 7 commits into
Conversation
_presets() now reads only the preset rule attached to the zone, so each zone on an Adam with several zones gets its own preset setpoints. When no rule or several rules are attached to a zone, it reads all preset rules, so gateways without per-zone rules keep their preset list.
set_number() sends all five presets on every write and changes only the target heating setpoint. The gateway replaces a rule's whole directive set on each write.
Schedules are keyed by rule id. Slot start and end times keep the gateway's notation, such as "mo 07:15".
Slots are checked for valid day and time notation and a setpoint between 4 and 30 before anything is sent to the gateway.
set_schedule_state() sends active=true with the contexts when a schedule is switched on. Switching off leaves the flag as it is.
- set_schedule_state() switches on a schedule that is attached but inactive, instead of treating it as already on. - set_schedule() no longer fails on a rule without directives or a name, and set_preset_temperature() refuses a preset rule whose switch point lacks its settings.
- Switching an attached schedule on again no longer adds its zone a second time. - A schedule renamed through set_schedule() can be switched by its new name. - Schedule writes check every setpoint value and slot key, and refuse a name containing "]]>". - Preset writes keep every attribute of the rule and escape the values. - Legacy gateways refuse schedule writes instead of ignoring them.
|
No actionable comments were generated in the recent review.
 |
| Layer / File(s) | Summary |
|---|---|
Gateway data and entity parsing plugwise/constants.py, plugwise/helper.py, plugwise/data.py, fixtures/*/data.json, tests/data/* |
The gateway data model now includes schedule details and five preset-temperature actuators. Parsing collects schedule names, activation state, zone associations, time slots, and preset-rule data. Device fixtures add schedule and preset-temperature examples. |
Preset and schedule write behavior plugwise/smile.py, tests/test_adam.py, tests/test_init.py |
The API validates and serializes preset and schedule writes. It updates cached rule data after successful requests. Schedule activation requests now set the active marker and avoid duplicate zone-context changes. |
Public API and legacy behavior plugwise/__init__.py, plugwise/legacy/smile.py, tests/test_legacy_anna.py, CHANGELOG.md |
The public API exposes schedule set, create, and delete methods. The legacy API rejects these operations. The changelog records the schedule and preset-temperature changes. |
Priority:
Estimated code review effort: 4 (Complex) | ~60 minutes
Change: Feature
Sequence Diagram(s)
sequenceDiagram
participant Client
participant SmileAPI
participant Gateway
Client->>SmileAPI: Request schedule update
SmileAPI->>Gateway: Send validated schedule data
Gateway-->>SmileAPI: Return response
SmileAPI->>SmileAPI: Update cached schedule state
Possibly related PRs
- plugwise/python-plugwise#934: Both changes cover selection and activation of schedules linked to a location, including schedules that are inactive.
- plugwise/python-plugwise#936: This change adds schedule and preset write requests that use the request retry path addressed by PR
#936.
Suggested reviewers: compatech, bouwew
Merge Risk: 
fa2ff
-
This change adds per-zone preset temperatures and schedule editing for Adam and Anna gateways. No concrete merge-blocking defect was found in the supplied context. The open question about preset heating values above the cooling value rests on gateway behavior that has not been confirmed.
Pre-merge checks: 
-
Check name Status Explanation Description Check Check skipped - CodeRabbit’s high-level summary is enabled. Title check The title clearly identifies the main changes: preset temperatures and weekly schedules. It is concise and directly related to the changeset, although it does not mention the additional Anna support. Docstring Coverage Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 69 functions across 10 files. (58 skipped:… Linked Issues check Check skipped because no linked issues were found for this pull request. Out of Scope Changes check Check skipped because no linked issues were found for this pull request. Full details: Docstring Coverage
-
Explanation
Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 69 functions across 10 files. (58 skipped: 58 unsupported.)
-
Finishing Touches
-
🧪 Generate unit tests (beta)
-
- Create a new PR
-
- Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.
Comment @coderabbitai help to get the list of available commands.
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
|
@MartvanMale nice work!! And yes, please split this PR in two parts, one covering the presets and one covering the schedules. Also, I would want to test the integration-updates in Plugwise-beta before rolling them out to HA Plugwise (I just had a look in your github, you are already testing in pw-beta👍)). |
|
Thanks, I will split this PR into two and create one into plugwise-beta. |
bouwew
left a comment
bouwew
left a comment
There was a problem hiding this comment.
Please split this PR into two separate PR's, thanks!
|
@MartvanMale please rebase onto the updated plugwise main branch (= v1.16.0) and create a new PR for the weekly schedule functions. |
Draft: I'm still doing a final review of my own before this is ready.Summary
This adds two things Home Assistant users of an Adam (and a non-legacy Anna) cannot do today: change the temperatures behind the presets of a zone, and read and change the weekly schedules on the gateway. It picks up the request from #57 and the work in #59 and plugwise-beta#148, which were closed in 2021 without being merged.
Two existing bugs are fixed along the way.
The diff looks large, but most of it is test data: 57 files in
fixtures/andtests/data/hold about 16,800 of the 17,400 added lines. The code changes are about 650 lines inplugwise/andtests/*.py.Changes
_presets()read every preset rule on the gateway and the last one won, so every zone showed the same preset setpoints. It now reads the rule attached to the zone, and falls back to the old behaviour when a zone has no single rule of its own.home_preset_temperature,asleep_preset_temperature,away_preset_temperature,vacation_preset_temperatureandno_frost_preset_temperature, each an actuator with bounds 4-30 and resolution 0.5.set_number()writes them throughset_preset_temperature().schedules: per rule id the name, the active flag, the zones it is attached to, and its time slots ({"start": "mo 07:15", "end": "mo 16:30", "preset": "home"}). Start and end keep the gateway's own notation.set_schedule()changes a schedule's slots and, optionally, its name.create_schedule()anddelete_schedule()add and remove schedules.set_schedule_state()only attached the zone. On my Adam a schedule does not run unless its rule is active, so choosing an inactive schedule did nothing, while the zone was still reported as following it. Switching on now also sends<active>true</active>. This includes a schedule that is already attached but inactive.]]>. Preset writes keep every attribute and escape the values. Legacy gateways raisePlugwiseErrorfor schedule writes.Gateway behaviour
Measured on my Adam, firmware 3.12.6, with test rules attached to no zone or to a zone at 5-6 °C (below room temperature):
/core/rules;id=…that carries<directives>replaces the whole directive set, for preset rules and schedules alike. A PUT without<directives>keeps them. Both writers therefore send the complete set.POST /core/rulescreates a schedule, inactive and attached to no zone.DELETE /core/rules;id=…removes one.Tests
tests/data/*/*.jsonandfixtures/*/data.jsonare updated for the new keys and the per-zone preset order. The expected schedules were computed from each fixture's XML by a separate parser, and both parsers agree on all 38 setups inuserdata/.Open questions
Running in Home Assistant
A test Home Assistant (2026.10.2) runs my plugwise-beta branch on top of this library branch, connected to my Adam. Each zone shows the five preset temperature numbers in its Configuration section, and each schedule on my gateway shows up as a read-only calendar. The plugwise-beta branch adds actions to get, set, create and delete schedules, and I have run them against my gateway.
Once these changes are in a release, I will open the plugwise-beta PR with the number entities, the calendars and the actions.
Summary by CodeRabbit