Function node for getting mqtt_in nodename

Hi all,

New to NodeRed, in the middle of the learning curve :slight_smile:

I want to use a function node to get the name of the parent node that is the mqtt in.


The function node has this code:
Screenshot 2024-10-28 164902
with that I get the name of the function node, like this:

From searching here and looking up documentation, I should be able to get the name of the parent node by prefixing with $parent. like this:
Screenshot 2024-10-28 165341
However, that results in an ' undefined'

Can anyone point me to documentation or give examples to solve this?

Thanks :slight_smile:

Welcome to the forum @refthoom

What do you mean by the parent node name?
What is the name that you are trying to get in the example you showed?

Welcome to the forum @refthoom

Can you tell us where you found that suggestion?

A more Node-red no-code kind of approach is to attach the data that you want to a message property, something like this using change nodes after the mqtt-in to set msg.inputnodename.

If you mean that you want the name of the node that sent the message, why do you want it? msg.topic will contain the topic that the mqtt node is subscribed to.

Thank you Colin
the name of the 'mqtt in' node

Why do you want to know that?

Thank you jbudd

Can you tell us where you found that suggestion?

I found it here: Working with context : Node-RED
It says there that it is for inside subflows but I thought (hoped :slight_smile: ) that it would work for all flows but maybe not.

A more Node-red no-code kind of approach is to attach the data that you want to a message property, something like this using change nodes after the mqtt-in to set msg.inputnodename.

That is basically what I have now (but with a function node that adds the key/value pair to the message with msg.payload.roomname = "my_room_name") but that still means I have to make the same change in two nodes instead of one, right? First set the topic in the 'mqtt_in' node and then hardcode the name in the function node.

Giving the 'mqtt in' node a unique name I have to do anyway to keep the flow clear so it would be nice if that could be used as a variable to use in the subflow that I intend to put after this part.

Please see my reply to jbudd.

Great, that helped! Sometimes I miss those details. With this code:

let Tname = msg.topic;
msg.payload.Topicname = Tname;
return msg;

I now get the subscribed topic like this: Topicname: "tele/home/room1/sensors/SENSOR"

I can take it from there to get the part that I need (room1). Thank you!

Can you not just leave it in the topic rather than moving it into the payload?

If you choose appropriate mqtt topics and use the wildcards # and +, you can very likely have a single mqtt-in node, but the topic will still contain "room1" or "room2" etc.

Unless you alter msg.topic it should still be available further along your flow.
As @Colin says, just use the topic. You may not need to move it to msg.payload.Topicname.

And if your mqtt message contained eg roomname: "Workshop" you would already have a nicely formatted room name as part of the message.

:slight_smile: I'd like to use it as a variable for my dashboard, specifically to set the zone as the room name.

My aim is to only create a new 'mqqt in' node with its unique topic string, for every room and connect that to the dashboard subflow. By extracting the room name from the msg.topic string I plan to use that to assign the zone name in the dashboard. According to the documentation that should be possible.

I'm using MCU's flashed with Tasmota and although that works out really well for me (lo code as well) it doesn't provide room for my own mqtt messages or additions.

Hmm it's perhaps more flexible than you think.

This is from the Configure Other web page for one of my ESPs running Tasmota.


You can see the device is called "Door"

The MQTT topic is tasmota/wemos/door

And if I send it {"payload": "status", "topic": "cmnd/tasmota/wemos/door/backlog"}
I get this including msg.payload.status.DeviceName: "Door" and other useful stuff.

Oh, very interesting suggestion @jbudd, thanks.

I have tried some different things, I think I will use Hostname from the .../sensors/INFO2 topic.

The Hostname is transmitted every Teleperiod while .../sensors/STATUS is not (only after restart or querying for it with a command like you showed). For this to work the 'mqtt in' subscription has to be changed from .../sensors/SENSOR to the wildcard .../sensors/+ which wil generate more traffic but nothing that can't be handled. Also I need to change the Hostename on every Tasmota instance to the room name but that won't be a problem either.

I do have another issue with the wildcard because now I receive multiple messages and my function node throws an error for what has been added. Do you know an easy fix for that, how do I seperate the messages?

Not without knowing the topics, your use of wildcards and the error thrown!

Hahaha yes I should have expected that.

The subscribed to topic is
tele/thuis/bgg/tuinkamer/sensors/+
The wildcard translates to the subtopics SENSOR, LWT, INFO1, INFO2, INFO3, STATE and STATUS of which I want to use SENSOR and INFO2.

The function node has this code to extract temperature values

msg.payload = {
    "DateTime": msg.payload.Time,
    "Tr": msg.payload['DS18B20-1'].Temperature,
    "Ta": msg.payload['DS18B20-2'].Temperature,
    "Tk": msg.payload['DS18B20-3'].Temperature
};
msg.payload.Td =  parseFloat((msg.payload.Ta - msg.payload.Tr).toFixed(1));
return msg;

Since only the subtopic SENSOR contains this payload and there is no distiction between the messages of the subtopics, the others throw an error.
The SENSOR message results in something like this:

29-10-2024, 09:34:14[node: debug 9]
tele/thuis/bgg/tuinkamer/sensors/SENSOR : msg.payload : Object
object
DateTime: "2024-10-29T09:33:17"
Tr: 18.6
Ta: 18.6
Tk: 18.4
Td: 0

But the others (LWT, INFO1, INFO2, etc), repeated for every subtopic, all result in this:

29-10-2024, 09:34:14[node: Tr, Ta, Tk, Td]
function : (error)
"TypeError: Cannot read properties of undefined (reading 'Temperature')"

I tried a switch node to seperate the different messages based on msg.topic like this

but I can't get that to work.

Change the mqtt node to subscribe only to the topic you want.

Well, that would mean back to square one...

Remind me what was wrong with square one?

Edit: I meant change the subscription to tele/thuis/bgg/tuinkamer/sensors/SENSOR

Nothing wrong with square one @Colin but there'd be no progress if I'd stay there :slight_smile:

For a flexible solution I would ultimately like to use the room name that is part of the subscribed topic to serve as the zone name of a dashboard in a subflow. So if the subscribed topic is tele/thuis/bgg/tuinkamer/sensors/SENSOR, than tuinkamer is the room name that I need.

The subflow (for now) looks like this


The 'mqtt in' node is what's connected to that input.

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.

Also I tried @jbudd's suggestion for Tasmota's STATE properties but that requires a wildcard subscription that produces errors that I can't get rid of and of which you also say is not the right approach, I should subscribe to only one specific topic.

So at the moment I'm actually at a loss where you are trying to guide me with your comment of which I'm honestly thankful, call me dense if you want. If you could provide me with examples or documentation where to look for a solution for what I'm trying to achieve that would be much appreciated.

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.

And I'm uncertain if it's best to get sensor data from the automatic telemetry messages or to request it with eg a status 8 message, I probably do both. It especially matters if the sensor device uses deep sleep.

Telemetry arrives on topic
tele/tasmota/wemos/<Device_Name>/SENSOR

Sensor data arrives on
stat/tasmota/wemos/<Device_Name>/STATUS8

I might send cmd/tasmota/wemos/door/backlog and status; status 8;
I would subscribe to stat/tasmota/wemos/+/+ and then extract the relevant data from the two messages returned on stat/tasmota/wemos/Door/Status and stat/tasmota/wemos/Door/Status8.