Yes I get that, but looking at this from the perspective of a amateur, with limited technical knowledge, and I wanted to filter the incoming MQTT messages, I may well look towards the switch node.
It's node description is "Route messages based on their property values or sequence position", so if I were routing MQTT messages based upon their topic properties, it's probably fair to say, that the switch node would be a viable consideration.
Though again. In the example uses above where does the mqtt wildcard come into play in the switch ? You need to actually match. None of them seem to need wildcards
As a total fumbling programming novice I find @knolleary argument fairly compelling. I'm going to suggest that most of the discussion so far has been from people so advanced they can't remember not coding. To me since I only have a hammer everything looks like a nail and offering more choices would probably just confuse me further.
That is of course only my own totally ignorant opinion
When you wanted to send a topic1/# one way and topic2/# another.
or +/sensors/# one way and +/switches/# another
Doesn't "contains" do that already ?
Hey @gerry I understand your point and Nick's but if you would let me flip that coin...
A novice who is learning MQTT might understand the whole
#+ filtering of topics but get them to do that in a function node or regex or JSONata and they end up here asking "how do I do ..."
So I started this thread to canvas opinion and so far I see a 60/40 approach, 60 like it 40 are "um but you can do xyz".
The the guy who raised this originally posted an interesting comment that led me starting this thread...
... To which I was originally defensive but he did raise an interesting point.
Keep the comments coming. It's good to debate.
So why do we have contains, if we have regex or JSONata.
But to answer your question, as it would make things simpler as some else pointed out if you are using mqtt topics already, it would not be a leap to use them in the switch node to for routing.
[edit would contains handle topic/+/sensors/# ?]
Well you need somewhere to keep the interesting data, and then probably somewhere to tell you what that data is. So yes we chose payload and topic as we started from Mqtt world. We do try to stick to payload being the main property so all nodes know where to look by default. These days lots of properties other than topic are used to describe other aspects of the message, so we are not so tied to topic.
Actually it was the other way round. We had the simple comparisons first and then the more complex ones were added later. Indeed another alternative would be to add an option to contains to treat * as a real wildcard. (Visually like the ignore case option in regex)
I was not arguing chicken or egg, just that we have other methods.
MQTT wildcard routing would complement the MQTT node.
One of the things that makes Node-RED so useful is it’s simplicity and ease of use.Too often software gets more and more frills added to it that most people never use. A node should do its job.
The mqtt-in node is where # and + belong so you can subscribe to msgs being sent to the broker. This has nothing to do with node-red msgs other than subscribing to information coming from a broker. Once the msg leaves the mqtt-in node you the topic is just a string.
To start adding #+ conditions to the switch is going to make a simple tool more complicated and confusing. I process mqtt msgs from several sensors and using the ‘contains’ option works great. Sometimes I might have to have another switch after it but it keeps it simple especially if someone else will need to look at it.
And if I really needed that complexity to analyze the topic, I should think about how I’m structuring the topics in the first place or I should use a function node.
That’s my two cents
Nor mqtt ... Until they learn about it. But they might know the word contains.. (OK may need to translate that ).
That is an interesting point. Why not adding real wildcard comparison (* for any word,? For any character). And name it something like "wildcard", "wildcard match" or "like" .
- This will be more generic, as it could be used for any string property. - not only MQTT like style
- is same as simply as MQTT matching, even for people who not comes from the MQTT world and knows this type of filtering.
- can still be used for MQTT filtering
- is more useful than only check for "contains", but not as complex/complicated as regex for new users
Using whose definition of "wildcard"?
I'd argue that * is more known/accepted/guessable convention as a wildcard for a number of missing characters in a string, than + for a single word (mqtt) or .* (regex). Especially if it was an explicit option of "contains"
Yes, "wildcard" is a very different used term. And the placeholders are different depending on which world you come from (for example% in SQL). At least Microsoft has used the asterisk * for any character and the question mark for a single character in many places. But this not consistently.
My 2 cent is that I would only prefer a real "wildcard" comparison (one placeholder character for any number of characters and one for one character) over the strict MQTT scheme, because it can still be used outside of a topic comparison.
For myself I don't care about the placeholder characters used. It should only be some that are widely known.
To be explicit I was thinking something like this (hacked visual only)
so a) it's optional and backwards compatible and b) explicit what wildcard character to use.
Sorry, I don't want to appear rude, but that to me looks like a hack, and would not provide the same functionality as discussed above.
I've being trying to stick to OP but my fingers have been itching to type since the start of this thread but I can't help it now .....
If (and I know it's big if) we are to change (pun intended) the switch node a bit - can we add in "not contains" at the same time please, as that is the main thing missing for me that makes me have to resort to coding using JSONata
#HijackOver - sorry
God loves a trier.
Next we'll be asking for startsWith and endswith (and not because that's what I would like in addition to your request )