<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
Am 13.05.2018 um 03:43 schrieb Mark Webb-Johnson:<br>
<blockquote type="cite"
cite="mid:CA947A67-BFB0-49B0-B44D-112FE9BC9A7D@webb-johnson.net">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
What I’m trying to do is create a generic algorithm that works for
as many vehicles as possible. If a particular vehicle needs
particular support, it can override and handle itself
appropriately.
<div class=""><br class="">
</div>
<div class="">I’ve delayed the charge start report for all those
pre-states (including charging, topoff, heating). I’m guessing
that when heating (for example) transitions to charging, the
current level should be fine and we can report immediately. For
Tesla roadster it goes heating->preparing->charging.</div>
</blockquote>
<br>
So the current implementation will also only notify on i.e. heating
but not on the transition from heating to charging, because the
charge time counter starts on heating. That may be sufficient, but
users may want to also or only get a notification on the actual
charge start. Heating may take quite some time in very cold climate.<br>
<br>
The base problem seems to result from a lack of a common definition
/ consent on the meaning of the states. I always understood and used
"topoff" not as a pre-state but as a finishing state. My definition
would look like this:<br>
<ul>
<li>charging: main charge phase (constant current phase, full
speed)</li>
<li>topoff: finishing charge phase (constant voltage phase, cell
balancing)</li>
<li>done: standard completion of a full charge</li>
<li>prepare: any kind of preparation phase</li>
<li>timerwait: waiting for a timer based charge start</li>
<li>heating: heating up cells before charge in cold climate</li>
<li>stopped: any kind of charge stop before the standard
completion ("done")<br>
</li>
</ul>
<br>
A normal charge process is: [timerwait →] [heating →] [prepare →]
charging → [topoff →] done<br>
<br>
…with [] being optional states. The charge process can start at any
state, i.e. if the battery is warm and nearly full, it would start
at topoff.<br>
<br>
You normally want to get a notification on "topoff" entry if you're
on the road and want to go on as quickly as possible.<br>
<br>
That's the process for the Twizy. The Twizy doesn't have a prepare
phase (it has technically but it's too short to bother), charge
voltage and current are stable on the bus when the charge start is
signaled.<br>
<br>
On the Tesla Roadster, if the current is not stable during the first
15 seconds, it would seem to be a natural mapping to set that phase
as state "prepare". But I remember the phases are taken directly
from the bus on the roadster implementation.<br>
<br>
<br>
For a general base solution, your approach of a delayed notification
would work if we didn't use ms_v_charge_time as a base but a
separate charge phase time that is reset on each phase change.<br>
<br>
The phase delay then can be applied to all state change
notifications, and the delay can be configurable / controllable by
the vehicle, possibly varying per state (callback hook).<br>
<br>
As that makes the process very flexible and even supports the old
scheme (by returning 0 as a delay) I've just implemented that,
please check and comment.<br>
<br>
I've set the default delay to 3 seconds, that should be sufficient
for all vehicles with direct bus→state mappings.<br>
<br>
Regards,<br>
Michael<br>
<br>
<br>
<blockquote type="cite"
cite="mid:CA947A67-BFB0-49B0-B44D-112FE9BC9A7D@webb-johnson.net">
<div class="">What does the current approach look like on the
Twizy?</div>
<div class=""><br class="">
</div>
<div class="">Regards, Mark.</div>
<div class=""><br class="">
<div>
<blockquote type="cite" class="">
<div class="">On 13 May 2018, at 6:42 AM, Michael Balzer
<<a href="mailto:dexter@expeedo.de" class=""
moz-do-not-send="true">dexter@expeedo.de</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<meta http-equiv="Content-Type" content="text/html;
charset=utf-8" class="">
<div text="#000000" bgcolor="#FFFFFF" class=""> Mark,<br
class="">
<br class="">
<div class="moz-cite-prefix">Am 12.05.2018 um 15:51
schrieb Mark Webb-Johnson:<br class="">
</div>
<blockquote type="cite"
cite="mid:93FC22F3-E0C2-4631-BC76-82D29585872E@webb-johnson.net"
class="">
<meta http-equiv="Content-Type" content="text/html;
charset=utf-8" class="">
<div class=""><br class="">
</div>
<div class="">
<blockquote type="cite" class="">
<div text="#000000" bgcolor="#FFFFFF" class="">A
minor issue: binding the actual notification to
a single metric introduces a dependance on the
CAN frame or processing order if the
notification content depends on other metrics as
well.</div>
</blockquote>
<br class="">
</div>
<div class="">Yep. Found one of those today.</div>
<div class=""><br class="">
</div>
<div class="">Tesla Roadster: charge started
notifications didn’t show current properly, because
that takes a few seconds to appear. Fix made was to
delay charge start notifications until 15 seconds
into the charge.</div>
</blockquote>
<br class="">
I just saw you made that change for all vehicles instead
of only for the roadster. I'm really not sure about
that, it feels like a workaround.<br class="">
<br class="">
Your change also breaks the notifications on state
transitions during the charge. The "topoff" phase on the
Twizy is equivalent to the CV (constant voltage) charge
phase, so "charging" goes over to "topoff" at some
indeterminate time into the charge.<br class="">
<br class="">
I don't know how "heating" works on the Roadster, but
"heating" would normally also seemlessly proceed to
"charging".<br class="">
<br class="">
Regards,<br class="">
Michael<br class="">
<br class="">
<br class="">
<blockquote type="cite"
cite="mid:93FC22F3-E0C2-4631-BC76-82D29585872E@webb-johnson.net"
class="">
<div class="">In general, I’m finding our ‘time’
metrics really useful. We have charge time
(v.c.time), and park time (v.e.parktime). Probably a
good to add v.e.drivetime to complement those and
track how long the vehicle has been not parked.</div>
<div class=""><br class="">
</div>
Regards, Mark.
<div class=""><br class="">
<div class="">
<blockquote type="cite" class="">
<div class="">On 10 May 2018, at 7:08 PM,
Michael Balzer <<a
href="mailto:dexter@expeedo.de" class=""
moz-do-not-send="true">dexter@expeedo.de</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<meta http-equiv="Content-Type"
content="text/html; charset=utf-8" class="">
<div text="#000000" bgcolor="#FFFFFF" class="">
Mark,<br class="">
<br class="">
I'll take care of the web UI for the
notification config, but not for 006.<br
class="">
<br class="">
A minor issue: binding the actual
notification to a single metric introduces a
dependance on the CAN frame or processing
order if the notification content depends on
other metrics as well.<br class="">
<br class="">
This applies especially to the charge start
notification. It is sent synchronously on
the ms_v_charge_state change, but also
includes info from multiple other metrics.
If those other metrics have not been updated
when the state change comes in, the
notification info will be inconsistent.<br
class="">
<br class="">
Vehicles implementing a separate state
metrics processing can work around this by
reordering the metrics updates so the state
update is always last, but a vehicle setting
metrics directly from the incoming frames
(i.e. mapping based) may not be able to do
so easily. We'll have to remember this when
designing the mapping, i.e. add the ability
to buffer some data and define ordered
metrics transactions. Or maybe there's a
more simple solution to this.<br class="">
<br class="">
There are two more framework notification
candidates, "charge.sufficient" and
"batt.alert.minsoc", but they can wait for
007.<br class="">
<br class="">
<blockquote type="cite" class="">
<div class="">I think we’re about ready
for 3.1.006 now? I need to test
Michael’s new initial config system, but
that code is in place so should be good
to go.</div>
</blockquote>
<br class="">
There was only one tester (besides me) of
the wizard yet, so more testing is
important.<br class="">
<br class="">
Regards,<br class="">
Michael<br class="">
<br class="">
<br class="">
<div class="moz-cite-prefix">Am 09.05.2018
um 15:50 schrieb Mark Webb-Johnson:<br
class="">
</div>
<blockquote type="cite"
cite="mid:CB8F8791-8413-4D76-8777-9AC7F218123D@webb-johnson.net"
class="">
<meta http-equiv="Content-Type"
content="text/html; charset=utf-8"
class="">
<div class=""><br class="">
</div>
<div class="">The modifications below have
been implemented. Works for me on the
bench.</div>
<div class=""><br class="">
</div>
<div class="">Individual vehicle modules
can turn this off (it defaults to on) by
setting m_autonotifications=false in
their constructor. Implementations can
also override the individual Notify…()
functions to disable particular
notifications, or customise the output.
For example, a Tesla Model S module may
want to override NotifyValetHood() and
send the alert as ‘frunk’ rather than
‘hood’.</div>
<div class=""><br class="">
</div>
<div class="">For those testing this with
individual vehicle support, you should
be able to see the following
standardised vehicle alerts now:</div>
<div class=""><br class="">
</div>
<div class="">
<div class="">
<ul class="MailOutline">
<li class="">charge.started (a
charge session has started)</li>
<li class="">heating.started (the
battery is being heated, as part
of a charge session)</li>
<li class="">charge.stopped (a
charge session has been
interrupted)</li>
<li class="">charge.done (a charge
session has completed normally)</li>
<li class="">valet.enabled (valet
mode has been enabled)</li>
<li class="">valet.disabled (valet
mode has been disabled)</li>
<li class="">valet.hood (the vehicle
hood has been opened, while in
valet mode)</li>
<li class="">valet.trunk (the
vehicle trunk has been opened,
while in valet mode)</li>
<li class="">alarm.sounding (the
vehicle alarm is sounding)</li>
<li class="">alarm.stopped (the
vehicle alarm has stopped)</li>
<li class="">batt.12v.alert (the 12v
battery is at a critically low
voltage level)</li>
<li class="">batt.12v.recovered (the
12v battery voltage level has
recovered)</li>
</ul>
</div>
</div>
<div class=""><br class="">
</div>
<div class="">I’ll be updating the user
guide documentation now, as there are
quite a lot of configuration options for
this now. Should finish by tomorrow.</div>
<div class=""><br class="">
</div>
<div class="">I think we’re about ready
for 3.1.006 now? I need to test
Michael’s new initial config system, but
that code is in place so should be good
to go.</div>
<div class=""><br class="">
</div>
<div class="">Perhaps people can commit
what they have this week, and we will
build a 3.1.006 OTA release at the
weekend?</div>
<div class=""><br class="">
</div>
<div class="">As always,
comments/suggestions/improvements
welcome.</div>
<div class=""><br class="">
</div>
<div class="">Regards, Mark.</div>
<div class=""><br class="">
<blockquote type="cite" class="">It is
time to implement vehicle
notifications (charge started, charge
completed, charge interrupted, etc) in
the vehicle modules I am supporting.
It seems that this can be done in the
vehicle.{h,cpp} framework in a
standard manner, and work across all
vehicle types. However, I guess that
will break any notifications already
being produced by other vehicle types.
<div class=""><br class="">
</div>
<div class="">My suggestion is:</div>
<div class=""><br class="">
</div>
<div class="">
<ol class="MailOutline">
<li class="">A config parameter
‘notifications’, with individual
instances to turn on/off the
notifications. Default is all
enabled.<br class="">
<br class="">
</li>
<li class="">OvmsVehicle::MetricModified
picks up metric changes and
issues the standard
notifications (checking
‘notifications’ parameter
appropriately).</li>
<ul class="">
<li class="">charge_mode=>charging:
Notify charge started</li>
<li class="">charge_mode=>topoff: Notify
charge started</li>
<li class="">charge_mode=>heating:
Notify battery heating started</li>
<li class="">charge_mode=>done:
Notify charge completed</li>
<li class="">charge_mode=>stopped:
Notify charge interrupted</li>
<li class="">valet_mode=>on:
Notify valet mode enabled</li>
<li class="">valet_mode=>off:
Notify valet mode disabled</li>
<li class="">alarm=>on:
Notify alarm is sounding</li>
<li class="">alarm=>off:
Notify alarm is off<br
class="">
<br class="">
</li>
</ul>
<li class="">All the above should
be suppressed for the initial
setting of each parameter. I
will have to look into metrics
to see how best that should be
done; one neat way is to keep a
modification count (rather than
the current m_defined boolean).</li>
</ol>
</div>
<div class=""><br class="">
</div>
<div class="">Does that make sense?
Any objections/suggestions?</div>
<div class=""><br class="">
</div>
<div class="">Regards, Mark</div>
</blockquote>
</div>
<div class=""><br class="">
</div>
<br class="">
<div class="">
<blockquote type="cite" class="">
<div class="">On 9 May 2018, at 9:33
AM, Mark Webb-Johnson <<a
href="mailto:mark@webb-johnson.net"
class="" moz-do-not-send="true">mark@webb-johnson.net</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<meta http-equiv="Content-Type"
content="text/html; charset=utf-8"
class="">
<div style="word-wrap: break-word;
-webkit-nbsp-mode: space;
line-break: after-white-space;"
class="">I’ve extended the
notifications framework to include
the concept of notification
subtypes. This is in addition to
the existing notification base
types.<br class="">
<div class=""><br class="">
</div>
<div class="">This allows us to
automatically filter
notifications based on the
granular subtypes. The filtering
is done at the framework level,
so all notification listeners
need to do is turn it on (when
they register).</div>
<div class=""><br class="">
</div>
<div class="">I have identified
the following standard subtypes,
and updated quite a few modules
to use them:</div>
<div class=""><br class="">
</div>
<div class="">
<ul class="MailOutline">
<li class="">charge.stopped</li>
<li class="">charge.state</li>
<li class="">batt.alert</li>
<li class="">batt.12v (seems
similar to batt.alert, but
not yet decided)</li>
<li class="">homelink</li>
<li class="">debug.crash</li>
<li class="">xks.aux</li>
<li class="">xrt.battmon</li>
<li class="">xrt.power</li>
<li class="">xrt.gps</li>
<li class="">xrt.trip</li>
<li class="">xrt.sevcon</li>
<li class="">xrt.logs</li>
<li class="">xrt.reset</li>
</ul>
</div>
<div class=""><br class="">
</div>
<div class="">I would really
rather have all the alert types
standardised (including things
like trip logs, gps tracking,
etc) and working across all
vehicle types. But this at least
is a starting point.</div>
<div class=""><br class="">
</div>
<div class="">An example of it
working is:</div>
<div class=""><br class="">
</div>
<blockquote style="margin: 0 0 0
40px; border: none; padding:
0px;" class="">
<div class="">
<div class=""><font class=""
face="Andale Mono"><span
style="font-size: 18px;"
class="">OVMS# notify
raise text info test
hello</span></font></div>
<div class=""><font class=""
face="Andale Mono"><span
style="font-size: 18px;"
class="">Raise text
notification for
info/test as hello</span></font></div>
<div class=""><font class=""
face="Andale Mono"><span
style="font-size: 18px;"
class="">I (25618)
ovms-server-v2: Send
MP-0 PIhello</span></font></div>
<div class=""><font class=""
face="Andale Mono"><span
style="font-size: 18px;"
class=""><br class="">
</span></font></div>
<div class="">
<div class=""><font class=""
face="Andale Mono"><span
style="font-size:
18px;" class="">OVMS#
config set notify test
none</span></font></div>
<div class=""><font class=""
face="Andale Mono"><span
style="font-size:
18px;" class="">Parameter
has been set.</span></font></div>
<div class=""><font class=""
face="Andale Mono"><span
style="font-size:
18px;" class=""><br
class="">
</span></font></div>
<div class=""><font class=""
face="Andale Mono"><span
style="font-size:
18px;" class="">OVMS#
notify raise text info
test hello</span></font></div>
<div class=""><font class=""
face="Andale Mono"><span
style="font-size:
18px;" class="">Raise
text notification for
info/test as hello</span></font></div>
<div class=""><font class=""
face="Andale Mono"><span
style="font-size:
18px;" class=""><br
class="">
</span></font></div>
<div class="">
<div class=""><font
class="" face="Andale
Mono"><span
style="font-size:
18px;" class="">OVMS#
config set notify
test ovmsv2</span></font></div>
<div class="">
<div class=""><font
class=""
face="Andale Mono"><span
style="font-size:
18px;" class="">Parameter
has been set.</span></font></div>
<div class=""><font
class=""
face="Andale Mono"><span
style="font-size:
18px;" class=""><br
class="">
</span></font></div>
<div class=""><font
class=""
face="Andale Mono"><span
style="font-size:
18px;" class="">OVMS#
notify raise text
info test hello</span></font></div>
<div class=""><font
class=""
face="Andale Mono"><span
style="font-size:
18px;" class="">Raise
text notification
for info/test as
hello</span></font></div>
<div class=""><font
class=""
face="Andale Mono"><span
style="font-size:
18px;" class="">I
(71368)
ovms-server-v2:
Send MP-0 PIhello</span></font></div>
</div>
</div>
</div>
</div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">
<div class="">I am working on
the vehicle module automated
alerts we previously
discussed, and this is a
pre-requisite. New
standardised subtypes will
come with that (such as
charge.start, charge.done,
etc).</div>
<div class=""><br class="">
</div>
</div>
<div class="">Regards, Mark.</div>
<div class=""><br class="">
<blockquote type="cite" class="">
<div class="">Begin forwarded
message:</div>
<br
class="Apple-interchange-newline">
<div style="margin-top: 0px;
margin-right: 0px;
margin-bottom: 0px;
margin-left: 0px;" class=""><span
style="font-family:
-webkit-system-font,
'Helvetica Neue',
Helvetica, sans-serif;"
class=""><b class="">From:
</b></span><span
style="font-family:
-webkit-system-font,
Helvetica Neue, Helvetica,
sans-serif;" class="">GitHub
<<a
href="mailto:noreply@github.com"
class=""
moz-do-not-send="true">noreply@github.com</a>><br
class="">
</span></div>
<div style="margin-top: 0px;
margin-right: 0px;
margin-bottom: 0px;
margin-left: 0px;" class=""><span
style="font-family:
-webkit-system-font,
'Helvetica Neue',
Helvetica, sans-serif;"
class=""><b class="">Subject:
</b></span><span
style="font-family:
-webkit-system-font,
Helvetica Neue, Helvetica,
sans-serif;" class=""><b
class="">[openvehicles/Open-Vehicle-Monitoring-System-3]
7516c9: test framework
commands for testing can
bus tx/rx</b><br
class="">
</span></div>
<div style="margin-top: 0px;
margin-right: 0px;
margin-bottom: 0px;
margin-left: 0px;" class=""><span
style="font-family:
-webkit-system-font,
'Helvetica Neue',
Helvetica, sans-serif;"
class=""><b class="">Date:
</b></span><span
style="font-family:
-webkit-system-font,
Helvetica Neue, Helvetica,
sans-serif;" class="">9
May 2018 at 9:18:53 AM HKT<br
class="">
</span></div>
<div style="margin-top: 0px;
margin-right: 0px;
margin-bottom: 0px;
margin-left: 0px;" class=""><span
style="font-family:
-webkit-system-font,
'Helvetica Neue',
Helvetica, sans-serif;"
class=""><b class="">To: </b></span><span
style="font-family:
-webkit-system-font,
Helvetica Neue, Helvetica,
sans-serif;" class=""><a
href="mailto:mark@webb-johnson.net"
class=""
moz-do-not-send="true">mark@webb-johnson.net</a><br
class="">
</span></div>
<div style="margin-top: 0px;
margin-right: 0px;
margin-bottom: 0px;
margin-left: 0px;" class=""><span
style="font-family:
-webkit-system-font,
'Helvetica Neue',
Helvetica, sans-serif;"
class=""><b class="">Reply-To:
</b></span><span
style="font-family:
-webkit-system-font,
Helvetica Neue, Helvetica,
sans-serif;" class="">GitHub
<<a
href="mailto:noreply@github.com"
class=""
moz-do-not-send="true">noreply@github.com</a>><br
class="">
</span></div>
<br class="">
<div class="">
<div class=""> Branch:
refs/heads/master<br
class="">
Home: <a
href="https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3"
class=""
moz-do-not-send="true">https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3</a><br
class="">
Commit:
7516c9681055ec7986a94ccb8cfb29bda5f1bce8<br
class="">
<a
href="https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/7516c9681055ec7986a94ccb8cfb29bda5f1bce8"
class=""
moz-do-not-send="true">https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/7516c9681055ec7986a94ccb8cfb29bda5f1bce8</a><br
class="">
Author: Mark Webb-Johnson
<<a
href="mailto:mark@webb-johnson.net"
class=""
moz-do-not-send="true">mark@webb-johnson.net</a>><br
class="">
Date: 2018-05-09 (Wed,
09 May 2018)<br class="">
<br class="">
Changed paths:<br
class="">
M
vehicle/OVMS.V3/main/test_framework.cpp<br
class="">
<br class="">
Log Message:<br class="">
-----------<br class="">
test framework commands
for testing can bus tx/rx<br
class="">
<br class="">
<br class="">
Commit:
183d26dc107bb21cd956776228d0a24030b115db<br
class="">
<a
href="https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/183d26dc107bb21cd956776228d0a24030b115db"
class=""
moz-do-not-send="true">https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/183d26dc107bb21cd956776228d0a24030b115db</a><br
class="">
Author: Mark Webb-Johnson
<<a
href="mailto:mark@webb-johnson.net"
class=""
moz-do-not-send="true">mark@webb-johnson.net</a>><br
class="">
Date: 2018-05-09 (Wed,
09 May 2018)<br class="">
<br class="">
Changed paths:<br
class="">
M
vehicle/OVMS.V3/components/ovms_server_v2/src/ovms_server_v2.cpp<br
class="">
M
vehicle/OVMS.V3/components/ovms_server_v3/src/ovms_server_v3.cpp<br
class="">
M
vehicle/OVMS.V3/components/vehicle/vehicle.cpp<br
class="">
M
vehicle/OVMS.V3/components/vehicle_kiasoulev/src/vehicle_kiasoulev.cpp<br
class="">
M
vehicle/OVMS.V3/components/vehicle_renaulttwizy/src/rt_battmon.cpp<br
class="">
M
vehicle/OVMS.V3/components/vehicle_renaulttwizy/src/rt_notify.cpp<br
class="">
M
vehicle/OVMS.V3/components/vehicle_renaulttwizy/src/rt_sevcon.cpp<br
class="">
M
vehicle/OVMS.V3/components/vehicle_renaulttwizy/src/rt_sevcon_faults.cpp<br
class="">
M
vehicle/OVMS.V3/components/vehicle_renaulttwizy/src/vehicle_renaulttwizy.cpp<br
class="">
M
vehicle/OVMS.V3/main/ovms_boot.cpp<br
class="">
M
vehicle/OVMS.V3/main/ovms_notify.cpp<br
class="">
M
vehicle/OVMS.V3/main/ovms_notify.h<br
class="">
<br class="">
Log Message:<br class="">
-----------<br class="">
Notifications: Framework
extensions to add support
for subtypes on
notifications, and
automatic filtering by
subtype and distribution
mechanism<br class="">
<br class="">
<br class="">
Compare: <a
href="https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/compare/57d8f1b449d6...183d26dc107b"
class=""
moz-do-not-send="true">https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/compare/57d8f1b449d6...183d26dc107b</a><br
class="">
**<a
class="moz-txt-link-freetext"
href="note:**"
moz-do-not-send="true">NOTE:**</a>
This service been marked
for deprecation: <a
href="https://developer.github.com/changes/2018-04-25-github-services-deprecation/"
class=""
moz-do-not-send="true">https://developer.github.com/changes/2018-04-25-github-services-deprecation/</a><br
class="">
<br class="">
Functionality will be
removed from <a
href="http://github.com/"
class=""
moz-do-not-send="true">GitHub.com</a>
on January 31st, 2019.<br
class="">
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
</blockquote>
</div>
<br class="">
<br class="">
<fieldset class="mimeAttachmentHeader"></fieldset>
<br class="">
<pre class="" wrap="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.openvehicles.com" moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a>
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" moz-do-not-send="true">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br class="">
<pre class="moz-signature" cols="160">--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
</div>
_______________________________________________<br class="">
OvmsDev mailing list<br class="">
<a
href="mailto:OvmsDev@lists.openvehicles.com"
class="" moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a><br
class="">
<a class="moz-txt-link-freetext"
href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev"
moz-do-not-send="true">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br
class="">
</div>
</blockquote>
</div>
<br class="">
</div>
<br class="">
<fieldset class="mimeAttachmentHeader"></fieldset>
<br class="">
<pre class="" wrap="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.openvehicles.com" moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a>
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" moz-do-not-send="true">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br class="">
<pre class="moz-signature" cols="160">--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
</div>
_______________________________________________<br
class="">
OvmsDev mailing list<br class="">
<a href="mailto:OvmsDev@lists.openvehicles.com" class=""
moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a><br
class="">
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br
class="">
</div>
</blockquote>
</div>
<br class="">
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.openvehicles.com">OvmsDev@lists.openvehicles.com</a>
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="160">--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
</body>
</html>