As i explained in connection with your second post above. The graphing is independent of the collection and storage of the data. Even when you know you have precisely the right data in the feeds, if you call a graph “out of sync” with those 1/2 hourly data points you will get unexpected results.
Look at you graph request data directly below the plot.
if you convert those values to the number of equivalent 1/2hourly periods
start time 1551477820 = 861932.1222222222 1/2hrs
end time 1551509660 = 861949.8111111111 1/2hrs
[therefore total time 31840 = 17.68888888888889 1/2hrs]
and interval 30 = 0.0166666666666667 1/2hrs
Nothing is a multiple of 1800 so what you are seeing is the period between the start and end time, divided into 30s intervals and the nearest datapoint found to each of those 30s intervals is displayed where possible.
Retry the graph after editing the values to 1551477600 and 1551508200 with an interval of 1800 and see what that looks like.
If that’s not right then check that your feed start time is a multiple of 1800 using the https://emoncms.org/feed/getmeta.json?id=1 api where id=1 is the feed id in question.
TBH looking at the graph, to me it does suggest the issue is with the feed start time, assuming the feed is actually a 30min fixed interval and not a 30s fixed interval, but that api call will confirm both the start time and the interval, from that you can determine what each datapoints timestamp will be, start time plus a multiple of interval. That part cannot change, if the input times vary they will be “adjusted to fit” and if the query timestamps are different, the nearest datapoint will be returned. The data itself will always be stored at feed start time plus a multiple of fixed-interval.