[Ovmsdev] WiFi client not switching to better AP

[Michael Balzer]

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 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
>
>
> _______________________________________________
> 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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20201222/cb65ae0d/attachment.htm>
-------------- 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/20201222/cb65ae0d/attachment.sig>