Rename Logbook to activity (#40837)

source/_dashboards/logbook.markdown

@@ -1,8 +1,8 @@
 ---
 type: card
-title: "Logbook card"
-sidebar_label: Logbook
-description: "The logbook card displays entries from the logbook for specific entities, devices, areas, and/or labels."
+title: "Activity card"
+sidebar_label: Activity
+description: "The activity card displays the activity of specific entities, devices, areas, and/or labels."
 related:
   - docs: /integrations/frontend/
     title: Themes
@@ -10,11 +10,11 @@ related:
     title: Dashboard cards
 ---
 
-The logbook card displays entries from the logbook for specific entities, devices, areas, and/or labels.
+The activity card displays entries from the activity for specific entities, devices, areas, and/or labels.
 
 <p class='img'>
-  <img src='/images/dashboards/logbook.png' alt='Screenshot of the logbook card'>
-  Screenshot of the logbook card.
+  <img src='/images/dashboards/activity-card.png' alt='Screenshot of the activity card'>
+  Screenshot of the activity card.
 </p>
 
 {% include dashboard/edit_dashboard.md %}
@@ -23,7 +23,7 @@ The logbook card displays entries from the logbook for specific entities, device
 
 {% configuration_basic %}
 Target:
-  description: The entities, devices, areas and labels whose logbook entries will show in the card. See [target selector](/docs/blueprint/selectors/#target-selector) for more information.
+  description: The entities, devices, areas and labels whose activity entries will show in the card. See [target selector](/docs/blueprint/selectors/#target-selector) for more information.
 Title:
   description: The title that shows on the top of the card.
 Hours to show:
@@ -34,7 +34,7 @@ Theme:
 
 ## YAML configuration
 
-The following YAML options are available when you use YAML mode or just prefer to use YAML in the code editor in the UI.
+The following YAML options are available when you use YAML mode or just prefer to use YAML in the code editor in the UI. Activity used to be called "logbook" in the past, and is still called logbook in YAML.
 
 {% configuration %}
 type:

source/_docs/automation/troubleshooting.markdown

@@ -33,7 +33,7 @@ If you are writing automations in YAML, it is also useful to go to {% my server_
 
 When an {% term automation %} is run, all steps are recorded and a trace is made. From the UI, open **Settings**, which is located in the sidebar, then select **Automations & Scenes** to go to the automation editor or click this button directly: {% my automations badge %}
 
-From the automation editor UI, or in the automations list in the three dots menu, select **Traces**. Alternatively, select an automation entry shown in the Logbook.
+From the automation editor UI, or in the automations list in the three dots menu, select **Traces**. Alternatively, select an automation entry shown under **Activity**.
 
 ![Automation tracing example](/images/integrations/automation/automation-tracing.png)
 
@@ -44,7 +44,7 @@ The right side of the trace screen has tabs with more information:
 - **Step Details** shows data and results of the step that is currently highlighted.
 - **Automation Config** shows the full YAML configuration at the time the automation was run.
 - **Trace Timeline**, shown in the screenshot above, lists the steps that were executed and their timing.
-- **Related logbook entries**, shows a logbook for all the entries related to the specific trace.
+- **Related activity**, shows the activity for all the entries related to the specific trace.
 - **Blueprint Config** will only be shown if the automation was created from a {% term blueprint %}.
 
 The top bar shows the date and time the automation was triggered. Use the left and right arrows to view previous runs of the automation.

source/_docs/scripts.markdown

@@ -325,7 +325,7 @@ This can be used to take different actions based on whether or not the condition
 
 ## Fire an event
 
-This {% term action %} allows you to fire an event. Events can be used for many things. It could trigger an {% term automation %} or indicate to another integration that something is happening. For instance, in the below example it is used to create an entry in the logbook.
+This {% term action %} allows you to fire an event. Events can be used for many things. It could trigger an {% term automation %} or indicate to another integration that something is happening. For instance, in the below example it is used to create an entry in the **Activity** panel.
 
 ```yaml
 - alias: "Fire LOGBOOK_ENTRY event"

source/_integrations/datadog.markdown

@@ -22,7 +22,7 @@ Datadog allows you to analyze, monitor, cross-reference and alert upon your data
   <img src='/images/screenshots/datadog-board-example.png' />
 </p>
 
-The integration also sends events from the logbook into Datadog, allowing you to correlate these events with your data.
+The integration also sends events from activity tracking into Datadog, allowing you to correlate these events with your data.
 
 <p class='img'>
   <img src='/images/screenshots/datadog-event-stream.png' />

source/_integrations/default_config.markdown

@@ -26,7 +26,7 @@ This {% term integration %} is a meta-component and configures a default set of
 - [Home Assistant Alerts](/integrations/homeassistant_alerts) (`homeassistant_alerts`)
 - [Home Assistant Cloud](/integrations/cloud/) (`cloud`)
 - [Image upload](/integrations/image_upload/) (`image_upload`)
-- [Logbook](/integrations/logbook/) (`logbook`)
+- [Activity](/integrations/logbook/) (`logbook`)
 - [Media source](/integrations/media_source/) (`media_source`)
 - [Mobile app support](/integrations/mobile_app/) (`mobile_app`)
 - [My Home Assistant](/integrations/my/) (`my`)

source/_integrations/garadget.markdown

@@ -115,7 +115,7 @@ customize:
 
 {% endraw %}
 
-Some of the Garadget sensors can create a lot of clutter in the logbook.  Use this section of code in your{% term "`configuration.yaml`" %} to exclude those entries.
+Some of the Garadget sensors can create a lot of clutter in the **Activity** section. Use this section of code in your{% term "`configuration.yaml`" %} to exclude those entries.
 
 ```yaml
 logbook:

source/_integrations/logbook.markdown

@@ -1,6 +1,6 @@
 ---
 title: Activity
-description: Instructions on how to enable the logbook integration for Home Assistant.
+description: Instructions on how to enable the activity integration for Home Assistant.
 ha_category:
   - History
 ha_release: 0.7
@@ -14,14 +14,14 @@ related:
     title: Configuration file
 ---
 
-<img src='/images/screenshots/logbook.png' style='margin-left:10px; float: right;' height="100" />
+<img src='/images/screenshots/activity-panel.png' style='margin-left:10px; float: right;' height="100" />
 
-The logbook {% term integration %} provides a different perspective on the history of your
+The activity {% term integration %} provides a different perspective on the history of your
 house by showing all the changes that happened to your house in reverse
 chronological order. It depends on
 the [`recorder`](/integrations/recorder/) integration for storing the data. This means that if the
 [`recorder`](/integrations/recorder/) integration is set up to use e.g., MySQL or
-PostgreSQL as data store, the `logbook` integration does not use the default
+PostgreSQL as data store, the `activity` integration does not use the default
 SQLite database to store data.
 
 This integration is by default enabled, unless you've disabled or removed the [`default_config:`](/integrations/default_config/) line from your {% term "`configuration.yaml`" %} file. If that is the case, the following example shows you how to enable this integration manually, by adding it to your {% term "`configuration.yaml`" %} file:
@@ -33,44 +33,44 @@ logbook:
 
 {% configuration %}
 exclude:
-  description: "Configure which integrations should **not** create logbook entries. ([Configure Filter](#configure-filter))"
+  description: "Configure which integrations should **not** should not track activity. ([Configure Filter](#configure-filter))"
   required: false
   type: map
   keys:
     entities:
-      description: The list of entity ids to be excluded from creating logbook entries.
+      description: The list of entity ids to be excluded from tracking activity.
       required: false
       type: list
     entity_globs:
-      description: Exclude all entities matching a listed pattern from creating logbook entries (e.g., `sensor.weather_*`).
+      description: Exclude all entities matching a listed pattern from tracking activity (e.g., `sensor.weather_*`).
       required: false
       type: list
     domains:
-      description: The list of domains to be excluded from creating logbook entries.
+      description: The list of domains to be excluded from tracking activity.
       required: false
       type: list
 include:
-  description: Configure which integrations should create logbook entries. ([Configure Filter](#configure-filter))
+  description: Configure which integrations should tracking activity. ([Configure Filter](#configure-filter))
   required: false
   type: map
   keys:
     entities:
-      description: The list of entity ids to be included in creating logbook entries.
+      description: The list of entity ids to be included when tracking activity.
       required: false
       type: list
     entity_globs:
-      description: Include all entities matching a listed pattern when creating logbook entries (e.g., `sensor.weather_*`).
+      description: Include all entities matching a listed pattern when tracking activity (e.g., `sensor.weather_*`).
       required: false
       type: list
     domains:
-      description: The list of domains to be included in creating logbook entries.
+      description: The list of domains to be included when tracking activity.
       required: false
       type: list
 {% endconfiguration %}
 
 ## Configure filter
 
-By default, the logbook will use the same filter as the recorder. To limit which entities are being exposed to `Logbook`, you can use the `include` and `exclude` parameters.
+By default, the activity will use the same filter as the recorder. To limit which entities are being exposed to `Logbook`, you can use the `include` and `exclude` parameters.
 
 ```yaml
 # Example filter to include specified domains and exclude specified entities
@@ -90,11 +90,11 @@ logbook:
 
 ### Common filtering examples
 
-If you want to exclude messages of some entities or domains from the logbook
+If you want to exclude messages of some entities or domains from activity tracking,
 just add the `exclude` parameter like:
 
 ```yaml
-# Example of excluding domains and entities from the logbook
+# Example of excluding domains and entities from activity tracking (formerly called logbook)
 logbook:
   exclude:
     entities:
@@ -106,11 +106,11 @@ logbook:
       - sun
 ```
 
-In case you just want to see messages from some specific entities or domains use
+In case you just want to see messages from some specific entities or domains, use
 the `include` configuration:
 
 ```yaml
-# Example to show how to include only the listed domains and entities in the logbook
+# Example to show how to only track the activity of the listed domains and entities
 logbook:
   include:
     domains:
@@ -120,11 +120,11 @@ logbook:
 ```
 
 You can also use the `include` list and filter out some entities or domains with
-an `exclude` list. Usually this makes sense if you define domains on the include
+an `exclude` list. Usually, this makes sense if you define domains on the include
 side and filter out some specific entities.
 
 ```yaml
-# Example of combining include and exclude configurations
+# Example of combining include and exclude configurations for activity tracking
 logbook:
   include:
     domains:
@@ -142,13 +142,13 @@ logbook:
 ### Exclude events
 
 If you have `sensor.date` to show the current date in the UI,
-but you do not want a logbook entry for that sensor every day it can be excluded.
-To exclude these entities just add them to the `exclude` > `entities` list in
-the configuration of the logbook.
+but you do not want activity tracking for that sensor every day, it can be excluded.
+To exclude these entities, just add them to the `exclude` > `entities` list in
+the configuration of the activity tracking.
 
-To exclude all events from a whole domain add it to the `exclude` > `domain`
-list. For instance you use the `sun` domain only to trigger automations on the
-`azimuth` attribute, then you possible are not interested in the logbook entries
+To exclude all events from a whole domain, add it to the `exclude` > `domain`
+list. For instance, if you use the `sun` domain only to trigger automations on the
+`azimuth` attribute, then you are possibly not interested in activity tracking
 for sun rise and sun set.
 
 Excluded entities still take up space in the database. It may be advisable to
@@ -156,14 +156,14 @@ exclude them in `recorder` instead.
 
 ### Custom entries
 
-It is possible to add custom entries to the logbook by using the script
+It is possible to add custom entries to activity tracking by using the script
 integration to fire an event.
 
 ```yaml
 # Example configuration.yaml entry
 script:
   add_logbook_entry:
-    alias: "Add Logbook"
+    alias: "Add activity"
     sequence:
       - action: logbook.log
         data:
@@ -176,9 +176,9 @@ script:
 
 
 {% important %}
-When calling the `logbook.log` action without a `domain` or `entity_id`, entries will be added with the `logbook` domain. Ensure that the `logbook` domain is not filtered away if you want these entries to appear in your logbook.
+When calling the `logbook.log` action without a `domain` or `entity_id`, entries will be added with the `logbook` domain. Ensure that the `logbook` domain is not filtered away if you want these entries to appear in your **Activity** panel.
 {% endimportant %}
 
 {% note %}
-Sensor entities that have been assigned units (i.e., have a `unit_of_measurement` attribute) are assumed to change frequently and those sensors are automatically excluded from the logbook.
+Sensor entities that have been assigned units (for example, have a `unit_of_measurement` attribute) are assumed to change frequently and those sensors are automatically excluded from activity tracking.
 {% endnote %}

source/_integrations/recorder.markdown

@@ -85,7 +85,7 @@ recorder:
       default: 10
       type: integer
     commit_interval:
-      description: How often (in seconds) the events and state changes are committed to the database. The default of `5` allows events to be committed almost right away without trashing the disk when an event storm happens. Increasing this will reduce disk I/O and may prolong disk (SD card) lifetime with the trade-off being that the database will lag (the logbook and history will not lag, because the changes are streamed to them immediatelly). If this is set to `0` (zero), commit are made as soon as possible after an event is processed.
+      description: How often (in seconds) the events and state changes are committed to the database. The default of `5` allows events to be committed almost right away without trashing the disk when an event storm happens. Increasing this will reduce disk I/O and may prolong disk (SD card) lifetime with the trade-off being that the database will lag (the activity and history will not lag, because the changes are streamed to them immediatelly). If this is set to `0` (zero), commit are made as soon as possible after an event is processed.
       required: false
       default: 5
       type: integer
@@ -149,7 +149,7 @@ recorder:
 
 {% include common-tasks/filters.md %}
 
-If you only want to hide events from your logbook, take a look at the [logbook integration](/integrations/logbook/). But if you have privacy concerns about certain events or want them in neither the history or logbook, you should use the `exclude`/`include` options of the `recorder` integration. That way they aren't even in your database, you can reduce storage and keep the database small by excluding certain often-logged events (like `sensor.last_boot`).
+If you only want to hide events from your **Activity** panel, take a look at the [Activity integration](/integrations/logbook/). But if you have privacy concerns about certain events or want them in neither the history nor activity, you should use the `exclude`/`include` options of the `recorder` integration. That way they aren't even in your database, you can reduce storage and keep the database small by excluding certain often-logged events (like `sensor.last_boot`).
 
 #### Common filtering examples
 

source/_integrations/zwave_js.markdown

@@ -326,7 +326,7 @@ It is recommended to back up your Z-Wave network before resetting the device.
 
 
     ![Screenshot showing the device panel of a Z-Wave adapter](/images/integrations/z-wave/z-wave-controller-commands.png)
-4. On the device info page, check the logbook. When you see that the status entity became unavailable, the reset process is finished.
+4. On the device info page, check the **Activity** panel. When you see that the status entity became unavailable, the reset process is finished.
    - You can now unplug the adapter and use it to start a new network, or pass it on to someone else.
 5. If you no longer need the Z-Wave integration, you can [remove it](#removing-z-wave-js-from-home-assistant) from Home Assistant.
 

source/dashboards/cards.markdown

@@ -27,7 +27,7 @@ Screenshot of the masonry view with different types of cards.
 
 There are several different card types, each with their own configuration options. They can be categorized in terms of their function:
 
-- **Specific to a device type or service**: [alarm](/dashboards/alarm-panel/), [light](/dashboards/light/), [humidifier](/dashboards/humidifier/), [thermostat](/dashboards/thermostat/), [plant status](/dashboards/plant-status/), [media control](/dashboards/media-control/), [weather forecast](/dashboards/weather-forecast/), [to-do list](/dashboards/todo-list/), [map](/dashboards/map/), [logbook](/dashboards/logbook/), [calendar](/dashboards/calendar/)
+- **Specific to a device type or service**: [alarm](/dashboards/alarm-panel/), [light](/dashboards/light/), [humidifier](/dashboards/humidifier/), [thermostat](/dashboards/thermostat/), [plant status](/dashboards/plant-status/), [media control](/dashboards/media-control/), [weather forecast](/dashboards/weather-forecast/), [to-do list](/dashboards/todo-list/), [map](/dashboards/map/), [activity](/dashboards/logbook/), [calendar](/dashboards/calendar/)
 - **Grouping other cards**: [vertical stack](/dashboards/vertical-stack/), [horizontal stack](/dashboards/horizontal-stack/), [grid](/dashboards/grid/)
 - **Logic function**: [conditional](/dashboards/conditional/), [entity filter](/dashboards/entity-filter/)
 - **Display generic data**: [sensor](/dashboards/sensor/), [history graph](/dashboards/history-graph/), [statistic](/dashboards/statistic/), [statistics graph](/dashboards/statistics-graph/), [energy](/dashboards/energy/), [gauge](/dashboards/gauge/), [webpage](/dashboards/iframe/)

source/dashboards/dashboards.markdown

@@ -3,7 +3,7 @@ title: "Multiple dashboards"
 description: "Multiple powerful and configurable dashboards in Home Assistant."
 related:
   - docs: /integrations/logbook/
-    title: Logbook integration
+    title: Activity integration
   - docs: /integrations/history/
     title: History integration
   - docs: /integrations/todo/
@@ -34,12 +34,12 @@ Home Assistant ships with some dashboards out of the box:
 - [Areas dashboard (experimental)](#areas-dashboard)
 - Energy dashboard
 - [History dashboard](#history-dashboard)
-- [Logbook dashboard](#logbook-dashboard)
+- [Activity dashboard](#activity-dashboard)
 - [Map dashboard](#map-dashboard)
 - [Overview dashboard](#creating-a-new-dashboard)
 - [To-do lists dashboard](#to-do-lists-dashboard)
 
-Not all of the predefined dashboards are listed under {% my lovelace_dashboards title="**Settings** > **Dashboards**" %}. The **Logbook** and **History** dashboards are powered by their respective integrations.
+Not all of the predefined dashboards are listed under {% my lovelace_dashboards title="**Settings** > **Dashboards**" %}. The **Activity** and **History** dashboards are powered by their respective integrations.
 
 ### Areas dashboard
 
@@ -84,9 +84,9 @@ Screenshot of the Areas default dashboard.
 
 The predefined **History** dashboard is powered by the [History integration](/integrations/history/). To learn about the data sources used and how to export data, refer to the documentation of the History integration.
 
-### Logbook dashboard
+### Activity dashboard
 
-The predefined **Logbook** dashboard is powered by the [Logbook integration](/integrations/logbook/). To control which events to show or filter out, refer to the documentation of the Logbook integration.
+The predefined **Activity** dashboard is powered by the [Activity integration](/integrations/logbook/). To control which events to show or filter out, refer to the documentation of the Activity integration.
 
 ### Map dashboard
 

source/getting-started/integration.markdown

@@ -57,7 +57,7 @@ This tutorial assumes that you have [installed Home Assistant](/installation/) a
    ![Screenshot of the workday integration details page](/images/getting-started/workday_sensor_details.png)
 
 2. Select **Service**, to open the service info page.
-   - In the **Logbook**, you can see the timeline of that {% term sensor %}.
+   - Under **Activity**, you can see the timeline of that {% term sensor %}.
    - Under **Sensors**, you can see all the sensors an integration provides. Here, we have only one, but if you have a climate device, for example, you might see temperature, humidity, and battery status here.
    - You can also see that **Workday** is not used (yet) in any {% term automations %}, {% term scripts %}, or {% term scenes %}.
 

source/getting-started/onboarding_dashboard.markdown

@@ -32,7 +32,7 @@ In the sidebar on the left, you see the names of different dashboards. Home Assi
 - Overview
 - Energy
 - Map
-- Logbook
+- Activity
 - History
 - To-do lists