You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If you no longer want to use a device or service in Home Assistant, you can remove the integration instance including the device or service with all its entities.
4
+
5
+
The following steps describe the general steps needed to remove an integration instance. Depending on the integration, additional steps can be needed, such as resetting the device or to delete credentials. Refer to the integration documentation to see if additional steps are needed.
6
+
7
+
### To remove an integration instance from Home Assistant
8
+
9
+
1. Go to {% my integrations title="**Settings** > **Devices & services**" %} and select the integration card.
10
+
2. From the list of devices, select the integration instance you want to remove.
11
+
3. Next to the entry, select the three-dot menu. Then, select **Delete**.
12
+
13
+
Copy file name to clipboardExpand all lines: source/_integrations/pushover.markdown
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -38,7 +38,7 @@ Example Automation:
38
38
39
39
Integration-specific values in the nested `data` section are optional.
40
40
41
-
Image attachments can be added using the `attachment` parameter, which can either be a local file reference (ex: `/tmp/image.png`).
41
+
Image attachments can be added using the `attachment` parameter, which must be a local file reference (ex: `/tmp/image.png`).
42
42
43
43
To use a specific Pushover device, set it using `target`. If one of the entered devices doesn't exist or is disabled in your Pushover account it will send a message to all you devices. To send to all devices, just skip the target attribute.
Copy file name to clipboardExpand all lines: source/_integrations/statistics.markdown
+9-4Lines changed: 9 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -20,14 +20,19 @@ ha_config_flow: true
20
20
21
21
The `statistics` integration observes the state of a source sensor and provides aggregated statistical characteristics about its recent past. This integration can be useful in automation, for example, to trigger an action when the air humidity in the bathroom settles after a hot shower or when the number of brewed coffees over a day gets too high.
22
22
23
-
The statistics sensor updates with every update of the source sensor, for which the numeric `sensor`and`binary_sensor`are supported. The time period and/or number of recent state changes, which should be considered, must be given in configuration. Check the configuration section below for details.
23
+
The `statistics` sensor can use either the numeric `sensor`or`binary_sensor`as it's input. The time period and/or number of recent state changes, which should be considered, must be given in configuration. Check the configuration section below for details.
24
24
25
25
Assuming the [`recorder`](/integrations/recorder/) integration is running, historical sensor data is read from the database on startup and is available immediately after a restart of the platform. If the [`recorder`](/integrations/recorder/) integration is *not* running, it can take some time for the sensor to start reporting data because some characteristics calculations require more than one source sensor value.
26
26
27
27
{% tip %}
28
-
The `statistics` integration is different to[Long-term Statistics](https://developers.home-assistant.io/docs/core/entity/sensor/#long-term-statistics). More details on the differences can be found in the [2021.8.0 release notes](/blog/2021/08/04/release-20218/#long-term-statistics).
28
+
The `statistics` integration is not the same as the[Long-term Statistics](https://developers.home-assistant.io/docs/core/entity/sensor/#long-term-statistics). More details on the differences can be found in the [2021.8.0 release notes](/blog/2021/08/04/release-20218/#long-term-statistics).
29
29
{% endtip %}
30
30
31
+
The `statistics` sensor has an internal buffer that stores the values it needs for the computation of the various functions (for example, `average_step`). The sensor is updated whenever new values are added to the buffer or when elements are removed. This is triggered either by a change of the source sensor (which may or may not change its actual value) or by values expiring (in cases where `max_age` was specified). This means that the buffer can hold a sequence of identical values in cases where values are not changing over time.
32
+
33
+
When using a time-based buffer (by providing a `max_age`), it is recommended to ensure that the buffer contains at least a decent number of values spanning the full range of time. For sensors that don't change much, this can be achieved by using a template sensor with a time-based trigger as input. If the input values don't cover most of the time range, the computed output values could lead to unexpected results.
34
+
Example: To find out whether a switch was used in the last 5 minutes, `count_on` could be used. However, if there are no frequent readings a single "Off" (maybe only a second ago) in the buffer would produce 0 even though the sensor was "On" for most of the last five minutes.
35
+
31
36
{% include integrations/config_flow.md %}
32
37
33
38
Further information about these configuration options can be found under the [YAML configuration](#yaml-configuration)
@@ -61,8 +66,8 @@ The following are supported for `sensor` source sensors `state_characteristic`:
61
66
62
67
| State Characteristic | Description |
63
68
| -------------------- | ----------- |
64
-
|`average_linear`| The average value of stored measurements under consideration of the time distances between them. A linear interpolation is applied per measurement pair. Suited to observe a source sensor with frequent, non-periodic sensor updates and when continuous behavior is represented by the measurements (e.g. your electricity consumption). WARNING: This type of average may show unexpected behavior in cases where values remain stable (e.g. an equally spaced sequence of t1:0 -> t2:0 -> t3:0 -> t4:0 -> t5:10 would produce an average of 5 instead of 1,25 because the non-changing zeros in the middle (t2 to t4) are being filtered out by Home Assistant and so the actually computed curve already starts rising at t1 instead of staying flat until t4). Accordingly, this function is only making sense in the context of noisy sensors that keep changing constantly. |
65
-
|`average_step`| The average value of stored measurements under consideration of the time distances between them. LOCF (last observation carried forward weighting) is applied, meaning, that the old value is assumed between two measurements. This is a better fit to how Home Assistant deals with constant values (compared to the linear function) and it is also better fitting to sensors that are switching between stable phases (e.g. a heating level set to either 1, 2 or 3). WARNING: Even when a time interval is specified by the max age parameter, the average is not necessarily matching the average over that whole interval (e.g. when values were removed due to the sampling size limit). |
69
+
|`average_linear`| The average value of stored measurements under consideration of the time distances between them. A linear interpolation is applied per measurement pair. Suited to observe a source sensor with frequent, non-periodic sensor updates and when continuous behavior is represented by the measurements (e.g. your electricity consumption). WARNING: This doesn't compute the exact average over the full interval defined by `max_age`. It will only consider the interval between the first and the last value in the buffer. |
70
+
|`average_step`| The average value of stored measurements under consideration of the time distances between them. LOCF (last observation carried forward weighting) is applied, meaning, that the old value is assumed between two measurements. This is a better fit to how Home Assistant deals with constant values (compared to the linear function) and it is also better fitting to sensors that are switching between stable phases (e.g. a heating level set to either 1, 2 or 3). WARNING: This doesn't compute the exact average over the full interval defined by `max_age`. It will only consider the interval between the first and the last value in the buffer. |
66
71
|`average_timeless`| The average value of stored measurements. This method assumes that all measurements are equally spaced and, therefore, time is ignored and a simple average of values is computed. Equal to `mean`. |
67
72
|`change_sample`| The average change per sample. The difference between the newest and the oldest measurement is divided by the number of in-between measurements (n-1). |
68
73
|`change_second`| The average change per second. The difference between the newest and the oldest measurement is divided by seconds between them. |
Copy file name to clipboardExpand all lines: source/common-tasks/general.markdown
+3-1Lines changed: 3 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -22,4 +22,6 @@ Creating an automation for polling gives you more flexibility on when to poll:
22
22
1. Not all integrations have a configurable polling interval. The homeassistant.update_entity service, on the other hand, works with most of the integrations; no code changes are required.
23
23
2. An automation allows you to poll whenever you want. For example, if you have a rate-limited solar panel provider with a maximum number of requests per day, you may want to lower/stop the polling at night but poll more frequently during the day.
24
24
25
-
{% include common-tasks/define_custom_polling.md %}
25
+
{% include common-tasks/define_custom_polling.md %}
26
+
27
+
{% include common-tasks/remove_device_service.md %}
0 commit comments