Stopped cron-plus-node "jumps" back on without any command

[marc965]

Good morning.

I have been using the node-red-contrib-cron-plus node under Node-RED v4.0.5 for a longer time, most recently in version 2.1.0.

Overall, the node works as expected, except for one issue:

A central part of my flow is regularly starting and stopping the cron-plus-node with msg.topic: stop and msg.topic: start.

This works very well, unfortunately, the cron-plus-node "jumps" back on at random times without any command, without any plausible reason. The "Save State" of the node is set to "File: local file system".

This is quite inconvenient. Is there anything I can do to prevent this behavior, or is it a bug?

Best regards,
Marc

[Steve-Mcl]

unfortunately, the cron-plus-node "jumps" back on at random times without any command, without any plausible reason.

Add a debug set to output to console that logs the messages going into the cron node - perhaps there is a stray message getting to the node?

Question:: Is the schedule a dynamic or static schedule? If it is a static schedule, I struggle to remember off the top of my head if the run state is persisted or not. You could counter this by making your schedule a dynamically created schedule. They are most definitely persisted.

Question: does this occur when you make a change to your flows and deploy? What type of deploy do you use? (Full deploy, flows deploy, nords deploy)

Question: does this occur after node-red restarts? Do you have a means of checking to see if your node-red is crashing and restarting?

[marc965]

Hi!

I have several function nodes in the input of this cron-plus-node that monitor incoming messages so that I can see if a message has been received. For example, this morning at 08:00, no message was received and it activated without any apparent reason.

I only have one static schedule in use: cron: 3 0 * * * *
What exactly is saved when "Save State" is set to "File: local file system" or something else?
Maybe I don't need the "Save State" at all? What happened if the "Save State" configuration is set to: "None: dont persist state"?
Please tell me what exactly this function "Save State" is look like...

I have a function in the flow that reads a file via a File-Node in case of initialization and sets the state of the cron-plus-node accordingly. This function was not activated here. This morning at 08:00, when the node activated by itself, the Linux machine was not restarted either.

Resetting the node state happens when I save any flow changes, but I am aware that it could happen, so I pay particular attention to ensuring that the node status is set correctly before I leave the environment. This morning at 08:00 when it happened again, there was no crash and no Linux restart, I specifically checked the logs and i was not logged in at this moment. I only received a message on my Whatsapp account that it happened again...

Best regards,

[marc965]

i marked with arrows:

1. link in where the command is comming into: one for starting the node, the other for stopping the node.
2. the start of the initializing part
3. and the two function nodes for debugging...

[marc965]

The issue is still occurring; the last instance was on Thursday this week. Suddenly, the cron-plus node became active again without receiving any command.

To be certain, I've logged the inputs.

There's no question that the node is reactivating on its own. It's not related to the "save state" setting either, as it's been set to "None: Don't persist state" for quite a while now.

I've verified that neither a restart nor a deploy in Node-Red are the cause.

To work around this bug, I've introduced a Gate node. I control it with the same inputs that activate and deactivate the cron-plus node.

I would be very pleased if there could be a solution to this problem in the foreseeable future. In the meantime, I will test the current configuration. The Gate node should at least catch the malfunction of the cron-plus node.

I am happy to contribute to solving this problem.
Thank you in advance for your support...

[Steve-Mcl]

Hi. I'm not as convinced as you are that node-red is not being restarted in some fashion. I've never seen the issue you are describing and no one on the discourse forum has reported it either.

Before I dig into this, can I ask that you somehow log to "something" every time node-red is started. This can be triggered easily by an inject node set to execute on start up. The external thing could be a database or file. It just has to be external (in the case of docker, that file should be persistent or outside of the container).

By chance, are you running node-red in docker (or home assistant or other plugin type environment?).

For completeness, what OS is this running on?

[marc965]

Hi Steve!

Thank you for showing interest in this case.

At the moment, I'm quite sure that the problem is caused by the cron-plus node, but of course, there's no 100% guarantee that I'm right, as the systems are too complex.
I'm happy to be proven wrong here. I would obviously like to move forward, regardless of whether I am mistaken - but right now, I have no other lead.

I've already implemented the desired functionality in my flow - an Inject node named "initialize" generates a message 3 seconds after a restart or a potential deploy - this message would not go unnoticed, as I have set up a function nodes for both cases (activation and deactivation) that immediately displays the passage of a message with date and time. I attached an image and marked it with red arrows. This inject labeled "initialize" has another functionality: It reads a file and sets the status of the cron-plus node based on its content. Is this sufficient for you?

And it just happened again today, 19th January 2025, between 13:29:29 and 14:00:03. You can see that the preceding function nodes labeled "I/O" displayed messages "last event: 19.01.2025 13:29:29" for the STOP path and "last event: 17.01.2025 17:01:38" for the START path. So, no additional message could have reached the cron-plus node between 13:29:29 and 14:00:03, or am I wrong?

Behind the cron-plus node, you can see another function node labeled "I/O" displaying "last event: 19.01.2025 14:00:03", even though the cron-plus node should have been deactivated.

For safety, I have implemented a Gate node that stops message passage. You can also see that this Gate node is closed, which happened at 13:29:29.

I am using a hardware-based native Ubuntu system version 24.04.1 LTS specifically for this Node-RED, as it is used for important control tasks, including inverter control. There is nothing else running on this machine...

Thank you again for your support.
Best regards,
Marc

[marc965]

This morning, it happened again;
although no messages could have reached the cron-plus node, it activated itself again.

It seems to happen only after a few hours.
Fortunately, my Gate Node prevented the worst.

Is there anything I can do to speed up the progress?

[marc965]

I'm not entirely sure, but I think I may have identified the cause of the cron-plus status resetting.

Since it has happened several times in the past few days, I have been looking into the matter more intensively. It is particularly noticeable that this reset to the active state is unpredictable; sometimes it doesn't happen for several days, while on other days it happens multiple times in a row.

For this reason, I created several cron-plus nodes to check if this behavior also affects the other nodes in parallel, to ensure that the flow is not the cause. And lo and behold, when the original cron-plus node was reset, all the others outside of this flow were also reset. This is no coincidence.

And then my discovery. Each time, at the same time, the ntpclient appears in the syslog, resetting the time by a few milliseconds.

I have now migrated the control to different hardware; now everything is running on a Raspberry Pi, and there have been no problems since then...

So you can close the topic. Thank you for your effort.