When using bluetoothctl, it seems necessary to run the command scan on before it will connect to a low energy (IoT) device. I know the MAC of the device, but attempting to connect to it directly always fails with a Device xx:xx:xx not available error message. Within 1-3 seconds of turning on scan on, it becomes possible to connect to the device. But as soon as scan off is run, the device immediately disconnects.
While running, I receive an onslaught of [CHG] Device xx:xx:xx and [NEW] Device xx:xx:xx messages. I work in an office building with apparently dozens to hundreds of devices occasionally within the max distance. Not all of the CHG messages are rssi, but even if they were the other guy's question failed to provide helpful answers. It was just a link to StackOverflow that pointed out they were rssi messages, without suggesting how to suppress them. I can't not scan on because the tool fails to work otherwise.
This tool is barely usable, and I have no idea why anyone thought this was good design. It must have been created when there were very few extant bt devices.
Additional information
I've figured out how to filter out some of the rssi messages. It's a simple enough command(s):
menu scan
rssi X
back
scan on
(Where X is an integer, usually negative, below which you will see no messages.)
The problem being that if I set this to a value high enough that I suppress all rssi messages, including the device I'm targeting, it's no longer possible to connect to the device. I can choose a number that suppresses most messages, but if the rssi messages for the device won't show up, then it's cock-blocked.
Did they design this tool just to make it unusable within a shell/expect script? This is just fucked.
I've had more luck suppressing the other messages. Once in the scan menu, you can do pattern <MAC> where the MAC is either the full MAC of the device, or a partal/prefix.
