fix: keep Nuos operation mode cache in sync with mode getter#181
Open
dpmworld wants to merge 1 commit into
Open
fix: keep Nuos operation mode cache in sync with mode getter#181dpmworld wants to merge 1 commit into
dpmworld wants to merge 1 commit into
Conversation
`AristonNuosSplitDevice.set_water_heater_operation_mode` (and its async counterpart) wrote the new operative mode into `NuosSplitProperties.MODE` (the generic Velis `mode` field), but `water_heater_mode_value` reads from `NuosSplitProperties.OP_MODE` (the Nuos-specific `opMode` field). The Nuos cloud payload exposes both fields with distinct semantics: `mode` is the plant mode shared with other Velis devices, while `opMode` is the Nuos operative mode (GREEN / COMFORT / FAST / IMEMORY). The `set_nuos_mode` API call posts to `/operativeMode`, so the server only updates `opMode`. Mirroring `mode` in the local cache therefore had two unwanted effects: * `water_heater_mode_value` continued to return the stale `opMode` value until the next `update_state()` round-trip. * The unrelated `mode` field was clobbered with an `opMode` value, briefly corrupting any caller reading the plant mode from the cache before the next refresh. This is the same class of bug that fustom#180 fixes for the temperature setter; the operation mode setter just slipped through the same review.
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.
AristonNuosSplitDevice.set_water_heater_operation_mode(and its async counterpart) wrote the new operative mode intoNuosSplitProperties.MODE(the generic Velismodefield), butwater_heater_mode_valuereads fromNuosSplitProperties.OP_MODE(the Nuos-specificopModefield).The Nuos cloud payload exposes both fields with distinct semantics:
modeis the plant mode shared with other Velis devices, whileopModeis the Nuos operative mode (GREEN / COMFORT / FAST / IMEMORY). Theset_nuos_modeAPI call posts to/operativeMode, so the server only updatesopMode. Mirroringmodein the local cache therefore had two unwanted effects:water_heater_mode_valuecontinued to return the staleopModevalue until the nextupdate_state()round-trip.modefield was clobbered with anopModevalue, briefly corrupting any caller reading the plant mode from the cache before the next refresh.This is the same class of bug that #180 fixes for the temperature setter; the operation mode setter just slipped through the same review.