While I was using the 'Buttons' node, I noticed I always had to include quite many other nodes in the flow to be able to differentiate which button was used, which press,...
So I often had such flows right at the start before being able to really add the 'action' nodes:
I already encountered such situation in I node-set I built (domotic control for Legrand/Bticino MyHome, node-red-contrib-myhome-bticino-v2) where I added a way to easily configure buttons range and action type (short press, long press, repeat,...). Since expected behaviour seemed quite similar to me, I looked into how nodes were built and re-integrated this mechanism directly in the node.
As a result, new outputs can be defined to simplify flows, such as :
The primary output remains as it was, additional outputs are configured as an option, which makes it backward compatible.
Note: when testing this out, I also found out that nodes, on re-deploy, remained kind of active (=all listeners to the bridge were not removed, which resulted in the node receiving x times (1 per re-deploy) bridge-triggered events, until server was restarted)
I modified the bridge part to manage listeners so that they are kept in memory for a later removal. The bidge now has an '.unsubscribe' method to remove node's listeners, which all nodes now call on '.close'.
I thought it could be interesting to merge it in master branch :-)
Hi @Foddy ,
While I was using the 'Buttons' node, I noticed I always had to include quite many other nodes in the flow to be able to differentiate which button was used, which press,... So I often had such flows right at the start before being able to really add the 'action' nodes:
I already encountered such situation in I node-set I built (domotic control for Legrand/Bticino MyHome, node-red-contrib-myhome-bticino-v2) where I added a way to easily configure buttons range and action type (short press, long press, repeat,...). Since expected behaviour seemed quite similar to me, I looked into how nodes were built and re-integrated this mechanism directly in the node. As a result, new outputs can be defined to simplify flows, such as :
The primary output remains as it was, additional outputs are configured as an option, which makes it backward compatible.
Note: when testing this out, I also found out that nodes, on re-deploy, remained kind of active (=all listeners to the bridge were not removed, which resulted in the node receiving x times (1 per re-deploy) bridge-triggered events, until server was restarted) I modified the bridge part to manage listeners so that they are kept in memory for a later removal. The bidge now has an '.unsubscribe' method to remove node's listeners, which all nodes now call on '.close'.
I thought it could be interesting to merge it in master branch :-)