@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.
