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.
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...
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 instead - that way you only need to send points when they change.
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.
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
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.
- that way you only need to send points when they change.
