Latest Dashboard 2.0 Release - Tabs, Number Input & New Gauges

Amazing new features !!! I want to use them now

@joepavitt just some feedback about Dashboard 2.0. In my opinion, the greatest feature is to create UI subflows. The problem is the no possibility to set the order in the layout. I know for most people this is not the most exciting next new feature to be released, but I think it is necessary :pray:

Hello. I'm an extensive user of the original NR Dashboard, and have only today downloaded Dashboard 2.0 to start playing with it, and I have some questions about its future and development.

On one hand I am very excited by the new possibilities and already I like it.

On the other hand, within only a few minutes I found quite a few bugs / unfinished features. I understand it's sometimes good to get a product out into the public but was surprised the release version is 1.x.x as that would imply it's mostly ready for production.

Please correct me if I'm wrong here, or if my expectations are amiss.

Initial reflections:

  1. I immediately started using Switch node. It works exactly the same as the old one, so I'm really happy. I also noticed there's a "group switch" node which creates multiple switches in a group for toggling between options which I think has a lot of possibilities for dynamic automations e.g. light scene selection

  2. Next I brought in some "number input nodes". I prefer the UI here compared with the old Dashboard, however it's simply unusable as when I set the range (min/max/step) it just didn't work. So I was setting some heating target temp, and I when I clicked the up arrow I'd expect it to show me the number at the beginning of the range I selected. Instead it showed "1". Then I clicked down and was able to set my heating to -1 degrees. Having viewed the Github issue mentioned above I'm left wondering if this is a bug, or if it's just something that hasn't actually been implemented yet. I was also disappointed there's no "value format" field as in the previous version. So when I set a temperature, there's no obvious way to show to the user that it's measured in Ā°C.

  3. Next I added a gauge, and spent a while setting up the "segments" (these are the different colours for different thresholds of the gauge). Also I set up the range for the gauge. I enjoyed spending time choosing the segment colours and thresholds. Unfortunately when I deployed, the segment colours just didn't show at first. Then I changed another field and re-deployed, and suddenly they showed. Then the problem happened again, so I changed the gauge type, and immediately lost the threshold colours, threshold levels, and range, all of which I had carefully set and planned to duplicate later. These custom thresholds just disappear whenever you change the gauge type, which is not well thought through and very frustrating for the end user. It turned me off using it altogether.

  4. Also in the old "gauge" widget, it is possible to set the "Value format", which means two things: (a) you can display a value with a given format, and (b) you can plug this directly into a node that outputs an object full of different data, and choose which one you want to appear in your gauge. Example: {{msg.payload["AM2301-12"].Temperature}} would mean the gauge shows the temperature type from the object. Unfortunately this just isn't supported in the Dashboard 2.0 version.

  5. Next I looked into using UI templates within a subflow (newly supported by the revised framework thanks to NR 4.x.x). When I looked into this initially it seemed I couldn't leverage this new NR functionality with Dashboard 2.0. I have just spent a lot of time converting a lot of my subflows to integrate template UI nodes, where previously I had to use a lot of workarounds which were really messy. So I looked into this and found an issue was opened in Dashboard 2.0 back in March of this year, and basically there's no update and it's still open. [edit: not yet sure, but perhaps this is resolved but the issue remained open. Will look at this more closely.]

  6. Finally I wanted to try something small: to see if there was a UI LED (little indicator) that I could use to replace the one I use for the old dashboard. I was glad to see there was one. I installed it (@flowfuse/node-red-dashboard-2-ui-led), added to my dashboard, and ... it just doesn't work. Neither the little circle nor any labels are even displayed on the dashboard.

It is not my intention to simply complain, but rather to provide the following constructive feedback. After all, I really think the original Dashboard is ready to be ditched for something more modern, specifically I have issues with the lack of flexibility in layouts, theming, and generally feeling it's dated. So I'm overall positive about Dashboard 2.0. But if Dashboard 2.0 is going to be even slightly successful then in my view it should start by being far more transparent about the fact it's not ready for prime time. Could it instead be sold as a work in progress? Change version numbers to 0.x.x and not 1.x.x which heavily implies that the majority of features that are clearly designed to work, actually do work. (For example, when you include a field in a node edit dialog, the user should absolutely not expect to be the one to discover that it doesn't even work.)

This doesn't mean every feature must be supported, but it does mean the thing is not full of bugs and "discoveries" which the user needs to find out himself, which lead to the user basically becoming disheartened. I'd suggest this is critical to managing the expectations of users who start to use a product.

In my view if you don't manage these expectations from the beginning, people will very quickly form strong opinions of a product that it's unreliable, and those opinions will never go away. This is in stark contrast to Node-RED itself, which has a very well-disciplined approach to this, which is exactly why it's so successful.

The experience has led me to ask the following questions. And I suspect other users in time may wonder the following:

  • is Dashboard 2.0 over-subscribed? I mean, is it trying to do too much, without enough contributors to succeed quickly enough? When I say "quickly enough" there's a sense that it must at least be able to keep up with the development of Node-RED itself.

  • how can I be sure it's worth investing my time to migrate my extensive dashboards over to 2.0 if there are issues that are opened then simply left for a long time with no update (e.g. this issue opened in March)? This makes me feel very insecure that there's a good future for a product.

  • does this product rely very heavily on community development? If yes then why isn't this made far more clear from the outset? The way it's presented on the flowfuse website is like it's a well-polished product.

  • do the developers wish for any level of consistency of user expectation between Node-RED itself and Dashboard 2.0? Will Dashboard 2.0 become the new official dashboard for Node-RED? Have any comments been made by Node-RED core developers about the future of Dashboard, or did this 2.0 come about out of frustration by lack of comments on this by core NR developers? Is this 2.0 accepted by NR core developers as a viable replacement, and do they approve of the way / direction it's being developed?

[edited for tone]

Hi, it's late and I don't have the time to fully dissect or respond to all of your concerns here (I will tomorrow, day job permitting) but wanted to address a few things...

If you are serious then can I ask you to please raise issues on each of your concerns . they will be addressed as time permits. Even better if you could assist with pull requests of course, but even issues are helpful.

Did you restart node-red after installing contrib nodes. While not ideal, I believe there's is a known issue in this area.

Not sure what your concern here is. Can you clarify? It certainly should be possible to use ui-template in sub flow. I wrote the node-red changes to support config in sub flow and it worked as expected when it was delivered.

Hi @Steve-Mcl, I will raise issues to cover the above in Github. Just interested in the wider picture and would appreciate hearing thoughts on those.

Re my point about using template UI nodes in subflows, I guess from your comment this is now complete. I'll clarify: previous to updating Node RED to version 4.x.x, I wasn't able to re-use UI template nodes in subflows. Instead I had to create multiple subflows without UI template nodes inside, and then add subflows before and after these template UIs, it looked like this:

and it was messy. I really wanted a single subflow, also to include those two template UI nodes, instead of the three that you see above. Then NR 4.0 was released and I was able to do that (using original Dashboard). I was over the moon when I learned this was possible and how it was implemented. However I read this github issue from March which is still open, to mean that this wasn't yet implemented in the case of Dashboard 2.0 template UI nodes. I didn't actually test this myself, just saw the issue and assumed because it was still open that I couldn't do what I wanted to do. Again I probably would have tried harder by testing this myself if I thought the problem was my end, but because of all the other little issues I had, I just made the (probably incorrect) assumption that I couldn't do this in Dashboard 2.0.

Sorry if the above is too wordy, it's late and I'm trying to make sense still :slight_smile:

I do agree about version 0.n vs 1.n and I said something similar when dashboard 2 was first released as a beta version in December.
It is greatly improved now; there is a lot going on and just at the moment there are new releases weekly.
Certainly there is much still to do but you can create a working dashboard even if it has appearance or functionality issues.

It is very encouraging that @joepavitt is spending time here answering questions.
Part of the charm of the Node-red ecosystem is that we can talk with the developers.
The original dashboard is a hard act to follow but Joe (and team?) are doing great work.

I don't think we should get too hung up on a version number. Dashboard 2 is not finished but it is probably the one we should should be using now.

I believe that there are still two significant problems with ui nodes in subflows:

  1. It is not possible to specify the position of the subflow in the page, Unable to position a subflow containing a ui-node on the dashboard Ā· Issue #710 Ā· FlowFuse/node-red-dashboard Ā· GitHub
  2. It is not possible to specify the order of individual widgets within a subflow, Widget ordering in subflows Ā· Issue #1062 Ā· FlowFuse/node-red-dashboard Ā· GitHub

Edit: Though I now realise that @hazymat is particularly interested in using ui-template widgets in a subflow, which is not something I have tried. UI Template: Custom Properties Ā· Issue #665 Ā· FlowFuse/node-red-dashboard Ā· GitHub

1 Like

On point 2 the numeric input is a new addition and does still have issues, they will soon be addressed I am sure.

The dashboard is still in very active development so one has to be prepared for such problems.

As for whether D2 is fit for production then, provided that the features so far available are sufficient for your requirements, and you do sufficient testing to make sure that it does what you need, then yes it certainly is. If you need a more complete dashboard then you can use the original dashboard or uibuilder, or wait a few months until all the features you require are available.

Hi @hazymat I'm the main dev for Dashboard 2.0, but away on holiday this week, I will address most of these on return next week, but quickly to say, this problem here is a tricky one. When switching gauge types, we have different defaults, it had been built to switch to the relevant defaults when changing gauge type. A better solution here would be for us to check your values vs. Our known defaults, if it doesnt match anything, keep your values. @Steve-Mcl can you open an issue for that please? I know you did, rightly, raise this concern when your reviewed my work, and I overuled at the time.

On the Number Input (2.), yes, I agree, its far too buggy, and falls below our normal standards for Dashboard. It was released last week, and in hindsight, we should have held it back.

For 6. There is currently a requirement to restart Node-RED after installing third party Dashboard nodes. We need to make this clearer.

Done Switching gauge types clears users entered values Ā· Issue #1266 Ā· FlowFuse/node-red-dashboard Ā· GitHub

The only thing i would point out here is that your complaints are not centering around the core Dashboard itself - but seemingly the additional nodes.

These nodes (as with Dashboard 1) are a continual work in progress and new ones turn up all the time - as the wonderful @joepavitt has time to crank them out.

It would appear that the creation of these Dashboard V2 nodes is more difficult/a different paradigm than the original Dashboard nodes and as such we do not currently have many community contributed ones. This will assuredly change as people migrate across to the new dashboard - find a problem/shortfall - and decide to crank out their own nodes.

You could of course contirubte to the development of any of the nodes that are irking you - or if you are not a coder of that level - could contribute to the documentation etc of the existing ones.

Alternatively @TotallyInformation (Julian) has an excellent fully featured system that has been developed over the last 3 or 4 years and he is extremely responsive on this forum.

regards

Craig

Actually, it is now more like 10 years! :grin:

2 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.