This project has moved and is read-only. For the latest updates, please go here.

Date/Time stamp in logfiles when summer time changes?

Jun 30, 2014 at 3:07 PM
I'd prefer not to wait until summer time changes the next time to understand SMA inverter and/or SBFspot behaviour.

So what actually happens around summer time changes with the date/time stamp in the log files. I can see from my log files that, when summer time last changed, the time stamp jumped by an hour at 2 o'clock. But I've got SBFspot time synchonisation enabled, so did the time jump because SBFspot changed the time on the inverter, or is it standard SMA inverter behaviour to change the time around summer time?
Jul 1, 2014 at 6:29 PM
Edited Jul 5, 2014 at 3:30 PM
dear BSG63

can you clarify what type of info you refer by "log files"

SBFspot does generate the following info:
File1: spot-values.csv file actual values for a series of data, eg Udc, Idc
File2: daily.csv values for each 5minutes interval (option -adnn)
File3: monthly.csv values for each day (in the month) (option -amnn)
File4: events.csv table with the events (option -aenn)
File5: StdOut (or debug-out file) a text output on screen or redirected to file when specifying -d5 -v5
File6: StdErr (also debug-out file) a text output on screen or redirected to file when specifying -d5 -v5

The answer to your question is two-fold
-A- when SBFspot sends the actual time info to the inverter, this info does not only include the actual time
but informs the the inverter about the interpretation of that value (DLS = avtice or not)
-B- when SBFspot receives information from the inverter, then the DateTime info is treated according to the
time zone information, which includes the knowledge about the DLS setting

Other points:
-1- point to be aware: -> distinguish the cases depending on the type of inverter,
-a- inverters with "an onboard continues RTC clock" <-->
rule-of-thumb - most HF and TL inverters do incorporate an in-build comm's module (this has cont.RTC)
-b- inverters where clockinfo (date-time) does not survive after sunset (inverter shuts down completely)
rule-of-thumb - inverters that require a piggy-back module for comm's do not have cont.RTC

For inverters that do NOT have an in-build (continious) RTClock,
  • eg my inverter (an SB3300) needed a piggy-back and does not have a RTC that keeps the clock-info overnight
    for these inverters the time must be "set" each day again (after sunrise),
!w! as long that the time is not yet set - the inverter assumes for the date: 1970jan01
and for the time setting: time elapsed since sunrise (=start of inverter)

!v! if the time is not set (eg today) then tomorrow the today's data is overwritten (lost)
this is true for 5minute interval table and the day records in the monthly file

!u! the first "time set" instruction does not only set the actual Date-Time but all records in the table are set to be in line with the time-setting

!t! if you modify the time (=subsequent time set instructions) during the day then:
either there will be a time-gap between the records or some records get overwritten

-2- point:
  • the internal time setting of the inverter is at "standard time" - cfr linux systems
    so the inverter's internal clock will not need to make a jump (PLUS or MIN) at DLS switchover
    the DLS jump is part of the interpretation of the Time field in the tables - when extracting the data
!s! at the moment of the DLS switch over's including the period from midnight till 2 or 3
it will be dark outside (so no production from a PV installation)
so the DLS time jump will not have an effect on the values

!r! eg: when extracting data from my inverter there is no data in the tables for the period that the inverter is
not in operation
  • some tools do make these tables complete by inserting extra records
    by filling the gap from 00h00 till sunrise and from sunset till 24h00
-3- point:
  • the key on this discussion is the interpretation of the time, ?? DLS on or not
    this is done by the OperatingSystems (also by SBFspot, . . . . )
    at the moment that the tables are extracted -> generated
kr wim