Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄

[Segway]

@gst666 sagte in Erwartete Tageshelligkeit (Dauer) berechnen:

Die Resthelligkeit ist auch stark vom Wetter abhängig.

Einfach einen Helligkeitssensor installieren :-) und abfragen

[Mic]

Hi Rainer,

aber geben denn dies nicht die Astrozeiten genau wider -- nämlich unberücksichtigt Wolken etc.?

Ich habe einen ähnlichen Wunsch bekommen :relaxed: -- allerdings für das Wohnlicht sobald es dunkler wird, bei mir bisher gekoppelt an Astro (goldene Stunde) mit einem Offset. Hier wird dann z.B. das Wohnlicht, falls es an ist, auf ein wärmeres Licht geschaltet.

/**
 * Ändert Wohnlicht-Szene auf Entspannen ab goldener Stunde + 30 Minuten
 * Allerdings nur, wenn Licht auch an ist.
 */
schedule({astro: "goldenHour", shift: 30}, function () {
   var isOn = getState('shelly.0.SHSW-1#XXXXX#1.Relay0.Switch').val;
    if (isOn) {
        setState('javascript.0.mic.Lichtsteuerung.Scene_Wohnlicht', 'Entspannen');
        g_Log("Astro: Wohnlicht auf 'Entspannen' geändert.");
    }
});

Ein ähnliches Script schaltet so auch bei Anwesenheit Lichter an je nach Astro.

Also ich wüsste jetzt nicht, wie man das praktikabel berechnen könnte: Angekommen es schieben sich grad dunkle Regenwolken rein, dann wird es ja deutlich dunkler zur selben Zeit, als wenn nur ein paar Wolken vorhanden sind. Dann möchte sicherlich die Holde, dass schon früher was passiert. Hab auch schon überlegt, hierfür einen Xiaomi-Bewegungssensor zu nehmen, der ja die Lux misst (muss noch testen wie zuverlässig).
D.h. z.B. ab Astro-Zeit "Goldene Stunde" (+/- Offset) soll die Helligkeit jede X. Minute geprüft werden und wenn unter Wert Y Lux, und falls wer anwesend, dann mach was.

Grüße
Mic

[dondaik]

"..Dauer der Resthelligkeit vorherzusehen... " - das wäre ganz grosses kino !
einfach vernünfige helligkeitssensoren benutzen die tun was sie sollen und eine gute auflösung haben!
wenn dann noch den mittelwert von mehreren positionen ums haus bilden, wenn man mag, und alles wird gut.
ja, läuft hier mit dem licht so und es gab für keinen raum eine WAF-beschwerde... :-)... und zu zeiten von r-läden auch nicht....
schönen fasching

[lesiflo]

@Segway said in Erwartete Tageshelligkeit (Dauer) berechnen:

@gst666 sagte in Erwartete Tageshelligkeit (Dauer) berechnen:

Die Resthelligkeit ist auch stark vom Wetter abhängig.

Einfach einen Helligkeitssensor installieren :-) und abfragen

Genau, alles andere macht meiner Meinung nach auf Grund von Wolken, Wetter etc keinen Sinn. Ich habe schon seit langen davon zwei in Betrieb und steuere damit meine Rollläden auch in der Dämmerung ohne Probleme. Warum also berechnen? Der Sinn erschließt mir nicht so ganz. Außer als Fallbacklösung falls der Sensor mal defekt ist.

[Homoran]

@lesiflo sagte in Erwartete Tageshelligkeit (Dauer) berechnen:

Warum also berechnen?

Weil es mich reizt!

@lesiflo sagte in Erwartete Tageshelligkeit (Dauer) berechnen:

auf Grund von Wolken

Das ist klar, hatte ich im Eröffnungsthread ja auch außen vorlassen wollen.
Mir ging es ausschließlich um die technische Möglichkeit.

Und ja, den Helligkeitssensor habe ich mir inzwischen gekauft, weil ich es nicht hinbekomme.
Aber es muss da doch auch einen astronomischen Zusammenhang geben.

[dondaik]

@Homoran

astronomischen Zusammenhang hat aber einen örtlich bedingten rundungsfehler ... :-) ...
und dieser wird dann durch den hellgkeitsenor bestimmt :-) :-)

[Homoran]

@dondaik

Die Rundung ist nicht mein Problem.
Es kommt nicht auf die Sekunde oder Minute an.
Nur zwischen Sommer und Winter liegt der Unterschied irgendwo zwischen einer halben bis zu einer Stunde

[dondaik]

@Homoran
sagen wir das das die benutzen rechenwege sind ... ähnliches war auch irgendwo zu lesen beim thema sonnenaufgang / untergang

[Segway]

@dondaik & @Homoran

Ich glaube die Grafik von HIER beschreibt das verhalten ganz gut und ist meiner Meinung nach recht genau (siehe auch Erklärung unter Genauigkeit auf seiner Page)

[Homoran]

@Segway
Das ist der idealisierte Verlauf an einem Tag

Ich muss in Kassel mal mit Eugen reden, wie sich diese Kurve im Verlauf des Jahres verändert

[Segway]

@Homoran
Ich hatte es so verstanden, dass es für jeden Tag bzw. für jedes Mal wann das Skript läuft die entsprechenden Variablen neu berechnet. Er braucht ja den Breitgrad und kann sich darüber die Elevation sowie Azimut ausrechnen.

[Homoran]

@Segway
Genau

und daraus müsste man jetzt eine dreidimensionale Grafik über das Jahr machen ;-) und dann aus der Kurve die sich aus der dritten Dimension ergibt eine Formel berechnen.

Wobei:
Solange die Dämmerung NUR aufgrund des Sonnenstandes definiert ist und nichts über die Lichtverhältnisse aussagt hilft das auch nicht :(

[Segway]

@Homoran sagte in Erwartete Tageshelligkeit (Dauer) berechnen:

und daraus müsste man jetzt eine dreidimensionale Grafik über das Jahr machen und dann aus der Kurve die sich aus der dritten Dimension ergibt eine Formel berechnen.

MatLab kann da bestimmt was draus machen :-)

@Homoran sagte in Erwartete Tageshelligkeit (Dauer) berechnen:

Solange die Dämmerung NUR aufgrund des Sonnenstandes definiert ist und nichts über die Lichtverhältnisse aussagt hilft das auch nicht

Das Problem wird immer bleiben, wüsste auch nicht wie man das weg kriegen sollte, da ja Nebel, Dunst, Schleierwolken usw. die Lichtintensität beeinflussen. Ich wüsst jetzt nicht wie man das "errechnen" sollte sondern das geht nur durch messen.

[Homoran]

@Segway sagte in Erwartete Tageshelligkeit (Dauer) berechnen:

da ja Nebel, Dunst, Schleierwolken usw

Das will ich ja erst einmal unberücksichtigt lassen und nur von Idealbedingungen ausgehen.

@Segway sagte in Erwartete Tageshelligkeit (Dauer) berechnen:

Ich wüsst jetzt nicht wie man das "errechnen" sollte sondern das geht nur durch messen.

und das weiß ich eben auch nicht, da muss es aber was geben.
Die Beobachtung, dass es im Sommer nach Sonnenuntergang länger hell ist als im Winter bilde ich mir (hoffentlich) nicht ein ;-)

[Segway]

@Homoran sagte in Erwartete Tageshelligkeit (Dauer) berechnen:

im Sommer nach Sonnenuntergang länger hell ist als im Winter bilde ich mir (hoffentlich) nicht ein

Ne, tust du nicht. Bilde mir das auch ein. Wenn ich jetzt gerade rausschaue kann ich eigentlich schon Licht anmachen und Rollos runter machen obwohl mein Script erst 18:10 sagt

[gst666]

Also ich vermute, dass hat etwas mit der Dämmerung zu tun. Wie dem auch sei, hier ein Lösungsvorschlag:

var sommer=30;  //Korrektur in Min
var winter=-30; //Korrektur in Min

console.log(correctSunset(new Date(),sommer, winter));


function correctSunset(iDateTime,iCorrectSunsetSummer,iCorrectSunsetWinter) {
    var month = iDateTime.getMonth();
    console.log(month);
    var diffSummerWinter = iCorrectSunsetSummer-iCorrectSunsetWinter;
    if (month<=6) {
        var corr = iCorrectSunsetWinter+(diffSummerWinter/5)*(month);
    } else {
        var corr = iCorrectSunsetSummer-(diffSummerWinter/5)*(month-6);
    }
    return(corr);
}

Ist zwar nur eine empirische Lösung. Sollte das Problem aber wohl lösen. Wem der Korreturwert noch zu grob ist, kann statt mit Monaten mit Tagen rechnen.

[Homoran]

@gst666 sagte in Erwartete Tageshelligkeit (Dauer) berechnen:

Ist zwar nur eine empirische Lösung.

So in der Art hätte ich es sonst auch gelöst.

Wird also erst nächstes Jahr etwas.
In der Zwischenzeit sammle ich mal BigData und sehe ob sich daraus eine Formel generieren lässt. ;-)

EDIT:
Und am ersten Schritt scheitere ich bereits.

Ich will den Zeitpunkt, wenn es dunkel wird (ja! Mit dem Helligkeitssensor!) loggen und habe dazu folgendes Blockly zusammengeschoben (noch ohne den debug-Baustein):

Die Sperrvariable "erstmal(ig)" sollte dafür sorgen, dass diese Zeitangabe nicht bei jeder Änderung <Minimalhelligkeit wieder überschrieben wird.

Leider stand heute Morgen eine Zeit kurz vor 7:00 in dem Datenpunkt.
Zu dieser Zeit überschritt die Helligkeit den Wert von 4

Nach meinem Verständnis hätte nichts passieren dürfen, da die Sperrvariable noch auf true hätte stehen müssen.

Wo ist mein Denkfehler?

Danke
Rainer

[Mihaeru]

Äm .. ich habe echt keine Ahnung von Blockly und gehe mal davon aus, dass es so einfach nicht sein wird aber trotzdem frage ich mal, ob das hier nicht bei jeder Änderung die Variable einmalig wieder auf false setzt:

Die Thematik interessiert mich ebenfalls für eine Anwesenheitssimulation. Insbesondere abhängig von der Bewölkung passen die Astro-Zeiten oft nicht.

[Homoran]

@Mihaeru
genau das tat es - in einer Schleife, so dass jede zweite Änderung wieder gewertet wurde.

Ich hatte das inzwischen selbst bemerkt und geändert.

Danke

[cash]

Für mich ist die bürgerliche Dämmerung ein sehr guter Richtwert. Diese ist je nach Jahreszeit Abends 25-40 Minuten nach Sonnenuntergang. Für meine Ambiente Beleuchtung nutze ich das schon Jahre. Jeweils noch mit einer kleinen Zusatzzeit und dann natürlich auch mim min und max Schaltzeiten. Sprich wenn Dämmerung nach 21:00 Uhr dann mach das Licht garnicht an oder so.

Wenn man nun noch den Adapter Das Wetter benutzt könnte man ja nochmals einen Aufschlag oder Abschlag berechnen und wäre schon relativ nah dran.

Im Winter ist die bürgerliche Dämmerung aber wie schon geschrieben meist ganz gut da die Tage ohne Wolken sehr selten sind....