Does the transfer to OCM happen from the OVMS server or from the smartphone app?

It seems to me like it should happen on the smartphone. I'm charging. I want to send in the data. The first step would be to authorize sharing the data, which sends it to the OVMS sever, now publicly accessible to anyone. Next, OCM code on the smartphone runs to see if it has a single matching site, multiple nearby sites, or no nearby site. Depending on how that turns out, I need to either confirm the correct site, choose from a list of candidates, or create a new site if none seems like a match. Once the (possibly new) site is confirmed, then the data goes to OCM associated with that site. That conversation can't easily happen as a post process on the server.

This could get interesting in multiple dimensions. Maybe another map vendor wants to add support to OVMS, so the user can choose OCM or PlugShare, or whatever. Or maybe choose multiple. Or it could happen the other way around: another map vendor integrates the OVMS API into their app.

It seems complicated to do this on the server side, requiring server integration with each vendor. That's messy and presents new surfaces for security exploits. If it is done on the OVMS server, it seems perfectly reasonable to me to have an API that says "tell me about all of the charging station reports since <date of last query>." That seems easier to secure and more flexible, but does still have the problem of dealing with mapping reports to site IDs potentially from multiple different map vendors.

As an aside, PlugShare is already experimenting with adding the ability to add voltage/amperage info to their database via a special version of their web site that appears when the user agent is the Model S browser.

   Tom

On 5/22/14, 3:02 PM, "Paul Churchley" <paul@churchley.org> wrote:

I agree with Tom. That makes sense from a data and functional design perspective too.

It is best if OVMS remain uncoupled as much as possible and pushes out updates to OCM for opted-in users through an external system update layer. That layer could be independent of the main OVMS system and could have stubs for each data interface that OVMS wishes to interact with. That would make the design, development and maintenance of this functionality modular, isolated and easier to develop.

tbh, I would feel uncomfortable with OCM pulling changes in from OVMS. The update originate from within OVMS and so OVMS should initiate the action IMO. So, I would prefer to OVMS charging location capture to be generic and not tied to OCM or to OCM functionality. Of course, OCM and its requirements will impact on the OVMS design but OVMS should remain, wherever possible, external system/database agnostic.

On 22 May 2014 22:49, Tom Saxton <tom@idleloop.com> wrote:

I'd like to make sure that whatever happens with OVMS reporting charging
station information stays open and stand-alone, not tied exclusively to
OCM.

When a user chooses to submit data, it should go to OVMS where it can be
accessed by anyone, whether it's a charge map vendor, some other
enterprise, or someone doing EV research for some completely different
purpose.

It's fine if there's a layer of top of that so that OVMS users who opt-in
to OCM can enter OCM credentials, disambiguate between possible sites,
etc., and the data also gets sent to OCM.

   Tom

_______________________________________________
OvmsDev mailing list
OvmsDev@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

_______________________________________________
OvmsDev mailing list
OvmsDev@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev