Skip to content

Commit

Permalink
Fix minor typos in doc files and source code
Browse files Browse the repository at this point in the history
  • Loading branch information
rhumbertgz committed Feb 8, 2020
1 parent 22a2191 commit 5245cf4
Show file tree
Hide file tree
Showing 12 changed files with 20 additions and 20 deletions.
2 changes: 1 addition & 1 deletion README.md
@@ -1,6 +1,6 @@
# Description

AppDaemon is a loosely coupled, multithreaded, sandboxed python
AppDaemon is a loosely coupled, multi-threaded, sandboxed python
execution environment for writing automation apps for various types of Home Automation Software including [Home
Assistant](https://home-assistant.io/) and MQTT. It has a pluggable architecture allowing it to be integrated with
practically any event driven application.
Expand Down
2 changes: 1 addition & 1 deletion README.rst
@@ -1,7 +1,7 @@
Description
===========

AppDaemon is a loosely coupled, multithreaded, sandboxed python
AppDaemon is a loosely coupled, multi-threaded, sandboxed python
execution environment for writing automation apps for various types of Home Automation Software including `Home
Assistant <https://home-assistant.io/>`__ and MQTT. It has a pluggable architecture allowing it to be integrated with
practically any event driven application.
Expand Down
2 changes: 1 addition & 1 deletion appdaemon/adapi.py
Expand Up @@ -1410,7 +1410,7 @@ def register_service(self, service, cb, **kwargs):
Args:
service: Name of the service, in the format `domain/service`. If the domain does not exist it will be created
cb: A reference to the function to be called when the service is requested. This function may be a regular
function, or it may be asynch. Note that if it is an async function, it will run on AppDaemon's main loop
function, or it may be async. Note that if it is an async function, it will run on AppDaemon's main loop
meaning that any issues with the service could result in a delay of AppDaemon's core functions.
Returns:
Expand Down
8 changes: 4 additions & 4 deletions appdaemon/dashboard.py
Expand Up @@ -319,7 +319,7 @@ def _load_widget(self, dash, includes, name, css_vars, global_parameters): # no
self._log_yaml_dash_error(dash, name, exc)
return self.error_widget("Error loading widget definition")

# Substitute variables in the parsed widget definiton.
# Substitute variables in the parsed widget definition.
final_widget, templates = self._do_subs(final_widget, instantiated_widget)

#
Expand All @@ -343,7 +343,7 @@ def _load_widget(self, dash, includes, name, css_vars, global_parameters): # no
if key != "widget_type" and key not in templates:
# if it is an existing key and it is a style attribute, prepend, don't overwrite
if key in final_widget and key.find("style") != -1:
# if it is an existing key and it is a style attirpute, prepend, don't overwrite
# if it is an existing key and it is a style attribute, prepend, don't overwrite
final_widget[key] = final_widget[key] + ";" + instantiated_widget[key]
else:
final_widget[key] = instantiated_widget[key]
Expand Down Expand Up @@ -382,8 +382,8 @@ def error_widget(error):

@staticmethod
def _widget_exists(widgets, _id):
for widge in widgets:
if widge["id"] == _id:
for widget in widgets:
if widget["id"] == _id:
return True
return False

Expand Down
2 changes: 1 addition & 1 deletion appdaemon/logging.py
Expand Up @@ -156,7 +156,7 @@ def emit(self, record):
)
except Exception:
logger.warning("-" * 60)
logger.warning("Unexpected error occured in LogSubscriptionHandler.emit()")
logger.warning("Unexpected error occurred in LogSubscriptionHandler.emit()")
logger.warning("-" * 60)
logger.warning(traceback.format_exc())
logger.warning("-" * 60)
Expand Down
2 changes: 1 addition & 1 deletion conf/example_apps/momentary_switch.py
Expand Up @@ -6,7 +6,7 @@
# Args:
#
# switch: switch to make momentary e.g. switch.garage
# delay: amount of time to waut upon activation of the switch before turning it off
# delay: amount of time to wait upon activation of the switch before turning it off
#
#
# Release Notes
Expand Down
10 changes: 5 additions & 5 deletions docs/APPGUIDE.rst
Expand Up @@ -494,7 +494,7 @@ To make an App explicitly reload when only this plugin and no other is restarted
class: some_class
plugin: HASS
If you have more than one plugin, you can make an App dependent on more than one plgin by specifying a YAML list:
If you have more than one plugin, you can make an App dependent on more than one plugin by specifying a YAML list:

.. code:: yaml
Expand Down Expand Up @@ -2044,7 +2044,7 @@ Here we see the default port being remapped to port 5000 which is where
AppDamon is listening in my setup.

Since each individual Skill has its own URL it is possible to have
different skills for Home Assitant and AppDaemon.
different skills for Home Assistant and AppDaemon.

Putting it together in an App
-----------------------------
Expand Down Expand Up @@ -2404,7 +2404,7 @@ They are configured in the ``appdaemon.yaml`` file as follows:
my_namespace3:
writeback: hybrid
Here we are defining 3 new namespaces - you can have as many as you want. Ther names are ``my_namespace1``, ``my_namespace2`` and ``my_namespace3``. UDMs are written to disk so that they survive restarts, and this can be done in 3 different ways, set by the writeback parameter for each UDM. They are:
Here we are defining 3 new namespaces - you can have as many as you want. Their names are ``my_namespace1``, ``my_namespace2`` and ``my_namespace3``. UDMs are written to disk so that they survive restarts, and this can be done in 3 different ways, set by the writeback parameter for each UDM. They are:

- ``safe`` - the namespace is written to disk every time a change is made so will be up to date even if a crash happens. The downside is that there is a possible performance impact for systems with slower disks, or that set state on many UDMs at a time.
- ``performance`` - the namespace is written when AD exits, meaning that all processing is in memory for the best performance. Although this style of UDM will survive a restart, data may be lost if AppDaemon or the host crashes.
Expand Down Expand Up @@ -2529,7 +2529,7 @@ There are 2 types of sequence - predefined sequences and inline sequences.
Defining a Sequence
~~~~~~~~~~~~~~~~~~~

A predefined sequence is created by addin a ``sequence`` section to your apps.yaml file. If you have apps.yaml split into
A predefined sequence is created by adding a ``sequence`` section to your apps.yaml file. If you have apps.yaml split into
multiple files, you can have sequences defined in each one if desired. For clarity, it is strongly recommended that
sequences are created in their own standalone yaml files, ideally in a separate directory from the app argument files.

Expand Down Expand Up @@ -2587,7 +2587,7 @@ If you prefer, you can use YAML's inline capabilities for a more compact represe
- sleep: 30
- homeassistant/turn_off: {"entity_id": "light.outside"}
Sequences can be cretaed that will loop forever by adding the value ``loop: True`` to the sequence:
Sequences can be created that will loop forever by adding the value ``loop: True`` to the sequence:

.. code:: yaml
Expand Down
4 changes: 2 additions & 2 deletions docs/CONFIGURE.rst
Expand Up @@ -137,7 +137,7 @@ The following items provide a high level of control over AppDaemon's internal fu
- ``pin_apps`` (optional) - When true (the default) Apps will be pinned to a particular thread which avoids complications around re-entrant code and locking of instance variables
- ``pin_threads`` (optional) - Number of threads to use for pinned apps, allowing the user to section off a sub-pool just for pinned apps. Default is to use all threads for pinned apps.
- ``threadpool_workers`` (optional) - the number of max_workers threads to be used by AD internally to execute calls asynchronously. This defaults to ``10``.
- ``load_distribution`` - Algorithm to use for load balancing between unpinned apps. Can be ``roundrobin`` (the default), ``random`` or ``load``
- ``load_distribution`` - Algorithm to use for load balancing between unpinned apps. Can be ``round-robin`` (the default), ``random`` or ``load``
- ``timewarp`` (optional) - equivalent to the command line flag ``-t`` but will take precedence
- ``qsize_warning_threshold`` - total number of items on thread queues before a warning is issued, defaults to 50
- ``qsize_warning_step`` - when total qsize is over ````qsize_warning_threshold`` a warning will be issued every time the ``qsize_warning_step`` times the utility loop executes (normally once every second), default is 60 meaning the warning will be issued once every 60 seconds.
Expand Down Expand Up @@ -426,7 +426,7 @@ To configure the MQTT plugin, in addition to the required parameters above, you


- ``type:`` This must be declared and it must be ``mqtt``
- ``namepace:`` (optional) This will default to ``default``
- ``namespace:`` (optional) This will default to ``default``
- ``client_host:`` (optional) The IP address or DNS of the Broker. Defaults to 127.0.0.1 which is the localhost
- ``client_port:`` (optional) The port number used to access the broker. Defaults to ``1883``
- ``client_transport:`` (optional) The transport protocol used to access the broker. This can be either ``tcp`` or ``websockets`` Defaults to ``tcp``
Expand Down
2 changes: 1 addition & 1 deletion docs/DASHBOARD_CREATION.rst
Expand Up @@ -2321,7 +2321,7 @@ The skin itself consists of 2 separate files:
Dashboard.css is a regular CSS file, and knowledge of CSS is required to
make changes to it.

Variables.yaml is really a set of overrise styles, so you can use
Variables.yaml is really a set of override styles, so you can use
fragments of CSS here, basically, anything that you could normally put in
an HTML ``style`` tag. Variables .yaml also supports variable expansion
to make structuring the file easier. Anything that starts with a ``$``
Expand Down
2 changes: 1 addition & 1 deletion docs/HISTORY.rst
Expand Up @@ -58,7 +58,7 @@ None
- Added the ability to fire an event callback only once, using the ``oneshot`` flag
- Added the ability to use async functions as endpoint callback
- Added the ability for ``input_select`` to auto-update when the options changes, without need of refreshing the browser page
- Added events for when a webscoket client connects and disconnects
- Added events for when a websocket client connects and disconnects
- Added the ability for apps to register web routes, thereby utilizing AD's internal web server
- Added static folder `web`, which can used to serve content like images using AD's internal web server
- Added ability for users to define static folders, which can used to serve content like images using AD's internal web server
Expand Down
2 changes: 1 addition & 1 deletion docs/UPGRADE_FROM_2.x.rst
Expand Up @@ -7,7 +7,7 @@ Note that not all changes will apply to everyone, some of them are in fairly obs

- AppDaemon no longer supports python 3.4

This is a fairly significant step, and the decision to do this was influenced by HASS' pending end of support for Python 3.4. There are many technical reasons why this is a good thing, but the bottom line is that you will need to upgrade your pyton version to run HASS anyway, so I took this opportunity to follow suit. AppDaemon 3.0 will remain in beta until HASS drops python 3.4 support entirely.
This is a fairly significant step, and the decision to do this was influenced by HASS' pending end of support for Python 3.4. There are many technical reasons why this is a good thing, but the bottom line is that you will need to upgrade your python version to run HASS anyway, so I took this opportunity to follow suit. AppDaemon 3.0 will remain in beta until HASS drops python 3.4 support entirely.

- Apps need to change the import and super class

Expand Down
2 changes: 1 addition & 1 deletion docs/WIDGETDEV.rst
Expand Up @@ -717,7 +717,7 @@ the change: ``self.call_service()``
The additional logic and loop when state is off is to construct the necessary dictionary of additional parameters in
the format the ``turn_on`` service expects to set brightness, color, etc, that may be passed into the widget.
Usually, HADasboard understands ``args`` values as a single string. If you need to use a service that expects to
Usually, HADashboard understands ``args`` values as a single string. If you need to use a service that expects to
receive a list or a dictionary then you may use the special key ``json_args`` and set its value to a stringified
json. For example, suppose you want to pass to the service a list called ``colors``, then you could change the above
code and include another check:
Expand Down

0 comments on commit 5245cf4

Please sign in to comment.