Node-RED dashboard can't handle high freq. data

I think you will need dedicated hardware to capture at that data rate, your graph example would contain over 14000 data points, if they could all be displayed. Also, node red is single threaded and there are lots of other processes and interrupts happening in the background.

How are you drawing the chart - which node are you using (or html?).

Some charts are more efficient than others, because when a new point is added, some libraries reload and redraw the entire chart, which maybe is struggling to keep up.

Forgive my ignorance about the topic, but I would like mention something.

Node-RED is running on Pi that runs minimal dietpi image, so it is CLI only. I access to Pi via SSH from my Intel i7 laptop. I realized Node-RED runs smoother than when I access it on Pi itself. So, I have assumed that it depends on where you access, not where you run the server. However, I am not sure how exactly it works.

Hi @Paul-Reed,

Here is the example setup:


Here is the configuration of line chart node:

I need to visualize these based on the time. I also changed X-axis setting to minutes as well, I have not observed any differences based on the performance.

It works well, If I set freq. to 1 Hz.

It may well be the browser that is overloading the machine running it, or possibly the connection between the two systems is the limiting factor, rather than node-red itself.

Hi @Colin,

Any advice regarding what might be the best setup to display such high freq. data?

Many things depend on the charting library. The chart node for dashboard uses the angular-chart.js which is based on Chart.js v2.xx
Chart.js is common charting library so it is not optimized to be performance king. But there is some advises to get more out of it. Performance | Chart.js. I think most of them not available to use with the chart node, so you need to create the chat with the ui_template to use and adjust the library options directly.
But even then, the chart.js is not only library in the world and it is far from being fastest.

So may be you can get better results if using some library which does claim to be fast. For example the uPlot

Hi @hotNipi,

Thanks for this informative post. Can you elaborate the below statement please?

So may be you can get better results if using some library which does claim to be fast. For example the uPlot

How can I use/integrate such a library to Node-RED dashboard?

Here is one example

Oh, I understand now what you mean. We download from GitHub, than include via:
<script src="/uplot/uPlot.iife.min.js"></script>
using the template node.

Just one more question, if my path is /home/pi/uplot/uPlot.iife.min.js is this how should include:
<script src="/home/pi/uplot/uPlot.iife.min.js"></script> or does that assume any path before /uplot. I remember wasting huge time for such a thing.

There is many threads talking about how to configure the static folder from where the node red serves external files. Just do search.
In this example the files are in subfolder called uplot
It is free of choice how you build up the internal hierarchy in your static folder.

It is a commonly known issue of the current Node-RED line chart. As @hotNipi mentioned, the line chart was based on the version v2.xx of Chart.js, which is extremely inefficient. It struggles when displaying slightly fast incoming data (say more than 10 points/second).

Chart.js since 3.0 is much faster and efficient. It would be great if line chart could use Chart.js 3.0 or above.

Alternatively, thanks to @hotNipi and Christian-Me, who have provided ways to use uPlot.
Chirstian-Me started working on a uPlot node and you can see discussions here:

Unfortunately, there are still bugs in the node.

Oh I absolutely forgot the Chirstian-Me contribution. But still in beta so yeah.. Anyway, if dealing with edge cases and/or pushing the limits, the raw library usage may give some advantages. Of course it takes then to good understanding not only the library but also all meaningful optimization strategies and often it takes also to go with some compromise decisions. It all depends...

My time is limited (I think I mentioned this) but I‘m working on it currently. I have a day time job and a family so ..
But there will be an update „soon“. The task to build a „low code“ node with a full feature ui around a complex library it is quite the opposite as @hotNipi approach. Not to mention that the documentation of uPlot is not “perfect” to honest.
With my speedtest demo I get more than 150 samples per second until the flow seams to stop increasing the pace. Think the interval function and the scheduler of node.js don’t call the callback function more often.
I can display the chart (scrolling sine wave) on a fire 7” tablet from 2019 without any issue and the browser is still responsive.


First, I will have a look at @hotNipi example with ui_template. In my case, IMU sensor generates 3 types sensor data (accelerometer, gyroscope and magnetometer). Acc. and gyro. fixed at 119 Hz, while mag. is at 20 Hz. I believe, ui_template might be enough. Then I will check the @Christian-Me's node and post my results here.

Thanks for the feedbacks.


I actually ended up using Influxdb + Grafana combo to visualize my data to be honest as my current work is kind of urgent. It works really well.

I will look into what I mentioned after Christmas.

1 Like

We tested Grafana 7.0 with Node-RED and show history data with Grafana inside Node-RED. It was clunky with decent large amount of data query, so we dropped this approach.

Grafana 8.0 does have the live data view function. Did you put Grafana display inside Node-RED, or use Grafana directly from another interface?

I am running it on another port, hence using its own interface. Here is an example image:

Here the data is not live though. I need to check what is the version that I run on my Pi.

OK there is an option of embedding Grafana to Node-RED display.

We will look into the Grafana live display at the server side. It should work for a server with good processing speed.

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