Openhab 3 Astro Binding

[mj1234]

Hallo Zusammen,
ich habe Openhab 3 im Dockercontainer laufen um den Umstieg von dem Produktivsystem vorzubereiten.

Ich bekomme das Event Sunset nicht zum laufen. Ich habe verstanden, dass ich einem Event kein Item zuweisen kann.
Wie kann ich sehen wann das Event auslöst?

Meine Annahme ist:
Ich habe der Startzeit ein Item zugewiesen und der Sonnenuntergang wäre z.B. 17:30 Uhr.
Um zu testen habe ich dem Event ein Ofsset von 230 zugewiesen. Nun müsste das Event doch um 20:00 Uhr auslösen.
Tut es aber nicht.

Im event.log habe ich einmal einen Auslöser um 17:30 gesehen.

Mache ich einen Denkfehler?

Viele Grüße

Michael

[peter-pan]

Da es ein Event ist, ist der Auslöser dazu ein Trigger in einer Rule.
Eine Regel könnte so, oder so ähnlich aussehen(entsprechend deinem Thing):

Code: Alles auswählen

//===============================================================================
rule "Sunset_180 Start"
    when
            Channel 'astro:sun:stowing:set#event' triggered START
    then
        logInfo("astro-rules" + '_03', " Sunset_180 Start. START")
        //EG_gEG_Kind2_Licht.sendCommand(ON)
end
//===============================================================================

[udo1toni]

Mache ich einen Denkfehler?

Ja

Grundsätzlich liefert Astro viele verschiedene Daten, die Zeitpunkte eines Ereignisses z.B. über einen DateTime Channel. Dieser Channel wird einmal täglich einen neuen Wert erhalten (mutmaßlich kurz nach Mitternacht) und ansonsten allenfalls erneuert (Update), aber mit identischem Wert. Alle angegebenen Zeitpunkt, so sie sich auf täglich wiederkehrende Ereignisse beziehen, beziehen sich immer auf das aktuelle Datum, also z.B. Sonnenaufgang ist der vergangene von heute, nicht der kommende von morgen.

Diese Channel sind nur interessant, um den Zeitpunkt anzuzeigen ("Wann ist heute Sonnenuntergang?").

Die Range Event Channel hingegen senden einen Impuls, wenn der entsprechende Zeitpunkt erreicht ist. Da jedes Event einen Beginn und ein Ende hat, werden jeweils zwei Impulse gesendet, eben einmal START und einmal END. Dabei beziehen sich diese Zeitpunkte auf den Beginn bzw. das Ende des Transits der Sonne. Also z.B. bürgerliche Dämmerung: definiert als Transit der -6° Höhenlinie. Da die Sonne einen Durchmesser hat, gibt es den Zeitpunkt, bei dem sie beginnt, die Höhenlinie zu berühren, und einen Zeitpunkt, bei dem diese Berührung endet. Das Ereignis gibt es zweimal, einmal für Wechsel Tag->Nacht (Dusk), einmal für Wechsel Nacht->Tag (Dawn). Da wir hier aber ausschließlich von Impulsen (also Events) sprechen, hätte ein gekoppeltes Switch Item immer den Zustand OFF, es bekäme nur kurz den Impuls ON, hätte aber weiter den Zustand OFF. Man könnte dann diesen Impuls entweder mit received update oder received command auswerten, changed hingegen könnte man nicht nutzen. Um hier von vornherein diese Besonderheit zu kennzeichnen, kann man diese Channel erst gar nicht verlinken, sondern muss stattdessen direkt den Channel als Trigger verwenden.

peter-pan hat das ja schon in seinem Beispiel gezeigt. Das geht ohne Einschränkungen auch über die UI Rules.

Weiter kann man in jedem der Channel getrennt Unter- und Obergrenze sowie ein Offset definieren. So kann man z.B. die Rollläden bei Sonnenaufgang fahren lassen, aber frühestens um 6 Uhr, spätestens um 8:30 Uhr, und vielleicht doch lieber schon 10 Minuten vor Sonnenaufgang. ergibt dann earliest=6:00, latest=8:30,offset=-10.
Diese Werte kann man pro Channel einstellen und muss das auch tun. Stellt man also z.B. für den Event Range Channel Sonnenuntergang ein Offset ein, so wird exakt dieser Trigger entsprechend verfrüht (oder verspätet) auftauchen (Channel astro:sun:local:set triggered START), die Anzeige der Uhrzeit des Sonnenuntergangs wird aber nicht beeinflusst. Eventuell möchte man ja dennoch den "echten" Zeitpunkt angezeigt bekommen, auch wenn man den Trigger verschoben nutzt.

Da Astro vier verschiedene Zeitpunkte anbietet (Sonnenauf-/-untergang, Bürgerliche/Nautische/Astronomische Dämmerung mit Dusk/Dawn) kann man hervorragend sonnenstandsabhängig steuern. Sollte das dann immer noch nicht ausreichen kann man auch Azimut und Elevation direkt auswerten (die aber über Items).
Alle Werte werden abhängig von der gewählten Refreshrate neu berechnet, was sich aber nur bei wenigen Channels, wie z.B. Azimut und Elevation, direkt auswirkt, die meisten anderen Werte ändern sich nur einmal täglich (Schattenlängenverhältnis, Strahlungsintensität, Zeit bis zur nächsten Jahreszeit sowie die Sonnenphase ändern sich vermutlich ebenfalls bei jeder neuen Berechnung oder zumindest mehrfach täglich).

[mj1234]

Hallo,
ich danke für die Antworten.
Aber meine Frage ist nicht beantwortet.
Wenn ich in den lokalen Sonnendaten den Wert Sonnenuntergang um 18:32 sehe, sollte das Event "Range Event astro:sun:local:set#event" ohne Offset um 18:32 auslösen. Da ich meine Rule aber nicht nur einmal am Tag testen möchte/kann schreibe ich in den Channel "Range Event astro:sun:local:set#event" eine Verschiebeung Z.B. 120. Das bedeutet doch, dass das Event um 20:32 auslöst. Sollte ich mit meiner Annahme richtig liegen, löst meine Rule nicht aus. Ich habe einfach nur eine Lampe, die von der Rule eingeschaltet wird.
Hier meine Rule:

configuration: {}
triggers:
- id: "1"
configuration:
thingUID: astro:sun:local
channelUID: astro:sun:local:set#event
type: core.ChannelEventTrigger
conditions: []
actions:
- inputs: {}
id: "2"
configuration:
command: ON
itemName: ShellyTest_Schalter
type: core.ItemCommandAction


Viele Grüße

Michael

[udo1toni]

Wie ist das vollständige Thing konfiguriert? Konkret: auf welchem Wert steht der Aktualisierungsintervall?

Abgesehen davon bin ich mir nicht sicher, ob das ohne einen kompletten Neustart von openHAB funktionieren wird. Schließlich weiß das Binding, dass der Event Channel bereits ausgelöst hat. Dazu muss man wissen, dass es Extreme gibt, in denen bestimmte Ereignisse evtl. gar nicht auftreten. Eventuell merkt sich das Binding also intern, welches Ereignis am aktuellen Tag schon ausgelöst hat.

Über eine Rule kannst Du das korrekte Verhalten des channels ohnehin nicht prüfen, Du kannst höchstens mit einem Blick in das events.log prüfen:

Code: Alles auswählen

openhabian@openhab3:$ cat /var/log/openhab/events.log | grep Channel
2022-03-23 04:33:00.002 [INFO ] [openhab.event.ChannelTriggeredEvent ] - astro:sun:local:morningNight#event triggered END
2022-03-23 04:33:00.002 [INFO ] [openhab.event.ChannelTriggeredEvent ] - astro:sun:local:astroDawn#event triggered START
2022-03-23 05:13:00.001 [INFO ] [openhab.event.ChannelTriggeredEvent ] - astro:sun:local:nauticDawn#event triggered START
2022-03-23 05:13:00.001 [INFO ] [openhab.event.ChannelTriggeredEvent ] - astro:sun:local:astroDawn#event triggered END
2022-03-23 05:51:00.001 [INFO ] [openhab.event.ChannelTriggeredEvent ] - astro:sun:local:nauticDawn#event triggered END
2022-03-23 06:00:00.001 [INFO ] [openhab.event.ChannelTriggeredEvent ] - astro:sun:local:civilDawn#event triggered START
2022-03-23 06:18:00.001 [INFO ] [openhab.event.ChannelTriggeredEvent ] - astro:sun:local:civilDawn#event triggered END
2022-03-23 06:23:00.000 [INFO ] [openhab.event.ChannelTriggeredEvent ] - astro:sun:local:rise#event triggered START
2022-03-23 06:27:00.001 [INFO ] [openhab.event.ChannelTriggeredEvent ] - astro:sun:local:daylight#event triggered START
2022-03-23 06:27:00.001 [INFO ] [openhab.event.ChannelTriggeredEvent ] - astro:sun:local:rise#event triggered END
2022-03-23 08:46:00.001 [INFO ] [openhab.event.ChannelTriggeredEvent ] - astro:moon:local:set#event triggered END

[peter-pan]

Ich denke schon, dass wir deine Fragen richtig beantwortet haben. Aber das Verständnis für das Astro-Binding ist dir vielleicht noch nicht ganz klar. Deshalb empfehle ich dir diese Doku.

Es besteht ein grundsätzlicher Unterschied zwischen einem "normalen" Channel, der einen bestimmten Zeitpunkt anzeigt und einem Event-Channel, der eine bestimmte Aktion(event) auslöst. Das bezieht sich auch auf das Offset.

Hierzu vielleicht noch ein Thing-Beispiel aus meinem SetUp. Das ist allerdings in Textform, trägt aber vielleicht auch zum besseren Verständnis bei.

Code: Alles auswählen

//    Astro - Binding Geo-Position  geolocation="43.993444,6.456789,502"

// astronomische Jahreszeiten (Tag- und Nachtgleiche)
Thing astro:sun:local     "Sonnen Daten"                   [geolocation="43.993444,6.456789,502", interval=300]
Thing astro:moon:local    "Mond Daten"                     [geolocation="43.993444,6.456789,502", interval=300]
                                        
// Meteorologische Jahreszeiten
Thing astro:sun:localmet  "Sonnen Daten meteorologisch"    [geolocation="43.993444,6.456789,502", interval=300, useMeteorologicalSeason=true]
                                        
Thing astro:sun:stowing4   "Offset 50"                     [geolocation="43.993444,6.456789,502", interval=300]{
  Channels:
    Type rangeEvent : set#event [
      offset=50
    ]
    Type start : set#start [
      offset=50
    ]
    Type end : set#end [
      offset=50
    ]
    Type rangeEvent : astroDusk#event [
      offset=50
    ]
    Type rangeEvent : night#event [
      offset=50
    ]
    Type rangeEvent : noon#event [
      offset=50
    ]
    Type start : noon#start [
      offset=50
    ]
    Type start : noon#end [
      offset=50
    ]
     Type rangeEvent : rise#event [
      offset=50
    ]
    Type start : rise#start [
      offset=50
    ]
    Type end : rise#end [
      offset=50
    ]
}

Die ersten beiden Things (astro:sun:local und astrolocal) beschreiben sozusagen alle Channels zum exakten Zeipunkt.

Das dritte Thing bzw. die Channels hierzu orientieren sich bei der Datumsfindung an den meteorologischen Werten.

Die Channels des vierten Things habe ich mit "Offsets" belegt.

Hier siehst du noch einmal deutlich den Unterschied zwischen einem Datums-Offset und einem Event-Offset.
Das Datums-Offset(CHannel) ist lediglich für die Anzeige eines Wertes verantwortlich. Das Event-Offset(Channel) für die Ausführung einer Regel.

Edit: Sorry, Udo hat schon geantwortet.

[mj1234]

Hallo Zusammen,
danke für die Antworten.
Ich glaube Udo hat mit seiner Aussage recht, dass man das Event nicht diverse Male mit einem Offset starten kann.
Ich sehe bei mir in den Logfiles, dass die Events getriggert haben.

Ich hatte gehöfft, dass wenn ich den Offset immer höher setzte ich so meine Regelt testen kann.


Viele Grüße

Michael

[udo1toni]

Nein, die Regel kannst Du aber auf anderem Weg viel leichter testen, und zwar, indem Du einen weiteren Trigger ergänzt, z.B.

Code: Alles auswählen

or Item Testswitch received command

Nun kannst Du in der UI ein Item Testswitch konfigurieren, welches Du zum gezielten Auslösen der Rule verwenden kannst.

Alternativ kannst Du auch einfach die Rule von Hand starten, auch das geht in der UI - auch bei Rules, die über Textdateien im System konfiguriert sind, also über die UI mit einem Schloss dargestellt werden.