<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
Steve,<br>
<br>
I've added the configuration, please test.<br>
<br>
Regards,<br>
Michael<br>
<br>
<br>
<div class="moz-cite-prefix">Am 21.12.20 um 13:22 schrieb Michael
Balzer:<br>
</div>
<blockquote type="cite"
cite="mid:84028cdc-548b-2040-d810-71a986b3000a@expeedo.de">Steve,
<br>
<br>
go ahead with the commit, I'll add the configuration for the
reconnect strategy.
<br>
<br>
Regards,
<br>
Michael
<br>
<br>
<br>
Am 21.12.20 um 03:29 schrieb Stephen Casner:
<br>
<blockquote type="cite">Michael,
<br>
<br>
That was going to be my next question for you: Is it possible to
<br>
connect to a different AP without tearing down all the
connections
<br>
like esp_wifi_disconnect() does. I studied the Wifi driver
<br>
documentation for a while trying to find an answer to that
question,
<br>
but it didn't really talk about that scenario.
<br>
<br>
It sounds like my proposed change worked OK for you, so shall I
go
<br>
ahead and commit it? Or would you do something differently to
include
<br>
your idea about an option to automatically reconnect on "bad"
events?
<br>
<br>
--
Steve
<br>
<br>
On Sun, 20 Dec 2020, Michael Balzer wrote:
<br>
<br>
<blockquote type="cite">Steve,
<br>
<br>
I just bewildered my neighbours by walking through the house,
holding a black
<br>
box into the corners while staring onto my laptop screen... ;)
<br>
<br>
Works nicely. With "wifi reconnect" on the event, it scans
immediately for the
<br>
next wifi net, without the script it doesn't scan until it
actually loses the
<br>
connection, so works as before. I've seen no duplicate "good"
or "bad" events
<br>
as well.
<br>
<br>
We could add an option for that reconnect strategy to the
network
<br>
configuration already, so users don't need to create an event
script to get
<br>
this behaviour.
<br>
<br>
I think the second part, keeping TCP connections alive on AP
changes, will
<br>
require some more changes - if it's possible at all with the
current Wifi &
<br>
LwIP stack.
<br>
<br>
Regards,
<br>
Michael
<br>
<br>
<br>
Am 19.12.20 um 21:51 schrieb Stephen Casner:
<br>
<blockquote type="cite">OK, a proposed change is attached.
<br>
<br>
--
Steve
<br>
<br>
On Sat, 19 Dec 2020, Michael Balzer wrote:
<br>
<br>
<blockquote type="cite">The reason to emit that event is to
inform all potential listeners of the
<br>
new
<br>
state, so they can keep their internal state synchronized.
<br>
<br>
Regards,
<br>
Michael
<br>
<br>
<br>
Am 19.12.20 um 19:09 schrieb Stephen Casner:
<br>
<blockquote type="cite">We don't need to emit the
network.wifi.sta.bad event to cause
<br>
WifiDisconnect() to be called because that is already
happening. Is
<br>
there some other reason for emitting that event?
<br>
<br>
-- Steve
<br>
<br>
On Sat, 19 Dec 2020, Michael Balzer wrote:
<br>
<br>
<blockquote type="cite">It's also the event emission,
keeping the handling close together is
<br>
for
<br>
code
<br>
readability. The compiler will probably inline that
call anyway.
<br>
<br>
Regards,
<br>
Michael
<br>
<br>
<br>
Am 19.12.20 um 18:32 schrieb Stephen Casner:
<br>
<blockquote type="cite">On Sat, 19 Dec 2020, Michael
Balzer wrote:
<br>
<br>
<blockquote type="cite">If we need to force good/bad
state, I suggest adding a method for
<br>
this
<br>
right
<br>
after WifiStaCheckSQ().
<br>
</blockquote>
Rather than just adding m_wifi_good = false in some
place like
<br>
WifiStaStop()? Another method doesn't seem
warranted. That is a
<br>
member variable, not something local to
WifiStaCheckSQ().
<br>
<br>
-- Steve
<br>
_______________________________________________
<br>
OvmsDev mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.openvehicles.com">OvmsDev@lists.openvehicles.com</a>
<br>
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
<br>
</blockquote>
--
<br>
Michael Balzer * Helkenberger Weg 9 * D-58256
Ennepetal
<br>
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
<br>
</blockquote>
_______________________________________________
<br>
OvmsDev mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.openvehicles.com">OvmsDev@lists.openvehicles.com</a>
<br>
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
<br>
</blockquote>
--
<br>
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
<br>
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
<br>
<br>
_______________________________________________
<br>
OvmsDev mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.openvehicles.com">OvmsDev@lists.openvehicles.com</a>
<br>
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
<br>
</blockquote>
</blockquote>
--
<br>
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
<br>
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
<br>
</blockquote>
_______________________________________________
<br>
OvmsDev mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.openvehicles.com">OvmsDev@lists.openvehicles.com</a>
<br>
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
<br>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-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>
<pre class="moz-signature" cols="72">--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26</pre>
</body>
</html>