Spelling fixes (#4532)
* Spelling fixes * "It's" -> "its" fixes * Fix capitalization of "Pi" in "Raspberry Pi" "Pi", not "PI" or "pi".
This commit is contained in:
Ville Skyttä
Franck Nijhof
parent
2216828c53
commit
b39bd81c6e
85 changed files with 111 additions and 111 deletions
|
|
@ -44,7 +44,7 @@ Before beginning make sure that you have the following:
|
|||
|
||||
3. Create a configuration file for the server
|
||||
|
||||
As the `asterisk` user create a `asterisk_mbox.ini` file (You can place this in any directory you choose, but the rommended location is `/etc/asterisk/asterisk_mbox.ini`)
|
||||
As the `asterisk` user create an `asterisk_mbox.ini` file (You can place this in any directory you choose, but the rommended location is `/etc/asterisk/asterisk_mbox.ini`)
|
||||
|
||||
```ini
|
||||
[default]
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ Field | Description
|
|||
`state.last_changed` | Time the state changed. This is not updated when there are only updated attributes. Example: `2017-10-28 08:13:36.715874+00:00`.
|
||||
`state.attributes` | A dictionary with extra attributes related to the current state.
|
||||
|
||||
The attributes of an entity are optional. There are a few attributes that are used by Home Assistant for representing the entity in a specific way. Each component will also have it's own attributes to represent extra state data about the entity. For example, the light component has attributes for the current brightness and color of the light. When an attribute is not available, Home Assistant will not write it to the state.
|
||||
The attributes of an entity are optional. There are a few attributes that are used by Home Assistant for representing the entity in a specific way. Each component will also have its own attributes to represent extra state data about the entity. For example, the light component has attributes for the current brightness and color of the light. When an attribute is not available, Home Assistant will not write it to the state.
|
||||
|
||||
When using templates, attributes will be available by their name. For example `state.attributes.assumed_state`.
|
||||
|
||||
|
|
|
|||
|
|
@ -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"
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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!
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -28,8 +28,8 @@ Just follow the component pages for each on how to add them to your Home Assista
|
|||
|
||||
- [DHT Sensor](/components/sensor.dht/).
|
||||
- [Raspberry Pi Cover](/components/cover.rpi_gpio/).
|
||||
- [Raspberry PI GPIO Binary Sensor](/components/binary_sensor.rpi_gpio/).
|
||||
- [Raspberry PI GPIO Switch](/components/switch.rpi_gpio/).
|
||||
- [Raspberry Pi GPIO Binary Sensor](/components/binary_sensor.rpi_gpio/).
|
||||
- [Raspberry Pi GPIO Switch](/components/switch.rpi_gpio/).
|
||||
- [Raspberry Pi RF Switch](/components/switch.rpi_rf/).
|
||||
|
||||
### {% linkable_title Raspberry Pi Camera %}
|
||||
|
|
|
|||
|
|
@ -155,7 +155,7 @@ The following automation shows how to raise a custom event called `event_light_t
|
|||
```
|
||||
{% endraw %}
|
||||
|
||||
The following automation shows how to capture the custom event `event_light_turned_on`, and retrieve corresponsing `entity_id` that was passed as the event data.
|
||||
The following automation shows how to capture the custom event `event_light_turned_on`, and retrieve corresponding `entity_id` that was passed as the event data.
|
||||
|
||||
{% raw %}
|
||||
```yaml
|
||||
|
|
|
|||
|
|
@ -52,7 +52,7 @@ Battery powered devices need to be awake before you can use the Z-Wave control p
|
|||
This is a dropdown where you can select all the entities of this node. Once selected you can then use:
|
||||
|
||||
* **Refresh Entity** to refresh just that entity's values
|
||||
* **Entity Attributes** to display the attributes of that entity (eg it's friendly name, the ID of the node, etc)
|
||||
* **Entity Attributes** to display the attributes of that entity (eg its friendly name, the ID of the node, etc)
|
||||
|
||||
Here you can mark a device as requiring polling so the controller is aware of changes because the device doesn't send updates itself. Do see the information on [polling here](/docs/z-wave/devices/#polling), since excessive polling can break your Z-Wave network.
|
||||
|
||||
|
|
|
|||
|
|
@ -147,7 +147,7 @@ binary_sensor:
|
|||
- **254**: Deep sleep
|
||||
- **255**: Case open
|
||||
|
||||
If your device has an `burglar` entity, but not a `binary_sensor` equivalent, you can use a [template binary sensor](/components/binary_sensor.template/) to create one:
|
||||
If your device has a `burglar` entity, but not a `binary_sensor` equivalent, you can use a [template binary sensor](/components/binary_sensor.template/) to create one:
|
||||
|
||||
```
|
||||
binary_sensor:
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ The `zwave` component exposes multiple services to help maintain the network. Al
|
|||
| ---------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| add_node | Put the Z-Wave controller in inclusion mode. Allows you to add a new device to the Z-Wave network. |
|
||||
| add_node_secure | Put the Z-Wave controller in secure inclusion mode. Allows you to add a new device with secure communications to the Z-Wave network. |
|
||||
| cancel_command | Cancels a running Z-Wave command. If you have started a add_node or remove_node command, and decide you are not going to do it, then this must be used to stop the inclusion/exclusion command. |
|
||||
| cancel_command | Cancels a running Z-Wave command. If you have started an add_node or remove_node command, and decide you are not going to do it, then this must be used to stop the inclusion/exclusion command. |
|
||||
| change_association | Add or remove an association in the Z-Wave network |
|
||||
| heal_network | Tells the controller to "heal" the Z-Wave network. Basically asks the nodes to tell the controller all of their neighbors so the controller can refigure out optimal routing. |
|
||||
| heal_node | Tells the controller to "heal" a specific node on the network. Requires `node_id` field. You can also force return route update with `return_routes` field.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue