A user of the node-red-contrib-simple-gate node has requested the ability to control the gate without having to wire a direct connection to it. In response, I have developed a gate node that can be operated "remotely" by a control node. I have uploaded it to GitHub as node-red-contrib-remote-gate. Before publishing the package to npm, I would appreciate feedback on this forum for two reasons. First, these nodes use features of node.js that I have not really dealt with before, except as part of the incantations required in all custom nodes. So, I expect there will be some bugs or at least coding malpractice that I need to correct. Second, the remote-control aspect of this project seems to run counter to the basic design of Node-RED: that nodes communicate by passing messages along wires. I realize that there are exceptions among the core nodes, and possibly elsewhere, so I would be interested in opinions on how serious an infraction this is and whether it likely to cause trouble in the future.
So how can someone "read" the flow and understand what it is triggered by ? As you said this is counter to the basic philosophy of Node-RED where the whole point is to be able to see what is driving the flow.
The exceptions you mention (like the link node) do (or will soon) visualise the link when selected.
What may break in the future is when we start to allow wires that may not stay local (ie distributed flows) where we won't know about any magic links you have created and they would not work.
You could of course get the same effect by using link nodes together with your existing node.
@dceejay, thanks for the feedback. Slightly out of sequence:
Exactly! That is what I do, and frankly I doubt that I would ever use this node. I cooked it up because a user of the existing node asked for it, and I thought it would be an interesting exercise. I have not heard back from that user, so I'm in no hurry to publish to npm. It's available on GitHub to anyone who wants it, and I wanted to have this conversation rather than seem "anti-social" by dumping something out there that breaks the rules.
I suppose these nodes should come with a caution label saying that they can make flows difficult to debug or modify. I have arranged for each node to display its topic if it is not given a name. This should help, as it does with mqtt nodes, which can be equally difficult to follow by inspection. Also, keep in mind that, unlike mqtt nodes, the traffic being passed here consists of "out-of-band" control messages that cannot actually trigger a flow.
My first thought was to embed the functionality of the link nodes in my gate and controller nodes. As Nick said in another thread, this is not possible, and I assume that if the connections for link (and catch and status nodes?) are going to extend beyond their local flows, it is unlikely that custom nodes will ever get access to that infrastructure. Definitely a warning to potential users.
Thanks for taking the time to respond to this.
Hi,
There are some changes to link nodes in the 0.20 beta that should make them easier to use as well so hopefully that will also help. Thank you for engaging and seeking feedback before just releasing it. Of course you are free to do so if you wish, and indeed the project tenets can evolve over time, but flow visibility is one of those we really don't want to change lightly.
It is always interesting to see what others come up with and why - and why a particular solution is chosen over another. Always good food for thought.
