Discussion about a new Dashboard

Ok not sure whether my usage would be multi-user or not to be honest. We had a very interesting discussion about having 'affordable' touch screen devices in the rooms of a house, where a Node-RED dashboard is being displayed. And each room needs to display another Node-RED dashboard: e.g. in the entrance hall you want to display a dashboard with an alarm keypad, in the bathroom you want to show temperature/humidity, and so on... To summarize: wall mount Amazon Fire 7 tablets which display a dashboard running on a central Raspberry, because such devices have not enough system resources to run Node-RED locally. But it would be very pity if I had to install N Node-RED instances, to host N different dashboards.

Such typical home automation situations should be easy to implement using a single Node-RED instance IMHO ...

But perhaps you guys have already other solutions in mind for this.

Yes indeed that is something that is not easy to solve in the current model. Entirely correct. Going to ask some (perhaps stupid) questions to understand it a bit better:

  • When you say "programmatically" then you mean a code snippet in the layout manager, or something else? I have not needed something like that yet, but I can imagine that some folks program this kind of stuff in a UI template node currently? Or do you mean that it is currently (in a template node) only possible for basic widgets (e.g. md-button) and that you can e.g. not add N instances of my node-red-contrib-ui-svg node on a screen programmatically, to show the floorplans of N floors in my house?

  • When you say "layout stuff" do you mean an easy way to specify css styles, or an out-of-the-box available layout manager? Because I can indeed understand that you want to use an existing layout manager, to avoid reinventing hot water. It is not a secret anymore that I like the current model, so I am going to give it yet another try :roll_eyes:. @Steve-Mcl integrated some time ago a third party SVG editor inside our node-red-contrib-ui-svg node, because we didn't want to spend the remaining of our miserable lives to develop a graphical SVG drawing editor ourselves. So we integrated an existing SVG editor (DrawSvg) in our node. Isn't something like that possible perhaps. That you can access the third-party layout manager easily from the flow editor, and the layout manager shows and manages the UI nodes in Node-RED. I mean dual way (like we do with DrawSvg):

    1. I see in my Twitter feeds that a nice new UI node has been developed.
    2. I have a look at flows.nodered.org what it is all about. Yes I need to have it ...
    3. I install the UI node via the "Manage Palette" menu in my flow editor.
    4. I drag the UI node in my flow.
    5. I double click it and change some properties in its config page.
    6. I have a look at the node's info panel in the sidebar, when something is not clear to me.
    7. I hit the "dashboard layout manager" button and the (third party) layout manager opens. While opening the manager, all the installed UI nodes and the properties of all UI node instances are passed to the layout manager.
    8. In the layout manager you can change properties of existing UI nodes, remove existing UI nodes, or create new UI nodes (based on the set of installed UI nodes). But here you are working with the UI node's widget counterpart.
    9. When you leave the layout manager all node instances (and their properties) are returned to the flow editor and updated in the flows.
    10. Now I can start adding wires to my new UI node instances.
    11. I hit the "Deploy" button and my updated dashboard is up and running.

    That way would be perfect for me: I can use UI nodes in Node-RED exactly the same as non-UI nodes, and I can also enjoy the power of a full blown existing third-party layout manager.

    I have absolutely no idea if there is a layout manager available that allows such level of integration. And I am also aware that this might need to require new functionality (in the core?): e.g. in step 9 the flow editor has no idea where to add newly added UI nodes (in which flow tabsheet or at which location). So something new is required, like e.g. a visual backpack or something else where such "draft" nodes are being stored until you drag and drop them in a flow.

    And perhaps there are other disadvantages that I have not thought about, which redirects my proposal directly to the garbage bin ...

    But such a setup would make life easier for me as node developer: all things that I have learned from my non-UI node developments, I can reuse for UI node developments. For example I know how to create a complex node config screen. I could easily keep doing that: my new ui-svg node could have a complex config screen in Node-RED, while it has a very simple properties screen in the third party layout manager. That way I don't have to start studying again how I have to create complex property screens in the layout manager. I hope that makes sense somehow?

This was most probably my last attempt to keep having my belovely UI node concept in Node-RED. It is something I really like... Absolutely not because "I got used to it", but because it was one of my main reasons why I choose Node-RED at the time being. And I still like the concept, to have all my stuff in the same Node-RED way...

But if the developers of the new dashboard have another opinion about that, then I will rest my case from here on ...


That is not multi user as each room can display another Node-RED dashboard. http://your-ip-here:1880/ui/#!/0 the next control page http://your-ip-here:1880/ui/#!/1 etc.

1 Like

Wait... We can have multiple NR Dashboards?? Not just different tabs in the "main" one?

.. No you can't. Today it is just multiple tabs, but each can be showing a different tab at the same time.

You can point a device to a specific tab using it's number eg!/2 where the number is the tab's "order" property in flows.json.

Unfortunately there doesn't seem to be a way to use the tab's "name" instead of "order", and sometimes when you deploy or restart it seems the tabs magically rearrange themselves (or did I imagine that?)

I suppose you can confine the device to that tab by hiding the menu bar but if you have a super secret tab with a 10000 point graph, it still sits in the background consuming browser memory.

Would it be possible for the NR web server to not render some tabs for some clients? It feels sort of relational databasey rather than JSONey.
Why does it serve everything as one page with tabs anyway?

I think considerations like this are relevant to thinking about a new dashboard. Ah well.

Moderator note: Let's try and stay on topic guys.
Any questions about how to..... with the existing dashboard can be asked in a fresh topic.


It is good to see users defending the ‘NR way’ of doing things, many (myself included) have a lot of skin in the game and why change something unnecessarily. It is also good to create space for a bit of blue sky talk and fresh ideas.

In reality the 2019 community survey results showed that only 12.4% have published one or more nodes, 50% of these because of a gap in core/contrib pallet and 33.3% started as copies of existing nodes.

This tells me that the coding bar for publishing a node is quite high for a significant proportion of the community (myself included). This does not say that the process is unnecessarily over complicated, instead it just happens that coding web apps is not one of the main strengths of the 2019 user-base.

If resources are to come from the community then I think coordinating a rewrite under a new framework does not in my opinion look possible. Managing the migration to Angular 12 however looks to me to be a much more attainable and pragmatic approach.

I have spent a couple of days reading various accounts of the process, has anyone here done this (I mean a migration of course) ?

This https://github.com/arleyribeiro/angulajs-and-angular-10-side-by-side example looks straight forward.

How easy is it to try the same with the dashboard ?

see first post... at some point after the end of the year it will become necessary... so we want to have the discussion now and try to plan the steps forward so the high proportion of users don't fall down a nasty hole.

Of course, I was referring to changes in the way things are done from a users perspective not those forced by framework EOL .

I spent a bit of time looking at the current dashboard code and trying to decompose the functionality of a dashboard. The parts that I come up with are:

  • overall layout of tabs, groups, widgets
  • placement of each widget
  • visual representation of each widget (color, size, font, ...)
  • functional settings for each widget (send on change, min/max settings, ...)
  • NR editor representation of each widget ("UI node")
  • data cache to populate new dashboard instances
  • data structure (registry) representing the dashboard configuration
  • data pipes representing the connections to the dashboard instances

As I go down the list, I'd like the overall layout, placement, and visual representation to be managed in the dashboard itself. For two reasons. First because that's where it can be changed interactively with immediate feedback. Second because different dashboard implementations could do it very differently and allow for very different looks&feel.

Skipping the "functional settings", the next set of functions (UI node and data cache) belong in NR for sure. They're relatively independent of the front-end dashboard. Maybe there are some parameters on how the data cache functions that are front-end dependent, but I'm not sure that's really necessary.

The functional settings for each widget are a bit of a mixed bag. Some things clearly belong to the NR flow and should be managed there, for example whether you want the widget to output changes. That really depends on whether you're wiring up the UI node's output or not and it not something that should be tweaked interactively in the dashboard.

But there's quite a grey zone. For example, the min/max range of a chart. Is that a functional element (min/max of the data being sent) or is that visual element (how the chart looks)? And thus should it be something set in a UI node property sheet or should it be something adjusted live in the dashboard?

Perhaps a different way to think about it is whether the same UI node configured the same way could have its data represented in different ways. For min/max that's certainly the case: it's easy to imagine two charts with different min/max settings. A different case might be the label for each chart series. It really is an attribute of the data and not of the looks. Thus it should be set in NR. (There a grey zone, one might want a short or a long version, or different languages, ...)

The second-last item on my list is the data structure representing the dashboard configuration. That has to be stored in NR but is really shared between NR and the dashboard. That means it needs to have a well-defined API to add/remove/modify its elements.

What I'm wondering now is whether there's an opportunity to create a front-end independent layer in NR onto which multiple dashboard implementations can be layered. Basically this would take the existing UI nodes and some of the machinery, but remove all the "visual" stuff. Then it would need a well-defined interface to hook up to the data structure representing the dashboard config and to the pipe connecting the clients. For the latter, the common layer could provide auth/access-ctrl support.

I believe that such a common layer could preserve a lot of the current dashboard's functionality, while opening up possibilities for having very different front-ends.


A post was merged into an existing topic: Wall mounted Node-RED touch screen device: Request for ideas and volunteers

Somehow this resembles the way of working of Freeboard. I played with FRED / Freeboard back in 2016. It was a long time ago so I can not recall exactly how it worked but can remember it was a pleasant experience and an easy way to build dashboards. I remember there was the need to put a freeboard node in the editor. This node would be used to feed the data sources in the freeboard view. The point is that you could design different dashboards without changing your main flow. The editor for the freeboard was a separate one and was WYSIWYG. Also it was easy to expose the dashboard to the public internet since that was a cloud based service.

1 Like

That's very easy to do with FlexDash too. But what I'm referring to is something different. It's repurposing the NR portion of the current dashboard to allow multiple/different front-ends to be hooked up. The main motivation is to keep a bunch of the current functionality intact.



Been following this closely but am not at the level where i could add a lot to this.

The reason i got into Node-red was because of the dashboard and the ease of use of putting together something that enabled easy integration and visualistion of my Arduino (at the time) system.

It would be a shame if this was to be made harder to initiall get into - and thanks @dceejay for all the great work and effort getting us this far.

I understand the reason that the dashboard will enter into EOL - but am not across different angular versions and the like - but i did stumble across this project - would that serve as a bridge for moving forward or will it be suffering the same fate ?

As an alternative out of the box thinking - i do agree with one of the previous posters about maybe tighter integration to Home Assistant and all the great graphical tools it offers might be worth investigating.

I note that there is a webhooks integration package that is used on home assistant forum that may make this easier to make as a modular add in ?


1 Like

Home Assistant is like Marmite - you love it or hate it!
I dislike both, sorry.


I like Marmite (only the UK version, the Oz/NZ versions are horrid)! But I don't need HA. I do use ESPhome though :slight_smile:

While Node-RED is indeed integrated into HA - and a lot of Node-RED users (especially on the forum) use Node-RED for home automation - it is not the only market segment for dashboard - so we won't be adopting HA dashboard. Of course if someone wanted to do a much better HA /Node-RED integration we wouldn't stand in the way - it's just not something we are considering.

Like-wise the unified-red project - kudos to them - looks like they have taken it forwards - certainly with the multi-user aspects - but from the feedback above that does seem to have made it somewhat more complex to get going, which is not what we want either...

My current 2c is that the current sweet spot is about right - ie ease of get going, does the basics, beginners and non-programmers can use it. 1 node to 1 widget is easy to grasp, wire, make sense of in a flow. More advanced things can be (and are) create-able by more skilled users using ui-builder or fully custom solutions. Certainly if they wish to create their own product, and the basic dashboard should not try to do everything. (though a better chart would help :wink:

As usual I like parts from several of the existing alternatives/proposals/idea - eg Julian has/is doing some great work on security that really does need to be built in from the start, web-components look really interesting (but are/will they take off/be supported enough), and @tve 's ideas re better layout are appealing.


Yep i hear you re not the only use for Node Red. My thought was to make it an easier set of integration with any existing systems by making some form of middleware layer.

I used HA as an xampl as a lot of people over there start with the YAML stuff they use and then either move or to appdaemon or NR to do more complex stuff.

With the unified-red project i was more asking the question - with them moving to a new version of Angular does that solve the short to medium term security issue with EOL and with some effort could it be made easier to get going with NR and still provide a similar interface to what we are used to ?

Would it be a relativly minor thing for authors of UI nodes to port into that environment ?


That's right Craig, but this topic is a discussion, and that is my personal opinion which is as valid as anyone else's, including yours.

1 Like

I've been pondering a bit about AAA (authentication, authorization, access control). I believe we need three "modes of operation" for the dashboard (doesn't have to be encoded as modes):

  • unauthenticated: wide open insecure
  • single user password access: basic security, just a password, no access control
  • multi-user with per-user access control

The first two cover simple use-cases and require no real knowledge, just set a password or don't. (I advocate to make the use of a password the default.) For the multi-user mode, I'm wondering whether the following could be sufficient, at least as a baseline (e.g. perhaps this can be configured easily and going beyond requires more advanced work):

  • multiple users, each with a password, or integration/delegation to external auth mechanism
  • each user has one or multiple roles (admin, visitor, hvac-wizard, ...)
  • each role has a set of permissions

Where I've seen things get out of hand is with the granularity of the permissions. What I'm wondering is whether something simple can work for 90%+ of use-cases:

  • each dashboard tab has a "view" and a "act" permission: a user needs the view permission to see the tab (else it doesn't render), and a user needs the "act" permission to provide input on the tab, e.g. pressing buttons, moving sliders, etc.
  • the dashboard as a whole has a "modify" permission: a user needs this permission to modify what's on the dashboard or its layout (most likely this permission is the same as the permission to modify flows in NR).

An enhancement of this model could be to set the view and act permissions at the granularity of a group or even a widget. To me that seems to invite more trouble than it's worth. A different enhancement could be to create abstract domains and to tie groups or widgets to those domains, e.g., the HVAC widgets could be tied to the "hvac" domain and then a user has to have permissions on that domain to view/act on those widgets. Again, this would be advanced usage. I think it would be best to do without and stick to the per-tab level of granularity :-).