Wifi trigger, inconsistent status?

[beelze]

My goal was to create flow which execute different actions based on connecting/disconnecting my home network.

Flow begins from combined trigger (AM startup, WiFi Connected, WiFi Disconnected). The second is a condition (WiFi Connected) used for subsequent storing actual connection status to variable. But when I come home, it is working unexpectedly (irrelevant data is omitted):

Code: Select all

10:41:01.368 Starting to execute flow with Context{local{trigger=WiFi Connected: net24,net5,ssid=net24,bssid=xxxx}}

Well, we see that device was connected to net24. But here's next log records:

Code: Select all

10:41:01.368 Start executing condition 'WiFi Connected: net24,net5'
10:41:02.379 End executing condition 'WiFi Connected: net24,net5' with return value false

After condition was running almost for a second(!) it shows that network is not connected. Why? Highly unexpected. Maybe because the network was quickly disconnected? Unlikely, because FEP was set to «stop current, start newer», and there are no log entries for the «newer» flow. So there was no disconnected event, right?
In other words, immediately after a «connected» event the connection status is «disconnected». Very strange.

[Desmanto]

What android version that got this problem? I forgot since when, probably nougat above; location and wifi is closely related. You can't check each other condition without turning on both. So to check for wifi connected, you have to turn on location feature, at least at battery saving mode. To check for location, you also have to get the wifi on, even though not connected.

At my phone RR 6.2 Final Oreo 8.1, there is a ROM issue where the location feature got turned off intermittently. I can't find the real cause yet. Some of my wifi checking flows and location based flows will fail when this happen. I have to create another flow to turn it on again if it is disabled. So I used Automagic to workaround the ROM bug.

[beelze]

What android version that got this problem?

AICP Oreo 13.1 Android 8.1.0.

Location (batt saving) is always on, so it isn't a issue. Seems I should seek indirect way to check connectivity, SSH/DNS or whatever.

[Desmanto]

It seems the wifi is flapping. In certain ROM, the OS will check for internet connection immediately after the first event of connection. And if no internet with that split of seconds, it will try to disconnect and reconnect again. I still don't fully understand this behaviour, but mostly happen when the wifi is on but no internet behind it. But I only experience it maybe twice or thrice in a month, can't say for sure. Haven't troubleshoot it yet, will check if it happens again.

[digitalstone]

I recognize this.
In this topic i described a similar behavior: viewtopic.php?f=5&t=7699
Apparently no matter what wifi-related settings you might make. Android (or the device) decides to, after "some time", to not check upon the AP anymore for as long as the screen is off. Period.

Confirmation
As of the last few days i can firmly confirm that this is the case, since when the wifi flicks on when i come home by AM, after either 30 seconds uptil a full minute it does not ping my router.
But, as soon as i turn on the screen (even just the lockscreen) for only a second or so... it will do its thing.

Solution (ASAIK)
Let AM turn the screen on after x-amount of fails, then turn on the screen for 1 or 2 seconds.
Ideally, make use of a screen sized-widget that doesn't register unintended touches.

[beelze]

In any way, we need reliable way to listen WiFi events and check it's status. Any needed/related workarounds should be implemented in AM.

[digitalstone]

Not quite. This is seems to be a problem at a lower level than AM. Therefor, i'd say it's up to the AM user to come up with creative ideas.
All the building blocks are there, you just have to put them in the right order. Mine works just fine now.

[Desmanto]

This can be considered false trigger, just like bouncing switch.
viewtopic.php?f=5&t=7229

If the flow that has wifi connect/disconnet are in different flow, add sleep 1 second and add condition wifi connected. For wifi connected, use the true branch to the main flow. While wifi disconnect, use the false branch.

If in same flow, simply using the FEP skip with sleep 1 second is enough to protect from false trigger.

[beelze]

Not quite. This is seems to be a problem at a lower level than AM. Therefor, i'd say it's up to the AM user to come up with creative ideas.
All the building blocks are there, you just have to put them in the right order. Mine works just fine now.

Not sure. False triggers? Maybe, but checking for actual Wi-Fi connection needs to be reliable. In my case, checking connection status immediately after one and only WiFi connected event (no other events fired) returns false, forcing me to use very indirect way to check it. As for now, I'm using checking connectivity to SSH port on home router and subsequent issuing SSH command. As for now, it's working fine, but seems to be some overkill.

[vertigo]

I'm having a similar issue as described here and in another thread, which the OP posted in as well.

I made a flow to enable/disable another flow based on whether or not I'm home, using Wi-Fi connected/disconnected as a trigger, since having that other flow enabled when I'm out causes it to trigger like crazy (trigger is sensor > face down and not face down, so it fires constantly when driving with the phone in my pocket). But I keep finding that flow disabled when at home, and when I just checked the log for the one responsible, I see the Wi-Fi occasionally disconnecting very briefly then reconnecting (not sure if it's the phone renewing the lease or Android briefly putting the radio to sleep or what). The problem is, the last Wi-Fi trigger is a connect, but then on a check to see if it's connected (done because I use both triggers in the same flow then use a condition to determine the current state to see whether to enable or disable the other flow), it wasn't, and so the other flow was disabled. The thing is, it seems to be a problem with Automagic not seeing all connect/disconnect events, because otherwise it should have shown a disconnect trigger between the connect trigger and the failed condition (where it shows as not being connected). And I have FEP set to stop the flow and execute a new instance, so it should have not only detected the disconnect, but restarted based on that, and then again when detecting the reconnect after that, which it also apparently missed.

In other words, here's what happened:

Wi-Fi disconnected
Flow triggered and disabled other flow
Wi-Fi connected
Flow triggered
Wi-Fi disconnected while flow running
Flow did check, found Wi-Fi not connected, disabled other flow
Wi-Fi reconnected
Automagic did nothing

And here's what should have happened:

Wi-Fi disconnected
Flow triggered and disabled other flow
Wi-Fi connected
Flow triggered
Wi-Fi disconnected while flow running
Flow triggered, canceling running instance and starting a new one
Wi-Fi reconnected, either while flow running or after
Flow triggered, canceling running instance (if occured while running) and enabling other flow

The next step is to try using the trigger itself as the condition for whether to enable or disable the other flow, instead of relying on a conditional check, but even that may not work if Automagic is missing triggers.