OH3 KNX-Binding schreibt keine KNX-Szenen auf den Bus

[kuczerek]

Hi zusammen,

ich migriere gerade meine OH2 Installation auf OH3. Gleichzeitig implementiere ich meine bestehenden DSL Regeln neu in JavaScript. Beim Schreiben von KNX-Szenen transportiert das KNX Bindung meine Skript Befehle aber nicht auf den Bus, währende openHAB allerdings Veränderungen der KNX Szenen vom Bus tadellos empfängt. Ich habe folgende Konfiguration:

KNX Thing mit einem Szenen Channel Typ Number:

thing.png

... daran hängt ein Item Typ Number

item.png

(... hmm, warum wir der Screenshot so klein angezeigt, naja egal...)

wenn ich die Szenen an einem Taster (also ohne openHAB) durchschalte, kann ich in den openHAB Logs Folgendes sehen:

Code: Alles auswählen

Item 'KNXLichtEGWohnzimmerSzene' changed from 1.0 to 2.0
Item 'KNXLichtEGWohnzimmerSzene' changed from 2.0 to 5.0
...

Mit folgendem Code-Snippet will ich die Szenen aus einem JavaScript heraus ändern:

Code: Alles auswählen

events.postUpdate("KNXLichtEGWohnzimmerSzene", 4.0);

Im Ergebnis sehe ich zwar folgende Ausgabe in der events.log:

Code: Alles auswählen

Item 'KNXLichtEGWohnzimmerSzene' changed from 5.0 to 4

... aber wenn ich gleichzeitig in der ETS den Gruppenmonitor laufen lasse sehe ich, dass openHAB keinen Befehl auf den KNX Bus schreibt. Andere KNX Befehle funktionieren problemlos, nur das Schreiben der Szene will irgendwie nicht klappen.
Auffällig ist natürlich, dass openHAB die von KNX gesendeten Kommandos im Log als Float darstellt, die von openHAB selbst ausgesendeten Ziffern allerdings als Integer. Ich bin mir nicht sicher, ob hier vielleicht das Problem liegt, und das KNX-Bus Gateway den Befehl aufgrund eines falschen Formats direkt ablehnt. Ein erzwungenes casten auf Float im Code ändert daran übrigens nichts. Mit folgendem Code

Code: Alles auswählen

events.postUpdate("KNXLichtEGWohnzimmerSzene", parseFloat("4.0"));

bleibt die Ausgabe in den Logs genau gleich.

Unter openHAB 2.5 hat mit folgender Regel in DSL alles reibungslos funktioniert, an der Konfiguration im Bus habe ich nichts geändert:

Code: Alles auswählen

rule "Wohnzimmer Szene Essen"
when
    Item KNXLichtEGWohnzimmerSzene received command
then
    if (receivedCommand == ON) {
        KNXLichtEGWohnzimmerSzene.sendCommand(0)
    }
    else if (receivedCommand == OFF) {
        KNXLichtEGWohnzimmerSzene.sendCommand(5)
    }
end

Hat irgendjemand eine Idee? Wir schreibt ihr KNX Szenen in OpenHAB3 auf den Bus?

Gruß,
Kuczerek

[kuczerek]

Ok, ich habs,

es muss

Code: Alles auswählen

events.sendCommand("KNXLichtEGWohnzimmerSzene", parseFloat("4.0"));

heißen nicht "postUpdate". Ich glaube ich habe den Unterschied noch nicht ganz verstanden...

[int5749]

Ich glaube ich habe den Unterschied noch nicht ganz verstanden...

sendCommand => Command = Befehl => Schicke einen Befehl (zur Änderung) an ein Objekt
postUpdate => sage einem Objekt es hat einen anderen Wert, ohne das dies als Befehl ber den Bus gesendet wird

So habe ich dies für mich verstanden, hoffe dies ist nicht völliger Quatsch

[udo1toni]

Ja. Aber ausgerechnet bei knx muss man noch sagen "Aber wenn"...

Das knx Binding bringt eine Sonderfunktion mit, das sind die *-control Channel. Es gibt jede Channel-Art (Switch, Rollershutter, Dimmer...) zusätzlich nochmal als -control Variante. Diese Channel verhalten sich exakt entgegengesetzt zu den normalen Channels. Die Idee dahinter ist folgende:
Ein normaler Channel stellt einen Aktor am knx Bus dar (oder alternativ einen Sensor), das heißt, der knx Bus liefert ausschließlich Status an openHAB. Im Gegenzug sendet openHAB ausschließlich Befehle an den knx Bus (z.B. um ein Licht einzuschalten).
Wenn nun aber ein Aktor nicht an knx angeschlossen ist, so muss ein eingehendes Telegramm aus knx als Befehl gewertet werden. openHAB übernimmt dann am knx Bus die Rolle des Aktors (oder Sensors) und sendet den Status direkt an den knx Bus zurück. Und es ist tatsächlich so, dass ein postUpdate in diesem Fall direkt zum knx Bus weitergeleitet wird. Das hat man so gemacht, damit man einfach zwei Channel mit einem Item verknüpfen, und anschließend das nicht-knx-Gerät so bedienen kann, als sei es ein knx-Gerät. Ganz ohne Rules oder so... Das stammt aus einer Zeit, bevor es Profile=follow gab... so ungefähr openHAB2.2...)

Übrigens gibt es per Definition bei knx Scenes keinen gültigen Status. Und kein Busgerät darf einen Read Request auf ein Szenen-KO beantworten. Insofern ist das < vor der Busadresse falsch.

[kuczerek]

Hi zusammen,

vielen Dank für die guten Erläuterungen. Jetzt habe ich den Unterschied verstanden. Gilt diese Differenzierung zwischen "sendCommand" und "postUpdate" im Prinzip für alle Bindings, oder ist das nur bei KNX so? Ich denke mal ersteres, würde ja sonst keinen Sinn machen...

Der Hinweis mit den Profilen hat mich an anderer Stelle zusätzlich auf die Idee gebracht, den Status der Stellgröße von KNX Heizungsaktoren gleich im Channel in vernünftige Prozentwerte umzurechnen, anstatt sie in einem openHAB Dimmer Item zu verarbeiten. So kann ich gleich ein Number Item nutzen und die Analyse Darstellung in openHAB3 sieht gleich richtig aus

Übrigens gibt es per Definition bei knx Scenes keinen gültigen Status. Und kein Busgerät darf einen Read Request auf ein Szenen-KO beantworten. Insofern ist das < vor der Busadresse falsch.

OK, das wusste ich gar nicht. Habe die Adresse gerade testweise mal in der ETS abgefragt, und siehe da: Mein Gira Tastsensor antwortet. Kann aber sein, dass ich selber das Lesen Flag im Szenen-Nebenstelleingang vor einiger Zeit gesetzt habe, da ich die aktuelle Szene beim Start von zum Beispiel openHAB gleich richtig initialisieren möchte. Bis jetzt ging das auch immer tadellos.

THX,
Kuczerek.

[udo1toni]

Habe die Adresse gerade testweise mal in der ETS abgefragt, und siehe da: Mein Gira Tastsensor antwortet. Kann aber sein, dass ich selber das Lesen Flag im Szenen-Nebenstelleingang vor einiger Zeit gesetzt habe, da ich die aktuelle Szene beim Start von zum Beispiel openHAB gleich richtig initialisieren möchte. Bis jetzt ging das auch immer tadellos.

Ja, das mag sein
Nehmen wir mal an, Du steuerst zwei Schaltkanäle über eine Szene, die mit GA 0/0/1 gekoppelt ist. Szene 1 ist dabei OFF/OFF, Szene 2 OFF/ON, Szene 3 ON/OFF und Szene 4 ON/ON.
Nun sendest Du Szene 4, die beiden Geräte wechseln auf ON/ON.
Leider gibt es aber noch eine zusätzliche Taste im Raum, mit der Du den 2. Aktor manuell bedienen kannst. Damit schaltest Du nun den 2. Aktor OFF. Der aktuelle Zustand lautet nun: Szene 4, Aktorzustände ON/OFF. Das knx System kann die Szenennummer nicht ändern, weil das schlicht nicht vorgesehen ist.
Um es mal anders auszudrücken: Szenen werden aufgerufen, eine Szene ist aber niemals aktiv.
Dass Du damit bei Dir keine Probleme hast, kann verschiedene Gründe haben, z.B. dass Du die betreffenden Kreise ausschließlich über die Szenensteuerung bedienst.

Die knx Hardware unterscheidet ausdrücklich zwischen Datenpaketen, die als Befehl gesendet wurden und solchen, die als Antwort auf einen Read Request erfolgten. Man kann über die Flags der KO bestimmen, ob ein Gerät nur auf das Command oder zusätzlich auch auf den Response reagiert. Gewöhnlich ist Letzteres abgeschaltet, so dass der Read Request auf dem Bus nicht zu zusätzlichen Schaltereignissen führt.
openHAB hat keine Einstellmöglichkeit für das A-Flag (bzw. U-Flag im englischen). openHAB wird also eine gesendete Zahl an dieser Stelle immer als Status (oder im Fall von number-control immer als Command) interpretieren.


Grundsätzlich gilt für postUpdate und sendCommand das von @int5749 aufgeführte Verhalten: postUpdate setzt einen Status eines Items, sendCommand sendet einen Befehl an das Item (welches diesen Befehl dann an alle gebundenen Channel weiterreicht). knx ist lediglich insofern eine Ausnahme, dass es ein postUpdate ebenfalls an den knx Bus weiterreicht, wenn der betreffende Channel ein *-control Channel ist.

In der Gegenrichtung gilt das gleiche: Grundsätzlich kann man Rules auf received command oder received update triggern lassen.
received command wird nur bei einem empfangenen Befehl getriggert. Über die Bindings kommen gewöhnlich aber nur Status hinein, keine Befehle. Deshalb wird received command gewöhnlich nur dann triggern, wenn man in der UI einen Schalter umlegt oder Ähnliches.
received update reagiert nur, wenn ein Status Update erfolgt ist, gewöhnlich also nur, wenn ein Channel einen Status empfangen hat.

Allerdings gibt es inzwischen einige Bindings, die es ermöglichen, einzelne Channel als Command Channel zu definieren (in knx geschieht das über *-control...).
Weiterhin ist das gewöhnliche Verhalten von openHAB so, dass ein sendCommand (egal ob als Befehl oder über die UI abgesetzt) ein postUpdate nach sich zieht, weil openHAB den wahrscheinlichen Status vorhersagt (predicted to become ---) und vorsorglich schon mal als Status speichert. Die Idee dahinter ist eine schneller reagierende Anzeige, um den Preis, dass die Anzeige vielleicht nicht allzu viel mit der Realität zu tun hat, bis der gebundene Channel seinerseits einen Status gesendet hat. Man kann dieses Verhalten mit dem Parameter autoupdate=false abschalten (und sollte das nach Möglichkeit auch tun, sofern ein Channel einen Status liefert).