I need MQTT node that have input and output

[denisjoshua]

I there all,
I so there is MQTT node that cab be used to input and the other one that can be used like output.
But how can I use a MQTT node that have also input and also output please ?
I wonder how can I use a node-red node that can read a MQTT topic but can be called from another node
Like this samle:

So when the battery capacity change, then continue to read the MQTT topic
Is this possible please ?

Thanks a lot
Denis

[craigcurtin]

Explain what your end result is that you would like to achieve ?

THe MQTT input would presumably come from the Inverter and would be some sort of updating message that the car was charging and the percentage ?

Craig

[Trying_to_learn]

@denisjoshua

I so there is MQTT node that cab be used to input and the other one that can be used like output

Yes.

There are two MQTT nodes. One is in and the other is out.

[craigcurtin]

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

Craig

[denisjoshua]

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
Denis

[Trying_to_learn]

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.

[Colin]

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.

[howl]

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.

Holger

[denisjoshua]

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")
{
    flow.set('M3OnCharge',msg.payload)
}

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
    flow.set('PWBattPercentage',msg.payload);
    return msg;
}

Here is the test flow:

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

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
Denis

[Colin]

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.

[denisjoshua]

@Colin

I would use a Join node, let it do the heavy lifting

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

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
Denis

[afelix]

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

[denisjoshua]

@afelix

With a COBOL perspective, I understand this solution though

:-))))))))))))))

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

Thanks a lot again
Denis

[zenofmud]

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.

[Colin]

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.

[denisjoshua]

@zenofmud

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

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

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

[howl]

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.

Holger

[denisjoshua]

@Colin

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

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

@Colin

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

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
Denis

[Colin]

@denisjoshua

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

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?

[denisjoshua]

@Colin

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
Someone must invent something more

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