-
-
Notifications
You must be signed in to change notification settings - Fork 10
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.
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.
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
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
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 toDEBUG
then you will get a lot of output from Bermuda. This is by design. HA also exposes recent entries from the logfile via thesystem_log
integration, viewable throughSettings
,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 therecorder
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.