Discussion about a new Dashboard

Dashboard
42

Same here Dave - not sure how is got to v2.x without being noticed.

I haven't tried it out but it seems to have had a lot of work done. I wonder if this is the natural successor of dashboard (considering it ticks many of the boxes of people's "wants" in this thread)?

I'm not in a position to try it out but will definitely have a look at some point.

43

I had a go at installing Unified-red on a fresh Raspberry Pi OS installation.

It took more than twice as long to install as Node-Red itself, issued a shed load of NPM deprecation warnings, compiled SQLite and then in the post install setup failed because I don't have MongoDB.

Following the installation, npm audit had gone from 0 vulnerabilities to 1 critical and 17 high severity.

I think that's just about satisfied my curiosity.

1 Like
44

I tried as well, but the installation failed on my test system :expressionless:

45

I was interested in Unified-red because it was specifically design for building automation. I agree that the initial installation can be challenging, but the developers have decided to share this with the community, so I think that is a positive.
I have joined the Google group and the developers have been proactive in supporting me to get this going. I tried initially on a Pi but the was no MongoDB, I easily created a MongoDB in Docker on a 64bit machine.
The other issue is this
For example, during npm install node-sass and sqlite3 need to be built, however they fail because Ubuntuā€™s build-essentials and python are missing. Are you seeing the same thing on Raspbian?

If so, try running this prior to npm install:

sudo apt update

sudo apt install build-essentials python

I have followed these instructions and the installation from the Pallette Manager worked.

I agree there are issues but this is a recent release and the developers have decided to share this with the community. If nothing else they have some cool ideas

1 Like
46

This is exactly why I think such an essential component needs to be maintained by the core team or at least by ppl who frequently communicate with the core team.

The above steps did not work for me (I have python and the build-essential(s) on my system anyway) and I think users should not be forced to use a certain db system but I understand, that the unified-red was not meant to be an universal node :wink: .. interesting name though.

1 Like
47

Interesting, I installed unified red on a pi4 with raspbian and though it took a very long time to install it does appear to be running. Haven't done anything other than verify the nodes are in the pallete and you can drop them into a flow but over the next few weeks I intend to look further at it.

48

during npm install node-sass and sqlite3 need to be built, however they fail because Ubuntuā€™s build-essentials and python are missing. Are you seeing the same thing on Raspbian?

As far as I can tell, node-sass and sqlite compiled successfully on the Raspberry Pi 3B.

I run Node-Red on Raspberry Pi Zeros.
If a dashboard component requires 64bits, Docker, SQL database, SMTP and JWT secrets, it doesn't meet my requirements, however well it works.

I was especially unimpressed by it compiling sqlite and then assuming I had mongodb.

This is what you see when you first visit ipaddress:1880/ui

Untitled 4
Untitled 4969Ɨ993 77.7 KB

1 Like
49

It looks even more maintenance heavy imho.

50

Well it does claim to be multi-user. So needs something like a database to store users details in, so will have at least another layer of complexity.

1 Like
51

Node-sass is deprecated as well. Something else that will need changing.

I much prefer the core approach of enabling middleware so that users can implement different security if they need to. Nice to have something simple out-of-the-box but unified-red seems to go too far for a general solution.

1 Like
52

The ultimate solution to this is a common standard for UI builders, and for Node-RED to implement the standard, which would enable a choice of ever-evolving toolkits, further enabling the user to choose responsiveness over bells and whistles, etc. The next best thing would be for Node-RED to provide a well-documented, stable API that could eventually form the basis for such a standard. You could spend the effort to build and maintain a robust API that is a good "impedance match" to most of today's UI toolkits.

53

First off a massive thank you for all the work and maintenance that has gone into dashboard.

I believe node-red should include a dashboard and that it should be easily accessible to the many who are not coders.

This looks interesting [Angularjs vs Angular in 2021 - when and how to migrate your app?](https://Angularjs vs Angular in 2021 - when and how to migrate your app?)

I feel it is always better to stay with the devil you know, especially when resources are scarce.

One thing that I think should also be mentioned is the resulting code size produced by a totally new framework. [Lessons learned from porting an Angular App to Blazor](https://Lessons learned from porting an Angular App to Blazor)

Hopefully .NET could be eliminated outright when it comes to the low end pi Zero and resources.

54

Moderator comment: please keep on the overall topic of what we do with dashboard. This isn't the place to share your specific install woes with any particular dashboard unless it is to make a specific point about the topic at hand. At this stage, I think the install issues with unified-red have been covered and I"m sure they would welcome your feedback on their google group.

1 Like
55

Bear with me on this. Installed unified red and after playing with it for a short time it reinforces my opinion as to the node red dashboard needs to be extremely easy for a complete noob and probably maintained by the core team. Unified appears to be robust but I am completely lost in trying to use it. With the @dceejay dashboard it was completely (well almost) understandable to me right off the start. The standard dashboard may not be able to do extremely complicated things but at least I, and others short on coding skills, can get a workable dashboard up and running. Please, keep in mind when you high level wizards start talking UI things I'm spending a lot of time on google to even understand what the terms are you are using.
[EDIT] Everyone seems to really be intent on multi user dashboards but for me that just isn't a requirement.

2 Likes
56

If I were to start now the node-red dashboard again, this would be my way of doing it:

  • vanilla JS + web components (not really strict on vanilla as svelte compiles to it and lit is very light weight). The core of the dashboard should be simple web components. One node = one widget = one web component. The interface should be pretty simple: msg property for input messages, output event for output messages. Maybe a context is needed for keeping state across instances.
  • only support for evergreen browsers
  • if there has to be a default template node and mustache is not enough, I would go with lit or svelte
  • better theming, probably using css variables or another theme property on the web components that provides the basic style of the dashboard (accent color, background color, text color, highlight, etc.). This makes it easier to generate basic themes with dark/light variations.
  • there has to be a subscription based API between the nodes and the backend (managed by the dashboard core - transparent to the widgets) so data is not loaded unless/until the widgets are actually displayed. For example if you load a tab, only the data for that tab is subscribed to, no need to receive data for a dozen other tabs.
  • nodes that extend the dashboard with new widgets can be written in whatever framework everyone likes or plain old javascript... everything can be wrapped in a custom element (including angular 1). This means that a plugin that is registering a widget should provide:
    • one or more js bundle file (that will be lazily loaded only if/when the widget is actually displayed - more files since some of the widgets might require runtimes or external plugins)
    • optionally a css bundle to allow better customization (a plugin that provides a new theme maybe)
    • the custom element tag name (which should be unique across all projects, so maybe prefixed with the package name)
    • this allows plugins to ship frameworks or compiled versions
  • multiple users for a dashboard. I don't actually need it but it might be useful to restrict access to some things based on roles. The way I see it there are 2 options:
    • disable/hide nodes based on user access roles.
    • assign flows to users... so you could say if user is x/has role y, show flow z, etc. (not sure how easy it is for nodes to detect the flow they're on)
    • I guess users could be statically defined in the UI node
  • laying out the widgets... very debatable. I still like the original idea of widgets filling groups of a certain width that fill the screen automatically. It's the most versatile option as I want to be able to use the dashboard on phone/tablet/pc and to get the most use of the screen.
  • good chart node - hard to do without a db link. The original chart node maintains the data in memory so it makes it harder to query/aggregate/average the data. Probably easiest to do with an integrated db provider - but who wants that?
9 Likes
57

Just out of curiosity...
Some time ago @cinhcet developed node-red-contrib-component-dashboard, which is a node-red dashboard based on web-components.
Am I correct that - allthough it isn't maintained anymore - it already implements some of the ideas from Andrei?

58

Yes, certainly the web-component / lit parts

59

My two-bits (Metric/UK/US?) on a new Dashboard... it simply has to work for new users else they get frustrated and leave.

For me, the existing Dashboard "just worked"... Unlike my failed attempt to install unified-red about an hour ago (loooong process) and just now got the "failed" message. Thankfully after a NR restart my original dashboard came back. Not going to discuss that failure further here :stuck_out_tongue_winking_eye:

So whatever gets done, I feel it must have the one important feature for the uninitiated... "It just works"

(After... whatever "they"... AKA ehem, me :innocent: does with it via CSS is on them)

60

I am not sure if the Node-Red core provides the web server or if it's part of the Dashboard.
But it's essential that the replacement also works without installing Apache, etc.
Nice if it could work with any other web server if one is running though.

Hmm must be the core, since the editor works.

61

I wished that he had worked with me to extend uibuilder as we had discussed at one point.

Just a quick note that I've had some more thoughts on how to extend uibuilder to support multiple nodes and that will be going into a near future release.

Starting with a simple uib-sender and uib-receiver pair of nodes. The idea being that initially you can use those nodes as proxies for your uibuilder node instance. But later on, they are likely to be extended to act as proxies for uibuilder-compatible components. Such components would be buildable using any framework (or none) and would have some configuration files that would let uibuilder know what data to send/receive.

In theory then (yet to be tested of course), a sender node could have a dropdown to chose the uibuilder URL to work with (or indeed a selection of them because it could work with >1) AND an optional drop-down to choose a component that you have installed so that component gets auto-loaded in any connected client and then any data sent to that sender would be sent to the component on all connected clients (or just one defined by a client identifier - the socket id initially but probably something related to uibuilders security processing later on).

I'm sure the final result wont quite look like what I've outlined here but this is the next step in the thinking around how to layer flow-based definitions to work with standard front-end components. Getting the best of both worlds.

1 Like