Fix IKEA Starkvind attribute reports #125
Merged
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 change
When the
fan_mode
attribute was updated, theattribute_updated
method was called again. Repeat this.Eventually, we would reach the maximum recursion depth and error out.
Now, we're completely removing the overridden
attribute_updated
method in the IKEA manufacturer-specific cluster.Instead, the super method is now called which does what we want (emit an event), but for all attributes. This is needed, as the
child_lock
and other config attributes on that cluster would not cause the config switch entities to update if changed from the device.The change is tested and seems to be working as expected now.
Additional information
On a side note, the
attribute_updated
stuff in the other cluster handlers also needs be improved. There's some duplicate code that can be avoided and it's one of the last places where the old_value_attribute
stuff is still used.It's also a bit confusing if only one attribute change actually emits an "attribute updated" event on a cluster. Maybe we should always emit the events and just check for the attribute in the places where we're subscribing? (the config switches do this already) It shouldn't cause any performance issues really..
Also, it seems like we do have a unit test for this in
test_fan.py
, but it didn't catch the issue, as we're (1) not testing getting afan_mode
attribute report from the device and/or (2) because whenfan_mode
is changed from ZHA, we're only checking if the attribute was written correctly. Not if the entity was also updated correctly.Doing either of those things would have caught the issue.
Further fixes and changes will come with #87 in the future.