-
-
Notifications
You must be signed in to change notification settings - Fork 15
FAQ
-
Yes! Both Android and iOS devices (iPhone, iPad) are supported. iWatch should also work, providing you can get them showing up in the Private BLE Device core integration.
-
Android: you have the option of using IRK (Private BLE Device) or iBeacon support via the HA Companion app.
-
Bermuda's iBeacon support is rather simplistic and opinionated, reflecting the author somewhat.
- To create a sensor for iBeacons, choose them in the
Configure
dialog where you can pick them from a drop-down, searchable list. - You'll probably want to rename the device and sensors to something sensible.
- Bermuda considers every UUID/Major/Minor version to uniquely identify a given iBeacon. That means the MAC address can change, or you can have multiple beacons transmitting the same uuid/major/minor and they'll all be one single device - but don't do that though, IMO it's silly.
- If your beacon sends multiple uuid's or changes it's major or minor version, they will show up as different "devices" that you can create sensors for. This might be good if you have one device that sends multiple IDs for some reason, or terrible if you have a device that tries to pack information into the major or minor fields. The latter device is, IMO, silly.
- If there are known beacons (in reasonable numbers) that do something I thought was silly, I will consider adding support for them. I'd rather they don't exist though, and I think the iBeacon integration suffers because of its trying to support those cases.
- To create a sensor for iBeacons, choose them in the
-
You can simply rename your entities if you like.
-
You can also tell your bluetooth proxies to send an inquiry in response to advertisements, this might cause names to show up. Consider also though that it means while your proxy is asking a device for its name it can't be listening for BLE traffic to proxy. In esphome, this is done by adding
active: true
to theesp32_ble_tracker
section (this is separate from the active property of thebluetooth_proxy
section, which controls outbound client connections).The default is
True
, and the templates at Ready-Made Projects also default toTrue
.To be explicit in setting the option, the YAML should contain a section like this (there migth be extra paramaters, that's OK):
esp32_ble_tracker: scan_parameters: active: True
-
Also, when you first restart homeassistant after loading the integration it may take a minute or so for the system to collect the names of the devices it sees.
- mmWave is definitely faster, but it will only tell you "someone" has entered a space, while Bermuda can tell you who (or what) is in a space.
- PIR is also likely faster than bluetooth, but again it only tells you that someone / something is present, but doesn't tell you who/what.
So how does that help?
-
If the home knows who is in a given room, it can set the thermostat to their personal preferences, or perhaps their lighting settings. This might be particularly useful for testing automations on yourself before unleashing them on to your housemates, so they don't get annoyed while you iron out the bugs :-)
-
If you have BLE tags on your pets you can have automations specifically for them, and/or you can exclude certain automations, for example don't trigger a light from an IR sensor if it knows it's just your cat, say.
- There are three main factors.
- How often your beacon transmits advertisements. Most are less than 2 seconds.
- Bermuda only checks for new advertisements every second. It will update sensors immediately if devices get "closer", but it is more leisurely for devices that appear to be "leaving" an area.
- The proxies might not catch every advertisement. In my esphome proxies I usually
use these settings to ensure we don't miss toooo many:
This makes sure the device is spending the majority of its time listening for bluetooth advertisements. 320/280 also works, but I think that 1000/900 gives a better balance of dedicated listening vs enough time for wifi tasks.^[citation required!]
esp32_ble_tracker: interval: 1000ms # default 320ms. Time spent per adv channel window: 900ms # default 30ms. Time spent listening during interval.
- So if your beacon transmits every second, it might take up to two seconds for Bermuda to come up with a new distance measurement, assuming no packets were lost. Which happens a lot.
- Due to the noise inherent in RSSI measurements, we do a lot of filtering on the values. The upshot of this is that measurements that read "closer" come through a lot faster because they're more reliable / more likely to be accurate, while readings of an increasing distance will be tracked a lot slower because most of them are signals that were weakened by noise, reflections, dog bodies etc. So asserting that something is in an area is authorative and quick, while asserting that something is leaving or not in an area carries less confidence and higher latency.
-
Currently, we use the relatively simple equation:
distance = 10 ** ((ref_power - rssi) / (10 * attenuation))
-
ref_power
is the rssi value you get when the device is 1 metre from the receiver. Currently you can configure this as a global setting in the options. -
rssi
is the "received signal strength indicator", being a measurement of RF power expressed in dBm. RSSI will usually range from -30 or so "down" to -100 or more. Numbers closer to zero are "stronger" or closer. -
attenuation
is a "constant" for the losses in the environment (humidity, air pressure(!), mammals etc). It's a bit of a "fudge factor". This is also set in the options. Typical values are between 1 and 3 but can vary. Finding this value is part of the calibration/setup process. -
distance
is the resulting distance in metres.
-
-
The default values won't be suitable for all use-cases. Apart from the environmental factors we can't calculate (like walls, reflective surfaces etc), each device might transmit a different power level, and every transmitter and receiver might have antennae that perform differently. Because of this it is planned to allow separate calibration of scanners and devices to account for the variances.
-
See How do I choose values for Attenuation and Ref_power for instructions on calibration.
See Settings for the explanation of each setting in detail.
- Soon you'll be able to set this per-device to account for variations in circuits, antennas and cases, but currently there are only the global defaults to fiddle with. Check out the Calibration guide for instructions.