Bluetooth Link Supervision Timeout Issue

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

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

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

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

[vertigo]

As an update to this, I tried having it stream clips of silence and wasn't able to get any improvement on the situation. I've also noticed that in the car, it still takes approximately the same amount of time for the music player to stop when the car is shut off or the BT receiver is unplugged as it does for Android to recognize the disconnect has occurred. So it seems while that has an effect on it when connected to the JBL speaker, it doesn't affect it when connected to the receiver I use in the car (Kinivo BTH240). The only thing I can think of at this point is that maybe a different receiver would work better in the car, but without knowing if that would be the case or what any particular one's timeout would be, it's not feasible to buy a new one to try. And it doesn't make sense that the connected device would have any impact on that; it seems it would be completely dependent on the phone, since once the device is powered off, it's out of the equation. So it doesn't make sense that it responds so much more quickly with the JBL speaker, especially when streaming, than with the Kinivo. I also searched and searched and couldn't find anything giving any indication of how much more power, if any, is used by BT when streaming to a device vs just being connected to it.

[Desmanto]

I don't know if you are still looking for solution. But have you try with different phone? Preferably with other brand or android version. If it is feasible, try to use adb logcat to check the 16 seconds period from the first disconnected until the OS send the event to AM. Maybe you can spot some pattern or the problem. It will be a long log though, so prepared to read a bunch of text.

[vertigo]

Well, the confusion piles on. I was still hoping for a solution, and I tried my Galaxy Tab, which only took 5 seconds to recognize the disconnect. Then I retried my phone, and it also only took 5 seconds. I tried it multiple times, and have tried it over the course of a few days now, and it's continuously at 5 seconds, and my flow is working as expected now (still wish it could be even less, but I'll take it). No idea why it suddenly changed, haven't done any system updates or anything. Go figure. I just hope it doesn't randomly change back again.

I do, however, have a couple other issues. One is that it sometimes, and frequently lately, doesn't reconnect to the BT receiver. The receiver shows up in BT settings, and if I tap it the phone connects to it right away. It also connects if I toggle BT off then back on. But for whatever reason, it more often than not won't connect on its own. I hate BT... Anyway, I figured I'd just set up a flow to connect whenever the receiver is available, but there's no trigger for that. Is that not possible?

The other thing was I wanted to set up a flow to be triggered whenever a notification changes, so I could have it turn the screen on when the track changes on the music player when I'm driving so I can see what it is. But there also isn't a trigger for a notification change, only a notification being added or removed. Is it possible to add that?

[Desmanto]

I also have various experience with bluetooth. MY PC bluetooth use to connect fine to my headset/headphones. Suddenly the same as yours, won't auto connect anymore. Have to turn the PC's bluetooth off and on again to make it can connect again. But I also have forgot what have changes (since a lot have changed over time). lazy to troubleshoot it, just do it the usual way.

There is no "bluetooth available" condition in Automagic, there is only for BLE device only. And even it has, you have to do periodic scan, which will drain your battery.

Notification changes is the same as trigger Notification on Statusbar Displayed. Usually when notification change, it has the remove and add (-ed back) event, so you can catch that. Or specificly for music changes, you can use trigger Media Session Changed.

[vertigo]

Yeah, I've never cared for BT. It's great in concept, but it has NEVER worked right. Since it first came out, up to now, it has always been extremely unreliable. A friend of mine and I were talking about it several years ago and he felt the same exact way. Yet another problem I have with it is I've never been able to get Android's trusted device feature to work with my computer. Even if they both have BT on and are paired, it says they're not connected.

Anyways, I tried the Media Session Changed trigger, and it seems to do what I want, so thanks. @Martin - I had to search for this. IMO it should also be tagged under Audio.

As for there not being a BT available condition, what I was actually asking about was a trigger, so a flow would run whenever a specific device becomes available (this would also allow me to have it trigger when the device becomes unavailable, which would allow me to potentially further cut down on the delay between shutting off the car and getting the phone to alert me so I don't forget it). Though I suppose if it would have to scan for that instead of being notified of the change by the OS, then yes, it would be a drain and wouldn't generally be a good idea, though I still might use it when driving for a quicker alert when I stop. However, if there was such a condition, then I could set the trigger as orientation face left, so it would run the flow when I dock the phone in the car. So the question is, is it possible to make such a condition? Of course, it wouldn't help if I leave my phone in my pocket, but it would be better than nothing. Obviously, I'd rather just get it to work properly, but I've accepted that BT will never work properly.

The only thing I can think of is to set a trigger for when I'm in the car, then have it check if the BT device is connected and, if not, connect to it. This presents a couple challenges. First is how to determine if I'm in the car. The only ways I can think of are based on WiFi, so when the home WiFi is lost it assumes I'm in the car. The main problem here is that it won't happen until I'm out of range, which could be after being in the car for several seconds. A possible solution would be to add a trigger (and possibly a condition as well) for WiFi strength. I know this can be done because I have an alarm that only allows you to dismiss it if within a certain range of the router, based on the signal strength, but I don't know if having this set as a trigger would require constant polling, draining the battery. The other possible solution is to do a speed-based trigger, so it would check if I'm moving more than say 10mph, though I don't know if this would drain the battery or if there wouldn't be an appreciable difference due to the phone possibly already constantly keeping tabs on this. The second challenge is that without a BT device available condition, it would be trying to connect to an unavailable device, which may cause problems. I just find this all so irritating, since the BT device should be the easy solution to telling it when I'm in the car, but instead it's the other way around.

[Desmanto]

Bluetooth is working fine for my ticwatch though. My other headset also working fine with the phone. It is just the PC's usb bluetooth that doesn't work fine. PC's also can't connect to the Bluedio bluetooth speaker. Seems like a driver issue or conflicting software. I will troubleshoot it one day.

I don't know if it is possible, maybe we can request for "bluetooth available" condition. Then use your orientation face left as the trigger to enable the periodic timer flow to scan for the bluetooth. Disable the flow once the purpose is achieved already.


The better trigger for you usage case maybe "User Activity". This use google's API to detect your current activity. It use almost no battery at all, since google is already tracking everything (very creepy right?). Surprisingly, this is quite accurate and you can set the confidence level too. You can use begin, end or periodic check. Once you stop driving, it will enable the flow to periodic check for the bluetooth connected. Then execute your main flow once disconnected.