<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi Mark,<br>
<br>
I like the idea of a configurable fail-over to GSM in the event the
WiFi is not working, even if / when we get the root cause of the
outages fixed. But, yes, make it configurable. WiFi is generally
free, and GSM is generally not. It's not going to make the evening
financial news, but I wouldn't want a wonky WiFi connection to
trigger a financial surprise or lockout of the GSM account without
having the user actively decide this is what they want to do.<br>
<br>
I've generally had good luck with the WiFi getting and staying
connected as the car comes and goes. The AP is about 10m and one
wall thickness from the car, and the OVMS module is in the passenger
foot well, under the dash, but I generally get a pair of
notifications on a roughly daily basis that the top-off charge is
taking place. The car is only driven once or twice a week.<br>
<br>
Greg<br>
<br>
<br>
<div class="moz-cite-prefix">Mark Webb-Johnson wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CA9A7141-F2D9-4DF9-A887-4374F978FFE0@webb-johnson.net">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
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=""
moz-do-not-send="true">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="" moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a><br
class="">
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br
class="">
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.openvehicles.com">OvmsDev@lists.openvehicles.com</a>
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br>
</body>
</html>