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

Begonnen von Esteban, 19 Juni 2016, 18:29:00

Vorheriges Thema - Nächstes Thema

joe99

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

Dietmar63

Gruß Dietmar
FB7390, CUL, 2 FHT, FS20
modules: 98_WOL.pm, 98_Heating_Control.pm,   98_WeekdayTimer.pm, 98_RandomTimer.pm, 59_Twilight.pm

joe99

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

Brockmann

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

Dietmar63

Vielleicht veröffentlichst du mal die problematischen Definitionen. Die Experten hier sehen oft auf dem ersten Blick wo das Problem liegt. 
Gruß Dietmar
FB7390, CUL, 2 FHT, FS20
modules: 98_WOL.pm, 98_Heating_Control.pm,   98_WeekdayTimer.pm, 98_RandomTimer.pm, 59_Twilight.pm

Jo

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...

joe99

@ 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).


Dietmar63

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.
Gruß Dietmar
FB7390, CUL, 2 FHT, FS20
modules: 98_WOL.pm, 98_Heating_Control.pm,   98_WeekdayTimer.pm, 98_RandomTimer.pm, 59_Twilight.pm

Dietmar63

Vorschlag für bessere Faktoren  für weather_horizon eingecheckt
Gruß Dietmar
FB7390, CUL, 2 FHT, FS20
modules: 98_WOL.pm, 98_Heating_Control.pm,   98_WeekdayTimer.pm, 98_RandomTimer.pm, 59_Twilight.pm

joe99

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

immigrantsong

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.



 

Dietmar63

liefern. Dann checke ich es einDu kannst mir den fertigen Code und die Beschreibung dazu gern liefern
Gruß Dietmar
FB7390, CUL, 2 FHT, FS20
modules: 98_WOL.pm, 98_Heating_Control.pm,   98_WeekdayTimer.pm, 98_RandomTimer.pm, 59_Twilight.pm

herrmannj

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

immigrantsong

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.

immigrantsong

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.