Is it possible for my custom node to subscribe to the flow restart event? This would be to allow me to run some code when the flows restart.
TIA
Which flow? All flows on all tabs? just your node? the flow your custom node is on?
When the deploy affects the custom node it will re-initialise it. Put `console.log("xxx") thoughout your custom node .js file - you will see one or more in the console log entries when you re-deploy.
The scenario is this, I make a change in the editor and click the Deploy button. That appears to restart all flows. When a given flow restarts, I need to execute code within that flow.
I added a ridiculous number of console.log() statements, and it appears that it runs the node.on("close", function (done) { function, but the function stops in the middle (I'm guessing it takes too long and the framework just kills it). I think I can work with "close".
It depends what you are trying to do. Is it the stopping of the flows you care about, or the starting of them?
You cannot do lots of work in the close event - you certainly can't assume the flow you're wired to is all still running as the runtime is busy stopping everything.
Whenever the flows are restarted, your node will be recreated - so its constructor function will get called. If you want it to do something whenever a deploy happens, that is the place to do it.
Note that the Deploy button has a number of options in its drop down selection. If it is set to Modified Nodes, for example, only nodes that have been modified will be restarted, so your node will not see the event (unless it is one of the ones that has been modified of course).
2 Likes
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.
What is the current state / solution for this problem?
- What is the recommended way to develop a node, that has dependencies?
- Is there a (new) way since 2021 that allows to detect if a:
- complete deploy
- partial deploy
- flow restart
- node-red service restart
is happening? And affecting the node itself, or the "child-nodes" which are depending on it?
(More about it here...)
Isn't there a hook for that? I would assume that would be the right way to trigger handlers for events.
I don't think so. Investigated it for 10 hours. It is too low level and would be called every each time some other type of node changes too.
But I've found this here : RED.events
RED.events.on("deploy", function() {
console.log("deploy happen- ed/ing?")
})
... will test it tomorrow.
is that a frontend thing? IIRC there are hooks and actions in the backend and events in the frontend but I might well be incorrect on that...
... "deploy" event never getting fired. 
Any idea, how to distinguish if NR is closing a node ?
(and not some error)
PS: tryied to find in NR's code where:
[info] Stopping modified nodes
based on "flows": {"stopping-modified-nodes": ... is printed to the consol log, but no files contain it other than the language locales\..\runtime.json files.
The close event handler on the node will be passed a boolean flag to say if the node is stopping because it has been removed from the flow config or not.
Otherwise, there is no way for the node to know why its being closed (ie a deploy of some flavour, or a full shutdown of the runtime).
If the registered listener accepts two arguments, the first will be a boolean flag that indicates whether the node is being closed because it has been removed entirely, or that it is just being restarted. It will also be set to true if the node has been disabled.
this.on('close', function(removed, done) {
if (removed) {
// This node has been disabled/deleted
} else {
// This node is being restarted
}
done();
});
1 Like
That's a bit of shocking. I've thought there is at least ONE flag, that would tell, if NR is shutting down. After all, it is doing it, and showing the process on the console.
From my point of view...
a properly written node has to know if:
- NR get's shut down
- (partial?) deploy is happening
- it gets deleted (at the moment a partial deploy is happening after that)
- it is changed, but existed before
Without these it won't be able to handle
- deleting subscriptions,
- restarting or stopping async processes
- report to "master" node
@knolleary Is there any obstacle that would prevent to declare some global variables in NR, like:
RED.starting (bool)
RED.stopping (bool)
RED.on("startstop", callback)
RED.deploying (bool)
RED.on("deploy", callback(partial))
When a node is told to closest should clean up its own subscriptions. If a node has a “master” configuration node that can wait until all the children it knows about have stopped (or told it they have) before calling its own done method.
@dceejay Thanks, yes, I understand the basic concept of master-child notifying technics.
Already implemented into the latest version of node-red-node-arduino module.
But neither the master, nor the child node can not handle, what it does not know. 
@knolleary Can you please answer my prev. question?
Correct me, if I'm wrong... but:
From my point of view, this should be very easy correction with lot's of benefits.
The node-red-log is already showing messages like "Stopping modified nodes" ... and similar.
You just have to add 1-1 line of code near those.
21 Apr 18:24:56 - [info] Started flows
...
21 Apr 18:25:53 - [info] Stopping modified nodes
21 Apr 18:25:53 - [info] Stopped modified nodes
21 Apr 18:25:53 - [info] Updated flows
21 Apr 18:25:53 - [info] Starting modified nodes
21 Apr 18:25:53 - [info] Started modified nodes
Or simply to "Deploy" menu command.
(After all, NR must know, which nodes must be restarted if someone is clicking that big red button... 
)
I have lost track of this thread, what is it that the nodes do not know?
[Edit] What I mean is that it knows if it is being stopped and it knows if it is being started, so what is the difference (as far as it is concerned) between that and a restart?
The huge diff. is:
- How it would/should handle closing / reinitialising.
- Depending on what is the reason of close / or restart.
- NR service restart? /
- Flow restart? /
- full-deploy? /
- Partial deploy?
For example:
If there is an external chip connected to the "node" via USB or Wifi, (like the one I'm currently working on via Firmata,) I have to decide what to do with it:
-
If it is a complete shutdown of everything, I have to send a RESET to the chip to stop all input events, otherwise the chip's buffer will overflow from collected data it can not send me any more. And I do not have to save the current pin's state.
-
But if this is only a restart, the chip should keep all current state of all the ports/pins, keep working as it is now, and I will need to READ the state of the pins/values after restart, to keep track.
-
Also, if it's only a partial deploy, nothing should be done, because only a few ports maybe changed,
-
except if the main chip-node (and not only the child nodes) are modified.
Of course I'm talking about a safe, industry grade software, not a "hobby junk", as most of the nodes are currently written. (Yes, I should not write this down, but this is the truth. Even my own work is not perfect.)
But without data, we can not prepare any node how to handle different scenarios.
A more simple example:
Let's say, you have a home control system, turning on/off your lamps.
You need to restart the flows at night, because an other module is frozen.
Do you want that your whole house turns dark?
No, of course not. MQTT persisted topics retain the current state and restore it on a restart. It makes no difference whether it is a restart or a stop and later start.
Cannot the software controlling the chip cope with the overflow and reset itself if that occurs? It must have to deal with that situation anyway in the case of comms failure for example.
Is there a problem saving the current pin's state whatever the reason?
Is there a problem with re-reading the pins values even in the case of a restart?
