Problem with change nodes out of nowhere earlier today

This has been working just fine for well over 8 months...
had a power cut earlier today and now many if not all change nodes with this type of function returning a value are failing and spitting out either Undefined of unchanged values.

I have replaced a couple with function nodes, doing exactly the same thing, and they are working.

It bizzare! anyone got any ideas?

The first thing that springs to mind, those that have not been replaced...

is HSE_KW_OBYC still present for example?

I ask, as if you do not use the file system as strorage, there is every chance your global, flow vars have gone since the outage ?

I didnt know that but as it happens all my static global are initialized at start-up and the dynamic ones, like that one, are a product of a meter being read so created/updated at least once / second.

It is there and when I replace the change with a function, doing the same thing, it worked.

global, context & flow vars reside in RAM, you can change that in settings, so they are written to, and restored from disc.

given this surprise, it might be worth just checking over your vars to ensure nothing is missing, that may lead you to where the problem may be occuring.

I can't imagine a single node being damaged from a sudden power loss (not impossible, but surely extremely rare) :man_shrugging:

maybe recreate one of the change nodes?

I agree totally... Exept it isnt just one node it is many, if not all, change nodes where I am setting the result of a calculation as in J:

In a command window, stop node red and start it again, and see if there are any rude messages in the startup log. Post it here if necessary.

1 Like

it could be possible that the JSONata lib could be damaged.

I dfid delete and then rebuild the first one I found that was wrong...
it worked when first deployed and then failed again after a few more deployments or other changes.
(changed nodes only)

I will try that... Ptroblem is that it is on a remote site and I will have to configure access to the PI first.
That means messing with the firewall remotely... I don't like doing that.

Is it possible to stop and restart node red from the web interface, I realise I wouldn't see the logs but switch it off and on again has to be worth a punt!

I don't know the correct sorcery, but it has been done using the exec node?
find the correct method using it, before doing so!!

Permissions might stand in the way

That sounds almost as scarry as mucking about with the firewall :cowboy_hat_face:

I think I will bite the bullet and try and do it properly...

I just added a function doing the same thing as a change that was failing due to a missing global
If it fails again at least I can see both output sicario's without deploying now.

I am going to look at the file system option, its on an SSD, because disappearing globals sound way more likely to me than core functionality suddnly going bad.

1 Like

This is currently my assumption - missing globals

to switch context storage to the fs.


contextStorage: {
   default: {
       module: "localfilesystem"

Can you show us the JSONata editor of one of those expressions? full screenshot no cropping

Post #1 but to be fair that could be a missing global issue. Assuming I messed up somewhere, which even I will admit is more likely than the system being broken.

I had to deal with something else for a while... Back at it now.

That is not the editor, click 3 dots and take screenshot.

How can it be the global if it works in function node?

No argument there, that why I confused.

There is one instance, annoyingly the one started the thread with where the global could have been missing some of the time when checking.
However after correcting that I was still getting undefined from the change node and the expected result from the function...
To be fair there is other stuff wrong and possibly confusing things. Have restored remote access to the PI now and enabled filesystem storage, at least I think I have

21 Dec 20:53:53 - [info] Node.js  version: v16.20.0
21 Dec 20:53:53 - [info] Linux 6.1.21-v8+ arm LE
21 Dec 20:53:54 - [info] Loading palette nodes
21 Dec 20:53:56 - [info] Dashboard up and running
21 Dec 20:53:56 - [info] Dashboard version 3.3.1 started at /ui
21 Dec 20:53:57 - [info] Settings file  : /home/picpe/.node-red/settings.js
21 Dec 20:53:57 - [info] Context store  : 'default' [module=localfilesystem]
21 Dec 20:53:57 - [info] User directory : /home/picpe/.node-red
21 Dec 20:53:57 - [warn] Projects disabled : editorTheme.projects.enabled=false
21 Dec 20:53:57 - [info] Flows file     : /home/picpe/.node-red/flows.json
21 Dec 20:53:57 - [info] Server now running at
21 Dec 20:53:57 - [warn]
Your flow credentials file is encrypted using a system-generated key.
If the system-generated key is lost for any reason, your credentials
file will not be recoverable, you will have to delete it and re-enter
your credentials.
You should set your own key using the 'credentialSecret' option in
your settings file. Node-RED will then re-encrypt your credentials
file using your chosen key the next time you deploy a change.
21 Dec 20:53:57 - [warn] Encrypted credentials not found
21 Dec 20:53:57 - [info] Starting flows
21 Dec 20:53:57 - [warn] Unknown context store 'memory' specified. Using default store.
21 Dec 20:53:57 - [info] Started flows

Somewhat concerned about the last but 1 line, even if that is only the cache I would rather have it correct.

Once I am sure that Global Context is not the issue I will update. It is possible I am just mistaken and was looking at stale values in the context browser that had actually were not available to the flow.
I am assuming that filsystem storage will fix that... JUst about to test it.

OK so, log error not withstanding all global context vars now surviving a restart. which is progress and education, thanks.
I am going to look at the errors I still have and report back.


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