Antwort
Aug 19, 2017 - 13:56
Ich habe mit den Astro-Zeiten kein Problem (Standort Bochum). Ich habe mir am Anfang auch Mail's dazu schicken lassen, die schienen mir richtig zu sein.
Wenn ich das richtig sehe (https://api.sunrise-sunset.org/json?f...), müsste der Sonnenaufgang heute so gegen 05:45 gewesen sein.
Es kann aber nicht sein, das die Mail so lange braucht?
Wie ist denn die Systemzeit des Gateway?
Ein Auslesen der zugrundeliegenden Formel kenne ich nicht, das wird, soweit ich gelesen habe, berechnet (die Formeln sprengen aber meine mathematischen Möglichkeiten) .
Um die Astrozeiten auszugeben, siehe https://mediola.answerbase.com/2322226/Wie-kann-man-die-Sonnenaufgang-und-Sonne
nuntergang-Zeiten-darstellen.
Wenn ich das richtig sehe (https://api.sunrise-sunset.org/json?f...), müsste der Sonnenaufgang heute so gegen 05:45 gewesen sein.
Es kann aber nicht sein, das die Mail so lange braucht?
Wie ist denn die Systemzeit des Gateway?
Ein Auslesen der zugrundeliegenden Formel kenne ich nicht, das wird, soweit ich gelesen habe, berechnet (die Formeln sprengen aber meine mathematischen Möglichkeiten) .
Um die Astrozeiten auszugeben, siehe https://mediola.answerbase.com/2322226/Wie-kann-man-die-Sonnenaufgang-und-Sonne
nuntergang-Zeiten-darstellen.
Von
Vielen Dank, ich habe nun folgendes probiert...
Aus dem Beitrag "https://mediola.answerbase.com/2322226/Wie-kann-man-die-Sonnenaufgang-und-Sonnenuntergang-Zeiten-darstellen" habe ich sowohl das Skript basierend auf dem WebService "http://rolfrost.de/sunservice.html" und auch "https://sunrise-sunset.org/api" getestet - Danke für die Skriptbeispiele...
Die Variablen setze ich nun auch per Skript einmal am Tag. Nur wäre noch die große Preisfrage, wie ich das als "Event" hinbekomme, da ich z.B. eine Blockregel "Nach Sonnenaufgang Licht außen aus" gelöst habe - ähnliches auch abends.
Übrigens zu Deiner Frage: Server und Gateway zeigen mir eigentlich die korrekte Zeit an. Ich bin jedoch bei der Zeitzone und in Verbindung mit Sommerzeit=automatisch berechnen unsicher. Zuletzt hatte ich UTC+1 (Berlin, Madrid) und Sommerzeit=JA eingestellt. Zu den Astro-Webservices müssen 2h zugezählt werden. Nun ist die Frage, ob das mit der Sommerzeit funzt, da in der GUI "(Deutschland)" steht. Oder ob ich UTC+2 einstellen muss und Sommerzeit=NEIN!?
Weil gestern Abend/heute Morgen kamen meine "Sonnenauf-/Untergang-Mail" der Astrofunktion vom Gateway/Server ca. 1h zu spät... Nehme ich die 1h weg, kommt es in etwa mit den beiden anderen WebServices hin...
Von
zu der Frage, ob das richtig eingestellt ist: denke ich schon. Ich habe nachgeschaut Conil de la Frontera ist MEZ (UTC+1) bzw im Sommer MESZ (UTZ+2), also ganz wie bei uns.
Den Haken "Sommerzeit beziehen" habe ich drin und würde ich auch immer drin lassen; in Verbindung mit dem Zeitzonen-Server-Eintrag (NTP-Server = 0.pool.ntp.org ) in den Netzwerkeinstellung stimmt die Zeit immer.
Bei meinem Script (sunrise-sunset) sollte die lokale Zeit berücksichtigt werden - dieser Dienst liefert UTC, aber sollt eeingentlich stimmen.
Die Funktion 'dateObj.getTimezoneOffset()' sollte den richtigen Wert liefern.
var d = new Date();
console.log(d.getTimezoneOffset());
liefert bei mir '-120'.
zu der Frage, wie man diese Werte in den SOBALD-Block bekommt: gar nicht. Im SOBALD-Block können nur Ereignisse auftauchen (also Geräte, die was merken und das aktiv an den Gateway schicken) und nicht Zustände (also Variablen-Werte).
Man kann aber einen Task machen, der zyklisch abläuft (im SOBALD als "Intervall") oder zu einem bestimmten Zeitpunkt ("Zeit") und dann die Variable testet.
Wäre zwar irgendwie schöner, wenn man Variablen-Änderungen direkt mitbekommen würde, aber es ist mit Pollen lösbar.
Von
Vielen Dank, ja die SOBALD-Polling-Lösung habe ich schon befürchtet.
Der TimezoneOffset wird mir auch mit "-120" ausgegeben. Ich habe testweise heute auch wieder die Astro-Zeiten des Gateways/Servers per Mail checken lassen und habe wieder ca. 1h morgens und abends zu spät das Mail bekommen.
Die Timezone habe ich auf UTC+1 und wieder Sommerzeit=automatisch gesetzt und den ntp-server habe ich wie vorgeschlagen auf die IP von 0.pool.ntp.org gesetzt.
...ist echt komisch, die Standard-Astro-Funktion oder der Zeitoffset passt einfach nicht.
Aber nun nochmal zu dem Polling-Vorschlag: der Vergleich der Zeiten (Zeit im Bereich der Nacht) bekomme ich nur mit einem Skript hin, oder? Mit dem Blockeditor klappt das doch nicht oder habe ich noch eine Option nicht erfasst? Bedeutet ja eigentlich, dass ich dann 2 Polling-Blöcke benötige, oder? Einen zur Abfrage der "Nacht-Variable" und einen zum prüfen ob die Zeit erreicht ist und die Variable gesetzt werden muss - das aber über ein Skript...!?
Von
Tja, das sieht ja etwas vertrackt aus.
Grundsätzlich bräuchtest Du sinnvollerweise zwei Tasks, 0:00 den Abruf der akt. Astro-zeiten und dann 1/Minute den Check, ob der Zeitpunkt eingetroffen ist. Das muss Du auch mit einem Script machen, weil Du ja die in der Variablen genutzten Zeitpunkte mit dem aktuelle Zeitpunkt vergleichen musst (und das geht im Blockeditor nativ nicht).
Je nachdem, was Du mit den Astrozeiten resp. der gesetzten Variablen erreichen willst ... mir war seinerzeit die Astrozeit zum Schalten der Außenbeleuchtung nicht ausreichend, da die Zeitpunkte viel zur fürs (am Abend) bzw viel zu spät (am Morgen) war, um Aussenbeleuchtung zu schalten. Daher habe ich mir eine Bewegungssensor (HM-Sen-MDIR-O-2) beschafft (der Lichtsensor HM-Sen-LI-O wurde seinerzeit nicht unterstützt) und werte die Helligkeitswerte des Sensors aus (https://mediola.answerbase.com/2298919/HM-Sen-MDIR-O2-Nutzung-der-Helligkei-für-Aussenlicht).
Trotzdem finde ich das Verhalten merkwürdig und würde mich an Deiner Stelle mal an den Support schreiben (am besten mit Hinweis auf diesen Vorgang).
Was man noch machen könnte: um sicher zu sein, welche Zeitpunkte Für Sonnenauf- und -untergang dienten, könnte man bei zwei Task machen, die bei Eintritt des Zeitpunkts jeweils eine Variable mit dem akt. Zeitstempel versehen.
var d = new Date();
var s = d.toString();
if (d.getHours() < 12) {
executeDeviceCommand(
"HomeServer",
"astro_sunrise",
{"value":"setValue","ext":""},
function(err) {
err && console.error(err);
}
);
} else {
executeDeviceCommand(
"HomeServer",
"astro_sunset",
{"value":"setValue","ext":""},
function(err) {
err && console.error(err);
}
);
}
Die Zeiten müssten Du zwar von Hand noch auslesen, aber dann wäre es sicher, welche Zeitpunkte das System ermittelt hatte.
Bessern Vorschlag habe ich leider nicht.
Von
Danke! Ich fange die Zeiten nun morgens/abends in Variablen ein und stelle sie mir in der AIO Remote-Seite auch dar. Es bleibt dabei, dass etwa 2h jeweils Versatz sind. So als ob der Timezone-Offset doppelt eingerechnet wird.
Support-Ticket bei Mediola läuft... Feedback folgt, sobald es dazu etwas Neues gibt.
Von
...heute kam die Bestätigung vom Mediola-Support, dass es ein Bug ist und dieser mit dem nächsten Update behoben wird
Von
hört sich ja gut an, dann brauchst du nix drumherum zu bauen.
Von
Sooo, mit dem aktuellen Update wurde das Problem behoben. Die Astro-Zeiten für Auf- und Untergang werden nun passend zur Region berechnet.
Neuen Kommentar hinzufügen