From Newsgroup: sci.electronics.design
On 7/26/2026 7:38 AM, Theo wrote:
Don Y <blockedofcourse@foo.invalid> wrote:
And, you keep ALL of these updated so they are usable when you
next might need them.
Or, you access the *up-to-date* web page for each of these
WHILE you need said access and your phone is unburdened by
them once you close the browser.
<https://webbluetoothcg.github.io/web-bluetooth/scanning.html>
why anyone in their right mind want a phone to by default have something that
notifies of every random BLE device you pass, and getting spammed with annoying
ads on top of that-a ?
You obviously would have controls -- just like your phone doesn't
notify you of every WiFi AP that you pass.
I don't know a whole lot about BLE but AFAIK it provides *communication* but doesn't define the *semantic meaning* in the way you want.
What a stream of bits "means" can be interpreted any way you want.
We tend to agree on what the bits that have been mapped to these characters mean. But, they could easily be interpreted to mean ANYTHING else.
I can set my SSID to "Dr Alonzo's Cardiology" and convey (deceptive) information to passersby looking at available BT connections.
In other words your garage door opener has two messages, 'open' and 'close'. BLE lets you send message A or message B, but it doesn't define the meaning that says 'you send message A to open the door' and 'message B means close'. Without that, you can't construct a UI with buttons for open and close.
That's up to whomever defines that interface. A and B might, instead,
be "turn on the light that is part of the opener mechanism" and
"prevent any other WIRED controls from being recognized by the opener".
The FIRST issue to address is how ubiquitous the underlying technology
is and how familiar it is to users:
"How ubiquitous is (or isn't!) this? Is there a general
(temporal) cutoff point where its support is "expected"
before which it is a rarity?"
The *hardware* and OS support has been around. But, it hides behind
specific applications tied to specific peripherals -- a small subset
of how it CAN be used.
Folks think of Bluetooth (Classic) and WiFi as "connectors". You "plug in" your earbuds and "plug your phone" into the internet. *YOU* control that action, for the most part. Unless you wander too far from your phone
(or the AP), you EXPECT the connection to persist (barring hardware
failures)
They don't think of it as something that they can have fleeting interactions with and still extract value. Waiting for a table at a restaurant and
"seeing" YOUR expected wait time updated dynamically (you will NEVER connect
to that instance again yet it has value NOW). Or, navigating a hospital
or other semi-public facility for the first (only?) time. Or,
standing in an endless line at Disney{Land,World} and receiving an updating notification "Wait time from this point is 45 minutes" -- which obviously changes the nearer you get to the destination.
It's only when people become accustomed to such interactions that they
start *looking* for them. Otherwise, the technology has no value to them.
Appliances now have the ability to alert their users of significant
events. But, do so using heavy protocols that often rely on (external)
third parties (why can't my washing machine contact me directly without
having to go through a manufacturer's server?)
Zigbee, to use another example, does provide enough meaning that you can
make those open and close buttons from a generic UI without needing to run code from the manufacturer. I don't think BLE does. You have make a device expect a HID profile (ie a keyboard) and maybe decide that 'Enter' means
open and 'Delete' means close or something, but again you need manufacturer code to make that work (or somebody else has reverse engineered that).
There are various BLE profiles like fitness and audio where these things
have been specified and they can be interpreted by generic code, but if you don't map to one of those profiles then generic support isn't possible.
If you can't *see* that BLE devices are present, then you don't consider looking to use them.
If I walk into a coffee shop, store, doctor's office, etc. there is no guarantee that they will DISPLAY an access point that I can use, there
(as a courtesy). If my phone couldn't show me the SSIDs that it was encountering while there, I likely wouldn't notice the one named
"Joe's Coffee Shop" so would not avail myself of that capability.
One wouldn't know the airport had beacons strewn about at known locations
to assist with pedestrian navigation unless you could *see* those. Seeing
them once might encourage you to investigate what sort of apps can
exploit them and how to acquire those.
As I said upthread, you definitely wouldn't want to be bothered with
installing an *app* to take advantage of these as their use frequency
would likely approach zero. But, (as also indicated) referencing
them in a web page that a facility can serve via a URl broadcast by
a beacon (cf Eddystone) makes a lot of sense -- IF you are savvy
enough to look for them.
From the informal survey I've done, most phones don't NATIVELY report
the existence of proximate BLE devices. One has to install a scanner
if you want to see what's available. And, tolerate the battery drain
if one wanted to *follow* the signals available as one wanders about.
And, Average Joe's likely would just find this information confusing.
They aren't sophisticated enough -- YET -- to see its value. If
they've opted to buy a fitness tracker or watch, then their knowledge
of BLE is hidden inside that product offering; they know nothing of
what *else* it can do for them.
https://en.wikipedia.org/wiki/List_of_Bluetooth_profiles
Yes, but you can always create a custom profile -- for Classic or LE.
Nothing forces you to use a technology in a particular manner.
--- Synchronet 3.22a-Linux NewsLink 1.2