Hi Node-Red user,
At the moment I'm developing nodes for Node-Red.
It bothered me that e.g. dashboard nodes always lose their set values when restarting.
That's why I developed nodes that allow you to persist set values.
These nodes are part of a larger project with other nodes.
Would the nodes be useful for you if I publish them separately in Node-Red?
Below is an example.
How do these nodes work?
MA memory node: This stores the number global variables from the global context every x seconds (default 20s) to disk.
M memory node: This saves the boolean global variables in from global context every x seconds (default 20s) to disk.
Of course, the values are written if they have changed.
When restarting Node-Red, the values are loaded from the disk.
The onstart node sends a message to the export nodes after x ms (default 100ms).
These read the global context variables and set the dashboard elements.
If you change the values in the dashboard, the import nodes write these values in the global context variables.
An advantage is that the values of the dashboard nodes are stored in global variables.
Of course you can also save values from other nodes.
What do you think of this procedure?
How does this differ from Node-REDs built in persistent context?
1 Like
Of course, Node-Red has persistent storage for context variables.
The entire context is stored on disk.
The storage interval is fixed for all variables.
Also, it is difficult to create and access the context variables.
If nodes handle them, the using is easier.
Fair enough, I understand now - you want to use context BUT be able to backup and restored "parts" of the context on demand - is that a correct assessment?
Yes, exactly, the memory interval can be set in each memory node.
In addition, the variables are loaded with default values when they created.
An array of 64 elements is created in the global context variable.
These are either boolean or numeric.
The import/export nodes then access the variable array via the index number.
Here is the settings page of the memory node:
Ok, my first issues is - you don't permit the user to specify which context store - if their store is already a file store, your node is doing double duty.
Next, you dont permit the user to use flow context (it looks to be locked at global context) - this can cause clashes when other nodes use global.M0 for something else on an unrelated flow.
Recommendations
- Dont use global context at all - consider using node context if possible, flow icontext if you must. This would isolate the context from all other flows.
- this might feel like a downside but in reality, it is simple and safer to pass context to another flow when needed.
- Let the user chose where context goes - to avoid clashes with existing context a user might have
- An even better solution would be to bake these capabilities into node-red - but I appreciate these things take time.
@iiot2k For more simple read/write access to the persistent context store I developed
node-red-persistent-values
Maybe this helps for your usecase too. At least a 'default value' support is provided.
Thanks Stephen for your hints.
As said, these nodes are a small part of a project.
The variable names are standardized according to IEC 61131-3.
M and MA variables are mainly used to store intermediate values.
The fact that these are also persistent is an extra feature.
I thought I might find these nodes useful for the Node-Red users.
@waldbaer thanks for pointing out your node and great work.
I will take a look at your node.
