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
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:
Triple and quadrupple click events have been implemented.
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.
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.
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:
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 ). 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).
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.
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
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:
I am attempting to use this node - i have a switch (Shelly 2.5) that i have setup to control my external ligthing
I have a momentary push button switch that is defined as a switch in Tasmota.
When it is pressed it sends an MQTT message with Toggle in it - i would like to use this node to catpure those toggles and dependant on how many i get (single, double etc) then do different actions.
It appears though that your node needs to get an "off" action or similar to discern between the toggles of the button
Tasmota instead just sends Toggle, Toggle, Toggle for 3 button presses
Is there anyway i can use this node or should i look to reconfigure tasmota ?
I'm sure there is a way where you can prepair your mesage for our node just to get the right information. I think for this use case you don't need our "button-event" node. Easier would it be if you just ad a counter node that counts your "toggle" inside a given time frame.
But. If you just have the Toggle-Information you loose the timings of when you press and when you release your button. For a full functionality I would highly recomend to get a button where you can get press and release informations. This makes the user experience much much better and is one of the main montivations to have our "button-events" node.
By the way. What is your motivation to use tasmota? I use many Shelly's (~50x) at home with the default firmware and activated MQTT. But maybe you have good reasons why I should also switch to tasmota ;-).
I have been using Tasmota for a long time now on lots of devices and find that it is easy and well understood. It also appears to offer more flexibility in terms of reassigning buttons etc (but this might just be because i am more familiar with it) - This is is my first foray into using Shellys - previously used mainly the Sonoff stuff and some of the clone Tuya devices
I will have a look at how easy it is to change the switch action/output - in the meantime i might just use the counter as you say
Yep very much so - but it is quite limited - in that it only works for buttons (not switches) - it can only work on the first button in a group and a few other issues.
I attempted this route to start with but ran into issues with it resetting the Shelly
I am just playing with all the different switchstates at the moment to see if i can find a workable solution
Yep thats what i was working through which particular combination would work - but it seems that the Shelly template does not like having switches redefined as buttons - even when they have been detached from the relays.
I did not take the time to have a look at Tasmota for now. But to me this sounds for the right direction.
Click detection is basicly a real time application and should be done bestcase embedded. If you send click and release events via WLAN to your Server it can occasionaly got delayed arround 100ms. In some cases this disturbes your click detection.
If you get de clicking thing running properly on the Shelly 2.5 with tasmota, I will give it a chance in my home too :-). So please let us know how it went.
). 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.
