Chart Generation File Build-up

[grwkak]

I have services running on my RPi that create a chart according to a template then FTP an html file to my web server. Here is a screenshot showing the set-up.

Screenshot 2026-09-26 131700.jpg (102.65 KiB) Viewed 339 times

Although I selected delete file for the FTP process, over time I end up with one remaining file per day for each graph on the local storage. This gradually begins to fill my SD Card. Its not a huge issue, but is there a way of creating one graph file per template that does not persist after the day changes. I may be missing something in my configuration.

Guy

[admin]

The FTP triggerd by chart generation should reference the "last_chart" entry from the template doop down.

[grwkak]

Thanks! Will make that change and see what happens.

Guy

[grwkak]

Not sure that did the trick. I have chart files for Oct 2nd and now Oct 3rd listed in the charts directory.

Example:

All Outdoor Data-min-202610020000-202610030000.html
All Outdoor Data-min-202610030000-202610040000.html

Guy

[ClimateBlender]

If this is still happening after switching to last_chart, does the triggered FTP event show success around the day change, and is the exact dated file that remains locally also present on the web server?

That would help separate a file that never got uploaded from one that was uploaded but not cleaned up. The docs describe using the latest-chart reference for a chart-triggered upload: https://www.meteobridge.com/wiki/index. ... h_Services

You already have Delete file enabled, so I would check the event result and filenames before changing anything else.

[grwkak]

The files that I list are only local, not on the webserver. The webserver versions have a different name and are updating correctly.

Guy

[ClimateBlender]

Thanks, Guy. That rules out a general failure to update the website. Could you share the current chart-generation event and its triggered FTP event, showing the selected local source, destination filename and Delete file option? Please hide server details, login details and any credential-bearing URL.

The next thing to establish is whether the dated file left in Charts is the same local file selected for that upload, or a separate generated file. A different remote filename is not enough to tell which. I would leave the files in place until that is clear rather than add a deletion job.

[grwkak]

Thanks, Guy. That rules out a general failure to update the website. Could you share the current chart-generation event and its triggered FTP event, showing the selected local source, destination filename and Delete file option? Please hide server details, login details and any credential-bearing URL.

The next thing to establish is whether the dated file left in Charts is the same local file selected for that upload, or a separate generated file. A different remote filename is not enough to tell which. I would leave the files in place until that is clear rather than add a deletion job.

That should be in the first post (screen shot). I don't think the local name is the name used for the upload. It seems completely different.

Guy

[gwhit_s11]

Could you share the current chart-generation event and its triggered FTP event, showing the selected local source, destination filename and Delete file option?

ClimateBlender, not sure I'd hold off quite that long. If Guy's right that the upload name is completely different, I reckon those dated files are just the ones the last_chart reference never touches, so they'll keep piling up regardless. Might be worth a proper tidy-up job for anything older than a couple of days in the meantime... though I dont know how much the Pi lets you get away with there.