Yahoo Wetter

Begonnen von stgeran, 01 September 2020, 21:00:45

Vorheriges Thema - Nächstes Thema

Beta-User

Die aktuelle MAINTAINER.txt gibt das so wieder, und es ist auch folgerichtig, siehe https://forum.fhem.de/index.php/topic,113722.msg1079869.html#msg1079869.

(Es wundert mich ein bißchen, dass Christoph das nicht schon länger gefixt hat; das Problem ist ja nicht neu... Rudi hat aber bestimmt auch nichts dagegen, wenn du ihm einen Patch lieferst, der auf was passendes aus einem Weather-Device zugreift ;) . Aus älteren Diskussionen meine ich aber mitgenommen zu haben, dass es dafür keinen wirklichen Ersatz gibt?).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

yersinia

Aber es gibt doch schon ein Thread für Twilight und dem Thema Yahoo Weather -> 59_Twilight.pm - Funktioniert seit dem 3.1.19 nicht mehr - Yahoo API Umstellung
Gefühlt ist die Twilight Modul Entwicklung erstmal pausiert.
viele Grüße, yersinia
----
FHEM 6.4 (SVN) on RPi 4B with RasPi OS Bookworm (perl 5.36.0) | FTUI
nanoCUL->2x868(1x ser2net)@tsculfw, 1x433@Sduino | MQTT2 | Tasmota | ESPEasy
VCCU->14xSEC-SCo, 7xCC-RT-DN, 5xLC-Bl1PBU-FM, 3xTC-IT-WM-W-EU, 1xPB-2-WM55, 1xLC-Sw1PBU-FM, 1xES-PMSw1-Pl

CoolTux

Zitat von: Beta-User am 03 September 2020, 13:25:55
Die aktuelle MAINTAINER.txt gibt das so wieder, und es ist auch folgerichtig, siehe https://forum.fhem.de/index.php/topic,113722.msg1079869.html#msg1079869.

(Es wundert mich ein bißchen, dass Christoph das nicht schon länger gefixt hat; das Problem ist ja nicht neu... Rudi hat aber bestimmt auch nichts dagegen, wenn du ihm einen Patch lieferst, der auf was passendes aus einem Weather-Device zugreift ;) . Aus älteren Diskussionen meine ich aber mitgenommen zu haben, dass es dafür keinen wirklichen Ersatz gibt?).

Einen wirklich passenden Ersatz gibt es nicht da sämtliche Berechnungen auf Basis der Yahoo Weathercodes geschehen. Der Aufwand ist es einfach nicht wert denke ich. Persönlich ist meine Meinung eh Twilight sterben zu lassen und auf Astro aus zu weichen.


Grüße
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

yersinia

Zitat von: CoolTux am 03 September 2020, 13:38:28Persönlich ist meine Meinung eh Twilight sterben zu lassen und auf Astro aus zu weichen.
Was _mir_ dann fehlen würde wären sx_indoor sowie sx_weather - dies kann mir weder Astro noch SUNRISE_EL zur Verfügung stellen.
MMn kann ich die Bewölkung im Twilight-Device mit dem Attribut useExtWeather von einem anderen Wetter Device Reading übernehmen - dann verschwindet auch die nervige Yahoo Warnung fast vollständig.

Zumal ich die Readings des Twilight-Devices insb. für Einsteiger sehr einfach finde - da ist dann alles dabei an Zeiten bezgl. sunrise und sunset. Ja, Astro bzw SUNRISE_EL können das auch, aber nicht derart komfortabel, imho.
Auch fand ich das Reading light praktisch, als es noch funktionierte.
viele Grüße, yersinia
----
FHEM 6.4 (SVN) on RPi 4B with RasPi OS Bookworm (perl 5.36.0) | FTUI
nanoCUL->2x868(1x ser2net)@tsculfw, 1x433@Sduino | MQTT2 | Tasmota | ESPEasy
VCCU->14xSEC-SCo, 7xCC-RT-DN, 5xLC-Bl1PBU-FM, 3xTC-IT-WM-W-EU, 1xPB-2-WM55, 1xLC-Sw1PBU-FM, 1xES-PMSw1-Pl

Beta-User

Hmm, ich kann das letztlich nicht beurteilen, da ich Astro einsetze (und gar keine Erfahrung mit Twilight habe), mich aber letztlich noch nie intensiver mit beiden auseinandergesetzt habe (nur mit bestimmten Code-Teilen, die sich Weekday- und RandomTimer daraus geborgt hatten).

Unschön ist zweierlei:
- Zum einen produziert es Logeinträge, von denen wir wissen, wo sie herkommen. Könnte man abstellen, die sind in der jetzigen Form für die User kein Mehrwert; ob man die zugehörigen Berechnungen/Herleitungen der Reading-Inhalte dann auch vereinfachen kann (wenn nicht erreichbar, wird mit defaults gerechnet, oder?), wäre eine weitere Frage.
- Der Status von Twilight ist nicht wirklich kommuniziert.

Das erste sollte man immer fixen, und WENN es so ist, dass man es ausphasen sollte, wäre das mindeste, in der cref (für neue User) und ggf. beim Start von FHEM (im Log) darauf hinzuweisen, dass man irgendwann auf einen passenden Ersatz (Astro? Sonst noch was, auch für Teile?) wechseln sollte, optimalerweise gleich mit einer Umstellungsroutine, falls sowas möglich ist (vorab schon mal sorry, wenn entsprechende Hinweise bereits erfolgen, ich habe nur in der d-commandref nachgesehen).

Dass man die Info finden kann, wenn man sucht und dort in dem 2019-er Thread ggf. auch Teillösungen und manches mehr (Danke auch für die Bereitstellung des Darksky-Plugins für weather!) diskutiert wurde, stimmt zwar, es ist aber mMn. kein guter Weg, irgendwie über einen "funktioniert nicht mehr"-Thread Module abzukündigen...

(Wenn es so ist, dass es "nur" darum geht, Twilight als Maintainer in Ehren zu beerdigen, kann ich das übernehmen, Umstellungsroutinen wird es dann aber vermutlich nicht geben...)

@yersinia:
Das sind m.E. gute Gründe. Falls du Interesse am Weiterleben von diesem Modul hast, können wir das auch zusammen in Co-Maintainerschaft übernehmen (und ich mich dann nach Ende der Überarbeitung dann wieder verabschiede). Es sollte halt so sein, dass wir wieder einen akzeptablen Stand bekommen und die Doku paßt...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

CoolTux

Wenn man sich die weitere Entwicklung auf Github an schaut so ist Twilight lediglich als Wrapper für Astro umgebaut worden und auf packages umgestellt.

https://github.com/fhem/Twilight/tree/development


Grüße
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Christoph Morrison

Zitat von: CoolTux am 03 September 2020, 13:18:42
Hat das Twilight Modul nicht der Christoph unter seinen Händen?

Ich habe alle meine Module kürzlich zurückgegeben (und auch meine neue Version von Twilight nie veröffentlicht, weil ich immer unzufrieden mit ihr war). Insofern, nein, weder igami (der sie vorher hatte) noch ich haben daran etwas gefixt.

Christoph Morrison

Zitat von: CoolTux am 03 September 2020, 13:38:28
Einen wirklich passenden Ersatz gibt es nicht da sämtliche Berechnungen auf Basis der Yahoo Weathercodes geschehen. Der Aufwand ist es einfach nicht wert denke ich. Persönlich ist meine Meinung eh Twilight sterben zu lassen und auf Astro aus zu weichen.

Die Diskussion haben wir ja schon mal geführt (mit pah) und sie endete IIRC damit, dass Astro was anderes macht als Twilight und eine Mischung nicht gewünscht ist. Meine Idee war, Astro zur Berechnung der Daten zu nehmen, die man nicht für eine wetterabhängigen Daten braucht.

Beta-User

#23
Dann würde ich darum bitten, die angehängte Version mal zu testen.

Ist nicht viel anders, außer dass die yahoo betreffenden Log-outputs weg sind, beim Starten was geschrieben wird und die cref in Teilen angepaßt ist. Wir können dann später immer noch entscheiden, was denn jetzt letztendlich geschehen soll...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Beta-User

#24
...weil's grade so nett war, noch eine etwas erweiterte Version. Neben kleineren Änderungen in der cref ist v.a. der define-Teil geändert, Twilight ohne nähere Infos in der DEF greift damit direkt die Angaben ab, die man in global gemacht hatte (d.h., longitude und latitude wären damit auch optional, nicht mehr verpflichtend).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

amenomade

Astro funktioniert nicht auf allen Architekturen wegen POSIX::tzset
ZitatPOSIX::tzset not implemented on this architecture at ./FHEM/95_Astro.pm line 2083.
Das heisst Twilight (als Wrapper für Astro) wird auch nicht mehr funktionieren?
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

Christoph Morrison

Zitat von: amenomade am 03 September 2020, 19:47:07
Astro funktioniert nicht auf allen Architekturen wegen POSIX::tzsetDas heisst Twilight (als Wrapper für Astro) wird auch nicht mehr funktionieren?

Naja, noch hat niemand Astro in Twilight reinimplementiert. Was für eine Plattform hast du denn?

amenomade

#27
Meine Testinstanz :
ZitatThis is perl 5, version 26, subversion 3 (v5.26.3) built for MSWin32-x64-multi-thread
(with 2 registered patches, see perl -V for more detail)

Copyright 1987-2018, Larry Wall

Binary build 2603 [a95bce075] provided by ActiveState http://www.activestate.com
Built Dec 17 2018 09:46:45

Ich glaube, es ist das gleiche bei StrawberryPerl: https://forum.fhem.de/index.php?topic=102107.0

Bei der produktiven (Debian) geht es.
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

Beta-User

Hmm, wenn es also (noch) keinen Sinn macht, Twilight zu beerdingen, würde ich Rudi anbieten, das als "orphan" interimsweise zu betreuen und wenigstens die Log-Einträge zu beseitigen etc., sofern positive Rückmeldung zu der letzten Testversion kommt? Ziel wäre dann aber eher eine Erhaltung des status quo, ggf. iVm. der Auslagerung einiger zentraler Mini-Funktionen.

Falls sich jemand anderes (mit) findet: feel free!

(@Christoph:
Ansonsten würde mich noch interessieren,
- ob es bei deinen Patchen irgendeinen (noch von Astro unabhängigen) Zwischenstatus gab, auf dem man aufsetzen kann und
- wie du den Hinweis auf InternalTimer gemeint hattest in irgendeinem früheren Thread (vermutlich zum RandomTimer-PBP-Review). Da ging es darum, ob diese "zentralen Mini-Funktionen" eigentlich überhaupt noch erforderlich sind. Ich hatte mir das im Nachgang angesehen, aber dann nicht verstanden, wie man diese "get-hash-indirect"-Geschichte direkt mit (Remove-)InternalTimer lösen könnte.)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Christoph Morrison

Zitat von: Beta-User am 04 September 2020, 09:37:41
Ansonsten würde mich noch interessieren,
- ob es bei deinen Patchen irgendeinen (noch von Astro unabhängigen) Zwischenstatus gab, auf dem man aufsetzen kann und

Nur das, was es im development-Branch gibt, mehr habe ich daran nicht geändert.

Der Grund warum ich nicht an Twilight weiter entwickelt habe ist, dass mir die Situation mit der Abhängigkeit zu Astro nicht gefällt (kein Mensch, nicht mal pah, weiß ob Astro morgen noch das tut, was es gestern getan hat und es funktioniert auch nicht auf jeder Plattform, wie ich gestern gelernt habe), außerdem gibt es keinen Dependency-Mechanismus in update, also hätte Twilight eigentlich zwingend im SVN-Repository bleiben müssen, was mir aber auch nicht gefällt. Die Implementierung, die Dietmar seinerzeit gemacht hat, war wohl fehlerhaft, denn die Astro-Daten stimmen nicht mit den berechneten Daten anderer Portale überein, also hätte ich das alles nachimplementieren müssen, wozu mir die Zeit und Lust gefehlt hat.

Zitat von: Beta-User am 04 September 2020, 09:37:41
- wie du den Hinweis auf InternalTimer gemeint hattest in irgendeinem früheren Thread (vermutlich zum RandomTimer-PBP-Review). Da ging es darum, ob diese "zentralen Mini-Funktionen" eigentlich überhaupt noch erforderlich sind. Ich hatte mir das im Nachgang angesehen, aber dann nicht verstanden, wie man diese "get-hash-indirect"-Geschichte direkt mit (Remove-)InternalTimer lösen könnte.)

Ich hab leider keine Ahnung was du meinst. Soweit ich mich erinnere, wurde Twilight noch vor InternalTimer() geschrieben und bringt seinen eigene InternalTimer-Implementierung mit, die inzwischen ja überflüssig ist.