TRIGGER NODE to set TOPIC also

Core Development Feature Requests
1

I know it could be rare, but I guess this is one of those times.

I am kind of using a trigger node as a watchdog kind of thing.

It needs to send a message with a topic if something goes wrong.

Alas there is no way to set a topic in the node. I have to do that externally with another node.

Would it be too much to ask for a topic field in this node?

Thanks.

2

Exactly, and that should not be a problem at all. If we allow to configure msg.topic in the trigger node why not to do the same with the delay node, RBE node, etc ? At the end all nodes would have this feature? I believe it is not a good thing to overload nodes with functionalities.

Anyway, you can already configure extra information to be forwarded by the trigger node. You can craft a msg using the "Send field" in the config dialog (but everything configured there will be send inside msg.payload).

trigger-node
trigger-node519Ă—575 15.6 KB

3

Isn't this meant to be the basic core of NR - tie nodes together to add functions as a message proceeds through the chain - rather than having an all seeing all doing entity with lots of complexity ?

Of course you could always write a new node to do what you want - have you checked in the repository to see if anyone else have written what you are looking for ?

Craig

2 Likes
4

Actually I am not sure you were meaning what I read, but I could use the { } and construct a message with payload and topic in there.

Thanks.

5

While we can agree in general, specifically, the topic is generally considered core and, along with the name field, appears in most nodes.

All of my nodes include both name and topic and the topic will pass through from an incoming msg unless explicitly written into the nodes configuration.

It is always a balancing act between node simplicity and flow simplicity. Adding another node just to set the topic is extra work and clutters the flow when it shouldn't really be needed. The amount of additional coding in the node is minimal.

6

Good point. I did a review on the core nodes. Indeed msg.topic is added into the msg by most of the nodes that can be used to trigger flows (input nodes). Some nodes, like the UDP in, for instance, will not produce a msg.topic in any way. Others, like the catch node and the complete node (new one in v1.0) will add msg.topic as an empty string having no option to set up a topic in the config dialog. Others, like the ping node (I guess it is not a core node) will add a msg.topic based on the content of another field (you can´t configure them in the config dialog). Fortunately the node help always makes clear how msg.topic is handled for those nodes.

I agree that is a good thing that input nodes add msg.topic to the msg object. Now when it comes to other nodes that already performs their specific function it is arguable if they should have the option to configure msg.topic . At the end of the day is like your phrase states "It is always a balancing act between flow simplicity and node simplicity" (good insight. I will borrow it for my classes if you don´t mind).

1 Like
7

It would be nice if the {} JSON option all the various nodes would actually produce msg instead of msg.payload

1 Like
8

@bakman2
Wouldn't that then loose the msg._msgid causing who knows what kind of problems??

9

Not necessarily, it will depend on the implementation, keep existing properties and add the rest.

10

Changing that now would probably break all existing users.
As Craig said - "tie nodes together to add functions as a message proceeds through the chain" is one of the key points of Node-RED... each node should do what it does, and do it well, and not try to do everything.

But yes things do evolve over time. Back in the days before it was even called Node-RED payload and topic were about the only things it understood. So everything that wasn't a payload was probably a topic.... (Some "what was I thinking" examples of that still remain - for example some of the database nodes query modes - aargh!). Obviously that was dumb and abandoned early on - but yes in general payload is considered the first place to look for "interesting" data from a node and what every node should expect and produce. Topic does make sense as a secondary piece of meta-data in many cases, but there are so many others that hard coding it into every node doesn't make sense when it is easy to add/remove with a change node (for example).

One thing we do want to look at fairly soon though (post 1.0) - is an upgrade to the inject node so that it can inject more than just payload (and topic), current thinking along the lines of the change node (as in you can add multiple "rules" or in this case properties, with payload and topic as the defaults naturally, so indeed this would produce a complete msg.

6 Likes