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