[Ovmsdev] Open Charge Map

[Kevin Sharpe]

FYI, I¹ve asked Lee Howard from Mainpine to take a look at this in detail.


Kevin Sharpe | Founder & Patron | Zero Carbon World is a UK Registered
Charity #1141347

From:  Mark Webb-Johnson <mark at webb-johnson.net>
Reply-To:  OVMS Developers <ovmsdev at lists.teslaclub.hk>
Date:  Wednesday, 21 May 2014 07:19
To:  OVMS Developers <ovmsdev at lists.teslaclub.hk>
Subject:  Re: [Ovmsdev] Open Charge Map

Here is an email with a proposal / suggest I sent out last year. This would
be wonderful to do, just limited resources to do it with.

Regards, Mark.

> I¹ve always been interested in the possible uses of OVMS for the greater good
> of the EV community, and to assist with the widespread adoption of Electric
> Vehicles. The anonymised Tesla Roadster charging records we provided to Tom
> Saxton for his work on a Charge Time Predictor for these cars showed how
> beautifully such information sharing can work.
> 
> One big target for me has always been the sharing of information on public
> charge stations. Most of these systems are walled gardens at the moment
> (either for the charge station network or for the vehicle manufacturers), and
> there seems to be very little sharing going on. Chargepoint know when you
> start to charge, when you finish, the result (completed successfully or
> interrupted), volts, amps, etc - but not SOC% or which vehicle was actually
> being charged (just the owner). Leaf Carwings presumably knows where you
> charged, and the result, per vehicle, but has no way of sharing that with
> charging station networks. You can use Recargo to find a charging station, but
> have to manually go in and enter the charge result (if you want to feed-back
> positive/negative reviews to Recargo for the benefit of other users). The end
> result is a wallet full of charging network membership cards, RFID tags, and a
> cellphone full of Apps for all the different networks. Over time this will
> resolve itself, but for the moment it is a mess.
> 
> Open Charge Map goes a long way towards opening the charging station
> information, but the information seems to be flowing out of OCM to others, but
> not necessarily the other way.
> 
> Well, it turns out that for OVMS at least, we have a possible solution. A
> solution that can be both charging network and vehicle agnostic (at least for
> the vehicles supported). The rest of this eMail outlines my ideas for how this
> could be implemented. Think of it as an old-fashioned Request For Comments,
> and let me have your feedback.
> 
> Thanks, Mark.
> 
> Sharing Public Charge Data
> 
> The Problem
> 
> To allow OVMS users to automatically and simply share their usage of public
> charging stations. The information shared would be openly available to
> charging networks, charge station databases, apps, researchers, and other
> interested parties.
> 
> Pre-Requisites
> 
> Participating users would be required to have OVMS installed in their vehicle,
> and for the vehicle to be supported in as much as it can provide to the server
> indication of location, charge start, and charge completion events. Users
> would also require a cellphone app for authorisation and control of the
> sharing of their data.
> 
> Licensing
> 
> The data produced should be licensed in some Œopen¹ way. Do with it as you
> will. Perhaps creative commons, or something similar.
> 
> Vehicle Firmware Changes
> 
> Specific messages for ³Charge Start² and ³Charge Completed² should be created
> and sent to the server at the appropriate times. Control of this can be in the
> common vehicle.{h,c} code, and is not hard to implement. Only the Œlast¹
> charge is required, and the normal historical data interface can be used.
> 
> App Changes
> 
> The Apps (Android and iOS) would require a mechanism for the user to opt-in to
> the scheme, and for that opt-in to be either anonymous or with a user-defined
> nickname. The opt-in is per-vehicle and the default is for all vehicles to be
> opted out. When the App connects to the server, it will inform the server as
> to the opt-in status.
> 
> The Apps will occasionally receive push notification messages from the server,
> at the start of a charge. Those messages will lead to a dialog for the user to
> confirm what he would like to do with the current charge:
>   a) Always shared charging information for this location
>   b) Share just this once charging information for this location
>   c) Do not share this one charging session for this location.
>   d) Never share charging information for this location
> 
> If the choice is made to share, additional information can be provided (such
> as the charging post number, comments, etc). It would be nice to include
> information from Open Charge Map at this point (such as the name of the
> charging station, and validation of the charging point number), but we will
> need to verify licensing and other considerations (such as whether this would
> be acceptable / desirable to Open Charge Map).
> 
> The Apps will occasionally receive push notification messages from the server,
> when charges are aborted. Those messages will lead to a dialog for the user to
> confirm the reason for the abort:
>   a) Charge was successful, but interrupted by the user
>   b) Charge was unsuccessful, due to a problem with the charging station
>   c) Charge was unsuccessful, but not a problem of the charging station.
> 
> The user¹s response must be returned to the server appropriately.
> 
> The Apps, when connected to the server, can also receive a list of charging
> records that have not yet been responded to. A dialog should be presented to
> the user for each such location.
> 
> Server Changes
> 
> The servers will maintain opt-in status for each vehicle in the system, and if
> opted-in, the nickname / anonymous handle for the vehicle.
> 
> The servers will maintain a historical list of charging locations for each
> vehicle in the system. Each location record would have:
>   a) Latitude, Longitude (geofenced).
>   b) Sharing flag (pending user, just this once, always, not this once, or
> never).
>   c) Charging information (date/time charge started, etc).
>   d) Date and result of last charge here.
> 
> When the server receives a Œcharge started¹ message from the vehicle, it would
> look up the geofenced location in the database, for the vehicle, and use the
> sharing flag to determine what to do.
> 
> If there is no matching record found, a new record would be created (sharing
> flag: pending user).
> 
> When the server receives a Œcharge completed¹ message from the vehicle, it
> would look up the geofenced location in the database, for the vehicle, and use
> the sharing flag to determine what to do.
> 
> If the sharing flag indicates that the charging information should be shared,
> the server would publish the charging session information appropriately.
> 
> If the server receives an indication from the car that a charge has been
> aborted, it will have to PUSH notify the user - but also ask the user for
> confirmation of the reason why the charge was interrupted.
> 
> When the server receives a user decision message from an App (either before or
> after charge completion), it should update the charging location record
> appropriately. This may also result in the publishing of the charging session
> information.
> 
> The server will maintain a database of partners, and their API access keys.
> This database should allow for PUSH messages (via HTTP) to the partner. If
> PUSH is enabled, every time a charging session is updated (either started or
> completed), the server will connect to each partner (in randomised order) and
> send them the information for recent charges. The server will also provide an
> API to allow partners to PULL messages past a certain date/time stamp (to
> allow for periodic synchronisation).
> 
> Partners
> 
> Partners would just have to subscribe to the system (signing up with a user
> account and being given an API key). They would have to agree to the license
> terms, but other than that there would be no restrictions to partnership.
> 
> Partners can choose to either retrieve updates via PUSH (they provide a server
> URL to receive the data), PULL (they periodically poll the OVMS server for
> updated data), or a combination of both.
> 
> Overview (start to finish)
> 
> An OVMS user opts in to the service. He uses the nickname ŒJimbo¹.
> 
> He arrives at a public charging station and plugs in. The OVMS module in his
> car detects the charge has started and informs the server. The server looks up
> the vehicle charging locations and finds that the vehicle has never charged
> here before, so sends a PUSH notification to the user¹s Apps to ask him about
> this charge.
> 
> Within seconds of the charge starting, the user¹s cellphone beeps and he sees
> an OVMS notification. He clicks on it and is taken a dialog asking him about
> the charge he has just started. This is a public charge station, so he just
> clicks ³Always share charging information for this location² and turns off his
> phone. The App sends a notification to the server, and the server updates its
> records to never both the user about this location again. The server also
> updates all partners (via PUSH notification) that a charge has started at this
> location.
> 
> Partners can use this information to record statistics on charge station
> usage, or even as a rudimentary indication of if the charging station is in
> use (at least by an OVMS user).
> 
> After a few hours of charging, a breaker trips and the charge is interrupted.
> The OVMS module in his car detected the abort and informs the server. The
> server looks up the vehicle charging location, and if sharing is enabled for
> this location sends a PUSH notification to the user¹s Apps asking him about
> the cause of this interruption?
> 
> The user returns to his car and finds the problem. He responds to the dialog
> in his OVMS App to let the system know that the charge was interrupted by a
> problem of the charging station. The server receives the response, updates its
> records, and updates all partners (via PUSH notification) that a charge has
> been interrupted at this location.
> 
> Partners can use this information to record statistics on charge station
> failure rates, as well as updating that the charge station is no longer in
> use.
> 
> Partners not using PUSH notifications can retrieve all this information at a
> later date by a simple HTTP PULL request.
> 
> Further work
> 
> There are many extensions possible to this system, but I would first of all
> like to concentrate on getting a basic implementation designed and
> implemented, and some partnerships in place.
> 
> For example:
> 
> * Pictures of new charging locations.
> * Information for new charging locations.
> * Charging station information.
> * Showing current usage of a particular station in the Apps.
> * and so much more
> 
> Privacy Issues
> 
> The biggest privacy issue is that the server would have to record the
> locations of charging stations that the user has requested not be shared. For
> example, someone¹s home. We could avoid this by not recording these, but that
> would not be optimal as the system would then have to ask the user whether he
> wanted to share, each and every time they charged at that location (rather
> than just once, the first time). As this information is not actually shared,
> it is not a true privacy issue - but should the security of the server be
> compromised, that data could be exposed.
> 
> Perhaps a one-way hash could be used for storing locations, but we would have
> to find one that also worked with geofenced lookups.
> 
> Conclusions
> 
> The above is not hard. In particular, the vehicle firmware changes are trivial
> (it could even be done without any vehicle firmware changes, by looking at the
> S and D messages coming back from the cars). The server code is not difficult
> at all. The largest amount of work would be in the Apps (in particular,
> handling the PUSH notifications and user dialogs).
> 
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

On 4 May, 2014, at 7:01 pm, Christopher Cook
<christopher.cook at webprofusion.com> wrote:

> Actually, on that topic (almost) - we should discuss how OVMS users might
> checkin (or even auto-checkin) to OCM. That would help us track which
> locations people are using and the quality of their experience there.
> 
> Are there any recent thoughts on this from the OVMS side? Currently there are
> no third party apps writing to the OCM API. Doing so currently requires at
> least authentication (via the web UI) - this is also the method used by the
> OCM mobile apps.
> 
> There is the possibility of a quicker/simple login to OCM via third party apps
> by way of a security code emailed to the user (who would either be new to OCM
> or an existing user). Not massively secure (there are holes in the approach)
> but it would make it easy for third party apps to quickly authenticate.
> 
> Alternatively we can provide URLs which OVMS users would open in a
> browser/webview which go on to use the standard mobile app or site. This is
> the easiest for OVMS apps to implement.
> 
> Depends on what integration people would like to see?
> 
> Chris
> 
> J-C Saint-Pô <jcsaintpo at gmail.com> wrote:
> 
> Hello guys,
> 
> Just a reminder.
> 
> http://openchargemap.org/ is used as database of chargingstations in the OVMS
> apps
> You can add / remove chargigstations via http://openchargemap.org/site/poi  or
> http://openchargemap.org/app/
> For some uses you need to login.  This can be done via your twitter google+ or
> facebook-account.  So no extra account to be made solely for OCM
> 
> 
> here some other examples of apps/ websites that use OCM
> http://openchargemap.org/site/develop/apps
> 
> Here the google+ community of OCM
> https://plus.google.com/u/0/communities/112113799071360649945
> 
> Kind Greets
> J-C
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

_______________________________________________ OvmsDev mailing list
OvmsDev at lists.teslaclub.hkhttp://lists.teslaclub.hk/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20140521/ed82367b/attachment.htm>