Wo kommt dieser logeintrag her?
2020.09.01 00:00:01 3: [myTwilight] got no weather info from yahoo. Error code: gethostbyname query.yahooapis.com failed
2020.09.01 03:35:40 3: [myTwilight] got no weather info from yahoo. Error code: gethostbyname query.yahooapis.com failed
Ist das ein Aufruf von twilight?
Zitat von: stgeran am 01 September 2020, 21:00:45
Wo kommt dieser logeintrag her?
2020.09.01 00:00:01 3: [myTwilight] got no weather info from yahoo. Error code: gethostbyname query.yahooapis.com failed
2020.09.01 03:35:40 3: [myTwilight] got no weather info from yahoo. Error code: gethostbyname query.yahooapis.com failed
Ist das ein Aufruf von twilight?
Ja
mein twilight funktioniert aber.
Readings
aktEvent
ss_astro
2020-09-01 17:58:42
azimuth
334.77
2020-09-01 22:10:22
compasspoint
northwest
2020-09-01 22:10:22
condition
0
2020-09-01 15:44:57
condition_txt
Cloudy
2019-01-25 14:29:46
elevation
-73
2020-09-01 22:10:22
horizon
-18
2020-09-01 17:58:42
light
0
2020-09-01 17:58:42
nextEvent
sr_astro
2020-09-01 17:58:42
nextEventTime
03:21:50
2020-09-01 17:58:42
sr
04:35:40
2020-09-01 00:00:01
sr_astro
03:21:50
2020-09-01 00:00:01
sr_civil
04:11:08
2020-09-01 00:00:01
sr_indoor
04:47:55
2020-09-01 00:00:01
sr_naut
03:46:32
2020-09-01 00:00:01
sr_weather
04:35:40
2020-09-01 15:44:57
ss
16:44:57
2020-09-01 00:00:01
ss_astro
17:58:42
2020-09-01 00:00:01
ss_civil
17:09:28
2020-09-01 00:00:01
ss_indoor
16:32:43
2020-09-01 00:00:01
ss_naut
17:34:03
2020-09-01 00:00:01
ss_weather
16:44:57
2020-09-01 15:44:57
state
12
2020-09-01 17:58:42
twilight
0
2020-09-01 22:10:22
twilight_weather
0
2020-09-01 22:10:22
wie bekomme ich diesen Eintrag weg?
Nicht die readings, nur den logeintrag :-)
Zitat von: Wiki-Twilight
End of Live der Yahoo Weather API
Da die Yahoo Weather API zum 03.01.2019 abgeschaltet wurde, kann Twilight aktuell keine Wetterdaten beziehen!
Um die Fehlermeldung got no weather info from yahoo. zu vermeiden, sollte der Parameter <Weather_Position> aus der Definition des Twilight Devices entfernt werden.
Gruß
Thomas
Da brauche ich Hilfe: Wie und wo kann ich das entfernen?
Zitataus der Definition des Twilight Devices entfernt werden
Auf DEF klicken, Parameter entfernen, auf modify klicken.
Dann stimmt bei mir etwas nicht. Wenn ich auf def klicke sehe ich nur meine Koordinaten des Standortes.
Mach mal ein "list" davon. (genaue Koordinaten kannst Du anonymisieren)
Hier ist das "list"
Internals:
CONDITION 0
DEF 8.4216976 49.9887497 3
FUUID 5c9fc509-f33f-914e-8ad8-94d1c281d486e94c
INDOOR_HORIZON 3
LATITUDE 8.x
LONGITUDE 49x
NAME myTwilight
NR 108
STATE 12
SUNPOS_OFFSET 300
SWIP 1
TYPE Twilight
VERSUCHE 0
WEATHER 0
WEATHER_HORIZON 0
READINGS:
2020-09-02 17:58:05 aktEvent ss_astro
2020-09-02 20:10:24 azimuth 291.01
2020-09-02 20:10:24 compasspoint west
2020-09-02 15:44:24 condition 0
2019-01-25 14:29:46 condition_txt Cloudy
2020-09-02 20:10:24 elevation -50.04
2020-09-02 17:58:05 horizon -18
2020-09-02 17:58:05 light 0
2020-09-02 17:58:05 nextEvent sr_astro
2020-09-02 17:58:05 nextEventTime 03:21:49
2020-09-02 00:00:01 sr 04:35:34
2020-09-02 00:00:01 sr_astro 03:21:49
2020-09-02 00:00:01 sr_civil 04:11:03
2020-09-02 00:00:01 sr_indoor 04:47:48
2020-09-02 00:00:01 sr_naut 03:46:29
2020-09-02 15:44:24 sr_weather 04:35:34
2020-09-02 00:00:01 ss 16:44:24
2020-09-02 00:00:01 ss_astro 17:58:05
2020-09-02 00:00:01 ss_civil 17:08:54
2020-09-02 00:00:01 ss_indoor 16:32:11
2020-09-02 00:00:01 ss_naut 17:33:27
2020-09-02 15:44:24 ss_weather 16:44:24
2020-09-02 17:58:05 state 12
2020-09-02 20:10:24 twilight 0
2020-09-02 20:10:24 twilight_weather 0
TIMER:
myTwilight_Midnight:
HASH myTwilight
MODIFIER Midnight
NAME myTwilight_Midnight
myTwilight_sr:
DEG 0
HASH myTwilight
LIGHT 4
MODIFIER sr
NAME myTwilight_sr
NAMENEXT sr_indoor
STATE 4
SWIP 0
TIME 1599014134.85829
myTwilight_sr_astro:
DEG -18
HASH myTwilight
LIGHT 1
MODIFIER sr_astro
NAME myTwilight_sr_astro
NAMENEXT sr_naut
STATE 1
SWIP 0
TIME 1599009709.82031
myTwilight_sr_civil:
DEG -6
HASH myTwilight
LIGHT 3
MODIFIER sr_civil
NAME myTwilight_sr_civil
NAMENEXT sr
STATE 3
SWIP 0
TIME 1599012663.84528
myTwilight_sr_indoor:
DEG 3
HASH myTwilight
LIGHT 5
MODIFIER sr_indoor
NAME myTwilight_sr_indoor
NAMENEXT sr_weather
STATE 5
SWIP 0
TIME 1599014868.87059
myTwilight_sr_naut:
DEG -12
HASH myTwilight
LIGHT 2
MODIFIER sr_naut
NAME myTwilight_sr_naut
NAMENEXT sr_civil
STATE 2
SWIP 0
TIME 1599011189.83291
myTwilight_sr_weather:
DEG 0
HASH myTwilight
LIGHT 6
MODIFIER sr_weather
NAME myTwilight_sr_weather
NAMENEXT ss_weather
STATE 6
SWIP 1
TIME 1599014134.94523
myTwilight_ss:
DEG 0
HASH myTwilight
LIGHT 3
MODIFIER ss
NAME myTwilight_ss
NAMENEXT ss_civil
STATE 9
SWIP 0
TIME 1599057864.79829
myTwilight_ss_astro:
DEG -18
HASH myTwilight
LIGHT 0
MODIFIER ss_astro
NAME myTwilight_ss_astro
NAMENEXT sr_astro
STATE 12
SWIP 0
TIME 1599062285.82031
myTwilight_ss_civil:
DEG -6
HASH myTwilight
LIGHT 2
MODIFIER ss_civil
NAME myTwilight_ss_civil
NAMENEXT ss_naut
STATE 10
SWIP 0
TIME 1599059334.80528
myTwilight_ss_indoor:
DEG 3
HASH myTwilight
LIGHT 4
MODIFIER ss_indoor
NAME myTwilight_ss_indoor
NAMENEXT ss
STATE 8
SWIP 0
TIME 1599057131.79059
myTwilight_ss_naut:
DEG -12
HASH myTwilight
LIGHT 1
MODIFIER ss_naut
NAME myTwilight_ss_naut
NAMENEXT ss_astro
STATE 11
SWIP 0
TIME 1599060807.81291
myTwilight_ss_weather:
DEG 0
HASH myTwilight
LIGHT 5
MODIFIER ss_weather
NAME myTwilight_ss_weather
NAMENEXT ss_indoor
STATE 7
SWIP 1
TIME 1599057864.84523
myTwilight_sunpos:
HASH myTwilight
MODIFIER sunpos
NAME myTwilight_sunpos
TW:
sr:
DEG 0
LIGHT 4
NAME sr
NAMENEXT sr_indoor
STATE 4
SWIP 0
TIME 1599014134.85829
sr_astro:
DEG -18
LIGHT 1
NAME sr_astro
NAMENEXT sr_naut
STATE 1
SWIP 0
TIME 1599009709.82031
sr_civil:
DEG -6
LIGHT 3
NAME sr_civil
NAMENEXT sr
STATE 3
SWIP 0
TIME 1599012663.84528
sr_indoor:
DEG 3
LIGHT 5
NAME sr_indoor
NAMENEXT sr_weather
STATE 5
SWIP 0
TIME 1599014868.87059
sr_naut:
DEG -12
LIGHT 2
NAME sr_naut
NAMENEXT sr_civil
STATE 2
SWIP 0
TIME 1599011189.83291
sr_weather:
DEG 0
LIGHT 6
NAME sr_weather
NAMENEXT ss_weather
STATE 6
SWIP 1
TIME 1599014134.94523
ss:
DEG 0
LIGHT 3
NAME ss
NAMENEXT ss_civil
STATE 9
SWIP 0
TIME 1599057864.79829
ss_astro:
DEG -18
LIGHT 0
NAME ss_astro
NAMENEXT sr_astro
STATE 12
SWIP 0
TIME 1599062285.82031
ss_civil:
DEG -6
LIGHT 2
NAME ss_civil
NAMENEXT ss_naut
STATE 10
SWIP 0
TIME 1599059334.80528
ss_indoor:
DEG 3
LIGHT 4
NAME ss_indoor
NAMENEXT ss
STATE 8
SWIP 0
TIME 1599057131.79059
ss_naut:
DEG -12
LIGHT 1
NAME ss_naut
NAMENEXT ss_astro
STATE 11
SWIP 0
TIME 1599060807.81291
ss_weather:
DEG 0
LIGHT 5
NAME ss_weather
NAMENEXT ss_indoor
STATE 7
SWIP 1
TIME 1599057864.84523
Attributes:
room Wohnzimmer
version Twilight?
File Rev Last Change
59_Twilight.pm 16005 2018-01-27 06:05:51Z igami
doif.js 15546 2017-12-03 09:57:42Z Ellert
fhemweb.js 21057 2020-01-26 14:04:57Z rudolfkoenig
Hmmm. Das ist doch die letzte Version. Was im Wiki steht scheint nicht zu reichen: hab gerade gesehen, dass alle meine Twilight Devices verbose 2 oder 1 haben.
Hab bei mir kein verbose gesetzt und keinen <Weather_Position>-Parameter angegeben.
Ohne verbose[1-2] kommt bei mir in regelmäßigen Abständen seit Monaten (seit dem rausnehmen des weather_Position-Parameter) im Log:
2020.09.01 00:00:22 3: [Twilight] got no weather info from yahoo. Error code: DNS: Cant find host
2020.09.01 05:48:57 3: [Twilight] got no weather info from yahoo. Error code: DNS: Cant find host
2020.09.01 19:02:47 3: [Twilight] got no weather info from yahoo. Error code: DNS: Cant find host
2020.09.02 00:00:20 3: [Twilight] got no weather info from yahoo. Error code: DNS: Cant find host
2020.09.02 05:50:23 3: [Twilight] got no weather info from yahoo. Error code: DNS: Cant find host
2020.09.02 19:00:42 3: [Twilight] got no weather info from yahoo. Error code: DNS: Cant find host
2020.09.03 00:00:34 3: [Twilight] got no weather info from yahoo. Error code: DNS: Cant find host
2020.09.03 05:51:50 3: [Twilight] got no weather info from yahoo. Error code: DNS: Cant find host
Aber nicht die oben erwähnte Meldung.
defmod Twilight Twilight xx.xxxx x.xxxx -1
attr Twilight devStateStyle style="text-align:left;;font-weight:bold"
attr Twilight event-on-change-reading .*
attr Twilight room Rollladen
attr Twilight stateFormat Winkel: azimuth<br>Sonnenhöhe: elevation
setstate Twilight Winkel: 141.2<br>Sonnenhöhe: 40.71
setstate Twilight 2020-09-03 06:51:51 aktEvent sr
setstate Twilight 2020-09-03 11:31:01 azimuth 141.2
setstate Twilight 2020-09-03 11:31:01 compasspoint southeast
setstate Twilight 2020-09-03 05:51:50 condition 0
setstate Twilight 2020-09-03 11:31:01 elevation 40.71
setstate Twilight 2020-09-03 06:51:51 horizon 0
setstate Twilight 2020-09-03 06:51:51 light 4
setstate Twilight 2020-09-03 06:51:51 nextEvent sr_indoor
setstate Twilight 2020-09-03 06:51:51 nextEventTime 06:45:33
setstate Twilight 2020-09-03 00:00:35 sr 06:51:51
setstate Twilight 2020-09-03 00:00:35 sr_astro 04:50:25
setstate Twilight 2020-09-03 00:00:35 sr_civil 06:13:37
setstate Twilight 2020-09-03 00:00:35 sr_indoor 06:45:33
setstate Twilight 2020-09-03 00:00:35 sr_naut 05:33:36
setstate Twilight 2020-09-03 05:51:50 sr_weather 06:51:50
setstate Twilight 2020-09-03 00:00:35 ss 19:58:36
setstate Twilight 2020-09-03 00:00:35 ss_astro 21:59:18
setstate Twilight 2020-09-03 00:00:35 ss_civil 20:36:41
setstate Twilight 2020-09-03 00:00:35 ss_indoor 20:04:51
setstate Twilight 2020-09-03 00:00:35 ss_naut 21:16:29
setstate Twilight 2020-09-03 05:51:50 ss_weather 19:58:36
setstate Twilight 2020-09-03 06:51:51 state 4
setstate Twilight 2020-09-03 11:31:01 twilight 100
setstate Twilight 2020-09-03 11:31:01 twilight_weather 100
@amenomade: Vielleicht möchtest du das Modul übernehmen? Rudi macht das afaik nur kommissarisch...
Es wäre vermutlich sinnvoll, den nicht funktionierenden yahoo-Teil erst mal einfach zu deaktivieren, das gibt nur unnötige Log-Einträge und ggf. Systemlast wegen unnützer INet-Abfragen?
Evtl. läßt sich das ja auch mit irgendeiner anderen Quelle füttern?
Zitat von: Beta-User am 03 September 2020, 11:47:53
@amenomade: Vielleicht möchtest du das Modul übernehmen? Rudi macht das afaik nur kommissarisch...
Es wäre vermutlich sinnvoll, den nicht funktionierenden yahoo-Teil erst mal einfach zu deaktivieren, das gibt nur unnötige Log-Einträge und ggf. Systemlast wegen unnützer INet-Abfragen?
Evtl. läßt sich das ja auch mit irgendeiner anderen Quelle füttern?
Hat das Twilight Modul nicht der Christoph unter seinen Händen?
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 (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?).
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 (https://forum.fhem.de/index.php/topic,95281.0.html)
Gefühlt ist die Twilight Modul Entwicklung erstmal pausiert.
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 (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
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 s
x_indoor sowie s
x_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.
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...
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
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.
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.
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...
...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).
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?
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?
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.
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.)
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.
Zitat von: Christoph Morrison am 04 September 2020, 10:57:57
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.
InternalTimer gab es schon wo Astro geschrieben wurde soweit ich den Code verstanden habe. Was es aber nicht gab war eine Möglichkeit die angelaufenen Timer sauber wieder zu löschen. Das hat Dietmar damals implementiert.
Grüße
Das mit dem "alten" eigenen RemoveInternalTimer habe ich gefunden, das war in (Weekday|Random)Timer bereits komplett raus gewesen (und ist in Twilight auskommentiert).
Wie CoolTux schreibt ist das eigentliche gemeinsame Thema, den "richtigen" von mehreren InternalTimer zu finden, wenn sich der Code selbst aufruft. Das würde ggf. Sinn machen, irgendwo zentral verfügbar zu sein (gibt's da schon was in den ASC-Funktionen? Da dürfte das Problem ja auch bestehen...?).
Die Diskussion über "falsche" Zeiten kenne ich aus der SUNRISE_EL-Ecke und bin nicht so richtig sicher, ob es da nicht auch ("neuere") Unterfunktionen gäbe (die _abs oder _date-Varianten), die das ggf. "besser" können, der Unterschied liegt afaik bei ein paar Minuten, auf die es mir persönlich nicht ankäme. Eventuell würde ich das ganze dann auf diese Abhängigkeit umstellen?
Aber wie gesagt, mir ginge es eher darum, das Ding "as is" am Laufen zu halten, mit langwierigen Diskussionen über "noch bessere" Astro-Daten wollte ich mich eigentlich nicht belasten ::) . Dann würde ich aber Rückmeldung brauchen, welche SUNRISE_EL-Funktion denn zu welchem Reading am besten paßt und ob jemand an der alten Methode bzw. ihren Ergebnissen hängt...
Grundsätzlich habe ich nichts gegen gewisse Abhängigkeiten, aber es sollte eben schon auch auf Testsystemen funktionieren.
Zitat von: Beta-User am 04 September 2020, 11:44:03
Das mit dem "alten" eigenen RemoveInternalTimer habe ich gefunden, das war in (Weekday|Random)Timer bereits komplett raus gewesen (und ist in Twilight auskommentiert).
Wie CoolTux schreibt ist das eigentliche gemeinsame Thema, den "richtigen" von mehreren InternalTimer zu finden, wenn sich der Code selbst aufruft. Das würde ggf. Sinn machen, irgendwo zentral verfügbar zu sein (gibt's da schon was in den ASC-Funktionen? Da dürfte das Problem ja auch bestehen...?).
Ich gebe jedem InternalTimer einen eigenen Hashwert mit welchen ich zwischenspeicher. Anhand deses Hashs kann ich dann genau den entsprechenden Timer löschen. Ich gebe also kein Instanzhash mit.
Dies kann man aber auch machen und muss dann den beim InternalTimer mit übergebenen Funktionsnamen beim Remove mitgeben.
Hmm, müßte ich mir evtl. mal ansehen, wie du das genau machst. Eigentlich klingt das genau nach "MkInternalTimer"/"RmInternalTimer" in RandomTimer.
(Ich sollte mir nur ggf. mal etwas besse zurodenbare Namen für die Funktionen überlegen, damit die in fhemdebug auch dem RT zugehörig erkennbar sind. "Exec" ist jetzt nicht so der Brüller...).
Zu guter Letzt auch nochmal eine neuere Version zum Testen, da sind die ganzen Prototypes raus und manches andere, was mir so beim intensiveren ersten Durchgang aufgefallen war (hoffentlich ohne irgendwelche funktionalen Änderungen).
So, mit dem normalen FHEM-update nachher käme dann eine Fassung, die auch die neuen Log-Einträge bis auf den beabsichtigten vermeidet. Rückmeldung dann bitte im offiziellen support-Thread lt. Maintainer.txt.