neues Modul 98_readingsWatcher , war 98_ReadingsSupervision

Begonnen von Wzut, 15 Februar 2016, 20:49:53

Vorheriges Thema - Nächstes Thema

Wzut

Die Idee bzw. die erste Version dieses Moduls stammt von HCS und wurde im LaCrosse Thread von ihm gepostet. Ich habe das Modul jetzt etwas erweitert und auf meine Bedürfnisse angepasst.

Was macht das Modul ?
Das Modul überwacht Readings in anderen Modulen das sich ihre Readings bzw. deren Zeiten in bestimmten Abständen ändern und löst ggf Events aus die mit anderen Modulen weiter verarbeitet werden können.

anlegen mit :
define myRS  ReadingsSupervision
define myRS  readingsWatcher

Danach besitzt jedes Device ein neues globales Attribut :
readingsSupervision
readingsWatcher
Dieses Attribut ist bei allen zu überwachenden Devices wie folgt zu belegen :
Timeout in Sekunden, neuer Reading Wert, Reading1 des Devices , Reading2 des Device , usw.

Beispiel : Ein Funk Thermometer sendet in regelmäßigen Abständen ( 5 Sekunden ) seine Werte. Bleiben diese nun für eine Zeit x (5 Minuten) aus, so kann man die nicht mehr aktuellen Werte mit einem beliebigen anderen Wert überschreiben ( Bsp ??? )
dann müsste das Attribut readingsSupervision wie folgt gesetzt werden :
attr AussenTemp readingsWatcher 300,???,temperature
oder falls mehr als ein Reading überschrieben werden soll
attr AussenTemp readingsWatcher 300,???,temperature,humidity
sollen Readings nur überwacht aber nicht überschrieben werden ist der Ersatz leer zu lassen:
attr AussenTemp readingsWatcher 300,,temperature,humidity

Das Device readingsWatcher hat als eigene Readings :
Name_des_überwachten_Device.aktueller_Status ( ok, timeout )
alive : Anzahl der ok Readings
devices : Anzahl der überwachten Geräte
readings : Anzahl der überwachten Readings
timeoutdevs : Komma getrennte Liste der Geräte mit Timeout Reading
timeouts : Anzahl der Readings mit Timeout

seinen eigenen state : ok = kein überwachtes Reading mit Zeitüberschreitung oder
timeout = mindestens eines der überwachten Devices hat einen Timeout ( Sammelmeldung) 

Edit :
Das Modul ist ab morgen unter dem neuen Namen 98_readingsWatcher via Update verfügbar.
Wer von der alten 98_ReadingsSupervison auf die neue Version umsteigen möchte kann dies nach und nach tun da sich auch das Attribut in den überwachten Geräten von readingsSupervision auf readingsWatcher ändert.
Neu dazu gekommen sind die Attribute deleteUnusedReadings und readingActivity
(Erklärung zu beiden , siehe command.ref ) 
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

betateilchen

Von den aktuellen Entwicklungsrichtlinien ist der Code in dem Modulentwurf aber ziemlich weit entfernt.


  • $hash->{STATE}
  • direktes Manipulieren von readings-hash

sollte man nicht mehr machen, dafür gibt es einheitliche Funktionen in fhem.pl.
Und das Aufzwingen von Attributen in andere devices ist auch fragwürdig.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Wzut

Udo, ich behaupte mal ich bin trotz meines Alters noch lernfähig :)
Gib mir etwas mehr Futter bzw.  Vorschläge zum besser machen :
$hash->{STATE} , hatte ich mir inzwischen schon mal ganz abgewöhnt fand es aber direkt im Define vertretbar damit state einen Wert hat.

direktes Manipulieren von readings-hash : du meinst damit den Teil in Set deleteReadings ? kann ich auch ganz rausnehmen, dann muss der User veralterte Werte mit deletereading in der Kommandozeile löschen.

Zitat von: betateilchen link=topic=49408.msg410787#msg410787
Und das Aufzwingen von Attributen in andere devices ist auch fragwürdig.
Stimmt, ehrlich gesagt kannte ich bis Samstag addToAttrList gar nicht :)
Aber : wie macht man das eleganter ? via userattr  in jedem zu überwachenden Device ? 
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

betateilchen

Anstatt $hash->{STATE} würde ich immer das reading state mit readingsSingleUpdate() setzen, damit ein User die Möglichkeit hat, mit stateFormat zu arbeiten, wenn er das möchte.

Das deletereading kannst Du auch im Modul verwenden, dafür gibt es eine Funktion in fhem.pl, wenn ich mich recht erinnere: CommandDeleteReading()

Userattr sind immer sinnvoller als globale Attribute über alle devices. Genau deshalb wurde das vor einiger Zeit ja getrennt.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

justme1968

das mit den attributen kann man auch etwas anderes sehen.

user attribute sind für den user da.

hier wird ja nicht einfach blind ein neues globales attribut eingeführt sondern es ist erst dann in allen devices vorhanden wenn man ein ReadingsSupervision device angelegt hat. und dann ist die wahrscheinlichkeit das man dieses attribut braucht recht hoch.

aber ich glaube du meinst eigentlich die trennung in addToAttrList und addToDevAttrList.

damit wäre die alternative das attribut nur bei den devices hinzuzufügen die man auch überwachen will. z.b. in dem man die devices im define des ReadingsSupervision devices angibt hier wäre man ja mit mehreren devspec recht frei.

das hätte zusätzlich noch den vorteil das du $hash->{NOTIFYDEV} setzen kannst und nicht alle events weiter geleitet werden.

und man könnte für den timeout einen default annehmen wenn keiner gesetzt ist.

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

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

betateilchen

Zitat von: justme1968 am 15 Februar 2016, 22:07:47
aber ich glaube du meinst eigentlich die trennung in addToAttrList und addToDevAttrList.

ja, ich glaub Du hast recht. Ich hatte nur noch im Hinterkopf, dass es unterschiedliche Listen gibt.

Den Sinn dieses Moduls habe ich allerdings immer noch nicht erkannt :D
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

HCS

Zitat von: betateilchen am 15 Februar 2016, 22:32:08
Den Sinn dieses Moduls habe ich allerdings immer noch nicht erkannt :D
Der Sinn ist, Readings individuell zu überwachen und wenn sie nicht mehr gesetzt werden, mit einem individuellen Wert zu belegen, der einen Fehler signalisiert.

Im Frontend (bei mir SmartVISU) steht 10° Außentemperatur, auch dann, wenn der Sensor schon seit Tagen nicht mehr sendet. Ich möchte im Frontend aber in dem Fall lieber --- oder ? oder was auch immer sehen, anstatt einen veralteten falschen Wert. Und da innerhalb von einem Device u. U. auch nur einzelne Readings wegbrechen können (z.B. die WS sendet nur noch Temperatur aber keinen Wind mehr) und nicht alle überwacht werden sollen, muss man es pro Reading festlegen können.

Das Wesentlich ist, dass man im Frontend keine veralteten Werte sieht.
Und dass man im Frontend und dessen Ankopplung an FHEM bei dieser Vorgehensweise nichts ändern muss, um dort den gewünschten Effekt zu erzielen.

Das ist der use case, über die Gestaltung des Modul kann man natürlich diskutieren.

Wzut

Danke Jungs für die kreativen Vorschläge, zwei der drei erheblichen Mängel konnte ich in ein paar Minuten beseitigen, d.h. es gibt also noch Hoffnung den fhem Modul TÜV irgend wann einmal zu bestehen :)
Mit addToDevAttrList fange ich jetzt mal an zu testen, mal schauen wievel Code ich dafür bei Rudi aus 98_structure klauen kann ...
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

betateilchen

Zitat von: HCS am 16 Februar 2016, 07:50:31
Der Sinn ist, Readings individuell zu überwachen und wenn sie nicht mehr gesetzt werden, mit einem individuellen Wert zu belegen, der einen Fehler signalisiert.

Etwas ähnliches habe ich seit mindestens zwei Jahren viel einfacher gelöst. Ich prüfe mit ReadingsTimestamp() ob der Wert des readings älter ist als ein bestimmtes Limit. Das ganze passiert in einer eigenen Funktion der 99_myUtils.pm die ich als Ersatz für ReadingsVal() immer da verwende, wo ich diese Altersprüfung tatsächlich brauche.

Ich finde es immer kritisch, wenn readings eines devices "von aussen" verändert werden und nicht vom device selbst.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

frank

hört sich interessant an.

dazu ein paar fragen:

1. kann man auch perl code für den neuen wert nutzen, oder ist das geplant?
2. bleibt die event-logik (event-on-change/update, min-interval ...) der überwachten readings erhalten?
3. würden mit event-on-update bei einem über längerere zeit "toten" reading zyklische events im abstand timeout abgefeuert?
4. ist das auch mit userreadings und "eigenen" readings (erstellt mit setreading) möglich?
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Wzut

1. hast du mal ein simples Beispiel ? lässt sich bestimmt was machen

2. ja

3. ja und wenn der zweite Parameter zum überschreiben definiert ist, da dann die bestehende Event Logik von Punkt 2 greift. Nein wenn der zweite Parameter leer bleibt da in diesem Fall auf das Reading nur lesend und nicht schreibend zugegriffen wird.

4. sollte kein Problem sein wenn das Modul den Reading Name des Device findet und dessen Zeitstempel lesbar ist. 
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

frank

Zitat1. hast du mal ein simples Beispiel ? lässt sich bestimmt was machen
im augenblick hätte ich einen anwendungsfall, um zusätzliche events mit dem letzten wert zu feuern.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Wzut

Ich habe das erste Posting etwas umgeschrieben und eine neue Version angehängt.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Feuerdrache

Hi,
Ich finde das ein super Modul, allerdings wirft es bei mir ein Problem mit den sag Graphen auf, die bekommen dadurch einen echten Knick. Gibt es einen Weg dafür zu sorgen, das die durch das Modul gesetzte "Anzeige" nicht per Event ins log / die Datenbank wandert?

Gruß FD
FHEM auf Raspberry PI B2
- CUL V3.4 mit culfw 1.65 für HM
- nanoCUL mit culfw 1.66 für KOPP FreeControl

frank

hallo Wzut,

mein perl auf der fritzbox
Perl     : v5.12.2

erzeugt folgenden fehler
2016.02.24 14:37:42.118 1: reload: Error:Modul 98_ReadingsSupervision deactivated:
Type of arg 1 to keys must be hash or array (not hash element) at ./FHEM/98_ReadingsSupervision.pm line 109, near "})   "


weil
ZitatStarting with Perl 5.14, keys can take a scalar EXPR, which must contain a reference to an unblessed hash or array. The argument will be dereferenced automatically. This aspect of keys is considered highly experimental. The exact behaviour may change in a future version of Perl.

mit folgender änderung der zeile 108 könnte auch meine fritzbox mit dem modul leben
   foreach (keys %{$hash->{READINGS}})

-------------

ist es richtig, dass die einstellung des userattr im zu überwachenden device nach bsp B) nur ein reading/event im RedingsSupervision device erzeugt, aber kein event des überwachten readings?

define rs_refTemp ReadingsSupervision sendRefTemp refRoom
attr refRoom sendRefTemp 60,,refTist


gruss frank
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html