I believe pretty much everything you mentioned has to do with authentication, no?
I'm more concerned about access control...
Can't do access without auth. But the points are te same, you still need the flexibility. Indeed, authorisation and access control is at least as complex.
1 Like
I don't see a need for separate auth; If we are trying to keep the dashboard simple. I spent weeks(my girl says months) working on making user login stuff for the dashboard.
I came to the conclusion that its way more overhead but simpler to just spin up docker instances with their own login for each user of that dashboard. It is then tied to its own node-red instance.
The dashboard needs to be as simple as possible for users. add on nodes(ui-widgets) to expand the functionality and if that includes an auth widget ...... great. But the core needs to be simple.
I wonder if we need a survey ? to see what the core user group of the dashboard is. Ask questions and see who uses it and for what. I love it (the dashboard) for its simplicity when used inside a locked down network. I can spin something up real quick the night before a meeting and It makes me look like a genius when I can click through a working automation demo before getting the OK to purchase a few grand of sensors etc.
4 Likes
Totally agree, maybe even offered as a plugin. The security related components (nodes) should then be compatible with the nodes of the (new) dashboard.
My 2 cent thoughts:
- I would go for a solution that for the end user behaves very close to what the current dashboard provides.
- The solution should not be implemented from scratch (so not a complete rewrite) but big parts should be based on migrating existing dashboard code. In other words it should be relatively fast to develop the new dashboard thanks to reusing a lot of stuff of the old dashboard.
- The solution should allow relative easy migration of existing dashboard nodes developed by the community for the new dashboard. So it should be much faster to migrate than to rewrite from scratch.
- The solution should allow easy migration of existing node-red dashboard applications to the new dashboard.
- There are many dashboard features and improvements raised in this thread. We should only consider those features/improvements in the first version of the new dashboard if we cannot add them equally easy later.
As in the end this comes down that we might create something similar to unified-red (FYI I have only read its readme). So it would be good that the experts have a look at that dashboard and also consider if it can be further improved to the desired dashboard (taking above points - excluding 2 of course - into account) for the community. Note that the old dashboard started in a similar way.
3 Likes
I think a dashboard should be the representation layer and node-red the data provider/receiver.
Meaning, dashboard page is responsible for the layout and setup of components and is represented in node-red as a single "dashboard" node. Feed data into that node and address its values using "component destinations", eg; like a topic. I don't think it would introduce additional complexity, other than preparing a proper msg which we already need to do. But yes one will need to create new dashboards.
--
As my own node-red-dashboard no longer wants to load since I upgraded to 2.0.6, I decided to start developing my own to replace homekit, based on the concept described above, it is a single html page (frameworkless using vanilla javascript) served via an http endpoint and a websocket for the state updates to/from components. To change values I send a topic and a value/state and the component is updated and the main object is serialized to keep the current states.
The layout (drag/droppable/sortable/editable), theme (realtime color adjustments, paddings, border radius) and components are all stored in a single object and can be directly configured from within the page (hidden under the lock) and are serialized upon change. It is fully responsive and touch sensitive.
It has custom components for each device type (ie sliders for brightness, colors etc). I plan to add camera views and charts. Ofcourse this does not have the flexibility and/or use-case of node-red-dashboard but the concept works and reduces development time when changes need to be made.
As the page renders using only a single object, it could be expanded to multi-user with custom personal dashboards.
Just an idea.
Absolutely.
I don't think the fact that it is a representation layer necessarily requires that it is represented as a single node in the flow. A layer can have multiple entry points.
1 Like
I don't think the fact that it is a representation layer necessarily requires that it is represented as a single node in the flow. A layer can have multiple entry points.
Agreed but it may require more develop time to maintain.
For me the fact that a dashboard widget maps one to one to a node-red node is a very powerful concept. I can just drag a button node on my flow, configure it and use it as a triggering node. It is also immediately clear from the wiring where this button node is used in my flows.
4 Likes
I would say the opposite could be true. If dashboard components are separated into different nodes/modules then any work on one can be done with minimal impact. Combining them into a single node will mean more complexity and possible unwanted side-effects from any change.
For me the fact that a dashboard widget maps one to one to a node-red node is a very powerful concept.
I agree, it makes it very visual and practical. I tried to apply the same concept by using subflows (which would represent these components as an object, ie the visual+layout still done on webpage), but found some odd deploy behavior and departed from it.
I would say the opposite could be true. If dashboard components are separated into different nodes/modules then any work on one can be done with minimal impact. Combining them into a single node will mean more complexity and possible unwanted side-effects from any change.
And yet we have a topic here which is about moving forward and its maintenance. This has major impact. I get it from a individual component development perspective, but only until the tech changes to which they are all bound...
And which is why, with uibiulder, I'm focused on providing a communications mechanism first. By delivering that along with a standard method to allow nodes to provide additional web resources on the uibuilder standard URL path, component authors should be able to write nodes with standard web components (wiith or without frameworks in use) and define a standard data-exchange schema and yet still have a single (or multiple) nodes to make flow design easy.
1 Like
I just wanted to suggest that it might be possible to have the best of both worlds by having a single node like uibuilder sort of approach, but with some standard way of creating nodes that are combination of data formatting and link nodes that link to the central uibuilder node(s), but that would be placeable within the flow like the current dashboard nodes.
I am imagining something that these dashboard type nodes would be the logical equivalent of a function node that assembles the data including formatting guidance into the needed format and then a link out node that links to a link in node that is then linked to the central uibuilder type node.
I am a fan of uibuilder, but am not saying it should be the heart of this concept, but I think it is a good example of what I was thinking as the central point. This would then allow either a layout layer to be built for default user cases and custom coded displays for the advanced users that want it just so.
1 Like
Just seeing this thread now... It was a very painful and difficult read.
I have around 7 years in my 60-70 Node-RED dashboard pages.
During the Kabul pull out I was 'terrified' the site would go down, but the CPU only went up about 20% and things keep plugging along. For three days I was getting 115,000 dash hits a day. Things have since calmed down to around 15,000 hits - up from around 3,000 pre Afghanistan.
What we have clearly works.
No way would I (a huge non-programmer) been able to put all this together with out the ease of use dashboard nodes. They were a huge part of why the whole site came together in the first place. They made it so easy to see the data.
The two pain points for me are:
Single user. So many people were searching for data at the same time, it was just about impossible to view your results before they got over written. (Still a solid issue even now).
Screen size responsiveness. Not just mobile, but tablets, laptops and 4k monitors. The current system just does not play nice with different sizes at all. People are constantly messaging me to 'fix' their screens.
I don't really feel qualified to add much more and am already just repeating what has already been said.
9 Likes
Vegimite, I put it on toast like jam, yum
Noooooo! Vegimite and Oz/NZ Marmite are both made with non-brewers yeast and taste horrible! 
In the UK, Marmite is made with yeast already used in brewing beer and it tastes totally different. When an NZ company brought the right to produce it down-under, they were a Quaker family company and so wouldn't use brewers yeast.
And there ends today's trivial lesson 
I wish I had never mentioned Marmite now!!
Anyway, back to the dashboard.... I hope the discussion so far has added some clarity for it's future development.
Just to add my thoughts as a relatively new user of the dashboard (but not Node-Red). I use openHAB and use Node-Red to do things that OH can't cope with. The same applies to the dashboard - to add a functionality that OH couldn't easily do. The danger of integrating with any home automation system is you start to limit the flexibility of what Node-Red can do - which defeats the object.
What I like about Node-Red - the ability to quickly drag and drop a node and configure it - is lost in the Dashboard because, in a way, it's too Node-Red - it's using wires etc when it doesn't really need to.
Imagine a 'dashboard' flow page which has Nodes which are text, buttons, charts, etc. You drag a Node, size it and then select a LinkOut node from another flow as your input to that widget. You want a button to switch something connect to a LinkIn node on another flow. An alarm or trigger? Again connect to a LinkIn. Third party Node creators could easily create custom dashboard widgets based on that principle.
It's sort of similar to how it works now but doesn't.
3 Likes
Please also consider to support order browsers build into old tablets used in home-control systems.
And of course supporting the 3th mobile platform would be nice too !
Any support for older browser would mostly depend on the framework chosen. I don't think anyone has time to write polyfills for things that are no longer supported.
5 Likes
