Logs, Recorder and Database size

Bermuda can cause a fair amount of extra logging to take place than your system is used to. This can result in more disk space being used for the database and more logbook entries etc. This is because we are tracking radio signal levels which are inherently unstable, so we get lots of "changes" all the time.

This can be especially important if you are using an SD card as your primary storage, such as on a RaspberryPi or similar. SD cards are not a good place to store rapidly changing (or growing!) databases, and you may find your card filling up, wearing out, or just performing poorly. Moving to an SSD is the best solution, but you can exclude Bermuda sensors (and others) from you history in the meantime.

The sensors that cause the most data changes are the "Unfiltered distance to..." and "Distance to.." sensors. This is why they are disabled by default. I'd recommend not using the "unfiltered" sensors unless you are working on testing our filtering algorithms, as the normal sensors are likely to be much more useful, and also don't update as often.

TL/DR; / The Quick Fix

Reduce how often distance sensors update

In Bermuda's Global Options config, the Update Interval setting gives some control over how often sensors update. It only affects updates where a sensor is reporting an increased distance. It does not affect the Area sensor, and updates showing a closer distance will always happen immediately.

Preventing further database growth:

To reduce database size growth that Bermuda can cause, add this to your configuration.yaml and restart (thanks @jaymunro):

recorder:
  exclude:
    # to completely exclude all Bermuda data from logs, add this domain section. Not
    # recommended, but might be good if you like *big* hammers.
    # domains:
    #   - bermuda
    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_*
      # The area sensors
      - sensor.*_area
      # The distance to closest area sensor
      - sensor.*_distance

Recovering disk space

After you have reconfigured the recorder, the historical data that was previously recorded will still be in the database. You can ask HA to purge that history from the database with a service call, which will delete those records. This alone won't free up the disk space though, as databases tend to just mark those places in their file as being "available" for new data, rather than re-writing the file to make it smaller. Using the purge option here will force the database to re-write its files in order to reclaim disk space. Note that this is an intensive operation, so your system may bog down for some time while it does this.

See the recorder - Service Purge documentation for more on this. In short, you go to Developer Tools, Services, select the Recorder Purge service, and either use the GUI or paste YAML similar to:

service: recorder.purge
data:
  keep_days: 10
  repack: true
  apply_filter: true

A deeper look at things...

HA has a few levels of historical recording:

• Logger / the Log file - stored in home-assistant.log in the config directory. Used for troubleshooting, Bermuda won't typically affect the size of this. If you set the log level to DEBUG then you will get a lot of output from Bermuda. This is by design. HA also exposes recent entries from the logfile via the system_log integration, viewable through Settings, System, Logs.
• Recorder integration is the primary database storage of HA. By default HA uses SQLite but it's also possible to change this to use MariaDB or PostgreSQL.
• Long-Term Statistics and short-term statistics are tables stored and maintained by the recorder integration. It keeps 5-minute snapshots for the recorder's retention period (default 10 days), and after that are aggregated into hourly snapshots for long-term stats. Since these entries are aggregated by time, they shouldn't cause any storage difficulties specifically from Bermuda's sensors.
• Long Term State Storage via the ltss custom integration. If you use this you may (or may not) want to apply the same filtering rules to it, as it works independently from the recorder integration but records the same information.
• Logbook displays information that is stored in the recorder integration. Filtering applied to this integration only affects the "view" of the data, not how it is stored. This can be good if you just want to reduce visual clutter in the logbook but still having full historical data available.
• History integration - is purely a "view" of data provided by the recorder integration.