[Twilight] - Licht geht zu früh abends an - Erklärung und Tuning Horizont

[CoolTux]

Twilight _weather wird in Abhängigkeit des Conditioncodes ermittelt. Es sollte also erstmal festgestellt werden ob die API von Openweather soetwas in der Art liefert.

[frank]

1. vorhersagen sind sowieso (meistens) ungenau/schlecht. das wird sich beim bedeckungsgrad sicherlich nicht grossartig durch andere, kostenlose anbieter ändern.
2. kostenlose vorhersagen werden meistens nur 2-4 mal am tag neu berechnet/aktualisiert. je weiter man von diesen zeitpunkten entfernt ist, desto ungenauer. eine stundengenaue darstellung ändert daran auch nichts.
3. je näher der standort an einem flughafen (messstelle für vorhersageberechnung) liegt, desto genauer wird die vorhersage sein.
4. schnell veränderliche wetterlagen machen die vorhersage sicherlich nicht einfacher.

alles in allem ist ein eigener lichtsensor die beste und wahrscheinlich einzige lösung.

[herrmannj]

ich habe ein solches modul seit geraumer Zeit im Test. Ohne den Thread sprengen zu wollen hier lessons learned:

Wetter:
Nicht so das Problem. METAR Wetter bekommt man kostenlos, das wird im 30Min Takt aktualisiert. Dort bezieht man keine Vorhersage sondern aktuelle Beobachtungen (des nächstgelegenen Flughafens).

Die Bewölkung wird sehr differenziert gemeldet (bis zu 3 Schichten, Bedeckung, vereinfacht, in x/4, Wolkentypen ergänzt zb SCT oder Cumuls (wenn), Nebel, Regen, Sichtweite +).

Dabei tritt folgendes auf: Bedeckung 1/8 sagt erst einmal nichts darüber aus ob ganz viele Wolken mit einem Meter Kantenlänge und sieben Metern Abstand am Himmel sind oder ob es sich um eine Wolke von 10km in einem 80km großen Gebiet handelt. Wenn die über Deinem Haus steht hast Du Overcast - auch bei 1/8 Bedeckung.

Die Bedeckung das per se wenig darüber aus wie viel Tageslicht das kostet. Bedeckung 4/8 mit dicken Regenwolken oder 4/8 mit leichten Federwolken fühlt sich vom Boden aus komplett anders an    Von daher kann man tatsächlich nur möglichst intelligentes Raten machen. Im Augenblick experimentiere ich mit der Einbeziehung von Luftdruck. Bei Tiefdruck sind die Wolken idr dicker, bei Hochdruck idr leichter, dünner.

Es ist und bleibt aber ein raten, mal liegen die Werte drüber, mal drunter.

vg
joerg 

[immigrantsong]

Der Ansatz hört sich trotzdem gut an. Bin gerne bereit zu unterstützen.

Die zweite Option wäre WUnderground, dass auf Weather Underground aufsetzt. Die Sichtweite ist übrigens noch ein Faktor, den man berücksichtigen kann um die Wolkendichte zu bewerten.

[immigrantsong]

Ich habe inzwischen auf Weather Underground gestellt und nutze eine dortige Station in der Nähe mit Solar Radiation-Daten.

Funzt so wie ich wollte.

[Zeitisen]

Wann wird denn eigentlich das Wetter abgefragt? Kann man Zeitpunkt und Häufigkeit beeinflussen?
Heute früh kam die Abfrage um 7.36. Da war durch die Korrektur der Zeitpunkt für "Fensterladen auf " schon vorbei.
Zuvor war im log immer nur "Original weather readings" zu sehen

[Dietmar63]

eine Stunde vor dem eigentlichem Sonnenaufgang.
kann man nicht verändern.

[Zeitisen]

Das ist aber doch nicht  richtig. Ich muss doch spätestens bevor twilight_weather > 0 werden kann ( elevation = - 12), das aktuelle wetter abfragen und dann wieder, bevor ein Wert unter 100 % möglich wäre, also 1 Stunde vor elevation = 6.


Ich habe nocheinmal im log nachgeschaut:

sunrise 7:41
wetterabfrage: 7:36
das sind 5 Minuten!

[Dietmar63]

eine Stunde wurde seinerzeit aus dem hohlen Bauch heraus eingestellt

[Zeitisen]

Ich habe mir den Code jetzt etwas angesehen und die Stelle gefunden, wo das festgelegt wird.

Ich habe nun als Zeitpunkt nicht sr_weather und ss_weather, sondern sr_naut und sr_twilight genommen.

Im Anhang sind zwei Screenshots des Verhaltens vor und nach der Änderung.

Code Auswählen Erweitern

sub Twilight_WeatherTimerSet($) {
  my ($hash) = @_;
  my $now    = time();

  myRemoveInternalTimer    ("weather", $hash);
# statt sr_weather und ss_weather  5 Minuten vor sr_naut und 65 Minuten vor ss_twilight
     my $tim = $hash->{TW}{"sr_naut"}{TIME};
     if ($tim-5*60>$now+60) { # mehr als 1 Minute zur nächsten Abrufzeit
        myInternalTimer       ("weather", $tim-5*60, "Twilight_WeatherTimerUpdate", $hash, 0);
        last;
     }
     my $tim = $hash->{TW}{"sr_twilight"}{TIME};
     if ($tim-65*60>$now+60) { # mehr als 1 Minute zur nächsten Abrufzeit
        myInternalTimer       ("weather", $tim-65*60, "Twilight_WeatherTimerUpdate", $hash, 0);
        last;
     }

}


Die Unstetigkeit am Anfang, verursacht durch eine Wetteränderung während  0 < twilight_weather  < 100 ist damit behoben.

Vielleicht kannst Du das einpflegen.

[Dietmar63]

gut gemacht - nehme ich in den Code auf.

[Dietmar63]

funktioniert nicht - nehme die Änderung wieder zurück:
https://forum.fhem.de/index.php/topic,61809.0.html

[Zeitisen]

Hallo,

Hallo, mit dem heutigen Update (2.12.2016) kommen beim Laden des Moduls folgende Warnungen:

2016.12.02 10:53:08 1: PERL WARNING: "my" variable $tim masks earlier declaration in same scope at ./FHEM/59_Twilight.pm line 470, <$fh> line 1531.
2016.12.02 10:53:09 1: PERL WARNING: Use of uninitialized value $tim in subtraction (-) at ./FHEM/59_Twilight.pm line 471, <$fh> line 1531.

Gruß

Elektrolurch

Schuld für die erste Warnung ist das zweite my vor der Varible $tim  in Zeile 470
Die habe ich eingefügt wegen der zweiten Warnung und nicht mehr getestet. Fälschlicherweise. Das war quick and dirty und ist meinen mangelnden Perl-Kenntnissen geschuldet.
Diese zweite Warnung kommt bei mir auch. Das führt nur dazu, dass das zweite Wetterholen nicht funktioniert. Das war aber nie das Problem.

Ich habe jetzt noch einmal etwas nachgeforscht und festgestellt, dass es ss_twilight und sr_twilight wohl nicht zu diesem Zeitpunkt gibt.
Die Zeiten werden in sub Twilight_TwilightTimes definiert mit der Zeile 254:
my @horizons = ("_astro:-18", "_naut:-12", "_civil:-6",":0", "_indoor:$hash->{INDOOR_HORIZON}", "_weather:$hash->{WEATHER_HORIZON}");

Die Zeile habe ich noch nicht verstanden.

Ich habe jetzt ss_twilight durch ss_indoor ersetzt. Dann funktioniert es ohne Warnings. Ich werde  morgen noch mal überprüfen, ob das Wetter am Nachmittag noch einmal abgerufen wird.

Code Auswählen Erweitern


# statt sr_weather und ss_weather  5 Minuten vor sr_naut und 65 Minuten vor ss_indoor
     my $tim = $hash->{TW}{"sr_naut"}{TIME};
     if ($tim-5*60>$now+60) { # mehr als 1 Minute zur nächsten Abrufzeit
        myInternalTimer       ("weather", $tim-5*60, "Twilight_WeatherTimerUpdate", $hash, 0);
        last;
     }
     my $tim = $hash->{TW}{"ss_indoor"}{TIME};
     if ($tim-65*60>$now+60) { # mehr als 1 Minute zur nächsten Abrufzeit
        myInternalTimer       ("weather", $tim-65*60, "Twilight_WeatherTimerUpdate", $hash, 0);
        last;
     }



Mit den Warnings bin ich wohl in bester Gesellschaft. Ich bekomme beim Start noch zwei andere. Da hatte ich aber nicht meine Finger drin:

Code Auswählen Erweitern


PERL WARNING: Use of uninitialized value $definition[1] in string ne at ./FHEM/98_CustomReadings.pm line 79.
PERL WARNING: ^* matches null string many times in regex; marked by <-- HERE in m/^* <-- HERE $/ at fhem.pl line 4184.

[Zeitisen]

Es hat etwas länger gedauert, aber hier der Bericht:


Beginn kurz nach Mitternacht:

Code Auswählen Erweitern


2016.12.07 00:00:01.780 4: [TW] 31=Clear -5, correction: 0°
2016.12.07 00:00:01.867 5: [TW] setting  Timer: TW_sr_naut 2016-12-07 06:38:17
2016.12.07 00:00:01.868 5: [TW] setting  Timer: TW_sr_weather 2016-12-07 08:06:37
2016.12.07 00:00:01.873 5: [TW] setting  Timer: TW_ss_indoor 2016-12-07 16:12:14


Das ergibt einen neuen Start termin für das Wetter aktualisieren 6:33:17
Das findet auch statt:

Code Auswählen Erweitern


2016.12.07 06:33:17.022 4: [TW] url=http://query.yahooapis.com/v1/public/y.....
2016.12.07 06:33:17.306 4: [TW] 27=Mostly Cloudy -6, correction: 3.2°
2016.12.07 06:33:17.333 5: [TW] setting  Timer: TW_sr_weather 2016-12-07 08:31:03
2016.12.07 06:33:17.334 5: [TW] setting  Timer: TW_ss_weather 2016-12-07 15:47:48

Das Wetter ändert sich von Clear auf Mostly Cloudy, sr_weather von 8:06 auf 8:31
Die Aktualisierung für sunset sollte  65 Minuten vor ss_indoor sein, also um 15:07:14

Code Auswählen Erweitern


2016.12.07 15:07:14.967 4: [TW] url=http://query.yahooapis.com/v1/public....
2016.12.07 15:07:25.107 3: [TW] got no weather info from yahoo. Error code: read from http://query.yahooapis.com:80 timed out
2016.12.07 15:07:25.116 5: [TW] setting  Timer: TW_ss_weather 2016-12-07 15:47:48



Leider wieder mal eine Fehlermeldung von Yahoo, deshalb wird der Wert von 6:33 genommen.


Die Werte von 6:33 sind leider total daneben.

Code Auswählen Erweitern


"pubDate":"Wed, 07 Dec 2016 05:00 AM CET","condition":{"code":"27","date":"Wed, 07 Dec 2016 05:00 AM CET","temp":"-6","text":"Mostly Cloudy"}
Zu diesem Zeitpunkt war es sternenklar und keine Wolke zu sehen. Die Temperatur war -9 und nicht -6
Das bedeutet also zumindest für meinen Standort, dass die Werte keine tatsächlichen Beobachtungswerte für diesen Ort sind.
Damit ist Yahoo für diesen Anwendungsfall unbrauchbar.
Ich verwende auf meinem Handy wetter-online.de. Damit habe ich schon über zwei Jahre nur gute Erfahrungen gemacht. Die Vorhersagen sind zuverlässig, die aktuellen Werte stimmen mit dem tatsächlichen Wetter überein ( auch heute).

Zum eigentlichen Grund dieses Posts: Die Berechnung der Zeitpunkte zum Wetter holen funktioniert.
Nur wäre ein anderer Wetterdienst besser. Vielleicht sollte man über eine Einbindung anderer Dienste nachdenken.

[frank]

Nur wäre ein anderer Wetterdienst besser. Vielleicht sollte man über eine Einbindung anderer Dienste nachdenken.

das sollte doch bereits möglich sein, so wie ich es verstehe.
hast du mal folgendes attribut probiert?

useExtWeather <device>:<reading>
use data from other devices to calculate twilight_weather.
The reading used shoud be in the range of 0 to 100 like the reading c_clouds   in an openweathermap device, where 0 is clear sky and 100 are overcast clouds.
With the use of this attribute weather effects like heavy rain or thunderstorms are neglegted for the calculation of the twilight_weather reading.