Another question about the `switch` node. (not the GUI)

Ok, I've been called up a few times that I do things back to front when filtering messages.
If I am looking for a message that isn't of a certain type I find all messages of type and send them to output #1 of the switch node.
Then for output #2 I have the otherwise set.
And then connect to the second output.

Yeah, maybe not the best way.... But this one came up today.

I am getting messages and there are two versions of the message. (Topics different)
So I get (example)
topic 1
topic 2
topic 3
topic 4
topic second1
topic second2
topic second3
topic second4

I want to ignore all messages with second in them.
I can't see an easy way to use the switch node other than how I do it by default.

Basic config:
if msg.topic contains second --> output 1
otherwise --> output 2

And I use output 2.

That is the easiest way - yeah?

Well you could do this ...


[{"id":"f763a100670d72b2","type":"switch","z":"5f633a28.607134","name":"","property":"topic","propertyType":"msg","rules":[{"t":"jsonata_exp","v":" $not($contains(topic, 'second'))\t","vt":"jsonata"}],"checkall":"true","repair":false,"outputs":1,"x":1470,"y":620,"wires":[["93cb67ca666a9a45"]]},{"id":"9563ae0998acc181","type":"inject","z":"5f633a28.607134","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"second1","payloadType":"date","x":1320,"y":580,"wires":[["f763a100670d72b2"]]},{"id":"660fe474003c28b2","type":"inject","z":"5f633a28.607134","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"1","payloadType":"date","x":1300,"y":640,"wires":[["f763a100670d72b2"]]},{"id":"93cb67ca666a9a45","type":"debug","z":"5f633a28.607134","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":1620,"y":620,"wires":[]}]

Yeah, ok.

But for the village idiots out there - like me....

That is black magic. :wink:

Only took 5 mins to google the voodoo :crazy_face:

Yes. The most efficient way too, probably.
But maybe it implies you gave insufficient thought to the value of topic back down the line?

Actually I think the flow is easier to grasp visually if you have a switch node with two outputs, one of which has no wires connected.

Untitled 6

1 Like

I haven't tried/noticed that before.

I guess I leave the unused output visible - for me - it is an indication that the passing is a NOT rather than a match.

But that's just me.

But those labels are wrong on the switch node. It is if NOT contains "second".

Yeah, but does it really save anything.
Putting it like that is basically what the second line in the switch node would do anyway - yeah?

Yeah its functionally the same effect, but only has one output.

I sometimes do it the same way as you @Trying_to_learn but the resulting unconnected outputs and wires that bend without good reason offend my inner NCO.
As do long node names. I'd probably just use "second?"

Yeah, long node names are a bit of a thing.

Also that sometimes I shrink the node to the small 1 x 1 square.
But then I do give it a good name so if I put the mouse over it, I see what it is and what it does.

I would question the reason why you receive these topics in the first place (if you don't want them there).

The messages are endemic messages from a command.

I originally thought the code would not use them. Alas recent events have shown me I was wrong.

So I needed to filter out those from the stream.

$hit happens.

Always you can delete unneeded message using change node or in function node.
Or using function node save the message to temporary variable next clean all message and finally
get important data from temporary variable and prepare a new message to resend it.

Having a unused output is the current NR way of selecting something that doesn't contain a search string.

I've made a recent feature request to have a "not contains" option as well

And for all the options that currently don't have a not alternative

1 Like

That's what I was thinking too.

But this is my work around. :wink:


But for the cost of the change (or function) node....

I'm not wanting to start counting how many bits of memory are needed for each.

I was just wanting to be sure I wasn't missing anything obvious.

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.