Multiple Wifi connects without Wifi disconnects in between.

[Econdoc]

I am seeing the trigger “Wifi Connected: All SSIDs” fire 2 or 3 times within 90 seconds without any intervening Wifi disconnects. What is going on and how do I work around this?

[beelze]

I've got a probably related issue. In any way, this is a serious problem, maybe a bug. What is your Android version?

[Econdoc]

Android 8.1 (Oreo), LineageOS 15.1

Location (battery savings) is on.

[Martin]

Hi,

Likely the BSSID changes when the device switches between different access points or when the system updates the BSSID late for some reason.
The trigger historically executes the trigger also for BSSID changes and an option to avoid that is still missing in Automagic. You could add an action 'Sleep: 2m' and flow execution policy 'Skip...' in the options of the flow to ignore the second and third invocations of the flow.
Adding the missing option to ignore BSSID changes is on my todo list. Unfortunately I have to implement support for notification channels first but I put it on the top of my todo list so it should not take long.

Regards,
Martin

[Desmanto]

@Martin : Maybe it is possible to add something like "Trigger cooldown". Tasker has the cooldown feature to prevent the profile being triggered too many times. I know it can be done by just using sleep and FEP skip. But maybe it makes more sense to include it in the flow level as a configuration. So we can use it to any flow with any trigger, not only trigger Wifi connected/disconnected.

Cooldown timer :
(Default) Instant
(time in miliseconds or duration string)

Should be in feature request subforum, but I think it is more relevant to discuss here.

[Martin]

I would prefer to avoid something like a cooldown setting for now and I think that adding a checkbox to ignore BSSID changes makes sense anyway since it's often not desired to get connected events in a larger corporate wifi setting when the SSID stays the same.
Maybe a condition that checks how frequent a flow is executed would make sense. You could add the condition anywhere in a flow which would be more flexible and you could execute some parts of a flow every time and "protect" some other parts of a flow, e.g:

-trigger 'Location'
-action 'Log: location now at ...'
-condition 'Check rate: more than once in 10s'
--> true: -action 'Notification on Screen: too frequent'
--> false: -action 'Execute expensive network call'

Regards,
Martin

[Wibbly]

.. or maybe just add a new variable like 'triggertime' which exists for every (?) trigger. I.e. add 'triggerperiod' which is the difference between the current and the last trigger times? This can be tested in a flow easily as above.

The disadvantage of this over the sleep method just for 'cool down', is that the flow still runs on every trigger, albeit not far if the condition is near the beginning of the flow, right?