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.
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 .
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.
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.
