<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">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.<div class=""><br class=""></div><div class="">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:</div><div class=""><br class=""></div><div class=""><ol class="MailOutline"><li class="">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.<br class=""><br class=""></li><li class="">Some logic in the network layer to determine wifi is unreliable (presumably based on sequential connections failures without success, over time).<br class=""><br class=""></li><li class="">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.<br class=""><br class=""></li><li class="">The switch is done in the network layer itself, and our current default route switching mechanism should support that just fine.</li></ol><div class=""><br class=""></div><div class="">I guess a config to enable/disable this as a feature.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Regards, Mark.<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 5 Jan 2019, at 2:56 PM, Stephen Casner <<a href="mailto:casner@acm.org" class="">casner@acm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Michael,<br class=""><br class="">You're right that we can't depend on the websocket job queue overflow<br class="">to detect loss of wifi connectivity. If the improvements in the wifi<br class="">driver make it sufficiently robust to detect disassociation, then we<br class="">may not need to do anything else to work around that problem.<br class=""><br class="">However, there may well be situations where wifi is able to associate<br class="">just fine, but there is no connectivity upstream from that point to<br class="">the server. To handle such cases I think it would be a good idea to<br class="">have a signal that both the websocket and server-v[23] can send to<br class="">netmanager to trigger switching to another path.<br class=""><br class=""> -- Steve<br class=""><br class="">On Fri, 4 Jan 2019, Michael Balzer wrote:<br class=""><br class=""><blockquote type="cite" class="">Steve,<br class=""><br class="">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<br class="">this as well.<br class=""><br class="">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<br class="">web client is connected.<br class=""><br class="">Another thing you could monitor is the signal quality, or maybe check for a lack of update callbacks? That's CSIRxCallback in esp32wifi.<br class=""><br class="">But that's all working around the underlying wifi blob bug. We first should check if the current IDF blob does a better job.<br class=""><br class="">Regards,<br class="">Michael<br class=""><br class=""><br class="">Am 04.01.19 um 06:15 schrieb Stephen Casner:<br class=""><blockquote type="cite" class="">Yesterday I found another instance where I could not ssh to OVMS nor<br class="">ping it. This time I verified in my router status that the wifi<br class="">association with OVMS was "inactive" (down). The iPhone app said that<br class="">server-v2 was not hear for 108 minutes. This time I have a full log<br class="">file covering back to the previous day, which is attached.<br class=""><br class="">I connected to OVMS with the serial console and the output from the<br class="">serial monitor is appended to the attached log file. The "wifi stat"<br class="">and "net stat" commands both indicated that the wifi connection was up<br class="">when all the external indications were to the contrary. Going back<br class="">108 minutes in the log file corresponds roughly to the first instance<br class="">of "job queue overflow detected". Perhaps the web server can act as<br class="">the canary in the coal mine? There is no indication that the wifi<br class="">driver signaled any problem at that time.<br class=""><br class="">Diagnosing this problem is difficult because the loss of connectivity<br class="">occurs after a day or a few days of operation. I have not tried the<br class="">current esp-idf yet; I may do that, but I'm not sure how long that<br class="">would need to operate without loss to determine success.<br class=""><br class=""> -- Steve<br class=""></blockquote></blockquote>_______________________________________________<br class="">OvmsDev mailing list<br class=""><a href="mailto:OvmsDev@lists.openvehicles.com" class="">OvmsDev@lists.openvehicles.com</a><br class="">http://lists.openvehicles.com/mailman/listinfo/ovmsdev<br class=""></div></div></blockquote></div><br class=""></div></div></body></html>