[Ovmsdev] Open Charge Map
Mark Webb-Johnson
mark at webb-johnson.net
Thu Jun 12 08:25:21 HKT 2014
Lee,
I'm working on the vehicle code, server and protocol changes side of things. Hope to have something this month (as I am on holidays in July).
Where I'm really looking for help is the authentication model for the HTTP API. What we have now is kludgy, and it would be good to support OAUTH.
Regards, Mark.
On 11 Jun, 2014, at 5:25 am, Lee Howard <lee.howard at mainpine.com> wrote:
> Mark,
>
> Has there been any work done in regards to submitting charging data out to OCM? I'm ready to start tinkering on this, and if some work is already being done then I want to attempt to do so collaboratively.
>
> Thanks,
>
> Lee.
>
>
> On 05/23/2014 01:19 AM, Mark Webb-Johnson wrote:
>>
>> There have been a bunch of responses to this original response - not sure which to reply to, so I’ll reply to the root.
>>
>> Firstly, thanks for all the feedback. Truly happy to see such great feedback from the OCM team as well as others. I’m particularly glad to see the positive response from the OCM guys and offer to help from their end. Whatever happens with this, presumably OCM would be the first consumer of the data, so it is important and useful to see how we can fit into their model. We also use the OCM database in the Apps, and that should make things easier.
>>
>> That said, I want to re-iterate that I want to make this truly ‘open’ (note: definitely not saying that OCM is not open). My own personal feelings on openness are in the MIT/BSD camp, rather than GPL. Perhaps I am naive, or perhaps it is my age (coming from a time when software was free as in "do whatever the hell you like with it, just don’t blame me”), but I think true freedom should not restrict the rights of others in any way (not just the rights upstream, but the rights downstream as well). Anyway, all this data is coming from OVMS users, so as long as the license and agreement there is completely open, we will be clear to distribute into other systems (open, free, or closed).
>>
>> So, given that we will be ‘giving away’ the data, it comes to the ‘black box’ question of how to do that. My own personal preference is just to provide an api to either PUSH or PULL the data, and the reason for that is I don’t want to be extending the server code to support ten different third-party APIs. That said, I did suggest a PUSH option in the original RFQ, and the thinking behind that is we can format a URL+formdata with parameter-substitution (based on server.conf settings for a particular provider - no code) and just fire it off. I see no problem with a single API key for OVMS to submit to such an external service. For ‘user credit’, it would be nice to have an option where the user could enter an optional username+pin for each service, and we can provide it as part of the PUSHed/PULLed data.
>>
>> Other than that, it seems fairly simple. The issue is going to be the apps - handling the events in a nice way given the limitations of the PUSH APIs.
>>
>> Regards, Mark.
>>
>> On 21 May, 2014, at 7:12 pm, Christopher Cook <christopher.cook at webprofusion.com <mailto:christopher.cook at webprofusion.com>> wrote:
>>
>>> Hi Mark,
>>>
>>> So to recap, the idea your proposing here is to checkin to OVMS, rather than directly to Open Charge Map, then later allow OCM access to the checkin information via your API.
>>>
>>> Since the existing apps have the ability to query OCM for the list of nearby charging locations then you can present a shortlist of OCM locations so the user can confirm which it is - maybe there's a need for the user to be able to Add a location though (that can be done by launch a webview to http://openchargemap.org/site/poi/add then waiting until the url changes to http://openchargemap.org/site/poi/details/12345 - you can then grab the OCM-ID from the url for the subsequent checkin to OVMS.
>>>
>>> Note that there is the option to directly checkin/comment to OCM if you wanted to, either via the API or by launching a webview to a specific OCM page to start the checkin and pass in relevant info. We already capture various types of success/failure but we could also accept a general payload (as JSON) to store with the checkin (for instance charging times/power levels etc) which we can parse later.
>>>
>>> A bit about the relevant bits of OCM API (if they were required):
>>>
>>> For simple web browser based stuff:
>>> checking in/commenting: http://openchargemap.org/site/poi/addcomment/12345
>>> add photos: http://openchargemap.org/site/poi/addmediaitem/12345
>>> edit a POI: http://openchargemap.org/site/poi/edit/1234
>>> add a new POI: http://openchargemap.org/site/poi/add
>>>
>>> For actual API level stuff:
>>> An anonymous checkin to OCM can be done via the API by posting to http://api.openchargemap.io/v2/?action=comment_submission&format=json with a JSON string for the comment object in the http post such as:
>>> {
>>> "ChargePointID": 12345,
>>> "CommentType": {
>>> "ID": 10,
>>> "Title": "General Comment"
>>> },
>>> "UserName": "A. Nickname",
>>> "Comment": "This place is awesome",
>>> "Rating": 5,
>>> "RelatedURL":"http://awesomevplace.com",
>>> "CheckinStatusType": {
>>> "IsPositive": null,
>>> "IsAutomatedCheckin": false,
>>> "ID": 0,
>>> "Title": "Did Not Visit Location"
>>> }
>>> }
>>> Checkin/Comment types can be found at: http://api.openchargemap.io/v2/referencedata/
>>>
>>> I'll be setting up a sandpit API shortly so that app folks can try out checkins etc.
>>>
>>> Note that authentication as a specific OCM user is slightly contrived (much like OAuth 2.0 etc) and currently requires initiating a browser workflow starting at:
>>>
>>> * http://openchargemap.org/site/loginprovider/?_mode=silent&_forceLogin=true&_redirectURL=AppLogin?redirectWithToken=true
>>> * And ending at: http://openchargemap.org/site/loginprovider/applogin
>>> * You then need to either reading the Username and OCMSessionToken
>>> cookies or we could include it in the url fragment of the
>>> applogin page and you can read that from the web view.
>>>
>>> One option I'm pondering is for apps to be able to request the OCM Session Token just by supplying a PIN code and Username to the API, the user would need to go to the OCM website to generate the pin code (and conform the expected Username for it to work) probably by starting a certain OCM url with an API Key specific to OVMS.
>>>
>>> Chris
>>>
>>> On 21/05/2014 15:23, Kevin Sharpe wrote:
>>>> 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 <mailto:mark at webb-johnson.net>>
>>>> Reply-To: OVMS Developers <ovmsdev at lists.teslaclub.hk <mailto:ovmsdev at lists.teslaclub.hk>>
>>>> Date: Wednesday, 21 May 2014 07:19
>>>> To: OVMS Developers <ovmsdev at lists.teslaclub.hk <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto:OvmsDev at lists.teslaclub.hk>
>>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>>>
>>>> _______________________________________________ OvmsDev mailing list OvmsDev at lists.teslaclub.hk <mailto:OvmsDev at lists.teslaclub.hk>http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>>>
>>>>
>>>> _______________________________________________
>>>> OvmsDev mailing list
>>>> OvmsDev at lists.teslaclub.hk
>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>>
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.teslaclub.hk <mailto:OvmsDev at lists.teslaclub.hk>
>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>
>>
>>
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>
>
> --
> *Lee Howard*
> *Mainpine, Inc. Chief Technology Officer*
> Tel: +1 866 363 6680 | Fax: +1 360 462 8160
> lee.howard at mainpine.com | www.mainpine.com
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
More information about the OvmsDev
mailing list