Settings

The main settings for Bermuda are configured in Home Assistant, "Settings", "Devices & Services", "Bermuda", "Configure":

• Max Radius is used by the device_tracker and Area sensors to limit how far away a device can be while still considered to be in that location. For device_tracker purposes (this is the Home/Away sensor you can attach to a Person), it probably makes sense for this to be quite large - since you still want to be "home" even if you're out in the yard or elsewhere that doesn't have good coverage. Bear in mind that "distance" is really a function of signal strength, so sitting in your car, inside the garage is likely to show a much more distant signal than standing next to the car or perhaps even out on the street. For the Area sensor, a large max_radius may also make sense if you have proxies in most of the rooms you want to track for. The Area will switch to the closest room, so you can consider it to mean "I am near my office". However if you have proxies only in a few rooms, you might want a more definitive sense of "I am not in my office", in which case you may wish to lower the max_radius to 4 metres (13') or similar, so that being in the adjacent room doesn't show you as still being in your office. Note that results will probably be more reliable by putting a proxy in the adjacent room instead, but that depends on how many proxies you have. On that note, the concept of "you can't prove a negative" is quite pertinent, if not factually accurate. If Bermuda detects that something is in an Area, you can be pretty confident that this is true. This is because there's no way for a proxy to receive a stronger signal than physics wants it to, other than some truly unlikely reflections. However, the idea of being "away" from an Area is much less confidence-inspiring, since signals often get attenuated (weakened) by reflections, or the transmitter being sat on, or sun-spots, or the dark arts of RF propagation. So when designing your system, try to think in terms of how you can assert that something IS somewhere, rather than hoping to prove that it ISN'T.

• Max Velocity is expressed in metres per second. When we receive a reading that implies the device moved away from us at an unlikely speed, we can ignore that reading as it's likely very noise-affected. We check this by comparing recent measurements and their timestamps against the new measurement to work out what the device's peak velocity must have been if the latest measurement is accurate. We can assume this because closer measurements are "always" "more accurate" than distant measurements. Humans tend to walk at around 1.42m/s (5km/h ~ 3mph). The default is 3m/s (10km/h or ~ 6mph) to accomodate dogs, cats and children holding scissors. If you get more spikes in distances than you like, reducing the max velocity may help the algo to ignore those spikes. Note that we only ignore velocities away from the scanner, since we treat a fresh, closer measurement as intrinsically more accurate and therefore more authorative than filtered values.

• Devtracker Timeout in seconds to consider a device as "Not Home" applies only to the device_tracker platform. If no proxy has received a broadcast from the device in timeout seconds, that device will be marked as not_home / Away. If you experience false "away" readings then try increasing this value. Something like 300 (5 minutes) is probably fairly sensible for things where you want to automate arriving home, while not getting false triggers from general signal loss when moving about the home. For things like automating an alert if a pet leaves the property a shorter value might be wiser, however I'd much more stronly suggest using the Area and Distance sensors instead. That way you can apply your own timeouts in the automation, and also think about "proving a positive" instead - put a proxy at the front gate, or detect that your pet is in the garden, rather than trying to prove that they are not in the house.

• Update Interval - How often in seconds to update sensor data defaults to 5 seconds. This defines a maximum interval between sensor updates on distance and rssi. If a device moves closer the sensor will always update immediately (within a second, anyway), but for distances that are increasing (likewise RSSI values that are decreasing) the sensor won't bother updating until this interval has passed. Note that decisions about what area a device is in is done every second regardless of this setting, using the finer-grained values contained in the back-end - so this only affects the UI, not the underlying decision algorithm. The idea is that this reduces the amount of "churn" on the sensors, which reduces how much data gets pumped into your history database. My 100GB Postgres/TimeseriesDB on raid doesn't mind so much, but if you are using an SD card for your storage you'll probably want to either keep it at 5 seconds or perhaps even increase it. If you are doing some testing and want to get a better idea of the values and how the filtering works in the background you can lower this to 1 second (1 second is the most often it will update, as the backend only refreshes values at this rate). Just don't forget to put it back afterwards! You can change this setting in the UI and it will take effect immediately, which is nice. It's worth noting here that the main distance sensor is also rounded to a single decimal place (10cm or ~4"), but the "Distance to xx" sensors are rounded to 3 decimal places (1mm or ~ 0.04"). Of course values even at 10cm are pretty unreliable but it helps to see that new values are coming in versus missing adverts.

  If you need to avoid growing your database but still want frequent updates, you can filter out specific sensors (or patterns/globs) of sensors from being written to the history db by adding something like this to your configuration.yaml (thanks @jaymunro). I think you might need an identical snippet in your ltss section to filter from your long-term statistics, too:

  recorder:
  exclude:
    entity_globs:
      # to filter specific sensors
      - sensor.*_distance_to_aska*
      - sensor.*_distance_to_back*
      # ...etc
      # or filter all the distance-to sensors
      - sensor.*_distance_to_*

• How many samples to use for smoothing distance readings or smoothing_samples. The bigger this number, the slower Bermuda will increase distances for devices that are moving away. This is good for filtering noisy data (noise always makes the distance longer). 10 gives a moderately increasing distance, 20 seems pretty reliable. You can enable one of the "raw/unfiltered" sensor entities and graph them against the distance to get a feel for how well it works. Note that the smoothing algorithm will change over time, so don't get too attached to this setting, or spend too long tuning it!

• Environment attenuation factor is for "fudging" the rate at which the signal strength drops off with distance. In a vacuum with no other objects, the signal drops off predictably, but so would we. This factor helps to account for things like humidity, air density (altitude, pollution etc) and in some part the way that the surroundings might interfere with the signal. Basically we fiddle with this so that after we calibrate our 1 metre setting, we get a sensible result at other distances like at 4 metres etc. See How do I choose values for Attenuation and Ref_power for instructions on calibration.

• Default RSSI at 1 metre is how strong a signal the receiver sees when the transmitter is 1 metre away. Some beacons will actually advertise this figure in their data, and some of them might even be true. But ignore that. See How do I choose values for Attenuation and Ref_power below for how to measure and set this for your own particular setup. Note that this number is dependent on the transmitter's software, the power it transmits at, the style (and orientation) of its antenna, the enclosure it's in, and also depends on the receiver's enclosure, antenna and circuit's sensitivity. And everything in- between. Future versions of Bermuda will let you set the value per-device and offset it per-receiver, but for now, measure the device you care most about against the proxy you have the most of. And bear in mind that "distance" is really a relative term when trying to measure it using the simple amplitude of radio waves.

• List of Bluetooth devices to specifically create tracking entities for this split-infinitive lets you select which devices you want to track. Any advertising devices that are in range, and any iBeacons should be available to select in here. If you don't see any devices check that your esphome or other proxies are connected to Homeassistant and configured to relay bluetooth traffic.