Merge 58f283f6ae into 696a828156
This commit is contained in:
Keith Burzinski
GitHub
commit
58ae960d90
|
|
@ -1,88 +1,79 @@
|
||||||
OTA Update Component
|
ESPHome OTA Updates
|
||||||
====================
|
===================
|
||||||
|
|
||||||
.. seo::
|
.. seo::
|
||||||
:description: Instructions for setting up Over-The-Air (OTA) updates for ESPs to upload firmwares remotely.
|
:description: Instructions for setting up ESPHome's Over-The-Air (OTA) platform to allow remote updating of devices.
|
||||||
:image: system-update.svg
|
:image: system-update.svg
|
||||||
|
|
||||||
.. _config-ota:
|
.. _config-ota:
|
||||||
|
|
||||||
With the OTA (Over The Air) update component you can upload your
|
ESPHome's Over-The-Air (OTA) platform allows you to remotely install modified/updated firmware binaries onto your
|
||||||
firmware binaries to your node without having to use a USB cable for
|
ESPHome devices over their network (Wi-Fi or Ethernet) interface.
|
||||||
uploads. ESPHome natively supports this through its ``run`` and
|
|
||||||
``upload`` helper scripts.
|
|
||||||
|
|
||||||
ESPHome also has an "OTA safe mode". If for some reason your
|
This platform is used by both the ESPHome dashboard as well as the command line interface (CLI) (via
|
||||||
node gets into a boot loop, ESPHome will automatically try to detect
|
``esphome run ...``) to install firmware onto supported devices.
|
||||||
this and will go over into a safe mode after the configured unsuccessful boot
|
|
||||||
attempts (Defaults to ``10``). In that mode, all components are disabled and only Serial
|
|
||||||
Logging + Network(WiFi or Ethernet) + OTA are initialized, so that you can upload a new
|
|
||||||
binary. You can trigger entering safe mode by either configuring a dedicated button or
|
|
||||||
switch to do that or by pressing the reset button on the board for ``num_attempts`` times.
|
|
||||||
|
|
||||||
|
In addition to updates, ESPHome also supports a "safe mode" to help recover from boot failures/reboot loops. After a
|
||||||
|
specified number (the default is ten) of boot failures, the safe mode may be invoked; in this mode, all components are
|
||||||
|
disabled except serial logging, network (Wi-Fi or Ethernet) and the OTA component, allowing you to attempt to upload a
|
||||||
|
new binary. You can also force the invocation of safe mode by configuring a dedicated
|
||||||
|
:doc:`button</components/button/safe_mode>` or :doc:`switch</components/switch/safe_mode>` component and/or by pressing
|
||||||
|
the reset button on the board for ``num_attempts`` times (see below).
|
||||||
|
|
||||||
.. code-block:: yaml
|
.. code-block:: yaml
|
||||||
|
|
||||||
# Example configuration entry
|
# Example configuration entry
|
||||||
ota:
|
ota:
|
||||||
safe_mode: true
|
- platform: esphome
|
||||||
password: !secret ota_password
|
safe_mode: true
|
||||||
|
password: !secret ota_password
|
||||||
|
|
||||||
Configuration variables:
|
Configuration variables:
|
||||||
------------------------
|
------------------------
|
||||||
|
|
||||||
- **safe_mode** (*Optional*, boolean): Whether to enable safe mode.
|
- **safe_mode** (*Optional*, boolean): Whether to enable safe mode. Defaults to ``true``.
|
||||||
Defaults to ``true``.
|
|
||||||
- **password** (*Optional*, string): The password to use for updates.
|
- **password** (*Optional*, string): The password to use for updates.
|
||||||
- **port** (*Optional*, int): The port to use for OTA updates.
|
- **port** (*Optional*, int): The port to use for OTA updates. Defaults:
|
||||||
Defaults:
|
|
||||||
|
|
||||||
- ``3232`` for the ESP32
|
- ``3232`` for the ESP32
|
||||||
- ``8266`` for the ESP8266
|
- ``8266`` for the ESP8266
|
||||||
- ``2040`` for the RP2040
|
- ``2040`` for the RP2040
|
||||||
|
|
||||||
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
|
- **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
|
||||||
- **reboot_timeout** (*Optional*, :ref:`config-time`): The amount of time to wait before rebooting when in
|
- **reboot_timeout** (*Optional*, :ref:`config-time`): The amount of time to wait before rebooting when in safe mode.
|
||||||
safe mode. Defaults to ``5min``.
|
Defaults to ``5min``.
|
||||||
- **num_attempts** (*Optional*, int): The number of attempts to wait before entering safe mode. Defaults to ``10``.
|
- **num_attempts** (*Optional*, int): The number of failed boot attempts which must occur before invoking safe mode.
|
||||||
- **on_begin** (*Optional*, :ref:`Automation<automation>`): An action to be
|
Defaults to ``10``.
|
||||||
performed when an OTA update is started. See :ref:`ota-on_begin`.
|
- **on_begin** (*Optional*, :ref:`Automation<automation>`): An action to be performed when an OTA update is started.
|
||||||
- **on_progress** (*Optional*, :ref:`Automation<automation>`): An action to be
|
See :ref:`ota-on_begin`.
|
||||||
performed (multiple times) during an OTA update. See :ref:`ota-on_progress`.
|
- **on_progress** (*Optional*, :ref:`Automation<automation>`): An action to be performed (approximately each second)
|
||||||
- **on_end** (*Optional*, :ref:`Automation<automation>`): An action to be
|
while an OTA update is in progress. See :ref:`ota-on_progress`.
|
||||||
performed after a successful OTA update. See :ref:`ota-on_end`.
|
- **on_end** (*Optional*, :ref:`Automation<automation>`): An action to be performed after a successful OTA update.
|
||||||
- **on_error** (*Optional*, :ref:`Automation<automation>`): An action to be
|
See :ref:`ota-on_end`.
|
||||||
performed after a failed OTA update. See :ref:`ota-on_error`.
|
- **on_error** (*Optional*, :ref:`Automation<automation>`): An action to be performed after a failed OTA update.
|
||||||
- **on_state_change** (*Optional*, :ref:`Automation<automation>`): An action to be
|
See :ref:`ota-on_error`.
|
||||||
performed when an OTA update state change happens. See :ref:`ota-on_state_change`.
|
- **on_state_change** (*Optional*, :ref:`Automation<automation>`): An action to be performed when an OTA update state
|
||||||
- **version** (*Optional*, int): Version of OTA protocol to use. Version 2 is more stable.
|
change happens. See :ref:`ota-on_state_change`.
|
||||||
To downgrade to legacy ESPHome, the device should be updated with OTA version 1 first.
|
- **version** (*Optional*, int): Version of OTA protocol to use. Version 2 is more stable. To downgrade to legacy
|
||||||
Defaults to ``2``.
|
ESPHome, the device should be updated with OTA version 1 first. Defaults to ``2``.
|
||||||
|
|
||||||
.. note::
|
.. note::
|
||||||
|
|
||||||
Please be aware that ESP8266 modules must be reset after a serial
|
After a serial upload, ESP8266 modules must be reset before OTA updates will work. If you attempt to perform an OTA
|
||||||
upload before OTA can work.
|
update and receive the error message ``Bad Answer: ERR: ERROR[11]: Invalid bootstrapping``, the ESP module/board
|
||||||
When you are trying to conduct an OTA update and receive an error message
|
must be power-cycled.
|
||||||
``Bad Answer: ERR: ERROR[11]: Invalid bootstrapping`` the reason is
|
|
||||||
very likely that power-cycling the ESP module is required once after
|
|
||||||
the serial upload.
|
|
||||||
|
|
||||||
OTA Automation
|
OTA Automations
|
||||||
--------------
|
---------------
|
||||||
|
|
||||||
The OTA component provides various automations that can be used to provide feedback
|
The OTA component provides various automations that can be used to provide feedback during the OTA update process.
|
||||||
during an OTA update. There are a few things to consider when making use of the
|
When using these automation triggers, note that:
|
||||||
provided automation triggers:
|
|
||||||
|
|
||||||
- An OTA update blocks the main loop during its operation. This means that you
|
- OTA updates block the main application loop while in progress. You won't be able to represent state changes using
|
||||||
won't be able to represent state changes using components that update their
|
components that update their output only from within their ``loop()`` method. Explained differently: if you try to
|
||||||
output only from within their ``loop()`` method. Explained differently: if you
|
display the OTA progress using component X, but the update only appears after the OTA update finished, then component
|
||||||
try to display the OTA progress using component X, but the update only appears
|
X cannot be used for providing OTA update feedback.
|
||||||
after the OTA update finished, then component X cannot be used for providing
|
- Your automation action(s) must not consume any significant amount of time; if they do, OTA updates may fail.
|
||||||
OTA update feedback.
|
|
||||||
|
|
||||||
- Make sure that your automation actions do not take too much time, to prevent
|
|
||||||
them from blocking the OTA update code for too long.
|
|
||||||
|
|
||||||
.. _ota-on_begin:
|
.. _ota-on_begin:
|
||||||
|
|
||||||
|
|
@ -103,9 +94,8 @@ This automation will be triggered when an OTA update is started.
|
||||||
``on_progress``
|
``on_progress``
|
||||||
***************
|
***************
|
||||||
|
|
||||||
Using this automation, it is possible to report on the OTA update progress.
|
Using this automation, it is possible to report on the OTA update progress. It will be triggered repeatedly during the
|
||||||
It will be triggered multiple times during the OTA update. You can get the actual
|
OTA update. You can get the actual progress percentage (a value between 0 and 100) from the trigger with variable ``x``.
|
||||||
progress percentage (a value between 0 and 100) from the trigger with variable ``x``.
|
|
||||||
|
|
||||||
.. code-block:: yaml
|
.. code-block:: yaml
|
||||||
|
|
||||||
|
|
@ -121,13 +111,12 @@ progress percentage (a value between 0 and 100) from the trigger with variable `
|
||||||
``on_end``
|
``on_end``
|
||||||
**********
|
**********
|
||||||
|
|
||||||
This automation will be triggered when an OTA update has completed successfully,
|
This automation will be triggered when an OTA update has completed successfully, immediately before the device is
|
||||||
right before the device is rebooted.
|
rebooted.
|
||||||
|
|
||||||
Because the update has completed, you can safely use an automation action that
|
Because the update has completed, you can safely use (an) automation action(s) that takes some time to complete. If,
|
||||||
takes some time to complete. This can for example be useful if you want to flash
|
for example, you want to flash an LED, multiple pauses/delays would be required to make the LED blink a few times,
|
||||||
a LED or so, in which case a pause would be required to make the LED light up
|
before the reboot. The OTA update can't fail at this point because it is already complete.
|
||||||
for long enough, before the reboot turns it off.
|
|
||||||
|
|
||||||
.. code-block:: yaml
|
.. code-block:: yaml
|
||||||
|
|
||||||
|
|
@ -141,11 +130,10 @@ for long enough, before the reboot turns it off.
|
||||||
``on_error``
|
``on_error``
|
||||||
************
|
************
|
||||||
|
|
||||||
This automation will be triggered when an OTA update has failed. You can get
|
This automation will be triggered when an OTA update has failed. You can get the internal error code with variable ``x``.
|
||||||
the internal error code with variable ``x``.
|
|
||||||
|
|
||||||
Just like for :ref:`ota-on_end`, you can safely use an automation that
|
Just like for :ref:`ota-on_end`, you can safely use an automation that takes some time to complete as the OTA update
|
||||||
takes some time to complete, because the OTA update is no longer busy.
|
process has already finished.
|
||||||
|
|
||||||
.. code-block:: yaml
|
.. code-block:: yaml
|
||||||
|
|
||||||
|
|
@ -161,12 +149,11 @@ takes some time to complete, because the OTA update is no longer busy.
|
||||||
``on_state_change``
|
``on_state_change``
|
||||||
*******************
|
*******************
|
||||||
|
|
||||||
This automation will be triggered on every state change. You can get the actual
|
This automation will be triggered on every state change. You can get the actual state with variable ``state``, which
|
||||||
state with variable ``state``, which will contain one of values for the OTAState
|
will contain one of values for the ``OTAState`` enum. These values are:
|
||||||
enum. These values are:
|
|
||||||
|
|
||||||
- ``ota::OTA_STARTED``
|
- ``ota::OTA_STARTED``
|
||||||
- ``ota::OTA_IN_PROGRESS`` (will be called multiple times during the update)
|
- ``ota::OTA_IN_PROGRESS`` *(will be called repeatedly during the update)*
|
||||||
- ``ota::OTA_COMPLETED``
|
- ``ota::OTA_COMPLETED``
|
||||||
- ``ota::OTA_ERROR``
|
- ``ota::OTA_ERROR``
|
||||||
|
|
||||||
|
|
@ -181,15 +168,14 @@ enum. These values are:
|
||||||
then:
|
then:
|
||||||
- logger.log: "OTA start"
|
- logger.log: "OTA start"
|
||||||
|
|
||||||
Updating the password:
|
Updating the Password
|
||||||
----------------------
|
---------------------
|
||||||
|
|
||||||
Changing an existing password:
|
Changing an Existing Password
|
||||||
******************************
|
*****************************
|
||||||
|
|
||||||
Since the password is used both for compiling and uploading the regular ``esphome <file> run``
|
Since the configured password is used for both compiling and uploading, the regular ``esphome run <file>`` command
|
||||||
won't work of course. This issue can be worked around by executing the operations separately
|
won't work. This issue can be worked around by executing the operations separately with an ``on_boot`` trigger:
|
||||||
through an ``on_boot`` trigger:
|
|
||||||
|
|
||||||
.. code-block:: yaml
|
.. code-block:: yaml
|
||||||
|
|
||||||
|
|
@ -197,15 +183,19 @@ through an ``on_boot`` trigger:
|
||||||
on_boot:
|
on_boot:
|
||||||
- lambda: |-
|
- lambda: |-
|
||||||
id(my_ota).set_auth_password("New password");
|
id(my_ota).set_auth_password("New password");
|
||||||
|
|
||||||
ota:
|
ota:
|
||||||
password: "Old password"
|
- platform: esphome
|
||||||
id: my_ota
|
id: my_ota
|
||||||
|
password: "Old password"
|
||||||
|
|
||||||
Adding a password:
|
After this trick has been used to change the password, the ``on_boot`` trigger may be removed and the old password
|
||||||
******************
|
replaced with the new password in the ``ota:`` section.
|
||||||
|
|
||||||
If OTA is already enabled without a password, simply add a ``password:`` line to the existing
|
Adding a Password
|
||||||
``ota:`` config block.
|
*****************
|
||||||
|
|
||||||
|
If OTA is already enabled without a password, simply add a ``password:`` line to the existing ``ota:`` config block.
|
||||||
|
|
||||||
See Also
|
See Also
|
||||||
--------
|
--------
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue