Reject a time based screensaver without both times - #1171
Merged
Merged
Conversation
Setting the screensaver time did not work. The device wants both times on every time based write, even one that only toggles the mode, and it fails in three different ways without them: start_time alone 200, and quietly ignored end_time alone 400 Bad end time params neither 400 Bad end time params The first is the bad one. Changing only the start time, which is the obvious way to use this, reported success and returned a Display still holding the old times. display() now raises ValueError for the time based mode unless both times are given, so the mismatch surfaces at the call instead of looking like it worked. The other modes take no times and are unaffected. Verified against a LaMetric TIME (sa8, OS 3.2.7). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
frenck
approved these changes
Sep 11, 2026
There was a problem hiding this comment.
🟢 Approval recommended
The focused validation matches documented device behavior and is adequately tested.
Pull request overview
Adds early validation for device-required time-based screensaver parameters.
Changes:
- Requires both start and end times for time-based writes.
- Tests invalid combinations and unaffected modes.
File summaries
| File | Description |
|---|---|
src/demetriek/device.py |
Validates time-based screensaver writes. |
tests/test_display.py |
Covers validation and other modes. |
Review details
- Files reviewed: 2/2 changed files
- Comments generated: 0
- Review effort level: Balanced
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Proposed Changes
Setting the screensaver time did not work. The device wants both
start_timeandend_timeon everytime_basedwrite, even one that only togglesenabled, and it fails three different ways without them:mode_paramsstart_timealone200, and quietly ignoredend_timealone400 Bad end time paramsenabledalone, no times400 Bad end time paramsThe first row is the damaging one, and the likely cause of the report. Changing only the start time — the obvious way to use this — reported success, and the returned
Displaystill held the old times, so nothing indicated the write had been dropped:display()now raisesValueErrorfor the time based mode unless both times are given, so the mismatch surfaces at the call rather than looking like it worked. The other modes take no times and are unaffected, which a test covers.Requiring both times even to disable the mode is the device's rule, not a choice made here. Callers that only want to toggle it can pass the times they read back from
display(), or switch modes instead, since enabling one mode disables the other.Verified against a LaMetric TIME (model
sa8, OS 3.2.7): all three shapes above now raise before any request is sent, and a write with both times applies and reads back correctly.Follow-up worth considering
The
400cases surfaced asLaMetricError: Error occurred while connecting to the LaMetric device at <host>, which is actively misleading, since nothing was wrong with the connection._request()discards the response body onClientResponseError, so the device's ownBad end time paramsnever reaches the caller. Including it would have made this far easier to diagnose, but it changes exception messages across every endpoint, so it belongs in its own change.Related Issues
None.
🤖 Generated with Claude Code