3

Real Beacon Support (not via inappropriate BT Near)

Beacons are so different from Classic Bluetooth devices they need their own tools. Although the name is the same (Bluetooth), both the operation and the usage are completely different. First the theory, then some specifics--

Theory
-In addition to being BLE devices, Beacons are a] off (not advertising) for several seconds at a time, b] have use cases that need to distinguish "nearness" as close as a few feet, c] have use cases that require responding in just a few seconds -even when off, and d] broadcast a _very_ faint signal to minimize power use (which means something as innocuous as a person walking in the next room can significantly affect the signal level from one advertising cycle to the next). No other Bluetooth device advertises anywhere near so infrequently for anywhere near such a short time (and at such a low signal level).
-A new context (say "Beacon Near") needs to have RSSI as a parameter (i.e. let the user set "specifically _how_ near?" separately for each context). Also, present/absent need to have different (higher/lower) RSSIs (and the difference should be _more_ than for Classic Bluetooth devices) to avoid flickering on and off; in other words the algorithm needs to incorporate a "de-bounce" that's smarter than just a timer or counter.
-And a new command (say "Beacon Info") needs to use _just_ a BLE scan, and return _just_ address, name (possibly blank), and RSSI. Most phones use a "dual mode" chip to time slice between the incompatible Classic and BLE (which is what startDiscovery(...) does). While time slicing Classic, the phone cannot hear Beacons, and so often "misses" an advertisement. Having a BLE-only scan (using startScan(...)) return only this very limited info uses so little power the scan could be left running all the time.
-The configured "off" monitor time is far far too long to be useful, and needs to be significantly changed somehow. Greatly reducing the monitor configuration parameters might solve the problem, but might increase power usage unacceptably in the process. Having Tasker always use what's currently the "Display On" parameters again might solve the problem, but again might increase power usage unacceptably. The new Beacon Monitor may be so different (with the scanner possibly on all the time) that it's best to have it simply ignore _all_ the monitor configuration parameters.
-Other tools may be needed too (for example get the complete advertising data from a Beacon).

Specifics (Android 12, Tasker 6.1.10-rc)
-When a BT Near context tracks a Beacon that's far away (typical RSSI -80dB) with Display On, it flickers on and off every minute or so.
-When a BT Near context tracks a Beacon that starts out far away with Display On and the Beacon/Phone moves closer, the context will activate far far too soon for many use cases.
-When a BT Near context tracks a Beacon that's nearby (typical RSSI -50dB) with Display On and neither the Beacon nor the Phone move at all, it works okay (but noticeably slowly).
-When a BT Near context tracks a Beacon that's nearby with Display Off and neither the Beacon nor the Phone move at all, the context deactivates then reactivates every few minutes.
-When a BT Near context tracks a Beacon that starts out nearby with Display On and the Beacon moves away, it can take a _very_ long time for the context to deactivate.
-When a BT Near context tracks a Beacon that's far away with Display Off, often the context will deactivate exactly when the Display is turned On. (Maybe "gone" detection resets and starts all over rather than continuing with the other monitor configuration parameters.)

Follow

1 reply

Votes Newest Oldest
C

A sample use case:

You work in a very large building that has its own "chapel". You sometimes use the chapel during a break. The rules say no smartphone is to EVER make a sound inside that chapel. 

So you plant a "beacon" inside that chapel, and build a Tasker profile/task that senses the beacon, turns off all sound, then turns all sound back on when you leave the chapel. To have the profile trigger when you're near the chapel, but _not_ trigger on the floor below, you have to control the RSSI sensitivity. The profile must detect the chapel as you walk up to it then go inside it -even when the phone is off. Given typical walking speed, this means the profile should detect the beacon within a few seconds (ten seconds max). The profile must remain activated the entire time you're in the chapel. Flickering off and back on is not okay because the phone might emit a sound during the period when the beacon is deactivated. Then when you're finished and walk out, your phone must detect that and return to its earlier state within a few seconds. Again the time should be at the same scale as walking speed; in fact, it would be nice if the detection of "gone" is just as fast as the detection of "near". 

Although the current BT Near "works" in the sense that it does detect the presence of the beacon (sooner or later at some distance the user can't control), it fails this use case in nearly every regard. False alarms, momentary disconnections, time lags much slower than walking speed, intermittent failures, and different operation when the phone is "off" than when it's "on" are all show-stoppers for this use case. 

Comment
Reply