Group STATE immer NULL bei einer STRING Gruppe

Einrichtung der openHAB Umgebung und allgemeine Konfigurationsthemen.

Moderatoren: seppy, udo1toni

Antworten
Benutzeravatar
Cyrelian
Beiträge: 601
Registriert: 24. Sep 2015 17:55
Answers: 4

Group STATE immer NULL bei einer STRING Gruppe

Beitrag von Cyrelian »

Hallo zusammen,

ich habe mal eine Verständnisfrage und wollte wissen ob das bei Euch ebenfalls so ist.
Ich habe eine Gruppe

Code: Alles auswählen

Group  gSysSmokeAlarm   "Rauchmelderstatus"      <fire>  (gSysMaint)
In dieser Gruppe befinden sich 5 Items vom Typ String.

Code: Alles auswählen

String	WohnzimmerSD_Status	"Rauchmelder (Wohnzimmer) [MAP(HmIP-SWSD.map):%s]"	<smoke>	(gWohnzimmerSD,gSysSmokeAlarm)
Der Status ALLER Items ist „IDLE_OFF“.

Die Dokumentation sagt dazu folgendes:
EQUALITY Default if no function is specified. If ALL members have state X the group state will be X, otherwise the group state will be UNDEF
Der Status der Gruppe selbst bleibt aber NULL. Mein Ziel war es in einer Rule folgendes abzufragen:

Code: Alles auswählen

when
    Item gTemperatures changed or
    Item gSysSmokeAlarm changed
Leider funktioniert

Code: Alles auswählen

 Item gSysSmokeAlarm changed 
nicht, da diese immer NULL ist.

Ich denke ich werde um ein Proxy Items nicht drum rum kommen oder?

CYA
Cyrelian
von udo1toni » 30. Jan 2020 12:59
Also, Gruppenstatus sind so eine Sache, schon gleich bei Strings, weil die Berechnungen (AVG, SUM, MAX, MIN, EQU) hier nicht funktionieren. Ja, auch Equality, denn es wird auf numerische Gleichheit geprüft.

Es ist aber ohnehin nicht gut, auf Item groupitem changed zu triggern. Es wurde mal vor Jahren etwas genauer auf den Code geschaut, weil nämlich eine Rule bei einem Update eines GroupItems einmal pro Member ausgelöst wird (egal, ob dieser Member upgedatet wurde oder nicht). Das ist ziemlich sicher kein erwünschtes Verhalten. Bei changed ist es nicht so kritisch, aber trotzdem nicht schön.
Daraufhin wurde Member of als Trigger hinzugefügt, welcher dann sauber nur einmal pro geändertem/upgedatetem Item triggert.

In der Programmierung ergeben sich keine Einschränkungen, im Gegenteil, mit triggeringItem steht sogar noch ein implizites Objekt zur Verfügung, um die Arbeit zu erleichtern.

Um nun Equality zu testen, sähe eine Rule so aus:

Code: Alles auswählen

rule "Smokealarm Gruppe prüfen"
when
    Member of gSysSmokeAlarm changed
then
    val lItems = gSysSmokeAlarm.members.filter[i|!(i.state.toString.contains("IDLE_OFF"))]
    if(lItems.size > 0) {
        gSysSmokeAlarm.postUpdate("ALARM")
        lItems.forEach[j|
            logInfo("smoke","Item {} hat Status {}",j.name,j.state)
        ]
    } else
        gSysSmokeAlarm.postUpdate("IDLE_OFF")
end
Die Definition des Objekts lItems ist nicht zwingend, erhöht hier aber hoffentlich die Lesbarkeit. Das Objekt enthält eine gefilterte Liste aller Member der Gruppe. der Filter sucht alle Items heraus, deren Status nicht den (Teil-)String IDLE_OFF enthalten.
Die if-Anweisung prüft, ob die Liste Items enthält (size ist die Anzahl der Items) und setzt dann das Gruppenitem gezielt auf den korrekten Wert (Wobei Alarm hier sicher nicht mit Rauchalarm gleichzusetzen ist, weil es vermutlich neben IDLE_OFF auch andere Status geben wird, die nicht unmittelsbar Brand oder Rauch bedeuten. Entsprechend wird zusätzlich der Status jedes Items, welches nicht IDLE_OFF als Status führt ins log geschrieben.

Wie man sieht, braucht es nicht mal das triggernde Item, da ja die gesamte Gruppe betrachtet werden soll.
Gehe zur vollständigen Antwort

Benutzeravatar
PeterA
Beiträge: 1106
Registriert: 8. Feb 2019 12:12
Answers: 13

Re: Group STATE immer NULL bei einer STRING Gruppe

Beitrag von PeterA »

Kann es sein das Du dann die Gruppe auch als "String" Gruppe definieren müsstest ?

Wobei ich in der Doku nur das gefunden habe:

Code: Alles auswählen

Group:Number             Lights       "Active Lights [%d]"              // e.g. "2"
Group:Switch:OR(ON,OFF)  Lights       "Active Lights [%d]"              // e.g. ON and "2"
Group:Number:AVG         Temperatures "All Room Temperatures [%.1f °C]" // e.g. "21.3 °C"
Wobei das aber auch definiert werden kann:

https://community.openhab.org/t/string-group/73240

Und hier habe ich auch noch was gefunden:

https://community.openhab.org/t/group-f ... lues/31532
- OpenHab 2.4
#PWRUP

Benutzeravatar
Cyrelian
Beiträge: 601
Registriert: 24. Sep 2015 17:55
Answers: 4

Re: Group STATE immer NULL bei einer STRING Gruppe

Beitrag von Cyrelian »

Hi Peter,

Code: Alles auswählen

Group:String  gSysSmokeAlarm   "Rauchmelderstatus"      <fire>  (gSysMaint)
hatte ich probiert. Da bekomme ich aber ne Fehlermeldung...heute Abend kann ich mal die genaue Meldung posten.
Was ich mal probiere ist das:

Code: Alles auswählen

Group:String:EQUALS("IDLE_OFF") gSysSmokeAlarm   "Rauchmelderstatus"      <fire>  (gSysMaint)
THX
Cyrelian

Benutzeravatar
peter-pan
Beiträge: 2758
Registriert: 28. Nov 2018 12:03
Answers: 30
Wohnort: Schwäbisch Gmünd

Re: Group STATE immer NULL bei einer STRING Gruppe

Beitrag von peter-pan »

...hast du es schon so probiert ?

Code: Alles auswählen

Member of <group> received command [<command>]
Member of <group> received update [<state>]
Member of <group> changed [from <state>] [to <state>]
Pi5/8GB(PiOS Lite 64-bit(bookworm)/SSD 120GB - OH4.3.5 openhabian

Benutzeravatar
udo1toni
Beiträge: 15248
Registriert: 11. Apr 2018 18:05
Answers: 242
Wohnort: Darmstadt

Re: Group STATE immer NULL bei einer STRING Gruppe

Beitrag von udo1toni »

Also, Gruppenstatus sind so eine Sache, schon gleich bei Strings, weil die Berechnungen (AVG, SUM, MAX, MIN, EQU) hier nicht funktionieren. Ja, auch Equality, denn es wird auf numerische Gleichheit geprüft.

Es ist aber ohnehin nicht gut, auf Item groupitem changed zu triggern. Es wurde mal vor Jahren etwas genauer auf den Code geschaut, weil nämlich eine Rule bei einem Update eines GroupItems einmal pro Member ausgelöst wird (egal, ob dieser Member upgedatet wurde oder nicht). Das ist ziemlich sicher kein erwünschtes Verhalten. Bei changed ist es nicht so kritisch, aber trotzdem nicht schön.
Daraufhin wurde Member of als Trigger hinzugefügt, welcher dann sauber nur einmal pro geändertem/upgedatetem Item triggert.

In der Programmierung ergeben sich keine Einschränkungen, im Gegenteil, mit triggeringItem steht sogar noch ein implizites Objekt zur Verfügung, um die Arbeit zu erleichtern.

Um nun Equality zu testen, sähe eine Rule so aus:

Code: Alles auswählen

rule "Smokealarm Gruppe prüfen"
when
    Member of gSysSmokeAlarm changed
then
    val lItems = gSysSmokeAlarm.members.filter[i|!(i.state.toString.contains("IDLE_OFF"))]
    if(lItems.size > 0) {
        gSysSmokeAlarm.postUpdate("ALARM")
        lItems.forEach[j|
            logInfo("smoke","Item {} hat Status {}",j.name,j.state)
        ]
    } else
        gSysSmokeAlarm.postUpdate("IDLE_OFF")
end
Die Definition des Objekts lItems ist nicht zwingend, erhöht hier aber hoffentlich die Lesbarkeit. Das Objekt enthält eine gefilterte Liste aller Member der Gruppe. der Filter sucht alle Items heraus, deren Status nicht den (Teil-)String IDLE_OFF enthalten.
Die if-Anweisung prüft, ob die Liste Items enthält (size ist die Anzahl der Items) und setzt dann das Gruppenitem gezielt auf den korrekten Wert (Wobei Alarm hier sicher nicht mit Rauchalarm gleichzusetzen ist, weil es vermutlich neben IDLE_OFF auch andere Status geben wird, die nicht unmittelsbar Brand oder Rauch bedeuten. Entsprechend wird zusätzlich der Status jedes Items, welches nicht IDLE_OFF als Status führt ins log geschrieben.

Wie man sieht, braucht es nicht mal das triggernde Item, da ja die gesamte Gruppe betrachtet werden soll.
openHAB4.3.3 stable in einem Debian-Container (bookworm) (Proxmox 8.3.5, LXC), mit openHABian eingerichtet

Benutzeravatar
PeterA
Beiträge: 1106
Registriert: 8. Feb 2019 12:12
Answers: 13

Re: Group STATE immer NULL bei einer STRING Gruppe

Beitrag von PeterA »

👏 Achso... "Applause"
- OpenHab 2.4
#PWRUP

Benutzeravatar
Cyrelian
Beiträge: 601
Registriert: 24. Sep 2015 17:55
Answers: 4

Re: Group STATE immer NULL bei einer STRING Gruppe

Beitrag von Cyrelian »

Hi Udo,

was soll ich sagen...läuft :mrgreen: Einfach genial.

THX
Cyrelian

Antworten