[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ocpp] NTP Time service configuration - standard configuration variables
Hi Robert, Anders, (all), I would think that the type of scenario that Anders describes will become quite common in the future, and therefore appropriate configuration variables should be standardized as part of OCPP 2.0, along the lines of Anders suggestions. When OCPP was first being designed, as a SOAP based protocol requiring bi-directional IP routability, it was the normal case for it to be carried over a private (mobile) network, so access to common (public) NTP services could not be presumed. Now, with the capability of OCPP to operate (tunnelling bi-directionally) over a client (charge point) initiated WebSocket (and possibly other transports), it is much more likely that charge points will be connected to the public internet, and consequently have access to reliable, high quality NTP services. For small/simple “low-end” charge point devices, the cost of implementing a full local real-time clock hardware is not insignificant, and it is likely in future that there will be charge point designs (for at least certain applications) that are effectively un-usable without a live internet connection (e.g. via local Wi-Fi). In such cases, it make more sense for the device to treat date/time synchronization information from NTP as preferable to the “traditional” OCPP mechanism of time synchronization via Central System timestamps returned in “Heartbeat” messages. In that case, the “currentTime” value in the Heartbeat.conf message should be made optional, so that if configured to get “correct” time from elsewhere, there is no possibility of the charge point being confused by receiving alternating conflicting “real” time updates. On a separate but related point, it is arguable that Heartbeat messages themselves (which can often be a large percentage of total data traffic for occasionally used charge points) are potentially redundant when OCPP is “tunnelled” over an underlying transport mechanism that has its own keep-alive and connection loss detection mechanisms. Best Regards, Brendan McMahon | Systems Architect | ESB ecars | T: +353 1 702 6708 / +353 87 662 2150 | www.esb.ie From: ocpp@lists.oasis-open.org [mailto:ocpp@lists.oasis-open.org] On Behalf Of Robert de Leeuw Hi Andres, You are free to define your own Variables. So if you want, you could create your own Variable: UseDhcpForNetworkAddress? or something like that? Of more people think this is a good idea we could even add this to OCPP as Default Variable in the appendix. When this flag is set to true, I would make Clock.NetworkAddress read-only, and show to address provided by DHCP. Might be usefull for the Central System to be able to see which NTP server is being used. Kind regards, Hoge Ham 85 5104 JC Dongen John F. Kennedylaan 3 5555 XC Valkenswaard
2016-11-11 12:22 GMT+01:00 Anders Darander <anders@chargestorm.se>: Hi,
* ** *** ** * ** *** ** * ** *** ** *
* ** *** ** * ** *** ** * ** *** ** * |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]