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@gmail.com> wrote:
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
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@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev On 4 May, 2014, at 7:01 pm, Christopher Cook <christopher.cook@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@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@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
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@webb-johnson.net> Reply-To: OVMS Developers <ovmsdev@lists.teslaclub.hk> Date: Wednesday, 21 May 2014 07:19 To: OVMS Developers <ovmsdev@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@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
On 4 May, 2014, at 7:01 pm, Christopher Cook <christopher.cook@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@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@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hkhttp://lists.teslaclub.hk/mailman/listinfo/ovmsdev
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&_... * 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@webb-johnson.net <mailto:mark@webb-johnson.net>> Reply-To: OVMS Developers <ovmsdev@lists.teslaclub.hk <mailto:ovmsdev@lists.teslaclub.hk>> Date: Wednesday, 21 May 2014 07:19 To: OVMS Developers <ovmsdev@lists.teslaclub.hk <mailto:ovmsdev@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@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
On 4 May, 2014, at 7:01 pm, Christopher Cook <christopher.cook@webprofusion.com <mailto:christopher.cook@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@gmail.com <mailto:jcsaintpo@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@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto: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
Hello Mark, Chris, and other OVMS users and developers... I am happy with all of Mark's outline with only one point for debate. Admittedly, I am new to OpenChargeMap API and OVMS programming, and so maybe I simply don't understand how things work, but... As the OVMS server will be performing the OpenChargeMap API on behalf of the partner instead of the portable app performing the OpenChargeMap API (more-directly in the control of the partner)... is it really necessary for the OVMS server to masquerade as the partner... using their identity for authentication with OpenChargeMap? I'd prefer to avoid requiring the user to set-up an independent account with OpenChargeMap and then permit OVMS to operate on behalf of that newly-created account. Could not the OVMS server simply use its own account (for everyone) and simply provide an information field about the identification of the OVMS user? My primary interest here is in making it as simple as possible for the OVMS user to opt-in. Requiring them to sign up with OpenChargeMap and provide a PIN or key from the account is an additional step that will prove to be a barrier for users that are willing to opt-in as long as it is merely as easy as a button-press. Thanks, Lee. On 05/21/2014 04:12 AM, Christopher Cook wrote:
....[snip]....
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.
....[/snip]....
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@webb-johnson.net <mailto:mark@webb-johnson.net>> Reply-To: OVMS Developers <ovmsdev@lists.teslaclub.hk <mailto:ovmsdev@lists.teslaclub.hk>> Date: Wednesday, 21 May 2014 07:19 To: OVMS Developers <ovmsdev@lists.teslaclub.hk <mailto:ovmsdev@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.
....[snip]....
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.
....[snip]....
-- *Lee Howard* *Mainpine, Inc. Chief Technology Officer* Tel: +1 866 363 6680 | Fax: +1 360 462 8160 lee.howard@mainpine.com | www.mainpine.com
Maybe people use their ovms usercode to write changes & comments to ocm to an cooperationg ovms server This server writes the changes & comments to ocm as "OVMS-user-submitted" Maybe give ovms users possibility to choose to submit directly to ocm for submitting more ample info And use the "via-ovms" for basic changes or submissions All will depend on how much load you want on the ovms-server (suggestion submited by someone who only knows the basics on computers & co) ;-) Kind greets JC 2014-05-21 19:04 GMT+02:00 Lee Howard <lee.howard@mainpine.com>:
Hello Mark, Chris, and other OVMS users and developers...
I am happy with all of Mark's outline with only one point for debate. Admittedly, I am new to OpenChargeMap API and OVMS programming, and so maybe I simply don't understand how things work, but...
As the OVMS server will be performing the OpenChargeMap API on behalf of the partner instead of the portable app performing the OpenChargeMap API (more-directly in the control of the partner)... is it really necessary for the OVMS server to masquerade as the partner... using their identity for authentication with OpenChargeMap?
I'd prefer to avoid requiring the user to set-up an independent account with OpenChargeMap and then permit OVMS to operate on behalf of that newly-created account. Could not the OVMS server simply use its own account (for everyone) and simply provide an information field about the identification of the OVMS user?
My primary interest here is in making it as simple as possible for the OVMS user to opt-in. Requiring them to sign up with OpenChargeMap and provide a PIN or key from the account is an additional step that will prove to be a barrier for users that are willing to opt-in as long as it is merely as easy as a button-press.
Thanks,
Lee.
On 05/21/2014 04:12 AM, Christopher Cook wrote:
....[snip]....
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.
....[/snip]....
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@webb-johnson.net <mailto: mark@webb-johnson.net>> Reply-To: OVMS Developers <ovmsdev@lists.teslaclub.hk <mailto: ovmsdev@lists.teslaclub.hk>>
Date: Wednesday, 21 May 2014 07:19 To: OVMS Developers <ovmsdev@lists.teslaclub.hk <mailto:ovmsdev@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.
....[snip]....
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.
....[snip]....
-- *Lee Howard* *Mainpine, Inc. Chief Technology Officer* Tel: +1 866 363 6680 | Fax: +1 360 462 8160 lee.howard@mainpine.com | www.mainpine.com
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- http://home.scarlet.be/jcsaintpo Get a warning of every update on my site: http://jcsaintpo.notifylist.com/jc_site.html My msn space: http://spaces.msn.com/members/jcstp/
Hi All, To be clear, there is no concrete requirement (from the OCM perspective) for OVMS to use the OCM API to checkin nor for OVMS to authenticate/link OCM users - it's just something that could be done if desired. As J-C suggests the checkin can appear anonymously as 'An OVMS User'. The check-in information can be published into OCM either by using the OCM API to check-in anonymously or by OCM pulling check-in data from the OVMS API. Thats fine and the end result is the same for most people. The disadvantage of not associating the check-in with an OCM user is that the user can never go back and remove/amend their checkin in OCM, which may or may not be an issue for them. If we're pulling from the OVMS API then the question is can we hold identifying information about the user (an ID etc) so that we can reconcile them later if they wish to link their accounts? Behind the scenes OCM holds a User Reputation score which increments when you add/edit a POI or add any comment/photo, some users would probably like their automated checkins to count against that when we get around to having a leaderboard of some sort - so that's a potential scenario for linking user in the future. By submitting data into the OCM API, the data becomes CC BY 3.0 licensed (by association that using the API is acceptance of those terms), whereas OCM pulling from OVMS is subject to whatever applicable license there will be there and if the data will be aggregated/anonymous etc. Likewise other charge map vendors will likely want to use the API to pull data into their own systems. Chris On 22/05/2014 03:29, J-C Saint-Pô wrote:
Maybe people use their ovms usercode to write changes & comments to ocm to an cooperationg ovms server This server writes the changes & comments to ocm as "OVMS-user-submitted" Maybe give ovms users possibility to choose to submit directly to ocm for submitting more ample info And use the "via-ovms" for basic changes or submissions All will depend on how much load you want on the ovms-server
(suggestion submited by someone who only knows the basics on computers & co) ;-) Kind greets JC
2014-05-21 19:04 GMT+02:00 Lee Howard <lee.howard@mainpine.com <mailto:lee.howard@mainpine.com>>:
Hello Mark, Chris, and other OVMS users and developers...
I am happy with all of Mark's outline with only one point for debate. Admittedly, I am new to OpenChargeMap API and OVMS programming, and so maybe I simply don't understand how things work, but...
As the OVMS server will be performing the OpenChargeMap API on behalf of the partner instead of the portable app performing the OpenChargeMap API (more-directly in the control of the partner)... is it really necessary for the OVMS server to masquerade as the partner... using their identity for authentication with OpenChargeMap?
I'd prefer to avoid requiring the user to set-up an independent account with OpenChargeMap and then permit OVMS to operate on behalf of that newly-created account. Could not the OVMS server simply use its own account (for everyone) and simply provide an information field about the identification of the OVMS user?
My primary interest here is in making it as simple as possible for the OVMS user to opt-in. Requiring them to sign up with OpenChargeMap and provide a PIN or key from the account is an additional step that will prove to be a barrier for users that are willing to opt-in as long as it is merely as easy as a button-press.
Thanks,
Lee.
On 05/21/2014 04:12 AM, Christopher Cook wrote:
....[snip]....
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.
....[/snip]....
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@webb-johnson.net <mailto:mark@webb-johnson.net> <mailto:mark@webb-johnson.net <mailto:mark@webb-johnson.net>>> Reply-To: OVMS Developers <ovmsdev@lists.teslaclub.hk <mailto:ovmsdev@lists.teslaclub.hk> <mailto:ovmsdev@lists.teslaclub.hk <mailto:ovmsdev@lists.teslaclub.hk>>>
Date: Wednesday, 21 May 2014 07:19 To: OVMS Developers <ovmsdev@lists.teslaclub.hk <mailto:ovmsdev@lists.teslaclub.hk> <mailto:ovmsdev@lists.teslaclub.hk <mailto:ovmsdev@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.
....[snip]....
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.
....[snip]....
-- *Lee Howard* *Mainpine, Inc. Chief Technology Officer* Tel: +1 866 363 6680 <tel:%2B1%20866%20363%206680> | Fax: +1 360 462 8160 <tel:%2B1%20360%20462%208160> lee.howard@mainpine.com <mailto:lee.howard@mainpine.com> | www.mainpine.com <http://www.mainpine.com>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- http://home.scarlet.be/jcsaintpo
Get a warning of every update on my site: http://jcsaintpo.notifylist.com/jc_site.html
My msn space: http://spaces.msn.com/members/jcstp/
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Hi, There is a design principle at play here that we would do well not to ignore and that is encapsulation. As a general rule there are massive benefits to ensuring that each system is as much as a "black box" as possible. By that I mean that each system functions in isolation taking care of its own business and not getting involved in the business of other systems. Designing systems, programs etc this way removes, or at least reduces, dependencies and decouples functionality. The way I see the integration of OVMS and OCM is that OCM should remain as much as possible a static partner. It should provide an API to allow the adding of locations, checking in, handing out location data etc by anyone. Where ever possible, it should not be pulling data from other systems if we want to reduce these dependencies and remain flexible. Functionally this interface is identical to a person doing the same things except that it is being automated. We should therefore use the same processes. This is not a database transfer, or a bulk data load, which would functionally be initiated by OCM. It is an individual checking in at a single location and so shouldn't we use the same process... OVMS sends the data to OCM via the OCM API? Which userid is used to access OCM is clear to me... it is OVMS that is the source and so there must be a single user in OCM through which OVMS intefaces with the OVMS user id perhaps passed to OCM perhaps as a comment or in one of the other API data fields that makes sense. For OCM to pull data from OVMS, or any system from that matter, is the wrong way to apporach this IMO. Paul On 22 May 2014 03:20, Christopher Cook <christopher.cook@webprofusion.com>wrote:
Hi All,
To be clear, there is no concrete requirement (from the OCM perspective) for OVMS to use the OCM API to checkin nor for OVMS to authenticate/link OCM users - it's just something that could be done if desired. As J-C suggests the checkin can appear anonymously as 'An OVMS User'. The check-in information can be published into OCM either by using the OCM API to check-in anonymously or by OCM pulling check-in data from the OVMS API. Thats fine and the end result is the same for most people. The disadvantage of not associating the check-in with an OCM user is that the user can never go back and remove/amend their checkin in OCM, which may or may not be an issue for them. If we're pulling from the OVMS API then the question is can we hold identifying information about the user (an ID etc) so that we can reconcile them later if they wish to link their accounts?
Behind the scenes OCM holds a User Reputation score which increments when you add/edit a POI or add any comment/photo, some users would probably like their automated checkins to count against that when we get around to having a leaderboard of some sort - so that's a potential scenario for linking user in the future.
By submitting data into the OCM API, the data becomes CC BY 3.0 licensed (by association that using the API is acceptance of those terms), whereas OCM pulling from OVMS is subject to whatever applicable license there will be there and if the data will be aggregated/anonymous etc. Likewise other charge map vendors will likely want to use the API to pull data into their own systems.
Chris
On 22/05/2014 03:29, J-C Saint-Pô wrote:
Maybe people use their ovms usercode to write changes & comments to ocm to an cooperationg ovms server This server writes the changes & comments to ocm as "OVMS-user-submitted" Maybe give ovms users possibility to choose to submit directly to ocm for submitting more ample info And use the "via-ovms" for basic changes or submissions All will depend on how much load you want on the ovms-server
(suggestion submited by someone who only knows the basics on computers & co) ;-) Kind greets JC
2014-05-21 19:04 GMT+02:00 Lee Howard <lee.howard@mainpine.com>:
Hello Mark, Chris, and other OVMS users and developers...
I am happy with all of Mark's outline with only one point for debate. Admittedly, I am new to OpenChargeMap API and OVMS programming, and so maybe I simply don't understand how things work, but...
As the OVMS server will be performing the OpenChargeMap API on behalf of the partner instead of the portable app performing the OpenChargeMap API (more-directly in the control of the partner)... is it really necessary for the OVMS server to masquerade as the partner... using their identity for authentication with OpenChargeMap?
I'd prefer to avoid requiring the user to set-up an independent account with OpenChargeMap and then permit OVMS to operate on behalf of that newly-created account. Could not the OVMS server simply use its own account (for everyone) and simply provide an information field about the identification of the OVMS user?
My primary interest here is in making it as simple as possible for the OVMS user to opt-in. Requiring them to sign up with OpenChargeMap and provide a PIN or key from the account is an additional step that will prove to be a barrier for users that are willing to opt-in as long as it is merely as easy as a button-press.
Thanks,
Lee.
On 05/21/2014 04:12 AM, Christopher Cook wrote:
....[snip]....
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.
....[/snip]....
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@webb-johnson.net <mailto: mark@webb-johnson.net>> Reply-To: OVMS Developers <ovmsdev@lists.teslaclub.hk <mailto: ovmsdev@lists.teslaclub.hk>>
Date: Wednesday, 21 May 2014 07:19 To: OVMS Developers <ovmsdev@lists.teslaclub.hk <mailto: ovmsdev@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.
....[snip]....
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.
....[snip]....
-- *Lee Howard* *Mainpine, Inc. Chief Technology Officer* Tel: +1 866 363 6680 | Fax: +1 360 462 8160 lee.howard@mainpine.com | www.mainpine.com
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- http://home.scarlet.be/jcsaintpo
Get a warning of every update on my site: http://jcsaintpo.notifylist.com/jc_site.html
My msn space: http://spaces.msn.com/members/jcstp/
_______________________________________________ OvmsDev mailing listOvmsDev@lists.teslaclub.hkhttp://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
I'm easy either way, whatever suits everyone else. By the way I'm in the process of a bug update to the OCM API documentation, which is always at: http://openchargemap.org/site/develop/api There is now also a sandboxed API for testing. Chris On 22/05/2014 15:46, Paul Churchley wrote:
Hi,
There is a design principle at play here that we would do well not to ignore and that is encapsulation.
As a general rule there are massive benefits to ensuring that each system is as much as a "black box" as possible. By that I mean that each system functions in isolation taking care of its own business and not getting involved in the business of other systems. Designing systems, programs etc this way removes, or at least reduces, dependencies and decouples functionality.
The way I see the integration of OVMS and OCM is that OCM should remain as much as possible a static partner. It should provide an API to allow the adding of locations, checking in, handing out location data etc by anyone. Where ever possible, it should not be pulling data from other systems if we want to reduce these dependencies and remain flexible.
Functionally this interface is identical to a person doing the same things except that it is being automated. We should therefore use the same processes. This is not a database transfer, or a bulk data load, which would functionally be initiated by OCM. It is an individual checking in at a single location and so shouldn't we use the same process... OVMS sends the data to OCM via the OCM API? Which userid is used to access OCM is clear to me... it is OVMS that is the source and so there must be a single user in OCM through which OVMS intefaces with the OVMS user id perhaps passed to OCM perhaps as a comment or in one of the other API data fields that makes sense.
For OCM to pull data from OVMS, or any system from that matter, is the wrong way to apporach this IMO.
Paul
I don't think it wise just leave such a decision to "what suits everyone else". It should be designed according to good design principles and good practice. Just because it is open source and community-driven it should still not compromise on industry-accepted principles. If we leave it to what is convenient to others then we will end up building in problems for everyone further down the line. Of course we must consider everyone's views in the mix but at the end of the day we should not compromise on what we know to be sound design principles if we want to have a system that is flexible to further needs. Design by committee will not result in a sound overall design IMO. Paul On 22 May 2014 10:27, Christopher Cook <christopher.cook@webprofusion.com>wrote:
I'm easy either way, whatever suits everyone else.
By the way I'm in the process of a bug update to the OCM API documentation, which is always at: http://openchargemap.org/site/develop/api
There is now also a sandboxed API for testing.
Chris
On 22/05/2014 15:46, Paul Churchley wrote:
Hi,
There is a design principle at play here that we would do well not to ignore and that is encapsulation.
As a general rule there are massive benefits to ensuring that each system is as much as a "black box" as possible. By that I mean that each system functions in isolation taking care of its own business and not getting involved in the business of other systems. Designing systems, programs etc this way removes, or at least reduces, dependencies and decouples functionality.
The way I see the integration of OVMS and OCM is that OCM should remain as much as possible a static partner. It should provide an API to allow the adding of locations, checking in, handing out location data etc by anyone. Where ever possible, it should not be pulling data from other systems if we want to reduce these dependencies and remain flexible.
Functionally this interface is identical to a person doing the same things except that it is being automated. We should therefore use the same processes. This is not a database transfer, or a bulk data load, which would functionally be initiated by OCM. It is an individual checking in at a single location and so shouldn't we use the same process... OVMS sends the data to OCM via the OCM API? Which userid is used to access OCM is clear to me... it is OVMS that is the source and so there must be a single user in OCM through which OVMS intefaces with the OVMS user id perhaps passed to OCM perhaps as a comment or in one of the other API data fields that makes sense.
For OCM to pull data from OVMS, or any system from that matter, is the wrong way to apporach this IMO.
Paul
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
On 05/22/2014 12:46 AM, Paul Churchley wrote:
This is not a database transfer, or a bulk data load, which would functionally be initiated by OCM. It is an individual checking in at a single location and so shouldn't we use the same process... OVMS sends the data to OCM via the OCM API? Which userid is used to access OCM is clear to me... it is OVMS that is the source and so there must be a single user in OCM through which OVMS intefaces with the OVMS user id perhaps passed to OCM perhaps as a comment or in one of the other API data fields that makes sense.
This is my preferred default method, as well, as it will permit an OVMS user to add data to OCM without their own account with OCM. This will encourage contribution as requiring individual accounts serves only as a barrier to contribution. However, Chris makes a valid point, then, that it would be difficult (if not impossible) for the OVMS user who may have their own OCM account to make edits to their own contributions to the OCM database. For this reason I think it is reasonable to permit the OVMS user to supply an identification PIN or key from their OCM account to the OVMS server so that OVMS would interact with OCM using the specified OCM account instead of the general OVMS account with OCM. However, by default OVMS should use a general account until the OVMS user supplies OCM identity information, of course. Thanks, Lee. -- *Lee Howard* *Mainpine, Inc. Chief Technology Officer* Tel: +1 866 363 6680 | Fax: +1 360 462 8160 lee.howard@mainpine.com | www.mainpine.com
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
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
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
On 05/22/2014 03:44 PM, Tom Saxton wrote:
Maybe another map vendor wants to add support to OVMS, so the user can choose OCM or PlugShare, or whatever. .... 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.
I am pleased that PlugShare easily accepts data contributions, but does it meet your own criteria listed an hour ago?... On 05/22/2014 02:49 PM, Tom Saxton 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.
I've read through the PlugShare "Terms of Use Agreement", and it seems very much opposed to the "open" philosophy espoused by OVMS (and OCM). Mind you, I have absolutely no objection to anyone developing-in an OVMS feature to contribute information to PlugShare and other databases besides OCM. I merely mean to point out and seek clarification for the apparent conflict in your positions. Thanks, Lee. -- *Lee Howard* *Mainpine, Inc. Chief Technology Officer* Tel: +1 866 363 6680 | Fax: +1 360 462 8160 lee.howard@mainpine.com | www.mainpine.com
I don't care who uses the OVMS data. I just want the OVMS data to be open, same as the Plug In America battery surveys that I run. Tom
On May 22, 2014, at 5:12 PM, Lee Howard <lee.howard@mainpine.com> wrote:
On 05/22/2014 03:44 PM, Tom Saxton wrote: Maybe another map vendor wants to add support to OVMS, so the user can choose OCM or PlugShare, or whatever. .... 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.
I am pleased that PlugShare easily accepts data contributions, but does it meet your own criteria listed an hour ago?...
On 05/22/2014 02:49 PM, Tom Saxton 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.
I've read through the PlugShare "Terms of Use Agreement", and it seems very much opposed to the "open" philosophy espoused by OVMS (and OCM).
Mind you, I have absolutely no objection to anyone developing-in an OVMS feature to contribute information to PlugShare and other databases besides OCM. I merely mean to point out and seek clarification for the apparent conflict in your positions.
Thanks,
Lee.
-- *Lee Howard* *Mainpine, Inc. Chief Technology Officer* Tel: +1 866 363 6680 | Fax: +1 360 462 8160 lee.howard@mainpine.com | www.mainpine.com _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Hi Tom, That sounds like broadly the correct process to me. The key thing for making the info useful to other users is identifying the specific charging location, OCM is capable of holding references to other map vendors charging locations and associating them as metadata tags attached to the charging location in OCM. So OCM can (and is supposed to be) a central list of charging locations, which can have pointers to the same location in other vendors systems. Vendors could use the OCM API to work out which of their charging locations was checked into using this metadata. Obviously if the checkin goes to PlugShare directly then we can't get that info, as they won't give OCM an API key (currently.. did try that!). Lee, I don't think there was an intention to create a new database of charging locations in OVMS (unless I've missed something). Note that OVMS doesn't strictly need to go through authentication to post checkins/comments to OCM as a single OVMS user. We can provide an API key to OVMS that works indefinitely and posts/adds/edits as that user. Regards, Chris On 23/05/2014 06:44, Tom Saxton wrote:
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 <mailto: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 <mailto: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 <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto: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
On 05/22/2014 02:49 PM, Tom Saxton 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.
Is OCM not open-enough already that it could simply be viewed as the charging-location database for OVMS? Why should OVMS duplicate the effort of developing a charging-location database? Lee. -- *Lee Howard* *Mainpine, Inc. Chief Technology Officer* Tel: +1 866 363 6680 | Fax: +1 360 462 8160 lee.howard@mainpine.com | www.mainpine.com
I'm not proposing that OVMS develop a charging location database. It merely stores charging reports, "at this date and time, someone charged at 240V/70A at this longitude and latitude." Tom
On May 22, 2014, at 3:44 PM, Lee Howard <lee.howard@mainpine.com> wrote:
On 05/22/2014 02:49 PM, Tom Saxton 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.
Is OCM not open-enough already that it could simply be viewed as the charging-location database for OVMS? Why should OVMS duplicate the effort of developing a charging-location database?
Lee.
-- *Lee Howard* *Mainpine, Inc. Chief Technology Officer* Tel: +1 866 363 6680 | Fax: +1 360 462 8160 lee.howard@mainpine.com | www.mainpine.com
On that topic, what other data can OVMS provide about the charging session? Just interested as to what we can/should include in OCM. For OCM this would be a flexible chunk of OVMS specific (JSON format) data attached to the checkin which OVMS can add/remove fields to over time. OVMS could also provide a textual comment "charged for 30 mins @ 240V/70A" or similar but we would have the more detailed breakdown available for later parsing. Chris On 23/05/2014 09:38, Tom Saxton wrote:
I'm not proposing that OVMS develop a charging location database. It merely stores charging reports, "at this date and time, someone charged at 240V/70A at this longitude and latitude."
Tom
On May 22, 2014, at 3:44 PM, Lee Howard <lee.howard@mainpine.com> wrote:
On 05/22/2014 02:49 PM, Tom Saxton 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. Is OCM not open-enough already that it could simply be viewed as the charging-location database for OVMS? Why should OVMS duplicate the effort of developing a charging-location database?
Lee.
-- *Lee Howard* *Mainpine, Inc. Chief Technology Officer* Tel: +1 866 363 6680 | Fax: +1 360 462 8160 lee.howard@mainpine.com | www.mainpine.com
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
OVMS could provide the vehicle type, the battery charge state, and by interpreting information from between the start-of-charge and the end-of-charge I'd think OCM could potentially interpret how much power was obtained. I'm not sure how useful all of that is. Thanks, Lee. On 05/22/2014 06:58 PM, Christopher Cook wrote:
On that topic, what other data can OVMS provide about the charging session? Just interested as to what we can/should include in OCM. For OCM this would be a flexible chunk of OVMS specific (JSON format) data attached to the checkin which OVMS can add/remove fields to over time. OVMS could also provide a textual comment "charged for 30 mins @ 240V/70A" or similar but we would have the more detailed breakdown available for later parsing.
Chris
On 23/05/2014 09:38, Tom Saxton wrote:
I'm not proposing that OVMS develop a charging location database. It merely stores charging reports, "at this date and time, someone charged at 240V/70A at this longitude and latitude."
Tom
On May 22, 2014, at 3:44 PM, Lee Howard <lee.howard@mainpine.com> wrote:
On 05/22/2014 02:49 PM, Tom Saxton 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. Is OCM not open-enough already that it could simply be viewed as the charging-location database for OVMS? Why should OVMS duplicate the effort of developing a charging-location database?
Lee.
-- *Lee Howard* *Mainpine, Inc. Chief Technology Officer* Tel: +1 866 363 6680 | Fax: +1 360 462 8160 lee.howard@mainpine.com | www.mainpine.com
_______________________________________________ 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
-- *Lee Howard* *Mainpine, Inc. Chief Technology Officer* Tel: +1 866 363 6680 | Fax: +1 360 462 8160 lee.howard@mainpine.com | www.mainpine.com
Could someone provide an update with respect to where the code is at with updating Open Charge Map? I know that I've been saying this was on my near-proximity radar, but I wanted to let those who were more-familiar with OVMS do this... if they wanted to. I've been keeping tabs on recent opinions regarding publishing charging locations, and privacy seems to be a substantial concern. For the most part people don't want to see automatically-published charging locations for private residences or other private-access locations. It is my understanding that while databases like Plugshare may welcome private residences others like OCM are deliberately trying to avoid inclusion of these for privacy reasons. Therefore, it may not be wise to publish charging info automatically. Maybe the app could prompt the user each time a charge is completed with a simple "yes" or "no" prompt to publish (or not) the charging information to OCM. Thoughts? Thanks, Lee. On 05/22/2014 09:07 PM, Lee Howard wrote:
OVMS could provide the vehicle type, the battery charge state, and by interpreting information from between the start-of-charge and the end-of-charge I'd think OCM could potentially interpret how much power was obtained. I'm not sure how useful all of that is.
Thanks,
Lee.
On 05/22/2014 06:58 PM, Christopher Cook wrote:
On that topic, what other data can OVMS provide about the charging session? Just interested as to what we can/should include in OCM. For OCM this would be a flexible chunk of OVMS specific (JSON format) data attached to the checkin which OVMS can add/remove fields to over time. OVMS could also provide a textual comment "charged for 30 mins @ 240V/70A" or similar but we would have the more detailed breakdown available for later parsing.
Chris
On 23/05/2014 09:38, Tom Saxton wrote:
I'm not proposing that OVMS develop a charging location database. It merely stores charging reports, "at this date and time, someone charged at 240V/70A at this longitude and latitude."
Tom
On May 22, 2014, at 3:44 PM, Lee Howard <lee.howard@mainpine.com> wrote:
On 05/22/2014 02:49 PM, Tom Saxton 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. Is OCM not open-enough already that it could simply be viewed as the charging-location database for OVMS? Why should OVMS duplicate the effort of developing a charging-location database?
Lee.
-- *Lee Howard* *Mainpine, Inc. Chief Technology Officer* Tel: +1 866 363 6680 | Fax: +1 360 462 8160 lee.howard@mainpine.com | www.mainpine.com
_______________________________________________ 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
-- *Lee Howard* *Mainpine, Inc. Chief Technology Officer* Tel: +1 866 363 6680 | Fax: +1 360 462 8160 lee.howard@mainpine.com | www.mainpine.com
Lee, It is on my plate. The problem I am having is the vehicle firmware. I am trying to build a very lightweight event framework for picking up and reporting charge start and complete events (as well as drive start and complete events), but the problem is that we are very tight on space now. We have this in the logging framework, but that is too big to fit in some of the builds, so I'm trying to take it out of logging and make a smaller common framework which logging can use - but do that with little ram/flash impact. Once the events are coming out, we can then report them back to the server. I'd also like to use the same framework to improve notifications (for example, some people want notifications whenever a charge is finished while others want them only when a charge is interrupted) - I'm trying to save ram/flash by moving notifications to this new system, that I can then use for the new system to end up memory-neutral. The privacy issues were documented in a framework eMail a while ago (copy attached). There were some comments that followed, which will be incorporated. We too would only like to focus on public charge stations. Regards, Mark. On 16 Oct, 2014, at 11:18 am, Lee Howard <lee.howard@mainpine.com> wrote:
Could someone provide an update with respect to where the code is at with updating Open Charge Map?
I know that I've been saying this was on my near-proximity radar, but I wanted to let those who were more-familiar with OVMS do this... if they wanted to.
I've been keeping tabs on recent opinions regarding publishing charging locations, and privacy seems to be a substantial concern. For the most part people don't want to see automatically-published charging locations for private residences or other private-access locations. It is my understanding that while databases like Plugshare may welcome private residences others like OCM are deliberately trying to avoid inclusion of these for privacy reasons.
Therefore, it may not be wise to publish charging info automatically. Maybe the app could prompt the user each time a charge is completed with a simple "yes" or "no" prompt to publish (or not) the charging information to OCM.
Thoughts?
Thanks,
Lee.
On 05/22/2014 09:07 PM, Lee Howard wrote:
OVMS could provide the vehicle type, the battery charge state, and by interpreting information from between the start-of-charge and the end-of-charge I'd think OCM could potentially interpret how much power was obtained. I'm not sure how useful all of that is.
Thanks,
Lee.
On 05/22/2014 06:58 PM, Christopher Cook wrote:
On that topic, what other data can OVMS provide about the charging session? Just interested as to what we can/should include in OCM. For OCM this would be a flexible chunk of OVMS specific (JSON format) data attached to the checkin which OVMS can add/remove fields to over time. OVMS could also provide a textual comment "charged for 30 mins @ 240V/70A" or similar but we would have the more detailed breakdown available for later parsing.
Chris
On 23/05/2014 09:38, Tom Saxton wrote:
I'm not proposing that OVMS develop a charging location database. It merely stores charging reports, "at this date and time, someone charged at 240V/70A at this longitude and latitude."
Tom
On May 22, 2014, at 3:44 PM, Lee Howard <lee.howard@mainpine.com> wrote:
On 05/22/2014 02:49 PM, Tom Saxton 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. Is OCM not open-enough already that it could simply be viewed as the charging-location database for OVMS? Why should OVMS duplicate the effort of developing a charging-location database?
Lee.
-- *Lee Howard* *Mainpine, Inc. Chief Technology Officer* Tel: +1 866 363 6680 | Fax: +1 360 462 8160 lee.howard@mainpine.com | www.mainpine.com
_______________________________________________ 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
-- *Lee Howard* *Mainpine, Inc. Chief Technology Officer* Tel: +1 866 363 6680 | Fax: +1 360 462 8160 lee.howard@mainpine.com | www.mainpine.com _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
I can see your point Lee. I see OCM slightly different in that I see it as just one of many potential charging databases out there that OVMS may want to interact with. By using OCM as the charging database of OVMS you remove all aspect of control over the data. The data collected by the OVMS users belongs to them, and by inference to OVMS. Just giving it to OCM as our datastore means that OVMS only has "acces"s to that data via the OCM API... we wouldn't have control over the data itself. We would have lost all element of direct control including where it goes to after OCM. That would then be down to OCM. If those issues could be overcome, of if people consider these points unimportant, then we could use the OCM database as "our" database I suppose. Perhaps OCM and OVMS would like to merge projects? Then this issue goes away :-) Just a thought :-) Smartphone apps are great but I believe that the best place to do location relatively complex and comms-dependent tasks; such as matching, sending updates to OCM etc, is on the OVMS server. What if there is a new database that OVMS wants to update also? The phone app would need updating and every user would need to update their app. In fact, some of that code might be pretty big or complex and that would then reside on relatively low-powered phone devices instead of the server. I wouldn't see this as a batch task. It could still be real-time and triggered by the phone app. On 22 May 2014 23:44, Lee Howard <lee.howard@mainpine.com> wrote:
On 05/22/2014 02:49 PM, Tom Saxton 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.
Is OCM not open-enough already that it could simply be viewed as the charging-location database for OVMS? Why should OVMS duplicate the effort of developing a charging-location database?
Lee.
-- *Lee Howard* *Mainpine, Inc. Chief Technology Officer* Tel: +1 866 363 6680 | Fax: +1 360 462 8160 lee.howard@mainpine.com | www.mainpine.com _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
I think there is a difference between the charging database (locations) and events (charge start/stop by a particular user at a particular time). We chose OCM (or did OCM choose us ;-) precisely because we didn’t need another charging database. Both the Android and iPhone Apps have some integration to OCM already. I suggest the data records for charge events that we publish should be keyed on geofencing of the latitude+longitude of the charging event. The OCM station ID can be optionally provided by the user, and other consumers could cross-reference that to provide correlation to their own databases (if they think it necessary and can abide to the OCM license terms). Regards, Mark On 23 May, 2014, at 4:15 pm, Paul Churchley <paul@churchley.org> wrote:
I can see your point Lee.
I see OCM slightly different in that I see it as just one of many potential charging databases out there that OVMS may want to interact with. By using OCM as the charging database of OVMS you remove all aspect of control over the data. The data collected by the OVMS users belongs to them, and by inference to OVMS. Just giving it to OCM as our datastore means that OVMS only has "acces"s to that data via the OCM API... we wouldn't have control over the data itself. We would have lost all element of direct control including where it goes to after OCM. That would then be down to OCM.
If those issues could be overcome, of if people consider these points unimportant, then we could use the OCM database as "our" database I suppose.
Perhaps OCM and OVMS would like to merge projects? Then this issue goes away :-) Just a thought :-)
Smartphone apps are great but I believe that the best place to do location relatively complex and comms-dependent tasks; such as matching, sending updates to OCM etc, is on the OVMS server. What if there is a new database that OVMS wants to update also? The phone app would need updating and every user would need to update their app. In fact, some of that code might be pretty big or complex and that would then reside on relatively low-powered phone devices instead of the server. I wouldn't see this as a batch task. It could still be real-time and triggered by the phone app.
On 22 May 2014 23:44, Lee Howard <lee.howard@mainpine.com> wrote: On 05/22/2014 02:49 PM, Tom Saxton 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.
Is OCM not open-enough already that it could simply be viewed as the charging-location database for OVMS? Why should OVMS duplicate the effort of developing a charging-location database?
Lee.
-- *Lee Howard* *Mainpine, Inc. Chief Technology Officer* Tel: +1 866 363 6680 | Fax: +1 360 462 8160 lee.howard@mainpine.com | www.mainpine.com _______________________________________________ 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
I expect that grouping by geofencing will be helpful, but there will be problems, so I think it's important to retain the original longitude/latitude coordinates. Consider Bellevue Square (700 Bellevue Way NE, Bellevue, WA 98004). There are five separate charging sites all within a 300 meter radius circle and all in covered parking garages so GPS coordinates will be spotty at best (probably a reading from before the vehicle entered the garage). Two of the sites are 5 feet apart and yet so different they should be treated separately (four 208V/30A public ChargePoint stations and a Tesla-only area with one each Model S and Roadster 208V/70A HPWC). None of the maps I checked (OCM, PlugShare, ChargePoint, US DOE) has it right even if we allow lumping the Tesla stations and ChargePoint stations together. For example, in OCM the pin for OCM-4350 is in the wrong place by about 100m (and is marked as private restricted access). OCM-4310 is in the right place for a nearby site, correctly marked as public, but only reports 2 stations when there are four. OCM-4311 looks like a duplicate of OCM-4310 but is in the wrong place by about 50 m and says it's private restricted access. I could be charging at OCM-4350 and even if I had perfect GPS coordinates by some miracle, I'd be closer to the arguably bogus OCM-4311 location. Any attempt to map from the OCM site record to another vendor's site database will definitely fail. So I vote for not geofencing; let the charge map folks do that (perhaps with help from the OVMS app user). It would be great to have a way to map each report to a charge site ID as long as that's flexible enough to allow IDs from multiple map vendors. If I'm using OCM, I'd want to map to an OCM site ID. If I'm using another map, I want to be able to associate my report with their ID. I'm really looking forward to having a charging station map that will let me find, and report status on, high-amp L2 stations. BTW, it looks like OCM needs to grab the stations from the Sun Country Highway network. I have a Perl script that will do it which I'm happy to share. Tom On 5/23/14, 1:23 AM, "Mark Webb-Johnson" <mark@webb-johnson.net> wrote: I think there is a difference between the charging database (locations) and events (charge start/stop by a particular user at a particular time). We chose OCM (or did OCM choose us ;-) precisely because we didn¹t need another charging database. Both the Android and iPhone Apps have some integration to OCM already. I suggest the data records for charge events that we publish should be keyed on geofencing of the latitude+longitude of the charging event. The OCM station ID can be optionally provided by the user, and other consumers could cross-reference that to provide correlation to their own databases (if they think it necessary and can abide to the OCM license terms). Regards, Mark On 23 May, 2014, at 4:15 pm, Paul Churchley <paul@churchley.org> wrote:
I can see your point Lee.
I see OCM slightly different in that I see it as just one of many potential charging databases out there that OVMS may want to interact with. By using OCM as the charging database of OVMS you remove all aspect of control over the data. The data collected by the OVMS users belongs to them, and by inference to OVMS. Just giving it to OCM as our datastore means that OVMS only has "acces"s to that data via the OCM API... we wouldn't have control over the data itself. We would have lost all element of direct control including where it goes to after OCM. That would then be down to OCM.
If those issues could be overcome, of if people consider these points unimportant, then we could use the OCM database as "our" database I suppose.
Perhaps OCM and OVMS would like to merge projects? Then this issue goes away :-) Just a thought :-)
Smartphone apps are great but I believe that the best place to do location relatively complex and comms-dependent tasks; such as matching, sending updates to OCM etc, is on the OVMS server. What if there is a new database that OVMS wants to update also? The phone app would need updating and every user would need to update their app. In fact, some of that code might be pretty big or complex and that would then reside on relatively low-powered phone devices instead of the server. I wouldn't see this as a batch task. It could still be real-time and triggered by the phone app.
On 22 May 2014 23:44, Lee Howard <lee.howard@mainpine.com> wrote:
On 05/22/2014 02:49 PM, Tom Saxton 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.
Is OCM not open-enough already that it could simply be viewed as the charging-location database for OVMS? Why should OVMS duplicate the effort of developing a charging-location database?
Lee.
-- *Lee Howard* *Mainpine, Inc. Chief Technology Officer* Tel: +1 866 363 6680 <tel:%2B1%20866%20363%206680> | Fax: +1 360 462 8160 <tel:%2B1%20360%20462%208160> lee.howard@mainpine.com | www.mainpine.com <http://www.mainpine.com/> _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <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
I think that OCM needs to be mindful of copyright when taking data from other sources. In fact, I know that Christopher Cook of OCM is mindful of that. So unless the data at the Sun Country Highway Network is open source OCM will be cautious of "grabbing" data from anywhere. This whole area of potential of breach of copyright and data licensing is something we all need to me mindful of. :-) On 23 May 2014 22:06, Tom Saxton <tom@idleloop.com> wrote:
I expect that grouping by geofencing will be helpful, but there will be problems, so I think it's important to retain the original longitude/latitude coordinates.
Consider Bellevue Square (700 Bellevue Way NE, Bellevue, WA 98004). There are five separate charging sites all within a 300 meter radius circle and all in covered parking garages so GPS coordinates will be spotty at best (probably a reading from before the vehicle entered the garage). Two of the sites are 5 feet apart and yet so different they should be treated separately (four 208V/30A public ChargePoint stations and a Tesla-only area with one each Model S and Roadster 208V/70A HPWC). None of the maps I checked (OCM, PlugShare, ChargePoint, US DOE) has it right even if we allow lumping the Tesla stations and ChargePoint stations together.
For example, in OCM the pin for OCM-4350 is in the wrong place by about 100m (and is marked as private restricted access). OCM-4310 is in the right place for a nearby site, correctly marked as public, but only reports 2 stations when there are four. OCM-4311 looks like a duplicate of OCM-4310 but is in the wrong place by about 50 m and says it's private restricted access. I could be charging at OCM-4350 and even if I had perfect GPS coordinates by some miracle, I'd be closer to the arguably bogus OCM-4311 location. Any attempt to map from the OCM site record to another vendor's site database will definitely fail.
So I vote for not geofencing; let the charge map folks do that (perhaps with help from the OVMS app user). It would be great to have a way to map each report to a charge site ID as long as that's flexible enough to allow IDs from multiple map vendors. If I'm using OCM, I'd want to map to an OCM site ID. If I'm using another map, I want to be able to associate my report with their ID.
I'm really looking forward to having a charging station map that will let me find, and report status on, high-amp L2 stations.
BTW, it looks like OCM needs to grab the stations from the Sun Country Highway network. I have a Perl script that will do it which I'm happy to share.
Tom
On 5/23/14, 1:23 AM, "Mark Webb-Johnson" <mark@webb-johnson.net> wrote:
I think there is a difference between the charging database (locations) and events (charge start/stop by a particular user at a particular time).
We chose OCM (or did OCM choose us ;-) precisely because we didn’t need another charging database. Both the Android and iPhone Apps have some integration to OCM already.
I suggest the data records for charge events that we publish should be keyed on geofencing of the latitude+longitude of the charging event. The OCM station ID can be optionally provided by the user, and other consumers could cross-reference that to provide correlation to their own databases (if they think it necessary and can abide to the OCM license terms).
Regards, Mark
On 23 May, 2014, at 4:15 pm, Paul Churchley <paul@churchley.org> wrote:
I can see your point Lee.
I see OCM slightly different in that I see it as just one of many potential charging databases out there that OVMS may want to interact with. By using OCM as the charging database of OVMS you remove all aspect of control over the data. The data collected by the OVMS users belongs to them, and by inference to OVMS. Just giving it to OCM as our datastore means that OVMS only has "acces"s to that data via the OCM API... we wouldn't have control over the data itself. We would have lost all element of direct control including where it goes to after OCM. That would then be down to OCM.
If those issues could be overcome, of if people consider these points unimportant, then we could use the OCM database as "our" database I suppose.
Perhaps OCM and OVMS would like to merge projects? Then this issue goes away :-) Just a thought :-)
Smartphone apps are great but I believe that the best place to do location relatively complex and comms-dependent tasks; such as matching, sending updates to OCM etc, is on the OVMS server. What if there is a new database that OVMS wants to update also? The phone app would need updating and every user would need to update their app. In fact, some of that code might be pretty big or complex and that would then reside on relatively low-powered phone devices instead of the server. I wouldn't see this as a batch task. It could still be real-time and triggered by the phone app.
On 22 May 2014 23:44, Lee Howard <lee.howard@mainpine.com> wrote:
On 05/22/2014 02:49 PM, Tom Saxton 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.
Is OCM not open-enough already that it could simply be viewed as the charging-location database for OVMS? Why should OVMS duplicate the effort of developing a charging-location database?
Lee.
-- *Lee Howard* *Mainpine, Inc. Chief Technology Officer* Tel: +1 866 363 6680 | Fax: +1 360 462 8160 lee.howard@mainpine.com | www.mainpine.com _______________________________________________ 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
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
That's a fair point, although I don't think it's especially proprietary since users can report the same information manually. The stations are all public. I'd suggest contacting Kent Rathwell: Kent Rathwell President and Founder Sun Country Highway kent@suncountryhighway.ca 306-612-4600 800-467-6920 If Kent says it's OK, but can't give you a nice data feed, my script may be useful. Tom On 5/23/14, 2:46 PM, "Paul Churchley" <paul@churchley.org> wrote: I think that OCM needs to be mindful of copyright when taking data from other sources. In fact, I know that Christopher Cook of OCM is mindful of that. So unless the data at the Sun Country Highway Network is open source OCM will be cautious of "grabbing" data from anywhere. This whole area of potential of breach of copyright and data licensing is something we all need to me mindful of. :-) On 23 May 2014 22:06, Tom Saxton <tom@idleloop.com> wrote:
I expect that grouping by geofencing will be helpful, but there will be problems, so I think it's important to retain the original longitude/latitude coordinates.
Consider Bellevue Square (700 Bellevue Way NE, Bellevue, WA 98004). There are five separate charging sites all within a 300 meter radius circle and all in covered parking garages so GPS coordinates will be spotty at best (probably a reading from before the vehicle entered the garage). Two of the sites are 5 feet apart and yet so different they should be treated separately (four 208V/30A public ChargePoint stations and a Tesla-only area with one each Model S and Roadster 208V/70A HPWC). None of the maps I checked (OCM, PlugShare, ChargePoint, US DOE) has it right even if we allow lumping the Tesla stations and ChargePoint stations together.
For example, in OCM the pin for OCM-4350 is in the wrong place by about 100m (and is marked as private restricted access). OCM-4310 is in the right place for a nearby site, correctly marked as public, but only reports 2 stations when there are four. OCM-4311 looks like a duplicate of OCM-4310 but is in the wrong place by about 50 m and says it's private restricted access. I could be charging at OCM-4350 and even if I had perfect GPS coordinates by some miracle, I'd be closer to the arguably bogus OCM-4311 location. Any attempt to map from the OCM site record to another vendor's site database will definitely fail.
So I vote for not geofencing; let the charge map folks do that (perhaps with help from the OVMS app user). It would be great to have a way to map each report to a charge site ID as long as that's flexible enough to allow IDs from multiple map vendors. If I'm using OCM, I'd want to map to an OCM site ID. If I'm using another map, I want to be able to associate my report with their ID.
I'm really looking forward to having a charging station map that will let me find, and report status on, high-amp L2 stations.
BTW, it looks like OCM needs to grab the stations from the Sun Country Highway network. I have a Perl script that will do it which I'm happy to share.
Tom
On 5/23/14, 1:23 AM, "Mark Webb-Johnson" <mark@webb-johnson.net> wrote:
I think there is a difference between the charging database (locations) and events (charge start/stop by a particular user at a particular time).
We chose OCM (or did OCM choose us ;-) precisely because we didn¹t need another charging database. Both the Android and iPhone Apps have some integration to OCM already.
I suggest the data records for charge events that we publish should be keyed on geofencing of the latitude+longitude of the charging event. The OCM station ID can be optionally provided by the user, and other consumers could cross-reference that to provide correlation to their own databases (if they think it necessary and can abide to the OCM license terms).
Regards, Mark
On 23 May, 2014, at 4:15 pm, Paul Churchley <paul@churchley.org> wrote:
I can see your point Lee.
I see OCM slightly different in that I see it as just one of many potential charging databases out there that OVMS may want to interact with. By using OCM as the charging database of OVMS you remove all aspect of control over the data. The data collected by the OVMS users belongs to them, and by inference to OVMS. Just giving it to OCM as our datastore means that OVMS only has "acces"s to that data via the OCM API... we wouldn't have control over the data itself. We would have lost all element of direct control including where it goes to after OCM. That would then be down to OCM.
If those issues could be overcome, of if people consider these points unimportant, then we could use the OCM database as "our" database I suppose.
Perhaps OCM and OVMS would like to merge projects? Then this issue goes away :-) Just a thought :-)
Smartphone apps are great but I believe that the best place to do location relatively complex and comms-dependent tasks; such as matching, sending updates to OCM etc, is on the OVMS server. What if there is a new database that OVMS wants to update also? The phone app would need updating and every user would need to update their app. In fact, some of that code might be pretty big or complex and that would then reside on relatively low-powered phone devices instead of the server. I wouldn't see this as a batch task. It could still be real-time and triggered by the phone app.
On 22 May 2014 23:44, Lee Howard <lee.howard@mainpine.com> wrote:
On 05/22/2014 02:49 PM, Tom Saxton 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.
Is OCM not open-enough already that it could simply be viewed as the charging-location database for OVMS? Why should OVMS duplicate the effort of developing a charging-location database?
Lee.
-- *Lee Howard* *Mainpine, Inc. Chief Technology Officer* Tel: +1 866 363 6680 <tel:%2B1%20866%20363%206680> | Fax: +1 360 462 8160 <tel:%2B1%20360%20462%208160> lee.howard@mainpine.com | www.mainpine.com <http://www.mainpine.com/> _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <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.hkhttp://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
Thanks Tom, we can chase that up, or alternatively if you know people at these networks you're welcome to invite them to join OCM as a data provider (just CC myself and J-C Saint-Po) - we are generally trying to convince them to donate their information under a CC BY S-A 3.0 license (http://creativecommons.org/licenses/by-sa/3.0/) but we'll consider other terms as long as it means we can redistribute the information via our API etc. In general most US stations have come from either the DOE AFDC system or from Carstations.com (and these would probably have been a point of reference for other map providers as well). It would generally be better for OCM to pull from the networks own data sets however these are often locked into systems we're not permitted to copy from. Historically we've been flexible about our data sources (so OCM data has mixed data licensing terms which can be seen in the Data Provider section of each POI) but we're now pretty strict about getting explicit permission - for instance we got permission yesterday to redistribute another 600 Canadian locations under an open data license. De-duplication is a big and surprisingly complicated problem. Currently we will try not to add stations which are within 100m of each other specifically because it may just be the same location described differently. In general stations from the same network are grouped under 1 POI with multiple equipment details entries. The absolute best way to get the information correct is for you to edit things when you see that they're wrong, or add information if you see it's not there. I realise that's where it gets frustrating because you end up having to enter stuff into all the various apps you use. Thanks for the offer of the perl script, we have a fairly standardised import mechanism (written in C#, which is similar to Java) which you can see here (excuse the mess, several of these providers are not used): https://github.com/openchargemap/ocm-system/tree/master/Import/OCM.Import.Co... Chris On 24/05/2014 06:19, Tom Saxton wrote:
That's a fair point, although I don't think it's especially proprietary since users can report the same information manually. The stations are all public.
I'd suggest contacting Kent Rathwell:
Kent Rathwell President and Founder Sun Country Highway kent@suncountryhighway.ca 306-612-4600 800-467-6920
If Kent says it's OK, but can't give you a nice data feed, my script may be useful.
Tom
On 5/23/14, 2:46 PM, "Paul Churchley" <paul@churchley.org <mailto:paul@churchley.org>> wrote:
I think that OCM needs to be mindful of copyright when taking data from other sources. In fact, I know that Christopher Cook of OCM is mindful of that. So unless the data at the Sun Country Highway Network is open source OCM will be cautious of "grabbing" data from anywhere.
This whole area of potential of breach of copyright and data licensing is something we all need to me mindful of. :-)
Tom, To be clear: I was only suggesting geofencing at the server per-user-per-chargestation level, to determine the user's preference for sharing information at this particular station. For the data published, I'd rather just send out raw GPS coordinates of the event (with OCM station ID as an optional field, if confirmed by the user). Regards, Mark. On 24 May, 2014, at 5:06 am, Tom Saxton <tom@idleloop.com> wrote:
I expect that grouping by geofencing will be helpful, but there will be problems, so I think it's important to retain the original longitude/latitude coordinates.
Consider Bellevue Square (700 Bellevue Way NE, Bellevue, WA 98004). There are five separate charging sites all within a 300 meter radius circle and all in covered parking garages so GPS coordinates will be spotty at best (probably a reading from before the vehicle entered the garage). Two of the sites are 5 feet apart and yet so different they should be treated separately (four 208V/30A public ChargePoint stations and a Tesla-only area with one each Model S and Roadster 208V/70A HPWC). None of the maps I checked (OCM, PlugShare, ChargePoint, US DOE) has it right even if we allow lumping the Tesla stations and ChargePoint stations together.
For example, in OCM the pin for OCM-4350 is in the wrong place by about 100m (and is marked as private restricted access). OCM-4310 is in the right place for a nearby site, correctly marked as public, but only reports 2 stations when there are four. OCM-4311 looks like a duplicate of OCM-4310 but is in the wrong place by about 50 m and says it's private restricted access. I could be charging at OCM-4350 and even if I had perfect GPS coordinates by some miracle, I'd be closer to the arguably bogus OCM-4311 location. Any attempt to map from the OCM site record to another vendor's site database will definitely fail.
So I vote for not geofencing; let the charge map folks do that (perhaps with help from the OVMS app user). It would be great to have a way to map each report to a charge site ID as long as that's flexible enough to allow IDs from multiple map vendors. If I'm using OCM, I'd want to map to an OCM site ID. If I'm using another map, I want to be able to associate my report with their ID.
I'm really looking forward to having a charging station map that will let me find, and report status on, high-amp L2 stations.
BTW, it looks like OCM needs to grab the stations from the Sun Country Highway network. I have a Perl script that will do it which I'm happy to share.
Tom
On 5/23/14, 1:23 AM, "Mark Webb-Johnson" <mark@webb-johnson.net> wrote:
I think there is a difference between the charging database (locations) and events (charge start/stop by a particular user at a particular time).
We chose OCM (or did OCM choose us ;-) precisely because we didn’t need another charging database. Both the Android and iPhone Apps have some integration to OCM already.
I suggest the data records for charge events that we publish should be keyed on geofencing of the latitude+longitude of the charging event. The OCM station ID can be optionally provided by the user, and other consumers could cross-reference that to provide correlation to their own databases (if they think it necessary and can abide to the OCM license terms).
Regards, Mark
On 23 May, 2014, at 4:15 pm, Paul Churchley <paul@churchley.org> wrote:
I can see your point Lee.
I see OCM slightly different in that I see it as just one of many potential charging databases out there that OVMS may want to interact with. By using OCM as the charging database of OVMS you remove all aspect of control over the data. The data collected by the OVMS users belongs to them, and by inference to OVMS. Just giving it to OCM as our datastore means that OVMS only has "acces"s to that data via the OCM API... we wouldn't have control over the data itself. We would have lost all element of direct control including where it goes to after OCM. That would then be down to OCM.
If those issues could be overcome, of if people consider these points unimportant, then we could use the OCM database as "our" database I suppose.
Perhaps OCM and OVMS would like to merge projects? Then this issue goes away :-) Just a thought :-)
Smartphone apps are great but I believe that the best place to do location relatively complex and comms-dependent tasks; such as matching, sending updates to OCM etc, is on the OVMS server. What if there is a new database that OVMS wants to update also? The phone app would need updating and every user would need to update their app. In fact, some of that code might be pretty big or complex and that would then reside on relatively low-powered phone devices instead of the server. I wouldn't see this as a batch task. It could still be real-time and triggered by the phone app.
On 22 May 2014 23:44, Lee Howard <lee.howard@mainpine.com> wrote:
On 05/22/2014 02:49 PM, Tom Saxton 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.
Is OCM not open-enough already that it could simply be viewed as the charging-location database for OVMS? Why should OVMS duplicate the effort of developing a charging-location database?
Lee.
-- *Lee Howard* *Mainpine, Inc. Chief Technology Officer* Tel: +1 866 363 6680 | Fax: +1 360 462 8160 lee.howard@mainpine.com | www.mainpine.com _______________________________________________ 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 _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Well guys, I've been spamming chargingnetworks again with e-mails the last 2-3 weeks To the detriment of christopher's e-mail too christopher.cook@webprofusion.com I am slowly guessing that gmail adresses are blocked in many company's, because answers are very scarce! So I think the best thing for you guys is if you want a certain network to be added to openchargemap, you try, and warn christopher, I try to add stations, via info I find or get on internet. Without infringing copyright of other chargingstationmaps. It's slow, but I do my best Openchargemap will only grow, and get more accurate the more users, use it! This is why opendata & interconnection between open databases will be the future! The more uses for the database the better! 2014-05-26 3:00 GMT+02:00 Mark Webb-Johnson <mark@webb-johnson.net>:
Tom,
To be clear: I was only suggesting geofencing at the server per-user-per-chargestation level, to determine the user's preference for sharing information at this particular station. For the data published, I'd rather just send out raw GPS coordinates of the event (with OCM station ID as an optional field, if confirmed by the user).
Regards, Mark.
On 24 May, 2014, at 5:06 am, Tom Saxton <tom@idleloop.com> wrote:
I expect that grouping by geofencing will be helpful, but there will be problems, so I think it's important to retain the original longitude/latitude coordinates.
Consider Bellevue Square (700 Bellevue Way NE, Bellevue, WA 98004). There are five separate charging sites all within a 300 meter radius circle and all in covered parking garages so GPS coordinates will be spotty at best (probably a reading from before the vehicle entered the garage). Two of the sites are 5 feet apart and yet so different they should be treated separately (four 208V/30A public ChargePoint stations and a Tesla-only area with one each Model S and Roadster 208V/70A HPWC). None of the maps I checked (OCM, PlugShare, ChargePoint, US DOE) has it right even if we allow lumping the Tesla stations and ChargePoint stations together.
For example, in OCM the pin for OCM-4350 is in the wrong place by about 100m (and is marked as private restricted access). OCM-4310 is in the right place for a nearby site, correctly marked as public, but only reports 2 stations when there are four. OCM-4311 looks like a duplicate of OCM-4310 but is in the wrong place by about 50 m and says it's private restricted access. I could be charging at OCM-4350 and even if I had perfect GPS coordinates by some miracle, I'd be closer to the arguably bogus OCM-4311 location. Any attempt to map from the OCM site record to another vendor's site database will definitely fail.
So I vote for not geofencing; let the charge map folks do that (perhaps with help from the OVMS app user). It would be great to have a way to map each report to a charge site ID as long as that's flexible enough to allow IDs from multiple map vendors. If I'm using OCM, I'd want to map to an OCM site ID. If I'm using another map, I want to be able to associate my report with their ID.
I'm really looking forward to having a charging station map that will let me find, and report status on, high-amp L2 stations.
BTW, it looks like OCM needs to grab the stations from the Sun Country Highway network. I have a Perl script that will do it which I'm happy to share.
Tom
On 5/23/14, 1:23 AM, "Mark Webb-Johnson" <mark@webb-johnson.net> wrote:
I think there is a difference between the charging database (locations) and events (charge start/stop by a particular user at a particular time).
We chose OCM (or did OCM choose us ;-) precisely because we didn’t need another charging database. Both the Android and iPhone Apps have some integration to OCM already.
I suggest the data records for charge events that we publish should be keyed on geofencing of the latitude+longitude of the charging event. The OCM station ID can be optionally provided by the user, and other consumers could cross-reference that to provide correlation to their own databases (if they think it necessary and can abide to the OCM license terms).
Regards, Mark
On 23 May, 2014, at 4:15 pm, Paul Churchley <paul@churchley.org> wrote:
I can see your point Lee.
I see OCM slightly different in that I see it as just one of many potential charging databases out there that OVMS may want to interact with. By using OCM as the charging database of OVMS you remove all aspect of control over the data. The data collected by the OVMS users belongs to them, and by inference to OVMS. Just giving it to OCM as our datastore means that OVMS only has "acces"s to that data via the OCM API... we wouldn't have control over the data itself. We would have lost all element of direct control including where it goes to after OCM. That would then be down to OCM.
If those issues could be overcome, of if people consider these points unimportant, then we could use the OCM database as "our" database I suppose.
Perhaps OCM and OVMS would like to merge projects? Then this issue goes away :-) Just a thought :-)
Smartphone apps are great but I believe that the best place to do location relatively complex and comms-dependent tasks; such as matching, sending updates to OCM etc, is on the OVMS server. What if there is a new database that OVMS wants to update also? The phone app would need updating and every user would need to update their app. In fact, some of that code might be pretty big or complex and that would then reside on relatively low-powered phone devices instead of the server. I wouldn't see this as a batch task. It could still be real-time and triggered by the phone app.
On 22 May 2014 23:44, Lee Howard <lee.howard@mainpine.com> wrote:
On 05/22/2014 02:49 PM, Tom Saxton 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.
Is OCM not open-enough already that it could simply be viewed as the charging-location database for OVMS? Why should OVMS duplicate the effort of developing a charging-location database?
Lee.
-- *Lee Howard* *Mainpine, Inc. Chief Technology Officer* Tel: +1 866 363 6680 | Fax: +1 360 462 8160 lee.howard@mainpine.com | www.mainpine.com _______________________________________________ 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 _______________________________________________ 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
-- http://home.scarlet.be/jcsaintpo Get a warning of every update on my site: http://jcsaintpo.notifylist.com/jc_site.html My msn space: http://spaces.msn.com/members/jcstp/
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@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&_... 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@webb-johnson.net> Reply-To: OVMS Developers <ovmsdev@lists.teslaclub.hk> Date: Wednesday, 21 May 2014 07:19 To: OVMS Developers <ovmsdev@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@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
On 4 May, 2014, at 7:01 pm, Christopher Cook <christopher.cook@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@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@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hkhttp://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
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@webprofusion.com <mailto:christopher.cook@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&_... * 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@webb-johnson.net <mailto:mark@webb-johnson.net>> Reply-To: OVMS Developers <ovmsdev@lists.teslaclub.hk <mailto:ovmsdev@lists.teslaclub.hk>> Date: Wednesday, 21 May 2014 07:19 To: OVMS Developers <ovmsdev@lists.teslaclub.hk <mailto:ovmsdev@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@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
On 4 May, 2014, at 7:01 pm, Christopher Cook <christopher.cook@webprofusion.com <mailto:christopher.cook@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@gmail.com <mailto:jcsaintpo@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@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto: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 <mailto: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
-- *Lee Howard* *Mainpine, Inc. Chief Technology Officer* Tel: +1 866 363 6680 | Fax: +1 360 462 8160 lee.howard@mainpine.com | www.mainpine.com
Hello Does anyone know if there exists a tutorial/quick guide on how to setup the environment needed to code and build the firmware? --Olav
Have you seen the OVMS_Development document in the GitHub repository? https://github.com/openvehicles/Open-Vehicle-Monitoring-System/blob/master/ docs/OVMS_Development.pdf Tom -----Original Message----- From: "Olav A. Antonsen" <olav@ansit.no> Reply-To: OVMS Developers <ovmsdev@lists.teslaclub.hk> Date: Tuesday, June 10, 2014 at 3:20 PM To: OVMS Developers <ovmsdev@lists.teslaclub.hk> Subject: [Ovmsdev] Build environment
Hello
Does anyone know if there exists a tutorial/quick guide on how to setup the environment needed to code and build the firmware?
--Olav
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
I just built a VMWare virtual machine this week to build the firmware. All my machines use windows so I had to select a linux distro to use the unlimited MPLAB C18 linux compiler. I selected the latest xubuntu release and it worked well. If you are a developer, it is straight forward and only took me about 2 hours to build the full working setup. I needed to compile code for the Think City as my hardware came programmed with the Tesla firmware (I just build the V2_Experimental which includes ThinkCity]. The PICKIT 3 worked fine. I also found a cheap US provider for the sim card (consumer cellular). They are a AT&T reseller but have very nice terms for our limited use (much better than going to AT&T directly). $11.88 / month for 200 text messages and 20 MB of data (1000 text and 100 MB data only costs $14.25). These prices are with the AARP 5% discount. Choose the "Anywhere Casual" which has 0 minutes, and add the "Connect! Lite" services for 200 text and 20 MB data. Another nice feature is that you can change the services during the month right up to the day they bill you so if you go over one month, you choose the next plan if it is cheaper. You can't loose and you can auto bill your credit card. Right now they are running a special until July 15. If you sign up with a referral link, you get $20 added to your account (that is about 1.5 months free). Here is the referral link to save $20: http://www.consumercellular.com/Friends/9717774519 It would be easy to create a downloadable image (self extracting) that you could run under the free VMWare player that is capable of building the firmware. Would that be of use to anyone? If so, I can easily create one and share the link. Phil H. On Tue, Jun 10, 2014 at 3:20 PM, Olav A. Antonsen <olav@ansit.no> wrote:
Hello
Does anyone know if there exists a tutorial/quick guide on how to setup the environment needed to code and build the firmware?
--Olav
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
On 06/11/2014 09:37 AM, phil hochstetler wrote:
They are a AT&T reseller but have very nice terms for our limited use (much better than going to AT&T directly). $11.88 / month for 200 text messages and 20 MB of data (1000 text and 100 MB data only costs $14.25). These prices are with the AARP 5% discount.
A minimal AT&T GoPhone with text and data pay-as-you-go is $10/month or $100/year (prepaid). You can get that just by walking into an AT&T store. At $100/yr that's $8.34/mo. Just sayin'. Lee. -- *Lee Howard* *Mainpine, Inc. Chief Technology Officer* Tel: +1 866 363 6680 | Fax: +1 360 462 8160 lee.howard@mainpine.com | www.mainpine.com
Lee, I think the issue is that people in US are finding it hard to actually buy that GoPhone plan. AT&T seem to be dropping it, market-by-market. Regards, Mark. On 12 Jun, 2014, at 6:16 am, Lee Howard <lee.howard@mainpine.com> wrote:
On 06/11/2014 09:37 AM, phil hochstetler wrote:
They are a AT&T reseller but have very nice terms for our limited use (much better than going to AT&T directly). $11.88 / month for 200 text messages and 20 MB of data (1000 text and 100 MB data only costs $14.25). These prices are with the AARP 5% discount.
A minimal AT&T GoPhone with text and data pay-as-you-go is $10/month or $100/year (prepaid). You can get that just by walking into an AT&T store. At $100/yr that's $8.34/mo.
Just sayin'.
Lee.
-- *Lee Howard* *Mainpine, Inc. Chief Technology Officer* Tel: +1 866 363 6680 | Fax: +1 360 462 8160 lee.howard@mainpine.com | www.mainpine.com _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
That's believable. I've had GoPhone for almost a year now, but had let the account lapse after only a month or two of use. It took going into the store in-person to reinstate (recreate) an account since it looks impossible to do on-line. Wireless service in the USA is a miserable experience. I much-appreciated the wireless pay-as-you-go services and SIM-swapping freedom that I experienced for a few months in Ukraine last year. Thanks, Lee. On 06/11/2014 04:52 PM, Mark Webb-Johnson wrote:
Lee,
I think the issue is that people in US are finding it hard to actually buy that GoPhone plan. AT&T seem to be dropping it, market-by-market.
Regards, Mark.
On 12 Jun, 2014, at 6:16 am, Lee Howard <lee.howard@mainpine.com> wrote:
On 06/11/2014 09:37 AM, phil hochstetler wrote:
They are a AT&T reseller but have very nice terms for our limited use (much better than going to AT&T directly). $11.88 / month for 200 text messages and 20 MB of data (1000 text and 100 MB data only costs $14.25). These prices are with the AARP 5% discount. A minimal AT&T GoPhone with text and data pay-as-you-go is $10/month or $100/year (prepaid). You can get that just by walking into an AT&T store. At $100/yr that's $8.34/mo.
Just sayin'.
Lee.
-- *Lee Howard* *Mainpine, Inc. Chief Technology Officer* Tel: +1 866 363 6680 | Fax: +1 360 462 8160 lee.howard@mainpine.com | www.mainpine.com _______________________________________________ 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
-- *Lee Howard* *Mainpine, Inc. Chief Technology Officer* Tel: +1 866 363 6680 | Fax: +1 360 462 8160 lee.howard@mainpine.com | www.mainpine.com
I walked into my local AT&T store and tried exactly that. They told me you cannot get that deal anymore. The cheapest go phone deal was more than $20/month. Phil H. On Wed, Jun 11, 2014 at 3:16 PM, Lee Howard <lee.howard@mainpine.com> wrote:
On 06/11/2014 09:37 AM, phil hochstetler wrote:
They are a AT&T reseller but have very nice terms for our limited use (much better than going to AT&T directly). $11.88 / month for 200 text messages and 20 MB of data (1000 text and 100 MB data only costs $14.25). These prices are with the AARP 5% discount.
A minimal AT&T GoPhone with text and data pay-as-you-go is $10/month or $100/year (prepaid). You can get that just by walking into an AT&T store. At $100/yr that's $8.34/mo.
Just sayin'.
Lee.
-- *Lee Howard* *Mainpine, Inc. Chief Technology Officer* Tel: +1 866 363 6680 | Fax: +1 360 462 8160 lee.howard@mainpine.com | www.mainpine.com
Here is the GoPhone plan to which I signed-up: https://www.paygonline.com/websc/rateplans/rateplan_en.jsp ----------------------- 10¢/minutefor all nationwide calls, pay per use data and pay per use text (or add messaging package) Messaging Packages available for 10¢/minute plan. $19.99 for Unlimited, $9.99 for 1,000 Messages and $4.99 for 200 Messages Pay-Per-Use Rates: Domestic Text - 20¢ per message sent/received, International text - 25¢ per message sent/20¢ per message received Domestic Picture/Video - 25¢ per message sent/received, International Picture/Video - 50¢ per message sent/25¢ per message received Data - 1¢/5 kb (Basic & Quick Messaging phones only). Pay per use data is not available for smartphones ------------------------ The bit about pre-paying $10/mo or $100/yr is here: http://www.att.com/shop/wireless/plans/prepaidplans.html#tabAccount ----------------------- * *Buy a GoPhone Refill card* at AT&T wireless stores or any one of more than 200,000 retail locations. Many cards will prompt you to refill right on your phone using the card PIN. Otherwise, you can also add the value online <https://www.paygonline.com/websc/index.jsp>. o Refill cards have varying expiration dates. $10 to $24 refill cards expire in 30 days; $25 to $99 expire in 90 days and $100 and higher expire in 1 year. ----------------------- So because I paid $100 up-front I have 1 year to use that up in the plan fees (OVMS will use texting and data only). If I limit this OVMS module to very little texting (mostly using it for start-up configuration) I should come-in under $100 data usage in the year. Recognize that you have to take a phone in with you (not a smart phone) or buy one of their phones that are not "smart" for this package. Then take the SIM out and put it into the OVMS module. If you talk to them about OVMS and such then some staff will consider it like a "tablet" or a "mobile hotspot", and then you end up in a different category. Thanks, Lee. On 06/11/2014 09:54 PM, phil hochstetler wrote:
I walked into my local AT&T store and tried exactly that. They told me you cannot get that deal anymore. The cheapest go phone deal was more than $20/month.
Phil H.
On Wed, Jun 11, 2014 at 3:16 PM, Lee Howard <lee.howard@mainpine.com <mailto:lee.howard@mainpine.com>> wrote:
On 06/11/2014 09:37 AM, phil hochstetler wrote:
They are a AT&T reseller but have very nice terms for our limited use (much better than going to AT&T directly). $11.88 / month for 200 text messages and 20 MB of data (1000 text and 100 MB data only costs $14.25). These prices are with the AARP 5% discount.
A minimal AT&T GoPhone with text and data pay-as-you-go is $10/month or $100/year (prepaid). You can get that just by walking into an AT&T store. At $100/yr that's $8.34/mo.
Just sayin'.
Lee.
-- *Lee Howard* *Mainpine, Inc. Chief Technology Officer* Tel: +1 866 363 6680 <tel:%2B1%20866%20363%206680> | Fax: +1 360 462 8160 <tel:%2B1%20360%20462%208160> lee.howard@mainpine.com <mailto:lee.howard@mainpine.com> | www.mainpine.com <http://www.mainpine.com>
_______________________________________________ OvmsDev mailing list OvmsDev@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@mainpine.com | www.mainpine.com
I expect that the H2O plan I described on this TMC post will cost me a bit over $40 per year ($10 for 90 days times 4) plus 5 cents per text message. http://www.teslamotorsclub.com/showthread.php/7716-OVMS-Installation?p=66689 7&viewfull=1#post666897 Tom -----Original Message----- From: Lee Howard <lee.howard@mainpine.com> Reply-To: OVMS Developers <ovmsdev@lists.teslaclub.hk> Date: Thursday, June 12, 2014 at 10:00 AM To: OVMS Developers <ovmsdev@lists.teslaclub.hk> Subject: Re: [Ovmsdev] Build environment
Here is the GoPhone plan to which I signed-up:
https://www.paygonline.com/websc/rateplans/rateplan_en.jsp
----------------------- 10¢/minutefor all nationwide calls, pay per use data and pay per use text (or add messaging package)
Messaging Packages available for 10¢/minute plan. $19.99 for Unlimited, $9.99 for 1,000 Messages and $4.99 for 200 Messages
Pay-Per-Use Rates: Domestic Text - 20¢ per message sent/received, International text - 25¢ per message sent/20¢ per message received Domestic Picture/Video - 25¢ per message sent/received, International Picture/Video - 50¢ per message sent/25¢ per message received Data - 1¢/5 kb (Basic & Quick Messaging phones only). Pay per use data is not available for smartphones ------------------------
The bit about pre-paying $10/mo or $100/yr is here:
http://www.att.com/shop/wireless/plans/prepaidplans.html#tabAccount
-----------------------
* *Buy a GoPhone Refill card* at AT&T wireless stores or any one of more than 200,000 retail locations. Many cards will prompt you to refill right on your phone using the card PIN. Otherwise, you can also add the value online <https://www.paygonline.com/websc/index.jsp>. o Refill cards have varying expiration dates. $10 to $24 refill cards expire in 30 days; $25 to $99 expire in 90 days and $100 and higher expire in 1 year.
-----------------------
So because I paid $100 up-front I have 1 year to use that up in the plan fees (OVMS will use texting and data only). If I limit this OVMS module to very little texting (mostly using it for start-up configuration) I should come-in under $100 data usage in the year.
Recognize that you have to take a phone in with you (not a smart phone) or buy one of their phones that are not "smart" for this package. Then take the SIM out and put it into the OVMS module.
If you talk to them about OVMS and such then some staff will consider it like a "tablet" or a "mobile hotspot", and then you end up in a different category.
Thanks,
Lee.
On 06/11/2014 09:54 PM, phil hochstetler wrote:
I walked into my local AT&T store and tried exactly that. They told me you cannot get that deal anymore. The cheapest go phone deal was more than $20/month.
Phil H.
On Wed, Jun 11, 2014 at 3:16 PM, Lee Howard <lee.howard@mainpine.com <mailto:lee.howard@mainpine.com>> wrote:
On 06/11/2014 09:37 AM, phil hochstetler wrote:
They are a AT&T reseller but have very nice terms for our limited use (much better than going to AT&T directly). $11.88 / month for 200 text messages and 20 MB of data (1000 text and 100 MB data only costs $14.25). These prices are with the AARP 5% discount.
A minimal AT&T GoPhone with text and data pay-as-you-go is $10/month or $100/year (prepaid). You can get that just by walking into an AT&T store. At $100/yr that's $8.34/mo.
Just sayin'.
Lee.
-- *Lee Howard* *Mainpine, Inc. Chief Technology Officer* Tel: +1 866 363 6680 <tel:%2B1%20866%20363%206680> | Fax: +1 360 462 8160 <tel:%2B1%20360%20462%208160> lee.howard@mainpine.com <mailto:lee.howard@mainpine.com> | www.mainpine.com <http://www.mainpine.com>
_______________________________________________ OvmsDev mailing list OvmsDev@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@mainpine.com | www.mainpine.com _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
The document https://github.com/openvehicles/Open-Vehicle-Monitoring-System/blob/master/d ocs/OVMS_Development.pdf helps a lot when it comes to setting up the dev environment. I set up the environment on windows 8, but it seems like everyone else is using linux to build the firmware. I was able to build the hex file (on win 8), but I haven't been able to test the file yet because I'm still waiting for my unit. https://dl.dropboxusercontent.com/u/12327518/OVMS.X.production.hex Is anyone else using win 8 to build the firmware? On the project in MPLAB it's possible to choose between different configurations 1)V1_Production 2)V2_Experimental 3)V2_Production 4)V2_TR_Production 5)V2_RT_Production The development documentation tells the user to select "V2_Experimental". What is the purpose of configuration 4 and 5? --Olav -----Opprinnelig melding----- Fra: ovmsdev-bounces@lists.teslaclub.hk [mailto:ovmsdev-bounces@lists.teslaclub.hk] På vegne av Olav A. Antonsen Sendt: 11. juni 2014 00:21 Til: 'OVMS Developers' Emne: [Ovmsdev] Build environment Hello Does anyone know if there exists a tutorial/quick guide on how to setup the environment needed to code and build the firmware? --Olav _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
The issue with building under windows is that the C compiler Microchip gives for free used to do medium-optimisation under windows, with high-optimisation a cost option. Then, they switched (silently, without any fanfare) to no-optimisation for the windows compiler. Both the Linux and OSX compiler continue with medium-optimisation. Without optimisation, the code won't fit into available flash space. They sell a commercial version of the C18 compiler for about US$500. Almost enough to drive one to ARM... I have heard rumours of people typing 'microchip c18 hack' into google. Configurations 4 and 5 are the 'full' featured production builds for Tesla Roadster and Renault Twizy (provided as a convenience for owners of those vehicles who just want a binary .hex to flash). Regards, Mark. On 12 Jun, 2014, at 6:55 am, Olav A. Antonsen <olav@ansit.no> wrote:
The document
https://github.com/openvehicles/Open-Vehicle-Monitoring-System/blob/master/d ocs/OVMS_Development.pdf
helps a lot when it comes to setting up the dev environment. I set up the environment on windows 8, but it seems like everyone else is using linux to build the firmware.
I was able to build the hex file (on win 8), but I haven't been able to test the file yet because I'm still waiting for my unit.
https://dl.dropboxusercontent.com/u/12327518/OVMS.X.production.hex
Is anyone else using win 8 to build the firmware?
On the project in MPLAB it's possible to choose between different configurations
1)V1_Production 2)V2_Experimental 3)V2_Production 4)V2_TR_Production 5)V2_RT_Production
The development documentation tells the user to select "V2_Experimental". What is the purpose of configuration 4 and 5?
--Olav
-----Opprinnelig melding----- Fra: ovmsdev-bounces@lists.teslaclub.hk [mailto:ovmsdev-bounces@lists.teslaclub.hk] På vegne av Olav A. Antonsen Sendt: 11. juni 2014 00:21 Til: 'OVMS Developers' Emne: [Ovmsdev] Build environment
Hello
Does anyone know if there exists a tutorial/quick guide on how to setup the environment needed to code and build the firmware?
--Olav
_______________________________________________ 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
I'm using the mcc18 compiler from a CD that came in the package when ordering the OVMS from FastTech. MPLAB C18 v3.35 Copyright 2000-2010 Microchip Technology Inc. Looks like 3.47 is the latest version (http://www.microchip.com/Developmenttools/ProductDetails.aspx?PartNO=SW0060 11). Do you know if v3.35 still uses medium-optimisation? Is there a way to detect what level of optimisation the compiler uses? --Olav -----Opprinnelig melding----- Fra: ovmsdev-bounces@lists.teslaclub.hk [mailto:ovmsdev-bounces@lists.teslaclub.hk] På vegne av Mark Webb-Johnson Sendt: 12. juni 2014 01:51 Til: OVMS Developers Emne: Re: [Ovmsdev] Build environment The issue with building under windows is that the C compiler Microchip gives for free used to do medium-optimisation under windows, with high-optimisation a cost option. Then, they switched (silently, without any fanfare) to no-optimisation for the windows compiler. Both the Linux and OSX compiler continue with medium-optimisation. Without optimisation, the code won't fit into available flash space. They sell a commercial version of the C18 compiler for about US$500. Almost enough to drive one to ARM... I have heard rumours of people typing 'microchip c18 hack' into google. Configurations 4 and 5 are the 'full' featured production builds for Tesla Roadster and Renault Twizy (provided as a convenience for owners of those vehicles who just want a binary .hex to flash). Regards, Mark. On 12 Jun, 2014, at 6:55 am, Olav A. Antonsen <olav@ansit.no> wrote:
The document
https://github.com/openvehicles/Open-Vehicle-Monitoring-System/blob/ma ster/d ocs/OVMS_Development.pdf
helps a lot when it comes to setting up the dev environment. I set up the environment on windows 8, but it seems like everyone else is using linux to build the firmware.
I was able to build the hex file (on win 8), but I haven't been able to test the file yet because I'm still waiting for my unit.
https://dl.dropboxusercontent.com/u/12327518/OVMS.X.production.hex
Is anyone else using win 8 to build the firmware?
On the project in MPLAB it's possible to choose between different configurations
1)V1_Production 2)V2_Experimental 3)V2_Production 4)V2_TR_Production 5)V2_RT_Production
The development documentation tells the user to select "V2_Experimental". What is the purpose of configuration 4 and 5?
--Olav
-----Opprinnelig melding----- Fra: ovmsdev-bounces@lists.teslaclub.hk [mailto:ovmsdev-bounces@lists.teslaclub.hk] På vegne av Olav A. Antonsen Sendt: 11. juni 2014 00:21 Til: 'OVMS Developers' Emne: [Ovmsdev] Build environment
Hello
Does anyone know if there exists a tutorial/quick guide on how to setup the environment needed to code and build the firmware?
--Olav
_______________________________________________ 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
Olav, Probably the easiest way is to try to build the RT_Production code. That is probably the biggest we have - if it will build then at least medium optimisations are working. Regards, Mark. On 12 Jun, 2014, at 8:16 am, Olav A. Antonsen <olav@ansit.no> wrote:
I'm using the mcc18 compiler from a CD that came in the package when ordering the OVMS from FastTech.
MPLAB C18 v3.35 Copyright 2000-2010 Microchip Technology Inc.
Looks like 3.47 is the latest version (http://www.microchip.com/Developmenttools/ProductDetails.aspx?PartNO=SW0060 11). Do you know if v3.35 still uses medium-optimisation? Is there a way to detect what level of optimisation the compiler uses?
--Olav
-----Opprinnelig melding----- Fra: ovmsdev-bounces@lists.teslaclub.hk [mailto:ovmsdev-bounces@lists.teslaclub.hk] På vegne av Mark Webb-Johnson Sendt: 12. juni 2014 01:51 Til: OVMS Developers Emne: Re: [Ovmsdev] Build environment
The issue with building under windows is that the C compiler Microchip gives for free used to do medium-optimisation under windows, with high-optimisation a cost option. Then, they switched (silently, without any fanfare) to no-optimisation for the windows compiler. Both the Linux and OSX compiler continue with medium-optimisation. Without optimisation, the code won't fit into available flash space. They sell a commercial version of the C18 compiler for about US$500. Almost enough to drive one to ARM... I have heard rumours of people typing 'microchip c18 hack' into google.
Configurations 4 and 5 are the 'full' featured production builds for Tesla Roadster and Renault Twizy (provided as a convenience for owners of those vehicles who just want a binary .hex to flash).
Regards, Mark.
On 12 Jun, 2014, at 6:55 am, Olav A. Antonsen <olav@ansit.no> wrote:
The document
https://github.com/openvehicles/Open-Vehicle-Monitoring-System/blob/ma ster/d ocs/OVMS_Development.pdf
helps a lot when it comes to setting up the dev environment. I set up the environment on windows 8, but it seems like everyone else is using linux to build the firmware.
I was able to build the hex file (on win 8), but I haven't been able to test the file yet because I'm still waiting for my unit.
https://dl.dropboxusercontent.com/u/12327518/OVMS.X.production.hex
Is anyone else using win 8 to build the firmware?
On the project in MPLAB it's possible to choose between different configurations
1)V1_Production 2)V2_Experimental 3)V2_Production 4)V2_TR_Production 5)V2_RT_Production
The development documentation tells the user to select "V2_Experimental". What is the purpose of configuration 4 and 5?
--Olav
-----Opprinnelig melding----- Fra: ovmsdev-bounces@lists.teslaclub.hk [mailto:ovmsdev-bounces@lists.teslaclub.hk] På vegne av Olav A. Antonsen Sendt: 11. juni 2014 00:21 Til: 'OVMS Developers' Emne: [Ovmsdev] Build environment
Hello
Does anyone know if there exists a tutorial/quick guide on how to setup the environment needed to code and build the firmware?
--Olav
_______________________________________________ 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
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
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@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@webprofusion.com <mailto:christopher.cook@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&_... * 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@webb-johnson.net <mailto:mark@webb-johnson.net>> Reply-To: OVMS Developers <ovmsdev@lists.teslaclub.hk <mailto:ovmsdev@lists.teslaclub.hk>> Date: Wednesday, 21 May 2014 07:19 To: OVMS Developers <ovmsdev@lists.teslaclub.hk <mailto:ovmsdev@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@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
On 4 May, 2014, at 7:01 pm, Christopher Cook <christopher.cook@webprofusion.com <mailto:christopher.cook@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@gmail.com <mailto:jcsaintpo@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@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto: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 <mailto: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
-- *Lee Howard* *Mainpine, Inc. Chief Technology Officer* Tel: +1 866 363 6680 | Fax: +1 360 462 8160 lee.howard@mainpine.com | www.mainpine.com _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
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@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@mainpine.com | www.mainpine.com
participants (9)
-
Christopher Cook -
J-C Saint-Pô -
Kevin Sharpe -
Lee Howard -
Mark Webb-Johnson -
Olav A. Antonsen -
Paul Churchley -
phil hochstetler -
Tom Saxton