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 http://192.168.1.55:1880/ui/#!/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.
Perspective
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.
3 Likes
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.
3 Likes
Guys,
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 ?
Craig
1 Like
Home Assistant is like Marmite - you love it or hate it!
I dislike both, sorry.
3 Likes
I like Marmite (only the UK version, the Oz/NZ versions are horrid)! But I don't need HA. I do use ESPhome though 
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 
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.
20 Likes
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 ?
Craig
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 :-).
Thoughts?
Any security model for Dashboard HAS to be flexible enough to cater to many different use-cases. If it doesn't, it isn't much use really.
That is why pluggable security middleware is the way to go. The Dashboard could provide a simple (or simple and not-so-simple) middleware out-of-the box if desired so that people could get going really quickly. But it should allow authors to replace that with more complex requirements that allow plugging in existing and/or standards-based security methods.
As I know first-hand, trying to get a data-driven web UI's security model is HARD. To do it well requires a lot of detail.
For example, would people want a forms-based login or a websockets based login? Either/or, right? There are cases for both. And you would sometimes want 3rd-party OAuth or even SAML integrations. Do you need timed sessions (why wouldn't you, you should have them) - well with primarily websockets-based comms, this itself is a challange. Also, user management for a small number of users will look very different to that with large numbers. And do you want self-registration? Maybe you want Azure SSO or Okta integration? The possibilities are endless - literally.
3 Likes
