<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hi Mark,<br>
<br>
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. <br>
<br>
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
<a class="moz-txt-link-freetext" href="http://openchargemap.org/site/poi/add">http://openchargemap.org/site/poi/add</a> then waiting until the url
changes to <a class="moz-txt-link-freetext" href="http://openchargemap.org/site/poi/details/12345">http://openchargemap.org/site/poi/details/12345</a> - you
can then grab the OCM-ID from the url for the subsequent checkin
to OVMS.<br>
<br>
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. <br>
<br>
A bit about the relevant bits of OCM API (if they were required):<br>
<br>
For simple web browser based stuff:<br>
checking in/commenting:
<a class="moz-txt-link-freetext" href="http://openchargemap.org/site/poi/addcomment/12345">http://openchargemap.org/site/poi/addcomment/12345</a><br>
add photos: <a class="moz-txt-link-freetext" href="http://openchargemap.org/site/poi/addmediaitem/12345">http://openchargemap.org/site/poi/addmediaitem/12345</a><br>
edit a POI: <a class="moz-txt-link-freetext" href="http://openchargemap.org/site/poi/edit/1234">http://openchargemap.org/site/poi/edit/1234</a><br>
add a new POI: <a class="moz-txt-link-freetext" href="http://openchargemap.org/site/poi/add">http://openchargemap.org/site/poi/add</a><br>
<br>
For actual API level stuff:<br>
An anonymous checkin to OCM can be done via the API by posting to
<span style="color: rgb(20, 20, 20); font-family: Helvetica,
Arial, sans-serif; font-size: 15px; font-style: normal;
font-variant: normal; font-weight: 300; letter-spacing: normal;
line-height: 20.53333282470703px; orphans: auto; text-align:
left; text-indent: 0px; text-transform: none; white-space:
normal; widows: auto; word-spacing: 0px;
-webkit-text-stroke-width: 0px; background-color: rgb(255, 255,
255); display: inline !important; float: none;"><a class="moz-txt-link-freetext" href="http://api.openchargemap.io/v2/?action=comment_submission&format=json">http://api.openchargemap.io/v2/?action=comment_submission&format=json</a></span>
with a JSON string for the comment object in the http post such
as:<br>
<pre style="color: rgb(0, 0, 0); font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; white-space: pre-wrap;">{
"ChargePointID": 12345,
"CommentType": {
"ID": 10,
"Title": "General Comment"
},
"UserName": "A. Nickname",
"Comment": "This place is awesome",
"Rating": 5,
"RelatedURL": <a class="moz-txt-link-rfc2396E" href="http://awesomevplace.com">"http://awesomevplace.com"</a>,
"CheckinStatusType": {
"IsPositive": null,
"IsAutomatedCheckin": false,
"ID": 0,
"Title": "Did Not Visit Location"
}
}</pre>
Checkin/Comment types can be found at:
<a class="moz-txt-link-freetext" href="http://api.openchargemap.io/v2/referencedata/">http://api.openchargemap.io/v2/referencedata/</a><br>
<br>
I'll be setting up a sandpit API shortly so that app folks can try
out checkins etc. <br>
<br>
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:<br>
<ul>
<li><a class="moz-txt-link-freetext" href="http://openchargemap.org/site/loginprovider/?_mode=silent&_forceLogin=true&_redirectURL=AppLogin?redirectWithToken=true">http://openchargemap.org/site/loginprovider/?_mode=silent&_forceLogin=true&_redirectURL=AppLogin?redirectWithToken=true</a></li>
<li>And ending at:
<a class="moz-txt-link-freetext" href="http://openchargemap.org/site/loginprovider/applogin">http://openchargemap.org/site/loginprovider/applogin</a></li>
<li>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.<br>
</li>
</ul>
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.<br>
<br>
Chris<br>
<br>
On 21/05/2014 15:23, Kevin Sharpe wrote:<br>
</div>
<blockquote
cite="mid:CFA212A6.4091A%25kevin.sharpe@zerocarbonworld.org"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<div>
<div>
<div>FYI, I’ve asked Lee Howard from Mainpine to take a look
at this in detail.</div>
<div><br>
</div>
<div><br>
</div>
<div><span style="font-family: 'helvetica neue'; font-size:
medium;">Kevin Sharpe | Founder & Patron | Zero Carbon
World is a UK Registered Charity #1141347</span></div>
<div><br>
</div>
</div>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:11pt;
text-align:left; color:black; BORDER-BOTTOM: medium none;
BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT:
0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid;
BORDER-RIGHT: medium none; PADDING-TOP: 3pt"><span
style="font-weight:bold">From: </span> Mark Webb-Johnson
<<a moz-do-not-send="true"
href="mailto:mark@webb-johnson.net">mark@webb-johnson.net</a>><br>
<span style="font-weight:bold">Reply-To: </span> OVMS
Developers <<a moz-do-not-send="true"
href="mailto:ovmsdev@lists.teslaclub.hk">ovmsdev@lists.teslaclub.hk</a>><br>
<span style="font-weight:bold">Date: </span> Wednesday, 21
May 2014 07:19<br>
<span style="font-weight:bold">To: </span> OVMS Developers
<<a moz-do-not-send="true"
href="mailto:ovmsdev@lists.teslaclub.hk">ovmsdev@lists.teslaclub.hk</a>><br>
<span style="font-weight:bold">Subject: </span> Re: [Ovmsdev]
Open Charge Map<br>
</div>
<div><br>
</div>
<div>
<div style="word-wrap: break-word; -webkit-nbsp-mode: space;
-webkit-line-break: after-white-space;">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.
<div><br>
</div>
<div>Regards, Mark.</div>
<div><br>
</div>
<div>
<blockquote style="margin: 0 0 0 40px; border: none;
padding: 0px;">
<div>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.</div>
<div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Thanks, Mark.</div>
<div><br>
</div>
<div><font size="4"><b><u>Sharing Public Charge Data</u></b></font></div>
<div><br>
</div>
<div><u><font size="4"><b>The Problem</b></font></u></div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div><u><font size="4"><b>Pre-Requisites</b></font></u></div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div><u><font size="4"><b>Licensing</b></font></u></div>
<div><br>
</div>
<div>The data produced should be licensed in some
‘open’ way. Do with it as you will. Perhaps creative
commons, or something similar.</div>
<div><br>
</div>
<div><u><font size="4"><b>Vehicle Firmware Changes</b></font></u></div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div><u><font size="4"><b>App Changes</b></font></u></div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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:</div>
<div> a) Always shared charging information for this
location</div>
<div> b) Share just this once charging information
for this location</div>
<div> c) Do not share this one charging session for
this location.</div>
<div> d) Never share charging information for this
location</div>
<div><br>
</div>
<div>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).</div>
<div><br>
</div>
<div>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:</div>
<div> a) Charge was successful, but interrupted by
the user</div>
<div> b) Charge was unsuccessful, due to a problem
with the charging station</div>
<div> c) Charge was unsuccessful, but not a problem
of the charging station.</div>
<div><br>
</div>
<div>The user’s response must be returned to the
server appropriately.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div><u><font size="4"><b>Server Changes</b></font></u></div>
<div><br>
</div>
<div>The servers will maintain opt-in status for each
vehicle in the system, and if opted-in, the nickname
/ anonymous handle for the vehicle.</div>
<div><br>
</div>
<div>The servers will maintain a historical list of
charging locations for each vehicle in the system.
Each location record would have:</div>
<div> a) Latitude, Longitude (geofenced).</div>
<div> b) Sharing flag (pending user, just this once,
always, not this once, or never).</div>
<div> c) Charging information (date/time charge
started, etc).</div>
<div> d) Date and result of last charge here.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>If there is no matching record found, a new
record would be created (sharing flag: pending
user).</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>If the sharing flag indicates that the charging
information should be shared, the server would
publish the charging session information
appropriately.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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).</div>
<div><br>
</div>
<div>
<div><u><font size="4"><b>Partners</b></font></u></div>
<div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
</div>
</div>
<div><u><font size="4"><b>Overview (start to finish)</b></font></u></div>
<div><br>
</div>
<div>An OVMS user opts in to the service. He uses the
nickname ‘Jimbo’.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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).</div>
<div><br>
</div>
<div>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?</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Partners not using PUSH notifications can
retrieve all this information at a later date by a
simple HTTP PULL request.</div>
<div><br>
</div>
<div><u><font size="4"><b>Further work</b></font></u></div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>For example:</div>
<div><br>
</div>
<div>* Pictures of new charging locations.</div>
<div>* Information for new charging locations.</div>
<div>* Charging station information.</div>
<div>* Showing current usage of a particular station
in the Apps.</div>
<div>* and so much more</div>
<div><br>
</div>
<div><u><font size="4"><b>Privacy Issues</b></font></u></div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Perhaps a one-way hash could be used for storing
locations, but we would have to find one that also
worked with geofenced lookups.</div>
<div><br>
</div>
<div><font size="4"><b><u>Conclusions</u></b></font></div>
<div><br>
</div>
<div>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).</div>
<div><br>
</div>
_______________________________________________<br>
OvmsDev mailing list<br>
<a moz-do-not-send="true"
href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a><br>
<a moz-do-not-send="true"
href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a></div>
</blockquote>
</div>
<div><br>
<div>
<div>On 4 May, 2014, at 7:01 pm, Christopher Cook <<a
moz-do-not-send="true"
href="mailto:christopher.cook@webprofusion.com">christopher.cook@webprofusion.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Depends on what integration people would like to see?<br>
<br>
Chris<br>
<br>
J-C Saint-Pô <<a moz-do-not-send="true"
href="mailto:jcsaintpo@gmail.com">jcsaintpo@gmail.com</a>>
wrote:<br>
<br>
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>
<div>
<div>Hello guys,<br>
<br>
</div>
Just a reminder.<br>
<br>
<a moz-do-not-send="true"
href="http://openchargemap.org/">http://openchargemap.org/</a>
is used as database of chargingstations
in the OVMS apps<br>
</div>
You can add / remove chargigstations via <a
moz-do-not-send="true"
href="http://openchargemap.org/site/poi">http://openchargemap.org/site/poi</a>
or <a moz-do-not-send="true"
href="http://openchargemap.org/app/">http://openchargemap.org/app/</a><br>
</div>
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<br>
<br>
<br clear="all">
</div>
here some other examples of apps/ websites
that use OCM<br>
<a moz-do-not-send="true"
href="http://openchargemap.org/site/develop/apps">http://openchargemap.org/site/develop/apps</a><br>
<br>
</div>
Here the google+ community of OCM <a
moz-do-not-send="true"
href="https://plus.google.com/u/0/communities/112113799071360649945">https://plus.google.com/u/0/communities/112113799071360649945</a><br>
<br>
</div>
Kind Greets<br>
</div>
J-C<br>
</div>
_______________________________________________<br>
OvmsDev mailing list<br>
<a moz-do-not-send="true"
href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a><br>
<a moz-do-not-send="true"
href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a><br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
_______________________________________________
OvmsDev mailing list
<a moz-do-not-send="true"
href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a><a
moz-do-not-send="true"
href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a></span>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a>
<a class="moz-txt-link-freetext" href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br>
</body>
</html>