Tidy up HADashboard and AppDaemon Exosystem docs

This commit is contained in:
Andrew Cockburn 2017-07-02 12:18:12 -04:00
parent afdba5c31e
commit 256816bcae
14 changed files with 125 additions and 590 deletions

100
source/_docs/ecosystem/appdaemon.markdown Normal file → Executable file
View File

@ -11,3 +11,103 @@ redirect_from: /ecosystem/appdaemon/
--- ---
AppDaemon is a loosely coupled, multithreaded, sandboxed python execution environment for writing automation apps for Home Assistant. AppDaemon is a loosely coupled, multithreaded, sandboxed python execution environment for writing automation apps for Home Assistant.
# Another Take on Automation
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.
- 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!
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.
# How it Works
The best way to show what AppDaemon does is through a few simple examples.
## Sunrise/Sunset Lighting
Lets start with a simple App to turn a light on every night at sunset and off every morning at sunrise. Every App when first started will have its `initialize()` function called which gives it a chance to register a callback for AppDaemons's scheduler for a specific time. In this case we are using `run_at_sunrise()` and `run_at_sunset()` to register 2 separate callbacks. The argument `0` is the number of seconds offset from sunrise or sunset and can be negative or positive. For complex intervals it can be convenient to use Python's `datetime.timedelta` class for calculations. When sunrise or sunset occurs, the appropriate callback function, `sunrise_cb()` or `sunset_cb()` is called which then makes a call to Home Assistant to turn the porch light on or off by activating a scene. The variables `args["on_scene"]` and `args["off_scene"]` are passed through from the configuration of this particular App, and the same code could be reused to activate completely different scenes in a different version of the App.
```python
import homeassistant.appapi as appapi
class OutsideLights(appapi.AppDaemon):
def initialize(self):
self.run_at_sunrise(self.sunrise_cb, 0)
self.run_at_sunset(self.sunset_cb, 0)
def sunrise_cb(self, kwargs):
self.turn_on(self.args["off_scene"])
def sunset_cb(self, kwargs):
self.turn_on(self.args["on_scene"])
```
This is also fairly easy to achieve with Home Assistant automations, but we are just getting started.
## Motion Light
Our next example is to turn on a light when motion is detected and it is dark, and turn it off after a period of time. This time, the `initialize()` function registers a callback on a state change (of the motion sensor) rather than a specific time. We tell AppDaemon that we are only interested in state changes where the motion detector comes on by adding an additional parameter to the callback registration - `new = "on"`. When the motion is detected, the callack function `motion()` is called, and we check whether or not the sun has set using a built-in convenience function: `sun_down()`. Next, we turn the light on with `turn_on()`, then set a timer using `run_in()` to turn the light off after 60 seconds, which is another call to the scheduler to execute in a set time from now, which results in `AppDaemon` calling `light_off()` 60 seconds later using the `turn_off()` call to actually turn the light off. This is still pretty simple in code terms:
```python
import homeassistant.appapi as appapi
class FlashyMotionLights(appapi.AppDaemon):
def initialize(self):
self.listen_state(self.motion, "binary_sensor.drive", new = "on")
def motion(self, entity, attribute, old, new, kwargs):
if self.sun_down():
self.turn_on("light.drive")
self.run_in(self.light_off, 60)
def light_off(self, kwargs):
self.turn_off("light.drive")
```
This is starting to get a little more complex in Home Assistant automations requiring an Automation rule and two separate scripts.
Now lets extend this with a somewhat artificial example to show something that is simple in AppDaemon but very difficult if not impossible using automations. Lets warn someone inside the house that there has been motion outside by flashing a lamp on and off 10 times. We are reacting to the motion as before by turning on the light and setting a timer to turn it off again, but in addition, we set a 1 second timer to run `flash_warning()` which when called, toggles the inside light and sets another timer to call itself a second later. To avoid re-triggering forever, it keeps a count of how many times it has been activated and bales out after 10 iterations.
```python
import homeassistant.appapi as appapi
class MotionLights(appapi.AppDaemon):
def initialize(self):
self.listen_state(self.motion, "binary_sensor.drive", new = "on")
def motion(self, entity, attribute, old, new, kwargs):
if self.self.sun_down():
self.turn_on("light.drive")
self.run_in(self.light_off, 60)
self.flashcount = 0
self.run_in(self.flash_warning, 1)
def light_off(self, kwargs):
self.turn_off("light.drive")
def flash_warning(self, kwargs):
self.toggle("light.living_room")
self.flashcount += 1
if self.flashcount < 10:
self.run_in(self.flash_warning, 1)
```
Of course if I wanted to make this App or its predecessor reusable I would have provide parameters for the sensor, the light to activate on motion, the warning light and even the number of flashes and delay between flashes.
In addition, Apps can write to `AppDaemon`'s logfiles, and there is a system of constraints that allows yout to control when and under what circumstances Apps and callbacks are active to keep the logic clean and simple.
For full installation instructions, see [README.md](https://github.com/home-assistant/appdaemon/blob/dev/README.md) in the `AppDaemon` repository.
There is also full documentation for the API and associated configuration in [API.md](https://github.com/home-assistant/appdaemon/blob/dev/API.md).

29
source/_docs/ecosystem/hadashboard.markdown Normal file → Executable file
View File

@ -10,12 +10,33 @@ footer: true
redirect_from: /ecosystem/hadashboard/ redirect_from: /ecosystem/hadashboard/
--- ---
HADashboard is a dashboard for [Home Assistant](https://home-assistant.io/) that is intended to be wall mounted, and is optimized for distance viewing. HADashboard is a modular, skinnable dashboard for [Home Assistant](https://home-assistant.io/) that is intended to be wall mounted, and is optimized for distance viewing.
<p class='img'> <p class='img'>
<img src='/images/hadashboard/dash.png' /> <img src='/images/hadashboard/dash1.png' />
Sample Dashboard Default Theme
</p> </p>
HADashboard was originally created by the excellent work of [FlorianZ](https://github.com/FlorianZ/hadashboard) for use with the SmartThings Home Automation system, with notable contributions from the [SmartThings Community](https://community.smartthings.com/t/home-automation-dashboard/4926). I would also like to acknowledge contributions made by [zipriddy](https://github.com/zpriddy/SmartThings_PyDash). This is my port of hadashboard to Home Assistant. <p class='img'>
<img src='/images/hadashboard/dash2.png' />
Obsidian Theme
</p>
<p class='img'>
<img src='/images/hadashboard/dash3.png' />
Zen Theme
</p>
<p class='img'>
<img src='/images/hadashboard/dash4.png' />
Simply Red Theme
</p>
<p class='img'>
<img src='/images/hadashboard/dash5.png' />
Glassic Theme
</p>
For full installation instructions see [DASHBOARD.md](https://github.com/home-assistant/appdaemon/blob/dev/DASHBOARD.md) in the AppDaemon Repository.

View File

@ -1,275 +0,0 @@
---
layout: page
title: "Dashboard Configuration"
description: "Dashboard Configuration"
release_date: 2016-11-13 15:00:00 -0500
sidebar: true
comments: false
sharing: true
footer: true
redirect_from: /ecosystem/hadashboard/dash_config/
---
(All installations)
Hadashboard is a Dashing application, so make sure to read all the instructions on http://dashing.io to learn how to add widgets to your dashboard, as well as how to create new widgets.
Make a copy of `dashboards/example.erb` and call it `main.erb`, then edit this file to reference the items you want to display and control and to get the layout that you want. Leave the original `example.erb` intact and unchanged so that you don't run into problems when trying to update using the git commands mentioned later in "Updating the Dashboard".
The basic anatomy of a widget is this:
``` html
<li data-row="" data-col="1" data-sizex="1" data-sizey="1">
<div data-id="office" data-view="Hadimmer" data-title="Office Lamp"></div>
</li>
```
- **data-row**, **data-col**: The position of the widget in the grid.
- **data-sizex**, **data-sizey**: The size of the widget in terms of grid tile.
- **data-id**: The homeassitant entity id without the entity type (e.g. `light.office` becomes `office`).
- **data-view**: The type of widget to be used (Haswitch, Hadimmer, Hatemp etc.)
- **data-icon**: The icon displayed on the tile. See http://fontawesome.io for an icon cheatsheet.
- **data-title**: The title to be displayed on the tile.
- ***data-bgcolor*** (optional) - the background color of the widget.
Note that although it is legal in XML terms to split the inner `<div>` like this:
``` html
<li data-row="" data-col="1" data-sizex="1" data-sizey="1">
<div data-id="office"
data-view="Hadimmer"
data-title="Office Lamp">
</div>
</li>
```
This may break `hapush`'s parsing of the file, so keep to the line format first presented.
Please, refer to the Dashing website for instructions on how to change the grid and tile size, as well as more general instructions about widgets, their properties, and how to create new widgets.
## {% linkable_title Supported Widgets %}
At this time I have provided support for the following Home Assistant entity types.
- switch: Widget type **Haswitch**
- lock: Widget type **Halock**
- devicetracker: Widget type **Hadevicetracker**
- light: Widget type **Hadimmer**
- cover: Widget type **Hacover**
- input_boolean: Widget type **Hainputboolean**
- scene: Widget type **Hascene**
- **data-ontime** (optional): The amount of time the scene icon lights up when pressed, in milliseconds, default 1000.
### {% linkable_title script %}
Widget type ***Hascript***
**data-ontime** (optional): The amount of time the scene icon lights up when pressed, in milliseconds, default 1000.
### {% linkable_title mode %}
The `Hamode` widget alows you to run a script on activation and to link it with a specified `input_select` so the button will be highlighted for certain values of that input select. The usecase for this is that I maintain an `input_select` as a flag for the state of the house to simplify other automations. I use scripts to switch between the states, and this feature provides feedback as to the current state by lighting up the appropriate mode button.
A `Hamode` widget using this feature will look like this:
```html
<li data-row="5" data-col="3" data-sizex="2" data-sizey="1">
<div data-id="day" data-view="Hamode" data-title="Good Day" data-icon="sun-o" data-changemode="Day" data-input="house_mode"></div>
</li>
```
- **data-changemode**: The value of the `input_select` for which this script button will light up
- **data-input**: The `input_select` entity to use (minus the leading entity type)
### {% linkable_title input_select (read only) %}
Widget type **Hainputselect**
### {% linkable_title sensor %}
Widget type **Hasensor**
Text based output of the value of a particular sensor.
The Hasensor widget supports an additional paramater `data-unit`. This allows you to set the unit to whatever you want: Centigrade, %, lux or whatever you need for the sensor in question. For a temperature sensor you will need to explicitly include the degree symbol like this:
```html
data-unit="&deg;F"
```
If omitted, no units will be shown.
### {% linkable_title sensor %}
Widget type **Hameter**
An alternative to the text based `Hasensor` that works for numeric values only.
The Hameter widget supports an additional paramater `data-unit`. This allows you to set the unit to whatever you want: Centigrade, %, lux or whatever you need for the sensor in question. For a temperature sensor you will need to explicitly include the degree symbol like this:
```html
data-unit="&deg;F"
```
If omitted, no units will be shown.
### {% linkable_title binary_sensor %}
Widget type **Habinary**
An icon-based option for generic binary sensors. Useful for things like door contact sensors. In addition to the standard widget parameters, Habinary supports two additional parameters:
- **data-iconon**: the icon to display when the sensor state is "on"
- **data-iconoff**: the icon to display when the sensor state if "off"
If no icons are specified, the widget defaults to a flat gray line for "off" and a green bullseye for "on".
### {% linkable_title group %}
Widget type **Hagroup**.
The Hagroup widget uses the homeassistant/turn_on and homeassistant/turn_off API call, so certain functionality will be lost. For example, you will not be able to use control groups of locks or dim lights.
## {% linkable_title Alarm Control Panel %}
These widgets allow the user to create a working control panel that can be used to control the Manual Alarm Control Panel component (https://home-assistant.io/components/alarm_control_panel.manual). The example dashboard contains an arrangement similar to this:
<p class='img'>
<img src='/images/hadashboard/alarm_panel.png' />
The Alarm Panel
</p>
Widget type **Haalarmstatus**
The Haalarmstatus widget displays the current status of the alarm_control_panel entity. It will also display the code as it is being entered by the user.
The data-id must be the same as the alarm_control_panel entity_id in Home Assistant.
Widget type **Haalarmdigit**
The Haalarmdigit widget is used to create the numeric keypad for entering alarm codes.
`data-digit` holds the numeric value you wish to enter. The special value of "-" creates a 'clear' button which will wipe the code and return the Haalarmstatus widget display back to the current alarm state.
`data-alarmentity` holds the data-id of the Haalarmstatus widget, so that the status widget can be correctly updated. It is mandatory for a 'clear' type digit and optional for normal numeric buttons.
Widget type **Haalarmaction**
The Haalarmaction widget creates the arm/disarm/trigger buttons. Bear in mind that alarm triggering does not require a code, so you may not want to put this button near the other buttons in case it is pressed accidentally.
data-action must contain one of the following: arm_home/arm_away/trigger/disarm.
### {% linkable_title weather (requires DarkSky) %}
Widget type **Haweather**.
In order to use the weather widget you must configure the [DarkSky component](/components/sensor.darksky/), and ensure that you configure at least the following monitored conditions in your Home Assistant sensor configuration:
- temperature
- humidity
- precip_probability
- precip_intensity
- wind_speed
- pressure
- wind_bearing
- apparent_temperature
- icon
The `data-id` of the Haweather widget must be set to `weather` or the widget will not work.
The Hatemp widget supports an additional paramater `data-unit`. This allows you to set the unit to whatever you want: Centigrade, Fahrenheit or even Kelvin if you prefer. You will need to explicitly include the degree symbol like this:
```html
data-unit="&deg;F"
```
If omitted, no units will be shown.
### {% linkable_title News %}
Widget type ***News*** (contributed by [KRiS](https://community.home-assistant.io/users/kris/activity))
This is an RSS widget that can be used for displaying travel information, news etc. on the dashboard. The RSS feed will update every 60 minutes. To configure this, first it is necessary to add your desired feeds in `homeassistant/lib/ha_conf.rb` in the `$news_feeds` section. By default it comes with 2 sample feeds:
```ruby
$news_feeds = {
"Traffic" => "http://api.sr.se/api/rss/traffic/2863",
"News" => "http://feeds.bbci.co.uk/news/rss.xml",
}
```
You can add as many as you want. The important point is that the key value (e.g. "Traffic" or "News" in the example above is used to tie the feed to your widget in the dashboard file. Here is an example of the Traffic widget that displays the first feed in the list:
```html
<li data-row="3" data-col="2" data-sizex="2" data-sizey="2">
<div data-id="Traffic" data-view="News" data-title="Traffic" data-interval="30" data-bgcolor="#643EBF">
</li>
```
The value of thee `data-id` tag must match the key value in the `$news_feeds` configuration.
- **data-interval** (optional): The time in seconds that each entry in the RSS feed is displayed before the next one is shown, default is 30 seconds.
**The follwing widget types have been deprecated in favor of the more flexible `Hasensor` and `Hameter` widgets. They will be removed in a future release.**
### {% linkable_title sensor (humidity) %}
Widget type **Hahumidity**.
### {% linkable_title sensor (humidity) %}
Widget type **Hahumiditymeter** (contributed by [Shiv Chanders](https://community.home-assistant.io/users/chanders/activity))
This is an alternative to the the text based humidity widget above, it display the humidity as an animated meter from 0 to 100%.
### {% linkable_title sensor (luminance) %}
Widget type **Halux**.
### {% linkable_title sensor (temperature) %}
Widget type **Hatemp**.
The Hatemp widget supports an additional paramater `data-unit`. This allows you to set the unit to whatever you want: Centigrade, Fahrenheit or even Kelvin if you prefer. You will need to explicitly include the degree symbol like this:
```html
data-unit="&deg;F"
```
If omitted, no units will be shown.
## {% linkable_title Customizing CSS styles %}
If you want to customize the styles of your dashboard and widgets, there are two options:
1. You can edit the application.scss file (and the individual widget .scss files) directly (not recommended; if you pull down updates from the master repository, your changes might conflict/be overwritten)
1. __Create override files (recommended)__
1. Create a couple of additional files in the _assets/stylesheets_ directory: `_application_custom.scss` and `_variables_custom.scss`.
1. Open `application.scss` and go to the bottom of the file. Uncomment the @import line.
1. Open `_variables.scss` and go to the bottom of the file. Uncomment the @import line.
1. Write your own SASS styles in `_application_custom.scss` (for general style customization) and `_variables_custom.scss` (for colors). You can customize those files without worrying about your changes getting overwritten if you pull down an update. The most you may have to do, if you update, will be to uncomment the @import lines again from steps 2 and 3.
__Note: The `_variables.scss` file (and your customizations from `_variables_custom.scss`) get imported into nearly every widget's SCSS file, so it is a best practice to define varaibles for colors in `_variables.scss` or `_variables_custom.scss` and reference those variables in the widget SCSS.__
## {% linkable_title Changes and Restarting %}
When you make changes to a dashboard, Dashing and `hapush` will both automatically reload and apply the changes without a need to restart.
Note: The first time you start Dashing, it can take up to a minute for the initial compilation of the pages to occur. You might get a timeout from your browser. If this occurs, be patient and reload. Subsequent reloads will be a lot quicker.
## {% linkable_title Multiple Pages %}
It is possible to have multiple pages within a dashboard. To do this, you can add an arbitary number of gridster divisions (you need at least one).
```html
<div class="gridster"> <!-- Main Panel - PAGE 1 -->
<some widgets>
</div
<div class="gridster"> <!-- More Stuff - PAGE 2 -->
<more widgets>
</div
```
The divisions are implicitly numbered from 1 so it is a good idea to comment them. You can then add a widget to switch between pages like so:
```html
<li data-row="1" data-col="1" data-sizex="1" data-sizey="1">
<div data-id="cpage1" data-view="ChangePage" data-icon="cogs" data-title="Upstairs" data-page="3" data-stagger="false" data-fasttransition="true" data-event-click="onClick"></div>
</li>
```
- ***data-page*** : The name of the page to switch to
## {% linkable_title Multiple Dashboards %}
You can also have multiple dashboards, by simply adding a new .erb file to the dashboards directory and navigating to the dashboards via `http://<IP address>:3030/dashboard-file-name-without-extension`
For example, if you want to deploy multiple devices, you could have one dashboard per room and still only use one hadashboard app installation.

View File

@ -1,95 +0,0 @@
---
layout: page
title: "HAPush"
description: "HAPush"
release_date: 2016-11-13 15:00:00 -0500
sidebar: true
comments: false
sharing: true
footer: true
redirect_from: /ecosystem/hadashboard/hapush/
---
# Installing hapush (Manual install only)
This is not necessary if you are using Docker as it is already installed.
When you have the dashboard correctly displaying and interacting with Home Assistant you are ready to install the final component - `hapush`. Without `hapush` the dashboard would not respond to events that happen outside of the hadashboard system. For instance, if someone uses the Home Assistant interface to turn on a light, or even another App or physical switch, there is no way for the Dashboard to reflect this change. This is where `hapush` comes in.
`hapush` is a python daemon that listens to Home Assistant's Event Stream and pushes changes back to the dashboard to update it in real time. You may want to create a [Virtual Environment](https://docs.python.org/3/library/venv.html) for hapush - at the time of writing there is a conflict in the Event Source versions in use between HA and hapush.
Before running `hapush` you will need to add some python prerequisites:
```bash
$ sudo pip3 install daemonize
$ sudo pip3 install sseclient
$ sudo pip3 install configobj
```
Some users are reporting errors with `InsecureRequestWarning`:
```
Traceback (most recent call last):
File "./hapush.py", line 21, in <module>
from requests.packages.urllib3.exceptions import InsecureRequestWarning
ImportError: cannot import name 'InsecureRequestWarning'
```
This can be fixed with:
```bash
$ sudo pip3 install --upgrade requests
```
## {% linkable_title Configuring hapush (all installation methods) %}
When you have all the prereqs in place, copy the `hapush.cfg.example` file to `hapush.cfg` then edit it to reflect your environment:
```
ha_url = "http://192.168.1.10:8123"
ha_key = api_key
dash_host = "192.168.1.10:3030"
dash_dir = "/srv/hass/src/hadashboard/dashboards"
logfile = "/etc/hapush/hapush.log"
```
- `ha_url` is a reference to your home assistant installation and must include the correct port number and scheme (`http://` or `https://` as appropriate)
- `ha_key` should be set to your key if you have one, otherwise it can be removed.
- `dash_host` should be set to the IP address and port of the host you are running Dashing on (no http or https) - this should be the same machine as you are running `hapush` on.
- `dash_dir` is the path on the machine that stores your dashboards. This will be the subdirectory `dashboards` relative to the path you cloned `hadashboard` to. For Docker installs this should be set to `/app/dashboards`
- `logfile` is the path to where you want `hapush` to keep its logs. 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 hapush to run from, although there is no reason you can't keep it in the `hapush` subdirectory of the cloned repository. For Docker installs this should be set to `/app/hapush/hapush.log`
## {% linkable_title Running hapush %}
For a manual installation you can then run `hapush` from the command-line as follows:
```bash
$ ./hapush.py hapush.cfg
```
For Docker installs, hapush will be started automatically when you run the startup command.
If all is well, you should start to see `hapush` responding to events as they occur. For a docker installation you should see these messages in `hapush/hapush.log`.
```bash
2016-06-19 10:05:59,693 INFO Reading dashboard: /srv/hass/src/hadashboard/dashboards/main.erb
2016-06-19 10:06:12,362 INFO switch.wendy_bedside -> state = on, brightness = 50
2016-06-19 10:06:13,334 INFO switch.andrew_bedside -> state = on, brightness = 50
2016-06-19 10:06:13,910 INFO script.night -> Night
2016-06-19 10:06:13,935 INFO script.night_quiet -> Night
2016-06-19 10:06:13,959 INFO script.day -> Night
2016-06-19 10:06:13,984 INFO script.evening -> Night
2016-06-19 10:06:14,008 INFO input_select.house_mode -> Night
2016-06-19 10:06:14,038 INFO script.morning -> Night
2016-06-19 10:06:21,624 INFO script.night -> Day
2016-06-19 10:06:21,649 INFO script.night_quiet -> Day
2016-06-19 10:06:21,674 INFO script.day -> Day
2016-06-19 10:06:21,698 INFO script.evening -> Day
2016-06-19 10:06:21,724 INFO input_select.house_mode -> Day
2016-06-19 10:06:21,748 INFO script.morning -> Day
2016-06-19 10:06:31,084 INFO switch.andrew_bedside -> state = off, brightness = 30
2016-06-19 10:06:32,501 INFO switch.wendy_bedside -> state = off, brightness = 30
2016-06-19 10:06:52,280 INFO sensor.side_multisensor_luminance_25 -> 871.0
2016-06-19 10:07:50,574 INFO sensor.side_temp_corrected -> 70.7
2016-06-19 10:07:51,478 INFO sensor.side_multisensor_relative_humidity_25 -> 52.0
```

View File

@ -1,155 +0,0 @@
---
layout: page
title: "Installation"
description: "Installation"
release_date: 2016-11-13 15:00:00 -0500
sidebar: true
comments: false
sharing: true
footer: true
redirect_from: /ecosystem/hadashboard/installation/
---
Installation can be performed using Docker (Contributed by [marijngiesen](https://github.com/marijngiesen)) or manually if Docker doesn't work for you. We also have a Raspberry Pi version of Docker contributed by [snizzleorg](https://community.home-assistant.io/users/snizzleorg/activity).
## {% linkable_title Using Docker (Non Raspian) %}
Assuming you already have Docker installed, installation is fairly easy.
### {% linkable_title Clone the Repository %}
Clone the **hadashboard** repository to the current local directory on your machine.
``` bash
$ git clone https://github.com/home-assistant/hadashboard.git
```
Change your working directory to the repository root. Moving forward, we will be working from this directory.
``` bash
$ cd hadashboard
```
### {% linkable_title Build the docker image %}
```bash
$ docker build -t hadashboard .
```
When the build completes, you can run the dashboard with the following command for unix based systems:
```bash
$ docker run --name="hadashboard" -d -v <path_to_hadashboard>/dashboards:/app/dashboards -v <path_to_hadashboard>/lib/ha_conf.rb:/app/lib/ha_conf.rb -v <path_to_hadashboard>/hapush:/app/hapush --net=host hadashboard
```
If you are running docker on windows you should not use the `--net` command and explicitly specify the port, also for security reason `--net=host` should not be used so the following can also be used in unix. This will also set the process to start when the docker process starts so you do not have to worry about reboots. To map the volumes make sure you have ticked the shred drives in the settings. In this example I am using `c:\hadashboard` as the location where the git clone was done and mapping to port 3030 on the host.
```powershell
docker run --restart=always --name="hadashboard" -p 3030:3030 -d -v C:/hadashboard/dashboards:/app/dashboards -v C:/hadashboard/lib/ha_conf.rb:/app/lib/ha_conf.rb -v C:/hadashboard/hapush:/app/hapush hadashboard
```
This will use all of the same configuration files as specified below in the configuration sections, although you will need to make a few changes to the `hapush` configuration to match the docker's filesystem, detailed below.
By default, the docker instance should pick up your timezone but if you want to explicitly set it you can add an environment variable for your specific zone as follows:
```bash
-e "TZ=Europe/Amsterdam"
```
### {% linkable_title Docker on Raspberry Pi %}
Raspberry Pi needs to use a different Docker build file so the build command is slightly different:
```bash
$ sudo docker build -f Docker-raspi/Dockerfile -t hadashboard .
```
Apart from that the other steps are identical. Running Docker is pretty slow even on a PI3, be prepared for it to take an hour or two to build all of the extensions and install everything.
## {% linkable_title Manual Installation %}
### {% linkable_title Clone the Repository %}
Clone the **hadashboard** repository to the current local directory on your machine.
``` bash
$ git clone https://github.com/home-assistant/hadashboard.git
```
Change your working directory to the repository root. Moving forward, we will be working from this directory.
``` bash
$ cd hadashboard
```
### {% linkable_title 2. Install Dashing and prerequirments %}
Essentially, you want to make sure that you have Ruby installed on your local machine.
For Debian based distribution do:
```bash
$ sudo apt-get install rubygems
```
Then, install the Dashing gem:
```bash
$ gem install dashing
```
From your repository root, make sure that all dependencies are available. On some systems you may also need to install `bundler`:
```bash
$ gem install bundler
```
When installed run it:
``` bash
$ bundle
```
Bundle will now install all the ruby prerequirements for running dashing. Prerequirements will vary across different machines. So far users have reported requirements for some additional installs to allow the bundle to complete succesfully:
- ruby-dev - `sudo apt-get install ruby-dev`
- node-js - `sudo apt-get install nodejs`
- libsqlite3-dev - `sudo apt-get install libsqlite3-dev`
- execjs gem - `gem install execjs`
You will need to research what works on your particular architecture and also bear in mind that version numbers may change over time.
This is currently running on various versions of Ruby and there are no strong dependencies however your mileage may vary.
## {% linkable_title Updating configuration (Manual and Docker) %}
Next, in the `./lib` directory, copy the `ha_conf.rb.example` file to `ha_conf.rb` and edit its settings to reflect your installation, pointing to the machine Home Assistant is running on and adding your API key.
```ruby
$ha_url = "http://192.168.1.10:8123"
$ha_apikey = "your key"
```
- `$ha_url` is a reference to your Home Assistant installation and must include the correct port number and scheme (`http://` or `https://` as appropriate)
- `$ha_apikey` should be set to your key if you have one, otherwise it can remain blank.
The file also contains example newsfeeds for the News widget:
```ruby
$news_feeds = {
"Traffic" => "http://api.sr.se/api/rss/traffic/2863",
"News" => "http://feeds.bbci.co.uk/news/rss.xml",
}
```
You can leave these alone for now or if you prefer customize them as described in the News widget section.
When you are done, you can start a local webserver like this or if you are on docker it should start when you start the container.
```bash
$ dashing start
```
Point your browser to **http://localhost:3030** to access the hadashboard on your local machine, and you should see the supplied default dashboard. If you want to access it remotely ensure you have opened any required firewall rules.
If the page never finishes loading and shows up all white, edit the dashboard config to match your own setup, instructions in the next step.

View File

@ -1,17 +0,0 @@
---
layout: page
title: "Reboot"
description: "Reboot"
release_date: 2016-11-13 15:00:00 -0500
sidebar: true
comments: false
sharing: true
footer: true
redirect_from: /ecosystem/hadashboard/reboot/
---
To run Dashing and `hapush` at reboot, checkout out the sample init scripts in the `./init` directory. These have been tested on a Raspberry Pi - your mileage may vary on other systems.
Instructions for automatically starting a Docker installation can be found [here](https://docs.docker.com/engine/admin/host_integration/).
For Docker you may also want to use `docker-compose` - there is a sample compose file in the `./init` directory.

View File

@ -1,25 +0,0 @@
---
layout: page
title: "Updating HADashboard"
description: "Updating HADashboard"
release_date: 2016-11-13 15:00:00 -0500
sidebar: true
comments: false
sharing: true
footer: true
redirect_from: /ecosystem/hadashboard/updating/
---
To update the dashboard after new code has been released, just run the following command to update your copy:
```bash
$ git pull origin
```
For some releases you may also need to rerun the `bundle` command:
``` bash
$ bundle
```
For Docker users, you will also need to rerun the Docker build process.

View File

@ -152,28 +152,9 @@
</li> </li>
<li> <li>
{% active_link /docs/ecosystem/appdaemon/ AppDaemon %} {% active_link /docs/ecosystem/appdaemon/ AppDaemon %}
<ul>
<li>{% active_link /docs/ecosystem/appdaemon/installation/ Installation %}</li>
<li>{% active_link /docs/ecosystem/appdaemon/configuration/ Configuration %}</li>
<li>{% active_link /docs/ecosystem/appdaemon/example_apps/ Example Apps %}</li>
<li>{% active_link /docs/ecosystem/appdaemon/running/ Running AppDaemon %}</li>
<li>{% active_link /docs/ecosystem/appdaemon/reboot/ Starting AppDaemon at Reboot %}</li>
<li>{% active_link /docs/ecosystem/appdaemon/operation/ Operation %}</li>
<li>{% active_link /docs/ecosystem/appdaemon/windows/ AppDaemon on Windows %}</li>
<li>{% active_link /docs/ecosystem/appdaemon/updating/ Updating AppDaemon %}</li>
<li>{% active_link /docs/ecosystem/appdaemon/tutorial/ AppDaemon Tutorial %}</li>
<li>{% active_link /docs/ecosystem/appdaemon/api/ AppDaemon API Reference %}</li>
</ul>
</li> </li>
<li> <li>
{% active_link /docs/ecosystem/hadashboard/ HADashboard %} {% active_link /docs/ecosystem/hadashboard/ HADashboard %}
<ul>
<li>{% active_link /docs/ecosystem/hadashboard/installation/ Installation %}</li>
<li>{% active_link /docs/ecosystem/hadashboard/dash_config/ Dashboard Configuration %}</li>
<li>{% active_link /docs/ecosystem/hadashboard/hapush/ HAPush %}</li>
<li>{% active_link /docs/ecosystem/hadashboard/reboot/ Reboot %}</li>
<li>{% active_link /docs/ecosystem/hadashboard/updating/ Updating HADashboard %}</li>
</ul>
</li> </li>
<li> <li>
{% active_link /docs/ecosystem/notebooks/ Notebooks %} {% active_link /docs/ecosystem/notebooks/ Notebooks %}

Binary file not shown.

Before

Width:  |  Height:  |  Size: 74 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 83 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 483 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 605 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 179 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 401 KiB