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.
5 Likes
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
Thanks a lot for the answer.
I think anyway that the node know when (date) the topic was received and also know the topic value
So someone that make this 2 nodes just must put this info under the node... will be great.
Cause for now I must insert a debug node in order to know the last date and value has arrive.
Lock how wonderful can be 
I know that last topic is 58% and was received at 12:23.
Just a propose.
Thanks again
Denis
As @Colin points out there, as this is a general purpose node we have no idea of the message rate that it may be handling and we don't want to overwhelm the browser socket connection. The status is supposed to be an indication of the state of the node - NOT data passing through it (the editor is NOT a dashboard)... You can of course also show any status you like on a function node - so you could add that to the existing function node you had - thus making it doubly useful
2 Likes
I don't know, because in any case I must set something else other than variable
in that function:
var PWBattPercentage = flow.get('PWBattPercentage') || 0;
var PWBattPercentageBkp = flow.get('PWBattPercentageBkp') || 0;
var M3PluggetIn = flow.get('M3PluggetIn') || 0;
var PVProduction = flow.get('PVProduction') || 0;
var M3State = flow.get('M3State') || 0;
var M3BattPercentage = flow.get('M3BattPercentage') || 0;
var M3TimeToFull = flow.get('M3TimeToFull') || 0;
var M3FullCharge = flow.get('M3FullCharge') || 0;
var Run = flow.get('Run') || 0;
// receive all vars from Home Assistant ///////////
const globalHomeAssistant = global.get('homeassistant');
// photovoltaic production
flow.set('PVProduction',((globalHomeAssistant.homeAssistant.states["sensor.solar_now"].state) * 1000));
// MQTT from Tesla Mate /////////////////////////
// is Tesla M3 plugget in
if (msg.topic=="teslamate/cars/1/plugged_in"){
flow.set('M3PluggetIn',msg.payload)
}
// state of Tesla M3 (charging/online/suspended)
if (msg.topic=="teslamate/cars/1/state"){
if (msg.payload == "charging") {
flow.set('M3State',"charging");
}
else {
flow.set('M3State',"stopped");
}
}
// % level of Tesla M3 battery
if (msg.topic=="teslamate/cars/1/battery_level"){
flow.set('M3BattPercentage',msg.payload)
}
// time to full charge of Tesla M3 battery (not used)
if (msg.topic=="teslamate/cars/1/time_to_full_charge"){
flow.set('M3TimeToFull',msg.payload)
}
// when flow start = 1 when flow finish = 0 (reason google assistant tts)
flow.set('Run',1);
// conditions that make the flow go on (return msg;)
// when the switch full charge=1 arrive from HASSIO, start flow
if (msg.topic=="teslamate/cars/1/hass_force_full_charge"){
if (msg.payload == "1") {
flow.set('M3FullCharge',"1");
flow.set('PWBattPercentage',999);
}
else {
flow.set('M3FullCharge',"0");
}
return msg;
}
// when the powerwall_battery_capacity change, return the msg and start flow
if (msg.topic=="sensor.powerwall_battery_capacity"){
if (flow.get('M3FullCharge') == "0" ){ //only if full charge is not request
// % level of PowerWall battery
flow.set('PWBattPercentage',msg.payload);
return msg;
}
flow.set('PWBattPercentageBkp',msg.payload);
}
Of course... just need a flag in order to set it if you want it or not
Yeah... but for me(and maybe for other) can be very comfortable.
That data arrive anyway, so you can decide if you want to see it or not with just a flag.
Other useful MQTT node can be one that can receive more that one topic
and can set an msg. , flow. global. etc... variable.
Ii repeat... my disappointment when first time I search a MQTT node, was to see
that there is only 2 nodes. Just my point of view because I like a lot Node-Red.
Thanks all
Denis
I don't think having the pass through would have saved any code at all.
However, using a Join node would save about 35 lines of (executable) code I think, so I know where my vote lies.
2 Likes
I'm near to finish first part of automation
But I promis I'll learn it and I'll use it (Join node) when after finish I will have time 
Thanks a lot for all
Denis
1 Like
Denis,
I think you are maybe misunderstanding some of the core philosophy of Node-red. The basic idea is that nodes are specialised at doing a single task (slim and trim) and can do it quickly and with little overhead. So adding more and more functionality to a specialised node to meet edge cases does not make a lot of sense - instead the idea is to allow you to link these specialised nodes together to achieve the desired result - or write your own specific code in a Function Node to achieve your results.
Why mess with the MQTT node when you can just link to a debug node and have it display the output as a status message as you request ?
Craig
2 Likes
Cause I think is much more comfortable to see it directly under the node VS
search it in the debug panel.
Denis
Yep and then someone else would prefer to see it on top of the node - someone else wants the node to also tell the time the message comes in etc etc - feature creep.
But if you want it so badly - you can write your own custom node - again the beauty of NR
Craig
1 Like
In the post #24 you can se that someone already make some nodes with the log under the node.
I just talk about the MQTT nodes.
The MQTT, as important part in Node-Red, in my opinion need more nodes.
For example, a pass thru node, a node with possibility to receive more that just one topic, node that can move the result in a variable, node with more info and non just status... etc
Then... if someone want to use it use it... if didn't want, can use just the 2 nodes that actual exist.
For example my "battery capacity" arrive from Home Assistant and i see the % in half second
on the flow under the node if I need to understand this data now,
the "plugged in status" arrive from MQTT and I need to read a lot of debug log in order to find it.
Well I prefer the first method... the one of half second time.
The Node-Red grow a lot in the last period, MQTT also... so implements some other feature,
can help someone that make thinks easy... maybe at home and not on industrial scale.
This is just my opinion.
Denis
That homeassistant makes the choice to use the node status for that does not mean that it is immediately a best practice and all other nodes should do too. Keep in mind that the homeassistant nodes are 3rd party plugins to node-red (contrib nodes), while the mqtt nodes arenāt just maintained by the core team, theyāre considered core nodes and included on every single installation of node-red by default.
@denisjoshua - you might want to take a little time and read about MQTT. There is a great series of posts giving an overview of it at hivemq.com. Here is a link to the first of a 10 part series Introducing the MQTT Protocol ā MQTT Essentials: Part 1
For example my "battery capacity" arrive from Home Assistant and i see the % in half second on the flow under the node if I need to understand this data now
Remember what @dceejay said 'the editor is NOT a dashboard' if you send that value to a dashboard you will see it uncluttered from the other items in the flow.
If you need to check it when editing the flow, send it to a debug node and ti will show up in the sidebar.
2 Likes
At the risk of going slightly offtopic, as a comparison, hereās how the Deconzā zigbee nodes handle this.
When a message comes in it shows a status āeventā for a couple seconds. That way you know an event occurred (state of the node, think of it like a state machine), but to read it out you connect a debug node to the output, with a name, so that when it shows up in the debug toolbar you know what it belongs to.
And, as Paul says above me, do yourself a favour and read the first couple parts of the mqtt guide linked. Especially the theory at first (and origin/initial usage) shows that MQTT has a broker where messages are published to by clients (mqtt-out node), and clients can subscribe to these messages (mqtt-in) to be alerted of those messages with an event coming out once the broker receives them from a sender. Within that concept, you canāt ask for the most recent message [to other readers Iām not touching retained topics here]. A message, an event really, comes out of those nodes when they happen.
From a COBOL point of view I understand your thinking and your request, but just like COBOL is hardly comparable to other languages and concepts, Node-RED uses the process and concept of flow/event based working. It means that rather than the strict i/o and calling functions and procedures (I still think in my first language Pascal too), you act on events that come in. Itās a different way of thinking and of programming, and it does take a bit of time to get used to. The key thing here is that rather than force your tooling into the thinking and concepts youāre used to, to utilise the tooling to your needs as best as you can. When you name debug nodes, you can keep a good debugging/logging going on in the sidebar. If you set the ālog to system consoleā flag on that debug node, it will also log to the console, which could for example be piped into a file for logging.
With that Pascal perspective in mind, my flows started out the exact same way. The join node, mentioned by Colin above, is far more powerful than I thought at first glance. If you set up your messages with distinct topics (which happens with different mqtt-in nodes), and take a look at what the join node says in the help in the sidebar. It could do this job pretty well.
Another idea worth looking at are gate node(s) mentioned earlier. With those you could push your mqtt events into a gate that blocks until it opens, by for example your battery event from the first node. Itās the beauty of node-red to me: thereās different ways to solve a problem, and not one is most correct. Some do fit best practices better than others. Iām not saying your solution is wrong or bad. Who am I to even tell you that, after all. What I do ask is to look at other offered suggestions too. You donāt have to take them up as your own, but understanding what they do/how they work might help on the long term. You will be the person who has to maintain these flows you create. However, it does help to be able to think in the concept of flow/event based programming, which is truly a whole new world when coming from the old programming languages from the 50s and 60s.
The changes/additions youāre asking for are unlikely to be implemented in existing nodes, especially those in the core, as they go against the event based principles (and with Nick on the standards committee for mqtt, unlikely to be added either way) That doesnāt mean others canāt implement it in contrib nodes of their own: thereās no vetting process going on for what is being added to the palette to install.
4 Likes
You can actually set the debug node to only show the last received msg (up to 32 characters) and not send anything to the debug tab. I actually use this quite a lot when testing to quickly see whats going on.
4 Likes
I often use that in a function node.
msg. payload is displayed for 30 seconds.
the length of the status line is not limited to 32 characters.
Holger
setTimeout(function() {
// Code that is only executed after 30 seconds
node.status({fill:'gray',text:''});
}, 30000);
node.status({fill:'green',text:msg.payload});
return msg;
4 Likes
I actually quite like that the last status stays there even if the nodered editor wasnāt open. I used it in function nodes before but why reinvent the wheel when its so easy with the debug node. If i want to see something thats longer than those 32 characters i actually use something like flogger as i find my statuses to crowded otherwise.
1 Like
Sorry guys... who talk about how is work MQTT ?
I just talk about the missing MQTT nodes in Node-Red.
I know how MQTT work...
I'm programmer from '95 and I also work on IBM iSeries WebSphere MQ Telemetry
and MQTT for more than 10-15 years.
But I use Node-Red only from begining of this week.
I just write about too poor nodes for MQTT
But because I don't like to repeat thinks
is better if I finish here this post.
Thanks you all for the help.
Denis
1 Like
@denisjoshua I don't want to sound rude (English isn't my first language) but your posts gave me the idea that you didn't fully grasps the basic of MQTT.
MQTT is a pub/sub protocol and trying to integrate it with a passthrough looks like a more traditional client/server approach where the client can connect to a server and ask for something. This is generally not the case with MQTT where data are not stored in the server. Even with the retain flag a subscriber read that value only when it subscribe, it didn't keep reading the same value and it can't ask the server.
This is why your flow should have multiple input joined together. Sure, you can do it in many ways but many of those ways are actually antipattern.
