[98_monitoring] - Support Thread ab 2022

Begonnen von Beta-User, 01 März 2022, 15:16:59

Vorheriges Thema - Nächstes Thema

ChrisH

Zitat von: Marcel_R am 29 Februar 2024, 16:07:27...

Wenn ich dies richtig sehe, gibt ChrisH als wesentlichen Unterschied in seinem funktionierenden Beispiel den winOpenTimer nicht in Sekunden, sondern in Std:min:sek an.

Oder übersehe ich etwas?
Gruss Marcel

mein Beispiel funktioniert auch nicht wie gewollt.

Ich habe jetzt mal ein Dachfenster umgestellt:
...
attr Fensterkontakt_Arbeitszimmer winOpenTimer 13*60
...


Ging aber wieder sofort auf Critical.

Beta-User

Hmmm, muss mich dazu leider vertieft in den Code eindenken, was die kommenden Wochen leider schwierig wird.

Falls jemand Lust hat, kann er gerne mal checken, ob es mit der Modulvariante vor dem Umbau (also ca. aus 2021) ging, oder ob es auf den Umbau zurückzuführen ist... Bitte aber nicht einfach einen reload machen, sondern FHEM komplett neu starten, wenn die alte Moduldatei eingespielt ist! Dto. beim Wechsel wieder auf die aktuelle Variante.
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

Marcel_R

Danke Beta-User - das ist sehr nett, dass Du Dich bereits in unsere Sorgen ein geklinkt hast, geschweige denn Dich in einiger Zeit in den Code tiefer einzuarbeiten gedenkst.

Ohne Gegenbericht werde ich mich in Anfängerfragen kundig machen, wo, bzw. wie, die alte Variante herunter geladen werden kann (unter https://github.com/mhop/fhem-mirror/blob/master/fhem/FHEM/98_monitoring.pm werde ich nicht klug...)

Gruss
Marcel

FHEM / Fritz!Box 7490 / CULv3 / Raspi / COC / MAX! / HomeMatic /

ChrisH

Zitat von: Beta-User am 01 März 2024, 20:28:57...
Falls jemand Lust hat, kann er gerne mal checken, ob es mit der Modulvariante vor dem Umbau (also ca. aus 2021) ging, oder ob es auf den Umbau zurückzuführen ist... Bitte aber nicht einfach einen reload machen, sondern FHEM komplett neu starten, wenn die alte Moduldatei eingespielt ist! Dto. beim Wechsel wieder auf die aktuelle Variante.


Was habe ich gemacht:
  • Von der Webseite mir den Code von der Zeit angesehen und zu `fhem/FHEM/98_monitoring.pm` geklickt
  • raw download
  • fhem gestoppt
  • File auf meine fhem server kopiert und ower/group permission angepasst
  • fhem gestartet
  • Fenster auf und zu und dabei ins log und auf die Webseite geschaut.



Test 1: ca. 2020
https://github.com/mhop/fhem-mirror/blob/15b4e5756ffbb8e04715aec17ecfd69e3a472899/fhem/FHEM/98_monitoring.pm

geht auch direkt auf ERROR:
2024.03.02 17:58:38 4: monitoring (Fenster_monitoring) triggered by "Fensterkontakt_Arbeitszimmer open"
2024.03.02 17:58:38 5: monitoring (Fenster_monitoring) errorFuncAdd and errorFuncRemove are preset
2024.03.02 17:58:38 5: monitoring (Fenster_monitoring) addRegex (Fensterkontakt_.*:open) and removeRegex (Fensterkontakt_.*:closed) are defined
2024.03.02 17:58:38 5: monitoring (Fenster_monitoring)
    entering monitoring_modify
        reading:  error
        operation: add
        value:    Fensterkontakt_Arbeitszimmer
        at:        now
2024.03.02 17:58:38 5: monitoring (Fenster_monitoring)
    entering monitoring_modify
        reading:  warning
        operation: remove
        value:    Fensterkontakt_Arbeitszimmer
        at:        now




noch etwas aelter probiert:
https://github.com/mhop/fhem-mirror/blob/e7ca7a6ea6cf65c82b202e303969ebe21d964757/fhem/FHEM/98_monitoring.pm

2024.03.02 18:02:46 4:  (Fenster_monitoring) triggered by "Fensterkontakt_Arbeitszimmer open"
2024.03.02 18:02:46 5: monitoring (Fenster_monitoring) errorFuncAdd and errorFuncRemove are preset
2024.03.02 18:02:46 5: monitoring (Fenster_monitoring) addRegex (Fensterkontakt_.*:open) and removeRegex (Fensterkontakt_.*:closed) are defined
2024.03.02 18:02:46 5: monitoring (Fenster_monitoring)
    entering monitoring_modify
        reading:  error
        operation: add
        value:    Fensterkontakt_Arbeitszimmer
        at:        now
2024.03.02 18:02:46 5: monitoring (Fenster_monitoring)
    entering monitoring_modify
        reading:  warning
        operation: remove
        value:    Fensterkontakt_Arbeitszimmer
        at:        now

Fuer mich klappt es also mit alten Versionen auch nicht.


Ich suche mal weiter.

christian

ChrisH

Heureka. Ich habe den Boesewicht gefunden und auch einen work around, aber mein Perl Know-How und FHEM interna Wissen ist fuer eine Fix Vorschlag zu gering.

Ursache gezeigt mit meinem mit Log3 durchgezogenem Code:
sub Notify {
      ...
      $cmd  = EvalSpecials($cmd, %specials);
      Log3 ($SELF, 5, "Notify: 2. cmd: $cmd and specials: %specials");

      # CMD ausführen
      my $listWait = AnalyzePerlCommand( $hash, $cmd );
      Log3 ($SELF, 5, "Notify: listWait 1: $listWait ");
      $listWait = 0 if !looks_like_number($listWait);
      Log3 ($SELF, 5, "Notify: listWait 2: $listWait ");



Liefert beim Fensterkontakt_Arbeitszimmer folgenden Logauszug. die beiden Zeilen listWait 1 und 2 vergleichen,

2024.03.05 21:55:35 5: Notify: specials $name: Fensterkontakt_Arbeitszimmer
2024.03.05 21:55:35 5: Notify: 2. cmd: { AttrVal($name, 'winOpenTimer', 60*10) } and specials: %specials
2024.03.05 21:55:35 5: Notify: listWait 1: 780
2024.03.05 21:55:35 5: Notify: listWait 2: 780
2024.03.05 21:55:35 5: Notify: addMatch != 0
2024.03.05 21:55:35 5: Notify: removeMatch NULL
2024.03.05 21:55:35 5: Notify: listWait: 780


Und beim Fensterkontakt_Duschbad folgendes:

2024.03.05 22:04:28 5: Notify: specials $name: Fensterkontakt_Duschbad
2024.03.05 22:04:28 5: Notify: 2. cmd: { AttrVal($name, 'winOpenTimer', 60*10) } and specials: %specials
2024.03.05 22:04:28 5: Notify: listWait 1: 00:35:00
2024.03.05 22:04:28 5: Notify: listWait 2: 0
2024.03.05 22:04:28 5: Notify: addMatch NULL
2024.03.05 22:04:28 5: Notify: removeMatch != 0
2024.03.05 22:04:28 5: Notify: listWait: 0


Als ich den Arbeitszimmer noch auf 13*60 hatte saht das so aus:
2024.03.05 21:41:22 5: Notify: 2. cmd: { AttrVal($name, 'winOpenTimer', 60*10) } and specials: %specials
2024.03.05 21:41:22 5: Notify: listWait 1: 13*60
2024.03.05 21:41:22 5: Notify: listWait 2: 0

Beim Fensterkontakt_Arbeitszimmer habe ich dann winOpenTimer auf 780 gesetzt und bei Fensterkontakt_Duschbad winOpenTimer 00:35:00 gehabt.


Nach meiner Einschaetzung funktioniert daher AnalyzePerlCommand nicht wie erwartet und liefert keinen Integer sondern ggf. eine Zeitdarstellung zurueck.
Bei einer Zeitdarstellung wird der Wert immer auf 0 gesetzt da looks_like_number nicht true ist.

work-around: winOpenTimer in Sekunden angeben, nicht als 10*60 oder 00:35:00

Loesung:
my $listWait = AnalyzePerlCommand( $hash, $cmd );so umschreiben das dort beliebige sinnvolle Varianten gesetzt werden koennen. Das kann ich aber nicht.  :(


Marcel_R

Danke ChrisH für Deine Detektivarbeit. Leider reichen meine Programmierkenntnisse knappestens um Deinen Ausführungen zu verfolgen.

Auf jeden Fall funktionierte bei meinem Test der work-around.

Marcel
P.S.: Vielleicht kann jemand mit Befugnis in der commandref den Text 'The waiting time can be set for each device via userattr "winOpenTimer"' mit '(in seconds)'.
FHEM / Fritz!Box 7490 / CULv3 / Raspi / COC / MAX! / HomeMatic /

Beta-User

Danke auch von meiner Seite; dann scheine ich jedenfalls nichts kaputt gemacht zu haben.

Für die Änderungshistory ist es m.E. am einfachsten, ins svn zu sehen, für monitoring wäre das: https://svn.fhem.de/trac/log/trunk/fhem/FHEM/98_monitoring.pm.

Werde beizeiten nicht die commandref anpassen, sondern mal sehen, ob sich der Code nicht dahin ändern läßt, dass die Zeit-Angaben da in allen angegebenen Fassungen eingegeben werden können... Wird aber vermutlich etwas dauern.
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

#52
So, anbei eine leider mangels Testsystem ungetestete Fassung, die mit HH:MM bzw. HH:MM:SS klarkommen sollte.

Wenn das jemand testen könnte, wäre das super, dann checke ich das bei Gelegenheit ein.
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

ChrisH

Zitat von: Beta-User am 08 März 2024, 18:06:40So, anbei eine leider mangels Testsystem ungetestete Fassung, die mit HH:MM bzw. HH:MM:SS klarkommen sollte.

Wenn das jemand testen könnte, wäre das super, dann checke ich das bei Gelegenheit ein.

Funktioniert, mit dieser kleinen Korrekturen:

um zeile 365 steht ein $hr das durch ein $hour ersetzt werden muss. Ich haenge eine korrigierte Fassung zur Pruefung durch andere an.
Du darfst diesen Dateianhang nicht ansehen.

Ich habe den Fix in meine instrumentierte Version eingebaut.

Danke!

Christian

Beta-User

Zitat von: ChrisH am 08 März 2024, 19:04:03Funktioniert, mit dieser kleinen Korrekturen:

um zeile 365 steht ein $hr das durch ein $hour ersetzt werden muss. Ich haenge eine korrigierte Fassung zur Pruefung durch andere an.
Du darfst diesen Dateianhang nicht ansehen.

Ich habe den Fix in meine instrumentierte Version eingebaut.

Danke!

Christian
Sorry für den Fehler beim Zusammenkopieren :-[ ...

Hab' eben die korrigierte Fassung eingecheckt, Danke für den support!!!
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