I'm using node-red-contrib-simple-gate and have used the 'status' node to see if the gate is open or closed which then updates a Dashboard text field.
This works fine under normal usage and I have enabled the 'Restore from saved state' option along with file persistence and the state is preserved between deploys.
However, if I do a full restart of Node-Red or reboot the server the text field does not populate after a reboot until I interact with the gate (I have a button to toggle its status). Is there any way to force the status node to periodically refresh the status node or make it run on startup so the status is displayed without needing to interact with the gate?
Alternatively, can the 'get status of node' be replicated in a 'function'? That way I could use the inject node to trigger it just after start?
That sounds like a bug in that node that should be reported to the author. If it is restoring state OK then it should be able to set its status. If not in restore mode then it is totally valid to not be set until it receives an input.
Hi, Thanks for the quick reply. To verify I found the json file with the matching node id in ~/.node-red/context/ and it's contents is reflected (albeit after 30 seconds as expected). So it suggests I set that up correctly.
Is there a function way to replicate the status node as a work around?
The Status cannot 'get' the status of a node - it can only report changes to the status when the node in question sets its status.
When Dave suggested it was "a bug in that node" - he was referring to node-red-contrib-simple-gate and whether that node is correctly setting its status when things restart - not a bug in the Status node.
However there is another aspect to this - the node might be setting its status properly on startup (you can check that by seeing what it reports in the editor after a restart) - however if it is reporting that status during startup, it is entirely possible the Status node has not been started yet, or that any of the nodes connected to the Status node have not yet been started.
I think it starts Status/Catch/Complete nodes first (I'd have to go double check that....) - so it could the latter.
Hi, thats does make sense. Thank you for the clarification.
I suspect I could work around it if I could create a 'function' that could query the current status of the 'gate' node. Is it possible to get the current state (open|closed) of the gate programatically?
As a workaround you could send the status to a Retained topic in MQTT. Then where you use the status connect to an MQTT In node to pick it up. Then on startup it will automatically pickup the status from before the restart.
This question has come up a few times before and in connection with other nodes as well, and I think the issue is what Nick describes. My guess is that if there were an easy fix for this in the runtime, it would already have been done.
For the gate node in particular, the status is set before any input is received, and I recall either @knolleary or @dceejay having checked the code and given it a clean bill of health, although I can't find the post at the moment.
I have a kluge you can try while I implement a workaround. You can replace the gate node with the q-gate node, which operates in essentially the same way if you ignore its queueing functions. One difference, however, is that I recently added a status command to q-gate that causes the node to refresh its status. If you connect the node to an inject node that sends the status command on startup with a short delay, you should have the flow fully deployed and the status node ready to accept input. I happen to be working on a bug-fix release of the gate node, and I should be able to add the status command and publish it in a few days.
