# KNX Binding
The openHAB KNX binding allows to connect to [KNX Home Automation](https://www.knx.org/) installations.
-Switching lights on and off, activating your roller shutters or changing room temperatures are only some examples.
+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 a gateway device which is connected to the KNX bus and allows computers to access the bus communication.
+To access your KNX bus, you either need a gateway device which is connected to the KNX bus and allows computers to access the bus communication.
This can be either an Ethernet (as a Router or a Tunnel type) or a serial gateway.
The KNX binding then can communicate directly with this gateway.
-Alternatively a PC running [KNXD](https://github.com/knxd/knxd) (free open source component sofware) can be put in between which then acts as a broker allowing multiple client to connect to the same gateway.
+Alternatively, a PC running [KNXD](https://github.com/knxd/knxd) (free open source component software) can be put in between which then acts as a broker allowing multiple client to connect to the same gateway.
Since the protocol is identical, the KNX binding can also communicate with it transparently.
## Supported Things
| ipAddress | for `TUNNEL` | Network address of the KNX/IP gateway. If type `ROUTER` is set, the IPv4 Multicast Address can be set. | for `TUNNEL`: \<nothing\>, for `ROUTER`: 224.0.23.12 |
| portNumber | for `TUNNEL` | Port number of the KNX/IP gateway | 3671 |
| localIp | No | Network address of the local host to be used to set up the connection to the KNX/IP gateway | the system-wide configured primary interface address |
-| localSourceAddr | No | The (virtual) individual address for identification of this KNX/IP gateway within the KNX bus <br/><br/>Note: Use a free adress, not the one of the interface. Or leave it at `0.0.0` and let openHAB decide which address to use. | 0.0.0 |
+| localSourceAddr | No | The (virtual) individual address for identification of this KNX/IP gateway within the KNX bus <br/><br/>Note: Use a free address, not the one of the interface. Or leave it at `0.0.0` and let openHAB decide which address to use. | 0.0.0 |
| useNAT | No | Whether there is network address translation between the server and the gateway | false |
| readingPause | No | Time in milliseconds of how long should be paused between two read requests to the bus during initialization | 50 |
| responseTimeout | No | Timeout in seconds to wait for a response from the KNX bus | 10 |
### *device* Things
-*basic* Things are wrappers around an arbitrary group addresses on the KNX bus.
-They have no specific function in the KNX binding, except that if the *address* is defined the binding will actively poll the Individual Address on the KNX bus to detect that the KNX actuator is reachable.
-Under normal real world circumstances, either all devices on a bus are reachable, or the entire bus is down.
+*basic* Things are wrappers around arbitrary group addresses on the KNX bus.
+They have no specific function in the KNX binding, except that if the *address* is defined, the binding will actively poll the Individual Address on the KNX bus to detect that the KNX actuator is reachable.
+Under normal real-world circumstances, either all devices on a bus are reachable, or the entire bus is down.
When *fetch* is set to true, the binding will read-out the memory of the KNX actuator in order to detect configuration data and so forth.
-This is however an experimental feature very prone to the actual on the KNX bus.
+This is however an experimental feature, very prone to the actual on the KNX bus.
| Name | Required | Description | Default value |
|--------------|----------|--------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------|
#### Standard Channel Types
Standard channels are used most of the time.
-They are used in the common case where the physical state is owned by a decive within the KNX bus, e.g. by a switch actuator who "knows" whether the light is turned on or of or by a temperature sensor which reports the room temperature regularly.
+They are used in the common case where the physical state is owned by a device within the KNX bus, e.g. by a switch actuator who "knows" whether the light is turned on or off, or by a temperature sensor which reports the room temperature regularly.
Note: After changing the DPT of already existing Channels, openHAB needs to be restarted for the changes to become effective.
#### Control Channel Types
In contrast to the standard channels above, the control channel types are used for cases where the KNX bus does not own the physical state of a device.
-This could be the case if e.g. a lamp from another binding should be controlled by a KNX wall switch.
+This could for example be the case if a lamp from another binding should be controlled by a KNX wall switch.
If from the KNX bus a `GroupValueRead` telegram is sent to a *-control Channel, the bridge responds with a `GroupValueResponse` telegram to the KNX bus.
##### Channel Type "switch-control"
Each configuration parameter has a `mainGA` where commands are written to and optionally several `listeningGA`s.
-The `dpt` element is optional. If ommitted, the corresponding default value will be used (see the channel descriptions above).
+The `dpt` element is optional. If omitted, the corresponding default value will be used (see the channel descriptions above).
## Examples
projects / openhab-addons.git / commitdiff