Wie peter-pan schon sehr richtig schreibt...
Ein Channel Trigger benötigt die vollständige Channel UID
Die einfachste Variante für das Pflanzenlicht wäre hier eine Rule (Gegeben: ein Thing
astro:sun:local, das packt openHAB automatisch in die Inbox, wenn man den Standort des Systems angibt und astro installiert):
Code: Alles auswählen
rule "Pflanzenlicht nach Sonnenstand"
when
Channel 'astro:sun:local:daylight#event' triggered
then
Fritz_Steckdose_Garage.sendCommand(if(receivedEvent == 'START') ON else OFF)
end
Diese schaltet das Licht automatisch ein und aus.
Für die zweite Rule (Licht, falls Tür geöffnet wird) brauchen wir den Höhenwinkel (die Elevation) der Sonne, dazu muss der Channel
astro:sun:local:position#elevation mit einem Item des Typs Number:Angle verlinkt sein, nennen wir es der Einfachheit halber
SunPosElevation
Den Türkontakt legst Du am besten als Contact Item an. Je nachdem, was Du für einen Kontakt verwendest, musst Du evtl. den Wert für OPEN und CLOSED im Channel manuell angeben (also 1 und 0). Dann sähe eine passende Rule so aus:
Code: Alles auswählen
// globale Variablen vor der ersten Rule definieren!
var Timer tLichtGarage = null
ule "LichtGarage"
when
Item Garage_Tuer_Kontakt changed to OPEN
then
if((SunPosElevation.state as Number).floatValue > 0)
return;
Fritz_Steckdose_Garage.sendCommand(ON)
tLichtGarage?.cancel
tLichtGarage = createTimer(now.plusSeconds(30), [|
Fritz_Steckdose_Garage.sendCommand(OFF)
])
end
Punkt 1 wäre hier, dass Itemnamen keine Umlaute enthalten dürfen. Vermeide Teilstrings wie "Neu", denn irgendwann ist der Kontakt nicht mehr neu, sondern alt. Der nächste heißt dann am Ende NeuNeu oder Neu2... Nein, mach das nicht, nimm vernünftige Namen
State als Teilstring des Namens ist auch irgendwie doppelt gemoppelt, denn wenn Du den Status des Items abfragen willst, musst Du noch ein .state anhängen, das wäre dann ..._State.state, irgendwie nicht schön.
Punkt 2 ist die Logik. Die Rule wird ausgelöst. Sollte die Sonne über dem Horizont stehen (Elevation ist positiv), so darf nichts passieren, d.h. die Rule wird umgehend abgebrochen. Natürlich könne man auch umgekehrt arbeiten, aber diese Herangehensweise hat einen entscheidenden Vorteil (hier egal, aber aus Prinzip...), und das ist die Schachtelung von if-Statements. Wenn das if-Statement eine Abbruchbedingung ist, spart man sich die Schachtelung, da die Abarbeitung des Codes einfach beendet werden kann.
Punkt 3: Ich empfehle immer, nur die Methode für die Befehle zu verwenden. Es gibt nur eine Situation, wo man auf die Action zurückgreifen müssen könnte, und das ist, wenn man den Namen des Items "errechnet" hat, also nicht einfach so hinschreiben kann. Spoiler: es gibt immer eine Möglichkeit, auf die Action
sendCommand(<Itemname>,<Befehl>) zugunsten der Methode
Item.sendCommand(<Befehl>) zu verzichten, es kann nur "umständlich" sein.
Punkt 4: Das Lambda (der Ausdruck zwischen [ und ]) ist Teil des Funktionsaufrufs
createTimer(). Man
kann das Lambda auch getrennt nach dem Aufruf hinschreiben, es erscheint aber sinnvoller, das Lambda explizit als Parameter zu übergeben, denn so wird klar, dass dieser Codeteil ein Parameter der Funktion ist.
Punkt 5: Es mag pedantisch wirken, aber man sollte immer darauf achten, Timer exakt einmal laufen zu lassen.
Stell Dir vor, Du öffnest die Tür, schließt sie sofort wieder und öffnest sie nach 25 Sekunden erneut (z.B. kurz unterbrochen worden...). Ohne Timer Variable wird das Licht beim ersten Öffnen eingeschaltet und der Timer gestartet. Beim zweiten Öffnen wird das Licht nochmal eingeschaltet, allerdings bleibt das wirkungslos, da das Licht ja schon an ist. Dafür wird der Timer ein zweites Mal angelegt, aber nach 5 Sekunden schaltet der erste Timer das Licht aus. Da Du die Tür noch in der Hand hast, öffnest Du sie und das Licht geht wieder an, nur um wenige Sekunden später durch den zweiten Timer ausgeschaltet zu werden, und dieses Spielt wiederholt sich, bis Du mindestens eine halbe Minute wartest, um die Tür erneut zu öffnen...
Mit der Timer Variable ist es aber kein Problem, einen bereits existierenden Timer abzubrechen, bevor man ihn mit neuer Endezeit erneut anlegt.
openHAB5.0.1 stable in einem Debian-Container (trixie, OpenJDK 21 headless runtime) (Proxmox 9.0.11, LXC)
