-
Notifications
You must be signed in to change notification settings - Fork 4
KNX Binding
Documentation of the KNX Binding Bundle
The openHAB KNX binding allows to connect to KNX Home Automation installations. Switching lights on and off, activating your roller shutters or changing room temperatures are only some examples.
To access your KNX bus you either need an KNX IP gateway (like e.g. the Gira KNX IP Router) or a PC running EIBD (free open source component that enables communication with the KNX bus).
For installation of the binding, please see Wiki page Bindings.
You can find the configuration section for the KNX binding in file configurations/openhab.cfg, section "KNX Binding".
For your convenience you can see the relevant section as follows:
# KNX gateway IP address
# (optional, if serialPort or connection type 'ROUTER' is specified)
knx:ip=
# KNX IP connection type. Could be either TUNNEL or ROUTER (optional, defaults to TUNNEL)
# Note: If you cannot get the ROUTER mode working (even if it claims it is connected),
# use TUNNEL mode instead with setting both the ip of the KNX gateway and the localIp.
knx:type=
# KNX gateway port (optional, defaults to 3671)
knx:port=
# Local endpoint to specify the multicast interface, no port is used (optional)
knx:localIp=
# Serial port of FT1.2 KNX interface (ignored, if ip is specified)
# Valid values are e.g. COM1 for Windows and /dev/ttyS0 or /dev/ttyUSB0 for Linux
knx:serialPort=
# Pause in milliseconds between two read requests on the KNX bus during
# initialization (optional, defaults to 50)
knx:pause=
# Timeout in milliseconds to wait for a response from the KNX bus (optional,
# defaults to 10000)
knx:timeout=
# Number of read retries while initialization items from the KNX bus (optional,
# defaults to 3)
knx:readRetries=
# Seconds between connect retries when KNX link has been lost
# 0 means never retry, it will only reconnect on next write or read request
# Note: without periodic retries all events will be lost up to the next read/write request
# (optional, default is 0)
knx:autoReconnectPeriod=
A sample configuration could look like:
knx:ip=192.168.1.10
knx:type=ROUTER
In order to bind an item to a KNX device you need to provide configuration settings. The easiest way to do so is to add binding information in your 'item file' (in the folder configurations/items`). The syntax for the KNX binding configuration string is explained here:
knx="[<][<dptId>:]<mainGA>[[+[<]<listeningGA>]+[<]<listeningGA>..], [<][<dptId>:]<mainGA>[[+[<]<listeningGA>]+[<]<listeningGA>..]"
where parts in brackets []
signify an optional information.
Each comma-separated section corresponds to a KNX datapoint. There is usually one datapoint defined per accepted command type of an openHAB item. If no datapoint type id is defined for the datapoint, this is automatically derived from the list of accepted command types of the item - i.e. the second datapoint definition is mapped to the second accepted command type of the item.
The optional '<' sign tells whether the group address of the datapoint accepts read requests on the KNX bus (it does, if the sign is there).
Each itemtype (see page Items) accepts different command types. When binding an item to KNX you can provide one KNX group address ("mainGA") and several listening group addresses ("listeningGA") to each commandtype.
mainGAs are used for updating the status of an openHAB items via KNX. There can only be one mainGA for an openHAB item (Highlander principle :-) listeningGAs are used for obtaining status changes from KNX. There can be multiple listeningGAs for one item.
Given we want to bind a Dimmer Item to KNX, we have first to check which commands an openHAB dimmer item does accept:
On page Items we that an openHAB Dimmer Item accepts three types of commands:
Itemname | Description | Command Types |
---|---|---|
Dimmer | Item carrying a percentage value for dimmers | OnOff, IncreaseDecrease, Percent |
Also in the sources, we can find this information:
acceptedCommandTypes.add(OnOffType.class);
acceptedCommandTypes.add(IncreaseDecreaseType.class);
acceptedCommandTypes.add(PercentType.class);
So, we first have to bind the OnOff command to the respective KNX group addresses, then the IncreaseDecrease command and finally the Percentage command. Please note that the sequence of these commands is relevant.
In our example we assign the following KNX group addresses to the different commands:
Command Type | Main Group Address | Listening Address(es) | Comment |
---|---|---|---|
OnOff command | 1/3/20 | 0/3/20 | - |
IncreaseDecreaseCommand | 1/3/21 | - | no listening GAs here as INCREASE and DECREASE are only commands but not valid states |
PercentCommand | 1/3/22 | 0/3/22 and 0/8/15 |
The respective line in the items definition file would therefore look like this:
Dimmer TestDimmer (Lights) { knx="1/3/20+0/3/20, 1/3/21, 1/3/22+0/3/22+0/8/15" }
If you have a dimmer that does not support INCREASE/DECREASE commands and you thus do not have a GA to provide in the middle, you can also directly define the datapoint types (DPTs) in the configuration. The above example would then look like this (without INCREASE/DECREASE support):
Dimmer TestDimmer (Lights) { knx="1.001:1/3/20+0/3/20, 5.004:1/3/22+0/3/22+0/8/15" }
For identifying the different command types for items, please either have a look into the openHAB source code or see Wiki page Items.
Here are some further examples for valid binding configuration strings:
For a SwitchItem:
knx="1/1/10"
knx="1.001:1/1/10"
knx="<1/1/10"
knx="<1/1/10+0/1/13+0/1/14+0/1/15"
knx="1/1/10+<0/1/13+0/1/14+0/1/15"
For a RollershutterItem:
knx="4/2/10"
knx="4/2/10, 4/2/11"
knx="4/2/10, 4/2/11, 4/2/12"
knx="1.008:4/2/10, 5.006:4/2/11"
knx="<4/2/10+0/2/10, 5.006:4/2/11+0/2/11"
As a result, your lines in the items file might look like the following:
/* Lights */
Switch Light_GF_Living_Table "Table" (GF_Living, Lights) { knx="1/1/10+0/1/5" }
/* Rollershutters Up/Down, Stop/Move */
Rollershutter Shutter_GF_Living "Shutter" (GF_Living, Shutters) { knx="4/2/10, 4/2/11" }
/* Rollershutters Up/Down, Stop/Move, Position */
Rollershutter Shutter_GF_Living "Shutter" (GF_Living, Shutters) { knx="4/2/10, 4/2/11, 4/2/12" }
/* Indoor Temperatures */
Number Temperature_GF_Living "Temperature [%.1f °C]" <temperature> (GF_Living) { knx="<5/2/12" }
Further KNX binding examples can be found in our openhab-samples WIKI: KNX Binding Examples
The KNX binding supports a limited set of Datapoint types (DPTs). If your item configuration contains a DPT that is not supported by the KNX binding, openHAB 1.4.0 and later will throw an exception during startup ("DPT n.nnn is not supported by the KNX binding").
To get an overview of the supported DPTs, it's best to look into the source code of the KNX binding and the library it depends on. The DPTs for the binding are defined in KNXCoreTypeMapper. The constants (and their mapping to DPTs) are defined in the library calimero.
Installation
Community
- Support
- News Archive
- Presentations
- How to Contribute
- IDE Setup
- How to Implement a Binding
- How to Implement an Action
- Projects using openHAB
- User Interfaces
- Classic UI
- iOS Client
- Android Client
- GreenT UI
- CometVisu
- Bindings
- Asterisk Binding
- Astro Binding
- Bluetooth Binding
- Comfo Air Binding
- CUL Binding
- CUPS Binding
- digitalSTROM Binding
- DMX512 Binding
- EnOcean Binding
- Epson Projector Binding
- Exec Binding
- Fritz!Box Binding
- Fritz AHA Binding
- GPIO Binding
- HDAnywhere binding
- Heatmiser Binding
- Homematic Binding
- HTTP Binding
- IHC / ELKO Binding
- Insteon Hub Binding
- Insteon PLM Binding
- Ir-Trans Binding
- KNX Binding
- Koubachi Binding
- MAX!Cube-Binding
- MiLight Binding
- Modbus TCP Binding
- MPD Binding
- MQTT Binding
- MQTTitude binding
- Neohub Binding (Preview)
- Netatmo Binding
- Network Health Binding
- Nibe Heatpump Binding
- Nikobus Binding
- Novelan/Luxtronic Heatpump Binding
- NTP Binding
- One-Wire Binding
- Onkyo AV Receiver Binding
- Open Energy Monitor Binding
- OpenPaths presence detection binding
- OpenSprinkler Binding
- OSGi Configuration Admin Binding
- Philips Hue Binding
- Piface Binding
- Pioneer-AVR-Binding
- Plugwise Binding
- PLCBus Binding
- Pulseaudio Binding
- RFXCOM Binding
- Samsung TV Binding
- Serial Binding
- Snmp Binding
- Squeezebox Binding
- System Info Binding
- Somfy URTSI II Binding
- Sonos Binding
- Swegon ventilation Binding
- TCP/UDP Binding
- Tellstick Binding
- TinkerForge Binding
- VDR Binding
- Velleman-K8055-Binding
- Wake-on-LAN Binding
- Withings Binding
- XBMC Binding
- xPL Binding
- Z-Wave Binding
- Persistence
- db4o Persistence
- rrd4j Persistence
- MySQL Persistence
- MongoDB Persistence
- Sen.Se Persistence
- Cosm Persistence
- Logging Persistence
- Exec Persistence
- MQTT Persistence
- Automation
- Scripts
- Rules
- Actions
- Misc
- REST-API
- Security
- Google Calendar Support
- Twitter Action
- Service Discovery
- Dropbox Bundle
Samples
- Item definitions
- Sitemap definitions
- Binding configurations
- Rules
- REST Examples
- Tips & Tricks
- FAQ
- XSLT Transforms
- Scripts
- Integration with other applications
- Syntax highlighting for external editors
- Update-Scripts
- Samples-Comfo-Air-Binding
- Samples WAC Binding
Release Notes