Build 14: rate-limit/SSE reconnect fixes + device status no-op guards#2
Merged
Conversation
Devices without an OperationState in /status (e.g. FridgeFreezer) never created that variable, so needsInitialization() returned true on every IM_CHANGESTATUS. Each parent status flap re-ran a full InitializeDevice(), burning through the rate limit within seconds (observed: 3 full cycles before the 429). Replace the fragile "OperationState variable exists" check with a dedicated Initialized attribute that is only set true after a fully successful initialization. The signature is written at the same point, so a partial failure (offline / rate limit mid-way) leaves Initialized=false and a retry happens on the next CONNECTED event - not on every status flap. Also suppress the echo for rate-limit responses (key 429) in RequestDataFromParent so blocked requests no longer spam the kernel log as "Fehler bei Instanz ... IM_CHANGESTATUS". Add a FridgeFreezer fixture and regression test (with an API request counter in the test API) that fails on the old code (5 calls) and passes now (0). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The keep-alive watchdog (60s timer) reconnected the event stream whenever no KEEP-ALIVE arrived. When /events itself returns 429 (daily limit), no keep-alive ever arrives, so the watchdog reconnected every ~60s - ~1440 calls/day, which on its own exceeds the 1000/day limit and keeps the account permanently blocked. This was independent of the device re-init loop and is why the problem persisted. - Guard RegisterServerEvents() on isRateLimitActive(): defer the reconnect to the end of the block window instead of retrying immediately. This covers all reconnect paths (Reconnect timer, keep-alive check, FM_CONNECT). - CheckServerEvents() returns early while rate limited (the missing keep-alive is expected then). - ResetRateLimit() resumes the stream exactly once when the window ends. - Feed a 429 carried by the SSE stream into the shared rate-limit machinery (ReceiveData -> applyRateLimitFromStream), so the limit is honored even when no REST call ran. Extracted applyRateLimit() so REST and SSE share one code path. Add HomeConnectCloudTest covering: 429-from-stream activates the limit, reconnect is deferred while limited, keep-alive check skips while limited. These fail on the old code (reconnect despite limit) and pass now. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Extends Thomas' fix (#1) so the Home Connect Device instance status is only written when it actually changes. Before, refreshDeviceState() and the FM_DISCONNECT handler called SetStatus() unconditionally on every refresh (parent status change, CONNECT, reconnect, ApplyChanges), which re-triggered status monitoring (EventControl scripts) even when nothing changed. Route the IS_ACTIVE and both IS_INACTIVE setters through a new setInstanceStatus() helper that compares the current status first. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
# Conflicts: # library.json
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
1 participant
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.
Fasst zwei Korrektur-Stränge in einem Release (Build 14) zusammen.
1. Device-Status nur bei Änderung setzen
Baut auf Thomas' (ThomasM65) PR #1 auf und vervollständigt ihn: Seit „Fix/device status refresh and setting constraints (symcon#10)" rief das Home-Connect-Device-Modul
SetStatus()bei jedem Refresh (Parent-Statuswechsel, CONNECT, Reconnect, ApplyChanges) bedingungslos auf. Das triggerte Status-Monitoring (EventControl-Skripte) auch ohne tatsächliche Änderung und erzeugte viele unnötige Log-/Trigger-Einträge.Alle drei Status-Setzer (
IS_ACTIVEinrefreshDeviceState()sowie beideIS_INACTIVE-Aufrufe inrefreshDeviceState()und imFM_DISCONNECT-Handler) laufen jetzt über eine neue HilfsmethodesetInstanceStatus(), die den aktuellen Status zuerst vergleicht und nur bei echter Änderung schreibt — analog zum bereits im Cloud-Modul vorhandenen Guard.2. Rate-Limit-/SSE-Reconnect-Fixes
/eventsweiter anfragt, während ein Rate-Limit aktiv ist.OperationStateaufbraucht.HomeConnectCloudTest,HomeConnectFridgeFreezerTest.Build
library.json: build 11 → 14, date → 1782691200 (2026-06-29).Tests
PHPUnit: 30 Tests, 519 Assertions – grün.