# Possible new contributed message gate node

**URL:** <https://discourse.nodered.org/t/possible-new-contributed-message-gate-node/7382>\
**Category:** Share Your Nodes\
**Created:** [29 January 2019 22:59 UTC](https://discourse.nodered.org/t/possible-new-contributed-message-gate-node/7382 "2019-01-29T22:59:09Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![drmibell](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/drmibell/32/8424_2.png) [@drmibell](https://discourse.nodered.org/u/drmibell)\
**Post date:** [29 January 2019 22:59 UTC](https://discourse.nodered.org/t/possible-new-contributed-message-gate-node/7382/1 "2019-01-29T22:59:09Z")

</div>

A user of the `node-red-contrib-simple-gate` node has [requested](https://github.com/drmibell/node-red-contrib-simple-gate/issues/2) 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](https://github.com/drmibell/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.

---

<div class="post-metadata">

**Author:** ![dceejay](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/dceejay/32/38_2.png) [@dceejay](https://discourse.nodered.org/u/dceejay)\
**Post date:** [29 January 2019 23:46 UTC](https://discourse.nodered.org/t/possible-new-contributed-message-gate-node/7382/2 "2019-01-29T23:46:42Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![drmibell](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/drmibell/32/8424_2.png) [@drmibell](https://discourse.nodered.org/u/drmibell)\
**Post date:** [30 January 2019 18:02 UTC](https://discourse.nodered.org/t/possible-new-contributed-message-gate-node/7382/3 "2019-01-30T18:02:38Z")

</div>

@dceejay, thanks for the feedback. Slightly out of sequence:

> [@dceejay](#):
>
> You could of course get the same effect by using link nodes together with your existing node.

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.

> [@dceejay](#):
>
> So how can someone "read" the flow and understand what it is triggered by ?

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.

> [@dceejay](#):
>
> 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.

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.

---

<div class="post-metadata">

**Author:** ![dceejay](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/dceejay/32/38_2.png) [@dceejay](https://discourse.nodered.org/u/dceejay)\
**Post date:** [30 January 2019 22:10 UTC](https://discourse.nodered.org/t/possible-new-contributed-message-gate-node/7382/4 "2019-01-30T22:10:29Z")

</div>

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.