Hi,
meine Config:
define Helligkeit Twilight 53.xxxxxx 9.xxxxxx 1 642123
Leider gehen bei mir die Lichter viel zu früh an :)
2016-06-18_20:34:14 Helligkeit twilight_weather: 95.9
2016-06-18_20:34:14 Helligkeit compasspoint: west-northwest
2016-06-18_20:39:14 Helligkeit azimuth: 298.86
2016-06-18_20:39:14 Helligkeit elevation: 8
2016-06-18_20:39:14 Helligkeit twilight: 100
2016-06-18_20:39:14 Helligkeit twilight_weather: 92.2
2016-06-18_20:39:14 Helligkeit compasspoint: west-northwest
2016-06-18_20:44:15 Helligkeit azimuth: 299.82
2016-06-18_20:44:15 Helligkeit elevation: 7.35
2016-06-18_20:44:15 Helligkeit twilight: 100
2016-06-18_20:44:15 Helligkeit twilight_weather: 88.6
2016-06-18_20:44:15 Helligkeit compasspoint: west-northwest
2016-06-18_20:49:15 Helligkeit azimuth: 300.77
2016-06-18_20:49:15 Helligkeit elevation: 6.71
2016-06-18_20:49:15 Helligkeit twilight: 100
2016-06-18_20:49:15 Helligkeit twilight_weather: 85
2016-06-18_20:49:15 Helligkeit compasspoint: west-northwest
2016-06-18_20:54:15 Helligkeit azimuth: 301.73
2016-06-18_20:54:15 Helligkeit elevation: 6.07
2016-06-18_20:54:15 Helligkeit twilight: 100
2016-06-18_20:54:15 Helligkeit twilight_weather: 81.5
2016-06-18_20:54:15 Helligkeit compasspoint: west-northwest
2016-06-18_20:59:15 Helligkeit azimuth: 302.69
2016-06-18_20:59:15 Helligkeit elevation: 5.44
2016-06-18_20:59:15 Helligkeit twilight: 96.9
2016-06-18_20:59:15 Helligkeit twilight_weather: 78
2016-06-18_20:59:15 Helligkeit compasspoint: west-northwest
2016-06-18_21:04:15 Helligkeit azimuth: 303.66
2016-06-18_21:04:15 Helligkeit elevation: 4.81
2016-06-18_21:04:15 Helligkeit twilight: 93.4
2016-06-18_21:04:15 Helligkeit twilight_weather: 74.5
2016-06-18_21:04:15 Helligkeit compasspoint: west-northwest
2016-06-18_21:09:15 Helligkeit azimuth: 304.63
2016-06-18_21:09:15 Helligkeit elevation: 4.2
2016-06-18_21:09:15 Helligkeit twilight: 90
2016-06-18_21:09:15 Helligkeit twilight_weather: 71.1
2016-06-18_21:09:15 Helligkeit compasspoint: west-northwest
2016-06-18_21:14:15 Helligkeit azimuth: 305.6
2016-06-18_21:14:15 Helligkeit elevation: 3.59
2016-06-18_21:14:15 Helligkeit twilight: 86.6
2016-06-18_21:14:15 Helligkeit twilight_weather: 67.7
2016-06-18_21:14:15 Helligkeit compasspoint: west-northwest
2016-06-18_21:15:03 Helligkeit 7
2016-06-18_21:15:03 Helligkeit light: 5
2016-06-18_21:15:03 Helligkeit horizon: 3.4
2016-06-18_21:15:03 Helligkeit aktEvent: ss_weather
2016-06-18_21:15:03 Helligkeit nextEvent: ss_indoor
2016-06-18_21:15:03 Helligkeit nextEventTime: 21:35:27
2016-06-18_21:20:56 Helligkeit azimuth: 306.91
2016-06-18_21:20:56 Helligkeit elevation: 2.78
2016-06-18_21:20:56 Helligkeit twilight: 82.1
2016-06-18_21:20:56 Helligkeit twilight_weather: 63.2
2016-06-18_21:20:56 Helligkeit compasspoint: west-northwest
2016-06-18_21:26:02 Helligkeit azimuth: 307.91
2016-06-18_21:26:02 Helligkeit elevation: 2.18
2016-06-18_21:26:02 Helligkeit twilight: 78.7
2016-06-18_21:26:02 Helligkeit twilight_weather: 59.8
2016-06-18_21:26:02 Helligkeit compasspoint: west-northwest
2016-06-18_21:31:02 Helligkeit azimuth: 308.9
2016-06-18_21:31:02 Helligkeit elevation: 1.59
2016-06-18_21:31:02 Helligkeit twilight: 75.5
2016-06-18_21:31:02 Helligkeit twilight_weather: 56.6
2016-06-18_21:31:02 Helligkeit compasspoint: west-northwestZitatdefine LichtAbends DOIF ([15:00-23:00] and [Helligkeit:twilight_weather] < 65)\
(set fl_LED on,\
set wz_LED_Balkon on,\
set wz_Highboard on,\
set gal_LED_Lese on)\
angegangen ist es gestern um 21:22 Uhr. Ich empfinde das gegenüber zum Winter als viel zu früh. Liegt das daran, dass man sich an die Helligkeit so gewöhnt hat oder wie könnt ihr das erklären?
Und ich wohne im 1. OG mit Wohnzimmer in westlicher Lage, die Sonne scheint bis ca. 21 Uhr auf den Balkon. Kann es sein, dass hier noch der Horizont getunt werden muss?
Danke!
Mit dem Parameter horizon kannst du den Sonnenaufgang nur vorverlegen
Du könntest die unterschiedliche Helligkeitsempfindung im DOIF anpassen, etwa so:
([15:00-23:00] and $month =~ "5|6|7|8" and [Helligkeit:twilight_weather] < 45)
DOELSEIF ([15:00-23:00] and $month !~ "5|6|7|8" and [Helligkeit:twilight_weather] < 65)
Wenn Du twilight_weather als Referenzwert verwendest, wird das nie so ganz befriedigend laufen (meiner Erfahrung nach).
Der Lichtwert ist dann eben immer nur so passend, wie es das Yahoo-Wetter für Deinen Ort ist. Besonders gut merkt man das morgens, wenn Yahoo meint, es wäre noch neblig, sich der Nebel aber schon verzogen hat und die Sonne scheint...
Deshalb setze ich schon lange auf einen eigenen Helligkeitssensor (bzw. den Helligkeitswert aus einem Bewegungsmelder).
Deine Einschätzung, dass man im Winter andere Helligkeitswerte als im Sommer bräuchte, hatte ich damals bei Verwendung von twilight_weather übrigens auch. Das hat sich mit dem eigenen Helligkeitssensor aber auch erledigt bzw. zumindest sind die Abweichungen jetzt so gering, dass ich da keinen Handlungsbedarf mehr sehe.
Ist halt nur Software
Hallo,
ich kenne und nutze fhem erst seit 2 Wochen (vielen Dank dafür), z.Zt. zur Rollosteuerung mit DUOFERN-Modul. Habe festgestellt, dass bei Nutzung von Twilight und indoor-Werten das Modul (für mich) gefühlt zu früh auslöst. Die Alternative "civil" erscheint aber zu spät. Eine Lösung dafür wäre es, für den Korrekturwert indoor_horizon auch negative Werte zuzulassen. Damit lassen sich die indoor-Werte auch in Richtung civil-Wert verschieben. Ich habe das mal gemacht (Zeile 111 in Twilight.pm auskommentiert), für mich ist das mit indoor_horizon -4 z.Zt. eine befriedigende Lösung. Ich wollte nun anfragen, ob es nicht sinnvoll wäre, diese Änderung zu übernehmen.
Viele Grüße
Achim
kann ich übernehmen - kannst du auch die Doku anpassen?
Dann das ganze als Patch schicken, dann baue ich es ein.
Hallo Dietmar,
Patch im Anhang incl. Doku-Anpassung.
VG Achim
patch ist eingeckeckt
Danke!
Nun habe ich gleich nochwas zu meckern ;) Betrifft die Zuordnung der Korrekturfaktoren zu den einzelnen Wettercodes von Yahoo. Da gibt es aus meiner Sicht einige Ungereimtheiten. So hat der Wert für partly cloudy (day) bzw. partly cloudy (night) (Codes 29 und 30) den Korrekturwert 3 (führt zu etwa 17 min. früheren weather_ss), partly cloudy (Code 44) erhält aber den Korrekturwert 12 (weather_ss liegt 67 min (!) vor indoor_ss). Schwere Gewitter kommen (im Gegensatz zu Tropenstürmen und Hurricans) auch bei uns vor. Der Korrekturwert 25 führt dazu, dass weather_ss 140 min (!) vor indoor_ss liegt. Die Zeiten basieren auf Dietmars Aussage 1grd entspricht 7min (aus der Diskussion um den indoor-Korrekturwert). M.E. sollte der Korrekturwert zu (44 partly cloudy) korrigiert werden. Die anderen Werte sind es vielleicht wert, nochmal diskutiert zu werden. Mir erscheinen sie zu hoch. Ich hab die derzeitigen Werte mal zusammengefasst:
Korrektur Minuten bei
25 140 tornado tropicalstorm hurricane severethunderstorms
20 112 thunderstorms
15 84 isolatedthunderstorms scatteredthunderstorms heavysnow
12 67 partlycloudy
10 56 mixedrainandsnow mixedrainandsleet mixedsnowandsleet freezingdrizzle drizzle freezingrain blowingsnow snow foggy
9 50 scattered showers
8 45 scatteredsnowshowers heavysnow snowshowers
7 40 showers snowflurries mixedrainandhail
6 33 hail sleet dust haze smoky blustery windy cold
5 28 lightsnowshowers mostlycloudy(night) mostlycloudy(day)
3 17 cloudy partlycloudy(night) partlycloudy(day)
0 0 clear(night) sunny fair(night) fair(day) hot
Derzeit kann es auch passieren, dass bei schnellen Wetterschwankungen bei der nächsten Wetterberechnung eine Zeit für weather_ss ermittelt wird, die bereits in der Vergangenheit liegt. In diesem Fall könnte man die Zeit durch die aktuelle Zeit + 1min ersetzen.
VG Achim
Die Korrekturen 0-56min finde ich in Ordnung, das passt aus meiner Erfahrung ganz gut.
Partlycloudy mit 67min passt nicht, zumal es schon partly cloudy mit 17min gibt.
Die Aktualisierung des Wetters müsste aber vorgezogen werden, gerade isolatedThunderstorm &Thunderstorm kann ja auch während des Tages entstehen ohne das da länger was vorhergesagt war, da müsste die Wetteraktualisierung schon über 2h vor dem indoor sunset gemacht werden.
Das erklärt auch Probleme die ich während der Gewitterzeit hatte - ich gehe inzwischen nicht mehr auf weather_ss sondern auf twilight_weather, da ich des öfteren 2 Sonnenuntergänge hatte...
Die Korrekturwerte gehen noch auf den Erfinder des Moduls zurück. Ich habe sie nicht in Frage gestellt, sondern nur die grundsätzliche Logik des Moduls völlig umgebaut.
Das Modul wurde aus der Homematic Welt abgekupfert.
Es hatte nach der Erstellung viele Fehler um die sich seinerzeit Rudi höchstpersönlich kümmern musste
Eigentlich war das Modul, als ich es übernommen habe, immer noch eine Katastrophe. Lässt sich in subversion noch gut nachvollziehen.
Ich habe um halbwegs passende Korrekturen zu bekommen den allgemeinen Faktor 20/25 eingeführt.
Ich hänge an keinem der Faktoren und würde sie auf euren Vorschlag hin übernehmen.
Hallo,
vielleicht könnte Dietmar bei Gelegenheit den 44. Wert in der Tabelle für partly cloudy von 12 auf 3 ändern. Derzeit experimentiere ich noch mit den Werten, sollte ich eine (für mich) bessere Lösung finden, werde ich sie hier zusammen mit einem Patch zur Diskussion stellen.
VG Achim
Hallo,
ich habe mal die o.g. Faktoren so geändert, dass Sie eine Verzögerung /Verspätung von max. 1 Stunde bewirken können (d.h. Maximalwert ist 10). Das macht m.E. Sinn, da (so hab ich das zumindest verstanden) eine Stunde vor dem berechneten ss_weather bzw. sr_weather die aktuelle Wettersituation nochmal abgefragt wird. Bei starker Verschlechterung (am Abend) bzw. Verbesserung (am Morgen) ist so der neue ss_weather / sr_weather in keinem Fall bereits erreicht. Um das auch bei schlecht reagierendem Yahoo-Dienst und/oder langsamen Rechner zu realisieren, habe ich auf 5min zusätzliche Verzögerung (bisher 1 min) geändert.
VG Achim
Hast du bei deinen Überlegungen auch diesen Faktor (Zeile 537) eingerechnet?
Wenn du über jeden Wert einzeln nachgedacht hast, benötigen wir diese Umrechnung vieleicht nicht mehr.
Nein, das habe ich nicht. Mir ging es zunächst darum, mit möglichst wenigen Änderungen am Quellcode auszukommen. M.E. ist es aber relativ einfach möglich, diesen Faktor mit einzubeziehen.
Z.Zt. habe ich aber noch eine andere Baustelle: Wegen des schönen Wetters fallen ss_indoor und ss_weather zusammen. Die werden bei mir in zwei unterschiedlichen at - Statements ausgewertet. Leider wird jetzt nur eine Aktion ausgeführt. Das hat aber sicherlich nichts mit dem Twilight - Modul zu tun.
VG Achim
Ich kann den Faktor einfach herausnehmen. Was meinst du?
Man müsste dann jeden Faktor mit 0,8 multiplizieren, um den gleichen Effekt zu haben. In der Tabelle faktor_cond_code stehen dann Werte mit Nachkommastellen. Oder man rundet halt auf Werte zwischen 0 und 8 (wegen der einen Stunde Maximalveränderung).
Btw, mein Problem mit dem Ausfall einer at-Reaktion scheint mir daran zu liegen, dass man keine zwei Timer auf die gleiche Zeit setzen kann. Habe leider die Definition von InternalTimer() noch nicht gefunden, um meine Vermutung zu überprüfen. Vielleicht habe ich auch noch nicht genügend RTFM betrieben. Wenn meine Vermutung stimmt, könnte man im Falle des Condition-Faktors 0 eine kleine Korrektur einbauen, also z.B. 0.1 anstelle 0. Das ist zwar keine saubere Lösung, aber einfach und überschaubar.
VG Achim
Zitat von: joe99 am 28 August 2016, 11:45:59
Btw, mein Problem mit dem Ausfall einer at-Reaktion scheint mir daran zu liegen, dass man keine zwei Timer auf die gleiche Zeit setzen kann.
Kann ich mir nicht vorstellen. DOIFs beispielsweise können problemlos zwei Timer auf demselben Zeitpunkt haben. Und verschiedene Module sowieso, das wäre ja auch eine unsinnige Einschränkung.
Wenn es um interne Timer geht, hilft dass hier vielleicht bei der Analyse (Timer auflisten):
https://forum.fhem.de/index.php/topic,11187.msg66490.html#msg66490
Vielleicht veröffentlichst du mal die problematischen Definitionen. Die Experten hier sehen oft auf dem ersten Blick wo das Problem liegt.
Wäre es denkbar die Korrekturfaktoren als Attribute (oder Internals wie indoor-horizon) auszuführen?
Ich vermute mal ganz stark das einige die jetzt nicht mitlesen sich melden wenn sie feststellen das die Korrekturen für sie nicht mehr passen... Mit den Attributen kann dann jeder nach seinem gutdünken optimieren ohne das Standardmodul anfassen zu müssen...
@ Jo:
Das ist sicher eine gute Idee. Bei meinem derzeitigen Perl-Kenntnisstand kann das aber noch eine Weile dauern. Vielleicht kann sich jemand anderes dieses Problems annehmen oder mir einen Link auf ähnliche Codestückchen (Auslagerung einer Tabelle) geben.
Und zu meinem anderen Problem:
Die Quelle zu InternalTimer() habe ich inzwischen gefunden, meine Vermutung war falsch.
define LichtAn at *{twilight("myTwilight","ss_weather","15:00","23:30")} IF ([anwesend:presence] eq "present") (set SchalterLicht on)
define RollosRunter at *{twilight("myTwilight","ss_indoor","15:00","23:30")} set TYPE=DUOFERN:FILTER=SUBTYPE=(Rollo|Troll|Rohrmotor).* dusk
Die Rollos gehen zuverlässig runter, das Licht soll je nach Wetter etwas früher angeschaltet werden. Das hat auch mehrere Tage lang geklappt, aber an den letzten beiden Tagen nicht.
anwesend ist ein PRESENCE-Objekt, das die Anwesenheit meines Handys checkt. Es wäre natürlich peinlich, wenn ausgerechnet an den letzten beiden Tagen der Akku leer gewesen wäre (ist aber nicht auszuschließen).
ZitatKorrekturfaktoren als Attribute (oder Internals wie indoor-horizon) auszuführen
kann man sicherlich machen, halte ich aber für unnötig.
Ich werde es so mal einchecken.
Vorschlag für bessere Faktoren für weather_horizon eingecheckt
Danke! Habe gestern mal ss_weather=ss_indoor erzwungen. Und Rollos gingen runter, Licht ging zur gleichen Zeit an. Wahrscheinlich war tatsächlich mein Handy aus, sorry. Das Alter... ;)
Gruß Achim
Mit TWILIGHT_WEATHER wird ja eigentlich nur versucht dem Umstand Rechnung zu tragen, dass es bei schlechtem Wetter dunkler ist als an sonnigen Tagen. Der Versuch das über WEATHER_HORIZON zu machen ist m.E. nicht der beste Ansatz. Oftmals ist es z.B: im Winter schon mittags dunkler als es im Sommer kurz vor Sonnenuntergang ist.
Dabei bietet Twilight eigentlich alle Voraussetzungen um einen Helligkeitsindex zu liefern. Tatsache ist, dass bei schlechtem Wetter bis zu 90% der Sonneneinstrahlung blockiert werden, so wie die Sonnenstrahlung im Sommer dreimal so intensiv ist wie im Winter.
Was mir also in Twilight fehlt sind einfache Helligkeitsindices. Den ersten nenne icn mal "BRIGHTNESS", der sich aus der Elevation und dem Wetter berechnen lies BRIGHTNESS = COS(ELEVATION). - und entspricht der direkten Sonneneinstrahlung . Den zweiten nenne ich mal "WEATHER_BRIGHTNESS", der ähnlich TWILIGHT_WEATHER über eine Lookup-Tabelle zu berechnen ist - je nach Wetter werden 10-100% der Lichtstrahlen durchgelassen.
liefern. Dann checke ich es einDu kannst mir den fertigen Code und die Beschreibung dazu gern liefern
Zitat von: immigrantsong am 14 Oktober 2016, 14:32:54
Mit TWILIGHT_WEATHER wird ja eigentlich nur versucht dem Umstand Rechnung zu tragen, dass es bei schlechtem Wetter dunkler ist als an sonnigen Tagen. Der Versuch das über WEATHER_HORIZON zu machen ist m.E. nicht der beste Ansatz. Oftmals ist es z.B: im Winter schon mittags dunkler als es im Sommer kurz vor Sonnenuntergang ist.
Dabei bietet Twilight eigentlich alle Voraussetzungen um einen Helligkeitsindex zu liefern. Tatsache ist, dass bei schlechtem Wetter bis zu 90% der Sonneneinstrahlung blockiert werden, so wie die Sonnenstrahlung im Sommer dreimal so intensiv ist wie im Winter.
Was mir also in Twilight fehlt sind einfache Helligkeitsindices. Den ersten nenne icn mal "BRIGHTNESS", der sich aus der Elevation und dem Wetter berechnen lies BRIGHTNESS = COS(ELEVATION). - und entspricht der direkten Sonneneinstrahlung . Den zweiten nenne ich mal "WEATHER_BRIGHTNESS", der ähnlich TWILIGHT_WEATHER über eine Lookup-Tabelle zu berechnen ist - je nach Wetter werden 10-100% der Lichtstrahlen durchgelassen.
Darf ich mich "reinschleichen" ?
Ich habe ein Projekt dazu in Arbeit.
Direkte und indirekte Einstrahlung entsprechen dem was Du beschreibst.
Verfügst Du über Daten / Modelle / Ansätze um "WEATHER_BRIGHTNESS" (bei mir das indirekte Licht) näherungsweise zu bestimmen ?
Wetterquelle wäre METAR, Bedeckung dort ge-viertelt plus Höhe, Besonderheiten wie Cumulus ja sowie Dunst, Niesel etc und Sichtweite aus denen das zu modellieren wäre. Gilt auch für (näherungsweise oder idealisiert) Abschirmung der direkten Strahlung.
Sorry for stepping in
Joerg
So, ich habe da mal etwas ausprobiert, das schon mal erste Ergebnisse liefert (meine erste Programmierung in PERL).
Ich habe die ideelle Helligkeit so berechnet, dass bei Sonneneinstrahlung direkt von Oben der Wert 1000 raus kommt, bei SS (-6 Grad) kommt 0. Dazwischen über Sinus berechnet (sin (elevation+6)).
Für die Wetterbeeinflussung gibt es eine Tabelle, mit Werten zwischen 20% und 100%. Ob diese Werte passen müsste noch empirisch ermittelt werden.
So, nach weiterer intensiver Prüfung wird ein neues Problem deutlich. Die Yahoo Wettervorhersagen sind selten richtig! Scheinen so gut zu sein, wie die Yahoo Geschäftsprognosen (wer weiß wie lange es Yahoo überhaupt noch gibt.
Ich glaube es wäre viel gewonnen, wenn man Twilight auf einen anderen Anbieter umbauen würde, z.B. http://www.openweathermap.org/API. Wäre außerdem eine Open Source Wetterquelle.
Da würde aber meine geringen PERL-Fähigkeiten strapazieren. Falls aber jemand Interesse hätte es gemeinsam zu entwickeln wäre ich dabei.
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.
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.
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
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.
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.
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
eine Stunde vor dem eigentlichem Sonnenaufgang.
kann man nicht verändern.
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!
eine Stunde wurde seinerzeit aus dem hohlen Bauch heraus eingestellt
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.
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.
gut gemacht - nehme ich in den Code auf.
funktioniert nicht - nehme die Änderung wieder zurück:
https://forum.fhem.de/index.php/topic,61809.0.html (https://forum.fhem.de/index.php/topic,61809.0.html)
Hallo,
Zitat von: Elektrolurch am 02 Dezember 2016, 12:16:51
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.
# 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:
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.
Es hat etwas länger gedauert, aber hier der Bericht:
Beginn kurz nach Mitternacht:
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:
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
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.
"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.
ZitatNur 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?
ZitatuseExtWeather <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.