Fixed common spelling mistakes (#3544)

* fix spelling errors

* Update binary_sensor.xiaomi_aqara.markdown

Reverts to previous revision before spell check.

* Update tellstick.markdown

Reverts to previous revision before spell check.

* Update owntracks_two_mqtt_broker.markdown

Reverts to previous revision before spell check.

* Update cla_sign.html

Reverts to previous revision before spell check.

* Update credits.markdown

Reverts to previous revision before spell check.

* Update api.markdown

Fixed spell checker changing noone to no one.

source/_docs/autostart/init.d.markdown

@@ -46,7 +46,7 @@ If HA does not start, check the log file output for errors at `/var/opt/homeassi
 
 ### {% linkable_title Extra: Running commands before hass executes %}
 
-If any commands need to run before executing hass (like loading a virutal environment), put them in PRE_EXEC. This command must end with a semicolon.
+If any commands need to run before executing hass (like loading a virtual environment), put them in PRE_EXEC. This command must end with a semicolon.
 
 ### {% linkable_title Daemon script %}
 

source/_docs/autostart/upstart.markdown

@@ -35,7 +35,7 @@ Upstart will launch init scripts that are located in the directory `/etc/init.d/
 #
 # Installation:
 #   1) If any commands need to run before executing hass (like loading a
-#      virutal environment), put them in PRE_EXEC. This command must end with
+#      virtual environment), put them in PRE_EXEC. This command must end with
 #      a semicolon.
 #   2) Set RUN_AS to the username that should be used to execute hass.
 #   3) Copy this script to /etc/init.d/

source/_docs/configuration/events.markdown

@@ -27,8 +27,8 @@ Event `state_changed` is fired when a state changes. Both `old_state` and `new_s
 Field | Description
 ----- | -----------
 `entity_id` | Entity ID of the changed entity. Example: `light.kitchen`
-`old_state` | The previous state of the entity before it changed. This field is ommitted if the entity is new.
-`new_state` | The new state of the entity. This field is ommitted if the entity is removed from the state machine.
+`old_state` | The previous state of the entity before it changed. This field is omitted if the entity is new.
+`new_state` | The new state of the entity. This field is omitted if the entity is removed from the state machine.
 
 
 ### {% linkable_title Event `time_changed` %}

source/_docs/configuration/packages.markdown

@@ -24,7 +24,7 @@ homeassistant:
 
 The package configuration can include: `switch`, `light`, `automation`, `groups` or the majority of the Home Assistant components. 
 
-It can be specified inline or in a seperate YAML file using `!include`.
+It can be specified inline or in a separate YAML file using `!include`.
 
 Inline example, main `configuration.yaml`:
 

source/_docs/ecosystem/appdaemon.markdown

@@ -24,7 +24,7 @@ AppDaemon is not meant to replace Home Assistant Automations and Scripts, rather
 - 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!
 
-It is in fact a testament to Home Assistant's open nature that a component like `AppDaemon` can be integrated so neatly and closely that it acts in all ways like an extension of the system, not a second class citizen. Part of the strength of Home Assistant's underlying design is that it makes no assumptions whatsoever about what it is controlling, reacting to, or reporting state on. This is made achievable in part by the great flexibility of Python as a programming environment for Home Assistant, and carrying that forward has enabled me to use the same philosophy for `AppDaemon` - it took surprisingly little code to be able to respond to basic events and call services in a completely open ended manner. The bulk of the work after that was adding additonal functions to make things that were already possible easier.
+It is in fact a testament to Home Assistant's open nature that a component like `AppDaemon` can be integrated so neatly and closely that it acts in all ways like an extension of the system, not a second class citizen. Part of the strength of Home Assistant's underlying design is that it makes no assumptions whatsoever about what it is controlling, reacting to, or reporting state on. This is made achievable in part by the great flexibility of Python as a programming environment for Home Assistant, and carrying that forward has enabled me to use the same philosophy for `AppDaemon` - it took surprisingly little code to be able to respond to basic events and call services in a completely open ended manner. The bulk of the work after that was adding additional functions to make things that were already possible easier.
 
 # How it Works
 

source/_docs/ecosystem/appdaemon/api.markdown

@@ -495,7 +495,7 @@ Note: `old` and `new` can be used singly or together.
 
 ##### {% linkable_title duration =  <seconds> (optional) %}
 
-If duration is supplied as a parameter, the callback will not fire unless the state listened for is maintained for that number of seconds. This makes the most sense if a specific attribute is specified (or the default os `state` is used), an in conjunction with the `old` or `new` parameters, or both. When the callback is called, it is supplied with the values of `entity`, `attr`, `old` and `new` that were current at the time the actual event occured, since the assumption is that none of them have changed in the intervening period.
+If duration is supplied as a parameter, the callback will not fire unless the state listened for is maintained for that number of seconds. This makes the most sense if a specific attribute is specified (or the default os `state` is used), an in conjunction with the `old` or `new` parameters, or both. When the callback is called, it is supplied with the values of `entity`, `attr`, `old` and `new` that were current at the time the actual event occurred, since the assumption is that none of them have changed in the intervening period.
 
 ```python
   def my_callback(self, **kwargs):
@@ -643,7 +643,7 @@ Delay, in seconds before the callback is invoked.
 
 ##### {% linkable_title \*\*kwargs %}
 
-Arbitary keyword parameters to be provided to the callback function when it is invoked.
+Arbitrary keyword parameters to be provided to the callback function when it is invoked.
 
 #### {% linkable_title Examples %}
 
@@ -677,7 +677,7 @@ A Python `time` object that specifies when the callback will occur. If the time
 
 ##### {% linkable_title \*\*kwargs %}
 
-Arbitary keyword parameters to be provided to the callback function when it is invoked.
+Arbitrary keyword parameters to be provided to the callback function when it is invoked.
 
 #### {% linkable_title Examples %}
 
@@ -715,7 +715,7 @@ A Python `datetime` object that specifies when the callback will occur.
 
 ##### {% linkable_title \*\*kwargs %}
 
-Arbitary keyword parameters to be provided to the callback function when it is invoked.
+Arbitrary keyword parameters to be provided to the callback function when it is invoked.
 
 #### {% linkable_title Examples %}
 
@@ -754,7 +754,7 @@ A Python `time` object that specifies when the callback will occur. If the time
 
 ##### {% linkable_title \*\*kwargs %}
 
-Arbitary keyword parameters to be provided to the callback function when it is invoked.
+Arbitrary keyword parameters to be provided to the callback function when it is invoked.
 
 #### {% linkable_title Examples %}
 
@@ -792,7 +792,7 @@ A Python `time` object that specifies when the callback will occur, the hour com
 
 ##### {% linkable_title \*\*kwargs %}
 
-Arbitary keyword parameters to be provided to the callback function when it is invoked.
+Arbitrary keyword parameters to be provided to the callback function when it is invoked.
 
 #### {% linkable_title Examples %}
 
@@ -829,7 +829,7 @@ A Python `time` object that specifies when the callback will occur, the hour and
 
 ##### {% linkable_title \*\*kwargs %}
 
-Arbitary keyword parameters to be provided to the callback function when it is invoked.
+Arbitrary keyword parameters to be provided to the callback function when it is invoked.
 
 #### {% linkable_title Examples %}
 
@@ -871,7 +871,7 @@ After the initial callback has occurred, another will occur every `repeat` secon
 
 ##### {% linkable_title \*\*kwargs %}
 
-Arbitary keyword parameters to be provided to the callback function when it is invoked.
+Arbitrary keyword parameters to be provided to the callback function when it is invoked.
 
 #### {% linkable_title Examples %}
 
@@ -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 whcih 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 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`.
 
 For example:
 
@@ -987,7 +987,7 @@ The time in seconds that the callback should be delayed after sunrise. A negativ
 
 ##### {% linkable_title \*\*kwargs %}
 
-Arbitary keyword parameters to be provided to the callback function when it is invoked.
+Arbitrary keyword parameters to be provided to the callback function when it is invoked.
 
 #### {% linkable_title Examples %}
 
@@ -1030,7 +1030,7 @@ The time in seconds that the callback should be delayed after sunrise. A negativ
 
 ##### {% linkable_title \*\*kwargs %}
 
-Arbitary keyword parameters to be provided to the callback function when it is invoked.
+Arbitrary keyword parameters to be provided to the callback function when it is invoked.
 
 #### {% linkable_title Examples %}
 

source/_docs/ecosystem/appdaemon/configuration.markdown

@@ -36,7 +36,7 @@ class = HelloWorld
 - `logfile` (optional) is the path to where you want `AppDaemon` to keep its main log. When run from the command line this is not used - log messages come out on the terminal. When running as a daemon this is where the log information will go. In the example above I created a directory specifically for AppDaemon to run from, although there is no reason you can't keep it in the `appdaemon` directory of the cloned repository. If `logfile = STDOUT`, output will be sent to stdout instead of stderr when running in the foreground, if not specified, output will be sent to STDOUT.
 - `errorfile` (optional) is the name of the logfile for errors - this will usually be errors during compilation and execution of the apps. If `errorfile = STDERR` errors will be sent to stderr instead of a file, if not specified, output will be sent to STDERR.
 - `app_dir` (optional) is the directory the apps are placed in. If not specified, AppDaemon will look first in `~/.homeassistant` then `/etc/appdaemon` for a subdirectory named `apps`
-- `threads` - the number of dedicated worker threads to create for running the apps. Note, this will bear no resembelance to the number of apps you have, the threads are re-used and only active for as long as required to tun a particular callback or initialization, leave this set to 10 unless you experience thread starvation
+- `threads` - the number of dedicated worker threads to create for running the apps. Note, this will bear no resemblance to the number of apps you have, the threads are re-used and only active for as long as required to tun a particular callback or initialization, leave this set to 10 unless you experience thread starvation
 - `latitude`, `longitude`, `elevation`, `timezone` - should all be copied from your Home Assistant configuration file
 - `cert_path` (optional) - path to root CA cert directory - use only if you are using self signed certs.
 

source/_docs/ecosystem/appdaemon/tutorial.markdown

@@ -35,7 +35,7 @@ So why `AppDaemon`? AppDaemon is not meant to replace Home Assistant Automations
 - 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!
 
-It is in fact a testament to Home Assistant's open nature that a component like `AppDaemon` can be integrated so neatly and closely that it acts in all ways like an extension of the system, not a second class citizen. Part of the strength of Home Assistant's underlying design is that it makes no assumptions whatever about what it is controlling or reacting to, or reporting state on. This is made achievable in part by the great flexibility of Python as a programming environment for Home Assistant, and carrying that forward has enabled me to use the same philosophy for `AppDaemon` - it took surprisingly little code to be able to respond to basic events and call services in a completely open ended manner - the bulk of the work after that was adding additonal functions to make things that were already possible easier.
+It is in fact a testament to Home Assistant's open nature that a component like `AppDaemon` can be integrated so neatly and closely that it acts in all ways like an extension of the system, not a second class citizen. Part of the strength of Home Assistant's underlying design is that it makes no assumptions whatever about what it is controlling or reacting to, or reporting state on. This is made achievable in part by the great flexibility of Python as a programming environment for Home Assistant, and carrying that forward has enabled me to use the same philosophy for `AppDaemon` - it took surprisingly little code to be able to respond to basic events and call services in a completely open ended manner - the bulk of the work after that was adding additional functions to make things that were already possible easier.
 
 ## {% linkable_title How it Works %}
 

source/_docs/ecosystem/appdaemon/windows.markdown

@@ -19,4 +19,4 @@ AppDaemon can be installed exactly as per the instructions for every other versi
 
 ## {% linkable_title Windows Under the Linux Subsystem %}
 
-Windows 10 now supports a full Linux bash environment that is capable of running Python. This is essentially an Ubuntu distribution and works extremely well. It is possible to run AppDaemon in exactly the same way as for Linux distributions, and none of the above Windows Caveats apply to this version. This is the reccomended way to run AppDaemon in a Windows 10 and later environment.
+Windows 10 now supports a full Linux bash environment that is capable of running Python. This is essentially an Ubuntu distribution and works extremely well. It is possible to run AppDaemon in exactly the same way as for Linux distributions, and none of the above Windows Caveats apply to this version. This is the recommended way to run AppDaemon in a Windows 10 and later environment.

source/_docs/ecosystem/backup/backup_dropbox.markdown

@@ -18,7 +18,7 @@ You need two parts in order to get it working correctly.
 
 Become the user that run Home Assistant.
 
-- A seperate Python script that syncs a specific folder. Which can be found [here](https://gist.github.com/riemers/31e3350041fd3e47e489cbc811209d6f)
+- A separate Python script that syncs a specific folder. Which can be found [here](https://gist.github.com/riemers/31e3350041fd3e47e489cbc811209d6f)
 - The excellent [dropbox uploader script](https://github.com/andreafabrizi/Dropbox-Uploader/blob/master/dropbox_uploader.sh) you can grab the .sh file only.
 
 Download those files to a folder of your liking, after that edit both files and change paths accordingly.
@@ -46,7 +46,7 @@ Do note, this will **backup your passwords to Dropbox**.
 
 ### {% linkable_title Automate the backup %}
 
-So you just made a full backup, next time you want it to be done automaticly. Since your database can change and so do other files over time.
+So you just made a full backup, next time you want it to be done automatically. Since your database can change and so do other files over time.
 Add it to your crontab, edit the **path/to** part.
 
 ```bash

source/_docs/ecosystem/backup/backup_github.markdown

@@ -30,7 +30,7 @@ Some best practices to consider before putting your configuration on GitHub:
 
 - Extensive use of [secrets.yaml](https://home-assistant.io/topics/secrets/) to hide sensitive information like usernames, passwords, device information, and location
 - Exclusion of some files, including `secrets.yaml` and device-specific information using a [`.gitignore`](https://git-scm.com/docs/gitignore) file
-- Regularly commiting your configuration to GitHub to make sure that your backup is up to date
+- Regularly committing your configuration to GitHub to make sure that your backup is up to date
 - Use a README.md to document your configuration and include screenshots of your Home Assistant GUI
 
 ### {% linkable_title Step 1: Installing and Initializing Git %}
@@ -127,7 +127,7 @@ git push origin master
 exit
 ```
 
-Every time you run this script, you will be prompted for a comment to describe the change(s) that you are commiting. This comment will be displayed beside each changed file on GitHub and will be stored after each commit.  You will also be asked to enter your GitHub username and password (or ssh key passphrase if you use [GitHub with ssh](https://help.github.com/categories/ssh/)).
+Every time you run this script, you will be prompted for a comment to describe the change(s) that you are committing. This comment will be displayed beside each changed file on GitHub and will be stored after each commit.  You will also be asked to enter your GitHub username and password (or ssh key passphrase if you use [GitHub with ssh](https://help.github.com/categories/ssh/)).
 
 ### {% linkable_title Step 7: Configuration file testing %}
 
@@ -162,7 +162,7 @@ home_elevation: 0
 
 ### {% linkable_title Extra commands %}
 
-You can enter these commands to get a list of the files in your local git repository and a status of files that have changed but not commited yet:
+You can enter these commands to get a list of the files in your local git repository and a status of files that have changed but not committed yet:
 
 
 ```bash

source/_docs/ecosystem/backup/backup_usb.markdown

@@ -101,7 +101,7 @@ Change below path to where you placed the `usb_backup.sh` and run the following
 
 ### {% linkable_title Auto mount %}
 
-This does not automaticly mount your USB drive at boot. You need to do that manually or add a line to your `/etc/fstab` file.
+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:
 

source/_docs/ecosystem/certificates/lets_encrypt.markdown

@@ -24,7 +24,7 @@ This guide was added by mf_social on 16/03/2017 and was valid at the time of wri
  * You are not currently running anything on port 80 on your network (you'd know if you were).
  * If you are not using Home Assistant on a Debian/Raspian/Hassbian system you will be able to convert any of the terminology I use in to the correct syntax for your system.
  * You understand that this is a 'guide' covering the general application of these things to the general masses and there are things outside of the scope of it, and it does not cover every eventuality (although I have made some notes where people may stumble). Also, I have used some turns of phrase to make it easier to understand for the novice reader which people of advanced knowledge may say is innacurate.  My goal here is to get you through this guide with a satisfactory outcome and have a decent understanding of what you are doing and why, not to teach you advanced internet communication protocols.
- * Each step presumes you have fully completed the previous step succesfully, so if you did an earlier step following a different guide, please ensure that you have not missed anything out that may affect the step you have jumped to, and ensure that you adapt any commands to take in to account different file placements from other guides.
+ * Each step presumes you have fully completed the previous step successfully, so if you did an earlier step following a different guide, please ensure that you have not missed anything out that may affect the step you have jumped to, and ensure that you adapt any commands to take in to account different file placements from other guides.
  
 Steps we will take:
  
@@ -358,11 +358,11 @@ If you were previously using a webapp on your phone/tablet to access your Home A
 https://home-assistant.io/docs/frontend/mobile/
 ```
 
-All done? Accessing your Home Assistant from across the world with your DuckDNS URL and a lovely secure logo on your browser? Ace! Now let's clean up our port forwards so that we are only exposing the parts of our network that are absolutely neccesary to the outside world.
+All done? Accessing your Home Assistant from across the world with your DuckDNS URL and a lovely secure logo on your browser? Ace! Now let's clean up our port forwards so that we are only exposing the parts of our network that are absolutely necessary to the outside world.
 
 ### {% linkable_title 6 - Clean up port forwards %}
 
-In step 2 we created a port forwarding rule called `ha_test`. This opens port 8123 to the world, and is no longer neccessary.
+In step 2 we created a port forwarding rule called `ha_test`. This opens port 8123 to the world, and is no longer necessary.
 
 Go to your router's configuration pages and delete the `ha_test` rule.
 
@@ -402,7 +402,7 @@ $ sudo apt-get install ssl-cert-check
 ```
 
 <p class='note'>
-In cases where, for whatever reason, apt-get installing is not appropriate for your installation you can fetch the ssl-cert-check script from `http://prefetch.net/code/ssl-cert-check` bearing in mind that you will have to modify the command in the sensor code below to run the script from wherever you put it, modify permission if neccessary and so on.
+In cases where, for whatever reason, apt-get installing is not appropriate for your installation you can fetch the ssl-cert-check script from `http://prefetch.net/code/ssl-cert-check` bearing in mind that you will have to modify the command in the sensor code below to run the script from wherever you put it, modify permission if necessary and so on.
 </p>
 
 To set up a senor add the following to your `configuration.yaml` (remembering to correct the URL for your DuckDNS):
@@ -433,7 +433,7 @@ If you are a TWO-RULE person (from step 6), you can automatically renew your cer
 There are a number of options for automating the renewal process:
  
 #### Option 1:
-Your certificate can be renewed as a 'cron job' - cron jobs are background tasks run by the computer at specified intervals (and are totally independant of Home Assistant). Defining cron is outside of the scope of this guide but you will have had dealings with `crontab` when setting up DuckDNS in step 3
+Your certificate can be renewed as a 'cron job' - cron jobs are background tasks run by the computer at specified intervals (and are totally independent of Home Assistant). Defining cron is outside of the scope of this guide but you will have had dealings with `crontab` when setting up DuckDNS in step 3
  
 To set a cron job to run the script at regular intervals:
  

source/_docs/ecosystem/hass-configurator.markdown

@@ -42,7 +42,7 @@ There are no dependencies on Python modules that are not part of the standard li
 
 ### {% linkable_title Configuration %}
 Near the top of the configurator.py-file you will find some global variables you can change to customize the configurator. If you are unfamiliar with Python: when setting variables of the type _string_, you have to write that within quotation marks. The default settings are fine for just checking out the configurator quickly. With more customized setups you should change some settings though.  
-To keep your settings across updates it is also possible to save settings in an external file. In that case copy [settings.conf](https://github.com/danielperna84/hass-configurator/blob/master/settings.conf) whereever you like and append the full path to the file to the command when starting the configurator. E.g. `sudo .configurator.py /home/homeassistant/.homeassistant/mysettings.conf`. This file is in JSON format. So make sure it has a valid syntax (you can set the editor to JSON to get syntax highlighting for the settings). The major difference to the settings in the py-file is, that `None` becomes `null`.
+To keep your settings across updates it is also possible to save settings in an external file. In that case copy [settings.conf](https://github.com/danielperna84/hass-configurator/blob/master/settings.conf) wherever you like and append the full path to the file to the command when starting the configurator. E.g. `sudo .configurator.py /home/homeassistant/.homeassistant/mysettings.conf`. This file is in JSON format. So make sure it has a valid syntax (you can set the editor to JSON to get syntax highlighting for the settings). The major difference to the settings in the py-file is, that `None` becomes `null`.
 
 #### LISTENIP (string)
 The IP the service is listening on. By default it is binding to `0.0.0.0`, which is every interface on the system.

source/_docs/ecosystem/ios/location.markdown

@@ -12,7 +12,7 @@ redirect_from: /ecosystem/ios/location/
 
 ## {% linkable_title Location tracking when outside a Home Assistant zone %}
 
-Home Assistant for iOS receives _significant location updates_ from iOS. Whenever an update is received, it is sent to Home Assistant. Roughly, an update is received everytime that your device transfers to a new cellular tower, a significant amount of time has passed (usually a couple hours) or a connection state changes and the system notices your location recently changed.
+Home Assistant for iOS receives _significant location updates_ from iOS. Whenever an update is received, it is sent to Home Assistant. Roughly, an update is received every time that your device transfers to a new cellular tower, a significant amount of time has passed (usually a couple hours) or a connection state changes and the system notices your location recently changed.
 
 Apple [defines][apple-location-programming-guide] significant significant-change location updates as:
 

source/_docs/ecosystem/scenegen.markdown

@@ -90,7 +90,7 @@ This output can be cut and pasted into your configuration.yaml file as required
 
 Scenegen supports all documented effects for lights including transitions and flash effects, however generally it is easier to run scenegen to get the basic setup and add any effects manually later.
 
-Note that depending on the type of light there may be a delay in actually setting up its parameters and Home Assistant actually recieving that state. For instance, if you set a scene up with the Hue App, Home Assistant won't see those changes for up to 10 seconds. Turning on a ZWave light might not be seen for an entire poll interval. For this reason, its good practice to wait for a while after the scene is setup before running scenegen. Alternatively, perform all setup using the Home Assistant frontend and it will instantly have the required state for capture.
+Note that depending on the type of light there may be a delay in actually setting up its parameters and Home Assistant actually receiving that state. For instance, if you set a scene up with the Hue App, Home Assistant won't see those changes for up to 10 seconds. Turning on a ZWave light might not be seen for an entire poll interval. For this reason, its good practice to wait for a while after the scene is setup before running scenegen. Alternatively, perform all setup using the Home Assistant frontend and it will instantly have the required state for capture.
 
 ## {% linkable_title Advanced Usage %}
 

source/_docs/installation/raspberry-pi-all-in-one.markdown

@@ -62,7 +62,7 @@ To upgrade the All-In-One setup manually:
 
 *  Login to Raspberry Pi `ssh pi@your_raspberry_pi_ip`
 *  Change to homeassistant user `sudo su -s /bin/bash homeassistant`
-*  Change to virtual enviroment `source /srv/homeassistant/homeassistant_venv/bin/activate`
+*  Change to virtual environment `source /srv/homeassistant/homeassistant_venv/bin/activate`
 *  Update Home Assistant `pip3 install --upgrade homeassistant`
 *  Type `exit` to logout the hass user and return to the `pi` user.
 
@@ -70,7 +70,7 @@ To upgrade the All-In-One setup manually:
 **If you deployed Home Assistant via the AiO installer prior to December 2016**
 *  Login to Raspberry Pi `ssh pi@your_raspberry_pi_ip`
 *  Change to homeassistant user `sudo su -s /bin/bash hass`
-*  Change to virtual enviroment `source /srv/hass/hass_venv/bin/activate`
+*  Change to virtual environment `source /srv/hass/hass_venv/bin/activate`
 *  Update Home Assistant `pip3 install --upgrade homeassistant`
 *  Type `exit` to logout the hass user and return to the `pi` user.
 </div>

source/_docs/installation/raspberry-pi.markdown

@@ -1,7 +1,7 @@
 ---
 layout: page
 title: "Manual installation on a Raspberry Pi"
-description: "Instructions to install Home Assistant on a Raspberry Pi runnning Raspbian Lite."
+description: "Instructions to install Home Assistant on a Raspberry Pi running Raspbian Lite."
 date: 2016-09-05 16:00
 sidebar: true
 comments: false

source/_docs/tools/scripts.markdown

@@ -19,7 +19,7 @@ Test any changes to your `configuration.yaml` file before launching Home Assista
 $ hass --script check_config
 ```
 
-### {% linkable_title Existance of configuration %}
+### {% linkable_title Existence of configuration %}
 
 This script checks if the `configuration.yaml` file exists. If the file is not available, one is created.
 
@@ -47,7 +47,7 @@ $ hass --script benchmark async_million_events
 
 ### {% linkable_title Old scripts %}
 
-Usally those scripts were only used when a massive update happend and was announced in the release notes.
+Usually those scripts were only used when a massive update happened and was announced in the release notes.
 
 - `db_migrator`: Migrate an existing SQLite database to the new schema.
 - `influxdb_migrator`: Convert an old InfluxDB to the new format.