Successful methods for multiple dashboards - please add yours

Dashboard
1

Hi all,

So the problem I have been trying to solve is that I need differing UIs for different people and scenarios.

Here are two examples.

  1. My partner tends to use the system differently than I do. I have created a simplified UI just for them, that prevents them from accessing pages that are available in my UI.

  2. The UI available from the display in the lounge is purpose-made for that room such that my kids cannot f with each other by turning lights off when the other is in the shower/toilet elsewhere in the house.

My solution is described below, but I would like to hear yours.

Short version: build each GUI in a unique instance of Node-Red, running in ProxMox or similar VM/LXC manager, all sharing the same MQTT broker. This only works because ProxMox makes infinite servers on one physical machine possible.

Obvious, right? I learn slowly, OK? so I'm posting this because it's such a basic, core part of how MQTT works that it took me years to learn it. Shut up.

Long version:

My home's instance of Node-RED runs in ProxMox, in a Debian LXC. It is a system that relies entirely on MQTT messages that pass through Mosquitto, itself running in a separate ProxMox LXC. That means the GUI updates via MQTT too.

My tiny brain eventually twigged that because of this, the dashboard does not need to be running in the same Node-RED instance that does all of the thinking and automation. The commands a GUI gives are published to MQTT, and it visually updates via MQTT.

So when I need a separate GUI, I simply spin up another Node-RED LXC just for that purpose. It's a vanilla Node-RED with Dashboard and no other plugins, is computationally negligible, and is saved as a template so that I don't even need to install Node-RED or the Dashboard plugin when I want one. It's simply there in 15 seconds or so (my server is an old NUC).

On that instance, I build the required custom GUI, which obviously has its own unique IP address.

This method gives me unlimited unique GUIs, because each one speaks via MQTT to the same broker. Changes in one GUI replicate to all, because it's MQTT.

I am 100% sure that this will be totally obvious to many people reading this. But I am a bear of very little brain, and it felt like an epiphany, since I have needed this functionality for some time.

It would make no sense without the ability to trivially spin up servers.

2

And if you want to avoid the complexity and overhead of containers, just use command line parameters to fire up as many instances you desire:

node-red -u /node-reds/node-red-1881 -p 1881
node-red -u /node-reds/node-red-1882 -p 1882
node-red -u /node-reds/node-red-1884 -p 1884
2 Likes
3

See? I knew there was a better way of doing it. Thank you @Steve-Mcl! I learned a new thing today.

Is there an elegant a way to have that happen automatically at runtime? ... I'm thinking function node that triggers an exec node?

4

Elegant? Use a platform like FlowFuse. You can add/remove, stop/start instances at runtime via it's GUI which is API based so you could do it all via HTTP.

Other ways: create a service for each instance.

5

If you have time, learn Docker and run multiple node-red instances on different ports.

1 Like
6

There is another approach that avoids the use of a proxy and multiple instances of node-red.

UIBUILDER allows multiple independent instances of UI's to be created. Each uibuilder node creates a new web app. Each instance of uibuilder allows both single-page (SPA) and multi-page UI's to be created easily.

So you could actually have a single instance of uibuilder with multiple pages. These can share the same CSS but have completely different UI's or, of course, they could have their own CSS or some hybrid.

If the UI's need to take/give significantly different data, you could use separate uibuilder instances. There are still ways of sharing resources between them if this is desirable.

In addition, UIBUILDER does not force you to use a specific front-end framework. It allows you to use any framework but actually, for most scenario's, you don't need any framework at all. This allows you to avoid the somewhat inevitable rebuilds that major framework version changes force on you over long periods of time.