Ich kommentiere das mil Inline:
Code: Alles auswählen
Bridge knx:ip:bridge [ // ein Label ist immer hilfreich, um Things zu identifizieren
ipAddress="192.168.100.250",
portNumber=3671, // default, muss nicht angegeben werden
localIp="192.168.100.145", // wird nur gebraucht, wenn ein Rechner mehrere IP-Adressen nutzt
type="TUNNEL",
readingPause=50, // default, siehe oben
responseTimeout=10, // default, siehe oben
readRetriesLimit=3, // default, siehe oben
autoReconnectPeriod=1, // in einer aktuellen Version ist das Minimum 30
localSourceAddr="1.1.15" ] // diese physikalische Adresse darf keinem Device zugeordnet sein!
{
Thing device generic [ // siehe oben
address="1.1.15", // generic Devices haben keine physikalische Adresse!
fetch=true, // generic Devices können nicht abgefragt werden!
pingInterval=300, // generic Devices können nicht gepingt werden!
readInterval=3600 // readInterval nur bei Bedarf setzen, sollte normalerweise immer 0 sein!
// hier fehlt ein ] {
Type switch : og_Buro "Licht" [ ga="2/6/0" ]
Type switch : og_Schlaf_Decke "Licht" [ ga="2/6/4" ]
// hier fehlen zwei }
Label sind immer eine gute Sache, sie werden sowohl in Paper UI als auch in VSCode angezeigt. Man kann auch die Location setzen, wenn man mal in Paper UI Control nachschauen will, ob ein Thing funktioniert, kann man sich damit etwas Übersicht verschaffen.
Die
autoReconnectPeriod sollte keinesfalls kleiner als 30 gesetzt werden, je größer die knx Installation, desto größer auch die
autoReconnectPeriod! In der aktuellen Milestone ist der Mindestwert im Addon definiert.
localSourceAddr darf von keinem anderen Device verwendet werden, auch nicht als weitere Adresse (wenn man z.B. ein knx/IP-Gateway mit mehreren Tunneln besitzt, darf keine der Adressen verwendet werden).
Man kann echte knx Devices als einzelne Things anlegen, das hat den Vorteil, dass man sehen kann, ob ein Device ausgefallen ist. Allerdings ist der Mechanismus nicht zuverlässig. Wenn man eine korrekte
address gesetzt hat, kann man bei bestimmten Devices mit
fetch=true zusätzliche Informationen über das Device erlangen. Nice to have, aber unwichtig.
readInterval ist nur dann sinnvoll, wenn auch lesbare GruppenAdressen hinterlegt sind, aber selbst dann ist dies nur sinnvoll, wenn das zugehörige Device nicht in der Lage ist, selbsttätig zu senden, sondern nur auf Leseanforderung antwortet.
Besser wäre folgende Konfiguration:
Code: Alles auswählen
Bridge knx:ip:bridge "KNX Bridge" [
ipAddress="192.168.100.250",
type="TUNNEL"
] {
Thing device generic "generisches Device" @ "KNX" [
] {
Type switch : og_Buro "Licht" [ ga="2/6/0" ]
Type switch : og_Schlaf_Decke "Licht" [ ga="2/6/4" ]
}
}
Rückmelde-GA sind eigentlich immer sinnvoll, sie werden zusätzlich zur Kommando-GA eingetragen, z.B.
In diesem Fall wäre 2/6/1 der Status des Kanals, der mit 2/6/0 geschaltet wird. das < sorgt dann dafür, dass openHAB beim Start den Status des Kanals über die GA 2/6/1 erfragt.
openHAB4.3.3 stable in einem Debian-Container (bookworm) (Proxmox 8.3.5, LXC), mit openHABian eingerichtet
