Letztes Item triggert eine Gruppe

[int5749]

Hallo zusammen,

gibt es eine Möglichkeit das letzte Item einer Gruppe zu ermitteln, welches den Status eines Items verändert hat?

Das implizite item triggeringItem steht ja nur bei "Member of Group changed" zur Verfügung.

Hintergrund:
Ich habe eine Grupper, welche 4 Items beinhaltet. Die Gruppe ist OFF wenn min 1 Item der Gruppe ON ist.
Sobald das letzte Item der Gruppe auf OFF wechselt, wird der Status der Gruppe ON
Hier möchte ich nun gerne ermitteln: Wer war der "Übeltäter", der den Statuswechsel des Items getriggert hat.

Viele Grüße

[udo1toni]

Einen direkten Weg wüsste ich jetzt nicht, indirekt ist es aber kein Problem:

Code: Alles auswählen

rule "teste Gruppe"
when
    Member of myGroup changed to OFF
then
    if(myGroup.state == ON)
        logInfo("testgroup","Der Übeltäter ist {}",triggeringItem.name)
end

Der Punkt ist, die Gruppe kann nur ON sein, wenn alle Items OFF sind. Wenn also ein Item auf OFF wechselt, reicht es, zu prüfen, ob die Gruppe ON ist. Wahlweise kannst Du auch so prüfen:

Code: Alles auswählen

if(myGroup.members.filter[i|i.state != OFF].size == 0)

Die Liste der Member der Gruppe myGroup wird auf die Einträge gefiltert, welche einen Status ungleich OFF haben. anschließend wird die Anzahl der Listeneinträge geprüft. Ist sie 0, so haben alle Items der Gruppe den Status OFF. Auch hier gilt mit dem passenden Trigger (Member changed to
OFF), dass triggeringItem das zuletzt auf OFF gewechselte Item sein muss.

[int5749]

Danke Dir.

OK, dann muss halt bei jedem Trigger einmal durch die Rule, geht ja schnell "in a blink of an eye"
Habe es umgebaut und werde es ein paar Tage beobachten.

VG

[udo1toni]

Ja, das lässt sich nicht vermeiden. Wobei es sich natürlich doch vermeiden lässt...

Die Rule könnte auch auf Item MyGroup changed to ON triggern.
Innerhalb der Rule musst Du dann für alle Group Member previousState(true).time (?) abfragen und das mit dem jüngsten Zeitstempel raus suchen. Allerdings müssen dann alle Items persistiert sein, und mapDB reicht nicht, denn es muss ja der letzte Wechsel des Status gefunden werden (deshalb das true).
Ich bin mir recht sicher, dass der Aufwand dafür um Größenordnungen höher ist, als damit zu leben, dass die Rule unnötig oft triggert.

[int5749]

Ich bin mir recht sicher, dass der Aufwand dafür um Größenordnungen höher ist, als damit zu leben, dass die Rule unnötig oft triggert.

Ja, daher habe ich dies nun ein paar Tage beobachtet und es schien schon fast gut zu laufen. Schien und fast gut, weil eine Abfrage noch nicht funktioniert => Abfrage des letzten Status der Gruppe, welche natürlich in der MapDB persistiert ist.

Code: Alles auswählen

GhostMode : strategy = everyChange,restoreOnStartup

Code: Alles auswählen

rule Ghost
when
	Member of GhostMode changed
then
	logInfo("Ghost", "Getriggert von: {}", triggeringItem.label.split(" ").get(0).toString)
	logInfo("Ghost", "Actual: {}", GhostMode.state.toString)
	logInfo("Ghost", "Previous: {}", GhostMode.previousState(false,"mapdb").state.toString)
	logInfo("Ghost", "MapDB: {}", GhostMode.previousState(false,"mapdb").toString)
	if (GhostMode.state == OFF && GhostMode.previousState(false,"mapdb").state == ON) {
		Absence.postUpdate(OFF)	// Stoppe Anwesendheitssimulation
	}
end

Seltsamerweiser ist bei dem Log-Eintrag dann der Actual Status identisch mit dem Previous
Somit läuft die Rule natürlich nicht in den gewünschten Zweig

Log-Eintrag (Beispiele)

2022-04-12 08:10:14.244 [INFO ] [org.openhab.core.model.script.Ghost ] - Actual: ON
2022-04-12 08:10:14.246 [INFO ] [org.openhab.core.model.script.Ghost ] - Previous: ON
Hier hatte ich die Abfrage der MapDB noch nicht eingebaut

2022-04-15 16:01:57.213 [INFO ] [org.openhab.core.model.script.Ghost ] - Actual: OFF
2022-04-15 16:01:57.214 [INFO ] [org.openhab.core.model.script.Ghost ] - Previous: OFF
2022-04-15 16:01:57.214 [INFO ] [org.openhab.core.model.script.Ghost ] - MapDB: 14.04.2022, 15:17:52: GhostMode -> OFF

[udo1toni]

Das ist ein gern genommenes Missverständnis. mapDB speichert ausschließlich den aktuellen Status, nicht den vorherigen.

[int5749]

Das ist ein gern genommenes Missverständnis. mapDB speichert ausschließlich den aktuellen Status, nicht den vorherigen.

Ahh, das erklört einiges

Ich habe dies dann nach jdbc geändert, leider mit ohne Erfolg

2022-04-16 21:05:15.729 [INFO ] [org.openhab.core.model.script.Ghost ] - Actual: ON
2022-04-16 21:05:15.730 [INFO ] [org.openhab.core.model.script.Ghost ] - Previous: ON
2022-04-16 21:05:15.731 [INFO ] [org.openhab.core.model.script.Ghost ] - JDBC: JdbcItem [name=GhostMode, state=ON, timestamp=2022-04-16T21:05:12.932+02:00[Europe/Berlin]]

2022-04-16 21:05:40.639 [INFO ] [org.openhab.core.model.script.Ghost ] - Actual: OFF
2022-04-16 21:05:41.640 [INFO ] [org.openhab.core.model.script.Ghost ] - Previous: OFF
2022-04-16 21:05:41.641 [INFO ] [org.openhab.core.model.script.Ghost ] - JDBC: JdbcItem [name=GhostMode, state=OFF, timestamp=2022-04-16T21:05:40.637+02:00[Europe/Berlin]]

Die Log Aufrufe sehen wie folgt aus

Code: Alles auswählen

logInfo("Ghost", "Actual: {}", GhostMode.state.toString)
logInfo("Ghost", "Previous: {}", GhostMode.previousState(false,"jdbc").state.toString)
logInfo("Ghost", "JDBC: {}", GhostMode.previousState(false,"jdbc").toString)

Scheinbar wird previousState nicht abgefragt?

Auszug aus der Datenbank

2022-04-16 20:59:24.839 ON
2022-04-16 20:59:24.884 OFF
2022-04-16 21:05:12.932 ON
2022-04-16 21:05:40.637 OFF

VG

[int5749]

Ein wechseln auf "true" soll evtl helfen

Code: Alles auswählen

logInfo("Ghost", "JDBC: {}", GhostMode.previousState(true,"jdbc").toString)

Werde ich mal testen, denn eigentlich muss es ja immer ein Wechsel zwischen ON und OFF sein.

[udo1toni]

MeinItem.previousState(true,<service>).state liefert den letzten Status, der sich vom aktuellen Status unterscheidet.
MeinItem.previousState(false,<service>).state liefert den vorletzten gespeicherten Wert, unabhängig davon, ob dies der gleiche Status ist, den man hat oder nicht. (vergleichbar mit den unterschiedlichen Triggern received update und changed).
Wenn Du die Persistence konfigurierst, kannst Du auch entscheiden, ob die Persistence everyChange oder everyUpdate persistiert. (oder auch nur auf Zeit...)