[erledigt] einfache liste mit readingshistory formatieren

Begonnen von the ratman, 08 Dezember 2021, 16:03:39

Vorheriges Thema - Nächstes Thema

the ratman

hiho,

ich spiele grade das erste mal mit readingshistry herum und dachte eigentlich, dass rennt wie readingsgroup ab. leider komm ich nicht wirklich weiter, sobalds ums formatieren der ausgabe geht.

meine readingshistoryDEF doif_tts_durchsage:text
nolinks 1
rows 5

die ausgabe sieht wie folgt aus:say verlauf
15:59:00  tts say text: nichts
15:58:50  tts say text: test 03
15:58:49  tts say text: nichts
15:58:39  tts say text: test 02
15:30:53  tts say text: nichts
15:30:43  tts say text: test 01
das ist auch korreckt so.

wie kriege ich alle zeilen mit der ausgabe "nichts" aus der tabelle gelöscht und
die ganze spalte "tts say text:" müsste auch noch vollkommen weg.
das ergebniss sollte also so aussehen:say verlauf
15:58:50 test 03
15:58:39 test 02
15:58:20 test 01


mit "mapping" und "valueformat" krieg ich das scheinbar nicht hin, so wies bei readingsgroup funktioniert.
→do↑p!dnʇs↓shit←

frank

probiere
attr mapping {'doif_tts_durchsage' => ''}
attr valueFormat {($VALUE eq 'nichts')? undef: $VALUE}
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

the ratman

oh ja - und ich hab auch wieder den fehler gefunden ... mich

20:30:06   videodaten fertig bearbeitet
20:29:12   test
20:13:01  tts say text: nichts
20:12:51  tts say text: die fabrik beginnt zu drucken
20:09:03  tts say text: nichts


gedankengang war: reload reicht um auch die alten sachen angepasst zu sehen.
tuts natürlich nicht, aber eine testausgabe kommt richtig und dann auch kein "nichts" hintenan mehr

danke dir vielmals!
→do↑p!dnʇs↓shit←

the ratman

hiho nochmal ...

irgendwas stimmt da wohl nicht so 100%
ich hatte bis eben die richtige anzeige mit der korrekten menge an infos. nun hab ich mein morgendliches update gemacht und die letzten 2 oder 3 informationstexte  von gestern abend fehlten auf einmal.
wird das wo zwischengespeichert und müsste erst abgespeichert werden?

mein ergebnis schaut derzeit so aus:09:55:06   videodaten fertig bearbeitet
20:45:21   treibhaus - alles ist geschlossen.
20:37:26   die fabrik ist für den nächsten druck bereit
20:36:55   die fabrik ist mit ratbörsl v41-kartenklemme re fertig
20:30:06   videodaten fertig bearbeitet
20:29:12   test

letzte zeile kam gerade eben wieder korrekt. btw - ist derzeit zum testen auf 10 rows gestellt und die sind noch nicht mal erreicht.

muss ich irgendwo was einstellen, oder ist die readingshistory keine richtige history und leidet unter vergesslichkeit?
→do↑p!dnʇs↓shit←

frank

Zitatmuss ich irgendwo was einstellen, oder ist die readingshistory keine richtige history und leidet unter vergesslichkeit?
gute frage.

bisher dachte ich, dass die werte der readingshistory im state file (fhem.save) gespeichert werden, welches vor einem "normalen" shutdown restart eigentlich automatisch aktualisiert werden sollte.

nun habe ich gesehen, dass die werte in einem extra file "readingsHistorys.dd.save" im log verzeichnis zu finden sind.
das wird zumindestens aktualisiert, wenn man "save config" ausführt.

eventuell ist es auch abhängig von "attr global autosave"
Zitatautosave
enable some modules to automatically trigger save after a configuration change, e.g. after a new device was created. Default is 1 (true), you can deactivate this feature by setting the value to 0. Configration errors at startup automatically deactivate this value.
schau mal auf deinen aktuellen wert von autosave.

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

the ratman

gut, heißt wenigstens mal, dass der fehler nicht wieder zwischen meinen ohren liegt.

muss ich mir wieder angewöhnen, vorher den save-button zu drücken, auch wenn's eigentlich nix zu saven gibt.
hatte ich früher mal sogar immer gemacht. warum auch immer, frag ich mich grade *g*
autosave mag ich ned - das geht mir dann alles zu schnell und zu ungeprüft, ist also bei mir tatsächlich auf "0".

wenn's allerdings ne elegantere lösung gibt, sag ich ned nein.
→do↑p!dnʇs↓shit←

frank

ich habe mal in den code geschaut.
so wie ich das verstehe, wird das sichern von einem event SAVE getriggert.
wenn ich jetzt ein event SAVE für meine readingshistory erzeuge, verändert sich das datum der ersten zeile im file readingsHistorys.dd.save. scheint also zu funktionieren.

du könntest also zum speichern der history den fhem cmd "trigger <name_deiner_readingshistory> SAVE" an passender stelle absetzen.

ich habe für meine rh mal ein notify zum automatischen speichern erstellt, das durch ein update event der rh getriggert wird. also bei jedem neuen eintrag wird gespeichert:
defmod n_autoSave_rh_nreachable notify rh_unreachable:history:.* trigger rh_unreachable SAVE
zusätzlich das "attr alwaysTrigger 1" in der rh gesetzt.

sieht gut aus.
ich hatte auch manchmal den eindruck, dass meine rh manchmal alzheimer hatte. aber kein wunder, wenn bei mir öfter mal global autosave auf 0 springt.

noch eleganter wäre natürlich ein zusätzliches attribut autosave für die rh.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

the ratman

#7
oh ja attr autosave - aber ich hab so den eindruck, als ob readingsXxx ein bissi stiefmütterlich behandelt werden würde.
sollte man mal mit dem maintainer reden? wobei - mich nimmt er sicher ned ernst genug *g*.

derweil ... bei mir hieße das dann wohl (is mein erstes notify):
defmod notify_autoSave_sayHistory notify sayHistory:history:.* trigger sayHistory SAVE

naja, einfach mal rein werfen ins fhem. was kostet die welt?
→do↑p!dnʇs↓shit←

the ratman

wollte nur verkünden: dein notify scheint zu funzen. meinen guten-morgen-neustart hats überlebt. alles steht noch da, wie es soll.

frank, ich dank dir für deine hilfe!
→do↑p!dnʇs↓shit←

frank

fein, wenn es funktioniert.

falls du dieses nützliche tool nun öfter verwenden solltest, noch ein tip zum speichern:
mit dem notify wird ja bei jedem neuen eintrag gespeichert. das ist natürlich nur ratsam, wenn die einträge auch nur gelegentlich und einzeln eintrudeln.

wenn die readingshistory deutlich mehr events "einfängt" ist es sicherlich besser ein "at" zu benutzen, das den trigger cmd dann vielleicht alle 5-10 minuten auslöst.
oder ein notify, das nur beim globalen SHUTDOWN event ein speichern auslöst.

ausserdem ist bei mehreren readinghistories wahrscheinlich nur ein device zum auslösen des speicherns nötig, da ja alle readinghistories in ein file speichern. sollte man ggf nochmal checken.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

the ratman

war soweit klar ...

bei zeiten wollt ich mir dann eh ein doif basteln, wenn's mal mehr history gäbe. und da ich eh nicht weiß, wie ich das notify da umsetzen müssten, wärs eh eine zeitsteuerung geworden. was weiß ich ... alle 1-5 min alle historys auf einmal speichern.

ganz neue idee ist: ich speicher mir einfach mal die texte in die db und lese die dann von dort aus. wäre wohl das sicherste. müsste ich mir halt wieder angucken, wie man sowas macht und auch wieder das "nichts" ignoriert.
aber jetzt lass ich mal das notify weiter vor sich hin speichern.
wer weiß, vielleicht sieht ja der maintainer diese texte und ihm ist grad langweilig ...
→do↑p!dnʇs↓shit←