Jojo hat geschrieben: ↑19. Apr 2021 08:31
udo1toni hat geschrieben: ↑18. Apr 2021 23:19
meine Abrechnungen mit Excel gemacht und meine Berechnungen haben im Gegensatz zur Abrechnungsstelle immer gestimmt...)
Da hätte ich einiges drauf gewettet
Du möchtest mich nur erröten sehen... Tatsächlich haben bis zur Umstellung auf eine digitale Dienstplanung (die seitdem die Überstunden automatisch berechnet) etliche Kollegen "meine" Excel-Arbeitsmappe verwendet...
Jojo hat geschrieben: ↑19. Apr 2021 08:31
Muss für das Funktionieren der Rule der Sensor zu allererst ein Update erhalten haben ? Sonst läuft ja der Timer nicht los oder ?
Genau. Die Rule muss einmal triggern, damit der Timer auch läuft. Sonst kann der Timer ja nicht auf OFF schalten.
Um dieses Problem zu umgehen, wäre tatsächlich die expire Funktion sinnvoller als ein Timer. Ich bin mir jetzt gerade nicht mehr sicher... openHAB2 oder openHAB3? Deshalbbeide Versionen:
in openHAB2 musst Du das expire Binding installieren. Anschließend richtest Du zwingend die Items zur Steuerung der LEDs über eine *.items Datei ein, denn das expire Binding ist ein v1 Binding, das heißt, es muss zwingend über die *.items Datei konfiguriert werden. Du richtest einen Link zusätzlich zum Link auf den Channel ein, mit dem Parameter
expire="5m,command=OFF".
In openHAB3 ist expire kein eigenes Binding mehr, stattdessen ist es in den Metadaten zu finden. Du legst also in den Metadaten der Items die Parameter für expire an, analog zur Konfiguration in openHAB2 (also als Zeit 5 Minuten und als auszuführende Funktion send command OFF).
Ab hier ist es für beide Welten gleich...
Die Rule reduziert sich nun auf eine Zeile:
Code: Alles auswählen
rule "update temp2"
when
Item HumBuero received update
then
rpower2.sendCommand(ON)
end
denn das Item wird immer, wenn der Status des Items nicht OFF ist, nach 5 Minuten zu diesem Status wechseln, und zwar mittels sendCommand, ein evtl. verlinkter Channel wird also aktiv gesteuert (und so wollen wir das ja haben).
Wenn Du jetzt noch die Namensgebung Deiner Items überdenkst
, kommst Du gar mit einer Rule für alle Sensoren aus, und das funktioniert so:
Du benennst das LED-Item genau wie das Item des Sensors, hängst aber noch ein LED hinten dran, also im Beispiel HumBueroLED.
Nun legst Du zwei Gruppen an, z.B. gHum und gHumLED. In die erste Gruppe kommen alle Fühler, in die zweite Gruppe kommen alle zugehörigen LED-Items. Nun reicht eine Rule:
Code: Alles auswählen
rule "update sensors"
when
Member of gHum received update
then
gHumLED.members.filter[ i | i.name == triggeringItem.name+"LED" ].head.sendCommand(ON)
end
gHumLED -> das Gruppenitem
.members -> eine Liste der Member
.filter[] ->gefiltert nach den angegeben Kriterien
i | -> nimm nacheinander jedes Listenelement und setzte es in i ein.
i.name == triggeringItem.name+"LED" -> Der Name des Items entspricht dem NAmen des Items, welches die Rule getriggert hat, ergänzt um die Zeichenfolge LED.
Das Ergebnis ist wieder eine Liste, in der nur die Elemente der ersten Liste enthalten sind, für die die Bedingung erfüllt ist.
.head -> nimm das erste Element der Liste (welche nur ein Element enthält, aber wir brauchen ein Item, keine Liste mit einem Item...)
Das .sendCommand kennst Du schon
Es ist egal, wieviele Sensoren Du so abdeckst, Du brauchst nur diese eine Rule. Es müssen lediglich die Namen der Items zueinander passen und die Items müssen den richtigen Gruppen zugeordnet sein.