The lady of the house asked me to install some LED strips in the house, but those also have to be controllable via physical hardware switches.
So I started looking around about reading a physical button from Node-RED. The only thing I found were some nice flows flows from @Trying_to_learn. However I was looking for a single node, to keep my flows simple. I must admit I was "very" surprised that I found none, in an active IOT community like this one. Perhaps it already exists, and I used the wrong keywords during my search...
It can be wired to a GPIO-in node, and can detect all kind of button events:
pressed: when a button is pressed and held down.
clicked: when a button is pressed and released rapidly.
clicked_pressed: when a click is quickly followed by pressing and holding the button.
double_clicked: when a click is quickly followed with another click.
released: when the pressed button is released.
I would like to thank Bryan Nielsen. I found his rpi-gpio-buttons and asked him whether I could have a separate button event detection library, without the gpio stuff (since we already have that inside the gpio nodes). The next day he offered me already his button-events library. What a support
It would be nice to get some 'constructive' feedback before I publish it on npm.
Hmm, interesting, I have some proximity buttons. I normally avoid attaching electronics to the Pi's but as I'm moving away from the Pi's for my main platform, it could be useful to have a proximity switch on a Pi.
This could be very useful for all sorts of inputs, not just GPIO pins. For example it could be connected to dashboard buttons, or MQTT inputs. I use some Sonoff devices with touch buttons that I need to detect such events and at the moment do it with Trigger nodes etc. For me it would be useful if the input values could be configured to other values such as "On"/"Off". It would not need the Idle value field if that were provided.
I am not able to test it at the moment (I will later when I have some time). Why does it wait after the first release before generating a clicked event? I would want it to generate that immediately and also generate the double click event on the second release if there is one.
Having thought further about my previous comment I see there would be problems if it produced both click and double click, as it would be difficult for those not wanting both events to filter out the click, so the node would have to provide the option for the existing behaviour, so my suggestion on that front probably isn't worth pursuing.
Also I have realised that it cannot be used with the dashboard button as that doesn't provide a release action. I don't know whether there is a technical reason for this or if it just hasn't been provided.
The suggestion of configurable input values would be helpful to me though.
Another feature that would be useful would be to have the events on separate outputs which would often save a switch node. I suppose that might be a major change to the config i/f though, as probably one would need to have something like the Switch node config where you could add outputs and configure each with the type of event.
Hey guys,
Thanks!! This is the kind of feedback that we - as node developers - really appreciate with a beta version, because it is rather difficult to change it when it is released ...
I have implemented your request (on Github):
So now you have to specify which values will arrive when the button is down (pressed/clicked) or when it is up (unused). This indeed allowed me to remove the "Idle value".
As simon already mentioned: it will wait for the "Clicked" time interval to see whether the button is immediately being clicked again afterwards (resulting in 1 double-click event instead of 2 separate click events). If you don't want that, you will have to set the "Clicked" time interval to 0 milliseconds. Then you will get your 'clicked' event immediately when you have released your button:
I have corrected it. You guys see everything...
It took me a couple of hours to figure out when which event was triggered by Bryan's state machine, and to draw it in a timeline. But I think/hope it was worth all the effort, because it was not clear to me how it worked in the beginning...
Indeed. In the test flow on my readme page, you will see that I use one button to produce zero's en one button to produce one's. But that is indeed a bit cheating. A button that would keep being pressed would have been nicer ...
I have been playing with that idea also last week, since I also want to avoid as much Switch nodes as possible. But when I add an output port per event, then my node becomes rather big and heavy:
So I don't think we would gain much with this design ...
I'm not sure whether I understand it correctly, because there is already a checkbox on the config screen:
You mean something else?
My time is up for today. Have to work tomorrow morning for my daily job
Work done. Was lucky because the systems were behaving well... The weekend can continue now at last ...
Those fields are very useful to reduce the number of Change nodes in the flows of my users, and they also allow people to avoid overwriting the original input by my event information (so the original input message will be extended instead of overwritten). That is why I'm not going to remove them ...
And indeed I could move them to the bottom of the config screen, since they are as relevant as the event checkboxes. But then I'm afraid that some people won't know that they exist. Because some kind of users don't know that there is a scrollbar to show all the options
But good that you mention this! Because seemed I had forgotten the basic rule: don't create a new message, but reuse the input message... However some functionality is missing in the button-events library to accomplish this, so I have create a feature request for Bryan.
That is true if you provide them all every time. I was thinking you could use something like the Switch node GUI where you select what you want on each output, and outputs are only added when the user configures them, so typically an individual use case would require only two or three outputs. That would be a significant rework of the GUI code though, so maybe not worth the effort.
...but would be a much more usable imho. In that you would need the out parameter, and the options for each pin become a simple select, rather than a large list of check boxes, And saves the subsequent switch.
Damn. Seemed after all that the servers at work had a bad day.
So a large part of my sunday was ruined
Hmm, seems Dave agrees with you. Damn again.
But indeed looks better. Although had to rewrite a major part of this node...
Anyway it was worth the effort:
And then the output labels are automatically updated:
This version is now available on Github...
Well there was a discussion about that already last week.
But - due to the editableList instead of the checkboxes - the config screen has become smaller, so hopefully the name field is not annoying for you anymore.
Yes indeed that is what I was talking about:
But good that you mention this! Because seemed I had forgotten the basic rule: don't create a new message, but reuse the input message... However some functionality is missing in the button-events library to accomplish this, so I have create a feature request for Bryan.
That feature request should be implemented before I can continue reusing the input message.
Not sure about that icon though hopefully just an artefact of the "video". Also the icon colour is a bit close to exec node with it's multiple outputs for me but... yes altogether much better.
