Michael, Thanks for the suggestions. Since I only use the WiFi when the car is in my garage where I now have a nearby AP, I don't need to worry about trying to keep a connection when the signal is poor so the event idea should do the trick. My laptop can switch from one AP to another as I move around without dropping network connections. So I guess it can hear other APs and decide when to switch for a better signal. Could the OVMS hardware and driver allow that? -- Steve On Mon, 7 Dec 2020, Michael Balzer wrote:

Steve,

that's something we can control.

If you don't mind frequent disconnects in poor Wifi situations, a simple solution now is to attach a "wifi reconnect" command call to the "network.wifi.sta.bad" event. I added that command on the Wifi rework some months ago.

For a better, general solution, we could e.g. count the "network.wifi.sta.bad" events on the same network (or better: check the event frequency) and disconnect when reaching some (tunable) threshold. The next automatic scan then connects to the best network available. Getting stuck in the "bad signal" state for too long would also need to trigger a disconnect.

Regards, Michael

Am 07.12.20 um 07:21 schrieb Stephen Casner:

...

Many months ago I installed another AP for the home network in my garage because the signal quality to the main router was too poor for OVMS to operate. Today I needed to restart the garage AP, so OVMS hear the main router again and associated to it. But even after the garage AP came back up, OVMS stuck with the main router and kept toggling between WiFi and modem because the signal quality was bad.

It this behavior just a function of the WiFi driver that we can't control, or is it something we could improve?

I fixed it by "wifi mode off" then "wifi mode client".

-- Steve

I (513443477) netmanager: WIFI client has bad signal quality (-89.2 dBm); disconnect I (513443477) netmanager: Interface priority is pp2 (10.170.41.247/255.255.255.255 gateway 10.64.64.64) I (513443477) netmanager: Set DNS#0 8.8.8.8 I (513443477) netmanager: Set DNS#1 8.8.4.4 I (513443477) netmanager: WIFI client down (with MODEM up): reconfigured for MODEM priority I (513443537) time: Network was reconfigured: restarting SNTP client I (513443547) ovms-server-v2: Network was reconfigured: disconnect, and reconnect in 10 seconds I (513443547) ovms-server-v2: Status: Network was reconfigured: disconnect, and reconnect in 10 seconds I (513443717) ovms-server-v2: Status: Disconnected I (513463467) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 I (513463467) ovms-server-v2: Status: Connecting... I (513466157) ovms-server-v2: Connection successful I (513466157) ovms-server-v2: Status: Logging in... ... I (513522477) netmanager: WIFI client has good signal quality (-86.9 dBm); connect I (513522477) netmanager: Interface priority is st13 (192.168.1.74/255.255.255.0 gateway 192.168.1.254) I (513522477) netmanager: Set DNS#0 8.8.8.8 I (513522477) netmanager: Set DNS#1 8.8.4.4 I (513522477) netmanager: WIFI client up (with MODEM up): reconfigured for WIFI client priority I (513522527) time: Network was reconfigured: restarting SNTP client I (513522527) ovms-server-v2: Network was reconfigured: disconnect, and reconnect in 10 seconds I (513522527) ovms-server-v2: Status: Network was reconfigured: disconnect, and reconnect in 10 seconds I (513522697) ovms-server-v2: Status: Disconnected I (513529477) netmanager: WIFI client has bad signal quality (-89.0 dBm); disconnect I (513529477) netmanager: Interface priority is pp2 (10.170.41.247/255.255.255.255 gateway 10.64.64.64) I (513529477) netmanager: Set DNS#0 8.8.8.8 I (513529477) netmanager: Set DNS#1 8.8.4.4 I (513529477) netmanager: WIFI client down (with MODEM up): reconfigured for MODEM priority I (513529527) time: Network was reconfigured: restarting SNTP client I (513529537) ovms-server-v2: Network was reconfigured: disconnect, and reconnect in 10 seconds I (513529537) ovms-server-v2: Status: Network was reconfigured: disconnect, and reconnect in 10 seconds I (513539467) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 I (513539467) ovms-server-v2: Status: Connecting... I (513541987) ovms-server-v2: Connection successful I (513541987) ovms-server-v2: Status: Logging in... _______________________________________________ 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, Switching to another network would imply a change of IP address and, as you say, breaking all TCP connections. But the case I was talking about with my laptop is just switching to another AP on the same network, so the IP address does not change and TCP connections are maintained. In the OVMS case, even if the scan for networks does report multiple APs for the same network, it might still be that switching causes a problem at the LWIP or Mongoose level. -- Steve On Mon, 7 Dec 2020, Michael Balzer wrote:

Steve,

scanning for networks is possible now without disrupting the Wifi mode, but TCP connections won't survive a switch to another network.

So if you implement that, I suggest only switching to another known network if it's substantially better than the current one.

Regards, Michael

Am 07.12.20 um 22:27 schrieb Stephen Casner:

...

Michael,

Thanks for the suggestions. Since I only use the WiFi when the car is in my garage where I now have a nearby AP, I don't need to worry about trying to keep a connection when the signal is poor so the event idea should do the trick.

My laptop can switch from one AP to another as I move around without dropping network connections. So I guess it can hear other APs and decide when to switch for a better signal. Could the OVMS hardware and driver allow that?

-- Steve

On Mon, 7 Dec 2020, Michael Balzer wrote:

...

Steve,

that's something we can control.

If you don't mind frequent disconnects in poor Wifi situations, a simple solution now is to attach a "wifi reconnect" command call to the "network.wifi.sta.bad" event. I added that command on the Wifi rework some months ago.

For a better, general solution, we could e.g. count the "network.wifi.sta.bad" events on the same network (or better: check the event frequency) and disconnect when reaching some (tunable) threshold. The next automatic scan then connects to the best network available. Getting stuck in the "bad signal" state for too long would also need to trigger a disconnect.

Regards, Michael

Am 07.12.20 um 07:21 schrieb Stephen Casner:

...

Many months ago I installed another AP for the home network in my garage because the signal quality to the main router was too poor for OVMS to operate. Today I needed to restart the garage AP, so OVMS hear the main router again and associated to it. But even after the garage AP came back up, OVMS stuck with the main router and kept toggling between WiFi and modem because the signal quality was bad.

It this behavior just a function of the WiFi driver that we can't control, or is it something we could improve?

I fixed it by "wifi mode off" then "wifi mode client".

-- Steve

I (513443477) netmanager: WIFI client has bad signal quality (-89.2 dBm); disconnect I (513443477) netmanager: Interface priority is pp2 (10.170.41.247/255.255.255.255 gateway 10.64.64.64) I (513443477) netmanager: Set DNS#0 8.8.8.8 I (513443477) netmanager: Set DNS#1 8.8.4.4 I (513443477) netmanager: WIFI client down (with MODEM up): reconfigured for MODEM priority I (513443537) time: Network was reconfigured: restarting SNTP client I (513443547) ovms-server-v2: Network was reconfigured: disconnect, and reconnect in 10 seconds I (513443547) ovms-server-v2: Status: Network was reconfigured: disconnect, and reconnect in 10 seconds I (513443717) ovms-server-v2: Status: Disconnected I (513463467) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 I (513463467) ovms-server-v2: Status: Connecting... I (513466157) ovms-server-v2: Connection successful I (513466157) ovms-server-v2: Status: Logging in... ... I (513522477) netmanager: WIFI client has good signal quality (-86.9 dBm); connect I (513522477) netmanager: Interface priority is st13 (192.168.1.74/255.255.255.0 gateway 192.168.1.254) I (513522477) netmanager: Set DNS#0 8.8.8.8 I (513522477) netmanager: Set DNS#1 8.8.4.4 I (513522477) netmanager: WIFI client up (with MODEM up): reconfigured for WIFI client priority I (513522527) time: Network was reconfigured: restarting SNTP client I (513522527) ovms-server-v2: Network was reconfigured: disconnect, and reconnect in 10 seconds I (513522527) ovms-server-v2: Status: Network was reconfigured: disconnect, and reconnect in 10 seconds I (513522697) ovms-server-v2: Status: Disconnected I (513529477) netmanager: WIFI client has bad signal quality (-89.0 dBm); disconnect I (513529477) netmanager: Interface priority is pp2 (10.170.41.247/255.255.255.255 gateway 10.64.64.64) I (513529477) netmanager: Set DNS#0 8.8.8.8 I (513529477) netmanager: Set DNS#1 8.8.4.4 I (513529477) netmanager: WIFI client down (with MODEM up): reconfigured for MODEM priority I (513529527) time: Network was reconfigured: restarting SNTP client I (513529537) ovms-server-v2: Network was reconfigured: disconnect, and reconnect in 10 seconds I (513529537) ovms-server-v2: Status: Network was reconfigured: disconnect, and reconnect in 10 seconds I (513539467) ovms-server-v2: Connection is api.openvehicles.com:6867 US33 I (513539467) ovms-server-v2: Status: Connecting... I (513541987) ovms-server-v2: Connection successful I (513541987) ovms-server-v2: Status: Logging in... _______________________________________________ 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

Following up: I see that OvmsNetManager::WifiStaGotIP() calls WifiStaCheckSQ() at the start of the connection, but it looks like the radio hasn't fully adapted yet or something. The signal quality can be -95.5 -99.2 dBm and sometimes even -127.0 dBm, which looks like an uninitialized value, even though wifi scan says the RSSI is -60. (Is RSSI calibrated to dBm for this system?) If I stop the looping by "wifi mode off" and "wifi mode client" then I see a good signal quality -79.3 reported after getting IP, and then if I do "wifi status" the reported signal quality is -56.0 dBm. This is all with my test OVMS v3.0 sitting on my desk. So would it make sense to introduce some delay here if the signal quality is not good enough yet? -- Steve On Mon, 14 Dec 2020, Stephen Casner wrote:

On Mon, 7 Dec 2020, Michael Balzer wrote:

...

If you don't mind frequent disconnects in poor Wifi situations, a simple solution now is to attach a "wifi reconnect" command call to the "network.wifi.sta.bad" event. I added that command on the Wifi rework some months ago.

I tested this today with the three APs in my home but ran into trouble. It looks like the event was emitted again at the end of the reconnection process so another reconnect was performed and it kept looping. See the attached log. I have not investigated this carefully.

...

For a better, general solution, we could e.g. count the "network.wifi.sta.bad" events on the same network (or better: check the event frequency) and disconnect when reaching some (tunable) threshold. The next automatic scan then connects to the best network available. Getting stuck in the "bad signal" state for too long would also need to trigger a disconnect.

I'll look at this further to see whether a smooth transition from one AP to another on the same network is possible.

-- Steve

Hi all, I tried to steal some code from the Twizy module but obviously don't understand how it works... my code results in a boot loop. I would like to have a possibility to test OBD codes in the shell (something I think would be immensely useful as a general function; that way, getting started with a new vehicle would be much easier.) Anyway, the problem seems to be in the lookup of the command name I'm trying to register, see stack trace below. Any help is greatly appreciated! Thanks, sharkcow 0x400fc115 is in std::_Rb_tree<char const*, std::pair<char const* const, OvmsCommand*>, std::_Select1st<std::pair<char const* const, OvmsCommand*> >, CompareCharPtr, std::allocator<std::pair<char const* const, OvmsCommand*> > >::find(char const* const&) (/opt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:663). 658 (this->_M_impl._M_header._M_parent); 659 } 660 661 _Link_type 662 _M_end() _GLIBCXX_NOEXCEPT 663 { return reinterpret_cast<_Link_type>(&this->_M_impl._M_header); } 664 665 _Const_Link_type 666 _M_end() const _GLIBCXX_NOEXCEPT 667 { return reinterpret_cast<_Const_Link_type>(&this->_M_impl._M_header); } 0x400fc15c is in OvmsCommandMap::FindCommand(char const*) (/opt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_map.h:846). 841 * past-the-end ( @c end() ) iterator. 842 */ 843 844 iterator 845 find(const key_type& __x) 846 { return _M_t.find(__x); } 847 848 #if __cplusplus > 201103L 849 template<typename _Kt> 850 auto 0x400fd87e is in OvmsCommand::RegisterCommand(char const*, char const*, void (*)(int, OvmsWriter*, OvmsCommand*, int, char const* const*), char const*, int, int, bool, int (*)(OvmsWriter*, OvmsCommand*, int, char const* const*, bool)) (/opt/Open-Vehicle-Monitoring-System-3_Unh/vehicle/OVMS.V3/main/ovms_command.cpp:542). 537 return m_parent; 538 } 539 540 OvmsCommand* OvmsCommand::FindCommand(const char* name) 541 { 542 return m_children.FindCommand(name); 543 } 544 545 void help(int verbosity, OvmsWriter* writer, OvmsCommand* cmd, int argc, const char* const* argv) 546 { 0x401ac67a is in OvmsVehicleVWeUp::OBDInit() (/opt/Open-Vehicle-Monitoring-System-3_Unh/vehicle/OVMS.V3/components/vehicle_vweup_all/src/vweup_obd.cpp:228). 223 // cmd->RegisterCommand("reset", "Reset OVMS DTC statistics", shell_obd_resetdtc, 224 // "Resets internal DTC buffer and presence counters.\n" 225 // "No change is done on the car side."); 226 227 OvmsCommand* obd; 228 obd = cmd_xvu->RegisterCommand("obd", "OBD2 tools"); 229 cmd = obd->RegisterCommand("request", "Send OBD2 request, output response"); 230 cmd->RegisterCommand("device", "Send OBD2 request to a device", shell_obd_request, "<txid> <rxid> <request>", 3, 3); 231 cmd->RegisterCommand("broadcast", "Send OBD2 request as broadcast", shell_obd_request, "<request>", 1, 1); 232 cmd->RegisterCommand("01motelec", "Send OBD2 request to ECU01 motor electronics", shell_obd_request, "<request>", 1, 1); 0x401abd4e is in OvmsVehicleVWeUp::ConfigChanged(OvmsConfigParam*) (/opt/Open-Vehicle-Monitoring-System-3_Unh/vehicle/OVMS.V3/components/vehicle_vweup_all/src/vehicle_vweup_all.cpp:210). 205 if (vweup_enable_t26) 206 T26Init(); 207 vweup_con = vweup_enable_obd * 2 + vweup_enable_t26; 208 // ESP_LOGD(TAG,"vweup_con: %i",vweup_con); 209 if (vweup_enable_obd || (vweup_modelyear<2020 && vweup_modelyear_new>2019) || (vweup_modelyear_new<2020 && vweup_modelyear>2019)) // switch between generations: reload OBD poll list 210 OBDInit(); 211 if (!vweup_enable_obd) 212 OBDDeInit(); 213 vweup_modelyear = vweup_modelyear_new; 214 if (!vweup_con) 0x401abf5f is in OvmsVehicleVWeUp::OvmsVehicleVWeUp() (/opt/Open-Vehicle-Monitoring-System-3_Unh/vehicle/OVMS.V3/components/vehicle_vweup_all/src/vehicle_vweup_all.cpp:124). 119 { 120 ESP_LOGI(TAG, "Start VW e-Up vehicle module"); 121 122 // init configs: 123 MyConfig.RegisterParam("xvu", "VW e-Up", true, true); 124 ConfigChanged(NULL); 125 126 // if (vweup_con % 2){ // T26A connected 127 // } 128 // if (vweup_con > 1){ // OBD connected 0x401abf9a is in CreateVehicle<OvmsVehicleVWeUp>() (/opt/Open-Vehicle-Monitoring-System-3_Unh/vehicle/OVMS.V3/components/vehicle/vehicle.h:456). 451 virtual bool FormatBmsAlerts(int verbosity, OvmsWriter* writer, bool show_warnings); 452 }; 453 454 template<typename Type> OvmsVehicle* CreateVehicle() 455 { 456 return new Type; 457 } 458 459 class OvmsVehicleFactory 460 { 0x401656ff is in OvmsVehicleFactory::NewVehicle(char const*) (/opt/Open-Vehicle-Monitoring-System-3_Unh/vehicle/OVMS.V3/components/vehicle/vehicle.cpp:873). 868 OvmsVehicle* OvmsVehicleFactory::NewVehicle(const char* VehicleType) 869 { 870 OvmsVehicleFactory::map_vehicle_t::iterator iter = m_vmap.find(VehicleType); 871 if (iter != m_vmap.end()) 872 { 873 return iter->second.construct(); 874 } 875 return NULL; 876 } 877 0x40165737 is in OvmsVehicleFactory::SetVehicle(char const*) (/opt/Open-Vehicle-Monitoring-System-3_Unh/vehicle/OVMS.V3/components/vehicle/vehicle.cpp:900). 895 m_currentvehicle->m_ready = false; 896 delete m_currentvehicle; 897 m_currentvehicle = NULL; 898 m_currentvehicletype.clear(); 899 } 900 m_currentvehicle = NewVehicle(type); 901 if (m_currentvehicle) 902 { 903 m_currentvehicle->m_ready = true; 904 } 0x40165825 is in OvmsVehicleFactory::AutoInit() (/opt/Open-Vehicle-Monitoring-System-3_Unh/vehicle/OVMS.V3/components/vehicle/vehicle.cpp:914). 909 910 void OvmsVehicleFactory::AutoInit() 911 { 912 std::string type = MyConfig.GetParamValue("auto", "vehicle.type"); 913 if (!type.empty()) 914 SetVehicle(type.c_str()); 915 } 916 917 OvmsVehicle* OvmsVehicleFactory::ActiveVehicle() 918 { 0x400f80f3 is in Housekeeping::Init(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, void*) (/opt/Open-Vehicle-Monitoring-System-3_Unh/vehicle/OVMS.V3/main/ovms_housekeeping.cpp:208). 203 ESP_LOGI(TAG, "Auto init modem (free: %zu bytes)", heap_caps_get_free_size(MALLOC_CAP_8BIT|MALLOC_CAP_INTERNAL)); 204 MyPeripherals->m_simcom->AutoInit(); 205 #endif // #ifdef CONFIG_OVMS_COMP_MODEM_SIMCOM 206 207 ESP_LOGI(TAG, "Auto init vehicle (free: %zu bytes)", heap_caps_get_free_size(MALLOC_CAP_8BIT|MALLOC_CAP_INTERNAL)); 208 MyVehicleFactory.AutoInit(); 209 210 #ifdef CONFIG_OVMS_COMP_OBD2ECU 211 ESP_LOGI(TAG, "Auto init obd2ecu (free: %zu bytes)", heap_caps_get_free_size(MALLOC_CAP_8BIT|MALLOC_CAP_INTERNAL)); 212 obd2ecuInit.AutoInit(); 0x400f7d06 is in std::_Function_handler<void (std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, void*), std::_Bind<std::_Mem_fn<void (Housekeeping::*)(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, void*)> (Housekeeping*, std::_Placeholder<1>, std::_Placeholder<2>)> >::_M_invoke(std::_Any_data const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&&, void*&&) (/opt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/functional:600). 595 template<typename... _Args, typename _Req 596 = _Require<typename _Traits::__lvalue, 597 _CheckArgs<_Pack<_Args...>>>> 598 result_type 599 operator()(_Class* __object, _Args&&... __args) const 600 { return (__object->*_M_pmf)(std::forward<_Args>(__args)...); } 601 602 // Handle smart pointers, references and pointers to derived 603 template<typename _Tp, typename... _Args, typename _Req 604 = _Require<_NotSame<_Class, _Tp>, _NotSame<_Class*, _Tp>, 0x400f457e is in std::function<void (std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, void*)>::operator()(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, void*) const (/opt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/functional:2271). 2266 function<_Res(_ArgTypes...)>:: 2267 operator()(_ArgTypes... __args) const 2268 { 2269 if (_M_empty()) 2270 __throw_bad_function_call(); 2271 return _M_invoker(_M_functor, std::forward<_ArgTypes>(__args)...); 2272 } 2273 2274 #if __cpp_rtti 2275 template<typename _Res, typename... _ArgTypes> 0x400f4711 is in OvmsEvents::HandleQueueSignalEvent(event_queue_t*) (/opt/Open-Vehicle-Monitoring-System-3_Unh/vehicle/OVMS.V3/main/ovms_events.cpp:229). 224 { 225 for (EventCallbackList::iterator itc=el->begin(); itc!=el->end(); ++itc) 226 { 227 m_current_started = monotonictime; 228 m_current_callback = *itc; 229 m_current_callback->m_callback(m_current_event, msg->body.signal.data); 230 m_current_callback = NULL; 231 } 232 } 233 } 0x400f47f4 is in OvmsEvents::EventTask() (/opt/Open-Vehicle-Monitoring-System-3_Unh/vehicle/OVMS.V3/main/ovms_events.cpp:187). 182 { 183 case EVENT_none: 184 break; 185 case EVENT_signal: 186 m_current_event = msg.body.signal.event; 187 HandleQueueSignalEvent(&msg); 188 esp_task_wdt_reset(); // Reset WATCHDOG timer for this task 189 m_current_event.clear(); 190 break; 191 default: 0x400f4859 is in EventLaunchTask(void*) (/opt/Open-Vehicle-Monitoring-System-3_Unh/vehicle/OVMS.V3/main/ovms_events.cpp:57). 52 53 void EventLaunchTask(void *pvParameters) 54 { 55 OvmsEvents* me = (OvmsEvents*)pvParameters; 56 57 me->EventTask(); 58 } 59 60 void event_trace(int verbosity, OvmsWriter* writer, OvmsCommand* cmd, int argc, const char* const* argv) 61 {

Sorry, obviously should have included this. The includes are copied from the twizy files. In my main header file, I have: class OvmsVehicleVWeUp : public OvmsVehicle { ... protected: OvmsCommand *cmd_xvu; ... public: // Shell commands: static void shell_obd_request(int verbosity, OvmsWriter* writer, OvmsCommand* cmd, int argc, const char* const* argv); ... } in the main cpp file: OvmsVehicleVWeUp::OvmsVehicleVWeUp() { ... // init commands: cmd_xvu = MyCommandApp.RegisterCommand("xvu", "VW e-Up"); ... } in the obd cpp file: void OvmsVehicleVWeUp::OBDInit() { .. // init commands: OvmsCommand* cmd; OvmsCommand* obd; obd = cmd_xvu->RegisterCommand("obd", "OBD2 tools"); cmd = obd->RegisterCommand("request", "Send OBD2 request, output response"); cmd->RegisterCommand("device", "Send OBD2 request to a device", shell_obd_request, "<txid> <rxid> <request>", 3, 3); cmd->RegisterCommand("broadcast", "Send OBD2 request as broadcast", shell_obd_request, "<request>", 1, 1); cmd->RegisterCommand("01motelec", "Send OBD2 request to ECU01 motor electronics", shell_obd_request, "<request>", 1, 1); } Am 17.12.20 um 08:54 schrieb Mark Webb-Johnson:

Can you post an extract of your command registry code?

...

On 17 Dec 2020, at 2:50 PM, sharkcow <sharkcow@gmx.de> wrote:

Hi all,

I tried to steal some code from the Twizy module but obviously don't understand how it works... my code results in a boot loop.

I would like to have a possibility to test OBD codes in the shell (something I think would be immensely useful as a general function; that way, getting started with a new vehicle would be much easier.)

Anyway, the problem seems to be in the lookup of the command name I'm trying to register, see stack trace below. Any help is greatly appreciated!

Thanks,

sharkcow

0x400fc115 is in std::_Rb_tree<char const*, std::pair<char const* const, OvmsCommand*>, std::_Select1st<std::pair<char const* const, OvmsCommand*> >, CompareCharPtr, std::allocator<std::pair<char const* const, OvmsCommand*> > >::find(char const* const&) (/opt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:663). 658 (this->_M_impl._M_header._M_parent); 659 } 660 661 _Link_type 662 _M_end() _GLIBCXX_NOEXCEPT 663 { return reinterpret_cast<_Link_type>(&this->_M_impl._M_header); } 664 665 _Const_Link_type 666 _M_end() const _GLIBCXX_NOEXCEPT 667 { return reinterpret_cast<_Const_Link_type>(&this->_M_impl._M_header); } 0x400fc15c is in OvmsCommandMap::FindCommand(char const*) (/opt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_map.h:846). 841 * past-the-end ( @c end() ) iterator. 842 */ 843 844 iterator 845 find(const key_type& __x) 846 { return _M_t.find(__x); } 847 848 #if __cplusplus > 201103L 849 template<typename _Kt> 850 auto 0x400fd87e is in OvmsCommand::RegisterCommand(char const*, char const*, void (*)(int, OvmsWriter*, OvmsCommand*, int, char const* const*), char const*, int, int, bool, int (*)(OvmsWriter*, OvmsCommand*, int, char const* const*, bool)) (/opt/Open-Vehicle-Monitoring-System-3_Unh/vehicle/OVMS.V3/main/ovms_command.cpp:542). 537 return m_parent; 538 } 539 540 OvmsCommand* OvmsCommand::FindCommand(const char* name) 541 { 542 return m_children.FindCommand(name); 543 } 544 545 void help(int verbosity, OvmsWriter* writer, OvmsCommand* cmd, int argc, const char* const* argv) 546 { 0x401ac67a is in OvmsVehicleVWeUp::OBDInit() (/opt/Open-Vehicle-Monitoring-System-3_Unh/vehicle/OVMS.V3/components/vehicle_vweup_all/src/vweup_obd.cpp:228). 223 // cmd->RegisterCommand("reset", "Reset OVMS DTC statistics", shell_obd_resetdtc, 224 // "Resets internal DTC buffer and presence counters.\n" 225 // "No change is done on the car side."); 226 227 OvmsCommand* obd; 228 obd = cmd_xvu->RegisterCommand("obd", "OBD2 tools"); 229 cmd = obd->RegisterCommand("request", "Send OBD2 request, output response"); 230 cmd->RegisterCommand("device", "Send OBD2 request to a device", shell_obd_request, "<txid> <rxid> <request>", 3, 3); 231 cmd->RegisterCommand("broadcast", "Send OBD2 request as broadcast", shell_obd_request, "<request>", 1, 1); 232 cmd->RegisterCommand("01motelec", "Send OBD2 request to ECU01 motor electronics", shell_obd_request, "<request>", 1, 1); 0x401abd4e is in OvmsVehicleVWeUp::ConfigChanged(OvmsConfigParam*) (/opt/Open-Vehicle-Monitoring-System-3_Unh/vehicle/OVMS.V3/components/vehicle_vweup_all/src/vehicle_vweup_all.cpp:210). 205 if (vweup_enable_t26) 206 T26Init(); 207 vweup_con = vweup_enable_obd * 2 + vweup_enable_t26; 208 // ESP_LOGD(TAG,"vweup_con: %i",vweup_con); 209 if (vweup_enable_obd || (vweup_modelyear<2020 && vweup_modelyear_new>2019) || (vweup_modelyear_new<2020 && vweup_modelyear>2019)) // switch between generations: reload OBD poll list 210 OBDInit(); 211 if (!vweup_enable_obd) 212 OBDDeInit(); 213 vweup_modelyear = vweup_modelyear_new; 214 if (!vweup_con) 0x401abf5f is in OvmsVehicleVWeUp::OvmsVehicleVWeUp() (/opt/Open-Vehicle-Monitoring-System-3_Unh/vehicle/OVMS.V3/components/vehicle_vweup_all/src/vehicle_vweup_all.cpp:124). 119 { 120 ESP_LOGI(TAG, "Start VW e-Up vehicle module"); 121 122 // init configs: 123 MyConfig.RegisterParam("xvu", "VW e-Up", true, true); 124 ConfigChanged(NULL); 125 126 // if (vweup_con % 2){ // T26A connected 127 // } 128 // if (vweup_con > 1){ // OBD connected 0x401abf9a is in CreateVehicle<OvmsVehicleVWeUp>() (/opt/Open-Vehicle-Monitoring-System-3_Unh/vehicle/OVMS.V3/components/vehicle/vehicle.h:456). 451 virtual bool FormatBmsAlerts(int verbosity, OvmsWriter* writer, bool show_warnings); 452 }; 453 454 template<typename Type> OvmsVehicle* CreateVehicle() 455 { 456 return new Type; 457 } 458 459 class OvmsVehicleFactory 460 { 0x401656ff is in OvmsVehicleFactory::NewVehicle(char const*) (/opt/Open-Vehicle-Monitoring-System-3_Unh/vehicle/OVMS.V3/components/vehicle/vehicle.cpp:873). 868 OvmsVehicle* OvmsVehicleFactory::NewVehicle(const char* VehicleType) 869 { 870 OvmsVehicleFactory::map_vehicle_t::iterator iter = m_vmap.find(VehicleType); 871 if (iter != m_vmap.end()) 872 { 873 return iter->second.construct(); 874 } 875 return NULL; 876 } 877 0x40165737 is in OvmsVehicleFactory::SetVehicle(char const*) (/opt/Open-Vehicle-Monitoring-System-3_Unh/vehicle/OVMS.V3/components/vehicle/vehicle.cpp:900). 895 m_currentvehicle->m_ready = false; 896 delete m_currentvehicle; 897 m_currentvehicle = NULL; 898 m_currentvehicletype.clear(); 899 } 900 m_currentvehicle = NewVehicle(type); 901 if (m_currentvehicle) 902 { 903 m_currentvehicle->m_ready = true; 904 } 0x40165825 is in OvmsVehicleFactory::AutoInit() (/opt/Open-Vehicle-Monitoring-System-3_Unh/vehicle/OVMS.V3/components/vehicle/vehicle.cpp:914). 909 910 void OvmsVehicleFactory::AutoInit() 911 { 912 std::string type = MyConfig.GetParamValue("auto", "vehicle.type"); 913 if (!type.empty()) 914 SetVehicle(type.c_str()); 915 } 916 917 OvmsVehicle* OvmsVehicleFactory::ActiveVehicle() 918 { 0x400f80f3 is in Housekeeping::Init(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, void*) (/opt/Open-Vehicle-Monitoring-System-3_Unh/vehicle/OVMS.V3/main/ovms_housekeeping.cpp:208). 203 ESP_LOGI(TAG, "Auto init modem (free: %zu bytes)", heap_caps_get_free_size(MALLOC_CAP_8BIT|MALLOC_CAP_INTERNAL)); 204 MyPeripherals->m_simcom->AutoInit(); 205 #endif // #ifdef CONFIG_OVMS_COMP_MODEM_SIMCOM 206 207 ESP_LOGI(TAG, "Auto init vehicle (free: %zu bytes)", heap_caps_get_free_size(MALLOC_CAP_8BIT|MALLOC_CAP_INTERNAL)); 208 MyVehicleFactory.AutoInit(); 209 210 #ifdef CONFIG_OVMS_COMP_OBD2ECU 211 ESP_LOGI(TAG, "Auto init obd2ecu (free: %zu bytes)", heap_caps_get_free_size(MALLOC_CAP_8BIT|MALLOC_CAP_INTERNAL)); 212 obd2ecuInit.AutoInit(); 0x400f7d06 is in std::_Function_handler<void (std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, void*), std::_Bind<std::_Mem_fn<void (Housekeeping::*)(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, void*)> (Housekeeping*, std::_Placeholder<1>, std::_Placeholder<2>)> >::_M_invoke(std::_Any_data const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&&, void*&&) (/opt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/functional:600). 595 template<typename... _Args, typename _Req 596 = _Require<typename _Traits::__lvalue, 597 _CheckArgs<_Pack<_Args...>>>> 598 result_type 599 operator()(_Class* __object, _Args&&... __args) const 600 { return (__object->*_M_pmf)(std::forward<_Args>(__args)...); } 601 602 // Handle smart pointers, references and pointers to derived 603 template<typename _Tp, typename... _Args, typename _Req 604 = _Require<_NotSame<_Class, _Tp>, _NotSame<_Class*, _Tp>, 0x400f457e is in std::function<void (std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, void*)>::operator()(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, void*) const (/opt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/functional:2271). 2266 function<_Res(_ArgTypes...)>:: 2267 operator()(_ArgTypes... __args) const 2268 { 2269 if (_M_empty()) 2270 __throw_bad_function_call(); 2271 return _M_invoker(_M_functor, std::forward<_ArgTypes>(__args)...); 2272 } 2273 2274 #if __cpp_rtti 2275 template<typename _Res, typename... _ArgTypes> 0x400f4711 is in OvmsEvents::HandleQueueSignalEvent(event_queue_t*) (/opt/Open-Vehicle-Monitoring-System-3_Unh/vehicle/OVMS.V3/main/ovms_events.cpp:229). 224 { 225 for (EventCallbackList::iterator itc=el->begin(); itc!=el->end(); ++itc) 226 { 227 m_current_started = monotonictime; 228 m_current_callback = *itc; 229 m_current_callback->m_callback(m_current_event, msg->body.signal.data); 230 m_current_callback = NULL; 231 } 232 } 233 } 0x400f47f4 is in OvmsEvents::EventTask() (/opt/Open-Vehicle-Monitoring-System-3_Unh/vehicle/OVMS.V3/main/ovms_events.cpp:187). 182 { 183 case EVENT_none: 184 break; 185 case EVENT_signal: 186 m_current_event = msg.body.signal.event; 187 HandleQueueSignalEvent(&msg); 188 esp_task_wdt_reset(); // Reset WATCHDOG timer for this task 189 m_current_event.clear(); 190 break; 191 default: 0x400f4859 is in EventLaunchTask(void*) (/opt/Open-Vehicle-Monitoring-System-3_Unh/vehicle/OVMS.V3/main/ovms_events.cpp:57). 52 53 void EventLaunchTask(void *pvParameters) 54 { 55 OvmsEvents* me = (OvmsEvents*)pvParameters; 56 57 me->EventTask(); 58 } 59 60 void event_trace(int verbosity, OvmsWriter* writer, OvmsCommand* cmd, int argc, const char* const* argv) 61 {

_______________________________________________ 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

Thank you Michael, that was the right track: I call my OBDInit after every config change, so that's where the loop came from. All good now :) Am 17.12.20 um 15:17 schrieb Michael Balzer:

Do you call OBDInit() after the cmd_xvu init?

Regards, Michael

Am 17.12.20 um 15:02 schrieb sharkcow:

...

Sorry, obviously should have included this. The includes are copied from the twizy files.

In my main header file, I have:

class OvmsVehicleVWeUp : public OvmsVehicle   { ...   protected:     OvmsCommand *cmd_xvu; ...   public:     // Shell commands:     static void shell_obd_request(int verbosity, OvmsWriter* writer, OvmsCommand* cmd, int argc, const char* const* argv); ...   }

in the main cpp file:

OvmsVehicleVWeUp::OvmsVehicleVWeUp() { ... // init commands:     cmd_xvu = MyCommandApp.RegisterCommand("xvu", "VW e-Up"); ... }

in the obd cpp file:

void OvmsVehicleVWeUp::OBDInit() { ..     // init commands:     OvmsCommand* cmd;     OvmsCommand* obd;     obd = cmd_xvu->RegisterCommand("obd", "OBD2 tools");     cmd = obd->RegisterCommand("request", "Send OBD2 request, output response");     cmd->RegisterCommand("device", "Send OBD2 request to a device", shell_obd_request, "<txid> <rxid> <request>", 3, 3);     cmd->RegisterCommand("broadcast", "Send OBD2 request as broadcast", shell_obd_request, "<request>", 1, 1);     cmd->RegisterCommand("01motelec", "Send OBD2 request to ECU01 motor electronics", shell_obd_request, "<request>", 1, 1); }

Am 17.12.20 um 08:54 schrieb Mark Webb-Johnson:

...

Can you post an extract of your command registry code?

...

On 17 Dec 2020, at 2:50 PM, sharkcow <sharkcow@gmx.de> wrote:

Hi all,

I tried to steal some code from the Twizy module but obviously don't understand how it works... my code results in a boot loop.

I would like to have a possibility to test OBD codes in the shell (something I think would be immensely useful as a general function; that way, getting started with a new vehicle would be much easier.)

Anyway, the problem seems to be in the lookup of the command name I'm trying to register, see stack trace below. Any help is greatly appreciated!

Thanks,

sharkcow

0x400fc115 is in std::_Rb_tree<char const*, std::pair<char const* const, OvmsCommand*>, std::_Select1st<std::pair<char const* const, OvmsCommand*> >, CompareCharPtr, std::allocator<std::pair<char const* const, OvmsCommand*> > >::find(char const* const&) (/opt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_tree.h:663).

658          (this->_M_impl._M_header._M_parent); 659          } 660 661          _Link_type 662          _M_end() _GLIBCXX_NOEXCEPT 663          { return reinterpret_cast<_Link_type>(&this->_M_impl._M_header); } 664 665          _Const_Link_type 666          _M_end() const _GLIBCXX_NOEXCEPT 667          { return reinterpret_cast<_Const_Link_type>(&this->_M_impl._M_header); } 0x400fc15c is in OvmsCommandMap::FindCommand(char const*) (/opt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/stl_map.h:846).

841           *  past-the-end ( @c end() ) iterator. 842           */ 843 844          iterator 845          find(const key_type& __x) 846          { return _M_t.find(__x); } 847 848    #if __cplusplus > 201103L 849          template<typename _Kt> 850        auto 0x400fd87e is in OvmsCommand::RegisterCommand(char const*, char const*, void (*)(int, OvmsWriter*, OvmsCommand*, int, char const* const*), char const*, int, int, bool, int (*)(OvmsWriter*, OvmsCommand*, int, char const* const*, bool)) (/opt/Open-Vehicle-Monitoring-System-3_Unh/vehicle/OVMS.V3/main/ovms_command.cpp:542).

537      return m_parent; 538      } 539 540    OvmsCommand* OvmsCommand::FindCommand(const char* name) 541      { 542      return m_children.FindCommand(name); 543      } 544 545    void help(int verbosity, OvmsWriter* writer, OvmsCommand* cmd, int argc, const char* const* argv) 546      { 0x401ac67a is in OvmsVehicleVWeUp::OBDInit() (/opt/Open-Vehicle-Monitoring-System-3_Unh/vehicle/OVMS.V3/components/vehicle_vweup_all/src/vweup_obd.cpp:228).

223    //    cmd->RegisterCommand("reset", "Reset OVMS DTC statistics", shell_obd_resetdtc, 224    //        "Resets internal DTC buffer and presence counters.\n" 225    //        "No change is done on the car side."); 226 227        OvmsCommand* obd; 228        obd = cmd_xvu->RegisterCommand("obd", "OBD2 tools"); 229        cmd = obd->RegisterCommand("request", "Send OBD2 request, output response"); 230        cmd->RegisterCommand("device", "Send OBD2 request to a device", shell_obd_request, "<txid> <rxid> <request>", 3, 3); 231        cmd->RegisterCommand("broadcast", "Send OBD2 request as broadcast", shell_obd_request, "<request>", 1, 1); 232        cmd->RegisterCommand("01motelec", "Send OBD2 request to ECU01 motor electronics", shell_obd_request, "<request>", 1, 1); 0x401abd4e is in OvmsVehicleVWeUp::ConfigChanged(OvmsConfigParam*) (/opt/Open-Vehicle-Monitoring-System-3_Unh/vehicle/OVMS.V3/components/vehicle_vweup_all/src/vehicle_vweup_all.cpp:210).

205        if (vweup_enable_t26) 206            T26Init(); 207        vweup_con = vweup_enable_obd * 2 + vweup_enable_t26; 208    //    ESP_LOGD(TAG,"vweup_con: %i",vweup_con); 209        if (vweup_enable_obd || (vweup_modelyear<2020 && vweup_modelyear_new>2019) || (vweup_modelyear_new<2020 && vweup_modelyear>2019)) // switch between generations: reload OBD poll list 210            OBDInit(); 211        if (!vweup_enable_obd) 212            OBDDeInit(); 213        vweup_modelyear = vweup_modelyear_new; 214        if (!vweup_con) 0x401abf5f is in OvmsVehicleVWeUp::OvmsVehicleVWeUp() (/opt/Open-Vehicle-Monitoring-System-3_Unh/vehicle/OVMS.V3/components/vehicle_vweup_all/src/vehicle_vweup_all.cpp:124).

119    { 120        ESP_LOGI(TAG, "Start VW e-Up vehicle module"); 121 122    // init configs: 123        MyConfig.RegisterParam("xvu", "VW e-Up", true, true); 124        ConfigChanged(NULL); 125 126    //    if (vweup_con % 2){ // T26A connected 127    //    } 128    //    if (vweup_con > 1){ // OBD connected 0x401abf9a is in CreateVehicle<OvmsVehicleVWeUp>() (/opt/Open-Vehicle-Monitoring-System-3_Unh/vehicle/OVMS.V3/components/vehicle/vehicle.h:456).

451        virtual bool FormatBmsAlerts(int verbosity, OvmsWriter* writer, bool show_warnings); 452      }; 453 454    template<typename Type> OvmsVehicle* CreateVehicle() 455      { 456      return new Type; 457      } 458 459    class OvmsVehicleFactory 460      { 0x401656ff is in OvmsVehicleFactory::NewVehicle(char const*) (/opt/Open-Vehicle-Monitoring-System-3_Unh/vehicle/OVMS.V3/components/vehicle/vehicle.cpp:873).

868    OvmsVehicle* OvmsVehicleFactory::NewVehicle(const char* VehicleType) 869      { 870      OvmsVehicleFactory::map_vehicle_t::iterator iter = m_vmap.find(VehicleType); 871      if (iter != m_vmap.end()) 872        { 873        return iter->second.construct(); 874        } 875      return NULL; 876      } 877 0x40165737 is in OvmsVehicleFactory::SetVehicle(char const*) (/opt/Open-Vehicle-Monitoring-System-3_Unh/vehicle/OVMS.V3/components/vehicle/vehicle.cpp:900).

895        m_currentvehicle->m_ready = false; 896        delete m_currentvehicle; 897        m_currentvehicle = NULL; 898        m_currentvehicletype.clear(); 899        } 900      m_currentvehicle = NewVehicle(type); 901      if (m_currentvehicle) 902      { 903          m_currentvehicle->m_ready = true; 904      } 0x40165825 is in OvmsVehicleFactory::AutoInit() (/opt/Open-Vehicle-Monitoring-System-3_Unh/vehicle/OVMS.V3/components/vehicle/vehicle.cpp:914).

909 910    void OvmsVehicleFactory::AutoInit() 911      { 912      std::string type = MyConfig.GetParamValue("auto", "vehicle.type"); 913      if (!type.empty()) 914        SetVehicle(type.c_str()); 915      } 916 917    OvmsVehicle* OvmsVehicleFactory::ActiveVehicle() 918      { 0x400f80f3 is in Housekeeping::Init(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, void*) (/opt/Open-Vehicle-Monitoring-System-3_Unh/vehicle/OVMS.V3/main/ovms_housekeeping.cpp:208).

203        ESP_LOGI(TAG, "Auto init modem (free: %zu bytes)", heap_caps_get_free_size(MALLOC_CAP_8BIT|MALLOC_CAP_INTERNAL)); 204        MyPeripherals->m_simcom->AutoInit(); 205    #endif // #ifdef CONFIG_OVMS_COMP_MODEM_SIMCOM 206 207        ESP_LOGI(TAG, "Auto init vehicle (free: %zu bytes)", heap_caps_get_free_size(MALLOC_CAP_8BIT|MALLOC_CAP_INTERNAL)); 208        MyVehicleFactory.AutoInit(); 209 210    #ifdef CONFIG_OVMS_COMP_OBD2ECU 211        ESP_LOGI(TAG, "Auto init obd2ecu (free: %zu bytes)", heap_caps_get_free_size(MALLOC_CAP_8BIT|MALLOC_CAP_INTERNAL)); 212        obd2ecuInit.AutoInit(); 0x400f7d06 is in std::_Function_handler<void (std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, void*), std::_Bind<std::_Mem_fn<void (Housekeeping::*)(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, void*)> (Housekeeping*, std::_Placeholder<1>, std::_Placeholder<2>)>

...

::_M_invoke(std::_Any_data const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&&, void*&&) (/opt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/functional:600).

595          template<typename... _Args, typename _Req 596                   = _Require<typename _Traits::__lvalue, 597 _CheckArgs<_Pack<_Args...>>>> 598        result_type 599        operator()(_Class* __object, _Args&&... __args) const 600        { return (__object->*_M_pmf)(std::forward<_Args>(__args)...); } 601 602          // Handle smart pointers, references and pointers to derived 603          template<typename _Tp, typename... _Args, typename _Req 604                   = _Require<_NotSame<_Class, _Tp>, _NotSame<_Class*, _Tp>, 0x400f457e is in std::function<void (std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, void*)>::operator()(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, void*) const (/opt/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/functional:2271).

2266        function<_Res(_ArgTypes...)>:: 2267        operator()(_ArgTypes... __args) const 2268        { 2269          if (_M_empty()) 2270        __throw_bad_function_call(); 2271          return _M_invoker(_M_functor, std::forward<_ArgTypes>(__args)...); 2272        } 2273 2274    #if __cpp_rtti 2275      template<typename _Res, typename... _ArgTypes> 0x400f4711 is in OvmsEvents::HandleQueueSignalEvent(event_queue_t*) (/opt/Open-Vehicle-Monitoring-System-3_Unh/vehicle/OVMS.V3/main/ovms_events.cpp:229).

224          { 225          for (EventCallbackList::iterator itc=el->begin(); itc!=el->end(); ++itc) 226            { 227            m_current_started = monotonictime; 228            m_current_callback = *itc; 229 m_current_callback->m_callback(m_current_event, msg->body.signal.data); 230            m_current_callback = NULL; 231            } 232          } 233        } 0x400f47f4 is in OvmsEvents::EventTask() (/opt/Open-Vehicle-Monitoring-System-3_Unh/vehicle/OVMS.V3/main/ovms_events.cpp:187).

182            { 183            case EVENT_none: 184              break; 185            case EVENT_signal: 186              m_current_event = msg.body.signal.event; 187              HandleQueueSignalEvent(&msg); 188              esp_task_wdt_reset(); // Reset WATCHDOG timer for this task 189              m_current_event.clear(); 190              break; 191            default: 0x400f4859 is in EventLaunchTask(void*) (/opt/Open-Vehicle-Monitoring-System-3_Unh/vehicle/OVMS.V3/main/ovms_events.cpp:57).

52 53    void EventLaunchTask(void *pvParameters) 54      { 55      OvmsEvents* me = (OvmsEvents*)pvParameters; 56 57      me->EventTask(); 58      } 59 60    void event_trace(int verbosity, OvmsWriter* writer, OvmsCommand* cmd, int argc, const char* const* argv) 61      {

_______________________________________________ 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

_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev

Michael,

the RSSI is read for the connection in use, -127.0 is the value for the unconnected state. The value needs to be smoothed as it's quite jumpy, so may need 2-3 seconds after connect to get to the actual value.

IP association normally takes long enough from connect to get the RSSI into a usable state, and thus the WifiStaCheckSQ() call in WifiStaGotIP() is meant to switch to the network as soon as possible.

It's not clear to me what scenario you are describing. When you say "switch to the network" are you talking about switching to a different Wifi network than the one from which an IP address was obtained? (If so, that does not make sense to me because we just chose the current one as the best in our scan.) Or are you talking about switching to the modem network because the Wifi we're trying to connect to does not have good enough signal quality so we should give up on it?

For the case of fast DHCP association, you could try speeding the RSSI adoption up by checking for m_sta_rssi == -1270 and skipping or weakening the smoothing in that case, so the first RSSI read after a connect will be used immediately / stronger.

I tried checking in WifiStaCheckSQ() for -127 and skip emitting the network.wifi.sta.bad event, but more often the value was -95 to -98 so that check was not sufficient. Hence the idea to just remove the call to WifiStaCheckSQ().

But I remember that first value being far too optimistic in my test cases, which were having a single AP barely reachable from the car. I suggest testing that case specifically, as it seems your current test setup is close to a best case scenario.

So this is the scenario where you are connected to the modem network and then Wifi hears one of its configured networks and so tries to take over from the modem? It seems like the decision to ignore the Wifi should be made earlier based on the scan before trying to associate and do DHCP. Is the problem that the RSSI from the scan is too optimistic? If so, should multiple scans be done for the smoothing before trying to associate? Or is the scan always unreliable and you have to connect for a while to get an accurate measure? If you're talking about have a good Wifi connection established but then hearing a new network and switching to it when it doesn't have good signal quality, shouldn't that be known from the scan? (Again, unless the scan is just not reliable.)

OTOH, removing the WifiStaCheckSQ() call in WifiStaGotIP() would introduce at most 1 second delay for the netmanager to switch to the Wifi network, as the next ticker.1 run would trigger the switch. So that's not critical I think.

That's what I was thinking, so simply removing the call would avoid the unreliability of the signal quality measure at the time the IP address is obtained.

Another option: WifiStaCheckSQ(NULL) triggers the events unconditionally of the previous state, just by the current signal quality. That was meant to process a changed threshold configuration, but I don't remember why I did that in WifiStaGotIP(). Maybe that's why the "bad" event got triggered twice? You could try passing ms_m_net_wifi_sq there instead of NULL.

I can try this, but I'm not clear on the logic yet. Why is the argument a metric pointer when it is only used as a flag? -- Steve

Michael, Oh ^2. The argument to WifiStaCheckSQ() is a metric pointer for MyMetrics.RegisterListener(). Another solution would be to just put the desired part of WifiStaCheckSQ() into WifiStaGotIP(): if (StdMetrics.ms_m_net_wifi_sq->AsFloat() >= m_cfg_wifi_sq_good) { m_wifi_good = true; MyEvents.SignalEvent("network.wifi.sta.good", NULL); } -- Steve On Thu, 17 Dec 2020, Stephen Casner wrote:

Michael,

Oh, now I think I understand what you were saying, sorry. I was focused on the 'else' clause of WifiStaCheckSQ() that triggers a disconnect and trying to figure out why you would want a disconnect to occur in WifiStaGotIP(). Instead, I think you were talking about the 'if' clause and saying that if the signal quality was good enough in WifiStaGotIP() then you would want to connect right away. For the weak case of the AP barely reachable from the car, you don't want network.wifi.sta.good to be signaled and WifiConnect() called.

Rather than not calling WifiStaCheckSQ() in WifiStaGotIP() at all, what we want is that only the 'if' clause would be executed and not the 'else' clause. That's what calling with a non-NULL argument accomplishes, as you suggested.

I still ask the question, why is the argument a metric pointer when it is only used as a flag?

I repeated my walking-around experiment with this code change. It mostly worked, but in one instance disassociation occurred first at the wifi driver level before the periodic check of the signal level. Thus WifiStaCheckSQ() was not called and m_wifi_good did not get set to false. Then when WifiStaCheckSQ() was called from WifiStaGotIP() after associating with the closer AP and the signal quality was again not reading as good enough yet, it caused a network.wifi.sta.bad event and an undesired reconnect due to my script.

So we also need m_wifi_good = false in some place like WifiStaStop().

-- Steve

On Thu, 17 Dec 2020, Stephen Casner wrote:

...

Michael,

...

the RSSI is read for the connection in use, -127.0 is the value for the unconnected state. The value needs to be smoothed as it's quite jumpy, so may need 2-3 seconds after connect to get to the actual value.

IP association normally takes long enough from connect to get the RSSI into a usable state, and thus the WifiStaCheckSQ() call in WifiStaGotIP() is meant to switch to the network as soon as possible.

It's not clear to me what scenario you are describing. When you say "switch to the network" are you talking about switching to a different Wifi network than the one from which an IP address was obtained? (If so, that does not make sense to me because we just chose the current one as the best in our scan.) Or are you talking about switching to the modem network because the Wifi we're trying to connect to does not have good enough signal quality so we should give up on it?

...

For the case of fast DHCP association, you could try speeding the RSSI adoption up by checking for m_sta_rssi == -1270 and skipping or weakening the smoothing in that case, so the first RSSI read after a connect will be used immediately / stronger.

I tried checking in WifiStaCheckSQ() for -127 and skip emitting the network.wifi.sta.bad event, but more often the value was -95 to -98 so that check was not sufficient. Hence the idea to just remove the call to WifiStaCheckSQ().

...

But I remember that first value being far too optimistic in my test cases, which were having a single AP barely reachable from the car. I suggest testing that case specifically, as it seems your current test setup is close to a best case scenario.

So this is the scenario where you are connected to the modem network and then Wifi hears one of its configured networks and so tries to take over from the modem? It seems like the decision to ignore the Wifi should be made earlier based on the scan before trying to associate and do DHCP. Is the problem that the RSSI from the scan is too optimistic? If so, should multiple scans be done for the smoothing before trying to associate? Or is the scan always unreliable and you have to connect for a while to get an accurate measure?

If you're talking about have a good Wifi connection established but then hearing a new network and switching to it when it doesn't have good signal quality, shouldn't that be known from the scan? (Again, unless the scan is just not reliable.)

...

OTOH, removing the WifiStaCheckSQ() call in WifiStaGotIP() would introduce at most 1 second delay for the netmanager to switch to the Wifi network, as the next ticker.1 run would trigger the switch. So that's not critical I think.

That's what I was thinking, so simply removing the call would avoid the unreliability of the signal quality measure at the time the IP address is obtained.

...

Another option: WifiStaCheckSQ(NULL) triggers the events unconditionally of the previous state, just by the current signal quality. That was meant to process a changed threshold configuration, but I don't remember why I did that in WifiStaGotIP(). Maybe that's why the "bad" event got triggered twice? You could try passing ms_m_net_wifi_sq there instead of NULL.

I can try this, but I'm not clear on the logic yet. Why is the argument a metric pointer when it is only used as a flag?

-- Steve

On Sat, 19 Dec 2020, Michael Balzer wrote:

If we need to force good/bad state, I suggest adding a method for this right after WifiStaCheckSQ().

Rather than just adding m_wifi_good = false in some place like WifiStaStop()? Another method doesn't seem warranted. That is a member variable, not something local to WifiStaCheckSQ(). -- Steve

We don't need to emit the network.wifi.sta.bad event to cause WifiDisconnect() to be called because that is already happening. Is there some other reason for emitting that event? -- Steve On Sat, 19 Dec 2020, Michael Balzer wrote:

It's also the event emission, keeping the handling close together is for code readability. The compiler will probably inline that call anyway.

Regards, Michael

Am 19.12.20 um 18:32 schrieb Stephen Casner:

...

On Sat, 19 Dec 2020, Michael Balzer wrote:

...

If we need to force good/bad state, I suggest adding a method for this right after WifiStaCheckSQ(). Rather than just adding m_wifi_good = false in some place like WifiStaStop()? Another method doesn't seem warranted. That is a member variable, not something local to WifiStaCheckSQ().

-- 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

OK, a proposed change is attached. -- Steve On Sat, 19 Dec 2020, Michael Balzer wrote:

The reason to emit that event is to inform all potential listeners of the new state, so they can keep their internal state synchronized.

Regards, Michael

Am 19.12.20 um 19:09 schrieb Stephen Casner:

...

We don't need to emit the network.wifi.sta.bad event to cause WifiDisconnect() to be called because that is already happening. Is there some other reason for emitting that event?

-- Steve

On Sat, 19 Dec 2020, Michael Balzer wrote:

...

It's also the event emission, keeping the handling close together is for code readability. The compiler will probably inline that call anyway.

Regards, Michael

Am 19.12.20 um 18:32 schrieb Stephen Casner:

...

On Sat, 19 Dec 2020, Michael Balzer wrote:

...

If we need to force good/bad state, I suggest adding a method for this right after WifiStaCheckSQ(). Rather than just adding m_wifi_good = false in some place like WifiStaStop()? Another method doesn't seem warranted. That is a member variable, not something local to WifiStaCheckSQ().

-- 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

-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

Hi all, I just noticed that when I switch my OVMS to the Twizy module and then switch back to another vehicle, some web modules (e.g. Drivemode, Sevcon Monitor) persist. I believe I should initialize / reset all web modules when my vehicle module is loaded to correct that. But how? Thanks, sharkcow

Fixed by https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/fb77... Regards, Michael Am 20.12.20 um 23:27 schrieb Michael Balzer:

That's probably more a cleanup issue on the Twizy code. I'll have a look at that.

Regards, Michael

Am 20.12.20 um 20:59 schrieb sharkcow:

...

Hi all,

I just noticed that when I switch my OVMS to the Twizy module and then switch back to another vehicle, some web modules (e.g. Drivemode, Sevcon Monitor) persist. I believe I should initialize / reset all web modules when my vehicle module is loaded to correct that. But how?

Thanks,

sharkcow _______________________________________________ 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

Steve, go ahead with the commit, I'll add the configuration for the reconnect strategy. Regards, Michael Am 21.12.20 um 03:29 schrieb Stephen Casner:

Michael,

That was going to be my next question for you: Is it possible to connect to a different AP without tearing down all the connections like esp_wifi_disconnect() does. I studied the Wifi driver documentation for a while trying to find an answer to that question, but it didn't really talk about that scenario.

It sounds like my proposed change worked OK for you, so shall I go ahead and commit it? Or would you do something differently to include your idea about an option to automatically reconnect on "bad" events?

-- Steve

On Sun, 20 Dec 2020, Michael Balzer wrote:

...

Steve,

I just bewildered my neighbours by walking through the house, holding a black box into the corners while staring onto my laptop screen... ;)

Works nicely. With "wifi reconnect" on the event, it scans immediately for the next wifi net, without the script it doesn't scan until it actually loses the connection, so works as before. I've seen no duplicate "good" or "bad" events as well.

We could add an option for that reconnect strategy to the network configuration already, so users don't need to create an event script to get this behaviour.

I think the second part, keeping TCP connections alive on AP changes, will require some more changes - if it's possible at all with the current Wifi & LwIP stack.

Regards, Michael

Am 19.12.20 um 21:51 schrieb Stephen Casner:

...

OK, a proposed change is attached.

-- Steve

On Sat, 19 Dec 2020, Michael Balzer wrote:

...

The reason to emit that event is to inform all potential listeners of the new state, so they can keep their internal state synchronized.

Regards, Michael

Am 19.12.20 um 19:09 schrieb Stephen Casner:

...

We don't need to emit the network.wifi.sta.bad event to cause WifiDisconnect() to be called because that is already happening. Is there some other reason for emitting that event?

-- Steve

On Sat, 19 Dec 2020, Michael Balzer wrote:

...

It's also the event emission, keeping the handling close together is for code readability. The compiler will probably inline that call anyway.

Regards, Michael

Am 19.12.20 um 18:32 schrieb Stephen Casner: > On Sat, 19 Dec 2020, Michael Balzer wrote: > >> If we need to force good/bad state, I suggest adding a method for >> this >> right >> after WifiStaCheckSQ(). > Rather than just adding m_wifi_good = false in some place like > WifiStaStop()? Another method doesn't seem warranted. That is a > member variable, not something local to WifiStaCheckSQ(). > > -- 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 -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

---

OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev

-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

Michael, The reconnect based on config network wifi.bad.reconnect worked correctly for me. I observed that in one instance where the association was dropped before the bad signal level was detected the reconnect code was not invoked but a scan and selection of the better AP is done anyway. -- Steve On Tue, 22 Dec 2020, Michael Balzer wrote:

Steve,

I've added the configuration, please test.

Regards, Michael