Suggestion for implementing 'setLongReleasedDelay'

[georgevbsantiago]

Hello, @bxparks

Thank you so much for this GREAT library!

I started using the Acebutton library in my projects and I'm really enjoying it.

I used the EasyButton library in my projects.
With EasyButton it was possible to use the function to identify how long a button was released [ex: button.releasedFor(releasedForTime) ]; .
However, I haven't found a way to do this with Acebutton.
See here: https://easybtn.earias.me/docs/released-for-api/

This function is especially important when we want to identify the state of a water float . The problem is that water waves/ripples can change the float state from HIGHT to LOW quickly (see image below).

I'm trying the following approach:

ButtonConfig* config_buoy = buoy.getButtonConfig();
config_buoy ->setEventHandler(handleEvent_boia_superior);
config_buoy ->setDebounceDelay(50);
config_buoy ->setFeature(ButtonConfig::kFeatureLongPress);
config_buoy ->setLongPressDelay(5000);
config_buoy ->setFeature(ButtonConfig::kFeatureSuppressAfterLongPress);

The problem is that kEventLongReleased is quickly triggered when water waves/ripples change the float state from HIGHT to LOW.

Therefore, it would be important to assign a delay to kEventLongReleased, something like a setLongReleasedDelay method:

ButtonConfig* config_buoy = buoy.getButtonConfig();
config_buoy ->setEventHandler(handleEvent_boia_superior);
config_buoy ->setDebounceDelay(50);
config_buoy ->setFeature(ButtonConfig::kFeatureLongPress);
config_buoy ->setLongPressDelay(5000);
config_buoy ->setFeature(ButtonConfig::kFeatureSuppressAfterLongPress);
config_buoy ->setLongReleasedDelay(10000);

With setLongReleasedDelay(10000); the kEventLongReleased event would not be triggered on the ripples of the water, but only when it stabilizes for a period of 10 seconds (in the example above).

Would this implementation in Acebutton be viable? This was the only EasyButton functionality that I didn't find in Acebutton.

[bxparks]

I've been mulling over this for a few days, and I think I understand what you are trying to do. The problem is that the current kEventLongReleased is not intended to mean to what you want it to mean.

The current kEventLongReleased event was a solution to a very specific problem, as described in Distinguishing Pressed and LongPressed: When the kEventReleased is suppressed to allow the differentiation between Pressed and LongPressed, we lose the kEventReleased from the LongPressed, so the kEventLongReleased was added to compensate.

Your version of kEventLongReleased is different. It is the symmetric equivalent of the kEventLongPressed, triggered when a button is released for a long duration. I never considered this to be an event, because by default, the buttons are considered to be in the Released state, and it did not seem that an event should be triggered without a specific human action.

If we were to implement your version of kEventLongReleased, then by symmetry, it would imply that we should implement a kEventRepeatReleased which triggers every 200 milliseconds in the Released state, in the same way that kEventRepeatPressed is triggered. I'm not sure that makes sense.

So I have a counter-suggestion: You are essentially using the LongPressed event to perform debouncing of your water level switch at a much larger timescale than the usual 20-50 milliseconds. You want to do debouncing at the level of 5-10 seconds. So instead of using LongPressed, is it possible to achieve your goals by using the normal kEventPressed and kEventReleased, but increase your setDebounceDelay(5000) instead?

[bxparks]

Note to my future self: If I were to implement this version of kEventLongReleased, then I would want to rename the current kEventLongReleased to something like kEventDelayedReleased, because these are 2 different types of events. But this would break backwards compatibility. Finding an alternate name for this new event, or maybe pair of events, seems difficult because kEventLongReleased is actually the best a good name for this new event. The best I can do off the top of my head is: kEventLongDefault and kEventRepeatDefault

[bxparks]

(Moved to Discussion because this is a feature request)

[georgevbsantiago]

Hello, @bxparks

I tried to use long debouncing (5 seconds), but the result was not good, because debouncing has a specific purpose: Filtering noise and state change (on or off) of button or switch contacts.
Unwanted behaviors occurred with this approach.
See the images below:

1. When I use kEventPressed and kEventReleased with a 60 second debouncing (just an illustrative example). In the image, you can see that the two initial events (1 - kEventPressed and 2 - kEventReleased) are unwanted triggers. The third activation (3 - kEventPressed) occurs, but the behavior is not adequate, since the objective is that it was something similar to the behavior of kEventLongPressed.
   

2. In the second example, when using kEventLongPressed and kEventLongReleased (if it were possible to assign a delay, as in my example above setLongReleasedDelay(10000), or a similar approach), the expected behavior is correct:
   

One detail is that this is not a typical behavior of Humans, but of a water level float. However, it would be very good if Acebutton addressed the behavior of buttons and switches in general, whether they are used with human behavior or triggered by elements of nature (water, wind...), such as a water level float.

[bxparks]

@georgevbsantiago : Thanks for those diagrams (they are very well done) and they explain the problem that you want to solve.

The first limitation that you are hitting is that AceButton was designed to operate on time scales of roughly 10-1000 milliseconds. So all internal timestamps are stored as a 16-bit integer typeuint16_t in milliseconds, so the theoretical maximum delay of various events is 65535 milliseconds, i.e ~65 seconds. You are trying to use it on a switch that operates on a time scale on the order of several minutes, and AceButton cannot do that.

(The primary reason that AceButton uses 16-bit integers is to save memory. Using 16-bit internal variables saves at least 8 bytes per button, with the expectation that some people may use 10-20 buttons, which saves 80-160 bytes of RAM, which makes a difference on an AVR processor with only 2kB of RAM. It also saves flash memory since most arithmetic operations can now be done using 16-bit integers, which is faster and takes fewer machine instructions on 8-bit AVR processors.)

Even if you were to update AceButton to use 32-bit integers, i can see 2 different paths to solve to your problem, depending on the type of noise that your water introduces into the switch.

• Case 1: If you know that your water level switch stabilizes in exactly N minutes (for example, 3 minutes in your diagram), you should be able to use the algorithm implemented by AceButton after setting setDebounceDelay(3 minutes). The diagrams that you posted are exactly like the oscillations of a push button over a time scale of ~30 milliseconds instead of ~3 minutes.

• Case 2: On the other hand, maybe your water level meter requires a variable amount of time to stabilize, let's say anywhere from 3-7 minutes. Maybe you need to filter out the high frequency oscillations of your switch, on the order of < 1-5 seconds. Then after the last high frequency oscillation, you want to wait an extra 20-30 seconds before determining that the water level switch has stabilized enough to register a HIGH or LOW level.

  In this case, I can see why you would want to use kEventPressed and kEventReleased to filter out the high frequency noise, then overload the kEvenLongPressed (and the missing kEventLongReleased/keventLongDefault) to detect the low-frequency change in state from HIGH to LOW, or vise versa.

  But even in this case, if you were able to use a very high debouncing time, say 10 minutes, the usual kEventPressed and kEventReleased events would detect your final states of the water level switch properly.

So let's see where this all means for you:

1. I don't think I want to change AceButton to use 32-bit integers. It was never designed for switches that operate on such a long time scale, and I don't want to impose that overhead on most people who don't need this feature. You are permitted and encouraged to fork the code for AceButton to make this happen for your application.

2. I am quite reluctant to add your kEventLongDefault/kEventLongReleased, because it would require some non-trivial amount of time to figure out how it interacts or interferes with the existing features and events. In particular, I think it would have impact on the features which allow suppression of the Released events (in particular, kFeatureSuppressAfterLongPress, kFeatureSuppressRepeatPress).

   Adding a new feature is more than just writing the code for it. It requires writing new unit tests to test all the edge cases, writing new documentation, and maintaining this new feature into the future. I don't think I want to spend that much time on a feature that I don't see myself using. I have other priorities and interests.

3. Finally, you may want to consider writing your own button/switch library to handle your requirements. The time scales involved in your application, and the type of noise filtering that you need to perform, are sufficiently different than the usual push button assumed by AceButton. The advantages writing your own library is that you can strip out all the unnecessary features of AceButton that you don't use (e.g. Click, DoubleClick, and all the flexibilty of AceButton such as its support of Resistor Ladder Buttons, and Binary Encoded Buttons).

So in summary, thanks for posing an interesting use-case for AceButton, but I think it is out of scope for how I intended the library to be used. And I don't want to take on the additional burden of supporting your use case. If you decide to fork my library, and you have trouble understanding parts of it, I can try to help if you have questions.

[georgevbsantiago]

Hello, @bxparks

Thank you very much for your reply and attention.

Just a few notes for the future:
Maybe I expressed myself badly and the drawing didn't help as much as I would like.

1. We set kEvenLongPressed to 10 seconds.
   Our code is like this:

ButtonConfig* config_buoy = buoy.getButtonConfig();
config_buoy ->setEventHandler(handleEvent_boia_superior);
config_buoy ->setDebounceDelay(50);
config_buoy ->setFeature(ButtonConfig::kFeatureLongPress);
config_buoy ->setLongPressDelay(10000);
config_buoy ->setFeature(ButtonConfig::kFeatureSuppressAfterLongPress);

I put the drawing with 60 seconds just to illustrate, but I think I ended up causing confusion.

2. Our intention was to discuss the viability of the kEventLongReleased event having a configuration similar to setLongPressDelay(10000);, something like setLongReleasedDelay(10000); , which would have a similar approach to the function button.releasedFor(releasedForTime ) from the Easybutton library.
   See here: https://easybtn.earias.me/docs/released-for-api/

In other words, we would like the kEventLongReleased event to be activated when the button or switch stays LOW continuously for 10 seconds.

In this logic, any HIGHT event on the MCU pin would reset the count, just like kEvenLongPressed behaves. Finally, kEvenLongPressed allows identifying a button that is continuously pressed for 10 seconds (without LOW during the 10 seconds). On the other hand, it would be very good if Acebutton had an event to identify if a button has been continuously released for 10 seconds.

Sorry if we caused any confusion. Our idea was that the drawing could help in understanding the problem, but it ended up generating a bit of confusion.

Let's try to clarify with this table, establishing a comparison between the Acebutton and Easybutton libraries:

Comparative table:

EasyButton	Acebutton
button.pressedFor(pressedForTime); (link)	setFeature(ButtonConfig::kFeatureLongPress); + setLongPressDelay(10000)
button.releasedFor(releasedForTime); (link)	No method or similar functionality.

In our case, it would help with the oscillations caused by the water waves that change the state of the water float from Hight to Low with the waves. kEvenLongPressed works perfectly for us. We just don't have a kEventLongReleased that fires after 10 continuous seconds of the same state, like kEvenLongPressed.

[bxparks]

If your time scales are all <~ 65 seconds, then you don't need to fork and replace all the uint16_t with uint32_t. That's the good news.

I do understand that you want the mirror image version of kEventLongPressed for the Released state. The problem is that the library was never designed for this kind of event, and without thinking through all the side effects, I am not sure that your new version of kEventLongReleased will not cause unforeseen bugs.

However, there may be good news for you. I happened to think of another way of achieving what I think you want, in a way that I know won't cause unintended bugs. It requires a feature that has been required for other features, so I think I can implement this one thing and also satisfy your needs. Give me a day or two to polish it, and I can send over the code for you to test.

[georgevbsantiago]

💖💖💖💖 👏👏👏👏👏 ✨✨✨✨

[georgevbsantiago]

Therefore, the closest example of what I think is available in the Easybutton library.
[ex: button.releasedFor(releasedForTime) ]; .
See here: https://easybtn.earias.me/docs/released-for-api/

But I'm incorporating Acebutton into my code as it has many more features and settings, the exception of which would be Easybutton's releasedFor(releasedForTime) function.

Thank you very much for your attention

[georgevbsantiago]

Your version of kEventLongReleased is different. It is the symmetric equivalent of the kEventLongPressed, triggered when a button is released for a long duration. I never considered this to be an event, because by default, the buttons are considered to be in the Released state, and it did not seem that an event should be triggered without a specific human action.

This observation is perfect. The question we ask is: A water float is activated by nature (water, wind...), and not by a human.
That's why we suggest something like setLongReleasedDelay(10000);.

But we understand if it's not feasible to implement in the Acebutton library.
We are very grateful for your dedication to developing this excellent library.

Thank you very much. ❤️❤️❤️ 👏👏👏

[bxparks]

I just released v1.10.0 of this library. See the CHANGELOG.md for the changes, but the thing that is of interest to you is the new kEventHeartBeat. I added this because it unlocks some other features that's been on the back of my mind, but I realized that it can be used to create the custom events that you need: kCustomEventLongPressed, and kCustomEventLongReleased as shown in the example app here examples/HeartBeat. Please take a look. I think this provides what you need. If it doesn't, then then I probably did not understand your requirements.