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

[[/img/screenshots/configuration.png]]

- `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:

  ```yaml
  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](#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](#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.