[Ovmsdev] WiFi client not switching to better AP

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 203 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20201221/c14d9345/attachment.sig>