Tasker mis-handling of beacons
Tasker handling of beacons (iBeacon, Eddystone, etc. etc.) is not possible because operation of BT Near with beacons is not reliable. Active Profiles keep going inactive again several times a minute even though neither the phone nor the beacon have moved at all. Although this false reporting of "BT Beacon Gone" can be reduced somewhat by careful tuning of the monitoring parameters, it cannot be reduced to a tolerable level.
The problem acts as though for faster response _both_ Tasker and Android are trying to detect the "BT Beacon Gone" condition at the same time. This should not be happening. As with other BT devices, Tasker by ltself detects Gone in a way that's both easily tunable and fully reliable. Theoretically adding the Android detection of Gone into the mix too will improve responsiveness, but in practice it reduces reliability so much that Beacon tasks become simply impossible.
I suspect if you search in the Tasker sources for CALLBACK_TYPE_MATCH_LOST, you will find the problem. That ScanSettings should not be used, for many reasons: it operates differently on different versions of Android, trying to detect BT Beacon Gone in the face of the highly variable "advertising" frequency of beacons is inherently very difficult, trying to mix Android reasoning and Tasker reasoning about BT Beacon Gone is unavoidably illogical, the operation is notorious for not working reliably, operation is not affected by any Tasker tuning parameters, in fact operation is not user-tunable at all even through Android, and the operation is extremely hard to debug because there are no entries in the Tasker run-log.
