I need MQTT node that have input and output

The MQTT topic is continually listened (subscribed to) for inbound messages so if your device that is generating the MQTT message is continually sending then you will see updates in Node-Red - you can simply link the output of this node to the input of a MQTT send node and send it to a different topic if that is what you are trying to achieve


1 Like

First of all thanks a lot for all help... wonderful quick answers

So here is all story... actually I have this flow:

What is do now is:
-if the Tesla PowerWall battery chenge the percentage > it start the flow
-then is set some variable that arrive now from Home Assistant Tesla (car) integration service
-then controll the PowerWall batt. for % of charege, and check the PV solar production
-then check if the car is attached to the charger
-and if the PV production is more than 1 kWp, will start the Tesla charger (until 80%)

What I want to achieve is:
I just installed the TeslaMate application, that receive all data from Tesla Car
with more real time data and more better, and TeslaMate set all variable via MQTT topics.

I want to start the flow always like now... only when PowerWall batt.(not MQTT)
change the percentage... then go to a node that read all data from Tesla car (MQTT)
...then continue with the flow.

So I want to start the flow with something like this:

Or maybe can I read the MQTT topics inside a function flow ? with some code ?
...maybe too complicated...

Thanks all again

Well, the battery capacity node......

Hook that to a MQTT OUT node.

Then, what the batter capacity node sends out is then sent out on MQTT protocol.
Those messages are then received by the MQTT IN nodes.

1 Like

Feed all the tesla mqtt nodes into a Join node set to Manual mode and key/value pairs, and On Subsequent Messages set. Also feed into the Join node your battery capacity signal (with a different topic). Then any time any of the inputs changes it will send a message containing all of the input values, and the topic will be set to tell you which one changed. Then use a Switch node to let only the battery topic through. The output of that will be a message telling you the battery input has been received and the message will also contain all the tesla data, so you can fee that into your set vars function.


Simply set the topic of MQTT out to the same value as the MQTT in. Then each MQTT out is also received from MQTT In.


1 Like

Thanks a lot all guys... Colin give me an idea on how to solve this.

So I don't use a Join Node but all of thinks is go in a Function Node

We know that every time the MQTT topic will change, that will start the MOTT Node
...in that case in the function node I just change a flow variable in base of topic name.
And I make available all variables like this:

// is Tesla M3 on charge 
var M3OnCharge         =flow.get('M3OnCharge') || 0;
if (msg.topic=="teslamate/cars/1/charger_power")

But I will return message in output only if the topic is from battery capacity:

// when the powerwall_battery_capacity change, return the msg and start flow 
if (msg.topic=="sensor.powerwall_battery_capacity")
    var PWBattPercentage = flow.get('PWBattPercentage') || 0;
    // % level of PowerWall battery
    return msg;

Here is the test flow:

So now everything is work great... and I have all day to change all production flow :slight_smile:

Ii think this is the easy and funny programm laguage that I find in my 25 years of programmer.
In just 2 days a learn a lot of thinks and I can make a lot with it.
Thanks a lot all of you for great support and I'm glad to be member of this community :slight_smile:


I would use a Join node, let it do the heavy lifting rather than all that messing around with context. As always there are multiple valid solutions though.
If you have not already you might want to have the tesla topics Retained, so the initial values will be picked up if you restart node red.


Thanks a lot Colin,
but I prefer a classic and easy mode (I'm Cobol programmer)
cause in this mode in a few mount I'll understand what I have do :slight_smile:

The topics arrive from a Tesla Mate app. that make another person.
I don't know if is retained but in some secs the topics receive the fresh data.

Thanks a lot again

I agree with Colin here. I had to read your first post a couple times to understand exactly what you meant. At first I thought you were looking for some kind of passthrough, where you publish the data on an MQTT topic, and then use it for more things. It took a couple good reads to realise that you're looking to combine the "battery level changes" with "take latest MQTT data and do something with it".

You could indeed use a Join node, like Colin explained. I saw a gate node mentioned before, that might work too. I more or less understand your solution in post #9 of this topic, and if it works for you that's good, but I wouldn't advise this solution from a maintainer perspective. With a COBOL perspective, I understand this solution though, and I'll stop suggesting otherwise because with that background it's perfectly maintainable :slight_smile:

1 Like


Thanks a lot Felix... maybe with more time to dedicate I'll try also the Join Node,
cause for now it's litle complex to do in little time.

But... the just word it's yours "some kind of passthrough" ...yes...
I think that someone must make a node that can be passthrough
and inside can read a topic queue... special mode because it's MQTT
that we talking about... I found only 2 nodes :frowning:

Thanks a lot again

MQTT messages are not 'read' by the 'subscriber', the 'broker' sends them to all subscribers when a 'publisher' sends them to the 'broker'. So a pass thru MQTT node doesn't make any sense (to me).

Flows are triggered by some event - someone pressing a button, a node reading a sensor at certain times, a node seeing a file added to a directory, a message arriving at a mqtt-in node. It's not like Cobol where you run the program, open a input file, read the data and process it. Think of it as each flow being a little program that is run when an event occurs. That might make it easier to understand.

1 Like

A passthrough MQTT node would be like asking for an email node that receives an email when you tell it to. It cannot receive an email unless one is sent to it. Similarly MQTT cannot receive a message from the broker unless the broker sends it.

I suppose you could ask for an MQTT node that remembered the values for all the topics it is subscribed to and could send them to the flow when asked, but the potential overheads of that are huge. Remember you can subscribe with wildcards so a single MQTT node can effectively be subscribed to hundreds of topics. Would you want it to store the previous values of all those? MQTT is capable of handling large buffers so the overhead could be huge.
Plus, a Join node does it perfectly without having to write any code.

As an aside, you may be able to simplify your flow by subscribing to telamate/cars/1/#, possibly that would bring in additional topics, but if the rate is not high then it probably doesn't matter. You would not have to change your code (provided it is not confused by unwanted topics). On the other hand if there are 50 other values in addition to the ones you want then maybe not a good idea.


I'm not much of an agreement.. and I tell you why.
Yes... is true that "Flows are triggered by some event"... but if I want to be triggered by another node
and not by MQTT Node ? ...and when I have ben triggered I just want to read last topic value and just go on ? ...like in my case.

Cause my flow is triggered by the PowerWall battery percentage, when this change,
I just want to read last MQTT topic status in order to understand if the Tesla car
is connected and if maybe already in charge or not.
So I don't need MQTT trigger in this case but I only nedd to know the actual(last) status.

Anyway, because MQTT in my opinion it's important piece in Node-Red,
I think that a "pass thru" node, that just read the topic and then go on,
it's a must for future development... cause now there is just 2 poor node.
Just my cobol man opinion :slight_smile:

Anyway now all it's work thanks on your's advice.
Thanks a lot all

you can receive the message via MQTT and store it e.g. in a global variable
You can query and react to this variable at any time.



Exacly what I wanted: "ask for --> remember the value --> send them" = pass thru :slight_smile:

There is 42 values and some time it's send by broker every second (whan I drive)
so it's to much probably and I don't need them in this proj.

Thanks a lot

In the particular case which you have described here, if the node had provided that feature then what would that have saved in the solution you ended up with?

Just the code in the first Function Node:

...but if someone can make a pass thru node of MQTT,
maybe this node can receive more than one topic.

But I repeat... MQTT it's an important think in Node_Red, but have only 2 nodes :frowning:
Someone must invent something more :slight_smile:

Another think that I would like to see in MQTT Node is the log under the node icon like this one:

The MQTT Node show me just "connected" but not last topic arrive and mayve the value.

Thanks all

Does the mqtt in node support subflow variable as a topic? If it did, it'd be simple to create a subflow with these functionalities...

MQTT is not a request/response type of protocol. There is no way for an MQTT client to ask the broker for just one message from a topic. If the client wants to do that, it has to subscribe to the topic, wait until a message arrives and then unsubscribe. But nothing would stop the broker from sending 30 messages before the unsubscribe arrives and is processed.

So the more general pattern to use would be, as has been suggested, an MQTT In node subscribed to the topic you are interested in, saving the most recent value received into local context which you can access at any time.

Where there is a need for another MQTT node is to be able to dynamically subscribe to topics at runtime - where you can't hard code the topic into the node.

We do have a design for such a node and it is sat in the backlog until someone is interested enough to contribute to its implementation.


How much code would it have saved?

That would have to be optional. I have nodes that receive hundreds of messages a second. The overheads on the browser updating it would be onerous.

1 Like