[ANNOUNCE] node-red-contrib-button-events version 2.0.0 beta

Hi folks,

When I published at the time being my node-red-contrib-button-events node, I was not 100% pleased with it. Because you needed to figure out the button click timings yourself, and I don't expect that everybody has an oscilloscope at home. Although in this community I would not be surprised if 99% would have such a device on the dining room table :rofl:

Thanks to the enthousiastic cooperation with @tsknightstorm, which provided me a boost to implement together a series of new features in version 2.0.0 of this node:

  1. Triple and quadrupple click events have been implemented.
  2. The node now supports calibration: in calibration mode the node will calculate the average timings based on your training set of clicking on the physical button.
  3. The timing properties have been moved to a config node, because most buttons in your house will have similar button click timings. Via a config node you can calibrate the node once, and reuse the timing settings (in the config node) across multiple button-event nodes.
  4. The documentation has been extended.

Time is not on my side lately, so I did not have the opportunity to test the calibration feature myself. Therefore I really hope that some people can test this new calibration feature with their physical buttons, and give us feedback (are the calculation results good, is the calibration mode easy to use, is the documentation of this feature understandable, ...).

It would be really useful if we would have a node in your palette that simplifies reading physical buttons. And imho I really think an easy to use calibration procedure is fundamental for this...

Since this version is not published on NPM yet, you can install it directly from my Github repository (from within your .node-red folder) if you have git installed:

npm install bartbutenaers/node-red-contrib-button-events

Now fingers crossed that the calibration works for most hardware setups :crossed_fingers:



A new issue was registered for this node, so I would like to publish the fix for that soon on NPM. But need first some feedback on this new release before I publish it on NPM.

As described above, it would be nice if some folks could test the new calibration mechanism from @tsknightstorm . Would like to know if the calibration feature works fine and is user friendly, because I am short of free time myself at this moment ...

Hey Bart, I installed today your contrib node for testing. I felt that it was a good idea to test it before calibrating (and before reading the docs :smile: ). I want to tell you that I am impressed how well it works, even without previous calibration. It is able to recognize the different patterns with great accuracy even using a cheap and unreliable button.

As for the calibration my first thought was that I would need to perform a training round for each different kind of pattern (click, double click, etc). I learned that my assumption was wrong and decided to read the documentation. Here is my first important remark. Step #4 in the calibration procedure is somehow confusing (at least for me).

  1. Repeat the button actions at least 10 times to get a reliable calibration result. Do this in the slowest speed you would like to detec multiclicks. Perform "thentime_click" action.

The second remark is regarding the results of the calibration. I tested the calibration with different timing for "pressing" (hold the button down) but the output of the calibration was always high for the "PressedMs" (even when I tried to make it real quick). I had to stop the testing today but I will resume tomorrow. All in all is a great node.

Note: tested with physical button (not with inject node).


Hey Andrei,
That is most kind of you. Thanks a lot!!!
I am going to mention @tsknightstorm here, because he is the brain behind the calibration.
It is better he explains how it works, and then we try to find a description that is clear to everybody.

Just tried to install the node on both m Mac m1 and a Pi and they just hang. We are talking about leaving it runnig for minutes. In one case, avter ctrl-c ing I got this log

0 info it worked if it ends with ok
1 verbose cli [
1 verbose cli   '/usr/local/bin/node',
1 verbose cli   '/usr/local/bin/npm',
1 verbose cli   'install',
1 verbose cli   'bartbutenaers/node-red-contrib-button-events'
1 verbose cli ]
2 info using npm@6.14.11
3 info using node@v14.16.0
4 verbose npm-session 59fbfd5b325b2cef
5 silly install loadCurrentTree
6 silly install readLocalPackageData
7 timing npm Completed in 37315ms
8 error cb() never called!
9 error This is an error with npm itself. Please report this error at:
10 error <https://npm.community>

other nodes install fine.

UPDATE: It finally finished

**pi@testpi**:**~/.node-red $** npm install bartbutenaers/node-red-contrib-button-events
+ node-red-contrib-button-events@2.0.0
added 2 packages from 3 contributors and audited 824 packages in 827.199s
76 packages are looking for funding
run `npm fund` for details
found 30 vulnerabilities (3 moderate, 20 high, 7 critical)
run `npm audit fix` to fix them, or `npm audit` for details
**pi@testpi**:**~/.node-red $**

but I've never had a node take over 14 minutes to install.
That was on a Pi 3.
On my Mac Mini M1 it took over 7 minutes.

For me it took only 20 seconds. That was in a fresh Raspberry Pi OS with the latest node.js and Node-RED.

added 2 packages, and audited 30 packages in 20s

I just could not find the node in the palette after installation. It took me some time to recall that I was supposed to restart node-RED to reload the palette :laughing:

Hey Paul,
I have no clue what could cause the installation to take so long. It is pure Js stuff, so no compilation or whatsever required. I assume it is somehow related to the download from Github you are doing (authentication or something related). No idea...

I’ve seen this weird behaviour a few times before when using npm pointed at a repo. No idea why. I have found that using yarn instead loads them in a fraction of the time. (But I hate trying to mix yarn and npm so always revert to npm)


Sorry for my late reply. Our newborn needs quit some attention.

I was reading my lines you mentioned now maybe 10x times and I have some difficulties to come up with a clear and short sentence. I would like to not explain it to you in a very long explanation but try it with a “short-er” note that we could add to the documentation.

The following could be added after Step #4 to help. Does it help for you? We try to find a balance between add little information to abstract the complexity inside the node and just give a step by step guide, but also give the more advanced users the details they need to understand the exact behaver.

REMARK: We would like to know how long the node needs to wait until it is clear that no more clicks are following and we can perform a clicked action. Or how long we need to wait when a button is pressed until we can perform a pressed action. If we want to detect actions very slow (slow clicking, long waiting times), it will take longer after your clicking until the action of it will start. If you want a short reaction time you need to click faster for calibration and also in your use case later. The number of clicks are counted with the same timings, so it is not needed to calibrate every pattern by it selves.

How high? We add to the measured values a fix timing to make sure that small changes are still inside the boundaries (+100ms for clicking, +250ms for pressing). In Real-World this should work fine. With infinite fast clicking the output could be a bit too conservative because of this. But if you are fine tuning your system on this level you are likely not using the calibration function but doing some serious measurements by your selves.

I have now kept @tsknightstorm waiting long enough, to publish the release he has contributed a lot of time and effort into. Finally version 2.0.0 is now available in the palette: