KNX 2.x Binding verfügbar!

[udo1toni]

Ich würde mal zusammenfassend vermuten, dass die items das Verhalten von Aktoren, die control-items dagegen das von Sensoren im KNX-Sinne abbildet.

Nö.
Naja, Ja und Nein. Temperaturen werden z.B. durchaus in openHAB ankommen, obwohl sie nicht als number-control, sondern als number definiert sind.

Wenn OH komplett stateless ist, kann es im KNX Sinne auch nur einen Sensor darstellen, aber keinen Aktor (der kennt ja einen Status)

Nochmal Nö. openHAB selbst ist stateless, hat aber sehr wohl einen Speicher, um die Status zu halten (nämlich den openHAB Bus, welcher durch die Items definiert ist) Aber im eigentlichen Sinne wird openHAB selbst kein Aktor sein, sondern die Aufgabe (Schalten und behalten) an ein Binding übergeben, welches sich dann darum kümmert. Dass openHAB sich dennoch intern die Status merk, ist einfach ein Zugeständnis an Zuverlässigkeit und Geschwindigkeit - wäre ja doof, wenn jedesmal, wenn ein Status benötigt wird, openHAB extern nachfragen müsste. Stattdessen verfolgt es sämtliche Änderungen.

Bleibt die Frage, warum man in der OH2 Visu ein Switch-Item schalten kann, das nur als item angelegt, wurde. Wie schon in meinen vorherigen Post geschrieben, dürfte das doch nur gehen, wenn ich das als control-item anlege.

Hab ich eigentlich geschrieben: control nimmt keine Befehle von openHAB entgegen, sendet sie aber. Nicht-control sendet keine Befehle an openHAB, nimmt sie aber entgegen. Ein Channel der Form

Type switch : ch1 "Name" [ga="1/1/1 + <1/1/2"]

steht für einen Aktor, der seine Befehle über GA 1/1/1 entgegen nimmt und seinen Status über GA 1/1/2 mitteilt.

[typoon007]

Hallo,

ich bin neu hier,

kann mir jemand die Syntax erklären wie man mehr wie einen KNX Baustein in die knx.things einträgt?

so wie nachfolgend geht es bei mir nicht

Danke



Bridge knx:ip:bridge "KNX IP Tunnel" [

ipAddress="192.168.3.15",

portNumber=3671,

localIp="192.168.3.202",

type="TUNNEL",

readingPause=50,

responseTimeout=10,

readRetriesLimit=3,

autoReconnectPeriod=1,

localSourceAddr="0.0.0"




]

{

{ Thing device Temp "KNX Tempregler" [ address="1.1.11",fetch=true,pingInterval=300,readI nterval=3600 ]




{

Type number : Temperature "Temperature" [ ga="9.001:<1/7/0" ]

}

}

{ Thing device Temp "KNX Tempregler" [ address="1.1.12",fetch=true,pingInterval=300,readI nterval=3600 ]




{

Type number : Temperature1 "Temperature1" [ ga="9.001:<1/7/1" ]

}

}

}

[udo1toni]

Wenn Du mehrere Things verwenden willst, musst Du schon jedem Device einen anderen Namen geben!
Strukturiert sähe das so aus:

Bridge knx:ip:bridge "KNX IP Tunnel" [
    ipAddress="192.168.3.15",
    portNumber=3671,
    localIp="192.168.3.202",
    type="TUNNEL",
    readingPause=50,
    responseTimeout=10,
    readRetriesLimit=3,
    autoReconnectPeriod=1,
    localSourceAddr="0.0.0"
]
{
    Thing device Temp[COLOR=#FF0000]1[/COLOR] "KNX Tempregler [COLOR=#FF0000]1[/COLOR]" [
        address="1.1.11",
        fetch=true,
        pingInterval=300 [COLOR=#FF0000]//,[/COLOR]
[COLOR=#FF0000]//[/COLOR]      readInterval=3600
    ]
    {
        Type number : [COLOR=#FF0000]Temperature[/COLOR] "Temperature 1" [ ga="9.001:<1/7/0" ]
    }
    Thing device Temp[COLOR=#FF0000]2[/COLOR] "KNX Tempregler [COLOR=#FF0000]2[/COLOR]" [
        address="1.1.12",
        fetch=true,
        pingInterval=300 [COLOR=#FF0000]//,[/COLOR]
[COLOR=#FF0000]//[/COLOR]      readInterval=3600
    ]
    {
        Type number : [COLOR=#FF0000]Temperature[/COLOR] "Temperature 2" [ ga="9.001:<1/7/1" ]
    }
}

Jedes Thing muss einen eindeutigen Namen haben. Bei den Labeln bin ich mir nicht sicher, ob die zwingend eindeutig sein müssen, aber da die Label das Sortierkriterium sind und von VSCode verwendet werden, um eindeutige Itemnamen zu erzeugen (wenn man ganze Things auf einmal als Items anlegen lässt), ist es mehr als sinnvoll, hier eindeutig zu bleiben.
Im Gegensatz dazu kann aber der einzelne Channel eines Things immer den gleichen Namen haben. Wenn man mehrere identische Devices hat, dann sind auch die Channel jeweils identisch.
Probiere erst mal, ob die Temperaturen bei Wertänderung automatisch auf dem Bus landen. readInterval ist ein hässlicher Hack, der nur bei sehr wenigen Devices wirklich notwendig ist - normalerweise sollte ein Temperatursensor bei Wertänderung senden, alternativ zyklisch. Nur falls beide Optionen nicht funktionieren, wäre der Read Request sinnvoll (dann aber sicher nicht stündlich )
Weiterhin Obacht was die Hierarchie betrifft! Alle Things befinden sich exakt eine Klammerebene unter der Bridge, alle zu einem Thing gehöredenen Channel befinden sich exakt eine Klammerebene unter dem Thing.

[fritzrichter]

Mal ne Frage an die Experten:
Ich habe einen KNX-Taster, der eine Szene "Gute Nacht" (Szene Nr. 5, GA: 0/7/5) sendet. Entsprechende Aktoren schalten dann überall das Licht aus, die Raffstores werden runtergefahren etc.

Mit OH und dem KNX2-Binding möchte ich nun auf dieses Szenen-Event lauschen und entsprechend dann weitere Aktionen durchführen (z.B. HEOS Lautsprecher ausschalten).

Kann mir jemand sagen, wie ich auf dieses Szenen-Event lausche? Was für ein Thing/Device/Item benötige ich um auf die Szene Nr. 5 auf der GA zu reagieren?

[udo1toni]

Es handelt sich um einen number channel, Du musst auch den DTP mit angeben. Allerdings haben Szenen bei mir bisher nicht richtig funktioniert, weil sie fälschlicherweise als Float übergeben werden (und openHAB kommt damit nicht zurecht - schon witzig, weil es ja openHAB ist, was da Float drauß macht). Aber vielleicht ist das auch schon gefixt, ich hab in letzter Zeit wenig Gelegenheit gefunden, weiter zu probieren,
Da es im Normalfall kein Device gibt, welches für die Szene zuständig ist, sollte der Channel eigentlich vom Typ number-control sein, so dass openHAB hier Befehle entgegen nimmt. Kann aber sein, dass es in diesem Fall egal ist.

Weiterhin ist es wichtig zu wissen, dass knx auf dem Bus die Szenen von 0-63 durchnummeriert, während man z.B. in ETS überall 1-64 zu sehen bekommt (oder 1-32 statt 0-31). Die Szene 1 wird also als Szene 0 über den Bus gesendet.
Entsprechend musst Du in openHAB auf die Szene 4 reagieren, wenn es in ETS die Szene 5 ist, denn openHAB verwendet die native Zählung von 0-63.

[fritzrichter]

udo1toni vielen Dank für deine Antwort! Das werde ich nachher gleich mal ausprobieren. Eine Frage stellt sich mir dennoch. In dem neuen KNX2 Binding, muss ich die Channel ja einem Device zuordnen. Du sagtest ja selbst, es gibt nicht "das eine device", zu welchem Device packe ich dann mein number-control?

[udo1toni]

Naja, das kommt darauf an. Bei knx2 hast Du die Wahl, ob Du den gesamten Bus als ein Device betrachtest, oder jedes reale Device einzeln als Thing anlegst.
Bei letzterer Variante ist es dann das einfachste, ein zusätzliches Device anzulegen (das steht dann quasi für openHAB als Device). Für dieses Device kannst Du natürlich keine physikalische Adresse angeben, entsprechend bleiben die eckigen Klammern leer. Wahlweise kannst Du den Channel auch bei jedem anderen Device angeben, letztlich gibt es keine echte Abhängigkeit, sondern nur eine organisatorische.

[fritzrichter]

Macht Sinn... Besten Dank für die Antworten!

[fritzrichter]

Stoße gerade auf ein weiteres Problem!
Ich habe alle meine Fensterkontakte jeweils über dezentrale ABB Universal-Eingänge (ABB US/U4.2 Universal-Schnittstelle). Diese senden laut Gruppenmonitor beim Öffnen/Schließen 1.001 GA Signale. In OpenHab 2 kann ich diese nicht als "Contacts" zum laufen bringen. Verwende ich jedoch einen "Switch", dann funktioniert es. Aber ich möchte ja keinen Switch sondern lediglich eine Anzeige ohne Schreib-Möglichkeit. Habe in Foren gelesen, dass es irgendwas mit OpenClose und OnOff zutun haben soll, aber verstehen tu ich es aktuell noch nicht.

Ich habe auch die Datentypen in der ETS umgestellt, sodass diese jetzt erfolgreich als 1.019 senden. OpenHab logt diese Events auch erfolgreich:

2018-06-18 21:50:40.639 [vent.ItemStateChangedEvent] - SensorEGKamin_Fenster changed from CLOSED to OPEN

Dennoch ändert sich auf der Seite "Control" nichts...

[udo1toni]

Wenn sich das Item im Log ändert, ist alles gut (naja, die Frage ist natürlich, warum das in Paper UI nicht korrekt angezeigt wird...)
Grundsätzlich ist es egal, ob Du ein Switch Item oder ein Contact Item verwendest. Das Contact Item kennt die Zustände OPEN, CLOSED und NULL, während die Zustände für Switch Items OFF, ON und NULL sind (NULL nur der Vollständigkeit halber...)

Paper UI Control ist als UI zum Bedienen eher ungeeignet. Man kann die Oberfläche nicht konfigurieren, es gibt etliche Darstellungsfehler (unter anderem auch, dass der Refresh unter bestimmten Umständen nicht funktioniert). Die Control Sektion ist eher als Testmöglichkeit gedacht, um mal schnell zu schauen, ob die Items schon das tun, was sie sollen. Ich bin mir auch nicht sicher, ob hier intensiv vorhandene Fehler beseitigt werden.

Für die tägliche Nutzung sollten stattdessen entweder Basic UI oder HABpanel genutzt werden. Basic UI wird über die Sitemaps konfiguriert (das geht bisher nur über Textdateien), HABpanel wird über einen grafischen Editor konfiguriert, der in HABpanel eingebaut ist. HABpanel bietet weitgehend freie Konfiguration, dafür sollte man sich aber schon mit html und Konsorten auskennen, während Basic UI, nun ja, eher Basic ist, dafür ist die Beschreibung aber sehr leicht verständlich, wenn man sich mal damit befasst hat. Sitemaps werden auch für iOS und Android App gebraucht (wobei es da auch Apps von Drittanbietern gibt, die aus der Reihe tanzen).

Wenn man für die Darstellung eines "Readonly" Items nicht das Default oder Switch Widget verwendet, sondern das Text Widget, gibt es keine Schaltflächen. Dabei ist es unerheblich, welchen Itemtyp man verwendet.
Dies ist eine minimale Sitemap mit zwei Widgets, die beide das selbe Item anzeigen:
daheim.sitemap

sitemap daheim label="Zuhause" {
    Frame label="Ein Kasten" {
        Switch item=mySwitch // Mit Schaltfläche
        Text item=mySwitch // Ohne Schaltfläche
    }
}

[henfri]

Hallo,

kann man die
listeningGA auch über das Web-Interface setzen, oder geht das nur über die Konfigurationsdateien?

Gruß, Hendrik

[udo1toni]

knx2 ist vollständig über Paper UI konfigurierbar. Man sollte sich aber für eine Variante entscheiden, also entweder alles per knx.things Datei oder alles per Paper UI.

[henfri]

Hallo,

ich hatte "binding-knx - 2.3.0" ausprobiert. Das sollte dann doch knx2 sein, oder?
Wie gebe ich denn die hörende Adresse an?

Gruß,
Hendrik

[udo1toni]

Ja, den Unterschied kann man direkt in der Versionsnummer sehen. Die erste Ziffer steht für OH1 oder OH2 Binding.
Weiterhin gibt es bei einem OH1 Binding in Paper UI kein Thing. Bis auf den Eintrag in der Liste der Bindings ist ein OH1 Binding in Paper UI "unsichtbar".

Alle GA, die zu einem Channel gehören, werden gemeinsam angegeben, getrennt durch ein Plus-Zeichen. Die Konfiguration ist in Paper UI identisch zur Text-Konfiguration, nur dass in Paper UI einzelne Felder zu sehen sind, während in der knx.things Datei eine Zeile pro Channel üblich ist. (Es gibt auch Channel, die mehrere Eigenschaften vereinen, z.B. ein Rolladen kennt normalerweise mindestens 3 Eigenschaften, Langzeitbefehl, Kurzzeitbefehl und absolute Position (diese ankommend und abgehend). das sieht dann so aus:

Rollladenaktor 1. Kanal	GA	DPT
Langzeit	1/1/1	1.008
Kurzzeit	1/1/2	1.008
Position anfahren	1/1/3	5.001
Rückmeldung Position (lesbar, L-Flag gesetzt)	1/1/4	5.001

Das sieht in openHAB so aus:

Type rollershutter: ch1 "Rollladen 1" [ upDown="1/1/1", stopMove="1/1/2", position="5.001:1/1/3+<1/1/4" ]

Eigentlich sollte die Angabe des DPT unnötig sein, aber es gibt einen Bug in knx2, durch den der DPT nicht optional ist, sobald man mehr als eine GA angibt.
Das Kleiner-als-Zeichen (<) bedeutet, dass openHAB beim Start einen Read Request auf diese GA schickt. So sollte der Status von Anfang an korrekt angezeigt werden.
Ein einfacher Schalter hat auch eine Rückmeldung, aber der Channel hat nur ein Feld für die GA:

Type switch: ch1 "Schalter 1" [ ga="1.001:0/0/1+<0/0/2" ]

Die Regeln sind aber die gleichen. Auch hier ist die Angabe des DPT wegen des Bugs zwingend.

[henfri]

Danke.
werde es probieren!