Dämmerungsscript

[rmeyerz]

Hallo DocZoid,

ich habe mich gestern mal mit dem switch-Problem beschäftigt. Das Problem lag wohl in einer Winzigkeit begründet. Der Befehl prüft die übergebene Variable nach Mustern. Der Musterteil beginnt mit einer geöffneten geschweiften Klammer, allerdings mit einem Leerzeichen dazwischen. Und genau hier war keine Leerzeichen gesetzt. Was wohl zur Folge hatte, dass die Variable nicht übergeben werden konnte und der switch-Befehl nicht ausgeführt wurde.

Hier der entsprechene Programmteil:
ich habe zwischen "switch $aCurrent(condition)" und "{" einfach ein Leerzeichen gesetzt

Code: Alles auswählen

    puts "[clock format [clock seconds] -format "%H:%M:%S"]: current condition is \"$aCurrent(condition)\""
    file delete /tmp/twilightweather.xml
    switch $aCurrent(condition) {
      "Klar"                  {set twilightHorizon [expr {$base_horizon + 0.2}]}
      "Meist sonnig"      {set twilightHorizon [expr {$base_horizon + 1.5}]}
      "Teils sonnig"       {set twilightHorizon [expr {$base_horizon + 3.0}]}
    }
  }
  log "twilight horizon set to $twilightHorizon"

Was jetzt noch verbleibt, ist die Sache mit dem Systemprotokoll. Ich habe mal auf der Startseite rechts, die Variable "Dämmerungszeiten" anzeigen lassen wollen. Da es sich ja um eine Tabellenkonstruktion mit den ganzen Zahlen handelt, unterschied es sich von den anderen angezeigten Werten. Ich habe dabei beobachtet, dass sofort die Startoberfläche einfriert. Die CCU ist weiter ansprechbar, funktioniert einwandfrei. Allerdings werden auf der Startseite keine Informationen mehr aktualisiert, weder die Uhrzeit, noch die Zustände der geschalteten Geräte. Komisch ist dann aber, sobald ich auf eine andere Seite gehe und dann wieder auf die Startseit, so ist einmalig alles aktualisiert. Aber nur für den Moment. Es bleibt weiterhin alles einfroren bis zum Wechsel und Rückwechsel auf die Startseite.

[DocZoid]

Danke für den Tipp, kam gerade rechtzeitig. Ich hatte bereits angefangen eine neue Version zu bauen. Nach etwas refactoring habe ich bestimmt auch wieder neue Fehler eingebaut (jo, genau jetzt sehe ich schon einen: in der Dämmerungszeiten-Variablen werden momentan zwei Werte kursiv und keiner fett angezeigt), aber zumindest die Wetterberechnung läuft aktuell korrekt (Zumindest für den Sonnenuntergang, -aufgang noch nicht genau beobachtet). Version 1.4 findet sich im wiki...

Zum Aktualisierungsproblem: Ich habe in der neuen Version ein fehlendes </td>-Tag eingefügt, ich denke das war die Ursache. Ein erster Test scheint das zu bestätigen.

[rmeyerz]

Bezüglich der Problematik mit dem Einfrieren des Systemprotokolls habe ich folgendes geändert: Es steht jeweils ein "\n" vor/bzw. hinger den Anweisungen <table>. Wenn ich die herausnehme, funktioniert alles auch wieder. Allerdings wird auf der Startseite die Tabelle nicht mehr angezeigt. Hier wird kein Html Code mehr erkannt. Aber in der Auflistung der Systemvariablen ist die Tabelle korrekt angezeigt. Das von dir eingesetzte \td hat bei mir immer noch dazu geführt, dass das Systemprotokoll einfror.

Die Version 1.4 habe ich seit gestern abend drauf. Leider zeigte er mir heute Vormittag immer noch die Tageshelligkeit "5" sowie den Status "Aufgang Indoor" an. Ich habe mal nachgeschaut und festgestellt, wenn der tatsächliche Wetterabh. Sonnenaufgang erreicht wird, geht das Script in die Warteschleife bis zum vorübergehenden wetterabh. Sonnenuntergang. Das ist ja auch so gewollt. Aber weiter unten werden erst die neuen Zustände für die Variablen geändert. Dieser Teil wird aber jetzt nicht mehr erreicht, da ja gewartet wird. Ich habe einfach die entsprechenden 2 Zeilen eingefügt und es funktioniert dann. Hier der Code mit den 2 eingefügten Zeilen:

Code: Alles auswählen

 if {$current_tt == $SR_WEATHER && [clock seconds] < [lindex $twilight_times $SS_INDOOR]} then {
    log "current twilight state $current_tt ([lindex $twilight_types [expr {6-abs($current_tt-7)}]]), sunlight state [expr {6-abs($current_tt-6)}], waiting to retrieve weather data"

# ---------------------------------
# eingefügt, damit Variablen hier auch geändert werden für den Zustang wetterabhängiger Sonnenaufgang    
 rega_script "dom.GetObject('Dämmerung').State('$current_tt');"
    rega_script "dom.GetObject('Tageslicht').State('[expr {6-abs($current_tt-6)}]');"
# Ende Einfügung
# ------------------

waitToTime $next_time

Wenn der vorläufige wetterabh. Sonnenuntergang dann erreicht wird, berechnet das Script neu und die Schleife wird bis zum Ende abgearbeitet. Hier werden dann jetzt wohl nochmal die Variablen mit den Werten "6" und Sonnenaufgang wetterabh. gefüllt. Aber zu diesem Zeitpunkt wären das ja noch die richtigen Werte, bis zum erst noch kommenden tatsächlichen wetterabh. Sonenuntergang.

[DocZoid]

Ich hatte das gleiche Problem und hatte dann auch festgestellt, dass das Script zwar schon in dem korrekten Modus war, die Werte aber eben nicht an Homematic abgesetzt wurden. Ist in Version 1.4.1 behoben.

Grundsätzliche Frage: sollten die bisherigen Zustände beim Starten des Scripts (mitten im Tag, z.B. CCU-Reboot) im Schnelldurchgang geschaltet werden, oder nur (so wie jetzt) der aktuelle Zustand? Ich schalte zum Beispiel an einer Dämmerung das Licht ein, aber wenn diese Dämmerung vorbei ist und ich starte das Script fehlt der Einschalt-Impuls. Man könnte sich dann natürlich an den Tageslicht-Helligkeits-Wert hängen, aber der ist weit weniger intuitiv, und dann muss ich die morgendlichen Werte wieder ausklammern... Aber will man wirklich um 8 Uhr Abends die nautische Dämmerung schalten um direkt danach die bürgerliche und noch ein paar andere hinterher zu jagen? Das kann auch Fehlimpulse verursachen...

[rmeyerz]

Zur grundsätzlichen Frage: Ich könnte mir vorstellen, dass es im folgenden Fall problematisch sein könnte: Beregnungsanglage, die zur astronomischen Dämmerung ganz früh morgens für 2 Stunden angeht, weil noch keiner auf dem Rasen spielt. Wird dann die CCU neu gestartet und das Script liefert den Einschaltimpuls, dann geht das Ganze eventuell zu einer sehr unpassenden Zeit los.
Bei Licht eher unproblematisch, vielleicht sogar praktisch, wenn es auch nach reboot angeht. Aber alles eine Frage der Anwendung. Am besten wäre natürlich ein Script, dass bei Start per übergebenem zusätzlichem Wert auf beiderlei Arten gestartet werden kann. Also noch ein Wert zusätzlich zur PLZ und zum Indoorhorizont.
Das Ganze könnte man natürlich, wie du schon sagst, auch per Helligkeitswert steuern. So nach dem Prinzip, falls bei Neustart der Wert kleiner oder größer bspw. 4 ist. Allerdings gibt es hier keine Unterscheidung zwischen morgens und abends. Vielleicht ist es ja sinnvoll, noch eine Variable nach außen an die Homematic zu übergeben. Den Twilight-state, der ja Werte von 0 bis 12 annimmt und so eine eindeutige Zuordnung zur Tageszeit zuläßt.

[rmeyerz]

Hallo DocZoid,

bei mir läuft dein Script mittlerweile gut. Allerdings habe ich folgende Probleme:

1. Im Programmteil "displayValues" muss ich die beiden "\n" entfernen, sonst erhalte ich immer noch Abrüche bei der Systemprotokollierung. Bei Entfernung der "\n" tags läuft alles gut.

2. die Variable twilight_types wird ja in der Tabelle benötigt. Du verwendest sie dann auch in der log-Ausgabedatei als Dämmerungswerte in den Klammern. Das ganze funktioniert über eine mathematische Formel. Diese zeigt dann den 0. 1. 2. 3. 4. 5. 6. 5. 4. 3. 2. 1. 0. Wert an. Da es aber den 6. Wert nicht gibt (in der Liste wäre es der 7. Punkt) bleibt hier einmal der Ausdruck innerhalb der Klammer leer. Dies führt dann zu einer Verschiebung um 1. Also richtigerweise müssten die Werte 012345 543210 abgefragt werden. Ich für meinen Fall habe es mir einfach gemacht, und nicht nach einer neuen passenden Formel gesucht. Ich habe einfach eine neue Werteliste definiert, die genau diese Reihenfolge hat und sie dann einfach der Reihe nach abgefragt. Diese Problem ist natürlich rein kosmetischer Natur und hat für die Anwendung keine Auswirkungen.

3. am Ende prüft das Script das Vorhandensein eine PID-Datei

Code: Alles auswählen

if {[file exists /tmp/twilight.pid]} then {

und löscht diese dann, falls vorhanden und die PID`s identisch sind. Allerdings heißt die Datei, die sich im tmp-Verzeichniss befindet ja nicht twilight.pid sondern twilight.tcl.pid. Ändert man das Script hier, dann wird die Datei auch tatsächlich nach Ablauf gelöscht und dieser Programmteil erfüllt seine Funktion.
Hierzu fand ich es für mich persönlich praktisch, ganz am Ende zum Ablauf des Scriptes noch einen log Eintrag zu generieren, der mir sagt, ja das Sript hat tatsächlich die letzte Zeile erreicht und ist auch dadurch beendet.

4. und wichtigster Punkt: In einigen Tagen wird es im Bereich des 52. Breitengrades und 9. Längengrades zu der Situation kommen, dass die Astronomische Dämmerung erst nach Mitternacht erreicht wird. Das Script startet dann halt nochmal, ich glaube, das ist nicht weiter wild. Man kann das Script ja auch erst um 01.010 Uhr wieder starten lassen. Aber es wird noch schlimmer, ab dem 18. Mai wird es gar keinen Zeitpunkt mehr geben, an dem die Sonne tiefer als -18 Grad stehen wird. Ich habe mal den Wert in deinem Script auf -24 gesellt (weil ich nicht bis zum 18. warten wollte). Jetzt bekommt man eine Fehlermeldung und das Script stoppt anscheinend sofort, ohne weitere Werte im Tagesverlauf zu liefern. Also ab Mitte Mai wird dann das Script gar nicht mehr weiter laufen.

Hier der relevante Teil der Fehlermeldung:

Code: Alles auswählen

 
domain error: argument not in valid range
    while executing
"expr {12*acos((sin($horizon

Gruß von Rüdiger

[rmeyerz]

Hallo,

wie in meinem letztem Beitrag unter Punkt 4 angegeben, erhält man bei bestimmten Breitengraden ab einem bestimmten Datum eine Fehlermeldung. Das Script wird dadurch nicht mehr ausgeführt. Es liegt daran, dass der acosinus für einen Wert errechnet werden muss, der kleiner als -1 ist. Dies ist aber per Definition des acosinus nicht möglich. Daher die Fehlermeldung.
Ich habe aber eine Lösung für mich geschrieben und will sie hier kurz erläutern: Ich ersetze das Argument, das dem mathematischen Befehl acos übergeben wird durch eine neue Variable acosvar. Dies Variable fülle ich mit der ursprünglichen Berechnung und prüfe dann, ob die Variable kleiner als -1 ist. Wenn dies der Fall ist, ersetze ich den Wert durch -1. Jetzt wird also auf jeden Fall ein gültiger Wert für den acos Befehl zur Verfügung gestellt. Natürlich entspricht dann die Astronomische Dämmerung nicht dem tatsächlichen Wert, diesen gibt es ja (im Sommer) gar nicht (in bestimmten Breitengraden). Aber man erhält sozusagen den Wert, an dem die Sonne vom Winkel am niedrigsten steht. Diese Zeit ist dann für morgens und abends gleich. In meinem Fall liegt die Zeit bei ca. 01.18 Uhr.
Ich habe für die log-Datei noch einen Eintrag erzeugt, der angibt, ob der acos Wert auf -1 geändert wurde, oder aber den echten Wert anzeigt.
Ich hoffe hiermit geholfen zu haben:

Hier der geänderte Code für das Programm calcTwilightTimes innerhalb des Scriptes:

Code: Alles auswählen

proc calcTwilightTimes {latitude longitude timezone dayofyear horizon sunrisevar sunsetvar} {
  upvar $sunrisevar sunrise
  upvar $sunsetvar sunset
 
  set timediff [expr {-0.171*sin(0.0337 * $dayofyear + 0.465) - 0.1299*sin(0.01787 * $dayofyear - 0.168)}]
  set declination [expr {0.4095 * sin(0.016906 * ($dayofyear - 80.086) ) }]

      set acosvar [expr ((sin($horizon/57.29578) - sin($latitude/57.29578)*sin($declination)) / (cos($latitude/57.29578)*cos($declination)))]
      if {$acosvar <-1} {
      set acosvar -1
      log "Die Variable acosvar wurde auf -1 gesetzt, da ihr ursprünglicher Wert kleiner -1 war"
          }
if {$horizon == -18} {
log "Die Variable acosvar muss zwischen -1 und 1, liegen und ist momentan $acosvar"
                     }

  set suntime [expr {12*acos($acosvar)/3.141592}]
  set sunrise [expr {[clock scan "0"] + round((12 - $timediff - $suntime - $longitude/15.0 + $timezone)*3600)}]
  set sunset  [expr {[clock scan "0"] + round((12 - $timediff + $suntime - $longitude/15.0 + $timezone)*3600)}]
}

Gruß
Rüdiger

[rmeyerz]

Hallo,

mal eine Frage an die Twilight Nutzer:
Hat keiner von Euch Probleme mit dem Ursprungs-Script? Meiner Meinung nach dürfte bei einigen Nutzern das Ganze im Moment aufgrund der beschriebenen Problematik nicht laufen. Oder haben die Nutzer das Script entsprechend geändert.

@DocZoid: Wie hast du das Problem für dich gelöst? Es gibt ja noch keine neue Version für das twilight-Script auf den Wiki-Seiten.
Bei mir läuft alles zur Zeit sauber. Allerdings habe ich mich mit der fiktiven Zeit für den astronomischen Sonnenuntergang vertan. Diese ändert sich weiterhin aufgrund der unterschiedlichen Tageszahlen, die ja in die Berechnung einfließt. Also habe ich den Wert nicht auf -1, sonder auf einen kleineren Wert geändert, so daß sich eine kleine Lücke zwischen Sunset und Sunrise auftut.
Hier wäre es aber wahrscheinlich sinnvoller, einfach für diesen Fall feste Zeiten vorzugeben, die sich dann nicht mehr ändern.

Gruß
Rüdiger

[DocZoid]

Endlich eine neue Version!

Jetzt, wo der "Sommer" vorbei ist, gibt es endlich eine neue Version, welche die Proleme bei den Dämmerungsberechnungen im Sommer behebt! Naja, der nächste Sommer kommt bestimmt!
Ich habe schwer mit den Eigenarten der Berechnung zu kämpfen gehabt. Da manche Zeiten nach Mitternacht liegen können musste die die täglich Ausführung aufgeben und es auf dauerhaft laufend umschreiben. Hierzu musste ich dann die Debug-Ausgaben umstellen, so dass nicht der Speicher auf dem tmp-Verzeichnis zugemüllt wird. Das Script läuft seit Anfang August bei mir, scheinbar ohne Probleme. Fehlende nächtliche Dämmerungen und Uhrzeiten nach Mitternacht bringen es nun nicht mehr aus dem Tritt

Die neue Version ist im wiki hochgeladen. Bitte beachtet auch die Informationen auf der Seite zum Script (Aufruf nur noch einmalig!).

PS: Die Sourcen sind alles Andere als hübsch, ich bitte um Verzeihung, falls sich da jemand reinarbeiten will. Es wäre mal etwas Code-Beautifying nötig, wozu ich aber momentan keine Lust mehr habe (never touch a running system und so).

[EnergyStar]

Moin Doc,

ich habe gestern mal das Dämmerungsscript bei mir installiert. Dabei ist mir aufgefallen, dass der Befehl zum Dämonize nicht funktioniert, wenn man das LCD_msg-Addon nicht installiert hat. Und damit läuft das Script gar nicht. Beim Dämmerungsscript nutzt Du die Datei "daemonize.tcl" aus dem Verzeichnis "/www/addons/lcd_msg", was es beides ohne das LCD_msg-Addon nicht gibt.
Legt man aber das Verzeichnis an und spielt diese eine Datei aus dem LCD_msg-Addon von Hand ein, geht es.

Jetzt der eigentliche Punkt: Mir ist diese Abhängigkeit in der Doku nicht aufgefallen. Entweder fehlt sie, oder ich habe sie nur nicht gefunden...

Vielleicht kannst Du diese Info an eine leicht einsichtige Stelle im Wiki verschieben bzw. nachpflegen. Danke.

Gruß
EnergyStar