readingshistory - frage zum speichern der history

[the ratman]

hiho,

mir ist eben beim regulären neu starten meines servers aufgefallen, dass dabei rund 2 stunden infos abhanden gekommen sind.

die readingshistory schaut wie folgt aus (und funzt auch wunderbar):

Code: [Auswählen]

defmod sayHistory readingsHistory doif_tts_durchsage:text
attr sayHistory alias say verlauf
attr sayHistory alwaysTrigger 1
attr sayHistory fp_tablet_einstellungen 5,1000,0,sayHistory
attr sayHistory group start1
attr sayHistory mapping {'doif_tts_durchsage' => ''}
attr sayHistory nolinks 1
attr sayHistory room start
attr sayHistory rows 24
attr sayHistory valueFormat {($VALUE eq 'nichts')? undef: $VALUE}auszug aus der historie:

Code: [Auswählen]

11:29:30   test
08:58:54   der akku vom händilein wird langsam leer.
08:48:59   tagbetrieb
08:11:38   der akku vom händilein wird langsam leer.
07:51:24   neues mäusevideo
07:50:29   maus an
07:23:31   der akku vom händilein wird langsam leer.
mein neustart fand um recht genau 11:00 statt und in der history ist der letzte eintrag von ca. 9:00.
da fehlen mindestens 5 oder 6 einträge ...

kann man da irgendwo an einer schraube drehen?

[Benni]

Das sollte eigentlich auch im Statefile landen!
Ich habe mal rein geschaut und nix gefunden!  ... keine Ahnung wo das gespeichert wird! -> readingsHistory hat ein eigenes statefile! Gehe aber mal davon aus, dass das ebenfalls mit WriteStatefile gesichert wird! von daher ist meine Aussage von daher wohl doch richtig!

Ich habe es getestet, bei mir geht nichts verloren, wenn ich vor dem Neustart ein WriteStatefile Save ausführe!

Von daher: https://forum.fhem.de/index.php/topic,126138.msg1207459.html#msg1207459

sollte hier eigentlich auch funktionieren!

Also ich habe es mir jetzt direkt in readingsHistory angeschaut und readingsHistory liest sein Statefile beim FHEM-Start oder bei einem rereadcfg. Gespeichert wird es nur bei einem Save.

Wenn du das analog zum statefile alle 10 Minuten mitsichern möchtest, müsstest du das Speichern des readingsHistory-Statefile mit in dein at aufnehmen

Code: [Auswählen]

defmod saveState at +*00:10 {\
   WriteStatefile;;\
   readingsHistory_Save;;\
}

gb#

[the ratman]

seit gestern wird mein statefile alle 10 min gesichert - somit lauft das wohl nicht gemeinsam.

sorry, ich war nicht genau: ich hab ein "sudo halt" gemacht - da wird doch eh alles beendet, oder?
was wäre am besten zum beenden von debian, wenn es kein halt ist?

[Benni]

seit gestern wird mein statefile alle 10 min gesichert - somit lauft das wohl nicht gemeinsam.

sorry, ich war nicht genau: ich hab ein "sudo halt" gemacht - da wird doch eh alles beendet, oder?
was wäre am besten zum beenden von debian, wenn es kein halt ist?

Ich habe meinen Beitrag oben noch mehrfach editiert.
Inzwischen sollte er inhaltlich passen! 

gb#

[the ratman]

*verbeug* dank dir!

schaut also in der def dann so aus

Code: [Auswählen]

+*00:10 {WriteStatefile(); readingsHistory_Save }nur zur sicherheit, weil ich immer mit den mengen der ";" durcheinander komm.

[Benni]

Müsste passen (ein Semikolon nach dem readingsHistory_Save kann nicht schaden).

Das von mir war übrigens eine RAW-Def, die kannst du doch direkt so im RAW-Editor (das plus links oben neben der fhem-kommandozeile) ausführen lassen!

gb#

[the ratman]

ja, nur hab ich das modul ja schon, da find ich eine zeile ergänzen einfacher, als dann wieder räume/gruppen/icons dran zu hängen bei nem neuen modul.
und sag jetzt nicht, der würde das alte modul per raw-def nur ergänzen - ne, oder?

[Benni]

und sag jetzt nicht, der würde das alte modul per raw-def nur ergänzen - ne, oder?

https://fhem.de/commandref_DE.html#defmod

 

gb#

[the ratman]

oh ja, lesen bildet ... wobei - wenn man nicht drauf gestoßen wird. könnt's 2-3 sätze dau-fähigere erklärung durchaus vertragen. die erklärung zum bspl. kapier ich zumindest nicht wirklich.

[Benni]

Code: [Auswählen]

define mdNtfy notify motionDetector defmod mdOff at +00:10 set lamp off

Im Beispiel wird ein notify angelegt (mdNtfy), das auf einen event motionDetector reagiert.
Wenn dieses notify ausgelöst wird, wird soll als Reaktion darauf ein (einmaliges) at (mdOff) angelegt werden, das nach 10 Minuten eine Lampe (lamp) ausschaltet.

Wenn jetzt während der 10 Minuten, in denen der Timer abläuft, erneut ein Ereignis motionDetector auftritt und somit das notify erneut ausgelöst wird, dann würde ja auch erneut versucht werden, das ein at mit Namen mdOff anzulegen. Das funktioniert mit dem einfachen define-Befehl nicht, es würde ein Fehler auftreten (... blah, blah, .. mdOff existiert bereits,...)
Deshalb wird im Beispiel zum Anlegen/Ändern des at mdOff der defmod Befehl verwendet. Der prüft, ob das device bereits vorhanden ist und falls nein, wird es angelegt und falls ja wird die DEF des bereits vorhandenen entsprechend angepasst.

DAU-tauglich genug?

gb#

[the ratman]

dies ist jetzt KEIN angriff auf die hilfstext-schreiber, sondern nur der versuch, es aus dau-sicht zu erklären.
vielleicht führen solche beispiele ja irgendwann mal dazu, dass die commandref auch (richtig) genutzt (weil verstanden) wird ...

Das funktioniert mit dem einfachen define-Befehl nicht, es würde ein Fehler auftreten (... blah, blah, .. mdOff existiert bereits,...)

schreibts sowas doch zu oder anstelle

Falls man statt defmod ein define verwenden würde, dann würde eine Meldung innerhalb von 10 Minuten nach der letzten Meldung zu einem Fehler führen, da mdOff noch existiert.

das den dau (oder zumindest mich) verwirrende, ist der "fehler innerhalb 10 min" da überlegst du erst mal: "was passiert den in 10 min?". und schon bist aus der eigentlichen info draußen.
hardcore-dau: mein gerät sendet doch alle 3 min, kommt der fehler dann erst nach 3 mal senden, oder wie?
fortgeschrittener dau: warum gibt's überhaupt define, wenn defmod so viel besser ist?

sprich: keep it simple! ich weiß, da sind die text schreiber immer sehr bemüht, alles abzudecken (was ich auch sehr löblich finde), aber im endeffekt macht mans für "unwissende" nur schlimmer.

eigentlich müsst das wie ein zeitungsartikel gehen: überschrift - zusammenfassung für die daus - exakte infos für die pros.
man hats ja gelernt:
vortrag für interessierte --> halt die nivea-creme auf 12 jahre.
vortrag für fachleute --> kannst schon mal auf geistiges niveau von 16 hoch (aber vorsichtig *g*)

ist natürlich nur meine meinung, aber ne umfrage der "o8/15" user zu dem thema würd wahrscheinlich recht interessant werden *lach*.


bspl.:
überschrift: defmod
zusammenfassung: erstellt oder modifiziert module mit 1 oder 2 sehr simplen beispielen, am besten auch mit "ausgangssituation" eines zu modifizierenden moduls.
text: aktuelle commandref zu defmod

[Benni]

Ich verstehe jetzt nicht mehr, was der DAU mir sagen will!

Hab ich jetzt irgendwas zu ausführlich geschrieben oder noch nicht ausführlich oder strukturiert genug?

Und man sollte schon genau lesen, was da steht und sich nicht irgendetwas zurechtinterpretieren:

das den dau (oder zumindest mich) verwirrende, ist der "fehler innerhalb 10 min" da überlegst du erst mal: "was passiert den in 10 min?". und schon bist aus der eigentlichen info draußen.
hardcore-dau: mein gerät sendet doch alle 3 min, kommt der fehler dann erst nach 3 mal senden, oder wie?
fortgeschrittener dau: warum gibt's überhaupt define, wenn defmod so viel besser ist?

Geschrieben hatte ich aber folgendes:

Wenn jetzt während der 10 Minuten, in denen der Timer abläuft, erneut ein Ereignis motionDetector auftritt und somit das notify erneut ausgelöst wird, dann würde ja auch erneut versucht werden, das ein at mit Namen mdOff anzulegen. Das funktioniert mit dem einfachen define-Befehl nicht, es würde ein Fehler auftreten (... blah, blah, .. mdOff existiert bereits,...)

Und da steht nix davon, dass der Fehler innerhalb 10 Minuten auftritt! Sondern, dass wenn während der 10 Minuten, die der Timer (per Definition +00:10) läuft das notify erneut getriggert wird. Egal ob nach 3 Mintuen. oder Nach 6 Minuten, oder beides es tritt dann, genau beim eintreten des Ereignisses das "Problem" auf. Übrigens auch genau so oft wie das Ereignis auftritt, während der 10 Minuten. Nur eben nicht mehr nach den 10 Minuten, denn dann ist der Timer abgelaufen und hat sich selbst zerstört! (Die Selbstzerstörung ist der fehlende * in der definition des at).

fortgeschrittener dau: warum gibt's überhaupt define, wenn defmod so viel besser ist?

defmod ist nicht besser! Es ist anders! Manchmal möchte man ja ein device gar nicht ändern, falls es schon existiert.
defmod  ist eigentlich auch genau zu dem Zweck da, nämlich eine DEF zu MODifizieren

sprich: keep it simple!

"If you try to make something idiot-proof, they'll invent a better idiot!"

gb#

PS: Auch jeder DAU darf am FHEM-Wiki teilnehmen. Wer könnte denn besser etwas DAU-tauglich dokumentieren, als der DAU selbst!

[the ratman]

nönö, alles bestens *g*

wollt tatsächlich nur mal so aus dau-sicht generelles zur commandref ablassen und hab versucht, mich an meine doof-dau-zeiten zurück zu erinnern. jetzt bin ich ja schon beglaubigter "fortgeschrittener dau".

PS: Auch jeder DAU darf am FHEM-Wiki teilnehmen. Wer könnte denn besser etwas DAU-tauglich dokumentieren, als der DAU selbst!

besser wäre dau dokumentiert unter überwachung. sonst gibt's wahrscheinlich sehr schnell sehr falsche infos da drinnen ...