All,
This suggestion may seem a bit odd, but please bear with me. I have a couple of projects that make heavy use of node.status displays in the editor and status messages caught by status nodes and shown in the dashboard. I have been looking for a way to generate arbitrary status messages in the middle of a flow. So far, only the function and bigstatus nodes have worked for me, but both have drawbacks that would take too much space to describe here. The change node has access to the flow and global context variables and the processing power of the JSONata language, so these features can be used "for free" in generating a status object. Only a couple of lines of code are needed to display the status (msg.status), without (I believe) breaking existing flows. This may violate the "do one thing well" principle, but the change node is already something of a "Swiss Army knife," and I think the feature would be useful. Any thoughts?
Mike
I disagree that it is a Swiss Army Knife node - it has a well defined purpose of modifying msg/context properties. It provides a variety of ways of doing it, but that is the thing it does well.
I don't think getting it to display a status message fits with that role. You can use the Debug node to display status messages.
1 Like
@knolleary,
I understand (and sort of anticipated) your reaction. No offense meant to the change node. The modification is so simple that I think I will keep it in a local copy of NR for a while for experimentation. Thanks for taking a look at my suggestion.
Using the debug node seems to be a non-starter here. As far as I can tell, it displays only the msg.payload text, with no control of the icon shape or fill. A function or change node would still be needed in front of it to do any necessary logic on the message and/or context in order to generate, for example, an error or warning message. Finally, to preserve the result of that logic as part of the message, the node doing the processing needs to be in the flow, not in a side branch with the debug node. When I first looked at this approach, I ended up doing the processing in a function node and having it use node.status to display the status, avoiding the debug node altogether.
Mike
in the debug node you can choose to display the complete msg object, or any specific part of the msg, like msg.topic or anything else that has been added to the msg object.
@zenofmud Understood, but Nick and I are talking about displaying the status in the editor widow, not the debug window (sidebar). This option is a checkbox labeled "node status (32 characters)" that appears only when the output is selected to be a message property, not the complete object.
One of the core project tenets is that the editor is not a dashboard.
You say you are then using the status node to catch those messages (good) - but that only gets the "payload" part and not the shape or colour either - so debug would be just as good as that.
@zenofmud - If you select complete message you don't get the option of status as it's (deliberately) limited to 32 chars and you can't really stick much of the default object into 32 chars.
But yes you can select any property to hook the debug to to show any particular property - not just payload.
However - I would like to understand why the function node is inadequate for this purpose - don't worry about space... we have plenty here... 
One of the core project tenets is that the editor is not a dashboard.
Got it. I often develop flows on a small laptop screen with the sidebar hidden. It is nice to have status indicators on nodes like http, file i/o, serial, etc. to help see what is happening during testing.
Yes exactly. They are indeed meant for that, to show the status of the node, like connection state, in error, depth of queue, etc. Not really meant for displaying things like value of payload etc.
So, what's wrong with function node for this ?
The function node is fine up to a point, and you'll soon see why I feel a bit foolish mentioning it. If I edit the flow and redeploy it, all the function status indicators disappear, making it harder to compare new results with old ones. Of course, this is the proper behavior, as we discussed some time ago ([https://groups.google.com/d/msg/node-red/NB7A107PpU0/t6K_uRl8BgAJ]). In a custom node or my modification of the change node, I can preserve the display between deployments.
and if you set the deploy mode to be "modified nodes" only then the function nodes shouldn't change either.... (as long as that works for the rest of your flow :-).... (unless you modify them of course)
@dceejay You're right, of course. Problem solved -- except for a slight preference for changing properties as opposed to writing JavaScript. I'll get over it.
Mike
What I'd really like to see in the future is the ability to add a "watchpoint" to a wire in between nodes to allow temporary debugging. What I dislike about debug nodes is they clutter the workspace a lot...
1 Like
That's a good use for the library. You can save your nice, standard status display in the library as a template and reuse it really easily.
