Drehgriffkontakte gruppen
Moderator: seppy
-
- Beiträge: 153
- Registriert: 4. Mai 2020 01:31
- Wohnort: Hagen a.T.W.
Drehgriffkontakte gruppen
Hallo,
Ich besitze nun seit einiger Zeit die drehgriff Kontakte von homematic diese geben als state raus
OPEN, TILTED oder CLOSED
Nun habe ich ja Fenster gruppen von jedem Raum
Wenn ein Fenster aus dem Raum OPEN ist zeigt die Gruppe das auch an
Aber wenn ein Fenster auf TILTED (gekippt) steht sagt die Gruppe CLOSED
Können Gruppe den alle werte anzeigen? Würde mir ja auch reichen wenn ein Fenster auf Kipp steht das es in der Gruppe auf OPEN steht doch ist dies leider nicht so
Weiß da einer bescheid?
Als ergänzung
Mein Ziel ist zumindest offende Fenster in der sitemap anzeigen zulassen nur ist es halt doof das die Gruppen TILTED als CLOSED erkennen
Lg
Florian
Ich besitze nun seit einiger Zeit die drehgriff Kontakte von homematic diese geben als state raus
OPEN, TILTED oder CLOSED
Nun habe ich ja Fenster gruppen von jedem Raum
Wenn ein Fenster aus dem Raum OPEN ist zeigt die Gruppe das auch an
Aber wenn ein Fenster auf TILTED (gekippt) steht sagt die Gruppe CLOSED
Können Gruppe den alle werte anzeigen? Würde mir ja auch reichen wenn ein Fenster auf Kipp steht das es in der Gruppe auf OPEN steht doch ist dies leider nicht so
Weiß da einer bescheid?
Als ergänzung
Mein Ziel ist zumindest offende Fenster in der sitemap anzeigen zulassen nur ist es halt doof das die Gruppen TILTED als CLOSED erkennen
Lg
Florian
Schreibweisen in openHAB sind nicht beliebig, Funktionen mit zwei Parametern können nicht einfach so umfunktioniert werden...
Wie gesagt, die Aufgabe ich trotzdem vergleichsweise leicht lösbar:
gFenster ist hier die Gruppe aller Items, die als Status OPEN, TILTED oder CLOSED liefern. Dabei muss das Item nicht zwingend vom Typ String sein, nur kann Contact z.B. nur OPEN oder CLOSED als Status liefern (das wäre ein klassischer Kontakt)
.members liefert eine Liste aller unmittelbaren Member (d.h. nicht Kindeskinder) .filter[] filtert die Liste, im vorliegenden Fall nach dem Status der Items. .size liefert die Anzahl der Elemente der Liste. Wenn also kein Fenster gekippt ist, wird nTilted = 0 sein, wenn keines der Fenster geöffnet ist, wird nOpen = 0 sein, womit sie Summe beider Konstanten ebenfalls 0 ist. Nur dann wird das Item auf CLOSED gesetzt, ansonsten auf OPEN.
Geht es darum, (zusätzlich) Items für ein einzelnes Fenster zu setzen, so geht das auch, man müsste diese zusätzlichen Items aber in einer weiteren Gruppe zusammenfassen. Nehmen wir an, die Gruppe heißt gFenster_2 (und alle Items sind nach dem selben Schema benannt), dann sähe das so aus:
Die erste Zeile sucht das jeweils passende Zielitem anhand des Namens des auslösenden Items aus der 2. Gruppe heraus. Ein Filter liefert immer eine Liste von ITems, selbst, wenn es sich sicher nur um ein Item handelt (oder auch gar keines). .head liefert das erste Item der Liste als Item. Dieses wird nun dem Objekt myItem zugewiesen. Nun kann dieses Item wie gewohnt einen Status erhalten. Hier ist es am einfachsten, die umgekehrte Logik zu verwenden, also zu prüfen, ob der String von CLOSED abweicht (das wäre sowohl für OPEN als auch für TILTED der Fall)
Einzig der Zustand, dass ein Item noch keinen gültigen Zustand hat, führt damit zu einer falsch-positiven Meldung.
Gehe zur vollständigen AntwortWie gesagt, die Aufgabe ich trotzdem vergleichsweise leicht lösbar:
Code: Alles auswählen
rule "Fenster"
when
Member of gFenster changed
then
val nTilted = gFenster.members.filter[i|i.state.toString == "TILTED"].size
val nOpen = gFenster.members.filter[i|i.state.toString == "OPEN"].size
// val nClosed = gFenster.members.filter[i|i.state.toString == "CLOSED"].size
gFenster.postUpdate(if(nTilted + nOpen == 0)CLOSED else OPEN)
end
.members liefert eine Liste aller unmittelbaren Member (d.h. nicht Kindeskinder) .filter[] filtert die Liste, im vorliegenden Fall nach dem Status der Items. .size liefert die Anzahl der Elemente der Liste. Wenn also kein Fenster gekippt ist, wird nTilted = 0 sein, wenn keines der Fenster geöffnet ist, wird nOpen = 0 sein, womit sie Summe beider Konstanten ebenfalls 0 ist. Nur dann wird das Item auf CLOSED gesetzt, ansonsten auf OPEN.
Geht es darum, (zusätzlich) Items für ein einzelnes Fenster zu setzen, so geht das auch, man müsste diese zusätzlichen Items aber in einer weiteren Gruppe zusammenfassen. Nehmen wir an, die Gruppe heißt gFenster_2 (und alle Items sind nach dem selben Schema benannt), dann sähe das so aus:
Code: Alles auswählen
rule "Fenster"
when
Member of gFenster changed
then
val myItem = gFenster_2.members.filter[i|i.name.contains(triggeringItem.name)].head
myItem.postUpdate(if(triggeringItem.state.toString != "CLOSED") OPEN else CLOSED)
val nTilted = gFenster.members.filter[i|i.state.toString == "TILTED"].size
val nOpen = gFenster.members.filter[i|i.state.toString == "OPEN"].size
// val nClosed = gFenster.members.filter[i|i.state.toString == "CLOSED"].size
gFenster.postUpdate(if(nTilted + nOpen == 0)CLOSED else OPEN)
end
Einzig der Zustand, dass ein Item noch keinen gültigen Zustand hat, führt damit zu einer falsch-positiven Meldung.
openHAB 3.1.0M5 als Debian-Container in Proxmox
Bindings (HomeMatic, Shelly, Phillips Hue, HTTP, MQTT, Spotify, Telegram)
rund 90 HomeMatic komponenten dazu 21 Shelly und ca. 126 Phillips Hue Leuchten im einsatz.
MQTT bindung für openWB (WallBox) abfrage, HTTP für DoorPi (IP Türsprechstelle)
Bindings (HomeMatic, Shelly, Phillips Hue, HTTP, MQTT, Spotify, Telegram)
rund 90 HomeMatic komponenten dazu 21 Shelly und ca. 126 Phillips Hue Leuchten im einsatz.
MQTT bindung für openWB (WallBox) abfrage, HTTP für DoorPi (IP Türsprechstelle)
- udo1toni
- Beiträge: 13857
- Registriert: 11. Apr 2018 18:05
- Wohnort: Darmstadt
Re: Drehgriffkontakte gruppen
Wenn Du eine Gruppe veroderst (z.B. Group:Contact:OR(OPEN,CLOSED)) so kann die Gruppe nur zwei Zustände annehmen. Ich nehme an, die Griffe werden mit String Items in openHAB dargestellt?
Du kannst alle Griffe in einer Gruppe zusammenfassen, aber Du kannst den Status des Gruppenitems nicht automatisch setzen, denn es gibt keine eindeutige Zuordnung. Wie soll sich das Gruppenitem verhalten, wenn einzelne Member CLOSED sind, andere OPEN und ein weiterer Teil TILTED? Da geht nur über eine Rule, die den Status den eigenen Wünschen entsprechend setzt.
Du kannst alle Griffe in einer Gruppe zusammenfassen, aber Du kannst den Status des Gruppenitems nicht automatisch setzen, denn es gibt keine eindeutige Zuordnung. Wie soll sich das Gruppenitem verhalten, wenn einzelne Member CLOSED sind, andere OPEN und ein weiterer Teil TILTED? Da geht nur über eine Rule, die den Status den eigenen Wünschen entsprechend setzt.
openHAB4.1.2 stable in einem Debian-Container (bookworm) (Proxmox 8.1.5, LXC), mit openHABian eingerichtet
-
- Beiträge: 153
- Registriert: 4. Mai 2020 01:31
- Wohnort: Hagen a.T.W.
Re: Drehgriffkontakte gruppen
Hallo,
Ja die drehgriffe werden als string rausgegeben
Aktuell ist es so es sind 6 Fenster in einer Gruppe davon 1 Magnet Kontakt und 5 drehgriff Kontakte wenn man 1 Fenster öffnet geht die Gruppe auf OPEN ganz egal wie viele Fenster offen sind das ist ja soweit richtig.
Habe schon versucht über eine Regel die Fenster mit drehgriff so zumachen, test weite mit einem Fenster
Wenn das Fenster1 auf TILTED geht soll das item Fenster1_2 auf OPEN gehen
Und wenn das Fenster1 auf OPEN geht soll das item Fenster1_2 auf OPEN gehen und mit CLOSED das selbe
Dies hat allerdings nicht funktioniert habe demnach erstmal alles wieder so gemacht wie es war und hatte darauf hin den Beitrag geöffnet
Habe als Gruppe auch versucht
dies scheint aber nicht zu gehen
Aktuell sind die gruppen
Und bei dem aktuellen wird TILTED als CLOSED angezeigt
Wie würde den so eine rule aussehen?
Wäre meine Idee mit der rule die ich hatte auch eine Option?
Lg
Florian
Ja die drehgriffe werden als string rausgegeben
Aktuell ist es so es sind 6 Fenster in einer Gruppe davon 1 Magnet Kontakt und 5 drehgriff Kontakte wenn man 1 Fenster öffnet geht die Gruppe auf OPEN ganz egal wie viele Fenster offen sind das ist ja soweit richtig.
Habe schon versucht über eine Regel die Fenster mit drehgriff so zumachen, test weite mit einem Fenster
Wenn das Fenster1 auf TILTED geht soll das item Fenster1_2 auf OPEN gehen
Und wenn das Fenster1 auf OPEN geht soll das item Fenster1_2 auf OPEN gehen und mit CLOSED das selbe
Dies hat allerdings nicht funktioniert habe demnach erstmal alles wieder so gemacht wie es war und hatte darauf hin den Beitrag geöffnet
Habe als Gruppe auch versucht
Code: Alles auswählen
Group:String:OR(AND(OPEN, TILTED)Closed)
Aktuell sind die gruppen
Code: Alles auswählen
Group:Contact:OR(OPEN, CLOSED)
Wie würde den so eine rule aussehen?
Wäre meine Idee mit der rule die ich hatte auch eine Option?
Lg
Florian
openHAB 3.1.0M5 als Debian-Container in Proxmox
Bindings (HomeMatic, Shelly, Phillips Hue, HTTP, MQTT, Spotify, Telegram)
rund 90 HomeMatic komponenten dazu 21 Shelly und ca. 126 Phillips Hue Leuchten im einsatz.
MQTT bindung für openWB (WallBox) abfrage, HTTP für DoorPi (IP Türsprechstelle)
Bindings (HomeMatic, Shelly, Phillips Hue, HTTP, MQTT, Spotify, Telegram)
rund 90 HomeMatic komponenten dazu 21 Shelly und ca. 126 Phillips Hue Leuchten im einsatz.
MQTT bindung für openWB (WallBox) abfrage, HTTP für DoorPi (IP Türsprechstelle)
-
- Beiträge: 153
- Registriert: 4. Mai 2020 01:31
- Wohnort: Hagen a.T.W.
Re: Drehgriffkontakte gruppen
Sprich in der Gruppe soll TILTED als OPEN erkannt werden.
openHAB 3.1.0M5 als Debian-Container in Proxmox
Bindings (HomeMatic, Shelly, Phillips Hue, HTTP, MQTT, Spotify, Telegram)
rund 90 HomeMatic komponenten dazu 21 Shelly und ca. 126 Phillips Hue Leuchten im einsatz.
MQTT bindung für openWB (WallBox) abfrage, HTTP für DoorPi (IP Türsprechstelle)
Bindings (HomeMatic, Shelly, Phillips Hue, HTTP, MQTT, Spotify, Telegram)
rund 90 HomeMatic komponenten dazu 21 Shelly und ca. 126 Phillips Hue Leuchten im einsatz.
MQTT bindung für openWB (WallBox) abfrage, HTTP für DoorPi (IP Türsprechstelle)
- udo1toni
- Beiträge: 13857
- Registriert: 11. Apr 2018 18:05
- Wohnort: Darmstadt
Re: Drehgriffkontakte gruppen
Schreibweisen in openHAB sind nicht beliebig, Funktionen mit zwei Parametern können nicht einfach so umfunktioniert werden...
Wie gesagt, die Aufgabe ich trotzdem vergleichsweise leicht lösbar:
gFenster ist hier die Gruppe aller Items, die als Status OPEN, TILTED oder CLOSED liefern. Dabei muss das Item nicht zwingend vom Typ String sein, nur kann Contact z.B. nur OPEN oder CLOSED als Status liefern (das wäre ein klassischer Kontakt)
.members liefert eine Liste aller unmittelbaren Member (d.h. nicht Kindeskinder) .filter[] filtert die Liste, im vorliegenden Fall nach dem Status der Items. .size liefert die Anzahl der Elemente der Liste. Wenn also kein Fenster gekippt ist, wird nTilted = 0 sein, wenn keines der Fenster geöffnet ist, wird nOpen = 0 sein, womit sie Summe beider Konstanten ebenfalls 0 ist. Nur dann wird das Item auf CLOSED gesetzt, ansonsten auf OPEN.
Geht es darum, (zusätzlich) Items für ein einzelnes Fenster zu setzen, so geht das auch, man müsste diese zusätzlichen Items aber in einer weiteren Gruppe zusammenfassen. Nehmen wir an, die Gruppe heißt gFenster_2 (und alle Items sind nach dem selben Schema benannt), dann sähe das so aus:
Die erste Zeile sucht das jeweils passende Zielitem anhand des Namens des auslösenden Items aus der 2. Gruppe heraus. Ein Filter liefert immer eine Liste von ITems, selbst, wenn es sich sicher nur um ein Item handelt (oder auch gar keines). .head liefert das erste Item der Liste als Item. Dieses wird nun dem Objekt myItem zugewiesen. Nun kann dieses Item wie gewohnt einen Status erhalten. Hier ist es am einfachsten, die umgekehrte Logik zu verwenden, also zu prüfen, ob der String von CLOSED abweicht (das wäre sowohl für OPEN als auch für TILTED der Fall)
Einzig der Zustand, dass ein Item noch keinen gültigen Zustand hat, führt damit zu einer falsch-positiven Meldung.
Wie gesagt, die Aufgabe ich trotzdem vergleichsweise leicht lösbar:
Code: Alles auswählen
rule "Fenster"
when
Member of gFenster changed
then
val nTilted = gFenster.members.filter[i|i.state.toString == "TILTED"].size
val nOpen = gFenster.members.filter[i|i.state.toString == "OPEN"].size
// val nClosed = gFenster.members.filter[i|i.state.toString == "CLOSED"].size
gFenster.postUpdate(if(nTilted + nOpen == 0)CLOSED else OPEN)
end
.members liefert eine Liste aller unmittelbaren Member (d.h. nicht Kindeskinder) .filter[] filtert die Liste, im vorliegenden Fall nach dem Status der Items. .size liefert die Anzahl der Elemente der Liste. Wenn also kein Fenster gekippt ist, wird nTilted = 0 sein, wenn keines der Fenster geöffnet ist, wird nOpen = 0 sein, womit sie Summe beider Konstanten ebenfalls 0 ist. Nur dann wird das Item auf CLOSED gesetzt, ansonsten auf OPEN.
Geht es darum, (zusätzlich) Items für ein einzelnes Fenster zu setzen, so geht das auch, man müsste diese zusätzlichen Items aber in einer weiteren Gruppe zusammenfassen. Nehmen wir an, die Gruppe heißt gFenster_2 (und alle Items sind nach dem selben Schema benannt), dann sähe das so aus:
Code: Alles auswählen
rule "Fenster"
when
Member of gFenster changed
then
val myItem = gFenster_2.members.filter[i|i.name.contains(triggeringItem.name)].head
myItem.postUpdate(if(triggeringItem.state.toString != "CLOSED") OPEN else CLOSED)
val nTilted = gFenster.members.filter[i|i.state.toString == "TILTED"].size
val nOpen = gFenster.members.filter[i|i.state.toString == "OPEN"].size
// val nClosed = gFenster.members.filter[i|i.state.toString == "CLOSED"].size
gFenster.postUpdate(if(nTilted + nOpen == 0)CLOSED else OPEN)
end
Einzig der Zustand, dass ein Item noch keinen gültigen Zustand hat, führt damit zu einer falsch-positiven Meldung.
openHAB4.1.2 stable in einem Debian-Container (bookworm) (Proxmox 8.1.5, LXC), mit openHABian eingerichtet
-
- Beiträge: 153
- Registriert: 4. Mai 2020 01:31
- Wohnort: Hagen a.T.W.
Re: Drehgriffkontakte gruppen
Hallo,
danke dir klappt alles wie es soll
LG
Florian
danke dir klappt alles wie es soll
LG
Florian
openHAB 3.1.0M5 als Debian-Container in Proxmox
Bindings (HomeMatic, Shelly, Phillips Hue, HTTP, MQTT, Spotify, Telegram)
rund 90 HomeMatic komponenten dazu 21 Shelly und ca. 126 Phillips Hue Leuchten im einsatz.
MQTT bindung für openWB (WallBox) abfrage, HTTP für DoorPi (IP Türsprechstelle)
Bindings (HomeMatic, Shelly, Phillips Hue, HTTP, MQTT, Spotify, Telegram)
rund 90 HomeMatic komponenten dazu 21 Shelly und ca. 126 Phillips Hue Leuchten im einsatz.
MQTT bindung für openWB (WallBox) abfrage, HTTP für DoorPi (IP Türsprechstelle)
- peter-pan
- Beiträge: 2564
- Registriert: 28. Nov 2018 12:03
- Wohnort: Schwäbisch Gmünd
Re: Drehgriffkontakte gruppen
Ich habe auch HMIP_SRH. Du könntest auch folgendes versuchen, wenn du im Gruppenitem die Reihenfolge (OPEN,CLOSED) nach (CLOSED,OPEN) tauschst und das GruppenItem als "Item-Trigger" benutzt.
items:
.rules
Das ist die einfache Variante.
Dabei ist es egal welches Fenster geöffnet oder gekippt wurde. Der Status des GruppenItems bleibt so lange auf OPEN" bis das letzte Item der Gruppe "CLOSED" signalisiert. Und sobald wieder ein Fenster gekippt oder geöffnet wird, geht der Status auf "OPEN".
Edit:
Das wird dann auch so für die Gruppe in der Sitemap entsprechend angezeigt. Die Regel brauchst du nur, wenn du etwas spezifisches machen willst
items:
Code: Alles auswählen
Group:Contact:OR(CLOSED,OPEN) gFenster_xyz "Fenster mit gekippt [MAP(de.map):%s]" <window>
String HmIP_SRH_0515_1STATE "Terrassentuer Status[MAP(de.map):%s]" <door> (gFenster_xyz) {channel="homematic:HmIP-SRH:abcde:fghij:1#STATE"}
Code: Alles auswählen
rule "Fenster"
when
Item gFenster_xyz changed
then
if (gFenster_xyz.state == "OPEN") {
....dann mache dies oder jenes
}
if (gFenster_xyz.state== "CLOSED") {
....dann mache etwas anderes
}
end
Dabei ist es egal welches Fenster geöffnet oder gekippt wurde. Der Status des GruppenItems bleibt so lange auf OPEN" bis das letzte Item der Gruppe "CLOSED" signalisiert. Und sobald wieder ein Fenster gekippt oder geöffnet wird, geht der Status auf "OPEN".
Edit:
Das wird dann auch so für die Gruppe in der Sitemap entsprechend angezeigt. Die Regel brauchst du nur, wenn du etwas spezifisches machen willst
Pi5/8GB(PiOS Lite 64-bit(bookworm)/SSD 120GB - OH4.1.1 openhabian
-
- Beiträge: 153
- Registriert: 4. Mai 2020 01:31
- Wohnort: Hagen a.T.W.
Re: Drehgriffkontakte gruppen
Hallo peter-pan,
habe das ganze jetzt mal nach der anleizung von Udo gemacht aber deine habe ich mir auch mal angeschaut und funktioniert genau so gut
also danke euch auf jedenfall
Lg
Florian
habe das ganze jetzt mal nach der anleizung von Udo gemacht aber deine habe ich mir auch mal angeschaut und funktioniert genau so gut
also danke euch auf jedenfall
Lg
Florian
openHAB 3.1.0M5 als Debian-Container in Proxmox
Bindings (HomeMatic, Shelly, Phillips Hue, HTTP, MQTT, Spotify, Telegram)
rund 90 HomeMatic komponenten dazu 21 Shelly und ca. 126 Phillips Hue Leuchten im einsatz.
MQTT bindung für openWB (WallBox) abfrage, HTTP für DoorPi (IP Türsprechstelle)
Bindings (HomeMatic, Shelly, Phillips Hue, HTTP, MQTT, Spotify, Telegram)
rund 90 HomeMatic komponenten dazu 21 Shelly und ca. 126 Phillips Hue Leuchten im einsatz.
MQTT bindung für openWB (WallBox) abfrage, HTTP für DoorPi (IP Türsprechstelle)