[Ovmsdev] Wifi setup
Michael Balzer
dexter at expeedo.de
Sat Jul 11 02:53:36 HKT 2020
Sorry for not including the examples. The Edimax does not have a host
name, it's addressed using the IP, no DNS involved.
Linux host request example working the same way with both the old & new
version:
HTTP.Request({
url: "http://192.168.2.108/f/test.json",
always: function() { JSON.print(this, false); }
});
(OK, no output)
D (42703) script: DuktapeHTTPRequest: started
'http://192.168.2.108/f/test.json'
D (42913) script: DuktapeHTTPRequest: MG_EV_CONNECT err=0/Success
D (42933) script: DuktapeHTTPRequest: MG_EV_HTTP_REPLY status=200 bodylen=20
D (42943) script: DuktapeHTTPRequest: MG_EV_CLOSE status=200
D (42963) script: DuktapeHTTPRequest: done status=200 bodylen=20
url='http://192.168.2.108/f/test.json'
D (42973) script: DuktapeHTTPRequest: calling method 'always' nargs=0
I (43173) script: [eval:3:]
{"url":"http://192.168.2.108/f/test.json","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"}]}}
…vs. Edimax working with the old version:
HTTP.Request({
url: "http://192.168.2.106/",
always: function() { JSON.print(this, false); }
});
(OK, no output)
D (533720) script: DuktapeHTTPRequest: started 'http://192.168.2.106/'
D (533920) script: DuktapeHTTPRequest: MG_EV_CONNECT err=104/Connection
reset by peer
D (533930) script: DuktapeHTTPRequest: MG_EV_CLOSE status=0
D (533950) script: DuktapeHTTPRequest: failed error='Connection reset by
peer' url='http://192.168.2.106/'
D (533950) script: DuktapeHTTPRequest: calling method 'always' nargs=0
I (533990) script: [eval:3:]
{"url":"http://192.168.2.106/","always":function () { [ecmascript code]
},"redirectCount":0,"error":"Connection reset by peer"}
(connection reset = expected result here, as connecting w/o credentials
to the default port -- to show it's host related)
…but not with the new version:
(OK, no output)
D (151953) script: DuktapeHTTPRequest: started 'http://192.168.2.106/'
…18 seconds…
D (170273) script: DuktapeHTTPRequest: MG_EV_CONNECT err=113/Software
caused connection abort
D (170273) script: DuktapeHTTPRequest: MG_EV_CLOSE status=0
D (170293) script: DuktapeHTTPRequest: failed error='Software caused
connection abort' url='http://192.168.2.106/'
D (170303) script: DuktapeHTTPRequest: calling method 'always' nargs=0
I (170333) script: [eval:3:]
{"url":"http://192.168.2.106/","always":function () { [ecmascript code]
},"redirectCount":0,"error":"Software caused connection abort"}
Regards,
Michael
Am 10.07.20 um 20:03 schrieb David Corrigan:
> 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
>
> https://superuser.com/questions/591863/how-to-resolve-local-domain-name
>
>
> On Fri, Jul 10, 2020 at 12:47 PM Michael Balzer <dexter at expeedo.de
> <mailto:dexter at expeedo.de>> wrote:
>
> It seems I've found a real issue with the new implementation, I
> don't know how to explain:
>
> 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.
>
> 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.
>
> Same behaviour in both client & apclient mode, fixed & scanning.
>
> 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…?
>
> I'm puzzled. Any ideas? Any other hosts that cannot be connected
> to with the new version?
>
> 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:
>
> HTTP.Request({
> url: "http://…" <http://…>,
> always: function() { JSON.print(this, false); }
> });
>
> Regards,
> Michael
>
>
> Am 10.07.20 um 15:21 schrieb Michael Balzer:
>> The dhcps log messages aren't new, I've had these all the time
>> before, also sometimes repeating for some period.
>>
>> Also not new are these messages:
>>
>> I (8771413) wifi: ampdu: ignore deleting tx BA0
>> I (8774723) wifi: ampdu: ignore deleting tx BA0
>> I (8784043) wifi: ampdu: ignore deleting tx BA0
>> I (8787253) wifi: ampdu: ignore deleting tx BA0
>> I (8793673) wifi: ampdu: ignore deleting tx BA0
>> I (8797813) wifi: ampdu: ignore deleting tx BA0
>>
>> 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.
>>
>> Regards,
>> Michael
>>
>>
>> Am 10.07.20 um 14:36 schrieb Mark Webb-Johnson:
>>> Working for me on my test bench device. I’m building EDGE now.
>>>
>>> Only strange thing so far is I am seeing this message repeatedly
>>> in apclient mode:
>>>
>>> dhcps: send_nak>>udp_sendto result 0
>>>
>>>
>>> Can’t work out the timing, as it seems to be random. I’ll keep
>>> looking...
>>>
>>> Regards, Mark
>>>
>>>> On 10 Jul 2020, at 7:42 PM, Michael Balzer <dexter at expeedo.de
>>>> <mailto:dexter at expeedo.de>> wrote:
>>>>
>>>> Everyone,
>>>>
>>>> the wifi rework is pushed:
>>>> https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/5d1f124060326b92f35887878b4d49c8012542dc
>>>> …and the new edge build is on my server.
>>>>
>>>> This now allows to scan for networks in all modes without
>>>> disruption of a running wifi network.
>>>>
>>>> I've used this to also add a network selection dialog to the
>>>> setup wizard & wifi config.
>>>>
>>>> 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.
>>>>
>>>> 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".
>>>>
>>>> Of course this has involved some changes to the wifi manager,
>>>> so please test & report.
>>>>
>>>> Regards,
>>>> Michael
>>>>
>>>>
>>>> Am 10.07.20 um 08:57 schrieb Michael Balzer:
>>>>> TL;DR: yes, I'm currently also going towards not letting
>>>>> esp_wifi_connect() decide which AP to connect to.
>>>>>
>>>>> 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.
>>>>>
>>>>> Example:
>>>>>
>>>>> D (5034) events: Signal(system.wifi.scan.done)
>>>>> V (5034) esp32wifi: ScanDone: #01 ssid='WLAN-214677'
>>>>> bssid='7c:ff:4d:15:2f:86' chan=11 rssi=-64
>>>>> V (5034) esp32wifi: ScanDone: #02 ssid='WLAN-214677'
>>>>> bssid='94:4a:0c:c3:9e:63' chan=11 rssi=-77
>>>>> I (5044) esp32wifi: Found SSID WLAN-214677 - trying to connect
>>>>> I (7564) esp32wifi: STA connected with SSID: WLAN-214677,
>>>>> BSSID: 94:4a:0c:c3:9e:63, Channel: 11, Auth: WPA2
>>>>>
>>>>> 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.
>>>>>
>>>>> On all following reconnects on the running system it will
>>>>> correctly pick the 7c:ff AP, also if wifi is stopped & restarted.
>>>>>
>>>>> 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.
>>>>>
>>>>> 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.
>>>>>
>>>>> Regards,
>>>>> Michael
>>>>>
>>>>>
>>>>> Am 10.07.20 um 02:55 schrieb Mark Webb-Johnson:
>>>>>> FYI:
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> That approach might help with your other issue (recently
>>>>>> raised in mantis).
>>>>>>
>>>>>> Regards, Mark.
>>>>>>
>>>>>>> On 10 Jul 2020, at 5:43 AM, Michael Balzer
>>>>>>> <dexter at expeedo.de> <mailto:dexter at expeedo.de> wrote:
>>>>>>>
>>>>>>> Welcome Derek,
>>>>>>>
>>>>>>> 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 ;-)
>>>>>>>
>>>>>>> Regards,
>>>>>>> Michael
>>>>>>>
>>>>>>>
>>>>>>> Am 09.07.20 um 20:50 schrieb Derek Caudwell:
>>>>>>>> Hi devs,
>>>>>>>>
>>>>>>>> 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).
>>>>>>>>
>>>>>>>> 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.
>>>>>>>>
>>>>>>>> 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:
>>>>>>>> - 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?
>>>>>>>> - 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?
>>>>>>>> - 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
>>>>>>>> - 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?
>>>>>>>>
>>>>>>>> Thanks in advance for any pointers and background.
>>>>>>>>
>>>>>>>> Cheers Derek
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> OvmsDev mailing list
>>>>>>>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>>>>>
>>>>>>> --
>>>>>>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal <https://www.google.com/maps/search/Helkenberger+Weg+9+*+D-58256+Ennepetal?entry=gmail&source=g>
>>>>>>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>>>>>>> _______________________________________________
>>>>>>> OvmsDev mailing list
>>>>>>> OvmsDev at lists.openvehicles.com
>>>>>>> <mailto:OvmsDev at lists.openvehicles.com>
>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>>>>
>>>>>> _______________________________________________
>>>>>> OvmsDev mailing list
>>>>>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>>>
>>>>> --
>>>>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal <https://www.google.com/maps/search/Helkenberger+Weg+9+*+D-58256+Ennepetal?entry=gmail&source=g>
>>>>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>>>>>
>>>>> _______________________________________________
>>>>> OvmsDev mailing list
>>>>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>>
>>>> --
>>>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal <https://www.google.com/maps/search/Helkenberger+Weg+9+*+D-58256+Ennepetal?entry=gmail&source=g>
>>>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>>>> _______________________________________________
>>>> OvmsDev mailing list
>>>> OvmsDev at lists.openvehicles.com
>>>> <mailto:OvmsDev at lists.openvehicles.com>
>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>
>>>
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>
>> --
>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal <https://www.google.com/maps/search/Helkenberger+Weg+9+*+D-58256+Ennepetal?entry=gmail&source=g>
>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>>
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
> --
> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal <https://www.google.com/maps/search/Helkenberger+Weg+9+*+D-58256+Ennepetal?entry=gmail&source=g>
> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200710/5b8b394a/attachment-0001.html>
More information about the OvmsDev
mailing list