<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
*sigh* Found it… it turned out my main router needed a reboot. I
assume somehow a faulty ARP cache entry got stuck.<br>
<br>
<a href="https://www.youtube.com/watch?v=nn2FB1P_Mn8">https://www.youtube.com/watch?v=nn2FB1P_Mn8</a><br>
<br>
So, no fault or bug on the module side.<br>
<br>
Checking the code once again I nevertheless found one remaining
potential bug, fix is pushed.<br>
<br>
Regards,<br>
Michael<br>
<br>
<br>
<div class="moz-cite-prefix">Am 10.07.20 um 20:53 schrieb Michael
Balzer:<br>
</div>
<blockquote type="cite"
cite="mid:c8aeef01-ba71-f0a2-863e-32a4b5ce8949@expeedo.de">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
Sorry for not including the examples. The Edimax does not have a
host name, it's addressed using the IP, no DNS involved.<br>
<br>
Linux host request example working the same way with both the old
& new version:<br>
<br>
<tt>HTTP.Request({</tt><tt><br>
</tt><tt> url: <a class="moz-txt-link-rfc2396E"
href="http://192.168.2.108/f/test.json" moz-do-not-send="true">"http://192.168.2.108/f/test.json"</a>,</tt><tt><br>
</tt><tt> always: function() { JSON.print(this, false); }</tt><tt><br>
</tt><tt>});</tt><tt><br>
</tt><tt><br>
</tt><tt>(OK, no output)</tt><tt><br>
</tt><tt>D (42703) script: DuktapeHTTPRequest: started '<a
class="moz-txt-link-freetext"
href="http://192.168.2.108/f/test.json" moz-do-not-send="true">http://192.168.2.108/f/test.json</a>'</tt><tt><br>
</tt><tt>D (42913) script: DuktapeHTTPRequest: MG_EV_CONNECT
err=0/Success</tt><tt><br>
</tt><tt>D (42933) script: DuktapeHTTPRequest: MG_EV_HTTP_REPLY
status=200 bodylen=20</tt><tt><br>
</tt><tt>D (42943) script: DuktapeHTTPRequest: MG_EV_CLOSE
status=200</tt><tt><br>
</tt><tt>D (42963) script: DuktapeHTTPRequest: done status=200
bodylen=20 url='<a class="moz-txt-link-freetext"
href="http://192.168.2.108/f/test.json" moz-do-not-send="true">http://192.168.2.108/f/test.json</a>'</tt><tt><br>
</tt><tt>D (42973) script: DuktapeHTTPRequest: calling method
'always' nargs=0</tt><tt><br>
</tt><tt>I (43173) script: [eval:3:] {"url":<a
class="moz-txt-link-rfc2396E"
href="http://192.168.2.108/f/test.json" moz-do-not-send="true">"http://192.168.2.108/f/test.json"</a>,"always":function
() { [ecmascript code]
},"redirectCount":0,"error":"","response":{"statusCode":200,"statusText":"OK","body":"{
\"das\": \"klappt?\" }","headers":[{"Date":"Fri, 10 Jul 2020
17:03:18 GMT"},{"Server":"Apache"},{"Last-Modified":"Sun, 29 Dec
2019 11:01:41
GMT"},{"ETag":"\"14-59ad5a6d190da\""},{"Accept-Ranges":"bytes"},{"Content-Length":"20"},{"Cache-Control":"max-age=0"},{"Expires":"Fri,
10 Jul 2020 17:03:18
GMT"},{"Content-Type":"application/json"}]}}</tt><br>
<br>
…vs. Edimax working with the old version:<br>
<br>
<tt>HTTP.Request({</tt><tt><br>
</tt><tt> url: <a class="moz-txt-link-rfc2396E"
href="http://192.168.2.106/" moz-do-not-send="true">"http://192.168.2.106/"</a>,</tt><tt><br>
</tt><tt> always: function() { JSON.print(this, false); }</tt><tt><br>
</tt><tt>});</tt><tt><br>
</tt><tt><br>
</tt><tt>(OK, no output)</tt><tt><br>
</tt><tt>D (533720) script: DuktapeHTTPRequest: started '<a
class="moz-txt-link-freetext" href="http://192.168.2.106/"
moz-do-not-send="true">http://192.168.2.106/</a>'</tt><tt><br>
</tt><tt>D (533920) script: DuktapeHTTPRequest: MG_EV_CONNECT
err=104/Connection reset by peer</tt><tt><br>
</tt><tt>D (533930) script: DuktapeHTTPRequest: MG_EV_CLOSE
status=0</tt><tt><br>
</tt><tt>D (533950) script: DuktapeHTTPRequest: failed
error='Connection reset by peer' url='<a
class="moz-txt-link-freetext" href="http://192.168.2.106/"
moz-do-not-send="true">http://192.168.2.106/</a>'</tt><tt><br>
</tt><tt>D (533950) script: DuktapeHTTPRequest: calling method
'always' nargs=0</tt><tt><br>
</tt><tt>I (533990) script: [eval:3:] {"url":<a
class="moz-txt-link-rfc2396E" href="http://192.168.2.106/"
moz-do-not-send="true">"http://192.168.2.106/"</a>,"always":function
() { [ecmascript code] },"redirectCount":0,"error":"Connection
reset by peer"}</tt><br>
<br>
(connection reset = expected result here, as connecting w/o
credentials to the default port -- to show it's host related)<br>
<br>
…but not with the new version:<br>
<br>
<tt>(OK, no output)</tt><tt><br>
</tt><tt>D (151953) script: DuktapeHTTPRequest: started '<a
class="moz-txt-link-freetext" href="http://192.168.2.106/"
moz-do-not-send="true">http://192.168.2.106/</a>'</tt><tt><br>
</tt><tt>…18 seconds…<br>
D (170273) script: DuktapeHTTPRequest: MG_EV_CONNECT
err=113/Software caused connection abort</tt><tt><br>
</tt><tt>D (170273) script: DuktapeHTTPRequest: MG_EV_CLOSE
status=0</tt><tt><br>
</tt><tt>D (170293) script: DuktapeHTTPRequest: failed
error='Software caused connection abort' url='<a
class="moz-txt-link-freetext" href="http://192.168.2.106/"
moz-do-not-send="true">http://192.168.2.106/</a>'</tt><tt><br>
</tt><tt>D (170303) script: DuktapeHTTPRequest: calling method
'always' nargs=0</tt><tt><br>
</tt><tt>I (170333) script: [eval:3:] {"url":<a
class="moz-txt-link-rfc2396E" href="http://192.168.2.106/"
moz-do-not-send="true">"http://192.168.2.106/"</a>,"always":function
() { [ecmascript code] },"redirectCount":0,"error":"Software
caused connection abort"}</tt><br>
<br>
<br>
Regards,<br>
Michael<br>
<br>
<br>
<div class="moz-cite-prefix">Am 10.07.20 um 20:03 schrieb David
Corrigan:<br>
</div>
<blockquote type="cite"
cite="mid:CAGyUOUHk9dPR3LiibmamS+1GExtYaX9CX7oGN53vqxU9doXrMw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html;
charset=UTF-8">
<div>
<div dir="auto">Sounds like a DNS issue. I’m really foggy on
the details but you can probably look this stuff up easily
enough. Local stuff is resolved a bit differently, it’s
something like your home router keeps track of the names
that get DHCP reservations and append .local so somehow when
looking for devices the client needs to query that as well
as the main DNS IPs given to it by the DHCP server. It might
be that the same DHCP server automatically appends it’s own
up IP to the list. There’s a discussion on it here that
might yield some ideas</div>
<div dir="auto"><br>
</div>
<div dir="auto">
<div><a
href="https://superuser.com/questions/591863/how-to-resolve-local-domain-name"
moz-do-not-send="true">https://superuser.com/questions/591863/how-to-resolve-local-domain-name</a></div>
<br>
</div>
</div>
<div><br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Fri, Jul 10, 2020 at
12:47 PM Michael Balzer <<a
href="mailto:dexter@expeedo.de" moz-do-not-send="true">dexter@expeedo.de</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">
<div> It seems I've found a real issue with the new
implementation, I don't know how to explain:<br>
<br>
With the new implementation, mongoose fails to establish
a HTTP connection to my Edimax smart plug. Just that
device, every other host works correctly, also with SSL.<br>
<br>
The mg_connect_http_opt() call fails after 18 seconds
with error 113 "Software caused connection abort" …
which may be a timeout or the LWIP error code 113 "No
route to host" passed through by mongoose.<br>
<br>
Same behaviour in both client & apclient mode, fixed
& scanning.<br>
<br>
The Edimax is on the same network as the module
(connected to the same AP) and perfectly reachable from
all other stations (and the build before). Netmask and
gateway are correct. Also the wifi connect is still done
by the esp_wifi_connect() call, so there should be no
difference…?<br>
<br>
I'm puzzled. Any ideas? Any other hosts that cannot be
connected to with the new version?<br>
<br>
To test a host, use this JS snippet in the editor with a
URL of a small page or non existent file on the host:<br>
<br>
<tt style="font-family:monospace">HTTP.Request({</tt><br>
<tt style="font-family:monospace"> url: <a
href="http://…" target="_blank"
style="font-family:monospace" moz-do-not-send="true">"http://…"</a>,</tt><br>
<tt style="font-family:monospace"> always: function() {
JSON.print(this, false); }</tt><br>
<tt style="font-family:monospace">});</tt><br>
<br>
Regards,<br>
Michael<br>
<br>
<br>
<div>Am 10.07.20 um 15:21 schrieb Michael Balzer:<br>
</div>
</div>
<div>
<blockquote type="cite"> The dhcps log messages aren't
new, I've had these all the time before, also
sometimes repeating for some period.<br>
<br>
Also not new are these messages:<br>
<br>
<tt style="font-family:monospace">I (8771413) wifi:
ampdu: ignore deleting tx BA0</tt><tt
style="font-family:monospace"><br>
</tt><tt style="font-family:monospace">I (8774723)
wifi: ampdu: ignore deleting tx BA0</tt><tt
style="font-family:monospace"><br>
</tt><tt style="font-family:monospace">I (8784043)
wifi: ampdu: ignore deleting tx BA0</tt><tt
style="font-family:monospace"><br>
</tt><tt style="font-family:monospace">I (8787253)
wifi: ampdu: ignore deleting tx BA0</tt><tt
style="font-family:monospace"><br>
</tt><tt style="font-family:monospace">I (8793673)
wifi: ampdu: ignore deleting tx BA0</tt><tt
style="font-family:monospace"><br>
</tt><tt style="font-family:monospace">I (8797813)
wifi: ampdu: ignore deleting tx BA0</tt><br>
<br>
They now start consistently after doing a scan from a
web client connected via the AP. They stop when the
client disconnects. Seem to be coupled to the
websocket somehow. I've found these in my log archives
as well, no clue about the trigger. No issue other
than annoying log spam though, everything works
normally.<br>
<br>
Regards,<br>
Michael<br>
<br>
<br>
<div>Am 10.07.20 um 14:36 schrieb Mark Webb-Johnson:<br>
</div>
<blockquote type="cite"> Working for me on my test
bench device. I’m building EDGE now.
<div><br>
</div>
<div>Only strange thing so far is I am seeing this
message repeatedly in apclient mode:</div>
<div><br>
</div>
<blockquote style="margin:0px 0px 0px
40px;border:none;padding:0px">
<div>dhcps: send_nak>>udp_sendto result 0</div>
</blockquote>
<div>
<div><br>
</div>
<div>Can’t work out the timing, as it seems to be
random. I’ll keep looking...</div>
<div><br>
</div>
<div>Regards, Mark</div>
<div><br>
<blockquote type="cite">
<div>On 10 Jul 2020, at 7:42 PM, Michael
Balzer <<a
href="mailto:dexter@expeedo.de"
target="_blank" moz-do-not-send="true">dexter@expeedo.de</a>>
wrote:</div>
<br>
<div>
<div> Everyone,<br>
<br>
the wifi rework is pushed: <a
href="https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/5d1f124060326b92f35887878b4d49c8012542dc"
target="_blank" moz-do-not-send="true">https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/5d1f124060326b92f35887878b4d49c8012542dc</a><br>
…and the new edge build is on my server.<br>
<br>
This now allows to scan for networks in
all modes without disruption of a running
wifi network.<br>
<br>
I've used this to also add a network
selection dialog to the setup wizard &
wifi config.<br>
<br>
The apclient mode can now be started
without a client SSID to let the module
automatically connect to any network
configured. The autostart config page now
allows this setup. The special "scanning
client" mode has been removed.<br>
<br>
The wifi manager will still stick to an
established connection, even if a new
network with higher signal strength
becomes available. I thought about
automatically switching networks if the
signal gets poor, but for now decided
against it to avoid frequent network
reconfigurations in edge cases. If you
want the module to explicitly scan for a
better network, issue "wifi reconnect".<br>
<br>
Of course this has involved some changes
to the wifi manager, so please test &
report.<br>
<br>
Regards,<br>
Michael<br>
<br>
<br>
<div>Am 10.07.20 um 08:57 schrieb Michael
Balzer:<br>
</div>
<blockquote type="cite"> TL;DR: yes, I'm
currently also going towards not letting
esp_wifi_connect() decide which AP to
connect to.<br>
<br>
More precisely, exactly the first (!)
call to esp_wifi_connect() after a
reboot/power up seems to do a round
robin scheme among all reachable access
points of a network regardless of their
signal strength. This even applies to
the first connect() immediately after a
scan.<br>
<br>
Example:<br>
<br>
D (5034) events:
Signal(system.wifi.scan.done)<br>
V (5034) esp32wifi: ScanDone: #01
ssid='WLAN-214677'
bssid='7c:ff:4d:15:2f:86' chan=11
rssi=-64<br>
V (5034) esp32wifi: ScanDone: #02
ssid='WLAN-214677'
bssid='94:4a:0c:c3:9e:63' chan=11
rssi=-77<br>
I (5044) esp32wifi: Found SSID
WLAN-214677 - trying to connect<br>
I (7564) esp32wifi: STA connected with
SSID: WLAN-214677, BSSID:
94:4a:0c:c3:9e:63, Channel: 11, Auth:
WPA2<br>
<br>
The next reboot will connect to 7c:ff
(despite unchanged signal strengths),
the next again to 94:4a and so on. I've
only got two access points, so I can't
test if it's really round-robin, but
it's wrong anyway.<br>
<br>
On all following reconnects on the
running system it will correctly pick
the 7c:ff AP, also if wifi is stopped
& restarted.<br>
<br>
This AP switching behaviour also
persists powering off the module, so the
wifi blob seems to do this on purpose
and even use some persistent storage to
implement it. Totally undocumented and
I've found no way to disable this and no
workaround so far.<br>
<br>
There may be a fix for this in the
current esp-idf wifi blob, but I've
found no issues on this, and esp-idf
commit comments are mostly not useful.<br>
<br>
Regards,<br>
Michael<br>
<br>
<br>
<div>Am 10.07.20 um 02:55 schrieb Mark
Webb-Johnson:<br>
</div>
<blockquote type="cite">
<div dir="ltr">FYI:</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">I’ve recently done some
work with the esphome system (based
on platformio on top of esp idf),
for home automation. They don’t seem
to trust the ESP libraries
identifying the strongest signal (in
the case of two APs broadcasting the
same SSID). They don’t blindly
connect to a SSID, but instead first
do a scan to produce an ordered list
and then connect to the
SSID+AP-MAC-Address of the AP with
the strongest signal.</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">That approach might
help with your other issue (recently
raised in mantis).</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">Regards, Mark.</div>
<div dir="ltr"><br>
<blockquote type="cite">On 10 Jul
2020, at 5:43 AM, Michael Balzer <a
href="mailto:dexter@expeedo.de"
target="_blank"
moz-do-not-send="true"><dexter@expeedo.de></a>
wrote:<br>
<br>
</blockquote>
</div>
<blockquote type="cite">
<div dir="ltr"> Welcome Derek,<br>
<br>
I've got a rework of the wifi
component near done that allows to
use scanning mode in apclient
configuration. I think I can push
the changes tomorrow & suggest
you'll be my beta tester ;-)<br>
<br>
Regards,<br>
Michael<br>
<br>
<br>
<div>Am 09.07.20 um 20:50 schrieb
Derek Caudwell:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hi devs,
<div><br>
</div>
<div>I recently received the
ovms hardware and have been
trying to setup the unit so
I can solely use the wifi
AP+client. In NZ 3G is soon
to be sunset and for my
needs I don't really need a
connection when I'm driving
(and want to make sure
everything is behaving
nicely on the can bus before
I do). </div>
<div><br>
</div>
<div>I realise AP+client
brings it limitations
however hopefully some of
these can be worked around
as I want to be able to use
the dashboard/plugins as
well as the mobile app. I am
new to C/ESP32 programming
and the code base so I
thought it best to ask a few
questions before I begin
tinkering with it.</div>
<div><br>
</div>
<div>Ideally I want the unit
on loss of connection to an
AP to try and find
another AP that has been set
in the wifi config and
connect. The parts I am not
too sure are as follows:</div>
<div> - on boot the code uses
the default wifi ssid, if
the default is not available
how does the code try and
switch to one of the other
saved APs?</div>
<div> - can multiple APs be
saved to the wifi config
memory and handled by ESP32?
or do they need to be
retrieved from ovms config,
wifi client details set, try
connect and enumerated
through?</div>
<div> - I assume EventTimer10
is the logical place to add
extra code if required to
enumerate through APs and
try to connect? similar to
EventScanWifiDone when in
SClient mode</div>
<div> - What is the reason
scanning mode is unavailable
for AP+client mode in auto
init, from the ESP32
documentation it appeared to
be usable still but with
limitations? </div>
<div><br>
</div>
<div>Thanks in advance for any
pointers and background.</div>
<div><br>
</div>
<div>Cheers Derek</div>
</div>
<br>
<fieldset></fieldset>
<pre style="font-family:monospace">_______________________________________________
OvmsDev mailing list
<a href="mailto:OvmsDev@lists.openvehicles.com" target="_blank" style="font-family:monospace" moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a>
<a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" target="_blank" style="font-family:monospace" moz-do-not-send="true">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br>
<pre cols="72" style="font-family:monospace">--
Michael Balzer * <a href="https://www.google.com/maps/search/Helkenberger+Weg+9+*+D-58256+Ennepetal?entry=gmail&source=g" style="font-family:monospace" moz-do-not-send="true">Helkenberger Weg 9 * D-58256 Ennepetal</a>
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
<span>_______________________________________________</span><br>
<span>OvmsDev mailing list</span><br>
<span><a
href="mailto:OvmsDev@lists.openvehicles.com"
target="_blank"
moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a></span><br>
<span><a
href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev"
target="_blank"
moz-do-not-send="true">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a></span><br>
</div>
</blockquote>
<br>
<fieldset></fieldset>
<pre style="font-family:monospace">_______________________________________________
OvmsDev mailing list
<a href="mailto:OvmsDev@lists.openvehicles.com" target="_blank" style="font-family:monospace" moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a>
<a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" target="_blank" style="font-family:monospace" moz-do-not-send="true">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br>
<pre cols="72" style="font-family:monospace">--
Michael Balzer * <a href="https://www.google.com/maps/search/Helkenberger+Weg+9+*+D-58256+Ennepetal?entry=gmail&source=g" style="font-family:monospace" moz-do-not-send="true">Helkenberger Weg 9 * D-58256 Ennepetal</a>
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
<br>
<fieldset></fieldset>
<pre style="font-family:monospace">_______________________________________________
OvmsDev mailing list
<a href="mailto:OvmsDev@lists.openvehicles.com" target="_blank" style="font-family:monospace" moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a>
<a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" target="_blank" style="font-family:monospace" moz-do-not-send="true">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br>
<pre cols="72" style="font-family:monospace">--
Michael Balzer * <a href="https://www.google.com/maps/search/Helkenberger+Weg+9+*+D-58256+Ennepetal?entry=gmail&source=g" style="font-family:monospace" moz-do-not-send="true">Helkenberger Weg 9 * D-58256 Ennepetal</a>
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
</div>
_______________________________________________<br>
OvmsDev mailing list<br>
<a
href="mailto:OvmsDev@lists.openvehicles.com"
target="_blank" moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a><br>
<a
href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev"
target="_blank" moz-do-not-send="true">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br>
</div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset></fieldset>
<pre style="font-family:monospace">_______________________________________________
OvmsDev mailing list
<a href="mailto:OvmsDev@lists.openvehicles.com" target="_blank" style="font-family:monospace" moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a>
<a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" target="_blank" style="font-family:monospace" moz-do-not-send="true">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br>
<pre cols="72" style="font-family:monospace">--
Michael Balzer * <a href="https://www.google.com/maps/search/Helkenberger+Weg+9+*+D-58256+Ennepetal?entry=gmail&source=g" style="font-family:monospace" moz-do-not-send="true">Helkenberger Weg 9 * D-58256 Ennepetal</a>
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
<br>
<fieldset></fieldset>
<pre style="font-family:monospace">_______________________________________________
OvmsDev mailing list
<a href="mailto:OvmsDev@lists.openvehicles.com" target="_blank" style="font-family:monospace" moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a>
<a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" target="_blank" style="font-family:monospace" moz-do-not-send="true">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br>
<pre cols="72" style="font-family:monospace">--
Michael Balzer * <a href="https://www.google.com/maps/search/Helkenberger+Weg+9+*+D-58256+Ennepetal?entry=gmail&source=g" style="font-family:monospace" moz-do-not-send="true">Helkenberger Weg 9 * D-58256 Ennepetal</a>
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
</div>
_______________________________________________<br>
OvmsDev mailing list<br>
<a href="mailto:OvmsDev@lists.openvehicles.com"
target="_blank" moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a><br>
<a
href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev"
rel="noreferrer" target="_blank" moz-do-not-send="true">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br>
</blockquote>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" 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>
<pre class="moz-signature" cols="72">--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-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="72">--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
</body>
</html>