EDIT: 'status' worked when I shut down Mosquitto MQTT broker. So, 'status' node confirmed OK.
'complete' does not work as I had expected. It needs a in/out pair to start/complete. This is not based on just sending messages. Consider making an option or signal to the user a symbol by the node that these will/will not complete based on what they are. OR setting to allow them to 'complete' by the output send() vs. done(), in order to use this for this purpose vs. adding code for the same reasons.
First, are 'status', 'complete' on the way to deprecated?
Why do not all of the default nodes have hooks to other default node properties and methods? It seems that this may be an oversight, or by design?
For example when you get values from MQTT, there is no response on either 'status', or 'complete' nodes. Can someone explain if, why this does not work as expected and if it needs to be completed to work with the "standard"?
It would reasonable expect that 'MQTT in' node to trigger the 'complete' node (being configured to it) such that when you get a value. Also, because it shows connected/disconnected, then that is a "Status".... If not, where in the documentation is it noted what default nodes do/do not work with 'status', 'complete', 'catch' nodes?
"Not all nodes will trigger this event - it will depend on whether they have been implemented to support this feature as introduced in Node-RED 1.0."
Status
Does the MQTT status change from "connected" ? - as the status node listens for changes there.
Complete
It would reasonable expect that 'MQTT in' node to trigger the 'complete' node
Not quite!
If I am not mistaken - you are not sending messages to the MQTT node
(it may output, but not process a message for you) - therefore it has nothing to "complete"
The complete node is triggered when a node receives a message on it's input, and calls done() internally
Why would you assume that there is nothing actually ending up to the MQTT in node for this question?
Of course, I'm sending a value through MQTT. The process as I would expect it to work is based on the sending of the message from the node which it is tied...
'status' may work as you say. I have not seen it respond. I'll try to shut down Mosquitto to see.
'complete' is not triggering on messages sent from this MQTT node.
So you are saying that the MQTT, for example will never trigger 'complete'. I'd need to configure a function node to pass a value, or just duplicate the MQTT node to satisfy the message deliver vs. actually getting a status/complete from the node itself.
For some nodes, it makes no sense (so yes, it was a design descision)
Also, each node has to implement the done feature - so while many newer nodes and most core nodes (where applicable) support complete node, you will still have issues with nodes that have not been updated or deliberately don't support done
you WILL get something from the status node IF the status changes - that is by design. Since the connection is stable - no status changes & the status node is NOT triggered!
As for triggering the complete node - based on what I know of the internals etc - can safely guess it did not make sense here as the node is not receiving a msg from another node, processing the msg, then sending it on. Instead, the MQTT node receives many messages, at random times, from a broker (completely async to node-red) - in what context would "complete" mean complete? An MQTT In node is technically "never complete".
If you want to know when an MQTT in node triggers (akin to "complete", attach a wire to its output!)
The purpose I envisioned was simply to use the 'complete' for timing of data to this destination node. I then connected a do-nothing function and monitored it instead. This duplicates the payload and will serve as timing, but it was not what I had expected. I fully expected (not being right or wrong) that I should get a message on event from the node itself. So I cannot monitor directly, but need to look at another function or downstream node to monitor... this is not intuitive, not wrong necessarily.
From the node-red perspective MQTT In is not a destination node, it is a source node. It creates messages based on external input from the MQTT broker.
There is no node red link between an MQTT Out and an MQTT In. The Out node publishes data to the broker. The In node subscribes to topics on the broker.
The broker may not be in the same machine as node red, and the s/w publishing data may be node red in a third machine but is commonly something like a sensor publishing temperature data to the broker.
Collin,
Yes, absoluetely! comprende! And I do understand that there was a certain point of view regarding the "Complete" node.
The function node can be measured "complete", it has has input, then output. MQTT node also has a local input irregardless of the source of the message. It arguably has a local input... from the broker. It has a local input point passed to it from the broker. Then, as any other node, it should be able to be monitored for "complete"'. The node on the page is the context in every example which "complete" works, NOT the message. The MQTT Out node has a monitor bubble for status. "connected", "disconnected". Logically, if it is "connected", then of course, it has an input... it is even telling you that by the status bubble!
It is a straw man argument to say it should not be able to be monitored just because it's source is coming from other places. Even the Link node which has its source possibly from other flows can be monitored successfully with "complete".
The complete node is based on the premise that a node will call done()
At this time, this method is only applicable for the portion of a node that handles pin inputs.
I'm not a core developer for the project - but this potentially is a huge structural change
self.on('input',(msg, send, done) => {
// do stuff, pass on msg
done()
})
However, you can emulate it maybe?
using a subflow, that has the MQTT client inside, and a function node
node.send(msg) // original MQTT client output
node.done()
This will
Forward the MQTT message as normal
Trigger the complete node
Then use the subflow as your 'MQTT Output' Node
EDIT:
Mmm - it may not actually, as the function node will trigger it for a local complete node inside the subflow??
Implicit in the concept of Complete is that of Started. For a node that has an input and an output it becomes Started when it receives a message, and Complete when it has finished processing that message. For an MQTT Out node it starts processing the message when it is passed in, and becomes Complete when it has passed it to the broker. At what point do you consider that an MQTT In node becomes Started?
Marcus,
I totally get that it works the way that it works. That is not my argument. And it's just a perspective. The "argument" is not complicated. You have a NODE xyz. You want to know when node xyz completes, or does what it does. send a value, get a message and pass it on. Just like all the other nodes that you can evaluate using "complete". Very simple.
Now, because it does not use a certain function "done()" or have a wired input it does not work that way. OK sure! The argument is not one which you or anyone need to accomodate. It's just an argument for having the nodes work the same way and not have indescriminant nodes not able to be monitored or whathaveyou. It's not that bad that you cannot monitor it with "complete". It's OK. But... Why the heck not? It's a node! yeah, yeah, read the aforementioned reasoning..
And, now knowing that MQTT Out does not respond, I can then attach it to any node except it in series for the same effect or purpose.
