Getting the initial status of nodes

From my experience, the status node reads other node statuses upon change and does not reflect the initial state.

For example, if the MQTT node connects upon deployment, the status is not pushed:

Then, if I stop and restart the MQTT broker, I get the statuses:

Similarly, with the state machine node. Upon deployment it enters the initial state, but status node does not reflect that:

On the first and subsequent state changes, status generates a message.

[{"id":"28d3a864.2ba658","type":"state-machine","z":"ea7ceec7.99905","name":"","triggerProperty":"payload","triggerPropertyType":"msg","stateProperty":"topic","statePropertyType":"msg","outputStateChangeOnly":true,"throwException":true,"states":["initial","state1","state2"],"transitions":[{"name":"go to state 1","from":"*","to":"state1"},{"name":"go to state 2","from":"*","to":"state2"}],"x":200,"y":80,"wires":[["726cb4c2.7b2fac"]]},{"id":"726cb4c2.7b2fac","type":"switch","z":"ea7ceec7.99905","name":"","property":"topic","propertyType":"msg","rules":[{"t":"eq","v":"initial","vt":"str"},{"t":"eq","v":"state1","vt":"str"},{"t":"eq","v":"state2","vt":"str"}],"checkall":"true","repair":false,"outputs":3,"x":370,"y":80,"wires":[["73ca5b46.c76904"],["4fe2533d.d71afc"],["73ca5b46.c76904"]]},{"id":"a2bb1e76.ef576","type":"link in","z":"ea7ceec7.99905","name":"New State","links":["aa121696.6d6be8"],"x":75,"y":80,"wires":[["28d3a864.2ba658"]]},{"id":"73ca5b46.c76904","type":"delay","z":"ea7ceec7.99905","name":"","pauseType":"delay","timeout":"5","timeoutUnits":"seconds","rate":"1","nbRateUnits":"1","rateUnits":"second","randomFirst":"1","randomLast":"5","randomUnits":"seconds","drop":false,"x":560,"y":60,"wires":[["ba0b31a8.f7d7e"]]},{"id":"4fe2533d.d71afc","type":"delay","z":"ea7ceec7.99905","name":"","pauseType":"delay","timeout":"5","timeoutUnits":"seconds","rate":"1","nbRateUnits":"1","rateUnits":"second","randomFirst":"1","randomLast":"5","randomUnits":"seconds","drop":false,"x":560,"y":100,"wires":[["58f22587.39099c"]]},{"id":"ba0b31a8.f7d7e","type":"change","z":"ea7ceec7.99905","name":"go to state 1","rules":[{"t":"set","p":"payload","pt":"msg","to":"go to state 1","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":730,"y":60,"wires":[["aa121696.6d6be8"]]},{"id":"58f22587.39099c","type":"change","z":"ea7ceec7.99905","name":"go to state 2","rules":[{"t":"set","p":"payload","pt":"msg","to":"go to state 2","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":730,"y":100,"wires":[["aa121696.6d6be8"]]},{"id":"aa121696.6d6be8","type":"link out","z":"ea7ceec7.99905","name":"","links":["a2bb1e76.ef576"],"x":875,"y":80,"wires":[]},{"id":"e6a036fd.720c08","type":"debug","z":"ea7ceec7.99905","name":"State (text)","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"status.text","targetType":"msg","x":430,"y":180,"wires":[]},{"id":"1d3d9993.eac0f6","type":"status","z":"ea7ceec7.99905","name":"","scope":["28d3a864.2ba658"],"x":200,"y":180,"wires":[["e6a036fd.720c08","7ae3e103.81836"]]},{"id":"7ae3e103.81836","type":"debug","z":"ea7ceec7.99905","name":"State (msg)","active":false,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","targetType":"full","x":430,"y":220,"wires":[]}]

Is this intended?

Is there a way to force status node to fetch the initial state of other nodes? Or get it through some other method?

I know that I can, and I actually get the initial status from the state machine's output - the above is just an example with shareable code - I am asking about checking statuses of other node types.

If the node’s real status updates before the browser web socket connects then it won’t receive it until the next update. As the browser could connect at any time then all the status would have to be stored on the off chance that it is needed.

And as we always say. The editor is NOT a dashboard.

1 Like

We need T-shirts with this on them :slight_smile:

6 Likes

If the node’s real status updates before the browser web socket connects then it won’t receive it until the next update. As the browser could connect at any time then all the status would have to be stored on the off chance that it is needed.

And as we always say. The editor is NOT a dashboard.

Frankly speaking, I don't understand this reply at all.

I am not using the dashboard, not even planning to. The process, which I needed the status for, is fully automated, no browsers are involved.

I need to trigger a process based on the status of a node. It so happens that the status might not change for a time, after deploying the flow and I need to "know" what that initial status is.

How can I achieve this?

If in your first example with the mqtt node and the debug output if you additionaly select System Console in the debug node do you see the connected status in the log on starting node red? I do.

There is a potential timing issue as any node could set its initial status whilst the flows are still starting. This means not all Status nodes will have necessarily been setup yet (I can't remember if we prioritise creation of status/catch nodes to try to minimise the chance of missing something).

As you've noted, the status node is only triggered by the change in a node's status - there is no way to query the current status.

I don't have a solution for you here - I think we need to look at the flow startup sequence to see if we can prioritize status/catch flows (if we don't already).

@techraf - apologies - I got slightly the wrong idea. (But the reason is the same -- ie timing)... but... maybe try... setting your debug to also send to console. When I do that I do see the initial status in the console log - so any nodes connected downstream of the status node would get it also... it's just as I said that the websocket to the browser you are using to edit / see the debug isn't connected.

(but yes - we should check to see if the status / catch nodes can be started even earlier to ensure they ready.)

I'm not sure if I understand your words correctly, but it's the status node that injects the message, isn't it?

How then the settings of the debug node could play any role here?

It would mean either that the status "became faster", or mqtt "became slower", wouldn't it?

I can imagine such settings causing the latter, though.


That said, I did what you suggested, and it seems now I get the state message every single time. It even works after reverting the settings. It might be a coincidence, though, as this is clearly a race condition.

As @dceejay explained, if the websocket connection is not made to the browser when the debug node tries to show its message then the display on the browser will not appear, by configuring the debug node to also send it to the log it will get sent to the log even if it is not displayed in the browser, so that is a better representation of what you are actually trying to do, which is to initiate actions in a flow on the connecting status as I understand it.

1 Like

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.