I am outputting accelerometer data at high freq. (119 Hz) to Node-RED dashboard via line chart node. I realized when we have lower freq. (1 Hz) there are no issues, but at higher frequencies, the dashboard can't catch up with the data as shown in below image.
I can see via debug node that the data are still arriving so no issues with that.
So, how I can handle high freq. data? Also, are the positions of widgets fixed/automated, I appreciate if someone can share a guide that shows how to customise the positions of widgets.
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.
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 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.
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
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:
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.
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?
