Page 1 of 1

Bluetooth Link Supervision Timeout Issue

Posted: 07 Apr 2019 18:00
by vertigo
I tried making a flow to remind me to grab my phone from the car, since I sometimes put it in its holder then forget it when I get home or wherever I'm going, so I have to go back to the car to get it. The problem is, I set it up to turn the volume up and play a noise when it disconnects from the car bluetooth, but apparently there's a hard-coded timeout in Android of ~16 seconds (give or take depending on the phone from what I can tell), which means it's that long before Android and therefore AM even realizes it's disconnected. Often, this is enough time for me to be out of the car, making the flow useless. I really, really hate Google. Anyways, does anyone have any thoughts on how else I might achieve this. I can't do it when I come to a stop, because then it would go off every time I come to a light or stop sign. GPS and WiFi would only work for home, and even then it would be iffy. Maybe if AM could actively scan to see if the BT device is still connected, instead of waiting to be told by the OS that it's not, but even if that were possible, it would likely be a battery drain (though maybe I could use a trigger to only do it when the car stops for more than a few seconds). Any ideas?

Re: Bluetooth Link Supervision Timeout Issue

Posted: 08 Apr 2019 06:27
by Desmanto
During this 16 seconds timeout, does condition Bluetooth device connected, return true? If true, it seems you can't use bluetooth trigger properly, as the timeout will always leave 16 seconds latency. But if false, then you can use periodic timer to check if the bluetooth device is still connected. 5 seconds probably is good and not drain too much for the whole driving session. You can also use trigger User Activity, use the same 5 seconds period.

Most users here charge their phones when in car. Then when the car is off, trigger power disconnected will always triggered immediately. It is a better trigger for the typical usage case.

Re: Bluetooth Link Supervision Timeout Issue

Posted: 11 Apr 2019 23:51
by vertigo
Well, I tried testing this with the computer, figuring that would be easier, but apparently W10 completely sucks with Bluetooth (and so many other things...), so I ended up using a BT speaker. Interestingly, instead of 16 seconds, which was the timeout with the car BT (technically a Kinivo BT to aux in adapter) on multiple tests, it's about 4-6 seconds with the speaker (JBL). From what I've read, the timeout seems to be something that should be consistent, but that's definitely not what I'm seeing, and 4-6 seconds would probably work for the car. Anyways, to answer your question, yes, it returns true after powering off the speaker, until the phone realizes it's disconnected and activates the trigger based on that.

I also found that if I'm playing music and I turn the speaker off, both the music app stops immediately, meaning it recognizes that the connection has been terminated, and AM is triggered immediately as well. So it must be that when there's actual data being transferred, vs merely maintaining an open line, Android is notified immediately instead of only on the next poll. So maybe that could be used somehow. I have no idea if the music player, or Android itself, is constantly polling when transmitting music, and that's why it works that way, or if there's something else going on.

Also, the supervision timeout can't just be a periodic, every x second poll, because if that were the case it would sometimes happen x seconds after turning off the car/speaker/etc and sometimes only a second or two after, depending on if the connection was terminated right before or after a poll or halfway in-between or whatever. It's clear to me that Android is recognizing that the connection is lost, but waiting a period of time after that before giving up on it and declaring it disconnected, vs actually taking that long to realize it's been disconnected. So if that's the case, maybe there's a way for AM to realize when Android does when it first occurs, and not wait to be notified by Android. IOW, instead of Android recognizing a disconnect, waiting x seconds, then notifying apps of the disconnect or announcing it in some way that they see it and are clued in, at which point AM is triggered, maybe AM could see the initial disconnect when Android does and activate triggers without having to wait for Android to announce it. I suspect, though, that that won't be possible, since it probably happens on the kernel level or something, and apps can't see it. But if not that, then maybe AM could simply poll the device like music players do, assuming that's what they do that allows them to immediately stop playback.

Re: Bluetooth Link Supervision Timeout Issue

Posted: 12 Apr 2019 06:25
by Desmanto
So this is the bluetooth device specific problem. My bluetooth headset S015 (unknown brand), give the disconnected event immediately, even before the bluetooth light goes off; at my Xiaomi Redmi Note 5, custom ROM RR 7.0.1 Pie 9.0.

X second poll is not efficient, because the latency can be up to 5 seconds. When the poll happen at 0 second, then bluetooth disconnected at 1st second, it will wait until the next 4 seconds to realize it has been disconnected. But for intermitten event like this, this is the only way to check it. You can reduce the 5 seconds interval, example to 2 seconds, so it reacts much faster. But at the cost of too frequent checking, once in every 2 seconds. And, because the condition bluetooth connected gives true, so you can't use this periodic checking too.

If the OS doesn't pass the event to Automagic, there is practically nothing Automagic can do about it. But we can have workaround. Based on your testing, your car bluetooth and JBL speaker instruct the phone to maintain the connection much longer when there is no active connection, giving a false connected state. Since music streaming will make the trigger reacts immediately (real connected state), you can use this as the helper. I thought about 2 ways to use it, try them to see which one is more efficient.

1. Same periodic check 5 seconds.
- Use the same periodic 5 seconds.
- Check the bluetooth connection directly. If no, then do all the task you want.
- If yes, continue to check if the music is playing (condition music active). Yes, do nothing.
- No, use action sound to play some sound to media volume.
- Continue to recheck again if the bluetooth is connected. No, do all the task you want. Yes, do nothing.

Playing sound will trigger the media stream check, hence when you check it again, it will know that the bluetooth has been disconnected.

Downside is this have latency up to 5 seconds. Decreasing the interval (example to 2 seconds) will giver lower latency at the cost of more flow execution per minute. This is also much more complex.

2. Playing silent/low volume sound all the time
- At another flow, create trigger bluetooth connected.
- Play sound, some silent or low volume sound file, maybe a 1 minute file.
- Loop this sound indefinetely, using sleep 10ms, then loop back to the sound.

Use your bluetooth disconnected trigger flow as usual. Create additional action to stop the flow above and add stop action sound. The silent playing sound will ensure the bluetooth connection is active streaming all the time, not just in maintaining (false) connected state. Hence the bluetooth disconnected event will react immediately. But I don't know if this will increase the battery drain to a significant level.

Try both and see which one works the best, with least latency and battery drain.