Spelling fixes (#4532)

* Spelling fixes

* "It's" -> "its" fixes

* Fix capitalization of "Pi" in "Raspberry Pi"

"Pi", not "PI" or "pi".

source/_docs/ecosystem/appdaemon/api.markdown

@@ -22,13 +22,13 @@ import homeassistant.appapi as appapi
 class MotionLights(appapi.AppDaemon):
 ```
 
-When configured as an app in the config file (more on that later) the lifecycle of the App begins. It will be instantiated as an object by AppDaemon, and immediately, it will have a call made to it's `initialize()` function - this function must appear as part of every app:
+When configured as an app in the config file (more on that later) the lifecycle of the App begins. It will be instantiated as an object by AppDaemon, and immediately, it will have a call made to its `initialize()` function - this function must appear as part of every app:
 
 ```python
   def initialize(self):
 ```
 
-The initialize function allows the app to register any callbacks it might need for responding to state changes, and also any setup activities. When the `initialize()` function returns, the App will be dormant until any of it's callbacks are activated.
+The initialize function allows the app to register any callbacks it might need for responding to state changes, and also any setup activities. When the `initialize()` function returns, the App will be dormant until any of its callbacks are activated.
 
 There are several circumstances under which `initialize()` might be called:
 
@@ -93,7 +93,7 @@ class = NewApp
 
 When AppDaemon sees the following configuration it will expect to find a class called `NewApp` defined in a module called `new.py` in the apps subdirectory. Apps can be placed at the root of the Apps directory or within a subdirectory, an arbitrary depth down - wherever the App is, as long as it is in some subdirectory of the Apps dir, or in the Apps dir itself, AppDaemon will find it. There is no need to include information about the path, just the name of the file itself (without the `.py`) is sufficient. If names in the subdirectories overlap, AppDir will pick one of them but the exact choice it will make is undefined.
 
-When starting the system for the first time or when reloading an App or Module, the system will log the fact in it's main log. It is often the case that there is a problem with the class, maybe a syntax error or some other problem. If that is the case, details will be output to the error log allowing the user to remedy the problem and reload.
+When starting the system for the first time or when reloading an App or Module, the system will log the fact in its main log. It is often the case that there is a problem with the class, maybe a syntax error or some other problem. If that is the case, details will be output to the error log allowing the user to remedy the problem and reload.
 
 ## {% linkable_title Steps to writing an App %}
 
@@ -154,7 +154,7 @@ Callback constraints are a feature of AppDaemon that removes the need for repeti
 
 Put simply, callback constraints are one or more conditions on callback execution that can be applied to an individual App. An App's callbacks will only be executed if all of the constraints are met. If a constraint is absent it will not be checked for.
 
-For example, the presence callback constraint can be added to an App by adding a parameter to it's configuration like this:
+For example, the presence callback constraint can be added to an App by adding a parameter to its configuration like this:
 
 ```ini
 [some_app]
@@ -565,7 +565,7 @@ self.cancel_listen_state(self.office_light_handle)
 
 ### {% linkable_title info_listen_state() %}
 
-Get information on state a callback from it's handle.
+Get information on state a callback from its handle.
 
 #### {% linkable_title Synopsis %}
 
@@ -909,7 +909,7 @@ self.cancel_timer(handle)
 
 ### {% linkable_title info_timer() %}
 
-Get information on a scheduler event from it's handle.
+Get information on a scheduler event from its handle.
 
 #### {% linkable_title Synopsis %}
 
@@ -944,7 +944,7 @@ All of the scheduler calls above support 2 additional optional arguments, `rando
 - `random_start` - start of range of the random time
 - `random_end` - end of range of the random time 
 
-`random_start` must always be numerically lower than `random_end`, they can be negative to denote a random offset before and event, or positive to denote a random offset after an event. The event would be a an absolute or relative time or sunrise/sunset depending on which scheduler call you use and these values affect the base time by the spcified amount. If not specified, they will default to `0`.
+`random_start` must always be numerically lower than `random_end`, they can be negative to denote a random offset before and event, or positive to denote a random offset after an event. The event would be an absolute or relative time or sunrise/sunset depending on which scheduler call you use and these values affect the base time by the spcified amount. If not specified, they will default to `0`.
 
 For example:
 
@@ -1463,7 +1463,7 @@ self.cancel_listen_event(handle)
 
 ### {% linkable_title info_listen_event() %}
 
-Get information on an event callback from it's handle.
+Get information on an event callback from its handle.
 
 #### {% linkable_title Synopsis %}
 
@@ -1552,7 +1552,7 @@ The custom event `MODE_CHANGE` would be subscribed to with:
 self.listen_event(self.mode_event, "MODE_CHANGE")
 ```
 
-Home Assistant can send these events in a variety of other places - within automations, and also directly from Alexa intents. Home Assistant can also listen for custom events with it's automation component. This can be used to signal from AppDaemon code back to Home Assistant. Here is a sample automation:
+Home Assistant can send these events in a variety of other places - within automations, and also directly from Alexa intents. Home Assistant can also listen for custom events with its automation component. This can be used to signal from AppDaemon code back to Home Assistant. Here is a sample automation:
 
 ```yaml
 automation:
@@ -2058,7 +2058,7 @@ OK, time travel sadly isn't really possible but it can be very useful when testi
 
 ### {% linkable_title Choosing a Start Time %}
 
-Internally, AppDaemon keeps track of it's own time relative to when it was started. This make is possible to start AppDaemon with a different start time and date to the current time. For instance to test that sunset App, start AppDaemon at a time just before sunset and see if it works as expected. To do this, simply use the "-s" argument on AppDaemon's command line. e,g,:
+Internally, AppDaemon keeps track of its own time relative to when it was started. This make is possible to start AppDaemon with a different start time and date to the current time. For instance to test that sunset App, start AppDaemon at a time just before sunset and see if it works as expected. To do this, simply use the "-s" argument on AppDaemon's command line. e,g,:
 
 ```bash
 $ appdaemon -s "2016-06-06 19:16:00"

source/_docs/ecosystem/appdaemon/reboot.markdown

@@ -10,4 +10,4 @@ footer: true
 redirect_from: /ecosystem/appdaemon/reboot/
 ---
 
-To run `AppDaemon` at reboot, I have provided a sample init script in the `./scripts` directory. These have been tested on a Raspberry PI - your mileage may vary on other systems. There is also a sample Systemd script.
+To run `AppDaemon` at reboot, I have provided a sample init script in the `./scripts` directory. These have been tested on a Raspberry Pi - your mileage may vary on other systems. There is also a sample Systemd script.

source/_docs/ecosystem/appdaemon/tutorial.markdown

@@ -23,14 +23,14 @@ So given the importance of Automation, what should Automation allow us to do? I
 - Is it open and expandable?
 - Does it run locally without any reliance on the cloud?
 
-In my opinion, Home Assistant accomplishes the majority of these very well with a combination of Automations, Scripts and Templates, and it's Restful API.
+In my opinion, Home Assistant accomplishes the majority of these very well with a combination of Automations, Scripts and Templates, and its Restful API.
 
 So why `AppDaemon`? AppDaemon is not meant to replace Home Assistant Automations and Scripts, rather complement them. For a lot of things, automations work well and can be very succinct. However, there is a class of more complex automations for which they become harder to use, and appdeamon then comes into its own. It brings quite a few things to the table:
 
 - New paradigm - some problems require a procedural and/or iterative approach, and `AppDaemon` Apps are a much more natural fit for this. Recent enhancements to Home Assistant scripts and templates have made huge strides, but for the most complex scenarios, Apps can do things that Automations can't
 - Ease of use - AppDaemon's API is full of helper functions that make programming as easy and natural as possible. The functions and their operation are as "Pythonic" as possible, experienced Python programmers should feel right at home.
 - Reuse - write a piece of code once and instantiate it as an app as many times as you need with different parameters e.g. a motion light program that you can use in 5 different places around your home. The code stays the same, you just dynamically add new instances of it in the config file
-- Dynamic - AppDaemon has been designed from the start to enable the user to make changes without requiring a restart of Home Assistant, thanks to it's loose coupling. However, it is better than that - the user can make changes to code and AppDaemon will automatically reload the code, figure out which Apps were using it and restart them to use the new code with out the need to restart `AppDaemon` itself. It is also possible to change parameters for an individual or multiple apps and have them picked up dynamically, and for a final trick, removing or adding apps is also picked up dynamically. Testing cycles become a lot more efficient as a result.
+- Dynamic - AppDaemon has been designed from the start to enable the user to make changes without requiring a restart of Home Assistant, thanks to its loose coupling. However, it is better than that - the user can make changes to code and AppDaemon will automatically reload the code, figure out which Apps were using it and restart them to use the new code with out the need to restart `AppDaemon` itself. It is also possible to change parameters for an individual or multiple apps and have them picked up dynamically, and for a final trick, removing or adding apps is also picked up dynamically. Testing cycles become a lot more efficient as a result.
 - Complex logic - Python's If/Else constructs are clearer and easier to code for arbitrarily complex nested logic
 - Durable variables and state - variables can be kept between events to keep track of things like the number of times a motion sensor has been activated, or how long it has been since a door opened
 - All the power of Python - use any of Python's libraries, create your own modules, share variables, refactor and re-use code, create a single app to do everything, or multiple apps for individual tasks - nothing is off limits!

source/_docs/ecosystem/backup/backup_usb.markdown

@@ -103,7 +103,7 @@ Change below path to where you placed the `usb_backup.sh` and run the following
 
 This does not automatically mount your USB drive at boot. You need to do that manually or add a line to your `/etc/fstab` file.
 
-If your drive is on `/dev/sda1`, you could add a entry to your `/etc/fstab` like so:
+If your drive is on `/dev/sda1`, you could add an entry to your `/etc/fstab` like so:
 
 ```text
 /dev/sda1  /media               ext4    defaults,noatime  0       1

source/_docs/ecosystem/certificates/lets_encrypt.markdown

@@ -241,7 +241,7 @@ In cases where your ISP blocks port 80 you will need to change the port forward
 Now SSH in to the device your Home Assistant is running on.
 
 <p class='note'>
-If you're running the 'standard' setup on a Raspberry Pi the chances are you just logged in as the 'pi' user. If not, you may have logged in as the Home Assistant user. There are commands below that require the Home Assistant user to be on the `sudoers` list. If you are not using the 'standard' pi setup it is presumed you will know how to get your Home Assistant user on the `sudoers` list before continuing.  If you are running the 'standard' pi setup, from your 'pi' user issue the following command (where `hass` is the Home Assistant user):
+If you're running the 'standard' setup on a Raspberry Pi the chances are you just logged in as the 'pi' user. If not, you may have logged in as the Home Assistant user. There are commands below that require the Home Assistant user to be on the `sudoers` list. If you are not using the 'standard' Pi setup it is presumed you will know how to get your Home Assistant user on the `sudoers` list before continuing.  If you are running the 'standard' Pi setup, from your 'pi' user issue the following command (where `hass` is the Home Assistant user):
 
 ```
 $ sudo adduser hass sudo

source/_docs/ecosystem/hass-configurator.markdown

@@ -109,7 +109,7 @@ Since the configurator script on its own is no service, you will have to take so
 
 1. Fork the process into the background with the command:  
 `nohup sudo ./configurator.py &`
-2. If your system is using systemd (that's usually what you'll find on a Raspberry PI), there's a [template file](https://github.com/danielperna84/hass-configurator/blob/master/hass-poc-configurator.systemd) you can use and then apply the same process to integrate it as mentioned in the [Home Assistant documentation](https://home-assistant.io/docs/autostart/systemd/). If you use this method you have to set the `BASEPATH` variable according to your environment.
+2. If your system is using systemd (that's usually what you'll find on a Raspberry Pi), there's a [template file](https://github.com/danielperna84/hass-configurator/blob/master/hass-poc-configurator.systemd) you can use and then apply the same process to integrate it as mentioned in the [Home Assistant documentation](https://home-assistant.io/docs/autostart/systemd/). If you use this method you have to set the `BASEPATH` variable according to your environment.
 3. If you have [supervisor](http://supervisord.org/) running on your system, [hass-poc-configurator.supervisor](https://github.com/danielperna84/hass-configurator/blob/master/hass-poc-configurator.supervisor) would be an example configuration you could use to control the configurator.
 4. A tool called [tmux](https://tmux.github.io/), which should be pre-installed with [HASSbian](https://home-assistant.io/docs/hassbian/).
 5. A tool called [screen](http://ss64.com/bash/screen.html) (alternative to tmux). If it's not already installed on your system, you can do `sudo apt-get install screen` or `sudo yum install screen` to get it. When it's installed, start a screen session by executing `screen`. Then navigate to your Home Assistant directory and start the configurator like described above. Put the screen session into the background by pressing `CTRL+A` and then `CTRL+D`. It is now safe to disconnect from your SSH session.