mirror of
https://github.com/esphome/esphome-docs.git
synced 2024-09-29 04:27:32 +02:00
Merge branch 'current' into beta
This commit is contained in:
commit
4367f5b750
@ -75,7 +75,7 @@ Configuration options:
|
|||||||
- **variables** (*Optional*, mapping): Optional variables that can be used in the ``data_template``.
|
- **variables** (*Optional*, mapping): Optional variables that can be used in the ``data_template``.
|
||||||
Values are :ref:`lambdas <config-lambda>` and will be evaluated before sending the request.
|
Values are :ref:`lambdas <config-lambda>` and will be evaluated before sending the request.
|
||||||
|
|
||||||
Data structures are not possible, but you can create an script in Home Assistant and call with all
|
Data structures are not possible, but you can create a script in Home Assistant and call with all
|
||||||
the parameters in plain format.
|
the parameters in plain format.
|
||||||
|
|
||||||
.. code-block:: yaml
|
.. code-block:: yaml
|
||||||
|
@ -20,7 +20,7 @@ in your configuration.
|
|||||||
Overview
|
Overview
|
||||||
--------
|
--------
|
||||||
|
|
||||||
The module can be powered by the 3.3V output of an NodeMCU. For communication you can connect only
|
The module can be powered by the 3.3V output of a NodeMCU. For communication you can connect only
|
||||||
the ``tx_pin`` of the ``uart`` bus to the module's ``RX`` but if you need feedback of playback active
|
the ``tx_pin`` of the ``uart`` bus to the module's ``RX`` but if you need feedback of playback active
|
||||||
you will also need to connect the ``rx_pin`` to the module's ``TX``.
|
you will also need to connect the ``rx_pin`` to the module's ``TX``.
|
||||||
For best quality audio a powered stereo speaker can be connected to the modules ``DAC_R``,
|
For best quality audio a powered stereo speaker can be connected to the modules ``DAC_R``,
|
||||||
|
@ -15,7 +15,7 @@ The ``lcd_pcf8574`` display platform allows you to use standard character-based
|
|||||||
with ESPHome. This integration is only for LCD displays that display individual characters on a screen (usually 16-20 columns
|
with ESPHome. This integration is only for LCD displays that display individual characters on a screen (usually 16-20 columns
|
||||||
and 2-4 rows), and not for LCD displays that can control each pixel individually.
|
and 2-4 rows), and not for LCD displays that can control each pixel individually.
|
||||||
|
|
||||||
This version of the LCD integration is for LCD displays with an PCF8574 connected to all the data pins. This has
|
This version of the LCD integration is for LCD displays with a PCF8574 connected to all the data pins. This has
|
||||||
the benefit that you only need to connect two data wires to the ESP instead of the 6 or 10 with the :ref:`lcd-gpio`.
|
the benefit that you only need to connect two data wires to the ESP instead of the 6 or 10 with the :ref:`lcd-gpio`.
|
||||||
As the communication with the :ref:`I²C Bus <i2c>`, you need to have an ``i2c:`` section in your configuration.
|
As the communication with the :ref:`I²C Bus <i2c>`, you need to have an ``i2c:`` section in your configuration.
|
||||||
|
|
||||||
|
@ -104,7 +104,7 @@ This is roughly the code used to display the MAX7219 pictured in the image.
|
|||||||
Scrolling
|
Scrolling
|
||||||
*********
|
*********
|
||||||
|
|
||||||
By default the MAX7219Digit display has scroll enabled. The paramaters can be set in the YAML file.
|
By default the MAX7219Digit display has scroll enabled. The parameters can be set in the YAML file.
|
||||||
They can also be changed in the Lambda by adding the following command:
|
They can also be changed in the Lambda by adding the following command:
|
||||||
|
|
||||||
.. code-block:: cpp
|
.. code-block:: cpp
|
||||||
|
@ -84,6 +84,7 @@ See Also
|
|||||||
--------
|
--------
|
||||||
|
|
||||||
- :doc:`index`
|
- :doc:`index`
|
||||||
|
- :doc:`/components/binary_sensor/nextion`
|
||||||
- :apiref:`nextion/nextion.h`
|
- :apiref:`nextion/nextion.h`
|
||||||
- `Simple Nextion Library <https://github.com/bborncr/nextion>`__ by `Bentley Born <https://github.com/bborncr>`__
|
- `Simple Nextion Library <https://github.com/bborncr/nextion>`__ by `Bentley Born <https://github.com/bborncr>`__
|
||||||
- `Official Nextion Library <https://github.com/itead/ITEADLIB_Arduino_Nextion>`__ by `iTead <https://www.itead.cc/>`__
|
- `Official Nextion Library <https://github.com/itead/ITEADLIB_Arduino_Nextion>`__ by `iTead <https://www.itead.cc/>`__
|
||||||
|
@ -13,7 +13,7 @@ The ``tm1637`` display platform allows you to use the popular TM1637 7-segment d
|
|||||||
|
|
||||||
TM1637 7-Segment Display.
|
TM1637 7-Segment Display.
|
||||||
|
|
||||||
The module can be powered with 5v or with 3.3v too. To display the colon punctiation use the
|
The module can be powered with 5v or with 3.3v too. To display the colon punctuation use the
|
||||||
``.`` in the colon place. (See clock example below)
|
``.`` in the colon place. (See clock example below)
|
||||||
|
|
||||||
|
|
||||||
@ -48,7 +48,7 @@ Rendering Lambda
|
|||||||
|
|
||||||
The TM1637 has a similar API to the fully fledged :ref:`display-engine`, but it's only a subset as the TM1637
|
The TM1637 has a similar API to the fully fledged :ref:`display-engine`, but it's only a subset as the TM1637
|
||||||
7-segment displays don't have a concept of individual pixels. In the lambda you're passed a variable called ``it``
|
7-segment displays don't have a concept of individual pixels. In the lambda you're passed a variable called ``it``
|
||||||
as with all other displays. In this case however, ``it`` is an TM1637 instance (see API Reference).
|
as with all other displays. In this case however, ``it`` is a TM1637 instance (see API Reference).
|
||||||
|
|
||||||
The most basic operation with the TM1637 is wiring a simple number to the screen as in the configuration example
|
The most basic operation with the TM1637 is wiring a simple number to the screen as in the configuration example
|
||||||
at the top of this page. But even though you're passing in a string (here ``"0123"``), ESPHome converts it
|
at the top of this page. But even though you're passing in a string (here ``"0123"``), ESPHome converts it
|
||||||
|
@ -159,8 +159,8 @@ Configuration variables:
|
|||||||
|
|
||||||
.. _esp32_ble_tracker-on_ble_service_data_advertise:
|
.. _esp32_ble_tracker-on_ble_service_data_advertise:
|
||||||
|
|
||||||
``on_ble_on_ble_service_data_advertise``
|
``on_ble_service_data_advertise``
|
||||||
****************************************
|
*********************************
|
||||||
|
|
||||||
This automation will be triggered when a Bluetooth advertising with service data is received. A
|
This automation will be triggered when a Bluetooth advertising with service data is received. A
|
||||||
variable ``x`` of type ``std::vector<uint8_t>`` is passed to the automation for use in lambdas.
|
variable ``x`` of type ``std::vector<uint8_t>`` is passed to the automation for use in lambdas.
|
||||||
|
@ -5,7 +5,7 @@ Cold White + Warm White Light
|
|||||||
:description: Instructions for setting up Cold White + Warm White lights.
|
:description: Instructions for setting up Cold White + Warm White lights.
|
||||||
:image: brightness-medium.png
|
:image: brightness-medium.png
|
||||||
|
|
||||||
The ``cwww`` light platform creates an Cold-White+Warm-White
|
The ``cwww`` light platform creates a Cold-White+Warm-White
|
||||||
light from 2 :ref:`float output components <output>` (one for each channel). The two
|
light from 2 :ref:`float output components <output>` (one for each channel). The two
|
||||||
channels will be mixed using the color temperature configuration options.
|
channels will be mixed using the color temperature configuration options.
|
||||||
|
|
||||||
|
@ -719,7 +719,7 @@ Available variables in the lambda:
|
|||||||
|
|
||||||
- **it** - :apiclass:`AddressableLight <light::AddressableLight>` instance (see API reference for more info).
|
- **it** - :apiclass:`AddressableLight <light::AddressableLight>` instance (see API reference for more info).
|
||||||
- **current_color** - :apistruct:`ESPColor <light::ESPColor>` instance (see API reference for more info).
|
- **current_color** - :apistruct:`ESPColor <light::ESPColor>` instance (see API reference for more info).
|
||||||
- **initial_run** - A bool which is true on the first execution of the lambda. Useful to reset static variables when restarting a effect.
|
- **initial_run** - A bool which is true on the first execution of the lambda. Useful to reset static variables when restarting an effect.
|
||||||
|
|
||||||
.. code-block:: yaml
|
.. code-block:: yaml
|
||||||
|
|
||||||
|
@ -6,7 +6,7 @@ Neopixelbus Light
|
|||||||
:image: color_lens.png
|
:image: color_lens.png
|
||||||
|
|
||||||
The ``neopixelbus`` light platform allows you to create RGB lights
|
The ``neopixelbus`` light platform allows you to create RGB lights
|
||||||
in ESPHome for a individually addressable lights like NeoPixel or WS2812.
|
in ESPHome for an individually addressable lights like NeoPixel or WS2812.
|
||||||
|
|
||||||
It is very similar to the :doc:`fastled` platform.
|
It is very similar to the :doc:`fastled` platform.
|
||||||
in fact most addressable lights are supported through both light platforms. The
|
in fact most addressable lights are supported through both light platforms. The
|
||||||
|
@ -62,7 +62,7 @@ Configuration variables:
|
|||||||
Color Interlock
|
Color Interlock
|
||||||
***************
|
***************
|
||||||
|
|
||||||
With some LED bulbs, setting the RGB channels to maximum whilst wanting a white light will have a undesired
|
With some LED bulbs, setting the RGB channels to maximum whilst wanting a white light will have an undesired
|
||||||
hue affect. Additionally, the brightness command may not work as expected depending upon configuration,
|
hue affect. Additionally, the brightness command may not work as expected depending upon configuration,
|
||||||
leaving users to adjust the white component level separately. For these cases a new configration variable
|
leaving users to adjust the white component level separately. For these cases a new configration variable
|
||||||
has been added: color_interlock.
|
has been added: color_interlock.
|
||||||
|
@ -124,7 +124,7 @@ Next, we can manually set the log levels in the configuration like this:
|
|||||||
mqtt.client: ERROR
|
mqtt.client: ERROR
|
||||||
|
|
||||||
Please note that the global log level determines what log messages are
|
Please note that the global log level determines what log messages are
|
||||||
saved in the binary. So for example a ``INFO`` global log message will
|
saved in the binary. So for example an ``INFO`` global log message will
|
||||||
purge all ``DEBUG`` log statements from the binary in order to conserve
|
purge all ``DEBUG`` log statements from the binary in order to conserve
|
||||||
space. This however means that you cannot set tag-specific log levels
|
space. This however means that you cannot set tag-specific log levels
|
||||||
that have a lower severity than the global log level.
|
that have a lower severity than the global log level.
|
||||||
|
@ -7,7 +7,7 @@ OTA Update Component
|
|||||||
:keywords: Xiaomi, Mi Flora, BLE, Bluetooth
|
:keywords: Xiaomi, Mi Flora, BLE, Bluetooth
|
||||||
|
|
||||||
With the OTA (Over The Air) update component you can upload your
|
With the OTA (Over The Air) update component you can upload your
|
||||||
firmware binaries to your node without having to use an USB cable for
|
firmware binaries to your node without having to use a USB cable for
|
||||||
uploads. ESPHome natively supports this through its ``run`` and
|
uploads. ESPHome natively supports this through its ``run`` and
|
||||||
``upload`` helper scripts.
|
``upload`` helper scripts.
|
||||||
|
|
||||||
|
@ -35,7 +35,7 @@ The output level is a percentage of the board supply voltage (VDD_A) - generally
|
|||||||
- platform: monochromatic
|
- platform: monochromatic
|
||||||
output: dac_output
|
output: dac_output
|
||||||
gamma_correct: 1.4
|
gamma_correct: 1.4
|
||||||
id: dac_output
|
id: mono_light
|
||||||
|
|
||||||
|
|
||||||
Configuration variables:
|
Configuration variables:
|
||||||
|
@ -45,7 +45,7 @@ Configuration variables:
|
|||||||
decoding process. Defaults to ``25%``.
|
decoding process. Defaults to ``25%``.
|
||||||
- **buffer_size** (*Optional*, int): The size of the internal buffer for storing the remote codes. Defaults to ``10kB``
|
- **buffer_size** (*Optional*, int): The size of the internal buffer for storing the remote codes. Defaults to ``10kB``
|
||||||
on the ESP32 and ``1kB`` on the ESP8266.
|
on the ESP32 and ``1kB`` on the ESP8266.
|
||||||
- **memory_blocks** (*Optional*, int): The number of RMT memory blocks used. Only used on ESP32 platfrom. Defaults to
|
- **memory_blocks** (*Optional*, int): The number of RMT memory blocks used. Only used on ESP32 platform. Defaults to
|
||||||
``3``.
|
``3``.
|
||||||
- **filter** (*Optional*, :ref:`time <config-time>`): Filter any pulses that are shorter than this. Useful for removing
|
- **filter** (*Optional*, :ref:`time <config-time>`): Filter any pulses that are shorter than this. Useful for removing
|
||||||
glitches from noisy signals. Defaults to ``10us``.
|
glitches from noisy signals. Defaults to ``10us``.
|
||||||
|
@ -60,7 +60,7 @@ Sensor
|
|||||||
|
|
||||||
The ``ads1115`` sensor allows you to use your ADS1115 sigma-delta ADC
|
The ``ads1115`` sensor allows you to use your ADS1115 sigma-delta ADC
|
||||||
sensors (`datasheet <http://www.ti.com/lit/ds/symlink/ads1115.pdf>`__, `Adafruit`_) with ESPHome.
|
sensors (`datasheet <http://www.ti.com/lit/ds/symlink/ads1115.pdf>`__, `Adafruit`_) with ESPHome.
|
||||||
First, setup a :ref:`ADS1115 Hub <ads1115-component>` for your ADS1115 sensor and then use this
|
First, setup an :ref:`ADS1115 Hub <ads1115-component>` for your ADS1115 sensor and then use this
|
||||||
sensor platform to create individual sensors that will report the
|
sensor platform to create individual sensors that will report the
|
||||||
voltage to Home Assistant.
|
voltage to Home Assistant.
|
||||||
|
|
||||||
|
@ -32,7 +32,7 @@ your configuration for this sensor to work.
|
|||||||
update_interval: 60s
|
update_interval: 60s
|
||||||
|
|
||||||
By default the **measurement_time** is set to ``69`` which will result into measurements up
|
By default the **measurement_time** is set to ``69`` which will result into measurements up
|
||||||
to 54612.5 lx for this sensor. For low-light situtations consider to choose a higer
|
to 54612.5 lx for this sensor. For low-light situtations consider to choose a higher
|
||||||
measurement_time up to ``254`` which will result in a maximum measurement range up to 14835 lx.
|
measurement_time up to ``254`` which will result in a maximum measurement range up to 14835 lx.
|
||||||
For sunny scenes (for example outdoors with sunlight) use lower values down to ``31`` which will
|
For sunny scenes (for example outdoors with sunlight) use lower values down to ``31`` which will
|
||||||
give you the maximum measurement range up to 121556 lx.
|
give you the maximum measurement range up to 121556 lx.
|
||||||
@ -44,7 +44,7 @@ Configuration variables:
|
|||||||
- **address** (*Optional*, int): Manually specify the I²C address of the sensor.
|
- **address** (*Optional*, int): Manually specify the I²C address of the sensor.
|
||||||
Defaults to ``0x23`` (address if address pin is pulled low). If the address pin is pulled high,
|
Defaults to ``0x23`` (address if address pin is pulled low). If the address pin is pulled high,
|
||||||
the address is ``0x5C``.
|
the address is ``0x5C``.
|
||||||
- **measurement_time** (*Optional*, int): Manually specifiy the measurement time between ``31``
|
- **measurement_time** (*Optional*, int): Manually specify the measurement time between ``31``
|
||||||
and ``254``. Defaults to ``69``.
|
and ``254``. Defaults to ``69``.
|
||||||
- **resolution** (*Optional*, string): The resolution of the sensor in lx. One of ``4.0``,
|
- **resolution** (*Optional*, string): The resolution of the sensor in lx. One of ``4.0``,
|
||||||
``1.0``, ``0.5``. Defaults to ``0.5`` (the maximum resolution).
|
``1.0``, ``0.5``. Defaults to ``0.5`` (the maximum resolution).
|
||||||
|
@ -150,7 +150,7 @@ Where HARDWARE can be any of:
|
|||||||
extern const float HARDWARE;
|
extern const float HARDWARE;
|
||||||
/// For components that import data from directly connected sensors like DHT.
|
/// For components that import data from directly connected sensors like DHT.
|
||||||
extern const float DATA;
|
extern const float DATA;
|
||||||
/// Alias for DATA (here for compatability reasons)
|
/// Alias for DATA (here for compatibility reasons)
|
||||||
extern const float HARDWARE_LATE;
|
extern const float HARDWARE_LATE;
|
||||||
/// For components that use data from sensors like displays
|
/// For components that use data from sensors like displays
|
||||||
extern const float PROCESSOR;
|
extern const float PROCESSOR;
|
||||||
|
@ -23,6 +23,45 @@ Configuration variables:
|
|||||||
- **id** (*Optional*, :ref:`config-id`): Set the ID of this sensor for use in lambdas.
|
- **id** (*Optional*, :ref:`config-id`): Set the ID of this sensor for use in lambdas.
|
||||||
- All other options from :ref:`Sensor <config-sensor>`.
|
- All other options from :ref:`Sensor <config-sensor>`.
|
||||||
|
|
||||||
|
Human readable sensor
|
||||||
|
---------------------
|
||||||
|
|
||||||
|
The sensor reports uptime in seconds which is good for automations
|
||||||
|
but is hard to read for humans, this example creates a text sensor
|
||||||
|
with human readable output.
|
||||||
|
|
||||||
|
.. code-block:: yaml
|
||||||
|
|
||||||
|
# Example configuration entry
|
||||||
|
text_sensor:
|
||||||
|
- platform: template
|
||||||
|
name: Uptime Human Readable
|
||||||
|
id: uptime_human
|
||||||
|
icon: mdi:clock-start
|
||||||
|
sensor:
|
||||||
|
- platform: uptime
|
||||||
|
name: Uptime Sensor
|
||||||
|
id: uptime
|
||||||
|
update_interval: 60s
|
||||||
|
on_raw_value:
|
||||||
|
then:
|
||||||
|
- text_sensor.template.publish:
|
||||||
|
id: uptime_human
|
||||||
|
state: !lambda |-
|
||||||
|
int seconds = round(id(uptime).raw_state);
|
||||||
|
int days = seconds / (24 * 3600);
|
||||||
|
seconds = seconds % (24 * 3600);
|
||||||
|
int hours = seconds / 3600;
|
||||||
|
seconds = seconds % 3600;
|
||||||
|
int minutes = seconds / 60;
|
||||||
|
seconds = seconds % 60;
|
||||||
|
return (
|
||||||
|
(days ? String(days) + "d " : "") +
|
||||||
|
(hours ? String(hours) + "h " : "") +
|
||||||
|
(minutes ? String(minutes + "m " : "") +
|
||||||
|
(String(seconds) + "s")
|
||||||
|
).c_str();
|
||||||
|
|
||||||
See Also
|
See Also
|
||||||
--------
|
--------
|
||||||
|
|
||||||
|
@ -23,7 +23,7 @@ monitors with ESPHome.
|
|||||||
:align: center
|
:align: center
|
||||||
:width: 80.0%
|
:width: 80.0%
|
||||||
|
|
||||||
ZyAura ZGm053U connection diagram (1 - empty, 2 - clock, 3 - data, 4 - GND).
|
ZyAura ZGm053U connection diagram (1 - empty, 2 - clock, 3 - data, 4 - GND). In some other models the clock and data pins are swapped.
|
||||||
|
|
||||||
.. code-block:: yaml
|
.. code-block:: yaml
|
||||||
|
|
||||||
|
@ -14,7 +14,7 @@ SPI is a very common high-speed protocol for a lot of devices. The SPI bus usual
|
|||||||
share this line. Sometimes also called ``SCK``.
|
share this line. Sometimes also called ``SCK``.
|
||||||
- **CS** (chip select): Is used to tell the receiving device when it should listen for data. Each device has
|
- **CS** (chip select): Is used to tell the receiving device when it should listen for data. Each device has
|
||||||
an individual CS line. Sometimes also called ``SS``. If the SPI bus has a single device, its CS pin
|
an individual CS line. Sometimes also called ``SS``. If the SPI bus has a single device, its CS pin
|
||||||
can somtimes be connected to ground to tell it that it is allways selected.
|
can sometimes be connected to ground to tell it that it is always selected.
|
||||||
- **MOSI** (also DIN): Is used to send data from the master (the ESP) to the receiving device. All devices on the bus can
|
- **MOSI** (also DIN): Is used to send data from the master (the ESP) to the receiving device. All devices on the bus can
|
||||||
share this line.
|
share this line.
|
||||||
- **MISO** (also DOUT): Is used to receive data. All devices on the bus can
|
- **MISO** (also DOUT): Is used to receive data. All devices on the bus can
|
||||||
|
@ -90,7 +90,7 @@ Example usage
|
|||||||
|
|
||||||
Here is an example switch using the uart text sensor to set switch state.
|
Here is an example switch using the uart text sensor to set switch state.
|
||||||
|
|
||||||
Here we use interval to request status from the device. The reponse will be stored in uart text sensor.
|
Here we use interval to request status from the device. The response will be stored in uart text sensor.
|
||||||
Then the switch uses the text sensor state to set its own state.
|
Then the switch uses the text sensor state to set its own state.
|
||||||
|
|
||||||
.. code-block:: yaml
|
.. code-block:: yaml
|
||||||
|
@ -2,7 +2,7 @@ Arduino Port Expander
|
|||||||
=====================
|
=====================
|
||||||
|
|
||||||
.. seo::
|
.. seo::
|
||||||
:description: Instructions on using an Arduino board, like the Pro Mini for expanding ports of a ESPHome node
|
:description: Instructions on using an Arduino board, like the Pro Mini for expanding ports of an ESPHome node
|
||||||
:image: arduino_pro_mini.jpg
|
:image: arduino_pro_mini.jpg
|
||||||
:keywords: Arduino port expander extender ESPHome
|
:keywords: Arduino port expander extender ESPHome
|
||||||
|
|
||||||
|
@ -14,7 +14,7 @@ This configuration will expose a :doc:`/components/light/binary` and a :doc:`/co
|
|||||||
|
|
||||||
To get this working in ESPHome you first need to create a :doc:`/components/output/custom` to control the iFan02.
|
To get this working in ESPHome you first need to create a :doc:`/components/output/custom` to control the iFan02.
|
||||||
|
|
||||||
Create a ifan02.h file:
|
Create an ifan02.h file:
|
||||||
|
|
||||||
.. code-block:: c++
|
.. code-block:: c++
|
||||||
|
|
||||||
|
@ -11,7 +11,7 @@ Compared to a dashboard screen the infostrip can only communicate the informatio
|
|||||||
|
|
||||||
- color (e.g., red = error/warning, orange = waring, green = ok, blue = active)
|
- color (e.g., red = error/warning, orange = waring, green = ok, blue = active)
|
||||||
- intensity (off, scaled brightness)
|
- intensity (off, scaled brightness)
|
||||||
- mode (continous vs. flashing, flashing or strobe is not recommened)
|
- mode (continuous vs. flashing, flashing or strobe is not recommend)
|
||||||
- light position on stripe
|
- light position on stripe
|
||||||
|
|
||||||
.. figure:: images/infostrip-detail.jpg
|
.. figure:: images/infostrip-detail.jpg
|
||||||
|
@ -120,7 +120,7 @@ Thanks to the `existing work <https://github.com/arendst/Sonoff-tasmota/wiki/Mir
|
|||||||
3.1 Monochromatic Bulbs
|
3.1 Monochromatic Bulbs
|
||||||
***********************
|
***********************
|
||||||
|
|
||||||
So the brightness of the bulb can be controlled we use the ``esp8266_pwm`` output component connected to the light component using the id configuration
|
The brightness of the bulb can be controlled using the ``esp8266_pwm`` output component connected to the light component using the id configuration
|
||||||
variable ``output_component1``.
|
variable ``output_component1``.
|
||||||
|
|
||||||
.. code-block:: yaml
|
.. code-block:: yaml
|
||||||
@ -152,8 +152,10 @@ variable ``output_component1``.
|
|||||||
output:
|
output:
|
||||||
- platform: esp8266_pwm
|
- platform: esp8266_pwm
|
||||||
id: output_component1
|
id: output_component1
|
||||||
|
# May need to use GPIO14 instead for certain globes
|
||||||
pin: GPIO13
|
pin: GPIO13
|
||||||
|
|
||||||
|
|
||||||
3.2 Cold + Warm White Bulbs
|
3.2 Cold + Warm White Bulbs
|
||||||
***************************
|
***************************
|
||||||
|
|
||||||
|
@ -48,7 +48,7 @@ interface.
|
|||||||
For this guide you will need:
|
For this guide you will need:
|
||||||
|
|
||||||
- Sonoff T1 UK 3 Gang 😉
|
- Sonoff T1 UK 3 Gang 😉
|
||||||
- An USB to UART Bridge for flashing the device. These can be bought on Amazon for less than 5 dollars.
|
- A USB to UART Bridge for flashing the device. These can be bought on Amazon for less than 5 dollars.
|
||||||
Note that the bridge *must* be 3.3V compatible. Otherwise you will destroy your Sonoff.
|
Note that the bridge *must* be 3.3V compatible. Otherwise you will destroy your Sonoff.
|
||||||
- Jumper wires to connect the UART bridge to the header pins and to connect GPIO0 to the Ground.
|
- Jumper wires to connect the UART bridge to the header pins and to connect GPIO0 to the Ground.
|
||||||
- Computer running ESPHome or Hass.io add-on.
|
- Computer running ESPHome or Hass.io add-on.
|
||||||
|
@ -44,7 +44,7 @@ interface.
|
|||||||
For this guide you will need:
|
For this guide you will need:
|
||||||
|
|
||||||
- Sonoff T3 EU 3 Gang 😉
|
- Sonoff T3 EU 3 Gang 😉
|
||||||
- An USB to UART Bridge for flashing the device. These can be bought on Amazon for less than 5 dollars.
|
- A USB to UART Bridge for flashing the device. These can be bought on Amazon for less than 5 dollars.
|
||||||
Note that the bridge *must* be 3.3V compatible. Otherwise you will destroy your Sonoff.
|
Note that the bridge *must* be 3.3V compatible. Otherwise you will destroy your Sonoff.
|
||||||
- Jumper wires to connect the UART bridge to the header pins and to connect GPIO0 to the Ground.
|
- Jumper wires to connect the UART bridge to the header pins and to connect GPIO0 to the Ground.
|
||||||
- Computer running ESPHome or the Home Assistant ESPHome add-on.
|
- Computer running ESPHome or the Home Assistant ESPHome add-on.
|
||||||
|
@ -801,7 +801,7 @@ using script modes ``single`` and ``restart`` respectively.
|
|||||||
- light.turn_off: hallway_light
|
- light.turn_off: hallway_light
|
||||||
|
|
||||||
...
|
...
|
||||||
on_...: # can be called from diffrent wall switches
|
on_...: # can be called from different wall switches
|
||||||
- script.execute: hallway_light_script
|
- script.execute: hallway_light_script
|
||||||
|
|
||||||
Sometimes you'll also need a timer which does not perform any action, that is ok too, just
|
Sometimes you'll also need a timer which does not perform any action, that is ok too, just
|
||||||
|
@ -224,7 +224,7 @@ Build
|
|||||||
|
|
||||||
docker run --rm -v "${PWD}/":/data/esphomedocs -p 8000:8000 -it esphome/esphome-docs
|
docker run --rm -v "${PWD}/":/data/esphomedocs -p 8000:8000 -it esphome/esphome-docs
|
||||||
|
|
||||||
With ``PWD`` refering to the root of the ``esphome-docs`` git repository. Then go to ``<CONTAINER_IP>:8000`` in your browser.
|
With ``PWD`` referring to the root of the ``esphome-docs`` git repository. Then go to ``<CONTAINER_IP>:8000`` in your browser.
|
||||||
|
|
||||||
This way, you don't have to install the dependencies to build the documentation.
|
This way, you don't have to install the dependencies to build the documentation.
|
||||||
|
|
||||||
|
@ -43,6 +43,7 @@ Blog Posts & Videos
|
|||||||
- `Washing machine phases detector (Sonoff Pow R2) <https://github.com/Gio-dot/Washing-Machine-Sonoff-Pow-R2-Esphome>`__ by `Gio-dot <https://github.com/Gio-dot>`__
|
- `Washing machine phases detector (Sonoff Pow R2) <https://github.com/Gio-dot/Washing-Machine-Sonoff-Pow-R2-Esphome>`__ by `Gio-dot <https://github.com/Gio-dot>`__
|
||||||
- `Sonoff L1 LED Strip <https://emorydunn.com/blog/2020/08/10/sonoff-l1-home-assistant/>`__ by :ghuser:`emorydunn`
|
- `Sonoff L1 LED Strip <https://emorydunn.com/blog/2020/08/10/sonoff-l1-home-assistant/>`__ by :ghuser:`emorydunn`
|
||||||
- `ESPHome for SP501E LED Controller <https://margau.net/posts/2020-11-21-2h-led-hack/>`__ by `margau <https://margau.net>`__
|
- `ESPHome for SP501E LED Controller <https://margau.net/posts/2020-11-21-2h-led-hack/>`__ by `margau <https://margau.net>`__
|
||||||
|
- `4$ Xiaomi mijia thermometer LYWSD03MMC + ESP32 + ESPhome <https://omarghader.github.io/how-to-monitor-your-home-temperature-with-esp32-and-xiaomi-mijia-using-esphome/>`__ by `Omar GHADER <https://omarghader.github.io/post>`__
|
||||||
|
|
||||||
Custom Components & Code
|
Custom Components & Code
|
||||||
------------------------
|
------------------------
|
||||||
|
Loading…
Reference in New Issue
Block a user