[Ovmsdev] Open Charge Map

Mark Webb-Johnson mark at webb-johnson.net
Thu Jun 12 13:19:06 HKT 2014

Chris, Lee,

Here's an overview:

The 'raw' protocol is a binary protocol car<->server and server<->apps. The same protocol is used for both, with the server primarily being a relay with store-and-forward capabilities.  The protocol itself is binary, but the data transmitted looks more like CSV records.

The current vehicle module uses the raw protocol to talk to the server.

The current iOS and Android apps use the raw protocol to talk to the server.

The raw protocol uses a vehicleid+serverpassword authentication scheme, where the serverpassword is a shared secret between the vehicle, server and apps, and is used for both authentication and encryption. The raw protocol also supports a 'paranoid mode' where a second modulepassword is used in the apps and vehicle module to double-encrypt the data so that even the server cannot decode it.

There is an experimental HTTP protocol (API) that runs on the server and is used to read the vehicle data and communicate with the vehicle. We want to use this as the basis for future apps. With this api, the data returned is in JSON format and is structured as human/machine readable (for example 'SOC', rather than 1st field in the 'D' message).

The HTTP API currently uses OVMS username+password for authentication, and returns an authentication cookie. That is fine for experimental use, but suffers when trying to get third parties involved (as the user would need to give their OVMS username + password to the third party for storage). We would like to migrate that to an OAUTH style scheme.

It seems sensible to use a variant/extension of the HTTP API for this work on charge event distribution.

The OVMS www.openvehicles.com site is in PHP (Drupal) and the OVMS server itself is in perl (AnyEvent and AnyEvent::HTTP based).

My issue is (a) time, and (b) lack of experience with OAUTH. We would presumably need an OAUTH server (either within the OVMS server or hosted by www.openvehicles.com), and an OAUTH capability within the HTTP API on the OVMS server. Quite frankly, I am not sure where to start with this. I've read the background documents, and have an understanding of what is required, but it is very hard to find implementation examples that make sense for what we are doing, in Drupal/PHP or Perl.

Regards, Mark.

On 12 Jun, 2014, at 12:58 pm, Christopher Cook <christopher.cook at webprofusion.com> wrote:

> Yes, sounds like it to me. So the OVMS web side needs help implementing OAUTH so that other app/services can make authenticated requests to the server over HTTP.
> I believe from my quick glance over it that the main server protocol is currently binary encrypted comms over UDP which is generally both harder to parse, impossible to use from a browser client (no UDP) and presumably more difficult to extend for operations unrelated to streaming car state.
> I assume the http API is php? Not really my bag but I'm sure there are plenty of oauth modules/libraries for you to choose from. Assuming you need OAuth 1. OAuth 2 always requires presenting the user with an authentication page which isn't ideal for server side stuff.
> Chris
> Lee Howard <lee.howard at mainpine.com> wrote:
>> If I understand correctly, the GPS data is sent from the module in the 
>> car encrypted through the server to the handheld app.  (Correct?)  Or 
>> maybe that was outdated information that I read (README files in the 
>> code).  Hence, I do not understand how OCM would reliably "pull" data 
>> from either the module or the app.  A "push" from module to OCM seems 
>> burdensome and inappropriate.
>> So, if the GPS data is encrypted all the way from the module to the app, 
>> then I can really only sensibly imagine the app pushing data to OCM.
>> I must have misunderstood or read outdated information in the READMEs... 
>> because it seems much more-sensible for OCM to be communicating with the 
>> OVMS server... whether it be a push or a pull.  But... if the data is 
>> encrypted passing through the server... then that's out of the question.
>> And, I presume, then, *that* is where you are looking for help: 
>> implementing the authentication model on the OVMS server. (?)
>> Thanks,
>> Lee.
>> On 06/11/2014 05:25 PM, Mark Webb-Johnson wrote:
>>> 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:
>>>>> 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.
>> -- 
>> *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
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

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

More information about the OvmsDev mailing list