Bei Abfrage in Rule DSL Variable nicht vorhanden

[Proton]

Hallo zusammen,
ich möchte bei dem "But only if" als Skript ein Rule DSL ausführen um zu überprüfen ob es nach Sonnenuntergang und vor Sonnenaufgang ist.
Dafür habe ich folgendes gefunden:

Code: Alles auswählen

now.isAfter((Sunset.state as DateTimeType).zonedDateTime) || now.isBefore((Sunrise.state as DateTimeType).zonedDateTime)

Dabei scheint er die Variable "now" nicht zu kennen.
Bei einer Ausgabe von

Code: Alles auswählen

logInfo("1", now)
// bzw.
logInfo("2", now())

wird ebenfalls ein Fehler geworfen, was mich zu der Annahme bringt.
Jetzt die Frage:
Was muss ich machen, damit die Variable bekannt ist?

Schönen Gruß

[udo1toni]

But only if kann keine Scripte ausführen, man kann dort lediglich Bedingungen setzen, die auf Itemzustände zurückgehen.

Der Punkt ist: Rules sind eventbasiert, ein Ereignis löst den Start einer Rule aus. Man kann beliebig viele Trigger angeben, aber eben keine Bedingungen festlegen, die unabhängig von dem Ereignis noch erfüllt sein müssen. deshalb wurde das But only if eingebaut.

Wenn man ein Script schreibt, so ist es kein Problem, eine entsprechende Abbruchbedingung als erstes im Code unterzubringen.

Du möchtest die Rule zwischen Sonnenuntergang und Sonnenaufgang ausführen lassen (from Dusk til Dawn) das geht in dieser Form nicht.
Die einfachste Variante ist, ein Hilfsitem isNight einzuführen. Du legst zwei Rules an, die jeweils bei Sonnenaufgang und Sonnenuntergang ausgelöst werden (Channel 'astro:sun:local:set#event' triggered START bzw. Channel 'astro:sun:localrise#event' triggered START).
Die beiden Rules machen nichts anderes, als das Hilfsitem isNight ein- bzw. auszuschalten - isnight.postUpdate(ON/OFF)

Nun kannst Du bei But only if einfach isNight.state == ON eintragen und gut ist.

[Proton]

Vielen Dank für die schnell und sehr kompetente Antwort.
Mein jetziges Problem ist der Trigger für die Rules.
Ich habe die lokalen Sonnendaten als non-semantic ins Modell eingebunden und dann beim Erstellen des Triggers ausgewählt und bin davon ausgegangen, dass es den State "START" gibt, aber es gab nur die folgenden
Zudem habe ich das isNight-Item als Switch angelegt, ist das richtig?

Btw großartiger Film bis Quentin die Regie abgibt

[udo1toni]

isNight wäre sinnvoll als Switch, ja.

Was die Trigger für die Rules betrifft, so habe ich diese exakt hingeschrieben (allerdings aus dem Kopf...)
Der Punkt ist: Du brauchst gar kein Item dafür (wobei es ab openHAB3.4 auch einen Trigger Time is gibt, mit dem Du Items verwenden kannst, aber der Reihe nach:

Das Astro Binding stellt verschiedene täglich auftretende Ereignisse zur Verfügung, unter anderem die, welche hier interessant sind.

rise, set: Sonnenauf-/-untergang, genauer: die Sonne passiert die 0° Höhenlinie.
civilDawn, civilDusk: bürgerliche Dämmerung (Auf- und Untergang), genauer: die Sonne passiert die -6° Höhenlinie.
nauticDawn, nauticDusk: nautische Dämmerung (Auf- und Untergang), genauer: die Sonne passiert die -12° Höhenlinie.
astroDawn, astroDusk: astronomische Dämmerung (Auf- und Untergang), genauer: die Sonne passiert die -18° Höhenlinie.

Da die jeweilige Höhenlinie auf der seinen Seite ein unendlich dünner Strich ist, auf der anderen Seite die Sonne aber kein Punkt, sondern ein Kreis, gibt es für die Passage jeweils zwei interessante Zeitpunkte, nämlich Beginn (Sonne berührt die Höhenlinie) und Ende (Sonne löst sich von der Höhenlinie).
Entsprechend gibt es vier Channel für jedes dieser Ereignisse, start, end, duration und event.
Start und End sind vom Typ DateTime. Sie werden um 0:00 Uhr für den aktuellen Tag berechnet (nun ja, eigentlich alle paar Minuten, aber das Ergebnis der Berechnung ändert sich nur um 0:00 Uhr). Die Duration gibt die Zeitspanne zwischen Start und End an, in Minuten. Diese drei Channel sind vor allem interessant, um den Zeitpunkt anzuzeigen oder damit Berechnungen anzustellen (Rechnen mit DateTime ist eklig, lässt man am besten, wenn es nicht unbedingt sein muss...)
der event Channel ist vom Typ RangeEvent und kann überhaupt nicht mit einem Item verlinkt werden. Er triggert genau in dem Moment, der errechnet wurde, und zwar zu Beginn mit dem Event START und zum Ende mit dem Event END.

Die Rules triggern also auf gar kein Item, sondern auf exakt die angegebenen Channel. Natürlich ist es möglich, dass Dein Thing nicht local heißt, das wäre aber der einzig variable Teil im Channelnamen, alles andere ist fix.

Ich habe ja oben erwähnt, dass es mit openHAB3.4 auch noch eine andere Variante gibt, das ist, den Trigger Time is <Item> zu verwenden. Das verwendete Item muss dann vom Typ DateTime sein. Die Rule wird ausgelöst, wenn der im Item gespeicherte Zeitpunkt erreicht wird.
Das ist vielleicht für den Einen oder Anderen besser zu verstehen, aus Softwaresicht ist der Channel Trigger eleganter, weil kein extra Scheduler gebraucht wird. Time is wird bei jedem changed Event für das gewählte Item intern eine Berechnung vornehmen und im Scheduler einen Eintrag anlegen, der dann die Rule zum berechneten Zeitpunkt auslöst - beim Channel-Trigger wird einfach auf den Bus gestarrt und auf das Event gewartet, das gibt es ohnehin.

Time is ist aber natürlich ein legitimer Weg, auch im Zusammenhang mit Astro, nur halt nicht der "übliche" Weg.

[Proton]

Vielen Dank für die ausführliche und überaus erhellende Antwort.
Gestern hatte ich leider keine Zeit zu testen und heute hat der Wechsel des Item-Zustands wunderbar funktioniert.
Leider bin ich etwas verwirrt, weil ich dachte, dass die Channels von Things immer mit Items verbunden werden. So hatte ich das jedenfalls in der Doku verstanden.
Mein Verständnis ist aber nicht so wichtig. Wichtiger wäre mir, zu erfahren, ob man ein Trigger-Event für das unterschreiten eines Sensor-Wertes auch in der UI erstellen kann oder ob man dafür eine Rule-Datei erstellen muss.

Vielen Dank und schönen Gruß

[udo1toni]

Es gibt halt zwei Channeltypen (darauf bezogen...), die Einen stellen einen Wert zur Verfügung (der kann in einem Item abgespeichert werden). Die Anderen stellen nur einen Trigger zur Verfügung. Ein Trigger kann nicht gespeichert werden (bzw. es erscheint sinnlos, denn der Wert ist IMMER inaktiv. Nut im exakten Moment des Triggers wird der Zustand für (theoretisch) den Bruchteil einer Millisekunde geändert und springt direkt wieder auf inaktiv.
Dieses Problem fiel schon in openHAB1 auf und wurde deshalb mit openHAB2 etwas verschoben. Ich denke, man wird diese Information auch in der Doku finden (wenn man intensiv genug danach forscht...), aber eigentlich lohnt der Aufwand nicht
Das Unterschreiten eines Sensorwertes ist aber wiederum KEIN Trigger
Die vollständige Lsite der möglichen Trigger ist in der Doku gelistet, wobei ganz wichtig ist, den Unterschied zwischen Thing und Channel nicht zu verwischen - das Thing ist die Entsprechung einer kompletten Hardware - Events (oder Ereignisse... Trigger...) beziehen sich auf das Element in der Liste - ist das Thing online oder offline, wird es gerade initialisiert usw. - während der Channel die Entsprechung tatsächlicher Daten ist, hier kann es also ein Update oder eine Änderung geben (beides wird dann an das verlinkte Item weitergegeben und dort als Event verzeichnet), oder es gibt eben ein Trigger eines Event Channels - neben den Event Channels bei Astro wären z.B. Tasten Channels verschiedener Systeme ein typisches Beispielk für einen Trigger - man könnte einen SHORT_PRESS, ein LONG_SRESS, ein DOUBLE_CLICK oder gar TRIPPLE_CLICK oder auch ein RELEASE als Ereignis erfassen. typisch ist eine Taste (im Gegensatz zu einem Schalter) aber immer losgelassen, weshalb es meist nicht lohnt, das als Item abzubilden.

[Proton]

Es gibt halt zwei Channeltypen (darauf bezogen...), die Einen stellen einen Wert zur Verfügung (der kann in einem Item abgespeichert werden). Die Anderen stellen nur einen Trigger zur Verfügung. Ein Trigger kann nicht gespeichert werden (bzw. es erscheint sinnlos, denn der Wert ist IMMER inaktiv. Nut im exakten Moment des Triggers wird der Zustand für (theoretisch) den Bruchteil einer Millisekunde geändert und springt direkt wieder auf inaktiv.
[...] Das Unterschreiten eines Sensorwertes ist aber wiederum KEIN Trigger

Okay, so wie ich das jetzt verstanden habe, müsste ich also mit dem Event "Messung der Helligkeit" die Regel auslösen und dann schauen, ob der Wert meinen Grenzwert unterschreitet, korrekt?

[...] den Unterschied zwischen Thing und Channel nicht zu verwischen - das Thing ist die Entsprechung einer kompletten Hardware - Events (oder Ereignisse... Trigger...) beziehen sich auf das Element in der Liste - ist das Thing online oder offline, wird es gerade initialisiert usw. - während der Channel die Entsprechung tatsächlicher Daten ist, hier kann es also ein Update oder eine Änderung geben (beides wird dann an das verlinkte Item weitergegeben und dort als Event verzeichnet), oder es gibt eben ein Trigger eines Event Channels [...]

Es werden also nur Werte/Änderungen in Items gespeichert. Events/Trigger können nicht gespeichert werden und sind daher direkt über Channel abrufbar.
Wobei Events und Trigger synonym sind, oder nicht?

[udo1toni]

Okay, so wie ich das jetzt verstanden habe, müsste ich also mit dem Event "Messung der Helligkeit" die Regel auslösen und dann schauen, ob der Wert meinen Grenzwert unterschreitet, korrekt?

Es gibt kein Event "Messung der Helligkeit"

Wenn Du einen Helligkeitssensor hast, kannst Du diesen über ein Thing in openHAB einbinden (wenn er unterstützt wird). Und dieses Thing wird dann einen Channel für die gemessene Helligkeit haben.
Diesen Channel (der wird vom Typ Number sein) verlinkst Du mit einem Number Item.
Das Item bekommt bei jedem Update, welches im channel aufschlägt ebenfalls ein Update seines Status.
Jedes Mal, wenn ein Itemstatus upgedatet wird, gibt es ein StatusUpdate Event für dieses Item.
Falls sich bei diesem Update der Status geändert hat, gibt es in der Folge ein StatusChanged Event für dieses Item.

Eine Rule kannst Du gezielt auf beide Events triggern lassen. Der Trigger heißt dann für das Update received update und für das Changed Event einfach changed.
Ob der Wert im Status des Items einen bestimmten Grenzwert unterschreitet, musst Du dann in der Tat innerhalb der Rule prüfen (es gibt in der UI auch noch den "But Only If" Teil, dort könntest Du auch einen Grenzwert eintragen, der unter- (oder über-) schritten werden muss, damit die Rule etwas tut.

Es werden also nur Werte/Änderungen in Items gespeichert. Events/Trigger können nicht gespeichert werden und sind daher direkt über Channel abrufbar.

Richtig, ein Item kann nur den Status speichern. Wenn ein Channel einen immer identischen Ruhezustand hat, und diesen nur kurzfristig (meinetwegen eine Millisekunde) ändert, dann wird dieser Channel gewöhnlich als reiner Trigger Channel zur Verfügung stehen und man kann kein Item mit ihm verknüpfen, einfach, weil dieses Item dann ja ebenfalls immer den gleichen Zustand hätte, bis auf die eine Millisekunde, in der der Channel triggert.
Man kann solche Channel aber eventuell dennoch mit einem Item verlinken (nämlich mit einem DateTime Item), unter Nutzung der Timestamp Profiles (oder so ähnlich). Im Item wird dann immer der letzte Zeitpunkt gespeichert, an dem der Channel getriggert hat.

Wobei Events und Trigger synonym sind, oder nicht?

Jein. Ein Event ist ein Ereignis. Ein Trigger ist die Definition, auf welches Ereignis eine Rule reagieren soll. Die Rule wird durch das Event getriggert.
Ja, die Begriffe sind dicht beieinander, aber es sind unterschiedliche Dinge damit gemeint.

[Proton]

Und wieder vielen Dank!
Durch diese Info und die Hilfsvariable, wird jetzt erkannt, wenn es "Nacht" ist und im Raum dunkel genug, um die Rollladen runterzufahren.
Der Wert des Helligkeitssensors wird alle 30 Sekunden geupdated und dann hört man alle 30 Sekunden die Relays für die Rollladen schalten.
Das ist natürlich suboptimal. Was wäre eine bessere Herangehensweise?
Wir entfernen uns ja immer mehr vom ursprünglichen Thema. Soll ich vielleicht besser einen neuen Thread aufmachen?
Schönen Gruß

[udo1toni]

Hast Du eine Rule, die Du zeigen kannst?

Im Zweifel musst Du halt prüfen, ob ein Laden bereits geschlossen ist, bevor Du den Befehl zum Schließen schickst.

Was das Thema betrifft, so kannst Du das halten wie ein Dachdecker allerdings ist dann ein Link zum neuen Thema sinnvoll, und genauso in der Gegenrichtung.
Die Themen driften hier gerne etwas ab, wenn es zu arg wird, wird eine Moderator das Thema notfalls splitten