diff --git a/bundles/org.openhab.binding.knx/README.md b/bundles/org.openhab.binding.knx/README.md index 5339c2862..87c5b38e5 100644 --- a/bundles/org.openhab.binding.knx/README.md +++ b/bundles/org.openhab.binding.knx/README.md @@ -2,12 +2,12 @@ # 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 @@ -33,7 +33,7 @@ The IP Gateway is the most commonly used way to connect to the KNX bus. At its b | ipAddress | for `TUNNEL` | Network address of the KNX/IP gateway. If type `ROUTER` is set, the IPv4 Multicast Address can be set. | for `TUNNEL`: \, 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

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

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 | @@ -57,11 +57,11 @@ The *serial* bridge accepts the following configuration parameters: ### *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 | |--------------|----------|--------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------| @@ -77,7 +77,7 @@ When defined and set to 0, the interval is ignored (default: 0) #### 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. @@ -132,7 +132,7 @@ Note: After changing the DPT of already existing Channels, openHAB needs to be r #### 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" @@ -196,7 +196,7 @@ With `*-control` channels, the state is not owned by any device on the KNX bus, 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