Is it required to not provide scan responses? about eddystone HOT 2 OPEN

Our preference is for Eddystone devices to broadcast as non-connectable, but we understand that there are some use cases for connectable advertisements so the specification leaves it up to you.

As you say, broadcasting as always connectable draws more power from a beacon. But in a dense BLE environment it also causes congestion and reduces the reliability of a given device sighting a beacon. Those two reasons (and the slightly improved security aspects) is why we have a preference for non-connectable.

If I may ask, why would you like to set a name?

from eddystone.

I shouldn't have said "eddystone beacon" because that's not entirely true.
I was actually more interested in the hand off from the Physical Web to Web Bluetooth for a "real" BLE device you can interact with in that case.

There are basically two scenarii:

1. People use the Physical Web to discover the Web App URL for the device and all I need is a regular eddystone-beacon there with no name as I'll simply use something like "navigator.bluetooth.getDevice()" to discover the BLE device.

2. People directly go the Web App URL and use the BT discovery chooser. This is going to be tricky if we don't provide a meaningful bluetooth device name for filtering as the only way to discover the device would be by eddystone UUID, meaning all beacons surrounding me.

from eddystone.