Pass a payload via the status framework

[ThorbenJ]

Hi.

I've created some nodes that provide detailed status information via a second output. However it seemed to me that it might be nicer if I used the existing status framework:

this.status({fill:"red",shape:"ring",text:"disconnected"});
this.status({fill:"green",shape:"dot",text:"connected"});

and the status node under node-red.

The problem is, it does not seem to be possible to pass any extra information.

I thought it might nice if this.status() had an optional second argument payload, and the status node would then place that in msg.payload.

Where error is the error object of some operation:

this.status(
  {fill:"red",shape:"ring",text:"authentication failed"},
  {info:"further operation details",error:error}
);

The status node could then emit:

{
  status:{ text:"authentication failed", source:{ type: "", id: "", name: "" }
  payload:{ info: "further operation details", error: {...} }
}

The graphical part of the status feature would ignore payload - this would be just a way to pass information from the source node to any attached status nodes.

I did try to search this forum, and I did not see anything that appeared to have discussed this. Also it appears feature requests are not welcome via GH issues.

[knolleary]

Hi @ThorbenJ

thanks for raising this.

I seem to remember there was a previous conversation around being able to include more properties in the status object. Although I don't believe it resulted in anything being done.

Without finding that discussion, and not remembering the specifics of what was said at the time, I suggest an approach that is consistent with the node.error(...) api; accept an optional second argument to be a full msg object that gets sent by the Status node (with the msg.status property added).

I think that would be clearer and not limit to just setting msg.payload.

If that sounds sensible (@dceejay) we can raise an issue to get it onto the backlog to get done.

[bakman2]

Would the message then both go to status and catch ?
I would expect an "error" to be catched by the catch node.

[knolleary]

Hi @bakman2

Perhaps I wasn't as clear as I could be. I'm am only suggesting that the style of the node.status() api be consistent with the node.error() api in terms of being able to provide a message to be sent.

I am not saying that node.error() should do anything with the Status node, nor the other way around.

[drmibell]

I have a mild objection to this. Consistency with the node.error() API is reasonable, but I have some concern that node.status() could be (ab)used to create invisible ("wireless") communication between nodes for all sorts of messages, something we have discussed in the past. Granted, node.error() probably could be used in the same way, and we haven't yet seen much of that. At the very least, the documentation should say a few words to discourage the practice.

[dceejay]

Not sure why it would be any more abused than node.error - It would be caught by status nodes so I suppose it could but seems rather clunky as the status node wouldn't just pass on that msg - it would be a sub-property. I thin kaligning it with node.error api makes sense.

Just need to make sure the extra msg part doesn't get sent to the editor.

[drmibell]

@dceejay

as the status node wouldn't just pass on that msg - it would be a sub-property.

Almost, but not quite. This flow passes the incoming payload to the output of the catch node with no fuss.

[{"id":"a9afe08da7ef07c6","type":"function","z":"424965709c0ff25f","name":"","func":"node.error(\"my error message\", msg);\nreturn msg;","outputs":1,"noerr":0,"initialize":"","finalize":"","libs":[],"x":460,"y":140,"wires":[[]]},{"id":"d56b8d3149b0de81","type":"catch","z":"424965709c0ff25f","name":"","scope":["a9afe08da7ef07c6"],"uncaught":false,"x":450,"y":200,"wires":[["ffdb1a878615d90c"]]},{"id":"ffdb1a878615d90c","type":"debug","z":"424965709c0ff25f","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":610,"y":200,"wires":[]},{"id":"ad5721bf5c957463","type":"inject","z":"424965709c0ff25f","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":300,"y":140,"wires":[["a9afe08da7ef07c6"]]}]

Not a big deal, but still interesting. I assume the modified node.status() and status node would do the same.