Add push notification support for WG4-series thermostats - #691
Open
adamjernst wants to merge 1 commit into
Open
Conversation
Refs robbinjanssen#226. The WG4 cloud delivers change notifications by long-polling GET /api/notification?sessionid=...: the request blocks until a thermostat changes (Action 2, full thermostat payload) or the server gives up after about a minute (Action 0, null thermostat). Notifications are queued per session and only once that session has fetched the thermostat list. - Add supports_notifications and get_notifications() to the OJMicrolineAPI protocol. WG4API implements it with the long-poll and re-subscribes (re-fetching every thermostat) whenever the session id changes, e.g. after the periodic re-login. WD5 and WG5 report unsupported and raise OJMicrolineError. - Add OJMicroline.subscribe(listener) -> unsubscribe. The first subscriber starts a background task that logs in, waits for notifications and dispatches them to every listener (sync or async), retrying failures with exponential backoff. The task stops when the last subscriber leaves or the client is closed. - Allow a per-request timeout override so the long-poll can outlast the default 30 second request timeout. - Document the feature in the README and cover it with tests. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Eer1ZnSZ8sz5oh8pq3AQT2
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #691 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 10 10
Lines 522 608 +86
Branches 67 79 +12
=========================================
+ Hits 522 608 +86 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
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.
Refs #226 (partially: WG4 only).
What
Adds push updates for WG4-series thermostats so consumers such as Home Assistant can react to changes within seconds instead of polling.
OJMicroline.subscribe(listener) -> unsubscribe. The first subscriber starts a background task that waits for notifications and dispatches each updatedThermostatto every listener (plain or coroutine functions). Failures are retried with exponential backoff (1 s up to 5 min); a failing listener is logged and does not affect the others. The task stops when the last subscriber leaves or the client is closed.OJMicrolineAPIgainssupports_notifications: boolandasync get_notifications() -> list[Thermostat], keeping the core client simple and the transport details in the per-model classes as discussed in Add support for notification streams #226.WG4APIimplements it. WD5 and WG5 report unsupported and raiseOJMicrolineError(WD5 has a SignalR hub, see the POC in Add support for notification streams #226, and can be added in a follow-up)._requestaccepts a per-request timeout so the long-poll can outlast the default 30 s.How the WG4 cloud does it
GET /api/notification?sessionid=...on mythermostat.info is a long-poll: it blocks until a thermostat changes and returns{"SequenceNr": n, "Action": 2, "Thermostat": {...full api/thermostat payload...}}, or after roughly a minute returnsAction 0with a null thermostat. Notifications are queued per session, and only once that session has calledapi/thermostats, soWG4API.get_notifications()re-fetches (and returns) every thermostat whenever the session id changes, which also covers the periodic re-login.Testing
Verified live against two UWG4 thermostats: both delivered on subscribe, a setpoint change made through the API arrived in about 2 s, periodic temperature reports arrive every 25-60 s per thermostat, a forced mid-stream re-login re-subscribed and re-delivered both thermostats, and unsubscribing cleared the task.