Hi Colin - I have the X-axis duration set to 2 hours (tried 3 hours and 1 hour and setting 1000 points). The X-axis Label set to automatic (have also tried setting it to HH:mm).
Maybe I should be using Labels instead of Series when sending the initial historic data arrays?
I notice the graph data shows UTC time as sent in the controller data rather than BST. I don't have the X-axis "as UTC" option enabled. Doesn't seem that straightforward to translate the incoming ISO8601 format date/date stamps into local time in my function node, but I'm going to have to figure that.
Don't think its related to my issue though as the new data timestamp is later than the historic ones...
The timestamps aren't in ISO format as they haven't got the timezone specified. It may be better to provide timestamps in javascript ticks anyway (which are in UTC of course).
Can you show the graph before and after adding new points please, it might help.
Edit, oh you have, sorry, having another look...
If the added data is actually live then there is no need to include the timestamp as it will get added at the current time - you just need topic and payload.
As long as the topics match up then it will add to the existing series. The window will get trimmed as per your settings - either time window or number of points.
Hi Colin - to make it easier I just taken a new image after data reset and the time at the right hand is showing GMT (its now BST so should actually be showing 5:26pm). So I do need to fix the array data timestamp to be correct for my local timezone.
I have taken out the timestamp from the update data points as indicated by dceejay (thx for that tip) and they now correctly show BST as below. Their time is now taken from the msg header which shows my correct lcoal time (when I added the timestamp in these I was just following the info at the URL to the letter!).
Unfortunately still have the issue that when the first update comes in, although the Total looks Ok, the 2.4/5Ghz histroical values get erased. They then start plotting Ok again in subsequent updates going forwards.
If you add a debug to the output of the chart node - then let it run a bit - you should see the data from the graph in a format that is what the input would want... so you should be able to compare them to ensure they look the same layout, have all the same fields in same format etc...
Then as below, looking after the first injected update I see the 3 input messages with their values.
In the output I can see array 0 (Total) shows 11 objects hence why there is some historical data in the chart for Total, but arrays 1 (2.4Ghz) and 2 (5Ghz) show only 2 objects (not sure why they show 2, but they are only 2ms apart so maybe can't be seen as separate datapoint in the graph).
What else I noticed is that in the historical data the date/time looks like a string (this is extracted from the incoming controller data array in the same format):
"2020-05-31 19:03:02"
When I look at the date/time for updated data its not a string and I can toggle between various formats:
1590955435069 or 2020-05-31T20:03:55.069Z or 31/05/2020, 21:03:55 [UTC+1]
Still not sure this has anything to do with it (why would it affect just the 2.4/5Ghz data)...
dceejay comment to remove timestamp from the updates helped in one part Colin's comment about timestamp format has moved it closer to resolution
Thx for your inputs.
Does look like there is a close relationship between the date/time format when sending an array with the initial data, and then sending updated data points.
I added a conversion of the controllers source date/time using the line below for each objects date to change it to this format: "2020-05-31T19:30:32.000Z" and now I am getting the historical data points maintained after adding new data points.
Just need to sort out the timezone on the source controller data as it's UTC rather than BST so I have an hours gap in the data, but thats straight forward to fix.
szTime = new Date(msg.payload.list[listCounter].key);
for 
...
