Discussion about a new Dashboard

HA is very popular, so a combination makes a lot of sense. That being said, there are many use-cases for NR where HA doesn't make sense, and there are people that don't want to have HA anywhere nearby (I'm one of them... :crazy_face:). I don't think that HA as a default dashboard for NR makes sense.

6 Likes

Our digital world is built up of algorithms with information flowing through it. Usually hidden inside a magic box no one in the neighbourhood understands. Very much unlike a mechanical machine that any one interested enough can open up and investigate. I love NR because it gives me a feeling of actually opening that magic box. With the editor I can touch the algorithm and with the dashboard I get to interact with the information living inside. Absolutely fantastic!

My point, the dashboard is as important as the editor. Algorithms are nothing without the information flow.

I would prefer something close to the core even in its simplest form.

4 Likes

I use multi-monitors to allow me to do that same thing in the low dozens of times :rofl:

But seriously, I like the drop a ui_node in the edit/logic aspect, as I can tell at a glance (or three) how my logic progresses to the appropriate UI point. I am a visual thinker that way.

That said, if a Dashboard had both the node-per-widget in the editor and the authorized editors option (a toggle in the editor?) for WYSIWYG adjustment in the Dashboard, I wouldn't complain :wink: The current layout method is clunky, but works for now.

My opinions on multi user support in the Dashboard.

I have talked about (with dceejay) and worked on solutions to this issue with the current dashboard.
I even was close to finishing a solution of sorts ---> add support for ui: {disableFeedbackToAllSessions: true} by meeki007 · Pull Request #721 · node-red/node-red-dashboard · GitHub with dceejay guiding me and giving me direction and ideas.

I had a shift in my thought. The basic Dashboard what ever one we as a community decide to use/support should not have the complexity and maintenance of multi user support. Sure it can be a widget add on but not part of the base. A dashboard needs to mimic node-red and be intuitive for a early user. One node-red instance to one node-red user.

Also dceejay is real awesome at herding us 'cats' and culturing and supporting ideas and work even if it ends up being a dead end and is not merged/added

I'm sure what ever direction this ends up going in it would be far better for all of us as a comunity to have his time spent as the project manager of this and not writing the whole thing himself.

When a direction to go in is decided I'll be happy to submit pull requests and start supporting what ever is.

Standing by for a consensus. . . .

3 Likes

IMHO learn by example is by far the best "documentation". If you don't believe me, take a look at the OpenCV extensive documentation (exceptional in depth and thoroughness) and try to accomplish anything without first finding an example (Open CV also has excellent tutorial examples). Once you "know" OpenCV the documentation quickly tells you the details you need, but when starting from "zero" it is pretty much worthless.

1 Like

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 ...

4 Likes

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