Now it is working thank you very much to you two for your help and for beeing on alert.
I appreaciate a lot
This is a very timely thread for me as I'm thinking about doing something similar so my to, cc, & Bcc headers can be set via the dashboard.
My question is what value will be in the dashboard fields when the flow starts again after a reboot?
@wb666greene - by dashboard do you mean the ui-dashboard or just the node's configuration.
In eithor case, on a reboot the values will be whatever you have set them to in your initilization flow (assuming you have some inject (?) nodes that run at startup)
If you use a global variable instead of a flow variable, you can set it in the settings.js file so that it is available immediately on startup. If you want it to appear in the text input (ui_text_input) node, you will have to send it there.
1 Like
I assume the global variable context is the same as the relatively new "file storage", this is what I was thinking about about trying, I didn't realize the change node could go the setting and getting to the flow variables.
Trying to init the display on the dashboard upon reboot has been an issue for me. Most of my dashboard has been to send MQTT messages so using "retain" was an easy way to get the last value on restart, but I had to add an rbe node as a "loop breaker" to the initialization when updated the dashboard display.
So I'm thinking this hew global context and persistent storage could be "cleaner". Downside is settings file edits on all my deployed systems. Not that I have that many, but its a thing that can easily be forgotten about when bringing a new system up in the future.
No, these are different. The functionGlobalContext object always was "persistent" in the sense that it lives in a file that is read each time NR starts. If a flow changes a variable defined in functionGlobalContext, the persistence of the the change depends on the type of storage you have selected for it. If you have both memory and file context storage available, you can select which to use in a change node, and if you use a function node you can even make that decision during execution.
True enough, but I have found that none of my systems use the default settings.js file distributed with NR. I keep a baseline modified file on GitHub, download it for each new system, and make small tweaks if needed.
