Is your feature request related to a problem? Please describe
There are some (Tuya) devices which spam the network with status updates multiple times per second. It's not really possible to easily slow down their processing, because setting a debounce value above a second will mean no messages are sent. Throttle isn't ideal either, as it would miss potentially important changes for some devices (e.g. a presence sensor in my case) - and it's not possible to use both in conjunction.
Describe the solution you'd like
When seeing the debounce option, I had assumed that it would work such that it would wait a maximum amount of time for additional updates before sending out the combined message (similar to Nagle's algorithm), rather than waiting for silence. If this was the behaviour then it could solve the above problem as it would allow limiting the frequency of messages.
However, these two approaches are compatible so it would be possible to add a total limit to the debounce time in addition to the 'silence time'.
Describe alternatives you've considered
I have looked at throttle, as well as ignoring certain debounce attributes. In my case I'd like fast responses for attributes which rarely change (such as presence), and slow for others like lux. The current options don't appear to support this.
Additional context
If this is desirable, I'm happy to look at opening a PR myself to implement it.
Is your feature request related to a problem? Please describe
There are some (Tuya) devices which spam the network with status updates multiple times per second. It's not really possible to easily slow down their processing, because setting a debounce value above a second will mean no messages are sent. Throttle isn't ideal either, as it would miss potentially important changes for some devices (e.g. a presence sensor in my case) - and it's not possible to use both in conjunction.
Describe the solution you'd like
When seeing the debounce option, I had assumed that it would work such that it would wait a maximum amount of time for additional updates before sending out the combined message (similar to Nagle's algorithm), rather than waiting for silence. If this was the behaviour then it could solve the above problem as it would allow limiting the frequency of messages.
However, these two approaches are compatible so it would be possible to add a total limit to the debounce time in addition to the 'silence time'.
Describe alternatives you've considered
I have looked at throttle, as well as ignoring certain debounce attributes. In my case I'd like fast responses for attributes which rarely change (such as presence), and slow for others like lux. The current options don't appear to support this.
Additional context
If this is desirable, I'm happy to look at opening a PR myself to implement it.