Custom node subscribed to flow restart event

General
21

You are right from one side view.
But on the other hand:

  1. This supposed to be an example. We can not know every each case scenarios.
  2. Firmata is not MQTT.

Cannot the software controlling the chip cope with the overflow and reset itself if that occurs?

  1. No. We do not write the chip's embedded code. We must deal with them. For example Firmata is running on 30+ different chips, all based on different libraries... etc.

Is there a problem with re-reading the pins values even in the case of a restart?

  1. Sadly Yes, there is a problem with that. Changing an output to "state read" causing sometimes the chip's pin to turn on/off Pull up resistors, start emitting data continuously, etc.
    Again: we do not write the embedded code of all the chips. I'm learning about those since 5 years now, and the more I read, the more I'm shocked by the chaos.

But again: this is only 1 example.
The question main question is:

  • why is it so difficult to add 2 booleans to the code of NR ???
  • are not we already debating 10x so much about it, than actually adding those few lines ?

Those, who do not want to use the info, will not have to.

RED.starting (bool)
RED.stopping (bool)
RED.on("startstop", callback)

RED.deploying (bool)
RED.on("deploy", callback(partial))
22

@PizzaProgram I think there are two separate considerations here.

  1. When a node's close event handler is called, have a way to indicate the runtime is stopping.
  2. Have a more general event around the deploy event.

In general, the close event on a node is the place to inform a node that it needs to stop. Making the additional context available as to how/why the stop is happening would help address the requirements. That will mean, if a partial deploy happens and a node hasn't be modified, it won't get notified. I think that's okay for the purposes we're talking about here.

Currently the close event handler function can take these forms:

  1. on('close', function () {}) - synchronous completion
  2. on('close', function (done) {}) - async completion with callback provided
  3. on('close', function (removed, done) {}) - async completion + 'removed' flag provided

My preference would be to find a way to pass this additional context to the close event handler, rather than expose different apis for querying this transitory state. All while maintaining backwards compatibility for the callback signatures listed above.

Most crudely, we could specify a third argument format:

on('close', function (removed, state, done) {})

Here, the state property can be an object containing whatever state flags we want (thus giving us an bag to stuff additional flags in the future...). The downside is the removed flag is still separate where it ought to be inside the state object... but we need a 3 arg function signature to know to pass it in. It isn't the most elegant api... but what comes from choices made over 10 years ago and keeping compatibility in place.

An alternative is a separate event for lifecycle events of the runtime. The downside there is, we'd still need to call the close event handler on the node - so you then have a lack of clarity on what the node should do when it receives the shutdown event before/after it receives the close event handler. I think the semantics would get messy.

So whilst I don't have a full proposal, I definitely do acknowledge the need here - I'll give it some more thought.

2 Likes