Switch node - MQTT like wildcards for switching

Core Development Feature Requests
1

Hi all, I am canvasing opinion on switch node switching with MQTT-like wildcards

@bartoszek made an interesting point...

Obviously we could use JSONata or regex to simulate this functionality but I think his point is valid. If we are using topics and have MQTT wildcard features for MQTT, it would seem like the obvious thing to add MQTT-like wildcard filtering to the switch node?

Something like...
image

What are peoples thoughts on this?

What would the dropdown entry label be?

Is it worth it?

4 Likes
2

With wildcard everyone also imagines something different. For example, I think of wildcard more about have a * as wildcard which stands for multiple characters and not the MQTT-like #.

I only think that this option should then be named a little more specifically.

On the other hand, I have been using the contains in the switch node for this type of filtering in the past.

3 Likes
3

Yes, me too, but contains doesnt do startsWith and cant handle + or #

For me, ? is 1 char, * is none or more of any char, '#' is a number etc etc - but you are completely right, eveeryone has there own idea of wildcards :confused:

Agreed. So perhaps the dropdown name would be something like +# wildcard or MQTT filter or ????

2 Likes
4

Not sure what would be the benefit compared to matches regex. Am I missing something?

5

It would be much easier to use.
Regex is not that easy to format, and it's reputation puts off a lot of users.

1 Like
6

That's true. But having multiple options to do almost the same thing might also be confusing when to stop using the "simple" one when to start using the "complex" one. I am no regex specialist, but regex101.com is my friend :slight_smile:
Putting a link to a simple regex tool could be an alternative to me.

1 Like
7

Hi @greengolfer

I feel the benefit is it matches MQTT topic filtering so anyone doing a primarily MQTT based solution has a sense of consistency.

I know regex fairly well but it is not for beginners. Nor is JSONata.

3 Likes
8

MQTT filter or Topic filter doesn't sound bad

1 Like
9

@greengolfer please remember that An unescaped delimiter must be escaped with a backslash () so a simple query would look like home\/.+\/temperature\/status compared to home/+/temperature/status

10

Topic filter could be confusing, but MQTT filter or MQTT topic would be clear (using the word 'MQTT' makes it's intended use clear, and leaves the regex option open for more advanced users).

2 Likes
11

Topic or MQTT filter is confusing as it implies it's for topic payloads or, has something to do with MQTT as it could just be used for path filtering, without MQTT. Maybe PATH Filter. Also escaping the / is also pron to errors and confusion.
[edit The ability to pass on the # or + match would be neat to]

1 Like
12

Perhaps "matches pattern" , and such a pattern can contain wildcards. Similar to the "matches regex" option... Although a regex is also a pattern of course...

3 Likes
13

My thoughts is - on the useful feature request scale of 1-10 is it anymore than a 1?

Do you have an actual use case for it?

99.9% of time - contains "xxx/yyy/" will handle xxx/yyy/# so only needed for xxx/+/yyy

PS but @BartButenaers suggestion of "matches pattern" seems good as a name for it

1 Like
14

IMHO this feature can be used in most use cases instead of regexp. For me personally, lack of this function was the sole reason why I dropped the use of topics in my project altogether, and probably all people that come from "embedded c" world would also try to avoid regexp
The fact that it would be inline with MQTT is also worth noticing
I think thit this should have lot higher grade then 1/10, maybe 3/10 :wink:

2 Likes
15

To me - either it is an MQTT wildcard type filter or it isn't. If it is then it may as well be called an MQTT filter and accept just + and # as the wildcards correctly (eg foo/+/bar is ok - but foo/ab+c/bar is not) .

If not then it is something else and why wouldn't contains or regex etc do, as otherwise it's yet another syntax to learn. (and of course if someone wants to add a regex helper/tester then that could also be an option instead)

6 Likes
16

Unless I've misread, that is exactly what has been suggested.
It would be a useful addition, because it would widen the scope of using MQTT topics & wildcards, which I would suggest are not currently used to their full potential by most 'non-technical' users (me included) :+1:

1 Like
17

I must admit that I have never used mqtt filters. So when I should see an "mqtt filter" option, I assume I would never use it. I don't mean that I don't like the concept of the mqtt filter examples above, but I would not expect that it would offer me pattern matching via wildcards on any (non-mqtt) messages...

18

I think if you are going to do this, you need to get rid of the escapes. Otherwise you might as well use regex. Its only real purpose is ease of use and ease of learning. So it should work exactly like an MQTT topic filter as stated.

I think I'd put it at a 5 myself. There are certainly times when I'd be happy to use it and it would certainly sometimes replace single, more complex, function nodes.

3 Likes
19

Do you have a concrete example of when you've had to program a function node to switch on wildcard topics?

20

Oh yes. Let me see if I can grab something.

1 Like