KNX Binding 2.0 installieren und umstellen von 1.11

[udo1toni]

Items sind Items. da hat sich (bis auf ganz viele zusätzliche Funktionen) nichts geändert.

Things repräsentieren hingegen die Hardware. In OH1 koppelst Du kleine Schnipsel der Hardware an einzelne Items, je nach Binding auf komplett unterschiedliche Weise.
Unter OH2 ist die Konfiguration wesentlich geordneter.

Wenn Du VSCode zur Konfiguration nutzt, lassen sich Items automatisch aus den Things erstellen, Du kannst also durchaus direkt profitieren. Ich habe konsequent alles über Dateien angelegt und das funktioniert eigentlich sehr gut. Man sollte im Hinterkopf haben, dass es manchmal Probleme mit der Erkennung von Änderungen gibt, was dann dazu führt, dass Änderungen in der Datei keine Auswirkungen haben (bis man openHAB bzw. das fragliche Addon neu startet).

Es gibt etliche Bindings, die nur unter OH2 zur Verfügung stehen. Es gibt ein paar OH1 Bindings, die unter OH2 nicht funktionieren. Leider wird das Compatibility Layer vermutlich nicht für OH3 weiter verwendet, womit dann alle OH1 Bindings aus OH3 raus fallen. Es werden aber immer mal wieder einzelne Bindings für OH2 neu entwickelt, das ist also vielleicht nur ein vorübergehendes Problem (und knx steht ja schon als 2er Version zur Verfügung).

Was den Einwand mit dem stark geänderten Verhalten, received command betreffend angeht, so ist das neue Verhalten eigentlich das korrekte. Man benötigt nicht zwingend received command, um Rules zu triggern. Sofern Geräte innerhalb des knx Busses geschaltet werden, ist es eher der Status, auf den man reagieren sollte (mit changed oder received update statt received command...)

Ich habe nur die Channel als *-control Channel angelegt, bei denen sich die gesteuerten Geräte nicht auf dem knx Bus befinden, also z.B. der Media Player, der über den Wandtaster gesteuert wird, das funktioniert eigentlich sehr gut.

[Jockel]

Hmmm, klingt nach einem prädestinierten Herbstprojekt

Ja, das kommt wohl hin, habe mich damit auch einen nennenswerten teil des letzten Winters beschäftigt. Wobei Du mal schauen solltest, im Forum unter openhab.org gibt es ein paar Skripte, die vielleicht Tipparbeit abnehmen können. Vollautomatisch wird es aber nicht gehen.

wie werden denn dummy Objekte angelegt, also was nur in OH genutzt wird?

Ich habe dazu ein generisches Thing angelegt. Dabei solltest Du dann auch auf die Unterschiede zwischen den "normalen" und den "control" Kanälen achten.

ist das “Light” in einem direkten Zusammenhang mit einem Eintrag in der items, oder ist “wahlfrei”?

Das ist nur ein frei wählbarer Bezeichner, z.B. zur Identifikation im Paper UI, identifiziert wird der Kanal über den "demoSwitch", z.B.: "knx:device:bridge:generic:demoSwitch"

[JoergA]

OK,

nun habe ich in den letzten beiden Tagen gelesen und gelesen, überlegt und geschrieben und wieder gelesen und konnte für mich noch nicht final entscheiden, bzw. verstehen wie ich die Umstellung angehe

• Aufteilung der Things pro Aktor? Oder pro Schaltschrank? Bei mir sind die Aktoren in 2 Schränken Oder pro Raum => Alle Aktoren in ein Thing
• Aufteilung der Sensoren pro Raum, oder Sensor (was dann deutlich mehr Things wären) oder alle in ein Thing
• Werden Status und Rückmeldung als Control-Thing angelegt? <= Den Sinn der control-things habe ich noch nicht ganz durchdrungen

Freue mich auch Euren Rat und Empfehlung

[Jockel]

Ich habe ein Thing pro KNX Gerät angelegt, vielleicht hat das später, bei erweiterter Funktionalität des Bindings mal Vorteile. Außerdem erscheint es mir übersichtlicher. Funktional ist es aktuell ist es vollkommen egal.

Die Idee mit den control things finde ich auch sehr merkwürdig, das scheint mir eher eine Sackgasse zu sein, passt auch vom zugrundeliegenden Konzept eher nicht zu KNX, ist aber für manche Funktionalität notwendig. Führt aber dazu, dass ich manche GAs jetzt doppelt in openHAB habe. Da hilft wohl nur wundern und akzeptieren...

[JoergA]

So, der Herbst kann kommen, die Vorbereitungen für den Umstieg sind angelaufen

Der Plan ist alle Things strickt nach Aktor/Sensor getrennt anzulegen.
Hierzu habe ich eine *.things angelegt, den Zugang konfiguriert und gemäß Stückliste der ETS die Things vorbereitet.
Bei den Rollladen und Switches, nebst Dimmer sind mir bereits einige fehlende Status Objekte aufgefallen, was ich direkt mit bereinigen werde.
Jedoch bin ich beim weiteren anlegen der Things bereits an die erste Fragestellung gestoßen, bei der ich derzeit keine Lösung sehe.

Ich habe je 1x Luna 131 S (Kombisensor für Lux und °C) sowie Gira Tastsensor 2plus 3fach Fläche

Derzeit habe ich folgende Item konfiguriert

Number Weather_Temperature        "Temperatur Sensor Garage [%.1f °C]"        (Weather, Weather_Chart) { knx="0/4/121" }
Number Helligkeit_Norden        "Helligkeit Norden [%.1f Lx]"        <sun>        (Lux_Chart)    { knx="0/4/120"}
Switch Night                    { knx="0/4/29" }

Number Temperature_Living        "Wohnzimmertemperatur [%.1f °C]"    (gEG)    { knx="0/4/123" }
DateTime        Time    "[%1$tA, %1$td.%1$tm.%1$tY %1$tT]"  { channel="ntp:ntp:local:dateTime", knx="11.001:0/6/7, 10.001:0/6/6" }

Die Geräte habe die Adressen
0.0.100 Theben AG 1319201 Luna 131 S (Kombisensor für Lux und °C)
0.0.36 GIRA Giersiepen 2053 xxx Tastsensor 2plus 3fach Fläche

Fragen:
- Wie konfiguriere ich die Things dafür
- Wie übergebe ich die Temperatur des Sensors and den Tastsensor zur Anzeige im Display
- Wie bekomme ich die Uhrzeit an den Tastsensor übergeben

Da ich das knx 2.0 Binding ja noch nicht installiert habe, kann ich erst mal nur Trockenübungen machen

Viele Grüße,

Jörg

[udo1toni]

Das läuft genauso, wie mit dem knx1 Binding.
Was die Temperatur Anzeige betrifft, so sollte die direkt in knx erfolgen (ich gehe mal davon aus, dass das ohnehin der Fall istz)

Die Uhrzeit sieht mit knx2 so aus:
Thing:

... // Thing gehört zur knx Bridge
    Thing device Virtuell "virtuelle" @ "KNX" [
     ] {
        Type datetime-control       : wochenzeit "Zeit und Tag" [ ga="10.001:0/6/6" ]
        Type datetime-control       : datum "Datum"             [ ga="11.001:0/6/7" ]
    }
} // Ende der knx Bridge
  [COLOR=#6a9955]/[/COLOR]/ Time and Date
  Thing ntp:ntp:home "Lokale Zeit" [hostname="fqdn zum bevorzugten NTP Server",refresh=120, refreshNtp=30, locale="de_DE", timeZone="Europe/Berlin"]

Ich habe alle Channel, deren Ursprung in openHAB liegt, unter diesem Thing gesammelt, denn es gibt in diesem Fall ja kein Device, dem die GA "gehören", nur solche, die die GA belauschen.
Items:

 DateTime Buszeit "Zeit und Tag" {channel="knx:device:bridge:Virtuell:datum", channel="knx:device:bridge:Virtuell:wochenzeit",channel="ntp:ntp:home:dateTime"}

[JoergA]

Items:

 DateTime Buszeit "Zeit und Tag" {channel="knx:device:bridge:Virtuell:datum", channel="knx:device:bridge:Virtuell:wochenzeit",channel="ntp:ntp:home:dateTime"}

OK, dies wäre dann mit dem NTP Binding, als letzte Zeile in

... // Thing gehört zur knx Bridge
Thing device Virtuell "virtuelle" @ "KNX" [
] {
Type datetime-control : wochenzeit "Zeit und Tag" [ ga="10.001:0/6/6" ]
Type datetime-control : datum "Datum" [ ga="11.001:0/6/7" ]
}
} // Ende der knx Bridge
[COLOR=#6a9955]/[/COLOR]/ Time and Date
Thing ntp:ntp:home "Lokale Zeit" [hostname="fqdn zum bevorzugten NTP Server",refresh=120, refreshNtp=30, locale="de_DE", timeZone="Europe/Berlin"]

angelegt ist?

Solange ich noch lokal die Zeit abgreife wäre dies dann

DateTime Buszeit "Zeit und Tag" {channel="knx:device:bridge:Virtuell:datum", channel="knx:device:bridge:Virtuell:wochenzeit",channel="ntp:ntp:local:dateTime"}

Oder habe ich da einen Denkfehler?

VG
Jörg

[udo1toni]

Das ist so oder so das ntp Addon, wie man das Thing nennt (home oder local) ist Jacke wie Hose. Der einzige Unterschied wäre, dass local automatisch von openHAB in die Inbox packt.

[JoergA]

Also, der Herbst ist ja da und ich habe an den letzten Abenden meine Items in Things transformiert, OH runtergefahren, gesichert, und KNX1 Binding de- und KNX 2 Binding installiert. .Items upgedated, .things kopiert und los ging es. Nachdem 2-3 Fehler ausgemerzt wurden, lief die Konfig hoch und ich konnte sogar die Items schalten, Dimmer betätigen etc.

Aber: Es gibt noch Fehler, bei denen ich keine Lösung finde

Datum Uhrzeit ist zwar auf dem Bus, denoch sind Fehler im Log

2019-11-09 19:52:47.509 [WARN ] [ore.common.registry.AbstractRegistry] - Cannot add "Metadata" with key "channel:Time". It exists already from provider "GenericMetadataProvider"! Failed to add a second with the same UID from provider "GenericMetadataProvider"!

Thing

/* NTP Binding */
Thing ntp:ntp:home "Lokale Zeit" [
    hostname="0.de.pool.ntp.org",
    refresh=120,
    refreshNtp=30,
    locale="de_DE",
    timeZone="Europe/Berlin"
]

Item

DateTime Time        "[%1$tA, %1$td.%1$tm.%1$tY %1$tT]"    {channel="knx:device:bridge:Vopenhab:wochenzeit",channel="ntp:ntp:home:dateTime"}

Desweiteren werden die Kontakte des Binär-Eingangs nicht gelesen und es hagelt Fehler a la => Giving up reading datapoint 0/4/51, the number of maximum retries (3) is reached.

Thing

    //    ABB    2CDG 110 056 R0011; BE/S8.20.1 Binäreingang,8fach,Abfrage (---)
    Thing device ABB_0_0_8 [
        address="0.0.8",
        fetch=false,
        pingInterval=600,
        readInterval=0
    ] {
        Type contact : ch1        "Feueralarm"                    [ ga="1.019:<0/5/0" ]
        Type contact : ch2        "Terrasse links"                [ ga="1.019:<0/5/1" ]
        Type contact : ch3        "Terrasse rechts"                [ ga="1.019:<0/5/2" ]
        //Type contact : ch4        "Reserve"                        [ ga="1.019:<" ]
        Type contact : ch5        "Dunstabzugshaube"                [ ga="1.019:<1/1/18" ]
        //Type contact : ch6        "Reserve"                        [ ga="1.019:<" ]
        //Type contact : ch7        "Reserve"                        [ ga="1.019:<" ]
        Type contact : ch8        "alle Fenster Erdgeschoss"        [ ga="1.019:<0/5/49" ]
    }

Die Items dazu

    /* Windows */
Contact Fenster_EG_Terasse_l     "Terrasse links [MAP(de.map):%s]"    (Fenster)    {channel="knx:device:bridge:ABB_0_0_8:ch2"}        //Eingang B von BE/20-8
Contact Fenster_EG_Terasse_r     "Terrasse rechts [MAP(de.map):%s]"    (Fenster)    {channel="knx:device:bridge:ABB_0_0_8:ch3"}        //Eingang C von BE/20-8

Das größte Problem zum Schluss Nach einigen Minuten kommen die folgenden Fehler pro angelegtem knx Thing

response timeout waiting for confirmation
tuwien.auto.calimero.KNXTimeoutException: no confirmation reply received for 0.0.0->0.0.32 L_Data.req, system priority hop count 6 repeat, tpdu 81

Und dann werden die Thing herunter gefahren und sind inaktiv

Also: Nach gutem Start ein Chaos auf dem Bus

Somit baue ich wieder auf Eure Hilfe zum anschubsen

[udo1toni]

Wie hast Du die Bridge definiert? Lass erst mal address und pingInterval weg (also jegliche Thing-spezifische Parameter auskommentieren)
Welche Version von openHAB nutzt Du?

[JoergA]

Wie hast Du die Bridge definiert?

//TUNNEL
Bridge knx:ip:bridge [  
    type="TUNNEL",
    ipAddress="192.168.1.235",
    autoReconnectPeriod=60
] {

Gemäß der Empfehlung weniger ist mehr, somit sind die anderen alle auf den default Werten.

Lass erst mal address und pingInterval weg (also jegliche Thing-spezifische Parameter auskommentieren)

OK, habe ich gemacht. Und wer mal parallel neu starten

Welche Version von openHAB nutzt Du?

2.4.0 stable

[JoergA]

Update:

Ohne

address und pingInterval

läuft es zumindest nun durch, Fehler sehe ich im Log nicht mehr (ausser Warns vom Gardena Binding, aber dies ist schon länger und nicht durch die Umstellung, dazu gibt es auch einen anderen Threat)

Seltsam ist: Den Fehler, dass die Kontakte nicht gelesen werden konnten, war immer noch da und endete für ALLE Kontakte, nachdem nur 1 Kontakt einmal den Status geändert hatte, als ich ein Fenster geööfnet und geschlossen hatte, was auch korrekt erkannt und in der Visu dargestellt wurde. <== weird

Die Thing Parameter haben aber doch sicher einen Sinn und ich hatte dies so aus der Doku und diversen Beispielen entnommen

[JoergA]

Neues Update: Nun, nach ca. 1 Std Lauf, fangen die Probleme auf dem Bus wieder an

22:31:22.252 [WARN ] [NXnet/IP Tunneling 192.168.1.235:3671] - tunneling request with invalid rcv-seq 98, expected 237
22:31:23.252 [WARN ] [NXnet/IP Tunneling 192.168.1.235:3671] - tunneling request with invalid rcv-seq 98, expected 237
22:31:30.000 [WARN ] [NXnet/IP Tunneling 192.168.1.235:3671] - tunneling request with invalid rcv-seq 99, expected 237
22:31:31.000 [WARN ] [NXnet/IP Tunneling 192.168.1.235:3671] - tunneling request with invalid rcv-seq 99, expected 237
22:31:32.000 [WARN ] [NXnet/IP Tunneling 192.168.1.235:3671] - tunneling request with invalid rcv-seq 100, expected 237
22:31:33.031 [WARN ] [NXnet/IP Tunneling 192.168.1.235:3671] - tunneling request with invalid rcv-seq 100, expected 237
22:31:35.000 [WARN ] [NXnet/IP Tunneling 192.168.1.235:3671] - tunneling request with invalid rcv-seq 101, expected 237
22:31:36.000 [WARN ] [NXnet/IP Tunneling 192.168.1.235:3671] - tunneling request with invalid rcv-seq 101, expected 237
22:31:40.719 [WARN ] [NXnet/IP Tunneling 192.168.1.235:3671] - tunneling request with invalid rcv-seq 102, expected 237
22:31:41.719 [WARN ] [NXnet/IP Tunneling 192.168.1.235:3671] - tunneling request with invalid rcv-seq 102, expected 237
22:31:46.467 [WARN ] [NXnet/IP Tunneling 192.168.1.235:3671] - tunneling request with invalid rcv-seq 103, expected 237

Schalten ist noch möglich, jedoch stark verzögert

[JoergA]

Und noch ein Update: Der zuvor genannte Fehler läuft dann hoch bis 236 und dann surprise surprise => Fehler erst mal weg

[udo1toni]

Die 2.4 ist ja nun uralt... die Milestone Version OH2.5M4 ist soweit ausgereift, und auch in Bezug auf knx sind da noch Fixes eingeflossen.