You are reading a single comment by @Ganblejs and its replies.
Click here to read the full conversation.
-
there are scenarios where turning BLE off would also not be good UX such as navigation, where the notification is important to be delivered fast... Also something to think about :)
Yes - I also think some consideration about such situations would be required.
- when user interaction is detected, keep the next connected window open for longer generally.
- on e.g. navigation/music playback/etc keep connection untill the task is done + some extra time at the end.
- when user interaction is detected, keep the next connected window open for longer generally.
Ganblejs
Interesting thought, maybe we could find out a ballpark number by just turning off BLE generally for a while throughout the day and compare that with power usage when BLE is activated. Your BLE "strobing" approach could then be at the midpoint of these two measurements, given that establishing a connection is not particularly expensive.
For example at night it might make sense to turn off BLE for longer periods of time to save on battery. The big question is if ble will use enough battery to be even noticeable when there is nothing being sent or received?
Gadget bridge has a function to redeliver messages after reconnecting, so on the software side this should work out; there are scenarios where turning BLE off would also not be good UX such as navigation, where the notification is important to be delivered fast... Also something to think about :)
Generally I like the idea to optimize battery life further, but first we need data to see if any effort could be worth it