meteohub.de

Any thoughts on the following incorrect naming convention being observed from a NanoSD. I can't duplicate this one on any other Nano or MBPro

Scenario: Export file is created around midnight which is tagged correctly. eg At midnight between July 3 & 4 a export file is created locally on the NanoSD for Yesterday which is correct, file name is Export-20190703.txt, date records in the file are correct 2019-07-03, data is correct etc, logged instance is valid etc all good so far. The local export file is all good regardless of being created at a specific time after midnight or periodical, just "before each new day" (for today) and "after each new day" (for yesterday) no problems

An FTP service is trigger by the above local export using template: lastexport.txt and by rights the file name should be Export-20190703 as the first date record in the local file (lastexport.txt) is 2019-07-03 but the file name is created as Export-20190702 (day before), file contents are correct, for 2019-07-03.

Have not been able to correct this regardless of cleaning out the local export folder, FW update/reboot etc but it is something specific to this one particular NanoSD and appeared to go this way since around the middle of May for what reason I have no idea at the moment. Can't be firmware as I can't duplicate this on any other config. So what is illogical with this incorrect file name.

Edit: To confuse things further if one does a test of the trigger anytime after the local export file is written, the FTP file name comes through perfectly, so the FTP triggered this morning (test) for the export/lastexport written at midnight for yesterday (20190703) comes through as Export-20190703 as it should so where is this Export-20190702 name coming from?

I've had a similar issue a while back with file date/times changing when ftping to the webserver. they were I think 1 hour different than the original created on the Nano. When the Nano ftp'd it to the Webserver the file time was 1 hour different. No sure what or how it was being done but it didnt actually make any problem, but i was curious why the time difference. both device times were the same. but it would look like the uploaded time was in UTC rather than GMT perhaps.

Actual date/times of the export data (minute archive) as created and as FTP'd are both good, identical as they should be. It is the FTP'd filename that is 1 day behind as if the trigger event is picking up some remnant of the previous days lastexport.txt before maybe the lastexport file is fully created? then FTP's the latest lastexport.txt file using this filename that is actually for the day before?? The FTP'd filename YYYYMMDD part is based on the first date record in the export file.

If one tests the trigger event manually at a later time the FTP'd filename is correct and reflects the day for when the export data was written. There is no UTC data conflict here as the date/time records are ok, just the FTP'd filename YYYYMMDD portion.

This is a hard one. No real idea how to dig into this without a setup that can reproduce the fault.