mirror of
https://github.com/esphome/esphome-docs.git
synced 2025-01-12 20:10:50 +01:00
Spelling and grammar fixes (#372)
This commit is contained in:
parent
124602fa98
commit
4ed468e747
@ -212,7 +212,7 @@ All changes
|
||||
- yaml: Make compatible with python 3 :yamlpr:`281`
|
||||
- docs: Fix copy/paste error in turn_off_action :docspr:`113` by :ghuser:`wutr`
|
||||
- yaml: GPIO Switch Fix restore_mode validator :yamlpr:`296` by :ghuser:`yottatsa`
|
||||
- yaml: Fixes for Python 3 Compatability :yamlpr:`297`
|
||||
- yaml: Fixes for Python 3 Compatibility :yamlpr:`297`
|
||||
- lib: Stop old template action when new one is started :libpr:`354`
|
||||
- lib: Add APDS-9960 support :libpr:`286`
|
||||
- lib: Change default update interval to 60 seconds :libpr:`356`
|
||||
|
@ -149,7 +149,7 @@ Beta Fixes
|
||||
All changes
|
||||
-----------
|
||||
|
||||
- core: Attemp to fix the addressable flicker effect :corepr:`392` by :ghuser:`RomRider`
|
||||
- core: Attempt to fix the addressable flicker effect :corepr:`392` by :ghuser:`RomRider`
|
||||
- esphome: typing is only required for python < 3.5 :esphomepr:`341` by :ghuser:`dotlambda`
|
||||
- esphome: Fix install pillow in docker image :esphomepr:`338`
|
||||
- esphome: Allow IPv4 addresses for SNTP servers :esphomepr:`340`
|
||||
@ -222,7 +222,7 @@ All changes
|
||||
- core: Better error messages for OTA :corepr:`486`
|
||||
- esphome: Better error messages for OTA :esphomepr:`418`
|
||||
- core: Synchronize homeassistant time periodically :corepr:`485`
|
||||
- core: ESP8266 Arduino 2.5.0 Compatability :corepr:`481` (cherry-picked)
|
||||
- core: ESP8266 Arduino 2.5.0 Compatibility :corepr:`481` (cherry-picked)
|
||||
- esphome: Add Switch Interlocking :esphomepr:`411` (cherry-picked)
|
||||
- esphome: Add local mDNS responder for .local :esphomepr:`386` (cherry-picked)
|
||||
- core: Auto-Redact private information from logs :corepr:`488`
|
||||
|
@ -98,7 +98,7 @@ Other notable changes:
|
||||
functions to allow easier effect creation.
|
||||
- Added a new custom component mechanism and contribution guidelines have been updated. See the
|
||||
:doc:`contributing guide </guides/contributing>` for more details.
|
||||
- :doc:`RDM6300 </components/binary_sensor/rdm6300>` now also has a ``on_tag`` trigger like the PN532.
|
||||
- :doc:`RDM6300 </components/binary_sensor/rdm6300>` now also has an ``on_tag`` trigger like the PN532.
|
||||
- :doc:`Remote Transmitter </components/remote_transmitter>` and :doc:`Remote Receiver </components/remote_receiver>`
|
||||
have gotten some new features: custom triggers and actions with templatable values.
|
||||
- Added ``output.esp8266_pwm.set_frequency`` action for dynamically changing the frequency of the ESP8266
|
||||
|
@ -98,7 +98,7 @@ You can repeat these steps for all your nodes, or convert them over to the new n
|
||||
});
|
||||
</script>
|
||||
|
||||
4. Stop Home Assistant - this is necessary for the entity registry changes not to become overriden.
|
||||
4. Stop Home Assistant - this is necessary for the entity registry changes not to become overridden.
|
||||
|
||||
5. Convert the Entity Registry file above using the "Convert Entity Registry Button", and
|
||||
override the ``.storage/core.entity_registry`` file with the new contents.
|
||||
|
@ -8,7 +8,7 @@ Please first read :doc:`/components/sensor/custom` guide,
|
||||
the same principles apply here.
|
||||
|
||||
All internal stuff (like effects, transitions etc) is handled by the light core
|
||||
and cannot be overriden. Light outputs are only responsible for displaying some state
|
||||
and cannot be overridden. Light outputs are only responsible for displaying some state
|
||||
when asked to do so.
|
||||
|
||||
The example below is an example of a custom light output.
|
||||
|
@ -48,7 +48,7 @@ Updating the password:
|
||||
|
||||
Since the password is used both for compiling and uploading the regular ``esphome <file> run``
|
||||
won't work of course. This issue can be worked around by executing the operations separately
|
||||
through a ``on_boot`` trigger:
|
||||
through an ``on_boot`` trigger:
|
||||
|
||||
.. code-block:: yaml
|
||||
|
||||
|
@ -42,7 +42,7 @@ Configuration variables:
|
||||
- **pin** (**Required**, :ref:`config-pin`): The pin to transmit the remote signal on.
|
||||
- **carrier_duty_percent** (*Optional*, int): How much of the time the remote is on. For example, infrared
|
||||
protocols modulate the signal using a carrier signal. Set this is ``50%`` if you're working with IR leds and to
|
||||
``100%`` if working with a other things like 433MHz transmitters.
|
||||
``100%`` if working with other things like 433MHz transmitters.
|
||||
- **id** (*Optional*, :ref:`config-id`): Manually specify
|
||||
the ID used for code generation. Use this if you have multiple remote transmitters.
|
||||
|
||||
|
@ -15,7 +15,7 @@ than about two meters and may sometimes make some annoying clicking
|
||||
sounds.
|
||||
|
||||
This sensor platform expects a sensor that can be sent a **trigger
|
||||
pulse** on a specific pin and will send out a **echo pulse** once a
|
||||
pulse** on a specific pin and will send out an **echo pulse** once a
|
||||
measurement has been taken. Because sometimes (for example if no object
|
||||
is detected) the echo pulse is never returned, this sensor also has a
|
||||
timeout option which specifies how long to wait for values.
|
||||
|
@ -274,7 +274,7 @@ lambda calls
|
||||
From :ref:`lambdas <config-lambda>`, you can call several methods on stepper motors to do some
|
||||
advanced stuff (see the full API Reference for more info).
|
||||
|
||||
- ``set_target``: Set the target postion of the motor as an integer.
|
||||
- ``set_target``: Set the target position of the motor as an integer.
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
@ -282,21 +282,21 @@ advanced stuff (see the full API Reference for more info).
|
||||
// Set the (absolute) target position to 250 steps
|
||||
id(my_stepper).set_target(250);
|
||||
|
||||
- ``report_position``: Report the current postion as an integer.
|
||||
- ``report_position``: Report the current position as an integer.
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
// Report the (absolute) current position as 250 steps
|
||||
id(my_stepper).report_position(250);
|
||||
|
||||
- ``current_postion``: Get the current postion of the stepper as an integer.
|
||||
- ``current_position``: Get the current position of the stepper as an integer.
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
int pos = id(my_stepper).current_position;
|
||||
|
||||
|
||||
- ``target_position``: Get the set target postion of the stepper as an integer.
|
||||
- ``target_position``: Get the set target position of the stepper as an integer.
|
||||
|
||||
.. code-block:: cpp
|
||||
|
||||
|
@ -71,7 +71,7 @@ When adding binary sensors the pins are configured as INPUT_PULLUP, you can use
|
||||
|
||||
.. note::
|
||||
|
||||
Arduino PIN 13 usually has a LED conected to it and using it as digital input with the built in internal
|
||||
Arduino PIN 13 usually has a LED connected to it and using it as digital input with the built in internal
|
||||
pull up might be problematic, using it as an output is preferred.
|
||||
|
||||
To setup binary sensors, create a custom platform as below, list in braces all the sensors you want,
|
||||
|
@ -25,7 +25,7 @@ for some motors.
|
||||
|
||||
Controlling the cover to quickly (sending new open/close commands within a minute of previous commands)
|
||||
might cause unexpected behaviour (eg: cover stopping halfway). This is because the delayed relay off
|
||||
feature is implemented using asynchronous automations. So every time a open/close command is sent a
|
||||
feature is implemented using asynchronous automations. So every time an open/close command is sent a
|
||||
delayed relay off command is added and old ones are not removed.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
@ -107,7 +107,7 @@ When you're done, it should look something like this:
|
||||
.. note::
|
||||
|
||||
On some older 4CHs, the ``RX`` and ``TX`` pins are swapped (sometimes even the written silkscreen is
|
||||
wrong). If your upload fails with a ``error: espcomm_upload_mem failed`` message it's most likely due
|
||||
wrong). If your upload fails with an ``error: espcomm_upload_mem failed`` message it's most likely due
|
||||
to the pins being swapped. In that case, just swap ``RX`` and ``TX`` and try again - you won't break
|
||||
anything if they're swapped.
|
||||
|
||||
|
@ -109,7 +109,7 @@ It's best to just use a multimeter and double check if it's unclear.
|
||||
.. note::
|
||||
|
||||
On some older S20s, the ``RX`` and ``TX`` pins are swapped (sometimes even the written silkscreen is
|
||||
wrong). If your upload fails with a ``error: espcomm_upload_mem failed`` message it's most likely due
|
||||
wrong). If your upload fails with an ``error: espcomm_upload_mem failed`` message it's most likely due
|
||||
to the pins being swapped. In that case, just swap ``RX`` and ``TX`` and try again - you won't break
|
||||
anything if they're swapped.
|
||||
|
||||
|
@ -108,7 +108,7 @@ provided **you are not touching any live contacts**, only the wires.
|
||||
.. note::
|
||||
|
||||
On some older T1 UK 3 Gangs, the ``RX`` and ``TX`` pins are swapped (sometimes even the written silkscreen is
|
||||
wrong). If your upload fails with a ``error: espcomm_upload_mem failed`` message it's most likely due
|
||||
wrong). If your upload fails with an ``error: espcomm_upload_mem failed`` message it's most likely due
|
||||
to the pins being swapped. In that case, just swap ``RX`` and ``TX`` and try again - you won't break
|
||||
anything if they're swapped.
|
||||
|
||||
|
@ -69,7 +69,7 @@ Woah, hold on there. Please explain what's going on here! Sure :) Let's step thr
|
||||
# ...
|
||||
id: dehumidifier1
|
||||
|
||||
First, we have to give the dehumidifier an :ref:`config-id` so that we can
|
||||
First, we have to give the dehumidifier a :ref:`config-id` so that we can
|
||||
later use it inside our awesome automation.
|
||||
|
||||
.. code-block:: yaml
|
||||
|
@ -202,7 +202,7 @@ RST primer:
|
||||
New pages need to be added to the ``imgtable`` list. The syntax is CSV with <PAGE NAME>, <FILE NAME> (without RST),
|
||||
<IMAGE> (in top-level images/ directory). The aspect ratio of these images should be 8:10 (or 10:8) but exceptions are possible.
|
||||
|
||||
Because these images are served on the main page, they need to be compressed heavily. SVGs are prefered over JPGs
|
||||
Because these images are served on the main page, they need to be compressed heavily. SVGs are preferred over JPGs
|
||||
and JPGs should be max. 300x300px.
|
||||
If you have imagemagick installed, you can use this command to convert the thumbnail:
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user