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 )
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.
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 ?
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.
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
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
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.
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 ...
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.
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?
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.
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.
Ich habe das erste Posting etwas umgeschrieben und eine neue Version angehängt.
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
hallo Wzut,
mein perl auf der fritzbox
Perl : v5.12.2erzeugt 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,,refTistgruss frank
a. ich habe im ersten Post eine neue Version des Moduls angehängt
b. foreach (keys %{$hash->{READINGS}}) ist so drin
c . Events :
@Frank : ja Timeout,, stellt sicher das das reading unverändert bleibt und kein Event erzeugt wird. Egal wie das neue Attribut client-event gesetzt ist.
Neues Attribut client-event 0 oder 1 (default 0)
Bei client-event 0 wird das zu überwachende Device keinen Event erzeugt auch wenn der Wert des Readings durch das Modul überschieben wird.
Damit lässt sich z.B das Problem von Feurerdrache recht einfach lösen, d.h. ersetzen des Wertes bei Timeout ja aber kein Event und damit auch keine "Zacken" im Logfile.
hallo wzut,
jetzt habe ich hiermit ein problem.
use Date::Parse;ZitatCan't locate Date/Parse.pm in @INC (@INC contains: /var/InternerSpeicher/fhem/lib/perl5/site_perl/5.12.2/mips-linux /var/InternerSpeicher/fhem/lib/perl5/site_perl/5.12.2/mips-linux /var/InternerSpeicher/fhem/lib/perl5/site_perl/5.12.2 /var/InternerSpeicher/fhem/lib/perl5/5.12.2/mips-linux /var/InternerSpeicher/fhem/lib/perl5/5.12.2/mips-linux /var/InternerSpeicher/fhem/lib/perl5/5.12.2 /opt/lib/perl5/site_perl/5.12.2/mips-linux /opt/lib/perl5/site_perl/5.12.2 /opt/lib/perl5/5.12.2/mips-linux /opt/lib/perl5/5.12.2 . ./FHEM) at ./FHEM/98_ReadingsSupervision.pm line 35.
BEGIN failed--compilation aborted at ./FHEM/98_ReadingsSupervision.pm line 35.
$Timestamp = str2time($TimestampString);hm....
geht das vielleicht auch anders?
Hallo Wzut,
danke für die schnelle Reaktion, hab es gerade eingespielt.
Gruß FD
Zitat von: frank am 24 Februar 2016, 20:06:22
geht das vielleicht auch anders?
tztz , diese Fritzboxen ....
ja der alte Weg steht noch auskommentiert im Modul :
#($date, $time) = split( ' ', $TimestampString );
#($year, $month, $day) = split( '-', $date );
#($hour, $min, $sec ) = split( ':', $time );
#$Timestamp = timelocal( $sec, $min, $hour, $day, $month-1, $year );
$Timestamp = str2time($TimestampString);wirf das use und Zeile $Timestamp = str2time($TimestampString); raus und entferne bei den anderen vier Zeilen den #
hallo wzut,
wie wäre es hiermit:
time_str2num("YYYY-MM-DD HH:MM:SS") returns a numerical value, which makes computation of time differences easier
ok, Weg Nr 47 von 99 nach Rom :)
schaut man in die Funktion reduziert sie lediglich die drei einzel splits von HCS auf einen :
@a = split("[- :]", $str);
mein server sagt danke.
der chef hat ein herz für schwache maschinen, so wie du wohl auch. :)
Hi Wzut,
wollte dir mal eine kurze Rückmeldung geben. Das Modul läuft bei mir wunderbar und macht überhaupt keine Probleme.
TOP
Gruß FD
Hallo zusammen,
danke für das Modul, genau sowas habe ich gesucht!
Wäre es möglich, dass man die devices mittels Wildcard und/oder als Typ spezifiziert? Wenn man für alle Temperatursensoren die Überwachung anmachen will, muss man sehr viele auflisten, da wäre z.B. lacTH.* oder LaCrosse als Angabe schon super angenehm...
Bin leider nicht tief genug in FHEM, um sowas selbst hinzubasteln...
Viele Grüße,
-Sheridan
Sobald das Modul einmal definiert ist hat jedes deiner vorhanden Geräte ein neues userattr.
Das kannst du in der Kommandozeile auch für ganze Gruppen in einem Rutsch setzen , bsp
attr Temp\..* userattr readingsSupervision 900,,temperature
würde allen Geräten deren Namen mit Temp beginnt das userattr readingsSupervison mit dem Wert 90,,temperatur belegen.
Was mache ich falsch, wenn das userattr nicht angelegt wird? Ich definiere das Device wie folgt:
define myRS ReadingsSupervision und wenn ich es richtig verstanden habe, dann müsste jetzt überall das userattr ReadingsSupervision auftauchen, oder nicht? Passiert aber nicht :)
Vollkommen richtig , mehr gibt es beim define nicht anzugeben und das dann an allen geräten das neue Attribut sofort zur Verfügung steht hatte betateilchen auf Seite 1 ja als Mangel eingestuft. Ich habe das Ding ja selbst in Benutzung und hat bis jetzt immer ohne Probleme geklappt, aber ich probiere gern nochmal ein paar Varianten auf meinem Testsystem durch.
Edit : habe es gerade aufs Testsystem kopiert und definiert. Das neue Attr ist sofort an allen Geräten verfügbar, aber schau mal genau in die Liste das attr nennt sich readingsSupervison , mit kleinem r zwischen icon & room
Aus mir unbekannten Gründen erscheint das Reading auf meinem Test System nicht. Habe es auch schon zwei mal gelöscht und auch einen anderen Namen für das userattr genutzt, hilft auch nix. Komisch.
Hier mal ein List des Device:
Internals:
ATTR readingsSupervision
CFGFN
NAME myRS
NOTIFYDEV global
NR 45
STATE ok
TYPE ReadingsSupervision
READINGS:
2018-01-26 17:48:46 state ok
Attributes:
Und ich gehe davon aus, dass im globel attr userattr das Reading readingsSupervison auftauchen müsste, oder? Da ist es auch nicht:
Internals:
DEF no definition
NAME global
NR 1
STATE no definition
TYPE Global
currentlogfile ./log/fhem-2018-01.log
logfile ./log/fhem-%Y-%m.log
Attributes:
autoload_undefined_devices 1
autosave 0
configfile fhem.cfg
exclude_from_update commandref fhemicon
logfile ./log/fhem-%Y-%m.log
modpath .
motd SecurityCheck:
WEB is not password protected
telnetPort is not password protected
Protect this FHEM installation by defining an allowed device with define allowed allowed
You can disable this message with attr global motd none
statefile ./log/fhem.save
updateInBackground 1
userattr cmdIcon devStateIcon devStateStyle icon msgContactAudio msgContactLight msgContactMail msgContactPush msgContactScreen msgParams msgPriority msgRecipient msgRecipientAudio msgRecipientLight msgRecipientMail msgRecipientPush msgRecipientScreen msgRecipientText msgTitle msgTitleShrt msgType:text,push,mail,screen,light,audio,queue sortby webCmd webCmdLabel:textField-long widgetOverride
verbose 3
version fhem.pl:15804/2018-01-06
Zitat von: Amenophis86 am 26 Januar 2018, 17:53:20
Und ich gehe davon aus, dass im globel attr userattr das Reading readingsSupervison auftauchen müsste, oder? Da ist es auch nicht:
Richtig in der sub Initialize steht am Ende
addToAttrList("readingsSupervision"); das sorgt eigentlich dafür das die vorhandene Liste global attr userattr um diesen Eintrag erweitert wird.
Wenn der Automatismus bei dir fehlschlägt dann füge den Eintrag doch händisch hinzu und du dann testen kannst ob wenigisten der Rest bei dir funktioniert.
Joa den Fehler habe ich mir schon gedacht, als ich mir den Code angesehen habe und keine entsprechende Zeile gefunden habe. So sieht die Sub bei mir aus (PM aus dem ersten Post):
sub ReadingsSupervision_Initialize($)
{
my ($hash) = @_;
$hash->{GetFn} = "ReadingsSupervision_Get";
$hash->{SetFn} = "ReadingsSupervision_Set";
$hash->{DefFn} = "ReadingsSupervision_Define";
$hash->{UndefFn} = "ReadingsSupervision_Undefine";
$hash->{AttrList} = "disable:0,1 interval client-event:0,1 ".$readingFnAttributes;
}
und auch nirgends sonst im Code kommt die addToAttrList() Funktion. Habe die Funktion jetzt mal händisch hinzugefügt und dann klappt es auch beim definieren.
OK, das tut mir jetzt wirklich leid, die Version die z.Z. noch am ersten Post hängt (V1.3) habe ich gar nicht im Einsatz sondern immer noch den Vorgänger V1.2 :(
Anyway , ich bin gerade dabei das Modul auf den aktuellen Stand zu bringen, inzwischen gibt es ja ReadingsAge in fhem.pl und damit entfällt die ganze Timestamp Rechnerei.
Kein Problem, haben den "Fehler" ja gefunden. Dann warte ich bis du es neu gemacht hast und teste das dann nochmal, bevor ich es in meiner Produktiv Umgebung einsetze.
Ich stolpere über https://forum.fhem.de/index.php/topic,97489.0.html - zufälliges Mitlesen.
Wow, das klingt ja spannend - warum sind die echten Perlen immer so versteckt?
Die aktuelle Version ist im ersten Beitrag, richtig? Und sie hat es nie in den offiziellen Zweig geschafft, richtig? Eine Dokumentation gibt es nicht - bzw. besteht lediglich aus diesem Thread, auch richtig?
(Ich weiß, dass meine direkte Fragetechnik manchmal für Verstimmungen sorgt, ich bitte um Verzeihung. Ich möchte lediglich schnell verstehen.)
@curt, ja allles richtig. Ich habe aber eben gesehen das die Version im ersten Post nicht meine letzte war und habe sie gerade ausgetauscht.
Ehe ich alles kaputt mache - darf ich bitte fragen?
oder
define myRS ReadingsSupervision Wachhund CUL Jee
Wenn ich zum Beispiel 40 Devices überwachen will, dann muss ich die 40 Devices alle in diese Zeile da oben schreiben?
Noch eine Frage:
Das da "???" je nach meinen Vorgaben geschrieben werden - habe ich verstanden. Nun wäre im nächsten Schritt ja schön, eine Liste (gern auch in FTUI) zu haben: Alle Devices, die nicht reagieren. Würde das denn gehen? Wie würde man das machen?
Ein schönes Modul, habe schon länger so was in der Richtung gesucht.
Leider wird das Reading nicht mit dem Ersatzwert überschrieben, egal ob dort Zeichen oder Ziffern eingetragen sind.
Das Modul ansich triggert wie vorgesehen den Timeout. Als Anhang ein Bild dazu.
Hier mal ein List vom Device:
Internals:
CHANGED
DEF 06
FUUID 5c622c63-f33f-c80d-efa5-d63a30cdec9a51fc
IODev myLaCrosseGateway
IODevMissing 1
IODevName JLLaCR
LASTInputDev myLaCrosseGateway
LaCrosse_lastRcv 2019-02-18 01:25:34
MSGCNT 690
NAME Test
NR 351
STATE T: 22 H: 47
TYPE LaCrosse
addr 06
battery_new 1
corr1 0
corr2 0
myLaCrosseGateway_MSGCNT 690
myLaCrosseGateway_TIME 2019-02-18 01:25:34
previousH 47
previousT 22
sensorType 0=T(H)
Helper:
DBLOG:
humidity:
logdb:
TIME 1550449388.78014
VALUE 47
temperature:
logdb:
TIME 1550449388.78014
VALUE 22
READINGS:
2019-02-18 01:25:34 battery ok
2019-02-18 01:25:34 humidity 47
2019-02-18 01:21:55 state T: 22 H: 47
2019-02-18 01:25:34 temperature 22
helper:
bm:
LaCrosse_Define:
cnt 1
dmx -1000
dtot 0
dtotcnt 0
mTS 1550445727.88531
max 0.010977029800415
tot 0.010977029800415
mAr:
HASH(0x60b8ad8)
Arbeitszimmer2 LaCrosse 01
LaCrosse_Set:
cnt 271
dmx -1000
dtot 0
dtotcnt 0
mTS 1550445749.10052
max 0.0028231143951416
tot 0.0239062309265137
mAr:
HASH(0x60b8ad8)
Arbeitszimmer2
replaceBatteryForSec
600
Attributes:
IODev JLLaCR
doAverage 1
event-min-interval temperature:600,humidity:600,battery:3600
filterThreshold 3
readingsSupervision 120,???,temperature,humidity
resolution 2
room LaCrosse
Habe ich eine Einstellung übersehen ?
Gruß Frank
@curt, da muss ich mal den ersten Post ändern, das mit dem Einzeldevice war einmal. Es wird nach der Definition des Device immer ein globales Attribut readingsSupervison hinzugefügt, dann kannst du in jedem deiner 40 Geräte mit der Parametrierung loslegen.
Eine List bekommst du wenn du die Readings des Device abfragst ( siehe Screenshot von TK67 ) ich kann aber auch ein zusätzliches Readings spendieren das alle Timeout Geräte enthält zwecks Weiterverarbeitung. Was wäre denn z.B. für FTUI sinnvoll, Komma getrennte Liste , JSON ?
@TK57, hast Recht :( da habe ich wohl mal bei einem Test etwas zuviel auskommentiert. Schau nochmal heute Abend rein dann schiebe ich eine gefixte Version im ersten Post nach.
Danke werde ich machen, noch eine Frage gibt es dieses Attribut client-event nicht mehr ?
Habe zumindest im Dropdown nichts dazu gefunden.
Vielleicht auch etwas zuviel auskommentiert ? ;)
Zitat von: Wzut am 24 Februar 2016, 19:23:45
a. ich habe im ersten Post eine neue Version des Moduls angehängt
b. foreach (keys %{$hash->{READINGS}}) ist so drin
c . Events :
@Frank : ja Timeout,, stellt sicher das das reading unverändert bleibt und kein Event erzeugt wird. Egal wie das neue Attribut client-event gesetzt ist.
Neues Attribut client-event 0 oder 1 (default 0)
Bei client-event 0 wird das zu überwachende Device keinen Event erzeugt auch wenn der Wert des Readings durch das Modul überschieben wird.
Damit lässt sich z.B das Problem von Feurerdrache recht einfach lösen, d.h. ersetzen des Wertes bei Timeout ja aber kein Event und damit auch keine "Zacken" im Logfile.
Zitat von: Wzut am 18 Februar 2019, 08:45:36
@curt, da muss ich mal den ersten Post ändern, das mit dem Einzeldevice war einmal.
Feinfein.
Zitat von: Wzut am 18 Februar 2019, 08:45:36
Es wird nach der Definition des Device immer ein globales Attribut readingsSupervison hinzugefügt, dann kannst du in jedem deiner 40 Geräte mit der Parametrierung loslegen.
Nicht verstanden.
Also wenn ich ab dem Tag X ein neues Device "Temp_Klo" anlege, bekommt das gleich readingsSupervison dazu, vermutlich. Was ist aber mit den schon existierenden Devices?
[/quote]
Zitat von: Wzut am 18 Februar 2019, 08:45:36
Eine List bekommst du wenn du die Readings des Device abfragst ( siehe Screenshot von TK67 )
Und das kann ich leider nicht, zu wenig Können. Zeigst Du mir bitte konkret , wie das geht?
Zitat von: Wzut am 18 Februar 2019, 08:45:36
ich kann aber auch ein zusätzliches Readings spendieren das alle Timeout Geräte enthält zwecks Weiterverarbeitung. Was wäre denn z.B. für FTUI sinnvoll, Komma getrennte Liste , JSON ?
Hmmm. Im Moment habe ich in FTUI zwei Listen. Die eine ist ein Geburtstagskalender, diese Liste wird durch das FTUI-Widget Calview erzeugt. Die andere Liste sind Blitzer, da hat der Autor vermittels Perl die Tabellenformatierung gleich in das Reading gekloppt.
Ich erzähle am Besten, wie ich darauf komme und was ich *eigentlich* will: Es gibt ja zig Vorschläge für Batterieüberwachung. Nur funktionieren die suboptimal. Bei meinen Jeelink-Temperatur-Dingsern ist die Batterie immer in Ordnung - und das Ding sendet schon seit Wochen nicht mehr. Dann sah ich völlig zufällig über einen anderen Thread Dein Modul - und dachte: Das ist es doch?
Denn bei der Gelegenheit könnte ich gleich mit überwachen, was meine (vielen) HTTPMOD-Dingser eigentlich treiben, ob es denen noch gut geht.
Ich habe den ersten Post etwas aufgeräumt und eine neue Version angehängt.
@TK67, das Attribut hatte ich bei irgendeinem Umbau wieder rausgeworfen da es heute keine Events des überwachten Gerätes mehr gibt,
das spielt sich alles zentral im RS Device ab.
@curt, lege es einfach an , das neue Attribut ist sofort an allen alten Geräten verfügbar.
Zum Thema FTUI kann ich die nicht helfen da ich davon null Ahnung habe, bitte ggf. im passenden Forum nachfragen.
Die neue Version hat ein neues Reading timeoutdevs da steht entweder none oder durch Komma getrennt eine Liste der Geräte mit Timeout,
wenn FTUI irgend etwas anderes brauch bitte nochmal melden.
Thema JeeLink , bzw LaCrosse Sensoren : lies mal den ersten Post, wo die Idee und erste Version des Moduls ursprünglich her kommt.
Zitat von: Wzut am 18 Februar 2019, 19:20:52
Thema JeeLink , bzw LaCrosse Sensoren : lies mal den ersten Post, wo die Idee und erste Version des Moduls ursprünglich her kommt.
Issjalustich ... nein, ich hatte dem Einleitungssatz nicht hinterhergeforscht.
Zitat von: Wzut am 18 Februar 2019, 19:20:52
lege es einfach an , das neue Attribut ist sofort an allen alten Geräten verfügbar.
Allen Mut zusammengenommen und los. Issjaschick.
Kleiner Stolperer war "verfügbar", ich dachte erst, das Attribut würde allen Devices hinzugefügt. Beim Wiki-Artikel müsste man das klarer fassen - ich nehme an, dass es keinen Artikel gibt?
Zitat von: Wzut am 18 Februar 2019, 19:20:52
Die neue Version hat ein neues Reading timeoutdevs da steht entweder none oder durch Komma getrennt eine Liste der Geräte mit Timeout, wenn FTUI irgend etwas anderes brauch bitte nochmal melden.
Keine Zeit, muss spielen! :D
Nein, im Ernst: Darüber denke ich nach, wenn das bei mir über einen gewissen Zeitraum läuft.
Aber mir sind andere Dinge aufgefallen, immer in Bezug darauf, dass das ein möglichst allgemein nutzbares Device werden soll - ich plappere einfach mal vor mich hin:
1) Internals? Wäre es möglich, Internals zu überwachen?
Die Frage hat den Hintergrund HTTPMOD. Da gibt es ein Internal "code" - und das ist "200", wenn der Abruf auf der Ebene http/https erfolgreich abgeschlossen wurde.
2) addLog grätscht rein: Folgende bekannte Situation:
define addLog("Bad","state");;\
addLog("Stecker_01","power");;\
addLog("Stecker_02","power");;\
}
# und das machen wir nun alle 5 Minuten
define a_5min at +*00:05 trigger addLog
Da kann ich vermutlich lange überwachen - der Stecker liegt in der Schublade, aber addLog suggeriert, dass der artig an der Steckdose hängt. Ich habe derzeit keine Idee, wie man damit umgeht.
3) Ausschlussliste: Die dürfen fehlen.
Beispielsweise: Movie (mein freundlicher kleiner Rasenmäher mit den aufgeklebten Wackelaugen) hält in der Servicewerkstatt Winterschlaf. Der steht als "tot" auf der Liste.
Da stellt sich die Frage, was die dümmere Lösung ist: Kein Attribut bei der Device "Movie" - oder eine Art Ausschlussliste bei Deinem Modul.
Darf ich da mal träumen?
Im Herbst ist Movie fürchterlich müde. Also fahre ich ihn zu seinem Winterschlafquartier in die Servicewerkstatt, Dein Modul meldet: Movie tot. Stimmt. - Wenn ich da jetzt irgendwo drauf klicken könnte "der darf das" - das wäre toll.
Warte, der Traum ist doch noch nicht zu Ende:
Um Pfingsten wird Movie wach und quengelt: Rasen mähen. Also hole ich ihn aus dem Winterquartier, er meldet sich selbstständig im Wlan an und mäht los (bisheriger Zustand!). Es wäre wunderfein, wenn das Attribut, der Attributteil "der darf tot sein" damit automatisch gelöscht würde.
Bitte nicht aufregen. Ich habe nur vor mich hingeplappert und geträumt.
Geniale Sache, danke Dir!
Das ersetzen des Readings funktioniert jetzt ohne Probleme, allerdings erscheinen jetzt willkürlich "Timestamp not found" bei wechselnden Devices. Mal ist es 1 Device und beim nächsten Scan z.b. 3 Devices.
Müllt dann natürlich ein wenig das Log zu.
2019.02.18 23:16:40 3: Watchdog_Readings, reading Timestamp humidity not found for device Arbeitszimmer
2019.02.18 23:16:40 3: Watchdog_Readings, reading Timestamp temperature not found for device Arbeitszimmer
2019.02.18 23:14:40 3: Watchdog_Readings, reading Timestamp humidity not found for device Schlafzimmer
2019.02.18 23:14:40 3: Watchdog_Readings, reading Timestamp temperature not found for device Schlafzimmer
2019.02.18 23:14:40 3: Watchdog_Readings, reading Timestamp humidity not found for device Flur
2019.02.18 23:14:40 3: Watchdog_Readings, reading Timestamp temperature not found for device Flur
2019.02.18 23:14:40 3: Watchdog_Readings, reading Timestamp humidity not found for device Aussen
2019.02.18 23:14:40 3: Watchdog_Readings, reading Timestamp temperature not found for device Aussen
2019.02.18 23:13:40 3: Watchdog_Readings, reading Timestamp humidity not found for device Aussen
2019.02.18 23:13:40 3: Watchdog_Readings, reading Timestamp temperature not found for device Aussen
2019.02.18 23:12:40 3: Watchdog_Readings, reading Timestamp humidity not found for device Badezimmer
2019.02.18 23:12:40 3: Watchdog_Readings, reading Timestamp temperature not found for device Badezimmer
2019.02.18 23:12:40 3: Watchdog_Readings, reading Timestamp humidity not found for device Aussen
2019.02.18 23:12:40 3: Watchdog_Readings, reading Timestamp temperature not found for device Aussen
2019.02.18 23:11:40 3: Watchdog_Readings, reading Timestamp humidity not found for device Kuehlschrank
2019.02.18 23:11:40 3: Watchdog_Readings, reading Timestamp temperature not found for device Kuehlschrank
2019.02.18 23:11:40 3: Watchdog_Readings, reading Timestamp humidity not found for device Aussen
2019.02.18 23:11:40 3: Watchdog_Readings, reading Timestamp temperature not found for device Aussen
2019.02.18 23:10:40 3: Watchdog_Readings, reading Timestamp humidity not found for device Wohnzimmer
2019.02.18 23:10:40 3: Watchdog_Readings, reading Timestamp temperature not found for device Wohnzimmer
2019.02.18 23:10:40 3: Watchdog_Readings, reading Timestamp humidity not found for device Kueche
2019.02.18 23:10:40 3: Watchdog_Readings, reading Timestamp temperature not found for device Kueche
2019.02.18 23:10:40 3: Watchdog_Readings, reading Timestamp humidity not found for device Aussen
2019.02.18 23:10:40 3: Watchdog_Readings, reading Timestamp temperature not found for device Aussen
2019.02.18 23:08:40 3: Watchdog_Readings, reading Timestamp humidity not found for device Wohnzimmer
2019.02.18 23:08:40 3: Watchdog_Readings, reading Timestamp temperature not found for device Wohnzimmer
2019.02.18 23:07:40 3: Watchdog_Readings, reading Timestamp humidity not found for device Schlafzimmer
2019.02.18 23:07:40 3: Watchdog_Readings, reading Timestamp temperature not found for device Schlafzimmer
2019.02.18 23:06:40 3: Watchdog_Readings, reading Timestamp humidity not found for device Kueche
2019.02.18 23:06:40 3: Watchdog_Readings, reading Timestamp temperature not found for device Kueche
2019.02.18 23:05:40 3: Watchdog_Readings, reading Timestamp humidity not found for device Arbeitszimmer
2019.02.18 23:05:40 3: Watchdog_Readings, reading Timestamp temperature not found for device Arbeitszimmer
@curt,
a. Wiki : gibt es nicht, Doku schreiben ist nicht meine starke Seite
b. Internals : Internals haben keinen Zeitstempel also kann man nicht überwachen wann sie zuletzt geschrieben wurden, aber HTTPMOD erzeugt doch Readings und die kann man überwachen, d.h. ist dein Internal Code != 200 wird mit Sicherheit irgend ein Reading nicht mit neuen Werten versorgt. Da muß man ansetzen.
c. AddLog : dann ersetz doch den power Wert bei Timeout durch irgendetwas, dann steht der Fehler auch im Log
d. Mähroboter : solche Saison Geräte kann man auf inactiv oder disable setzen, dann übergeht das Modul das Gerät bis es wieder im Einsatz ist.
@TK67, Fehler gefunden , neue Version im ersten Post
Jetzt funktioniert so weit alles ohne Probleme. Es gibt allerdings noch einen kleinen Schönheitsfehler.
Die Timestamps unter "Get Devices" werden nicht mehr gefüllt. Vielleicht lässt sich da noch was machen.
das sieht aber nicht aus wie bei mir, ganz sicher das du die letzte Version aus dem ersten Post am Start hast ?
Habe gerade noch mal verglichen, ist die aktuelle Version bei mir in Fhem.
# Version 1.5 - 19.02.19
# Version 1.3 - 26.01.18 Wzut use ReadingsAge
# Version 1.2 - 15.02.16 Wzut add Set, Get
# Version 1.1 - 14.02.16 Wzut
# Version 1.0 - (c) HCS, first version
Fhem ist auch aktuell. Habe trotzdem die Version aus dem ersten Post nochmals drüber gezogen, es bleibt aber bei dem "no Timestamp".
In der Version die bei mir in den Readings no Timestamp gebracht hatte funktionierte die Anzeige noch.
https://forum.fhem.de/index.php/topic,49408.msg908195.html#msg908195
@Wzut
Aktuell "spiele" ich ein wenig mit diesem Modul und habe dabei folgende "Ungereimtheiten" festgestellt:
get <myRS> devices liefert falsche Ergebnisse; dies liegt an einer vertauschten Logik in Zeile 137 - verursacht dabei auch das hier angesprochene "no Timestamp"-Problem.
line 137
-- if (defined($age))
++ if (!defined($age))
Das Reading timeouts wird nach einem bereinigten timeout-Zustand nicht wieder auf 0 zurückgesetzt - bleibt also auch dann ungleich 0, wenn kein timeout mehr vorliegt. Dies liegt wohl an der Verwendung untypisierter Variablen; $deads ist für den angesprochenen Fall (in Zeile 260 bzw. 261) nicht 0, da es nie einen Wert erhalten hat. Die @timeOutdevs-Deklaration musste ich aus der Gruppe rausziehen, da das Array ansonsten bereits ab hier ein Element enthielt.
line 184
-- my ($alives, $deads, @timeOutdevs ,$state);
++ my ($alives, $deads, $state) = (0, 0, '');
++ my @timeOutdevs = ();
line 261
-- readingsBulkUpdate($hash,'state' , ($deads) ? 'timeout' : 'ok');
++ readingsBulkUpdate($hash,'state' , ($deads == 0) ? 'ok' : 'timeout');
line 263
-- if (int(@timeOutdevs))
++ if (scalar(@timeOutdevs) > 0)
Vielleicht kannst Du die geschilderten Fälle ja nachvollziehen und die Code-Korrekturen so oder in ähnlicher Form - bekanntlich führen ja viele Wege nach Rom - übernehmen.
@OdfFhem
Habe die Änderungen von dir gerade mal eingebaut, jetzt läuft alles so wie es soll.
Dankeschön :)
@OdfFhem, ich freue mich immer wenn sich andere User statt zu meckern gleich Lösungen präsentieren :)
Der erste Punkt in Zeile 137 : Volle Zustimmung. Auf meinem Live System ist das heute schon so, k.A. warum da ne andere Version in den ersten Post gerutscht ist (erklärt dann auch warum TK67 das Problem hat).
Beim Reading timeouts stimme ich dir auch zu, blieb bis jetzt unbemerkt weil ich es nicht verwende.
Mit den beiden anderen Änderungen habe ich allerdings ein Problem den Sinn zu erkennen. Wenn jetzt am Anfang my $dead =0 steht
passt doch nach wie vor ($deads) ? 'timeout' : 'ok' und auch int(@timeOutdevs) führt heute zum gewünschten Erfolg.
@Wzut
Ich kann derzeit nichts testen, aber von der zweiten Änderung reicht mit seeeeeehr großer Wahrscheinlichkeit die Änderung zu Zeile 184 - man beachte den Rom-Hinweis ;-)
@Wzut
Zitat von: Wzut am 04 März 2019, 14:22:44
Auf meinem Live System ist das heute schon so, k.A. warum da ne andere Version in den ersten Post gerutscht ist (erklärt dann auch warum TK67 das Problem hat).
Welches ist denn die aktuelle Version und wo ist sie zu finden?
BTW: Nach kleineren anfänglichen Schwierigkeiten macht es bei mir das, was es soll. Ich bin zufrieden und glücklich, danke!
Zitat von: betateilchen am 16 Februar 2016, 09:47:34
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.
Hallo Udo,
ich bin auf deinen Beitrag gestoßen und interessiere für deine Lösung mit ReadingsTimestamp() in einer eigenen Funktion der 99_myUtils.pm. Könnte ich daran partizipieren?
Viele Grüße Gisbert
Update, ich habe das erste Posting editiert :
Zitat von: Wzut am 15 Februar 2016, 20:49:53
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 )
Moin,
nach heutigem Update steht im Log:
2019.09.05 10:03:39 1: reload: Error:Modul 98_readingsWatcher deactivated:
syntax error at ./FHEM/98_readingsWatcher.pm line 136, near ") if"
VG Sebastian
ja ich habe mit Schrecken heute morgen gemerkt das ich gestern Abend die falsche Version hochgeladen habe.
Entweder die die Zeile 136 auskommentieren / löschen oder noch bis morgen früh warten auf die richtige Version warten.
Ich bin faul und warte aufs Update ;)
VG Sebastian
Kann es sein, dass dir ein Tippfehler unterlaufen ist?
Im dem gemonitortem Device jist der Wert von Reading Activity aöive ( s. Screenshot)
Hier das List vom readingsWatcher
Internals:
CFGFN
DEF global
FUUID 5d721370-f33f-88d3-cc14-b66135daebedbb6a
INTERVAL 60
NAME rdwatcher
NR 105
STATE ok
TYPE readingsWatcher
OLDREADINGS:
READINGS:
2019-09-06 11:06:16 MQTT2_espeasy_dht_aussen_state ok
2019-09-06 11:06:16 alive 1
2019-09-06 11:06:16 devices 1
2019-09-06 11:06:16 readings 1
2019-09-06 11:06:16 state ok
2019-09-06 11:06:16 timeoutdevs none
2019-09-06 11:06:16 timeouts 0
Attributes:
interval 60
readingActivity activity
oh Mann das wird ja langsam oberpeinlich .... :(
aber Glück im Unglück du kannst es gleich selbst beheben und das ö mit einem l überschreiben, setz das Attribut readingActivity statt nur auf activity
auf activity:dead:alive oder activity:0:1 je nach Geschmack
Zitat von: Wzut am 06 September 2019, 11:22:02
auf activity:dead:alive oder activity:0:1 je nach Geschmack
Sehr gut, das mache ich. Magst du es trotzdem fixen?
ja sicher. Diese Woche steht eh noch ein Update an, ich muß nur noch die command.ref nachziehen.
a. habe ich die Ausgabe bei get <name> devices etwas aufgeräumt
b. können heute zwar mehrere Readings eines Devices überwacht werden, allerdings unterliegen sie der gleichen Regel in Bezug auf Timeoutwert und
Ersatzwert. In der nächsten Version können beliebig viele Regeln für ein Device vergeben werden.
Guten Morgen,
kann es sein das sich das Modul nicht inactive setzen lässt oder ist mit "set inactive" nicht die Abschaltung der Überwachung gemeint?
Gruß Marco
Hust, da scheint wohl jemand vergessen zu haben den inactive state in der sub OnTimer anbzufragen .... :(
Im Moment wirst du wohl nur mit disable 1 dein Ziel erreichen.
Danke für Dein rasanten Support, das hilft mir erstmal weiter [emoji106]
Gesendet von meinem Pixel 3 mit Tapatalk
1. Erst mal Danke für das tolle Modul. Es löst bei mir äußerst zufriedenstellend alle möglichen Bastellösungen für div. Geräte ab.
nur ein paar Kleinigkeiten:
- In Antwort #39 schreibst du, dass das Atribut "client-event" rausgeflogen ist, "da es heute keine Events des überwachten Gerätes mehr gibt,"
Die ??? lösen bei mir aber trotzdem bei jedem Prüfungsintervall Events aus und die Kurven sind versaut. (Lücken wären besser)
- die Einstellung "attr myReadingsWatcher readingActivity activ:0:1" führt bei mir dazu, dass am Geräte-Reading activ der Wert dead oder 1 steht.
Grüsse, Dirk
- das sollte natürlich nicht sein , schau ich mir heute Abend an
- und wenn du activ:1:0 setzt bekommst du vermutlich 1 oder alive , np. das habe ich sofort gefunden
also ich habe jetzt nochmal nachgeschaut und auch getestet
- um Events des überwachten Device zu vermeiden nutzt das Modul zum ersetzen eines Readings die FHEM interne Funktion
setReadingsVal und genau wie erwartet erzeugt die bei mir keinerlei Events. Kann es sein das du noch andere Hilfen am Start hast wie z.B. hier -> https://wiki.fhem.de/wiki/Plot-Abriss_vermeiden beschrieben ? Dann wäre es klar wie der Ersatz Wert in die Datei kommt.
- activ 0/alive habe ich gefixt und ist im nächsten Update
Hallo,
ich habe jetzt an einem Gerät mit überwachten readings ein "künstliches" reading angelegt, welches nicht aktualisiert wird und dieses in die Überwachung aufgenommen.
Das positive ... es sieht so aus, als wenn kein Event erzeugt wird, wenn die ??? eingetragen werden. Keine Ahnung wo das bei dem anderen herkam. Prüfe ich später
Aber ... nur springt das Gerät ständig zwischen activ:1 und activ:dead hin und her.
Ich habe also alle 90 sekunden die tot-sowie die alive Meldung.
Ich habe mehrere Geräte, welche einzelne Sensoren mit "sendeausfällen" haben. Einen konsequenten Gerätestatus (tot oder lebend) würde ich mir hier wünschen. (bevorzugt: wenn ein überwachtes reading aktualisiert wird, lebt das Gerät)
sorry, aber das kann ich nicht nachvollziehen. Wenn ein überwachtes Reading nicht aktualisiert wird d.h der Zeitstempel bleibt gleich, bleibt auch der Actifity Status bestehen.
Ich habe aber am selben Gerät mehrere readings überwacht (in diesem Testgerät sind das testreading,temperature,humidity ).
Wenn nur eines Ausfällt (hier halt das testreading) ist das neue Reading "activ" immer am hin und her schalten.
Im angehängten Bild ist sehr schön zu sehen, temp..&hum... werden regelmäßig aktualisiert, testreading ist tot und der Gerätegesamtstatus (activ) ist gerade "dead".
ja ist klar, für so eine Aufgabenstellung (halbtot) wurde das Modul nicht geschrieben.
Das ist schade.
Ich habe viele (WLAN-)Geräte mit mehreren Sensoren. Da ist öfter mal ein einzelner Sensor unpässlich.
Findest du die Idee so etwas zu betrachten nützlich? Ich hätte da eine kleine selbstgebastelte Anpassung.(5Zeilen)
Ich würde nämlich gern dein Modul weiter einsetzen und kein angepasstes mit eingefrorenem Stand.
dann verrate doch mal deine fünf Zeilen, wird sich schon irgend etwas daraus zaubern lassen :)
Ich habe leider mit SVN und ähnlichem null Erfahrung.
Notepad++ gab mir diese Änderungen aus. Einen ordentlichen Export gibt es hier aber nicht ... daher die Änderungen leider als Screenshots.
Kurze Erläuterung:
Ich habe nicht bei jedem geprüften Reading den Gerätestatus gesetzt, sondern nur die guten readings gezählt und am Ende einen Status gesetzt.
Alles findes im sub OnTimer statt.
- bei "foreach $deviceName (@devs)" definiere ich my $LivingDev = 0;
die beiden Zeilen
$error = CommandSetReading(undef, "$deviceName $areading $dead") und
$error = CommandSetReading(undef, "$deviceName $areading $alive") habe ich auskommentiert
und stattdessen die Readings ohne Fehler gezählt .. mittels $LivingDev++;
zum Schluss bei 0 funktionierenden readings dead und sonst alive gesendet ... wie es im Originalcode verwendet wurde.
CodeAnpassung in sub OnTimer($):
sub OnTimer($)
{
my ($hash) = @_;
my $name = $hash->{NAME};
my $interval = AttrNum($name, 'interval', 0);
$hash->{INTERVAL} = $interval;
RemoveInternalTimer($hash);
return if (!$interval);
InternalTimer(gettimeofday()+$interval, 'FHEM::readingsWatcher::OnTimer', $hash, 0);
readingsSingleUpdate($hash, 'state', 'disabled', 0) if (IsDisabled($name));
return if(IsDisabled($name) || !$init_done);
my ($timeOutState, $errorValue, $timeout, $associated, $error, $readingsList);
my ($deviceName, $rSA, $age, @devices, $rts, @parts, @devs);
my ($alives, $deads, $state, $readings) = (0, 0, '', 0);
my @timeOutdevs = ();
foreach (keys %{$defs{$name}{READINGS}}) # alle eignen Readings
{ $readingsList .= $_ .',' if ($_ =~ /_/); }# nur die mit _ im Namen
@devs = devspec2array("readingsWatcher!=");
my ($areading,$dead,$alive) = split(":",AttrVal($name,'readingActivity','none:dead:alive'));
$dead = 'dead' if(!$dead);
$alive= 'alive' if(!$alive);
$areading = '' if ($areading eq 'none');
readingsBeginUpdate($hash);
foreach $deviceName (@devs)
{
$rSA = ($deviceName eq $name) ? '' : AttrVal($deviceName, 'readingsWatcher', undef);
my $LivingDev = 0;
if(defined($rSA) && !IsDisabled($deviceName) && !IsIgnored($deviceName))
{
push @devices, $deviceName if !grep {/$deviceName/} @devices; # keine doppelten Namen
# rSA: timeout, errorValue, reading1, reading2, reading3, ...
# 120,---,temperature,humidity,battery
# or 900,,current,eState / no errorValue = do not change reading
my @r = split(';', $rSA);
foreach (@r)
{
@parts = split(',', $_);
if (@parts > 2)
{
$timeout = int($parts[0]);
$errorValue = $parts[1]; # = leer, Readings des Device nicht anfassen !
# die ersten beiden brauchen wir nicht mehr
shift @parts;
shift @parts;
foreach (@parts) # alle zu überwachenden Readings
{
$_ =~ s/^\s+|\s+$//g; # $_ = Reading Name
$state = 0;
if ($_ eq 'STATE')
{
$_ = 'state'; $state = 1; # Sonderfall STATE
}
$age = ReadingsAge($deviceName, $_, undef);
if (defined($age))
{
$readings++;
if (($age > $timeout) && ($timeout>0))
{
push @timeOutdevs, $deviceName if !grep {/$deviceName/} @timeOutdevs;
$timeOutState = "timeout";
$deads++;
$rts = ReadingsTimestamp($deviceName, $_,0);
setReadingsVal($defs{$deviceName},$_,$errorValue,$rts) if ($errorValue && $rts); # leise setzen ohne Event
# $error = CommandSetReading(undef, "$deviceName $areading $dead") if ($areading); # und das mit Event
$defs{$deviceName}->{STATE} = $errorValue if ($errorValue && $state);
}
else
{
$alives++;
$timeOutState = "ok";
# $error = CommandSetReading(undef, "$deviceName $areading $alive") if ($areading);
$LivingDev++;
}
Log3 $name,2,$name.', '.$error if ($error);
my $r = $deviceName.'_'.$_;
readingsBulkUpdate($hash, $r, $timeOutState) if ($timeout>0);
$readingsList =~ s/$r,// if ($readingsList) ; # das Reading aus der Liste streichen, leer solange noch kein Device das Attr hat !
if ($timeout < 1)
{
$alives--;
$error = 'Invalid timeout value '.$timeout.' for reading '.$deviceName.'.'.$_;
Log3 $name,2,$name.', '.$error;
}
}#age
else
{
$error = 'Timestamp for '.$_.' not found on device '.$deviceName;
Log3 $name,3,$name.', reading '.$error;
readingsBulkUpdate($hash, $deviceName.'_'.$_, 'no Timestamp');
}
}# foreach @parts
if ($LivingDev > 0)
{
$error = CommandSetReading(undef, "$deviceName $areading $alive") if ($areading);
}
else
{
$error = CommandSetReading(undef, "$deviceName $areading $dead") if ($areading);
}
}# parts > 2
else
{
$error = 'insufficient parameters for device '.$deviceName;
Log3 $name,2,$name.', '.$error.' - skipped !';
}
}# if $readingsWatcherAttribute
}
}# foreach $deviceName
readingsBulkUpdate($hash,'readings' , $readings);
readingsBulkUpdate($hash,'devices' , int(@devices));
readingsBulkUpdate($hash,'alive' , $alives);
readingsBulkUpdate($hash,'timeouts' , $deads);
readingsBulkUpdate($hash,'state' , ($deads) ? 'timeout' : 'ok');
# nicht aktualisierte Readings markieren oder löschen
if ($readingsList)
{
my @a = split(",",$readingsList);
foreach (@a)
{
if ($_)
{
if (AttrNum($name,'deleteUnusedReadings','1'))
{
readingsDelete($hash, $_);
Log3 $name,3,$name.', delete unused reading '.$_;
}
else
{
readingsBulkUpdate($hash, $_ , 'unused');
Log3 $name,4,$name.', unused reading '.$_;
}
}
}
}
if (int(@devices))
{ readingsBulkUpdate($hash,'.associatedWith' , join(',',@devices)); }
else
{ readingsDelete($hash, '.associatedWith'); }
if (int(@timeOutdevs))
{ readingsBulkUpdate($hash,'timeoutdevs',join(',',@timeOutdevs));}
else
{ readingsBulkUpdate($hash,'timeoutdevs','none');}
readingsEndUpdate($hash, 1);
return undef;
}
sub Attr (@)
{
my ($cmd, $name, $attrName, $attrVal) = @_;
my $hash = $defs{$name};
my $error;
if ($cmd eq 'set')
{
if ($attrName eq 'disable')
{
readingsSingleUpdate($hash,'state','disabled',1) if ($attrVal == 1);
OnTimer($hash) if ($attrVal == 0);
$_[3] = $attrVal;
}
if (($attrName eq 'readingActivity') && ($attrVal eq 'state'))
{
$_[3] = '';
my $err = 'forbidden value state !';
Log3 $name,1,$name.', readingActivity '.$err;
return $err;
}
}
elsif ($cmd eq 'del')
{
if ($attrName eq 'disable')
{
OnTimer($hash);
}
}
return undef;
}
Screenshots:
ok, ich habe es begriffen. Einfach gesagt :
a. wird an einem Device nur ein Reading überwacht -> alles wie bisher
b. bei mehr als einem Readings sollte der User entscheiden (mal schauen wie) ob die einzelen überwachten Readings als UND oder ODER den Gesamtstatus bilden.
Eine einfache Möglichkeit wäre z.B.
attr Thermo1 readingsWatcher 300,???,CUL_RSSI,CUL2_RSSI
heute, Readings werden als ODER behandelt
attr Thermo1 readingsWatcher 300,???,CUL_RSSI+CUL2_RSSI
neu , als UND
Gute Idee beide Varianten zu ermöglichen.
Auch die Schreibweise gefällt mir.
Mein Vorschlag hat die "oder Variante" aber nicht beachtet.
Evtl. bräuchte man einen 2. Zähler, damit es nicht wieder zum flappen kommt.
(hauptsächlich das hatte mich ja gestört)
Wenn ich noch helfen kann ...
@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 :
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.
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)
Zitat von: dirk.k am 12 Januar 2020, 10:42:52
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
Ich habe mehrere Device , wo das state überwacht wird
attr FHEM_HC readingsWatcher 61,dead,state
allerdings --> wenn es kein state Reading gibt, --> wird das Reading
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
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 :)
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
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 :)
ZitatIMHO "wokrs as designed"
Schade , Leider so dann "unbrauchbar" ;)
Zitata. 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.
Zitat von: fhem-hm-knecht am 19 Januar 2020, 18:07:43
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.
Zitatvia 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.
ZitatDevice Typ es sich hier handelt
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_Timestampda 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
Zitat von: fhem-hm-knecht am 19 Januar 2020, 19:21:29
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.
Zitat von: fhem-hm-knecht am 19 Januar 2020, 18:07:43
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)
Zitater 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?
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
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?
Zitat von: tomcat.x am 25 Januar 2020, 09:29:38
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
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.
Nach dem Update am 13.04. wird das Device nicht mehr angelegt. Es kommt die Fehlermeldung.
ZitatMessages 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.
das ist als Fehlerbeschreibung leider etwas wenig. Was steht denn im Log ?
Zitat von: Wzut am 14 April 2020, 08:27:20
das ist als Fehlerbeschreibung leider etwas wenig. Was steht denn im Log ?
Hilft das?
2020.04.14 08:06:20 1: reload: Error:Modul 98_readingsWatcher deactivated:
"uniq" is not exported by the List::Util module
Can't continue after import errors at ./FHEM/98_readingsWatcher.pm line 45.
BEGIN failed--compilation aborted at ./FHEM/98_readingsWatcher.pm line 45.
2020.04.14 08:06:20 0: "uniq" is not exported by the List::Util module
Can't continue after import errors at ./FHEM/98_readingsWatcher.pm line 45.
BEGIN failed--compilation aborted at ./FHEM/98_readingsWatcher.pm line 45.
Kannst du bitte mehr Angaben zu deinem verwendetem System machen auf dem FHEM bei dir läuft ?
Zitat von: Wzut am 14 April 2020, 09:07:19
Kannst du bitte mehr Angaben zu deinem verwendetem System machen auf dem FHEM bei dir läuft ?
Raspberry Pi 3B+ mit stretch
FHEM wird aller paar Tage aktuallisiert
Auf Grund der Diskussion zum Code Review
ZitatThis is perl 5, version 24, subversion 1 (v5.24.1)
hmm , komisch das entspricht meiner Testumgebung.
Anyway mach bitte morgen nach 8 Uhr nochmal ein Update dann gibt es eine Version ohne List::Utils
Scheint behoben. Danke.
@Wzut
Im Reading "html" stehen bei mir hornalte Einträge, die es als Devices nicht mehr gibt. set clearReadings, set checkNow führte ich aus, das ändert leider nichts. Das Reading "html" nutze ich, um die Meldungen in der FTUI-Oberfläche zu haben.
Ich update FHEM regelmäßig (und hoffe, dass ich damit aktuell bin - oder ist da was zu beachten?).
Ich weiß, dass meine Fehlermeldung unspezifisch ist: Was habe ich zu liefern?
Das ist klar, das Modul hat kein eigenes Reading mit Namen html :)
Wenn ich mich richtig erinnere (Antwort #39) hatte ich auf deinen Wunsch eine Kommata getrennte Liste der toten Geräte dazugenommen.
Diese Liste steht aktuell im Reading deadDevs
Zitat von: Wzut am 11 Oktober 2020, 07:41:16
Das ist klar, das Modul hat kein eigenes Reading mit Namen html :)
Wenn ich mich richtig erinnere (Antwort #39) hatte ich auf deinen Wunsch eine Kommata getrennte Liste der toten Geräte dazugenommen.
Du bist ein sehr freundlicher Helfer.
Zitat von: Wzut am 11 Oktober 2020, 07:41:16
Diese Liste steht aktuell im Reading deadDevs
Soweit zur hohen Theorie.
In der niederen Praxis sind (bei gleichem Reading-Datum!) beide inhaltlich völlig unterschiedlich. Es wirkt auf mich so, als ob der Mechanismus irgendwann quasi eingefroren wurde, ich sehe einen recht alten Stand.
Was muss ich denn tun, damit das Reading "html" wieder uptodate kommt?
kurze Antwort :
attr <name> userReadings html:deadDevs.* {return ReadingsVal($name, 'deadDevs', '???');}
wobei ich noch sagen muss das es zwei Listen gibt : deadDevs und timeoutDevs daher must du entscheiden was deinen Wünschen enstpricht.
Lange Antwort :
Da das Modul selbst kein Reading mit Namen html erzeugt muss es bei dir auf eine andere Art entstehen bzw. entstanden sein.
Möglichkeiten wären u.a. entweder ein bereits vorhandens userReading oder ein notify/DOIF das mit setreading arbeitet.
Aber warum muss es denn unbedingt html sein ? Ändere doch einfach im anderen Device ( TabletUI ? ) die Quelle.
Hallo,
Eine kleine Bitte noch, könntest du die Hilfe noch mal überarbeiten
Attribut:
readingActifity versus readingActivity
Danke und Gruß
Carlos
Hallo,
cooles Modul, genau was ich gesucht hatte.
Besteht die Möglichkeit, dass das Attribut "client-event" wieder aktiviert wird? Dann wär's perfekt für mich!
Gruß
Markus
...Ach nee, ich habe mittlerweile bemerkt, dass ein Reading, das per 'readingActivity' erzeugt wird, ein Event im Client-Device erzeugt.
Das ist völlig ausreichend.
Hi,
besteht die Möglochkeit alle Readings des Device zu überwachen, ohne diese einzeln aufzuführen?
.* hat nicht funktioniert.
Eine direkte Antwort habe ich leider nicht, gemäß commandref sieht es nicht so aus, als ob das ginge.
ABer Anmerkungen: Ich denke, Du willst das nur für ein bestimmtes Gerät machen, dann wäre es aber auch nur ein einmaliger Aufwand, alle Readings aufzunehmen. Falls Du das für alle Geräte machen willst: Ich habe Geräte, die schon bei der Abfrage ein Reading ändern. Gleiches gilt für ein "Fehler-Reading". In beiden Fällen wären das aus meiner Sicht keine Readings, die man in die Liste für readingsWatcher zur Überwachung aufnehmen würde. Auch readingActivity dürfte man nicht verwenden, sonst hätte man eine Schleife gebaut, wenn man alle Readings (und damit auch das über readingActivity hinzugefügte) überwacht.
Hiho,
in der Anleitung muss was angepasst werden:
readingActifity (default none)
Das Modul kann ähnlich dem HomeMatic ActionDetector im überwachten Gerät ein eigenes Reading setzen und den Überwachungsstatus
in diesem speichern. Beispiel :
attr <name> readingActifity actifity
Erzeugt in den überwachten Geräten das zusäzliche Reading actifity und versorgt es mit dem Status dead bzw alive
attr <name> readingActifity aktiv:0:1
Erzeugt in den überwachten Geräten das zusätzliche Reading aktiv und versorgt es mit dem Status 0 bzw 1
Statt readingActifity muss es readingActivity sein!
Gruß Florian
Hallo zusammen,
ein Feature-Wunsch ...
ich nutze readingsWatcher nun schon lange und für einen Haufen Geräte.
Nun kommt es immer wieder vor, dass Geräte geplant längere Zeit nicht anwesend oder im Einsatz sind.
Es wäre toll, diese Geräte für readingsWatcher pausieren zu können, als sie die ganze Zeit in der Liste der ausgefallenen zu haben.
Genial wäre es, wenn der gesetzte "pausiert" Status verschwindet, wenn das Gerät wieder "alive" meldet.
Was haltet ihr davon?
Zitat von: Florian_GT am 03 Oktober 2021, 02:23:14
Statt readingActifity muss es readingActivity sein!
THX4Info, werde ich bei Gelegenheit fixen.
Zitat von: dirk.k am 06 Oktober 2021, 19:09:40
Es wäre toll, diese Geräte für readingsWatcher pausieren zu können
Ist schon drin wenn beim entsprechenden Device dessen Attribut disable oder ignore auf 1 gesetzt ist.
...da ich grade eh' dabei war, commandref-"id"-Vorschläge zu verteilen, hier einer für readingsWatcher :) .
Da das zentrale Attribut ja ein dezentrales ist, ist die eigentliche Modulbeschreibung jetzt halt verkürzt und der Teil in die Attributbeschreibung gewandert. Hoffe, es gefällt :) .
Eine funktionale Frage hätte ich noch: Ich würde gerne ein "totes" Reading ganz löschen. Dazu steht aber nichts in der commandref. Ohne jetzt hier bzw. dem Entwiicklungsthread dazu intensiv gesucht zu haben: Geht das?
Oder könnte man das ggf. (via Schlüsselwort "undef" (?)) ergänzen?
Zitat von: Beta-User am 29 Januar 2022, 07:14:07
commandref-"id"-Vorschläge zu verteilen
--snipp---
Ich würde gerne ein "totes" Reading ganz löschen.
a. verstehe im Moment nicht um was es genau geht schaue mir deine Datei heute Mittag mal an.
b. um Readings aufzuräumen : set <name> clearReadings - alles was noch gebraucht wird kommt dann es im nächsten Lauf wieder
Zitat von: Wzut am 29 Januar 2022, 09:24:37
a. verstehe im Moment nicht um was es genau geht schaue mir deine Datei heute Mittag mal an.
Na ja, zum einen ist "id" (statt "name") der neue (allgemeine) "Standard" bei der Identifizierung/Belabelung der Ankernamen in der commandref, zum anderen (und das ist hier der springende Punkt) erlaubt es eine bestimmte Benennung iVm. der Klarstellung, zu welchem Modul (z.B.) ein Attribut gehört, dann auch eine entsprechende Sortierung bei den Attributen allgemein und die Darstellung eines entsprechenden Hilfetextes. Siehe screenshot (das ist ausschnittsweise ein MQTT2_DEVICE). Gibt auch einen recht aktuellen Thread dazu im Dev-Bereich.
Zitatb. um Readings aufzuräumen : set <name> clearReadings - alles was noch gebraucht wird kommt dann es im nächsten Lauf wieder
Es ging eher darum, das Reading jeweils am Ausgangsdevice zu löschen. Mein Anwendungsfall ist aber ein Sonderfall und mir ist zwischenzeitlich was anderes dazu eingefallen, da ist eh' ein Eventhandler dazwischen...
Hi Wzut,
gibt es noch Fragen bzgl. der "id"-commandref?
Weitere Infos und links wären hier zu finden: https://forum.fhem.de/index.php/topic,125039.msg1206275.html#msg1206275 (https://forum.fhem.de/index.php/topic,125039.msg1206275.html#msg1206275)
nöö schon gut , ich werde deinen Vorschlag nehmen und will aber noch wegen alias Unterstützung ein neues Attribut einbauen.
Hallo,
ist schon etwas her:
Zitat von: Wzut am 11 Januar 2020, 09:04:16
ok, ich habe es begriffen. Einfach gesagt :
a. wird an einem Device nur ein Reading überwacht -> alles wie bisher
b. bei mehr als einem Readings sollte der User entscheiden (mal schauen wie) ob die einzelen überwachten Readings als UND oder ODER den Gesamtstatus bilden.
Eine einfache Möglichkeit wäre z.B.
attr Thermo1 readingsWatcher 300,???,CUL_RSSI,CUL2_RSSI
heute, Readings werden als ODER behandelt
attr Thermo1 readingsWatcher 300,???,CUL_RSSI+CUL2_RSSI
neu , als UND
Leider steht dazu nichts in der Doku. Ist das im Code enthalten? Was bedeutet hier UND / ODER genau? Wenn ich zwei Readings angebe, dann habe ich hier Interpretationsmöglichkeiten:
ODER:
- Gerät ist "dead" wenn eines oder das andere ausfällt?
- Es wird als "alive" angesehen, wenn das eine oder das andere noch aktiv ist?
Grüße,
Torben
Hallo,
ich habe ein paar batteriebetriebene Temperatursensoren mit Readingswatcher überwacht.
Attribut für RS im Device: 3600,,temperature,humidity,dewpoint,batteryPercent
Attribut in RS attr <name> readingActivity actifity
Sobald die Batterie irgendwann leer ist, gibt es nach geraumer Zeit natürlich in dem
Device die Meldung bei actifity "dead".
Das Log wird jedoch auch befüttert:
PERL WARNING: Argument "timeout" isn't numeric in numeric le (<=) at (eval 103242) line 1
Wie kann die Logmeldung verhindert werden, ohne das Device auf disabled zu stellen?
Hallo Panik,
ich hab ein ähnliches Problem mit Tuya-Devices, die solche log-Einträge im Minutentakt erzeugen:
2023.05.03 22:38:08.867 1: 'setreading tuya_local_bf40c31ece6575958bzage active alive' called form userReadings is prohibitedIch weiß leider nicht, wo ich ansetzen muss, um das zu verhindern.
Mir kommt beim Schreiben dieses Beitrags ein Gedanke. Der log-Eintrag sagt ja aus, dass ich ein setreading nicht in einem userReading tun darf. Dann sollte ich den Rat befolgen und eine andere Lösung suchen.
Viele Grüße Gisbert
Zitat von: Panik am 15 Januar 2023, 08:14:32Hallo,
ich habe ein paar batteriebetriebene Temperatursensoren mit Readingswatcher überwacht.
Attribut für RS im Device: 3600,,temperature,humidity,dewpoint,batteryPercent
Attribut in RS attr <name> readingActivity actifity
Sobald die Batterie irgendwann leer ist, gibt es nach geraumer Zeit natürlich in dem
Device die Meldung bei actifity "dead".
Das Log wird jedoch auch befüttert:
PERL WARNING: Argument "timeout" isn't numeric in numeric le (<=) at (eval 103242) line 1
Wie kann die Logmeldung verhindert werden, ohne das Device auf disabled zu stellen?
Naja, wenn man einen String 'timeout' wo hinschreibt, wo eine Zahl erwartet wird, kommt eine entsprechende Meldung.
D.h. die Weiterverarbeitung in dewpoint, SVG Plot, notify, Userreading....
Zitat von: Gisbert am 03 Mai 2023, 22:52:20Hallo Panik,
ich hab ein ähnliches Problem mit Tuya-Devices, die solche log-Einträge im Minutentakt erzeugen:
2023.05.03 22:38:08.867 1: 'setreading tuya_local_bf40c31ece6575958bzage active alive' called form userReadings is prohibitedIch weiß leider nicht, wo ich ansetzen muss, um das zu verhindern.
Mir kommt beim Schreiben dieses Beitrags ein Gedanke. Der log-Eintrag sagt ja aus, dass ich ein setreading nicht in einem userReading tun darf. Dann sollte ich den Rat befolgen und eine andere Lösung suchen.
Viele Grüße Gisbert
Leider zu früh gefreut.
Ich hab das ganze Konstrukt jetzt von einem userReading zum stateFormat verlagert, aber mit dem gleichen Ergebnis, dass sehr viele log-Einträge mit dem identischen Inhalt produziert werden.
Hier meine Definition des stateFormats meines Devices:
attr tuya_local_bf40c31ece6575958bzage stateFormat {if (ReadingsVal($name,'active','') eq "alive" or ReadingsVal($name,'state','') eq "alive" ) {"power: ".round(ReadingsVal($name,'cur_power',''),1)." W<br/>voltage: ".round(ReadingsVal($name,'cur_voltage',''),1)." V<br/>relay state: ".ReadingsVal($name,'state','')."<br/>device: ".ReadingsVal($name,'active','')} else {"device: ".ReadingsVal($name,'active','')}}Das Reading "active" wird durch den readingsWatcher erzeugt.
Viele Grüße Gisbert
Zitat von: Gisbert am 04 Mai 2023, 12:12:00Leider zu früh gefreut.
Ich hab das ganze Konstrukt jetzt von einem userReading zum stateFormat verlagert, aber mit dem gleichen Ergebnis, dass sehr viele log-Einträge mit dem identischen Inhalt produziert werden.
Hier meine Definition des stateFormats meines Devices:
attr tuya_local_bf40c31ece6575958bzage stateFormat {if (ReadingsVal($name,'active','') eq "alive" or ReadingsVal($name,'state','') eq "alive" ) {"power: ".round(ReadingsVal($name,'cur_power',''),1)." W<br/>voltage: ".round(ReadingsVal($name,'cur_voltage',''),1)." V<br/>relay state: ".ReadingsVal($name,'state','')."<br/>device: ".ReadingsVal($name,'active','')} else {"device: ".ReadingsVal($name,'active','')}}Das Reading "active" wird durch den readingsWatcher erzeugt.
Viele Grüße Gisbert
Ohne die entsprechenden Logeinträge kann ich nur Hellsehen.
Aber ReadingsVal und round() würde ich vermeiden. Dafür gibt es ReadingsNum, der 4. Parameter ist für die Anzahl der Stellen.
Genauso eine Zahl auszulesen und den Defaultwert als String anzugeben, erzeugt irgendwann eine Perl Warnung beim Weiterverarbeiten der Daten (dazu zählt auch das Loggen und Anzeigen der Plots).
Das gilt auch für readingsWatcher, wenn ich einen String z.B. 'timeout' ins Reading einer Zahl schreibe, kann ich damit nicht rechnen. Ergo gibt es ein Logeintrag.
Hallo frober,
danke für deine Hinweise. Ich werde das prüfen und versuche deine Vorschläge umzusetzen.
Die log-Einträge kommen im Minutentakt, manchmal ist aber eine halbe Stunde kein log-Eintrag da. Anschließend geht es wieder im Minutentakt weiter.
2023.05.03 22:38:08.867 1: 'setreading tuya_local_bf40c31ece6575958bzage active alive' called form userReadings is prohibitedDer Eintrag kommt, egal ob ich das im userReading- oder stateFormat-Attribut definiert habe.
Viele Grüße Gisbert
Zitat von: Gisbert am 04 Mai 2023, 15:41:16Hallo frober,
danke für deine Hinweise. Ich werde das prüfen und versuche deine Vorschläge umzusetzen.
Die log-Einträge kommen im Minutentakt, manchmal ist aber eine halbe Stunde kein log-Eintrag da. Anschließend geht es wieder im Minutentakt weiter.
2023.05.03 22:38:08.867 1: 'setreading tuya_local_bf40c31ece6575958bzage active alive' called form userReadings is prohibitedDer Eintrag kommt, egal ob ich das im userReading- oder stateFormat-Attribut definiert habe.
Viele Grüße Gisbert
Da passt was nicht, du hast im stateFormat kein setreading und wieso benutzt du überhaupt setreading im userReading? Mach keinen Sinn ..
Hallo frober,
zu der Erkenntnis, dass etwas nicht stimmt bin ich auch gekommen - insofern Zustimmung zu deiner Aussage.
Ich benutze kein setreading im Attribut userReading oder stateFormat:
attr tuya_local_bf40c31ece6575958bzage stateFormat {if (ReadingsVal($name,'active','') eq "alive" or ReadingsVal($name,'state','') eq "alive" ) {"power: ".round(ReadingsVal($name,'cur_power',''),1)." W<br/>voltage: ".round(ReadingsVal($name,'cur_voltage',''),1)." V<br/>relay state: ".ReadingsVal($name,'state','')."<br/>device: ".ReadingsVal($name,'active','')} else {"device: ".ReadingsVal($name,'active','')}}
Der log-Eintrag ist ja auch noch witzigerweise identisch, auch dann, wenn es gar kein userReading gibt sondern stattdessen stateFormat.
Viele Grüße Gisbert
Du hast irgendwo ein userReading, das folgendes macht:setreading tuya_local_bf40c31ece6575958bzage active alive
Hast du mal im readingsWatcher selbst geschaut.
Bin mir nicht sicher, ob das auch indirekt geht. D.h. dass du übers userReading den readingsWatcher triggerst.
Hallo frober,
im readingsWatcher gibt es kein userReading-Attribut:
define myreadingsWatcher readingsWatcher global
attr myreadingsWatcher interval 60
attr myreadingsWatcher readingActivity active
attr myreadingsWatcher room Heizung,Network,Weather
# CFGFN ./FHEM/Monitoring.cfg
# DEF global
# FUUID 5f283b49-f33f-e986-a37b-6e4760f3e10ebe51
# FVERSION 98_readingsWatcher.pm:v2.1.3-s25053/2021-10-07
# INTERVAL 60
# NAME myreadingsWatcher
# NR 869
# STATE ok
# SVN 25053
# TYPE readingsWatcher
# eventCount 2800
# READINGS:
# 2023-05-04 22:49:47 HeizungGB112_Heizung.System.Info ok
# 2023-05-04 22:49:47 Klingel_Klingel.System.Info ok
# 2023-05-04 22:49:47 Lichtstaerke.West_MAX44009_Illuminance ok
# 2023-05-04 22:49:47 Lichtstaerke_BH1750_Illuminance ok
# 2023-05-04 22:49:47 Pulsemeter_Pulsemeter.System.Info ok
# 2023-05-04 22:49:47 Stellantriebe.EG_EG.System.Info ok
# 2023-05-04 22:49:47 Temp.EG_EG.System.Info ok
# 2023-05-04 22:49:47 alive 9
# 2023-05-04 22:49:47 dead 0
# 2023-05-04 22:49:47 deadDevs none
# 2023-05-04 22:49:47 devices 9
# 2023-05-04 22:49:47 readings 9
# 2023-05-04 22:49:47 skipped 0
# 2023-05-04 22:49:47 skippedDevs none
# 2023-05-04 22:49:47 state ok
# 2023-05-04 22:49:47 timeoutDevs none
# 2023-05-04 22:49:47 timeouts 0
# 2023-05-04 22:49:47 tuya_local_bf1f765162617dcd31ido7_cur_voltage ok
# 2023-05-04 22:49:47 tuya_local_bf40c31ece6575958bzage_cur_voltage ok
#
setstate myreadingsWatcher ok
setstate myreadingsWatcher 2023-05-04 22:49:47 .associatedWith HeizungGB112,Klingel,Lichtstaerke,Lichtstaerke.West,Pulsemeter,Stellantriebe.EG,Temp.EG,tuya_local_bf1f765162617dcd31ido7,tuya_local_bf40c31ece6575958bzage
setstate myreadingsWatcher 2023-05-04 22:49:47 HeizungGB112_Heizung.System.Info ok
setstate myreadingsWatcher 2023-05-04 22:49:47 Klingel_Klingel.System.Info ok
setstate myreadingsWatcher 2023-05-04 22:49:47 Lichtstaerke.West_MAX44009_Illuminance ok
setstate myreadingsWatcher 2023-05-04 22:49:47 Lichtstaerke_BH1750_Illuminance ok
setstate myreadingsWatcher 2023-05-04 22:49:47 Pulsemeter_Pulsemeter.System.Info ok
setstate myreadingsWatcher 2023-05-04 22:49:47 Stellantriebe.EG_EG.System.Info ok
setstate myreadingsWatcher 2023-05-04 22:49:47 Temp.EG_EG.System.Info ok
setstate myreadingsWatcher 2023-05-04 22:49:47 alive 9
setstate myreadingsWatcher 2023-05-04 22:49:47 dead 0
setstate myreadingsWatcher 2023-05-04 22:49:47 deadDevs none
setstate myreadingsWatcher 2023-05-04 22:49:47 devices 9
setstate myreadingsWatcher 2023-05-04 22:49:47 readings 9
setstate myreadingsWatcher 2023-05-04 22:49:47 skipped 0
setstate myreadingsWatcher 2023-05-04 22:49:47 skippedDevs none
setstate myreadingsWatcher 2023-05-04 22:49:47 state ok
setstate myreadingsWatcher 2023-05-04 22:49:47 timeoutDevs none
setstate myreadingsWatcher 2023-05-04 22:49:47 timeouts 0
setstate myreadingsWatcher 2023-05-04 22:49:47 tuya_local_bf1f765162617dcd31ido7_cur_voltage ok
setstate myreadingsWatcher 2023-05-04 22:49:47 tuya_local_bf40c31ece6575958bzage_cur_voltage ok
Viele Grüße Gisbert
Hmm, setze mal ein 'attr global stactrace 1'.
Eines der ersten Meldungen, bevor die Warnung kommt, sollte weiterhelfen.
Hallo erst mal.
Vielen Dank für das Modul. Ich nutze es intensiv und es hat schon oft geholfen.
Ich hätte noch mal eine Anfrage/feature-request aufzuwärmen, den ich vor langer Zeit gestellt habe...
Problem:
Einzelne Geräte werden zeitweise (z.B. nur im Winterhalbjahr) nicht genutzt. (bei mir immer 2-5 Geräte)
Diese gehen auf DEAD. Ist soweit ja richtig.
Nur möchte ich diese "temporär stillgelegten" Geräte dort nicht haben.
Die Mischung mit "echten" Ausfällen ist unübersichtlich.
Den Hinweis diese Geräte auf "disabled" oder "ignore" zu setzen ... OK, aber einige Geräte haben kein "disabled" (SD_WS07, MQTT_DEVICE). Ausserdem müssten diese bei Wiederanlauf manuell "enabled" werden ... ungünstig, schlechter WAF
Ignore gibt es bei einigen Geräten ebenfalls nicht ... ausserdem verschwinden sie dann (fast) komplett aus dem WebUI und ich müsste sie auch erst manuell wiederbeleben.
Lösungsvorschlag:
Wäre es nicht möglich, wenn ich das Reading für den ReadingsWatcher (activ) manuell auf "disabled" oder "paused" setze, dieses im nächsten Durchlauf nicht auf "dead" geändert wird, sondern erst wieder, wenn ein "alive" kommt?
Dann würde das Gerät in diesem Moment aus seinem Winterschlaf erwachen und ohne manuellen Eingriff vollständig funktionieren...
Und die Liste der "toten" Geräte bliebe sauber .. und ich habe sogar eine neue Liste der pausierten Geräte.
Was haltet ihr davon?
viele Grüße,
Dirk