# MQTT yields no results from 'status' or 'complete' nodes
**URL:** https://discourse.nodered.org/t/mqtt-yields-no-results-from-status-or-complete-nodes/81831
**Category:** General
**Created:** [6 October 2023 13:03 UTC](https://discourse.nodered.org/t/mqtt-yields-no-results-from-status-or-complete-nodes/81831 "2023-10-06T13:03:25Z")
**Posts on this page:** 17
**Page:** 1
### Author:  [@tree-frog](https://discourse.nodered.org/u/tree-frog)
#### Post date: [6 October 2023 13:03 UTC](https://discourse.nodered.org/t/mqtt-yields-no-results-from-status-or-complete-nodes/81831/1 "2023-10-06T13:03:25Z")
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."
---
### Author:  [@marcus-j-davies](https://discourse.nodered.org/u/marcus-j-davies)
#### Post date: [6 October 2023 13:10 UTC](https://discourse.nodered.org/t/mqtt-yields-no-results-from-status-or-complete-nodes/81831/2 "2023-10-06T13:10:19Z")
`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
---
### Author:  [@tree-frog](https://discourse.nodered.org/u/tree-frog)
#### Post date: [6 October 2023 13:15 UTC](https://discourse.nodered.org/t/mqtt-yields-no-results-from-status-or-complete-nodes/81831/3 "2023-10-06T13:15:20Z")
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...
---
### Author:  [@tree-frog](https://discourse.nodered.org/u/tree-frog)
#### Post date: [6 October 2023 13:18 UTC](https://discourse.nodered.org/t/mqtt-yields-no-results-from-status-or-complete-nodes/81831/4 "2023-10-06T13:18:15Z")
'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.
---
### Author:  [@marcus-j-davies](https://discourse.nodered.org/u/marcus-j-davies)
#### Post date: [6 October 2023 13:18 UTC](https://discourse.nodered.org/t/mqtt-yields-no-results-from-status-or-complete-nodes/81831/5 "2023-10-06T13:18:49Z")
The `complete` node, is only triggered when `done()` is called and is only applicable for messages here (image)
i.e in flow terms - you are not sending it a message directly - it only outputs a message from the MQTT Broker
This does not allow the opportunity for `done()` to be called
---
### Author:  [@tree-frog](https://discourse.nodered.org/u/tree-frog)
#### Post date: [6 October 2023 13:23 UTC](https://discourse.nodered.org/t/mqtt-yields-no-results-from-status-or-complete-nodes/81831/6 "2023-10-06T13:23:11Z")
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.
---
### Author:  [@Steve-Mcl](https://discourse.nodered.org/u/Steve-Mcl)
#### Post date: [6 October 2023 13:26 UTC](https://discourse.nodered.org/t/mqtt-yields-no-results-from-status-or-complete-nodes/81831/7 "2023-10-06T13:26:49Z")
> [@tree-frog](#):
>
> 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 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`
> [@tree-frog](#):
>
> For example when you get values from MQTT, there is no response on either 'status', or 'complete' nodes
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".
> [@tree-frog](#):
>
> 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,
If you want to know when an MQTT in node triggers (akin to "complete", attach a wire to its output!)
Or am I missing your point?
---
### Author:  [@tree-frog](https://discourse.nodered.org/u/tree-frog)
#### Post date: [6 October 2023 13:40 UTC](https://discourse.nodered.org/t/mqtt-yields-no-results-from-status-or-complete-nodes/81831/8 "2023-10-06T13:40:00Z")
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.
---
### Author:  [@Colin](https://discourse.nodered.org/u/Colin)
#### Post date: [6 October 2023 16:35 UTC](https://discourse.nodered.org/t/mqtt-yields-no-results-from-status-or-complete-nodes/81831/9 "2023-10-06T16:35:43Z")
> [@tree-frog](#):
>
> use the 'complete' for timing of data to this destination node
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.
---
### Author:  [@tree-frog](https://discourse.nodered.org/u/tree-frog)
#### Post date: [10 October 2023 23:17 UTC](https://discourse.nodered.org/t/mqtt-yields-no-results-from-status-or-complete-nodes/81831/10 "2023-10-10T23:17:01Z")
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".
---
### Author:  [@marcus-j-davies](https://discourse.nodered.org/u/marcus-j-davies)
#### Post date: [11 October 2023 07:22 UTC](https://discourse.nodered.org/t/mqtt-yields-no-results-from-status-or-complete-nodes/81831/11 "2023-10-11T07:22:14Z")
Just my 2c:
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
```js
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
```js
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?? 🤪
---
### Author:  [@Colin](https://discourse.nodered.org/u/Colin)
#### Post date: [11 October 2023 09:24 UTC](https://discourse.nodered.org/t/mqtt-yields-no-results-from-status-or-complete-nodes/81831/12 "2023-10-11T09:24:03Z")
> [@marcus-j-davies](#):
>
> Then use the subflow as your 'MQTT Output' Node
Did you mean MQTT Input?
---
### Author:  [@Colin](https://discourse.nodered.org/u/Colin)
#### Post date: [11 October 2023 09:26 UTC](https://discourse.nodered.org/t/mqtt-yields-no-results-from-status-or-complete-nodes/81831/13 "2023-10-11T09:26:57Z")
> [@tree-frog](#):
>
> 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
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?
---
### Author:  [@marcus-j-davies](https://discourse.nodered.org/u/marcus-j-davies)
#### Post date: [11 October 2023 09:43 UTC](https://discourse.nodered.org/t/mqtt-yields-no-results-from-status-or-complete-nodes/81831/14 "2023-10-11T09:43:22Z")
> [@Colin](#):
>
> Did you mean MQTT Input?
Indeed I did!
---
### Author:  [@tree-frog](https://discourse.nodered.org/u/tree-frog)
#### Post date: [12 October 2023 00:53 UTC](https://discourse.nodered.org/t/mqtt-yields-no-results-from-status-or-complete-nodes/81831/15 "2023-10-12T00:53:04Z")
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.
Thanks for the excersize and effort.
---
### Author:  [@tree-frog](https://discourse.nodered.org/u/tree-frog)
#### Post date: [13 October 2023 01:12 UTC](https://discourse.nodered.org/t/mqtt-yields-no-results-from-status-or-complete-nodes/81831/16 "2023-10-13T01:12:04Z")
> [@Colin](#):
>
> At what point do you consider that an MQTT In node becomes Started?
Ok I just found that I was referring to the MQTT Out and I meant the MQTT In Node. Thank you for the correction. MQTT Out Node can be monitored.
To answer your question, I'd think it would be on detection of the message that's processed. Right?
---
### Author:  [@system](https://discourse.nodered.org/u/system)
#### Post date: [27 October 2023 01:12 UTC](https://discourse.nodered.org/t/mqtt-yields-no-results-from-status-or-complete-nodes/81831/17 "2023-10-27T01:12:19Z")
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.