Reading the topic I just had another idea how this could be solved.
By integrating the functionality of your contrib node into the existing mqtt-broker config node to provide an "in-memory mode" without a broker. That way you could keep your MQTT nodes in-place and just switch to the "in-memory" broker, which does all the message routing in your local instance.
The disadvantage I see, it would require changes to the core node code, UI, and possibly clutter up the code of the MQTT node. And yet another piece of code that has to be maintained.
You can now publish to topics with + wildcards in them and the topic is inferred as much as possible. Of course, if both publishing and subscribing have a wildcard at the same place, it cannot invent a topic, so it will infer to +.
I am in the process of rewriting many of my flows with this node and it makes them much cleaner. Especially things like "turn all off" or similar can now be done very elegantly.
I indeed thought about that first, but given the fact that Dave did not seem to like the idea of this node, I think the chances of getting such a PR through are low. Furthermore, since I now depart from standard MQTT behavior by allowing publishing with + wildcards, it doesn't make so much sense anymore to have it in MQTT. Further, interfacing this node with MQTT is really easy.
Personally, I would have stuck with the MQTT semantics if there was any real interest in incorporating this into the core. Hopefully it won't confuse users who think this node uses MQTT wildcards and then try to apply what works with your node to the actual MQTT nodes.
I get your argument, but in which way should this have been incorporated into the core?
As an addition to the link node or the MQTT node? As I said, the feedback in the beginning was not really positive, so I did not expect that there is interest in incorporating this into the core.
Being able to send out to for example devices/+/updateState or similar is really a useful feature or do you disagree?
Furthermore, I think such a feature is also more closely related to the link node if the filter gets implemented.
I will update the readme and the help text to more clearly state that this behavior departs from standard MQTT behavior. Maybe even remove MQTT from the first description.
Let us assume you have 10 relays at some location.
They might be controlled by the topic relays/location/relay_i/control for i = 1,\ldots,10.
Now assume you want to turn all of them off.
The MQTT way would be to have an additional in node that listens on an additional topic, like relays/location/all/control for example.
If you can publish with a wildcard, you can just publish on relays/location/+/control and turn all off, without needing additional nodes.
You can go even more crazy, if you have multiple locations, you can just publish on relays/+/+/control to turn off all relays on all locations.
Well, I think that you would at least have to maintain an in-memory list so this does potentially simplify that use-case. Matthias is, of course, correct that this can be done in other ways but that is always true.
While I'm not sure I will use this myself, I can see that it could be elegant and simple for some people.
then you have to do the list thing manually, e.g. like suggested by @kuema or similar.
OR you have your topics organized in a hierarchy that reflects the 8 out of 10 you want to reach
As an example I mentioned earlier:
You have relays which listen on the topics relays/location1/relay1/control relays/location1/relay2/control relays/location1/relay3/control relays/location1/relay4/control relays/location2/relay1/control relays/location2/relay2/control
Now if you publish on relays/location1/+/control, all relays in location1 are turned off, while the ones in location2 are not turned off. But if you publish on relays/+/+/control all relays in all locations are turned off.
You can introduce more hierarchies for more fine grained access.
It is the same as if you subscribe like in MQTT today, if you subscribe to sensors/+ you get the data from all sensors and not only those 8 you might care of.
I opened another topic for this problem. dceejay and cymlpecy wrote that this is solved problem by node-red-contrib-topic-link.
I've already planned my smart home system with rpi + node-red + zigbee2mqtt for months. At the and of the project about 80-100 zigbee device will be in my home. It means the traffic of sensor messages will be quite big through mqtt broker, so i don't want to use it for anything else.
I'd like to make a schedule and an event handler. Its operation is as follows: I can choose one of zigbee device in UI and set a status value of it, which the event handler checks. If this UI configured event occurs the handler have to send an order (msg) to one of zigbee device to make something (for example: switch off a lamp). The scheduler works same like event handler.
In one word the event handler and scheduler have to reach all of (zigbee) device subflow (all device have own subflow), but I canât wired the scheduler, event handler directly to each device subflow, because I should wire 4-500 connections and 1-200 messages go at the same time, and every device subflow should decide if it is the recipient the incoming message.
Well, I got stuck in planning 3 weeks ago, and Iâve looked for the solution since then. And this is the best, if I donât want to load the mqtt broker.
One of big advantage node-red-contrib-topic-link is that the whole msg object will be sende to âtopic link inâ node.
That is a super innovation and the biggest barrier terminated with your nodes.
But I have a suggestion / request.
I donât know yet exactly that maybe I should use dynamic âtopic link inâ like ânode-red-contrib-mqtt-dynamictopicâ
Can you add one more node: âdynamic topic link inâ, where we can set the exact topic by msg message.
Nowadays I just plan the smart home system, and there are some device on the zigbee network yet, but I don't like to rebuild the whole system at the end of the system building when I realize a traffic problem. It will be very difficult (I think)
I will use rpi 4 2GB
My guess, you will most likely not find the mqtt broker being the bottleneck, rather the ZigBee network will be, especially if it is "meshing" a lot. A ZigBee network operates from only 20 to 250 Kbps
I think you have to have a proper design of the system architecture. I believe what is important will be to filter out information early that you really have no interest in, avoid "carrying" this all the way through your system, eventually also over your local wlan/lan. The commands and responses when turning on/off your many devices should be a piece of cake for the mqtt broker, eventual latency I expect would happen on the zig-bee network but it might be almost "unnoticeable" for the naked eye
The node already allows this. Just leave the topic blank for the out node and set it via the msg.topic property. The readme explains that also, I think.
@cinhcet: Yes, I tried it and it works well at 'topic link out' but this option is not currently available at your 'topic link in' node. (there isn't input of 'topic link in' node)
