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/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.