Open dale3h opened 4 years ago
I’m not sure why something would be sending twice, but I like the idea of preventing it. I wonder if this will be easy to implement after adding the birth/will support I just logged. Once that is done, we’d be storing the last state value Which would make for an easy comparison before sending again.
Did you have an idea here on how you wanted to implement this?
There have been quite a few things in this project that have sent me for a puzzled brain, but I refuse to give up on it. Like I said before, it is far more stable than the HA custom integration.
Apparently I am the "rare case" for every scenario that we've found yet, but that is a good thing because I am willing to speaking up about my experience with the software.
I honestly have no clue where to begin to implement this. Might it be possible to keep a global variable of event payloads and skip publishing if the timestamp matches? I just don't know enough about the underlying asynchronous nature of the script to understand the best place to address this issue.
Here's what I propose on this one. Assuming you are able to pick up another bridge soon, lets see if this repeats with a second bridge. It's possible this is a side effect of whatever is causing the bridge/USB disconnect issues.
If it does stick around, lets start by adding a SENSOR_STATES dict (like what I'm talking about in the HA birth/will issue), and compare the major values in the event to that, in particular the state and timestamp values. We could just start with that living in memory and determine if we want to store it later, but would give us a relatively quick way to test for the duplicates without having to settle on a storage option for now.
Sound good?
Is your feature request related to a problem? Please describe.
Yes. Sometimes a state event is sent twice.
Describe the solution you'd like
Some implementation of debouncing to prevent identical state events from being handled twice.
Additional context
Here are some (custom) debug logs that show multiple state events being handled simultaneously: