# Switch node - MQTT like wildcards for switching

**URL:** <https://discourse.nodered.org/t/switch-node-mqtt-like-wildcards-for-switching/46337>\
**Category:** Feature Requests\
**Created:** [27 May 2021 11:54 UTC](https://discourse.nodered.org/t/switch-node-mqtt-like-wildcards-for-switching/46337 "2021-05-27T11:54:50Z")\
**Posts on this page:** 20\
**Page:** 4

<div class="post-metadata">

**Author:** ![Steve-Mcl](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/steve-mcl/32/4826_2.png) [@Steve-Mcl](https://discourse.nodered.org/u/Steve-Mcl)\
**Post date:** [29 May 2021 12:54 UTC](https://discourse.nodered.org/t/switch-node-mqtt-like-wildcards-for-switching/46337/61 "2021-05-29T12:54:34Z")

</div>

> [@dceejay](#):
>
> 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

I would say no Dave. There are projects I have done where I have employed an MQTT like topic structure to a property other than `topic` to help identify a value. e.g. when storing mqtt values in context for later retrieval

I would suggest the goal is mainly to be consistent with MQTT topics style filters.

> [@Hypnos](#):
>
> My concern is the same that dave has, that the proposed MQTT filtering only makes sense for strings that are structured like a topic (/abc/ def/ghi).

But that is the whole point of the topic (sic) - to compliment MQTT style topics in a switch node.

Dont get me wrong, I definitely think wildcard matching in the switch would be great addition (I am all for it, where do I sign up) but IMO it muddies the waters with regards MQTT (see my previous post). Someone doing a primarily MQTT solution (as the guy who raised this) rightly or wrongly expected the switch node to do MQTT style topic filtering.

---

<div class="post-metadata">

**Author:** ![knolleary](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/knolleary/32/3_2.png) [@knolleary](https://discourse.nodered.org/u/knolleary)\
**Post date:** [29 May 2021 13:03 UTC](https://discourse.nodered.org/t/switch-node-mqtt-like-wildcards-for-switching/46337/62 "2021-05-29T13:03:33Z")

</div>

> [@Steve-Mcl](#):
>
> Someone doing a primarily MQTT solution (as the guy who raised this) rightly or wrongly expected the switch node to do MQTT style topic filtering.

In 8 years, this is the first time I'm aware of anyone raising it. Let's not make it sound like a major problem.

I'm not keen on adding such mqtt specific semantics to a non MQTT node where more generalisable solutions can be applied and a wider audience benefits. The mqtt wildcards are great for one specific solution. That doesn't justify in my mind adding them to the switch node that is used for way more than just routing mqtt messages.

---

<div class="post-metadata">

**Author:** ![E1cid](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/e1cid/32/77971_2.png) [@E1cid](https://discourse.nodered.org/u/E1cid)\
**Post date:** [29 May 2021 13:15 UTC](https://discourse.nodered.org/t/switch-node-mqtt-like-wildcards-for-switching/46337/63 "2021-05-29T13:15:55Z")

</div>

> [@dceejay](#):
>
> none of the examples above have actually shown a real use case for when the filter includes a wildcard, they all need exactly matches

surly blah/+/blah/# would match multiple topics and require wildcard.

> [@knolleary](#):
>
> Let's not make it sound like a major problem.

No one is suggesting it is a major issue

> [@knolleary](#):
>
> I'm not keen on adding such mqtt specific semantics to a non MQTT node where more generalisable solutions can be applied and a wider audience benefits. The mqtt wildcards are great for one specific solution. That doesn't justify in my mind adding them to the switch node that is used for way more than just routing mqtt messages.

Maybe you could add multiple output's to the MQTT node and routing could be done there.

---

<div class="post-metadata">

**Author:** ![Steve-Mcl](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/steve-mcl/32/4826_2.png) [@Steve-Mcl](https://discourse.nodered.org/u/Steve-Mcl)\
**Post date:** [29 May 2021 13:21 UTC](https://discourse.nodered.org/t/switch-node-mqtt-like-wildcards-for-switching/46337/64 "2021-05-29T13:21:22Z")

</div>

> [@knolleary](#):
>
> Let's not make it sound like a major problem.

Its not & I personally dont think that either ( dont shoot the messenger 😉 )

> [@knolleary](#):
>
> That doesn't justify in my mind adding them to the switch node that is used for way more than just routing mqtt messages.

I understand your point but to play devils advocate (sorry) - its not really a reason not to add it either. It has a use, aligns with the whole topic concept and is additive (benefits those who would use it - others can ignore it).

  

> [@knolleary](#):
>
> I'm not keen on adding such mqtt specific semantics to a non MQTT node where more generalisable solutions can be applied and a wider audience benefits

Am I reading your statement correctly here if i paraphrase that as ...

> **"I'm not keen on adding such mqtt specific semantics to a non MQTT node where a well defined wildcard option could be added for wider audience benefit"**

... or am i mis-reading you Nick?

If I read you right then perhaps we should close this thread off here and start a new discussion on " **wildcard entry for the switch node**" in a new thread?

_(please note I am personally fine with a wildcard solution instead of MQTT filter)_

---

<div class="post-metadata">

**Author:** ![TotallyInformation](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/totallyinformation/32/31_2.png) [@TotallyInformation](https://discourse.nodered.org/u/TotallyInformation)\
**Post date:** [29 May 2021 14:16 UTC](https://discourse.nodered.org/t/switch-node-mqtt-like-wildcards-for-switching/46337/65 "2021-05-29T14:16:45Z")

</div>

> [@dceejay](#):
>
> so a) it's optional and backwards compatible and b) explicit what wildcard character to use.

I'd be happy with that. Though I think it should be \* and ? where ? is 1 character and \* is any number. I think this is the most common form of wildcards?

---

<div class="post-metadata">

**Author:** ![Steve-Mcl](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/steve-mcl/32/4826_2.png) [@Steve-Mcl](https://discourse.nodered.org/u/Steve-Mcl)\
**Post date:** [29 May 2021 14:18 UTC](https://discourse.nodered.org/t/switch-node-mqtt-like-wildcards-for-switching/46337/66 "2021-05-29T14:18:43Z")

</div>

> [@TotallyInformation](#):
>
> Though I think it should be \* and ? where ? is 1 character and \* is any number. I think this is the most common form of wildcards?

I always liked the [VB `like`](https://docs.microsoft.com/en-us/dotnet/visual-basic/language-reference/operators/like-operator) operator. Often wished it were in C#, JS etc

---

<div class="post-metadata">

**Author:** ![dceejay](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/dceejay/32/38_2.png) [@dceejay](https://discourse.nodered.org/u/dceejay)\
**Post date:** [29 May 2021 14:20 UTC](https://discourse.nodered.org/t/switch-node-mqtt-like-wildcards-for-switching/46337/67 "2021-05-29T14:20:39Z")

</div>

> [@Steve-Mcl](#):
>
> its not really a reason not to add it either

see Nick's original comment (post 31) about burden of choice being detrimental.  
"What would Jony Ive do ?"

> [@E1cid](#):
>
> Maybe you could add multiple output's to the MQTT node

or just use multiple MQTT nodes - each for its relevant group of topics - ie use the wildcard in subscription as god (andysc 😉 ) intended. They can all share the same connection after all so it's no greater burden on the system.

---

<div class="post-metadata">

**Author:** ![TotallyInformation](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/totallyinformation/32/31_2.png) [@TotallyInformation](https://discourse.nodered.org/u/TotallyInformation)\
**Post date:** [29 May 2021 14:21 UTC](https://discourse.nodered.org/t/switch-node-mqtt-like-wildcards-for-switching/46337/68 "2021-05-29T14:21:39Z")

</div>

> [@dceejay](#):
>
> "What would Jony Ive do ?"

Create a new wearable that nobody wanted, hype it up and make billions from it 😀

---

<div class="post-metadata">

**Author:** ![E1cid](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/e1cid/32/77971_2.png) [@E1cid](https://discourse.nodered.org/u/E1cid)\
**Post date:** [29 May 2021 14:24 UTC](https://discourse.nodered.org/t/switch-node-mqtt-like-wildcards-for-switching/46337/69 "2021-05-29T14:24:22Z")

</div>

> [@dceejay](#):
>
> or just use multiple MQTT nodes

Yes it would be nice to make the choice ourselves. So you can add multiple i can choose a different stlye.

---

<div class="post-metadata">

**Author:** ![dceejay](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/dceejay/32/38_2.png) [@dceejay](https://discourse.nodered.org/u/dceejay)\
**Post date:** [29 May 2021 14:27 UTC](https://discourse.nodered.org/t/switch-node-mqtt-like-wildcards-for-switching/46337/70 "2021-05-29T14:27:18Z")

</div>

"I refer the honourable gentleman to the previous answer" about too much choice...

---

<div class="post-metadata">

**Author:** ![E1cid](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/e1cid/32/77971_2.png) [@E1cid](https://discourse.nodered.org/u/E1cid)\
**Post date:** [29 May 2021 14:28 UTC](https://discourse.nodered.org/t/switch-node-mqtt-like-wildcards-for-switching/46337/71 "2021-05-29T14:28:09Z")

</div>

And I respond there is nothing wrong with choice's

---

<div class="post-metadata">

**Author:** ![Steve-Mcl](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/steve-mcl/32/4826_2.png) [@Steve-Mcl](https://discourse.nodered.org/u/Steve-Mcl)\
**Post date:** [29 May 2021 14:28 UTC](https://discourse.nodered.org/t/switch-node-mqtt-like-wildcards-for-switching/46337/72 "2021-05-29T14:28:15Z")

</div>

> [@dceejay](#):
>
> see Nick's original comment (post 31) about burden of choice being detrimental.  
> "What would Jony Ive do ?"

I'm not a fan of that sentiment (nor of walled-gardens in general) tbh Dave. Choice is good. Its why we have all the options we do already 🙂

_Anyhow, we are veering off topic again 😃_

---

<div class="post-metadata">

**Author:** ![dceejay](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/dceejay/32/38_2.png) [@dceejay](https://discourse.nodered.org/u/dceejay)\
**Post date:** [29 May 2021 14:30 UTC](https://discourse.nodered.org/t/switch-node-mqtt-like-wildcards-for-switching/46337/73 "2021-05-29T14:30:21Z")

</div>

Now there's a thought - we could add the button and charge millions ! or remove it and charge even more...

---

<div class="post-metadata">

**Author:** ![dceejay](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/dceejay/32/38_2.png) [@dceejay](https://discourse.nodered.org/u/dceejay)\
**Post date:** [29 May 2021 14:38 UTC](https://discourse.nodered.org/t/switch-node-mqtt-like-wildcards-for-switching/46337/74 "2021-05-29T14:38:42Z")

</div>

Ok - wrong analogy (actually not wrong..) - it's a well studied area -

- [The Psychology of choice: Why less is more - Learn UX](https://www.keepitusable.com/blog/the-psychology-of-choice-why-less-is-more/)
- [https://usabilla.com/blog/paradox-choice-less-ux-design/](https://usabilla.com/blog/paradox-choice-less-ux-design/)
- [Simplicity Wins over Abundance of Choice](https://www.nngroup.com/articles/simplicity-vs-choice/)

---

<div class="post-metadata">

**Author:** ![E1cid](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/e1cid/32/77971_2.png) [@E1cid](https://discourse.nodered.org/u/E1cid)\
**Post date:** [29 May 2021 14:49 UTC](https://discourse.nodered.org/t/switch-node-mqtt-like-wildcards-for-switching/46337/75 "2021-05-29T14:49:45Z")

</div>

Choice can also lead to better decisions

> “Choosing from larger assortments tends to increase choice difficulty and, consequently, can cause consumers to rely more on accessible justifications when making their choice,” researchers report in their paper, published in the Journal of Consumer Research. “As a result, we argue that choosing from a larger assortment should lead consumers to select options that are easier to justify.”  
> [More choice leads to better choices - Futurity](https://www.futurity.org/more-choice-leads-to-better-choices/)

---

<div class="post-metadata">

**Author:** ![Steve-Mcl](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/steve-mcl/32/4826_2.png) [@Steve-Mcl](https://discourse.nodered.org/u/Steve-Mcl)\
**Post date:** [29 May 2021 14:50 UTC](https://discourse.nodered.org/t/switch-node-mqtt-like-wildcards-for-switching/46337/76 "2021-05-29T14:50:26Z")

</div>

The importance of choice vs opinionated design is a huuuuuge can of worms - lets not go there 🤣

  

If I can point us back to [post #64](https://discourse.nodered.org/t/switch-node-mqtt-like-wildcards-for-switching/46337/64) for a minute,...

> [@Steve-Mcl](#):
>
> > [@knolleary](#):
> >
> > I'm not keen on adding such mqtt specific semantics to a non MQTT node where more generalisable solutions can be applied and a wider audience benefits
> 
> Am I reading your statement correctly here if i paraphrase that as ...
> 
> > **"I'm not keen on adding such mqtt specific semantics to a non MQTT node where a well defined wildcard option could be added for wider audience benefit"**
> 
> ... or am i mis-reading you Nick?
> 
> If I read you right then perhaps we should close this thread off here and start a new discussion on " **wildcard entry for the switch node**" in a new thread?
> 
> _(please note I am personally fine with a wildcard solution instead of MQTT filter)_

As you guys are not keen on the whole MQTT filter proposal, should we move this in a different direction Dave?

---

<div class="post-metadata">

**Author:** ![dceejay](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/dceejay/32/38_2.png) [@dceejay](https://discourse.nodered.org/u/dceejay)\
**Post date:** [29 May 2021 15:04 UTC](https://discourse.nodered.org/t/switch-node-mqtt-like-wildcards-for-switching/46337/77 "2021-05-29T15:04:32Z")

</div>

I think you'll find that Nick's carefully informed but opinionated design is what has helped make Node-RED what it is over 8 years 🕶  
and yes let's move it over.

---

<div class="post-metadata">

**Author:** ![Steve-Mcl](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/steve-mcl/32/4826_2.png) [@Steve-Mcl](https://discourse.nodered.org/u/Steve-Mcl)\
**Post date:** [29 May 2021 15:14 UTC](https://discourse.nodered.org/t/switch-node-mqtt-like-wildcards-for-switching/46337/78 "2021-05-29T15:14:47Z")

</div>

> [@dceejay](#):
>
> I think you'll find that Nick's carefully informed but opinionated design is what has helped make Node-RED what it is over 8 years

Damn straight. 🧙

PS I hope you don't think i was implying anything there - I certainly did not mean to dis anyone nor our beloved node-red (not my style). I simply hope we can all fairly agree and disagree on points of implementation now and again without offending anyone otherwise there is little point to discussion TBH.

---

<div class="post-metadata">

**Author:** ![Steve-Mcl](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/steve-mcl/32/4826_2.png) [@Steve-Mcl](https://discourse.nodered.org/u/Steve-Mcl)\
**Post date:** [29 May 2021 15:19 UTC](https://discourse.nodered.org/t/switch-node-mqtt-like-wildcards-for-switching/46337/79 "2021-05-29T15:19:19Z")

</div>

> [@dceejay](#):
>
> and yes let's move it over.

New thread soon.

Suggested title: "Switch node - wildcard option for routing"

---

<div class="post-metadata">

**Author:** ![knolleary](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/knolleary/32/3_2.png) [@knolleary](https://discourse.nodered.org/u/knolleary)\
**Post date:** [29 May 2021 15:34 UTC](https://discourse.nodered.org/t/switch-node-mqtt-like-wildcards-for-switching/46337/80 "2021-05-29T15:34:46Z")

</div>

> [@dceejay](#):
>
> We could add the button and charge millions !

Hush, don't give away my business plan for FlowForge

[Previous page](https://discourse.nodered.org/t/switch-node-mqtt-like-wildcards-for-switching/46337.md?page=3)

[Next page](https://discourse.nodered.org/t/switch-node-mqtt-like-wildcards-for-switching/46337.md?page=5)