Skip to content

3.4. KNX device

Jump to bottom
John edited this page Sep 24, 2022 · 1 revision

Introduction

ebusd supports acting as a KNX device by implementing necessary parts of KNXnet/IP multicast as well as alternatively using a TCP connection to knxd.

In order to use it, either a running knxd instance (see knxd) or any other KNXnet/IP routing compliant end point is necessary.

To enable KNX support, the KNX URL needs to be set (see --knxurl).

KNX group associations

The association of eBUS message values to KNX groups is done via the integration file /etc/ebusd/knx.cfg and/or additional properties set using --knxvar=.

For details on how group addresses are associated with eBUS messages, see the documentation in the integration file /etc/ebusd/knx.cfg that is used as default if not configured otherwise.

KNX data types

Currently only numeric KNX data types are supported (i.e. no strings, dates or times) and the mapping from ebusd data types to KNX is as follows:

  • BI0:1 - BI7:1, length 1: 1 bit, DPT 1
  • without divisor:
    • BI0 - BI6, length >1: 1 octet, unsigned, DPT 5.010
    • UCH: 1 octet, unsigned, DPT 5.010
    • SCH, D1B: 1 octet, signed, DPT 6.010
    • UIN, UIR, PIN: 2 octet, unsigned, DPT 7.001
    • SIN, SIR: 2 octet, signed, DPT 8.001
    • U3N, U3R, ULG, ULR: 4 octet, unsigned, DPT 12.001
    • U3N, U3R, SLG, SLR: 4 octet, signed, DPT 13.001
  • with divisor:
    • BI0 - BI6, length >1: 2 octet, signed float, DPT 9.*
    • UCH, SCH, D1B, UIN, UIR, SIN, SIR: 2 octet, signed float, DPT 9.*
    • U3N, U3R, ULG, ULR, SLG, SLR: 4 octet, signed float, DPT 14.*
  • with or without divisor:
    • D1C, D2B, D2C, FLT, FLR: 2 octet, signed float, DPT 9.*
    • EXP, EXR: 4 octet, signed float, DPT 14.*

Note: the float conversion from eBUS to KNX may lose precision due to the KNX DPT 9 not being able to carry more than two digits after the decimal point and having a mantissa of only 11 bits. Consequently, when writing a 2-octet float from KNX to ebusd, a consecutive read on the same group address is likely to reveal a different value if it was using more than two digits after the decimal point or exceeding the KNX float mantissa range, e.g.:

  • an eBUS D2B value of 10.004 will read as 10.00 2-octet float on KNX,
  • an eBUS UIN with divisor 100 (like heating curve) value of 655.34 will read as 655.04 2-octet float on KNX,
  • writing a KNX 2-octet float value of 12.34 to an eBUS UIN with divisor 10 will actually write 12.3 and read as 12.3.

Writing to eBUS from KNX

Writing a value to eBUS from KNX currently is only possible if the eBUS message contains a single field respectively at most one non-ignored field. This is due to otherwise the value to be set for the other fields would have to be determined first which is mostly not possible.

Group associations to write messages not fulfilling this requirement are silently ignored.

Message precedence

The mapping for reads/writes from KNX to eBUS is done as follows:

  • for KNX read, the precedence on picking the corresponding eBUS message is: active read, passive read+write.
  • for KNX write, the precedence on picking the corresponding eBUS message is: active write only.
Clone this wiki locally