Twilight - Maintainership (orphan 2020)

Begonnen von Beta-User, 05 September 2020, 10:06:33

Vorheriges Thema - Nächstes Thema

Beta-User

Hm, irgendwie scheint da ein Teil verloren gegangen zu sein...

Du kannst die nicht so relevanten Teile (fcn_.*) aus dem Weather-list gerne rauslassen ;) . (und ich stelle fest, dass ich mit "cloudCover" selbst ggf. Input hätte :) ).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

teufelchen

#16
Ich habe das List für DarkSky mal um sehr viele FC-Werte gekürzt, deshalb war auch nicht alles im vorherigen Beitrag zu sehen.

Erwarten würde ich dass sich ss-weather und sr-weather abhängig von CloudCover verändern.

Im LogFile ändert sich auch stündlich bei der Aktualisierung der Wetterdaten auch der Wert für Twilight twilight_weather.
Hat aber keinen Einfluss auf SR- und SS-Weather.
Raspberry Pi 3
CUL433: V 1.26.05 a-culfw Build: 311 (2018-12-09_19-12-53) CUL433 (F-Band: 433MHz)
freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB
Debmatic mit RPI-RF-MOD

Beta-User

OK, muß ich mir mal ansehen. Ich habe jetzt verstanden, dass du eigentlich erwarten würdest, dass sich die vorhergesagten "Sonnenauf-/untergangszeiten" auch ändern, wenn sich die Bedeckung verändert?

Bevor ich lange über dem Code brüte: Kann mir jemand sagen, ob das mit yahoo so war, dass die forecast-Zeiten da irgendwie berücksichtigt  wurden?
Und was passiert ist, wenn sich  irgendwas geändert hatte zwischendurch?

(Ich befürchte, es wird noch eine Reihe von Rückfragen geben zum Verhalten des Moduls, und wenn man da dynamisch rückwärts/vorwärts rechnen muß und schauen, ob ein Timer ggf. in die Vergangenheit verlegt werden müßte, wird es "lustig"...)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

teufelchen

Bei Yahoo war es etwa so, dass wenn es Bewölkt war Sunrise Weather später als SR Indoor war und Sunset entsprechend früher.

Auch ist mir nicht bekannt welche Zeitverschiebung verschiedene Bewölkungsgrade bewirken.
Raspberry Pi 3
CUL433: V 1.26.05 a-culfw Build: 311 (2018-12-09_19-12-53) CUL433 (F-Band: 433MHz)
freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB
Debmatic mit RPI-RF-MOD

PieBa

Zitat von: teufelchen am 18 September 2020, 22:53:23
Bei Yahoo war es etwa so, dass wenn es Bewölkt war Sunrise Weather später als SR Indoor war und Sunset entsprechend früher.

Auch ist mir nicht bekannt welche Zeitverschiebung verschiedene Bewölkungsgrade bewirken.

ja, das kann ich bestätigen und macht ja auch Sinn:
Wenn es bewölkt ist, ist es dunkler. Das heißt: Es wird später hell und früher dunkel, als es ohne die Bewölkung der Fall wäre.

BroPi

An dieser Berechnung hatte sich schon mal "acaliebe" ausprobiert. Sein Vorschlag dazu ist hier zu finden:

https://forum.fhem.de/index.php/topic,95281.msg883568.html#msg883568

Vielleicht kannst du da etwas von seinem Code abschauen und eine Anregung bekommen.

Beta-User

Zitat von: BroPi am 20 September 2020, 09:41:49
An dieser Berechnung hatte sich schon mal "acaliebe" ausprobiert. Sein Vorschlag dazu ist hier zu finden:

https://forum.fhem.de/index.php/topic,95281.msg883568.html#msg883568

Vielleicht kannst du da etwas von seinem Code abschauen und eine Anregung bekommen.
Danke für diesen Link!
Ist zwar nicht so, dass das ganz direkt weiterhilft, aber es ist zumindest eine klare Bestätigung, dass das "schon immer" so war...

Im Moment meine ich, dass ein setter tendenziell nicht die optimale Lösung ist, das ganze sollte automatisch funktionieren. Vorher war halt eine timer-Schleife da, die immer mal wieder die Yahoo-Daten abgeholt und die beiden Readings aktualisiert hat. Timer-Schleife ist aber m.E. nur eine zweitbeste Lösung.

Mein aktueller Gesamt-Plan sähe in etwa so aus:

- Yahoo fliegt ersatzlos raus, wer irgendwelche Wetterdaten berücksichtigt sehen will, soll das extWeather-Attribut füllen (und ggf. dafür sorgen, dass das Ausgangsdevice passende Werte liefert);
- Damit wird auch die letzte Angabe in der DEF vollends für alle Zukunft sinnlos, die betreffende Angabe könnte also m.E. entfallen (?, siehe auch unten);
- Einführung einer notifFn(), die auf Änderungen dieses extWeather-Device/Readings hört und ggf. dann bei Änderungen die beiden sr_weather und ss_weather-Readings aktualisiert. Dabei werden in der Vergangenheit liegende Timer nicht mehr aktualisiert, geht der neue Wert (z.B. weil es jetzt bewölkt ist, vorher aber heiter war) in die Vergangenheit, ist das betreffende Event "jetzt" (im üblichen Zeitformat), liegt er in der Zukunft, wird er triggernd aktualisiert (aber nur, wenn es "wirklich" eine Änderung gab, Schwankungen im Bereich von z.B. 5-10 Minuten sollten keine Events werfen).

- In der Regel sind die long/lat-Angaben aus global ausreichend, die eigentlich einzige "individuelle" Einstellung, die man ggf. wirklich zu benötigen scheint, wäre "indoor_horizon" zu sein. Das werde ich vermutlich in ein Attribut packen und dann bei einer der kommenden Versionen dann diese Angabe in das Attribut umpacken, checken, ob long/lat anders als in global sind und dann aus der DEF löschen, was dort nichts (mehr) verloren hat (Meistens wird die dann alos leer sein). Tendenziell sind long/lat-Angaben auch Daten, die in einem normalen List nichts zu suchen haben, da wäre meine Neigung, das in versteckte Hashes zu packen, die man nur bei Bedarf sichtbar machen würde.

Meinungen dazu?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

BroPi

Ich finde deine Vorschläge sehr gut. So über extWether würde es gut funktionieren. Für mich die beste Lösung.

teufelchen

Ich finde Deinen Vorschlag gut. Auch kann man dann den Wetterdeinst nehmen, der für einen die besten Werte liefert.
Raspberry Pi 3
CUL433: V 1.26.05 a-culfw Build: 311 (2018-12-09_19-12-53) CUL433 (F-Band: 433MHz)
freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB
Debmatic mit RPI-RF-MOD

swsmily

Hallo!

Ich nutze Twilight sehr gerne. Mit Yahoo war es super und hat auch das Wetter sehr gut berücksichtigt. Seit Yahoo die API eingestellt hat, hab ich aber das Problem, dass state nicht mehr wirklich passt.
Statt tagsüber auf State 6 steht es auf 5. Es springt von 4 auf 6 und wenn es dann wirklich hell ist auf zurück auf 5.
Dies betrifft auch das Reading Light, welches von 0 bis 6 und abends wieder zurück geht. Das ist dann morgens auch von 4 auf 6, und dann wieder auf 5 gesprungen, Abends von 5 auf 6 und dann auf 4 zurück.
Hier hatte ich damals bereits sogar einen Screenshot angehängt.
https://forum.fhem.de/index.php/topic,95281.msg906325.html#msg906325


Dadurch schaltet das Licht früh z.b. zu zeitig ab, wenn man [Twilight:State >="6"] hat, da es zu dem Zeitpunkt erst auf 5 springen müsste.

Ich habe daher bei mir in Version: # $Id: 59_Twilight.pm 22737 2020-09-06 04:56:20Z Beta-User $
folgende Zeile geändert:

  my @horizons = ("_astro:-18", "_naut:-12", "_civil:-6",":0", "_indoor:$hash->{INDOOR_HORIZON}", "_weather:$hash->{WEATHER_HORIZON}");

zu so:
  my @horizons = ("_astro:-18", "_naut:-12", "_civil:-6",":0", "_indoor:$hash->{WEATHER_HORIZON}", "_weather:$hash->{INDOOR_HORIZON}");

Also WEATHER und INDOOR vertauscht. Seitdem habe ich wieder richtig STATE, so wie mal gedacht war.

Beta-User, vielleicht findest du heraus, woran das liegt. Wäre schön, wenn STATE zukünftig wieder richtig funktioniert, da ich diese Auswertung in DOIFs leichter finde als auf die Uhrzeiten zu triggern.


Beta-User

#25
...bisschen viel auf einmal, aber da es doch einige zu geben scheint, die Interesse haben, anbei mal mein aktueller Zwischenstand:

Erledigt wären hoffentlich:
- es gibt ein neues Attribut indoorHorizon
- die DEF wird ggf. umgestellt, der 3. Wert landet im Attribut, long/lat gibt es nur noch, wenn anders als global, die Yahoo-ID ist raus...
- es gibt eine NotifyFn, die auf Änderungen des betreffenden Readings reagiert und auch die beiden Zeiten neu berechnet - allerdings kommt nichts sinnvolles raus, weil die beiden Routinen, um einen "fikitven" Horizont zu berechnen und dann daraus wieder Zeiten zu generieren, ziemlich Yahoo-abhängig sind (vor allen Dingen:  Twilight_getWeatherHorizon()), und dann einfach defaults verwenden, wenn es via Yahoo nichts gibt. Da kann es sein, dass das eine Regression darstellt für die, die eine ID angegeben hatten.

An der Stelle (in der NotifyFn()) könnte man jetzt vermutlich den Code von acaliebe (https://forum.fhem.de/index.php/topic,95281.msg883568.html#msg883568), insbesondere aus der "sub Twilight_Set" reinbasteln, aber das war mir für heute "too much".

Danach wäre noch offen, ob das schon ausreicht, um das von swsmily geschilderte Problem zu verhindern, oder ob die vorgeschlagenen Begleitmaßnahmen Sinn machen (oder was anderes).

Wäre natürlich nett, wenn ihr testen wollt, (oder gar patches für diesen Stand liefern), ansonsten mache ich bei Gelegenheit weiter, kann aber dann etwas dauern...

Waren einige Eingriffe, kann also nicht garantieren, ob es nicht Probleme gibt, ggf. bitte kritisch beobachten!...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

#26
Jetzt hat's mich doch interessiert, anbei daher eine "ziemlich wilde" Variante, die auch irgendwas rechnet, allerdings mit einer 0-100-Skala (warum das dann nur noch 0-10 sein sollte mit dem setter, hat sich mir nicht erschlossen). Kann aber nicht viel mehr  sagen, wie das das irgendwie auf den ersten Blick halbwegs  plausibel aussieht und ansonsten auch die NotifyRegexp beim Neustarten dann aktiviert.

Insgesamt muß da der Startvorgang, die Trigger, ... dann nochmal im Gesamtzusammenhang angesehen werden, bin ziemlich sicher, dass das nicht wirklich alles sauber und logisch ineinandergreift (beim FHEM-Start).

(EDIT: noch drei Meldungen beim Starten entsorgt)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

BroPi

Ich habe mir mal die neueste Twiligt.pm runtergeladen und rumexperimentiert. useExtWether fuktioniert wieder.
Super Erfolg!

Bei 100 --> keine Verschiebung der sr_weather oder ss_weather
Bei  50 --> Verschiebung ca. 30 min.
Bei    0 --> Verschiebung ca. 1 Std.

Es ist alsoanders als in der Ref beschrieben: "... bei dem 0 heiteren und 100 bedeckten Himmel bedeuten ..."

Beta-User

Vorab mal sorry, dass ich erst mal eine Vorabversion geliefert habe, ohne tiefer in die Materie einzutauchen, ging v.a. erst mal darum, die prinzipielle Funktionalität herzustellen.

Was mir gestern nicht klar war:
- 0-100 oder 0-10 als CONDITION. Der ursprüngliche Code von dem, was aus Yahoo kam, sah eher wie 0-100 aus, daher habe ich das mit dieser Zahlenskala gemacht. Scheint prinzipiell richtig gewesen zu sein, kann aber auch sein, dass das intern erst noch auf einen Wertebereich von 0-10 eingedampft wird (es sah aber danach aus, als würde das erst später noch gemacht).

- Die Logik aus dem Code von acaliebe war invertiert, das ist jetzt erst mal so übernommen worden, obwohl mir das ebenso wie die 0-10-Geschichte komisch vorkam. Die Umkehrung steht in Zeile 644, da müßte eine Änderung auf
$hash->{CONDITION} = $result;
eigentlich schon zum Ziel führen (wenn nicht der ganze Code anders zu verstehen ist).
Wäre nett, wenn ihr das mal austesten könntet, ob dann schon plausiblere Werte kommen...


(- Wenn das dann zufällig schon soweit passen sollte, wäre dann noch die Aufgabe, das ganze so zu machen, dass wirklich nur die noch ausstehenden Zeiten geändert werden.)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

BroPi

Habe das "$hash->{CONDITION} = $result;" mal kurz getestet. Sieht jetzt gut aus. Die Zuordnung wie in der Ref. "bei dem 0 heiteren und 100 bedeckten Himmel" stimmt auch wieder.
Mir ist noch aufgefallen, daß sr und sr_indoor bzw. ss und ss_indoor immer gleich sind. "indoorHorizon" scheint keinen Einfluß zu haben. Vielleicht erfolgt die Neuberechnung auch erst später?