Restricting connections between custom nodes

Hello :slight_smile:

Is it possible to restrict not only the number of entries but which type of node is "entering"?

E. g. I have 2 custom nodes:

  • NodePlant
  • NodeWater

I want to make sure that only NodeWater can be connected to NodePlant. Is that possible? and sorry for the stupid example :wink:

Thank you

Hi,

no, the editor doesn't provide any way to restrict what can be wired into what.

As a concept, it has come up from time to time, but it has never got onto the backlog to be looked at eventually.

1 Like

It might be more sensible to enforce a data schema instead, that way you are keeping the node-red way of doing things but still getting a similar benefit.

In your example, NodePlant would check the format of the incoming msg and if it didn't have the right structure, it would reject the msg, probably emitting an error.

4 Likes

Agree with @TotallyInformation as this kind of constraint might backfire at some point. I believe the two different nodes should be "loosely coupled" by the structure of the data (or alternatively with a simple property telling the format).

This way it will be possible to modify or replace the data source if needed. For example imagine a situation where you loose interest in maintaining the nodes but someone will still find them useful for some modified scenario. Or if the user wants to add nodes in between to calibrate the data.

2 Likes

Hi @oreo,
When I started with Node-RED I also was wondering why there were no restrictions on which nodes can be wired to each other. Because then users cannot add incorrect wires anymore...

But during time I learned that Nick his current model offers a lot of advantages:

  • Suppose I really like your NodePlant node, but I don't want to use your NodeWater node. Now I can develop my own NodeWater2 node, and I can still send messages to your NodePlant node. I only need to make sure that my NodeWater2 node sends messages that contain all the information that your NodePlant node needs ...
  • Suppose I would like to count the number of times that the plant gets water, and trigger an alarm when then count becomes to high. Now I can simply add an extra counter node in between both nodes. And it still works.
  • ...

Bart

1 Like

The flexibility of not having any constraints is what makes Node-RED so useful. Somebody might come along one day and think of new ways to use the information from the "NodePlant" node, or find an interesting way to control the "NodeWater" node. Allowing other connections turns them from a very specific application into more general purpose nodes.

2 Likes

And some more examples:

  • You could have NodePlant running on server 1 and NodeWater on server 2, and send the message via MQTT from one server to another. But then there will be extra nodes in between:

    NodeWater --> MqttOut --> MqttIn --> NodePlant

    Since both nodes are running on separate Node-RED instances (with separate flows), so don't think you will be able to use your model in such a setup.

  • You could have NodePlant on tab A of your flow editor and NodeWater on tab B. Some extra Link nodes are added to wire your nodes together:

    NodeWater --> LinkOut --> LinkIn --> NodePlant

    So in theory there is a simple wire in between them, but in in reality there are two nodes in between.

  • Via the new pluggable routing mechanism, your both nodes could - in the future - even be inside two separate groups running on separate servers. That might 'perhaps' be a problem with your model...

2 Likes

Thanks to all of you guys for your answers :slight_smile:

1 Like