OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ocpp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [ocpp] Re: Old OCPP 2.0 RC2 Time Zones description


* Ali Imran Najmi <ali@grid-scape.com> [161109 17:09]:

> I agree with Brendan that there needs to be additional date/time info for
> DST start time and end time, which needs to be passed to the CP for the
> daylight switching (surely required when offline). The heartbeat is a
> regular RTC sync as mentioned in OCPP 1.5 and OCPP 1.6 and thousands of CP
> sync their clocks from it, the offset and daylight saving date/time
> start/end is already defined in old OCPP 2.0. Just need to have use cases
> defined on when this data would be synced.

This is another thing I'm not really comfortable with, using the
heartbeat to sync the time.

In the old 2.0-draft, under device management, there was a field,
Clock.NetworkAddress that made me a lot more happy. This allowed the CP
to use NTP for time keeping. There's a big advantage of using NTP (if
you have a CP which is big enough to properly implement NTP), most
(all?) NTP implementations implement a drift measure. The drift allows
you to take your normal clock drift into account, even if you're
temporarily off-line. This will likely reduce the time-jump you need to
perform when you're getting online again.

> TZ data may not be bad altogether but there shouldn't be 2 sources for time
> and daylight sync to the CP as the two sources can be out of sync as well.

Of course, we can't really use two sources at the same time.

> So may be we decide on either below and have use cases defined
> a. Remove time sync from OCPP messages and define how to use TZdata in OCPP

It looks like the offset is the one to use, and not the timezone
approach. However, I'm still going to advocate the use of NTP, even
though it seems to have been omitted in the latest DeviceManagement RFC.

> OR
> b. Use offset, dst-offset, dst-starttime, and dst-stoptime as Anders
> suggested and already present in old OCPP 2.0 under clock component.

Well, not with those names, but the more generic ones in the 2.0.

The names above was merely to stress the point.

Cheers,
Anders
-- 
Anders Darander		Senior System Architect
ChargeStorm AB		Tel: +46 702 44 84 36
Hospitalsgatan 3	E-mail: anders@chargestorm.se
602 27 Norrköping	Web: www.chargestorm.se


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]