MQTT topic help please Wild card use

With another project in which some one pointed out a problem with how I was controlling tasmota devices.

I have 2 bulbs.
They are called (from MQTT) BULB-1 and BULB-2 Which kind of made sense for me, but it is flawed if I want to control all of them.

It would be better if I called them:
BULB/1/ and BULB/2/

Then I could listen to BULB/# to listen for bulb changes.


I wrote a flow that doesn't seem to be liked by Node-Red.

I'm not sure it is the same thing for both the IN and OUT nodes, but they both have an error on them when I send a message to/through them.

Now, maybe the IN node is not happy that I sent out a bad message.

So if I want to send a message to all the BULB/ devices I can't post a message to BULB/+/cmnd/power1/ a value of ON or OFF and expect all the devices to decode that messages.

A bit of help on this would be appreciated.

I have since been told You can't publish to wild cards.

So, that means I will have to create a bit of stuff so it publishes to all the bulbs.
In this case only 1 and 2. But when I get more bulbs.......

You can listen to wildcard topics, the output shows the full topic, so you know to which bulb to send the command to. Leave the topic in the output mqtt node empty and use the topic that you received.


I have been pointed towards group topics. So that may be of some help for this problem.

That should also work, never looked into it myself.

I just need to find a good reference to group topics.

This video shows how it works (starting from the timestamp that is relevant)

1 Like

Have you read thru this:

Yeah, but it kind of confused me.

The link @bakman2 posted seems to be good. Still applying the changes.
Not done yet.

Woo Hoo! It seems to work!

It is called a grouptopic, but in reality it has nothing to do with mqtt, as it works via UDP directly between the tasmota devices.

yes, but that link filled most of the gap I still had.

Dumb question about topics......

In the switch node...... What is the wild card for there? *?

This is what I have:

But the + is a wild card. So what do I put in the field of the switch node?

Look what the topic looks like when you receive it in a debug node.

is it called blbla/+ ?

FYI from the Hivemq post:


When a client subscribes to a topic, it can subscribe to the exact topic of a published message or it can use wildcards to subscribe to multiple topics simultaneously. A wildcard can only be used to subscribe to topics, not to publish a message. There are two different kinds of wildcards: single-level and multi-level .

Well, I get multiple replies from all the devices and the + is replaced with their names.

Yes, thanks.

And now using grouptopic and a bit of trickery shown in the clip:

I have another topic which controls all the bulbs. So I can turn them all off/on/etc.
But now how to parse the replies.
There is on guarantee to which bulb/s will/may be on when the command is sent.
So I don't know if it is a good idea to pick specifically one.

But I guess for now if I am saying all bulbs (and I have only two) number 1 will be replying.

Try not to mixup what you are doing in NR with MQTT and what you are doing in Tasmota.
The video looks like it is talking about things you do in Home Assistant

You will confuse yourself with grouptopics (device groups) and mqtt.

You say you have another "topic", but is this device also a tasmota device ? If yes, I would suggest to solve it there directly, instead of mixing up mqtt with the group topic control.

Or all via mqtt or all via grouptopics, you are entering a labyrinth.

Well, what I did on each bulb was set a grouptopic and set the extra stuff about receive but don't transmit.

Then in Node-Red, I set a whole new topic and I send a message to it and both bulbs turn on or off.

But I can control each bulb on their own topic.

So I think I have it nutted out.

1 Like

I always use the source of the topic as the first element of the topic path. I can then establish a 1 to 1 or many to 1 publish/subscribe pairs. The '+' at the subscriber topic head, is an easy way to do a many to 1 model, then you can add flow logic to qualify how you want to route message from any unique publishers. I find it easier create new topics, rather than parse existing topics with deeper elements in a given topic.

ESP8266 Temperature Module //ambient/data - > /+/ambient/data Example of a universal receiver, or subscriber.

ESP Temperature Module /<Host>/ambient/control <- /<Host>/ambient/control Example of send, or publisher. (1 to 1).

So I can send a demand for immediate measurement, or have a loop that say every 15 minutes sends temperature data to a universal collector (many to 1).

Do I generate a lot of traffic with unique topics? Yes, but with MQTT you always do, either unique topics or parsing data from fewer topics, it amounts to the same thing in effect.

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