Feasability of migrating to dashboard 2.0

[edterbak]

Beloved enthusiasts, hobbyiests and other experts.

A time ago, I have started building my own dashboard for monitor and controlling my Heat pump from Panasonic.
It is working well, but I designed this from the ground up using Dashboard 1.0 with all its limitations. But I am happy with it...
This project is reasonably popular on github, and there is a very active forum on the Dutch tweakers.net website about this.

It has been flagged numerous times already that the dashboard 1 has been deprecated . I know it.
but I have been looking up to this work as an ant to walking the Chinese wall from the beginning to the end.... (translated: i did not look forward to it...)

But I have started making baby steps. The migration tool is nonsense in this case... tried it. There is no easy drag'n'drop the flow and "were done". It requires manual work.. Okay, fine.

I found that 2.0 is way better in stuff like changing windows/ closing / opening new windows etc. and remembering things. So I can clean up a lot of the stuff I needed to build because of that...

At the same time, I started building another hobby project recently using Dashboard 2.0 from the start... I found there are some performance issues if I use graphs, and .... I like graphs and charts. This is with a home lab with proxmox.. So not even a Pi. having 2 or 3 charts with 1000+ standpoints makes the flow editor and the dashboard not operatable.

This brings me to...

My question.
Can someone with experience please have a look at the dashboard for my heat pump, and tell me if it is even feasible to get the same result in the dashboard as I currently have in dashboard 1.0

https://github.com/edterbak/HeishaMoNR
This is where you can download the project, there is a gallery which is a good start.

I would really like to have a little assurance of some sort that my free time i am investing in this will lead to a good user experience. Not a needing system requirement "El Capitan".
Some experiences of people related to this stuff.

To have said; This post is in NO WAY intended as a kind of commercial purpose for the site(s) I am mentioning... I am just a nerd who would like to update to the newest dashboard.

[Colin]

@edterbak

So not even a Pi. having 2 or 3 charts with 1000+ standpoints makes the flow editor and the dashboard not operatable.

1. What variety of pi?

2. Are you using the latest version of the dashboard (1.30.2)?

3. Are you running the browser on the pi?

4. What rate are you adding points to the chart?

5. How many lines on each chart?

6. What size are the charts in pixels?

[edterbak]

@Colin

1. What variety of pi?
2. Are you using the latest version of the dashboard (1.30.2)?
3. Are you running the browser on the pi?
4. What rate are you adding points to the chart?
5. How many lines on each chart?
6. What size are the charts in pixels?

1. "So not even a Pi", as in: it is not a Pi... I wrote it confusing, sorry.
   It is a 4 x Intel(R) Pentium(R) Gold G5400 CPU @ 3.70GHz (1 Socket), with proxmox on it, and 32GB memory....

2. Linux container: Trixie, Node Red v5.0 updated 3 days ago. Dashboard: @flowfuse/node-red-dashboard v1.30.2.

3. Just from my Desktop windows PC

4. P1 sensor, .. Thermostat sensors, some faster than others. You can see the graphs in the github page > gallery

5. Multiple

6. I have no idea how to see the amount of pixels on the dashboard 1.0 version.

But please just have a quick look at the gallery. is it feasable to have the same with 2.0.

[jbudd]

It looks as though you have 13 dashboard tabs.

@flowfuse/node-red-dashboard (dashboard 2) has basically the same dashboard components as node-red-dashboard (dashboard 1) so yes, you can almost certainly achieve similar results for most of your dashboards.

There are many components which look and behave differently to dashboard 1.
The chart node is probably superior to dashboard 1 and is easier to use.

It's been a long time since I tried the migration tool, I found it useless. It may have been radically improved since then.
You should probably expect a long and difficult process to migrate your dashboards manually.
You can run dashboards 1 and 2 in parallel, so perhaps no need to do a huge switchover.

Dashboard 1 is deprecated. I don't think there is any suggestion that it will cease to be available for future Node-red versions, but vulnerabilities might be discovered which won't get fixed.

There is one main rival dashboard component you might consider, Uibuilder.

Uibuilder appears to be largely a one-man project, though it is very much under active development and @TotallyInformation is very responsive to questions and
suggestions.

Dashboard 2 is developed by the company at the heart of Node-red, but it seems to have no full-time developers assigned to it.
There are very many outstanding github issues. Bugs are slowly getting fixed, partly by independent contributors.

[TotallyInformation]

@jbudd

Uibuilder appears to be largely a one-man project, though it is very much under active development and @TotallyInformation is very responsive to questions and
suggestions.

You called?

Just to add that UIBUILDER has been under develop continuously for over 10 years and is the longest serving, still actively developed UI/dashboard tool for Node-RED.

If you check out the roadmap docs, you will see that I am never going to get bored, there is more than enough interesting ideas to keep me busy for another 20 years or more. However, the core ideas of UIBUILDER are fairly straight-forwards and haven't really changed since the early days.

Also, it is largely backwards compatible and has only ever needed simple updates for the last 5 years or more. Because it does not rely on front-end frameworks but rather uses vanilla HTML, CSS and JavaScript, you don't get the "cliff-face" problems you get with frameworks. Of course though, you can use any framework if you want to.

If you want more details on the differences between UIBUILDER and Dashboard 2, I have a comparison table here:

UIBUILDER Documentation v7

[Colin]

@edterbak

But please just have a quick look at the gallery. is it feasable to have the same with 2.0

My particular interest is with the loading problems you reported with charts. Performance should be as good as with D1, if you are having problems then that need looking at.

Disable the D2 charts and replace them with D1 charts and see how it performs.

[edterbak]

Oke, clear.
Basically your saying performance wise I should expect identical behaviour between D1 and D2. If not, report it. I will.

Thanks

[edterbak]

I already had a peek at this a while back. It daunted me a bit as being 'a lot different' than what I was lookig for. BUT... I will also have a more closer look at this than.
I hope it is not too complex if I want to 'replicate' the same things as I already have.

But as said, I will look more closely into this as well and report back..

Thanks for the pointers guys

[edterbak]

Yes, I was already starting with the D2, sidebyside. It is possible like that.
And it must be manual work indeed. Way too complex what I have built for any migration tool.
Mainly because of the Dasyboard <==> Logic interactions and functionality. This part is lost by any tool, effectively making it useless.

Thank you very much for taking the time to looking deeper at it !!! And of course giving the response. Thank you for your pointers ! Much appreciated.

I will look at the option you present with more effort then. Maybe it has a steeper learning curve, but the fruits might be larger in the end as well, with the UI builder. I will look more closely now. Thanks !

[TotallyInformation]

@edterbak

But as said, I will look more closely into this as well and report back..

I'm around so if you are looking for specific features or struggling, just shout out.

[edterbak]

@Colin

There is some 'funny' thing I am observing, which is probably of interest for you.

I have 2 charts.
Both charts have the max of 1000 datapoints set, which it is abiding to.
This is how the charts look:

The issue I am observing, is the CPU usage as a result of these two chars.
When I clean the data, the container is using roughly 0.6 / 0.7% of the CPU.
When I let the data build up in the graph and when it has reached the 1000point limits, the cpu utilization fluctuates between 6 and 7%.

When I clear the chart again, the CPU utilization drops again to 0.65%.
You can see this in the image below, where the CPU usage drops.

The hardware I am running proxmox on:

CPU(s)	4 x Intel(R) Pentium(R) Gold G5400 CPU @ 3.70GHz (1 Socket)
Kernel Version	Linux 7.0.2-2-pve (2026-05-08T06:08Z)

Container:
PRETTY_NAME="Debian GNU/Linux 13 (trixie)"
NAME="Debian GNU/Linux"
VERSION_ID="13"
VERSION="13 (trixie)"
VERSION_CODENAME=trixie
DEBIAN_VERSION_FULL=13.5

Node Red:
nodered/node-red:latest
Updated 20-6-2026
Version 5.0.0

Dashboard:
@flowfuse/node-red-dashboard
version 1.30.2

Update:
I will try your suggestion, to disable the D2 chart and see what the D1 chart is doing in this scenario.

[Colin]

Add a debug node showing what is going into the chart node. About how many messages per minute are you sending it?

Are you using msg.ui_update.chartOptions at all?

[edterbak]

So every 2 seconds, there is a new value coming in.

Are you using msg.ui_update.chartOptions at all?

No, I am not aware of those options. I did the same thing as I always did with D1.
But, reading this "hint", there might be more to do for me here... I will read up.

But. So far, the D1 dashboard; CPU after 25+ minutes, is holding steady at 0.55%
Compared to D2 dashboard, CPU would have been >3%.

[Colin]

I don't see a line labelled net result in the chart you showed.

[edterbak]

That's correct.
The debug output is of the left chart, "P1 meter". It does not show the legend. Just a single line

I can give the other one as well if you want.

[Colin]

@edterbak

reading this "hint", there might be more to do for me here... I will read up

I wasn't suggesting that you should use it, but if you were then, depending on what you were doing, it could make things worse.

[Colin]

It might be easier if, for the purpose of testing, you just had one chart active.

[edterbak]

Oke.

Here is the debug output of the other chart.
There is a LOT more missery being pushed into the chart, but I assume it is not used at all.

Just:
datapoint value is in msg.payload.
datapoint name is in msg.topic

The entire msg going in:
{"payload":-13,"topic":"M3 (Measured)","data_type":"int16","property":"battery_power","communication_status":"operational","scale":1,"unit":"W","precision":1,"_msgid":"99dc1aa1ac8ed0b7","messageId":"6a37d65d40cb157a909cd203","modbusRequest":{"unitid":1,"fc":3,"address":30001,"quantity":1,"emptyMsgOnFail":true,"keepMsgProperties":true,"enableDeformedMessages":false,"messageId":"6a37d65d40cb157a909cd203"},"responseBuffer":{"data":[65523],"buffer":[255,243]},"parse_buffer":[255,243],"specification":{"options":{"byteSwap":false,"resultType":"keyvalue","singleResult":true,"msgProperty":"translated_payload","setTopic":true},"items":[{"name":"value","type":"int16be","offset":0,"length":1,"mask":"","scale":"1","offsetbit":0,"id":0,"value":-13}]},"originalPayload":[65523],"values":[-13],"objectResults":{"value":{"name":"value","type":"int16be","offset":0,"length":1,"mask":"","scale":"1","offsetbit":0,"id":0,"value":-13}},"keyvalues":{"value":-13},"arrayResults":[{"name":"value","type":"int16be","offset":0,"length":1,"mask":"","scale":"1","offsetbit":0,"id":0,"value":-13}],"buffer":[255,243],"translated_payload":{"value":-13},"_event":"node:53ebc095797a50fc"}

There are 3 simultaneous entries of this, each 5 seconds.

[edterbak]

Can you elaborate on your request?
D1 / D2?
Which chart.

I will just make it so.

[edterbak]

Current status with D1 dash, 2 charts.

The result in Proxmox.
The moment of switching / deploying the D1 charts is at the arrow. (proxmox time scale is now on "day" where it in earlier images was on "hour")