Function node for getting mqtt_in nodename

[Colin]

@jbudd

I think it's tidier not to have a different mqtt-in node for each sensor. Not sure if it results in less MQTT connection IDs.

I believe any extra overheads are trivial. I much prefer to have multiple mqtt nodes rather than additional logic in the flow routing the messages.

[Colin]

@refthoom

Before I extracted the msg.topic with a function node but you say that is not the appropriate way, I should keep using msg.topic instead but I don't know which node can provide me with the room name from that to be able to use it as the zone name.

I did not say that you should leave it in the topic, I asked whether you needed to move it.

You can get it from the topic just the same as from a payload member, using, for example, in a function node
const room = msg.topic.split("/")[3]

[refthoom]

@jbudd

I think it's tidier not to have a different mqtt-in node for each sensor. Not sure if it results in less MQTT connection IDs

Thanks @jbudd. After some reading and testing I think I understand your approach. With an injectnode that has a timer for example, I could query each Tasmota device to recieve the telemetry data but the automatic tele works fine as well for my situation. I've set the Teleperiod to 60 in Tasmota giving me data every minute. However that would still involve having to put the room name in every injectnode then. Instead of course I could add some logic and an array of rooms to route messages but at the moment that seems more complex than just using the tele and msg.topic. So, one connection is indeed tidier but I think I'll go with @Colin's approach here, for the pratical reasons.

@Colin

I did not say that you should leave it in the topic, I asked whether you needed to move it.

Apologies, I misread that then.

@Colin

You can get it from the topic just the same as from a payload member, using, for example, in a function node
const room = msg.topic.split("/")[3]

Thank you, that could work very well for me. I was tinkering with a node-contrib option but this is much cleaner If I have time today I will try that out and post my results here.

Update 30-10-2024 10:55: I have what I wanted now, thank you very much @jbudd and @Colin

On the left I've subscribed with a wildcard, extract the room name with const room = msg.topic.split("/")[3] and then route the different topics with the switch node. BTW: Obviously this flow is just for testing. The function and switch nodes here will be part of my subflow.

The switch node uses regex matching:

With this configuration I can have multiple dashboards from one connection and only one subscription for that connection. Yeah! (still one connection per room though)