Change subscription floor to 1 second to prevent flooding #891
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.
Change subscription floor to 1 second (instead of 0) to prevent flooding during transitions.
This basically means that sending an attribute update is debounced with 1 second.
A state update (e.g. motion detected, door sensor) still comes as fast as possible but if you e.g. toggle it super fast you will only get an update every second which is good enough for all normal usecases.
Tested it with doorsensor and updates are still instant (just debounced with 1 seconds if you open/close very fast in succession). Also tested a bit with a generic switch (remote button press) and the 1 second debounce still felt natural (you just get a burst of events at once) but if this may ever lead to complaints/issues, we could consider splitting up the subscription in 2 parts, one for regular attribute updates (where we could even go for 2 seconds maybe) and one for events (where we want a 0 seconds floor).
Without this fix (so with a 0 second floor), a device sends a burst of attribute changes every 100ms (or even higher frequency!) resulting in increased traffic and even a bit of a laggy experience such as a clunky transition on the light itself (maybe because it needs to send so many updates). same applies for e.g. switch with "onWithTimedOff" where the device sends the state of the timer at an insane interval.
For lights, this makes the transitions working smoothly, at least for Thread based lights.
Does not fix transition issues on ESP32 because that is a firmware issue.