ItemStateChangedEvent vs ItemCommandEvent

[JoergB]

Hallo,

ich habe mir eine (neue) Visu in Openhab erstellt und vieles davon geht auch bereits. Aber bei vielen über das KNX Binding eingebundenen Items erhalte ich laut der events.log nur ItemCommandEvents ala

"Item <Item-Name> received command <Value>"

Bei anderen erhalte ich sowohl die ItemCommandEvents als auch die ItemStateChangedEvents:

"<Item-Name> changed from <OldValue> to <NewValue>"

Dabei bin ich bei der Darstellung der Werte in der Visu auf die ItemStateChangedEvents angewiesen. Wonach richtet sich das, welche Events gesendet werden? Was muss ich tun, dass die ItemStateChangedEvents gesendet werden, damit die KNX Items die (richtigen) Werte erhalten?

Viele Grüße,
Jörg

[udo1toni]

Changed wird nur ausgelöst, wenn sich der Zustand eines Items geändert hat. Wenn auf einer GA immer nur ein ON reinkommt (z.B. bei Bewegungsmeldern), gibt es auch keine Änderung (nach dem ersten Event)

[JoergB]

Changed wird nur ausgelöst, wenn sich der Zustand eines Items geändert hat. Wenn auf einer GA immer nur ein ON reinkommt (z.B. bei Bewegungsmeldern), gibt es auch keine Änderung (nach dem ersten Event)

Okay, verstehe... Vielen Dank für die Info.

Wie kann ich dann für ein Item den richtigen Wert in der Visu bekommen, wenn Openhab neu gestartet wird. In dem Falle haben ja alle Items den Wert Null, soweit ich weiß. Der ändert sich ja erst, wenn sich der "echte Zustand" geändert hat. Das kann aber z.T. Tage dauern... Muss ich tatsächlich so lange warten oder gibt es eine Möglichkeit, das Ermitteln des echten Status bei Neustart von Openhab zu erzwingen?

[lo4dro]

da gibt es unterschiedliche Weg.
Ich kenne und nutze diese drei Möglichkeiten.

1) Persistence benutzen. (z.b. RRD4J) restoreOnStartup => Wert wiederherstellen

Strategies {
    everyMinute: "0 * * * * ?"
    everyHour : "0 0 * * * ?"
    everyDay  : "0 0 0 * * ?"
    default = everyChange
}
Items {
    KNX_Temp_1 : strategy = everyMinute, restoreOnStartup
    OW_Temp_1 : strategy = everyMinute, restoreOnStartup
} 

2) Aktiv die Komponente abfragen. das Geht z.B. bei KNX sehr gut. (KNX das "<" )

Rollershutter Rollo 1 "OG 1 [%s %%]"  {knx="0/0/50,0/0/51,5.001:0/0/56+<5.001:0/0/57"} 

3) Regel für den Systemstart anlegen. Die Regel kann dann Initial-Werte vorgeben oder aktiv ein Aktion ausführen

rule "Init"
when
        System started
then
        createTimer(now.plusSeconds(180)) [|
        if (Item1.state == NULL) item1.postUpdate(OFF)
        sendCommand(Item2, "ON")
        ]
end 

[JoergB]

Vielen Dank für die schnelle Antwort und die ausführlichen Infos!

Zu 1)
Sehe ich das richtig, dass diese Methode den Nachteil hat, dass wenn sich der Zustand eines Items innerhalb der "Downtime" von Openhab ändert, mir praktisch der letzte gespeicherte Wert in das Item nach dem Neustart geschrieben wird und nicht unbedingt der aktuelle?

Zu 2)
Das wäre mir auch die liebste Methode, aber selbst bei einem einfachen Schaltobjekt funktioniert das bei mir irgendwie nicht:

Switch DG_Schlafzimmer_Steckdose_2 <poweroutlet> (DG_Schlafzimmer) {knx="<3/4/32"}

Der Status dieser Steckdose wird nicht initialisiert beim Neustart von Openhab. Er bleibt auf "Null", obwohl die Steckdose "ON" ist. Sobald ich den Wert einmal ändere, wird er korrekt in der Visu dargestellt.

Zu 3)
Mit der Methode kann ich einen Wert explizit setzen (ist ja eigentlich kein "Lesen" zur Initialisierung). Aber bei z.B. einem Fensterkontakt ist das ja ziemlich sinnlos. Ich möchte ja zum Zeitpunkt des Neustarts den Wert wissen/visualisieren, den das Item gerade hat und den kann ich nicht unbedingt immer definiert setzen.

Grüße,
Jörg

[udo1toni]

Der einzig korrekte Weg für knx ist der zweite in der Liste. Dazu muss aber knx korrekt konfiguriert sein.

1. Voraussetzung: Es gibt für jeden Aktorkanal (bzw. für jeden Status) eine eigene GA, die die Rückmeldung übernimmt.
2. Voraussetzung: Nur der Aktor selbst antwortet auf Read Requests auf dieser GA (das heißt, es ist das L-Flag gesetzt)
3. Voraussetzung: in openHAB ist die Rückmelde-GA mit einem <-Zeichen eingetragen.

Wenn diese drei Bedingungen erfüllt sind, holt openHAB zuverlässig beim Start alle Status ab. Funktioniert bei mir wunderbar, mit 18 Schaltkanälen, 13 Dimmern, 20 Rollläden und 9 RTR. Wenn man mehrere Taster im Modus Toggle mit einem Aktor verknüpft, ist diese Rückmelde-GA meist auch als zweite GA im Taster einzutragen, damit alle Taster den aktuellen Zustand des Aktors kennen (insbesondere wichtig, wenn noch Szenen dazu kommen, sonst stimmt die Schaltrichtung beim 1. Tastendruck oft nicht, oder die Kontrolleuchte funktioniert nicht richtig...)

Andere Bindings unterstützen teilweise nicht die Abfrage des Status, dann bleibt einem nichts anderes übrig, als auf Persistence (1. Möglichkeit) oder gezieltes Setzen beim Hochfahren (3. Möglichkeit), aber das sollet wirklich nur ein Notnagel sein.

[JoergB]

1. Voraussetzung: Es gibt für jeden Aktorkanal (bzw. für jeden Status) eine eigene GA, die die Rückmeldung übernimmt.
2. Voraussetzung: Nur der Aktor selbst antwortet auf Read Requests auf dieser GA (das heißt, es ist das L-Flag gesetzt)
3. Voraussetzung: in openHAB ist die Rückmelde-GA mit einem <-Zeichen eingetragen.

Vielen Dank für die Liste!

Meine ABB Schaltaktoren SA/S12.16.5 bieten folgende Parameter:

ABBParameter2.png

ABBParameter.png

Dass ich eine GA zum Schalten benötige und eine für den Status habe ich verstanden. Auf welchen Wert muss ich aber die Rückmeldung setzen? Auf "nein", "bei Änderung" oder "immer"?

Könnte ich auch den Wert auf "nein" stellen und die GA für den Status mit den Schaltobjekten 10, 30, 50, ... verbinden (also für Schalten und Status das gleiche Schaltobjekt) oder muss ich den Status über 29, 49, 69, ... verbinden?

Grüße,
Jörg

[udo1toni]

Die Rückmeldung auf "immer" möchte ich mal so interpretieren, dass der Aktor auch eine Statusmeldung sendet, wenn er zwar einen Schaltbefehl erhielt, aber seinen Zustand nicht ändern musste, weil er ohnehin schon diesen Zustand hatte. Das wäre vermutlich die sicherste Variante, "bei Änderung" sollte aber auch ausreichen.

Wenn Du das Rückmeldeobjekt nicht benutzt, darfst Du jeden Aktorkanal nur mit exakt(!) einer GA betreiben. Trägst Du z.B. eine 2. GA ein (z.B. Zentral aus) bekommt openHAB das nicht mit. Trägst Du eine Szenen-GA ein, bekommt openHAB die Steuerung nicht mit. Im Gegensatz zum Zentral-Aus - die Adresse könnte man ja noch als 2. GA in der Item-Definition eintragen - müsstest Du, um das Szenenproblem abzufangen eine Rule bauen, die bei Szenenbefehlen den Status der Items entsprechend ändert, soll heißen, wenn Du jemals am Aktor was umkonfigurierst, musst Du zusätzlich die Rule anpassen und/oder die Konfiguration der Items.
Das Startup-Problem ist damit immer noch nicht gelöst, der Status in openHAB ist solange ungültig oder zweifelhaft, bis der Aktor das erste Mal geschaltet wurde.

Keinesfalls darf die Schalt-GA mit Read-Requests verwendet werden, falls man nämlich eine GA mit mehreren Aktorkanälen verbindet (normale Gruppenfunktion in knx) wird ein Read Request auf dieser Adresse im Zweifel einen Schaltvorgang auf allen verknüpften Aktoren auslösen. Wegen der Regeln 1 und 2 aus meinem Posting #6 könnte auch nur ein Aktor seinen Zustand melden, es ist verboten, mehrere Aktoren innerhalb einer GA mit L-Flag zu konfigurieren. (Verboten in dem Sinne, dass es Deine knx Installation "kaputt" macht - natürlich rein softwareseitig, man kann das mit erneuter Änderung "reparieren" - ETS lässt eine solche Konfiguration aber zu). Die einzelnen Busteilnehmer haben voneinander keine Ahnung, sie reagieren nur auf einprogrammierte GA oder senden auf solchen.

Also ein ganz klares NEIN! Es ist keine Option, nur eine einzige GA zu verwenden und keine Rückmelde-GA einzutragen. Ich verstehe ehrlich gesagt auch nicht, warum man etwas falsch konfigurieren will, wo es doch einen richtigen Weg gibt.
Es gibt aber jede Menge schlampig ausgeführter knx Installationen (auch von Fachleuten) bei denen das nicht korrekt durchgeführt wurde. In einer herkömmmlichen knx Installation ohne Server und ohne Kontrollleuchten im Taster fällt das dann nicht mal auf, vielleicht wundert sich mancher, warum er manchmal zweimal drücken muss, um das Licht auszuschalten, aber "das liegt sicher am unzuverlässigen Bus!" - Nicht.