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

_______________________________________________
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