Extremely slow Dashboard because of Graphs

Hello and sorry if that topic was discussed already....i found several similar discussions already but still dont know what is the best way to solve it.

I run a rental villa with 6 bed

rooms in Thailand and have door and motionsensors in every room.

That means, Nodered on a Pi4 here in Austria subscribes an MQTT broker in Thailand and gets every 30 seconds information about door and motionsignals in the villa,... also many other informations...

I get information graphs like in the attached picture about motion events and door events.
I want to see the last hour in detail and also the last 12 hours. Thats not much information at all,
mut in the mithod I use now, thats too much points in the graph and it makes the dashboard extremely slow, espacially when I use remote access. All togerther I have about 25 graphs in the flow

How can I simplyfy the job for the pi4 to get the same graph at the end?

Some solutions could be:

It would be much easier if I would just make a new point omly when something changes, but then it would draw diagonal lines in the graph...Also the time frame seems to be adjusted by the system, I could not get it fixed the last 12 hours

Someone also told me that an SSD USB Harddisk could be used instaad the CF card to get the system faster. Would that make sense?

Maybe there is just another graph node with more suitable settings for my case?

another solution could be to split the jobs in 2 Pi 4s, 1 for the graphs and the other for the none graphic jobs...

What is your suggestion?

Thanks in advance

is a great node for this sort of event.
You could also make the existing chart do what you want by setting the interpolation to be step insteadimage - that way you only need to send points when they change.
1 Like

Agree with @dceejay about the state-trail node, but even then the data aggregation may be needed. If you read the nodes readme page, there is talk about what will happen if there is too many data points.
It is hard to give exact advise about what kind of aggregation you should apply cos it really depends what kind of readout makes most sense for you.
May be like count of movement triggers per minute (makes 60 data points per hour) or something similar. And then you can make state-trail to have different colors for different count regions like "no-activity" , "less than 10", "10 to 20" or something like that.

1 Like

Well I don't think they need to send all the points - just the changes. I think they are only being sent to make the graph look good...

For state-trail the input rate makes the difference. Too short timeslice just cant be rendered. ( dot indicates but that is extreme and may not be good) That may come the main reason for aggregation need. But for performance the state tail can may be give some results even without aggregation. It all depends on wise configuring. And may be some compromise decisions about the readout needs.

First of all , thanks a lot for the productive answers that helped me a lot.
I changed the flow, so only changes of state will be sent to the trial node.
I tested the trial node and basically it is what I need, but:

But when I open the dashboard, I just see a graph when new data is arriving.
Even If I have a graph, if I close the dashboard and open it again, the graph is "waiting for data" again.

I read in the node describtion that, If I want to see past data, I have to send the timestamp together with the state information,

I tried in the way you see on the attached picture, but the effect was the same.

What am I doing wrong or is for this node an additional persistent data storage required?
The normal "graph node" that I used before

stored the past data as long as nodered was running...

Thanks again for your help...

PS: in case I did something wrong with the syntax of timestamp, please tell me what code is needed to attach timestamp to the payload 1 or 0....

There is chapter "Data storage" at nodes Readme page. Follow the description how to make persistent storage work for node.

To show historical data the object seems to be correct but it is inside another msg.payload which seems very wrong.
It should look like this

But try to make persistent storage working first. Then may be you dont need to send the state with timestamp at all, just send in states as they happen.

Not necessarily.. if you save the current value to context, then when a new value arrives, first send the saved value to the chart, followed immediately by the new current value. Then save the current value to context again. Result - no diagonal lines.

But state-trail does seem a better solution.

not necessary probably:

I used this way to visualize door states sending 1s and 0s before @hotNipi s state trail arrived.

Thanks a lot for all the good advises *** TOP ***

The combination of "send changes only" and interpolate "step" works fine with the old graph.

Thanks again :slight_smile:


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