Autor Thema: Funktion zum Überprüfen ob ein InternalTimer exitiert  (Gelesen 219 mal)

Offline igami

  • Hero Member
  • *****
  • Beiträge: 1439
  • RTFM
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 DbLog/logProxy
HM, HUE, KNX, RFX, AMAD, harmony, TelegramBot, Squeezebox/Squeezelite, alexa
archetype, monitoring, Nmap
Gib einem Mann einen Fisch und du ernährst ihn für einen Tag. Lehre einen Mann zu fischen und du ernährst ihn für sein Leben.
Zustimmung Zustimmung x 1 Liste anzeigen

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 15704
Antw:Funktion zum Überprüfen ob ein InternalTimer exitiert
« Antwort #1 am: 07 März 2017, 10:21:44 »
Zitat
Ich wünsche mir eine Funktion mit der ich überprüfen kann ob ein InternalTimer exitiert.
Warum?

Offline igami

  • Hero Member
  • *****
  • Beiträge: 1439
  • RTFM
Antw:Funktion zum Überprüfen ob ein InternalTimer exitiert
« Antwort #2 am: 07 März 2017, 10:38:50 »
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 DbLog/logProxy
HM, HUE, KNX, RFX, AMAD, harmony, TelegramBot, Squeezebox/Squeezelite, alexa
archetype, monitoring, Nmap
Gib einem Mann einen Fisch und du ernährst ihn für einen Tag. Lehre einen Mann zu fischen und du ernährst ihn für sein Leben.

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 15704
Antw:Funktion zum Überprüfen ob ein InternalTimer exitiert
« Antwort #3 am: 07 März 2017, 12:00:34 »
Zitat
Wenn 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.

Offline igami

  • Hero Member
  • *****
  • Beiträge: 1439
  • RTFM
Antw:Funktion zum Überprüfen ob ein InternalTimer exitiert
« Antwort #4 am: 07 März 2017, 12:37:19 »
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 DbLog/logProxy
HM, HUE, KNX, RFX, AMAD, harmony, TelegramBot, Squeezebox/Squeezelite, alexa
archetype, monitoring, Nmap
Gib einem Mann einen Fisch und du ernährst ihn für einen Tag. Lehre einen Mann zu fischen und du ernährst ihn für sein Leben.

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15735
Antw:Funktion zum Überprüfen ob ein InternalTimer exitiert
« Antwort #5 am: 07 März 2017, 13:13:56 »
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



FHEM5.4,DS1512+,2xCULv3,DS9490R,HMLAN,2xRasPi
CUL_HM:HM-LC-Bl1PBU-FM,HM-LC-Sw1PBU-FM,HM-SEC-MDIR,HM-SEC-RHS
HUEBridge,HUEDevice:LCT001,LLC001,LLC006,LWL001
OWDevice:DS1420,DS18B20,DS2406,DS2423
FS20:fs20as4,fs20bs,fs20di
AKCP:THS01,WS15
CUL_WS:S300TH

Offline igami

  • Hero Member
  • *****
  • Beiträge: 1439
  • RTFM
Antw:Funktion zum Überprüfen ob ein InternalTimer exitiert
« Antwort #6 am: 07 März 2017, 15:38:12 »
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

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 DbLog/logProxy
HM, HUE, KNX, RFX, AMAD, harmony, TelegramBot, Squeezebox/Squeezelite, alexa
archetype, monitoring, Nmap
Gib einem Mann einen Fisch und du ernährst ihn für einen Tag. Lehre einen Mann zu fischen und du ernährst ihn für sein Leben.

Offline igami

  • Hero Member
  • *****
  • Beiträge: 1439
  • RTFM
Antw:Funktion zum Überprüfen ob ein InternalTimer exitiert
« Antwort #7 am: 09 März 2017, 22:14:05 »
Erste Version ist fertig: neues Modul 98_monitoring
Pi3 mit DbLog/logProxy
HM, HUE, KNX, RFX, AMAD, harmony, TelegramBot, Squeezebox/Squeezelite, alexa
archetype, monitoring, Nmap
Gib einem Mann einen Fisch und du ernährst ihn für einen Tag. Lehre einen Mann zu fischen und du ernährst ihn für sein Leben.