I find the wifi performance of OVMS v3 to be poor, and I'm wondering how it might be improved. I have a mix of thoughts here. For both my own unit and that of Timothy Rodgers, wifi reception in our garages was unusable. You can blame that on too much distance from the access point, but my iPhone and MacBook both access the wifi just fine from my garage. The wifi antenna in the OVMS is probably smaller and its location within the metal framework around the car's firewall may impede radio transmission. Perhaps it would be feasible to switch to an ESP32-WROVER-I with an external antenna to improve performance, but that would be a big deal. If there is a transmit power adjustment, perhaps that could be increased? When Timothy parks his car next to his house, which is about 50 feet closer than the garage, then the wifi reception was good enough for the update to 3.1.008 to succeed. But when he tries to connect with the browser, page updates often time out, so it is close to unusable. Perhaps we could improve usability by increasing the timeout in our javascript to allow more time for TCP to retransmit? For my own unit, I switched from AP+client to just client mode and at first it seemed that had improved the client performance. But still the next day I had no access from the iPhone app. When I connected to the console to find out why I saw that server v2 was repeatedly trying to connect and failing. I'm presuming that the cause was poor wifi connectivity since I was also not able to reach the web server on the client address, although I have not proven that. But since the client wifi was associated with the home AP and had an address, the OVMS network routing preferred the wifi and did not try to use the modem. For now I have resorted to turning off wifi. I suggest that the network routing algorithm be enhanced to back off to use the modem if some number of attempts to connect to the server over wifi have failed. The iPhone will do this for itself (there is a setting to enable this called Wi-Fi Assist). The behavior of repeated connection attempts and failures by server v2 seems to induce a more serious failure after a while, perhaps due to some resource starvation. At that point there is a failure message "mg_connect(api.openvehicles.com:6867) failed: cannot parse address" every time server v2 tries to connect. I expect that is a bug that could be fixed. Lastly, since we may encounter situations where network communication is not working, we should facilitate access to the console. When I was trying to help Timothy change a location radius setting remotely by phone and the web browser was timing out, I suggested that he find a micro-USB cable so he could connect to the console. But then I realized he would not have any application on his laptop that would allow him to connect to the console. Developers use "make monitor" in the software development cycle, but users won't have that tool. I have my own program on the MacBook that I use as an alternative when I don't want to induce a reset when I connect. But is there a simple program for Windows suitable for non-developer users that can connect to the OVMS console? -- Steve
...or not. Just tried it with a Windows 7 Netbook. Apparently it needs a driver for "CP2102 USB to Serial Bridge Controller", which was not installed. No clue if available on the 'Net. Greg Greg D. wrote:
I've used putty on a Raspberry Pi to connect to the USB console; I assume it would work for Windows as well.
Greg
Stephen Casner wrote:
But is there a simple program for Windows suitable for non-developer users that can connect to the OVMS console?
Page #21 of the user guide has some links to the CP2102 driver, and suggestions for terminal emulator apps on OSX, Linux, Windows, and Android. Regards, Mark.
On 6 Jul 2018, at 8:01 AM, Greg D. <gregd2350@gmail.com> wrote:
...or not. Just tried it with a Windows 7 Netbook. Apparently it needs a driver for "CP2102 USB to Serial Bridge Controller", which was not installed. No clue if available on the 'Net.
Greg
Greg D. wrote:
I've used putty on a Raspberry Pi to connect to the USB console; I assume it would work for Windows as well.
Greg
Stephen Casner wrote:
But is there a simple program for Windows suitable for non-developer users that can connect to the OVMS console?
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Perfect. Also a reason I generally don't use Windows... :) Greg Mark Webb-Johnson wrote:
Page #21 of the user guide has some links to the CP2102 driver, and suggestions for terminal emulator apps on OSX, Linux, Windows, and Android.
Regards, Mark.
On 6 Jul 2018, at 8:01 AM, Greg D. <gregd2350@gmail.com> wrote:
...or not. Just tried it with a Windows 7 Netbook. Apparently it needs a driver for "CP2102 USB to Serial Bridge Controller", which was not installed. No clue if available on the 'Net.
Greg
Greg D. wrote:
I've used putty on a Raspberry Pi to connect to the USB console; I assume it would work for Windows as well.
Greg
Stephen Casner wrote:
But is there a simple program for Windows suitable for non-developer users that can connect to the OVMS console?
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
I've had similar reports regarding poor wifi connectivity, and this seems to affect some modules more than others (or may be channel/frequency dependant?). One user has just 1-2 bars AP wifi signal with the module placed ~ 50 cm away from the phone. I also still get reports of spurious strange crashes, that mostly seem to be related to situations with poor wifi signal. Some crash backtraces just are complete blank / null, and there is no crash report on the USB output for these before reboot. Yesterday, Frank tried to perform some wifi scans. The first scan went fine, the second never returned, he had to power off the module. After reboot, all successive scans worked. Two users reported they occasionally cannot auth to the OVMS AP with the correct password, and they can then reconnect just by retrying for some minutes or by connecting & disconnecting another client to the AP. I already had a look at the wifi tx power configuration, it's at 100% by default. This all feels like a) we need to change something about the antenna, and b) there are quite some bugs in the wifi blob. Looking at https://github.com/espressif/esp32-wifi-lib/commits/master it seems there have been numerous wifi blob fixes lately. Last time I checked I still was out of memory with the current esp-idf, I'll check again. Regards, Michael Am 06.07.2018 um 01:48 schrieb Stephen Casner:
I find the wifi performance of OVMS v3 to be poor, and I'm wondering how it might be improved. I have a mix of thoughts here.
For both my own unit and that of Timothy Rodgers, wifi reception in our garages was unusable. You can blame that on too much distance from the access point, but my iPhone and MacBook both access the wifi just fine from my garage. The wifi antenna in the OVMS is probably smaller and its location within the metal framework around the car's firewall may impede radio transmission. Perhaps it would be feasible to switch to an ESP32-WROVER-I with an external antenna to improve performance, but that would be a big deal. If there is a transmit power adjustment, perhaps that could be increased?
When Timothy parks his car next to his house, which is about 50 feet closer than the garage, then the wifi reception was good enough for the update to 3.1.008 to succeed. But when he tries to connect with the browser, page updates often time out, so it is close to unusable. Perhaps we could improve usability by increasing the timeout in our javascript to allow more time for TCP to retransmit?
For my own unit, I switched from AP+client to just client mode and at first it seemed that had improved the client performance. But still the next day I had no access from the iPhone app. When I connected to the console to find out why I saw that server v2 was repeatedly trying to connect and failing. I'm presuming that the cause was poor wifi connectivity since I was also not able to reach the web server on the client address, although I have not proven that. But since the client wifi was associated with the home AP and had an address, the OVMS network routing preferred the wifi and did not try to use the modem. For now I have resorted to turning off wifi. I suggest that the network routing algorithm be enhanced to back off to use the modem if some number of attempts to connect to the server over wifi have failed. The iPhone will do this for itself (there is a setting to enable this called Wi-Fi Assist).
The behavior of repeated connection attempts and failures by server v2 seems to induce a more serious failure after a while, perhaps due to some resource starvation. At that point there is a failure message "mg_connect(api.openvehicles.com:6867) failed: cannot parse address" every time server v2 tries to connect. I expect that is a bug that could be fixed.
Lastly, since we may encounter situations where network communication is not working, we should facilitate access to the console. When I was trying to help Timothy change a location radius setting remotely by phone and the web browser was timing out, I suggested that he find a micro-USB cable so he could connect to the console. But then I realized he would not have any application on his laptop that would allow him to connect to the console. Developers use "make monitor" in the software development cycle, but users won't have that tool. I have my own program on the MacBook that I use as an alternative when I don't want to induce a reset when I connect. But is there a simple program for Windows suitable for non-developer users that can connect to the OVMS console?
-- Steve _______________________________________________ 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
My 2c: For the access points I normally use, it works 100% of the time for me. The only issue I had was when the SSID password was wrong on one of my access points (sharing the same SSID) and that was randomly causing me connection issues (every time the ESP32 picked it). I also don’t use APCLIENT, and only use SCLIENT mode. I’ve found APCLIENT to be buggy as hell. But, I do have problems connecting to some access points. In particular phone hotspots. I suspect either bugs in the wifi stack, or some issue with channels. The only thing I am wary of is that our current code does this: esp_wifi_set_config… esp_wifi_start… esp_wifi_connect... But the Espressif examples have: esp_wifi_set_config… esp_wifi_start… Wait for SYSTEM_EVENT_STA_START esp_wifi_connect... I had that working the Espressif way in my big wifi refactor that never made it to production. But our current code doesn’t wait for the SYSTEM_EVENT_STA_START before calling esp_wifi_connect. Regards, Mark.
On 6 Jul 2018, at 9:04 PM, Michael Balzer <dexter@expeedo.de> wrote:
I've had similar reports regarding poor wifi connectivity, and this seems to affect some modules more than others (or may be channel/frequency dependant?). One user has just 1-2 bars AP wifi signal with the module placed ~ 50 cm away from the phone.
I also still get reports of spurious strange crashes, that mostly seem to be related to situations with poor wifi signal. Some crash backtraces just are complete blank / null, and there is no crash report on the USB output for these before reboot.
Yesterday, Frank tried to perform some wifi scans. The first scan went fine, the second never returned, he had to power off the module. After reboot, all successive scans worked.
Two users reported they occasionally cannot auth to the OVMS AP with the correct password, and they can then reconnect just by retrying for some minutes or by connecting & disconnecting another client to the AP.
I already had a look at the wifi tx power configuration, it's at 100% by default.
This all feels like a) we need to change something about the antenna, and b) there are quite some bugs in the wifi blob.
Looking at https://github.com/espressif/esp32-wifi-lib/commits/master it seems there have been numerous wifi blob fixes lately. Last time I checked I still was out of memory with the current esp-idf, I'll check again.
Regards, Michael
Am 06.07.2018 um 01:48 schrieb Stephen Casner:
I find the wifi performance of OVMS v3 to be poor, and I'm wondering how it might be improved. I have a mix of thoughts here.
For both my own unit and that of Timothy Rodgers, wifi reception in our garages was unusable. You can blame that on too much distance from the access point, but my iPhone and MacBook both access the wifi just fine from my garage. The wifi antenna in the OVMS is probably smaller and its location within the metal framework around the car's firewall may impede radio transmission. Perhaps it would be feasible to switch to an ESP32-WROVER-I with an external antenna to improve performance, but that would be a big deal. If there is a transmit power adjustment, perhaps that could be increased?
When Timothy parks his car next to his house, which is about 50 feet closer than the garage, then the wifi reception was good enough for the update to 3.1.008 to succeed. But when he tries to connect with the browser, page updates often time out, so it is close to unusable. Perhaps we could improve usability by increasing the timeout in our javascript to allow more time for TCP to retransmit?
For my own unit, I switched from AP+client to just client mode and at first it seemed that had improved the client performance. But still the next day I had no access from the iPhone app. When I connected to the console to find out why I saw that server v2 was repeatedly trying to connect and failing. I'm presuming that the cause was poor wifi connectivity since I was also not able to reach the web server on the client address, although I have not proven that. But since the client wifi was associated with the home AP and had an address, the OVMS network routing preferred the wifi and did not try to use the modem. For now I have resorted to turning off wifi. I suggest that the network routing algorithm be enhanced to back off to use the modem if some number of attempts to connect to the server over wifi have failed. The iPhone will do this for itself (there is a setting to enable this called Wi-Fi Assist).
The behavior of repeated connection attempts and failures by server v2 seems to induce a more serious failure after a while, perhaps due to some resource starvation. At that point there is a failure message "mg_connect(api.openvehicles.com:6867) failed: cannot parse address" every time server v2 tries to connect. I expect that is a bug that could be fixed.
Lastly, since we may encounter situations where network communication is not working, we should facilitate access to the console. When I was trying to help Timothy change a location radius setting remotely by phone and the web browser was timing out, I suggested that he find a micro-USB cable so he could connect to the console. But then I realized he would not have any application on his laptop that would allow him to connect to the console. Developers use "make monitor" in the software development cycle, but users won't have that tool. I have my own program on the MacBook that I use as an alternative when I don't want to induce a reset when I connect. But is there a simple program for Windows suitable for non-developer users that can connect to the OVMS console?
-- Steve _______________________________________________ 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
I've been using APCLIENT all the time and only had one crash that looked like a wifi problem. This really is a very specific problem. I also have a very good wifi signal, I can perfectly use my module's web UI while the car is in my garage two floors below. But I live in an uncrowded area, not much wifi competition. I have updated my esp-idf to the latest upstream master (it's v3.2 now) and could build without any memory issues. The wifi driver now, besided loads of bug fixes, also supports CSI. Our code only needs a minor adjustment if you'd like to compile yourself, add… #define _SOC_SPI_PERIPH_H_ // don't include spi_periph.h (type conflict) …in components/spinodma/spi_master_nodma.h before #include "driver/spi_common.h". If you don't want to compile, the new build (with CSI enabled) is also on my server: http://ovms.dexters-web.de/firmware/ota/v3.1/edge/ …and now being installed by my beta testers. Regards, Michael Am 06.07.2018 um 16:28 schrieb Mark Webb-Johnson:
My 2c:
For the access points I normally use, it works 100% of the time for me. The only issue I had was when the SSID password was wrong on one of my access points (sharing the same SSID) and that was randomly causing me connection issues (every time the ESP32 picked it).
I also don’t use APCLIENT, and only use SCLIENT mode. I’ve found APCLIENT to be buggy as hell.
But, I do have problems connecting to some access points. In particular phone hotspots. I suspect either bugs in the wifi stack, or some issue with channels.
The only thing I am wary of is that our current code does this:
esp_wifi_set_config… esp_wifi_start… esp_wifi_connect...
But the Espressif examples have:
esp_wifi_set_config… esp_wifi_start… Wait for SYSTEM_EVENT_STA_START
esp_wifi_connect...
I had that working the Espressif way in my big wifi refactor that never made it to production. But our current code doesn’t wait for the SYSTEM_EVENT_STA_START before calling esp_wifi_connect.
Regards, Mark.
On 6 Jul 2018, at 9:04 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
I've had similar reports regarding poor wifi connectivity, and this seems to affect some modules more than others (or may be channel/frequency dependant?). One user has just 1-2 bars AP wifi signal with the module placed ~ 50 cm away from the phone.
I also still get reports of spurious strange crashes, that mostly seem to be related to situations with poor wifi signal. Some crash backtraces just are complete blank / null, and there is no crash report on the USB output for these before reboot.
Yesterday, Frank tried to perform some wifi scans. The first scan went fine, the second never returned, he had to power off the module. After reboot, all successive scans worked.
Two users reported they occasionally cannot auth to the OVMS AP with the correct password, and they can then reconnect just by retrying for some minutes or by connecting & disconnecting another client to the AP.
I already had a look at the wifi tx power configuration, it's at 100% by default.
This all feels like a) we need to change something about the antenna, and b) there are quite some bugs in the wifi blob.
Looking at https://github.com/espressif/esp32-wifi-lib/commits/master it seems there have been numerous wifi blob fixes lately. Last time I checked I still was out of memory with the current esp-idf, I'll check again.
Regards, Michael
Am 06.07.2018 um 01:48 schrieb Stephen Casner:
I find the wifi performance of OVMS v3 to be poor, and I'm wondering how it might be improved. I have a mix of thoughts here.
For both my own unit and that of Timothy Rodgers, wifi reception in our garages was unusable. You can blame that on too much distance from the access point, but my iPhone and MacBook both access the wifi just fine from my garage. The wifi antenna in the OVMS is probably smaller and its location within the metal framework around the car's firewall may impede radio transmission. Perhaps it would be feasible to switch to an ESP32-WROVER-I with an external antenna to improve performance, but that would be a big deal. If there is a transmit power adjustment, perhaps that could be increased?
When Timothy parks his car next to his house, which is about 50 feet closer than the garage, then the wifi reception was good enough for the update to 3.1.008 to succeed. But when he tries to connect with the browser, page updates often time out, so it is close to unusable. Perhaps we could improve usability by increasing the timeout in our javascript to allow more time for TCP to retransmit?
For my own unit, I switched from AP+client to just client mode and at first it seemed that had improved the client performance. But still the next day I had no access from the iPhone app. When I connected to the console to find out why I saw that server v2 was repeatedly trying to connect and failing. I'm presuming that the cause was poor wifi connectivity since I was also not able to reach the web server on the client address, although I have not proven that. But since the client wifi was associated with the home AP and had an address, the OVMS network routing preferred the wifi and did not try to use the modem. For now I have resorted to turning off wifi. I suggest that the network routing algorithm be enhanced to back off to use the modem if some number of attempts to connect to the server over wifi have failed. The iPhone will do this for itself (there is a setting to enable this called Wi-Fi Assist).
The behavior of repeated connection attempts and failures by server v2 seems to induce a more serious failure after a while, perhaps due to some resource starvation. At that point there is a failure message "mg_connect(api.openvehicles.com:6867 <http://api.openvehicles.com:6867>) failed: cannot parse address" every time server v2 tries to connect. I expect that is a bug that could be fixed.
Lastly, since we may encounter situations where network communication is not working, we should facilitate access to the console. When I was trying to help Timothy change a location radius setting remotely by phone and the web browser was timing out, I suggested that he find a micro-USB cable so he could connect to the console. But then I realized he would not have any application on his laptop that would allow him to connect to the console. Developers use "make monitor" in the software development cycle, but users won't have that tool. I have my own program on the MacBook that I use as an alternative when I don't want to induce a reset when I connect. But is there a simple program for Windows suitable for non-developer users that can connect to the OVMS console?
-- Steve _______________________________________________ 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 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
The new esp-idf works good, I think I'll push the changes this evening. I even have some more free IRAM now, it used to be down to ~1K and is now ~7K. Remaining crashes recorded up to now: * 3.1.008-32-g2fa3ab8-dirty/ota_1/edge (build idf v3.2-dev-168-g0fb2019f Jul 6 2018 20:49:00),7,Crash,8,14,1,0,IllegalInstruction,0,0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 , * 3.1.008-32-g2fa3ab8-dirty/ota_0/edge (build idf v3.2-dev-168-g0fb2019f Jul 6 2018 20:49:00),98,Crash,8,14,1,0,LoadProhibited,1,0x401165fc 0x00060230 0x80106004 0x3fff0d40 0x3ffc4794 0x00000000 0x3f4020ac 0x3fff1080 0x3fff1060 0x00000008 0x3ffed634 0x00000000 0x00000001 0x3ffc41f5 0x000000ff 0x0000ff00 0x00ff0000 0xff000000 0x00000004 0x0000001c 0x00000064 0x4009ee01 0x4009ee11 0xffffffff ,0x401165fc 0x40106001 0x400d3f9b 0x400d3ab5 → Using elf file: tmp/3.1.008-32-g2fa3ab8-dirty-elf/ovms3.elf 0x401165fc is in _vfprintf_r (../../../.././newlib/libc/stdio/vfprintf.c:1855). 0x40106001 is in _siprintf_r (../../../.././newlib/libc/stdio/siprintf.c:124). 0x400d3f9b is in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char*>(char*, char*, std::forward_iterator_tag) (/home/balzer/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.tcc:215). 210 basic_string<_CharT, _Traits, _Alloc>:: 211 _M_construct(_InIterator __beg, _InIterator __end, 212 std::forward_iterator_tag) 213 { 214 // NB: Not required, but considered best practice. 215 if (__gnu_cxx::__is_null_pointer(__beg) && __beg != __end) 216 std::__throw_logic_error(__N("basic_string::" 217 "_M_construct null not valid")); 218 219 size_type __dnew = static_cast<size_type>(std::distance(__beg, __end)); 0x400d3ab5 is in canlog::LogStatus(canbus*, CAN_LogEntry_t, CAN_status_t const*) (/home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/can/src/canlog.cpp:297). 292 return; 293 if (CheckFilter(bus, type)) 294 { 295 CAN_LogMsg_t msg; 296 msg.timestamp = esp_log_timestamp(); 297 msg.bus = bus; 298 msg.type = type; 299 msg.status = *status; 300 m_msgcount++; 301 if (xQueueSend(m_queue, &msg, 0) != pdTRUE) * 3.1.008-32-g2fa3ab8-dirty/ota_1/edge (build idf v3.2-dev-168-g0fb2019f Jul 6 2018 20:49:00),11,Crash,12,12,3,0,abort(),0,,0x40095e74 0x4009606f 0x400ddaf7 0x40084e15 0x401e271d → watchdog timeout, no more info Regards, Michael Am 06.07.2018 um 22:07 schrieb Michael Balzer:
I've been using APCLIENT all the time and only had one crash that looked like a wifi problem. This really is a very specific problem. I also have a very good wifi signal, I can perfectly use my module's web UI while the car is in my garage two floors below. But I live in an uncrowded area, not much wifi competition.
I have updated my esp-idf to the latest upstream master (it's v3.2 now) and could build without any memory issues. The wifi driver now, besided loads of bug fixes, also supports CSI. Our code only needs a minor adjustment if you'd like to compile yourself, add…
#define _SOC_SPI_PERIPH_H_ // don't include spi_periph.h (type conflict)
…in components/spinodma/spi_master_nodma.h before #include "driver/spi_common.h".
If you don't want to compile, the new build (with CSI enabled) is also on my server:
http://ovms.dexters-web.de/firmware/ota/v3.1/edge/
…and now being installed by my beta testers.
Regards, Michael
Am 06.07.2018 um 16:28 schrieb Mark Webb-Johnson:
My 2c:
For the access points I normally use, it works 100% of the time for me. The only issue I had was when the SSID password was wrong on one of my access points (sharing the same SSID) and that was randomly causing me connection issues (every time the ESP32 picked it).
I also don’t use APCLIENT, and only use SCLIENT mode. I’ve found APCLIENT to be buggy as hell.
But, I do have problems connecting to some access points. In particular phone hotspots. I suspect either bugs in the wifi stack, or some issue with channels.
The only thing I am wary of is that our current code does this:
esp_wifi_set_config… esp_wifi_start… esp_wifi_connect...
But the Espressif examples have:
esp_wifi_set_config… esp_wifi_start… Wait for SYSTEM_EVENT_STA_START
esp_wifi_connect...
I had that working the Espressif way in my big wifi refactor that never made it to production. But our current code doesn’t wait for the SYSTEM_EVENT_STA_START before calling esp_wifi_connect.
Regards, Mark.
On 6 Jul 2018, at 9:04 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
I've had similar reports regarding poor wifi connectivity, and this seems to affect some modules more than others (or may be channel/frequency dependant?). One user has just 1-2 bars AP wifi signal with the module placed ~ 50 cm away from the phone.
I also still get reports of spurious strange crashes, that mostly seem to be related to situations with poor wifi signal. Some crash backtraces just are complete blank / null, and there is no crash report on the USB output for these before reboot.
Yesterday, Frank tried to perform some wifi scans. The first scan went fine, the second never returned, he had to power off the module. After reboot, all successive scans worked.
Two users reported they occasionally cannot auth to the OVMS AP with the correct password, and they can then reconnect just by retrying for some minutes or by connecting & disconnecting another client to the AP.
I already had a look at the wifi tx power configuration, it's at 100% by default.
This all feels like a) we need to change something about the antenna, and b) there are quite some bugs in the wifi blob.
Looking at https://github.com/espressif/esp32-wifi-lib/commits/master it seems there have been numerous wifi blob fixes lately. Last time I checked I still was out of memory with the current esp-idf, I'll check again.
Regards, Michael
Am 06.07.2018 um 01:48 schrieb Stephen Casner:
I find the wifi performance of OVMS v3 to be poor, and I'm wondering how it might be improved. I have a mix of thoughts here.
For both my own unit and that of Timothy Rodgers, wifi reception in our garages was unusable. You can blame that on too much distance from the access point, but my iPhone and MacBook both access the wifi just fine from my garage. The wifi antenna in the OVMS is probably smaller and its location within the metal framework around the car's firewall may impede radio transmission. Perhaps it would be feasible to switch to an ESP32-WROVER-I with an external antenna to improve performance, but that would be a big deal. If there is a transmit power adjustment, perhaps that could be increased?
When Timothy parks his car next to his house, which is about 50 feet closer than the garage, then the wifi reception was good enough for the update to 3.1.008 to succeed. But when he tries to connect with the browser, page updates often time out, so it is close to unusable. Perhaps we could improve usability by increasing the timeout in our javascript to allow more time for TCP to retransmit?
For my own unit, I switched from AP+client to just client mode and at first it seemed that had improved the client performance. But still the next day I had no access from the iPhone app. When I connected to the console to find out why I saw that server v2 was repeatedly trying to connect and failing. I'm presuming that the cause was poor wifi connectivity since I was also not able to reach the web server on the client address, although I have not proven that. But since the client wifi was associated with the home AP and had an address, the OVMS network routing preferred the wifi and did not try to use the modem. For now I have resorted to turning off wifi. I suggest that the network routing algorithm be enhanced to back off to use the modem if some number of attempts to connect to the server over wifi have failed. The iPhone will do this for itself (there is a setting to enable this called Wi-Fi Assist).
The behavior of repeated connection attempts and failures by server v2 seems to induce a more serious failure after a while, perhaps due to some resource starvation. At that point there is a failure message "mg_connect(api.openvehicles.com:6867 <http://api.openvehicles.com:6867>) failed: cannot parse address" every time server v2 tries to connect. I expect that is a bug that could be fixed.
Lastly, since we may encounter situations where network communication is not working, we should facilitate access to the console. When I was trying to help Timothy change a location radius setting remotely by phone and the web browser was timing out, I suggested that he find a micro-USB cable so he could connect to the console. But then I realized he would not have any application on his laptop that would allow him to connect to the console. Developers use "make monitor" in the software development cycle, but users won't have that tool. I have my own program on the MacBook that I use as an alternative when I don't want to induce a reset when I connect. But is there a simple program for Windows suitable for non-developer users that can connect to the OVMS console?
-- Steve _______________________________________________ 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 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
I even have some more free IRAM now, it used to be down to ~1K and is now ~7K.
That is very very good news. Using RELEASE build (rather than DEBUG), I got mine down to a usable level, but this should give us some breathing room. Any noticeable improvement to the wifi issues? Regards, Mark.
On 8 Jul 2018, at 4:49 PM, Michael Balzer <dexter@expeedo.de> wrote:
The new esp-idf works good, I think I'll push the changes this evening.
I even have some more free IRAM now, it used to be down to ~1K and is now ~7K.
Remaining crashes recorded up to now: 3.1.008-32-g2fa3ab8-dirty/ota_1/edge (build idf v3.2-dev-168-g0fb2019f Jul 6 2018 20:49:00),7,Crash,8,14,1,0,IllegalInstruction,0,0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 ,
3.1.008-32-g2fa3ab8-dirty/ota_0/edge (build idf v3.2-dev-168-g0fb2019f Jul 6 2018 20:49:00),98,Crash,8,14,1,0,LoadProhibited,1,0x401165fc 0x00060230 0x80106004 0x3fff0d40 0x3ffc4794 0x00000000 0x3f4020ac 0x3fff1080 0x3fff1060 0x00000008 0x3ffed634 0x00000000 0x00000001 0x3ffc41f5 0x000000ff 0x0000ff00 0x00ff0000 0xff000000 0x00000004 0x0000001c 0x00000064 0x4009ee01 0x4009ee11 0xffffffff ,0x401165fc 0x40106001 0x400d3f9b 0x400d3ab5 → Using elf file: tmp/3.1.008-32-g2fa3ab8-dirty-elf/ovms3.elf 0x401165fc is in _vfprintf_r (../../../.././newlib/libc/stdio/vfprintf.c:1855). 0x40106001 is in _siprintf_r (../../../.././newlib/libc/stdio/siprintf.c:124). 0x400d3f9b is in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char*>(char*, char*, std::forward_iterator_tag) (/home/balzer/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.tcc:215). 210 basic_string<_CharT, _Traits, _Alloc>:: 211 _M_construct(_InIterator __beg, _InIterator __end, 212 std::forward_iterator_tag) 213 { 214 // NB: Not required, but considered best practice. 215 if (__gnu_cxx::__is_null_pointer(__beg) && __beg != __end) 216 std::__throw_logic_error(__N("basic_string::" 217 "_M_construct null not valid")); 218 219 size_type __dnew = static_cast<size_type>(std::distance(__beg, __end)); 0x400d3ab5 is in canlog::LogStatus(canbus*, CAN_LogEntry_t, CAN_status_t const*) (/home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/can/src/canlog.cpp:297). 292 return; 293 if (CheckFilter(bus, type)) 294 { 295 CAN_LogMsg_t msg; 296 msg.timestamp = esp_log_timestamp(); 297 msg.bus = bus; 298 msg.type = type; 299 msg.status = *status; 300 m_msgcount++; 301 if (xQueueSend(m_queue, &msg, 0) != pdTRUE)
3.1.008-32-g2fa3ab8-dirty/ota_1/edge (build idf v3.2-dev-168-g0fb2019f Jul 6 2018 20:49:00),11,Crash,12,12,3,0,abort(),0,,0x40095e74 0x4009606f 0x400ddaf7 0x40084e15 0x401e271d → watchdog timeout, no more info Regards, Michael
Am 06.07.2018 um 22:07 schrieb Michael Balzer:
I've been using APCLIENT all the time and only had one crash that looked like a wifi problem. This really is a very specific problem. I also have a very good wifi signal, I can perfectly use my module's web UI while the car is in my garage two floors below. But I live in an uncrowded area, not much wifi competition.
I have updated my esp-idf to the latest upstream master (it's v3.2 now) and could build without any memory issues. The wifi driver now, besided loads of bug fixes, also supports CSI. Our code only needs a minor adjustment if you'd like to compile yourself, add…
#define _SOC_SPI_PERIPH_H_ // don't include spi_periph.h (type conflict)
…in components/spinodma/spi_master_nodma.h before #include "driver/spi_common.h".
If you don't want to compile, the new build (with CSI enabled) is also on my server:
http://ovms.dexters-web.de/firmware/ota/v3.1/edge/ <http://ovms.dexters-web.de/firmware/ota/v3.1/edge/>
…and now being installed by my beta testers.
Regards, Michael
Am 06.07.2018 um 16:28 schrieb Mark Webb-Johnson:
My 2c:
For the access points I normally use, it works 100% of the time for me. The only issue I had was when the SSID password was wrong on one of my access points (sharing the same SSID) and that was randomly causing me connection issues (every time the ESP32 picked it).
I also don’t use APCLIENT, and only use SCLIENT mode. I’ve found APCLIENT to be buggy as hell.
But, I do have problems connecting to some access points. In particular phone hotspots. I suspect either bugs in the wifi stack, or some issue with channels.
The only thing I am wary of is that our current code does this:
esp_wifi_set_config… esp_wifi_start… esp_wifi_connect...
But the Espressif examples have:
esp_wifi_set_config… esp_wifi_start… Wait for SYSTEM_EVENT_STA_START esp_wifi_connect...
I had that working the Espressif way in my big wifi refactor that never made it to production. But our current code doesn’t wait for the SYSTEM_EVENT_STA_START before calling esp_wifi_connect.
Regards, Mark.
On 6 Jul 2018, at 9:04 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
I've had similar reports regarding poor wifi connectivity, and this seems to affect some modules more than others (or may be channel/frequency dependant?). One user has just 1-2 bars AP wifi signal with the module placed ~ 50 cm away from the phone.
I also still get reports of spurious strange crashes, that mostly seem to be related to situations with poor wifi signal. Some crash backtraces just are complete blank / null, and there is no crash report on the USB output for these before reboot.
Yesterday, Frank tried to perform some wifi scans. The first scan went fine, the second never returned, he had to power off the module. After reboot, all successive scans worked.
Two users reported they occasionally cannot auth to the OVMS AP with the correct password, and they can then reconnect just by retrying for some minutes or by connecting & disconnecting another client to the AP.
I already had a look at the wifi tx power configuration, it's at 100% by default.
This all feels like a) we need to change something about the antenna, and b) there are quite some bugs in the wifi blob.
Looking at https://github.com/espressif/esp32-wifi-lib/commits/master <https://github.com/espressif/esp32-wifi-lib/commits/master> it seems there have been numerous wifi blob fixes lately. Last time I checked I still was out of memory with the current esp-idf, I'll check again.
Regards, Michael
Am 06.07.2018 um 01:48 schrieb Stephen Casner:
I find the wifi performance of OVMS v3 to be poor, and I'm wondering how it might be improved. I have a mix of thoughts here.
For both my own unit and that of Timothy Rodgers, wifi reception in our garages was unusable. You can blame that on too much distance from the access point, but my iPhone and MacBook both access the wifi just fine from my garage. The wifi antenna in the OVMS is probably smaller and its location within the metal framework around the car's firewall may impede radio transmission. Perhaps it would be feasible to switch to an ESP32-WROVER-I with an external antenna to improve performance, but that would be a big deal. If there is a transmit power adjustment, perhaps that could be increased?
When Timothy parks his car next to his house, which is about 50 feet closer than the garage, then the wifi reception was good enough for the update to 3.1.008 to succeed. But when he tries to connect with the browser, page updates often time out, so it is close to unusable. Perhaps we could improve usability by increasing the timeout in our javascript to allow more time for TCP to retransmit?
For my own unit, I switched from AP+client to just client mode and at first it seemed that had improved the client performance. But still the next day I had no access from the iPhone app. When I connected to the console to find out why I saw that server v2 was repeatedly trying to connect and failing. I'm presuming that the cause was poor wifi connectivity since I was also not able to reach the web server on the client address, although I have not proven that. But since the client wifi was associated with the home AP and had an address, the OVMS network routing preferred the wifi and did not try to use the modem. For now I have resorted to turning off wifi. I suggest that the network routing algorithm be enhanced to back off to use the modem if some number of attempts to connect to the server over wifi have failed. The iPhone will do this for itself (there is a setting to enable this called Wi-Fi Assist).
The behavior of repeated connection attempts and failures by server v2 seems to induce a more serious failure after a while, perhaps due to some resource starvation. At that point there is a failure message "mg_connect(api.openvehicles.com:6867 <http://api.openvehicles.com:6867/>) failed: cannot parse address" every time server v2 tries to connect. I expect that is a bug that could be fixed.
Lastly, since we may encounter situations where network communication is not working, we should facilitate access to the console. When I was trying to help Timothy change a location radius setting remotely by phone and the web browser was timing out, I suggested that he find a micro-USB cable so he could connect to the console. But then I realized he would not have any application on his laptop that would allow him to connect to the console. Developers use "make monitor" in the software development cycle, but users won't have that tool. I have my own program on the MacBook that I use as an alternative when I don't want to induce a reset when I connect. But is there a simple program for Windows suitable for non-developer users that can connect to the OVMS console?
-- Steve _______________________________________________ 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
Sorry, no user feedback up to now on the wifi issues. As I don't have them myself, I need to wait for feedback. But no news means it's at least not worse than before ;) Anyway, I've pushed the changes and esp-idf update. @all: you need to update your esp-idf to build the current version: * cd $IDF_PATH * git pull * git submodule update --recursive Regards, Michael Am 08.07.2018 um 10:59 schrieb Mark Webb-Johnson:
I even have some more free IRAM now, it used to be down to ~1K and is now ~7K.
That is very very good news. Using RELEASE build (rather than DEBUG), I got mine down to a usable level, but this should give us some breathing room.
Any noticeable improvement to the wifi issues?
Regards, Mark.
On 8 Jul 2018, at 4:49 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
The new esp-idf works good, I think I'll push the changes this evening.
I even have some more free IRAM now, it used to be down to ~1K and is now ~7K.
Remaining crashes recorded up to now:
* 3.1.008-32-g2fa3ab8-dirty/ota_1/edge (build idf v3.2-dev-168-g0fb2019f Jul 6 2018 20:49:00),7,Crash,8,14,1,0,IllegalInstruction,0,0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 ,
* 3.1.008-32-g2fa3ab8-dirty/ota_0/edge (build idf v3.2-dev-168-g0fb2019f Jul 6 2018 20:49:00),98,Crash,8,14,1,0,LoadProhibited,1,0x401165fc 0x00060230 0x80106004 0x3fff0d40 0x3ffc4794 0x00000000 0x3f4020ac 0x3fff1080 0x3fff1060 0x00000008 0x3ffed634 0x00000000 0x00000001 0x3ffc41f5 0x000000ff 0x0000ff00 0x00ff0000 0xff000000 0x00000004 0x0000001c 0x00000064 0x4009ee01 0x4009ee11 0xffffffff ,0x401165fc 0x40106001 0x400d3f9b 0x400d3ab5 → Using elf file: tmp/3.1.008-32-g2fa3ab8-dirty-elf/ovms3.elf 0x401165fc is in _vfprintf_r (../../../.././newlib/libc/stdio/vfprintf.c:1855). 0x40106001 is in _siprintf_r (../../../.././newlib/libc/stdio/siprintf.c:124). 0x400d3f9b is in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char*>(char*, char*, std::forward_iterator_tag) (/home/balzer/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.tcc:215). 210 basic_string<_CharT, _Traits, _Alloc>:: 211 _M_construct(_InIterator __beg, _InIterator __end, 212 std::forward_iterator_tag) 213 { 214 // NB: Not required, but considered best practice. 215 if (__gnu_cxx::__is_null_pointer(__beg) && __beg != __end) 216 std::__throw_logic_error(__N("basic_string::" 217 "_M_construct null not valid")); 218 219 size_type __dnew = static_cast<size_type>(std::distance(__beg, __end)); 0x400d3ab5 is in canlog::LogStatus(canbus*, CAN_LogEntry_t, CAN_status_t const*) (/home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/can/src/canlog.cpp:297). 292 return; 293 if (CheckFilter(bus, type)) 294 { 295 CAN_LogMsg_t msg; 296 msg.timestamp = esp_log_timestamp(); 297 msg.bus = bus; 298 msg.type = type; 299 msg.status = *status; 300 m_msgcount++; 301 if (xQueueSend(m_queue, &msg, 0) != pdTRUE)
* 3.1.008-32-g2fa3ab8-dirty/ota_1/edge (build idf v3.2-dev-168-g0fb2019f Jul 6 2018 20:49:00),11,Crash,12,12,3,0,abort(),0,,0x40095e74 0x4009606f 0x400ddaf7 0x40084e15 0x401e271d → watchdog timeout, no more info
Regards, Michael
Am 06.07.2018 um 22:07 schrieb Michael Balzer:
I've been using APCLIENT all the time and only had one crash that looked like a wifi problem. This really is a very specific problem. I also have a very good wifi signal, I can perfectly use my module's web UI while the car is in my garage two floors below. But I live in an uncrowded area, not much wifi competition.
I have updated my esp-idf to the latest upstream master (it's v3.2 now) and could build without any memory issues. The wifi driver now, besided loads of bug fixes, also supports CSI. Our code only needs a minor adjustment if you'd like to compile yourself, add…
#define _SOC_SPI_PERIPH_H_ // don't include spi_periph.h (type conflict)
…in components/spinodma/spi_master_nodma.h before #include "driver/spi_common.h".
If you don't want to compile, the new build (with CSI enabled) is also on my server:
http://ovms.dexters-web.de/firmware/ota/v3.1/edge/
…and now being installed by my beta testers.
Regards, Michael
Am 06.07.2018 um 16:28 schrieb Mark Webb-Johnson:
My 2c:
For the access points I normally use, it works 100% of the time for me. The only issue I had was when the SSID password was wrong on one of my access points (sharing the same SSID) and that was randomly causing me connection issues (every time the ESP32 picked it).
I also don’t use APCLIENT, and only use SCLIENT mode. I’ve found APCLIENT to be buggy as hell.
But, I do have problems connecting to some access points. In particular phone hotspots. I suspect either bugs in the wifi stack, or some issue with channels.
The only thing I am wary of is that our current code does this:
esp_wifi_set_config… esp_wifi_start… esp_wifi_connect...
But the Espressif examples have:
esp_wifi_set_config… esp_wifi_start… Wait for SYSTEM_EVENT_STA_START
esp_wifi_connect...
I had that working the Espressif way in my big wifi refactor that never made it to production. But our current code doesn’t wait for the SYSTEM_EVENT_STA_START before calling esp_wifi_connect.
Regards, Mark.
On 6 Jul 2018, at 9:04 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
I've had similar reports regarding poor wifi connectivity, and this seems to affect some modules more than others (or may be channel/frequency dependant?). One user has just 1-2 bars AP wifi signal with the module placed ~ 50 cm away from the phone.
I also still get reports of spurious strange crashes, that mostly seem to be related to situations with poor wifi signal. Some crash backtraces just are complete blank / null, and there is no crash report on the USB output for these before reboot.
Yesterday, Frank tried to perform some wifi scans. The first scan went fine, the second never returned, he had to power off the module. After reboot, all successive scans worked.
Two users reported they occasionally cannot auth to the OVMS AP with the correct password, and they can then reconnect just by retrying for some minutes or by connecting & disconnecting another client to the AP.
I already had a look at the wifi tx power configuration, it's at 100% by default.
This all feels like a) we need to change something about the antenna, and b) there are quite some bugs in the wifi blob.
Looking at https://github.com/espressif/esp32-wifi-lib/commits/master it seems there have been numerous wifi blob fixes lately. Last time I checked I still was out of memory with the current esp-idf, I'll check again.
Regards, Michael
Am 06.07.2018 um 01:48 schrieb Stephen Casner:
I find the wifi performance of OVMS v3 to be poor, and I'm wondering how it might be improved. I have a mix of thoughts here.
For both my own unit and that of Timothy Rodgers, wifi reception in our garages was unusable. You can blame that on too much distance from the access point, but my iPhone and MacBook both access the wifi just fine from my garage. The wifi antenna in the OVMS is probably smaller and its location within the metal framework around the car's firewall may impede radio transmission. Perhaps it would be feasible to switch to an ESP32-WROVER-I with an external antenna to improve performance, but that would be a big deal. If there is a transmit power adjustment, perhaps that could be increased?
When Timothy parks his car next to his house, which is about 50 feet closer than the garage, then the wifi reception was good enough for the update to 3.1.008 to succeed. But when he tries to connect with the browser, page updates often time out, so it is close to unusable. Perhaps we could improve usability by increasing the timeout in our javascript to allow more time for TCP to retransmit?
For my own unit, I switched from AP+client to just client mode and at first it seemed that had improved the client performance. But still the next day I had no access from the iPhone app. When I connected to the console to find out why I saw that server v2 was repeatedly trying to connect and failing. I'm presuming that the cause was poor wifi connectivity since I was also not able to reach the web server on the client address, although I have not proven that. But since the client wifi was associated with the home AP and had an address, the OVMS network routing preferred the wifi and did not try to use the modem. For now I have resorted to turning off wifi. I suggest that the network routing algorithm be enhanced to back off to use the modem if some number of attempts to connect to the server over wifi have failed. The iPhone will do this for itself (there is a setting to enable this called Wi-Fi Assist).
The behavior of repeated connection attempts and failures by server v2 seems to induce a more serious failure after a while, perhaps due to some resource starvation. At that point there is a failure message "mg_connect(api.openvehicles.com:6867 <http://api.openvehicles.com:6867/>) failed: cannot parse address" every time server v2 tries to connect. I expect that is a bug that could be fixed.
Lastly, since we may encounter situations where network communication is not working, we should facilitate access to the console. When I was trying to help Timothy change a location radius setting remotely by phone and the web browser was timing out, I suggested that he find a micro-USB cable so he could connect to the console. But then I realized he would not have any application on his laptop that would allow him to connect to the console. Developers use "make monitor" in the software development cycle, but users won't have that tool. I have my own program on the MacBook that I use as an alternative when I don't want to induce a reset when I connect. But is there a simple program for Windows suitable for non-developer users that can connect to the OVMS console?
-- Steve _______________________________________________ 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 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 _______________________________________________ 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
Works for me, and the tonight’s edge nightly build will feature this. Only issue I am seeing is that Espressif seemed to have messed up the crlf handling on ‘make monitor’ again. The ‘make simple_monitor’ works fine, but for the full monitor terminal emulator, the CRLF issued by our console (when you press ENTER) is lost. Just seems to end up as a CR (LF discarded). Regards, Mark.
On 9 Jul 2018, at 6:14 AM, Michael Balzer <dexter@expeedo.de> wrote:
Sorry, no user feedback up to now on the wifi issues. As I don't have them myself, I need to wait for feedback. But no news means it's at least not worse than before ;)
Anyway, I've pushed the changes and esp-idf update.
@all: you need to update your esp-idf to build the current version: cd $IDF_PATH git pull git submodule update --recursive
Regards, Michael
Am 08.07.2018 um 10:59 schrieb Mark Webb-Johnson:
I even have some more free IRAM now, it used to be down to ~1K and is now ~7K.
That is very very good news. Using RELEASE build (rather than DEBUG), I got mine down to a usable level, but this should give us some breathing room.
Any noticeable improvement to the wifi issues?
Regards, Mark.
On 8 Jul 2018, at 4:49 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
The new esp-idf works good, I think I'll push the changes this evening.
I even have some more free IRAM now, it used to be down to ~1K and is now ~7K.
Remaining crashes recorded up to now: 3.1.008-32-g2fa3ab8-dirty/ota_1/edge (build idf v3.2-dev-168-g0fb2019f Jul 6 2018 20:49:00),7,Crash,8,14,1,0,IllegalInstruction,0,0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 ,
3.1.008-32-g2fa3ab8-dirty/ota_0/edge (build idf v3.2-dev-168-g0fb2019f Jul 6 2018 20:49:00),98,Crash,8,14,1,0,LoadProhibited,1,0x401165fc 0x00060230 0x80106004 0x3fff0d40 0x3ffc4794 0x00000000 0x3f4020ac 0x3fff1080 0x3fff1060 0x00000008 0x3ffed634 0x00000000 0x00000001 0x3ffc41f5 0x000000ff 0x0000ff00 0x00ff0000 0xff000000 0x00000004 0x0000001c 0x00000064 0x4009ee01 0x4009ee11 0xffffffff ,0x401165fc 0x40106001 0x400d3f9b 0x400d3ab5 → Using elf file: tmp/3.1.008-32-g2fa3ab8-dirty-elf/ovms3.elf 0x401165fc is in _vfprintf_r (../../../.././newlib/libc/stdio/vfprintf.c:1855). 0x40106001 is in _siprintf_r (../../../.././newlib/libc/stdio/siprintf.c:124). 0x400d3f9b is in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char*>(char*, char*, std::forward_iterator_tag) (/home/balzer/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.tcc:215). 210 basic_string<_CharT, _Traits, _Alloc>:: 211 _M_construct(_InIterator __beg, _InIterator __end, 212 std::forward_iterator_tag) 213 { 214 // NB: Not required, but considered best practice. 215 if (__gnu_cxx::__is_null_pointer(__beg) && __beg != __end) 216 std::__throw_logic_error(__N("basic_string::" 217 "_M_construct null not valid")); 218 219 size_type __dnew = static_cast<size_type>(std::distance(__beg, __end)); 0x400d3ab5 is in canlog::LogStatus(canbus*, CAN_LogEntry_t, CAN_status_t const*) (/home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/can/src/canlog.cpp:297). 292 return; 293 if (CheckFilter(bus, type)) 294 { 295 CAN_LogMsg_t msg; 296 msg.timestamp = esp_log_timestamp(); 297 msg.bus = bus; 298 msg.type = type; 299 msg.status = *status; 300 m_msgcount++; 301 if (xQueueSend(m_queue, &msg, 0) != pdTRUE)
3.1.008-32-g2fa3ab8-dirty/ota_1/edge (build idf v3.2-dev-168-g0fb2019f Jul 6 2018 20:49:00),11,Crash,12,12,3,0,abort(),0,,0x40095e74 0x4009606f 0x400ddaf7 0x40084e15 0x401e271d → watchdog timeout, no more info Regards, Michael
Am 06.07.2018 um 22:07 schrieb Michael Balzer:
I've been using APCLIENT all the time and only had one crash that looked like a wifi problem. This really is a very specific problem. I also have a very good wifi signal, I can perfectly use my module's web UI while the car is in my garage two floors below. But I live in an uncrowded area, not much wifi competition.
I have updated my esp-idf to the latest upstream master (it's v3.2 now) and could build without any memory issues. The wifi driver now, besided loads of bug fixes, also supports CSI. Our code only needs a minor adjustment if you'd like to compile yourself, add…
#define _SOC_SPI_PERIPH_H_ // don't include spi_periph.h (type conflict)
…in components/spinodma/spi_master_nodma.h before #include "driver/spi_common.h".
If you don't want to compile, the new build (with CSI enabled) is also on my server:
http://ovms.dexters-web.de/firmware/ota/v3.1/edge/ <http://ovms.dexters-web.de/firmware/ota/v3.1/edge/>
…and now being installed by my beta testers.
Regards, Michael
Am 06.07.2018 um 16:28 schrieb Mark Webb-Johnson:
My 2c:
For the access points I normally use, it works 100% of the time for me. The only issue I had was when the SSID password was wrong on one of my access points (sharing the same SSID) and that was randomly causing me connection issues (every time the ESP32 picked it).
I also don’t use APCLIENT, and only use SCLIENT mode. I’ve found APCLIENT to be buggy as hell.
But, I do have problems connecting to some access points. In particular phone hotspots. I suspect either bugs in the wifi stack, or some issue with channels.
The only thing I am wary of is that our current code does this:
esp_wifi_set_config… esp_wifi_start… esp_wifi_connect...
But the Espressif examples have:
esp_wifi_set_config… esp_wifi_start… Wait for SYSTEM_EVENT_STA_START esp_wifi_connect...
I had that working the Espressif way in my big wifi refactor that never made it to production. But our current code doesn’t wait for the SYSTEM_EVENT_STA_START before calling esp_wifi_connect.
Regards, Mark.
On 6 Jul 2018, at 9:04 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
I've had similar reports regarding poor wifi connectivity, and this seems to affect some modules more than others (or may be channel/frequency dependant?). One user has just 1-2 bars AP wifi signal with the module placed ~ 50 cm away from the phone.
I also still get reports of spurious strange crashes, that mostly seem to be related to situations with poor wifi signal. Some crash backtraces just are complete blank / null, and there is no crash report on the USB output for these before reboot.
Yesterday, Frank tried to perform some wifi scans. The first scan went fine, the second never returned, he had to power off the module. After reboot, all successive scans worked.
Two users reported they occasionally cannot auth to the OVMS AP with the correct password, and they can then reconnect just by retrying for some minutes or by connecting & disconnecting another client to the AP.
I already had a look at the wifi tx power configuration, it's at 100% by default.
This all feels like a) we need to change something about the antenna, and b) there are quite some bugs in the wifi blob.
Looking at https://github.com/espressif/esp32-wifi-lib/commits/master <https://github.com/espressif/esp32-wifi-lib/commits/master> it seems there have been numerous wifi blob fixes lately. Last time I checked I still was out of memory with the current esp-idf, I'll check again.
Regards, Michael
Am 06.07.2018 um 01:48 schrieb Stephen Casner: > I find the wifi performance of OVMS v3 to be poor, and I'm wondering > how it might be improved. I have a mix of thoughts here. > > For both my own unit and that of Timothy Rodgers, wifi reception in > our garages was unusable. You can blame that on too much distance > from the access point, but my iPhone and MacBook both access the wifi > just fine from my garage. The wifi antenna in the OVMS is probably > smaller and its location within the metal framework around the car's > firewall may impede radio transmission. Perhaps it would be feasible > to switch to an ESP32-WROVER-I with an external antenna to improve > performance, but that would be a big deal. If there is a transmit > power adjustment, perhaps that could be increased? > > When Timothy parks his car next to his house, which is about 50 feet > closer than the garage, then the wifi reception was good enough for > the update to 3.1.008 to succeed. But when he tries to connect with > the browser, page updates often time out, so it is close to unusable. > Perhaps we could improve usability by increasing the timeout in our > javascript to allow more time for TCP to retransmit? > > For my own unit, I switched from AP+client to just client mode and at > first it seemed that had improved the client performance. But still > the next day I had no access from the iPhone app. When I connected to > the console to find out why I saw that server v2 was repeatedly trying > to connect and failing. I'm presuming that the cause was poor wifi > connectivity since I was also not able to reach the web server on the > client address, although I have not proven that. But since the client > wifi was associated with the home AP and had an address, the OVMS > network routing preferred the wifi and did not try to use the modem. > For now I have resorted to turning off wifi. I suggest that the > network routing algorithm be enhanced to back off to use the modem if > some number of attempts to connect to the server over wifi have > failed. The iPhone will do this for itself (there is a setting to > enable this called Wi-Fi Assist). > > The behavior of repeated connection attempts and failures by server v2 > seems to induce a more serious failure after a while, perhaps due to > some resource starvation. At that point there is a failure message > "mg_connect(api.openvehicles.com:6867 <http://api.openvehicles.com:6867/>) failed: cannot parse address" > every time server v2 tries to connect. I expect that is a bug that > could be fixed. > > Lastly, since we may encounter situations where network communication > is not working, we should facilitate access to the console. When I > was trying to help Timothy change a location radius setting remotely > by phone and the web browser was timing out, I suggested that he find > a micro-USB cable so he could connect to the console. But then I > realized he would not have any application on his laptop that would > allow him to connect to the console. Developers use "make monitor" in > the software development cycle, but users won't have that tool. I > have my own program on the MacBook that I use as an alternative when I > don't want to induce a reset when I connect. But is there a simple > program for Windows suitable for non-developer users that can connect > to the OVMS console? > > -- Steve > _______________________________________________ > 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 <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 http://lists.openvehicles.com/mailman/listinfo/ovmsdev
OK, so it's not in my python environment (I recently upgraded to openSuSE 15). It seems to happen only on single lines, consecutive lines are shown correctly. Regards, Michael Am 09.07.2018 um 04:34 schrieb Mark Webb-Johnson:
Works for me, and the tonight’s edge nightly build will feature this.
Only issue I am seeing is that Espressif seemed to have messed up the crlf handling on ‘make monitor’ again. The ‘make simple_monitor’ works fine, but for the full monitor terminal emulator, the CRLF issued by our console (when you press ENTER) is lost. Just seems to end up as a CR (LF discarded).
Regards, Mark.
On 9 Jul 2018, at 6:14 AM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Sorry, no user feedback up to now on the wifi issues. As I don't have them myself, I need to wait for feedback. But no news means it's at least not worse than before ;)
Anyway, I've pushed the changes and esp-idf update.
@all: you need to update your esp-idf to build the current version:
* cd $IDF_PATH * git pull * git submodule update --recursive
Regards, Michael
Am 08.07.2018 um 10:59 schrieb Mark Webb-Johnson:
I even have some more free IRAM now, it used to be down to ~1K and is now ~7K.
That is very very good news. Using RELEASE build (rather than DEBUG), I got mine down to a usable level, but this should give us some breathing room.
Any noticeable improvement to the wifi issues?
Regards, Mark.
On 8 Jul 2018, at 4:49 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
The new esp-idf works good, I think I'll push the changes this evening.
I even have some more free IRAM now, it used to be down to ~1K and is now ~7K.
Remaining crashes recorded up to now:
* 3.1.008-32-g2fa3ab8-dirty/ota_1/edge (build idf v3.2-dev-168-g0fb2019f Jul 6 2018 20:49:00),7,Crash,8,14,1,0,IllegalInstruction,0,0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 ,
* 3.1.008-32-g2fa3ab8-dirty/ota_0/edge (build idf v3.2-dev-168-g0fb2019f Jul 6 2018 20:49:00),98,Crash,8,14,1,0,LoadProhibited,1,0x401165fc 0x00060230 0x80106004 0x3fff0d40 0x3ffc4794 0x00000000 0x3f4020ac 0x3fff1080 0x3fff1060 0x00000008 0x3ffed634 0x00000000 0x00000001 0x3ffc41f5 0x000000ff 0x0000ff00 0x00ff0000 0xff000000 0x00000004 0x0000001c 0x00000064 0x4009ee01 0x4009ee11 0xffffffff ,0x401165fc 0x40106001 0x400d3f9b 0x400d3ab5 → Using elf file: tmp/3.1.008-32-g2fa3ab8-dirty-elf/ovms3.elf 0x401165fc is in _vfprintf_r (../../../.././newlib/libc/stdio/vfprintf.c:1855). 0x40106001 is in _siprintf_r (../../../.././newlib/libc/stdio/siprintf.c:124). 0x400d3f9b is in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char*>(char*, char*, std::forward_iterator_tag) (/home/balzer/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.tcc:215). 210 basic_string<_CharT, _Traits, _Alloc>:: 211 _M_construct(_InIterator __beg, _InIterator __end, 212 std::forward_iterator_tag) 213 { 214 // NB: Not required, but considered best practice. 215 if (__gnu_cxx::__is_null_pointer(__beg) && __beg != __end) 216 std::__throw_logic_error(__N("basic_string::" 217 "_M_construct null not valid")); 218 219 size_type __dnew = static_cast<size_type>(std::distance(__beg, __end)); 0x400d3ab5 is in canlog::LogStatus(canbus*, CAN_LogEntry_t, CAN_status_t const*) (/home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/can/src/canlog.cpp:297). 292 return; 293 if (CheckFilter(bus, type)) 294 { 295 CAN_LogMsg_t msg; 296 msg.timestamp = esp_log_timestamp(); 297 msg.bus = bus; 298 msg.type = type; 299 msg.status = *status; 300 m_msgcount++; 301 if (xQueueSend(m_queue, &msg, 0) != pdTRUE)
* 3.1.008-32-g2fa3ab8-dirty/ota_1/edge (build idf v3.2-dev-168-g0fb2019f Jul 6 2018 20:49:00),11,Crash,12,12,3,0,abort(),0,,0x40095e74 0x4009606f 0x400ddaf7 0x40084e15 0x401e271d → watchdog timeout, no more info
Regards, Michael
Am 06.07.2018 um 22:07 schrieb Michael Balzer:
I've been using APCLIENT all the time and only had one crash that looked like a wifi problem. This really is a very specific problem. I also have a very good wifi signal, I can perfectly use my module's web UI while the car is in my garage two floors below. But I live in an uncrowded area, not much wifi competition.
I have updated my esp-idf to the latest upstream master (it's v3.2 now) and could build without any memory issues. The wifi driver now, besided loads of bug fixes, also supports CSI. Our code only needs a minor adjustment if you'd like to compile yourself, add…
#define _SOC_SPI_PERIPH_H_ // don't include spi_periph.h (type conflict)
…in components/spinodma/spi_master_nodma.h before #include "driver/spi_common.h".
If you don't want to compile, the new build (with CSI enabled) is also on my server:
http://ovms.dexters-web.de/firmware/ota/v3.1/edge/
…and now being installed by my beta testers.
Regards, Michael
Am 06.07.2018 um 16:28 schrieb Mark Webb-Johnson:
My 2c:
For the access points I normally use, it works 100% of the time for me. The only issue I had was when the SSID password was wrong on one of my access points (sharing the same SSID) and that was randomly causing me connection issues (every time the ESP32 picked it).
I also don’t use APCLIENT, and only use SCLIENT mode. I’ve found APCLIENT to be buggy as hell.
But, I do have problems connecting to some access points. In particular phone hotspots. I suspect either bugs in the wifi stack, or some issue with channels.
The only thing I am wary of is that our current code does this:
esp_wifi_set_config… esp_wifi_start… esp_wifi_connect...
But the Espressif examples have:
esp_wifi_set_config… esp_wifi_start… Wait for SYSTEM_EVENT_STA_START
esp_wifi_connect...
I had that working the Espressif way in my big wifi refactor that never made it to production. But our current code doesn’t wait for the SYSTEM_EVENT_STA_START before calling esp_wifi_connect.
Regards, Mark.
> On 6 Jul 2018, at 9:04 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote: > > I've had similar reports regarding poor wifi connectivity, and this seems to affect some modules more than others (or may be > channel/frequency dependant?). One > user has just 1-2 bars AP wifi signal with the module placed ~ 50 cm away from the phone. > > I also still get reports of spurious strange crashes, that mostly seem to be related to situations with poor wifi signal. Some crash > backtraces just are > complete blank / null, and there is no crash report on the USB output for these before reboot. > > Yesterday, Frank tried to perform some wifi scans. The first scan went fine, the second never returned, he had to power off the module. > After reboot, all > successive scans worked. > > Two users reported they occasionally cannot auth to the OVMS AP with the correct password, and they can then reconnect just by retrying > for some minutes or by > connecting & disconnecting another client to the AP. > > I already had a look at the wifi tx power configuration, it's at 100% by default. > > This all feels like a) we need to change something about the antenna, and b) there are quite some bugs in the wifi blob. > > Looking at https://github.com/espressif/esp32-wifi-lib/commits/master it seems there have been numerous wifi blob fixes lately. Last > time I checked I still was > out of memory with the current esp-idf, I'll check again. > > Regards, > Michael > > > Am 06.07.2018 um 01:48 schrieb Stephen Casner: >> I find the wifi performance of OVMS v3 to be poor, and I'm wondering >> how it might be improved. I have a mix of thoughts here. >> >> For both my own unit and that of Timothy Rodgers, wifi reception in >> our garages was unusable. You can blame that on too much distance >> from the access point, but my iPhone and MacBook both access the wifi >> just fine from my garage. The wifi antenna in the OVMS is probably >> smaller and its location within the metal framework around the car's >> firewall may impede radio transmission. Perhaps it would be feasible >> to switch to an ESP32-WROVER-I with an external antenna to improve >> performance, but that would be a big deal. If there is a transmit >> power adjustment, perhaps that could be increased? >> >> When Timothy parks his car next to his house, which is about 50 feet >> closer than the garage, then the wifi reception was good enough for >> the update to 3.1.008 to succeed. But when he tries to connect with >> the browser, page updates often time out, so it is close to unusable. >> Perhaps we could improve usability by increasing the timeout in our >> javascript to allow more time for TCP to retransmit? >> >> For my own unit, I switched from AP+client to just client mode and at >> first it seemed that had improved the client performance. But still >> the next day I had no access from the iPhone app. When I connected to >> the console to find out why I saw that server v2 was repeatedly trying >> to connect and failing. I'm presuming that the cause was poor wifi >> connectivity since I was also not able to reach the web server on the >> client address, although I have not proven that. But since the client >> wifi was associated with the home AP and had an address, the OVMS >> network routing preferred the wifi and did not try to use the modem. >> For now I have resorted to turning off wifi. I suggest that the >> network routing algorithm be enhanced to back off to use the modem if >> some number of attempts to connect to the server over wifi have >> failed. The iPhone will do this for itself (there is a setting to >> enable this called Wi-Fi Assist). >> >> The behavior of repeated connection attempts and failures by server v2 >> seems to induce a more serious failure after a while, perhaps due to >> some resource starvation. At that point there is a failure message >> "mg_connect(api.openvehicles.com:6867 <http://api.openvehicles.com:6867/>) failed: cannot parse address" >> every time server v2 tries to connect. I expect that is a bug that >> could be fixed. >> >> Lastly, since we may encounter situations where network communication >> is not working, we should facilitate access to the console. When I >> was trying to help Timothy change a location radius setting remotely >> by phone and the web browser was timing out, I suggested that he find >> a micro-USB cable so he could connect to the console. But then I >> realized he would not have any application on his laptop that would >> allow him to connect to the console. Developers use "make monitor" in >> the software development cycle, but users won't have that tool. I >> have my own program on the MacBook that I use as an alternative when I >> don't want to induce a reset when I connect. But is there a simple >> program for Windows suitable for non-developer users that can connect >> to the OVMS console? >> >> -- Steve >> _______________________________________________ >> 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 > 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 _______________________________________________ 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 <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
This problem of no newline is related to the somewhat tricky way I implemented alert output being written above the current command input line. I truncate the newline from the last or only line of an alert message so that when it is followed by microrl putting out a new prompt, which is preceded by a newline, we don't get a blank line. I've just committed a fix. The problem was that the terminal monitor discards a newline that does not follow carriage return, and microrl's terminal_newline() function was written to output the same string to go to the next line as it takes for input to indicate the end of a command. We need the input end-of-line to be just a newline character, so that is all that terminal_newline() put out before the prompt. My fix was to change terminal_newline() to output the explicit string "\r\n" rather than the macro ENDL. -- Steve
Still not working for me. I get: “Password:” overwriting “OVMS>” when I type “enable”. First line of output overwrites command prompt whenever I type a command. Pressing ENTER at “OVMS#” prompt seemingly does nothing. Looking through the code, we send \n, not \r\n, in multiple places (for example in ovms_command.cpp enableInsert() function that handles password entry. A ‘find in project’ for \n shows 11,350 results! Simple_monitor works just fine. Regards, Mark.
On 10 Jul 2018, at 4:35 AM, Stephen Casner <casner@acm.org> wrote:
This problem of no newline is related to the somewhat tricky way I implemented alert output being written above the current command input line. I truncate the newline from the last or only line of an alert message so that when it is followed by microrl putting out a new prompt, which is preceded by a newline, we don't get a blank line.
I've just committed a fix. The problem was that the terminal monitor discards a newline that does not follow carriage return, and microrl's terminal_newline() function was written to output the same string to go to the next line as it takes for input to indicate the end of a command. We need the input end-of-line to be just a newline character, so that is all that terminal_newline() put out before the prompt. My fix was to change terminal_newline() to output the explicit string "\r\n" rather than the macro ENDL.
-- Steve _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
I don't see “Password:” overwriting “OVMS>” but I see "Secure mode" overwriting "Password:". Since "Secure mode" is a printf, not a write, I would expect \n to be massaged into \r\n somewhere along the path. It can't be expected that all output strings get \r\n instead of \n. So I have to retract my assertion of having fixed the problem. -- Steve On Tue, 10 Jul 2018, Mark Webb-Johnson wrote:
Still not working for me. I get:
“Password:” overwriting “OVMS>” when I type “enable”. First line of output overwrites command prompt whenever I type a command. Pressing ENTER at “OVMS#” prompt seemingly does nothing.
Looking through the code, we send \n, not \r\n, in multiple places (for example in ovms_command.cpp enableInsert() function that handles password entry. A ‘find in project’ for \n shows 11,350 results! Simple_monitor works just fine.
Regards, Mark.
On 10 Jul 2018, at 4:35 AM, Stephen Casner <casner@acm.org> wrote:
This problem of no newline is related to the somewhat tricky way I implemented alert output being written above the current command input line. I truncate the newline from the last or only line of an alert message so that when it is followed by microrl putting out a new prompt, which is preceded by a newline, we don't get a blank line.
I've just committed a fix. The problem was that the terminal monitor discards a newline that does not follow carriage return, and microrl's terminal_newline() function was written to output the same string to go to the next line as it takes for input to indicate the end of a command. We need the input end-of-line to be just a newline character, so that is all that terminal_newline() put out before the prompt. My fix was to change terminal_newline() to output the explicit string "\r\n" rather than the macro ENDL.
-- Steve _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Maybe timing related? They’ve messed with things to try to avoid the ‘wait for end of line’ delay. Regards, Mark.
On 10 Jul 2018, at 9:30 AM, Stephen Casner <casner@acm.org> wrote:
I don't see “Password:” overwriting “OVMS>” but I see "Secure mode" overwriting "Password:". Since "Secure mode" is a printf, not a write, I would expect \n to be massaged into \r\n somewhere along the path. It can't be expected that all output strings get \r\n instead of \n. So I have to retract my assertion of having fixed the problem.
-- Steve
On Tue, 10 Jul 2018, Mark Webb-Johnson wrote:
Still not working for me. I get:
“Password:” overwriting “OVMS>” when I type “enable”. First line of output overwrites command prompt whenever I type a command. Pressing ENTER at “OVMS#” prompt seemingly does nothing.
Looking through the code, we send \n, not \r\n, in multiple places (for example in ovms_command.cpp enableInsert() function that handles password entry. A ‘find in project’ for \n shows 11,350 results! Simple_monitor works just fine.
Regards, Mark.
On 10 Jul 2018, at 4:35 AM, Stephen Casner <casner@acm.org> wrote:
This problem of no newline is related to the somewhat tricky way I implemented alert output being written above the current command input line. I truncate the newline from the last or only line of an alert message so that when it is followed by microrl putting out a new prompt, which is preceded by a newline, we don't get a blank line.
I've just committed a fix. The problem was that the terminal monitor discards a newline that does not follow carriage return, and microrl's terminal_newline() function was written to output the same string to go to the next line as it takes for input to indicate the end of a command. We need the input end-of-line to be just a newline character, so that is all that terminal_newline() put out before the prompt. My fix was to change terminal_newline() to output the explicit string "\r\n" rather than the macro ENDL.
-- Steve _______________________________________________ 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
I looked at the log for this tools/idf_monitor.py: commit 797340f7f82c29c15c8f59a39856bacbd0a74d53 Author: Roland Dobai <dobai.roland@gmail.com> Date: Mon Jun 18 12:49:04 2018 +0200 idf_monitor: Fix console performance https://github.com/espressif/esp-idf/commit/51e42d8e925a20011bb7105da8cc3194... introduced filtering options which handles the last (unterminated) line with a delay. This introduced poor performance for console applications when the user interacts with the ESP32 device in the same line because there is an artificial delay for each key-press. https://github.com/espressif/esp-idf/commit/bb152030a0057c5a9a048782f917c4fa... decreased the delay but there are still delays for each key-presses. The current fix makes only one delay per line instead of each key-presses. When an unterminated line is detected then no more "delayed" print is used for the given line. Fixes https://github.com/espressif/esp-idf/issues/2054 commit bb152030a0057c5a9a048782f917c4fa9d7b770e Author: Roland Dobai <dobai.roland@gmail.com> Date: Wed Jun 13 07:48:52 2018 +0200 Fix the console performance issue The IDF monitor waits for one second before printing the last unterminated line. This is necessary for the correct filtering. However, this causes poor performance, for example, in the case of the system/console example. This fix reduces the waiting time which improves the response time of the console example and doesn't seem to influence the monitor filter. Closes https://github.com/espressif/esp-idf/issues/2054 Then tried rolling back to the Jun 13th commit (bb152030a0057c5a9a048782f917c4fa9d7b770e), and that solved the problem for me. Issue is the Jun 18th commit (797340f7f82c29c15c8f59a39856bacbd0a74d53), which is: --- a/tools/idf_monitor.py +++ b/tools/idf_monitor.py @@ -393,8 +393,8 @@ class Monitor(object): # default we don't touch it and just wait for the arrival of the rest # of the line. But after some time when we didn't received it we need # to make a decision. - if self._last_line_part != b"": - if self._force_line_print or (finalize_line and self._line_matcher.match(self._last_line_part)): + if finalize_line and self._last_line_part != b"": + if self._line_matcher.match(self._last_line_part): self._force_line_print = True; if self._output_enabled: self.console.write_bytes(self._last_line_part) (that is a reverse patch, so ‘-‘ is new, and ‘+’ is old). It is simple for us to reverse this in our branch, but we’re out of sync with upstream from then onwards. Regards, Mark.
On 10 Jul 2018, at 10:01 AM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Maybe timing related? They’ve messed with things to try to avoid the ‘wait for end of line’ delay.
Regards, Mark.
On 10 Jul 2018, at 9:30 AM, Stephen Casner <casner@acm.org> wrote:
I don't see “Password:” overwriting “OVMS>” but I see "Secure mode" overwriting "Password:". Since "Secure mode" is a printf, not a write, I would expect \n to be massaged into \r\n somewhere along the path. It can't be expected that all output strings get \r\n instead of \n. So I have to retract my assertion of having fixed the problem.
-- Steve
On Tue, 10 Jul 2018, Mark Webb-Johnson wrote:
Still not working for me. I get:
“Password:” overwriting “OVMS>” when I type “enable”. First line of output overwrites command prompt whenever I type a command. Pressing ENTER at “OVMS#” prompt seemingly does nothing.
Looking through the code, we send \n, not \r\n, in multiple places (for example in ovms_command.cpp enableInsert() function that handles password entry. A ‘find in project’ for \n shows 11,350 results! Simple_monitor works just fine.
Regards, Mark.
On 10 Jul 2018, at 4:35 AM, Stephen Casner <casner@acm.org> wrote:
This problem of no newline is related to the somewhat tricky way I implemented alert output being written above the current command input line. I truncate the newline from the last or only line of an alert message so that when it is followed by microrl putting out a new prompt, which is preceded by a newline, we don't get a blank line.
I've just committed a fix. The problem was that the terminal monitor discards a newline that does not follow carriage return, and microrl's terminal_newline() function was written to output the same string to go to the next line as it takes for input to indicate the end of a command. We need the input end-of-line to be just a newline character, so that is all that terminal_newline() put out before the prompt. My fix was to change terminal_newline() to output the explicit string "\r\n" rather than the macro ENDL.
-- Steve _______________________________________________ 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
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Maybe reopen issue 2054 to list our specific example of what fails to see what they say? -- Steve On Fri, 27 Jul 2018, Mark Webb-Johnson wrote:
I looked at the log for this tools/idf_monitor.py:
commit 797340f7f82c29c15c8f59a39856bacbd0a74d53 Author: Roland Dobai <dobai.roland@gmail.com> Date: Mon Jun 18 12:49:04 2018 +0200
idf_monitor: Fix console performance
https://github.com/espressif/esp-idf/commit/51e42d8e925a20011bb7105da8cc3194... introduced filtering options which handles the last (unterminated) line with a delay. This introduced poor performance for console applications when the user interacts with the ESP32 device in the same line because there is an artificial delay for each key-press.
https://github.com/espressif/esp-idf/commit/bb152030a0057c5a9a048782f917c4fa... decreased the delay but there are still delays for each key-presses.
The current fix makes only one delay per line instead of each key-presses. When an unterminated line is detected then no more "delayed" print is used for the given line.
Fixes https://github.com/espressif/esp-idf/issues/2054
commit bb152030a0057c5a9a048782f917c4fa9d7b770e Author: Roland Dobai <dobai.roland@gmail.com> Date: Wed Jun 13 07:48:52 2018 +0200
Fix the console performance issue
The IDF monitor waits for one second before printing the last unterminated line. This is necessary for the correct filtering. However, this causes poor performance, for example, in the case of the system/console example.
This fix reduces the waiting time which improves the response time of the console example and doesn't seem to influence the monitor filter.
Closes https://github.com/espressif/esp-idf/issues/2054
Then tried rolling back to the Jun 13th commit (bb152030a0057c5a9a048782f917c4fa9d7b770e), and that solved the problem for me.
Issue is the Jun 18th commit (797340f7f82c29c15c8f59a39856bacbd0a74d53), which is:
--- a/tools/idf_monitor.py +++ b/tools/idf_monitor.py @@ -393,8 +393,8 @@ class Monitor(object): # default we don't touch it and just wait for the arrival of the rest # of the line. But after some time when we didn't received it we need # to make a decision. - if self._last_line_part != b"": - if self._force_line_print or (finalize_line and self._line_matcher.match(self._last_line_part)): + if finalize_line and self._last_line_part != b"": + if self._line_matcher.match(self._last_line_part): self._force_line_print = True; if self._output_enabled: self.console.write_bytes(self._last_line_part)
(that is a reverse patch, so ‘-‘ is new, and ‘+’ is old).
It is simple for us to reverse this in our branch, but we’re out of sync with upstream from then onwards.
Regards, Mark.
On 10 Jul 2018, at 10:01 AM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Maybe timing related? They’ve messed with things to try to avoid the ‘wait for end of line’ delay.
Regards, Mark.
On 10 Jul 2018, at 9:30 AM, Stephen Casner <casner@acm.org> wrote:
I don't see “Password:” overwriting “OVMS>” but I see "Secure mode" overwriting "Password:". Since "Secure mode" is a printf, not a write, I would expect \n to be massaged into \r\n somewhere along the path. It can't be expected that all output strings get \r\n instead of \n. So I have to retract my assertion of having fixed the problem.
-- Steve
On Tue, 10 Jul 2018, Mark Webb-Johnson wrote:
Still not working for me. I get:
“Password:” overwriting “OVMS>” when I type “enable”. First line of output overwrites command prompt whenever I type a command. Pressing ENTER at “OVMS#” prompt seemingly does nothing.
Looking through the code, we send \n, not \r\n, in multiple places (for example in ovms_command.cpp enableInsert() function that handles password entry. A ‘find in project’ for \n shows 11,350 results! Simple_monitor works just fine.
Regards, Mark.
On 10 Jul 2018, at 4:35 AM, Stephen Casner <casner@acm.org> wrote:
This problem of no newline is related to the somewhat tricky way I implemented alert output being written above the current command input line. I truncate the newline from the last or only line of an alert message so that when it is followed by microrl putting out a new prompt, which is preceded by a newline, we don't get a blank line.
I've just committed a fix. The problem was that the terminal monitor discards a newline that does not follow carriage return, and microrl's terminal_newline() function was written to output the same string to go to the next line as it takes for input to indicate the end of a command. We need the input end-of-line to be just a newline character, so that is all that terminal_newline() put out before the prompt. My fix was to change terminal_newline() to output the explicit string "\r\n" rather than the macro ENDL.
-- Steve _______________________________________________ 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
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Back to the original topic... I have not driven my car for several days, so I have not been paying attention to OVMS. As I was about to connect the charge cable last evening to charge for driving today I found that OVMS had not made contact with the v2 server for four days. This morning I connected the USB cable to find again that server v2 connection attempts were again in a failure loop with the message: mg_connect(api.openvehicles.com:6867) failed: cannot parse address That may not be a bug in Mongoose itself, rather a problem induced by running out of some resource. The think that resource loss occurs when there are repeated connection attempts that fail. So, the first stage of this loss of server v2 connectivity is expressed as repeated connection attempts that fail, consuming the resource, then the second phase is expressed with this mg_connect failure so that the connection is not even attempted. As before, I found that since the client wifi was associated with the home AP and had an address (and was pingable!), the OVMS network routing preferred the wifi and did not try to use the modem. I still think it would be a good idea for the network routing algorithm to be enhanced to back off to use the modem if some number of attempts to connect to the server over wifi have failed. Again I was able to restore operation of both server v2 and http by "wifi mode off" then "wifi mode client". This is shown in the log below including "module memory" and "module tasks". The module status is: Last boot was 883596 second(s) ago Time at boot: 2018-07-18 11:26:55 GMT This is reset #6 since last power cycle Detected boot reason: Crash (12/12) Crash counters: 1 total, 0 early Last crash: Alloca exception on core 0 Registers: PC : 0x40081b9c PS : 0x00060434 A0 : 0x80081d61 A1 : 0x3ffafa60 A2 : 0x00000000 A3 : 0x00000001 A4 : 0x00000050 A5 : 0x00000001 A6 : 0x000000fe A7 : 0x000000a0 A8 : 0x00000081 A9 : 0x00000001 A10 : 0x0000cdcd A11 : 0x00000000 A12 : 0x3f40819c A13 : 0x3f407ebe A14 : 0x000000c8 A15 : 0x00000000 SAR : 0x00000000 EXCCAUSE: 0x00000005 EXCVADDR: 0x00000000 LBEG : 0x40097664 LEND : 0x40097692 LCOUNT : 0xffffffff Backtrace: 0x40081b9c 0x40081d5e 0x400db815 0x401e59a9 0x401e9fcb 0x401e5f31 0x40207f01 0x40208d00 0x40208d1f 0x4020906c 0x4020938f 0x4020998a 0x4020de03 0x4020dfd9 0x40205343 Version: 3.1.008/ota_0/main (build idf v3.1-dev-986-g1a1a544a Jun 26 2018 09:30:21) Running partition: ota_0 Boot partition: ota_0 Firmware: 3.1.008/ota_0/main (build idf v3.1-dev-986-g1a1a544a Jun 26 2018 09:30:21) -- Steve OVMS> ena Password: E (883184595) ovms-server-v2: mg_connect(api.openvehicles.com:6867) failed: cannot parse address| E (883184595) ovms-server-v2: Status: Error: Connection failed I (883191605) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 I (883191605) ovms-server-v2: Status: Connecting... OVMS# E (883205565) ovms-server-v2: mg_connect(api.openvehicles.com:6867) failed: cannot parse address| E (883205565) ovms-server-v2: Status: Error: Connection failed I (883205565) housekeeping: 2018-07-28 16:46:59 GMT (RAM: 8b=113788-152720 32b=28252) I (883211605) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 I (883211605) ovms-server-v2: Status: Connecting... E (883225515) ovms-server-v2: mg_connect(api.openvehicles.com:6867) failed: cannot parse address| E (883225515) ovms-server-v2: Status: Error: Connection failed I (883231605) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 I (883231605) ovms-server-v2: Status: Connecting... OVMS# mo m Free 8-bit 152728/281376, 32-bit 644/28920, SPIRAM 4073124/4194252 --Task-- Total DRAM D/IRAM IRAM SPIRAM +/- DRAM D/IRAM IRAM SPIRAM main* 8412 0 0 7636 +8412 +0 +0 +7636 no task* 5348 0 0 0 +5348 +0 +0 +0 3FFDBC58* 176 0 0 0 +176 +0 +0 +0 3FFD9F20* 352 0 0 0 +352 +0 +0 +0 esp_timer 23856 0 644 44448 +23856 +0 +644 +44448 OVMS Events 73408 0 0 21488 +73408 +0 +0 +21488 ipc0 7776 0 0 0 +7776 +0 +0 +0 ipc1 12 0 0 0 +12 +0 +0 +0 Tmr Svc 88 0 0 132 +88 +0 +0 +132 tiT 928 0 0 6164 +928 +0 +0 +6164 OVMS SIMCOM 0 0 0 3896 +0 +0 +0 +3896 wifi 1636 0 0 3764 +1636 +0 +0 +3764 OVMS Vehicle 200 0 0 688 +200 +0 +0 +688 OVMS Console 0 0 27488 20 +0 +0 +27488 +20 OVMS NetMan 308 0 0 148 +308 +0 +0 +148 mdns 104 0 0 4 +104 +0 +0 +4 E (883245475) ovms-server-v2: mg_connect(api.openvehicles.com:6867) failed: cannot parse address| E (883245475) ovms-server-v2: Status: Error: Connection failed I (883251605) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 I (883251605) ovms-server-v2: Status: Connecting... OVMS# mo t Number of Tasks = 16 Stack: Now Max Total Heap 32-bit SPIRAM C# PRI 3FFAFB48 1 Blk esp_timer 388 676 4096 23856 644 44448 0 22 3FFBDE68 2 Blk eventTask 436 1876 4608 0 0 0 0 20 3FFC0388 3 Blk OVMS Events 1476 3316 8192 73408 0 21488 1 23 3FFC1850 4 Blk OVMS CanRx 428 588 1024 0 0 0 0 10 3FFC2234 5 Blk ipc0 400 560 1024 7776 0 0 0 24 3FFC2834 6 Blk ipc1 400 496 1024 12 0 0 1 24 3FFC465C 9 Rdy IDLE 376 552 1024 0 0 0 0 0 3FFC4BF0 10 Rdy IDLE 380 556 1024 0 0 0 1 0 3FFC5984 11 Blk Tmr Svc 352 2032 3072 88 0 12 0 1 3FFC2C24 16 Blk tiT 484 2452 3072 928 0 6164 * 18 3FFCAC78 17 Blk OVMS SIMCOM 452 2324 4096 0 0 3896 1 5 3FFCC664 18 Blk wifi 432 2432 4096 1636 0 3764 0 23 3FFD06D8 19 Blk OVMS Vehicle 452 3284 6144 200 0 688 1 10 3FFD37A0 20 Rdy OVMS Console 748 2444 6144 0 27488 20 1 5 3FFD5934 21 Blk OVMS NetMan 736 3424 8192 308 0 148 1 23 3FFD6EE4 22 Blk mdns 464 1632 4096 104 0 4 0 1 E (883265415) ovms-server-v2: mg_connect(api.openvehicles.com:6867) failed: cannot parse address| E (883265415) ovms-server-v2: Status: Error: Connection failed I (883271605) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 I (883271605) ovms-server-v2: Status: Connecting... OVMS# simcom status Network Registration: RegisteredRoaming Provider: AT&T Hologram Signal: -99 dBm State: NetMode PPP: Connected on channel: #2 GPS: Not connected E (883285325) ovms-server-v2: mg_connect(api.openvehicles.com:6867) failed: cannot parse address| E (883285325) ovms-server-v2: Status: Error: Connection failed OVMS# network Interface#3: pp3 (ifup=1 linkup=1) IPv4: 10.170.41.247/255.255.255.255 gateway 10.64.64.64 Interface#2: ap2 (ifup=1 linkup=1) IPv4: 192.168.4.1/255.255.255.0 gateway 192.168.4.1 Interface#1: st1 (ifup=1 linkup=1) IPv4: 192.168.1.82/255.255.255.0 gateway 192.168.1.254 DNS: 8.8.8.8 8.8.4.4 Default Interface: st1 (192.168.1.82/255.255.255.0 gateway 192.168.1.254) I (883291605) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 I (883291605) ovms-server-v2: Status: Connecting... E (883305265) ovms-server-v2: mg_connect(api.openvehicles.com:6867) failed: cannot parse address| E (883305265) ovms-server-v2: Status: Error: Connection failed I (883311605) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 I (883311605) ovms-server-v2: Status: Connecting... E (883325225) ovms-server-v2: mg_connect(api.openvehicles.com:6867) failed: cannot parse address| E (883325225) ovms-server-v2: Status: Error: Connection failed I (883331605) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 I (883331605) ovms-server-v2: Status: Connecting... E (883345185) ovms-server-v2: mg_connect(api.openvehicles.com:6867) failed: cannot parse address| E (883345185) ovms-server-v2: Status: Error: Connection failed I (883351605) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 I (883351605) ovms-server-v2: Status: Connecting... E (883365155) ovms-server-v2: mg_connect(api.openvehicles.com:6867) failed: cannot parse address| E (883365155) ovms-server-v2: Status: Error: Connection failed I (883371605) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 I (883371605) ovms-server-v2: Status: Connecting... E (883385115) ovms-server-v2: mg_connect(api.openvehicles.com:6867) failed: cannot parse address| E (883385115) ovms-server-v2: Status: Error: Connection failed I (883391605) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 I (883391605) ovms-server-v2: Status: Connecting... E (883405005) ovms-server-v2: mg_connect(api.openvehicles.com:6867) failed: cannot parse address| E (883405005) ovms-server-v2: Status: Error: Connection failed I (883411605) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 I (883411605) ovms-server-v2: Status: Connecting... E (883424925) ovms-server-v2: mg_connect(api.openvehicles.com:6867) failed: cannot parse address| E (883424925) ovms-server-v2: Status: Error: Connection failed I (883431605) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 I (883431605) ovms-server-v2: Status: Connecting... E (883444885) ovms-server-v2: mg_connect(api.openvehicles.com:6867) failed: cannot parse address| E (883444885) ovms-server-v2: Status: Error: Connection failed I (883451605) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 I (883451605) ovms-server-v2: Status: Connecting... OVMS# wifi mode off Stopping wifi station... I (883453745) esp32wifi: Stopping WIFI station I (883453745) wifi: state: run -> init (0) I (883453745) wifi: pm stop, total sleep time: 430473605972 us / 521077537519 us I (883453745) wifi: n:1 0, o:1 1, ap:1 1, sta:1 0, prof:1 I (883453755) wifi: flush txq I (883453755) wifi: stop sw txq I (883453755) wifi: lmac stop hw txq E (883464855) ovms-server-v2: mg_connect(api.openvehicles.com:6867) failed: cannot parse address| E (883464855) ovms-server-v2: Status: Error: Connection failed I (883464855) netmanager: Interface priority is pp3 (10.170.41.247/255.255.255.255 gateway 10.64.64.64) I (883464855) netmanager: Set DNS#0 8.8.8.8 I (883464855) netmanager: Set DNS#1 8.8.4.4 I (883464855) netmanager: WIFI client down (with MODEM up): reconfigured for MODEM priority I (883464855) netmanager: Interface priority is pp3 (10.170.41.247/255.255.255.255 gateway 10.64.64.64) I (883464855) netmanager: Set DNS#0 8.8.8.8 I (883464855) netmanager: Set DNS#1 8.8.4.4 I (883464855) esp32wifi: STA disconnected with reason 8 I (883464855) netmanager: Interface priority is pp3 (10.170.41.247/255.255.255.255 gateway 10.64.64.64) I (883464855) netmanager: Set DNS#0 8.8.8.8 I (883464855) netmanager: Set DNS#1 8.8.4.4 I (883464855) netmanager: Interface priority is pp3 (10.170.41.247/255.255.255.255 gateway 10.64.64.64) I (883464855) netmanager: Set DNS#0 8.8.8.8 I (883464865) netmanager: Set DNS#1 8.8.4.4 I (883464865) netmanager: WIFI access point is down I (883464865) esp32wifi: AP stopped I (883464865) time: Network was reconfigured: restarting SNTP client I (883464865) ovms-server-v2: Network was reconfigured: disconnect, and reconnect in 10 seconds I (883464865) ovms-server-v2: Status: Network was reconfigured: disconnect, and reconnect in 10 seconds I (883474605) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 I (883474605) ovms-server-v2: Status: Connecting... I (883475575) ovms-server-v2: Connection successful I (883475575) ovms-server-v2: Status: Logging in... I (883475585) ovms-server-v2: Sending server login: MP-C 0 ze4eZZFUPu2d3Lo+H4lvag eqhEPTdnHHCmf7oKGLmJgw== US33 I (883476175) ovms-server-v2: Got server response: MP-S 0 qTQRfCoaBEV4v3jOSboT5W +AwXY+/c0F1Fv3VQsf8c0g== I (883476175) ovms-server-v2: Server token is qTQRfCoaBEV4v3jOSboT5W and digest is +AwXY+/c0F1Fv3VQsf8c0g== I (883476175) ovms-server-v2: Status: Server authentication ok. Now priming crypto. I (883476175) ovms-server-v2: Shared secret key is qTQRfCoaBEV4v3jOSboT5Wze4eZZFUPu2d3Lo+H4lvag (44 bytes) I (883476175) ovms-server-v2: Status: OVMS V2 login successful, and crypto channel established I (883476195) ovms-server-v2: Incoming Msg: MP-0 Z0 I (883476605) ovms-server-v2: Send MP-0 S86.0,M,65535,127,stopped,standard,205,198,32,0,0,2100,2,21,0,0,0,0,184.04,32,0,0,0,-1,0,0,0,0,0,0,0,0.00,0.00,82 I (883476605) ovms-server-v2: Send MP-0 D69,0,5,29,35,28,300,515969,0,643274,22,0,1,1,11.37,0,12.6,0,29,0 I (883476605) ovms-server-v2: Send MP-0 L37.346310,-122.037224,15,48,1,1,0,0,0.0,0,0 I (883476615) ovms-server-v2: Send MP-0 F3.1.008/ota_0/main (build idf v3.1-dev-986-g1a1a544a Jun 26 2018 09:30:21),5YJRE11B181000033,7,1,TR1N,AT&T Hologram I (883476615) ovms-server-v2: Send MP-0 PAStandard - Charge Stopped|SOC: 86.0%|Ideal range: 207Km|Est. range: 199Km|ODO: 51596.9Km|CAC: 184.0Ah|SOH: 82%| I (883476615) ovms-server-v2: Send MP-0 PIStandard - Charging|245.0V/3.0A|Full: 247 mins|SOC: 53.0%|Ideal range: 125Km|Est. range: 121Km|ODO: 51596.9Km|CAC: 184.0Ah|SOH: 82%| I (883476615) ovms-server-v2: Send MP-0 PIStandard - Charge Done|SOC: 86.0%|Ideal range: 209Km|Est. range: 201Km|ODO: 51596.9Km|CAC: 184.0Ah|SOH: 82%| I (883500605) housekeeping: 2018-07-28 16:51:55 GMT (RAM: 8b=113788-152748 32b=644) I (883512195) event: station ip lost OVMS# wifi mode client Revelstoke Starting WIFI as a client to Revelstoke... I (883524865) wifi: mode : sta (30:ae:a4:43:9c:28) I (883527275) wifi: n:1 0, o:1 0, ap:255 255, sta:1 0, prof:1 I (883527965) wifi: state: init -> auth (b0) I (883527975) wifi: state: auth -> assoc (0) I (883527975) wifi: state: assoc -> run (10) I (883528015) wifi: connected with Revelstoke, channel 1 I (883528015) wifi: pm start, type: 1 I (883529095) event: sta ip: 192.168.1.82, mask: 255.255.255.0, gw: 192.168.1.254 I (883529095) netmanager: Interface priority is st4 (192.168.1.82/255.255.255.0 gateway 192.168.1.254) I (883529095) netmanager: Set DNS#0 8.8.8.8 I (883529095) netmanager: Set DNS#1 8.8.4.4 I (883529095) netmanager: WIFI client up (with MODEM up): reconfigured for WIFI client priority I (883529095) esp32wifi: STA got IP with SSID: Revelstoke, MAC: 30:ae:a4:43:9c:28, IP: 192.168.1.82, mask: 255.255.255.0, gw: 192.168.1.254 I (883529095) time: Network was reconfigured: restarting SNTP client I (883529095) ovms-server-v2: Network was reconfigured: disconnect, and reconnect in 10 seconds I (883529095) ovms-server-v2: Status: Network was reconfigured: disconnect, and reconnect in 10 seconds I (883529335) ovms-server-v2: Status: Disconnected I (883548605) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 I (883548605) ovms-server-v2: Status: Connecting... I (883548795) ovms-server-v2: Connection successful I (883548795) ovms-server-v2: Status: Logging in... I (883548795) ovms-server-v2: Sending server login: MP-C 0 ckcTJt/ZXBlyxcklQULIA0 MuBQZZ9X5KpG0ofDjULWsw== US33 I (883549025) ovms-server-v2: Got server response: MP-S 0 6+7upY3iY6hpYdQPk2JihK RylaYqE9Yh/nZ65FG2aSoQ== I (883549025) ovms-server-v2: Server token is 6+7upY3iY6hpYdQPk2JihK and digest is RylaYqE9Yh/nZ65FG2aSoQ== I (883549025) ovms-server-v2: Status: Server authentication ok. Now priming crypto. I (883549025) ovms-server-v2: Shared secret key is 6+7upY3iY6hpYdQPk2JihKckcTJt/ZXBlyxcklQULIA0 (44 bytes) I (883549025) ovms-server-v2: Status: OVMS V2 login successful, and crypto channel established I (883549035) ovms-server-v2: Incoming Msg: MP-0 Z0 OVMS# net sta Interface#4: st4 (ifup=1 linkup=1) IPv4: 192.168.1.82/255.255.255.0 gateway 192.168.1.254 Interface#3: pp3 (ifup=1 linkup=1) IPv4: 10.170.41.247/255.255.255.255 gateway 10.64.64.64 DNS: 8.8.8.8 8.8.4.4 Default Interface: st4 (192.168.1.82/255.255.255.0 gateway 192.168.1.254) I (883585175) webserver: HTTP GET /status I (883596435) webserver: HTTP POST /status I (883596445) webserver: HandleLogin: 'admin' logged in, sid da66bbbc0ea1e7e1 I (883596645) webserver: HTTP GET /menu I (883596655) webserver: HTTP GET /status
On Sun, 29 Jul 2018, Greg D. wrote:
Hi Steve,
Interesting...? I just got a very cryptic "event" from my car:? Not charging SOC:-
I believe it is expected to get that event when OVMS boots while the car is idle since "not charging" is an accurate description of the state. I received a "not charging" notification on Sunday as well, coincidentally as we were approaching home in our RAV4-EV. This resulted from another "Alloca exception on core 0" crash and reboot of OVMS: Last boot was 170458 second(s) ago Time at boot: 2018-07-29 21:41:32 GMT This is reset #7 since last power cycle Detected boot reason: Crash (8/14) Crash counters: 2 total, 0 early Last crash: Alloca exception on core 0 This is not the same time as yours (2018-07-29 17:55:36 PDT) so it does not appear that the crashes are synchronized by some external event. Then today I looked at the iPhone app and saw that my OVMS had not communicated with the v2 server for 15 hours. So I connected to the USB cable again and found that the wifi was again in trouble. This time there were many instances of a new error message from wifi that I had not seen before, as shown in the log below. Again I was able to restore operation of both server v2 and http by "wifi mode off" then "wifi mode client". -- Steve E (170324792) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170325752) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170328632) ovms-server-v2: mg_connect(api.openvehicles.com:6867) failed: cannot parse address| E (170328632) ovms-server-v2: Status: Error: Connection failed E (170329542) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170333742) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170333742) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170333742) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170333752) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170333752) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170333752) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170333752) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170333752) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170333752) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170333762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170333762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170335592) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb I (170335672) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 I (170335672) ovms-server-v2: Status: Connecting... E (170335672) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170336312) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170337272) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170338232) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170339192) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170340152) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170341112) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170342072) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170343032) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb OVMS> ena Password: E (170343992) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170344702) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170345912) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170346232) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170346872) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170347262) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb OVMS# E (170347832) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170348792) ovms-server-v2: mg_connect(api.openvehicles.com:6867) failed: cannot parse address| E (170348792) ovms-server-v2: Status: Error: Connection failed E (170348792) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170349752) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170350832) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353802) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353802) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353802) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353802) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353812) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353812) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353812) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353812) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353812) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353812) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353812) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353822) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353822) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353822) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353822) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353832) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353832) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353832) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353832) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb I (170355672) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 I (170355672) ovms-server-v2: Status: Connecting... E (170355672) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170356472) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170357432) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170358392) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170359352) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170359842) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170360862) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170362232) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170362922) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170363192) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170364152) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170365112) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170366072) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170368952) ovms-server-v2: mg_connect(api.openvehicles.com:6867) failed: cannot parse address| E (170368952) ovms-server-v2: Status: Error: Connection failed E (170372022) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373782) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373782) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373782) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373782) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373782) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373782) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170374992) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170375672) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170375672) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb I (170375672) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 I (170375672) ovms-server-v2: Status: Connecting... E (170376632) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170377592) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170378062) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170378552) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170379512) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170380472) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170381432) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170382392) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb OVMS# wifi mode off Stopping wifi station... I (170383222) esp32wifi: Stopping WIFI station I (170383222) wifi: state: run -> init (0) I (170383222) wifi: pm stop, total sleep time: 47593209375 us / 59459320714 us I (170383222) wifi: n:1 0, o:1 1, ap:1 1, sta:1 0, prof:1 I (170383232) wifi: flush txq I (170383232) wifi: stop sw txq I (170383232) wifi: lmac stop hw txq E (170389112) ovms-server-v2: mg_connect(api.openvehicles.com:6867) failed: cannot parse address| E (170389112) ovms-server-v2: Status: Error: Connection failed I (170389112) netmanager: Interface priority is pp3 (10.170.41.247/255.255.255.255 gateway 10.64.64.64) I (170389112) netmanager: Set DNS#0 8.8.8.8 I (170389112) netmanager: Set DNS#1 8.8.4.4 I (170389112) netmanager: WIFI client down (with MODEM up): reconfigured for MODEM priority I (170389122) netmanager: Interface priority is pp3 (10.170.41.247/255.255.255.255 gateway 10.64.64.64) I (170389122) netmanager: Set DNS#0 8.8.8.8 I (170389122) netmanager: Set DNS#1 8.8.4.4 I (170389122) esp32wifi: STA disconnected with reason 8 W (170389122) netmanager: CleanupConnections: can't get AP station list I (170389122) netmanager: Interface priority is pp3 (10.170.41.247/255.255.255.255 gateway 10.64.64.64) I (170389122) netmanager: Set DNS#0 8.8.8.8 I (170389122) netmanager: Set DNS#1 8.8.4.4 I (170389132) netmanager: Interface priority is pp3 (10.170.41.247/255.255.255.255 gateway 10.64.64.64) I (170389132) netmanager: Set DNS#0 8.8.8.8 I (170389132) netmanager: Set DNS#1 8.8.4.4 I (170389132) netmanager: WIFI access point is down I (170389132) esp32wifi: AP stopped I (170389132) netmanager: CleanupConnections: closing conn 3f81dbbc: interface/link down I (170389142) netmanager: CleanupConnections: closing conn 3f81dbbc: interface/link down I (170389142) time: Network was reconfigured: restarting SNTP client I (170389142) ovms-server-v2: Network was reconfigured: disconnect, and reconnect in 10 seconds I (170389142) ovms-server-v2: Status: Network was reconfigured: disconnect, and reconnect in 10 seconds I (170389152) netmanager: CleanupConnections: closing conn 3f81dbbc: interface/link down I (170398672) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 I (170398672) ovms-server-v2: Status: Connecting... I (170401312) housekeeping: 2018-07-31 21:01:32 GMT (RAM: 8b=113788-152956 32b=28252) I (170402032) ovms-server-v2: Connection successful I (170402032) ovms-server-v2: Status: Logging in... I (170402032) ovms-server-v2: Sending server login: MP-C 0 xR/s7da9YTwJ+uKH0C2zRl VXtWmVfsQQjJCe4+AwK74w== US33 I (170402852) ovms-server-v2: Got server response: MP-S 0 1uDt9VTVDl5jzvSqsIwmtN isXmd3Gy2AcrvhQVrX3LAA== I (170402852) ovms-server-v2: Server token is 1uDt9VTVDl5jzvSqsIwmtN and digest is isXmd3Gy2AcrvhQVrX3LAA== I (170402852) ovms-server-v2: Status: Server authentication ok. Now priming crypto. I (170402852) ovms-server-v2: Shared secret key is 1uDt9VTVDl5jzvSqsIwmtNxR/s7da9YTwJ+uKH0C2zRl (44 bytes) I (170402852) ovms-server-v2: Status: OVMS V2 login successful, and crypto channel established I (170402872) ovms-server-v2: Incoming Msg: MP-0 Z0 I (170403672) ovms-server-v2: Send MP-0 S70.0,M,65535,127,stopped,standard,166,146,32,0,0,2100,7,21,0,0,0,0,0.00,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,0.00,0 I (170403672) ovms-server-v2: Send MP-0 D65,0,5,23,23,24,587,516256,0,170403,24,0,1,1,11.63,0,12.6,0,23,0 I (170403672) ovms-server-v2: Send MP-0 L37.346340,-122.037308,206,64,1,1,0,0,0.0,0,0 I (170403682) ovms-server-v2: Send MP-0 F3.1.008/ota_0/main (build idf v3.1-dev-986-g1a1a544a Jun 26 2018 09:30:21),5YJRE11B181000033,7,1,TR1N,AT&T Hologram OVMS# wifi mode client Revelstoke Starting WIFI as a client to Revelstoke... I (170432062) wifi: mode : sta (30:ae:a4:43:9c:28) I (170434462) wifi: n:1 0, o:1 0, ap:255 255, sta:1 0, prof:1 I (170435152) wifi: state: init -> auth (b0) I (170435162) wifi: state: auth -> assoc (0) I (170435162) wifi: state: assoc -> run (10) I (170435202) wifi: connected with Revelstoke, channel 1 I (170435202) wifi: pm start, type: 1 I (170438872) event: sta ip: 192.168.1.82, mask: 255.255.255.0, gw: 192.168.1.254 I (170438872) netmanager: Interface priority is st4 (192.168.1.82/255.255.255.0 gateway 192.168.1.254) I (170438872) netmanager: Set DNS#0 8.8.8.8 I (170438872) netmanager: Set DNS#1 8.8.4.4 I (170438872) netmanager: WIFI client up (with MODEM up): reconfigured for WIFI client priority I (170438872) esp32wifi: STA got IP with SSID: Revelstoke, MAC: 30:ae:a4:43:9c:28, IP: 192.168.1.82, mask: 255.255.255.0, gw: 192.168.1.254 I (170438882) time: Network was reconfigured: restarting SNTP client I (170438882) ovms-server-v2: Network was reconfigured: disconnect, and reconnect in 10 seconds I (170438882) ovms-server-v2: Status: Network was reconfigured: disconnect, and reconnect in 10 seconds I (170439082) ovms-server-v2: Status: Disconnected I (170451362) webserver: HTTP GET / I (170451572) webserver: HTTP GET /apple-touch-icon.png I (170451842) webserver: HTTP GET /status I (170458672) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 I (170458672) ovms-server-v2: Status: Connecting... I (170458902) ovms-server-v2: Connection successful I (170458902) ovms-server-v2: Status: Logging in... I (170458902) ovms-server-v2: Sending server login: MP-C 0 zSgUQypXKd9tYDq7XuHf8m Raby/geQppSUPG5l9NRztw== US33 I (170458922) webserver: HTTP POST /status I (170458922) webserver: HandleLogin: 'admin' logged in, sid 6ea0f4c3207e3328 I (170459342) ovms-server-v2: Got server response: MP-S 0 ooMhIGTk/0ZEvxVpwoHZ4d 4d+RTkaUZ1onzxLyxVwYEQ== I (170459342) ovms-server-v2: Server token is ooMhIGTk/0ZEvxVpwoHZ4d and digest is 4d+RTkaUZ1onzxLyxVwYEQ== I (170459342) ovms-server-v2: Status: Server authentication ok. Now priming crypto. I (170459342) ovms-server-v2: Shared secret key is ooMhIGTk/0ZEvxVpwoHZ4dzSgUQypXKd9tYDq7XuHf8m (44 bytes) I (170459342) ovms-server-v2: Status: OVMS V2 login successful, and crypto channel established I (170459352) ovms-server-v2: Incoming Msg: MP-0 Z0 I (170459352) webserver: HTTP GET /status I (170459392) webserver: HTTP GET /menu
Hi Steve, Ok, so, still a puzzle as to why the crashes. Fortunately, I've only had the one. I've not had any trouble losing wifi connectivity, either when the car's been sitting in the garage for a few days, or coming and going on errands (so, transitioning to cell and back). Prior to this, I think the last boot was the upgrade to 3.1.008. Oh, perhaps the car's recent near death experience (*) cycled power? Not sure, but probably did. Anyway, in general, I've not had trouble with connectivity in a long time. The only thing I've noticed is that sometimes I have a rather long delay between an event (e.g. when the car starts charging) and having it show up on my cell phone. Usually I get it immediately, but some time it's delayed several minutes, and once in a while it never shows up (e.g. charging started but never finished). It might simply be packet loss on my Internet connection (it's fast, but sometimes leaky), not related to wi-fi. I get delays at times on the PC going to websites too. {shrug} Greg (*) For some reason, the VMS lost connectivity to the VDS, and the car locked up. Fortunately it was in the garage, and the windows were rolled down since the door opening switches stopped working too. Had to unplug the cables to the VMS under the dash and plug them back in to force a reboot. {phew!} Stephen Casner wrote:
On Sun, 29 Jul 2018, Greg D. wrote:
Hi Steve,
Interesting...? I just got a very cryptic "event" from my car:? Not charging SOC:- I believe it is expected to get that event when OVMS boots while the car is idle since "not charging" is an accurate description of the state.
I received a "not charging" notification on Sunday as well, coincidentally as we were approaching home in our RAV4-EV. This resulted from another "Alloca exception on core 0" crash and reboot of OVMS:
Last boot was 170458 second(s) ago Time at boot: 2018-07-29 21:41:32 GMT This is reset #7 since last power cycle Detected boot reason: Crash (8/14) Crash counters: 2 total, 0 early
Last crash: Alloca exception on core 0
This is not the same time as yours (2018-07-29 17:55:36 PDT) so it does not appear that the crashes are synchronized by some external event.
Then today I looked at the iPhone app and saw that my OVMS had not communicated with the v2 server for 15 hours. So I connected to the USB cable again and found that the wifi was again in trouble. This time there were many instances of a new error message from wifi that I had not seen before, as shown in the log below.
Again I was able to restore operation of both server v2 and http by "wifi mode off" then "wifi mode client".
-- Steve
E (170324792) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170325752) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170328632) ovms-server-v2: mg_connect(api.openvehicles.com:6867) failed: cannot parse address| E (170328632) ovms-server-v2: Status: Error: Connection failed E (170329542) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170333742) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170333742) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170333742) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170333752) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170333752) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170333752) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170333752) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170333752) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170333752) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170333762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170333762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170335592) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb I (170335672) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 I (170335672) ovms-server-v2: Status: Connecting... E (170335672) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170336312) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170337272) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170338232) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170339192) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170340152) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170341112) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170342072) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170343032) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb OVMS> ena Password: E (170343992) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170344702) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170345912) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170346232) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170346872) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170347262) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb OVMS# E (170347832) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170348792) ovms-server-v2: mg_connect(api.openvehicles.com:6867) failed: cannot parse address| E (170348792) ovms-server-v2: Status: Error: Connection failed E (170348792) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170349752) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170350832) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353802) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353802) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353802) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353802) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353812) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353812) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353812) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353812) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353812) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353812) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353812) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353822) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353822) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353822) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353822) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353832) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353832) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353832) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353832) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb I (170355672) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 I (170355672) ovms-server-v2: Status: Connecting... E (170355672) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170356472) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170357432) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170358392) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170359352) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170359842) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170360862) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170362232) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170362922) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170363192) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170364152) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170365112) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170366072) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170368952) ovms-server-v2: mg_connect(api.openvehicles.com:6867) failed: cannot parse address| E (170368952) ovms-server-v2: Status: Error: Connection failed E (170372022) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373782) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373782) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373782) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373782) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373782) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373782) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170374992) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170375672) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170375672) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb I (170375672) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 I (170375672) ovms-server-v2: Status: Connecting... E (170376632) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170377592) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170378062) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170378552) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170379512) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170380472) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170381432) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170382392) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb OVMS# wifi mode off Stopping wifi station... I (170383222) esp32wifi: Stopping WIFI station I (170383222) wifi: state: run -> init (0) I (170383222) wifi: pm stop, total sleep time: 47593209375 us / 59459320714 us I (170383222) wifi: n:1 0, o:1 1, ap:1 1, sta:1 0, prof:1 I (170383232) wifi: flush txq I (170383232) wifi: stop sw txq I (170383232) wifi: lmac stop hw txq E (170389112) ovms-server-v2: mg_connect(api.openvehicles.com:6867) failed: cannot parse address| E (170389112) ovms-server-v2: Status: Error: Connection failed I (170389112) netmanager: Interface priority is pp3 (10.170.41.247/255.255.255.255 gateway 10.64.64.64) I (170389112) netmanager: Set DNS#0 8.8.8.8 I (170389112) netmanager: Set DNS#1 8.8.4.4 I (170389112) netmanager: WIFI client down (with MODEM up): reconfigured for MODEM priority I (170389122) netmanager: Interface priority is pp3 (10.170.41.247/255.255.255.255 gateway 10.64.64.64) I (170389122) netmanager: Set DNS#0 8.8.8.8 I (170389122) netmanager: Set DNS#1 8.8.4.4 I (170389122) esp32wifi: STA disconnected with reason 8 W (170389122) netmanager: CleanupConnections: can't get AP station list I (170389122) netmanager: Interface priority is pp3 (10.170.41.247/255.255.255.255 gateway 10.64.64.64) I (170389122) netmanager: Set DNS#0 8.8.8.8 I (170389122) netmanager: Set DNS#1 8.8.4.4 I (170389132) netmanager: Interface priority is pp3 (10.170.41.247/255.255.255.255 gateway 10.64.64.64) I (170389132) netmanager: Set DNS#0 8.8.8.8 I (170389132) netmanager: Set DNS#1 8.8.4.4 I (170389132) netmanager: WIFI access point is down I (170389132) esp32wifi: AP stopped I (170389132) netmanager: CleanupConnections: closing conn 3f81dbbc: interface/link down I (170389142) netmanager: CleanupConnections: closing conn 3f81dbbc: interface/link down I (170389142) time: Network was reconfigured: restarting SNTP client I (170389142) ovms-server-v2: Network was reconfigured: disconnect, and reconnect in 10 seconds I (170389142) ovms-server-v2: Status: Network was reconfigured: disconnect, and reconnect in 10 seconds I (170389152) netmanager: CleanupConnections: closing conn 3f81dbbc: interface/link down I (170398672) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 I (170398672) ovms-server-v2: Status: Connecting... I (170401312) housekeeping: 2018-07-31 21:01:32 GMT (RAM: 8b=113788-152956 32b=28252) I (170402032) ovms-server-v2: Connection successful I (170402032) ovms-server-v2: Status: Logging in... I (170402032) ovms-server-v2: Sending server login: MP-C 0 xR/s7da9YTwJ+uKH0C2zRl VXtWmVfsQQjJCe4+AwK74w== US33 I (170402852) ovms-server-v2: Got server response: MP-S 0 1uDt9VTVDl5jzvSqsIwmtN isXmd3Gy2AcrvhQVrX3LAA== I (170402852) ovms-server-v2: Server token is 1uDt9VTVDl5jzvSqsIwmtN and digest is isXmd3Gy2AcrvhQVrX3LAA== I (170402852) ovms-server-v2: Status: Server authentication ok. Now priming crypto. I (170402852) ovms-server-v2: Shared secret key is 1uDt9VTVDl5jzvSqsIwmtNxR/s7da9YTwJ+uKH0C2zRl (44 bytes) I (170402852) ovms-server-v2: Status: OVMS V2 login successful, and crypto channel established I (170402872) ovms-server-v2: Incoming Msg: MP-0 Z0 I (170403672) ovms-server-v2: Send MP-0 S70.0,M,65535,127,stopped,standard,166,146,32,0,0,2100,7,21,0,0,0,0,0.00,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,0.00,0 I (170403672) ovms-server-v2: Send MP-0 D65,0,5,23,23,24,587,516256,0,170403,24,0,1,1,11.63,0,12.6,0,23,0 I (170403672) ovms-server-v2: Send MP-0 L37.346340,-122.037308,206,64,1,1,0,0,0.0,0,0 I (170403682) ovms-server-v2: Send MP-0 F3.1.008/ota_0/main (build idf v3.1-dev-986-g1a1a544a Jun 26 2018 09:30:21),5YJRE11B181000033,7,1,TR1N,AT&T Hologram OVMS# wifi mode client Revelstoke Starting WIFI as a client to Revelstoke... I (170432062) wifi: mode : sta (30:ae:a4:43:9c:28) I (170434462) wifi: n:1 0, o:1 0, ap:255 255, sta:1 0, prof:1 I (170435152) wifi: state: init -> auth (b0) I (170435162) wifi: state: auth -> assoc (0) I (170435162) wifi: state: assoc -> run (10) I (170435202) wifi: connected with Revelstoke, channel 1 I (170435202) wifi: pm start, type: 1 I (170438872) event: sta ip: 192.168.1.82, mask: 255.255.255.0, gw: 192.168.1.254 I (170438872) netmanager: Interface priority is st4 (192.168.1.82/255.255.255.0 gateway 192.168.1.254) I (170438872) netmanager: Set DNS#0 8.8.8.8 I (170438872) netmanager: Set DNS#1 8.8.4.4 I (170438872) netmanager: WIFI client up (with MODEM up): reconfigured for WIFI client priority I (170438872) esp32wifi: STA got IP with SSID: Revelstoke, MAC: 30:ae:a4:43:9c:28, IP: 192.168.1.82, mask: 255.255.255.0, gw: 192.168.1.254 I (170438882) time: Network was reconfigured: restarting SNTP client I (170438882) ovms-server-v2: Network was reconfigured: disconnect, and reconnect in 10 seconds I (170438882) ovms-server-v2: Status: Network was reconfigured: disconnect, and reconnect in 10 seconds I (170439082) ovms-server-v2: Status: Disconnected I (170451362) webserver: HTTP GET / I (170451572) webserver: HTTP GET /apple-touch-icon.png I (170451842) webserver: HTTP GET /status I (170458672) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 I (170458672) ovms-server-v2: Status: Connecting... I (170458902) ovms-server-v2: Connection successful I (170458902) ovms-server-v2: Status: Logging in... I (170458902) ovms-server-v2: Sending server login: MP-C 0 zSgUQypXKd9tYDq7XuHf8m Raby/geQppSUPG5l9NRztw== US33 I (170458922) webserver: HTTP POST /status I (170458922) webserver: HandleLogin: 'admin' logged in, sid 6ea0f4c3207e3328 I (170459342) ovms-server-v2: Got server response: MP-S 0 ooMhIGTk/0ZEvxVpwoHZ4d 4d+RTkaUZ1onzxLyxVwYEQ== I (170459342) ovms-server-v2: Server token is ooMhIGTk/0ZEvxVpwoHZ4d and digest is 4d+RTkaUZ1onzxLyxVwYEQ== I (170459342) ovms-server-v2: Status: Server authentication ok. Now priming crypto. I (170459342) ovms-server-v2: Shared secret key is ooMhIGTk/0ZEvxVpwoHZ4dzSgUQypXKd9tYDq7XuHf8m (44 bytes) I (170459342) ovms-server-v2: Status: OVMS V2 login successful, and crypto channel established I (170459352) ovms-server-v2: Incoming Msg: MP-0 Z0 I (170459352) webserver: HTTP GET /status I (170459392) webserver: HTTP GET /menu _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Steve, Greg, you're both still on the 3.1.008 main release, please check out the edge build. Your crashes look very familiar to me, I assume they are wifi related. The "esf_buf" error log Steve had is coming from within the wifi blob, and the latest edge build includes many fixes to that. That build reduced those crashes in the Twizy community by about 90%. Regarding logging, this is my base config: level: debug level.gsm-ppp: debug level.simcom: debug level.time: info level.v-twizy: verbose ← change accordingly level.webserver: debug If I need more detail I simply switch the default level to verbose. Regards, Michael Am 01.08.2018 um 08:40 schrieb Greg D.:
Well, we seem to be on a roll... Got another one.
I just realized that I have an SD card in the module, but am not logging anything. What logging should I be setting up to capture additional information?
Greg
Last boot was 2153 second(s) ago Time at boot: 2018-07-31 23:01:39 PDT This is reset #20 since last power cycle Detected boot reason: Crash (12/12) Crash counters: 2 total, 0 early Last crash: Alloca exception on core 0 Registers: PC : 0x40081b96 PS : 0x00060634 A0 : 0x80081d61 A1 : 0x3ffafa60 A2 : 0x3ffb43e4 A3 : 0x00000001 A4 : 0x00000050 A5 : 0x00000001 A6 : 0x000000fe A7 : 0x000000a0 A8 : 0x00000081 A9 : 0x00000001 A10 : 0x0000cdcd A11 : 0x00000000 A12 : 0x3f40819c A13 : 0x3f407ebe A14 : 0x000000fe A15 : 0x00060023 SAR : 0x00000000 EXCCAUSE: 0x00000005 EXCVADDR: 0x00000000 LBEG : 0x40097664 LEND : 0x40097692 LCOUNT : 0xffffffff Backtrace: 0x40081b96 0x40081d5e 0x400db815 0x40174f95 0x400e73be 0x400e4699 0x40085149 0x40128bc2 0x40128df7 0x401287b4 0x400ea22d 0x400eac7a 0x400ead09 0x400ead19 0x402207d6 0x400e9ece 0x400e9f79 0x400e45f5 0x400e4604 0x400f5c09 0x400f035d Version: 3.1.008/ota_1/main (build idf v3.1-dev-986-g1a1a544a Jun 26 2018 09:30:21) ---------------------------------------------------------------------------------------------------------------------------------------------------------------- Running partition: ota_1 Boot partition: ota_1 Firmware: 3.1.008/ota_1/main (build idf v3.1-dev-986-g1a1a544a Jun 26 2018 09:30:21)
Greg D. wrote:
Hi Steve,
Ok, so, still a puzzle as to why the crashes. Fortunately, I've only had the one. I've not had any trouble losing wifi connectivity, either when the car's been sitting in the garage for a few days, or coming and going on errands (so, transitioning to cell and back). Prior to this, I think the last boot was the upgrade to 3.1.008. Oh, perhaps the car's recent near death experience (*) cycled power? Not sure, but probably did. Anyway, in general, I've not had trouble with connectivity in a long time.
The only thing I've noticed is that sometimes I have a rather long delay between an event (e.g. when the car starts charging) and having it show up on my cell phone. Usually I get it immediately, but some time it's delayed several minutes, and once in a while it never shows up (e.g. charging started but never finished). It might simply be packet loss on my Internet connection (it's fast, but sometimes leaky), not related to wi-fi. I get delays at times on the PC going to websites too.
{shrug}
Greg
(*) For some reason, the VMS lost connectivity to the VDS, and the car locked up. Fortunately it was in the garage, and the windows were rolled down since the door opening switches stopped working too. Had to unplug the cables to the VMS under the dash and plug them back in to force a reboot. {phew!}
Stephen Casner wrote:
On Sun, 29 Jul 2018, Greg D. wrote:
Hi Steve,
Interesting...? I just got a very cryptic "event" from my car:? Not charging SOC:- I believe it is expected to get that event when OVMS boots while the car is idle since "not charging" is an accurate description of the state.
I received a "not charging" notification on Sunday as well, coincidentally as we were approaching home in our RAV4-EV. This resulted from another "Alloca exception on core 0" crash and reboot of OVMS:
Last boot was 170458 second(s) ago Time at boot: 2018-07-29 21:41:32 GMT This is reset #7 since last power cycle Detected boot reason: Crash (8/14) Crash counters: 2 total, 0 early
Last crash: Alloca exception on core 0
This is not the same time as yours (2018-07-29 17:55:36 PDT) so it does not appear that the crashes are synchronized by some external event.
Then today I looked at the iPhone app and saw that my OVMS had not communicated with the v2 server for 15 hours. So I connected to the USB cable again and found that the wifi was again in trouble. This time there were many instances of a new error message from wifi that I had not seen before, as shown in the log below.
Again I was able to restore operation of both server v2 and http by "wifi mode off" then "wifi mode client".
-- Steve
E (170324792) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170325752) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170328632) ovms-server-v2: mg_connect(api.openvehicles.com:6867) failed: cannot parse address| E (170328632) ovms-server-v2: Status: Error: Connection failed E (170329542) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170333742) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170333742) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170333742) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170333752) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170333752) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170333752) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170333752) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170333752) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170333752) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170333762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170333762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170335592) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb I (170335672) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 I (170335672) ovms-server-v2: Status: Connecting... E (170335672) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170336312) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170337272) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170338232) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170339192) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170340152) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170341112) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170342072) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170343032) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb OVMS> ena Password: E (170343992) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170344702) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170345912) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170346232) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170346872) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170347262) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb OVMS# E (170347832) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170348792) ovms-server-v2: mg_connect(api.openvehicles.com:6867) failed: cannot parse address| E (170348792) ovms-server-v2: Status: Error: Connection failed E (170348792) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170349752) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170350832) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353802) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353802) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353802) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353802) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353812) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353812) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353812) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353812) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353812) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353812) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353812) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353822) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353822) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353822) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353822) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353832) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353832) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353832) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353832) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb I (170355672) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 I (170355672) ovms-server-v2: Status: Connecting... E (170355672) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170356472) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170357432) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170358392) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170359352) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170359842) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170360862) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170362232) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170362922) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170363192) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170364152) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170365112) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170366072) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170368952) ovms-server-v2: mg_connect(api.openvehicles.com:6867) failed: cannot parse address| E (170368952) ovms-server-v2: Status: Error: Connection failed E (170372022) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373782) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373782) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373782) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373782) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373782) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373782) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170374992) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170375672) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170375672) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb I (170375672) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 I (170375672) ovms-server-v2: Status: Connecting... E (170376632) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170377592) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170378062) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170378552) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170379512) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170380472) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170381432) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170382392) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb OVMS# wifi mode off Stopping wifi station... I (170383222) esp32wifi: Stopping WIFI station I (170383222) wifi: state: run -> init (0) I (170383222) wifi: pm stop, total sleep time: 47593209375 us / 59459320714 us I (170383222) wifi: n:1 0, o:1 1, ap:1 1, sta:1 0, prof:1 I (170383232) wifi: flush txq I (170383232) wifi: stop sw txq I (170383232) wifi: lmac stop hw txq E (170389112) ovms-server-v2: mg_connect(api.openvehicles.com:6867) failed: cannot parse address| E (170389112) ovms-server-v2: Status: Error: Connection failed I (170389112) netmanager: Interface priority is pp3 (10.170.41.247/255.255.255.255 gateway 10.64.64.64) I (170389112) netmanager: Set DNS#0 8.8.8.8 I (170389112) netmanager: Set DNS#1 8.8.4.4 I (170389112) netmanager: WIFI client down (with MODEM up): reconfigured for MODEM priority I (170389122) netmanager: Interface priority is pp3 (10.170.41.247/255.255.255.255 gateway 10.64.64.64) I (170389122) netmanager: Set DNS#0 8.8.8.8 I (170389122) netmanager: Set DNS#1 8.8.4.4 I (170389122) esp32wifi: STA disconnected with reason 8 W (170389122) netmanager: CleanupConnections: can't get AP station list I (170389122) netmanager: Interface priority is pp3 (10.170.41.247/255.255.255.255 gateway 10.64.64.64) I (170389122) netmanager: Set DNS#0 8.8.8.8 I (170389122) netmanager: Set DNS#1 8.8.4.4 I (170389132) netmanager: Interface priority is pp3 (10.170.41.247/255.255.255.255 gateway 10.64.64.64) I (170389132) netmanager: Set DNS#0 8.8.8.8 I (170389132) netmanager: Set DNS#1 8.8.4.4 I (170389132) netmanager: WIFI access point is down I (170389132) esp32wifi: AP stopped I (170389132) netmanager: CleanupConnections: closing conn 3f81dbbc: interface/link down I (170389142) netmanager: CleanupConnections: closing conn 3f81dbbc: interface/link down I (170389142) time: Network was reconfigured: restarting SNTP client I (170389142) ovms-server-v2: Network was reconfigured: disconnect, and reconnect in 10 seconds I (170389142) ovms-server-v2: Status: Network was reconfigured: disconnect, and reconnect in 10 seconds I (170389152) netmanager: CleanupConnections: closing conn 3f81dbbc: interface/link down I (170398672) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 I (170398672) ovms-server-v2: Status: Connecting... I (170401312) housekeeping: 2018-07-31 21:01:32 GMT (RAM: 8b=113788-152956 32b=28252) I (170402032) ovms-server-v2: Connection successful I (170402032) ovms-server-v2: Status: Logging in... I (170402032) ovms-server-v2: Sending server login: MP-C 0 xR/s7da9YTwJ+uKH0C2zRl VXtWmVfsQQjJCe4+AwK74w== US33 I (170402852) ovms-server-v2: Got server response: MP-S 0 1uDt9VTVDl5jzvSqsIwmtN isXmd3Gy2AcrvhQVrX3LAA== I (170402852) ovms-server-v2: Server token is 1uDt9VTVDl5jzvSqsIwmtN and digest is isXmd3Gy2AcrvhQVrX3LAA== I (170402852) ovms-server-v2: Status: Server authentication ok. Now priming crypto. I (170402852) ovms-server-v2: Shared secret key is 1uDt9VTVDl5jzvSqsIwmtNxR/s7da9YTwJ+uKH0C2zRl (44 bytes) I (170402852) ovms-server-v2: Status: OVMS V2 login successful, and crypto channel established I (170402872) ovms-server-v2: Incoming Msg: MP-0 Z0 I (170403672) ovms-server-v2: Send MP-0 S70.0,M,65535,127,stopped,standard,166,146,32,0,0,2100,7,21,0,0,0,0,0.00,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,0.00,0 I (170403672) ovms-server-v2: Send MP-0 D65,0,5,23,23,24,587,516256,0,170403,24,0,1,1,11.63,0,12.6,0,23,0 I (170403672) ovms-server-v2: Send MP-0 L37.346340,-122.037308,206,64,1,1,0,0,0.0,0,0 I (170403682) ovms-server-v2: Send MP-0 F3.1.008/ota_0/main (build idf v3.1-dev-986-g1a1a544a Jun 26 2018 09:30:21),5YJRE11B181000033,7,1,TR1N,AT&T Hologram OVMS# wifi mode client Revelstoke Starting WIFI as a client to Revelstoke... I (170432062) wifi: mode : sta (30:ae:a4:43:9c:28) I (170434462) wifi: n:1 0, o:1 0, ap:255 255, sta:1 0, prof:1 I (170435152) wifi: state: init -> auth (b0) I (170435162) wifi: state: auth -> assoc (0) I (170435162) wifi: state: assoc -> run (10) I (170435202) wifi: connected with Revelstoke, channel 1 I (170435202) wifi: pm start, type: 1 I (170438872) event: sta ip: 192.168.1.82, mask: 255.255.255.0, gw: 192.168.1.254 I (170438872) netmanager: Interface priority is st4 (192.168.1.82/255.255.255.0 gateway 192.168.1.254) I (170438872) netmanager: Set DNS#0 8.8.8.8 I (170438872) netmanager: Set DNS#1 8.8.4.4 I (170438872) netmanager: WIFI client up (with MODEM up): reconfigured for WIFI client priority I (170438872) esp32wifi: STA got IP with SSID: Revelstoke, MAC: 30:ae:a4:43:9c:28, IP: 192.168.1.82, mask: 255.255.255.0, gw: 192.168.1.254 I (170438882) time: Network was reconfigured: restarting SNTP client I (170438882) ovms-server-v2: Network was reconfigured: disconnect, and reconnect in 10 seconds I (170438882) ovms-server-v2: Status: Network was reconfigured: disconnect, and reconnect in 10 seconds I (170439082) ovms-server-v2: Status: Disconnected I (170451362) webserver: HTTP GET / I (170451572) webserver: HTTP GET /apple-touch-icon.png I (170451842) webserver: HTTP GET /status I (170458672) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 I (170458672) ovms-server-v2: Status: Connecting... I (170458902) ovms-server-v2: Connection successful I (170458902) ovms-server-v2: Status: Logging in... I (170458902) ovms-server-v2: Sending server login: MP-C 0 zSgUQypXKd9tYDq7XuHf8m Raby/geQppSUPG5l9NRztw== US33 I (170458922) webserver: HTTP POST /status I (170458922) webserver: HandleLogin: 'admin' logged in, sid 6ea0f4c3207e3328 I (170459342) ovms-server-v2: Got server response: MP-S 0 ooMhIGTk/0ZEvxVpwoHZ4d 4d+RTkaUZ1onzxLyxVwYEQ== I (170459342) ovms-server-v2: Server token is ooMhIGTk/0ZEvxVpwoHZ4d and digest is 4d+RTkaUZ1onzxLyxVwYEQ== I (170459342) ovms-server-v2: Status: Server authentication ok. Now priming crypto. I (170459342) ovms-server-v2: Shared secret key is ooMhIGTk/0ZEvxVpwoHZ4dzSgUQypXKd9tYDq7XuHf8m (44 bytes) I (170459342) ovms-server-v2: Status: OVMS V2 login successful, and crypto channel established I (170459352) ovms-server-v2: Incoming Msg: MP-0 Z0 I (170459352) webserver: HTTP GET /status I (170459392) webserver: HTTP GET /menu _______________________________________________ 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
Michael, Will 009 be ready for main soon? I could switch to edge, but my friend in Santa Barbara needs it too, and edge would not be good for him. -- Steve On Wed, 1 Aug 2018, Michael Balzer wrote:
Steve, Greg,
you're both still on the 3.1.008 main release, please check out the edge build.
Your crashes look very familiar to me, I assume they are wifi related. The "esf_buf" error log Steve had is coming from within the wifi blob, and the latest edge build includes many fixes to that. That build reduced those crashes in the Twizy community by about 90%.
Regarding logging, this is my base config:
level: debug level.gsm-ppp: debug level.simcom: debug level.time: info level.v-twizy: verbose ← change accordingly level.webserver: debug
If I need more detail I simply switch the default level to verbose.
Regards, Michael
Am 01.08.2018 um 08:40 schrieb Greg D.:
Well, we seem to be on a roll... Got another one.
I just realized that I have an SD card in the module, but am not logging anything. What logging should I be setting up to capture additional information?
Greg
Last boot was 2153 second(s) ago Time at boot: 2018-07-31 23:01:39 PDT This is reset #20 since last power cycle Detected boot reason: Crash (12/12) Crash counters: 2 total, 0 early Last crash: Alloca exception on core 0 Registers: PC : 0x40081b96 PS : 0x00060634 A0 : 0x80081d61 A1 : 0x3ffafa60 A2 : 0x3ffb43e4 A3 : 0x00000001 A4 : 0x00000050 A5 : 0x00000001 A6 : 0x000000fe A7 : 0x000000a0 A8 : 0x00000081 A9 : 0x00000001 A10 : 0x0000cdcd A11 : 0x00000000 A12 : 0x3f40819c A13 : 0x3f407ebe A14 : 0x000000fe A15 : 0x00060023 SAR : 0x00000000 EXCCAUSE: 0x00000005 EXCVADDR: 0x00000000 LBEG : 0x40097664 LEND : 0x40097692 LCOUNT : 0xffffffff Backtrace: 0x40081b96 0x40081d5e 0x400db815 0x40174f95 0x400e73be 0x400e4699 0x40085149 0x40128bc2 0x40128df7 0x401287b4 0x400ea22d 0x400eac7a 0x400ead09 0x400ead19 0x402207d6 0x400e9ece 0x400e9f79 0x400e45f5 0x400e4604 0x400f5c09 0x400f035d Version: 3.1.008/ota_1/main (build idf v3.1-dev-986-g1a1a544a Jun 26 2018 09:30:21) ---------------------------------------------------------------------------------------------------------------------------------------------------------------- Running partition: ota_1 Boot partition: ota_1 Firmware: 3.1.008/ota_1/main (build idf v3.1-dev-986-g1a1a544a Jun 26 2018 09:30:21)
Greg D. wrote:
Hi Steve,
Ok, so, still a puzzle as to why the crashes. Fortunately, I've only had the one. I've not had any trouble losing wifi connectivity, either when the car's been sitting in the garage for a few days, or coming and going on errands (so, transitioning to cell and back). Prior to this, I think the last boot was the upgrade to 3.1.008. Oh, perhaps the car's recent near death experience (*) cycled power? Not sure, but probably did. Anyway, in general, I've not had trouble with connectivity in a long time.
The only thing I've noticed is that sometimes I have a rather long delay between an event (e.g. when the car starts charging) and having it show up on my cell phone. Usually I get it immediately, but some time it's delayed several minutes, and once in a while it never shows up (e.g. charging started but never finished). It might simply be packet loss on my Internet connection (it's fast, but sometimes leaky), not related to wi-fi. I get delays at times on the PC going to websites too.
{shrug}
Greg
(*) For some reason, the VMS lost connectivity to the VDS, and the car locked up. Fortunately it was in the garage, and the windows were rolled down since the door opening switches stopped working too. Had to unplug the cables to the VMS under the dash and plug them back in to force a reboot. {phew!}
Stephen Casner wrote:
On Sun, 29 Jul 2018, Greg D. wrote:
Hi Steve,
Interesting...? I just got a very cryptic "event" from my car:? Not charging SOC:- I believe it is expected to get that event when OVMS boots while the car is idle since "not charging" is an accurate description of the state.
I received a "not charging" notification on Sunday as well, coincidentally as we were approaching home in our RAV4-EV. This resulted from another "Alloca exception on core 0" crash and reboot of OVMS:
Last boot was 170458 second(s) ago Time at boot: 2018-07-29 21:41:32 GMT This is reset #7 since last power cycle Detected boot reason: Crash (8/14) Crash counters: 2 total, 0 early
Last crash: Alloca exception on core 0
This is not the same time as yours (2018-07-29 17:55:36 PDT) so it does not appear that the crashes are synchronized by some external event.
Then today I looked at the iPhone app and saw that my OVMS had not communicated with the v2 server for 15 hours. So I connected to the USB cable again and found that the wifi was again in trouble. This time there were many instances of a new error message from wifi that I had not seen before, as shown in the log below.
Again I was able to restore operation of both server v2 and http by "wifi mode off" then "wifi mode client".
-- Steve
E (170324792) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170325752) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170328632) ovms-server-v2: mg_connect(api.openvehicles.com:6867) failed: cannot parse address| E (170328632) ovms-server-v2: Status: Error: Connection failed E (170329542) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170333742) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170333742) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170333742) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170333752) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170333752) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170333752) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170333752) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170333752) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170333752) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170333762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170333762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170335592) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb I (170335672) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 I (170335672) ovms-server-v2: Status: Connecting... E (170335672) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170336312) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170337272) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170338232) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170339192) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170340152) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170341112) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170342072) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170343032) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb OVMS> ena Password: E (170343992) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170344702) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170345912) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170346232) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170346872) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170347262) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb OVMS# E (170347832) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170348792) ovms-server-v2: mg_connect(api.openvehicles.com:6867) failed: cannot parse address| E (170348792) ovms-server-v2: Status: Error: Connection failed E (170348792) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170349752) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170350832) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353802) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353802) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353802) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353802) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353812) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353812) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353812) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353812) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353812) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353812) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353812) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353822) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353822) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353822) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353822) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353832) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353832) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353832) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353832) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb I (170355672) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 I (170355672) ovms-server-v2: Status: Connecting... E (170355672) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170356472) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170357432) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170358392) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170359352) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170359842) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170360862) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170362232) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170362922) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170363192) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170364152) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170365112) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170366072) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170368952) ovms-server-v2: mg_connect(api.openvehicles.com:6867) failed: cannot parse address| E (170368952) ovms-server-v2: Status: Error: Connection failed E (170372022) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373782) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373782) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373782) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373782) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373782) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373782) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170374992) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170375672) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170375672) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb I (170375672) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 I (170375672) ovms-server-v2: Status: Connecting... E (170376632) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170377592) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170378062) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170378552) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170379512) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170380472) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170381432) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170382392) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb OVMS# wifi mode off Stopping wifi station... I (170383222) esp32wifi: Stopping WIFI station I (170383222) wifi: state: run -> init (0) I (170383222) wifi: pm stop, total sleep time: 47593209375 us / 59459320714 us I (170383222) wifi: n:1 0, o:1 1, ap:1 1, sta:1 0, prof:1 I (170383232) wifi: flush txq I (170383232) wifi: stop sw txq I (170383232) wifi: lmac stop hw txq E (170389112) ovms-server-v2: mg_connect(api.openvehicles.com:6867) failed: cannot parse address| E (170389112) ovms-server-v2: Status: Error: Connection failed I (170389112) netmanager: Interface priority is pp3 (10.170.41.247/255.255.255.255 gateway 10.64.64.64) I (170389112) netmanager: Set DNS#0 8.8.8.8 I (170389112) netmanager: Set DNS#1 8.8.4.4 I (170389112) netmanager: WIFI client down (with MODEM up): reconfigured for MODEM priority I (170389122) netmanager: Interface priority is pp3 (10.170.41.247/255.255.255.255 gateway 10.64.64.64) I (170389122) netmanager: Set DNS#0 8.8.8.8 I (170389122) netmanager: Set DNS#1 8.8.4.4 I (170389122) esp32wifi: STA disconnected with reason 8 W (170389122) netmanager: CleanupConnections: can't get AP station list I (170389122) netmanager: Interface priority is pp3 (10.170.41.247/255.255.255.255 gateway 10.64.64.64) I (170389122) netmanager: Set DNS#0 8.8.8.8 I (170389122) netmanager: Set DNS#1 8.8.4.4 I (170389132) netmanager: Interface priority is pp3 (10.170.41.247/255.255.255.255 gateway 10.64.64.64) I (170389132) netmanager: Set DNS#0 8.8.8.8 I (170389132) netmanager: Set DNS#1 8.8.4.4 I (170389132) netmanager: WIFI access point is down I (170389132) esp32wifi: AP stopped I (170389132) netmanager: CleanupConnections: closing conn 3f81dbbc: interface/link down I (170389142) netmanager: CleanupConnections: closing conn 3f81dbbc: interface/link down I (170389142) time: Network was reconfigured: restarting SNTP client I (170389142) ovms-server-v2: Network was reconfigured: disconnect, and reconnect in 10 seconds I (170389142) ovms-server-v2: Status: Network was reconfigured: disconnect, and reconnect in 10 seconds I (170389152) netmanager: CleanupConnections: closing conn 3f81dbbc: interface/link down I (170398672) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 I (170398672) ovms-server-v2: Status: Connecting... I (170401312) housekeeping: 2018-07-31 21:01:32 GMT (RAM: 8b=113788-152956 32b=28252) I (170402032) ovms-server-v2: Connection successful I (170402032) ovms-server-v2: Status: Logging in... I (170402032) ovms-server-v2: Sending server login: MP-C 0 xR/s7da9YTwJ+uKH0C2zRl VXtWmVfsQQjJCe4+AwK74w== US33 I (170402852) ovms-server-v2: Got server response: MP-S 0 1uDt9VTVDl5jzvSqsIwmtN isXmd3Gy2AcrvhQVrX3LAA== I (170402852) ovms-server-v2: Server token is 1uDt9VTVDl5jzvSqsIwmtN and digest is isXmd3Gy2AcrvhQVrX3LAA== I (170402852) ovms-server-v2: Status: Server authentication ok. Now priming crypto. I (170402852) ovms-server-v2: Shared secret key is 1uDt9VTVDl5jzvSqsIwmtNxR/s7da9YTwJ+uKH0C2zRl (44 bytes) I (170402852) ovms-server-v2: Status: OVMS V2 login successful, and crypto channel established I (170402872) ovms-server-v2: Incoming Msg: MP-0 Z0 I (170403672) ovms-server-v2: Send MP-0 S70.0,M,65535,127,stopped,standard,166,146,32,0,0,2100,7,21,0,0,0,0,0.00,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,0.00,0 I (170403672) ovms-server-v2: Send MP-0 D65,0,5,23,23,24,587,516256,0,170403,24,0,1,1,11.63,0,12.6,0,23,0 I (170403672) ovms-server-v2: Send MP-0 L37.346340,-122.037308,206,64,1,1,0,0,0.0,0,0 I (170403682) ovms-server-v2: Send MP-0 F3.1.008/ota_0/main (build idf v3.1-dev-986-g1a1a544a Jun 26 2018 09:30:21),5YJRE11B181000033,7,1,TR1N,AT&T Hologram OVMS# wifi mode client Revelstoke Starting WIFI as a client to Revelstoke... I (170432062) wifi: mode : sta (30:ae:a4:43:9c:28) I (170434462) wifi: n:1 0, o:1 0, ap:255 255, sta:1 0, prof:1 I (170435152) wifi: state: init -> auth (b0) I (170435162) wifi: state: auth -> assoc (0) I (170435162) wifi: state: assoc -> run (10) I (170435202) wifi: connected with Revelstoke, channel 1 I (170435202) wifi: pm start, type: 1 I (170438872) event: sta ip: 192.168.1.82, mask: 255.255.255.0, gw: 192.168.1.254 I (170438872) netmanager: Interface priority is st4 (192.168.1.82/255.255.255.0 gateway 192.168.1.254) I (170438872) netmanager: Set DNS#0 8.8.8.8 I (170438872) netmanager: Set DNS#1 8.8.4.4 I (170438872) netmanager: WIFI client up (with MODEM up): reconfigured for WIFI client priority I (170438872) esp32wifi: STA got IP with SSID: Revelstoke, MAC: 30:ae:a4:43:9c:28, IP: 192.168.1.82, mask: 255.255.255.0, gw: 192.168.1.254 I (170438882) time: Network was reconfigured: restarting SNTP client I (170438882) ovms-server-v2: Network was reconfigured: disconnect, and reconnect in 10 seconds I (170438882) ovms-server-v2: Status: Network was reconfigured: disconnect, and reconnect in 10 seconds I (170439082) ovms-server-v2: Status: Disconnected I (170451362) webserver: HTTP GET / I (170451572) webserver: HTTP GET /apple-touch-icon.png I (170451842) webserver: HTTP GET /status I (170458672) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 I (170458672) ovms-server-v2: Status: Connecting... I (170458902) ovms-server-v2: Connection successful I (170458902) ovms-server-v2: Status: Logging in... I (170458902) ovms-server-v2: Sending server login: MP-C 0 zSgUQypXKd9tYDq7XuHf8m Raby/geQppSUPG5l9NRztw== US33 I (170458922) webserver: HTTP POST /status I (170458922) webserver: HandleLogin: 'admin' logged in, sid 6ea0f4c3207e3328 I (170459342) ovms-server-v2: Got server response: MP-S 0 ooMhIGTk/0ZEvxVpwoHZ4d 4d+RTkaUZ1onzxLyxVwYEQ== I (170459342) ovms-server-v2: Server token is ooMhIGTk/0ZEvxVpwoHZ4d and digest is 4d+RTkaUZ1onzxLyxVwYEQ== I (170459342) ovms-server-v2: Status: Server authentication ok. Now priming crypto. I (170459342) ovms-server-v2: Shared secret key is ooMhIGTk/0ZEvxVpwoHZ4dzSgUQypXKd9tYDq7XuHf8m (44 bytes) I (170459342) ovms-server-v2: Status: OVMS V2 login successful, and crypto channel established I (170459352) ovms-server-v2: Incoming Msg: MP-0 Z0 I (170459352) webserver: HTTP GET /status I (170459392) webserver: HTTP GET /menu _______________________________________________ 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
Feature wise it is fine. Just trying to find out the cause of these crashes, and if they are worse in recent edge builds vs main 3.1.008. Regards, Mark
On 2 Aug 2018, at 2:54 PM, Stephen Casner <casner@acm.org> wrote:
Michael,
Will 009 be ready for main soon? I could switch to edge, but my friend in Santa Barbara needs it too, and edge would not be good for him.
-- Steve
On Wed, 1 Aug 2018, Michael Balzer wrote:
Steve, Greg,
you're both still on the 3.1.008 main release, please check out the edge build.
Your crashes look very familiar to me, I assume they are wifi related. The "esf_buf" error log Steve had is coming from within the wifi blob, and the latest edge build includes many fixes to that. That build reduced those crashes in the Twizy community by about 90%.
Regarding logging, this is my base config:
level: debug level.gsm-ppp: debug level.simcom: debug level.time: info level.v-twizy: verbose ← change accordingly level.webserver: debug
If I need more detail I simply switch the default level to verbose.
Regards, Michael
Am 01.08.2018 um 08:40 schrieb Greg D.:
Well, we seem to be on a roll... Got another one.
I just realized that I have an SD card in the module, but am not logging anything. What logging should I be setting up to capture additional information?
Greg
Last boot was 2153 second(s) ago Time at boot: 2018-07-31 23:01:39 PDT This is reset #20 since last power cycle Detected boot reason: Crash (12/12) Crash counters: 2 total, 0 early Last crash: Alloca exception on core 0 Registers: PC : 0x40081b96 PS : 0x00060634 A0 : 0x80081d61 A1 : 0x3ffafa60 A2 : 0x3ffb43e4 A3 : 0x00000001 A4 : 0x00000050 A5 : 0x00000001 A6 : 0x000000fe A7 : 0x000000a0 A8 : 0x00000081 A9 : 0x00000001 A10 : 0x0000cdcd A11 : 0x00000000 A12 : 0x3f40819c A13 : 0x3f407ebe A14 : 0x000000fe A15 : 0x00060023 SAR : 0x00000000 EXCCAUSE: 0x00000005 EXCVADDR: 0x00000000 LBEG : 0x40097664 LEND : 0x40097692 LCOUNT : 0xffffffff Backtrace: 0x40081b96 0x40081d5e 0x400db815 0x40174f95 0x400e73be 0x400e4699 0x40085149 0x40128bc2 0x40128df7 0x401287b4 0x400ea22d 0x400eac7a 0x400ead09 0x400ead19 0x402207d6 0x400e9ece 0x400e9f79 0x400e45f5 0x400e4604 0x400f5c09 0x400f035d Version: 3.1.008/ota_1/main (build idf v3.1-dev-986-g1a1a544a Jun 26 2018 09:30:21) ---------------------------------------------------------------------------------------------------------------------------------------------------------------- Running partition: ota_1 Boot partition: ota_1 Firmware: 3.1.008/ota_1/main (build idf v3.1-dev-986-g1a1a544a Jun 26 2018 09:30:21)
Greg D. wrote:
Hi Steve,
Ok, so, still a puzzle as to why the crashes. Fortunately, I've only had the one. I've not had any trouble losing wifi connectivity, either when the car's been sitting in the garage for a few days, or coming and going on errands (so, transitioning to cell and back). Prior to this, I think the last boot was the upgrade to 3.1.008. Oh, perhaps the car's recent near death experience (*) cycled power? Not sure, but probably did. Anyway, in general, I've not had trouble with connectivity in a long time.
The only thing I've noticed is that sometimes I have a rather long delay between an event (e.g. when the car starts charging) and having it show up on my cell phone. Usually I get it immediately, but some time it's delayed several minutes, and once in a while it never shows up (e.g. charging started but never finished). It might simply be packet loss on my Internet connection (it's fast, but sometimes leaky), not related to wi-fi. I get delays at times on the PC going to websites too.
{shrug}
Greg
(*) For some reason, the VMS lost connectivity to the VDS, and the car locked up. Fortunately it was in the garage, and the windows were rolled down since the door opening switches stopped working too. Had to unplug the cables to the VMS under the dash and plug them back in to force a reboot. {phew!}
Stephen Casner wrote:
On Sun, 29 Jul 2018, Greg D. wrote:
Hi Steve,
Interesting...? I just got a very cryptic "event" from my car:? Not charging SOC:- I believe it is expected to get that event when OVMS boots while the car is idle since "not charging" is an accurate description of the state.
I received a "not charging" notification on Sunday as well, coincidentally as we were approaching home in our RAV4-EV. This resulted from another "Alloca exception on core 0" crash and reboot of OVMS:
Last boot was 170458 second(s) ago Time at boot: 2018-07-29 21:41:32 GMT This is reset #7 since last power cycle Detected boot reason: Crash (8/14) Crash counters: 2 total, 0 early
Last crash: Alloca exception on core 0
This is not the same time as yours (2018-07-29 17:55:36 PDT) so it does not appear that the crashes are synchronized by some external event.
Then today I looked at the iPhone app and saw that my OVMS had not communicated with the v2 server for 15 hours. So I connected to the USB cable again and found that the wifi was again in trouble. This time there were many instances of a new error message from wifi that I had not seen before, as shown in the log below.
Again I was able to restore operation of both server v2 and http by "wifi mode off" then "wifi mode client".
-- Steve
E (170324792) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170325752) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170328632) ovms-server-v2: mg_connect(api.openvehicles.com:6867) failed: cannot parse address| E (170328632) ovms-server-v2: Status: Error: Connection failed E (170329542) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170333742) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170333742) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170333742) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170333752) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170333752) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170333752) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170333752) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170333752) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170333752) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170333762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170333762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170335592) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb I (170335672) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 I (170335672) ovms-server-v2: Status: Connecting... E (170335672) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170336312) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170337272) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170338232) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170339192) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170340152) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170341112) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170342072) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170343032) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb OVMS> ena Password: E (170343992) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170344702) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170345912) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170346232) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170346872) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170347262) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb OVMS# E (170347832) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170348792) ovms-server-v2: mg_connect(api.openvehicles.com:6867) failed: cannot parse address| E (170348792) ovms-server-v2: Status: Error: Connection failed E (170348792) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170349752) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170350832) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353802) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353802) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353802) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353802) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353812) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353812) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353812) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353812) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353812) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353812) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353812) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353822) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353822) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353822) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353822) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353832) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353832) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353832) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353832) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb I (170355672) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 I (170355672) ovms-server-v2: Status: Connecting... E (170355672) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170356472) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170357432) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170358392) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170359352) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170359842) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170360862) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170362232) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170362922) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170363192) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170364152) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170365112) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170366072) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170368952) ovms-server-v2: mg_connect(api.openvehicles.com:6867) failed: cannot parse address| E (170368952) ovms-server-v2: Status: Error: Connection failed E (170372022) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373782) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373782) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373782) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373782) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373782) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373782) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170374992) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170375672) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170375672) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb I (170375672) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 I (170375672) ovms-server-v2: Status: Connecting... E (170376632) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170377592) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170378062) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170378552) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170379512) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170380472) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170381432) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170382392) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb OVMS# wifi mode off Stopping wifi station... I (170383222) esp32wifi: Stopping WIFI station I (170383222) wifi: state: run -> init (0) I (170383222) wifi: pm stop, total sleep time: 47593209375 us / 59459320714 us I (170383222) wifi: n:1 0, o:1 1, ap:1 1, sta:1 0, prof:1 I (170383232) wifi: flush txq I (170383232) wifi: stop sw txq I (170383232) wifi: lmac stop hw txq E (170389112) ovms-server-v2: mg_connect(api.openvehicles.com:6867) failed: cannot parse address| E (170389112) ovms-server-v2: Status: Error: Connection failed I (170389112) netmanager: Interface priority is pp3 (10.170.41.247/255.255.255.255 gateway 10.64.64.64) I (170389112) netmanager: Set DNS#0 8.8.8.8 I (170389112) netmanager: Set DNS#1 8.8.4.4 I (170389112) netmanager: WIFI client down (with MODEM up): reconfigured for MODEM priority I (170389122) netmanager: Interface priority is pp3 (10.170.41.247/255.255.255.255 gateway 10.64.64.64) I (170389122) netmanager: Set DNS#0 8.8.8.8 I (170389122) netmanager: Set DNS#1 8.8.4.4 I (170389122) esp32wifi: STA disconnected with reason 8 W (170389122) netmanager: CleanupConnections: can't get AP station list I (170389122) netmanager: Interface priority is pp3 (10.170.41.247/255.255.255.255 gateway 10.64.64.64) I (170389122) netmanager: Set DNS#0 8.8.8.8 I (170389122) netmanager: Set DNS#1 8.8.4.4 I (170389132) netmanager: Interface priority is pp3 (10.170.41.247/255.255.255.255 gateway 10.64.64.64) I (170389132) netmanager: Set DNS#0 8.8.8.8 I (170389132) netmanager: Set DNS#1 8.8.4.4 I (170389132) netmanager: WIFI access point is down I (170389132) esp32wifi: AP stopped I (170389132) netmanager: CleanupConnections: closing conn 3f81dbbc: interface/link down I (170389142) netmanager: CleanupConnections: closing conn 3f81dbbc: interface/link down I (170389142) time: Network was reconfigured: restarting SNTP client I (170389142) ovms-server-v2: Network was reconfigured: disconnect, and reconnect in 10 seconds I (170389142) ovms-server-v2: Status: Network was reconfigured: disconnect, and reconnect in 10 seconds I (170389152) netmanager: CleanupConnections: closing conn 3f81dbbc: interface/link down I (170398672) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 I (170398672) ovms-server-v2: Status: Connecting... I (170401312) housekeeping: 2018-07-31 21:01:32 GMT (RAM: 8b=113788-152956 32b=28252) I (170402032) ovms-server-v2: Connection successful I (170402032) ovms-server-v2: Status: Logging in... I (170402032) ovms-server-v2: Sending server login: MP-C 0 xR/s7da9YTwJ+uKH0C2zRl VXtWmVfsQQjJCe4+AwK74w== US33 I (170402852) ovms-server-v2: Got server response: MP-S 0 1uDt9VTVDl5jzvSqsIwmtN isXmd3Gy2AcrvhQVrX3LAA== I (170402852) ovms-server-v2: Server token is 1uDt9VTVDl5jzvSqsIwmtN and digest is isXmd3Gy2AcrvhQVrX3LAA== I (170402852) ovms-server-v2: Status: Server authentication ok. Now priming crypto. I (170402852) ovms-server-v2: Shared secret key is 1uDt9VTVDl5jzvSqsIwmtNxR/s7da9YTwJ+uKH0C2zRl (44 bytes) I (170402852) ovms-server-v2: Status: OVMS V2 login successful, and crypto channel established I (170402872) ovms-server-v2: Incoming Msg: MP-0 Z0 I (170403672) ovms-server-v2: Send MP-0 S70.0,M,65535,127,stopped,standard,166,146,32,0,0,2100,7,21,0,0,0,0,0.00,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,0.00,0 I (170403672) ovms-server-v2: Send MP-0 D65,0,5,23,23,24,587,516256,0,170403,24,0,1,1,11.63,0,12.6,0,23,0 I (170403672) ovms-server-v2: Send MP-0 L37.346340,-122.037308,206,64,1,1,0,0,0.0,0,0 I (170403682) ovms-server-v2: Send MP-0 F3.1.008/ota_0/main (build idf v3.1-dev-986-g1a1a544a Jun 26 2018 09:30:21),5YJRE11B181000033,7,1,TR1N,AT&T Hologram OVMS# wifi mode client Revelstoke Starting WIFI as a client to Revelstoke... I (170432062) wifi: mode : sta (30:ae:a4:43:9c:28) I (170434462) wifi: n:1 0, o:1 0, ap:255 255, sta:1 0, prof:1 I (170435152) wifi: state: init -> auth (b0) I (170435162) wifi: state: auth -> assoc (0) I (170435162) wifi: state: assoc -> run (10) I (170435202) wifi: connected with Revelstoke, channel 1 I (170435202) wifi: pm start, type: 1 I (170438872) event: sta ip: 192.168.1.82, mask: 255.255.255.0, gw: 192.168.1.254 I (170438872) netmanager: Interface priority is st4 (192.168.1.82/255.255.255.0 gateway 192.168.1.254) I (170438872) netmanager: Set DNS#0 8.8.8.8 I (170438872) netmanager: Set DNS#1 8.8.4.4 I (170438872) netmanager: WIFI client up (with MODEM up): reconfigured for WIFI client priority I (170438872) esp32wifi: STA got IP with SSID: Revelstoke, MAC: 30:ae:a4:43:9c:28, IP: 192.168.1.82, mask: 255.255.255.0, gw: 192.168.1.254 I (170438882) time: Network was reconfigured: restarting SNTP client I (170438882) ovms-server-v2: Network was reconfigured: disconnect, and reconnect in 10 seconds I (170438882) ovms-server-v2: Status: Network was reconfigured: disconnect, and reconnect in 10 seconds I (170439082) ovms-server-v2: Status: Disconnected I (170451362) webserver: HTTP GET / I (170451572) webserver: HTTP GET /apple-touch-icon.png I (170451842) webserver: HTTP GET /status I (170458672) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 I (170458672) ovms-server-v2: Status: Connecting... I (170458902) ovms-server-v2: Connection successful I (170458902) ovms-server-v2: Status: Logging in... I (170458902) ovms-server-v2: Sending server login: MP-C 0 zSgUQypXKd9tYDq7XuHf8m Raby/geQppSUPG5l9NRztw== US33 I (170458922) webserver: HTTP POST /status I (170458922) webserver: HandleLogin: 'admin' logged in, sid 6ea0f4c3207e3328 I (170459342) ovms-server-v2: Got server response: MP-S 0 ooMhIGTk/0ZEvxVpwoHZ4d 4d+RTkaUZ1onzxLyxVwYEQ== I (170459342) ovms-server-v2: Server token is ooMhIGTk/0ZEvxVpwoHZ4d and digest is 4d+RTkaUZ1onzxLyxVwYEQ== I (170459342) ovms-server-v2: Status: Server authentication ok. Now priming crypto. I (170459342) ovms-server-v2: Shared secret key is ooMhIGTk/0ZEvxVpwoHZ4dzSgUQypXKd9tYDq7XuHf8m (44 bytes) I (170459342) ovms-server-v2: Status: OVMS V2 login successful, and crypto channel established I (170459352) ovms-server-v2: Incoming Msg: MP-0 Z0 I (170459352) webserver: HTTP GET /status I (170459392) webserver: HTTP GET /menu _______________________________________________ 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
My feeling is that we don't have enough information to really know, and what we know is inconsistent. I had a couple of wireless and internet "burps" yesterday and today (my router rebooted itself, and separately, the modem dropped link a time or two), yet no further issues from the OVMS module. So, I am skeptical what direct effect wi-fi has on the reboots. I think the best bet is to push 3.1.009 out, when it is otherwise ready, and gather more information on the issue. Greg Mark Webb-Johnson wrote:
Feature wise it is fine. Just trying to find out the cause of these crashes, and if they are worse in recent edge builds vs main 3.1.008.
Regards, Mark
On 2 Aug 2018, at 2:54 PM, Stephen Casner <casner@acm.org> wrote:
Michael,
Will 009 be ready for main soon? I could switch to edge, but my friend in Santa Barbara needs it too, and edge would not be good for him.
-- Steve
On Wed, 1 Aug 2018, Michael Balzer wrote:
Steve, Greg,
you're both still on the 3.1.008 main release, please check out the edge build.
Your crashes look very familiar to me, I assume they are wifi related. The "esf_buf" error log Steve had is coming from within the wifi blob, and the latest edge build includes many fixes to that. That build reduced those crashes in the Twizy community by about 90%.
Regarding logging, this is my base config:
level: debug level.gsm-ppp: debug level.simcom: debug level.time: info level.v-twizy: verbose ← change accordingly level.webserver: debug
If I need more detail I simply switch the default level to verbose.
Regards, Michael
Am 01.08.2018 um 08:40 schrieb Greg D.:
Well, we seem to be on a roll... Got another one.
I just realized that I have an SD card in the module, but am not logging anything. What logging should I be setting up to capture additional information?
Greg
Last boot was 2153 second(s) ago Time at boot: 2018-07-31 23:01:39 PDT This is reset #20 since last power cycle Detected boot reason: Crash (12/12) Crash counters: 2 total, 0 early Last crash: Alloca exception on core 0 Registers: PC : 0x40081b96 PS : 0x00060634 A0 : 0x80081d61 A1 : 0x3ffafa60 A2 : 0x3ffb43e4 A3 : 0x00000001 A4 : 0x00000050 A5 : 0x00000001 A6 : 0x000000fe A7 : 0x000000a0 A8 : 0x00000081 A9 : 0x00000001 A10 : 0x0000cdcd A11 : 0x00000000 A12 : 0x3f40819c A13 : 0x3f407ebe A14 : 0x000000fe A15 : 0x00060023 SAR : 0x00000000 EXCCAUSE: 0x00000005 EXCVADDR: 0x00000000 LBEG : 0x40097664 LEND : 0x40097692 LCOUNT : 0xffffffff Backtrace: 0x40081b96 0x40081d5e 0x400db815 0x40174f95 0x400e73be 0x400e4699 0x40085149 0x40128bc2 0x40128df7 0x401287b4 0x400ea22d 0x400eac7a 0x400ead09 0x400ead19 0x402207d6 0x400e9ece 0x400e9f79 0x400e45f5 0x400e4604 0x400f5c09 0x400f035d Version: 3.1.008/ota_1/main (build idf v3.1-dev-986-g1a1a544a Jun 26 2018 09:30:21) ---------------------------------------------------------------------------------------------------------------------------------------------------------------- Running partition: ota_1 Boot partition: ota_1 Firmware: 3.1.008/ota_1/main (build idf v3.1-dev-986-g1a1a544a Jun 26 2018 09:30:21)
Greg D. wrote:
Hi Steve,
Ok, so, still a puzzle as to why the crashes. Fortunately, I've only had the one. I've not had any trouble losing wifi connectivity, either when the car's been sitting in the garage for a few days, or coming and going on errands (so, transitioning to cell and back). Prior to this, I think the last boot was the upgrade to 3.1.008. Oh, perhaps the car's recent near death experience (*) cycled power? Not sure, but probably did. Anyway, in general, I've not had trouble with connectivity in a long time.
The only thing I've noticed is that sometimes I have a rather long delay between an event (e.g. when the car starts charging) and having it show up on my cell phone. Usually I get it immediately, but some time it's delayed several minutes, and once in a while it never shows up (e.g. charging started but never finished). It might simply be packet loss on my Internet connection (it's fast, but sometimes leaky), not related to wi-fi. I get delays at times on the PC going to websites too.
{shrug}
Greg
(*) For some reason, the VMS lost connectivity to the VDS, and the car locked up. Fortunately it was in the garage, and the windows were rolled down since the door opening switches stopped working too. Had to unplug the cables to the VMS under the dash and plug them back in to force a reboot. {phew!}
Stephen Casner wrote:
On Sun, 29 Jul 2018, Greg D. wrote:
> Hi Steve, > > Interesting...? I just got a very cryptic "event" from my car:? > Not charging > SOC:- I believe it is expected to get that event when OVMS boots while the car is idle since "not charging" is an accurate description of the state.
I received a "not charging" notification on Sunday as well, coincidentally as we were approaching home in our RAV4-EV. This resulted from another "Alloca exception on core 0" crash and reboot of OVMS:
Last boot was 170458 second(s) ago Time at boot: 2018-07-29 21:41:32 GMT This is reset #7 since last power cycle Detected boot reason: Crash (8/14) Crash counters: 2 total, 0 early
Last crash: Alloca exception on core 0
This is not the same time as yours (2018-07-29 17:55:36 PDT) so it does not appear that the crashes are synchronized by some external event.
Then today I looked at the iPhone app and saw that my OVMS had not communicated with the v2 server for 15 hours. So I connected to the USB cable again and found that the wifi was again in trouble. This time there were many instances of a new error message from wifi that I had not seen before, as shown in the log below.
Again I was able to restore operation of both server v2 and http by "wifi mode off" then "wifi mode client".
-- Steve
E (170324792) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170325752) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170328632) ovms-server-v2: mg_connect(api.openvehicles.com:6867) failed: cannot parse address| E (170328632) ovms-server-v2: Status: Error: Connection failed E (170329542) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170333742) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170333742) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170333742) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170333752) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170333752) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170333752) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170333752) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170333752) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170333752) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170333762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170333762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170335592) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb I (170335672) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 I (170335672) ovms-server-v2: Status: Connecting... E (170335672) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170336312) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170337272) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170338232) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170339192) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170340152) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170341112) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170342072) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170343032) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb OVMS> ena Password: E (170343992) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170344702) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170345912) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170346232) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170346872) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170347262) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb OVMS# E (170347832) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170348792) ovms-server-v2: mg_connect(api.openvehicles.com:6867) failed: cannot parse address| E (170348792) ovms-server-v2: Status: Error: Connection failed E (170348792) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170349752) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170350832) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353802) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353802) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353802) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353802) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353812) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353812) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353812) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353812) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353812) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353812) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353812) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353822) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353822) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353822) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353822) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353832) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353832) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353832) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170353832) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb I (170355672) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 I (170355672) ovms-server-v2: Status: Connecting... E (170355672) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170356472) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170357432) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170358392) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170359352) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170359842) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170360862) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170362232) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170362922) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170363192) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170364152) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170365112) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170366072) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170368952) ovms-server-v2: mg_connect(api.openvehicles.com:6867) failed: cannot parse address| E (170368952) ovms-server-v2: Status: Error: Connection failed E (170372022) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373782) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373782) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373782) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373782) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373782) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170373782) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170374992) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170375672) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170375672) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb I (170375672) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 I (170375672) ovms-server-v2: Status: Connecting... E (170376632) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170377592) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170378062) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb E (170378552) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170379512) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170380472) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170381432) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb E (170382392) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb OVMS# wifi mode off Stopping wifi station... I (170383222) esp32wifi: Stopping WIFI station I (170383222) wifi: state: run -> init (0) I (170383222) wifi: pm stop, total sleep time: 47593209375 us / 59459320714 us I (170383222) wifi: n:1 0, o:1 1, ap:1 1, sta:1 0, prof:1 I (170383232) wifi: flush txq I (170383232) wifi: stop sw txq I (170383232) wifi: lmac stop hw txq E (170389112) ovms-server-v2: mg_connect(api.openvehicles.com:6867) failed: cannot parse address| E (170389112) ovms-server-v2: Status: Error: Connection failed I (170389112) netmanager: Interface priority is pp3 (10.170.41.247/255.255.255.255 gateway 10.64.64.64) I (170389112) netmanager: Set DNS#0 8.8.8.8 I (170389112) netmanager: Set DNS#1 8.8.4.4 I (170389112) netmanager: WIFI client down (with MODEM up): reconfigured for MODEM priority I (170389122) netmanager: Interface priority is pp3 (10.170.41.247/255.255.255.255 gateway 10.64.64.64) I (170389122) netmanager: Set DNS#0 8.8.8.8 I (170389122) netmanager: Set DNS#1 8.8.4.4 I (170389122) esp32wifi: STA disconnected with reason 8 W (170389122) netmanager: CleanupConnections: can't get AP station list I (170389122) netmanager: Interface priority is pp3 (10.170.41.247/255.255.255.255 gateway 10.64.64.64) I (170389122) netmanager: Set DNS#0 8.8.8.8 I (170389122) netmanager: Set DNS#1 8.8.4.4 I (170389132) netmanager: Interface priority is pp3 (10.170.41.247/255.255.255.255 gateway 10.64.64.64) I (170389132) netmanager: Set DNS#0 8.8.8.8 I (170389132) netmanager: Set DNS#1 8.8.4.4 I (170389132) netmanager: WIFI access point is down I (170389132) esp32wifi: AP stopped I (170389132) netmanager: CleanupConnections: closing conn 3f81dbbc: interface/link down I (170389142) netmanager: CleanupConnections: closing conn 3f81dbbc: interface/link down I (170389142) time: Network was reconfigured: restarting SNTP client I (170389142) ovms-server-v2: Network was reconfigured: disconnect, and reconnect in 10 seconds I (170389142) ovms-server-v2: Status: Network was reconfigured: disconnect, and reconnect in 10 seconds I (170389152) netmanager: CleanupConnections: closing conn 3f81dbbc: interface/link down I (170398672) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 I (170398672) ovms-server-v2: Status: Connecting... I (170401312) housekeeping: 2018-07-31 21:01:32 GMT (RAM: 8b=113788-152956 32b=28252) I (170402032) ovms-server-v2: Connection successful I (170402032) ovms-server-v2: Status: Logging in... I (170402032) ovms-server-v2: Sending server login: MP-C 0 xR/s7da9YTwJ+uKH0C2zRl VXtWmVfsQQjJCe4+AwK74w== US33 I (170402852) ovms-server-v2: Got server response: MP-S 0 1uDt9VTVDl5jzvSqsIwmtN isXmd3Gy2AcrvhQVrX3LAA== I (170402852) ovms-server-v2: Server token is 1uDt9VTVDl5jzvSqsIwmtN and digest is isXmd3Gy2AcrvhQVrX3LAA== I (170402852) ovms-server-v2: Status: Server authentication ok. Now priming crypto. I (170402852) ovms-server-v2: Shared secret key is 1uDt9VTVDl5jzvSqsIwmtNxR/s7da9YTwJ+uKH0C2zRl (44 bytes) I (170402852) ovms-server-v2: Status: OVMS V2 login successful, and crypto channel established I (170402872) ovms-server-v2: Incoming Msg: MP-0 Z0 I (170403672) ovms-server-v2: Send MP-0 S70.0,M,65535,127,stopped,standard,166,146,32,0,0,2100,7,21,0,0,0,0,0.00,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,0.00,0 I (170403672) ovms-server-v2: Send MP-0 D65,0,5,23,23,24,587,516256,0,170403,24,0,1,1,11.63,0,12.6,0,23,0 I (170403672) ovms-server-v2: Send MP-0 L37.346340,-122.037308,206,64,1,1,0,0,0.0,0,0 I (170403682) ovms-server-v2: Send MP-0 F3.1.008/ota_0/main (build idf v3.1-dev-986-g1a1a544a Jun 26 2018 09:30:21),5YJRE11B181000033,7,1,TR1N,AT&T Hologram OVMS# wifi mode client Revelstoke Starting WIFI as a client to Revelstoke... I (170432062) wifi: mode : sta (30:ae:a4:43:9c:28) I (170434462) wifi: n:1 0, o:1 0, ap:255 255, sta:1 0, prof:1 I (170435152) wifi: state: init -> auth (b0) I (170435162) wifi: state: auth -> assoc (0) I (170435162) wifi: state: assoc -> run (10) I (170435202) wifi: connected with Revelstoke, channel 1 I (170435202) wifi: pm start, type: 1 I (170438872) event: sta ip: 192.168.1.82, mask: 255.255.255.0, gw: 192.168.1.254 I (170438872) netmanager: Interface priority is st4 (192.168.1.82/255.255.255.0 gateway 192.168.1.254) I (170438872) netmanager: Set DNS#0 8.8.8.8 I (170438872) netmanager: Set DNS#1 8.8.4.4 I (170438872) netmanager: WIFI client up (with MODEM up): reconfigured for WIFI client priority I (170438872) esp32wifi: STA got IP with SSID: Revelstoke, MAC: 30:ae:a4:43:9c:28, IP: 192.168.1.82, mask: 255.255.255.0, gw: 192.168.1.254 I (170438882) time: Network was reconfigured: restarting SNTP client I (170438882) ovms-server-v2: Network was reconfigured: disconnect, and reconnect in 10 seconds I (170438882) ovms-server-v2: Status: Network was reconfigured: disconnect, and reconnect in 10 seconds I (170439082) ovms-server-v2: Status: Disconnected I (170451362) webserver: HTTP GET / I (170451572) webserver: HTTP GET /apple-touch-icon.png I (170451842) webserver: HTTP GET /status I (170458672) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 I (170458672) ovms-server-v2: Status: Connecting... I (170458902) ovms-server-v2: Connection successful I (170458902) ovms-server-v2: Status: Logging in... I (170458902) ovms-server-v2: Sending server login: MP-C 0 zSgUQypXKd9tYDq7XuHf8m Raby/geQppSUPG5l9NRztw== US33 I (170458922) webserver: HTTP POST /status I (170458922) webserver: HandleLogin: 'admin' logged in, sid 6ea0f4c3207e3328 I (170459342) ovms-server-v2: Got server response: MP-S 0 ooMhIGTk/0ZEvxVpwoHZ4d 4d+RTkaUZ1onzxLyxVwYEQ== I (170459342) ovms-server-v2: Server token is ooMhIGTk/0ZEvxVpwoHZ4d and digest is 4d+RTkaUZ1onzxLyxVwYEQ== I (170459342) ovms-server-v2: Status: Server authentication ok. Now priming crypto. I (170459342) ovms-server-v2: Shared secret key is ooMhIGTk/0ZEvxVpwoHZ4dzSgUQypXKd9tYDq7XuHf8m (44 bytes) I (170459342) ovms-server-v2: Status: OVMS V2 login successful, and crypto channel established I (170459352) ovms-server-v2: Incoming Msg: MP-0 Z0 I (170459352) webserver: HTTP GET /status I (170459392) webserver: HTTP GET /menu _______________________________________________ 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
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Greg, Mark, It would be nice if it had a direct effect, would be reproducable then… :-) Every crash event of this kind I had and got reported involved some sort of poor wifi situation. But the module still resolves >99% of those situations without a crash.
Feature wise it is fine. Just trying to find out the cause of these crashes, and if they are worse in recent edge builds vs main 3.1.008.
From my crash statistics (*-OVM-DebugCrash = 1 month): * 3.1.008: 30 cars, 878 crashes => 29 crashes per car * >= 3.1.008-73 (idf v3.2): 13 cars, 39 crashes => 3 crashes per car There should be more data available on your server. My crash statistics query: SELECT v.version, v.cars, c.crashes, c.crashes/v.cars AS crashratio FROM ( SELECT LEFT(m_msg, INSTR(m_msg,'/')-1) AS version, COUNT(*) AS cars FROM ovms_carmessages WHERE m_code='F' AND m_msg LIKE '%build idf%' GROUP BY version ) v LEFT JOIN ( SELECT LEFT(h_data, INSTR(h_data,'/')-1) AS version, COUNT(*) AS crashes FROM ovms_historicalmessages WHERE h_recordtype='*-OVM-DebugCrash' AND h_data LIKE '%build idf%' GROUP BY version ) c ON c.version = v.version GROUP BY v.version Regards, Michael Am 03.08.2018 um 03:26 schrieb Greg D.:
My feeling is that we don't have enough information to really know, and what we know is inconsistent. I had a couple of wireless and internet "burps" yesterday and today (my router rebooted itself, and separately, the modem dropped link a time or two), yet no further issues from the OVMS module. So, I am skeptical what direct effect wi-fi has on the reboots.
I think the best bet is to push 3.1.009 out, when it is otherwise ready, and gather more information on the issue.
Greg
Mark Webb-Johnson wrote:
Feature wise it is fine. Just trying to find out the cause of these crashes, and if they are worse in recent edge builds vs main 3.1.008.
Regards, Mark
On 2 Aug 2018, at 2:54 PM, Stephen Casner <casner@acm.org> wrote:
Michael,
Will 009 be ready for main soon? I could switch to edge, but my friend in Santa Barbara needs it too, and edge would not be good for him.
-- Steve
On Wed, 1 Aug 2018, Michael Balzer wrote:
Steve, Greg,
you're both still on the 3.1.008 main release, please check out the edge build.
Your crashes look very familiar to me, I assume they are wifi related. The "esf_buf" error log Steve had is coming from within the wifi blob, and the latest edge build includes many fixes to that. That build reduced those crashes in the Twizy community by about 90%.
Regarding logging, this is my base config:
level: debug level.gsm-ppp: debug level.simcom: debug level.time: info level.v-twizy: verbose ← change accordingly level.webserver: debug
If I need more detail I simply switch the default level to verbose.
Regards, Michael
Am 01.08.2018 um 08:40 schrieb Greg D.:
Well, we seem to be on a roll... Got another one.
I just realized that I have an SD card in the module, but am not logging anything. What logging should I be setting up to capture additional information?
Greg
Last boot was 2153 second(s) ago Time at boot: 2018-07-31 23:01:39 PDT This is reset #20 since last power cycle Detected boot reason: Crash (12/12) Crash counters: 2 total, 0 early Last crash: Alloca exception on core 0 Registers: PC : 0x40081b96 PS : 0x00060634 A0 : 0x80081d61 A1 : 0x3ffafa60 A2 : 0x3ffb43e4 A3 : 0x00000001 A4 : 0x00000050 A5 : 0x00000001 A6 : 0x000000fe A7 : 0x000000a0 A8 : 0x00000081 A9 : 0x00000001 A10 : 0x0000cdcd A11 : 0x00000000 A12 : 0x3f40819c A13 : 0x3f407ebe A14 : 0x000000fe A15 : 0x00060023 SAR : 0x00000000 EXCCAUSE: 0x00000005 EXCVADDR: 0x00000000 LBEG : 0x40097664 LEND : 0x40097692 LCOUNT : 0xffffffff Backtrace: 0x40081b96 0x40081d5e 0x400db815 0x40174f95 0x400e73be 0x400e4699 0x40085149 0x40128bc2 0x40128df7 0x401287b4 0x400ea22d 0x400eac7a 0x400ead09 0x400ead19 0x402207d6 0x400e9ece 0x400e9f79 0x400e45f5 0x400e4604 0x400f5c09 0x400f035d Version: 3.1.008/ota_1/main (build idf v3.1-dev-986-g1a1a544a Jun 26 2018 09:30:21) ---------------------------------------------------------------------------------------------------------------------------------------------------------------- Running partition: ota_1 Boot partition: ota_1 Firmware: 3.1.008/ota_1/main (build idf v3.1-dev-986-g1a1a544a Jun 26 2018 09:30:21)
Greg D. wrote:
Hi Steve,
Ok, so, still a puzzle as to why the crashes. Fortunately, I've only had the one. I've not had any trouble losing wifi connectivity, either when the car's been sitting in the garage for a few days, or coming and going on errands (so, transitioning to cell and back). Prior to this, I think the last boot was the upgrade to 3.1.008. Oh, perhaps the car's recent near death experience (*) cycled power? Not sure, but probably did. Anyway, in general, I've not had trouble with connectivity in a long time.
The only thing I've noticed is that sometimes I have a rather long delay between an event (e.g. when the car starts charging) and having it show up on my cell phone. Usually I get it immediately, but some time it's delayed several minutes, and once in a while it never shows up (e.g. charging started but never finished). It might simply be packet loss on my Internet connection (it's fast, but sometimes leaky), not related to wi-fi. I get delays at times on the PC going to websites too.
{shrug}
Greg
(*) For some reason, the VMS lost connectivity to the VDS, and the car locked up. Fortunately it was in the garage, and the windows were rolled down since the door opening switches stopped working too. Had to unplug the cables to the VMS under the dash and plug them back in to force a reboot. {phew!}
Stephen Casner wrote: > On Sun, 29 Jul 2018, Greg D. wrote: > >> Hi Steve, >> >> Interesting...? I just got a very cryptic "event" from my car:? >> Not charging >> SOC:- > I believe it is expected to get that event when OVMS boots while the > car is idle since "not charging" is an accurate description of the > state. > > I received a "not charging" notification on Sunday as well, > coincidentally as we were approaching home in our RAV4-EV. This > resulted from another "Alloca exception on core 0" crash and reboot of > OVMS: > > Last boot was 170458 second(s) ago > Time at boot: 2018-07-29 21:41:32 GMT > This is reset #7 since last power cycle > Detected boot reason: Crash (8/14) > Crash counters: 2 total, 0 early > > Last crash: Alloca exception on core 0 > > This is not the same time as yours (2018-07-29 17:55:36 PDT) so it > does not appear that the crashes are synchronized by some external > event. > > Then today I looked at the iPhone app and saw that my OVMS had not > communicated with the v2 server for 15 hours. So I connected to the > USB cable again and found that the wifi was again in trouble. This > time there were many instances of a new error message from wifi that I > had not seen before, as shown in the log below. > > Again I was able to restore operation of both server v2 and http by > "wifi mode off" then "wifi mode client". > > -- Steve > > E (170324792) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb > E (170325752) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb > E (170328632) ovms-server-v2: mg_connect(api.openvehicles.com:6867) failed: cannot parse address| > E (170328632) ovms-server-v2: Status: Error: Connection failed > E (170329542) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb > E (170333742) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb > E (170333742) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb > E (170333742) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb > E (170333752) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb > E (170333752) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb > E (170333752) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb > E (170333752) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb > E (170333752) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb > E (170333752) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb > E (170333762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb > E (170333762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb > E (170335592) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb > I (170335672) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 > I (170335672) ovms-server-v2: Status: Connecting... > E (170335672) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb > E (170336312) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb > E (170337272) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb > E (170338232) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb > E (170339192) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb > E (170340152) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb > E (170341112) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb > E (170342072) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb > E (170343032) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb > OVMS> ena > Password: > E (170343992) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb > E (170344702) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb > E (170345912) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb > E (170346232) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb > E (170346872) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb > E (170347262) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb > OVMS# > E (170347832) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb > E (170348792) ovms-server-v2: mg_connect(api.openvehicles.com:6867) failed: cannot parse address| > E (170348792) ovms-server-v2: Status: Error: Connection failed > E (170348792) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb > E (170349752) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb > E (170350832) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb > E (170353802) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb > E (170353802) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb > E (170353802) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb > E (170353802) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb > E (170353812) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb > E (170353812) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb > E (170353812) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb > E (170353812) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb > E (170353812) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb > E (170353812) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb > E (170353812) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb > E (170353822) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb > E (170353822) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb > E (170353822) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb > E (170353822) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb > E (170353832) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb > E (170353832) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb > E (170353832) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb > E (170353832) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb > I (170355672) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 > I (170355672) ovms-server-v2: Status: Connecting... > E (170355672) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb > E (170356472) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb > E (170357432) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb > E (170358392) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb > E (170359352) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb > E (170359842) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb > E (170360862) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb > E (170362232) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb > E (170362922) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb > E (170363192) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb > E (170364152) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb > E (170365112) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb > E (170366072) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb > E (170368952) ovms-server-v2: mg_connect(api.openvehicles.com:6867) failed: cannot parse address| > E (170368952) ovms-server-v2: Status: Error: Connection failed > E (170372022) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb > E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb > E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb > E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb > E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb > E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb > E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb > E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb > E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb > E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb > E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb > E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb > E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb > E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb > E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb > E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb > E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb > E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb > E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb > E (170373782) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb > E (170373782) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb > E (170373782) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb > E (170373782) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb > E (170373782) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb > E (170373782) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb > E (170374992) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb > E (170375672) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb > E (170375672) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb > I (170375672) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 > I (170375672) ovms-server-v2: Status: Connecting... > E (170376632) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb > E (170377592) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb > E (170378062) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb > E (170378552) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb > E (170379512) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb > E (170380472) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb > E (170381432) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb > E (170382392) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb > OVMS# wifi mode off > Stopping wifi station... > I (170383222) esp32wifi: Stopping WIFI station > I (170383222) wifi: state: run -> init (0) > I (170383222) wifi: pm stop, total sleep time: 47593209375 us / 59459320714 us > I (170383222) wifi: n:1 0, o:1 1, ap:1 1, sta:1 0, prof:1 > I (170383232) wifi: flush txq > I (170383232) wifi: stop sw txq > I (170383232) wifi: lmac stop hw txq > E (170389112) ovms-server-v2: mg_connect(api.openvehicles.com:6867) failed: cannot parse address| > E (170389112) ovms-server-v2: Status: Error: Connection failed > I (170389112) netmanager: Interface priority is pp3 (10.170.41.247/255.255.255.255 gateway 10.64.64.64) > I (170389112) netmanager: Set DNS#0 8.8.8.8 > I (170389112) netmanager: Set DNS#1 8.8.4.4 > I (170389112) netmanager: WIFI client down (with MODEM up): reconfigured for MODEM priority > I (170389122) netmanager: Interface priority is pp3 (10.170.41.247/255.255.255.255 gateway 10.64.64.64) > I (170389122) netmanager: Set DNS#0 8.8.8.8 > I (170389122) netmanager: Set DNS#1 8.8.4.4 > I (170389122) esp32wifi: STA disconnected with reason 8 > W (170389122) netmanager: CleanupConnections: can't get AP station list > I (170389122) netmanager: Interface priority is pp3 (10.170.41.247/255.255.255.255 gateway 10.64.64.64) > I (170389122) netmanager: Set DNS#0 8.8.8.8 > I (170389122) netmanager: Set DNS#1 8.8.4.4 > I (170389132) netmanager: Interface priority is pp3 (10.170.41.247/255.255.255.255 gateway 10.64.64.64) > I (170389132) netmanager: Set DNS#0 8.8.8.8 > I (170389132) netmanager: Set DNS#1 8.8.4.4 > I (170389132) netmanager: WIFI access point is down > I (170389132) esp32wifi: AP stopped > I (170389132) netmanager: CleanupConnections: closing conn 3f81dbbc: interface/link down > I (170389142) netmanager: CleanupConnections: closing conn 3f81dbbc: interface/link down > I (170389142) time: Network was reconfigured: restarting SNTP client > I (170389142) ovms-server-v2: Network was reconfigured: disconnect, and reconnect in 10 seconds > I (170389142) ovms-server-v2: Status: Network was reconfigured: disconnect, and reconnect in 10 seconds > I (170389152) netmanager: CleanupConnections: closing conn 3f81dbbc: interface/link down > I (170398672) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 > I (170398672) ovms-server-v2: Status: Connecting... > I (170401312) housekeeping: 2018-07-31 21:01:32 GMT (RAM: 8b=113788-152956 32b=28252) > I (170402032) ovms-server-v2: Connection successful > I (170402032) ovms-server-v2: Status: Logging in... > I (170402032) ovms-server-v2: Sending server login: MP-C 0 xR/s7da9YTwJ+uKH0C2zRl VXtWmVfsQQjJCe4+AwK74w== US33 > I (170402852) ovms-server-v2: Got server response: MP-S 0 1uDt9VTVDl5jzvSqsIwmtN isXmd3Gy2AcrvhQVrX3LAA== > I (170402852) ovms-server-v2: Server token is 1uDt9VTVDl5jzvSqsIwmtN and digest is isXmd3Gy2AcrvhQVrX3LAA== > I (170402852) ovms-server-v2: Status: Server authentication ok. Now priming crypto. > I (170402852) ovms-server-v2: Shared secret key is 1uDt9VTVDl5jzvSqsIwmtNxR/s7da9YTwJ+uKH0C2zRl (44 bytes) > I (170402852) ovms-server-v2: Status: OVMS V2 login successful, and crypto channel established > I (170402872) ovms-server-v2: Incoming Msg: MP-0 Z0 > I (170403672) ovms-server-v2: Send MP-0 S70.0,M,65535,127,stopped,standard,166,146,32,0,0,2100,7,21,0,0,0,0,0.00,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,0.00,0 > I (170403672) ovms-server-v2: Send MP-0 D65,0,5,23,23,24,587,516256,0,170403,24,0,1,1,11.63,0,12.6,0,23,0 > I (170403672) ovms-server-v2: Send MP-0 L37.346340,-122.037308,206,64,1,1,0,0,0.0,0,0 > I (170403682) ovms-server-v2: Send MP-0 F3.1.008/ota_0/main (build idf v3.1-dev-986-g1a1a544a Jun 26 2018 09:30:21),5YJRE11B181000033,7,1,TR1N,AT&T Hologram > OVMS# wifi mode client Revelstoke > Starting WIFI as a client to Revelstoke... > I (170432062) wifi: mode : sta (30:ae:a4:43:9c:28) > I (170434462) wifi: n:1 0, o:1 0, ap:255 255, sta:1 0, prof:1 > I (170435152) wifi: state: init -> auth (b0) > I (170435162) wifi: state: auth -> assoc (0) > I (170435162) wifi: state: assoc -> run (10) > I (170435202) wifi: connected with Revelstoke, channel 1 > I (170435202) wifi: pm start, type: 1 > I (170438872) event: sta ip: 192.168.1.82, mask: 255.255.255.0, gw: 192.168.1.254 > I (170438872) netmanager: Interface priority is st4 (192.168.1.82/255.255.255.0 gateway 192.168.1.254) > I (170438872) netmanager: Set DNS#0 8.8.8.8 > I (170438872) netmanager: Set DNS#1 8.8.4.4 > I (170438872) netmanager: WIFI client up (with MODEM up): reconfigured for WIFI client priority > I (170438872) esp32wifi: STA got IP with SSID: Revelstoke, MAC: 30:ae:a4:43:9c:28, IP: 192.168.1.82, mask: 255.255.255.0, gw: 192.168.1.254 > I (170438882) time: Network was reconfigured: restarting SNTP client > I (170438882) ovms-server-v2: Network was reconfigured: disconnect, and reconnect in 10 seconds > I (170438882) ovms-server-v2: Status: Network was reconfigured: disconnect, and reconnect in 10 seconds > I (170439082) ovms-server-v2: Status: Disconnected > I (170451362) webserver: HTTP GET / > I (170451572) webserver: HTTP GET /apple-touch-icon.png > I (170451842) webserver: HTTP GET /status > I (170458672) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 > I (170458672) ovms-server-v2: Status: Connecting... > I (170458902) ovms-server-v2: Connection successful > I (170458902) ovms-server-v2: Status: Logging in... > I (170458902) ovms-server-v2: Sending server login: MP-C 0 zSgUQypXKd9tYDq7XuHf8m Raby/geQppSUPG5l9NRztw== US33 > I (170458922) webserver: HTTP POST /status > I (170458922) webserver: HandleLogin: 'admin' logged in, sid 6ea0f4c3207e3328 > I (170459342) ovms-server-v2: Got server response: MP-S 0 ooMhIGTk/0ZEvxVpwoHZ4d 4d+RTkaUZ1onzxLyxVwYEQ== > I (170459342) ovms-server-v2: Server token is ooMhIGTk/0ZEvxVpwoHZ4d and digest is 4d+RTkaUZ1onzxLyxVwYEQ== > I (170459342) ovms-server-v2: Status: Server authentication ok. Now priming crypto. > I (170459342) ovms-server-v2: Shared secret key is ooMhIGTk/0ZEvxVpwoHZ4dzSgUQypXKd9tYDq7XuHf8m (44 bytes) > I (170459342) ovms-server-v2: Status: OVMS V2 login successful, and crypto channel established > I (170459352) ovms-server-v2: Incoming Msg: MP-0 Z0 > I (170459352) webserver: HTTP GET /status > I (170459392) webserver: HTTP GET /menu > _______________________________________________ > 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
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
Greg, the wifi signal level is shown in the status UI and available in metric m.net.sq (when m.net.type is wifi) since commit 925417081d8e1b4a952bca26d98bec8753623fb8. I've just added it to the "wifi status" output as well. The wifi internal logging is beyond our control. I just had a loss of the wifi client connectivity, with AP mode still working. The wifi status said it was connected to my network, but my network said it wasn't. The wifi logging had gone completely silent after looping in 201 errors for some hours with these final words: I (164063432) esp32wifi: STA disconnected with reason 201 … I (164073402) wifi: n:1 1, o:1 0, ap:1 1, sta:1 0, prof:1 I (164073412) wifi: state: init -> auth (b0) I (164073422) wifi: state: auth -> assoc (0) I (164073452) wifi: state: assoc -> run (10) … I (164788102) wifi: bcn_timout,ap_probe_send_start …signal level was fine, just no association. Stopping and restarting the apclient mode fixed it. Regards, Michael Am 04.08.2018 um 19:10 schrieb Greg D.:
Hi Michael,
I guess my point about not being able to reproduce the crash, and the few events that we have had, suggests that putting the Edge build on my and Steve's cars isn't going to give us any real data in terms of stability, at least not on a timeline that would make a difference for the release of 3.1.009. (Lordy, that was a long sentence...) We need more test cases in order to narrow down what the significant cause (or causes) of the crash is.
One thing I notice... If the issue truly is related to WiFi reception, it would be handy to have a better idea of what the module is hearing. The modem status lists the received signal level; how does one find that for Wi-Fi? Can we put some additional (focused) logging into 3.1.009 to help?
Greg
Michael Balzer wrote:
Greg, Mark,
It would be nice if it had a direct effect, would be reproducable then… :-)
Every crash event of this kind I had and got reported involved some sort of poor wifi situation. But the module still resolves >99% of those situations without a crash.
Feature wise it is fine. Just trying to find out the cause of these crashes, and if they are worse in recent edge builds vs main 3.1.008.
From my crash statistics (*-OVM-DebugCrash = 1 month):
* 3.1.008: 30 cars, 878 crashes => 29 crashes per car * >= 3.1.008-73 (idf v3.2): 13 cars, 39 crashes => 3 crashes per car
There should be more data available on your server.
My crash statistics query:
SELECT v.version, v.cars, c.crashes, c.crashes/v.cars AS crashratio FROM ( SELECT LEFT(m_msg, INSTR(m_msg,'/')-1) AS version, COUNT(*) AS cars FROM ovms_carmessages WHERE m_code='F' AND m_msg LIKE '%build idf%' GROUP BY version ) v LEFT JOIN ( SELECT LEFT(h_data, INSTR(h_data,'/')-1) AS version, COUNT(*) AS crashes FROM ovms_historicalmessages WHERE h_recordtype='*-OVM-DebugCrash' AND h_data LIKE '%build idf%' GROUP BY version ) c ON c.version = v.version GROUP BY v.version
Regards, Michael
Am 03.08.2018 um 03:26 schrieb Greg D.:
My feeling is that we don't have enough information to really know, and what we know is inconsistent. I had a couple of wireless and internet "burps" yesterday and today (my router rebooted itself, and separately, the modem dropped link a time or two), yet no further issues from the OVMS module. So, I am skeptical what direct effect wi-fi has on the reboots.
I think the best bet is to push 3.1.009 out, when it is otherwise ready, and gather more information on the issue.
Greg
Mark Webb-Johnson wrote:
Feature wise it is fine. Just trying to find out the cause of these crashes, and if they are worse in recent edge builds vs main 3.1.008.
Regards, Mark
On 2 Aug 2018, at 2:54 PM, Stephen Casner <casner@acm.org> wrote:
Michael,
Will 009 be ready for main soon? I could switch to edge, but my friend in Santa Barbara needs it too, and edge would not be good for him.
-- Steve
On Wed, 1 Aug 2018, Michael Balzer wrote:
Steve, Greg,
you're both still on the 3.1.008 main release, please check out the edge build.
Your crashes look very familiar to me, I assume they are wifi related. The "esf_buf" error log Steve had is coming from within the wifi blob, and the latest edge build includes many fixes to that. That build reduced those crashes in the Twizy community by about 90%.
Regarding logging, this is my base config:
level: debug level.gsm-ppp: debug level.simcom: debug level.time: info level.v-twizy: verbose ← change accordingly level.webserver: debug
If I need more detail I simply switch the default level to verbose.
Regards, Michael
Am 01.08.2018 um 08:40 schrieb Greg D.: > Well, we seem to be on a roll... Got another one. > > I just realized that I have an SD card in the module, but am not logging anything. What logging should I be setting up to capture additional information? > > Greg > > Last boot was 2153 second(s) ago Time at boot: 2018-07-31 23:01:39 PDT This is reset #20 since last power cycle Detected boot reason: Crash (12/12) Crash > counters: 2 total, 0 early Last crash: Alloca exception on core 0 Registers: PC : 0x40081b96 PS : 0x00060634 A0 : 0x80081d61 A1 : 0x3ffafa60 A2 : 0x3ffb43e4 > A3 : 0x00000001 A4 : 0x00000050 A5 : 0x00000001 A6 : 0x000000fe A7 : 0x000000a0 A8 : 0x00000081 A9 : 0x00000001 A10 : 0x0000cdcd A11 : 0x00000000 A12 : > 0x3f40819c A13 : 0x3f407ebe A14 : 0x000000fe A15 : 0x00060023 SAR : 0x00000000 EXCCAUSE: 0x00000005 EXCVADDR: 0x00000000 LBEG : 0x40097664 LEND : 0x40097692 > LCOUNT : 0xffffffff Backtrace: 0x40081b96 0x40081d5e 0x400db815 0x40174f95 0x400e73be 0x400e4699 0x40085149 0x40128bc2 0x40128df7 0x401287b4 0x400ea22d > 0x400eac7a 0x400ead09 0x400ead19 0x402207d6 0x400e9ece 0x400e9f79 0x400e45f5 0x400e4604 0x400f5c09 0x400f035d Version: 3.1.008/ota_1/main (build idf > v3.1-dev-986-g1a1a544a Jun 26 2018 09:30:21) > ---------------------------------------------------------------------------------------------------------------------------------------------------------------- > Running partition: ota_1 Boot partition: ota_1 Firmware: 3.1.008/ota_1/main (build idf v3.1-dev-986-g1a1a544a Jun 26 2018 09:30:21) > > > > Greg D. wrote: >> Hi Steve, >> >> Ok, so, still a puzzle as to why the crashes. Fortunately, I've only >> had the one. I've not had any trouble losing wifi connectivity, either >> when the car's been sitting in the garage for a few days, or coming and >> going on errands (so, transitioning to cell and back). Prior to this, I >> think the last boot was the upgrade to 3.1.008. Oh, perhaps the car's >> recent near death experience (*) cycled power? Not sure, but probably >> did. Anyway, in general, I've not had trouble with connectivity in a >> long time. >> >> The only thing I've noticed is that sometimes I have a rather long delay >> between an event (e.g. when the car starts charging) and having it show >> up on my cell phone. Usually I get it immediately, but some time it's >> delayed several minutes, and once in a while it never shows up (e.g. >> charging started but never finished). It might simply be packet loss on >> my Internet connection (it's fast, but sometimes leaky), not related to >> wi-fi. I get delays at times on the PC going to websites too. >> >> {shrug} >> >> Greg >> >> (*) For some reason, the VMS lost connectivity to the VDS, and the car >> locked up. Fortunately it was in the garage, and the windows were >> rolled down since the door opening switches stopped working too. Had to >> unplug the cables to the VMS under the dash and plug them back in to >> force a reboot. {phew!} >> >> >> Stephen Casner wrote: >>> On Sun, 29 Jul 2018, Greg D. wrote: >>> >>>> Hi Steve, >>>> >>>> Interesting...? I just got a very cryptic "event" from my car:? >>>> Not charging >>>> SOC:- >>> I believe it is expected to get that event when OVMS boots while the >>> car is idle since "not charging" is an accurate description of the >>> state. >>> >>> I received a "not charging" notification on Sunday as well, >>> coincidentally as we were approaching home in our RAV4-EV. This >>> resulted from another "Alloca exception on core 0" crash and reboot of >>> OVMS: >>> >>> Last boot was 170458 second(s) ago >>> Time at boot: 2018-07-29 21:41:32 GMT >>> This is reset #7 since last power cycle >>> Detected boot reason: Crash (8/14) >>> Crash counters: 2 total, 0 early >>> >>> Last crash: Alloca exception on core 0 >>> >>> This is not the same time as yours (2018-07-29 17:55:36 PDT) so it >>> does not appear that the crashes are synchronized by some external >>> event. >>> >>> Then today I looked at the iPhone app and saw that my OVMS had not >>> communicated with the v2 server for 15 hours. So I connected to the >>> USB cable again and found that the wifi was again in trouble. This >>> time there were many instances of a new error message from wifi that I >>> had not seen before, as shown in the log below. >>> >>> Again I was able to restore operation of both server v2 and http by >>> "wifi mode off" then "wifi mode client". >>> >>> -- Steve >>> >>> E (170324792) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >>> E (170325752) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >>> E (170328632) ovms-server-v2: mg_connect(api.openvehicles.com:6867) failed: cannot parse address| >>> E (170328632) ovms-server-v2: Status: Error: Connection failed >>> E (170329542) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170333742) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170333742) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170333742) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170333752) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170333752) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170333752) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170333752) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170333752) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170333752) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170333762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170333762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170335592) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> I (170335672) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 >>> I (170335672) ovms-server-v2: Status: Connecting... >>> E (170335672) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >>> E (170336312) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >>> E (170337272) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >>> E (170338232) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >>> E (170339192) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >>> E (170340152) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >>> E (170341112) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >>> E (170342072) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >>> E (170343032) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >>> OVMS> ena >>> Password: >>> E (170343992) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >>> E (170344702) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170345912) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >>> E (170346232) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170346872) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >>> E (170347262) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> OVMS# >>> E (170347832) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >>> E (170348792) ovms-server-v2: mg_connect(api.openvehicles.com:6867) failed: cannot parse address| >>> E (170348792) ovms-server-v2: Status: Error: Connection failed >>> E (170348792) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >>> E (170349752) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >>> E (170350832) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170353802) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170353802) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170353802) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170353802) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170353812) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170353812) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170353812) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170353812) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170353812) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170353812) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170353812) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170353822) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170353822) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170353822) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170353822) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170353832) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170353832) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170353832) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170353832) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> I (170355672) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 >>> I (170355672) ovms-server-v2: Status: Connecting... >>> E (170355672) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >>> E (170356472) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >>> E (170357432) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >>> E (170358392) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >>> E (170359352) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >>> E (170359842) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170360862) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170362232) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >>> E (170362922) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170363192) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >>> E (170364152) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >>> E (170365112) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >>> E (170366072) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >>> E (170368952) ovms-server-v2: mg_connect(api.openvehicles.com:6867) failed: cannot parse address| >>> E (170368952) ovms-server-v2: Status: Error: Connection failed >>> E (170372022) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170373782) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170373782) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170373782) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170373782) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170373782) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170373782) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170374992) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170375672) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >>> E (170375672) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >>> I (170375672) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 >>> I (170375672) ovms-server-v2: Status: Connecting... >>> E (170376632) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >>> E (170377592) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >>> E (170378062) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170378552) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >>> E (170379512) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >>> E (170380472) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >>> E (170381432) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >>> E (170382392) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >>> OVMS# wifi mode off >>> Stopping wifi station... >>> I (170383222) esp32wifi: Stopping WIFI station >>> I (170383222) wifi: state: run -> init (0) >>> I (170383222) wifi: pm stop, total sleep time: 47593209375 us / 59459320714 us >>> I (170383222) wifi: n:1 0, o:1 1, ap:1 1, sta:1 0, prof:1 >>> I (170383232) wifi: flush txq >>> I (170383232) wifi: stop sw txq >>> I (170383232) wifi: lmac stop hw txq >>> E (170389112) ovms-server-v2: mg_connect(api.openvehicles.com:6867) failed: cannot parse address| >>> E (170389112) ovms-server-v2: Status: Error: Connection failed >>> I (170389112) netmanager: Interface priority is pp3 (10.170.41.247/255.255.255.255 gateway 10.64.64.64) >>> I (170389112) netmanager: Set DNS#0 8.8.8.8 >>> I (170389112) netmanager: Set DNS#1 8.8.4.4 >>> I (170389112) netmanager: WIFI client down (with MODEM up): reconfigured for MODEM priority >>> I (170389122) netmanager: Interface priority is pp3 (10.170.41.247/255.255.255.255 gateway 10.64.64.64) >>> I (170389122) netmanager: Set DNS#0 8.8.8.8 >>> I (170389122) netmanager: Set DNS#1 8.8.4.4 >>> I (170389122) esp32wifi: STA disconnected with reason 8 >>> W (170389122) netmanager: CleanupConnections: can't get AP station list >>> I (170389122) netmanager: Interface priority is pp3 (10.170.41.247/255.255.255.255 gateway 10.64.64.64) >>> I (170389122) netmanager: Set DNS#0 8.8.8.8 >>> I (170389122) netmanager: Set DNS#1 8.8.4.4 >>> I (170389132) netmanager: Interface priority is pp3 (10.170.41.247/255.255.255.255 gateway 10.64.64.64) >>> I (170389132) netmanager: Set DNS#0 8.8.8.8 >>> I (170389132) netmanager: Set DNS#1 8.8.4.4 >>> I (170389132) netmanager: WIFI access point is down >>> I (170389132) esp32wifi: AP stopped >>> I (170389132) netmanager: CleanupConnections: closing conn 3f81dbbc: interface/link down >>> I (170389142) netmanager: CleanupConnections: closing conn 3f81dbbc: interface/link down >>> I (170389142) time: Network was reconfigured: restarting SNTP client >>> I (170389142) ovms-server-v2: Network was reconfigured: disconnect, and reconnect in 10 seconds >>> I (170389142) ovms-server-v2: Status: Network was reconfigured: disconnect, and reconnect in 10 seconds >>> I (170389152) netmanager: CleanupConnections: closing conn 3f81dbbc: interface/link down >>> I (170398672) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 >>> I (170398672) ovms-server-v2: Status: Connecting... >>> I (170401312) housekeeping: 2018-07-31 21:01:32 GMT (RAM: 8b=113788-152956 32b=28252) >>> I (170402032) ovms-server-v2: Connection successful >>> I (170402032) ovms-server-v2: Status: Logging in... >>> I (170402032) ovms-server-v2: Sending server login: MP-C 0 xR/s7da9YTwJ+uKH0C2zRl VXtWmVfsQQjJCe4+AwK74w== US33 >>> I (170402852) ovms-server-v2: Got server response: MP-S 0 1uDt9VTVDl5jzvSqsIwmtN isXmd3Gy2AcrvhQVrX3LAA== >>> I (170402852) ovms-server-v2: Server token is 1uDt9VTVDl5jzvSqsIwmtN and digest is isXmd3Gy2AcrvhQVrX3LAA== >>> I (170402852) ovms-server-v2: Status: Server authentication ok. Now priming crypto. >>> I (170402852) ovms-server-v2: Shared secret key is 1uDt9VTVDl5jzvSqsIwmtNxR/s7da9YTwJ+uKH0C2zRl (44 bytes) >>> I (170402852) ovms-server-v2: Status: OVMS V2 login successful, and crypto channel established >>> I (170402872) ovms-server-v2: Incoming Msg: MP-0 Z0 >>> I (170403672) ovms-server-v2: Send MP-0 S70.0,M,65535,127,stopped,standard,166,146,32,0,0,2100,7,21,0,0,0,0,0.00,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,0.00,0 >>> I (170403672) ovms-server-v2: Send MP-0 D65,0,5,23,23,24,587,516256,0,170403,24,0,1,1,11.63,0,12.6,0,23,0 >>> I (170403672) ovms-server-v2: Send MP-0 L37.346340,-122.037308,206,64,1,1,0,0,0.0,0,0 >>> I (170403682) ovms-server-v2: Send MP-0 F3.1.008/ota_0/main (build idf v3.1-dev-986-g1a1a544a Jun 26 2018 09:30:21),5YJRE11B181000033,7,1,TR1N,AT&T Hologram >>> OVMS# wifi mode client Revelstoke >>> Starting WIFI as a client to Revelstoke... >>> I (170432062) wifi: mode : sta (30:ae:a4:43:9c:28) >>> I (170434462) wifi: n:1 0, o:1 0, ap:255 255, sta:1 0, prof:1 >>> I (170435152) wifi: state: init -> auth (b0) >>> I (170435162) wifi: state: auth -> assoc (0) >>> I (170435162) wifi: state: assoc -> run (10) >>> I (170435202) wifi: connected with Revelstoke, channel 1 >>> I (170435202) wifi: pm start, type: 1 >>> I (170438872) event: sta ip: 192.168.1.82, mask: 255.255.255.0, gw: 192.168.1.254 >>> I (170438872) netmanager: Interface priority is st4 (192.168.1.82/255.255.255.0 gateway 192.168.1.254) >>> I (170438872) netmanager: Set DNS#0 8.8.8.8 >>> I (170438872) netmanager: Set DNS#1 8.8.4.4 >>> I (170438872) netmanager: WIFI client up (with MODEM up): reconfigured for WIFI client priority >>> I (170438872) esp32wifi: STA got IP with SSID: Revelstoke, MAC: 30:ae:a4:43:9c:28, IP: 192.168.1.82, mask: 255.255.255.0, gw: 192.168.1.254 >>> I (170438882) time: Network was reconfigured: restarting SNTP client >>> I (170438882) ovms-server-v2: Network was reconfigured: disconnect, and reconnect in 10 seconds >>> I (170438882) ovms-server-v2: Status: Network was reconfigured: disconnect, and reconnect in 10 seconds >>> I (170439082) ovms-server-v2: Status: Disconnected >>> I (170451362) webserver: HTTP GET / >>> I (170451572) webserver: HTTP GET /apple-touch-icon.png >>> I (170451842) webserver: HTTP GET /status >>> I (170458672) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 >>> I (170458672) ovms-server-v2: Status: Connecting... >>> I (170458902) ovms-server-v2: Connection successful >>> I (170458902) ovms-server-v2: Status: Logging in... >>> I (170458902) ovms-server-v2: Sending server login: MP-C 0 zSgUQypXKd9tYDq7XuHf8m Raby/geQppSUPG5l9NRztw== US33 >>> I (170458922) webserver: HTTP POST /status >>> I (170458922) webserver: HandleLogin: 'admin' logged in, sid 6ea0f4c3207e3328 >>> I (170459342) ovms-server-v2: Got server response: MP-S 0 ooMhIGTk/0ZEvxVpwoHZ4d 4d+RTkaUZ1onzxLyxVwYEQ== >>> I (170459342) ovms-server-v2: Server token is ooMhIGTk/0ZEvxVpwoHZ4d and digest is 4d+RTkaUZ1onzxLyxVwYEQ== >>> I (170459342) ovms-server-v2: Status: Server authentication ok. Now priming crypto. >>> I (170459342) ovms-server-v2: Shared secret key is ooMhIGTk/0ZEvxVpwoHZ4dzSgUQypXKd9tYDq7XuHf8m (44 bytes) >>> I (170459342) ovms-server-v2: Status: OVMS V2 login successful, and crypto channel established >>> I (170459352) ovms-server-v2: Incoming Msg: MP-0 Z0 >>> I (170459352) webserver: HTTP GET /status >>> I (170459392) webserver: HTTP GET /menu >>> _______________________________________________ >>> 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
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
_______________________________________________ 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
I haven’t seen any new problems, so will be tagging a 3.1.009 now, and releasing it to EAP tonight. 90+ changes since 3.1.008 is too many. Regards, Mark.
On 4 Aug 2018, at 3:38 PM, Michael Balzer <dexter@expeedo.de> wrote:
Greg, Mark,
It would be nice if it had a direct effect, would be reproducable then… :-)
Every crash event of this kind I had and got reported involved some sort of poor wifi situation. But the module still resolves >99% of those situations without a crash.
Feature wise it is fine. Just trying to find out the cause of these crashes, and if they are worse in recent edge builds vs main 3.1.008.
From my crash statistics (*-OVM-DebugCrash = 1 month): 3.1.008: 30 cars, 878 crashes => 29 crashes per car
= 3.1.008-73 (idf v3.2): 13 cars, 39 crashes => 3 crashes per car There should be more data available on your server.
My crash statistics query: SELECT v.version, v.cars, c.crashes, c.crashes/v.cars AS crashratio FROM ( SELECT LEFT(m_msg, INSTR(m_msg,'/')-1) AS version, COUNT(*) AS cars FROM ovms_carmessages WHERE m_code='F' AND m_msg LIKE '%build idf%' GROUP BY version ) v LEFT JOIN ( SELECT LEFT(h_data, INSTR(h_data,'/')-1) AS version, COUNT(*) AS crashes FROM ovms_historicalmessages WHERE h_recordtype='*-OVM-DebugCrash' AND h_data LIKE '%build idf%' GROUP BY version ) c ON c.version = v.version GROUP BY v.version Regards, Michael
Am 03.08.2018 um 03:26 schrieb Greg D.:
My feeling is that we don't have enough information to really know, and what we know is inconsistent. I had a couple of wireless and internet "burps" yesterday and today (my router rebooted itself, and separately, the modem dropped link a time or two), yet no further issues from the OVMS module. So, I am skeptical what direct effect wi-fi has on the reboots.
I think the best bet is to push 3.1.009 out, when it is otherwise ready, and gather more information on the issue.
Greg
Mark Webb-Johnson wrote:
Feature wise it is fine. Just trying to find out the cause of these crashes, and if they are worse in recent edge builds vs main 3.1.008.
Regards, Mark
On 2 Aug 2018, at 2:54 PM, Stephen Casner <casner@acm.org> <mailto:casner@acm.org> wrote:
Michael,
Will 009 be ready for main soon? I could switch to edge, but my friend in Santa Barbara needs it too, and edge would not be good for him.
-- Steve
On Wed, 1 Aug 2018, Michael Balzer wrote:
Steve, Greg,
you're both still on the 3.1.008 main release, please check out the edge build.
Your crashes look very familiar to me, I assume they are wifi related. The "esf_buf" error log Steve had is coming from within the wifi blob, and the latest edge build includes many fixes to that. That build reduced those crashes in the Twizy community by about 90%.
Regarding logging, this is my base config:
level: debug level.gsm-ppp: debug level.simcom: debug level.time: info level.v-twizy: verbose ← change accordingly level.webserver: debug
If I need more detail I simply switch the default level to verbose.
Regards, Michael
Am 01.08.2018 um 08:40 schrieb Greg D.:
Well, we seem to be on a roll... Got another one.
I just realized that I have an SD card in the module, but am not logging anything. What logging should I be setting up to capture additional information?
Greg
Last boot was 2153 second(s) ago Time at boot: 2018-07-31 23:01:39 PDT This is reset #20 since last power cycle Detected boot reason: Crash (12/12) Crash counters: 2 total, 0 early Last crash: Alloca exception on core 0 Registers: PC : 0x40081b96 PS : 0x00060634 A0 : 0x80081d61 A1 : 0x3ffafa60 A2 : 0x3ffb43e4 A3 : 0x00000001 A4 : 0x00000050 A5 : 0x00000001 A6 : 0x000000fe A7 : 0x000000a0 A8 : 0x00000081 A9 : 0x00000001 A10 : 0x0000cdcd A11 : 0x00000000 A12 : 0x3f40819c A13 : 0x3f407ebe A14 : 0x000000fe A15 : 0x00060023 SAR : 0x00000000 EXCCAUSE: 0x00000005 EXCVADDR: 0x00000000 LBEG : 0x40097664 LEND : 0x40097692 LCOUNT : 0xffffffff Backtrace: 0x40081b96 0x40081d5e 0x400db815 0x40174f95 0x400e73be 0x400e4699 0x40085149 0x40128bc2 0x40128df7 0x401287b4 0x400ea22d 0x400eac7a 0x400ead09 0x400ead19 0x402207d6 0x400e9ece 0x400e9f79 0x400e45f5 0x400e4604 0x400f5c09 0x400f035d Version: 3.1.008/ota_1/main (build idf v3.1-dev-986-g1a1a544a Jun 26 2018 09:30:21) ---------------------------------------------------------------------------------------------------------------------------------------------------------------- Running partition: ota_1 Boot partition: ota_1 Firmware: 3.1.008/ota_1/main (build idf v3.1-dev-986-g1a1a544a Jun 26 2018 09:30:21)
Greg D. wrote: > Hi Steve, > > Ok, so, still a puzzle as to why the crashes. Fortunately, I've only > had the one. I've not had any trouble losing wifi connectivity, either > when the car's been sitting in the garage for a few days, or coming and > going on errands (so, transitioning to cell and back). Prior to this, I > think the last boot was the upgrade to 3.1.008. Oh, perhaps the car's > recent near death experience (*) cycled power? Not sure, but probably > did. Anyway, in general, I've not had trouble with connectivity in a > long time. > > The only thing I've noticed is that sometimes I have a rather long delay > between an event (e.g. when the car starts charging) and having it show > up on my cell phone. Usually I get it immediately, but some time it's > delayed several minutes, and once in a while it never shows up (e.g. > charging started but never finished). It might simply be packet loss on > my Internet connection (it's fast, but sometimes leaky), not related to > wi-fi. I get delays at times on the PC going to websites too. > > {shrug} > > Greg > > (*) For some reason, the VMS lost connectivity to the VDS, and the car > locked up. Fortunately it was in the garage, and the windows were > rolled down since the door opening switches stopped working too. Had to > unplug the cables to the VMS under the dash and plug them back in to > force a reboot. {phew!} > > > Stephen Casner wrote: >> On Sun, 29 Jul 2018, Greg D. wrote: >> >>> Hi Steve, >>> >>> Interesting...? I just got a very cryptic "event" from my car:? >>> Not charging >>> SOC:- >> I believe it is expected to get that event when OVMS boots while the >> car is idle since "not charging" is an accurate description of the >> state. >> >> I received a "not charging" notification on Sunday as well, >> coincidentally as we were approaching home in our RAV4-EV. This >> resulted from another "Alloca exception on core 0" crash and reboot of >> OVMS: >> >> Last boot was 170458 second(s) ago >> Time at boot: 2018-07-29 21:41:32 GMT >> This is reset #7 since last power cycle >> Detected boot reason: Crash (8/14) >> Crash counters: 2 total, 0 early >> >> Last crash: Alloca exception on core 0 >> >> This is not the same time as yours (2018-07-29 17:55:36 PDT) so it >> does not appear that the crashes are synchronized by some external >> event. >> >> Then today I looked at the iPhone app and saw that my OVMS had not >> communicated with the v2 server for 15 hours. So I connected to the >> USB cable again and found that the wifi was again in trouble. This >> time there were many instances of a new error message from wifi that I >> had not seen before, as shown in the log below. >> >> Again I was able to restore operation of both server v2 and http by >> "wifi mode off" then "wifi mode client". >> >> -- Steve >> >> E (170324792) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >> E (170325752) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >> E (170328632) ovms-server-v2: mg_connect(api.openvehicles.com:6867) failed: cannot parse address| >> E (170328632) ovms-server-v2: Status: Error: Connection failed >> E (170329542) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >> E (170333742) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >> E (170333742) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >> E (170333742) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >> E (170333752) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >> E (170333752) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >> E (170333752) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >> E (170333752) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >> E (170333752) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >> E (170333752) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >> E (170333762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >> E (170333762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >> E (170335592) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >> I (170335672) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 >> I (170335672) ovms-server-v2: Status: Connecting... >> E (170335672) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >> E (170336312) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >> E (170337272) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >> E (170338232) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >> E (170339192) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >> E (170340152) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >> E (170341112) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >> E (170342072) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >> E (170343032) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >> OVMS> ena >> Password: >> E (170343992) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >> E (170344702) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >> E (170345912) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >> E (170346232) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >> E (170346872) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >> E (170347262) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >> OVMS# >> E (170347832) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >> E (170348792) ovms-server-v2: mg_connect(api.openvehicles.com:6867) failed: cannot parse address| >> E (170348792) ovms-server-v2: Status: Error: Connection failed >> E (170348792) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >> E (170349752) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >> E (170350832) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >> E (170353802) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >> E (170353802) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >> E (170353802) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >> E (170353802) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >> E (170353812) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >> E (170353812) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >> E (170353812) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >> E (170353812) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >> E (170353812) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >> E (170353812) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >> E (170353812) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >> E (170353822) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >> E (170353822) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >> E (170353822) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >> E (170353822) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >> E (170353832) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >> E (170353832) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >> E (170353832) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >> E (170353832) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >> I (170355672) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 >> I (170355672) ovms-server-v2: Status: Connecting... >> E (170355672) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >> E (170356472) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >> E (170357432) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >> E (170358392) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >> E (170359352) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >> E (170359842) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >> E (170360862) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >> E (170362232) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >> E (170362922) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >> E (170363192) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >> E (170364152) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >> E (170365112) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >> E (170366072) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >> E (170368952) ovms-server-v2: mg_connect(api.openvehicles.com:6867) failed: cannot parse address| >> E (170368952) ovms-server-v2: Status: Error: Connection failed >> E (170372022) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >> E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >> E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >> E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >> E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >> E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >> E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >> E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >> E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >> E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >> E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >> E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >> E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >> E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >> E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >> E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >> E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >> E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >> E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >> E (170373782) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >> E (170373782) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >> E (170373782) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >> E (170373782) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >> E (170373782) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >> E (170373782) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >> E (170374992) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >> E (170375672) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >> E (170375672) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >> I (170375672) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 >> I (170375672) ovms-server-v2: Status: Connecting... >> E (170376632) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >> E (170377592) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >> E (170378062) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >> E (170378552) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >> E (170379512) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >> E (170380472) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >> E (170381432) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >> E (170382392) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >> OVMS# wifi mode off >> Stopping wifi station... >> I (170383222) esp32wifi: Stopping WIFI station >> I (170383222) wifi: state: run -> init (0) >> I (170383222) wifi: pm stop, total sleep time: 47593209375 us / 59459320714 us >> I (170383222) wifi: n:1 0, o:1 1, ap:1 1, sta:1 0, prof:1 >> I (170383232) wifi: flush txq >> I (170383232) wifi: stop sw txq >> I (170383232) wifi: lmac stop hw txq >> E (170389112) ovms-server-v2: mg_connect(api.openvehicles.com:6867) failed: cannot parse address| >> E (170389112) ovms-server-v2: Status: Error: Connection failed >> I (170389112) netmanager: Interface priority is pp3 (10.170.41.247/255.255.255.255 gateway 10.64.64.64) >> I (170389112) netmanager: Set DNS#0 8.8.8.8 >> I (170389112) netmanager: Set DNS#1 8.8.4.4 >> I (170389112) netmanager: WIFI client down (with MODEM up): reconfigured for MODEM priority >> I (170389122) netmanager: Interface priority is pp3 (10.170.41.247/255.255.255.255 gateway 10.64.64.64) >> I (170389122) netmanager: Set DNS#0 8.8.8.8 >> I (170389122) netmanager: Set DNS#1 8.8.4.4 >> I (170389122) esp32wifi: STA disconnected with reason 8 >> W (170389122) netmanager: CleanupConnections: can't get AP station list >> I (170389122) netmanager: Interface priority is pp3 (10.170.41.247/255.255.255.255 gateway 10.64.64.64) >> I (170389122) netmanager: Set DNS#0 8.8.8.8 >> I (170389122) netmanager: Set DNS#1 8.8.4.4 >> I (170389132) netmanager: Interface priority is pp3 (10.170.41.247/255.255.255.255 gateway 10.64.64.64) >> I (170389132) netmanager: Set DNS#0 8.8.8.8 >> I (170389132) netmanager: Set DNS#1 8.8.4.4 >> I (170389132) netmanager: WIFI access point is down >> I (170389132) esp32wifi: AP stopped >> I (170389132) netmanager: CleanupConnections: closing conn 3f81dbbc: interface/link down >> I (170389142) netmanager: CleanupConnections: closing conn 3f81dbbc: interface/link down >> I (170389142) time: Network was reconfigured: restarting SNTP client >> I (170389142) ovms-server-v2: Network was reconfigured: disconnect, and reconnect in 10 seconds >> I (170389142) ovms-server-v2: Status: Network was reconfigured: disconnect, and reconnect in 10 seconds >> I (170389152) netmanager: CleanupConnections: closing conn 3f81dbbc: interface/link down >> I (170398672) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 >> I (170398672) ovms-server-v2: Status: Connecting... >> I (170401312) housekeeping: 2018-07-31 21:01:32 GMT (RAM: 8b=113788-152956 32b=28252) >> I (170402032) ovms-server-v2: Connection successful >> I (170402032) ovms-server-v2: Status: Logging in... >> I (170402032) ovms-server-v2: Sending server login: MP-C 0 xR/s7da9YTwJ+uKH0C2zRl VXtWmVfsQQjJCe4+AwK74w== US33 >> I (170402852) ovms-server-v2: Got server response: MP-S 0 1uDt9VTVDl5jzvSqsIwmtN isXmd3Gy2AcrvhQVrX3LAA== >> I (170402852) ovms-server-v2: Server token is 1uDt9VTVDl5jzvSqsIwmtN and digest is isXmd3Gy2AcrvhQVrX3LAA== >> I (170402852) ovms-server-v2: Status: Server authentication ok. Now priming crypto. >> I (170402852) ovms-server-v2: Shared secret key is 1uDt9VTVDl5jzvSqsIwmtNxR/s7da9YTwJ+uKH0C2zRl (44 bytes) >> I (170402852) ovms-server-v2: Status: OVMS V2 login successful, and crypto channel established >> I (170402872) ovms-server-v2: Incoming Msg: MP-0 Z0 >> I (170403672) ovms-server-v2: Send MP-0 S70.0,M,65535,127,stopped,standard,166,146,32,0,0,2100,7,21,0,0,0,0,0.00,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,0.00,0 >> I (170403672) ovms-server-v2: Send MP-0 D65,0,5,23,23,24,587,516256,0,170403,24,0,1,1,11.63,0,12.6,0,23,0 >> I (170403672) ovms-server-v2: Send MP-0 L37.346340,-122.037308,206,64,1,1,0,0,0.0,0,0 >> I (170403682) ovms-server-v2: Send MP-0 F3.1.008/ota_0/main (build idf v3.1-dev-986-g1a1a544a Jun 26 2018 09:30:21),5YJRE11B181000033,7,1,TR1N,AT&T Hologram >> OVMS# wifi mode client Revelstoke >> Starting WIFI as a client to Revelstoke... >> I (170432062) wifi: mode : sta (30:ae:a4:43:9c:28) >> I (170434462) wifi: n:1 0, o:1 0, ap:255 255, sta:1 0, prof:1 >> I (170435152) wifi: state: init -> auth (b0) >> I (170435162) wifi: state: auth -> assoc (0) >> I (170435162) wifi: state: assoc -> run (10) >> I (170435202) wifi: connected with Revelstoke, channel 1 >> I (170435202) wifi: pm start, type: 1 >> I (170438872) event: sta ip: 192.168.1.82, mask: 255.255.255.0, gw: 192.168.1.254 >> I (170438872) netmanager: Interface priority is st4 (192.168.1.82/255.255.255.0 gateway 192.168.1.254) >> I (170438872) netmanager: Set DNS#0 8.8.8.8 >> I (170438872) netmanager: Set DNS#1 8.8.4.4 >> I (170438872) netmanager: WIFI client up (with MODEM up): reconfigured for WIFI client priority >> I (170438872) esp32wifi: STA got IP with SSID: Revelstoke, MAC: 30:ae:a4:43:9c:28, IP: 192.168.1.82, mask: 255.255.255.0, gw: 192.168.1.254 >> I (170438882) time: Network was reconfigured: restarting SNTP client >> I (170438882) ovms-server-v2: Network was reconfigured: disconnect, and reconnect in 10 seconds >> I (170438882) ovms-server-v2: Status: Network was reconfigured: disconnect, and reconnect in 10 seconds >> I (170439082) ovms-server-v2: Status: Disconnected >> I (170451362) webserver: HTTP GET / >> I (170451572) webserver: HTTP GET /apple-touch-icon.png >> I (170451842) webserver: HTTP GET /status >> I (170458672) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 >> I (170458672) ovms-server-v2: Status: Connecting... >> I (170458902) ovms-server-v2: Connection successful >> I (170458902) ovms-server-v2: Status: Logging in... >> I (170458902) ovms-server-v2: Sending server login: MP-C 0 zSgUQypXKd9tYDq7XuHf8m Raby/geQppSUPG5l9NRztw== US33 >> I (170458922) webserver: HTTP POST /status >> I (170458922) webserver: HandleLogin: 'admin' logged in, sid 6ea0f4c3207e3328 >> I (170459342) ovms-server-v2: Got server response: MP-S 0 ooMhIGTk/0ZEvxVpwoHZ4d 4d+RTkaUZ1onzxLyxVwYEQ== >> I (170459342) ovms-server-v2: Server token is ooMhIGTk/0ZEvxVpwoHZ4d and digest is 4d+RTkaUZ1onzxLyxVwYEQ== >> I (170459342) ovms-server-v2: Status: Server authentication ok. Now priming crypto. >> I (170459342) ovms-server-v2: Shared secret key is ooMhIGTk/0ZEvxVpwoHZ4dzSgUQypXKd9tYDq7XuHf8m (44 bytes) >> I (170459342) ovms-server-v2: Status: OVMS V2 login successful, and crypto channel established >> I (170459352) ovms-server-v2: Incoming Msg: MP-0 Z0 >> I (170459352) webserver: HTTP GET /status >> I (170459392) webserver: HTTP GET /menu >> _______________________________________________ >> 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>
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 http://lists.openvehicles.com/mailman/listinfo/ovmsdev
I found an issue with the Tesla Roadster module in 3.1.009. This was causing crashing. Silly mistake affecting the digital speedo, but probably crashing the module in all parked Tesla Roadsters running 3.1.009. I am surprised nobody reported it (maybe nobody using EAP?). The fix was simple, so I’ve re-built, and put in EAP as 3.1.010. Restarting EAP testing now… Regards, Mark.
Begin forwarded message:
From: Mark Webb-Johnson <mark@webb-johnson.net> Subject: Re: [Ovmsdev] Poor wifi performance Date: 15 August 2018 at 7:49:54 PM HKT To: OVMS Developers <ovmsdev@lists.openvehicles.com> Reply-To: OVMS Developers <ovmsdev@lists.openvehicles.com>
I haven’t seen any new problems, so will be tagging a 3.1.009 now, and releasing it to EAP tonight. 90+ changes since 3.1.008 is too many.
Regards, Mark.
On 4 Aug 2018, at 3:38 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Greg, Mark,
It would be nice if it had a direct effect, would be reproducable then… :-)
Every crash event of this kind I had and got reported involved some sort of poor wifi situation. But the module still resolves >99% of those situations without a crash.
Feature wise it is fine. Just trying to find out the cause of these crashes, and if they are worse in recent edge builds vs main 3.1.008.
From my crash statistics (*-OVM-DebugCrash = 1 month): 3.1.008: 30 cars, 878 crashes => 29 crashes per car
= 3.1.008-73 (idf v3.2): 13 cars, 39 crashes => 3 crashes per car There should be more data available on your server.
My crash statistics query: SELECT v.version, v.cars, c.crashes, c.crashes/v.cars AS crashratio FROM ( SELECT LEFT(m_msg, INSTR(m_msg,'/')-1) AS version, COUNT(*) AS cars FROM ovms_carmessages WHERE m_code='F' AND m_msg LIKE '%build idf%' GROUP BY version ) v LEFT JOIN ( SELECT LEFT(h_data, INSTR(h_data,'/')-1) AS version, COUNT(*) AS crashes FROM ovms_historicalmessages WHERE h_recordtype='*-OVM-DebugCrash' AND h_data LIKE '%build idf%' GROUP BY version ) c ON c.version = v.version GROUP BY v.version Regards, Michael
Am 03.08.2018 um 03:26 schrieb Greg D.:
My feeling is that we don't have enough information to really know, and what we know is inconsistent. I had a couple of wireless and internet "burps" yesterday and today (my router rebooted itself, and separately, the modem dropped link a time or two), yet no further issues from the OVMS module. So, I am skeptical what direct effect wi-fi has on the reboots.
I think the best bet is to push 3.1.009 out, when it is otherwise ready, and gather more information on the issue.
Greg
Mark Webb-Johnson wrote:
Feature wise it is fine. Just trying to find out the cause of these crashes, and if they are worse in recent edge builds vs main 3.1.008.
Regards, Mark
On 2 Aug 2018, at 2:54 PM, Stephen Casner <casner@acm.org> <mailto:casner@acm.org> wrote:
Michael,
Will 009 be ready for main soon? I could switch to edge, but my friend in Santa Barbara needs it too, and edge would not be good for him.
-- Steve
On Wed, 1 Aug 2018, Michael Balzer wrote:
Steve, Greg,
you're both still on the 3.1.008 main release, please check out the edge build.
Your crashes look very familiar to me, I assume they are wifi related. The "esf_buf" error log Steve had is coming from within the wifi blob, and the latest edge build includes many fixes to that. That build reduced those crashes in the Twizy community by about 90%.
Regarding logging, this is my base config:
level: debug level.gsm-ppp: debug level.simcom: debug level.time: info level.v-twizy: verbose ← change accordingly level.webserver: debug
If I need more detail I simply switch the default level to verbose.
Regards, Michael
Am 01.08.2018 um 08:40 schrieb Greg D.: > Well, we seem to be on a roll... Got another one. > > I just realized that I have an SD card in the module, but am not logging anything. What logging should I be setting up to capture additional information? > > Greg > > Last boot was 2153 second(s) ago Time at boot: 2018-07-31 23:01:39 PDT This is reset #20 since last power cycle Detected boot reason: Crash (12/12) Crash > counters: 2 total, 0 early Last crash: Alloca exception on core 0 Registers: PC : 0x40081b96 PS : 0x00060634 A0 : 0x80081d61 A1 : 0x3ffafa60 A2 : 0x3ffb43e4 > A3 : 0x00000001 A4 : 0x00000050 A5 : 0x00000001 A6 : 0x000000fe A7 : 0x000000a0 A8 : 0x00000081 A9 : 0x00000001 A10 : 0x0000cdcd A11 : 0x00000000 A12 : > 0x3f40819c A13 : 0x3f407ebe A14 : 0x000000fe A15 : 0x00060023 SAR : 0x00000000 EXCCAUSE: 0x00000005 EXCVADDR: 0x00000000 LBEG : 0x40097664 LEND : 0x40097692 > LCOUNT : 0xffffffff Backtrace: 0x40081b96 0x40081d5e 0x400db815 0x40174f95 0x400e73be 0x400e4699 0x40085149 0x40128bc2 0x40128df7 0x401287b4 0x400ea22d > 0x400eac7a 0x400ead09 0x400ead19 0x402207d6 0x400e9ece 0x400e9f79 0x400e45f5 0x400e4604 0x400f5c09 0x400f035d Version: 3.1.008/ota_1/main (build idf > v3.1-dev-986-g1a1a544a Jun 26 2018 09:30:21) > ---------------------------------------------------------------------------------------------------------------------------------------------------------------- > Running partition: ota_1 Boot partition: ota_1 Firmware: 3.1.008/ota_1/main (build idf v3.1-dev-986-g1a1a544a Jun 26 2018 09:30:21) > > > > Greg D. wrote: >> Hi Steve, >> >> Ok, so, still a puzzle as to why the crashes. Fortunately, I've only >> had the one. I've not had any trouble losing wifi connectivity, either >> when the car's been sitting in the garage for a few days, or coming and >> going on errands (so, transitioning to cell and back). Prior to this, I >> think the last boot was the upgrade to 3.1.008. Oh, perhaps the car's >> recent near death experience (*) cycled power? Not sure, but probably >> did. Anyway, in general, I've not had trouble with connectivity in a >> long time. >> >> The only thing I've noticed is that sometimes I have a rather long delay >> between an event (e.g. when the car starts charging) and having it show >> up on my cell phone. Usually I get it immediately, but some time it's >> delayed several minutes, and once in a while it never shows up (e.g. >> charging started but never finished). It might simply be packet loss on >> my Internet connection (it's fast, but sometimes leaky), not related to >> wi-fi. I get delays at times on the PC going to websites too. >> >> {shrug} >> >> Greg >> >> (*) For some reason, the VMS lost connectivity to the VDS, and the car >> locked up. Fortunately it was in the garage, and the windows were >> rolled down since the door opening switches stopped working too. Had to >> unplug the cables to the VMS under the dash and plug them back in to >> force a reboot. {phew!} >> >> >> Stephen Casner wrote: >>> On Sun, 29 Jul 2018, Greg D. wrote: >>> >>>> Hi Steve, >>>> >>>> Interesting...? I just got a very cryptic "event" from my car:? >>>> Not charging >>>> SOC:- >>> I believe it is expected to get that event when OVMS boots while the >>> car is idle since "not charging" is an accurate description of the >>> state. >>> >>> I received a "not charging" notification on Sunday as well, >>> coincidentally as we were approaching home in our RAV4-EV. This >>> resulted from another "Alloca exception on core 0" crash and reboot of >>> OVMS: >>> >>> Last boot was 170458 second(s) ago >>> Time at boot: 2018-07-29 21:41:32 GMT >>> This is reset #7 since last power cycle >>> Detected boot reason: Crash (8/14) >>> Crash counters: 2 total, 0 early >>> >>> Last crash: Alloca exception on core 0 >>> >>> This is not the same time as yours (2018-07-29 17:55:36 PDT) so it >>> does not appear that the crashes are synchronized by some external >>> event. >>> >>> Then today I looked at the iPhone app and saw that my OVMS had not >>> communicated with the v2 server for 15 hours. So I connected to the >>> USB cable again and found that the wifi was again in trouble. This >>> time there were many instances of a new error message from wifi that I >>> had not seen before, as shown in the log below. >>> >>> Again I was able to restore operation of both server v2 and http by >>> "wifi mode off" then "wifi mode client". >>> >>> -- Steve >>> >>> E (170324792) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >>> E (170325752) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >>> E (170328632) ovms-server-v2: mg_connect(api.openvehicles.com:6867 <http://api.openvehicles.com:6867/>) failed: cannot parse address| >>> E (170328632) ovms-server-v2: Status: Error: Connection failed >>> E (170329542) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170333742) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170333742) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170333742) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170333752) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170333752) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170333752) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170333752) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170333752) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170333752) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170333762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170333762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170335592) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> I (170335672) ovms-server-v2: Connection is api.openvehicles.com:6867 <http://api.openvehicles.com:6867/> US33 >>> I (170335672) ovms-server-v2: Status: Connecting... >>> E (170335672) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >>> E (170336312) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >>> E (170337272) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >>> E (170338232) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >>> E (170339192) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >>> E (170340152) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >>> E (170341112) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >>> E (170342072) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >>> E (170343032) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >>> OVMS> ena >>> Password: >>> E (170343992) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >>> E (170344702) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170345912) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >>> E (170346232) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170346872) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >>> E (170347262) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> OVMS# >>> E (170347832) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >>> E (170348792) ovms-server-v2: mg_connect(api.openvehicles.com:6867 <http://api.openvehicles.com:6867/>) failed: cannot parse address| >>> E (170348792) ovms-server-v2: Status: Error: Connection failed >>> E (170348792) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >>> E (170349752) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >>> E (170350832) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170353802) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170353802) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170353802) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170353802) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170353812) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170353812) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170353812) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170353812) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170353812) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170353812) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170353812) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170353822) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170353822) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170353822) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170353822) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170353832) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170353832) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170353832) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170353832) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> I (170355672) ovms-server-v2: Connection is api.openvehicles.com:6867 <http://api.openvehicles.com:6867/> US33 >>> I (170355672) ovms-server-v2: Status: Connecting... >>> E (170355672) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >>> E (170356472) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >>> E (170357432) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >>> E (170358392) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >>> E (170359352) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >>> E (170359842) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170360862) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170362232) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >>> E (170362922) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170363192) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >>> E (170364152) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >>> E (170365112) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >>> E (170366072) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >>> E (170368952) ovms-server-v2: mg_connect(api.openvehicles.com:6867 <http://api.openvehicles.com:6867/>) failed: cannot parse address| >>> E (170368952) ovms-server-v2: Status: Error: Connection failed >>> E (170372022) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170373762) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170373772) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170373782) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170373782) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170373782) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170373782) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170373782) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170373782) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170374992) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170375672) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >>> E (170375672) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >>> I (170375672) ovms-server-v2: Connection is api.openvehicles.com:6867 <http://api.openvehicles.com:6867/> US33 >>> I (170375672) ovms-server-v2: Status: Connecting... >>> E (170376632) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >>> E (170377592) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >>> E (170378062) wifi: esf_buf: t=7 l=1600 max:16, alloc:16 no eb >>> E (170378552) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >>> E (170379512) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >>> E (170380472) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >>> E (170381432) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >>> E (170382392) wifi: esf_buf: t=7 l=110 max:16, alloc:16 no eb >>> OVMS# wifi mode off >>> Stopping wifi station... >>> I (170383222) esp32wifi: Stopping WIFI station >>> I (170383222) wifi: state: run -> init (0) >>> I (170383222) wifi: pm stop, total sleep time: 47593209375 us / 59459320714 us >>> I (170383222) wifi: n:1 0, o:1 1, ap:1 1, sta:1 0, prof:1 >>> I (170383232) wifi: flush txq >>> I (170383232) wifi: stop sw txq >>> I (170383232) wifi: lmac stop hw txq >>> E (170389112) ovms-server-v2: mg_connect(api.openvehicles.com:6867 <http://api.openvehicles.com:6867/>) failed: cannot parse address| >>> E (170389112) ovms-server-v2: Status: Error: Connection failed >>> I (170389112) netmanager: Interface priority is pp3 (10.170.41.247/255.255.255.255 gateway 10.64.64.64) >>> I (170389112) netmanager: Set DNS#0 8.8.8.8 >>> I (170389112) netmanager: Set DNS#1 8.8.4.4 >>> I (170389112) netmanager: WIFI client down (with MODEM up): reconfigured for MODEM priority >>> I (170389122) netmanager: Interface priority is pp3 (10.170.41.247/255.255.255.255 gateway 10.64.64.64) >>> I (170389122) netmanager: Set DNS#0 8.8.8.8 >>> I (170389122) netmanager: Set DNS#1 8.8.4.4 >>> I (170389122) esp32wifi: STA disconnected with reason 8 >>> W (170389122) netmanager: CleanupConnections: can't get AP station list >>> I (170389122) netmanager: Interface priority is pp3 (10.170.41.247/255.255.255.255 gateway 10.64.64.64) >>> I (170389122) netmanager: Set DNS#0 8.8.8.8 >>> I (170389122) netmanager: Set DNS#1 8.8.4.4 >>> I (170389132) netmanager: Interface priority is pp3 (10.170.41.247/255.255.255.255 gateway 10.64.64.64) >>> I (170389132) netmanager: Set DNS#0 8.8.8.8 >>> I (170389132) netmanager: Set DNS#1 8.8.4.4 >>> I (170389132) netmanager: WIFI access point is down >>> I (170389132) esp32wifi: AP stopped >>> I (170389132) netmanager: CleanupConnections: closing conn 3f81dbbc: interface/link down >>> I (170389142) netmanager: CleanupConnections: closing conn 3f81dbbc: interface/link down >>> I (170389142) time: Network was reconfigured: restarting SNTP client >>> I (170389142) ovms-server-v2: Network was reconfigured: disconnect, and reconnect in 10 seconds >>> I (170389142) ovms-server-v2: Status: Network was reconfigured: disconnect, and reconnect in 10 seconds >>> I (170389152) netmanager: CleanupConnections: closing conn 3f81dbbc: interface/link down >>> I (170398672) ovms-server-v2: Connection is api.openvehicles.com:6867 <http://api.openvehicles.com:6867/> US33 >>> I (170398672) ovms-server-v2: Status: Connecting... >>> I (170401312) housekeeping: 2018-07-31 21:01:32 GMT (RAM: 8b=113788-152956 32b=28252) >>> I (170402032) ovms-server-v2: Connection successful >>> I (170402032) ovms-server-v2: Status: Logging in... >>> I (170402032) ovms-server-v2: Sending server login: MP-C 0 xR/s7da9YTwJ+uKH0C2zRl VXtWmVfsQQjJCe4+AwK74w== US33 >>> I (170402852) ovms-server-v2: Got server response: MP-S 0 1uDt9VTVDl5jzvSqsIwmtN isXmd3Gy2AcrvhQVrX3LAA== >>> I (170402852) ovms-server-v2: Server token is 1uDt9VTVDl5jzvSqsIwmtN and digest is isXmd3Gy2AcrvhQVrX3LAA== >>> I (170402852) ovms-server-v2: Status: Server authentication ok. Now priming crypto. >>> I (170402852) ovms-server-v2: Shared secret key is 1uDt9VTVDl5jzvSqsIwmtNxR/s7da9YTwJ+uKH0C2zRl (44 bytes) >>> I (170402852) ovms-server-v2: Status: OVMS V2 login successful, and crypto channel established >>> I (170402872) ovms-server-v2: Incoming Msg: MP-0 Z0 >>> I (170403672) ovms-server-v2: Send MP-0 S70.0,M,65535,127,stopped,standard,166,146,32,0,0,2100,7,21,0,0,0,0,0.00,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,0.00,0 >>> I (170403672) ovms-server-v2: Send MP-0 D65,0,5,23,23,24,587,516256,0,170403,24,0,1,1,11.63,0,12.6,0,23,0 >>> I (170403672) ovms-server-v2: Send MP-0 L37.346340,-122.037308,206,64,1,1,0,0,0.0,0,0 >>> I (170403682) ovms-server-v2: Send MP-0 F3.1.008/ota_0/main (build idf v3.1-dev-986-g1a1a544a Jun 26 2018 09:30:21),5YJRE11B181000033,7,1,TR1N,AT&T Hologram >>> OVMS# wifi mode client Revelstoke >>> Starting WIFI as a client to Revelstoke... >>> I (170432062) wifi: mode : sta (30:ae:a4:43:9c:28) >>> I (170434462) wifi: n:1 0, o:1 0, ap:255 255, sta:1 0, prof:1 >>> I (170435152) wifi: state: init -> auth (b0) >>> I (170435162) wifi: state: auth -> assoc (0) >>> I (170435162) wifi: state: assoc -> run (10) >>> I (170435202) wifi: connected with Revelstoke, channel 1 >>> I (170435202) wifi: pm start, type: 1 >>> I (170438872) event: sta ip: 192.168.1.82, mask: 255.255.255.0, gw: 192.168.1.254 >>> I (170438872) netmanager: Interface priority is st4 (192.168.1.82/255.255.255.0 gateway 192.168.1.254) >>> I (170438872) netmanager: Set DNS#0 8.8.8.8 >>> I (170438872) netmanager: Set DNS#1 8.8.4.4 >>> I (170438872) netmanager: WIFI client up (with MODEM up): reconfigured for WIFI client priority >>> I (170438872) esp32wifi: STA got IP with SSID: Revelstoke, MAC: 30:ae:a4:43:9c:28, IP: 192.168.1.82, mask: 255.255.255.0, gw: 192.168.1.254 >>> I (170438882) time: Network was reconfigured: restarting SNTP client >>> I (170438882) ovms-server-v2: Network was reconfigured: disconnect, and reconnect in 10 seconds >>> I (170438882) ovms-server-v2: Status: Network was reconfigured: disconnect, and reconnect in 10 seconds >>> I (170439082) ovms-server-v2: Status: Disconnected >>> I (170451362) webserver: HTTP GET / >>> I (170451572) webserver: HTTP GET /apple-touch-icon.png >>> I (170451842) webserver: HTTP GET /status >>> I (170458672) ovms-server-v2: Connection is api.openvehicles.com:6867 <http://api.openvehicles.com:6867/> US33 >>> I (170458672) ovms-server-v2: Status: Connecting... >>> I (170458902) ovms-server-v2: Connection successful >>> I (170458902) ovms-server-v2: Status: Logging in... >>> I (170458902) ovms-server-v2: Sending server login: MP-C 0 zSgUQypXKd9tYDq7XuHf8m Raby/geQppSUPG5l9NRztw== US33 >>> I (170458922) webserver: HTTP POST /status >>> I (170458922) webserver: HandleLogin: 'admin' logged in, sid 6ea0f4c3207e3328 >>> I (170459342) ovms-server-v2: Got server response: MP-S 0 ooMhIGTk/0ZEvxVpwoHZ4d 4d+RTkaUZ1onzxLyxVwYEQ== >>> I (170459342) ovms-server-v2: Server token is ooMhIGTk/0ZEvxVpwoHZ4d and digest is 4d+RTkaUZ1onzxLyxVwYEQ== >>> I (170459342) ovms-server-v2: Status: Server authentication ok. Now priming crypto. >>> I (170459342) ovms-server-v2: Shared secret key is ooMhIGTk/0ZEvxVpwoHZ4dzSgUQypXKd9tYDq7XuHf8m (44 bytes) >>> I (170459342) ovms-server-v2: Status: OVMS V2 login successful, and crypto channel established >>> I (170459352) ovms-server-v2: Incoming Msg: MP-0 Z0 >>> I (170459352) webserver: HTTP GET /status >>> I (170459392) webserver: HTTP GET /menu >>> _______________________________________________ >>> 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>
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
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
I'm still having poor wifi performance with 3.1.011. As with earlier releases, when I find OVMS is not responsive over wifi and connect to the serial port I find this error repeating: E (57630676) ovms-server-v2: mg_connect(api.openvehicles.com:6867) failed: cannot parse address| E (57630676) ovms-server-v2: Status: Error: Connection failed I (57637436) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 I (57637436) ovms-server-v2: Status: Connecting... E (57650836) ovms-server-v2: mg_connect(api.openvehicles.com:6867) failed: cannot parse address| E (57650836) ovms-server-v2: Status: Error: Connection failed I (57657436) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 I (57657436) ovms-server-v2: Status: Connecting... This can be cured by "wifi mode off" then "wifi mode client ..." to bring wifi back up again. The really bad part is that the wifi system does not recognize that it has lost connectivity so the primary interface does not switch over to the modem. The "cannot parse address" error suggests that Mongoose is in some strange state. I've put in some debugging code to investigate just how the parse is failing, and I'm waiting for it to get back into this error loop. Meanwhile, my ssh connection to OVMS dropped and my router says the OVMS station is down, so I went to hook up to the serial console again. This mongoose complaint is not happening (yet). But the wifi does not recognize that it has no association with my router: OVMS# wifi status Power: on Mode: Client mode STA SSID: Revelstoke (-81 dBm) MAC: 30:ae:a4:43:9c:28 IP: 192.168.1.74/255.255.255.0 GW: 192.168.1.254 OVMS# network status Interface#2: pp2 (ifup=1 linkup=1) IPv4: 10.170.41.247/255.255.255.255 gateway 10.64.64.64 Interface#1: st1 (ifup=1 linkup=1) IPv4: 192.168.1.74/255.255.255.0 gateway 192.168.1.254 DNS: 8.8.8.8 8.8.4.4 Default Interface: st1 (192.168.1.74/255.255.255.0 gateway 192.168.1.254) OVMS# server v2 status State: Connected OVMS V2 login successful, and crypto channel established OVMS# Even though server-v2 sends updates periodically, the failed wifi is not detected. So I guess that is the root problem. I'm expecting that after some time the mongoose state will deteriorate such that the parse error occurs again and I can at least investigate that part. -- Steve
Last night the OVMS wifi claimed to be up while my router said OVMS was not active (which I interpret to mean not associated). I was expecting the condition of OVMS to deteriorate further such that the mg_connect error loop would occur again, but this morning wifi connectivity was working again and OVMS had not rebooted. I guess the wifi reception improved enough to associate again. -- Steve On Fri, 21 Dec 2018, Stephen Casner wrote:
I'm still having poor wifi performance with 3.1.011. As with earlier releases, when I find OVMS is not responsive over wifi and connect to the serial port I find this error repeating:
E (57630676) ovms-server-v2: mg_connect(api.openvehicles.com:6867) failed: cannot parse address| E (57630676) ovms-server-v2: Status: Error: Connection failed I (57637436) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 I (57637436) ovms-server-v2: Status: Connecting... E (57650836) ovms-server-v2: mg_connect(api.openvehicles.com:6867) failed: cannot parse address| E (57650836) ovms-server-v2: Status: Error: Connection failed I (57657436) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 I (57657436) ovms-server-v2: Status: Connecting...
This can be cured by "wifi mode off" then "wifi mode client ..." to bring wifi back up again. The really bad part is that the wifi system does not recognize that it has lost connectivity so the primary interface does not switch over to the modem.
The "cannot parse address" error suggests that Mongoose is in some strange state. I've put in some debugging code to investigate just how the parse is failing, and I'm waiting for it to get back into this error loop.
Meanwhile, my ssh connection to OVMS dropped and my router says the OVMS station is down, so I went to hook up to the serial console again. This mongoose complaint is not happening (yet). But the wifi does not recognize that it has no association with my router:
OVMS# wifi status Power: on Mode: Client mode
STA SSID: Revelstoke (-81 dBm) MAC: 30:ae:a4:43:9c:28 IP: 192.168.1.74/255.255.255.0 GW: 192.168.1.254 OVMS# network status Interface#2: pp2 (ifup=1 linkup=1) IPv4: 10.170.41.247/255.255.255.255 gateway 10.64.64.64
Interface#1: st1 (ifup=1 linkup=1) IPv4: 192.168.1.74/255.255.255.0 gateway 192.168.1.254
DNS: 8.8.8.8 8.8.4.4
Default Interface: st1 (192.168.1.74/255.255.255.0 gateway 192.168.1.254) OVMS# server v2 status State: Connected OVMS V2 login successful, and crypto channel established OVMS#
Even though server-v2 sends updates periodically, the failed wifi is not detected. So I guess that is the root problem. I'm expecting that after some time the mongoose state will deteriorate such that the parse error occurs again and I can at least investigate that part.
-- Steve _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
I have finally given in and purchased a wifi extender to improve coverage in my garage for the benefit of OVMS. However, before I install it, I'm trying to diagnose the problems in the wifi support because I'm sure there will the other locations where OVMS will encounter weak wifi connectivity. The first section of log output below shows a typical situation. (I've run a script over this log to replace the system's uptime values with full date/timestamps.) The system boots up and establishes both WIFI and MODEM connectivity and gives priority to WIFI. The server-v2 transmits two 10-minute updates successfully, but 23 minutes after initially coming up it reports being disconnected. Instead of switching over to MODEM, it just tries every 20 seconds to connect again through WIFI and fails. This goes on for 25 minutes until the condition worsens. At that point mg_connect() begins reporting "failed: cannot parse address" so the result continues to be failure to connect. The failed attempst continue every 20 seconds indefinitely. The "-1" after "cannot parse address" is from some debugging code I added to determine which of several error returns from the mg_parse_address() function was taken. This tells me that the actual failure was not in parsing, rather name lookup failed. I wonder if 25 minutes is timeout interval of the name cache. The real question here is why wifi is still considered UP when connections via wifi fail. Perhaps a wifi disconnect event failed to be sent or received, but I know I have seen instances where my router indicated that the association to OVMS was inactive, yet OVMS wifi status indicated UP. I think it would make sense for the server to signal netmanager when it has encountered N consecutive connection failures and for netmanager to then try another interface if it has one that is up. I'm not sure how to transition back to wifi as the preferred interface; perhaps netmanage could switch back after some period of time (10 minutes?) and signal the server(s) to reconnect (since I assume the established connection would not be affected when netmanager switches priority). Or perhaps netmanager can explore connectivity using ping? Here is this first section of the log: I (2018-12-27 21:17:32.108) netmanager: MODEM up (with WIFI client up): staying with WIFI client priority W (2018-12-27 21:18:14.538) websocket: WebSocketHandler[0x3f819994]: job queue overflow resolved, 2362 drops W (2018-12-27 21:18:45.788) websocket: WebSocketHandler[0x3f819994]: job queue overflow detected I (2018-12-27 21:19:14.428) housekeeping: 2018-12-27 21:19:14 GMT (RAM: 8b=113788-143140 32b=10448) I (2018-12-27 21:22:08.428) ovms-server-v2: Send MP-0 S45.0,M,65535,127,stopped,standard,105,89,32,0,0,0,7,21,0,0,0,0,0.00,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,0.00,0 I (2018-12-27 21:22:08.488) ovms-server-v2: Send MP-0 D64,0,5,15,14,13,627,535490,0,64374,14,0,1,1,11.54,0,12.6,0,15,0,0 I (2018-12-27 21:22:08.548) ovms-server-v2: Send MP-0 L37.346279,-122.037292,67,48,1,1,0,0,0.0,0,0 I (2018-12-27 21:22:08.618) ovms-server-v2: Send MP-0 F3.1.011-90-g72ac9202-dirty/factory/main (build idf v3.1-dev-2835-g151269458-dirty Dec 22 2018 22:25:50),5YJRE11B181000033,14,1,TR1N,Revelstoke I (2018-12-27 21:24:14.428) housekeeping: 2018-12-27 21:24:14 GMT (RAM: 8b=113788-143140 32b=10448) I (2018-12-27 21:29:14.428) housekeeping: 2018-12-27 21:29:14 GMT (RAM: 8b=113788-143140 32b=10448) I (2018-12-27 21:32:09.428) ovms-server-v2: Send MP-0 S45.0,M,65535,127,stopped,standard,105,89,32,0,0,0,7,21,0,0,0,0,0.00,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,0.00,0 I (2018-12-27 21:32:09.498) ovms-server-v2: Send MP-0 D64,0,5,15,14,13,627,535490,0,64975,14,0,1,1,11.56,0,12.6,0,15,0,0 I (2018-12-27 21:32:09.558) ovms-server-v2: Send MP-0 L37.346260,-122.037315,67,56,1,1,0,0,0.0,0,0 I (2018-12-27 21:32:09.608) ovms-server-v2: Send MP-0 F3.1.011-90-g72ac9202-dirty/factory/main (build idf v3.1-dev-2835-g151269458-dirty Dec 22 2018 22:25:50),5YJRE11B181000033,13,1,TR1N,Revelstoke I (2018-12-27 21:34:14.428) housekeeping: 2018-12-27 21:34:14 GMT (RAM: 8b=113788-143140 32b=10448) I (2018-12-27 21:39:14.428) housekeeping: 2018-12-27 21:39:14 GMT (RAM: 8b=113788-143140 32b=10448) I (2018-12-27 21:40:33.498) ovms-server-v2: Status: Disconnected I (2018-12-27 21:40:53.428) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 I (2018-12-27 21:40:53.478) ovms-server-v2: Status: Connecting... W (2018-12-27 21:41:11.408) ovms-server-v2: Connection failed E (2018-12-27 21:41:11.458) ovms-server-v2: Status: Error: Connection failed I (2018-12-27 21:41:11.518) ovms-server-v2: Status: Disconnected I (2018-12-27 21:41:31.428) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 I (2018-12-27 21:41:31.478) ovms-server-v2: Status: Connecting... W (2018-12-27 21:41:48.848) ovms-server-v2: Connection failed E (2018-12-27 21:41:48.898) ovms-server-v2: Status: Error: Connection failed I (2018-12-27 21:41:48.958) ovms-server-v2: Status: Disconnected ... I (2018-12-27 22:05:44.428) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 I (2018-12-27 22:05:44.498) ovms-server-v2: Status: Connecting... E (2018-12-27 22:05:57.048) ovms-server-v2: mg_connect(api.openvehicles.com:6867) failed: cannot parse address -1 E (2018-12-27 22:05:57.098) ovms-server-v2: Status: Error: Connection failed I (2018-12-27 22:06:04.428) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 I (2018-12-27 22:06:04.478) ovms-server-v2: Status: Connecting... E (2018-12-27 22:06:17.198) ovms-server-v2: mg_connect(api.openvehicles.com:6867) failed: cannot parse address -1 E (2018-12-27 22:06:17.268) ovms-server-v2: Status: Error: Connection failed I (2018-12-27 22:06:24.428) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 I (2018-12-27 22:06:24.478) ovms-server-v2: Status: Connecting... E (2018-12-27 22:06:37.358) ovms-server-v2: mg_connect(api.openvehicles.com:6867) failed: cannot parse address -1 E (2018-12-27 22:06:37.408) ovms-server-v2: Status: Error: Connection failed The second section of log is just to show a particular odd error in the wifi driver: "wifi: ieee80211_output.c 853". After this error occurs, the wifi task is stuck in a loop resulting in a watchdog timeout if enabled. I did not find any mention of this in the github issues for esp-idf. On the forum there was one post with a similar message but a different number, but there was no reply. I (528) esp32wifi: Powering up WIFI driver I (528) wifi: wifi driver task: 3ffcda80, prio:23, stack:3584, core=0 I (538) wifi: wifi firmware version: 771f1dc I (538) wifi: config NVS flash: enabled I (538) wifi: config nano formating: disabled I (578) wifi: Init dynamic tx buffer num: 16 I (578) wifi: Init data frame dynamic rx buffer num: 16 I (578) wifi: Init management frame dynamic rx buffer num: 16 I (578) wifi: Init static rx buffer size: 2212 I (588) wifi: Init static rx buffer num: 4 I (588) wifi: Init dynamic rx buffer num: 16 I (648) phy: phy_version: 3910, c0c45a3, May 21 2018, 18:07:06, 0, 0 I (658) wifi: mode : sta (30:ae:a4:43:9c:28) I (3068) esp32wifi: STA disconnected with reason 201 I (12838) esp32wifi: STA disconnected with reason 201 I (22838) esp32wifi: STA disconnected with reason 201 I (32838) esp32wifi: STA disconnected with reason 201 I (42838) wifi: n:1 0, o:1 0, ap:255 255, sta:1 0, prof:1 I (43598) wifi: state: init -> auth (b0) I (44598) wifi: state: auth -> init (2) I (44598) wifi: n:1 0, o:1 0, ap:255 255, sta:1 0, prof:1 I (44598) esp32wifi: STA disconnected with reason 2 I (52838) esp32wifi: STA disconnected with reason 201 I (62838) esp32wifi: STA disconnected with reason 201 I (72838) esp32wifi: STA disconnected with reason 201 I (82858) esp32wifi: STA disconnected with reason 201 I (92838) wifi: n:1 0, o:1 0, ap:255 255, sta:1 0, prof:1 I (92838) wifi: state: init -> auth (b0) I (92848) wifi: state: auth -> assoc (0) I (92858) wifi: state: assoc -> run (10) I (92908) wifi: connected with Revelstoke, channel 1 I (92908) wifi: pm start, type: 1 I (128848) wifi: bcn_timout,ap_probe_send_start E (133258) wifi: ieee80211_output.c 853 OVMS# Task watchdog got triggered. The following tasks did not reset the watchdog in time: - IDLE (CPU 0) Tasks currently running: CPU 0: wifi CPU 1: IDLE Aborting. abort() was called at PC 0x400ddf43 on core 0 Backtrace: 0x40096068:0x3ffb05b0 0x4009622f:0x3ffb05d0 0x400ddf43:0x3ffb05f0 0x40085009:0x3ffb0610 0x401d351d:0x00000000 -- Steve
Steve, we've got an open issue on the connection failure detection: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/112 Mark also planned to do a rework of our Wifi integration to better handle some event situations IIRC. But do you see a wifi system event on connection loss, that should be handled? The situations I checked did not show any events we should have handled better, it just lost the connection. Can you try the current idf version? There are quite some Wifi related entries in the change history, I'm still hoping the update will solve some of these problems. If you hesitate because of the config partition problem: that's just a one time event when doing the upgrade, you can restore your config afterwards. Regards, Michael Am 30.12.18 um 04:17 schrieb Stephen Casner:
I have finally given in and purchased a wifi extender to improve coverage in my garage for the benefit of OVMS. However, before I install it, I'm trying to diagnose the problems in the wifi support because I'm sure there will the other locations where OVMS will encounter weak wifi connectivity.
The first section of log output below shows a typical situation. (I've run a script over this log to replace the system's uptime values with full date/timestamps.) The system boots up and establishes both WIFI and MODEM connectivity and gives priority to WIFI. The server-v2 transmits two 10-minute updates successfully, but 23 minutes after initially coming up it reports being disconnected. Instead of switching over to MODEM, it just tries every 20 seconds to connect again through WIFI and fails. This goes on for 25 minutes until the condition worsens. At that point mg_connect() begins reporting "failed: cannot parse address" so the result continues to be failure to connect. The failed attempst continue every 20 seconds indefinitely. The "-1" after "cannot parse address" is from some debugging code I added to determine which of several error returns from the mg_parse_address() function was taken. This tells me that the actual failure was not in parsing, rather name lookup failed. I wonder if 25 minutes is timeout interval of the name cache.
The real question here is why wifi is still considered UP when connections via wifi fail. Perhaps a wifi disconnect event failed to be sent or received, but I know I have seen instances where my router indicated that the association to OVMS was inactive, yet OVMS wifi status indicated UP. I think it would make sense for the server to signal netmanager when it has encountered N consecutive connection failures and for netmanager to then try another interface if it has one that is up. I'm not sure how to transition back to wifi as the preferred interface; perhaps netmanage could switch back after some period of time (10 minutes?) and signal the server(s) to reconnect (since I assume the established connection would not be affected when netmanager switches priority). Or perhaps netmanager can explore connectivity using ping?
Here is this first section of the log:
I (2018-12-27 21:17:32.108) netmanager: MODEM up (with WIFI client up): staying with WIFI client priority W (2018-12-27 21:18:14.538) websocket: WebSocketHandler[0x3f819994]: job queue overflow resolved, 2362 drops W (2018-12-27 21:18:45.788) websocket: WebSocketHandler[0x3f819994]: job queue overflow detected I (2018-12-27 21:19:14.428) housekeeping: 2018-12-27 21:19:14 GMT (RAM: 8b=113788-143140 32b=10448) I (2018-12-27 21:22:08.428) ovms-server-v2: Send MP-0 S45.0,M,65535,127,stopped,standard,105,89,32,0,0,0,7,21,0,0,0,0,0.00,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,0.00,0 I (2018-12-27 21:22:08.488) ovms-server-v2: Send MP-0 D64,0,5,15,14,13,627,535490,0,64374,14,0,1,1,11.54,0,12.6,0,15,0,0 I (2018-12-27 21:22:08.548) ovms-server-v2: Send MP-0 L37.346279,-122.037292,67,48,1,1,0,0,0.0,0,0 I (2018-12-27 21:22:08.618) ovms-server-v2: Send MP-0 F3.1.011-90-g72ac9202-dirty/factory/main (build idf v3.1-dev-2835-g151269458-dirty Dec 22 2018 22:25:50),5YJRE11B181000033,14,1,TR1N,Revelstoke I (2018-12-27 21:24:14.428) housekeeping: 2018-12-27 21:24:14 GMT (RAM: 8b=113788-143140 32b=10448) I (2018-12-27 21:29:14.428) housekeeping: 2018-12-27 21:29:14 GMT (RAM: 8b=113788-143140 32b=10448) I (2018-12-27 21:32:09.428) ovms-server-v2: Send MP-0 S45.0,M,65535,127,stopped,standard,105,89,32,0,0,0,7,21,0,0,0,0,0.00,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,0.00,0 I (2018-12-27 21:32:09.498) ovms-server-v2: Send MP-0 D64,0,5,15,14,13,627,535490,0,64975,14,0,1,1,11.56,0,12.6,0,15,0,0 I (2018-12-27 21:32:09.558) ovms-server-v2: Send MP-0 L37.346260,-122.037315,67,56,1,1,0,0,0.0,0,0 I (2018-12-27 21:32:09.608) ovms-server-v2: Send MP-0 F3.1.011-90-g72ac9202-dirty/factory/main (build idf v3.1-dev-2835-g151269458-dirty Dec 22 2018 22:25:50),5YJRE11B181000033,13,1,TR1N,Revelstoke I (2018-12-27 21:34:14.428) housekeeping: 2018-12-27 21:34:14 GMT (RAM: 8b=113788-143140 32b=10448) I (2018-12-27 21:39:14.428) housekeeping: 2018-12-27 21:39:14 GMT (RAM: 8b=113788-143140 32b=10448) I (2018-12-27 21:40:33.498) ovms-server-v2: Status: Disconnected I (2018-12-27 21:40:53.428) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 I (2018-12-27 21:40:53.478) ovms-server-v2: Status: Connecting... W (2018-12-27 21:41:11.408) ovms-server-v2: Connection failed E (2018-12-27 21:41:11.458) ovms-server-v2: Status: Error: Connection failed I (2018-12-27 21:41:11.518) ovms-server-v2: Status: Disconnected I (2018-12-27 21:41:31.428) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 I (2018-12-27 21:41:31.478) ovms-server-v2: Status: Connecting... W (2018-12-27 21:41:48.848) ovms-server-v2: Connection failed E (2018-12-27 21:41:48.898) ovms-server-v2: Status: Error: Connection failed I (2018-12-27 21:41:48.958) ovms-server-v2: Status: Disconnected ... I (2018-12-27 22:05:44.428) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 I (2018-12-27 22:05:44.498) ovms-server-v2: Status: Connecting... E (2018-12-27 22:05:57.048) ovms-server-v2: mg_connect(api.openvehicles.com:6867) failed: cannot parse address -1 E (2018-12-27 22:05:57.098) ovms-server-v2: Status: Error: Connection failed I (2018-12-27 22:06:04.428) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 I (2018-12-27 22:06:04.478) ovms-server-v2: Status: Connecting... E (2018-12-27 22:06:17.198) ovms-server-v2: mg_connect(api.openvehicles.com:6867) failed: cannot parse address -1 E (2018-12-27 22:06:17.268) ovms-server-v2: Status: Error: Connection failed I (2018-12-27 22:06:24.428) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 I (2018-12-27 22:06:24.478) ovms-server-v2: Status: Connecting... E (2018-12-27 22:06:37.358) ovms-server-v2: mg_connect(api.openvehicles.com:6867) failed: cannot parse address -1 E (2018-12-27 22:06:37.408) ovms-server-v2: Status: Error: Connection failed
The second section of log is just to show a particular odd error in the wifi driver: "wifi: ieee80211_output.c 853". After this error occurs, the wifi task is stuck in a loop resulting in a watchdog timeout if enabled. I did not find any mention of this in the github issues for esp-idf. On the forum there was one post with a similar message but a different number, but there was no reply.
I (528) esp32wifi: Powering up WIFI driver I (528) wifi: wifi driver task: 3ffcda80, prio:23, stack:3584, core=0 I (538) wifi: wifi firmware version: 771f1dc I (538) wifi: config NVS flash: enabled I (538) wifi: config nano formating: disabled I (578) wifi: Init dynamic tx buffer num: 16 I (578) wifi: Init data frame dynamic rx buffer num: 16 I (578) wifi: Init management frame dynamic rx buffer num: 16 I (578) wifi: Init static rx buffer size: 2212 I (588) wifi: Init static rx buffer num: 4 I (588) wifi: Init dynamic rx buffer num: 16 I (648) phy: phy_version: 3910, c0c45a3, May 21 2018, 18:07:06, 0, 0 I (658) wifi: mode : sta (30:ae:a4:43:9c:28) I (3068) esp32wifi: STA disconnected with reason 201 I (12838) esp32wifi: STA disconnected with reason 201 I (22838) esp32wifi: STA disconnected with reason 201 I (32838) esp32wifi: STA disconnected with reason 201 I (42838) wifi: n:1 0, o:1 0, ap:255 255, sta:1 0, prof:1 I (43598) wifi: state: init -> auth (b0) I (44598) wifi: state: auth -> init (2) I (44598) wifi: n:1 0, o:1 0, ap:255 255, sta:1 0, prof:1 I (44598) esp32wifi: STA disconnected with reason 2 I (52838) esp32wifi: STA disconnected with reason 201 I (62838) esp32wifi: STA disconnected with reason 201 I (72838) esp32wifi: STA disconnected with reason 201 I (82858) esp32wifi: STA disconnected with reason 201 I (92838) wifi: n:1 0, o:1 0, ap:255 255, sta:1 0, prof:1 I (92838) wifi: state: init -> auth (b0) I (92848) wifi: state: auth -> assoc (0) I (92858) wifi: state: assoc -> run (10) I (92908) wifi: connected with Revelstoke, channel 1 I (92908) wifi: pm start, type: 1 I (128848) wifi: bcn_timout,ap_probe_send_start E (133258) wifi: ieee80211_output.c 853 OVMS# Task watchdog got triggered. The following tasks did not reset the watchdog in time: - IDLE (CPU 0) Tasks currently running: CPU 0: wifi CPU 1: IDLE Aborting. abort() was called at PC 0x400ddf43 on core 0
Backtrace: 0x40096068:0x3ffb05b0 0x4009622f:0x3ffb05d0 0x400ddf43:0x3ffb05f0 0x40085009:0x3ffb0610 0x401d351d:0x00000000
-- Steve _______________________________________________ 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
Michael, My observations are consistent with Issue 112. Just now, as I prepared to answer your email, I found that I could not ping or ssh to OVMS. When I connected to the serial console, wifi and network status indicated UP. Shortly after connecting I also saw log messages from server-v2 indicating messages sent, yet the iPhone app said 23 minutes since OVMS was heard. Then shortly thereafter I started getting the connection attempt loop with "mg_connect(api.openvehicles.com:6867) failed: cannot parse address" indicating hostname lookup failure. I restored connectivity with "wifi mode off" then "wifi mode client". In this instance, my router indictated that OVMS was associated, but I have had instances in the past where the router indicated that OVMS was not associated and yet OVMS claimed wifi was up. So, yes, I definitely believe that the wifi system is failing to detect and report disconnects. But even if that is fixed, there may be instances where there is a network problem upstream from the access point that prevents the server from connecting. In those cases we should try backing off to the modem. The iPhone does that for its connection if enabled in the configuration. If Mark does not have code for this in process already, maybe I can help. Is there any additional diagnostic logging that could be added to determine whether the wifi driver is failing to indicate the disconnection or our esp32wifi code is missing the indication? I am running with the current openvehicles/esp-idf. I have not tried espressif/esp-idf. I was hoping to dig into this event using the log file, but when I connected I found that the system had restarted on an illegal instruction exception after I entered the log-to-file command two days ago. -- Steve On Sun, 30 Dec 2018, Michael Balzer wrote:
Steve,
we've got an open issue on the connection failure detection: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/112
Mark also planned to do a rework of our Wifi integration to better handle some event situations IIRC. But do you see a wifi system event on connection loss, that should be handled? The situations I checked did not show any events we should have handled better, it just lost the connection.
Can you try the current idf version? There are quite some Wifi related entries in the change history, I'm still hoping the update will solve some of these problems.
If you hesitate because of the config partition problem: that's just a one time event when doing the upgrade, you can restore your config afterwards.
Regards, Michael
Yesterday I found another instance where I could not ssh to OVMS nor ping it. This time I verified in my router status that the wifi association with OVMS was "inactive" (down). The iPhone app said that server-v2 was not hear for 108 minutes. This time I have a full log file covering back to the previous day, which is attached. I connected to OVMS with the serial console and the output from the serial monitor is appended to the attached log file. The "wifi stat" and "net stat" commands both indicated that the wifi connection was up when all the external indications were to the contrary. Going back 108 minutes in the log file corresponds roughly to the first instance of "job queue overflow detected". Perhaps the web server can act as the canary in the coal mine? There is no indication that the wifi driver signaled any problem at that time. Diagnosing this problem is difficult because the loss of connectivity occurs after a day or a few days of operation. I have not tried the current esp-idf yet; I may do that, but I'm not sure how long that would need to operate without loss to determine success. -- Steve
Steve, you could have enabled event logging additionally, but there clearly is no event from the wifi driver on the disassociation, or the netmanager would have logged this as well. You're probably right in the websocket job queue overflow indicating the loss, but that won't fit as a general canary, as it's only active while at least one web client is connected. Another thing you could monitor is the signal quality, or maybe check for a lack of update callbacks? That's CSIRxCallback in esp32wifi. But that's all working around the underlying wifi blob bug. We first should check if the current IDF blob does a better job. Regards, Michael Am 04.01.19 um 06:15 schrieb Stephen Casner:
Yesterday I found another instance where I could not ssh to OVMS nor ping it. This time I verified in my router status that the wifi association with OVMS was "inactive" (down). The iPhone app said that server-v2 was not hear for 108 minutes. This time I have a full log file covering back to the previous day, which is attached.
I connected to OVMS with the serial console and the output from the serial monitor is appended to the attached log file. The "wifi stat" and "net stat" commands both indicated that the wifi connection was up when all the external indications were to the contrary. Going back 108 minutes in the log file corresponds roughly to the first instance of "job queue overflow detected". Perhaps the web server can act as the canary in the coal mine? There is no indication that the wifi driver signaled any problem at that time.
Diagnosing this problem is difficult because the loss of connectivity occurs after a day or a few days of operation. I have not tried the current esp-idf yet; I may do that, but I'm not sure how long that would need to operate without loss to determine success.
-- Steve
_______________________________________________ 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
Michael, You're right that we can't depend on the websocket job queue overflow to detect loss of wifi connectivity. If the improvements in the wifi driver make it sufficiently robust to detect disassociation, then we may not need to do anything else to work around that problem. However, there may well be situations where wifi is able to associate just fine, but there is no connectivity upstream from that point to the server. To handle such cases I think it would be a good idea to have a signal that both the websocket and server-v[23] can send to netmanager to trigger switching to another path. -- Steve On Fri, 4 Jan 2019, Michael Balzer wrote:
Steve,
you could have enabled event logging additionally, but there clearly is no event from the wifi driver on the disassociation, or the netmanager would have logged this as well.
You're probably right in the websocket job queue overflow indicating the loss, but that won't fit as a general canary, as it's only active while at least one web client is connected.
Another thing you could monitor is the signal quality, or maybe check for a lack of update callbacks? That's CSIRxCallback in esp32wifi.
But that's all working around the underlying wifi blob bug. We first should check if the current IDF blob does a better job.
Regards, Michael
Am 04.01.19 um 06:15 schrieb Stephen Casner:
Yesterday I found another instance where I could not ssh to OVMS nor ping it. This time I verified in my router status that the wifi association with OVMS was "inactive" (down). The iPhone app said that server-v2 was not hear for 108 minutes. This time I have a full log file covering back to the previous day, which is attached.
I connected to OVMS with the serial console and the output from the serial monitor is appended to the attached log file. The "wifi stat" and "net stat" commands both indicated that the wifi connection was up when all the external indications were to the contrary. Going back 108 minutes in the log file corresponds roughly to the first instance of "job queue overflow detected". Perhaps the web server can act as the canary in the coal mine? There is no indication that the wifi driver signaled any problem at that time.
Diagnosing this problem is difficult because the loss of connectivity occurs after a day or a few days of operation. I have not tried the current esp-idf yet; I may do that, but I'm not sure how long that would need to operate without loss to determine success.
-- Steve
The core issue here (wifi connection being lost, but ESP stack not able to report that to the application - us) is the real culprit. I, like Michael, hope that later versions of the ESP IDF can solve this. Once the wear levelling version upgrade bug is fixed, perhaps we can try? I do see this in my home (despite the wifi access point being about 2metres from the car), so suspect it is more related to a timeout / interference. For me, it only happens once every few weeks. Implementing a facility for fallback to modem even if wifi is up (in the case of connections over wifi failing) is probably a sensible feature. I think we would need: A way for connection success / failure over a particular transport to be reported to the network layer. Or some way for network layer to access historical statistics. Some logic in the network layer to determine wifi is unreliable (presumably based on sequential connections failures without success, over time). Some logic in the network layer to determine wifi is reliable again. Perhaps after some time (hours) on modem failover, it could switch back to wifi and try again. The switch is done in the network layer itself, and our current default route switching mechanism should support that just fine. I guess a config to enable/disable this as a feature. But, I would really much rather ‘fix’ the wifi in the first place. It is certainly easier to see if any fix is effective at the moment, with the wifi unreliable, than if we had some automatic failover to modem situation. Regards, Mark.
On 5 Jan 2019, at 2:56 PM, Stephen Casner <casner@acm.org> wrote:
Michael,
You're right that we can't depend on the websocket job queue overflow to detect loss of wifi connectivity. If the improvements in the wifi driver make it sufficiently robust to detect disassociation, then we may not need to do anything else to work around that problem.
However, there may well be situations where wifi is able to associate just fine, but there is no connectivity upstream from that point to the server. To handle such cases I think it would be a good idea to have a signal that both the websocket and server-v[23] can send to netmanager to trigger switching to another path.
-- Steve
On Fri, 4 Jan 2019, Michael Balzer wrote:
Steve,
you could have enabled event logging additionally, but there clearly is no event from the wifi driver on the disassociation, or the netmanager would have logged this as well.
You're probably right in the websocket job queue overflow indicating the loss, but that won't fit as a general canary, as it's only active while at least one web client is connected.
Another thing you could monitor is the signal quality, or maybe check for a lack of update callbacks? That's CSIRxCallback in esp32wifi.
But that's all working around the underlying wifi blob bug. We first should check if the current IDF blob does a better job.
Regards, Michael
Am 04.01.19 um 06:15 schrieb Stephen Casner:
Yesterday I found another instance where I could not ssh to OVMS nor ping it. This time I verified in my router status that the wifi association with OVMS was "inactive" (down). The iPhone app said that server-v2 was not hear for 108 minutes. This time I have a full log file covering back to the previous day, which is attached.
I connected to OVMS with the serial console and the output from the serial monitor is appended to the attached log file. The "wifi stat" and "net stat" commands both indicated that the wifi connection was up when all the external indications were to the contrary. Going back 108 minutes in the log file corresponds roughly to the first instance of "job queue overflow detected". Perhaps the web server can act as the canary in the coal mine? There is no indication that the wifi driver signaled any problem at that time.
Diagnosing this problem is difficult because the loss of connectivity occurs after a day or a few days of operation. I have not tried the current esp-idf yet; I may do that, but I'm not sure how long that would need to operate without loss to determine success.
-- Steve
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
On analysis of issue #189 I just did a build using the latest upstream/master. There now are options to enable wifi debug logging: CONFIG_ESP32_WIFI_DEBUG_LOG_ENABLE=y CONFIG_ESP32_WIFI_DEBUG_LOG_DEBUG=y CONFIG_ESP32_WIFI_DEBUG_LOG_VERBOSE= CONFIG_ESP32_WIFI_DEBUG_LOG_MODULE_ALL= CONFIG_ESP32_WIFI_DEBUG_LOG_MODULE_WIFI=y CONFIG_ESP32_WIFI_DEBUG_LOG_MODULE_COEX= CONFIG_ESP32_WIFI_DEBUG_LOG_MODULE_MESH= CONFIG_ESP32_WIFI_DEBUG_LOG_SUBMODULE= That may help in debugging our wifi reliability issue if it's still unfixed. Regards, Michael Am 08.01.19 um 05:58 schrieb Mark Webb-Johnson:
The core issue here (wifi connection being lost, but ESP stack not able to report that to the application - us) is the real culprit. I, like Michael, hope that later versions of the ESP IDF can solve this. Once the wear levelling version upgrade bug is fixed, perhaps we can try? I do see this in my home (despite the wifi access point being about 2metres from the car), so suspect it is more related to a timeout / interference. For me, it only happens once every few weeks.
Implementing a facility for fallback to modem even if wifi is up (in the case of connections over wifi failing) is probably a sensible feature. I think we would need:
1. A way for connection success / failure over a particular transport to be reported to the network layer. Or some way for network layer to access historical statistics.
2. Some logic in the network layer to determine wifi is unreliable (presumably based on sequential connections failures without success, over time).
3. Some logic in the network layer to determine wifi is reliable again. Perhaps after some time (hours) on modem failover, it could switch back to wifi and try again.
4. The switch is done in the network layer itself, and our current default route switching mechanism should support that just fine.
I guess a config to enable/disable this as a feature.
But, I would really much rather ‘fix’ the wifi in the first place. It is certainly easier to see if any fix is effective at the moment, with the wifi unreliable, than if we had some automatic failover to modem situation.
Regards, Mark.
On 5 Jan 2019, at 2:56 PM, Stephen Casner <casner@acm.org <mailto:casner@acm.org>> wrote:
Michael,
You're right that we can't depend on the websocket job queue overflow to detect loss of wifi connectivity. If the improvements in the wifi driver make it sufficiently robust to detect disassociation, then we may not need to do anything else to work around that problem.
However, there may well be situations where wifi is able to associate just fine, but there is no connectivity upstream from that point to the server. To handle such cases I think it would be a good idea to have a signal that both the websocket and server-v[23] can send to netmanager to trigger switching to another path.
-- Steve
On Fri, 4 Jan 2019, Michael Balzer wrote:
Steve,
you could have enabled event logging additionally, but there clearly is no event from the wifi driver on the disassociation, or the netmanager would have logged this as well.
You're probably right in the websocket job queue overflow indicating the loss, but that won't fit as a general canary, as it's only active while at least one web client is connected.
Another thing you could monitor is the signal quality, or maybe check for a lack of update callbacks? That's CSIRxCallback in esp32wifi.
But that's all working around the underlying wifi blob bug. We first should check if the current IDF blob does a better job.
Regards, Michael
Am 04.01.19 um 06:15 schrieb Stephen Casner:
Yesterday I found another instance where I could not ssh to OVMS nor ping it. This time I verified in my router status that the wifi association with OVMS was "inactive" (down). The iPhone app said that server-v2 was not hear for 108 minutes. This time I have a full log file covering back to the previous day, which is attached.
I connected to OVMS with the serial console and the output from the serial monitor is appended to the attached log file. The "wifi stat" and "net stat" commands both indicated that the wifi connection was up when all the external indications were to the contrary. Going back 108 minutes in the log file corresponds roughly to the first instance of "job queue overflow detected". Perhaps the web server can act as the canary in the coal mine? There is no indication that the wifi driver signaled any problem at that time.
Diagnosing this problem is difficult because the loss of connectivity occurs after a day or a few days of operation. I have not tried the current esp-idf yet; I may do that, but I'm not sure how long that would need to operate without loss to determine success.
-- Steve
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
Perhaps it is time to update sdkconfig.default.hw3{0,1} in conjunction with the esp-idf update? -- Steve On Mon, 9 Jul 2018, Mark Webb-Johnson wrote:
Works for me, and the tonight’s edge nightly build will feature this.
Only issue I am seeing is that Espressif seemed to have messed up the crlf handling on ‘make monitor’ again. The ‘make simple_monitor’ works fine, but for the full monitor terminal emulator, the CRLF issued by our console (when you press ENTER) is lost. Just seems to end up as a CR (LF discarded).
Regards, Mark.
On 9 Jul 2018, at 6:14 AM, Michael Balzer <dexter@expeedo.de> wrote:
Sorry, no user feedback up to now on the wifi issues. As I don't have them myself, I need to wait for feedback. But no news means it's at least not worse than before ;)
Anyway, I've pushed the changes and esp-idf update.
@all: you need to update your esp-idf to build the current version: cd $IDF_PATH git pull git submodule update --recursive
Regards, Michael
Am 08.07.2018 um 10:59 schrieb Mark Webb-Johnson:
I even have some more free IRAM now, it used to be down to ~1K and is now ~7K.
That is very very good news. Using RELEASE build (rather than DEBUG), I got mine down to a usable level, but this should give us some breathing room.
Any noticeable improvement to the wifi issues?
Regards, Mark.
On 8 Jul 2018, at 4:49 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
The new esp-idf works good, I think I'll push the changes this evening.
I even have some more free IRAM now, it used to be down to ~1K and is now ~7K.
Remaining crashes recorded up to now: 3.1.008-32-g2fa3ab8-dirty/ota_1/edge (build idf v3.2-dev-168-g0fb2019f Jul 6 2018 20:49:00),7,Crash,8,14,1,0,IllegalInstruction,0,0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 ,
3.1.008-32-g2fa3ab8-dirty/ota_0/edge (build idf v3.2-dev-168-g0fb2019f Jul 6 2018 20:49:00),98,Crash,8,14,1,0,LoadProhibited,1,0x401165fc 0x00060230 0x80106004 0x3fff0d40 0x3ffc4794 0x00000000 0x3f4020ac 0x3fff1080 0x3fff1060 0x00000008 0x3ffed634 0x00000000 0x00000001 0x3ffc41f5 0x000000ff 0x0000ff00 0x00ff0000 0xff000000 0x00000004 0x0000001c 0x00000064 0x4009ee01 0x4009ee11 0xffffffff ,0x401165fc 0x40106001 0x400d3f9b 0x400d3ab5 → Using elf file: tmp/3.1.008-32-g2fa3ab8-dirty-elf/ovms3.elf 0x401165fc is in _vfprintf_r (../../../.././newlib/libc/stdio/vfprintf.c:1855). 0x40106001 is in _siprintf_r (../../../.././newlib/libc/stdio/siprintf.c:124). 0x400d3f9b is in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char*>(char*, char*, std::forward_iterator_tag) (/home/balzer/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.tcc:215). 210 basic_string<_CharT, _Traits, _Alloc>:: 211 _M_construct(_InIterator __beg, _InIterator __end, 212 std::forward_iterator_tag) 213 { 214 // NB: Not required, but considered best practice. 215 if (__gnu_cxx::__is_null_pointer(__beg) && __beg != __end) 216 std::__throw_logic_error(__N("basic_string::" 217 "_M_construct null not valid")); 218 219 size_type __dnew = static_cast<size_type>(std::distance(__beg, __end)); 0x400d3ab5 is in canlog::LogStatus(canbus*, CAN_LogEntry_t, CAN_status_t const*) (/home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/can/src/canlog.cpp:297). 292 return; 293 if (CheckFilter(bus, type)) 294 { 295 CAN_LogMsg_t msg; 296 msg.timestamp = esp_log_timestamp(); 297 msg.bus = bus; 298 msg.type = type; 299 msg.status = *status; 300 m_msgcount++; 301 if (xQueueSend(m_queue, &msg, 0) != pdTRUE)
3.1.008-32-g2fa3ab8-dirty/ota_1/edge (build idf v3.2-dev-168-g0fb2019f Jul 6 2018 20:49:00),11,Crash,12,12,3,0,abort(),0,,0x40095e74 0x4009606f 0x400ddaf7 0x40084e15 0x401e271d → watchdog timeout, no more info Regards, Michael
Am 06.07.2018 um 22:07 schrieb Michael Balzer:
I've been using APCLIENT all the time and only had one crash that looked like a wifi problem. This really is a very specific problem. I also have a very good wifi signal, I can perfectly use my module's web UI while the car is in my garage two floors below. But I live in an uncrowded area, not much wifi competition.
I have updated my esp-idf to the latest upstream master (it's v3.2 now) and could build without any memory issues. The wifi driver now, besided loads of bug fixes, also supports CSI. Our code only needs a minor adjustment if you'd like to compile yourself, add…
#define _SOC_SPI_PERIPH_H_ // don't include spi_periph.h (type conflict)
…in components/spinodma/spi_master_nodma.h before #include "driver/spi_common.h".
If you don't want to compile, the new build (with CSI enabled) is also on my server:
http://ovms.dexters-web.de/firmware/ota/v3.1/edge/ <http://ovms.dexters-web.de/firmware/ota/v3.1/edge/>
…and now being installed by my beta testers.
Regards, Michael
Am 06.07.2018 um 16:28 schrieb Mark Webb-Johnson:
My 2c:
For the access points I normally use, it works 100% of the time for me. The only issue I had was when the SSID password was wrong on one of my access points (sharing the same SSID) and that was randomly causing me connection issues (every time the ESP32 picked it).
I also don’t use APCLIENT, and only use SCLIENT mode. I’ve found APCLIENT to be buggy as hell.
But, I do have problems connecting to some access points. In particular phone hotspots. I suspect either bugs in the wifi stack, or some issue with channels.
The only thing I am wary of is that our current code does this:
esp_wifi_set_config… esp_wifi_start… esp_wifi_connect...
But the Espressif examples have:
esp_wifi_set_config… esp_wifi_start… Wait for SYSTEM_EVENT_STA_START esp_wifi_connect...
I had that working the Espressif way in my big wifi refactor that never made it to production. But our current code doesn’t wait for the SYSTEM_EVENT_STA_START before calling esp_wifi_connect.
Regards, Mark.
> On 6 Jul 2018, at 9:04 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote: > > I've had similar reports regarding poor wifi connectivity, and this seems to affect some modules more than others (or may be channel/frequency dependant?). One > user has just 1-2 bars AP wifi signal with the module placed ~ 50 cm away from the phone. > > I also still get reports of spurious strange crashes, that mostly seem to be related to situations with poor wifi signal. Some crash backtraces just are > complete blank / null, and there is no crash report on the USB output for these before reboot. > > Yesterday, Frank tried to perform some wifi scans. The first scan went fine, the second never returned, he had to power off the module. After reboot, all > successive scans worked. > > Two users reported they occasionally cannot auth to the OVMS AP with the correct password, and they can then reconnect just by retrying for some minutes or by > connecting & disconnecting another client to the AP. > > I already had a look at the wifi tx power configuration, it's at 100% by default. > > This all feels like a) we need to change something about the antenna, and b) there are quite some bugs in the wifi blob. > > Looking at https://github.com/espressif/esp32-wifi-lib/commits/master <https://github.com/espressif/esp32-wifi-lib/commits/master> it seems there have been numerous wifi blob fixes lately. Last time I checked I still was > out of memory with the current esp-idf, I'll check again. > > Regards, > Michael > > > Am 06.07.2018 um 01:48 schrieb Stephen Casner: >> I find the wifi performance of OVMS v3 to be poor, and I'm wondering >> how it might be improved. I have a mix of thoughts here. >> >> For both my own unit and that of Timothy Rodgers, wifi reception in >> our garages was unusable. You can blame that on too much distance >> from the access point, but my iPhone and MacBook both access the wifi >> just fine from my garage. The wifi antenna in the OVMS is probably >> smaller and its location within the metal framework around the car's >> firewall may impede radio transmission. Perhaps it would be feasible >> to switch to an ESP32-WROVER-I with an external antenna to improve >> performance, but that would be a big deal. If there is a transmit >> power adjustment, perhaps that could be increased? >> >> When Timothy parks his car next to his house, which is about 50 feet >> closer than the garage, then the wifi reception was good enough for >> the update to 3.1.008 to succeed. But when he tries to connect with >> the browser, page updates often time out, so it is close to unusable. >> Perhaps we could improve usability by increasing the timeout in our >> javascript to allow more time for TCP to retransmit? >> >> For my own unit, I switched from AP+client to just client mode and at >> first it seemed that had improved the client performance. But still >> the next day I had no access from the iPhone app. When I connected to >> the console to find out why I saw that server v2 was repeatedly trying >> to connect and failing. I'm presuming that the cause was poor wifi >> connectivity since I was also not able to reach the web server on the >> client address, although I have not proven that. But since the client >> wifi was associated with the home AP and had an address, the OVMS >> network routing preferred the wifi and did not try to use the modem. >> For now I have resorted to turning off wifi. I suggest that the >> network routing algorithm be enhanced to back off to use the modem if >> some number of attempts to connect to the server over wifi have >> failed. The iPhone will do this for itself (there is a setting to >> enable this called Wi-Fi Assist). >> >> The behavior of repeated connection attempts and failures by server v2 >> seems to induce a more serious failure after a while, perhaps due to >> some resource starvation. At that point there is a failure message >> "mg_connect(api.openvehicles.com:6867 <http://api.openvehicles.com:6867/>) failed: cannot parse address" >> every time server v2 tries to connect. I expect that is a bug that >> could be fixed. >> >> Lastly, since we may encounter situations where network communication >> is not working, we should facilitate access to the console. When I >> was trying to help Timothy change a location radius setting remotely >> by phone and the web browser was timing out, I suggested that he find >> a micro-USB cable so he could connect to the console. But then I >> realized he would not have any application on his laptop that would >> allow him to connect to the console. Developers use "make monitor" in >> the software development cycle, but users won't have that tool. I >> have my own program on the MacBook that I use as an alternative when I >> don't want to induce a reset when I connect. But is there a simple >> program for Windows suitable for non-developer users that can connect >> to the OVMS console? >> >> -- Steve >> _______________________________________________ >> 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 <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 http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Done. Regards, Michael Am 09.07.2018 um 23:16 schrieb Stephen Casner:
Perhaps it is time to update sdkconfig.default.hw3{0,1} in conjunction with the esp-idf update?
-- Steve
On Mon, 9 Jul 2018, Mark Webb-Johnson wrote:
Works for me, and the tonight’s edge nightly build will feature this.
Only issue I am seeing is that Espressif seemed to have messed up the crlf handling on ‘make monitor’ again. The ‘make simple_monitor’ works fine, but for the full monitor terminal emulator, the CRLF issued by our console (when you press ENTER) is lost. Just seems to end up as a CR (LF discarded).
Regards, Mark.
On 9 Jul 2018, at 6:14 AM, Michael Balzer <dexter@expeedo.de> wrote:
Sorry, no user feedback up to now on the wifi issues. As I don't have them myself, I need to wait for feedback. But no news means it's at least not worse than before ;)
Anyway, I've pushed the changes and esp-idf update.
@all: you need to update your esp-idf to build the current version: cd $IDF_PATH git pull git submodule update --recursive
Regards, Michael
Am 08.07.2018 um 10:59 schrieb Mark Webb-Johnson:
I even have some more free IRAM now, it used to be down to ~1K and is now ~7K. That is very very good news. Using RELEASE build (rather than DEBUG), I got mine down to a usable level, but this should give us some breathing room.
Any noticeable improvement to the wifi issues?
Regards, Mark.
On 8 Jul 2018, at 4:49 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
The new esp-idf works good, I think I'll push the changes this evening.
I even have some more free IRAM now, it used to be down to ~1K and is now ~7K.
Remaining crashes recorded up to now: 3.1.008-32-g2fa3ab8-dirty/ota_1/edge (build idf v3.2-dev-168-g0fb2019f Jul 6 2018 20:49:00),7,Crash,8,14,1,0,IllegalInstruction,0,0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 ,
3.1.008-32-g2fa3ab8-dirty/ota_0/edge (build idf v3.2-dev-168-g0fb2019f Jul 6 2018 20:49:00),98,Crash,8,14,1,0,LoadProhibited,1,0x401165fc 0x00060230 0x80106004 0x3fff0d40 0x3ffc4794 0x00000000 0x3f4020ac 0x3fff1080 0x3fff1060 0x00000008 0x3ffed634 0x00000000 0x00000001 0x3ffc41f5 0x000000ff 0x0000ff00 0x00ff0000 0xff000000 0x00000004 0x0000001c 0x00000064 0x4009ee01 0x4009ee11 0xffffffff ,0x401165fc 0x40106001 0x400d3f9b 0x400d3ab5 → Using elf file: tmp/3.1.008-32-g2fa3ab8-dirty-elf/ovms3.elf 0x401165fc is in _vfprintf_r (../../../.././newlib/libc/stdio/vfprintf.c:1855). 0x40106001 is in _siprintf_r (../../../.././newlib/libc/stdio/siprintf.c:124). 0x400d3f9b is in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_construct<char*>(char*, char*, std::forward_iterator_tag) (/home/balzer/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.tcc:215). 210 basic_string<_CharT, _Traits, _Alloc>:: 211 _M_construct(_InIterator __beg, _InIterator __end, 212 std::forward_iterator_tag) 213 { 214 // NB: Not required, but considered best practice. 215 if (__gnu_cxx::__is_null_pointer(__beg) && __beg != __end) 216 std::__throw_logic_error(__N("basic_string::" 217 "_M_construct null not valid")); 218 219 size_type __dnew = static_cast<size_type>(std::distance(__beg, __end)); 0x400d3ab5 is in canlog::LogStatus(canbus*, CAN_LogEntry_t, CAN_status_t const*) (/home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/can/src/canlog.cpp:297). 292 return; 293 if (CheckFilter(bus, type)) 294 { 295 CAN_LogMsg_t msg; 296 msg.timestamp = esp_log_timestamp(); 297 msg.bus = bus; 298 msg.type = type; 299 msg.status = *status; 300 m_msgcount++; 301 if (xQueueSend(m_queue, &msg, 0) != pdTRUE)
3.1.008-32-g2fa3ab8-dirty/ota_1/edge (build idf v3.2-dev-168-g0fb2019f Jul 6 2018 20:49:00),11,Crash,12,12,3,0,abort(),0,,0x40095e74 0x4009606f 0x400ddaf7 0x40084e15 0x401e271d → watchdog timeout, no more info Regards, Michael
Am 06.07.2018 um 22:07 schrieb Michael Balzer:
I've been using APCLIENT all the time and only had one crash that looked like a wifi problem. This really is a very specific problem. I also have a very good wifi signal, I can perfectly use my module's web UI while the car is in my garage two floors below. But I live in an uncrowded area, not much wifi competition.
I have updated my esp-idf to the latest upstream master (it's v3.2 now) and could build without any memory issues. The wifi driver now, besided loads of bug fixes, also supports CSI. Our code only needs a minor adjustment if you'd like to compile yourself, add…
#define _SOC_SPI_PERIPH_H_ // don't include spi_periph.h (type conflict)
…in components/spinodma/spi_master_nodma.h before #include "driver/spi_common.h".
If you don't want to compile, the new build (with CSI enabled) is also on my server:
http://ovms.dexters-web.de/firmware/ota/v3.1/edge/ <http://ovms.dexters-web.de/firmware/ota/v3.1/edge/>
…and now being installed by my beta testers.
Regards, Michael
Am 06.07.2018 um 16:28 schrieb Mark Webb-Johnson: > My 2c: > > For the access points I normally use, it works 100% of the time for me. The only issue I had was when the SSID password was wrong on one of my access points (sharing the same SSID) and that was randomly causing me connection issues (every time the ESP32 picked it). > > I also don’t use APCLIENT, and only use SCLIENT mode. I’ve found APCLIENT to be buggy as hell. > > But, I do have problems connecting to some access points. In particular phone hotspots. I suspect either bugs in the wifi stack, or some issue with channels. > > The only thing I am wary of is that our current code does this: > > esp_wifi_set_config… > esp_wifi_start… > esp_wifi_connect... > > But the Espressif examples have: > > esp_wifi_set_config… > esp_wifi_start… > Wait for SYSTEM_EVENT_STA_START > esp_wifi_connect... > > I had that working the Espressif way in my big wifi refactor that never made it to production. But our current code doesn’t wait for the SYSTEM_EVENT_STA_START before calling esp_wifi_connect. > > Regards, Mark. > >> On 6 Jul 2018, at 9:04 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote: >> >> I've had similar reports regarding poor wifi connectivity, and this seems to affect some modules more than others (or may be channel/frequency dependant?). One >> user has just 1-2 bars AP wifi signal with the module placed ~ 50 cm away from the phone. >> >> I also still get reports of spurious strange crashes, that mostly seem to be related to situations with poor wifi signal. Some crash backtraces just are >> complete blank / null, and there is no crash report on the USB output for these before reboot. >> >> Yesterday, Frank tried to perform some wifi scans. The first scan went fine, the second never returned, he had to power off the module. After reboot, all >> successive scans worked. >> >> Two users reported they occasionally cannot auth to the OVMS AP with the correct password, and they can then reconnect just by retrying for some minutes or by >> connecting & disconnecting another client to the AP. >> >> I already had a look at the wifi tx power configuration, it's at 100% by default. >> >> This all feels like a) we need to change something about the antenna, and b) there are quite some bugs in the wifi blob. >> >> Looking at https://github.com/espressif/esp32-wifi-lib/commits/master <https://github.com/espressif/esp32-wifi-lib/commits/master> it seems there have been numerous wifi blob fixes lately. Last time I checked I still was >> out of memory with the current esp-idf, I'll check again. >> >> Regards, >> Michael >> >> >> Am 06.07.2018 um 01:48 schrieb Stephen Casner: >>> I find the wifi performance of OVMS v3 to be poor, and I'm wondering >>> how it might be improved. I have a mix of thoughts here. >>> >>> For both my own unit and that of Timothy Rodgers, wifi reception in >>> our garages was unusable. You can blame that on too much distance >>> from the access point, but my iPhone and MacBook both access the wifi >>> just fine from my garage. The wifi antenna in the OVMS is probably >>> smaller and its location within the metal framework around the car's >>> firewall may impede radio transmission. Perhaps it would be feasible >>> to switch to an ESP32-WROVER-I with an external antenna to improve >>> performance, but that would be a big deal. If there is a transmit >>> power adjustment, perhaps that could be increased? >>> >>> When Timothy parks his car next to his house, which is about 50 feet >>> closer than the garage, then the wifi reception was good enough for >>> the update to 3.1.008 to succeed. But when he tries to connect with >>> the browser, page updates often time out, so it is close to unusable. >>> Perhaps we could improve usability by increasing the timeout in our >>> javascript to allow more time for TCP to retransmit? >>> >>> For my own unit, I switched from AP+client to just client mode and at >>> first it seemed that had improved the client performance. But still >>> the next day I had no access from the iPhone app. When I connected to >>> the console to find out why I saw that server v2 was repeatedly trying >>> to connect and failing. I'm presuming that the cause was poor wifi >>> connectivity since I was also not able to reach the web server on the >>> client address, although I have not proven that. But since the client >>> wifi was associated with the home AP and had an address, the OVMS >>> network routing preferred the wifi and did not try to use the modem. >>> For now I have resorted to turning off wifi. I suggest that the >>> network routing algorithm be enhanced to back off to use the modem if >>> some number of attempts to connect to the server over wifi have >>> failed. The iPhone will do this for itself (there is a setting to >>> enable this called Wi-Fi Assist). >>> >>> The behavior of repeated connection attempts and failures by server v2 >>> seems to induce a more serious failure after a while, perhaps due to >>> some resource starvation. At that point there is a failure message >>> "mg_connect(api.openvehicles.com:6867 <http://api.openvehicles.com:6867/>) failed: cannot parse address" >>> every time server v2 tries to connect. I expect that is a bug that >>> could be fixed. >>> >>> Lastly, since we may encounter situations where network communication >>> is not working, we should facilitate access to the console. When I >>> was trying to help Timothy change a location radius setting remotely >>> by phone and the web browser was timing out, I suggested that he find >>> a micro-USB cable so he could connect to the console. But then I >>> realized he would not have any application on his laptop that would >>> allow him to connect to the console. Developers use "make monitor" in >>> the software development cycle, but users won't have that tool. I >>> have my own program on the MacBook that I use as an alternative when I >>> don't want to induce a reset when I connect. But is there a simple >>> program for Windows suitable for non-developer users that can connect >>> to the OVMS console? >>> >>> -- Steve >>> _______________________________________________ >>> 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 <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 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
participants (4)
-
Greg D. -
Mark Webb-Johnson -
Michael Balzer -
Stephen Casner