Updated auto-generated content and added HABmin and HABPanel to the menu
Signed-off-by: Kai Kreuzer <kai@openhab.org>pull/95/head
Kai Kreuzer
parent
085cfa33fd
commit
d29883e4b9
|
|
@ -25,6 +25,7 @@ meteostick,Meteostick,"This is the binding for the [Meteostick](http://www.smart
|
|||
milight,Milight,"The openHAB2 Milight binding allows to send commands to multiple Milight bridges."
|
||||
netatmo,Netatmo,"The Netatmo binding integrates the following Netatmo products :"
|
||||
network,Network,"This binding allows to check, whether a device is currently available on the network."
|
||||
oceanic,Oceanic,"This binding integrates the Oceanic water softener and management system (www.oceanic.be). The binding supports the Limex IQ and Limex Pro water softeners. The Oceanic systems are also distributed by Syr in Germany (www.syr.de). In order to integrate the Limex into openHAB, the optional CAN-Serial gateway has to be installed"
|
||||
onkyo,Onkyo,"This binding integrates the Onkyo AV receivers."
|
||||
opensprinkler,OpenSprinkler,"This binding allows allows basic control of the OpenSprinkler and OpenSprinkler PI (Plus) devices. Stations can be controlled to be turned on or off and rain sensor state can be read."
|
||||
orvibo,Orvibo,"This binding integrates Orvibo devices that communicate using UDP. Primarily this was designed for S20 Wifi Sockets but other products using the same protocol may be implemented in future."
|
||||
|
|
@ -37,6 +38,7 @@ smaenergymeter,SMA Energy Meter,"This Binding is used to display the measured va
|
|||
squeezebox,Logitech Squeezebox,"This binding integrates the [Logitech Media Server](http://www.mysqueezebox.com) and compatible Squeeze players."
|
||||
systeminfo,Systeminfo,"System information Binding provides operating system and hardware information including:"
|
||||
tesla,Tesla,"This binding integrates the [Tesla Electrical Vehicle](http://www.teslamotors.com)."
|
||||
toon,Toon,"The Toon bindings shows among others current room temperature, setpoint, energy and gas usage information."
|
||||
urtsi,Somfy URTSI II,"The addressable Universal RTS Interface II (URTSI II) can be used to communicate between home automation or other third party systems and SOMFY’s RTS Motors and controls. It is capable of individual or group control, and can be operated via infrared remote, RS232 and RS485 serial communication. Once an input is activated, an RTS radio command is sent to the automated window treatment."
|
||||
vitotronic,vitotronic,"Viessmann heating systems with vitotronic has a optolink Interface for maintenance."
|
||||
zwave,ZWave,"The ZWave binding supports an interface to a wireless Z-Wave home automation network."
|
||||
|
|
|
|||
|
|
|
@ -54,6 +54,7 @@ binding,Novelan Heatpump Binding
|
|||
binding,OpenEnergyMonitor Binding
|
||||
binding,OneWire Binding
|
||||
binding,OWServer Binding
|
||||
binding,Plugwise Binding
|
||||
binding,Visonic PowerMax Binding
|
||||
binding,RWE SmartHome Binding
|
||||
binding,Samsung A/C Binding
|
||||
|
|
|
|||
|
|
|
@ -73,6 +73,8 @@
|
|||
<li><a href="{{docu}}/addons/uis/basic/readme.html">Basic UI</a></li>
|
||||
<li><a href="{{docu}}/addons/uis/classic/readme.html">Classic UI</a></li>
|
||||
<li><a href="{{docu}}/addons/uis/paper/readme.html">Paper UI</a></li>
|
||||
<li><a href="{{docu}}/addons/uis/habmin/readme.html">HABmin</a></li>
|
||||
<li><a href="{{docu}}/addons/uis/habpanel/readme.html">HABPanel</a></li>
|
||||
<li><a href="{{docu}}/addons/iconsets/classic/readme.html">Classic Iconset</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
|
|
|
|||
|
|
@ -1 +1 @@
|
|||
Subproject commit bad54e6f1a0fed3fdb6ed634f5bc3f03523d3bb2
|
||||
Subproject commit 8a2ca43bd278d0acfeddb9f9ad12a98068d3687f
|
||||
|
|
@ -1 +1 @@
|
|||
Subproject commit 57d6611cd5ea81b80b98ead5d95b69e202f21500
|
||||
Subproject commit 9edf6432b9302e125c109c54c9b49312f75de48b
|
||||
|
|
@ -1 +1 @@
|
|||
Subproject commit 1d18dc07a1333a550c30d5a9f025d048f1542718
|
||||
Subproject commit 79e9245d7fff85968fa5a3b7f86de594d93036d5
|
||||
|
|
@ -1 +1 @@
|
|||
Subproject commit 7ff25962fb2d2e1206b1315d92a90dca9071231e
|
||||
Subproject commit ce70ff4f20f6f75a1fcb346c19ea6909f701fc4a
|
||||
|
|
@ -257,6 +257,3 @@ A device may return this failure while fetching the datapoint values. I've teste
|
|||
Fetching values is only done at startup or if you trigger a REFRESH. I hope this will be fixed in one of the next CCU firmwares.
|
||||
With [Homegear](https://www.homegear.eu) everything works as expected.
|
||||
|
||||
**Ung?ltiges Byte 1 von 1-Byte-UTF-8-Sequenz**
|
||||
|
||||
Your LOCALE is wrong, make sure it is set to UTF-8
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ layout: documentation
|
|||
|
||||
# Network Binding
|
||||
|
||||
This binding allows to check whether a device is currently available on the network.
|
||||
This binding allows to check, whether a device is currently available on the network.
|
||||
This happens by either using [ping](https://en.wikipedia.org/wiki/Ping_%28networking_utility%29) or by a successful TCP connection on a port of your choosing.
|
||||
|
||||
## Supported Things
|
||||
|
|
@ -28,7 +28,7 @@ network:device:devicename [ hostname="192.168.0.64", port="0", retry="1", timeou
|
|||
- **hostname:** IP address or hostname of the device
|
||||
- **port:** "0" to use ICMP ping or the number of an open TCP port on the device
|
||||
- **retry:** After how many ping retries shall the device be assumed as offline
|
||||
- **timeout:** How long shall the ping wait for an answer (in milliseconds, `60000` = one minute)
|
||||
- **timeout:** How long shall the ping wait for an answer (in milliseconds, `60000` = one minute)
|
||||
- **refresh_interval:** How often shall the device be checked (in milliseconds, `5000` = 5 seconds)
|
||||
- **use\_system\_ping:** Use the real ICMP ping program of the operating system, instead of the Java ping. Useful if the devices cannot be reached by Java ping. **Beware**: By setting this option to `true`, the **port option is ignored**.
|
||||
- **dhcplisten:** Listen for DHCP Request messages.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,83 @@
|
|||
---
|
||||
layout: documentation
|
||||
---
|
||||
|
||||
{% include base.html %}
|
||||
|
||||
# Oceanic Binding
|
||||
|
||||
This binding integrates the Oceanic water softener and management system (www.oceanic.be). The binding supports the Limex IQ and Limex Pro water softeners. The Oceanic systems are also distributed by Syr in Germany (www.syr.de). In order to integrate the Limex into openHAB, the optional CAN-Serial gateway has to be installed
|
||||
|
||||
## Supported Things
|
||||
|
||||
Softener
|
||||
|
||||
## Thing Configuration
|
||||
|
||||
The Thing configuration requires the name of the serial port that is used to connect the ESH host with the Oceanic unit, and the interval period in seconds to poll the Oceanic unit
|
||||
|
||||
## Channels
|
||||
|
||||
All devices support the following channels (non-exhaustive):
|
||||
|
||||
| Channel Type ID | Item Type | Description |
|
||||
|-----------------|------------------------|--------------|----------------- |------------- |
|
||||
| alarm | String | Current alarm description, if any|
|
||||
| alert | String | Current alert description, if any, to notify a shortage of salt |
|
||||
| totalflow | Number | Current flow in l/min |
|
||||
| maxflow | Number | Maximum flow recorded, in l/min |
|
||||
| reserve | Number | Water reserve in l before regeneration has to start |
|
||||
| cycle | String | Indicates the stage of the regeneration cycle |
|
||||
| endofcycle | String | Indicates the time to the end of the current cycle |
|
||||
| endofgeneration | String | Indicates the time to the end of the current generation |
|
||||
| inlethardness | Number | Water hardness at the inlet |
|
||||
| outlethardness | Number | Water hardness at the outlet |
|
||||
| salt | String | Volume of salt remaining, in kg |
|
||||
| consumption(today)(currentweek)(...) | String | Water consumption, in l, for that period |
|
||||
| regeneratenow | Switch | Start an immediate regeneration |
|
||||
| regeneratelater | Switch | Start a delayed regeneration |
|
||||
| lastgeneration | DateTime | Date and Time of the last regeneration cycle |
|
||||
| pressure | Number | Water pressure, in bar |
|
||||
| minpressure | Number | Minimum water pressure recorded, in bar |
|
||||
| maxpressure | Number | Maximum water pressure recorded, in bar |
|
||||
| normalregenerations | Number | Number of regenerations completed |
|
||||
| serviceregenerations | Number | Number of service regenerations completed |
|
||||
| incompleteregenerations | Number | Number of incomplete regenerations |
|
||||
| allregenerations | Number | Number of all regenerations |
|
||||
|
||||
|
||||
## Full Example
|
||||
|
||||
.things
|
||||
|
||||
```
|
||||
Thing oceanic:softener:s1 [ port="/dev/tty.usbserial-FTWGX64N", interval=60]
|
||||
```
|
||||
|
||||
.items
|
||||
```
|
||||
Number oceanicVolume "volume [%d]" (oceanic) {channel="oceanic:softener:s1:totalflow"}
|
||||
String oceanicAlarm "alarm: [%s]" (oceanic) {channel="oceanic:softener:s1:alarm"}
|
||||
String oceanicAlert "alert: [%s]" (oceanic) {channel="oceanic:softener:s1:alert"}
|
||||
Number oceanicReserve (oceanic) {channel="oceanic:softener:s1:reserve"}
|
||||
String oceanicCycle (oceanic) {channel="oceanic:softener:s1:cycle"}
|
||||
String oceanicEOC (oceanic) {channel="oceanic:softener:s1:endofcycle"}
|
||||
String oceanicEOG (oceanic) {channel="oceanic:softener:s1:endofgeneration"}
|
||||
String oceanicHU (oceanic) {channel="oceanic:softener:s1:hardnessunit"}
|
||||
Number oceanicInletHardness (oceanic) {channel="oceanic:softener:s1:inlethardness"}
|
||||
Number oceanicOutletHardness (oceanic) {channel="oceanic:softener:s1:outlethardness"}
|
||||
String oceanicCylState (oceanic) {channel="oceanic:softener:s1:cylinderstate"}
|
||||
Number oceanicSalt (oceanic) {channel="oceanic:softener:s1:salt"}
|
||||
Number oceanicConsToday "volume today is [%d]" (oceanic) {channel="oceanic:softener:s1:consumptiontoday"}
|
||||
Number oceanicConsYday "volume yesterday was [%d]"(oceanic) {channel="oceanic:softener:s1:consumptionyesterday"}
|
||||
Number oceanicPressure (oceanic) {channel="oceanic:softener:s1:pressure"}
|
||||
DateTime oceanicLastGeneration (oceanic) {channel="oceanic:softener:s1:lastgeneration"}
|
||||
Number oceanicAllGen (oceanic) {channel="oceanic:softener:s1:allregenerations"}
|
||||
Number oceanicMaxFlow (oceanic) {channel="oceanic:softener:s1:maxflow"}
|
||||
Number oceanicConsThisWk "volume this week is [%d]"(oceanic) {channel="oceanic:softener:s1:consumptioncurrentweek"}
|
||||
Number oceanicConsThisMnth "volume this month is [%d]"(oceanic) {channel="oceanic:softener:s1:consumptioncurrentmonth"}
|
||||
Number oceanicConsLastMnth "volume last month is [%d]"(oceanic) {channel="oceanic:softener:s1:consumptionlastmonth"}
|
||||
Number oceanicConsComplete "volume all time is [%d]"(oceanic) {channel="oceanic:softener:s1:consumptioncomplete"}
|
||||
Number oceanicConsUntreated "volume untreated is [%d]"(oceanic) {channel="oceanic:softener:s1:consumptionuntreated"}
|
||||
Number oceanicConsLastWk "volume last week is [%d]"(oceanic) {channel="oceanic:softener:s1:consumptionlastweek"}
|
||||
```
|
||||
|
|
@ -67,6 +67,11 @@ sudo kextunload -b com.apple.driver.AppleUSBFTDI
|
|||
|
||||
If you have any problems with JD2XX or you don't want to disable FTDI driver on OS X, you can also configure RFXCOM transceivers/receivers manually.
|
||||
|
||||
You can also use an RFXCOM device over TCP/IP. To start a TCP server for an RFXCOM device, you can use socat:
|
||||
```
|
||||
socat tcp-listen:10001,fork,reuseaddr file:/dev/ttyUSB0,raw
|
||||
```
|
||||
|
||||
After the bridge is configured and the transceiver receives a message from any sensor or actuator, the device is put in the Inbox. Because RFXCOM communication is a one way protocol, receiver actuators can't be discovered automatically.
|
||||
|
||||
Both bridges and sensor/actuators are easy to configure from the Paper UI. However, you can configure things manually in the thing file, for example:
|
||||
|
|
@ -101,6 +106,6 @@ This binding currently supports following channels:
|
|||
| signallevel | Number | Received signal strength level. |
|
||||
| temperature | Number | Current temperature in degree Celsius. |
|
||||
| totalusage | Number | Used energy in Watt hours. |
|
||||
| totalamphours | Number | Used "energy" in ampere-hours. |
|
||||
| totalamphour | Number | Used "energy" in ampere-hours. |
|
||||
| winddirection | Number | Wind direction in degrees. |
|
||||
| windspeed | Number | Average wind speed in meters per second. |
|
||||
|
|
|
|||
|
|
@ -48,6 +48,8 @@ The devices support the following channels:
|
|||
| currentartist | String | Name of the artist currently playing | all |
|
||||
| currenttitle | String | Title of the song currently playing | all |
|
||||
| currenttrack | String | This channel indicates the name of the track or radio station currently playing | all |
|
||||
| currenttrackuri | String | URI of the current track | all |
|
||||
| currenttransporturi | String | URI of the current AV transport | all |
|
||||
| favorite | String | Play the given favorite entry. The favorite entry has to be predefined in the Sonos Controller app | all |
|
||||
| led | Switch | Set or get the status of the white led on the front of the Zone Player | all |
|
||||
| localcoordinator | Switch | Indicator set to ON if the this Zone Player is the Zone Group Coordinator | all |
|
||||
|
|
@ -62,11 +64,13 @@ The devices support the following channels:
|
|||
| publicaddress | Switch | Put all Zone Players in one group, and stream audio from the line-in from the Zone Player that triggered the command | PLAY5, CONNECT, CONNECTAMP |
|
||||
| radio | String | Play the given radio station. The radio station has to be predefined in the Sonos Controller app | all |
|
||||
| remove | String | Remove the given Zone Player to the group of this Zone Player | all |
|
||||
| repeat | String | Repeat the current track or queue. The accepted values are OFF, ONE and ALL | all |
|
||||
| restore | Switch | Restore the state of the Zone Player | all |
|
||||
| restoreall | Switch | Restore the state of all the Zone Players | all |
|
||||
| volume | Dimmer | This channel supports setting the master volume of the zoneplayer | all |
|
||||
| save | Switch | Save the state of the Zone Player | all |
|
||||
| saveall | Switch | Save the state of all the Zone Players | all |
|
||||
| shuffle | Switch | Shuffle the queue playback | all |
|
||||
| snooze | Switch | Snooze the running alarm, if any, with the given number of minutes | all |
|
||||
| standalone | Switch | Make the Zone Player leave its Group and become a standalone Zone Player | all |
|
||||
| state | String | The State channel contains state of the Zone Player, e.g. PLAYING, STOPPED,... | all |
|
||||
|
|
|
|||
|
|
@ -0,0 +1,79 @@
|
|||
---
|
||||
layout: documentation
|
||||
---
|
||||
|
||||
{% include base.html %}
|
||||
|
||||
# Toon Binding
|
||||
The Toon bindings shows among others current room temperature, setpoint, energy and gas usage information.
|
||||
It can control the setpoint and current program. Connected smart plugs can also be controlled.
|
||||
|
||||
|
||||
## Supported Things
|
||||
|
||||
### Toon Webaccount
|
||||
|
||||
Before the binding can be used, a Toon Webaccount must be added. This needs to be done manually. Select `Toon Webaccount`, and enter your username and password.
|
||||
Afterwards start discovery so your display and connected plugs are discovered.
|
||||
|
||||
### Toon display unit
|
||||
|
||||
The display unit holds all channels that represent current room temperature, setpoint, setpoint mode, gas and energy meter readings.
|
||||
|
||||
### Toon plug
|
||||
|
||||
A Toon plug represents a connected wall plug that can be controlled via Toon.
|
||||
|
||||
## Discovery
|
||||
|
||||
Once the binding is authorized, and the bridge is added, you can start the discovery. This will find your Toon Display and put it in the Inbox.
|
||||
|
||||
Currently only the display and plugs discovered. So no Alarms or Hue lights will be discovered.
|
||||
|
||||
## Binding Configuration
|
||||
|
||||
|
||||
|
||||
## Thing Configuration
|
||||
|
||||
demo.things
|
||||
```
|
||||
toon:toonapi:toontest [ username="xxxx", password="yyyy" ]
|
||||
```
|
||||
|
||||
## Items
|
||||
|
||||
demo.items:
|
||||
```
|
||||
Group Toon
|
||||
Number ToonTemp (Toon) {channel="toon:main:toontest:xxxx:Temperature"}
|
||||
Number ToonSetpoint (Toon) {channel="toon:main:toontest:xxxx:Setpoint"}
|
||||
Number ToonSetpointMode (Toon) {channel="toon:main:toontest:xxxx:SetpointMode"}
|
||||
|
||||
Number Gas (Toon) {channel="toon:main:toontest:xxxx:GasMeterReading"}
|
||||
Number Power (Toon) {channel="toon:main:toontest:xxxx:PowerMeterReading"}
|
||||
Number PowerLow (Toon) {channel="toon:main:toontest:xxxx:PowerMeterReadingLow"}
|
||||
Number PowerConsumption (Toon) {channel="toon:main:toontest:xxxx:PowerConsumption"}
|
||||
|
||||
Number Modulation (Toon) {channel="toon:main:toontest:xxxx:ModulationLevel"}
|
||||
Switch Heater (Toon) {channel="toon:main:toontest:xxxx:Heating"}
|
||||
Switch Tapwater (Toon) {channel="toon:main:toontest:xxxx:Tapwater"}
|
||||
Switch PreHeat (Toon) {channel="toon:main:toontest:xxxx:Preheat"}
|
||||
|
||||
```
|
||||
Replace xxxx with the discovered value.
|
||||
|
||||
## Sitemaps
|
||||
|
||||
demo.sitemaps
|
||||
```
|
||||
Frame {
|
||||
Group item=Toon
|
||||
Setpoint item=ToonSetpoint minValue=16 maxValue=28 step=0.5
|
||||
Selection item=ToonSetpointMode label="Toon Program Selection" mappings=[0=Comfort, 1=Active, 2=Sleep, 3=Away]
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
|
@ -32,19 +32,19 @@ The weather information that is retrieved is available as these channels:
|
|||
|
||||
## Full Example
|
||||
|
||||
demo.things:
|
||||
demo.things:
|
||||
|
||||
```
|
||||
yahooweather:weather:berlin [ location="638242" ]
|
||||
yahooweather:weather:berlin [ location=638242 ]
|
||||
```
|
||||
|
||||
demo.items:
|
||||
demo.items:
|
||||
|
||||
```
|
||||
Number Temperature "Outside Temperature" { channel="yahooweather:weather:berlin:temperature" }
|
||||
```
|
||||
|
||||
demo.sitemap:
|
||||
demo.sitemap:
|
||||
|
||||
```
|
||||
sitemap demo label="Main Menu"
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ ZWave is a wireless home automation protocol with reliable two way communication
|
|||
|
||||
A wide range of devices are supported from lights, switches and sensors to smoke alarms, window coverings and keyfobs. Z-Wave certification guarantees that certified devices will be compatible with each other and the network.
|
||||
|
||||
The binding uses a standard Z-Wave stick to communicate with the Z-Wave devices. There are many sticks available, and they all support the same interface so the binding does not distinguish between them.
|
||||
The binding uses a standard Z-Wave serial stick to communicate with the Z-Wave devices. There are many sticks available, and they all support the same interface so the binding does not distinguish between them.
|
||||
|
||||
|
||||
## Supported Things
|
||||
|
|
@ -23,7 +23,7 @@ Before the binding can be used, a serial adapter must be added. This needs to be
|
|||
|
||||
## Discovery
|
||||
|
||||
Once the binding is authorized, and an adapter is added, it automatically reads all devices that are set up on the Z-Wave controller and puts them in the Inbox.
|
||||
Once the binding is authorized, and an adapter is added, it automatically reads all devices that are included into the network. This is read directly from the Z-Wave controller and new things are added to the Inbox. When the discovery process is started, the binding will put the controller into inclusion mode for a defined period of time to allow new devices to be discovered and added to the network.
|
||||
|
||||
|
||||
## Binding Configuration
|
||||
|
|
@ -33,12 +33,15 @@ There is no binding level configuration required for the Z-Wave binding. All con
|
|||
|
||||
### Controller Configuration
|
||||
|
||||
#### Serial Port
|
||||
The following section lists the controller configuration. If using manual configuration in text files, the parameter names are given in the square brackets.
|
||||
|
||||
|
||||
#### Serial Port [port]
|
||||
|
||||
Sets the serial port name for the controller.
|
||||
|
||||
|
||||
#### Controller Is Master
|
||||
#### Controller Is Master [controller_master]
|
||||
|
||||
When *Controller Is Master* is true, the binding expects to be the main Z-Wave controller in the system. This is not related to the type of controller (*Primary* or *Secondary*), but is related to how devices will be configured. This will instruct the binding to perform configuration of the device to send network related information such as device wakeup to the binding.
|
||||
|
||||
|
|
@ -47,40 +50,71 @@ Many functions in Z-Wave only allow a single node to be set, and this is normall
|
|||
For most systems, this should be set to *true* - the only time when it should be *false* is if you normally control your Z-Wave network through a different system.
|
||||
|
||||
|
||||
#### Controller Is SUC
|
||||
#### Controller Is SUC [controller_suc]
|
||||
|
||||
#### Heal Time
|
||||
Sets the controller as a Static Update Controller within the network
|
||||
|
||||
|
||||
#### Inclusion Mode
|
||||
#### Heal Time [heal_time]
|
||||
|
||||
Sets the nightly heal time (in hours).
|
||||
|
||||
|
||||
#### Secure Inclusion Mode
|
||||
#### Inclusion Mode [inclusion_mode]
|
||||
|
||||
The inclusion mode setting allows the user to set how the controller will initiate inclusion when discovery is initiated. There are three options available -:
|
||||
|
||||
* Low Power Inclusion: In this mode devices must be within 1 meter of the controller to be included.
|
||||
* High Power Inclusion: In this mode devices must be able to communicate directly with the controller, so can be 10 to 15 meters from the controller under most conditions.
|
||||
* Network Wide Inclusion: In this mode devices can be anywhere in the network. This mode
|
||||
|
||||
|
||||
#### Secure Inclusion Mode [security_inclusionmode]
|
||||
|
||||
The secure command classes allow you to secure communications between devices in your network. Secure communications is a good thing, and for devices such as locks that protect the security of your property, it's mandatory. However, most devices support the same communications and functions over the standard communication classes, without security. The secure classes come with some negative points - they communicate more slowly, and consume more power in battery devices. This is because there is roughly twice as much communication required for the security classes. You should therefore consider if you need all devices secured, or if it is acceptable for your system to only secure entry devices.
|
||||
|
||||
This option allows you to select which classes will be configured to use security - you can elect to use security on all devices that support it, or only on entry control devices.
|
||||
|
||||
|
||||
#### Inclusion Mode Timeout
|
||||
#### Inclusion Mode Timeout [controller_inclusiontimeout]
|
||||
|
||||
This sets the maximum time that the controller will remain in inclusion or exclusion mode. Once inclusion is enabled, it will be disabled either when the first device is discovered, or when the timeout occurs. Generally this should be kept to a minimum as it increases the opportunity for unwanted nodes to be included into the network.
|
||||
|
||||
Note that updating this value will cause the controller to be reinitialised which will take all your Z-Wave devices offline for a short period.
|
||||
|
||||
|
||||
#### Network Security Key
|
||||
#### Default Wakeup Period [controller_wakeupperiod]
|
||||
|
||||
This sets the system wide default wakeup period. If a battery device does not have the wakeup period set to a value, then the system will configure it to use this value during the device configuration.
|
||||
|
||||
It is defined in seconds.
|
||||
|
||||
|
||||
#### Network Security Key [security_networkkey]
|
||||
|
||||
This sets the network security key used in your network for securing communications using the secure command classes. It is a 16 byte value, specified in hexadecimal.
|
||||
|
||||
|
||||
### Thing Configuration
|
||||
|
||||
There are a huge number of things supported by the Z-Wave binding, so configuration can not be covered here and you should refer to the device manual.
|
||||
|
||||
Things configured manually require the following minimum configuration to be set. -:
|
||||
|
||||
| Configuration | Description |
|
||||
|------------------|---------------------------------------------------------------------------------------------------------------|
|
||||
| zwave_nodeid | Sets the node id of the node within the network. |
|
||||
| zwave_deviceid | Specifies the manufacturer device ID for this device (as decimal). This is used to get the thing type from the database. |
|
||||
| zwave_devicetype | Specifies the manufacturer device type for this device (as decimal). This is used to get the thing type from the database. |
|
||||
| zwave_version | Specifies the application version for this device. This is used to get the thing type from the database. |
|
||||
|
||||
|
||||
## Channels
|
||||
|
||||
### Controller Channels
|
||||
|
||||
The table below summarises the channels available in the controller. These provide health information about the communications between the binding and the controller.
|
||||
|
||||
| Channel | Description |
|
||||
|------------|--------------------------------------------------------|
|
||||
| serial_sof | Counts number of frames started |
|
||||
|
|
@ -96,11 +130,11 @@ This sets the network security key used in your network for securing communicati
|
|||
|
||||
## Initialisation
|
||||
|
||||
To initialise the bunding and get your Z-Wave network running, you need to follow the following steps -:
|
||||
To initialise the binding and get your Z-Wave network running, you need to follow the following steps -:
|
||||
|
||||
* Manually install the serial controller. It doesn't matter what type of Z-Wave dongle you have, there is only a single *thing type* since all sticks use the same communication protocol, and the binding can detect what functions the device supports by communicating with the stick.
|
||||
* Set the serial port in the controller configuration.
|
||||
* In the UI enable *discovery* mode - this will add all existing things into the *discovery inbox*. From the *inbix* you can add the device directly into the system.
|
||||
* In the UI enable *discovery* mode - this will add all existing things into the *discovery inbox*. From the *inbox* you can add the device directly into the system.
|
||||
* the binding should automatically detect the device type and should provide a list of *channels* to which you can attach *items*. Note that it may take some time to discover the device type - especially in battery devices.
|
||||
|
||||
|
||||
|
|
@ -108,10 +142,12 @@ To initialise the bunding and get your Z-Wave network running, you need to follo
|
|||
|
||||
This section provides information on the Z-Wave network, and how functions are implemented in the binding.
|
||||
|
||||
|
||||
### Network Overview
|
||||
|
||||
The Z-Wave network includes devices known as *Controllers* and *Slaves*. As the name suggests, *Controllers* control how the network runs and provide network administration functions, while *Slaves* are users of the network.
|
||||
|
||||
|
||||
#### Home ID
|
||||
The network is identified with a *Home ID*. This is programmed into the controller, and can't be changed. It is used to identify the network in all frames that are transmitted over the air. When a device is included into a network, the controller sets the *Home ID* of the network in the slave so that the slave will only communicate over this network until it is removed from the network.
|
||||
|
||||
|
|
@ -138,7 +174,8 @@ Every device supports the *BASIC* command class. This is normally mapped to a sp
|
|||
|
||||
### Controllers
|
||||
|
||||
There are different types of controllers.
|
||||
There are different types of controllers in a Z-Wave network. This section provides an overview of the different types of controller.
|
||||
|
||||
|
||||
#### Primary Controller
|
||||
There is a single *Primary* controller in the network. This controller provides the network routing table
|
||||
|
|
@ -157,12 +194,16 @@ Most devices in your network are *slaves* - they come in in two types, *routing*
|
|||
|
||||
## Z-Wave in practice
|
||||
|
||||
This section endeavors to provide some practical information about Z-Wave networks and how the system works that may be of use to users.
|
||||
|
||||
|
||||
### Inclusion and Exclusion
|
||||
|
||||
Inclusion and exclusion are always started by the primary controller, unless an *SIS* is available in the network, in which case any controller can start these functions. To include or exclude a device in the network, set the controller into include mode, and press the appropriate button on the device to place the device into include mode. All Z-Wave devices will have such a button, and you should refer to the device manual.
|
||||
|
||||
Secure inclusion must be started from the binding. This is because once the device is included into the network, a key exchange takes place between the binding and the device. This key exchange must take place within a very short time of the inclusion, and if it doesn't succeed, the device must be excluded and included again. Secure inclusion will generate a lot of activity on the network, so you should avoid other activities at the same time, and the device being included should be close to the controller to reduce any retries that could cause the security handshake to fail.
|
||||
|
||||
|
||||
### Device Initialisation
|
||||
|
||||
As soon as the device is discovered (eg included) it is added to the inbox. At this point we still don't know the manufacturer etc.
|
||||
|
|
@ -174,12 +215,23 @@ We then initialise some information in the device such as associations. Associat
|
|||
This discovery is only performed once, and the information is then persisted when the binding is restarted. On each restart the binding will perform an update of the information to read any dynamic data from the device.
|
||||
|
||||
|
||||
### Thing States
|
||||
|
||||
Internally the binding holds a device state and these states are mapped to the system states ONLINE and OFFLINE. This section provides an explanation of the meaning of the states.
|
||||
|
||||
* ONLINE - A device is considered to be operating normally.
|
||||
* DEAD - A device is considered DEAD if it does not respond to a message three times. This is a binding state only and while the binding will continue to attempt to contact a DEAD device retries to the node will be stopped until it responds. DEAD devices can slow down communications within the network so you are advised to remove DEAD devices from the network if possible. DEAD devices will be marked as OFFLINE within the system status.
|
||||
* FAILED - A device is considered FAILED if the controller can not communicate with the device. The binding does not control this. FAILED devices are treated in a similar way to DEAD devices however the controller will reduce communications to the device and will timeout quicker. It should be noted that the controller will generally not consider battery devices as failed. FAILED devices will be marked as OFFLINE within the system status.
|
||||
|
||||
|
||||
### Associations
|
||||
|
||||
Associations are used by Z-Wave devices to send commands from one device to another, independent of the controller. This could be used to turn on a light when a movement sensor is triggered. Associations are also used to send state updates to the controller when the state of a device changes. For example, if you turn a light on, the device will let the controller know so that the state of the light is shown correctly within the user interface.
|
||||
Associations are used by Z-Wave devices to send commands from one device to another, independent of the controller. This could be used to turn on a light when a movement sensor is triggered without requiring the message from the movement sensor to be used to trigger a rule, and for the rule to send a message to turn on the light. Associations are also used to send state updates to the controller when the state of a device changes. For example, if you turn a light on, the device will let the controller know so that the state of the light is shown correctly within the user interface.
|
||||
|
||||
Often there is a *Lifeline* association group, and normally this is the only association that is required in order to notify the binding of changes to the device. If you set the controller node into other association groups, you will likely receive multiple notifications - while this shouldn't cause problems most of the time, it can reduce battery life in battery powered devices, and may cause issues with rules.
|
||||
|
||||
It should be noted that associations are only triggered from a local action within the device. Thus if a command is sent from one device to a second device, and the second device has an association to notify the controller when it changes state, this will not be sent to the controller in these circumstances.
|
||||
|
||||
|
||||
### Battery Devices
|
||||
|
||||
|
|
@ -187,16 +239,23 @@ Z-Wave battery devices require additional configuration in order for them to ope
|
|||
|
||||
In order to configure the device properly following its initial inclusion in the network, the device must be woken up a number of times while close to the controller. During this time, the binding will read the device information, but will also configure some settings. The most important is to configure the wakeup period, and wakeup node - until this is done, the device will not wake up periodically, and if it is out of direct range of the controller, it will not be able to communicate with the controller.
|
||||
|
||||
A battery device will be considered *DEAD* if the controller does not receive a wakeup notification, or some other message, within approximately twice the wakeup period. In this event, the thing will be set offline and the device considered *DEAD*.
|
||||
|
||||
|
||||
### Polling
|
||||
|
||||
The binding supports periodic polling. This has two purposes - firstly to ensure that a device is still responding, and secondly to update the bindings representation of the state of the device. Where possible *associations* should be used to update the device state - this will keep network traffic to a minimum, which will improve the network latency, and it will be faster since *associations* send updates to the controller immediately where polling will always be noticeably slower.
|
||||
|
||||
Keep the polling at a slow rate unless your device doesn't support *associations*.
|
||||
If a device fails to respond to a poll, then it will be marked as DEAD and shown as offline. For battery devices, if they do no provide a wakeup within a period of twice the wakeup period, then they will also be considered dead and taken offline.
|
||||
|
||||
Keep the polling at a slow rate unless your device doesn't support *associations*. This will reduce network traffic, reduce the chance of timeouts and retries, and therefore improve the overall performance of the network.
|
||||
|
||||
|
||||
### Binding Maintenance Functions
|
||||
|
||||
The binding provides a number of facilities for maintaining the network.
|
||||
|
||||
|
||||
#### Mesh Heal
|
||||
|
||||
Sometimes the Z-Wave mesh can get messed up and nodes can become 'lost'. In theory, the Z-Wave controller should automatically resolve these issues, and any device that finds itself orphaned from the network should send a *Explorer Frames* to request a routing update.
|
||||
|
|
@ -208,6 +267,16 @@ While the neighbor update is running, all nodes in the system will be taken offl
|
|||
Once the neighbor update is complete, the system will perform a routing update on all nodes. Z-Wave is a "source routed mesh network" which means that the controller needs to tell the end nodes information about its routes. Specifically, the controller will provide each node a list of routes required to talk to the controller, the SUC (if it exists in the network), and other nodes to which the controller needs to talk to (eg for associated devices). The binding simply instructs the stick to configure a route between two nodes - the route itself if derived by the stick and the binding has no visibility of the actual routes being used.
|
||||
|
||||
|
||||
#### Joining as a secondary controller
|
||||
|
||||
The binding can be added to the network as a secondary controller. This can be useful if you already have another home automation system and you want to use the binding as a secondary controller.
|
||||
|
||||
|
||||
#### Network updates
|
||||
|
||||
A secondary controller can receive an updated list of network nodes from the primary controller...
|
||||
|
||||
|
||||
### Z-Wave Device Database
|
||||
|
||||
A database of device information is required for Z-Wave since there is no way to know the devices configuration directly from the device. Some Z-Wave command classes have preset configuration, and these we can implicitly configure, however the configuration command class has no device specific declarations. This data is normally provided by the device manufacturer in the manual, or on their website.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,196 @@
|
|||
<!--
|
||||
#
|
||||
# Licensed to the Apache Software Foundation (ASF) under one
|
||||
# or more contributor license agreements. See the NOTICE file
|
||||
# distributed with this work for additional information
|
||||
# regarding copyright ownership. The ASF licenses this file
|
||||
# to you under the Apache License, Version 2.0 (the
|
||||
# "License"); you may not use this file except in compliance
|
||||
# with the License. You may obtain a copy of the License at
|
||||
#
|
||||
# http://www.apache.org/licenses/LICENSE-2.0
|
||||
#
|
||||
# Unless required by applicable law or agreed to in writing,
|
||||
# software distributed under the License is distributed on an
|
||||
# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
|
||||
# KIND, either express or implied. See the License for the
|
||||
# specific language governing permissions and limitations
|
||||
# under the License.
|
||||
#
|
||||
-->
|
||||
# Cordova Hooks
|
||||
|
||||
Cordova Hooks represent special scripts which could be added by application and plugin developers or even by your own build system to customize cordova commands. Hook scripts could be defined by adding them to the special predefined folder (`/hooks`) or via configuration files (`config.xml` and `plugin.xml`) and run serially in the following order:
|
||||
* Application hooks from `/hooks`;
|
||||
* Application hooks from `config.xml`;
|
||||
* Plugin hooks from `plugins/.../plugin.xml`.
|
||||
|
||||
__Remember__: Make your scripts executable.
|
||||
|
||||
__Note__: `.cordova/hooks` directory is also supported for backward compatibility, but we don't recommend using it as it is deprecated.
|
||||
|
||||
## Supported hook types
|
||||
The following hook types are supported:
|
||||
|
||||
after_build/
|
||||
after_compile/
|
||||
after_docs/
|
||||
after_emulate/
|
||||
after_platform_add/
|
||||
after_platform_rm/
|
||||
after_platform_ls/
|
||||
after_plugin_add/
|
||||
after_plugin_ls/
|
||||
after_plugin_rm/
|
||||
after_plugin_search/
|
||||
after_plugin_install/ <-- Plugin hooks defined in plugin.xml are executed exclusively for a plugin being installed
|
||||
after_prepare/
|
||||
after_run/
|
||||
after_serve/
|
||||
before_build/
|
||||
before_compile/
|
||||
before_docs/
|
||||
before_emulate/
|
||||
before_platform_add/
|
||||
before_platform_rm/
|
||||
before_platform_ls/
|
||||
before_plugin_add/
|
||||
before_plugin_ls/
|
||||
before_plugin_rm/
|
||||
before_plugin_search/
|
||||
before_plugin_install/ <-- Plugin hooks defined in plugin.xml are executed exclusively for a plugin being installed
|
||||
before_plugin_uninstall/ <-- Plugin hooks defined in plugin.xml are executed exclusively for a plugin being uninstalled
|
||||
before_prepare/
|
||||
before_run/
|
||||
before_serve/
|
||||
pre_package/ <-- Windows 8 and Windows Phone only.
|
||||
|
||||
## Ways to define hooks
|
||||
### Via '/hooks' directory
|
||||
To execute custom action when corresponding hook type is fired, use hook type as a name for a subfolder inside 'hooks' directory and place you script file here, for example:
|
||||
|
||||
# script file will be automatically executed after each build
|
||||
hooks/after_build/after_build_custom_action.js
|
||||
|
||||
|
||||
### Config.xml
|
||||
|
||||
Hooks can be defined in project's `config.xml` using `<hook>` elements, for example:
|
||||
|
||||
<hook type="before_build" src="scripts/appBeforeBuild.bat" />
|
||||
<hook type="before_build" src="scripts/appBeforeBuild.js" />
|
||||
<hook type="before_plugin_install" src="scripts/appBeforePluginInstall.js" />
|
||||
|
||||
<platform name="wp8">
|
||||
<hook type="before_build" src="scripts/wp8/appWP8BeforeBuild.bat" />
|
||||
<hook type="before_build" src="scripts/wp8/appWP8BeforeBuild.js" />
|
||||
<hook type="before_plugin_install" src="scripts/wp8/appWP8BeforePluginInstall.js" />
|
||||
...
|
||||
</platform>
|
||||
|
||||
<platform name="windows8">
|
||||
<hook type="before_build" src="scripts/windows8/appWin8BeforeBuild.bat" />
|
||||
<hook type="before_build" src="scripts/windows8/appWin8BeforeBuild.js" />
|
||||
<hook type="before_plugin_install" src="scripts/windows8/appWin8BeforePluginInstall.js" />
|
||||
...
|
||||
</platform>
|
||||
|
||||
### Plugin hooks (plugin.xml)
|
||||
|
||||
As a plugin developer you can define hook scripts using `<hook>` elements in a `plugin.xml` like that:
|
||||
|
||||
<hook type="before_plugin_install" src="scripts/beforeInstall.js" />
|
||||
<hook type="after_build" src="scripts/afterBuild.js" />
|
||||
|
||||
<platform name="wp8">
|
||||
<hook type="before_plugin_install" src="scripts/wp8BeforeInstall.js" />
|
||||
<hook type="before_build" src="scripts/wp8BeforeBuild.js" />
|
||||
...
|
||||
</platform>
|
||||
|
||||
`before_plugin_install`, `after_plugin_install`, `before_plugin_uninstall` plugin hooks will be fired exclusively for the plugin being installed/uninstalled.
|
||||
|
||||
## Script Interface
|
||||
|
||||
### Javascript
|
||||
|
||||
If you are writing hooks in Javascript you should use the following module definition:
|
||||
```javascript
|
||||
module.exports = function(context) {
|
||||
...
|
||||
}
|
||||
```
|
||||
|
||||
You can make your scipts async using Q:
|
||||
```javascript
|
||||
module.exports = function(context) {
|
||||
var Q = context.requireCordovaModule('q');
|
||||
var deferral = new Q.defer();
|
||||
|
||||
setTimeout(function(){
|
||||
console.log('hook.js>> end');
|
||||
deferral.resolve();
|
||||
}, 1000);
|
||||
|
||||
return deferral.promise;
|
||||
}
|
||||
```
|
||||
|
||||
`context` object contains hook type, executed script full path, hook options, command-line arguments passed to Cordova and top-level "cordova" object:
|
||||
```json
|
||||
{
|
||||
"hook": "before_plugin_install",
|
||||
"scriptLocation": "c:\\script\\full\\path\\appBeforePluginInstall.js",
|
||||
"cmdLine": "The\\exact\\command\\cordova\\run\\with arguments",
|
||||
"opts": {
|
||||
"projectRoot":"C:\\path\\to\\the\\project",
|
||||
"cordova": {
|
||||
"platforms": ["wp8"],
|
||||
"plugins": ["com.plugin.withhooks"],
|
||||
"version": "0.21.7-dev"
|
||||
},
|
||||
"plugin": {
|
||||
"id": "com.plugin.withhooks",
|
||||
"pluginInfo": {
|
||||
...
|
||||
},
|
||||
"platform": "wp8",
|
||||
"dir": "C:\\path\\to\\the\\project\\plugins\\com.plugin.withhooks"
|
||||
}
|
||||
},
|
||||
"cordova": {...}
|
||||
}
|
||||
|
||||
```
|
||||
`context.opts.plugin` object will only be passed to plugin hooks scripts.
|
||||
|
||||
You can also require additional Cordova modules in your script using `context.requireCordovaModule` in the following way:
|
||||
```javascript
|
||||
var Q = context.requireCordovaModule('q');
|
||||
```
|
||||
|
||||
__Note__: new module loader script interface is used for the `.js` files defined via `config.xml` or `plugin.xml` only.
|
||||
For compatibility reasons hook files specified via `/hooks` folders are run via Node child_process spawn, see 'Non-javascript' section below.
|
||||
|
||||
### Non-javascript
|
||||
|
||||
Non-javascript scripts are run via Node child_process spawn from the project's root directory and have the root directory passes as the first argument. All other options are passed to the script using environment variables:
|
||||
|
||||
* CORDOVA_VERSION - The version of the Cordova-CLI.
|
||||
* CORDOVA_PLATFORMS - Comma separated list of platforms that the command applies to (e.g.: android, ios).
|
||||
* CORDOVA_PLUGINS - Comma separated list of plugin IDs that the command applies to (e.g.: org.apache.cordova.file, org.apache.cordova.file-transfer)
|
||||
* CORDOVA_HOOK - Path to the hook that is being executed.
|
||||
* CORDOVA_CMDLINE - The exact command-line arguments passed to cordova (e.g.: cordova run ios --emulate)
|
||||
|
||||
If a script returns a non-zero exit code, then the parent cordova command will be aborted.
|
||||
|
||||
## Writing hooks
|
||||
|
||||
We highly recommend writting your hooks using Node.js so that they are
|
||||
cross-platform. Some good examples are shown here:
|
||||
|
||||
[http://devgirl.org/2013/11/12/three-hooks-your-cordovaphonegap-project-needs/](http://devgirl.org/2013/11/12/three-hooks-your-cordovaphonegap-project-needs/)
|
||||
|
||||
Also, note that even if you are working on Windows, and in case your hook scripts aren't bat files (which is recommended, if you want your scripts to work in non-Windows operating systems) Cordova CLI will expect a shebang line as the first line for it to know the interpreter it needs to use to launch the script. The shebang line should match the following example:
|
||||
|
||||
#!/usr/bin/env [name_of_interpreter_executable]
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 230 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 246 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 203 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 247 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 248 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 88 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 273 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 288 KiB |
|
|
@ -0,0 +1,67 @@
|
|||
---
|
||||
layout: documentation
|
||||
---
|
||||
|
||||
{% include base.html %}
|
||||
|
||||
HABmin
|
||||
======
|
||||
|
||||
HABmin is a modern, professional and portable user interface for openHAB,
|
||||
providing both user and administrative functions (eg sitemaps for users, and configuration utilities
|
||||
to aid setup).
|
||||
|
||||
Features
|
||||
========
|
||||
|
||||
* **Responsive**. Should work well on all devices. Of course some functions may be removed or be difficult to use on small devices (eg the graphical rule editor).
|
||||
* **Theme-able**. Multiple themes are available - take your pick (currently 3 themes). If you want a different look, we're using [bootswatch](http://www.bootswatch.com) themes - vote for your favourite by [raising an issue](https://github.com/openhab/org.openhab.ui.habmin/issues/new).
|
||||
* **Charting**. Modern, fast charting of historical data.
|
||||
* **Graphical rule editor**. No need to learn rule syntax.
|
||||
* **International support**. Currently translated in English, Deutsch, Français. Add support for your language...
|
||||
* Available as native app for **Android**.
|
||||
|
||||
|
||||
Screenshots
|
||||
===========
|
||||
|
||||
The following images show a selection of screenshots. Note that the theme is user selectable, although most images are shown with a dark (*slate*) theme (except the mobile sitemap image).
|
||||
|
||||
Graphing a saved chart...
|
||||
|
||||
|
||||
|
||||
|
||||
Editing a saved chart...
|
||||
|
||||
|
||||
|
||||
|
||||
Editing rules (graphical editor)...
|
||||
|
||||
|
||||
|
||||
|
||||
Editing rules (text editor)...
|
||||
|
||||
|
||||
|
||||
|
||||
Dashboard view (Paper theme, French localisation)...
|
||||
|
||||
|
||||
|
||||
|
||||
ZWave device configuration...
|
||||
|
||||
|
||||
|
||||
|
||||
ZWave network routing diagram...
|
||||
|
||||
|
||||
|
||||
|
||||
Sitemaps (mobile view using *yeti* theme)...
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,78 @@
|
|||
angular-dialgauge
|
||||
=================
|
||||
|
||||
AngularJS directive for a dial gauge. This uses SVG and will automatically size to the parent. Therefore the parent should
|
||||
have a size.
|
||||
|
||||
The following options are possible. These can either be set as separate configuration items, or a configuration object
|
||||
called ```options``` can be set to provide a single configuration object.
|
||||
|
||||
Option | Description
|
||||
--------------------| -----------
|
||||
rotate | Sets the rotation of the gauge
|
||||
angle | Sets the total angle of the active part of the gauge
|
||||
scaleMin | Sets the minimum value
|
||||
scaleMax | Sets the maximum value
|
||||
lineCap | Sets the endcap for the bar line (round, butt, square)
|
||||
barWidth | Sets the width of the bar
|
||||
barColor | Sets the color of the bar
|
||||
barColorEnd | Along with _barColor_ will produce a dynamic color for the bar. Must be used with ```#rrggbb``` color format.
|
||||
barAngle | Sets the angle of the indicator if a knob style is desired
|
||||
trackColor | Sets the color of the track behind the bar
|
||||
scaleOffset |
|
||||
scaleMajorColor | Sets the color to be used for the minor ticks in the scale
|
||||
scaleMajorWidth | Sets the width of the line for the minor ticks in the scale
|
||||
scaleMajorLength | Sets the length of the line for the minor ticks in the scale
|
||||
scaleMajorSteps | Sets the number of major steps
|
||||
scaleMinorColor | Sets the color to be used for the minor ticks in the scale
|
||||
scaleMinorWidth | Sets the width of the line for the minor ticks in the scale
|
||||
scaleMinorLength | Sets the length of the line for the minor ticks in the scale
|
||||
scaleMinorSteps | Sets the number of minor steps
|
||||
dialWidth |
|
||||
borderWidth | Sets the width of the border
|
||||
borderOffset | Sets the number of pixels between the border and the scale
|
||||
borderColor | Sets the border color used to create a circle around the outside of the gauge
|
||||
title | Sets the title string
|
||||
units | Sets the text to be used for the units
|
||||
|
||||
|
||||
The following CSS classes can be used for the text -:
|
||||
|
||||
Class | Description
|
||||
--------------------| -----------
|
||||
dialgauge-title | Styles the title caption
|
||||
dialgauge-value | Styles the value (number)
|
||||
dialgauge-unit | Styles the unit
|
||||
|
||||
|
||||
For example -:
|
||||
```
|
||||
.dialgauge-unit {
|
||||
font-size:14px;
|
||||
font-weight:100;
|
||||
fill: grey;
|
||||
stroke: grey;
|
||||
}
|
||||
|
||||
.dialgauge-value {
|
||||
font-size:20px;
|
||||
font-weight:200;
|
||||
fill: white;
|
||||
stroke: white;
|
||||
}
|
||||
```
|
||||
|
||||
Installation
|
||||
============
|
||||
Use bower
|
||||
```
|
||||
bower install angular-dialgauge --save
|
||||
```
|
||||
|
||||
Add the ```angular-dialgauge.js``` file to your application and ensure you register the directive by adding
|
||||
```ngDialGauge``` to your app.
|
||||
|
||||
|
||||
License
|
||||
=======
|
||||
Licensed under MIT license.
|
||||
|
|
@ -0,0 +1,57 @@
|
|||
# bower-angular-localization
|
||||
|
||||
This repo is for distribution on `bower`. The source for this module is in the
|
||||
[main AngularJS Localization repo](https://github.com/doshprompt/angular-localization).
|
||||
Please file issues and pull requests against that repo.
|
||||
|
||||
## Install
|
||||
|
||||
Install with `bower`:
|
||||
|
||||
```shell
|
||||
bower install angular-localization
|
||||
```
|
||||
|
||||
Add a `<script>` to your `index.html`:
|
||||
|
||||
```html
|
||||
<script src="bower_components/angular/angular.js"></script>
|
||||
<script src="bower_components/angular-cookies/angular-cookies.js"></script>
|
||||
<script src="bower_components/angular-sanitize/angular-sanitize.js"></script>
|
||||
<script src="bower_components/angular-localization/angular-localization.js"></script>
|
||||
```
|
||||
|
||||
Inject the dependency into your application module
|
||||
|
||||
```js
|
||||
angular.module('myApp', ['ngLocalize']);
|
||||
```
|
||||
|
||||
## Documentation
|
||||
|
||||
Documentation is available on the
|
||||
[main AngularJS Localization repo](https://github.com/doshprompt/angular-localization).
|
||||
|
||||
## License
|
||||
|
||||
The MIT License (MIT)
|
||||
|
||||
Copyright (c) 2014 Rahul Doshi
|
||||
|
||||
Permission is hereby granted, free of charge, to any person obtaining a copy
|
||||
of this software and associated documentation files (the "Software"), to deal
|
||||
in the Software without restriction, including without limitation the rights
|
||||
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
||||
copies of the Software, and to permit persons to whom the Software is
|
||||
furnished to do so, subject to the following conditions:
|
||||
|
||||
The above copyright notice and this permission notice shall be included in all
|
||||
copies or substantial portions of the Software.
|
||||
|
||||
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
||||
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
||||
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
||||
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
||||
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
||||
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
||||
SOFTWARE.
|
||||
|
|
@ -0,0 +1,36 @@
|
|||
# angular-toggle-switch [](https://travis-ci.org/cgarvis/angular-toggle-switch)
|
||||
|
||||
Toggle Switches for AngularJS. Based off [Bootstrap switch](http://www.larentis.eu/switch/) by Matt Lartentis.
|
||||
|
||||
## Demo
|
||||
[cgarvis.github.io/angular-toggle-switch](http://cgarvis.github.io/angular-toggle-switch)
|
||||
|
||||
## Installation
|
||||
|
||||
Download [angular-toggle-switch.min.js](https://raw.github.com/cgarvis/angular-toggle-switch/master/angular-toggle-switch.min.js) or install with bower.
|
||||
|
||||
```bash
|
||||
$ bower install angular-toggle-switch --save
|
||||
```
|
||||
|
||||
Load `angular-toggle-switch.min.js` then add the `toggle-switch` module to your Angular App.
|
||||
|
||||
```javascript
|
||||
angular.module('app', ['toggle-switch']);
|
||||
```
|
||||
|
||||
See [demo](http://cgarvis.github.io/angular-toggle-switch) for usage.
|
||||
|
||||
## Development
|
||||
|
||||
Testing is done using Karma Test Runner.
|
||||
|
||||
```bash
|
||||
$ grunt test
|
||||
```
|
||||
|
||||
## Release
|
||||
|
||||
```bash
|
||||
$ grunt release
|
||||
```
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 22 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 59 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 51 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 61 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 57 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 37 KiB |
|
|
@ -0,0 +1,43 @@
|
|||
---
|
||||
layout: documentation
|
||||
---
|
||||
|
||||
{% include base.html %}
|
||||
|
||||
HABPanel
|
||||
========
|
||||
|
||||
HABPanel is a lightweight dashboard interface for openHAB.
|
||||
|
||||
It notably features a quasi-WYSIWYG in-app editor allowing the user to design the dashboard directly on the target device.
|
||||
|
||||
## Configuration
|
||||
|
||||
HABPanel stores its configuration (including sets of dashboards, called panel configurations) as openHAB 2 service configuration variables.
|
||||
This allows sharing of panel configurations between devices. You can also lock down editing globally to prevent accidental changes.
|
||||
|
||||
You can access the configuration in Paper UI, _Configuration > Services > HABPanel_.
|
||||
|
||||
Note: by default, HABPanel uses the local browser's storage until you save it in a new panel configuration as detailed below.
|
||||
|
||||
## Getting started
|
||||
|
||||
- When accessing HABPanel for the first time on a new browser or device, you should be presented with a rather empty screen with a clock, a settings icon (gears) to the left. Click on the icon.
|
||||
- You're now in edit mode, a link (**"Add new dashboard"**) appeared, as well as an "Advanced settings" link.
|
||||
- If you previously used HABPanel, are using openHAB 2 and stored some panel configurations on the server, go to "Advanced settings" and click on your previous configuration. Otherwise, create your first dashboard: click on the "Add new dashboard" link and give it a name.
|
||||
- Click on the dashboard tile to enter the dashboard editor
|
||||
- Add your first widget: click on "Add Widget" and select the type in the menu (let's say Dummy)
|
||||
- Move the widget by drag-and-drop and resize it with the white chevron - it appears when you click on the widget
|
||||
- Click on the gears icon to bring up the widget's settings
|
||||
- Rename the widget, bind it to a supported openHAB item, adjust some settings and click OK
|
||||
- Save your configuration by clicking the Save button
|
||||
- Click Run to see your dashboard in action - use your browser's back button or the arrow to go back to the drawing board
|
||||
- When you're happy with your set of dashboards, go back to "Advanced settings" and either "Show the local configuration object" (the only available if using openHAB 1) and copy the JSON object somewhere to back it up, or click on "Save the current configuration to a new panel configuration"; this will store it on the openHAB 2 server and make it available for reuse.
|
||||
|
||||
## Screenshots
|
||||
|
||||
_(excuse the French, will make new ones in English later)_
|
||||
|
||||
 
|
||||
 
|
||||
 
|
||||
|
|
@ -6,7 +6,7 @@ layout: documentation
|
|||
|
||||
# Events
|
||||
|
||||
The Eclipse SmartHome framework provides an event bus for inter-component communication. The communication is based on events which can be sent and received through the event bus in an asynchronous way. Examples of Eclipse SmartHome event types are _ItemCommandEvent_, _ItemStateEvent_, _ItemAddedEvent_, _ThingStatusInfoEvent_, etc.
|
||||
The Eclipse SmartHome framework provides an event bus for inter-component communication. The communication is based on events which can be sent and received through the event bus in an asynchronous way. Examples of Eclipse SmartHome event types are _ItemCommandEvent_, _ItemStateEvent_, _ItemAddedEvent_, _ThingStatusInfoEvent_, etc.
|
||||
|
||||
This section gives a short overview about the event API and illustrates how to receive such events. Furthermore, the sending of events and the implementation of new event types will be described.
|
||||
|
||||
|
|
@ -18,18 +18,18 @@ A code snippet about receiving events can be found in chapter "Receive Events".
|
|||
|
||||
|
||||
|
||||
The `EventPublisher` posts `Event`s through the Eclipse SmartHome event bus in an asynchronous way. The `EventSubscriber` defines the callback interface to receive events of specific types to which the event subscriber is subscribed. The EventPublisher and the EventSubscribers are registered as OSGi services. An event subscriber can provide an `EventFilter` in order to filter events based on the topic or the content. If there is no filter all subscribed event types are received. The event itself will be subclassed for each event type, which exists in the System (e.g. ItemCommandEvent, ItemUpdatedEvent, ThingStatusInfoEvent).
|
||||
The `EventPublisher` posts `Event`s through the Eclipse SmartHome event bus in an asynchronous way. The `EventSubscriber` defines the callback interface to receive events of specific types to which the event subscriber is subscribed. The EventPublisher and the EventSubscribers are registered as OSGi services. An event subscriber can provide an `EventFilter` in order to filter events based on the topic or the content. If there is no filter all subscribed event types are received. The event itself will be subclassed for each event type, which exists in the System (e.g. ItemCommandEvent, ItemUpdatedEvent, ThingStatusInfoEvent).
|
||||
|
||||
### The Core Events
|
||||
This section lists the core events provided by Eclipse SmartHome which can be divided into the categories _Item Events_, _Thing Events_ and _Inbox Events_.
|
||||
This section lists the core events provided by Eclipse SmartHome which can be divided into the categories _Item Events_, _Thing Events_ and _Inbox Events_.
|
||||
|
||||
An event consists of a `topic`, a `type`, a `payload` and a `source`. The payload can be serialized with any String representation and is determined by its concrete event type implementation (e.g. ItemCommandEvent, ItemUpdatedEvent). The payloads of the Eclipse SmartHome core events are serialized with JSON. Each event implementation provides the payload as high level methods as well, usually presented by a data transfer object (DTO).
|
||||
|
||||
A topic clearly defines the target of the event and its structure is similar to a REST URI, except the last part, the action. The topics of Eclipse SmartHome events are divided into the following four parts: `{namespace}/{entityType}/{entity}/{action}`, e.g. `smarthome/items/{itemName}/command`.
|
||||
A topic clearly defines the target of the event and its structure is similar to a REST URI, except the last part, the action. The topics of Eclipse SmartHome events are divided into the following four parts: `{namespace}/{entityType}/{entity}/{action}`, e.g. `smarthome/items/{itemName}/command`.
|
||||
|
||||
The type of an event is represented by a string, usually the name of the concrete event implementation class, e.g. ItemCommandEvent, ItemUpdatedEvent. This string type presentation is used by event subscribers for event subscription (see chapter "Receive Events") and by the framework for the creation of concrete event instances.
|
||||
The type of an event is represented by a string, usually the name of the concrete event implementation class, e.g. ItemCommandEvent, ItemUpdatedEvent. This string type presentation is used by event subscribers for event subscription (see chapter "Receive Events") and by the framework for the creation of concrete event instances.
|
||||
|
||||
The event source is optional and represents the name of the source identifying the sender.
|
||||
The event source is optional and represents the name of the source identifying the sender.
|
||||
|
||||
#### Item Events
|
||||
|
||||
|
|
@ -73,6 +73,11 @@ The event source is optional and represents the name of the source identifying t
|
|||
| ItemThingLinkAddedEvent |An item thing link has been added to the registry. |smarthome/links/{itemName}-{thingUID}/added |
|
||||
| ItemThingLinkRemovedEvent |An item thing link has been removed from the registry. |smarthome/links/{itemName}-{thingUID}/removed |
|
||||
|
||||
#### Channel Events
|
||||
| Event |Description |Topic |
|
||||
|-----------------------------|---------------------------------------------------------|------------------------------------------------|
|
||||
| ChannelTriggeredEvent |A channel has been triggered. |smarthome/channels/{channelUID}/triggered |
|
||||
|
||||
## Receive Events
|
||||
|
||||
This section describes how to receive Eclipse SmartHome events in Java. If you want to receive events "outside" Eclipse SmartHome, e.g. with JavaScript, please refer to the [Server Sent Events section](../features/rest.html).
|
||||
|
|
@ -83,7 +88,7 @@ An event subscriber defines the callback interface for receiving events from the
|
|||
public class SomeItemEventSubscriber implements EventSubscriber {
|
||||
private final Set<String> subscribedEventTypes = ImmutableSet.of(ItemStateEvent.TYPE, ItemCommandEvent.TYPE);
|
||||
private final EventFilter eventFiter = new TopicEventFilter("smarthome/items/ItemX/.*");
|
||||
|
||||
|
||||
@Override
|
||||
public Set<String> getSubscribedEventTypes() {
|
||||
return subscribedEventTypes;
|
||||
|
|
@ -113,7 +118,7 @@ public class SomeItemEventSubscriber implements EventSubscriber {
|
|||
```
|
||||
The `SomeItemEventSubscriber` is subscribed to the event types `ItemStateEvent` and `ItemCommandEvent`, provided by the method `getSubscribedEventTypes()`. A string representation of an event type can be found by a public member `TYPE` which usually presents the name of the class. To subscribe to all available event types, use the public member `ALL_EVENT_TYPES` of the event subscriber interface.
|
||||
|
||||
The event subscriber provides a `TopicEventFilter` which is a default Eclipse SmartHome `EventFilter` implementation that ensures filtering of events based on a topic. The argument of the filter is a [Java regular expression](http://docs.oracle.com/javase/7/docs/api/java/util/regex/Pattern.html). The filter method `EventFilter.apply()` will be called for each event on the event bus to which the event subscriber is subscribed (in the example above ItemStateEvent and ItemCommandEvent). If the filter applies (in the given example for all item events with the item name "ItemX"), the event will be received by the `EventSubscriber.receive()` method. Received events can be cast to the event implementation class for further processing.
|
||||
The event subscriber provides a `TopicEventFilter` which is a default Eclipse SmartHome `EventFilter` implementation that ensures filtering of events based on a topic. The argument of the filter is a [Java regular expression](http://docs.oracle.com/javase/7/docs/api/java/util/regex/Pattern.html). The filter method `EventFilter.apply()` will be called for each event on the event bus to which the event subscriber is subscribed (in the example above ItemStateEvent and ItemCommandEvent). If the filter applies (in the given example for all item events with the item name "ItemX"), the event will be received by the `EventSubscriber.receive()` method. Received events can be cast to the event implementation class for further processing.
|
||||
|
||||
Each event subscriber must be registered via OSGi Declarative Services (DS) under the `org.eclipse.smarthome.event.EventSubscriber` interface.
|
||||
|
||||
|
|
@ -130,18 +135,18 @@ The listing below summarizes some best practices in order to implement event sub
|
|||
|
||||
- To subscribe to only one event type Eclipse SmartHome provides the `org.eclipse.smarthome.core.events.AbstractTypedEventSubscriber` implementation. To receive an already cast event the `receiveTypedEvent(T)` method must be implemented. To provide an event filter the method `getEventFilter()` can be overridden.
|
||||
- Eclipse SmartHome provides an `AbstractItemEventSubscriber` class in order to receive ItemStateEvents and ItemCommandEvents (more information can be obtained in the next chapter).
|
||||
- To filter events based on a topic the `org.eclipse.smarthome.core.events.TopicEventFilter` implementation from the Eclipse SmartHome core bundle can be used. The filtering is based on [Java regular expression](http://docs.oracle.com/javase/7/docs/api/java/util/regex/Pattern.html).
|
||||
- The subscribed event types and the filter should be stored as class members (see example above) due to performance reasons.
|
||||
- To filter events based on a topic the `org.eclipse.smarthome.core.events.TopicEventFilter` implementation from the Eclipse SmartHome core bundle can be used. The filtering is based on [Java regular expression](http://docs.oracle.com/javase/7/docs/api/java/util/regex/Pattern.html).
|
||||
- The subscribed event types and the filter should be stored as class members (see example above) due to performance reasons.
|
||||
- If the subscribed event types are sufficient in order to receive all interested events, do not return any filter (in that case the method getFilter() returns null) due to performance reasons.
|
||||
- Avoid the creation of too many event subscribers. Similar event types can be received in one event subscriber.
|
||||
- Handle exceptions in event subscriber implementation and throw only serious exceptions. Thrown exceptions will be handled in the framework by logging an error message with the cause.
|
||||
- Handle exceptions in event subscriber implementation and throw only serious exceptions. Thrown exceptions will be handled in the framework by logging an error message with the cause.
|
||||
- The receive method should terminate quickly, since it blocks other event subscribers. Create a thread for long running operations.
|
||||
|
||||
|
||||
### Receive ItemStateEvents and ItemCommandEvents
|
||||
Due to the fact that receiving ItemStateEvents and ItemCommandEvents is a common use case, Eclipse SmartHome provides an abstract event subscriber implementation via the core bundle. The class `org.eclipse.smarthome.core.items.events.AbstractItemEventSubscriber` provides two methods `receiveUpdate(ItemStateEvent)` and `receiveCommand(ItemCommandEvent)` which can be implemented in order to receive and handle such events.
|
||||
Due to the fact that receiving ItemStateEvents and ItemCommandEvents is a common use case, Eclipse SmartHome provides an abstract event subscriber implementation via the core bundle. The class `org.eclipse.smarthome.core.items.events.AbstractItemEventSubscriber` provides two methods `receiveUpdate(ItemStateEvent)` and `receiveCommand(ItemCommandEvent)` which can be implemented in order to receive and handle such events.
|
||||
|
||||
```java
|
||||
```java
|
||||
public class SomeItemEventSubscriber extends AbstractItemEventSubscriber {
|
||||
private final EventFilter eventFiter = new TopicEventFilter("smarthome/items/ItemX/.*");
|
||||
|
||||
|
|
@ -149,7 +154,7 @@ public class SomeItemEventSubscriber extends AbstractItemEventSubscriber {
|
|||
public EventFilter getEventFilter() {
|
||||
return eventFilter;
|
||||
}
|
||||
|
||||
|
||||
@Override
|
||||
protected void receiveCommand(ItemCommandEvent commandEvent) {
|
||||
// do something
|
||||
|
|
@ -166,9 +171,9 @@ public class SomeItemEventSubscriber extends AbstractItemEventSubscriber {
|
|||
|
||||
Usually the core events are only sent by the Eclipse SmartHome framework. However, it is possible to sent events explicitly, e.g. ItemCommandEvents and ItemStateEvents. The Java snippet below illustrates how to send events via the EventPublisher. The Eclipse SmartHome core events can only be created via the corresponding event factory.
|
||||
|
||||
```java
|
||||
```java
|
||||
public class SomeComponentWantsToPost {
|
||||
private EventPublisher eventPublisher;
|
||||
private EventPublisher eventPublisher;
|
||||
|
||||
public void postSomething() {
|
||||
ItemCommandEvent itemCommandEvent = ItemEventFactory.createCommandEvent("ItemX", OnOffType.ON);
|
||||
|
|
@ -178,7 +183,7 @@ public class SomeComponentWantsToPost {
|
|||
protected void setEventPublisher(EventPublisher eventPublisher) {
|
||||
this.eventPublisher = eventPublisher;
|
||||
}
|
||||
|
||||
|
||||
protected void unsetEventPublisher(EventPublisher eventPublisher) {
|
||||
this.eventPublisher = null;
|
||||
}
|
||||
|
|
@ -190,7 +195,7 @@ The EventPublisher will be injected via OSGi Declarative Services.
|
|||
```xml
|
||||
<scr:component xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0" immediate="true" name="SomeComponentWantsToPost">
|
||||
<!-- ... -->
|
||||
<reference bind="setEventPublisher" cardinality="1..1" interface="org.eclipse.smarthome.core.events.EventPublisher"
|
||||
<reference bind="setEventPublisher" cardinality="1..1" interface="org.eclipse.smarthome.core.events.EventPublisher"
|
||||
name="EventPublisher" policy="static" unbind="unsetEventPublisher"/>
|
||||
</scr:component>
|
||||
```
|
||||
|
|
|
|||
3
pom.xml
3
pom.xml
|
|
@ -303,6 +303,9 @@
|
|||
if(readme.exists()) {
|
||||
println readme
|
||||
readme.renameTo(new File(simpleUiNameDir.path, 'readme.md'))
|
||||
if(!readme.text.startsWith('---')) {
|
||||
readme.write("---\nlayout: documentation\n---\n\n{% include base.html %}\n\n" + readme.text)
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
#!/bin/sh
|
||||
# This script can be used to update all submodules and re-generated the automatically constructed documentation pages
|
||||
|
||||
git pull
|
||||
|
||||
cd _repos/smarthome
|
||||
git checkout master
|
||||
git pull
|
||||
|
|
@ -13,5 +15,10 @@ cd ../openhab2-addons
|
|||
git checkout master
|
||||
git pull
|
||||
|
||||
cd ../openhab-bundles
|
||||
git checkout master
|
||||
git pull
|
||||
git submodule update --recursive --remote
|
||||
|
||||
cd ../..
|
||||
mvn clean package
|
||||
|
|
|
|||
Loading…
Reference in New Issue