<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
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">"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">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">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">"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/">"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/">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/">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/">"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/">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/">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/">"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">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>