Twilight - Maintainership (orphan 2020)

[Helmi55]

Hallo
Danke das du dich um dieses Modul kümmerst
Welche Wetterdienste kann man für extWeather verwenden
Ich habe meine eigene Netatmo Wetterstation. Würde das auch funktionieren?
Gruß Helmut

[BroPi]

Es müssten eigentlich alle Wetterdienste gehen, die eine Vorhersage für den morgigen Bewölkungsgrad machen. Entsprechend dieses Grades wird ss_weather und sr_weather im voraus berechnet. Der Bewölkungsgrad muss in den Wertebereich 0 ... 100 passen, wobei 0 klares Wetter bedeutet und 100 stake Bewölkung. Man muß gegebenenfalls eine Umrechnung vornehmen. Es hängt von dem verwendeten Wetterdienst ab.

Vorschlag:
1. Bewölkungsdaten vom Wetterdienst holen
2. Werte in den Bereich 0 ... 100 konvertieren
3. Daten in ein Dummy schreiben
4. Dummy triggert extWeather von Twilight

Ob Netatmo eine Vorhersage der Bewölung macht kann ich nicht sagen.

[Helmi55]

Danke für deine Antwort.
Leider zeigt das Netatmo nicht an

Nice eve

[Beta-User]

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.

Danke für die Rückmeldung, dann wird das erst mal die Basis für die weitere Entwicklung...

Es müssten eigentlich alle Wetterdienste gehen, die eine Vorhersage für den morgigen Bewölkungsgrad machen.

Jein! So wie es jetzt ist, wird der (zum Triggerzeitpunkt) _aktuelle_ Wert berücksichtigt und für die nächste Zeitermittlung zugrundegelegt. Das ist was prinzipiell anderes...
Zu Prognose: s.u.

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?

Die ganze Logik muss dann vermutlich neu aufgebaut werden. Leider sind mir die alten Yahoo-Werte und ihre Auswirkungen nicht bekannt, die alte Logik war aber eben rein Timer-basiert, und das Modul kannte sowohl die (regelmäßigen?) Timer zur Aktualisierung der Wetterwerte wie (vermutlich) auch die Prognosewerte für die Zukunft, und hat dann das irgendwie in Deckung gebracht.

Meine aktuellen Gedanken:
- Es wird in Schritt 1 rein Ist-Wert-bezogen gearbeitet. Damit sollte alles tauglich sein, was die AKTUELLE Bedeckung liefert (noch: als Zahlenwert). Status: Scheint (nach obiger Änderung) zu funktionieren - Cool!
- Dann wird eben immer alles aktualisiert, was in der Zukunft liegt (tbd.), optimalerweise, wenn es wirklich spürbare Auswirkungen hat.

Ergo:

Vorschlag:
1. Bewölkungsdaten vom Wetterdienst holen
2. Werte in den Bereich 0 ... 100 konvertieren
3. Daten in ein Dummy schreiben
4. Dummy triggert extWeather von Twilight

könnte im Prinzip funktionieren, wobei meine Vorgehensweise eher wäre, 3+4 zusammenzufassen und das als userReadings zu lösen, und dann extWeather auf das userreading hören zu lassen.

Als Ausblick - auch zum Thema Prognose - würde ich mal folgendes an die Wand werfen: Anhand des TYPE könnte man wissen, ob ein Wetterdevice
- nur den aktuellen Bewölkungsgrad angeben kann, oder auch eine Prognose;
- ein passendes nummerische Reading liefert (bzw. auch, wie es heißt), oder was anderes und wie das dann ggf. zu konvertieren wäre (hieße, die Logik aus dem userReading käme in Twilight in eine Art dispatch-Routine).

Falls es auch Prognosewerte für die Zukunft liefert:  man könnte ggf. dann sogar die für die Berechnung nutzen - das wäre dann die "extended version" zu dem vorigen Punkt.

Klingt nach einem größeren act, erscheint mir aber machbar. Werde jetzt aber erst mal versuchen, den Code soweit zu fixen, dass er was halbwegs sinnstiftendes für (sr|ss)_indoor liefert, in einer package-Variante "tut" und dann irgendwann auch möglichst abgelaufene Timer von zukünftigen unterscheiden kann und zukünftige nur "sachte" ändert...

@Helmi: Gibt es denn ein Reading, das Aufschluss über den aktuellen Bewölkungsgrad gibt? Dann könte Netatmo das Wetter-Modul sein mit der ersten speziellen dispatch-Logik . Sicher noch nicht morgen, aber evtl. will ja jemand mitarbeiten, der sowas besser kann als meinereiner, das Modul ist "orphan"...

[Helmi55]

Hallo Beta-User

leider nein. Sind mMn nur forecasts.
Ich häng mal zwei Bilder an (sonst wird die Formatierung nix)

1. netatmo weathermap und 2. netatmo_forecast
Dies stammt alles aus dem netatmo Modul in netatmo.com finde ich leider auch nichts.

Bei Bedarf kann ich dir auch gerne einmal kurzfristigen Zugriff auf meine Station geben - kein Problem.

Gruß
Helmut

[Beta-User]

Na ja, notfalls täte es wohl auch ein forecast anstatt eines aktuellen Messwerts. Da scheint aber gar nichts dabei zu sein, was in Richtung Wolken geht, oder interpretiere ich das falsch?

Ansonsten kannst du notfalls zu diesem Zweck auch ein Weather-Device definieren und dessen Wert nehmen.

[Frank_Huber]

Moin,

Ich würde hier Darksky empfehlen.
da gibt es direkt das "cloudcover" reading.
bei OpenWeatherMap übrigens auch.

Noch eine kurze Frage zur Überarbeitung, das "light" reading im twilight, wird das auch wieder richtig berechnet?
Das habe ich "damals" ganz gerne für die Aussenbeleuchtung genommen.

Grüße
Frank

[yersinia]

Ich würde hier Darksky empfehlen.
da gibt es direkt das "cloudcover" reading.

Für jene, die es schon haben, gut, für jene, die es neu aufsetzen wollen, schlecht - es gibt keine API keys mehr.

[...]
Wettervorhersagen und Karten auf Darksky.com sowie Embeds für andere Seiten werden noch bis zum 1. Juli 2020 offeriert, danach abgedreht.
Die Website an sich bleibt als Supportportal für die bisherigen iOS-App- und API-Kunden online.
Die API selbst soll mindestens bis Ende 2021 verfügbar sein, ob Apple sie weiterführt, ist jedoch unklar.
[...]

https://www.heise.de/mac-and-i/meldung/Apple-kauft-sich-beliebte-Wetter-App-4694561.html

API

Our API service for existing customers is not changing today, but we will no longer accept new signups. The API will continue to function through the end of 2021.

As part of this transition, use of Dark Sky by Apple is subject to the Apple Privacy Policy, which can be found at apple.com/privacy.

https://blog.darksky.net

Zumal, ist cloudCover nicht der aktuelle Wert? Selbst wenn Twilight so arbeitet, aber was interessiert mich die Bewölkung jetzt für den Sonnenaufgang morgen früh? Das ändert sich, wenn man näher ranrückt an den Termin, zB eine Stunde vorher auf einen aktuellen Wert wechselt. Aber die Logik inklusive der Definition durch Attribute/readings würde die Hölle werden....
Interessanter wäre doch der fc2_cloudCover für sr morgen bzw fc1_cloudCover für ss heute, oder nicht?

[Frank_Huber]

Für jene, die es schon haben, gut, für jene, die es neu aufsetzen wollen, schlecht - es gibt keine API keys mehr.https://www.heise.de/mac-and-i/meldung/Apple-kauft-sich-beliebte-Wetter-App-4694561.htmlhttps://blog.darksky.net

Zumal, ist cloudCover nicht der aktuelle Wert? Selbst wenn Twilight so arbeitet, aber was interessiert mich die Bewölkung jetzt für den Sonnenaufgang morgen früh? Das ändert sich, wenn man näher ranrückt an den Termin, zB eine Stunde vorher auf einen aktuellen Wert wechselt. Aber die Logik inklusive der Definition durch Attribute/readings würde die Hölle werden....
Interessanter wäre doch der fc2_cloudCover für sr morgen bzw fc1_cloudCover für ss heute, oder nicht?

Oh, das hatte ich wohl verdrängt mit Darksky. Dann bleibt OpenWeatherMap.

Twilight hatte ja nicht nur die SR / SS Zeiten angepasst, es hat ja auch das "light" Reading für die aktuelle Helligkeit ausgegeben.
DS und OWM haben aber auch beide den CloudCover im forecast.

[BroPi]

aber was interessiert mich die Bewölkung jetzt für den Sonnenaufgang morgen früh? Das ändert sich, wenn man näher ranrückt an den Termin, zB eine Stunde vorher auf einen aktuellen Wert wechselt. Aber die Logik inklusive der Definition durch Attribute/readings würde die Hölle werden....
Interessanter wäre doch der fc2_cloudCover für sr morgen bzw fc1_cloudCover für ss heute, oder nicht?

Da stimme ich voll zu. Übrigens gibt es gute Vorsagewerte von PROPLANTA. PROPLANTA geht ohne Anmeldung/Registrierung. Mein Vorschlag wäre das attr useExtWeather zu doppeln:

useExtWeather_sr
useExtWeather_ss

Damit kann man den obigen Vorschlag "fc2_cloudCover für sr morgen bzw fc1_cloudCover für ss heute" umsetzen.

[yersinia]

Da stimme ich voll zu. Übrigens gibt es gute Vorsagewerte von PROPLANTA. PROPLANTA geht ohne Anmeldung/Registrierung.

Ich habe festgestellt, dass Proplantas Vorhersagen nicht sehr genau sind, auch nicht in der nahen Zukunft. Die Abweichungen zu anderen Wetterdiensten/-vorhersagen sind partiell gravierend. Vom dann IST-Wetter mal ganz abgesehen.

Mein Vorschlag wäre das attr useExtWeather zu doppeln:
useExtWeather_sr
useExtWeather_ss

Damit kann man den obigen Vorschlag "fc2_cloudCover für sr morgen bzw fc1_cloudCover für ss heute" umsetzen.

Allerdings müsste man hier auch prüfen, wann sich zB fc2_cloudCover von morgen auf übermorgen ändert. Wenn wir kurz vorm sr stehen (sagen wir um 2 Uhr morgens), kann fc2_cloudCover schon vom nächsten Tag sein - ich müsste also immer zwischen fc1 (heute) und fc2 (morgen) springen. Für ss wäre es weniger dramatisch, da es immer fc1 wäre.
Also passt für die ultimativ kurz vorher neu berechneten sr_weather Werte cloudCover besser mMn.. Der zeitliche Aspekt ist schwierig.
Zumal mVn fc1_cloudCover für den ganzen Tag gilt, evtl ein Durchschnitsswert. Interessant wäre die Bewölkungsvorhersage kurz nach dem sr und kurz vor ss.

[Beta-User]

...dass das ganze erhebliche Eingriffe in die gesamte Logik des Moduls erforderlich macht, ist klar...

Wie bereits geschrieben:

Die ganze Logik muss dann vermutlich neu aufgebaut werden. Leider sind mir die alten Yahoo-Werte und ihre Auswirkungen nicht bekannt, die alte Logik war aber eben rein Timer-basiert, und das Modul kannte sowohl die (regelmäßigen?) Timer zur Aktualisierung der Wetterwerte wie (vermutlich) auch die Prognosewerte für die Zukunft, und hat dann das irgendwie in Deckung gebracht.

Meine aktuellen Gedanken:
- Es wird in Schritt 1 rein Ist-Wert-bezogen gearbeitet. Damit sollte alles tauglich sein, was die AKTUELLE Bedeckung liefert (noch: als Zahlenwert). Status: Scheint (nach obiger Änderung) zu funktionieren - Cool!
- Dann wird eben immer alles aktualisiert, was in der Zukunft liegt (tbd.), optimalerweise, wenn es wirklich spürbare Auswirkungen hat.
[...]Werde jetzt aber erst mal versuchen, den Code soweit zu fixen, dass er [...] in einer package-Variante "tut" [...]

Anbei eine erste package-Variante mit der gefixten invertierten Logik.

Derzeit werden noch bei Aktualisierung des Readings alle ".*weather-Readings aktualisiert, ob diese Triggerei negative Auswrikungen hat: k.A. (Rückmeldung erbeten!)

Interessanter wäre doch der fc2_cloudCover für sr morgen bzw fc1_cloudCover für ss heute, oder nicht?

Als Ausblick - auch zum Thema Prognose - würde ich mal folgendes an die Wand werfen: Anhand des TYPE könnte man wissen, ob ein Wetterdevice
- nur den aktuellen Bewölkungsgrad angeben kann, oder auch eine Prognose;
- ein passendes nummerische Reading liefert (bzw. auch, wie es heißt), oder was anderes und wie das dann ggf. zu konvertieren wäre (hieße, die Logik aus dem userReading käme in Twilight in eine Art dispatch-Routine).

Falls es auch Prognosewerte für die Zukunft liefert:  man könnte ggf. dann sogar die für die Berechnung nutzen - das wäre dann die "extended version" zu dem vorigen Punkt.

Klingt nach einem größeren act, erscheint mir aber machbar.

Vielleicht noch ein paar Anmerkungen zum Thema "package":
- "twilight()" müßte jetzt als einzige der internen Funktionen weiter nutzbar sein (Siehe meine betreffende Frage, ob jemand noch was anderes braucht ziemlich zu Anfang des Threads).
- Die ganze Initialisierung muß mAn. weiter überarbeitet werden. Damit meine ich den Aufbau der Timerstruktur nach Änderungen. Was wir brauchen ist eine volle Initialisierung, wenn ein define abgesetzt wird, und jeweils um Mitternacht (vermutlich mit der Übergabe der Info, um welche Art der Initialisierung es sich handelt). define und "Mitternacht" müssen alle Timer neu setzen, alle anderen Varianten immer nur das, was heute noch nicht "um" und irgendwie von den Wetterdaten abhängig ist.
- Da das insgesamt einen größeren Umbau erforderlich macht, ist das einfacher, wenn die Funktionen nicht im main-Namespace rumspuken. Hat halt den Nachteil, dass einem z.B. das System abschmiert, wenn ein Timer auf eine nicht vorhandene Funktion verweist bzw. dir Referenzen müssen angepaßt werden. (Ich hoffe, das jetzt halbwegs vollständig abgefangen zu haben, aber bitte wenn möglich das ganze erst mal auf einem Testsystem laufen lassen).

Next steps wären jetzt
- Trigger einschränken
- .*_indoor fixen (ich vermute auch hier einen Rest des Yahoo-Codes, der gewisse defaults setzt, wenn die Online-Abfrage ins Leere geht, der hier genannte Tausch der Internals-Referenzierungen kommt mir (noch) spanisch vor..

Wer mag, darf sich gerne Gedanken machen, wie man z.B. standardisiert Weather oder Proplanta abfragen könnte, um den forecast für 18-19 Uhr zu bekommen... (Dann hätte sich der Vorschlag von BroPi ggf. auf andere Weise "erledigt", und man könnte z.B. für das Attribut (zukünftige Benennung oder Struktur für "ext. trigger" und "ext. prognosis" sei mal dahingestellt, es ist ja immer "ext") einfach den Namen des Proplanta-Devices angeben...

[BroPi]

Kurzer Zwischenbericht:

Die vorher bei light und state vorhandenen Sprünge sind jetzt teilweise weg, aber die Werte stimmen nicht mehr (siehe dazu die Bilder). Tagsüber sind die Werte für state 7 und light bei 5. Diese sollten aber beide bei 6 liegen.

[Beta-User]

Die vorher bei light und state vorhandenen Sprünge sind jetzt teilweise weg, aber die Werte stimmen nicht mehr (siehe dazu die Bilder).

Muss ich mir ansehen, wo das ggf. herkommen könnte. "Eigentlich" habe ich diesen Teil der Logik nicht bewußt angefaßt ... (Das mit dem Graphen ist gut, da bekommt man einen guten Eindruck, wie das sein soll; woher hast du die Vergleichswerte? Kopie des Moduls unter anderem Namen?).

Allerdings ist jetzt in der angehängten Fassung die ganze Modulinitialisierung etwas verändert, so dass  auch "irgendwelche" .*_indoor-Werte kommen . Es wäre daher denkbar, dass das mit den springenden Werten auch was mit teilweise fehlenden Infos zu tun hatte, die man auch für die indoor-Berechnung braucht (und die  wieder zur richtigen Zeit (in der Ablauflogik gedacht) verfügbar sein sollten).

Weiter gibt es jetzt eine gewisse Toleranz von +/-6 Punkten, die überschritten sein muss, dass die .*_weather-Werte neu berechnet werden. Was jetzt noch fehlt, ist das Überspringen von "vergangenen" Werten. Mal schauen, wann ich dazu komme.

Auch diese Version ist im Prinzip nur kurz angetestet, also Bitte um Vorsicht...

[Frank_Huber]

Die Sprünge könnten aber auch von der Bewölkung kommen.
mehr und dunklere Wolken = kleinerer light Wert.
Das könnte auch evtl erklären warum er gestern nicht über 5 raus ist.

Eventuell wäre es ja noch hilfreich den cloudcover mit in die Grafik zu ziehen?

btw und OT:
Du kannst auch 2 Y-Achsen mit verschiedenen Werten auf jeder Seite haben.
Das kann man aber nur direkt im gplot editieren.