If I understood well this is the place where we can make some improvement request right?
If I’m right I think a huge amount of people will be interested that node red has native capability to recover all global variables after deploy/restart.
This will be great and will release the job to be making tricks with MQTT or saving variable by variable to a file etc…
Perfect. My idea was to ‘store’ variable contents in a retained message and use an Inject node at start to subscribe to the storage topic and store the value again. I was going to ask how best to accomplish this (subscribe in a function, get the payload once, store it in a variable and kill the subscription) but now I rather wait for 0.19.
I looked at the PR. If I understand it correctly, variables are persisted by writing their content to files. I wonder if this better for the hardware (e.g. a Raspberry Pi’s SD card) than retained messages (which are stored also in the file system in a database).
Mosquitto’s database is a simple file DB anyway. File handling is generally very efficient these days and you really don’t see much benefit from a managed DB until you are able to keep indexes fully in memory - not a lot of benefit when the purpose is to reload to memory anyway.
I have the opposite problem, I need to send some data to hardware to initialize it at every deploy, I?m using a global variable that if undefined will be "0" and at every single event generated by a cyclic Inject increase its value till the data is finished, in my case after 10 data sent cycles, than the main flow can use the hardware if 10 is riched, not before.
WHen I deploy the valuse is already 10.. how can I force it to zero? Thank you
If you define a memory only context store, you can write specific data to that which will be flushed by a restart, where as other data is written to the default which if you have defined it is saved to the localfilesystem and survives a restart