No longer responding to single click

[ullix]

I have been using AceButton on an ESP32's 'Boot' button (GPIO 0) and it worked really well with Click, Doubleclick, and Longpress. But suddenly I get no longer a 'Clicked' response, but I still get Double and Long.

I was using version 1.6, and after detecting the problem, I upgraded to 1.8.3, but no change to my problem.

When pressing a button I see a kEventPressed. Pressing again after some 10+ seconds, I see another kEventPressed followed by a kEventDoubleClicked. Doing a doubleclick as fast as I can also gives a correct kEventDoubleClicked.

Longpress still coming correctly after 2 sec (programmed setLongPressDelay(2000);).

Setting 'setClickDelay()' down to 100 or up to 1000 does not make a difference.

How do I get my click back?

[bxparks]

If you are getting a kEventDoubleClicked, then it must be detecting a kEventClicked, because the DoubleClicked depends on the Clicked. So it sounds like you changed something in the configuration of ButtonConfig or your event handler.

Try stripping down your program to get rid of everything but the AceButton related code, insert some Serial.println() statements in the handleButtonEvent() and figure out what's going on.

[bxparks]

(Converted to Discussions, I don't think this is a bug with AceButton).

[ullix]

Well, it still looks buggy to me. I stripped the button code down and ran it with a barest minimum setup and loop code as a kind of clean room test. Those two files are:

// Testing the AceButton functions
void setup() {
    Serial.begin(115200);
    initButton();
}

void loop() {
    readButton();
}

/*
 * Button lib  AceButton
 */

#include <AceButton.h>

const uint8_t           ButtonPin = 0;
ace_button::AceButton   button;

class ButtonHandler: public ace_button::IEventHandler {
    public:
        void handleEvent(ace_button::AceButton *, uint8_t eventType, uint8_t buttonState) override {

            Serial.printf("%6i  classButtonHandler(): handleEvent(): eventType: %i; buttonState: %i  ",
                            millis(), eventType, buttonState);

            switch(eventType) {
                case ace_button::AceButton::kEventPressed:
                    Serial.println("  kEventPressed ");
                    break;

                case ace_button::AceButton::kEventReleased:
                    Serial.println("  kEventReleased ");
                    break;

                case ace_button::AceButton::kEventClicked:
                    Serial.println("  kEventClicked ");
                    break;

                case ace_button::AceButton::kEventDoubleClicked:
                    Serial.println("  kEventDoubleClicked ");
                    break;

                case ace_button::AceButton::kEventLongPressed:
                    Serial.println("  kEventLongPressed ");
                    break;

                case ace_button::AceButton::kEventRepeatPressed:
                    Serial.println("  kEventRepeatPressed ");
                    break;

                case ace_button::AceButton::kEventLongReleased:
                    Serial.println("  kEventLongReleased ");
                    break;

                case ace_button::AceButton::kButtonStateUnknown:
                    Serial.println("  kButtonStateUnknown ");
                    break;

                default:
                    Serial.println("  programming error ");
                    break;
            }
        }
};

ButtonHandler   handleEvent;

void initButton(){
    Serial.println("Initializing Button");

    button.init(ButtonPin, HIGH);
    Serial.printf("AceButton Version: %s\n\n", ACE_BUTTON_VERSION_STRING);

    ace_button::ButtonConfig* buttonConfig = button.getButtonConfig();
    buttonConfig->setIEventHandler(&handleEvent);
    buttonConfig->setFeature(ace_button::ButtonConfig::kFeatureClick);
    buttonConfig->setFeature(ace_button::ButtonConfig::kFeatureDoubleClick);
    buttonConfig->setFeature(ace_button::ButtonConfig::kFeatureLongPress);

    buttonConfig->setFeature(ace_button::ButtonConfig::kFeatureSuppressAll);
    //~buttonConfig->setFeature(ace_button::ButtonConfig::kFeatureSuppressClickBeforeDoubleClick);
    //~buttonConfig->setFeature(ace_button::ButtonConfig::kFeatureSuppressAfterClick);
    //~buttonConfig->setFeature(ace_button::ButtonConfig::kFeatureSuppressAfterDoubleClick);
}

void readButton(){
    button.check();
}

Then I included the button file in my large code (~1 MB bin). Thus the code is exactly the same, and I ran it the same way. The outcome is shown next:

# CLEAN Demo script #

Initializing Button
AceButton Version: 1.8.3

  2433  classButtonHandler(): handleEvent(): eventType: 0; buttonState: 0    kEventPressed # short press
  2989  classButtonHandler(): handleEvent(): eventType: 2; buttonState: 1    kEventClicked # 556 ms later

  6946  classButtonHandler(): handleEvent(): eventType: 0; buttonState: 0    kEventPressed # short press
  7505  classButtonHandler(): handleEvent(): eventType: 2; buttonState: 1    kEventClicked # 559 ms later

 14196  classButtonHandler(): handleEvent(): eventType: 0; buttonState: 0    kEventPressed # 1st short press
 14506  classButtonHandler(): handleEvent(): eventType: 0; buttonState: 0    kEventPressed # 2nd short press
 14654  classButtonHandler(): handleEvent(): eventType: 3; buttonState: 1    kEventDoubleClicked # 148 ms after 2nd

 18214  classButtonHandler(): handleEvent(): eventType: 0; buttonState: 0    kEventPressed # press and hold
 19214  classButtonHandler(): handleEvent(): eventType: 4; buttonState: 0    kEventLongPressed # 1000 ms later
 25669  classButtonHandler(): handleEvent(): eventType: 6; buttonState: 1    kEventLongReleased # >7s later

-----------------------------------------------------------------------------------------------------------------
# same code within large script #

 35314  classButtonHandler(): handleEvent(): eventType: 0; buttonState: 0    kEventPressed # short press
 51877  classButtonHandler(): handleEvent(): eventType: 2; buttonState: 1    kEventClicked # 16563 ms later

 57506  classButtonHandler(): handleEvent(): eventType: 0; buttonState: 0    kEventPressed # short press
 74042  classButtonHandler(): handleEvent(): eventType: 2; buttonState: 1    kEventClicked # 16536 ms later

 78241  classButtonHandler(): handleEvent(): eventType: 0; buttonState: 0    kEventPressed # 1st short press
 78558  classButtonHandler(): handleEvent(): eventType: 0; buttonState: 0    kEventPressed # 2nd short press
 78726  classButtonHandler(): handleEvent(): eventType: 3; buttonState: 1    kEventDoubleClicked # 168 ms after 2nd

 83094  classButtonHandler(): handleEvent(): eventType: 0; buttonState: 0    kEventPressed # press and hold
 84094  classButtonHandler(): handleEvent(): eventType: 4; buttonState: 0    kEventLongPressed # 1000 ms later
 91192  classButtonHandler(): handleEvent(): eventType: 6; buttonState: 1    kEventLongReleased # >7 sec later
107571  classButtonHandler(): handleEvent(): eventType: 2; buttonState: 1    kEventClicked # ???? no further presses ???
                                                                                           # 16379 ms after release

In the clean case the AceButton behaves as it should - a short press and some 560 ms later the click is detected. Likewise Double and Long behave as they should.

However, the very same code gives quite different answers when incorporated into my large project. The single click's recognition takes very close to 16 sec longer! The double-click is normal, and so is the Long press. However, a spurious Click is detected - I had not touched the button - after again some exactly 16 sec later.

You'll note in the code that I have removed the namespace definition which you suggest in your reference code, fearing some overwriting from elsewhere in the source. But this does not seem to be the case.

I have also played with feature setting and removing, but no combination brought the proper click recognition back.

I am puzzled about the 16 sec delays - is there some last-resort-cleaning done in the code?

Somehow my large script has an influence on this button code. What can it possibly be?

[bxparks]

Hi, thanks for the sample code. I compiled and ran it on my ESP32, and initially I got... absolutely nothing. No output. Then I noticed that you don't call pinMode(ButtonPin, INPUT_PULLUP) on the pin. After I added the call to pinMode(), I began to see the Serial.println() output and it was as expected.

So my question for you is, in your larger program, are you calling pinMode() properly? Are you using an external pull resistor?

[ullix]

I am not calling pinMode() at all. And it is not necessary on an ESP32 dev board. I use the "Boot" button on the ESP32 modules, which is connected to GPIO0, and this is set to INPUT_PULLUP by default. See this pdf https://www.waveshare.com/w/upload/8/86/Esp32_chip_pin_list_en.pdf and look for GPIO0 and Note 10: after reset, the pin is set to "input enable (ie=1), internal pull-up (wpu)".

But I added the command anyway, and, as expected, nothing changed; clean room works well with and without it, and project still fails on the single click detection with and without it.

What ESP do you have? I had WROOM-32, -32D, -32E, PICO, WROVER and it had worked in the past on all of them. AceButton worked so smoothly, I didn't pay much attention :-/ and can't tell when the change occurred.

[bxparks]

Thanks for that info about the BOOT button, it's cool that it can be used as just a normal button after the bootloader has finished.

I am using 2 different ESP32 dev modules from 2 different manufacturers, though both of them are using the WROOM-32. Your results are very strange. I have used AceButton for dozens of projects, using 7-8 different microcontrollers, as listed on the README.md. I have not seen anything like the problem that you describe.

I looked through the event detection logic in AceButton.cpp and I cannot imagine a scenario where it would produce the results that you posted. Is there any chance that your button event handler is calling code that is accidentally modifying the values of AceButton or ButtonConfig, maybe through an out-of-bounds pointer access?

Here's a shot in the dark: Try printing out the values of:

• ButtonConfig::getDebounceDelay()
• ButtonConfig::getClickDelay()
• ButtonConfig::getDoubleClickDelay()
• ButtonConfig::getLongPressDelay()
• ButtonConfig::getRepeatPressDelay()
• ButtonConfig::getRepeatPressIntervalDelay()

in your eventhandler and check if anything was accidentally changed.

[bxparks]

(oops, sent too quickly, see edit above)

[ullix]

The code shown above is still what is used also in the big project, no other calls within it! Your printing request of course has now been added. I also modified some settings to easily distinguish them from defaults. This is the output in setup() after calling my InitButton():

By the way, my AceButton version is 1.8.3, which has no ButtonConfig::getRepeatPressIntervalDelay() ?

Initializing Button
AceButton Version: 1.8.3
    ButtonConfig::getDebounceDelay(): 22
    ButtonConfig::getClickDelay(): 333
    ButtonConfig::getDoubleClickDelay(): 777
    ButtonConfig::getLongPressDelay(): 2222
    ButtonConfig::getRepeatPressDelay(): 1111

Then some other actions occur, and the output becomes:

    ButtonConfig::getDebounceDelay(): 22
    ButtonConfig::getClickDelay(): 32856
    ButtonConfig::getDoubleClickDelay(): 16379
    ButtonConfig::getLongPressDelay(): 2222
    ButtonConfig::getRepeatPressDelay(): 1111

First, something has overwritten both click and double delay, but not the other. However, the delays are not what the log on button presses says (1st number is millis() output):

millis():
13040  classButtonHandler(): handleEvent(): eventType: 0; buttonState: 0    kEventPressed
29565  classButtonHandler(): handleEvent(): eventType: 2; buttonState: 1    kEventClicked
Delta: 16525

16334  classButtonHandler(): handleEvent(): eventType: 0; buttonState: 0    kEventPressed
16610  classButtonHandler(): handleEvent(): eventType: 0; buttonState: 0    kEventPressed
16654  classButtonHandler(): handleEvent(): eventType: 3; buttonState: 1    kEventDoubleClicked
delta: 320

So, the click is delayed by >16 sec but it should be delayed by >32 sec, and the double is delayed by 0.3 sec, but should be delayed by >16 sec. How does this fit together?

Which actions did the overwriting? I checked all of them, and very clearly, only WiFi activation did it. When I block WiFi, the AceButton is working as it should. And when unblocked, Wifi, and everything else except Acebutton, is working properly.

Any chance for those two libs - AceButton and WiFi - creating conflicts? As I said, all of it did work together, and I had touched neither the AceButton code nor the WiFi code for a while, but suddenly this problem turned up.

[bxparks]

Typo, it should be ButtonConfig::getRepeatPressInterval() not ButtonConfig::getRepeatPressIntervalDelay().

Yeah, something is pissing all over the memory occupied by the ButtonConfig object. I assume those values "1111", "2222", etc are numbers that you entered yourself? Because they are not the defaults. The strange behavior between Clicked and DoubleClick probably comes from the fact that ClickDelay is greater than DoubleClickDelay, which is a scenario that is not legal, and hasn't been tested. And because internally, ButtonConfig uses uint16_t to store the milliseconds, instead of uint32_t, and these large delay times may overflow the 16-bit unsigned integer. Normally, that's never a problem because those delays would never overflow a 16-bit integer.

A few more things:

1. Have you tried running this on other ESP32 boards?
2. Does your program work on an ESP8266?
3. At this point, we can't debug this any further without looking at your code. Can you strip it down to the bare minimum to reproduce the problem (i.e. with WiFi code and AceButton), upload it to GitHub and send me the link to the code?

[ullix]

How about correcting a wrong index at an array of structures in my code? :-((

Your suggestion of the printouts finally led to the discovery. Phew, that bug must have been there for at least a year. C(++) sucks; time to take a rest and look for Rust?

AceButton is now running as smoothly as ever! Sorry for the mess, and thanks for the help.

One question: since kEventLongReleased seems to be a new one, is it possible to somehow convert this to a LongLongPress (like 10sec) ? I could use an extra event.

[bxparks]

Glad you found your problem.

With regards to LongLongPress, it's software, anything is possible. But it's such an uncommon button event, I don't think it's worth adding that complexity within AceButton. You are free to fork the library if you want. But it's also probably pretty easy to detect such long-term events by layering in a small amount of code over your event handler, using the kEventPressed, kEventReleased and kEventLongReleased events, and your own timer variable.

[bxparks]

It just occurred to me you cannot use a kEventReleased or kEventLongReleased directly to detect a kLongLongPressed, because those events wouldn't trigger after 10 seconds.

But I think it is possible to use the kEventRepeatPressed, and just count the number of kEventRepeatPressed in your event handler until you get to your desired 10-second kLongLongPress, then you fire off your custom event. You'll have to remember to reset the counter when you detect a kEventReleased or kEventLongReleased.

[ullix]

Well, almost. It is awfully simple to implement, but as of now the Long fires, while waiting for the LongLong. I would have to invalidate Long, when LongLong does not happen, which makes it more complicate.

But couldn't the idea of watching kEventRepeatPressed not be used more generally, i.e. instead of looking at the timers looking at the kEventRepeatPressed counts?

[bxparks]

I see. So if Long was set to 1 s, and LongLong was 10 s, and the button was held down for 5 s, you want just the Long to fire if the button was lifted after 5 s. One problem is that Long is delayed until 5 s, which might be weird in certain applications, but acceptable in others.

Yes, I think you could modify your event handler to listen to RepeatPressed, keeping a count. Assuming it takes 50 RepeatPressed events to get to your desired LongLong (default repeat press interval is 200 ms), if you got a LongReleased before you got to 50, you fire off a Long event. If you get to 50, you fire off a LongLong event.

After that, you have the option of either clearing your counter right away, or waiting for a LongReleased to clear. If you clear right away, it will fire off another LongLong after another 50 RepeatPressed. Ha, you could even assign a separate event to the repeated LongLong and call it "RepeatLongLong".

[ullix]

Mulling over the idea of counting kEventRepeatPressed - I'll call them ticks - I am wondering whether this approach couldn't be used more easily and more flexibly, even to the point of allowing Morse code recognition? Sorry, but as former radio HAM, this isn't far fetched for me.

The dot and dash symbols of Morse code have a clear time relationship. One dot has the length of 1 time unit, one dash of 3 time units. The time delay between symbols is equally well defined: within a letter the delay is 1 time unit, between letters 3 time units, and between words 7 units. For a good Morse typist, a time unit might be 50ms.

The word ACE will then look like: (# = dot, ### = dash)

A       C             E
#.###...###.#.###.#...#.......(next word)

The length would then be 30 x 50ms = 1.5 sec.

Now let's say the ticks also come 50 ms apart. You would have to look for missing ticks. 1 tick is a dot, 2 is also a dot, 3 is a dash, 4 and perhaps even 5, 6,...(?) also become a dash. Similar for spaces, i.e. lacking ticks. To distinguish an input of just the letter A from a word like ACE, you would have to look ahead for only 3 ticks (or 4, 5 to allow for human imperfection).

Or a classic Long might be 20 ticks, a LongLong 100 ticks. But you wouldn't fire a Long after 20 ticks, you'd wait until the user lifts his finger from the button and a break in flow of ticks occurs. Up to a count of 99 it could still be considered as only a Long. It seems reasonable to assume that the user would not be surprised about nothing happening for 80 ticks, because he has still his finger on the button.

At the end, ticks are proportional to time in millisec, so counting ticks is basically the same as measuring delays. But it may be easier to count and program?

[bxparks]

Morse code encoding is interesting, but I think that should be handled by another library not AceButton. Mostly because RepeatPress only fires if the button is held down. AceButton has no ability to send "ticks" while the button is in the Released state. I would consider such a feature to be out of scope of this library, just adds too much complexity.

By the way, why are you so limited to only a single button? Are you trying to save pins? If so, perhaps you are aware that AceButton can handle 2-8 buttons on a single analog pin using a resistor ladder.