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
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@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
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@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@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 _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
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@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@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 _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@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
Everyone, the wifi rework is pushed: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/5d1f... …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@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@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 _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@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
_______________________________________________ OvmsDev mailing list OvmsDev@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
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@expeedo.de> wrote:
Everyone,
the wifi rework is pushed: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/5d1f... <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@expeedo.de> <mailto:dexter@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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
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@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Everyone,
the wifi rework is pushed: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/5d1f... …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@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@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 _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@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
_______________________________________________ OvmsDev mailing list OvmsDev@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 _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@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
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://…", 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@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Everyone,
the wifi rework is pushed: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/5d1f... …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@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@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 _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@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
_______________________________________________ OvmsDev mailing list OvmsDev@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 _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@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
_______________________________________________ OvmsDev mailing list OvmsDev@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
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@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@expeedo.de> wrote:
Everyone,
the wifi rework is pushed: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/5d1f... …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@expeedo.de> <dexter@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 listOvmsDev@lists.openvehicles.comhttp://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@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing listOvmsDev@lists.openvehicles.comhttp://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 listOvmsDev@lists.openvehicles.comhttp://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@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing listOvmsDev@lists.openvehicles.comhttp://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 listOvmsDev@lists.openvehicles.comhttp://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@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
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@expeedo.de <mailto:dexter@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@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Everyone,
the wifi rework is pushed: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/5d1f... …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@expeedo.de> <mailto:dexter@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@lists.openvehicles.com <mailto:OvmsDev@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@lists.openvehicles.com > <mailto:OvmsDev@lists.openvehicles.com> > http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@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@lists.openvehicles.com <mailto:OvmsDev@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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@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@lists.openvehicles.com <mailto:OvmsDev@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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@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
*sigh* Found it… it turned out my main router needed a reboot. I assume somehow a faulty ARP cache entry got stuck. https://www.youtube.com/watch?v=nn2FB1P_Mn8 So, no fault or bug on the module side. Checking the code once again I nevertheless found one remaining potential bug, fix is pushed. Regards, Michael Am 10.07.20 um 20:53 schrieb Michael Balzer:
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@expeedo.de <mailto:dexter@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@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Everyone,
the wifi rework is pushed: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/5d1f... …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@expeedo.de> <mailto:dexter@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@lists.openvehicles.com <mailto:OvmsDev@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@lists.openvehicles.com >> <mailto:OvmsDev@lists.openvehicles.com> >> http://lists.openvehicles.com/mailman/listinfo/ovmsdev > > _______________________________________________ > OvmsDev mailing list > OvmsDev@lists.openvehicles.com <mailto:OvmsDev@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@lists.openvehicles.com <mailto:OvmsDev@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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@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@lists.openvehicles.com <mailto:OvmsDev@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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@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
_______________________________________________ OvmsDev mailing list OvmsDev@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
Really appreciate you guys taking the time to fix this. I also use the module in wifi only mode and was constantly getting disconnects. I blamed this on the poor wifi connection in the parking spot, but as it turns out the problem was far deeper. Regards, Jaunius Kapkan [Sent from cellphone]
On 2020-07-10, at 23:42, Michael Balzer <dexter@expeedo.de> wrote:
*sigh* Found it… it turned out my main router needed a reboot. I assume somehow a faulty ARP cache entry got stuck.
https://www.youtube.com/watch?v=nn2FB1P_Mn8
So, no fault or bug on the module side.
Checking the code once again I nevertheless found one remaining potential bug, fix is pushed.
Regards, Michael
Am 10.07.20 um 20:53 schrieb Michael Balzer:
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@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://…", 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@expeedo.de> wrote: > > Everyone, > > the wifi rework is pushed: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/5d1f... > …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@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@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 >>>> _______________________________________________ >>>> OvmsDev mailing list >>>> OvmsDev@lists.openvehicles.com >>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev >>> >>> >>> _______________________________________________ >>> OvmsDev mailing list >>> OvmsDev@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 >> >> >> _______________________________________________ >> OvmsDev mailing list >> OvmsDev@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 > _______________________________________________ > OvmsDev mailing list > OvmsDev@lists.openvehicles.com > http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@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
_______________________________________________ OvmsDev mailing list OvmsDev@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 _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@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
_______________________________________________ OvmsDev mailing list OvmsDev@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 _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
participants (5)
-
David Corrigan -
Derek Caudwell -
Jaunius Kapkan -
Mark Webb-Johnson -
Michael Balzer