expiredReadings

Begonnen von pirmanji, 03 Juni 2019, 19:03:37

Vorheriges Thema - Nächstes Thema

pirmanji

Huhu!

ich weiß nicht, ob es da schon etwas Entsprechendes gibt (gefunden habe ich in der Doku erstmal nichts): ich lasse mir in regelmäßigen Abständen Readings per Telegram / Pushbullet auf mein Smartphone senden. Es kommt aber auch immer wieder vor, dass irgend etwas schief läuft (kein Empfang zum Temperatursensor etc) und ich bekomme total veraltete Werte gesendet, die mich in falsche Sicherheit wiegen. Also bastel ich immer mal wieder, damit ich veraltete Werte rausfiltere bzw. entsprechend informiere, dass kein aktueller Wert da ist. Aber es wäre viel einfacher, wenn es ein globales Attribut gäbe, dem man mitteilen könnte, dass bestimmte Readings nach einer gewissen Zeit expired sind und was dann passieren soll. Z.B. comma-separated list of reading:interval:expiredValue, oder ähnlich:

attr xyz expiredReadings RegEx:300:-1, RegEx:1200:undef

Mir persönlich würde es ja schon reichen, wenn das von ReadingsVal() ausgewertet würde. Ich kenne aber die Interna nicht und hab mich auch noch nicht durchgewühlt. Das ist für andere Leute vielleicht viel einfacher und ich werfe das jetzt einfach mal so in den Raum. Oder gibt es das doch schon?

Viele Grüße,
Christian
Raspberry Pi 3 + COC SlowRF 868.30MHz (FS20 S8-3 + 2x DS18B20) + 1x SCC SlowRF 433.92MHz (3x TX17 + 1x TX3) + JeeLink (4x PCA301) + MaxCube

amenomade

#1
Also... mit ReadingsTimestamp und ReadingsAge kannst Du schon auswerten.

Bin kein Developer, aber das was Du dir wünschst, sehe ich schwierig zu implementieren: man sollte bei jedem Reading-Setzen irgendwelches Timer noch dazu setzen, das das Reading dann löscht. Viel Last für Fhem, und wenig Sinn.

Ausserdem: vielleicht brauchst Du die verältete Readings für deine Benachrichtung nicht, aber für irgendwelche andere Steuerung doch. Lieber ReadingsAge auswerten, wenn Du es brauchst
Pi 3B, Alexa, CUL868+Selbstbau 1/2λ-Dipol-Antenne, USB Optolink / Vitotronic, Debmatic und HM / HmIP Komponenten, Rademacher Duofern Jalousien, Fritz!Dect Thermostaten, Proteus

pirmanji

Hmm...die Idee mit den Timers ist gar nicht schlecht. Soviel Last dürfte das gar nicht erzeugen. Sämtliche Readings zu loggen erzeugt sicherlich mehr. Aber eigentlich würde es auch reichen, jene Funktionen, mit denen man gezielt Readings ausliest mit einer entsprechenden Abfrage zu versehen. Denn im FhemWeb muss ich es nicht sehen. Da habe ich ja die Zeit des Readings jeweils dabei.
Raspberry Pi 3 + COC SlowRF 868.30MHz (FS20 S8-3 + 2x DS18B20) + 1x SCC SlowRF 433.92MHz (3x TX17 + 1x TX3) + JeeLink (4x PCA301) + MaxCube

CoolTux

Da Du anscheinend schon eine Funktion hast welche Zeitgesteuert Dir Werte zu sendet kannst Du Dir doch gleich noch das Alter des Wertes mit dazu senden lassen.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

betateilchen

-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

herrmannj

Schau dir doch mal den watchdog an

peterk_de

#6
+1 ;-)

Interessanterweise hatte ich die Tage genau den gleichen Wunsch im Kopf ...

Aktuell gelöst habe ich es mit dem Modul "Monitoring" für wichtige Readings, die gerne mal "aussteigen" (wegen leerer Batterien / kaputten Funkgateway o.Ä.). Das Monitoring-Modul triggert dann eine Push-Benachrichtigung und überschreibt das Reading im Device mit "invalid". Dazu nutze ich diverse solcher Monitoring-Devices, die sich jeder wiederum um diverse Readings kümmern (für jeden Regex ein Monitoring-Device) ... schön ist was anderes:  ;-)

defmod system.monitoring.co2 monitoring (.*raspi.co2):co2:.*
attr system.monitoring.co2 errorWait 30*60
attr system.monitoring.co2 event-on-change-reading state,errorCount
attr system.monitoring.co2 stateFormat {"Offline: ".monitoring_stateFormat("system.monitoring.co2")}


Dazu dann noch NOTIFYS bzw. DOIFS, die die entsprechende Aktion ausführen (also Benachrichtigung, das nix mehr kommt und Reading "löschen").

Könnte man sicher auch mit dem Monitoring Modul noch eleganter hinbekommen als ich das grad tue, aber eine Definition des Ablaufdatums direkt im Device wäre m.E. nochmal sehr viel galanter, da für mich die Information, wann ein Reading als nicht mehr verfügbar zu verstehen ist, irgendwie auch direkt zum Device gehört. Denn so wie ichs grad mache, muss ich bei jedem neuen Device erstmal noch "an anderer Stelle" die Monitoring-Dinger anpassen / ergänzen, und dazu bin ich dann meist zu faul oder vergesse es ;)

Die Syntax so wie du sie vorgeschlagen hast fände ich so ziemlich perfekt.
FHEM auf Ubuntu-VM / 2xNUC Proxmox Cluster
UI: HomeKit, TabletUI, Grafana
IOdevs: 2xHueBridge, RaspiMatic-CCU, CUL868, 2xHarmonyHub, 6xRaspi-Roomnode mit CO2, VOC und lepresenced
Devices: 107xHomematic(IP), 96xPhilips Hue, 17xTECHEM, 12xBTLE, 8xSONOS, 2xHomeConnect, 1xShelly 3em, 1xNanoleaf ...

Peteruser

#7
Hallo,
ich wollte gerade so etwas anregen, hab dann den vorhandenen Eintrag in der Wunschliste gefunden. Wenn ich mir die letzten Einträge in dem Forum ansehe, dann macht jeder so sein eingenes Süppchen. Bei mir macht das ein Cronjob, der regelmäßig über die wichtigen Werte wacht.

Könnte man hier nicht wenigstens ein Attribut einführen?
attr <Device> TTL <Reading>  <Zeit in Sekunden> <Aktion>

Ich Cleane den Wert bei mir, dann ist ein entsprechendes Chart an der Stelle leer
Aktion > Clean

Sicher geht das auch mit den Userattributen und eingenen Scripten
attr global userattr <attributelist>

Grüße Peter
Ubuntu+Debian FHEM + ESPEasy + Homematic + ConBee + DUROFERN

herrmannj


Wzut

Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Peteruser

#10
Hallo,
danke für den Hinweis, in der Doku ist darüber noch nichts zu finden.
Werde das mal testen, scheint genau das zu sein, mit einer aus meiner Sicht unglücklichen Namensgebung.

Gibt es hier schon einen offiziellen Downloadlink oder nur das File in Forum?

Grüße Peter
Ubuntu+Debian FHEM + ESPEasy + Homematic + ConBee + DUROFERN

Wzut

ob der Name nun glücklich oder nicht ist darüber kann man streiten, ich habe damals in diese Richtung keinen Gedanken verschwendet und ihn vom seinem Vater HCS übernommen. Wenn das Modul via SVN verfügbar wäre hätte ich es schon aus dem ersten Post gelöscht und einen Vermerk hinterlassen.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Peteruser

Hallo,
ok, dann gibt es in kürze einen Testunser mehr.  ;D

Grüße Peter
Ubuntu+Debian FHEM + ESPEasy + Homematic + ConBee + DUROFERN

Christoph Morrison

Gibt es eine Chance dass du es in den FHEM-Github-Space mit controls schiebst?

Wzut

@Christoph, ich verstehe deine Worte , aber nicht deren Sinn :(
Ich habe keine Ahnung was der FHEM-Github-Space ist, IMHO gibt es genau zwei Alternativen :
a. ich setze mich hin und bringe endlich die command.ref auf Vorderman und checke ganz normal ein
b. ich spare mir die Doku Arbeit und lege es unterhalb contrib ab, nur da ist es vom update und Commandref genau so ausgeschlossen wie im ersten Post des Freds
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Christoph Morrison

Zitat von: Wzut am 23 August 2019, 17:21:24
@Christoph, ich verstehe deine Worte , aber nicht deren Sinn :(
Ich habe keine Ahnung was der FHEM-Github-Space ist, IMHO gibt es genau zwei Alternativen :
a. ich setze mich hin und bringe endlich die command.ref auf Vorderman und checke ganz normal ein
b. ich spare mir die Doku Arbeit und lege es unterhalb contrib ab, nur da ist es vom update und Commandref genau so ausgeschlossen wie im ersten Post des Freds

Es gibt bei Github einen FHEM-Space wo einige Module liegen, u.a. auch welche die man nicht über das SVN bekommt. Wenn du dort ein Repository machst und einen Controls-File (hier mal exemplarisch einer von Buienradar) anlegst, dann kann man dein Model über das normale update-Prozedere einbinden. Außerdem können dir andere Leute leicht Patches schicken (Fork + Pull Request).

Wzut

#16
Uff, was für ein Umstand :(
bis ich das ganze (iii)git Zeugs begriffen und gemacht habe, da kann ich in der Zeit auch die beiden command.refs schreiben ....
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

herrmannj

minimal Anforderungen für SVN module sind die englische cmdref und support Einsatz über das forum.

DE und EN sind aber in der Tat guter Stil und natürlich müssen SVN Module den Developer guidelines folgen. Sollten fhem module aber sowieso, allein aus funktionalen Gründen. Der Aufwand für SVN Module ist daher eigentlich überschaubar (cmdref EN)

Christoph Morrison

Zitat von: Wzut am 23 August 2019, 19:10:42
Uff, was für ein Umstand :(
bis ich das ganze (iii)git Zeugs begriffen und gemacht habe, da kann ich in der Zeit auch die beiden command.refs schreiben ....

Du bist ja nicht der erste der das macht und du kannst dich an einer der vielen Lösungen zum Erzeugen der Datei(en) orientieren. Guck dir einfach mal Buienradar an, da ist das alles schon ganz gut automatisiert.

Wzut

ich habe  die letzten Tage das Modul überarbeitet und auch nochmal über den Namen nachgedacht.
Ich werde es Mitte der Woche mit erweiterten Funktionen unter den Namen 98_readingsWatcher.pm einchecken.
 
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Peteruser

Hallo,
wollte mich gerade aufmachen, dann warte ich nochmal.
Danke für die Info.

Grüße Peter
Ubuntu+Debian FHEM + ESPEasy + Homematic + ConBee + DUROFERN