timeseries2csv <-> RCT Power App export - 1h time difference

[UweRieping]

I have one hour time difference between the export done by timeservice2csv and the RCT power app.

Yesterday evening at 21:00h CET my battery was showing the load of 50,00 %.
The export from the RCT power app is showing the same value (49,707...) in the field SOC [%] with the timestamp 25.02.2021 21:00
The .csv file from timeseries2csv is showing the same value (0,49707....) in the field soc at the timestamp 2021-02-25T22:00:00+01:00
I have not use the parameter "--time-zone" while using timeseries2csv.
By using the csv2influxdb program I have imported the .csv file in Grafana. The 50% is shown at 22:00h.
My virtual Raspberry Pi running the InfluxDB and Grafana has the timezone "Europe/Berlin" configured.
The RCT inverter has the same time as all other devices. It has "auto daylight saving" enabled.
I was not able to find any timezone setting.

Is it me, doing something wrong? Something I have not taken in consideration?

[svalouch]

Raw timestamps (without time zone info) and time zones in general are a never-ending source for fun. I don't think it's you or your doing, the timestamps of the device are off by one hour. The app seems to compensate, though I'm not sure how it figures out the details. The --time-zone option (defaulting to Europe/Berlin if not specified) is just there to attach a UTC offset to the output and it doesn't actually convert anything, it's there so that systems know what time zone the data is in, which helps with InfluxDB that internally stores as UTC.

Using the following bash script:

# put your devices address here:
DEV=192.168.0.1

echo "local:  $(date +%s) = $(date)"

D_TS=$(rctclient read-value --host $DEV --name flash_rtc.time_stamp)
echo "device: ${D_TS} = $(date -d @${D_TS})"

echo -n "device auto-adjust DST: "
rctclient read-value --host $DEV --name flash_rtc.flag_time_auto_switch

I get this output:

local:  1614432221 = Sat Feb 27 02:23:41 PM CET 2021
device: 1614435898 = Sat Feb 27 03:24:58 PM CET 2021
device auto-adjust DST: True

So the devices timestamp is one hour plus some seconds (set manually) in the future. I've also verified that what the app receives is also one hour ahead of the the current time by looking at a network dump. This is pretty frustrating, because it doesn't show up in my Grafana because of time zone differences between the host that runs the InfluxDB and the Grafana/Browser that shows it, but my stored CSVs are off by an hour.

I wonder if the app simply compares the time stamp and figures out the offset to apply, though I see some unknown (read: not in the registry yet) OIDs (0xb403a7e6 with value 0x47000000 as well as 0x663f1452 with value 0x02) in the vicinity of the history display and data export.

So in the end it looks like timeseries2csv.py needs some way to compensate. I guess the easiest way would be to add a parameter that allows the caller to specify a positive or negative compensation value of "minute" granularity, e.g. --compensate=-60 or --timeshift=-60 and add a section about it to the documentation. What do you think, does that sound reasonable?

[UweRieping]

Using you small script, for me the situation looks the same.

local: 1614443345 = Sat 27 Feb 2021 05:29:05 PM CET
device: 1614446937 = Sat 27 Feb 2021 06:28:57 PM CET
device auto-adjust DST: True

And as mentioned already, the device is showing the local 05:29 time. I have just rechecked at the device.
The suggested solution is looking simple form an "user" perspective and it also looks flexible.
Your have used minutes, I recommend the same. There are a few countries on this world with not full hour time zones.
E.g. Afghanistan with UTC+4:30, not saying that RTC will ever sell an inverter in this country.

I was a little surprised that the hour wasn't noticed before :-)
Many thanks in advance if you create a new version with the timeshift option! 👍

[MichaelMMS]

Same here, I input the current time into the rct app and at the inverter display it is 2 hours difference.

[stephanritscher]

Could it be that the RCT device mishandles the dates by treating the local timestamp as GMT and convert this to unix epoch?
I checked my data for the 27th of March, the day of time change from winter to summer time, and it seems the gap between the exported csv time and the time shown in the RCT app increases from 1 hour to 2 hour (csv file being ahead) at the point where the timestamps in the csv file jump from timezone +01:00 to +02:00.
Basically,

TZ=GMT date --date="@$(rctclient read-value --host hf-a21 --name flash_rtc.time_stamp)" +%Y-%m-%dT%H:%M:%s

gives my the local time, i.e. the same as

date +%Y-%m-%dT%H:%M:%s