Yahoo Wetter

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

Vorheriges Thema - Nächstes Thema

CoolTux

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
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

Beta-User

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.
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

CoolTux

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.
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

Beta-User

#33
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).
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

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. 
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