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 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
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.
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
Steve,
You can also create a node-red-contrib-pattern-matcher node, that let users choose from a list of pattern matching mechanisms (regex, wildcards, mqtt filters, ...).
Bart
As was already established above several times the switch node is more than capable to do this with regex right now.
So why not just add an example to the mqtt section of the cookbook to explain how to do this. This way either people see it there or we can link to it when it comes up in the forum.
Nice side effect would be that people get to learn some simple regex which is a useful skill in itself.
Just my opinion though
Johannes
Nobody reads the docs - you have seen the forum replies "see the built in help" "see the readme" "see the cookbook" right?
MQTT topic (of course )...
sentiment node?
Ok, lets see if we can round this off...
Summary
So I read from the posts in this thread there is slightly more positive consensus towards the switch node supporting this but there are variations on that support (mqtt filter vs more general wildcard)
Use xxxx (arguments against it)
There are several posters saying "use regex" or "use JSONata".
The counter argument to that is, why bother having == or contains or is true etc - you can do these in one of regex or JSONata
Personally, I dont think "use regex" or "use JSONata" is the answer. I love the power of regex & JSONata BUT I almost always have to use a helper for even quite simple things.
The fact is, they are not simple, not for newbees and are inconsistent with MQTT topics.
e.g. to achieve a really simple topic filter of +/1/+/temperature in regex is ^[^\/\n]+\/1\/[^\/\n]+\/temperature$
I do agree MQTT topic filtering is somewhat restrictive BUT as others have pointed out "which wildcards?". There is no real standard (MS versions, VB like version, SQL like, glob etc etc). I too would really like a nice easy to use *?# form of wildcard matching but in the context of MQTT topic filtering, I dont think it it makes a lot of sense since * and ? are valid characters in a topic (not that I would ever use them) - meaning we would have to escape them.
Perhaps this is a good and sensible proposal for simple wildcard matching & something that should be considered for the switch node but I believe it should be separate from MQTT topic filter. Perhaps we can discuss and agree in a different thread?
MQTT topic filtering
IMHO Anyone doing MQTT knows (or will eventually learn about) topic filtering via +/# so i would propose if we DO add support for this, then it is just that - KISS approach.
MQTT Topic filtering - so it would only need to be enabled/visible when the property is set to msg.topic ? - as that is the only practical use for it, otherwise it's just confusing. Again as I said - none of the examples above have actually shown a real use case for when the filter includes a wildcard, they all need exactly matches - so I think this a nit of a corner of a tiny problem.
General wildcard - as per my example above the option states what the wildcard is so you don't have to guess - and by being an option (default off) then * can be matched to * in a topic if required. Happy to move to a different thread if required - though of course it could be used to match mqtt topics as well as any other msg property.
With a wildcard matching this will be simple and clear:
startsWith: bla*
endWith: *bla
My concern is the same that @dceejay have, that the proposed MQTT filtering only makes sense for strings that are structured like a topic (/abc/ def/ghi).
for a single character in many places. But this not consistently.
)
