Twilight - Maintainership (orphan 2020)

[BroPi]

Ich spiele immer die aktuellste Version ein. Das Bild ist von gestern war mit der gestrigen Version.
Gerade eben habe ich wieder aktualisiert. Mal sehen, ob state und light wieder aktualisiert werden.
Übrigens bei uns hier ist cloud auf 100 gegangen. So dunkel war es hier tagsüber schon lange nicht mehr.

[Beta-User]

Ich spiele immer die aktuellste Version ein. Das Bild ist von gestern war mit der gestrigen Version.

Dann hast du jetzt gleich wieder die Gelegenheit...

Da ist jetzt fast alles raus, was mit dem Pollen von Yahoo zu tun hatte, und auch die Funktionsaufrufe sind zum Teil vereinfacht und umbenannt. Allerdings kommt es mir so vor, als sei das ganze immer noch reichlich verschachtelt für das, was es jetzt noch können muss...

Übrigens bei uns hier ist cloud auf 100 gegangen. So dunkel war es hier tagsüber schon lange nicht mehr.

Habe mir jetzt auch den Tag über immer mal wieder mit die sich ergebenden Werte angesehen, das ist schon interessant, was sich da so ergibt.

Die (geringfügige) Verschiebung der Zeiten war im Modul auch schon vorher - an anderer Stelle - implementiert, von daher ist der Teil wieder auf dem vorherigen Stand.

Viel Spaß dann mal beim Testen, ich habe das jetzt auch mal auf meine Hauptinstanz losgelassen...

[BroPi]

Die heutige Version von Twilight (eingespielt am Vormittag) bringt nun wieder die light und state Daten in der Dämmerungshase.
Auch die neueste Version (eingespielt um 19:30 Uhr) arbeitet mit light und state korrekt weiter. Dazu wieder ein Bild.
Morgen werden wir dann sehen ob light und state wieder tagsüber auf 6 zusammen fallen.

[Beta-User]

Danke für die Rückmeldung!

Scheint gut auszusehen .

[swsmily]

Ist das die hier im Forum angehängte Version oder die über Update verteilte?

[Beta-User]

Im Moment geht es um die hier geposteten Versionen - Fehlermeldungen zu der im svn befindlichen (=>update) sind mir nicht bekannt, und ich wollte das eigentlich erst auf einer halbwegs "gesicherten" Basis haben, bevor es ins svn geht.

Von daher sind Rückmeldungen zu der jeweils letzten hier angehängten Version sehr hilfreich.
Die letzte Variante hat jedenfalls auch den Tageswechsel gut überstanden und die Werte sehen gut aus. Fragt sich daher, ob das nicht ins svn sollte, wenn das unfallfrei bis morgen durchläuft...? (Müßte aber die cref auch noch anpassen, das wird mir wohl nicht reichen).

Will das zwar dann immer noch weiter umbauen, aber so ist es dem Gefühl nach jedenfalls wieder eine deutliche Verbesserung.

[BroPi]

Hier jetzt ein Bild im Anhang mit der "59_Twilight.pm:?/2020-09-25 UNSTABLE". Diese wurde am 25.09. um 19:30 Uhr eingespielt.  Läuft also über mehr als einen Tag.
Es zeigen sich bei state und light keine Überschwinger mehr. Auch die Verläufe sehen wieder völlig normal aus. Der Einfluss von "useExtWeather" mit den Werten 50 und 100 gesetzt um 04:00 bzw. 15:00 Uhr sind auch gut zu erkennen.
Aus meiner Sicht ein sehr guter Stand der jetzt erreicht wurde. Vielen Dank!

[Frank_Huber]

Hier jetzt ein Bild im Anhang mit der "59_Twilight.pm:?/2020-09-25 UNSTABLE". Diese wurde am 25.09. um 19:30 Uhr eingespielt.  Läuft also über mehr als einen Tag.

müsste sich "light" nicht auch nach unten korrigieren wenn der "cloudcover" auf 100 geht?

[BroPi]

Soweit ich mich erinnere war light noch nie cloudabhängig. Das wäre dann ein neues Feature: "light_weather".

[Frank_Huber]

Ich meine ich hätte damals extra Light genommen weil es eben Wetter abhängig war. Bin mir aber auch nicht mehr ganz sicher.

[Beta-User]

Zwischeninfos:

- Werde mit dem Einchecken noch etwas warten, hatte ja angedeutet, dass m.E. eigentlich parseParams() auch eine Lösung sein könnte. Nachdem das bei RandomTimer seit kurzem beschwerdefrei läuft, will ich das gleich in diese Richtung umbauen, dann entfällt das indoorHorizon als Attribut wieder...
Hintergrund: Nach meinen ersten Erfahrungen mit dem Modul macht es eigentlich nur Sinn, wenn man wenigstens einen indoorHorizon angibt, besser ist es mit einem Wetter-Device und optimal läuft es mit beidem. Daher sind auch die letzten beiden "Pflichtangaben" und gehören in die DEF, wobei man indoorHorizon eigentlich gleich mit was sinnvollem vorbelegen könnte, wenn der User nichts angibt (tendiere zu 3 (?))...

- "light_weather": Mal schauen,  ob das in dem Yahoo-Code irgendwo versteckt war (sachdienliche Hinweise sind willkommen, hat im Moment noch low prio gg. parseParams und Doku...)

Von daher könnt ihr gerne noch mittesten, es kann dann aber sein, dass indoorHorizon dann beim Wechsel auf das endgültige Modul neu gesetzt werden muss.

[BroPi]

Ich meine ich hätte damals extra Light genommen weil es eben Wetter abhängig war. Bin mir aber auch nicht mehr ganz sicher.

Ich hatte light nie verwendet. Daher meine Falschaussage. Die Diagramme zeigen eindeutig (habe mir das mal jetzt genauer angesehen), dass light und state wetterabhängig sind! Macht ja auch Sinn, denn wer "useExtWeather" verwendet will ja auch dies wetterabhängig haben.

müsste sich "light" nicht auch nach unten korrigieren wenn der "cloudcover" auf 100 geht?

Light verschiebt sich nur zeitlich. Alle Stufen werden durchlaufen.

[swsmily]

Nach einem Tag mit der hier angehängten Version sieht es für mich auch super aus!
Danke, dass dieses Modul weiter unterstützt und entwickelt wird!

[yersinia]

Vielen Dank Beta-User für die Übernahme und anpassen/optimieren des Moduls!

Ich hab jetzt die Version aus #61 übernommen und es läuft unaufällig gut. Dabei hab ich das bestehende Twilight-Device nicht angefasst, hab die .pm also direkt so übernommen (natürlich plust shutdown restart).
Reading light ist jetzt tagsüber auch auf 6 - und nicht 5 wie bisher seitdem Yahoo den Servie eingestellt hat.

Hintergrund: Nach meinen ersten Erfahrungen mit dem Modul macht es eigentlich nur Sinn, wenn man wenigstens einen indoorHorizon angibt, besser ist es mit einem Wetter-Device und optimal läuft es mit beidem. Daher sind auch die letzten beiden "Pflichtangaben" und gehören in die DEF, wobei man indoorHorizon eigentlich gleich mit was sinnvollem vorbelegen könnte, wenn der User nichts angibt (tendiere zu 3 (?))...

Ich hatte beim alten Twilight Device lat, long und indoor_horizon via DEF mitgegeben, mit dem Update ist die DEF nun geleert worden. Gibt es ein Reading, dass mir die Übernahme der Koordinaten aus dem global Device anzeigt?
Mein definierter indoor_horizon ist ebenso aus der DEF verschwunden - dafür gibt es nun ein Internal INDOOR_HORIZON (mit dem gleichen Wert = 1). Müsste ich, der korrekten Vorgehensweise wegen, das Attribut indoorHorizon setzen? Warum wäre 3 für den indoorHorizon ein guter Wert - die Frage, die sich mir hier stellt, ist eher wie sich dieser Wert auf die Zeiten tatsächlich auswirkt.
Wie gebe ich das WetterDevice mit? Gebe ich nur ein Device an und Twilight sucht sich die Werte selbst raus? Oder eher Device:Reading? Bisher nutze ich das Attribut useExtWeather mit einem userReading aus dem ProplanteDevice - in Abhängigkeit der Uhrzeit wird jeweils ein anderes Reading ausgewählt.

Wie sehe eine korrekte DEF aus?

Code Auswählen Erweitern

define MyTwilight Twilight [[indoorHorizon] [WetterDevice:CloudCoverReading]]

[Beta-User]

Vielen Dank Beta-User für die Übernahme und anpassen/optimieren des Moduls!

Gerne geschehen!

Wie sehe eine korrekte DEF aus?

Code Auswählen Erweitern

define MyTwilight Twilight [[indoorHorizon] [WetterDevice:CloudCoverReading]]

Wie bereits angemerkt: Ich will da noch etwas ändern, muß dazu aber selbst ein paar Vorabtests machen...
latitude/longitude bleibt (optional) erhalten, und wenn alles klappt, kann man Varianten wie

Code Auswählen Erweitern

define MyTwilight Twilight 44.444444 8.888888 1 weatherDevice=MeinWetter:cloudCover

Code Auswählen Erweitern

define MyTwilight Twilight indoorHorizon=1 weatherDevice=MeinWetter:cloudCover

Code Auswählen Erweitern

define MyTwilight Twilight 2
attr MyTwilight useExtWeather MeinWetter:cloudCover

Code Auswählen Erweitern

define MyTwilight Twilight 44.444444 8.888888 indoorHorizon=1 weatherDevice=MeinWetter:cloudCoveroder

Code Auswählen Erweitern

define MyTwilight Twilight weatherDevice=MeinWetter:cloudCover indoorHorizon=2nehmen, wobei lat/long dann ggf. zwangsweise rausfliegen, wenn sie (beide) identisch zu global sind...

(Seit Rudi SUNRISE_EL umgebaut hat, kann es mehrere Twilight-Instanzen geben, vorher wäre sich das ins Gehege gekommen.)

Welche Werte für lat/long genutzt werden, sieht man in einem list, wenn man in global "showInternalValues" auf 1 setzt.

Soweit ich mich erinnere war light noch nie cloudabhängig. Das wäre dann ein neues Feature: "light_weather".

Habe mal in der Version https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/59_Twilight.pm?rev=16005 nach Hinweisen auf irgendwas in der Art gesucht, aber nichts gefunden. Gehe also davon aus, dass das in der Tat ein neues Feature wäre...
Ergo sollte erst mal der Rest (svn-fähig) funktionieren, und das würde bedeuten, möglichst die DEF nur dann anzufassen, wenn "unnützes" drinsteht.

Mal schauen, wann ich euch eine Testversion mit parseParams zur Verfügung stellen kann.