Funktion zum Überprüfen ob ein InternalTimer exitiert

Begonnen von igami, 07 März 2017, 09:03:14

Vorheriges Thema - Nächstes Thema

igami

Ich wünsche mir eine Funktion mit der ich überprüfen kann ob ein InternalTimer exitiert.
Diese könnte so aussehen:

sub
CheckInternalTimer($;$)
{
  my ($arg, $fn) = @_;
  foreach my $a (keys %intAt) {
    return($intAt{$a}{TRIGGERTIME}) if($intAt{$a}{ARG} eq $arg &&
                                      (!$fn || $intAt{$a}{FN} eq $fn));
  }
  return;
}

Aufgerufen wird diese dann wie RemoveInternalTimer und gibt den Ausführungszeitpunkt zurück, falls der Timer existiert.
Pi3 mit fhem.cfg + DbLog/logProxy
Komm vorbei zum FHEM Treffen im Kreis Gütersloh! Das nächste Mal im April 2020.

MAINTAINER: archetype, LuftdatenInfo, monitoring, msgDialog, Nmap, powerMap
ToDo: AVScene, FluxLED

rudolfkoenig

ZitatIch wünsche mir eine Funktion mit der ich überprüfen kann ob ein InternalTimer exitiert.
Warum?

igami

Ich schreibe gerade an einem monitoring Modul welches devices erst auf eine warning und dann auf eine error Liste setzt nachdem ein ein Ereignis eingetroffen ist und in einer gewissen Zeit nicht ein Ereignis zwei empfangen wurden. Imprinzip ein erweitertes watchdog welches ich für Sammelmeldungen verwernden will.

Beispiel einer Sammelmeldung für Geräte mit einer niedrigen Batteriespannung:

defmod battery_monitoring monitoring .*:battery:.low .*:battery:.ok
attr battery_monitoring errorWait 60*15

setstate battery_monitoring error add: HM_36CF07
setstate battery_monitoring 2017-03-07 07:20:05 error HM_26B05C,HM_36CF07
setstate battery_monitoring 2017-03-07 07:20:05 state error add: HM_36CF07
setstate battery_monitoring 2017-03-07 07:20:05 warning

Über weitere Attribute lässt sich auch die Ausgabe formatieren:

attr battery_monitoring errorReturn {return unless(@errors);;\
return("Bei dem Gerät \"$errors[0]\" muss die Batterie gewechselt werden.") if(int(@errors) == 1);;\
$_ = AttrVal($_, "alias", $_) for(@errors);;\
@errors = sort {lc($a) cmp lc($b)} @errors;;\
return(join("\n - ", 'Bei den folgenden Geräten muss die Batterie gewechselt werden:', @errors));;\
}
attr battery_monitoring warningReturn {return unless(@warnings);;\
return("Bei dem Gerät \"$warnings[0]\" muss die Batterie demnächst gewechselt werden.") if(int(@warnings) == 1);;\
$_ = AttrVal($_, "alias", $_) for(@warnings);;\
@warnings = sort {lc($a) cmp lc($b)} @warnings;;\
return(join("\n - ", 'Bei den folgenden Geräten muss die Batterie demnächst gewechselt werden:', @warnings));;\
}


Wenn nun nicht event-on-change-reading auf battery gesetzt ist würde der Timer erneut gestartet werden. Da das nicht gewollt ist kam mir in den Sinn zu überprüfen ob ein solcher Timer schon läuft.
Pi3 mit fhem.cfg + DbLog/logProxy
Komm vorbei zum FHEM Treffen im Kreis Gütersloh! Das nächste Mal im April 2020.

MAINTAINER: archetype, LuftdatenInfo, monitoring, msgDialog, Nmap, powerMap
ToDo: AVScene, FluxLED

rudolfkoenig

ZitatWenn nun nicht event-on-change-reading auf battery gesetzt ist würde der Timer erneut gestartet werden.
Ich verstehe das nicht, vermutlich weil ich nur einen winzigen Teil der noetigen Infos dazu habe.

Ein Modul sollte es selbst wissen, ob es einen Timer gestartet hat oder nicht. Falls man Probleme hat das zu merken, dann sollte man darueber nachdenken, ob man nicht mit weniger (einen?) TImer auskommt.

Ob ein anderes Modul einen Timer gestartet hat oder nicht, geht es nur diesen Modul was an.

igami

Zitat von: rudolfkoenig am 07 März 2017, 12:00:34
Ein Modul sollte es selbst wissen, ob es einen Timer gestartet hat oder nicht. Falls man Probleme hat das zu merken, dann sollte man darueber nachdenken, ob man nicht mit weniger (einen?) TImer auskommt.
Jetzt wo du es sagst speicher ich sogar im device ab, dass ich einen Timer gestartet habe um den Timer nach einen Neustart erneut zu setzen ::)
Pi3 mit fhem.cfg + DbLog/logProxy
Komm vorbei zum FHEM Treffen im Kreis Gütersloh! Das nächste Mal im April 2020.

MAINTAINER: archetype, LuftdatenInfo, monitoring, msgDialog, Nmap, powerMap
ToDo: AVScene, FluxLED

justme1968

warum ein modul? das geht doch mit ein oder zwei notifys und einem benannten sleep... :)

aber im ernst: hast du dir mal das DeviceMonitor modul aus contrib angeschaut? vielleicht könnte man das etwas erweitern und dann offiziell einchecken. aktuell hat es glaube ich keinen maintainer.

gruss
  andre



hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

igami

Zitat von: justme1968 am 07 März 2017, 13:13:56
warum ein modul? das geht doch mit ein oder zwei notifys und einem benannten sleep... :)
Weil ich den Monitor für alles mögliche benutzen und eine für menschen lesbare ausgabe im device definieren möchte. Klar kann man sich ein notify mit userreadings und myUtils soweit aufbohren, aber da schreibe ich doch lieber ein Modul :) Anstoss war https://forum.fhem.de/index.php/topic,65437.msg566514.html#msg566514

Zitat von: justme1968 am 07 März 2017, 13:13:56
aber im ernst: hast du dir mal das DeviceMonitor modul aus contrib angeschaut? vielleicht könnte man das etwas erweitern und dann offiziell einchecken. aktuell hat es glaube ich keinen maintainer.
schaue ich mir nachher mal in Ruhe an, scheint auf den ersten Blick einen anderen Ansatz zu haben.
Mein aktueller code: https://github.com/Igami/monitoring-fhem/blob/master/98_monitoring.pm

Sobald ich eine lauffähige und dokumentierte Version fertig habe stelle ich das mal vor. Ist von der Idee her nur ein erweiterter Watchdog der die beiden beliebten Themen "globale Fensteroffen Meldung" und "Batterieüberwachung" abdecken kann. Hierbei habe ich dann zwei Listen, warning und error, um zu sehen welche devices "battery: low" melden und welche das schon seit Zeit X machen und wirklich mal getauscht werden sollten.
Pi3 mit fhem.cfg + DbLog/logProxy
Komm vorbei zum FHEM Treffen im Kreis Gütersloh! Das nächste Mal im April 2020.

MAINTAINER: archetype, LuftdatenInfo, monitoring, msgDialog, Nmap, powerMap
ToDo: AVScene, FluxLED

igami

Pi3 mit fhem.cfg + DbLog/logProxy
Komm vorbei zum FHEM Treffen im Kreis Gütersloh! Das nächste Mal im April 2020.

MAINTAINER: archetype, LuftdatenInfo, monitoring, msgDialog, Nmap, powerMap
ToDo: AVScene, FluxLED