Steve, I've added the configuration, please test. Regards, Michael Am 21.12.20 um 13:22 schrieb Michael Balzer:
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