OK - so no need for any timeouts then ? If it can't be in two states at once (unless it's quantum), then the node is still in warning state. Nothing will clear that as it's just a warning - (it's still connected and working for example) - and so the node should show that forever until it does move to another state.
I have understood the proposal the following way:
- If a status is set without the additional duration parameter, it is additionally stored in a permanent value
- If a status is set with the additional duration parameter, then the status is changed to the temporary status until the timeout, on which it is reverted to the stored permanent value
- If during a timeout a new permanent status is received, the temporary timeout is cleared and the status is switched immediately to the new permanent status
- If during a timeout a new temporary status is received, the old temporary timeout is cleared and the status is switched immediately to the new temporary status. If that times out, the status is reverted to the stored permanent value
- In all cases, a change to the status will trigger the status node to not introduce exceptions from the rule.
I do see the argument of not triggering the status node if it switches back to the stored permanent value.
For example, I use the status node to trigger things if a node changes its status to connected, which could involve resource heavy things. It sometimes would be cool to still being able to change the status e.g. to indicate "msg processed" or something, which would be temporary, and then if it is reverted back to "connected", I don't want to trigger the connected flow again.
Maybe adding a flag into the message indicating that it goes back to an stored value.
Honestly, after writing all that, maybe it is better to have boilerplate code in custom nodes for that....
I believe you meant to say "new temporary status"?
edited 
I like your summary! But it would be nice to get a consensus here for a general solution. Just to make sure that e.g. the interaction with Status node is done correctly, without me (as a node developer) having to think about that over and over again ...
Just thought that a numbered list of steps would make it more clear... Will rephrase it in plain text: after the specified interval, the last known "non-temporary" status should be set again. Is that correct? Then I can easily use scenario 2 to return to my original "connected" status afterwards, without having to specify a second status object...
Based on the tips I received today, I updated my code snippet to allow an optional duration parameter in the (temporary) status object:
node.status({fill:"yellow",shape:"dot",text:"temporary status", duration:2});
Which solves everything for 'my' orignal use case:
1 Like
Scenario 1 & 2 get my vote, however not a supporter of scenario 3 (as updated). The node status should reflect the 'actual' status, and not assume that it's returned to its original status by a duration timeout.
IMO, the flow should determine the status message.
1 Like
I would see the use case to visually indicate something occurred that's unrelated to let's say a "connected" status.
1 Like
Hi Bart - while th NR powers-that-be argue this out, did you happen to put your modified nodejs file anywhere so interested parties can hava a play at their own risk?
Hello Peter,
I'm afraid the NR powers are busy with other more critical beta-related stuff at the moment 
So the discussion will need to be finished, before I can continue with a pull request...
Not sure whether it has much use to share my code at this moment, when you don't know whether this feature will be accepted anyway ...
If I remember correctly, the main problem is how to deal with temporary messages intercepted by the Status node:
- You could say that the Status node has to report every status change.
- On the other hand not all use cases might have interest in those temporary messages. Like in Dave's example: if a device has status "connected", you might not be interested if it temporarily switches to another status (and afterwards it returns back to "connected").
I can understand both arguments...
So I have tried tonight to find a compromise, in an attempt to please both parties.
I now 'generate' (behind the scenes) a boolean property temporary in the status object:
This property is true for all temporary status objects, and also when the original status will be restored (because that status was already available at the start, so it is not really a new status):
- A node sets its status to "connected" => status.temporary will be
false - That node sets its status temporary to "warning" => status.temporary will be
true - After timeout the original status "connected" will be set => status.temporary will be
true
So when you would not interested in those temporary statuses in their flows, you can ignore them (based on the new status property):
And to avoid everybody having to add those switch nodes, I have also have added a new checkbox to the Status node (similar as in the Catch node):
Then the flows keep clean, and that works fine ...
Hopefully you like this new concept. Fingers crossed ...
[EDIT] For everybody against the concept of temporary statuses: node developers already offer temporary statuses (by using timers themselves), but you cannot handle them now in the core (e.g. in the Status node). So I would be very disappointed if the whole idea would be send to the garbage bin here ...
Ugh! Adding more non-obvious optional checkboxes is even worse..
I can just about get with having the optional duration property, but as I said I think it should be then handled by CSS transition browser side to revert it back. If the node designer wants to send a "warning removed" status they can do as per today and send two messages.
I am still wary of what temporary means though. What is the maximum duration of a temporary message ? 10 seconds ? A minute ? An hour ? Too long and it may as well be permanent. Too short and it may not be there when I next look at that tab...
2 Likes
Bart, can you explain/show a practical use case, step by step, where this addition would be useful? Again, it can be done by having your custom node send out a status, change the status, then emit the old status again. What would be a practical use case combined with the status node? So far Iâve only seen several abstract examples, or showing connecting status (but really should that be displayed in the editor beyond connected/disconnected/error), but why have temporary status that could be ignorable? If itâs ignorable, imo it shouldnât be important enough to display in the editor in the first place.
What would be a practical use case of a temporary status that should/shouldnât be ignored by the status node, and whatâs stopping node developers from adding a second output port for status messages like that?
1 Like
Where I see it being useful...
A node thats normal state is something like "idle". then when a message arrives, you want to indicate something happened (temporarily) but ultimately, you are interested in the idle state.
Another - I wrote a subflow that works like a FIFO. Ordinarily I want the count displayed however when a message is pushed/shifted/popped/etc I want to display that operation or the data momentarily in the status (to make sure stuff is working visually without looking through debug messages) however normally I want the count visible.
In Bart's original intention of having a go-to status (after delay) I thought was useful for things like ...
{Action} - [delay] - (state)
E.g ...
{sent record 7} [delay 5s] (12 records remain)
2 Likes
My two cents worth on this is that I use "boiler plate" Blockly code to this a fair amount e.g
and then modify it as required to sometimes leave info in the status (such as time of last event).
So the basic premise of modifying the node status to have a time out and second status would save having to create the timer myself.
I don't catch status updates so don't know about the ramifications of that
That indeed makes sense if you always want to ignore them in the Status-node. But I understood from the above discussion that the Status-node should receive all status changes. Therefore I added the checkbox so users can decide themselves (case by case, node by node ...) whether they want to have the temporary messages...
But I'm not familiar enough with CSS to implement that.
That is indeed a good question!! For me the time should be short, like e.g. 5 seconds.
But I'm not sure whether we will ever find an optimal value ...
For example, my Onvif node shows that the camera is "connected". But then I press an Inject-node button to inject a control message e.g. to change the resolution. But that fails (e.g. to incorrect payload content) so I want to show temporarily an error "invalid input msg". But I don't want to have that error status still being displayed after 3 days, because the current status is still "connected".
I have always done that in the past, but get lots of feedback from users using the Status-node. I don't use the Status-node myself in my flows, but I have adapted my thinking to the community ...
In this specific use case, I would personally consider "invalid input msg" to be more pressing to keep as status than the connection status. The status might be static, but if the user supplies incorrect input payload that should either be reported on node.error so that (optionally) the error node can catch it, and it should be logged properly to the maintainer of the flow so that they can make sure that the error is resolved. To be perfectly honest, I don't consider errors like those a status, as intercepting/acting on them should be handled not through the status nodes but as error, like it is. After all, that's what the error node/node.error handling is meant for.
I meant here to use a secondary output for actual temporary status messages, not errors as described above. Have anything that shouldn't be displayed for longer time be outputted as message on that port, and errors raised the proper way. I do use the status node for specific situations, such as executing longer running processes and using the status to get the PID out or checking if it has started so I can then interact with the process, or sending confirmations back that the process has started/stopped.
What would be the practical usage of having the status node getting a checkbox to ignore temporary messages, when one of the apparent goals of this proposal is to allow those temporary statuses to be used in combination with a status node?
Hey Lena,
Thanks for your valuable input! That indeed also makes sense!
Anyway I give up on this feature request. Had really hoped it would be a quick win, but only has cost me a lot of free time. Since I have very little free time left in these Corona days, I consider it case closed for me. Thanks a lot for everybody who has contributed to this discussion, because I learned a lot from all the feedback!!!!!
3 Likes
... is that a temporary or permanent status ??? 
(Apologies Bart. I couldnât resist)
3 Likes
Permanent with a duration of 2 days !!! 
(Apologies Dave. I couldnât resist)
5 Likes
Hi,
I noticed the whole thread was based on new âsolutionsâ to be implemented. I wasnt able to catch the actual user-story.
âAs a node-red flows designer, iâd like the option to provide temporary messages on top of the nodes, so that i can analyze whats happening throughout the flow while its runningâ
- Dont have to use the current status logic because status is actually a different use case
- Existing node.warn() mechanism is not covering the need because its very difficult to follow along on a long list of messages while it is much easier to follow the messages on top of the visually organized flow editor
- Because this need is not covered people are trying to hack status mechanism
I hope this adds value to the conversation,
