5

Profile Debounce as an option

I would like to see an option under "Profile Properties" to add a debounce time out similar to the "Cooldown Time" option.  The Debounce time would prevent a profile from changing state for a fixed period of time after the profile asserts or de-asserts.

For example, let's say we have a profile with a WiFi Connected context and a debounce timer set to 10 seconds.  Assume the profile has been inactive for more than 10 seconds and then becomes active.  The pofile's enter task should start as soon as the profile becomes active.  Now assume that the profile becomes inactive after 4 seconds and active again in another 4 seconds.  The exit task should not fire and the enter task should not fire again as the total time (8 seconds) is less than 10 seconds.  However, at any time after 10 seconds, if the profile becomes inactive, then the exit task should fire and then no enter or exit tasks fire for another 10 seconds.

Follow

4 replies

Votes Newest Oldest
S

I think this request is very similar to this one.

Comment

+1 to this request, to Robert's logic, and adding my request that the de-bounce be able to handle long bounces. In my use case I'm allowing 5 min bounces.

As a stop-gap solution I use an exit task with a wait for 5 min then use if %PACTIVE to see if the profile has since reactivated, in which case I do nothing. It's not as elegant as de-bounce but works.

Comment

Thanks for the input!

Comment

Thanks for the request.

In your opinion should the debounce timer always restart on a change?

To clarify, in your Wifi Connected profile:

  • Debounce set to 10 seconds
  • wifi is connected, profiles becomes active
  • wifi disconnected after 8 seconds, profile remains active
  • wifi connected after 3 seconds, profile remains active
  • wifi disconnected after 2 seconds, profile should remain active or switch to inactive?
  • wifi connected after 5 seconds, profile should be active

What do you think?

Comment
PS

That's a hard question to answer as it would depend on the specifics of the profile.  Perhaps this could be an option of the debounce function such that the user could choose to have the timer restart after every change or only after a change after the timer has timed out.

RR

My thought was that the profile would simply ignore all state changes during those 10 seconds. After the 10 second interval, normal operation would resume. So, to use your example:

* Debounce set to 10 seconds

* wifi is connected, profile becomes active

* wifi disconnected after 8 seconds, state change ignored

* after two more seconds elapse, If wifi still disconnected, assume it is not a bounce and run exit task.

* If wifi reconnects any time within the 10 second interval the timer is reset and the profile remains active

Reply