neues Modul 98_readingsWatcher , war 98_ReadingsSupervision

[Wzut]

@dirk.k  & all,
bitte mal die angehängte Version testen bevor ich sie hochlade, da ich einges ändern musste.
Was ich jetzt aus Zeitmangel noch nicht testen konnte ist ein Mischbetrieb von AND und OR innnerhalb von einem Device
also z.B. so etwas :

Code Auswählen Erweitern

attr Heinz readingsWatcher 300,???,T1,T2;600,,T3+T4
oder
attr Heinz readingsWatcher 300,???,T1+T2;600,,T3,T4

Beim Testen bitte auch die Readings vom Watcher Device selber (und auch das Log) beachten, das da noch alles stimmt.

[dirk.k]

Hi Wzut,
danke für die schnelle Reaktion.
Bei Einsatz von "7,???,temperature++humidity++testreading" bzw. "7,???,temperature,humidity,testreading" funktioniert die und/oder Verknüpfung auf den ersten Blick gut.
Kurzzeitig/temporär hatte ich im Readingswatcher aber ein Reading "SD_WS07_TH_3_" mit dem Wert "no Timestamp".
Das ist aber wieder verschwunden.

Die Möglichkeit und/oder zu mischen wird ganz schön komplex und für meinen Kopf gerade zu viel. Ich denke, eine einmalige Entscheidung würde reichen, ob ein einzelnes ausgefallenes Reading oder alle zum Gerätestatus "dead" führen. 
Mit einem optionalen Parameter nach den ersten Werten ... evtl. so:
attr Heinz readingsWatcher 300,???,T1,T2,or;600,,T3,T4 (== attr Heinz readingsWatcher 300,???,T1,T2;600,,T3,T4)
attr Heinz readingsWatcher 300,???,T1,T2,and;600,,T3,T4
aber evtl. auch einfach so, dass ein
attr Heinz readingsWatcher 300,???,T1+T2;600,,T3,T4 für alle Readings das ++ bedeutet...
(Damit wäre es das gleiche wie ein attr Heinz readingsWatcher 300,???,T1+T2;600,,T3+T4 und auch das Verhalten zwischen den 2 Wertepaaren wäre klar)

 

[Wzut]

aber evtl. auch einfach so, dass ein

genau, ich bin eben nochmal die Logik im Modul durchgegangen. Wenn einmal pro Device ein + vorhanden ist bestimmt es wie das Device komplett zu behandeln ist.
D.h AND schlägt  OR

Ok, dann werde ich das so eimchecken

[LuckyDay]

Ich habe mehrere Device , wo das state überwacht wird

Code Auswählen Erweitern

attr FHEM_HC readingsWatcher 61,dead,state

allerdings --> wenn es kein state Reading gibt, --> wird das Reading

Code Auswählen Erweitern

setstate FHEM_HC unkown
setstate FHEM_HC 2020-01-19 15:01:08 no_Timestamp unkown

soweit so gut, da es kein Timestamp/reading gibt.

allerdings hätte ich jetzt erwartet, nach dem zweiten Durchlauf erwartet, dass das Reading auf dead geht.

stattdessen

alle Minute+1sek im Fhemlog

Code Auswählen Erweitern

2020.01.19 15:08:08.110 2: AKTIV, insufficient parameters for device FHEM_HC - skipped !
2020.01.19 15:07:08.110 2: AKTIV, insufficient parameters for device FHEM_HC - skipped !
2020.01.19 15:06:08.109 2: AKTIV, insufficient parameters for device FHEM_HC - skipped !
2020.01.19 15:05:08.108 2: AKTIV, insufficient parameters for device FHEM_HC - skipped !
2020.01.19 15:04:08.108 2: AKTIV, insufficient parameters for device FHEM_HC - skipped !
2020.01.19 15:03:08.107 2: AKTIV, insufficient parameters for device FHEM_HC - skipped !

Ich bin auch der Meihnung, das die Meldung im Fhemlog als verbose 2 nicht zu suchen hat

Code Auswählen Erweitern



Internals:
   .FhemMetaInternals 1
   DEF        global
   FUUID      5d72b586-f33f-8631-9236-38d6bd787ef68f83
   FVERSION   98_readingsWatcher.pm:v1.6.0-s20957/2020-01-12
   INTERVAL   60
   NAME       AKTIV
   NR         25
   STATE      ok
   TYPE       readingsWatcher
   .attraggr:
   .attreocr:
     .*
   .attrminint:
   OLDREADINGS:
   READINGS:
     2020-01-19 15:11:08   .associatedWith FB_1und1,FB_TCom,FHEM_HC,FHEM_HM,FHEM_HZ,FHEM_Inet,FHEM_Test
     2020-01-19 15:11:08   FB_1und1_box_ipExtern ok
     2020-01-19 15:11:08   FB_TCom_box_ipExtern ok
     2020-01-19 15:11:08   FHEM_HC_state   no Timestamp
     2020-01-19 15:11:08   FHEM_HM_state   ok
     2020-01-19 15:11:08   FHEM_HZ_state   ok
     2020-01-19 15:11:08   FHEM_Inet_state ok
     2020-01-19 15:11:08   FHEM_Test_state ok
     2020-01-19 15:11:08   alive           6
     2020-01-19 15:11:08   dead            0
     2020-01-19 15:11:08   deadDevs        none
     2020-01-19 15:11:08   devices         7
     2020-01-19 15:11:08   readings        6
     2020-01-19 15:11:08   skipped         1
     2020-01-19 15:11:08   skippedDevs     FHEM_HC
     2020-01-19 15:11:08   state           ok
     2020-01-19 15:11:08   timeoutdevs     none
     2020-01-19 15:11:08   timeouts        0
Attributes:
   event-on-change-reading .*
   interval   60
   readingActivity no_Timestamp:dead:alive



skippedDevs     FHEM_HC ist für mein Empfinden falsch, es ist einfach tot in dem Moment.

Wenn ich ein setreading state ... mache dann geht das Device auch auf dead

[Wzut]

IMHO "wokrs as designed"
a. wenn es kein Reading state gibt dann macht es keinen Sinn zu versuchen das nicht vorhandene Reading zu übewachen.
b. das wertet das Modul als config Fehler des Anwenders , überspringt das Device (skipped) und teilt das dem User auch via Log mit.
c. Level 2 halte ich für angemessen, da durch diesen Fehler das Modul nicht  so arbeiten kann wie es der User erwartet.
Ist dir Level 2 zu hoch dann setze dein AKTIV Device runter auf verbose 1 oder noch besser : überwache ein Reading das es tatsächlich gibt  

[LuckyDay]

IMHO "wokrs as designed"

Schade , Leider so dann "unbrauchbar" 

a. wenn es kein Reading state gibt dann macht es keinen Sinn zu versuchen das nicht vorhandene Reading zu übewachen.

leider meldelt sich das Gerät ja nicht, deswegen kann (bei mir)auch kein Reading da sein-->ergo ist es tot und kein configFehler.

Ich denke mal du gehst davon aus, dass jedes Gerät nach Fhemstart ein Reading hat, es wäre mir neu, dass dies eine Pflicht wäre.

Verbose1 ist keine Lösung für mich.

[Wzut]

Ich denke mal du gehst davon aus, dass jedes Gerät nach Fhemstart ein Reading hat, es wäre mir neu, dass dies eine Pflicht wäre.

ähh richtig , da zumindest alles was ich im Einsatz habe ein Reading hat und wenn es ein altes ist das via fhem.save und setstate restauriert wurde.
Natürlich ist es keine Pflicht, aber ich bin trotz meines Alters durchaus noch lernfähig, daher verrate mir doch bitte um welchen Device Typ es sich hier handelt der so bescheiden mit seinen Ausgaben ist und wann das Gerät denn beginnt zu sprechen.

[LuckyDay]

via fhem.save

bei mir wird nur "fhem.save" bei "shutdown restart" geladen

bei Stromausfall oder Debian reboot, wird die fhem.save (bei mir) nicht geladen. Alte Zustände will ich nicht.
dafür werden alle Zustände , sofern möglich, via Status Abfrage abgefragt, oder die Geräte melden sich selber.

Device Typ es sich hier handelt

Code Auswählen Erweitern

Internals:
   .triggerUsed 1
   DEVICETOPIC FHEM_HC
   FUUID      5e014f96-f33f-8631-964c-3185fbc79a76d8ba
   IODev      mqttclient_localhost
   NAME       FHEM_HC
   NR         70
   STATE      dead
   TYPE       MQTT2_DEVICE
   .attraggr:
   .attrminint:
   OLDREADINGS:
   READINGS:
     2020-01-19 19:14:08   no_Timestamp    dead
     2020-01-19 15:23:25   state           dead
Attributes:
   IODev      mqttclient_localhost
   group      FHEMs
   readingList haus/HC1/Fhem_HC1_live/state:.* state
   readingsWatcher 61,dead,state
   room       test
   stateFormat no_Timestamp

da steht nicht wirkich etwas drin. alle 30 Sekunden kommt auf dem topic ein "on" und wird ins state geschrieben, wenn das Device am Leben ist!


HM AKTIONDEDCTOR macht es auch so nach Neustart, device ist unknown , solange bis actCycle abgelaufen ist --> dann dead

[Wzut]

HM AKTIONDEDCTOR macht es auch so nach Neustart, device ist unknown , solange bis actCycle abgelaufen ist --> dann dead

der hat es auch etwas einfacher, er kennt "seine" Pappemheimer und kann entsprechend handeln, hier bestimmt aber der User und wenn er sich beim Readingsnamen einfach nur vertippt hat soll er kein neues Reading mit Gewalt ins Device gedrückt bekommen.
D.h. wie also unterscheiden zwischen einem "falsch" geschrieben Namen, das niemals da sein wird und einem echten das eben nur noch nicht da ist ?
Ich habe das mal ausprobiert und kann mit einer Lösung leben :

a. das "ungültige" Reading ist state ( auch wenn man das enfalls "falsch" schreiben kann )
und b. der User muß durch ein gesetztes ErrorValue (61,dead,state -> dead in diesem Fall ) dem RW Device das schreiben im Device erlaubt haben,
d.h. in diesem Fall ist es nicht nur schreiben sonder sogar erzeugen.

Verbose1 ist keine Lösung für mich.

verstehe ich auch nicht, ich meinte kein globales verbose 1 oder an dem MQTT Device sondern am RW Device.
Anyway, auch mit der eben beschriebenen Sonderlösung bliebe zumindest ein Log Eintrag übrig bis das Reading erzeugt wurde (von wem auch immer)   


   

[LuckyDay]

er User muß durch ein gesetztes ErrorValue (61,dead,state -> dead in diesem Fall ) dem RW Device das schreiben im Device erlaubt haben

Wo soll denn das -->ErrorValue sein?

[Wzut]

in deinem Fall ist es dead -> readingsWatcher 61,dead,state
weil es ja auch zulässig ist das das Modul die überwachten Readings nicht verändern darf -> readingsWatcher 61,,state

[tomcat.x]

Wenn wir gerade bei dem ErrorValue sind: Bei mir wird der nicht mehr gesetzt. readingsWatcher erkennt den Zustand der "fehlerhaften" Geräte, listet Anzahl und Gerätenamen in "dead" bzw. "deadDevs" und setzt auch das über "readingActivity" definierte Attribut in den Geräten richtig. Nur der Wert des überwachten Attributs wird nicht mehr geändert.

Hat das noch jemand?

Hätte ich aufgrund der letzten hier diskutierten Änderungen etwas am Attribut "readingsWatcher" in den überwachten Gräten ändern müssen oder im Gerät readingsWatcher etwas neu setzen müssen?

Im readingsWatcher Gerät habe ich mal Verbose hoch gesetzt und ein checkNow ausgelöst, aber da kommt rein gar nichts.

Edit:
Gerade habe ich herausgefunden, dass das nur Readings betrifft, die 0 oder 1 sein können und und von readingsWatcher auf 0 gesetzt werden sollen, also ungefähr so: 1800,0,reading
Muss ich 0 irgendwie besonders angeben?

[Wzut]

Muss ich 0 irgendwie besonders angeben?

eigentlich nicht, aber ich habe da so einen Verdacht ....

Edit : Verdacht hat sich bestätigt , neue Version morgen ab 8:00 Uhr via update

[tomcat.x]

Danke, hat prima funktioniert.

Dann fange ich jetzt auch noch mal von vorne an. Mein erster Beitrag zu dem Modul sollte nämlich ganz anders aussehen, ungefähr so:

Cool, über was man so alles zufällig stolpert. Vorbei mit selbst gebastelten Lösungen zur Überwachung von Geräten. Aktuell nutze ich das hauptsächlich für HMS- und trädfri-Geräte.

HMS-Geräte senden eigentlich mindestens mal den Batteriestand regelmäßig. Wenn aber die Verbindung gestört ist oder fast leere Batterien von jetzt auf gleich komplett versagen, kommt natürlich gar nichts mehr. Mit dem Modul kann man jetzt gleichzeitig auf kurze Aussetzer (mit "Löschen" des Wertes) und längere (mit Fehlerzustand) reagieren. Einfach nur über setzen eines Attributs, falls man den Batteriezustand verändert und den sowieso schon über ein Notify überwacht.

Bei trädfri gab es gerade wieder ein Update für das Gateway. Danach war die Verbindung zu fhem weg. Im Gateway-Gerät ist es mir bis jetzt nicht gelungen, das zu erkennen. Die einzelnen Geräte haben ein reachable Attribut das einmal am Tag gesetzt wird. Das wird aber ohne Verbindung zum Gateway auch nicht mehr verändert. Da ich reachable der einzelnen Geräte schon überwache, setze ich das Reading im beschriebenen Fall über readingsWatcher einfach auf 0 (daher mein Problem). Bei mehreren Geräten dauert es dann auch weniger als 24 Stunden bis man den Fehler erkennt, weil keine Veränderung mehr an den Readings der Geräte erfolgt.

[rabehd]

Nach dem Update am 13.04. wird das Device nicht mehr angelegt. Es kommt die Fehlermeldung.

Messages collected while initializing FHEM:configfile: Cannot load module readingsWatcher
Please define ... first

Nach dem ich auf die Vorversion zurück bin (aus Backup), ist die Fehlermeldung weg.