Adding a debounce function for the TOF sensor

[rvanderwouw]

Hi,

Thanks for making your code public. I used it to create my own stairlight, but the ToF sensors were a little too sensitive in my setup, it sometimes triggered a number of breakbeam and breakbeam-clear events directly after each other when passing the sensor. So I decided to incorporate a small 'debouncing' function in the lambda-function. In this case I have an update interval of 0.1 second and a debouncing threshold of 10 (10 * 0.1s = 1 s), meaning that after the beam has been broken every new reading within 1 second after that will simply be ignored. This kept my automation from 'bouncing' around.
I hope you may see the benefit of this and will include it in your code.

//Rob

[Resinchem]

I've actually made recommendations to people to do this in the actual Home Assistant automation... using a 'for' clause to the triggers:

      platform: state
      entity_id: binary_sensor.stair_motion_top_2
      to: "on"
      for:
        milliseconds: 250   #adjust delay period here to meet your needs

By handling the delay in the automation, it allows someone to easily adjust the timing, even via the UI editor, for their particular situation (some people will traverse the stairs much faster than others). You method would definitely work as well, but I think many Home Assistant users would have difficulty determining where/how to make the adjustment (and have no idea what a lambda is or what it does)... and then reuploading the ESPHome code. Where adding the 'for' clause can be done via YAML or the UI automation editor and just requires a reload of automations.

You method is more of a true "debounce" and I think a more elegant solution... but I do think it is a little more difficult to tweak and adjust for the "average" Home Assistant user. I do need to go back to my YAML code here and add the for clause to the automations.. along with some documentation. I'll leave the PR open for now to see if anyone else has additional thoughts.

[rvanderwouw]

As always there is more than one way to achieve something! However, I think that the "for" clause in the trigger is doing something else. It requires that the state of the binary sensor stays in the "on" state for 250 milliseconds, otherwise the trigger will not fire an event,. This means in essence that the beam must stay in the 'beam broken'-state for 250 milliseconds. If you go very quickly through the ToF-sensor beam, you might end up missing an event with this method. The debouncing counter in the ESPHome lamdba code essentially says: "okay, I have seen that the beam was broken and I will ignore any events in the next 10 update intervals". This will cause the binary sensor to be in that state for at least 10*interval milliseconds, but it will also prevent the "beam unbroken" event from triggering.
So I agree that fiddling with a lambda function is for many users a little bit too much, but there is some additional value in this approach as well. The debouncing option can also cater for the scenario where two or more people are walking up/down the stairs, each triggering a sensor event. If you prolong the debouncing timer to say 5 seconds, the effect that the lights will turn of when the second person breaks the beam can be mitigated as well. Still a lot to think about!
In essence I am currently very happy with this setup, but it is still not good enough to cater for more scenario's. Think for instance if someone starts to walk the stairs and then decides to go back. The current 'state machine' here is not well equipped for these situations.