Fix some formatting (#4894)

Author: jesserockz

changelog/2021.11.0.rst

@@ -20,7 +20,7 @@ State of the Open Smart Home
 ----------------------------
 
 Mark your calendar for the `State of the Open Smart Home <https://www.home-assistant.io/state-of-the-open-home/>`__ hosted by Nabu Casa, Home Assistant & ESPHome
-and we’ll be joined by our friends from WLED and Z-Wave JS to talk about our work on making this vision a reality.
+and we'll be joined by our friends from WLED and Z-Wave JS to talk about our work on making this vision a reality.
 
 Where: YouTube
 

changelog/2021.12.0.rst

@@ -22,7 +22,7 @@ State of the Open Smart Home
 ----------------------------
 
 Today is the `State of the Open Smart Home <https://www.home-assistant.io/state-of-the-open-home/>`__ hosted by Nabu Casa, Home Assistant & ESPHome
-and we’ll be joined by our friends from WLED, Z-Wave JS, Stanford’s OVAL lab and Northeastern University to talk about our work on making this vision a reality.
+and we'll be joined by our friends from WLED, Z-Wave JS, Stanford's OVAL lab and Northeastern University to talk about our work on making this vision a reality.
 
 Where: YouTube
 

changelog/v1.8.0.rst

@@ -69,7 +69,7 @@ awesome projects ☀️
 
 Special thanks to all the contributors for this release:
 
-- esphomeyaml: Add ‘only-generate’ parameter to generate command to only generate the C++ code
+- esphomeyaml: Add ``only-generate`` parameter to generate command to only generate the C++ code
   `#84 <https://github.com/OttoWinter/esphomeyaml/pull/84>`__ by `@apeeters <https://github.com/apeeters>`__
 - esphomeyaml: Fix esphomeyaml logs for tls enabled mqtt brokers
   `#118 <https://github.com/OttoWinter/esphomeyaml/pull/118>`__ by `@johnerikhalse <https://github.com/johnerikhalse>`__

components/binary_sensor/status.rst

@@ -5,7 +5,7 @@ Status Binary Sensor
     :description: Instructions for setting up MQTT status binary sensors.
     :image: server-network.svg
 
-The Status Binary Sensor exposes the node state (if it’s connected to via MQTT/native API)
+The Status Binary Sensor exposes the node state (if it's connected to via MQTT/native API)
 for Home Assistant.
 
 .. figure:: images/status-ui.png

components/canbus/index.rst

@@ -13,7 +13,7 @@ single or dual-wire data bus at speeds up to 1Mbps.
 CAN is an International Standardization Organization (ISO) defined serial communications bus originally
 developed for the automotive industry to replace the complex wiring harness with a two-wire bus. The
 specification calls for high immunity to electrical interference and the ability to self-diagnose and repair
-data errors. These features have led to CAN’s popularity in a variety of industries including building
+data errors. These features have led to CAN's popularity in a variety of industries including building
 automation, medical, and manufacturing.
 
 The current ESPHome implementation supports single frame data transfer. In this way you may send and
@@ -59,7 +59,7 @@ Each ``canbus`` platform extends the following configuration schema:
 - **id** (*Optional*, :ref:`config-id`): Manually specify the ID used for code generation.
 - **can_id** (**Required**, int): default *CAN ID* used for transmitting frames.
 - **use_extended_id** (*Optional*, boolean): Identifies the type of ``can_id``:
-  
+
   - ``false``: Standard 11-bit IDs *(default)*
   - ``true``: Extended 29-bit IDs
 
@@ -190,7 +190,7 @@ The CAN bus can transmit frames by means of the ``canbus.send`` action. There ar
   CAN bus platforms defined in your configuration.
 - **can_id** (*Optional*, int): Allows overriding the ``can_id`` configured for the CAN bus device.
 - **use_extended_id** (*Optional*, boolean): Identifies the type of ``can_id``:
-  
+
   - ``false``: Standard 11-bit IDs *(default)*
   - ``true``: Extended 29-bit IDs
 

components/climate/haier.rst

@@ -9,7 +9,7 @@ This is an implementation of the ESPHome component to control HVAC on the base o
 
 There are two versions of the Haier protocol: the older version uses an application called SmartAir2 while the newer version uses an application called hOn. Both protocols are compatible on the transport level but utilize different commands to control appliances.
 
-Older Haier models controlled by the SmartAir2 application are using the KZW-W002 module. This module can’t be reused, and you need to replace it with an ESP or RPI Pico W module. The USB connector on the board doesn’t support the USB protocol. It is a UART port that just uses a USB connector. To connect the ESP board to your AC you can cut a USB type A cable and connect wires to the climate connector.
+Older Haier models controlled by the SmartAir2 application are using the KZW-W002 module. This module can't be reused, and you need to replace it with an ESP or RPI Pico W module. The USB connector on the board doesn't support the USB protocol. It is a UART port that just uses a USB connector. To connect the ESP board to your AC you can cut a USB type A cable and connect wires to the climate connector.
 
 .. list-table:: Haier UART pinout
     :header-rows: 1
@@ -41,7 +41,7 @@ Older Haier models controlled by the SmartAir2 application are using the KZW-W00
 
     KZW-W002 module pinout
 
-Newer Haier models using a module called ESP32-for-Haier. It is an ESP32 single-core board with an ESP32-S0WD chip. In some cases, you can reuse this module and flash it with ESPHome, but some new modules don’t support this. They look the same but have encryption enabled.
+Newer Haier models using a module called ESP32-for-Haier. It is an ESP32 single-core board with an ESP32-S0WD chip. In some cases, you can reuse this module and flash it with ESPHome, but some new modules don't support this. They look the same but have encryption enabled.
 
 **Warning!** The new generation of ESP32-Haier devices has encryption enabled, so they can only be flashed with firmware that is signed with a private key. There is no way to make them work with ESPHome, so if you try to do it, the board will get into a boot loop with the error ``rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)`` The only way to recover this board is to flash it with the original image. So before starting your experiments make a backup image.
 

components/logger.rst

@@ -38,7 +38,7 @@ Configuration variables:
 Advanced settings:
 
 -  **tx_buffer_size** (*Optional*, int): The size of the buffer used
-   for log messages. Decrease this if you’re having memory problems.
+   for log messages. Decrease this if you're having memory problems.
    Defaults to ``512``.
 -  **hardware_uart** (*Optional*, string): The Hardware UART to use for logging. The default varies depending on
    the specific processor/chip and framework you are using. See the :ref:`table below <logger-default_hardware_interfaces>`.
@@ -75,7 +75,7 @@ Default UART GPIO Pins
 .. list-table::
     :header-rows: 1
 
-    * - 
+    * -
       - ``UART0``
       - ``UART0_SWAP``
       - ``UART1``
@@ -140,7 +140,7 @@ the original ESP32 or ESP8266) continue to use USB-to-serial bridge ICs for comm
 .. list-table::
     :header-rows: 1
 
-    * - 
+    * -
       - Arduino
       - ESP-IDF
     * - ESP8266
@@ -215,7 +215,7 @@ log level for it, first identify the tag of the log messages in question
 and then disable them in your configuration.
 
 Suppose we want to have verbose log messages globally, but the MQTT
-client spams too much. In the following example, we’d first see that the
+client spams too much. In the following example, we'd first see that the
 tag of the MQTT client is ``mqtt.client`` (before the first colon) and
 the tag for MQTT components is ``mqtt.component``.
 

components/lvgl/index.rst

@@ -533,7 +533,7 @@ It can arrange items into rows or columns (tracks), handle wrapping, adjust spac
         - ``END``: means right horizontally and bottom vertically.
         - ``CENTER``: simply center.
         - ``SPACE_EVENLY``: items are distributed so that the spacing between any two items (and the space to the edges) is equal. Does not apply to ``flex_align_track``.
-        - ``SPACE_AROUND``: items are evenly distributed in the track with equal space around them. Note that visually the spaces aren’t equal, since all the items have equal space on both sides. The first item will have one unit of space against the container edge, but two units of space between the next item because that next item has its own spacing that applies. Does not apply to ``flex_align_track``.
+        - ``SPACE_AROUND``: items are evenly distributed in the track with equal space around them. Note that visually the spaces aren't equal, since all the items have equal space on both sides. The first item will have one unit of space against the container edge, but two units of space between the next item because that next item has its own spacing that applies. Does not apply to ``flex_align_track``.
         - ``SPACE_BETWEEN``: items are evenly distributed in the track: first item is on the start line, last item on the end line. Does not apply to ``flex_align_track``.
 
     - **pad_row** (*Optional*, int16): Set the padding between the rows, in pixels.
@@ -597,7 +597,7 @@ Values for use with ``grid_column_align``, ``grid_row_align``, ``grid_cell_x_ali
         - ``CENTER``: simply center.
         - ``STRETCH``: stretch the widget to the cell in the respective direction. Does not apply to ``grid_column_align``, ``grid_row_align``.
         - ``SPACE_EVENLY``: items are distributed so that the spacing between any two items (and the space to the edges) is equal.
-        - ``SPACE_AROUND``: items are evenly distributed in the track with equal space around them. Note that visually the spaces aren’t equal, since all the items have equal space on both sides. The first item will have one unit of space against the container edge, but two units of space between the next item because that next item has its own spacing that applies.
+        - ``SPACE_AROUND``: items are evenly distributed in the track with equal space around them. Note that visually the spaces aren't equal, since all the items have equal space on both sides. The first item will have one unit of space against the container edge, but two units of space between the next item because that next item has its own spacing that applies.
         - ``SPACE_BETWEEN``: items are evenly distributed in the track: first item is on the start line, last item on the end line.
 
 .. code-block:: yaml

components/modbus_controller.rst

@@ -398,8 +398,8 @@ An example is an SDM meter, with interesting data in register addresses 0, 2, 4
 
 The configuration above will generate *one* modbus command *read multiple registers from 0 to 6*.
 
-Maybe you don’t care about the data in register addresses 2 and 4, which are voltage values for Phase 2 and Phase 3 (or you have a SDM-120).
-Of course, you can delete the sensors your don’t care about, but then you'd have a gap in the addresses. If you remove the registers at address 2 and 4, *two* commands will be generated -- *read register 0* and *read register 6*. To avoid generating multiple commands and thus reduce activity on the bus, ``register_count`` can be used to fill the gaps:
+Maybe you don't care about the data in register addresses 2 and 4, which are voltage values for Phase 2 and Phase 3 (or you have a SDM-120).
+Of course, you can delete the sensors your don't care about, but then you'd have a gap in the addresses. If you remove the registers at address 2 and 4, *two* commands will be generated -- *read register 0* and *read register 6*. To avoid generating multiple commands and thus reduce activity on the bus, ``register_count`` can be used to fill the gaps:
 
 .. code-block:: yaml
 

components/mqtt.rst

@@ -52,7 +52,7 @@ Configuration variables:
   discovery messages so that entities are added automatically on Home
   Assistant restart. Defaults to ``true``.
 - **discovery_prefix** (*Optional*, string): The prefix to use for Home
-  Assistant’s MQTT discovery. Should not contain trailing slash.
+  Assistant's MQTT discovery. Should not contain trailing slash.
   Defaults to ``homeassistant``.
 - **discovery_unique_id_generator** (*Optional*, string): The unique_id generator
   to use. Can be one of ``legacy`` or ``mac``. Defaults to ``legacy``, which
@@ -65,7 +65,7 @@ Configuration variables:
   `Abbreviations <https://www.home-assistant.io/docs/mqtt/discovery/>`__
   in discovery messages. Defaults to ``true``.
 - **topic_prefix** (*Optional*, string): The prefix used for all MQTT
-  messages. Should not contain trailing slash. Defaults to ``<APP_NAME>``. 
+  messages. Should not contain trailing slash. Defaults to ``<APP_NAME>``.
   Use ``null`` to disable publishing or subscribing of any MQTT topic unless
   it is explicitly configured.
 - **log_topic** (*Optional*, :ref:`mqtt-message`): The topic to send MQTT log
@@ -246,10 +246,10 @@ And that should already be it 🎉 All devices defined through ESPHome should sh
 in the entities section of Home Assistant.
 
 When adding new entities, you might run into trouble with old entities
-still appearing in Home Assistant’s front-end. This is because in order
+still appearing in Home Assistant's front-end. This is because in order
 to have Home Assistant “discover” your devices on restart, all discovery
 MQTT messages need to be retained. Therefore the old entities will also
-re-appear on every Home Assistant restart even though they’re in
+re-appear on every Home Assistant restart even though they're in
 ESPHome anymore.
 
 To fix this, ESPHome has a simple helper script that purges stale
@@ -288,7 +288,7 @@ By default, ESPHome will prefix all messages with your node name or
 ``topic_prefix`` if you have specified it manually. The client id will
 automatically be generated by using your node name and adding the MAC
 address of your device to it. Next, discovery is enabled by default with
-Home Assistant’s default prefix ``homeassistant``.
+Home Assistant's default prefix ``homeassistant``.
 
 If you want to prefix all MQTT messages with a different prefix, like
 ``home/living_room``, you can specify a custom ``topic_prefix`` in the

components/output/ledc.rst

@@ -19,7 +19,7 @@ Configuration variables:
 - **pin** (**Required**, :ref:`config-pin`): The pin to use LEDC on. Can only be GPIO0-GPIO33.
 - **id** (**Required**, :ref:`config-id`): The id to use for this output component.
 - **frequency** (*Optional*, float): At which frequency to run the LEDC
-  channel’s timer. Defaults to 1000Hz.
+  channel's timer. Defaults to 1000Hz.
 - All other options from :ref:`Output <config-output>`.
 
 Advanced options:

components/power_supply.rst

@@ -7,9 +7,9 @@ Power Supply Component
     :keywords: power, ATX
 
 The ``power_supply`` component allows you to have a high power mode for
-certain outputs. For example, if you’re using an `ATX power
+certain outputs. For example, if you're using an `ATX power
 supply <https://en.wikipedia.org/wiki/ATX>`__ to power your LED strips,
-you usually don’t want to have the power supply on all the time while
+you usually don't want to have the power supply on all the time while
 the output is not on. The power supply component can be attached to any
 :ref:`Output Component <output>` and
 will automatically switch on if any of the outputs are on. Furthermore,
@@ -66,7 +66,7 @@ to be inverted.
           inverted: true
 
 Then simply connect the green control wire from the ATX power supply to
-your specified pin. It’s recommended to put a small resistor (about 1kΩ)
+your specified pin. It's recommended to put a small resistor (about 1kΩ)
 in between to protect the ESP board.
 
 See Also

components/sensor/dsmr.rst

@@ -9,7 +9,7 @@ Component/Hub
 -------------
 
 The DSMR component connects to Dutch Smart Meters which comply to DSMR (Dutch Smart Meter
-Requirements), also known as ‘Slimme meter’ or ‘P1 port’.
+Requirements), also known as 'Slimme meter' or 'P1 port'.
 
 This component supports plain non encrypted telegrams and also encrypted as used in Luxembourg.
 In case your equipment has encryption you must get a 32 character long encryption key from your energy company.
@@ -256,8 +256,8 @@ Configuration variables:
 
   - All options from :ref:`Text Sensor <config-text_sensor>`.
 
-- **telegram** (*Optional*): The (decrypted) unparsed telegram, marked as internal sensor. 
-  Can also be used to trigger an action based on the last values. 
+- **telegram** (*Optional*): The (decrypted) unparsed telegram, marked as internal sensor.
+  Can also be used to trigger an action based on the last values.
 
   - All other options from :ref:`Text Sensor <config-text_sensor>`.
 
@@ -414,7 +414,7 @@ You can use another uart to supply another P1 receiver with the same telegram. S
       uart_id: p1_uart
       max_telegram_length: 1700
 
-    # log the telegram and pass telegram to p1_bridge_uart 
+    # log the telegram and pass telegram to p1_bridge_uart
     text_sensor:
       - platform: dsmr
         telegram:

components/sensor/index.rst

@@ -206,10 +206,10 @@ Filters are applied in the order they are defined in your configuration.
 Example: Converting Celsius to Fahrenheit
 -----------------------------------------
 
-While I personally don’t like the Fahrenheit temperature scale, I do
+While I personally don't like the Fahrenheit temperature scale, I do
 understand that having temperature values appear in the Fahrenheit unit
 is quite useful to some users. ESPHome uses the Celsius temperature
-unit internally, and I’m not planning on making converting between the
+unit internally, and I'm not planning on making converting between the
 two simple (😉), but you can use this filter to convert Celsius values to
 Fahrenheit.
 

components/sensor/ld2420.rst

@@ -230,7 +230,7 @@ Configuration variables:
   ``max_gate_distance`` - 1. Each increment equals 70 cm. Defaults to 1. **Required** when ``presence_timeout`` and
   ``max_gate_distance`` is specified. May contain any options from :ref:`Number <config-number>`.
 - **max_gate_distance** (*Optional*): Maximum gate for movement detection. Value from 1 to 15. Each gate detects
-  movement and still energy at 70 cm increments. At the maximum value, the sensor’s range equates to 16 * 70 cm
+  movement and still energy at 70 cm increments. At the maximum value, the sensor's range equates to 16 * 70 cm
   resulting in an approximately 12-meter range; however, accuracy at this range may be diminished. The recommended
   maximum value is 12 * 70 cm which results in approximately 9 meters. **Required** when ``presence_timeout`` and
   ``min_gate_distance`` is specified. May contain any options from :ref:`Number <config-number>`.