esphome-docs/components/sensor/index.rst

446 lines
14 KiB
ReStructuredText
Raw Normal View History

2018-05-13 11:37:02 +02:00
Sensor Component
================
2018-11-14 22:12:27 +01:00
.. seo::
2019-02-16 23:25:23 +01:00
:description: Instructions for setting up sensor components in ESPHome.
:image: folder-open.png
2018-11-14 22:12:27 +01:00
2019-02-16 23:25:23 +01:00
ESPHome has support for many different sensors. Each of them is a
2018-05-13 11:37:02 +02:00
platform of the ``sensor`` domain and each sensor has several base
configuration options.
2018-06-01 18:10:00 +02:00
.. _config-sensor:
2018-05-13 11:37:02 +02:00
Base Sensor Configuration
2018-08-24 22:44:01 +02:00
-------------------------
2018-05-13 11:37:02 +02:00
2019-02-16 23:25:23 +01:00
All sensors in ESPHome have a name and some other
2018-05-13 11:37:02 +02:00
optional configuration options. By default, the sensor platform will
chose appropriate values for all of these by default, but you can always
override them if you want to.
.. code-block:: yaml
2018-05-13 11:37:02 +02:00
# Example sensor configuration
name: Livingroom Temperature
# Optional variables:
unit_of_measurement: "°C"
icon: "mdi:water-percent"
accuracy_decimals: 1
expire_after: 30s
filters:
- sliding_window_moving_average:
window_size: 15
send_every: 15
Configuration variables:
2018-06-01 18:10:00 +02:00
- **name** (**Required**, string): The name for the sensor.
- **unit_of_measurement** (*Optional*, string): Manually set the unit
of measurement the sensor should advertise its values with. This does
not actually do any maths (conversion between units).
- **icon** (*Optional*, icon): Manually set the icon to use for the sensor in the frontend.
- **accuracy_decimals** (*Optional*, int): Manually set the accuracy of decimals to use when reporting values.
- **filters** (*Optional*): Specify filters to use for some basic
2019-02-28 09:37:37 +01:00
transforming of values. See :ref:`Sensor Filters <sensor-filters>` for more information.
2019-02-17 12:28:17 +01:00
- **internal** (*Optional*, boolean): Mark this component as internal. Internal components will
not be exposed to the frontend (like Home Assistant). Only specifying an ``id`` without
a ``name`` will implicitly set this to true.
2018-06-13 22:38:49 +02:00
Automations:
2018-06-01 18:10:00 +02:00
- **on_value** (*Optional*, :ref:`Automation <automation>`): An automation to perform
when a new value is published. See :ref:`sensor-on_value`.
- **on_value_range** (*Optional*, :ref:`Automation <automation>`): An automation to perform
when a published value transition from outside to a range to inside. See :ref:`sensor-on_value_range`.
- **on_raw_value** (*Optional*, :ref:`Automation <automation>`): An automation to perform
when a raw value is received that hasn't passed through any filters. See :ref:`sensor-on_raw_value`.
2019-02-17 12:28:17 +01:00
MQTT Options:
- **expire_after** (*Optional*, :ref:`config-time`): Manually set the time in which
the sensor values should be marked as “expired”/“unknown”. Not providing any value means no expiry.
- All other options from :ref:`MQTT Component <config-mqtt-component>`.
2018-06-01 18:10:00 +02:00
.. note::
If you're trying to setup filters for a sensor that has multiple outputs - for example a DHT22 which
reports temperature *and* humidity - put the ``filters`` option into each sensor output like this:
.. code-block:: yaml
sensor:
- platform: dht
# ...
temperature:
filters:
# ...
humidity:
filters:
# ...
2018-06-01 18:10:00 +02:00
.. _sensor-filters:
2018-05-13 11:37:02 +02:00
Sensor Filters
2018-08-24 22:44:01 +02:00
--------------
2018-05-13 11:37:02 +02:00
2019-02-16 23:25:23 +01:00
ESPHome allows you to do some basic pre-processing of
2018-05-13 11:37:02 +02:00
sensor values before theyre sent to Home Assistant. This is for example
2019-02-16 23:25:23 +01:00
useful if you want to apply some average over the last few values.
2018-05-13 11:37:02 +02:00
2019-02-26 19:33:50 +01:00
There are a lot of filters that sensors support. You define them by adding a ``filters``
block in the sensor configuration (at the same level as ``platform``; or inside each sensor block
for platforms with multiple sensors)
.. code-block:: yaml
2018-05-13 11:37:02 +02:00
# Example filters:
filters:
- offset: 2.0
- multiply: 1.2
2019-02-26 19:33:50 +01:00
- calibrate_linear:
- 0.0 -> 0.0
- 40.0 -> 45.0
- 100.0 -> 102.5
2018-05-13 11:37:02 +02:00
- filter_out: 42.0
- sliding_window_moving_average:
window_size: 15
send_every: 15
- exponential_moving_average:
alpha: 0.1
send_every: 15
2018-05-17 21:39:46 +02:00
- throttle: 1s
2018-05-18 08:21:52 +02:00
- heartbeat: 5s
- debounce: 0.1s
2018-05-17 21:39:46 +02:00
- delta: 5.0
- or:
- throttle: 1s
- delta: 5.0
2018-06-05 21:07:40 +02:00
- lambda: return x * (9.0/5.0) + 32.0;
2018-05-13 11:37:02 +02:00
2019-02-26 19:33:50 +01:00
``offset`` / ``multiply``
*************************
.. code-block:: yaml
# Example configuration entry
- platform: adc
# ...
filters:
- offset: 2.0
- multiply: 1.2
Offset adds a constant value to each sensor value. Multiply multiplies each value
by a constant value.
2019-03-13 18:57:49 +01:00
.. _sensor-filter-calibrate_linear:
2019-02-26 19:33:50 +01:00
``calibrate_linear``
********************
Calibrate your sensor values by using values you measured with an accurate "truth" source.
First, collect a bunch of values of what the sensor shows and what the real value should be.
For temperature, this can for example be achieved by using an accurate thermometer. For other
sensors like power sensor this can be done by connecting a known load and then writing down
the value the sensor shows.
.. code-block:: yaml
# Example configuration entry
- platform: dht
# ...
2019-03-11 13:21:21 +01:00
temperature:
2019-02-26 19:33:50 +01:00
filters:
- calibrate_linear:
# Map 0.0 (from sensor) to 0.0 (true value)
- 0.0 -> 0.0
- 10.0 -> 12.1
The arguments are a list of data points, each in the form ``MEASURED -> TRUTH``. ESPHome will
then fit a linear equation to the values (using least squares). So you need to supply at least
two values.
``filter_out``
**************
Filter out specific values to be displayed. For example to filter out the value ``85.0``
.. code-block:: yaml
# Example configuration entry
- platform: wifi_signal
# ...
filters:
- filter_out: 85.0
``sliding_window_moving_average`` / ``exponential_moving_average``
******************************************************************
Two simple moving averages over the data. These can be used to have a short update interval
on the sensor but only push out an average on a specific interval (thus increasing resolution).
.. code-block:: yaml
# Example configuration entry
- platform: wifi_signal
# ...
filters:
- sliding_window_moving_average:
window_size: 15
send_every: 15
2018-05-13 11:37:02 +02:00
- **sliding_window_moving_average**: A `simple moving
average <https://en.wikipedia.org/wiki/Moving_average#Simple_moving_average>`__
over the last few values.
- **window_size**: The number of values over which to perform an
average when pushing out a value.
- **send_every**: How often a sensor value should be pushed out. For
example, in above configuration the weighted average is only
pushed out on every 15th received sensor value.
- **send_first_at**: By default, the very first raw value on boot is immediately
published. With this parameter you can specify when the very first value is to be sent.
Defaults to ``1``.
2018-05-13 11:37:02 +02:00
- **exponential_moving_average**: A simple `exponential moving
average <https://en.wikipedia.org/wiki/Moving_average#Exponential_moving_average>`__
over the last few values.
- **alpha**: The forget factor/alpha value of the filter.
- **send_every**: How often a sensor value should be pushed out.
2019-02-26 19:33:50 +01:00
``throttle`` / ``heartbeat`` / ``debounce`` / ``delta``
*******************************************************
.. code-block:: yaml
# Example filters:
filters:
- throttle: 1s
- heartbeat: 5s
- debounce: 0.1s
- delta: 5.0
- lambda: return x * (9.0/5.0) + 32.0;
2018-05-17 21:39:46 +02:00
- **throttle**: Throttle the incoming values. When this filter gets an incoming value,
2018-05-18 08:21:52 +02:00
it checks if the last incoming value is at least ``specified time period`` old.
If it is not older than the configured value, the value is not passed forward.
- **heartbeat**: Send the last value that this sensor in the specified time interval.
So a value of ``10s`` will cause the filter to output values every 10s regardless
of the input values.
- **debounce**: Only send values if the last incoming value is at least ``specified time period``
old. For example if two values come in at almost the same time, this filter will only output
the last value and only after the specified time period has passed without any new incoming
values.
2018-05-17 21:39:46 +02:00
- **delta**: This filter stores the last value passed through this filter and only
passes incoming values through if the absolute difference is greater than the configured
value. For example if a value of 1.0 first comes in, it's passed on. If the delta filter
is configured with a value of 5, it will now not pass on an incoming value of 2.0, only values
that are at least 6.0 big or -4.0.
2019-02-26 19:33:50 +01:00
``or`` Filter
2019-03-05 20:43:30 +01:00
*************
2019-02-26 19:33:50 +01:00
.. code-block:: yaml
# Example filters:
filters:
- or:
- throttle: 1s
- delta: 5.0
2018-05-17 21:39:46 +02:00
- **or**: Pass forward a value with the first child filter that returns. Above example
will only pass forward values that are *either* at least 1s old or are if the absolute
difference is at least 5.0.
2019-02-26 19:33:50 +01:00
``lambda`` Filter
*****************
.. code-block:: yaml
filters:
- lambda: return x * (9.0/5.0) + 32.0;
**lambda**: Perform a simple mathematical operation over the sensor
values. The input value is ``x`` and the result of the lambda is used
as the output (use ``return``).
Make sure to add ``.0`` to all values in the lambda, otherwise divisions of integers will
result in integers (not floating point values).
2018-05-13 11:37:02 +02:00
Example: Converting Celsius to Fahrenheit
2018-08-24 22:44:01 +02:00
-----------------------------------------
2018-05-13 11:37:02 +02:00
While I personally dont like the Fahrenheit temperature scale, I do
understand that having temperature values appear in the fahrenheit unit
2019-02-16 23:25:23 +01:00
is quite useful to some users. ESPHome uses the celsius temperature
2018-05-13 11:37:02 +02:00
unit internally, and Im not planning on making converting between the
two simple (😉), but you can use this filter to convert celsius values to
fahrenheit.
.. code-block:: yaml
2018-05-13 11:37:02 +02:00
filters:
2018-06-05 21:07:40 +02:00
- lambda: return x * (9.0/5.0) + 32.0;
2018-05-13 11:37:02 +02:00
unit_of_measurement: "°F"
2018-06-01 18:10:00 +02:00
Sensor Automation
2018-08-24 22:44:01 +02:00
-----------------
2018-06-01 18:10:00 +02:00
You can access the most recent state of the sensor in :ref:`lambdas <config-lambda>` using
2018-12-16 11:08:54 +01:00
``id(sensor_id).state`` and the most recent raw state using ``id(sensor_id).raw_state``.
2018-06-01 18:10:00 +02:00
.. _sensor-on_value:
``on_value``
2018-08-24 22:44:01 +02:00
************
2018-06-01 18:10:00 +02:00
This automation will be triggered when a new value that has passed through all filters
is published. In :ref:`Lambdas <config-lambda>` you can get the value from the trigger
with ``x``.
.. code-block:: yaml
2018-06-01 18:10:00 +02:00
sensor:
- platform: dallas
# ...
on_value:
then:
- light.turn_on:
id: light_1
red: !lambda "return x/255;"
Configuration variables: See :ref:`Automation <automation>`.
.. _sensor-on_value_range:
``on_value_range``
2018-08-24 22:44:01 +02:00
******************
2018-06-01 18:10:00 +02:00
With this automation you can observe if a sensor value passes from outside
a defined range of values to inside a range. For example you can have an
automation that triggers when a humidity crosses a threshold, and then turns on a dehumidifier.
This trigger will only trigger when the new value is inside the range and the previous value
2019-02-16 10:21:13 +01:00
was outside the range. On startup, the last state before reboot is restored and if the value crossed
the boundary during the boot process, the trigger is also executed.
2018-06-01 18:10:00 +02:00
Define the range with ``above`` and ``below``. If only one of them is defined, the interval is half-open.
So for example ``above: 5`` with no below would mean the range from 5 to positive infinity.
.. code-block:: yaml
2018-06-01 18:10:00 +02:00
sensor:
- platform: dallas
# ...
on_value_range:
above: 5
below: 10
then:
2018-11-10 14:33:24 +01:00
- switch.turn_on: relay_1
2018-06-01 18:10:00 +02:00
Configuration variables:
- **above** (*Optional*, float): The minimum for the trigger.
- **below** (*Optional*, float): The maximum for the trigger.
- See :ref:`Automation <automation>`.
.. _sensor-on_raw_value:
``on_raw_value``
2018-08-24 22:44:01 +02:00
****************
2018-06-01 18:10:00 +02:00
This automation will be triggered when a new value is received that hasn't passed
through any filters. In :ref:`Lambdas <config-lambda>` you can get the value from the
trigger with ``x``.
2018-06-01 18:10:00 +02:00
.. code-block:: yaml
2018-06-01 18:10:00 +02:00
sensor:
- platform: dallas
# ...
on_raw_value:
2018-06-01 18:10:00 +02:00
then:
- light.turn_on:
id: light_1
red: !lambda "return x/255;"
Configuration variables: See :ref:`Automation <automation>`.
2018-12-05 10:19:48 +01:00
.. _sensor-in_range_condition:
``sensor.in_range`` Condition
*****************************
This condition passes if the state of the given sensor is inside a range.
Define the range with ``above`` and ``below``. If only one of them is defined, the interval is half-open.
So for example ``above: 5`` with no below would mean the range from 5 to positive infinity.
.. code-block:: yaml
# in a trigger:
on_...:
if:
condition:
sensor.in_range:
id: my_sensor
above: 50.0
then:
- script.execute: my_script
Configuration variables:
- **above** (*Optional*, float): The minimum for the condition.
- **below** (*Optional*, float): The maximum for the condition.
.. _sensor-lambda_calls:
2018-06-07 15:55:31 +02:00
lambda calls
2018-08-24 22:44:01 +02:00
************
2018-06-07 15:55:31 +02:00
From :ref:`lambdas <config-lambda>`, you can call several methods on all sensors to do some
advanced stuff (see the full API Reference for more info).
2018-06-07 15:55:31 +02:00
- ``publish_state()``: Manually cause the sensor to push out a value. It will then
2018-06-07 15:55:31 +02:00
be processed by the sensor filters, and once done be published to MQTT.
.. code-block:: cpp
2018-06-07 15:55:31 +02:00
// Within lambda, push a value of 42.0
id(my_sensor).publish_state(42.0);
2018-06-07 15:55:31 +02:00
- ``.state``: Retrieve the current value of the sensor that has passed through all sensor filters.
2018-06-07 15:55:31 +02:00
Is ``NAN`` if no value has gotten through all filters yet.
.. code-block:: cpp
2018-06-07 15:55:31 +02:00
// For example, create a custom log message when a value is received:
ESP_LOGI("main", "Value of my sensor: %f", id(my_sensor).state);
2018-06-07 15:55:31 +02:00
- ``raw_state``: Retrieve the current value of the sensor that has not passed through any filters
2018-06-07 15:55:31 +02:00
Is ``NAN`` if no value if no value has been pushed by the sensor itself yet.
.. code-block:: cpp
2018-06-07 15:55:31 +02:00
// For example, create a custom log message when a value is received:
ESP_LOGI("main", "Raw Value of my sensor: %f", id(my_sensor).raw_state);
2018-06-07 15:55:31 +02:00
2018-06-01 18:10:00 +02:00
See Also
--------
2018-06-01 18:10:00 +02:00
- :apiref:`sensor/sensor.h`
- :ghedit:`Edit`
2018-06-01 18:10:00 +02:00
.. toctree::
:maxdepth: 1
:glob:
2018-06-01 18:10:00 +02:00
*