[Ovmsdev] WiFi client not switching to better AP

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