diff --git a/changelog/2023.4.0.rst b/changelog/2023.4.0.rst index 96d6554d0..375fd8540 100644 --- a/changelog/2023.4.0.rst +++ b/changelog/2023.4.0.rst @@ -22,7 +22,7 @@ Voice Assistant This year is the Year of the Voice for Home Assistant, and ESPHome is charging ahead with this in mind. We've added a new :doc:`/components/voice_assistant` component that allows you to use ESPHome devices as an input -for `assist `__ in Home Assistant **2023.5 or later**. +for `assist `__ in Home Assistant **2023.5 or later**. With this also comes preliminary :doc:`microphone ` support, which has been built in a way that multiple components, like ``voice_assistant`` can request start / stop of the microphone and get the data. We diff --git a/changelog/2023.5.0.rst b/changelog/2023.5.0.rst index 68f4b9ff4..f2e8583de 100644 --- a/changelog/2023.5.0.rst +++ b/changelog/2023.5.0.rst @@ -80,6 +80,11 @@ Release 2023.5.4 - May 24 - fix modbus sending FP32_R values :esphomepr:`4882` by :ghuser:`ssieb` - Fix esp32_rmt_led_strip color modes :esphomepr:`4886` by :ghuser:`jesserockz` +Release 2023.5.5 - May 29 +------------------------- + +- Fix version printing not breaking yaml parsing :esphomepr:`4904` by :ghuser:`jesserockz` + Full list of changes -------------------- diff --git a/components/captive_portal.rst b/components/captive_portal.rst index 4b2543347..74305f44c 100644 --- a/components/captive_portal.rst +++ b/components/captive_portal.rst @@ -16,7 +16,7 @@ After 1 minute of unsuccessful WiFi connection attempts, the ESP will start a Wi :width: 70.0% In this web interface, you can manually override the WiFi settings of the device (please note -this will be overwritten by any subsequent upload so make sure to also update your YAML configuration). +this will be overwritten by any subsequent serial upload so make sure to also update your YAML configuration). Additionally, you can upload a new firmware file. diff --git a/components/climate/haier.rst b/components/climate/haier.rst index 62be42893..68a2b7685 100644 --- a/components/climate/haier.rst +++ b/components/climate/haier.rst @@ -5,7 +5,7 @@ Haier Climate :description: Instructions for setting up a Haier climate devices. :image: air-conditioner.svg -The `haier` climate platform creates a Haier climate device. +The ``haier`` climate platform creates a Haier climate device. The component can be used as a replacement of a Haier proprietary WiFi modules such as KZW-W001 and KZW-W002. This component requires a :ref:`uart` to be setup. @@ -33,7 +33,7 @@ Configuration variables: - **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation. - **name** (**Required**, string): The name of the climate device. -- **update_interval** (*Optional*, :ref:`config-time`): How often device will be polled for status. Defaults to `5s`. +- **update_interval** (*Optional*, :ref:`config-time`): How often device will be polled for status. Defaults to ``5s``. - **supported_swing_modes** (*Optional*, list): List of supported swing modes. Possible values are: ``VERTICAL``, ``HORIZONTAL``, ``BOTH``. - All other options from :ref:`Climate `. @@ -42,10 +42,10 @@ Hardware setup Most units will have a dedicated USB-A port for Haier WiFi module. The physical USB port is in fact UART and does not "speak" USB protocol. -It uses four USB pins as 5V, GND, RX, TX. +It uses four USB pins as 5V, GND, RX, TX. You can use spare male USB cable to connect esphome device directly to the climate appliance. -Other units will not have USB ports, but will still probably have UART exposed somewhere on the main board. +Other units will not have USB ports, but will still probably have UART exposed somewhere on the main board. .. list-table:: Haier UART pinout :header-rows: 1 diff --git a/components/climate/index.rst b/components/climate/index.rst index ceebe2525..7a49b5e12 100644 --- a/components/climate/index.rst +++ b/components/climate/index.rst @@ -52,8 +52,8 @@ Configuration variables: - **temperature_step** (*Optional*, float): The granularity with which the target temperature can be controlled. Can be a single number, or split as below: - - **target_temperature** (**Required**, float) - - **current_temperature** (**Required**, float) + - **target_temperature** (**Required**, float): The granularity for target temperature + - **current_temperature** (**Required**, float): The granularity for current temperature Advanced options: diff --git a/components/climate/pid.rst b/components/climate/pid.rst index 38f711eec..32a317560 100644 --- a/components/climate/pid.rst +++ b/components/climate/pid.rst @@ -15,12 +15,12 @@ temperature to a user-specified setpoint. .. note:: PID is like cruise control in the cars: it keeps the car's speed constant by continuously - adjusting the fuel quantity, based on load measurements. Eg when the car has to go up on a hill, + adjusting the fuel quantity, based on load measurements. Eg when the car has to go up on a hill, the system notices the load increase thus immediately gives more fuel to the engine; and when it goes down on the other side of the hill, it notices the load decrease thus reduces or cuts off fuel completely so that car speed remains as constant as possible. The calculation takes in consideration - constants like car weight, wind resistance etc. - + constants like car weight, wind resistance etc. + This kind of math can be used for a heating or cooling system too, and an auto-tuning algorithm can help determining such constants, which mainly describe the heat loss of the room or building. Goal is to keep the temperature as constant as possible, and smooth out oscillations otherwise produced by @@ -47,12 +47,12 @@ but there's a nice article explaining the function principle `here ` @@ -72,37 +72,35 @@ Configuration variables: ``ki`` to prevent windup. Defaults to ``-1``. - **max_integral** (*Optional*, float): The minimum value of the integral term multiplied by ``ki`` to prevent windup. Defaults to ``1``. - - **starting_integral_term** (*Optional*, float): Set the initial output, by priming the integral - term. This is useful for when your system is rebooted and you don't want to wait + - **starting_integral_term** (*Optional*, float): Set the initial output, by priming the integral + term. This is useful for when your system is rebooted and you don't want to wait for it to get back equilibrium. - - **output_averaging_samples** (*Optional*, int): average the output over this many samples. PID controllers - can be quite sensitive to small changes on the input sensor. By averaging the last X output samples, - the temperature can be more stable. However, the larger the sampling window, the less responsive the + - **output_averaging_samples** (*Optional*, int): average the output over this many samples. PID controllers + can be quite sensitive to small changes on the input sensor. By averaging the last X output samples, + the temperature can be more stable. However, the larger the sampling window, the less responsive the PID controller. Defaults to ``1`` which is no sampling/averaging. - - **derivative_averaging_samples** (*Optional*, int): average the derivative term over this many samples. Many - controllers don't use the derivative term because it is sensitive to slight changes in the input sensor. - By taking an average of the derivative term it might become more useful for you. Most PID controllers call - this derivative filtering. The derivative term is used to pre-act so don't filter too much. Defaults to ``1`` + - **derivative_averaging_samples** (*Optional*, int): average the derivative term over this many samples. Many + controllers don't use the derivative term because it is sensitive to slight changes in the input sensor. + By taking an average of the derivative term it might become more useful for you. Most PID controllers call + this derivative filtering. The derivative term is used to pre-act so don't filter too much. Defaults to ``1`` which is no sampling/averaging. -- **deadband_parameters** (*Optional*): Enables a deadband to stabilise and minimise changes in the +- **deadband_parameters** (*Optional*): Enables a deadband to stabilise and minimise changes in the output when the temperature is close to the target temperature. See `Deadband Setup`_. - - **threshold_low/threshold_high** (**Required**, float): Specifies a high/low - threshold defining the deadband - around the target temperature. For instance with `default_target_temperature` of ``21°C`` and - thresholds of ``+/-0.5°C``, the deadband will be + - **threshold_high/threshold_low** (**Required**, float): Specifies a high/low + threshold defining the deadband around the target temperature. For instance with + ``default_target_temperature`` of ``21°C`` and thresholds of ``+/-0.5°C``, the deadband will be between ``20.5°C - 21.5°C``. The PID controller will limit output changes within the deadband. + - **kp_multiplier** (*Optional*, float): Set the ``kp`` gain when inside the deadband. Defaults to ``0``. + - **ki_multiplier** (*Optional*, float): Set the ``ki`` gain when inside the deadband. Defaults to ``0``. + - **kd_multiplier** (*Optional*, float): Set the ``kd`` gain when inside the deadband. Recommended this + is set to ``0``. Defaults to ``0``. - - **kp_multiplier** (**Optional**, float): Set the ``kp`` gain when inside the deadband. Defaults to ``0``. - - **ki_multiplier** (**Optional**, float): Set the ``ki`` gain when inside the deadband. Defaults to ``0``. - - **kd_multiplier** (**Optional**, float): Set the ``kd`` gain when inside the deadband. Recommended this - is set to 0. Defaults to ``0``. - - - **deadband_output_averaging_samples** (**Optional**, int): Typically when inside the deadband the PID Controller has - reached a state of equilibrium, so it advantageous to use a higher number of output samples + - **deadband_output_averaging_samples** (*Optional*, int): Typically when inside the deadband the PID Controller has + reached a state of equilibrium, so it advantageous to use a higher number of output samples like 10-30 samples. Defaults to ``1`` which is no sampling/averaging. - All other options from :ref:`Climate `. @@ -116,7 +114,7 @@ To set up a PID climate controller, you need a couple of components: - A :ref:`Sensor ` to read the current temperature (``sensor``). - At least one :ref:`float output ` to drive for heating or cooling (or both). - This could for example be a PWM output via :doc:`/components/output/sigma_delta` or :doc:`/components/output/slow_pwm` that drives a heating unit. + This could for example be a PWM output via :doc:`/components/output/sigma_delta_output` or :doc:`/components/output/slow_pwm` that drives a heating unit. Please note the output *must* be controllable with continuous value (not only ON/OFF, but any state in between for example 50% heating power). @@ -126,22 +124,22 @@ To set up a PID climate controller, you need a couple of components: The sensor should have a short update interval. The PID update frequency is tied to the update interval of the sensor. Set a short ``update_interval`` like ``5s`` on the sensor. - We recommend putting a filter on the sensor (see filters in :doc:`/components/sensor/index`) and + We recommend putting a filter on the sensor (see filters in :doc:`/components/sensor/index`) and using ``output_averaging_samples`` to calm the PID sensor from a noisy input sensor. Deadband Setup -------------- -A deadband is used to prevent the PID controller from further adjusting the power -once the temperature has settled within a range of the target temperature. +A deadband is used to prevent the PID controller from further adjusting the power +once the temperature has settled within a range of the target temperature. -We do this by specifying a high/low threshold of the target temperature. +We do this by specifying a high/low threshold of the target temperature. -To understand the benefit, consider a heating/cooling HVAC which is constantly -oscillating between heating and cooling as the thermostat records very minor -changes from +0.1º to -0.1º. Clearly this is undesirable and will cause wear -and tear as the HVAC oscillates. With a deadband in place the heater won't -activate until the thermostat breaches the low_threshold and the cooler won't activate -until the thermostat breaches the high_threshold. +To understand the benefit, consider a heating/cooling HVAC which is constantly +oscillating between heating and cooling as the thermostat records very minor +changes from +0.1º to -0.1º. Clearly this is undesirable and will cause wear +and tear as the HVAC oscillates. With a deadband in place the heater won't +activate until the thermostat breaches the low_threshold and the cooler won't activate +until the thermostat breaches the high_threshold. The most basic setup specifies the threshold around the target temperature as follows: @@ -153,7 +151,7 @@ The most basic setup specifies the threshold around the target temperature as fo threshold_high: 0.5°C threshold_low: -1.0°C -In this example the deadband is between ``20.0°C - 21.5°C``. The PID controller will limit any output +In this example the deadband is between ``20.0°C - 21.5°C``. The PID controller will limit any output variation inside this deadband. How it limits depends on how you set the `Deadband Multipliers`_. .. figure:: images/deadband1.png @@ -161,19 +159,19 @@ variation inside this deadband. How it limits depends on how you set the `Deadba Deadband Multipliers ******************** -Deadband Multipliers tell the controller how to operate when inside of the deadband. +Deadband Multipliers tell the controller how to operate when inside of the deadband. -Each of the p,i and d terms can be controlled using the kp, ki and kd multipliers. For instance, if the kp_multiplier -is set to 0.05 then the final proportional term will be set to 5% of its normal value within the deadband. +Each of the p,i and d terms can be controlled using the kp, ki and kd multipliers. For instance, if the kp_multiplier +is set to 0.05 then the final proportional term will be set to 5% of its normal value within the deadband. -If all of the multipliers are set to 0, then the controller will not adjust power at all within the +If all of the multipliers are set to 0, then the controller will not adjust power at all within the deadband. This is the default behavior. -Most deadband implementations set kp and ki multipliers to a small gain like ``0.05`` and set -derivative to 0. This means that the PID output will calmly make minor adjustments over a 20x longer -timeframe to stay within the deadband zone. +Most deadband implementations set kp and ki multipliers to a small gain like ``0.05`` and set +derivative to 0. This means that the PID output will calmly make minor adjustments over a 20x longer +timeframe to stay within the deadband zone. -To start with we recommend just setting the ``ki_multiplier`` to ``0.05`` (5%). Then +To start with we recommend just setting the ``ki_multiplier`` to ``0.05`` (5%). Then set ``kp_multiplier`` to ``0.05`` (5%) if the controller is falling out of the deadband too often. .. code-block:: yaml @@ -184,7 +182,7 @@ set ``kp_multiplier`` to ``0.05`` (5%) if the controller is falling out of the d threshold_high: 0.5°C threshold_low: -1.0°C kp_multiplier: 0.0 # proportional gain turned off inside deadband - ki_multiplier: 0.05 # integral accumulates at only 5% of normal ki + ki_multiplier: 0.05 # integral accumulates at only 5% of normal ki kd_multiplier: 0.0 # derviative is turned off inside deadband deadband_output_averaging_samples: 15 # average the output over 15 samples within the deadband @@ -192,8 +190,8 @@ set ``kp_multiplier`` to ``0.05`` (5%) if the controller is falling out of the d Deadband Output Averaging Samples ********************************* -Since we expect the PID Controller to be at equilibrium while inside the deadband, we can -average the output over a longer range of samples, like 15 samples. This helps even further +Since we expect the PID Controller to be at equilibrium while inside the deadband, we can +average the output over a longer range of samples, like 15 samples. This helps even further with temperature and controller stability. .. _pid-autotune: @@ -249,7 +247,7 @@ is automatically calculated. To do this, it needs to observe at least 3 oscillat device can reach. For example if the temperature of a room is to be controlled, the setpoint needs to be above the ambient temperature. If the ambient temperature is 20°C, the setpoint of the climate device should be set to at least ~24°C so that an oscillation can be induced. - + Also take care of external influences, like for example when room temperature is severely affected by outdoor weather like sun, if it starts to warm up the room in parallel with the heating autotune will likely fail or give false results. @@ -273,10 +271,10 @@ is automatically calculated. To do this, it needs to observe at least 3 oscillat .. note:: In the output above, the autotuner is driving the heating output at 100% and trying to reach 24.25 °C. - + This will continue for some time until data for 3 phases (6 crossings of the setpoint; or a bit more, depending on the data quality) have been acquired. - + The autotune algorithm may take a long time to complete, it depends on the time needed to reproduce the heating up and cooling down oscillations the required number of times. @@ -298,7 +296,7 @@ is automatically calculated. To do this, it needs to observe at least 3 oscillat As soon as the the autotune procedure finishes, the climate starts to work with the calculated parameters so that expected operation can be immediately verified. - + If satisfied, copy the values in ``control_parameters`` into your configuration: .. code-block:: yaml @@ -349,7 +347,7 @@ Configuration variables: Defaults to ``-1.0``. The ``positive_output`` and ``negative_output`` parameters can be used to compensate the heating or the -cooling process during the autotune, in the cases when they are not changing the temperature at the +cooling process during the autotune, in the cases when they are not changing the temperature at the same rate, resulting in a not symmetrical oscillation. The autotune result will print a message when it's recommended to repeat the entire procedure with such parameters configured. @@ -435,7 +433,7 @@ See Also - Åström, K. J. and T. Hägglund (1984a), 'Automatic tuning of simple regulators', Proceedings of IFAC 9th World Congress, Budapest, 1867-1872 - :doc:`/components/climate/index` -- :doc:`/components/output/sigma_delta` +- :doc:`/components/output/sigma_delta_output` - :doc:`/components/output/slow_pwm` - `Principles of PID `__ - :apiref:`pid/pid_climate.h` diff --git a/components/cover/custom.rst b/components/cover/custom.rst index 305e1a5f9..dcd4a1643 100644 --- a/components/cover/custom.rst +++ b/components/cover/custom.rst @@ -30,6 +30,7 @@ two methods: traits.set_is_assumed_state(false); traits.set_supports_position(true); traits.set_supports_tilt(false); + traits.set_supports_stop(true); return traits; } void control(const CoverCall &call) override { diff --git a/components/deep_sleep.rst b/components/deep_sleep.rst index 3eb6b2d61..c9914a96a 100644 --- a/components/deep_sleep.rst +++ b/components/deep_sleep.rst @@ -32,7 +32,7 @@ even Over The Air updates. .. note:: - ESP8266 that have an onboard USB chip (e.g. D1 mini) one the chips' control lines is connected to the RST pin. This enables the flasher can reboot the ESP when required. This may interfere with deep sleep on some devices and prevent the ESP from waking when it's powered through its USB connector. Powering the ESP from a separate 3.3V source connected to the 3.3V pin and GND will solve this issue. In these cases using a USB to TTL adapter will allow you to log ESP activity. + Some ESP8266s have an onboard USB chip (e.g. D1 mini) on the chips' control line that is connected to the RST pin. This enables the flasher to reboot the ESP when required. This may interfere with deep sleep on some devices and prevent the ESP from waking when it's powered through its USB connector. Powering the ESP from a separate 3.3V source connected to the 3.3V pin and GND will solve this issue. In these cases, using a USB to TTL adapter will allow you to log ESP activity. Configuration variables: ------------------------ diff --git a/components/display/ili9xxx.rst b/components/display/ili9xxx.rst index 030e287cd..2fce0d340 100644 --- a/components/display/ili9xxx.rst +++ b/components/display/ili9xxx.rst @@ -33,7 +33,6 @@ beyond the typical SPI connections, it is better suited for use with the ESP32. display: - platform: ili9xxx model: ili9341 - cs_pin: 14 dc_pin: 27 reset_pin: 33 lambda: |- @@ -48,7 +47,6 @@ Configuration variables: - ``M5STACK``, ``TFT 2.4``, ``TFT 2.4R`` - ``ILI9341``, ``ILI9342``, ``ILI9481``, ``ILI9486``, ``ILI9488``, ``ST7796`` -- **cs_pin** (*Optional*, :ref:`Pin Schema `): The CS pin. - **dc_pin** (**Required**, :ref:`Pin Schema `): The DC pin. - **reset_pin** (*Optional*, :ref:`Pin Schema `): The RESET pin. - **rotation** (*Optional*): Set the rotation of the display. Everything drawn in the ``lambda:`` will be rotated @@ -66,6 +64,7 @@ Configuration variables: - ``GRAYSCALE`` - ``IMAGE_ADAPTIVE`` - **color_palette_images** (*Optional*): A list of image files that will be used to generate the color pallet for the display. This should only be used in conjunction with ``-color_palette: IMAGE_ADAPTIVE`` above. The images will be analysed at compile time and a custom color pallet will be created based on the most commonly occuring colors. A typical setting would be a sample image that represented the fully populated display. This can significantly improve the quality of displayed images. Note that these images are not stored on the ESP device, just the 256byte color pallet created from them. +- **dimensions** (*Optional*): Dimensions of the screen with WIDTHxHEIGHT. Usually not needed since ``model:`` has good defaults. Configuration examples ********************** @@ -140,7 +139,6 @@ To configure an image adaptive color pallet to show greater than 8 bit color dep display: - platform: ili9xxx model: ili9341 - cs_pin: 5 dc_pin: 4 reset_pin: 22 rotation: 90 diff --git a/components/fan/binary.rst b/components/fan/binary.rst index 78e967d09..eefad56e1 100644 --- a/components/fan/binary.rst +++ b/components/fan/binary.rst @@ -14,10 +14,18 @@ The ``binary`` fan platform lets you represent any binary :ref:`output` as a fan .. code-block:: yaml # Example configuration entry + output: + - id: fan_output + platform: gpio + pin: GPIO16 + fan: - platform: binary - output: my_output_1 + output: fan_output name: "Living Room Fan" + + + Configuration variables: ------------------------ diff --git a/components/light/fastled.rst b/components/light/fastled.rst index 9cf7cb482..5cceb0992 100644 --- a/components/light/fastled.rst +++ b/components/light/fastled.rst @@ -20,6 +20,12 @@ FastLED Light - https://github.com/FastLED/FastLED/issues/1322 - https://github.com/FastLED/FastLED/issues/1264 +.. warning:: + + FastLED does **not** work with ESP-IDF. + + For addressable lights, you can use :doc:`esp32_rmt_led_strip`. + .. _fastled-clockless: Clockless diff --git a/components/light/neopixelbus.rst b/components/light/neopixelbus.rst index cc5808a11..3eed9eff0 100644 --- a/components/light/neopixelbus.rst +++ b/components/light/neopixelbus.rst @@ -5,6 +5,12 @@ NeoPixelBus Light :description: Instructions for setting up Neopixel addressable lights. :image: color_lens.svg +.. warning:: + + NeoPixelBus does **not** work with ESP-IDF. + + For addressable lights, you can use :doc:`esp32_rmt_led_strip`. + The ``neopixelbus`` light platform allows you to create RGB lights in ESPHome for an individually addressable lights like NeoPixel or WS2812. diff --git a/components/matrix_keypad.rst b/components/matrix_keypad.rst index c546e0261..caf143c24 100644 --- a/components/matrix_keypad.rst +++ b/components/matrix_keypad.rst @@ -7,8 +7,8 @@ Matrix keypad :description: Matrix key input panel The ``matrix_keypad`` component allows you to integrate pads which -have the keys connected at the intersection points of the rows and columns -of a matrix. +have the keys connected at the intersection points of the rows and columns +of a matrix. .. figure:: ../images/matrix_keypad.jpg :align: center @@ -44,14 +44,14 @@ Configuration variables: - **columns** (**Required**, list): A list of :ref:`pins ` where the vertical matrix lines are connected, in order from left to right. These pins need to be input capable with pullups enabled. If there is no internal pullup, then an external one is required. -- **keys** (*Optional*, string): The keys present on the matrix, from top left to bottom right, +- **keys** (*Optional*, string): The keys present on the matrix, from top left to bottom right, row by row. Required for ``key_collector`` and ``binary_sensor`` (if using key selection). -- **has_diodes** (*Optional*, boolean): For pads where row pins are outputs, and the keys are +- **has_diodes** (*Optional*, boolean): For pads where row pins are outputs, and the keys are connected with diodes. Defaults to ``false``. -Binary Sensors --------------- +Binary Sensor +------------- Individual keys can be added independently to ESPHome as ``binary_sensor``: @@ -82,7 +82,7 @@ Either the ``row`` and ``col`` parameters, or the ``key`` parameter has to be pr .. note:: - Automatic handling of multiple keys (e.g. PIN code entry) is possible with the + Automatic handling of multiple keys (e.g. PIN code entry) is possible with the the :ref:`Key Collector ` component. See Also diff --git a/components/mdns.rst b/components/mdns.rst index ed388627d..6b14f6dca 100644 --- a/components/mdns.rst +++ b/components/mdns.rst @@ -48,7 +48,7 @@ Configuration variables: - **disabled** (*Optional*, boolean): Set to true to disable mDNS usage. Defaults to false. - **services** (*Optional*, list): List of additional services to expose. - - **service** (*Required*, string): Name of extra service - - **protocol** (*Required*, string): Protocol of service (_udp or _tcp) - - **port** (*Optional*, int): Port number of extra service - - **txt** (*Optional*, mapping): Additional text records to add to service + - **service** (**Required**, string): Name of extra service. + - **protocol** (**Required**, string): Protocol of service (_udp or _tcp). + - **port** (*Optional*, int): Port number of extra service. + - **txt** (*Optional*, mapping): Additional text records to add to service. diff --git a/components/media_player/i2s_audio.rst b/components/media_player/i2s_audio.rst index 68bd4f3f1..be6b880d2 100644 --- a/components/media_player/i2s_audio.rst +++ b/components/media_player/i2s_audio.rst @@ -1,4 +1,4 @@ -I2S Audio Media Player +I²S Audio Media Player ====================== .. seo:: diff --git a/components/output/index.rst b/components/output/index.rst index 66f689fd6..7c00c46dc 100644 --- a/components/output/index.rst +++ b/components/output/index.rst @@ -98,7 +98,7 @@ This action turns the output with the given ID off when executed. *************************** This action sets the float output to the given level when executed. Note: This only -works with floating point outputs like :doc:`/components/output/esp8266_pwm`, :doc:`/components/output/ledc`, :doc:`/components/output/sigma_delta`, :doc:`/components/output/slow_pwm`. +works with floating point outputs like :doc:`/components/output/esp8266_pwm`, :doc:`/components/output/ledc`, :doc:`/components/output/sigma_delta_output`, :doc:`/components/output/slow_pwm`. .. code-block:: yaml diff --git a/components/output/sigma_delta.rst b/components/output/sigma_delta_output.rst similarity index 100% rename from components/output/sigma_delta.rst rename to components/output/sigma_delta_output.rst diff --git a/components/output/slow_pwm.rst b/components/output/slow_pwm.rst index 9c129f4d9..34d6c8aa7 100644 --- a/components/output/slow_pwm.rst +++ b/components/output/slow_pwm.rst @@ -70,7 +70,7 @@ Example: .. note:: If the duty cycle is not constrained to a maximum value, the - :doc:`/components/output/sigma_delta` component offers faster updates and + :doc:`/components/output/sigma_delta_output` component offers faster updates and greater control over the switching frequency. This is better for loads that need some time to fully change between on and off, like eletric thermal actuator heads or fans. @@ -81,7 +81,7 @@ See Also - :doc:`/components/output/index` - :doc:`/components/output/esp8266_pwm` - :doc:`/components/output/ledc` -- :doc:`/components/output/sigma_delta` +- :doc:`/components/output/sigma_delta_output` - :doc:`/components/light/monochromatic` - :doc:`/components/fan/speed` - :doc:`/components/power_supply` diff --git a/components/prometheus.rst b/components/prometheus.rst index 151a8c6cb..5df1dfa00 100644 --- a/components/prometheus.rst +++ b/components/prometheus.rst @@ -71,5 +71,9 @@ Set the ``id`` and ``name`` label values of the Prometheus metric for the sensor See Also -------- +- :doc:`/components/web_server` +- :ref:`api-rest` +- :doc:`/components/http_request` - :apiref:`prometheus/prometheus_handler.h` +- `Prometheus `__ - :ghedit:`Edit` diff --git a/components/remote_receiver.rst b/components/remote_receiver.rst index 9c866f45f..640a3170c 100644 --- a/components/remote_receiver.rst +++ b/components/remote_receiver.rst @@ -204,13 +204,13 @@ Remote code selection (exactly one of these has to be included): - **canalsat**: Trigger on a decoded CanalSat remote code with the given data. - **device** (**Required**, int): The device to trigger on, see dumper output for more info. - - **address** (**Optional**, int): The address (or subdevice) to trigger on, see dumper output for more info. Defaults to ``0`` + - **address** (*Optional*, int): The address (or subdevice) to trigger on, see dumper output for more info. Defaults to ``0`` - **command** (**Required**, int): The command to listen for. - **canalsatld**: Trigger on a decoded CanalSatLD remote code with the given data. - **device** (**Required**, int): The device to trigger on, see dumper output for more info. - - **address** (**Optional**, int): The address (or subdevice) to trigger on, see dumper output for more info. Defaults to ``0`` + - **address** (*Optional*, int): The address (or subdevice) to trigger on, see dumper output for more info. Defaults to ``0`` - **command** (**Required**, int): The command to listen for. - **coolix**: Trigger on a decoded Coolix remote code with the given data. diff --git a/components/remote_transmitter.rst b/components/remote_transmitter.rst index 43c7ff85d..62c36ae95 100644 --- a/components/remote_transmitter.rst +++ b/components/remote_transmitter.rst @@ -122,7 +122,7 @@ This :ref:`action ` sends a CanalSat infrared remote code to a re Configuration variables: - **device** (**Required**, int): The device to send to, see dumper output for more details. -- **address** (**Optional**, int): The address (or subdevice) to send to, see dumper output for more details. Defaults to ``0`` +- **address** (*Optional*, int): The address (or subdevice) to send to, see dumper output for more details. Defaults to ``0`` - **command** (**Required**, int): The command to send. - All other options from :ref:`remote_transmitter-transmit_action`. @@ -149,7 +149,7 @@ This :ref:`action ` sends a CanalSatLD infrared remote code to a Configuration variables: - **device** (**Required**, int): The device to send to, see dumper output for more details. -- **address** (**Optional**, int): The address (or subdevice) to send to, see dumper output for more details. Defaults to ``0`` +- **address** (*Optional*, int): The address (or subdevice) to send to, see dumper output for more details. Defaults to ``0`` - **command** (**Required**, int): The command to send. - All other options from :ref:`remote_transmitter-transmit_action`. @@ -283,7 +283,7 @@ This :ref:`action ` sends a 40-bit Midea code to a remote transmi on_...: - remote_transmitter.transmit_midea: code: [0xA2, 0x08, 0xFF, 0xFF, 0xFF] - + on_...: - remote_transmitter.transmit_midea: code: !lambda |- diff --git a/components/rtttl.rst b/components/rtttl.rst index ea66970b4..51f35978f 100644 --- a/components/rtttl.rst +++ b/components/rtttl.rst @@ -55,7 +55,7 @@ Plays an rtttl tone. on_...: then: - - rtttl.play: 'MissionImp:d=16,o=6,b=95:32d,32d#,32d,32d#,32d,32d#,32d,32d#,32d,32d,32d#,32e,32f,32f#,32g,g,8p,g,8p,a#,p,c7,p,g,8p,g,8p,f,p,f#,p,g,8p,g,8p,a#,p,c7,p,g,8p,g,8p,f,p,f#,p,a#,g,2d,32p,a#,g,2c#,32p,a#,g,2c,a#5,8c,2p,32p,a#5,g5,2f#,32p,a#5,g5,2f,32p,a#5,g5,2e,d#,8d' + - rtttl.play: 'siren:d=8,o=5,b=100:d,e,d,e,d,e,d,e' Configuration options: @@ -101,15 +101,17 @@ This Condition returns true while playback is active. Common beeps ------------ -You can do your own beep patterns too! Here are a few I made so you can just use right away or tweak them to your -like: +You can do your own beep patterns too! Here's a short collection so you can just use right away or tweak them to your like: .. code-block:: yaml - two short:d=4,o=5,b=100:16e6,16e6 + two_short:d=4,o=5,b=100:16e6,16e6 long:d=1,o=5,b=100:e6 siren:d=8,o=5,b=100:d,e,d,e,d,e,d,e scale_up:d=32,o=5,b=100:c,c#,d#,e,f#,g#,a#,b + star_wars:d=16,o=5,b=100:4e,4e,4e,8c,p,g,4e,8c,p,g,4e,4p,4b,4b,4b,8c6,p,g,4d#,8c,p,g,4e,8p + mission_imp:d=16,o=6,b=95:32d,32d#,32d,32d#,32d,32d#,32d,32d#,32d,32d,32d#,32e,32f,32f#,32g,g,8p,g,8p,a#,p,c7,p,g,8p,g,8p,f,p,f#,p,g,8p,g,8p,a#,p,c7,p,g,8p,g,8p,f,p,f#,p,a#,g,2d,32p,a#,g,2c#,32p,a#,g,2c,a#5,8c,2p,32p,a#5,g5,2f#,32p,a#5,g5,2f,32p,a#5,g5,2e,d#,8d + mario:d=4,o=5,b=100:16e6,16e6,32p,8e6,16c6,8e6,8g6,8p,8g,8p,8c6,16p,8g,16p,8e,16p,8a,8b,16a#,8a,16g.,16e6,16g6,8a6,16f6,8g6,8e6,16c6,16d6,8b,16p,8c6,16p,8g,16p,8e,16p,8a,8b,16a#,8a,16g.,16e6,16g6,8a6,16f6,8g6,8e6,16c6,16d6,8b,8p,16g6,16f#6,16f6,16d#6,16p,16e6,16p,16g#,16a,16c6,16p,16a,16c6,16d6,8p,16g6,16f#6,16f6,16d#6,16p,16e6,16p,16c7,16p,16c7,16c7,p,16g6,16f#6,16f6,16d#6,16p,16e6,16p,16g#,16a,16c6,16p,16a,16c6,16d6,8p,16d#6,8p,16d6,8p,16c6 Test setup @@ -120,7 +122,7 @@ E.g. for calling ``rtttl.play`` select the service ``esphome.test_esp8266_rtttl_ .. code-block:: yaml - song_str: "mario:d=4,o=5,b=100:16e6,16e6,32p,8e6,16c6,8e6,8g6,8p,8g,8p,8c6,16p,8g,16p,8e,16p,8a,8b,16a#,8a,16g.,16e6,16g6,8a6,16f6,8g6,8e6,16c6,16d6,8b,16p,8c6,16p,8g,16p,8e,16p,8a,8b,16a#,8a,16g.,16e6,16g6,8a6,16f6,8g6,8e6,16c6,16d6,8b,8p,16g6,16f#6,16f6,16d#6,16p,16e6,16p,16g#,16a,16c6,16p,16a,16c6,16d6,8p,16g6,16f#6,16f6,16d#6,16p,16e6,16p,16c7,16p,16c7,16c7,p,16g6,16f#6,16f6,16d#6,16p,16e6,16p,16g#,16a,16c6,16p,16a,16c6,16d6,8p,16d#6,8p,16d6,8p,16c6" + song_str: 'scale_up:d=32,o=5,b=100:c,c#,d#,e,f#,g#,a#,b' Sample code *********** diff --git a/components/sensor/ads1115.rst b/components/sensor/ads1115.rst index 09ef99c54..cc1640bcc 100644 --- a/components/sensor/ads1115.rst +++ b/components/sensor/ads1115.rst @@ -96,8 +96,8 @@ Configuration variables: - **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation. - **resolution** (*Optional*, string): the resolution of this sensor. Defaults to ``16 bits``. - - **16 bits** - - **12 bits** + - ``16 bits`` + - ``12 bits`` Multiplexer and Gain @@ -105,10 +105,10 @@ Multiplexer and Gain .. note:: - As per (`datasheet `__, `Adafruit`_) Section 7.3 Note 2: + As per (`datasheet `__, `Adafruit`_) Section 7.3 Note 2: "No more than VDD + 0.3V must be applied to the analog inputs of the device." This means if you power the device with 3.3V, take care not to supply the 4 AIN pins with more than 3.6V. - + The ADS1115 has a multiplexer that can be configured to measure voltage between several pin configurations. These are: - ``A0_A1`` (between Pin 0 and Pin 1) @@ -128,11 +128,11 @@ Additionally, the ADS1115 has a Programmable Gain Amplifier (PGA) that can help - ``1.024`` (measures up to 1.024V) - ``0.512`` (measures up to 0.512V) - ``0.256`` (measures up to 0.256V) - + The ADS1115 can be used with defaults settings. When using an ADS1015, the resolution has to be specified and should be defined to ``12_BITS`` (or equivalent notations like ``12 BITS`` or ``12 bits``). - + See Also -------- diff --git a/components/sensor/ee895.rst b/components/sensor/ee895.rst index d56db1579..dfb5f2b7d 100644 --- a/components/sensor/ee895.rst +++ b/components/sensor/ee895.rst @@ -36,19 +36,19 @@ The :ref:`I²C Bus ` is required to be set up in your configuration for thi Configuration variables: ------------------------ -- **temperature** (*Required*): The information for the Temperature sensor. +- **temperature** (**Required**): The information for the Temperature sensor. - **name** (**Required**, string): The name for the temperature sensor. - **id** (*Optional*, :ref:`config-id`): Set the ID of this sensor for use in lambdas. - All other options from :ref:`Sensor `. -- **co2** (*Required*): The information for the CO₂ sensor. +- **co2** (**Required**): The information for the CO₂ sensor. - **name** (**Required**, string): The name for the CO₂eq sensor. - **id** (*Optional*, :ref:`config-id`): Set the ID of this sensor for use in lambdas. - All other options from :ref:`Sensor `. -- **Pressure** (*Required*): The information for the Pressure sensor. +- **pressure** (**Required**): The information for the Pressure sensor. - **name** (**Required**, string): The name for the Pressure sensor. - **id** (*Optional*, :ref:`config-id`): Set the ID of this sensor for use in lambdas. diff --git a/components/sensor/hmc5883l.rst b/components/sensor/hmc5883l.rst index c2551acb0..1430b54f9 100644 --- a/components/sensor/hmc5883l.rst +++ b/components/sensor/hmc5883l.rst @@ -26,7 +26,7 @@ for this sensor to work. # Example configuration entry sensor: - platform: hmc5883l - address: 0x68 + address: 0x1E field_strength_x: name: "HMC5883L Field Strength X" field_strength_y: diff --git a/components/sensor/index.rst b/components/sensor/index.rst index 3b15ff77e..3fb874c7e 100644 --- a/components/sensor/index.rst +++ b/components/sensor/index.rst @@ -415,7 +415,7 @@ Configuration variables: ``skip_initial`` **************** -A simple skip filter; `skip_initial: N` skips the first `N` sensor readings and passes on the +A simple skip filter; ``skip_initial: N`` skips the first ``N`` sensor readings and passes on the rest. This can be used when the sensor needs a few readings to 'warm up'. After the initial readings have been skipped, this filter does nothing. diff --git a/components/sensor/internal_temperature.rst b/components/sensor/internal_temperature.rst index 3949346f8..2aca16fab 100644 --- a/components/sensor/internal_temperature.rst +++ b/components/sensor/internal_temperature.rst @@ -12,7 +12,7 @@ temperature sensor of the ESP32 and RP2040 chip. .. note:: Some ESP32 variants return a large amount of invalid temperature - values. Invalid measurements are ignored by this component. + values, including 53.3°C which equates to a raw value of 128. Invalid measurements are ignored by this component. .. figure:: images/internal_temperature-ui.png :align: center diff --git a/components/sensor/kuntze.rst b/components/sensor/kuntze.rst index b4727c693..6bd2372d7 100644 --- a/components/sensor/kuntze.rst +++ b/components/sensor/kuntze.rst @@ -5,7 +5,7 @@ Kuntze pool monitor :description: Instructions for setting up Kuntze pool monitor in ESPHome. :image: kuntze.jpg -The ``kuntze`` component allows you to integrate the Kuntze water measurement +The ``kuntze`` component allows you to integrate the Kuntze water measurement instrument in ESPHome. It uses :ref:`UART ` (ModBUS) for communication. Once configured you can use sensors as described below for your projects. @@ -19,25 +19,25 @@ Once configured you can use sensors as described below for your projects. Overview -------- -Kuntze devices have an RS485 (ModBUS RTU) communication port. Please see the +Kuntze devices have an RS485 (ModBUS RTU) communication port. Please see the Kuntze papers for the pinout of the RS485 connector on your unit. ModBUS line has to be terminated properly (with a ``120Ω`` resistor), and since this is likely your only unit connected to ESPHome, you should activate bus termination in the -Network menu (this component doesn't support multiple Kuntze devices on the same +Network menu (this component doesn't support multiple Kuntze devices on the same bus). ModBUS address should remain at factory default value. -The device communicates at ``19200`` baud ``8E1``. To connect to ESPHome, an RS485 -transceiver is needed. Choose a type which does not need a trigger to send and +The device communicates at ``19200`` baud ``8E1``. To connect to ESPHome, an RS485 +transceiver is needed. Choose a type which does not need a trigger to send and receive data, for example: .. figure:: ../../images/rs485.jpg -The controller connects to the UART of the MCU. For ESP32 GPIO `16` to `TXD` and `17` +The controller connects to the UART of the MCU. For ESP32 GPIO `16` to `TXD` and `17` to RXD are the default ones but any other pins can be used as well. 3.3V to VCC and GND to GND. .. warning:: - If you are using the :ref:`logger` make sure you are not using the same pins for it or otherwise disable the UART + If you are using the :ref:`logger` make sure you are not using the same pins for it or otherwise disable the UART logging with the ``baud_rate: 0`` option. Component @@ -66,14 +66,13 @@ A configured modbus component is optional. It will be automatically created. Configuration variables: -- **ph**: Measured pH value -- **temperature**: Measured temperature value -- **dis1**: Measured DIS 1 value -- **dis2**: Measured DIS 2 value -- **redox**: Measured Redox value -- **ec**: Measured EC value -- **oci**: Measured OCI value - +- **ph** (*Optional*): Measured pH value. +- **temperature** (*Optional*): Measured temperature value. +- **dis1** (*Optional*): Measured DIS 1 value. +- **dis2** (*Optional*): Measured DIS 2 value. +- **redox** (*Optional*): Measured Redox value. +- **ec** (*Optional*): Measured EC value. +- **oci** (*Optional*): Measured OCI value. All sensors are *Optional* and support all other options from :ref:`Sensor `. diff --git a/components/sensor/ld2410.rst b/components/sensor/ld2410.rst index 813ef999b..751388ca2 100644 --- a/components/sensor/ld2410.rst +++ b/components/sensor/ld2410.rst @@ -75,7 +75,7 @@ and binary sensors. Value between ``0.75m`` and ``6m`` inclusive. Defaults to ``4.5m``. - **gX_move_threshold** (*Optional*, int): Threshold for the Xth gate for motion detection (X => 0 to 8). Above this level for the considered gate (distance), movement detection will be triggered. Defaults to ``see table below``. -- **gX _still_threshold** (*Optional*, int): Threshold for the Xth gate for still detection. (X => 0 to 8). +- **gX_still_threshold** (*Optional*, int): Threshold for the Xth gate for still detection. (X => 0 to 8). Above this level for the considered gate (distance), still detection will be triggered. Defaults to ``see table below``. .. list-table:: Default values for gate threshold diff --git a/components/sensor/mics_4514.rst b/components/sensor/mics_4514.rst index 731e89b1c..1fb366c3a 100644 --- a/components/sensor/mics_4514.rst +++ b/components/sensor/mics_4514.rst @@ -6,7 +6,7 @@ MiCS 4514 Gas Sensor :image: mics_4514.jpg :keywords: MiCS, 4514, MICS-4514 -This component exposes the different gas concentration sensors from the `MiCS-4514 `__. +This component exposes the different gas concentration sensors from the `MiCS-4514 `__. This is a differnet sensor than the MICS-4514 being sold on AliExpress. .. note:: diff --git a/components/sensor/scd30.rst b/components/sensor/scd30.rst index c33f622ad..4081d8a14 100644 --- a/components/sensor/scd30.rst +++ b/components/sensor/scd30.rst @@ -6,7 +6,7 @@ SCD30 CO₂, Temperature and Relative Humidity Sensor :image: scd30.jpg The ``scd30`` sensor platform allows you to use your Sensirion SCD30 CO₂ -(`datasheet `__) sensors with ESPHome. +(`datasheet `__) sensors with ESPHome. The :ref:`I²C Bus ` is required to be set up in your configuration for this sensor to work. .. figure:: images/scd30.jpg diff --git a/components/sensor/sdp3x.rst b/components/sensor/sdp3x.rst index 4bbfd7159..8944c1b1b 100644 --- a/components/sensor/sdp3x.rst +++ b/components/sensor/sdp3x.rst @@ -7,8 +7,8 @@ SDP3x / SDP800 Series Differential Pressure Sensor :keywords: SDP3x, SDP31, SDP32, SDP800 Series, SDP810, SDP810 The SDP3x Differential Pressure sensor allows you to use your SDP3x -(`datasheet `__, -`sparkfun `__) or SDP800 Series (`datasheet `__) +(`datasheet `__, +`sparkfun `__) or SDP800 Series (`datasheet `__) sensors with ESPHome. .. figure:: images/sdp31.jpg diff --git a/components/sensor/sht4x.rst b/components/sensor/sht4x.rst index c671f8a01..4cb37c1b2 100644 --- a/components/sensor/sht4x.rst +++ b/components/sensor/sht4x.rst @@ -6,7 +6,7 @@ SHT4X Temperature and Humidity Sensor :image: sht4x.jpg The ``sht4x`` sensor platform allows you to use your SHT4X temperature and humidity sensor -(`datasheet `__, `Adafruit`_) with ESPHome. +(`datasheet `__, `Adafruit`_) with ESPHome. The :ref:`I²C Bus ` is required to be set up in your configuration for this sensor to work. @@ -58,7 +58,7 @@ The heater can be enabled by setting ``heater_max_duty`` up to a maximum duty cy of ``5%`` (``0.05``). This runs the heater on a regular interval. While the heater is in operation the sensor disables measurements so no updates will be published. -See the (`datasheet `__) +See the (`datasheet `__) for more information about heater operation. See Also diff --git a/components/sensor/shtcx.rst b/components/sensor/shtcx.rst index e69b2595e..a5fce79eb 100644 --- a/components/sensor/shtcx.rst +++ b/components/sensor/shtcx.rst @@ -6,10 +6,10 @@ SHTCx Temperature+Humidity Sensors :image: shtc3.jpg The ``shtcx`` sensor platform Temperature+Humidity sensor allows you to use your Sensirion SHTC1 -(`datasheet `__, +(`datasheet `__, `Sensirion STHC1 `__) and the newer SHTC3 -(`datasheet `__, +(`datasheet `__, `SparkFun`_ ) sensors with ESPHome. The :ref:`I²C Bus ` is required to be set up in your configuration for this sensor to work. diff --git a/components/sensor/sps30.rst b/components/sensor/sps30.rst index f80081032..ac085be2c 100644 --- a/components/sensor/sps30.rst +++ b/components/sensor/sps30.rst @@ -6,7 +6,7 @@ SPS30 Particulate Matter Sensor :image: sps30.jpg The ``sps30`` sensor platform allows you to use your Sensirion SPS30 -(`datasheet `__) sensors with ESPHome. +(`datasheet `__) sensors with ESPHome. The :ref:`I²C Bus ` is required to be set up in your configuration for this sensor to work. This sensor supports both UART and I²C communication. However, at the moment only I²C communication is implemented. diff --git a/components/sensor/sts3x.rst b/components/sensor/sts3x.rst index 479760059..b3f1b84be 100644 --- a/components/sensor/sts3x.rst +++ b/components/sensor/sts3x.rst @@ -6,7 +6,7 @@ STS3X Temperature Sensor :image: sts3x.jpg The ``sts3x`` sensor platform Temperature sensor allows you to use your Sensirion STS30-DIS, STS31-DIS or STS35-DIS -(`datasheet `__, +(`datasheet `__, `Sensirion STS3x `__) sensors with ESPHome. The :ref:`I²C Bus ` is required to be set up in your configuration for this sensor to work. diff --git a/components/vbus.rst b/components/vbus.rst index 9cb76c84b..72dd10720 100644 --- a/components/vbus.rst +++ b/components/vbus.rst @@ -176,8 +176,8 @@ All binary sensors are *Optional* and support all other options from :ref:`Binar ``Custom`` VBus sensors ----------------------- -Devices on a VBus are identified with a source address. There can be multiple devices on the same bus, -each device type has a different address. +Devices on a VBus are identified with a source address. There can be multiple devices on the same bus, +each device type has a different address. .. code-block:: yaml @@ -203,7 +203,7 @@ Configuration variables: - **sensors** (**Required**): A list of :ref:`Sensor ` definitions that include a ``lambda`` to do the decoding and return a ``float`` value. - **lambda** (**Required**, :ref:`lambda `): Code to parse a value from the incoming data packets and return it. - The data packet is in a `std::vector` called `x`. + The data packet is in a ``std::vector`` called ``x``. ``custom`` VBus binary sensors @@ -218,7 +218,7 @@ Configuration variables: - **binary_sensors** (**Required**): A list of :ref:`Binary Sensor ` definitions that include a ``lambda`` to do the decoding and return a ``bool`` value. - **lambda** (**Required**, :ref:`lambda `): Code to parse a value from the incoming data packets and return it. - The data packet is in a `std::vector` called `x`. + The data packet is in a ``std::vector`` called ``x``. To determine the correct values for the parameters above, visit `packet definitions list `__. In the search field of the **Packets** table, enter the name of your device. diff --git a/components/voice_assistant.rst b/components/voice_assistant.rst index fd8565833..9349b2f1e 100644 --- a/components/voice_assistant.rst +++ b/components/voice_assistant.rst @@ -5,7 +5,7 @@ Voice Assistant :description: Instructions for setting up a Voice Assistant in ESPHome. :image: voice-assistant.svg -ESPHome devices with a microphone are able to stream the audio to Home Assistant and be processed there by `assist `__. +ESPHome devices with a microphone are able to stream the audio to Home Assistant and be processed there by `assist `__. .. note:: diff --git a/components/web_server.rst b/components/web_server.rst index 4e1e29efe..50fdb638e 100644 --- a/components/web_server.rst +++ b/components/web_server.rst @@ -7,27 +7,26 @@ Web Server Component :keywords: web server, http, REST API The ``web_server`` component creates a simple web server on the node that can be accessed -through any browser and a simple `REST API`_. Please note that enabling this component -will take up *a lot* of memory and can lead to problems, especially on the ESP8266. +through any browser and a simple :ref:`api-rest`. Please note that enabling this component +will take up *a lot* of memory and may decrease stability, especially on ESP8266. + +.. figure:: /components/images/web_server.png + :align: center + :width: 86.0% + + Web server version 1 + + +.. figure:: /components/images/web_server-v2.png + :align: center + :width: 86.0% + + Web server version 2 + To navigate to the web server in your browser, either use the IP address of the node or use ``.local/`` (note the trailing forward slash) via mDNS. -To conserve flash size, the CSS and JS files used on the root page to show a simple user -interface are hosted by esphome.io. If you want to use your own service, use the -``css_url`` and ``js_url`` options in your configuration. - -.. _REST API: /web-api/index.html - -.. figure:: /components/images/web_server.png - - Example web server frontend (Version 1) - -Version 2: ----------- -.. figure:: /components/images/web_server-v2.png - - Web Components (Version 2) .. code-block:: yaml @@ -50,7 +49,7 @@ Configuration variables: - **js_include** (*Optional*, local file): Path to local file to be included in web server index page. Contents of this file will be served as ``/0.js`` and used as JS script by internal webserver. Useful when building device without internet access, where you want to use built-in AP and webserver. -- **auth** (*Optional*): Enables basic authentication with username and password. +- **auth** (*Optional*): Enables a simple *Digest* authentication with username and password. - **username** (**Required**, string): The username to use for authentication. - **password** (**Required**, string): The password to check for authentication. @@ -62,52 +61,53 @@ Configuration variables: - **local** (*Optional*, boolean): Include supporting javascript locally allowing it to work without internet access. Defaults to ``false``. - **version** (*Optional*, string): ``1`` or ``2``. Version 1 displays as a table. Version 2 uses web components and has more functionality. Defaults to ``2``. -.. note:: +To conserve flash size, the CSS and JS files used on the root page to show a simple user +interface are hosted by esphome.io. If you want to use your own service, use the +``css_url`` and ``js_url`` options in your configuration. - Example web_server configuration using HTTP authentication: +Example configurations: +----------------------- - .. code-block:: yaml +Enabling HTTP authentication: - # Example configuration entry - web_server: - port: 80 - auth: - username: admin - password: !secret web_server_password +.. code-block:: yaml - Example web_server configuration using version 1 (previous behaviour): + # Example configuration entry + web_server: + port: 80 + auth: + username: !secret web_server_username + password: !secret web_server_password - .. code-block:: yaml +Use version 1 user interface: - # Example configuration entry - web_server: - port: 80 - version: 1 +.. code-block:: yaml - Example web_server configuration using version 2 - no internet/intranet required: + # Example configuration entry + web_server: + port: 80 + version: 1 - .. code-block:: yaml +No internet/intranet required on the clients (all assets are inlined, compressed and served from flash): - # Example configuration entry - web_server: - local: true +.. code-block:: yaml + + # Example configuration entry + web_server: + local: true - - All of the assets are inlined, compressed and served from flash - -Here be Dragons -=============== +Advanced usage +-------------- The following assume copies of the files with local paths - which are config dependant. -Example web_server version 1 configuration with CSS and JS included from esphome-docs. +Example ``web_server`` version 1 configuration with CSS and JS included from esphome-docs. CSS and JS URL's are set to empty value, so no internet access is needed for this device to show it's web interface. Force to turn off OTA function because the missing authentication. .. code-block:: yaml - # Example configuration entry V1 web_server: port: 80 version: 1 @@ -117,26 +117,26 @@ Force to turn off OTA function because the missing authentication. js_include: "../../../esphome-docs/_static/webserver-v1.min.js" js_url: "" -Example web_server version 2 configuration with JS included from a local file. - +Example ``web_server`` version 2 configuration with JS included from a local file. CSS and JS URL's are set to empty value, so no internet access is needed for this device to show it's web interface. V2 embeds the css within the js file so is not required, however you could include your own CSS. .. code-block:: yaml - # Example configuration entry V2 + # Example configuration entry v2 web_server: js_include: "./v2/www.js" js_url: "" version: 2 - Copy https://oi.esphome.io/v2/www.js to a V2 folder in your yaml folder. See Also -------- +- :ref:`api-event-source` +- :ref:`api-rest` - :apiref:`web_server/web_server.h` - :doc:`prometheus` - :ghedit:`Edit` diff --git a/cookbook/http_request_sensor.rst b/cookbook/http_request_sensor.rst new file mode 100644 index 000000000..86cedeb01 --- /dev/null +++ b/cookbook/http_request_sensor.rst @@ -0,0 +1,121 @@ +Share data directly between ESPHome nodes +========================================= + +In certain special cases it might be desired to avoid placing any middleware like an MQTT or a home automation server just to transfer small bits of data from one node to another. Direct data polling is possibvle using HTTP, but beware that the involved components are resource hungry and may be less stable on long term. The webserver embedded in the node is not designed to constantly serve a large amount of requests. + +The primary node holding the data we need to retrieve from will be the server, and the others polling for it will be the clients (can be multiple). + +Server part +----------- + +Setting up a webserver using the :doc:`/components/web_server` on the primary node will make available the required sensor data through a :ref:`api-rest` interface. + +.. code-block:: yaml + + web_server: + port: 80 + +Client part +----------- + +On the client nodes we need an :doc:`/components/http_request` with an ``id`` set, and a :doc:`/components/sensor/template` to make it accessible locally. + +.. code-block:: yaml + + http_request: + useragent: esphome/device + id: http_request_id + + sensor: + - platform: template + name: "Template sensor on client" + id: template_sensor_id + + +Pulling the data +**************** + +To automate the request for data, we use an :ref:`interval` requesting the URL pointing to the sensor id for which the state is needed. See :ref:`api-rest` on how to build up the URL for your sensors. + +In the example below we request the value of a sensor from the server node, and after parsing the resulted JSON string we publish it to the local template sensor: + +.. code-block:: yaml + + interval: + - interval: 60s + then: + - http_request.get: + url: http://ip or nodename.local/sensor/ID_of_the_sensor + on_response: + then: + - lambda: |- + json::parse_json(id(http_request_id).get_string(), [](JsonObject root) { + id(template_sensor_id).publish_state(root["value"]); + }); + + +Result +------ + +.. figure:: images/server.png + :align: center + :width: 95.0% + + Server side real sensor + + +.. figure:: images/clients.png + :align: center + :width: 95.0% + + Client side template sensor + + +Increasing security +------------------- + +For security reasons, it's always recommended to protect the web interface of the nodes with authentication, even if you're using them on your local network. + +Server part +*********** + +Add authentication to the ``web_server`` component on the primary node: + +.. code-block:: yaml + + web_server: + port: 80 + auth: + username: !secret admin + password: !secret web_server_password + +Client part +*********** + +Add an ``Authorization`` header to your ``http_request.get`` action. The simplest way to determine a working authorization header is to visit the password-protected REST URL of the primary node using a browser while watching the network traffic in the browser's developer tools. If you look at the headers of the request sent by the browser, you'll find the ``Authorization`` header it sends to the node, and you can copy it for your own replay: + +.. code-block:: yaml + + interval: + - interval: 60s + then: + - http_request.get: + url: http://ip or nodename.local/sensor/ID_of_the_sensor + headers: + Authorization: 'Digest username="admin", realm="asyncesp", nonce="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx", uri="/sensor/ID_of_the_sensor", response="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx", opaque="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx", qop=auth, nc=xxxxxxxx, cnonce="xxxxxxxxxxxxxxxx"' + on_response: + then: + - lambda: |- + json::parse_json(id(http_request_id).get_string(), [](JsonObject root) { + id(template_sensor_id).publish_state(root["value"]); + }); + +See Also +-------- + +- :doc:`/components/web_server` +- :doc:`/components/http_request` +- :doc:`/components/sensor/template` +- :ref:`interval` +- :ref:`api-rest` +- :ghedit:`Edit` diff --git a/cookbook/images/clients.png b/cookbook/images/clients.png new file mode 100644 index 000000000..5b96deb84 Binary files /dev/null and b/cookbook/images/clients.png differ diff --git a/cookbook/images/server.png b/cookbook/images/server.png new file mode 100644 index 000000000..93ab1ab0e Binary files /dev/null and b/cookbook/images/server.png differ diff --git a/custom/i2c.rst b/custom/i2c.rst index ce1c30c71..78b68fa2d 100644 --- a/custom/i2c.rst +++ b/custom/i2c.rst @@ -29,6 +29,64 @@ them publish values. } }; + +I²C Write +--------- +It may be useful to write to a register via I²C using a numerical input. For example, the following yaml code snippet captures a user-supplied numerical input in the range 1--255 from the dashboard: + +.. code-block:: yaml + + number: + - platform: template + name: "Input 1" + optimistic: true + min_value: 1 + max_value: 255 + initial_value: 20 + step: 1 + mode: box + id: input_1 + icon: "mdi:counter" + +We want to write this number to a ``REGISTER_ADDRESS`` on the slave device via I²C. The Arduino-based looping code shown above is modified following the guidance in :doc:`Custom Sensor Component `. + +.. code-block:: cpp + + #include "esphome.h" + + const uint16_t I2C_ADDRESS = 0x21; + const uint16_t REGISTER_ADDRESS = 0x78; + const uint16_t POLLING_PERIOD = 15000; //milliseconds + char temp = 20; //Initial value of the register + + class MyCustomComponent : public PollingComponent { + public: + MyCustomComponent() : PollingComponent(POLLING_PERIOD) {} + float get_setup_priority() const override { return esphome::setup_priority::BUS; } //Access I2C bus + + void setup() override { + //Add code here as needed + Wire.begin(); + } + + void update() override { + char register_value = id(input_1).state; //Read the number set on the dashboard + //Did the user change the input? + if(register_value != temp){ + Wire.beginTransmission(I2C_ADDRESS); + Wire.write(REGISTER_ADDRESS); + Wire.write(register_value); + Wire.endTransmission(); + temp = register_value; //Swap in the new value + } + } + }; + +The ``Component`` class has been replaced with ``PollingComponent`` and the free-running ``loop()`` is changed to the ``update()`` method with period set by ``POLLING_PERIOD``. The numerical value from the dashboard is accessed with its ``id`` tag and its state is set to the byte variable that we call ``register_value``. To prevent an I²C write on every iteration, the contents of the register are stored in ``temp`` and checked for a change. Configuring the hardware with ``get_setup_priority()`` is explained in :doc:`Step 1 `. + + + + See Also -------- diff --git a/guides/configuration-types.rst b/guides/configuration-types.rst index a8a0dcc53..cf9661eb7 100644 --- a/guides/configuration-types.rst +++ b/guides/configuration-types.rst @@ -451,6 +451,76 @@ them locally with their own subsitution value. # shorthand form github://username/repository/[folder/]file-path.yml[@branch-or-tag] remote_package_three: github://esphome/non-existant-repo/file1.yml@main +Packages as Templates +********************* + +Since packages are incorporated using the ``!include`` system, +variables can be provided to them. This means that packages can be +used as `templates`, allowing complex or repetitive configurations to +be stored in a package file and then incorporated into the +configuration more than once. + +As an example, if the configuration needed to support three garage +doors using the ``gpio`` switch platform and the ``time_based`` cover +platform, it could be constructed like this: + +.. code-block:: yaml + + # In config.yaml + packages: + left_garage_door: !include + file: garage-door.yaml + vars: + door_name: Left + door_location: left + open_switch_gpio: 25 + close_switch_gpio: 26 + middle_garage_door: !include + file: garage-door.yaml + vars: + door_name: Middle + door_location: middle + open_switch_gpio: 27 + close_switch_gpio: 29 + right_garage_door: !include + file: garage-door.yaml + vars: + door_name: Right + door_location: right + open_switch_gpio: 15 + close_switch_gpio: 18 + + +.. code-block:: yaml + + # In garage-door.yaml + switch: + - id: open_${door_location}_door_switch + name: ${door_name} Garage Door Open Switch + platform: gpio + pin: ${open_switch_gpio} + + - id: close_${door_location}_door_switch + name: ${door_name} Garage Door Close Switch + platform: gpio + pin: ${close_switch_gpio} + + cover: + - platform: time_based + name: ${door_name} Garage Door + + open_action: + - switch.turn_on: open_${door_location}_door_switch + open_duration: 2.1min + + close_action: + - switch.turn_on: close_${door_location}_door_switch + close_duration: 2min + + stop_action: + - switch.turn_off: open_${door_location}_door_switch + - switch.turn_off: close_${door_location}_door_switch + See Also -------- diff --git a/guides/getting_started_command_line.rst b/guides/getting_started_command_line.rst index a58ed5798..da532d7c7 100644 --- a/guides/getting_started_command_line.rst +++ b/guides/getting_started_command_line.rst @@ -40,6 +40,12 @@ If you want to use `docker-compose` instead, here's a sample file: privileged: true network_mode: host +.. note:: + + If you are using NFS share to back your container's config volume, you may + need to mount the volume with the `nolock` option, otherwise platformio may + freeze on container startup as per `platformIO-core Issue 3089 `__ + The project provides multiple docker tags; please pick the one that suits you better: diff --git a/guides/supporters.rst b/guides/supporters.rst index 5437f485d..dafeee1c5 100644 --- a/guides/supporters.rst +++ b/guides/supporters.rst @@ -64,7 +64,7 @@ Contributors - `Alexandre Danault (@AlexDanault) `__ - `Alex Iribarren (@alexiri) `__ - `Alex Mekkering (@AlexMekkering) `__ -- `Alex Yao (@alexyao2015) `__ +- `Alex (@alexyao2015) `__ - `Alfredo (@alfredopironti) `__ - `Andreas Mandel (@amandel) `__ - `Amish Vishwakarma (@amishv) `__ @@ -80,12 +80,12 @@ Contributors - `Andreas Hergert (@andreashergert1984) `__ - `Andrew J.Swan (@andrewjswan) `__ - `andrewpc (@andrewpc) `__ -- `Andrew Y. (@andrey-yantsen) `__ +- `Andrey Yantsen (@andrey-yantsen) `__ - `Andrzej (@andriej) `__ - `Andreas (@anduchs) `__ - `Andy2No (@Andy2No) `__ - `AndyRPH (@AndyRPH) `__ -- `Angel Nunez Mencias (@angelnu) `__ +- `Vegetto (@angelnu) `__ - `Sergey Anisimov (@anisimovsergey) `__ - `Nikolay Vasilchuk (@Anonym-tsk) `__ - `Anthony Keane (@anthonykeane) `__ @@ -111,12 +111,12 @@ Contributors - `Alexander Turlov (@aturlov) `__ - `aus (@aus) `__ - `AustinMorris (@AustinMorris) `__ -- `Denis Demchenko (@Avirsaam) `__ +- `Avirsaam (@Avirsaam) `__ - `Arsène von Wyss (@avonwyss) `__ - `Andrew Weddle (@aweddle2) `__ - `Achilleas Pipinellis (@axilleas) `__ - `Kamil Trzciński (@ayufan) `__ -- `Azimath (@Azimath) `__ +- `Nicholas Peters (@Azimath) `__ - `Daniel (@azrael783) `__ - `B48D81EFCC (@B48D81EFCC) `__ - `Florian Mösch (@badbadc0ffee) `__ @@ -131,7 +131,7 @@ Contributors - `Bascht74 (@Bascht74) `__ - `Viktr (@BbIKTOP) `__ - `J. Nick Koston (@bdraco) `__ -- `Maxym Ocheretianko (@bearpawmaxim) `__ +- `Maxim Ocheretianko (@bearpawmaxim) `__ - `beaudeanadams (@beaudeanadams) `__ - `Benjamin Freeman (@Beetix) `__ - `beikeland (@beikeland) `__ @@ -151,7 +151,7 @@ Contributors - `Ivan Bessarabov (@bessarabov) `__ - `Brandon (@bgulla) `__ - `Benedikt Hübschen (@bhuebschen) `__ -- `Stef (@Bierchermuesli) `__ +- `Bierchermuesli (@Bierchermuesli) `__ - `Bill Church (@billchurch) `__ - `Brian Kaufman (@bkaufx) `__ - `JDavid (@blackhack) `__ @@ -169,7 +169,7 @@ Contributors - `Mauricio Bonani (@bonanitech) `__ - `Casey Olson (@bookcasey) `__ - `Borja Burgos (@borjaburgos) `__ -- `bouhaa (@BoukeHaarsma23) `__ +- `BoukeHaarsma23 (@BoukeHaarsma23) `__ - `brambo123 (@brambo123) `__ - `Bram Kragten (@bramkragten) `__ - `Brandan Cotton (@Brando47) `__ @@ -288,7 +288,7 @@ Contributors - `Daniel Correa Lobato (@dclobato) `__ - `DeadEnd (@DeadEnded) `__ - `Debashish Sahu (@debsahu) `__ -- `Dek Shanaghy (@declanshanaghy) `__ +- `declanshanaghy (@declanshanaghy) `__ - `Maximilian (@DeerMaximum) `__ - `definitio (@definitio) `__ - `Christiaan Blom (@Deinara) `__ @@ -335,7 +335,7 @@ Contributors - `Tom Soer (@dtx3k) `__ - `dubit0 (@dubit0) `__ - `Mikkel Jeppesen (@Duckle29) `__ -- `Sergey Dudanov (@dudanov) `__ +- `Sergey V. DUDANOV (@dudanov) `__ - `David Girón (@duhow) `__ - `Duncan Findlay (@duncf) `__ - `Jannick (@DutchDeffy) `__ @@ -489,7 +489,7 @@ Contributors - `Héctor Giménez (@hectorgimenez) `__ - `Jimmy Hedman (@HeMan) `__ - `Hemi03 (@Hemi03) `__ -- `Andrei Solodovnikov (@HepoH3) `__ +- `HepoH3 (@HepoH3) `__ - `Hermann Kraus (@herm) `__ - `Herr Frei (@herrfrei) `__ - `highground88 (@highground88) `__ @@ -510,7 +510,7 @@ Contributors - `Adrián Panella (@ianchi) `__ - `Ian Anderson (@ianderso) `__ - `Ian Leeder (@ianleeder) `__ -- `Honza Pobořil (@iBobik) `__ +- `Jan Pobořil (@iBobik) `__ - `igg (@igg) `__ - `Ignacio Hernandez-Ros (@IgnacioHR) `__ - `ikatkov (@ikatkov) `__ @@ -606,13 +606,13 @@ Contributors - `Jonathan Treffler (@JonathanTreffler) `__ - `JonnyaiR (@jonnyair) `__ - `Jonathan V (@jonofmac) `__ -- `Joppy Furr (@JoppyFurr) `__ +- `Joppy (@JoppyFurr) `__ - `Jared Sanson (@jorticus) `__ - `Joshua Spence (@joshuaspence) `__ - `joskfg (@joskfg) `__ - `Joscha Wagner (@jowgn) `__ - `Javier Peletier (@jpeletier) `__ -- `Jos Suanet (@jsuanet) `__ +- `jsuanet (@jsuanet) `__ - `James Szalay (@jtszalay) `__ - `Jules-R (@Jules-R) `__ - `Julie Koubová (@juliekoubova) `__ @@ -621,7 +621,7 @@ Contributors - `Justin Gerhardt (@justin-gerhardt) `__ - `Justyn Shull (@justyns) `__ - `Jasper van der Neut - Stulen (@jvanderneutstulen) `__ -- `João Vitor Miranda Roma (@jvmr1) `__ +- `João Vitor M. Roma (@jvmr1) `__ - `Jack Wozny (@jwozny) `__ - `Jozef Zuzelka (@jzlka) `__ - `Kris (@K-r-i-s-t-i-a-n) `__ @@ -656,7 +656,7 @@ Contributors - `Karl Q. (@kquinsland) `__ - `Kodey Converse (@krconv) `__ - `KristopherMackowiak (@KristopherMackowiak) `__ -- `Stefan Rado (@kroimon) `__ +- `kroimon (@kroimon) `__ - `krunkel (@krunkel) `__ - `kryptonitecb3 (@kryptonitecb3) `__ - `Kendell R (@KTibow) `__ @@ -672,7 +672,7 @@ Contributors - `Lawrie George (@lawriege) `__ - `Laszlo Gazdag (@lazlyhu) `__ - `Ludovic BOUÉ (@lboue) `__ -- `Luca Cavalli (@lcavalli) `__ +- `lcavalli (@lcavalli) `__ - `Craig Fletcher (@leakypixel) `__ - `Dominik Wagenknecht (@LeDominik) `__ - `Benny de Leeuw (@leeuwte) `__ @@ -681,7 +681,7 @@ Contributors - `Leon Loopik (@Lewn) `__ - `Luca Gugelmann (@lgugelmann) `__ - `Lubos Horacek (@lhoracek) `__ -- `LiJu09 (@LiJu09) `__ +- `Juraj Liso (@LiJu09) `__ - `lillborje71 (@lillborje71) `__ - `lingex (@lingex) `__ - `Markus (@Links2004) `__ @@ -704,7 +704,7 @@ Contributors - `Ohad Lutzky (@lutzky) `__ - `Luke Fitzgerald (@lwfitzgerald) `__ - `Alex Peters (@Lx) `__ -- `Marius Dinu (@M95D) `__ +- `M95D (@M95D) `__ - `maaadc (@maaadc) `__ - `Marc-Antoine Courteau (@macourteau) `__ - `Massimiliano Ravelli (@madron) `__ @@ -856,7 +856,7 @@ Contributors - `obrain17 (@obrain17) `__ - `Ockert Marais (@OckertM) `__ - `Dave Walker (@oddsockmachine) `__ -- `Andrii Ganzevych (@odya) `__ +- `Andrey Ganzevich (@odya) `__ - `ogatatsu (@ogatatsu) `__ - `Oğuzhan Başer (@oguzhanbaser) `__ - `OkhammahkO (@OkhammahkO) `__ @@ -864,7 +864,7 @@ Contributors - `Ömer Şiar Baysal (@omersiar) `__ - `optimusprimespace (@optimusprimespace) `__ - `Oscar Bolmsten (@oscar-b) `__ -- `Mauri (@Otamay) `__ +- `Otamay (@Otamay) `__ - `Otto Winter (@OttoWinter) `__ - `Maxime Dufour (@outscale-mdr) `__ - `Ben Owen (@owenb321) `__ @@ -935,7 +935,7 @@ Contributors - `Robert Gabrielson (@rgabrielson11) `__ - `Rafael Goes (@rgriffogoes) `__ - `rheinz (@rheinz) `__ -- `Richard Hopton (@richardhopton) `__ +- `richardhopton (@richardhopton) `__ - `Richard Klingler (@richardklingler) `__ - `Richard Lewis (@richrd) `__ - `Andre Borie (@Rjevski) `__ @@ -964,6 +964,7 @@ Contributors - `rwilson131 (@rwilson131) `__ - `Ryan Lang (@ryan-lang) `__ - `ryanalden (@ryanalden) `__ +- `ryansmigley (@ryansmigley) `__ - `Lukas Bachschwell (@s00500) `__ - `Sabesto (@Sabesto) `__ - `Jan Čermák (@sairon) `__ @@ -1024,7 +1025,7 @@ Contributors - `sticilface (@sticilface) `__ - `Stijn Tintel (@stintel) `__ - `Mathias Stock (@Stock-M) `__ -- `Daniel Jönsson (@Strixx76) `__ +- `Strixx76 (@Strixx76) `__ - `stubs12 (@stubs12) `__ - `Jordan Vohwinkel (@sublime93) `__ - `sud33p (@sud33p) `__ @@ -1068,7 +1069,7 @@ Contributors - `Thomas Langewouters (@thouters) `__ - `Transylvania High Tech (@thtro) `__ - `Thunderbiscuits (@Thunderbiscuits) `__ -- `Tiago Freire (@tiagofreire-pt) `__ +- `tiagofreire-pt (@tiagofreire-pt) `__ - `Tijs-B (@Tijs-B) `__ - `Tim Laurence (@timdaman) `__ - `Aidan Timson (@timmo001) `__ @@ -1077,7 +1078,7 @@ Contributors - `Tinkerfish (@tinkerfish) `__ - `TJ Horner (@tjhorner) `__ - `Christian (@Tntdruid) `__ -- `Philipp Riederer (@toelke) `__ +- `Philipp Tölke (@toelke) `__ - `tomaszduda23 (@tomaszduda23) `__ - `Tom Brien (@TomBrien) `__ - `Tom Hartogs (@TomHartogs) `__ @@ -1086,7 +1087,7 @@ Contributors - `Tom Price (@tomtom5152) `__ - `David Kiliani (@torfbolt) `__ - `tracestep (@tracestep) `__ -- `Felix E (@tribut) `__ +- `Felix Eckhofer (@tribut) `__ - `Trick van Staveren (@trickv) `__ - `TripitakaBC (@TripitakaBC) `__ - `Tobias (@tripplet) `__ @@ -1128,7 +1129,7 @@ Contributors - `Ian Wells (@wellsi) `__ - `wifwucite (@wifwucite) `__ - `wilberforce (@wilberforce) `__ -- `Willem Vooijs (@wildekek) `__ +- `wildekek (@wildekek) `__ - `Wingman3434 (@Wingman3434) `__ - `Emil Hesslow (@WizKid) `__ - `WJCarpenter (@wjcarpenter) `__ @@ -1143,7 +1144,7 @@ Contributors - `Mike Brown (@xenoxaos) `__ - `Xose Pérez (@xoseperez) `__ - `WitchKing (@xvil) `__ -- `Yaroslav Heriatovych (@Yarikx) `__ +- `Yaroslav (@Yarikx) `__ - `Marcin Jaworski (@yawor) `__ - `Yuval Aboulafia (@yuvalabou) `__ - `Björn Stenberg (@zagor) `__ @@ -1158,4 +1159,4 @@ Contributors - `Zack Barett (@zsarnett) `__ - `Christian Zufferey (@zuzu59) `__ -*This page was last updated May 24, 2023.* +*This page was last updated May 29, 2023.* diff --git a/index.rst b/index.rst index 6ae7b8168..c302d3520 100644 --- a/index.rst +++ b/index.rst @@ -500,7 +500,7 @@ Output Components BLE Binary Output, components/output/ble_client, bluetooth.svg Modbus Output, components/output/modbus_controller, modbus.png Custom Output, components/output/custom, language-cpp.svg - Sigma-Delta Output, components/output/sigma_delta, sigma-delta.svg + Sigma-Delta Output, components/output/sigma_delta_output, sigma-delta.svg Template Output, components/output/template, description.svg BP1658CJ, components/output/bp1658cj, bp1658cj.svg BP5758D, components/output/bp5758d, bp5758d.svg @@ -848,6 +848,7 @@ Cookbook Sonoff Fishpond Pump, cookbook/sonoff-fishpond-pump, cookbook-sonoff-fishpond-pump.jpg Arduino Port Extender, cookbook/arduino_port_extender, arduino_logo.svg EHMTX a matrix status/text display, cookbook/ehmtx, ehmtx.jpg + Share data directly between ESPHome nodes, cookbook/http_request_sensor, connection.svg Do you have other awesome automations or cool setups? Please feel free to add them to the documentation for others to copy. See :doc:`Contributing `. diff --git a/schema_doc.py b/schema_doc.py index 9dc5869eb..9607ff415 100644 --- a/schema_doc.py +++ b/schema_doc.py @@ -81,6 +81,8 @@ PLATFORMS_TITLES = { "Stepper": "stepper", "Switch": "switch", "I²C": "i2c", + "Media Player": "media_player", + "Microphone": "microphone", } CUSTOM_DOCS = { @@ -196,6 +198,8 @@ CUSTOM_DOCS = { }, } +REQUIRED_OPTIONAL_TYPE_REGEX = r"(\(((\*\*Required\*\*)|(\*Optional\*))(,\s(.*))*)\):\s" + def get_node_title(node): return list(node.traverse(nodes.title))[0].astext() @@ -250,7 +254,6 @@ class SchemaGeneratorVisitor(nodes.NodeVisitor): ] else: # sub component, e.g. output/esp8266_pwm - # components here might have a core / hub, eg. dallas, ads1115 # and then they can be a binary_sensor, sensor, etc. self.platform = self.path[1] @@ -775,7 +778,6 @@ class SchemaGeneratorVisitor(nodes.NodeVisitor): and (self.props or self.multi_component) and self.bullet_list_level > 1 ): - self.prop_stack.append((self.current_prop, node)) self.accept_props = True return @@ -844,7 +846,7 @@ class SchemaGeneratorVisitor(nodes.NodeVisitor): try: name_type = markdown[: markdown.index(": ") + 2] ntr = re.search( - r"(\(((\*\*Required\*\*)|(\*Optional\*))(,\s(.*))*)\):\s", + REQUIRED_OPTIONAL_TYPE_REGEX, name_type, re.IGNORECASE, ) @@ -875,7 +877,6 @@ class SchemaGeneratorVisitor(nodes.NodeVisitor): return markdown def update_prop(self, node, props): - prop_name = None for s_prop, n in self.prop_stack: @@ -901,10 +902,10 @@ class SchemaGeneratorVisitor(nodes.NodeVisitor): found = True if enum_docs: enum_docs = enum_docs.strip() - if "values_docs" not in inner: - inner["values_docs"] = {name: enum_docs} + if inner["values"][name] is None: + inner["values"][name] = {"docs": enum_docs} else: - inner["values_docs"][name] = enum_docs + inner["values"][name]["docs"] = enum_docs statistics.props_documented += 1 statistics.enums_good += 1 if not found: @@ -941,12 +942,19 @@ class SchemaGeneratorVisitor(nodes.NodeVisitor): return prop_name, False # Example properties formats are: - # **name** (**Required**, string): Long Description... - # **name** (*Optional*, string): Long Description... Defaults to ``value``. - # **name** (*Optional*): Long Description... Defaults to ``value``. + # **prop_name** (**Required**, string): Long Description... + # **prop_name** (*Optional*, string): Long Description... Defaults to ``value``. + # **prop_name** (*Optional*): Long Description... Defaults to ``value``. + # **prop_name** can be a list of names separated by / e.g. **name1/name2** (*Optional*) see climate/pid/ threshold_low/threshold_high + + PROP_NAME_REGEX = r"\*\*(\w*(?:/\w*)*)\*\*" + + FULL_ITEM_PROP_NAME_TYPE_REGEX = ( + r"\* " + PROP_NAME_REGEX + r"\s" + REQUIRED_OPTIONAL_TYPE_REGEX + ) ntr = re.search( - r"\* \*\*(\w*)\*\*\s(\(((\*\*Required\*\*)|(\*Optional\*))(,\s(.*))*)\):\s", + FULL_ITEM_PROP_NAME_TYPE_REGEX, name_type, re.IGNORECASE, ) @@ -956,14 +964,14 @@ class SchemaGeneratorVisitor(nodes.NodeVisitor): param_type = ntr.group(7) else: s2 = re.search( - r"\* \*\*(\w*)\*\*\s(\(((\*\*Required\*\*)|(\*Optional\*))(,\s(.*))*)\):\s", + FULL_ITEM_PROP_NAME_TYPE_REGEX, markdown, re.IGNORECASE, ) if s2: # this is e.g. when a property has a list inside, and the list inside are the options. # just validate **prop_name** - s3 = re.search(r"\* \*\*(\w*)\*\*:\s", name_type) + s3 = re.search(r"\* " + PROP_NAME_REGEX + r"*:\s", name_type) if s3 is not None: prop_name = s3.group(1) else: @@ -977,61 +985,61 @@ class SchemaGeneratorVisitor(nodes.NodeVisitor): ) return prop_name, False - k = str(prop_name) + prop_names = str(prop_name) + for k in prop_names.split("/"): + config_var = props.get(k) - config_var = props.get(k) + if not config_var: + # Create docs for common properties when descriptions are overridden + # in the most specific component. - if not config_var: - # Create docs for common properties when descriptions are overridden - # in the most specific component. - - if k in [ - "id", - "name", - "internal", - # i2c - "address", - "i2c_id", - # polling component - "update_interval", - # uart - "uart_id", - # light - "effects", - "gamma_correct", - "default_transition_length", - "flash_transition_length", - "color_correct", - # display - "lambda", - "pages", - "rotation", - # spi - "spi_id", - "cs_pin", - # output (binary/float output) - "inverted", - "power_supply", - # climate - "receiver_id", - ]: - config_var = props[k] = {} - else: - if self.path[1] == "esphome" and k in [ - # deprecated esphome - "platform", - "board", - "arduino_version", - "esp8266_restore_from_flash", + if k in [ + "id", + "name", + "internal", + # i2c + "address", + "i2c_id", + # polling component + "update_interval", + # uart + "uart_id", + # light + "effects", + "gamma_correct", + "default_transition_length", + "flash_transition_length", + "color_correct", + # display + "lambda", + "pages", + "rotation", + # spi + "spi_id", + "cs_pin", + # output (binary/float output) + "inverted", + "power_supply", + # climate + "receiver_id", ]: - return prop_name, True - return prop_name, False + config_var = props[k] = {} + else: + if self.path[1] == "esphome" and k in [ + # deprecated esphome + "platform", + "board", + "arduino_version", + "esp8266_restore_from_flash", + ]: + return prop_name, True + return prop_name, False - desc = markdown[markdown.index(": ") + 2 :].strip() - if param_type: - desc = "**" + param_type + "**: " + desc + desc = markdown[markdown.index(": ") + 2 :].strip() + if param_type: + desc = "**" + param_type + "**: " + desc - config_var["docs"] = desc + config_var["docs"] = desc statistics.props_documented += 1 @@ -1084,7 +1092,11 @@ class SchemaGeneratorVisitor(nodes.NodeVisitor): def _find_extended(self, component, key): for extended in component.get("extends", []): - schema = self.visitor.get_component_schema(extended).get("schema", {}) + c = self.visitor.get_component_schema(extended) + if c.get("type") == "typed": + p = self.visitor.Props(self.visitor, c) + return p[key] + schema = c.get("schema", {}) for k, cv in schema.get("config_vars", {}).items(): if k == key: return SetObservable( @@ -1124,7 +1136,7 @@ class SchemaGeneratorVisitor(nodes.NodeVisitor): ) def _set_typed(self, inner_key, original_dict, key, value): - if inner_key == self.component.get("typed_key"): + if inner_key == self.component.get("typed_key", "type"): self.component[key] = value else: for tk, tv in self.component["types"].items(): diff --git a/web-api/index.rst b/web-api/index.rst index 481ab6c1e..3abe30003 100644 --- a/web-api/index.rst +++ b/web-api/index.rst @@ -24,6 +24,8 @@ While it's currently recommended to use ESPHome directly through Home Assistant, to integrate ESPHome with an external or self-built application you can use two available APIs: the real-time event source API and REST API. +.. _api-event-source: + Event Source API ~~~~~~~~~~~~~~~~ @@ -56,6 +58,8 @@ states so that the client can catch up with reality. The payloads of these state events are also the same as the payloads of the REST API GET calls. I would recommend just opening the network debug panel of your web browser to see what's sent. +.. _api-rest: + REST API -------- @@ -297,3 +301,11 @@ method is ``set``. The following parameter can be used: minimum and maximum range of the number otherwise it will be ignored. For example POST ``/number/desired_delay/set?value=24`` will set the number to 24. + +See Also +-------- + +- :doc:`/components/web_server` +- :doc:`/components/prometheus` +- :doc:`/components/http_request` +- :ghedit:`Edit`