mirror of
https://github.com/esphome/esphome-docs.git
synced 2024-12-26 17:27:47 +01:00
Merge branch 'current' into patch-4
This commit is contained in:
commit
dc68655854
2
Doxygen
2
Doxygen
@ -38,7 +38,7 @@ PROJECT_NAME = "ESPHome"
|
||||
# could be handy for archiving the generated documentation or if some version
|
||||
# control system is used.
|
||||
|
||||
PROJECT_NUMBER = 2022.11.1
|
||||
PROJECT_NUMBER = 2022.11.3
|
||||
|
||||
# Using the PROJECT_BRIEF tag one can provide an optional one line description
|
||||
# for a project that appears at the top of each page and should give viewer a
|
||||
|
2
Makefile
2
Makefile
@ -1,5 +1,5 @@
|
||||
ESPHOME_PATH = ../esphome
|
||||
ESPHOME_REF = 2022.11.1
|
||||
ESPHOME_REF = 2022.11.3
|
||||
|
||||
.PHONY: html html-strict cleanhtml deploy help live-html Makefile netlify netlify-api api netlify-dependencies svg2png copy-svg2png minify
|
||||
|
||||
|
@ -1 +1 @@
|
||||
2022.11.1
|
||||
2022.11.3
|
@ -98,6 +98,22 @@ Release 2022.11.1 - November 17
|
||||
|
||||
- Support ADC on RP2040 :esphomepr:`4040` by :ghuser:`jesserockz`
|
||||
|
||||
Release 2022.11.2 - November 23
|
||||
-------------------------------
|
||||
|
||||
- Fix rp2040 pwm to use pico-sdk, not mbed :esphomepr:`4059` by :ghuser:`jesserockz`
|
||||
- Update web_server index :esphomepr:`4060` by :ghuser:`jesserockz`
|
||||
- rp2040_pwm frequency is per pair of pins :esphomepr:`4061` by :ghuser:`jesserockz`
|
||||
- Avoid 128bit uuid loop for 16/32 bit uuids :esphomepr:`4068` by :ghuser:`bdraco`
|
||||
- Avoid creating a new espbt::ESPBTUUID each loop when registering for notify :esphomepr:`4069` by :ghuser:`bdraco`
|
||||
|
||||
Release 2022.11.3 - November 24
|
||||
-------------------------------
|
||||
|
||||
- fix missing library :esphomepr:`4051` by :ghuser:`ssieb`
|
||||
- Fix units for refresh: never :esphomepr:`4048` by :ghuser:`bkaufx`
|
||||
- Don't convert climate temperature step :esphomepr:`4082` by :ghuser:`jesserockz`
|
||||
|
||||
Full list of changes
|
||||
--------------------
|
||||
|
||||
|
@ -7,7 +7,7 @@ Climate Component
|
||||
|
||||
ESPHome has support for climate devices. Climate devices can represent different types of
|
||||
hardware, but the defining factor is that climate devices have a settable target temperature
|
||||
and can be put in different modes like HEAT, COOL, HEAT_COOL or OFF.
|
||||
and can be put in different modes like ``HEAT``, ``COOL``, ``HEAT_COOL`` or ``OFF``.
|
||||
|
||||
.. figure:: images/climate-ui.png
|
||||
:align: center
|
||||
@ -58,42 +58,6 @@ Advanced options:
|
||||
for a list of available options. Requires Home Assistant 2021.11 or newer.
|
||||
Set to ``""`` to remove the default entity category.
|
||||
|
||||
MQTT options:
|
||||
|
||||
- **action_state_topic** (*Optional*, string): The topic to publish
|
||||
climate device action changes to.
|
||||
- **away_state_topic** (*Optional*, string): The topic to publish
|
||||
away mode changes on.
|
||||
- **away_command_topic** (*Optional*, string): The topic to receive
|
||||
away mode commands on.
|
||||
- **current_temperature_state_topic** (*Optional*, string): The topic to publish
|
||||
current temperature changes to.
|
||||
- **fan_mode_state_topic** (*Optional*, string): The topic to publish
|
||||
fan mode changes to.
|
||||
- **fan_mode_command_topic** (*Optional*, string): The topic to receive
|
||||
fan mode commands on.
|
||||
- **mode_state_topic** (*Optional*, string): The topic to publish
|
||||
climate device mode changes to.
|
||||
- **mode_command_topic** (*Optional*, string): The topic to receive
|
||||
climate device mode commands on.
|
||||
- **swing_mode_state_topic** (*Optional*, string): The topic to publish
|
||||
swing mode changes to.
|
||||
- **swing_mode_command_topic** (*Optional*, string): The topic to receive
|
||||
swing mode commands on.
|
||||
- **target_temperature_state_topic** (*Optional*, string): The topic to publish
|
||||
target temperature changes to.
|
||||
- **target_temperature_command_topic** (*Optional*, string): The topic to receive
|
||||
target temperature commands on.
|
||||
- **target_temperature_high_state_topic** (*Optional*, string): The topic to publish
|
||||
higher target temperature changes to.
|
||||
- **target_temperature_high_command_topic** (*Optional*, string): The topic to receive
|
||||
higher target temperature commands on.
|
||||
- **target_temperature_low_state_topic** (*Optional*, string): The topic to publish
|
||||
lower target temperature changes to.
|
||||
- **target_temperature_low_command_topic** (*Optional*, string): The topic to receive
|
||||
lower target temperature commands on.
|
||||
- All other options from :ref:`MQTT Component <config-mqtt-component>`.
|
||||
|
||||
Climate Automation
|
||||
------------------
|
||||
|
||||
@ -189,7 +153,7 @@ advanced stuff.
|
||||
.. _climate-on_state_trigger:
|
||||
|
||||
``climate.on_state`` Trigger
|
||||
******************************************************
|
||||
****************************
|
||||
|
||||
This trigger is activated each time the state of the climate device is updated
|
||||
(for example, if the current temperature measurement or the mode set by the users changes).
|
||||
@ -202,6 +166,43 @@ This trigger is activated each time the state of the climate device is updated
|
||||
on_state:
|
||||
- logger.log: "State updated!"
|
||||
|
||||
MQTT options:
|
||||
|
||||
- **action_state_topic** (*Optional*, string): The topic to publish
|
||||
climate device action changes to.
|
||||
- **away_state_topic** (*Optional*, string): The topic to publish
|
||||
away mode changes on.
|
||||
- **away_command_topic** (*Optional*, string): The topic to receive
|
||||
away mode commands on.
|
||||
- **current_temperature_state_topic** (*Optional*, string): The topic to publish
|
||||
current temperature changes to.
|
||||
- **fan_mode_state_topic** (*Optional*, string): The topic to publish
|
||||
fan mode changes to.
|
||||
- **fan_mode_command_topic** (*Optional*, string): The topic to receive
|
||||
fan mode commands on.
|
||||
- **mode_state_topic** (*Optional*, string): The topic to publish
|
||||
climate device mode changes to.
|
||||
- **mode_command_topic** (*Optional*, string): The topic to receive
|
||||
climate device mode commands on.
|
||||
- **swing_mode_state_topic** (*Optional*, string): The topic to publish
|
||||
swing mode changes to.
|
||||
- **swing_mode_command_topic** (*Optional*, string): The topic to receive
|
||||
swing mode commands on.
|
||||
- **target_temperature_state_topic** (*Optional*, string): The topic to publish
|
||||
target temperature changes to.
|
||||
- **target_temperature_command_topic** (*Optional*, string): The topic to receive
|
||||
target temperature commands on.
|
||||
- **target_temperature_high_state_topic** (*Optional*, string): The topic to publish
|
||||
higher target temperature changes to.
|
||||
- **target_temperature_high_command_topic** (*Optional*, string): The topic to receive
|
||||
higher target temperature commands on.
|
||||
- **target_temperature_low_state_topic** (*Optional*, string): The topic to publish
|
||||
lower target temperature changes to.
|
||||
- **target_temperature_low_command_topic** (*Optional*, string): The topic to receive
|
||||
lower target temperature commands on.
|
||||
- All other options from :ref:`MQTT Component <config-mqtt-component>`.
|
||||
|
||||
|
||||
See Also
|
||||
--------
|
||||
|
||||
|
@ -6,10 +6,10 @@ Thermostat Climate Controller
|
||||
:image: air-conditioner.svg
|
||||
|
||||
The ``thermostat`` climate platform allows you to control a climate control system in much the same manner as a
|
||||
physical thermostat. Its operation is similar to the :doc:`bang-bang <bang_bang>` controller; a sensor measures a value
|
||||
physical thermostat. Its operation is similar to the :doc:`Bang-Bang <bang_bang>` controller; a sensor measures a value
|
||||
(the air temperature) and the controller will try to keep this value within a range defined by the set point(s). To do this,
|
||||
the controller can activate devices like a heating unit and/or a cooling unit to change the value observed by the sensor.
|
||||
When configured for both heating and cooling, it is essentially two :doc:`bang-bang <bang_bang>` controllers in one; it
|
||||
When configured for both heating and cooling, it is essentially two :doc:`Bang-Bang <bang_bang>` controllers in one; it
|
||||
differs, however, in that interaction with the thermostat component is nearly identical to that of a real thermostat.
|
||||
|
||||
This component can operate in one of two ways:
|
||||
@ -169,45 +169,6 @@ The thermostat controller uses the sensor to determine whether it should heat or
|
||||
|
||||
- **sensor** (**Required**, :ref:`config-id`): The sensor that is used to measure the current temperature.
|
||||
|
||||
Default Target Temperatures and Mode
|
||||
************************************
|
||||
|
||||
These configuration items determine default values the thermostat controller should use when it starts.
|
||||
|
||||
- **default_mode** (*Optional*, *Deprecated*, climate mode): The default climate mode the controller should
|
||||
use if it is unable to restore it from memory. One of:
|
||||
|
||||
- ``off`` (default)
|
||||
- ``heat_cool``
|
||||
- ``cool``
|
||||
- ``heat``
|
||||
- ``dry``
|
||||
- ``fan_only``
|
||||
- ``auto``
|
||||
|
||||
This value is used the first time your device starts after ESPHome is initially installed onto it. Add
|
||||
this option into your configuration if you want your thermostat component to start in a climate mode other
|
||||
than ``off``. If this option is not configured, you'll need to manually change the climate mode later via
|
||||
the front end (Home Assistant), an ESPHome action, automation, or from within a lambda elsewhere in your
|
||||
device's configuration.
|
||||
|
||||
- **default_target_temperature_low** (*Optional*, float): The default low target
|
||||
temperature for the control algorithm. This can be dynamically set in the frontend later.
|
||||
- **default_target_temperature_high** (*Optional*, float): The default high target
|
||||
temperature for the control algorithm. This can be dynamically set in the frontend later.
|
||||
|
||||
**At least one of** ``default_target_temperature_low`` **and** ``default_target_temperature_high``
|
||||
**must be specified.**
|
||||
|
||||
.. note::
|
||||
|
||||
**default_mode**, **default_target_temperature_low**, and **default_target_temperature_high** are
|
||||
being removed in a future release. In the future you will need to migrate your configuration to using
|
||||
a :ref:`preset <thermostat-preset>` which will allow for more flexibility and customisation
|
||||
|
||||
Note that ``min_temperature`` and ``max_temperature`` from the base climate component are used to define
|
||||
the range of allowed temperature values in the thermostat component. See :doc:`/components/climate/index`.
|
||||
|
||||
Heating and Cooling Actions
|
||||
***************************
|
||||
|
||||
@ -527,6 +488,9 @@ Additional Actions/Behavior
|
||||
- **min_fan_mode_switching_time** (*Required with any* ``fan_mode`` *action*, :ref:`config-time`): Minimum duration
|
||||
any given fan mode must be active before it may be changed.
|
||||
|
||||
Note that ``min_temperature`` and ``max_temperature`` from the base climate component are used to define
|
||||
the range of allowed temperature values in the thermostat component. See :doc:`/components/climate/index`.
|
||||
|
||||
Hysteresis Values
|
||||
*****************
|
||||
|
||||
@ -547,15 +511,16 @@ Hysteresis Values
|
||||
adjustability and the defaults will probably not make sense for control of things like humidity. See
|
||||
:doc:`/components/climate/index`.
|
||||
|
||||
Bang-bang vs. Thermostat
|
||||
Bang-Bang vs. Thermostat
|
||||
------------------------
|
||||
|
||||
Please see the :doc:`Bang-bang <bang_bang>` component's documentation for a detailed comparison of these two components.
|
||||
Please see the :doc:`Bang-Bang <bang_bang>` component's documentation for a detailed comparison of these two components.
|
||||
|
||||
See Also
|
||||
--------
|
||||
|
||||
- :doc:`/components/climate/index`
|
||||
- :doc:`/components/sensor/index`
|
||||
- :doc:`Bang-Bang <bang_bang>`
|
||||
- :ref:`config-action`
|
||||
- :ghedit:`Edit`
|
||||
|
@ -7,7 +7,7 @@ Debug Component
|
||||
|
||||
The ``debug`` component can be used to debug problems with ESPHome. At startup, it prints
|
||||
a bunch of useful information like reset reason, free heap size, ESPHome version and so on.
|
||||
It also allows you get the same information as a text sensor, and to monitor the state of the
|
||||
It also allows you to get the same information as a text sensor, and to monitor the state of the
|
||||
ESP heap memory (free space, maximum free block size and fragmentation level) and the main-loop timing.
|
||||
|
||||
.. figure:: images/debug.png
|
||||
|
@ -5,7 +5,7 @@ Shelly Dimmer
|
||||
:description: Instructions for setting up a Shelly Dimmer 2.
|
||||
:image: shellydimmer2.jpg
|
||||
|
||||
The ``shelly_dimmer`` component adds support for the dimming and power-metering functionality that can be found the `Shelly Dimmer 2 <https://shelly.cloud/knowledge-base/devices/shelly-dimmer-2/>`_. The interaction with mains is done via an STM32 microcontroller that is flashed with an `open source firmware <https://github.com/jamesturton/shelly-dimmer-stm32>`_.
|
||||
The ``shelly_dimmer`` component adds support for the dimming and power-metering functionality that can be found the `Shelly Dimmer 2 <https://shelly.cloud/knowledge-base/devices/shelly-dimmer-2/>`_. The interaction with mains is done via an STM32 microcontroller that is automatically (when configured) flashed with an `open source firmware <https://github.com/jamesturton/shelly-dimmer-stm32>`_.
|
||||
A detailed analysis of the Shelly Dimmer 2 hardware is given `here <https://github.com/arendst/Tasmota/issues/6914>`_.
|
||||
|
||||
Warning!!! At the time of writing there seems to be no way to revert back to the "stock firmware", because there seems to be no way to revert to firmware of the STM32 co-processor.
|
||||
@ -84,7 +84,7 @@ Configuration variables:
|
||||
|
||||
.. note::
|
||||
|
||||
When flashing Shelly Dimmer with esphome for the first time, flashing the STM firmware is necessary too for the dimmer to work:
|
||||
When flashing Shelly Dimmer with esphome for the first time, automatic flashing the STM firmware is necessary too for the dimmer to work and enabled by the following configuration.:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
@ -92,6 +92,7 @@ Configuration variables:
|
||||
version: "51.6" #<-- set version here
|
||||
update: true
|
||||
|
||||
There is no action required by the user to flash the STM32. There is no way to revert to stock firmware on the STM32 at the time of writing.
|
||||
|
||||
- All other options from :ref:`Light <config-light>`.
|
||||
|
||||
|
@ -152,7 +152,7 @@ From :ref:`lambdas <config-lambda>`, you can interact with the sensor in various
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
id(ph_ezo).set_calibration_point_low(10.00);
|
||||
id(ph_ezo).set_calibration_point_high(10.00);
|
||||
|
||||
|
||||
- ``clear_calibration()``: Clears all calibration points.
|
||||
|
2
conf.py
2
conf.py
@ -69,7 +69,7 @@ author = "ESPHome"
|
||||
# The short X.Y version.
|
||||
version = "2022.11"
|
||||
# The full version, including alpha/beta/rc tags.
|
||||
release = "2022.11.1"
|
||||
release = "2022.11.3"
|
||||
|
||||
# The language for content autogenerated by Sphinx. Refer to documentation
|
||||
# for a list of supported languages.
|
||||
|
@ -385,7 +385,7 @@ And a docker compose file looks like this:
|
||||
|
||||
Notes on disabling mDNS
|
||||
------------------------------------------------------------------------------
|
||||
Some of ESPHome's functionalities rely on mDNS, so naturally :ref:`disabling <wifi-configuration_variables>` it will cause these features to stop working.
|
||||
Some of ESPHome's functionalities rely on mDNS, so naturally :doc:`disabling </components/mdns>` it will cause these features to stop working.
|
||||
Generally speaking, disabling mDNS without setting a :ref:`static IP address <wifi-manual_ip>` (or a static DHCP lease) is bound to cause problems. This is due to the fact that mDNS is used to find the IP address of each ESPHome nodes.
|
||||
|
||||
- You will not be able to use the node's hostname to ping, find it's IP address or connect to it.
|
||||
|
@ -76,6 +76,10 @@ The configuration files for ESPHome can be found and edited under ``<HOME_ASSIST
|
||||
For example the configuration for the ``garage-door`` node in the picture above can be found
|
||||
in ``/config/esphome/garage-door.yaml``.
|
||||
|
||||
.. note::
|
||||
|
||||
Since Home Assistant add-ons run as indvidual containers, accessing these through command line is not very straightforward, but it's possible. To do that, install Home Assistant's SSH addon, configure a username and a password, and disable `Protection Mode` (please assess the risks you take with that). Then, for example to access the logs form a device through an SSH client, log in, and you can use a command like `docker exec -it addon_15ef4d2f_esphome esphome logs /config/esphome/garage-door.yaml`. See :doc:`getting_started_command_line` for more.
|
||||
|
||||
Now go ahead and use one of the :ref:`devices guides <devices>` to extend your configuration.
|
||||
|
||||
Adding some (basic) features
|
||||
|
@ -230,7 +230,6 @@ Contributors
|
||||
- `Destix (@Destix) <https://github.com/Destix>`__
|
||||
- `Develo (@devyte) <https://github.com/devyte>`__
|
||||
- `Dezorian (@Dezorian) <https://github.com/Dezorian>`__
|
||||
- `dgtal1 (@dgtal1) <https://github.com/dgtal1>`__
|
||||
- `Dan Halbert (@dhalbert) <https://github.com/dhalbert>`__
|
||||
- `Alain Turbide (@Dilbert66) <https://github.com/Dilbert66>`__
|
||||
- `Mark (@Diramu) <https://github.com/Diramu>`__
|
||||
@ -898,4 +897,4 @@ Contributors
|
||||
- `Zack Barett (@zsarnett) <https://github.com/zsarnett>`__
|
||||
- `Christian Zufferey (@zuzu59) <https://github.com/zuzu59>`__
|
||||
|
||||
*This page was last updated November 17, 2022.*
|
||||
*This page was last updated November 24, 2022.*
|
||||
|
Loading…
Reference in New Issue
Block a user