Switch node - wildcard option for routing

Core Development Feature Requests
1

Hi all, following on from the thread Switch node - MQTT like wildcards for switching that was raised following some interesting points in this thread, it is proposed that it would be ultimately more beneficial to everyone to have a wildcard option for switch routing.

This wildcard option would be more flexible than MQTT filter while being simpler than regex and JSONata and so being more accessible.

Several of the folk who commented on the previous thread alluded to the familiar format of using *, ?, #. This is a pretty common syntax as described here on wikipedia and here in MS docs

Examples...

Wildcard Description Example Matches Does not match
* matches any number of any characters including none *Law* Law , GrokLaw , or Lawyer . La , or aw
# matches any single number no# no1 , no2 ~ no9 nod or o2 or no
? matches any single character ?at Cat , cat , Bat or bat at
[abc] matches one character given in the bracket [CB]at Cat or Bat cat , bat or CBat
[!abc] Dont match one character given in the bracket [!CB]at Rat or Hat Cat , Bat or CBat
[a-z] matches one character from the (locale-dependent) range given in the bracket Letter[0-9] Letter0 , Letter1 , Letter2 up to Letter9 Letters , Letter or Letter10

With regards to MQTT topic matching, this would now be expressed as...

MQTT filter glob style
# ?*
home/# home/?*
home/+/# home/?*/?*
home/+/temperature home/?*/temperature
home/+/+/sensors/# home/?*/?*/sensors/?*
home/+ not possible (*1)
home/+/+ not possible (*2)

*1 : home/+ not possible - closest possible filter is home/?* but that will not stop at level 2
*2 : home/+/+ not possible - closest possible filter is home/?*/?* but that will not stop at level 3


Discussion points...

  • Add + as a wildcard with the definition of "1 or more characters up to a /" to handle points (*1) & (*2) ?
  • Support for Digraph Characters (e.g. æ would equal a and e)?
  • Support for Collating Sequence (e.g. [A–E] matches A ,Ă€ , B , C , D and E. The range does not match ĂŠ because accented characters collate after unaccented characters in the sort order)?

Personal thoughts...

Firstly, apologies up front, I mean no offence to anyone, these are personal thoughts and musings.
I might be wrong (it happens) but as I write this up, I see enough limitations and complexity in implementation that makes me think this wildcard proposal is a case of more effort than benefit considering regex does it all + more. And please don't bite my head off here but I think this tells a tale - there is possibly some mileage in the originally proposed MQTT filter (suitably simple for its purpose at 20 lines of code!). I no longer know TBH :sigh: (sorry folks)


That said, lets see where this goes - perhaps I am to close to this - fresh eyes never hurt :slight_smile:


Ideas / thoughts / comments below please

2

I tend to agree.
Plan A seemed like a good idea which would benefit inexperienced users, but this does not move us on much further from what we have at the moment.
Also, could adding + as a wildcard confuse the regex geeks, as it's not in the official regex schema.

1 Like
3

Frankly, I think that anything more than the simplest * = any number of characters and ? = 1 character is too much. You can use regex for that. I'd personally be happy with the above or with the MQTT style, it is good enough for what I'd use it for and it would help avoid some complex JavaScript nodes.

Keep it simple.

4 Likes
4

+1 for KISS

3 Likes
5

Like others here, I advocate not over-designing this. According to the KISS principle only * for any and ? for one character. Everything that goes beyond that can be solved with regex.

2 Likes
6

Not sure if my beginner's point of view is worth much but...

The Switch node's list of value rules is already so long that you have to use the scrollbar to see them and some of their functions already overlap.
Please don't add yet another option "wildcard".

On the surface the "contains" option looks nice and simple.
I feel the "contains" value should be treated as far as possible as a literal with no special character meanings.
A value of "Chanel #5" should match 'Chanel #5' and not 'Chanel 75'.
If I want to match either Chanel #5 or Chanel 75 I know I can do it with a simple regex.

The fact that regexes can be difficult to construct and understand is not a good reason to provide in addition a simplified subset under a different name and perhaps slightly different syntax.

7

@jbudd I agree (almost) entirely with what you are saying & why I have pretty much dropped this now.

The original request was for a MQTT-like topic filter which is not so easy in regex nor JSONata. Example...

But ultimately it was rejected so I made a subflow instead.

8

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