Persist dashboard state/context between restarts

Dashboard
1

Hey everyone,

I just started using Dashboard v2 recently to create a simple and easy-to-use interface for my parents to control some IoT stuff around the house. It is working perfectly, previously I had a decent experience with Dashboard v1, but I have a slight problem with it: dashboard state is not persisted between reboots/restarts. I tried searching for a solution, but did not find anything, only an explanation that the state is stored in-memory on the backend and there is no config for it.

Is there a reason Dashboard works this way? I have set the default context provider of Node-RED to use the filesystem storage and I would really appreciate if Dashboard also used the same context provider.

Right now when I restart Node-RED my whole dashboard gets reset and basically I have to click on every element/input/group once to set a desired state (reflecting the real world).

I would really appreciate if Dashboard v2 persisted its state the same way flow context does!

2

As a workaround I managed to get my whole dashboard and every element keep their state during restarts by utilizing node-red-contrib-persist, but I have to admit it makes my flow unnecessary large, so a global default persistence option would be much better I think.

image
image1131Ă—862 83.2 KB

3

You could also use the uib-cache node from UIBUILDER. which uses Node-RED's standard context and has various different settings and includes the ability to store multiple as well as single msgs.

image
image823Ă—1000 67.6 KB

You can, of course, also use multiple nodes to get different settings for different caches. It has standard control messages for cache replay's and cache clearing.

4

Are you using MQTT? If so the send the states to retained topics in MQTT. Then on startup an MQTT In node on that topic will send you the state. You can wire that to the switch, or whatever it is, and it will be set to the right value.

If you are not using MQTT then you are missing out on useful stuff.

5

A further advantage of using MQTT is that you don't need to wire the switch (or whatever) directly to the other flows. You can use MQTT In nodes to get the values where you need them. In addition if you want to change the state under flow control you can send the new state to MQTT and it will update the dashboard state automatically. This means you can keep the dashboard flows separate from the logic control flows, which can make flows much simpler.

Edit: Sorry, Julian, I replied to the wrong post.

6

No worries. And of course, you are correct. MQTT with retained messages can indeed be a useful option when you are just interested in what happens when Node-RED restarts.

On the other hand, not sure it helps much if a new client is connecting? One of the advantages of a caching node is the ability to trigger a cache replay whenever you like. The uib-cache node also allows multiple messages to be retained, I think that the Dashboard only retains the last message sent to each node? Oh, and of course, uib-cache can use any of Node-RED's context stores and so can use retained context variables.

As always, Node-RED has options. :smiley:

7

Why persist the dashboard status? If your Node-red server was down (say, for a day), why bring back yesterday's statuses? You can auto-launch an update flow upon restart or upon page load which queries & updates the statuses to their real-life state.

8

Many devices report on change and cannot be polled. Also many status items are under node red control. For example I have an external light that can be in auto mode based on a motion detector, or manual mode with a switch. I want that retained if I restart node red.

9

In such cases you are of course correct (raising the question if it is better to show a persisted value which could be wrong, or something representing an "unknown" status).
Here he mentions that upon startup he goes manually and clicks each element to refresh it. So I assume this can be automated.

10

Just building a UIBUILDER Dashboard here and I am allowing HTML blocks to display Grey until NR refreshes their value. That way I can see what is current and what is 'old'.

(I admit, I discovered this 'feature' accidentally during my experiments with HTML and CSS!!)

Edit: Added HTML to read HTML Blocks.

1 Like
11

Nice idea.

I also sometimes add tooltips containing the last update timestamp. Similarly, JBudd's nice, compact weather display panel shows the last forecast timestamp.

I will also often include update timestamps on MQTT topic hierarchies.

12

Some great ideas here in this thread, but I think we are overcomplicating stuff. I just want my dashboard to keep its state when Node-RED restarts for whatever reason, that simple.

In my opinion losing dashboard state on reboot is essentially data loss. I want my NR to be as robust as possible: that's why I set up filesystem storage for flow contexts and use node-red-contrib-stoptimer-varidelay instead of the built-in timer nodes, because those can also save their state and scheduled firing time. And most other software, e.g. browsers, can be closed and can reconstruct their state next time they are opened (re-open tabs, remember movie position and continue from there, whatever). I think this is a really elementary feature of any software, and from this point-of-view NR Dashboard not keeping its state is just weird.

See also sablier, which is an extreme example, but brings the point across about why I think proper persistence is important.

And I'm not doing this because I restart my Node-RED frequently for fun, but because I want to simply make my setup robust and resilient against e.g. power outages, which happen here quite frequently (a little bit of wind can cause outages lasting 1-2 hours).

Also in my case the dashboard is the single source of truth. Interacting with it can only send requests to the other service, and no external request is received by NR, nor is the target service used by anything else. It's one-way communication. This is why I don't want or need any data flow in the other direction (polling or handling incoming requests, etc.), that would make the whole setup much more complicated than it needs to be.

Right now my dashboard saves its state thanks to node-red-contrib-persist, so basically it is perfect. I just wish this feature was built-in, so I could omit wiring up all these persist in and out nodes.

Regarding MQTT: I'm using it for my home automation stuff, but on the system I'm hosting this dashboard there is no MQTT server and I don't see the need for it. Retained messages would basically do the same as node-red-contrib-persist, but with an external dependency that also needs to run.