[ANNOUNCE] @waldbaer/node-red-persistent-values

Share Your Nodes
1

Hi,
I would like to announce my new released node for user-friendly usage of the Node-RED context stores.

Motivation

I am using Node-RED to control my SmartHome.
For many smart actions several states / config options are typically necessary (Anyone present, Everyone sleeping, Heating Period, Open Windows, Open Doors, ...) fed by sensor data or manual user interaction.

To store all these states I used in the past two years a custom subflow/function with subflow configuration options where I could define all my used states/config options.
Under the hood the excellent core context stores is used to store all the states either on disk or memory to let them survive system reboots etc.

One major issue with the context store APIs are that a user must always remember the correct name of the variables. Futhermode if different scopes (node, flow, global) or stores (file, memory, default) were used an unintended mix up of these parameters can happen very fast.

Solution

To simplify the usage of all these states / config options etc the idea came up to implement a dedicated node where all necessary states can be defined via an shared configuration node.
In the configuration node the different states as well as their datatype, default value, scope and context store can be configured at a single location.
In the concrete nodes used to read or write to the state/config option only the shared configuration node as well as the state/config option to be accessed must be selected.

This is the new born node:

Future

There are several ideas for future improvements:

  • Get previous state value in the output message
  • More config validation: Unique config and state names
  • More datatypes (Map, Object, Array, BigInt, ? ...)
  • Output current state after NodeRED startup

I hope that the node is helpful for many more NodeRED enthusiasts.
Looking forward to constructive feedback!

1 Like
2

Hi @waldbaer

Nice work!

Can you see the variables created, also being accessed via the global context, given that custom nodes can write to that context?

3

@marcus-j-davies
The node is "just" an abstraction of the NodeRED core context API.
So you can see all the states as before in the UI as well access them in any custom function.

As I have also the usecase that I need several states at once to make a decision (e.g. Windows open && Lights on) I added the "Collect Values" option. Multiple nodes can then be "chained" and at the end in a custom function all the states are evaluated. The collected states are added to an configurable msg property as Object. E.g. msg.states = { RoomStates_OpenWindows: 5, RoomStates_LightsOn: true}.
Please also have a look at the example flow "Collect Multiple Values".

1 Like
4

What is the advantage of this over using filesystem context?
(Rather than the default where context is stored in memory)

5

@Trying_to_learn The user-friendly usage in multiple flows etc without needing to remember the exact variable name, context type, store type.

Any mixup of the string parameters results in an invalid behavior.

Flow1:
msg.payload = global.get('mystate1', 'memory');
Flow2:
msg.payload = global.get('mystate1', 'file');. // Inconsistent states returned!

Also every custom node must take care of an not yet set context variable.

The same applies if context variables are accessed via the change node.

There are definitely usecases where the direct usage of the context APIs is the best and easiest way (e.g. variables on scope 'node'). But for huge NodeRED setups where dozens of variables in the context need to be accessed from multiple flow locations it might end up fast in bugs due to copy-pasting code.

6

@waldbaer can correct me...

But I see it as a UI / definable way to manage context based variables

1 Like
7

@waldbaer

Can this enumerate variables not defined Within your node?

8

@marcus-j-davies Can you please give me some more detail on your question? I don't get it.

9

If a user were to do (in a function node)

global.set('SomeKey','SomeValue')

Would it be listed in the node?

10

@marcus-j-davies Ah, nice idea! :star_struck:
But this is not (yet) supported.

Might be an option to add this an feature. But this might then require an configurable naming scheme.

Today the values are stored with the scheme <Config Name>_<Value Name>.

11

Understood :+1:

Again Nice work!

12

@marcus-j-davies

In a first shot I didn't want to implement a full abstraction of all variables in the context stores to avoid too invasive effects on existing setups.

At the moment any deletion or renaming of configured values will not lead to a renaming of the context variables.

But yes, would be a future extension to let the node actually do a 'full management' of all context variables.

Thanks for the input!

1 Like
13

There are members of the community on higher 'payrolls' that can provide more robust feedback :sweat_smile:

And if desirable, would provide some solid input. :+1:

14

I just want to give a short update here. Since the first released version several small features have been added in the meantime.

With the latest version 1.6.0 the following new features are now included:

  • full dynamic control of command and selected value with configurable msg properties
  • Output of previous persisted value
  • Datatype JSON
  • 'Reset' command to restore configured default value
  • Description field and 'meta data' output of persisted value
  • Several small fixes and improvements

Have fun with it!