quickshell-mirror
bluetooth: add rssi property
Add rssi to bluetooth property bindings. It's useful to see signal strength of devices during discovery (IE, for sorting by signal strength, ignoring very low signal strength devices)
Because rssi is not available when the adapter is no longer discovering I also added a condition to lower the log level on the property update callback for optional properties, it's not really necessary and can be removed - but prevents some log spam when turning off discovery (because the rssi properties become unavailable)
@outfoxxed can you have a look at the updates made since your last request? Some of these PR's sit for days or weeks at a time with small enhancement requests. I would say many are okay if you co-author as well to help push them along quicker.
@outfoxxed can you have a look at the updates made since your last request? Some of these PR's sit for days or weeks at a time with small enhancement requests. I would say many are okay if you co-author as well to help push them along quicker.
This one is deceptively simple looking. I'm quite busy and have not had the time to test that shown signal strength reports a logical looking value for various devices. The strength calculation function also looks suspiciously like a curve fit better solved by a single equation. Figuring that out for review takes a considerable amount of time which I don't have right now.
Tbh it might be better to just report an enum with Excellent, good, fair, poor or something for the easy to consume value. And raw rssi for those who desire it.
It’s hard to quantify very accurately because different BT versions and protocols and device manufacturers have some variations on the reporting and work better or worse at lower signals/different distances. But I’m good with whatever approach you wanna go with, no strong opinion.
The main thing for me would be to sort, and show the excellent/good/fair/poor icon/text next to them.
I don't have an issue with exposing raw RSSI, and exposing signal strength as an enum/int for general quality is acceptable as well. I would lean towards an integer, e.g. 0-4 for that "quality" value because enums are generally more annoying to deal with in QML.