public/openhab-addons
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

[knx] Minor wording changes to documentation (#12589)

Browse Source 
Signed-off-by: Holger Friedrich <mail@holger-friedrich.de>
This commit is contained in:
Holger Friedrich 2022-04-09 09:18:10 +02:00 committed by GitHub
parent 7e35341f23
commit 08d03d9ddf
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 11 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
bundles/org.openhab.binding.knx/README.md
View File

@ -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`: \<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 |
@ -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