Stop node from initialization?

General
1

I suspect I know the answer, but is there a way to stop a node from initializing its self? Not unless the node developer allows it by design, right?

I have a situation where I only want a node to 'initialize' when the first message is received as input. Until that first message, the node does nothing, absolutely nothing. Usually nodes do some type of prep, run a constructor, what have you.

2

Which node are you concerned about?

3

You don't have do to any initialization when creating the node, besides registering the required event handlers, like on('message').

You can put your specific init code into that handler function, but you should take care, that it runs only once.
And I have some concerns in case you do async stuff during initialization and a second message arrives during that time.... :thinking:

But without any details about your specific use-case, it's all just guesses.

4

@kuema
Nope, what you stated is what I expected. And matches the behavior of nodes I have used. Thanks.

@Colin
Just as an example, the BME280 sensor node tries to initialize the sensor, even if the sensor is not present. This generates (debug) errors. As a result as I am developing my own nodes, wanted to know what could or should be done. Really, specific to that node, it comes down to how the developer wrote the code.

There is a design issue here, there is a difference between the sensor not on the i2c bus because not connected physically, or a sensor that has failed at some point, and maybe dropped of the bus. I think for what I write, I will include a configuration option of how to handle the error reporting if the sensor is missing or non-responsive, and an option for when the sensor is initialized, at node load, or at node actual use.

Just to illustrate this design decision... Below is an example... I am not suggesting a change to the mysql node design...

The mysql node is another node that attempts/does connect to a db before it is ever invoked by message received. I don't think this always the best option all the time. I understand why a connection is held open, in the case of mysql there is true cost to opening and closing the connection per select/insert/delete, etc. queries. Pooling connections benefit, etc. are real issues. Adding a configuration option for the mysql node, to open and close connection per query, or explicit nodes that do open and close functions, thus not initialize and hold open a connection, provides node use flexibility, which I am a big fan of, providing user flexibility, when possible.

5

indeed - at the cost of confusing naive users with options they don't understand or need. Always a balance.

6

The example you give isn't just about flexibility though, it is also about performance. As Dave says. The best approach is often to try and identify the "happy path". e.g. the path most generally taken by most people when using Node-RED. Since Node-RED is a low-code development platform, it is sensible to keep up-front choices to a minimum for most nodes.

For uibuilder, I try to hide complexity behind an "Advanced Options" section that you click on to reveal.

7

It is not that I don't agree in principle to what both of you are saying. I guess I just have greater expectations of what can be done as NR matures. TotallyInformation points out a good idea, to hide (initial) complexity. Since I am writing the code, I know the design is my decision, I have always designed above and beyond the 'requirements' of the job, task, etc. And it has never burned me, in fact it as been rewarding.

My perspective in part is based on my experience, to which, robust design always benefits the long term use of the solution. Have a long history experience with designing monitoring solutions, in enterprise critical environments. If you don't think NR is being evaluated beyond its stated target audience, that would be in error. I know for a fact NR is being reviewed by some very interesting entities.

8

So, getting back to the technical issue, what you propose is some sort of lazy node initialization that is implemented by the core?

After thinking about it over the weekend, I had a similar issue a while back. I isn't a problem, if your init code is all synchronous, but I had to run some async code during initialization and stumbled upon the fact, that I can't tell the runtime that my init code has finished. So my node seemed ready to the runtime, got triggered by messages and I had to make sure, no messages were lost during that time (worked around it).

So having some sort of done callback similar to the close handler would make up a more consistent node life-cycle.
If there's work in that area, I think that should be taken into consideration.

However, changing the initialization would be a major modification that needs to keep its backward compatibility. One of the things I really admire about Node-RED and its developers, they always get that part right. :grinning:

9

To get back to the original question:

That is correct. It is up to individual node implementations how they initialise themselves and how they manage any resources in relation to individual messages.

For the stated example of the mysql node, even if the runtime did hold off initialising the node until the first message arrived for it, the node would then get initialised and would be connected from then on. You would not achieve a separate connection for each message. That type of low-level behaviour would be down to the node to offer.

There is a separate question about the node lifecycle and whether there should be a separate initialise phase where all nodes are given the chance to prime themselves without starting to send messages. It is something to think about for 2.x or later, but that is unrelated to the original question.

We don't think that. We speak to all sorts of 'entities' about their use of Node-RED, both directly and indirectly. We're well aware of how broadly used it is.

10

@kuema
Right, This would be a really nice feature, to have a event/call back as you outlined. Although I am not sure how many would use it, effectively, if at all. I would to be sure, given the use case I have with the sensor nodes I am starting to working on now.

@knolleary
:slight_smile: Cool.

11

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