ab morgen gibt es das aus diesem thread http://forum.fhem.de/index.php/topic,23148.msg165046.html#msg165046 (http://forum.fhem.de/index.php/topic,23148.msg165046.html#msg165046) entstande modul readingsHistory.
damit lässt sich eine mit timestamps versehene liste von readings/events im fhemweb darstellen. neue zeilen werden am anfang eingefügt, alle zeilen größer als die konfigurierte anzahl fallen am ende weg.
es lassen sich entweder direkt die events ein oder mehrerer devices darstellen, das ganze kann ähnlich wie readingsGroup mit mapping und valueFormat aufbereitet werden oder es lassen sich mit 'set <device> add ...' eigene zeilen einfügen.
das update im web frontend erfolgt per longpoll. es werden hierbei jeweils nur die neu hinzugekommen zeilen übertragen und das auch nur wenn tatsächlich ein browser fenster mit dem history device offen ist.
die history wird bei 'save' automatisch mit gespeichert und beim neustart wieder geladen.
gruss
andre
und wie kriege ich da eine Liste raus, deren Inhalt (die letzten Readings) ich selbst weiterverarbeiten kann?
die eingecheckte version ist nur zum anzeigen.
eine schnittstelle für ein get baue ich gerade. eventuell auch ein mini api.
ich wollte aber erst das interne format dafür noch ändern damit man auf timestamp und wert zugreifen kann und nicht nur die zeile als string bekommt.
danke, das heißt, im Moment kann ich auf meinen Datenverschieber noch nicht verzichten.
erzähl doch mal was der genau macht. vielleicht passt es ja zum modul.
das steht in dem von Dir verlinkten Thema und war irgendwie mit der Auslöser für Deine Modulentwicklung...
Kann es sein das timestampFormat über die set add Möglichkeit nicht unterstützt wird?
ja. das habe ich gestern auch bemerkt. das muss ich noch reparieren.
ist repariert.
gruss
andre
Klasse, entweder ich teste es heute Abend und nehm die Version aus dem SVN oder ich wart bis morgen
in der aktuellen version gibt es ein 'get <device> history' damit lässt sich die history auflisten.
das format der zeilen ist zur zeit das hier:<timestamp>\t<device>\t<reading>\t<angezeigte zeile>
je nach verwendendungszweck ist ein get das nur eine bestimmte zeile zurück liefert bzw. ein direkter zugriff auf die interne liste aber besser wenn man das ganze weiter verarbeiten will. beides kommt noch.
gruss
andre
- Es heisst :noArg nicht :noArgs
- Wieso steht eigentlich nirgends, dass das ganze Modul nicht nutzbar ist, wenn der Anwender mit configDB arbeitet? (Zumindest hat das Modul bei mir NULL Effekt)
1. ist repariert
2. es gibt nichts im modul das verhindert das es mit configDB funktioniert. und config db sollte nichts am event handling ändern.
was versuchte du zu tun?
ps: das was tatsächlich noch nicht geht ist das save file in die configDB zu schreiben. das kommt demnächst für alle meine module wenn ich auf die generischen read/write funktionen umgestellt habe.
Achtung: die generischen read/write Funktionen beziehen sich nicht auf fhem-Konfigurationsdaten, also nicht auf das, was in fhem.cfg und fhem.save steht. Und bei configDB gibt es kein $attr{global}{statefile} mehr.
Was ich versuche? Ich will die letzten acht Meldungen vom Türkontakt meiner Wohnungstür in einer Liste sehen.
ZitatUnd bei configDB gibt es kein $attr{global}{statefile} mehr
das ist erst mal schlecht. ich verwende $attr{global}{statefile} um rauszufinden wo ich mein eigenes file hin schreiben kann. das heisst so lange ich nicht umgestellt habe wird die history beim save nicht persistent gespeichert.
die events kommen ja doch an...
das format ist nicht unvernünftig. es ist sogar dokumentiert. aber es ist nicht unbedingt zum automatischen weiter verarbeiten gedacht.
mach einen vorschlag was dir passen würde.
ich vermute mal dir gefällt der html teil nicht? die links kannst du mit nolinks abschalten. die   in der nächsten version mit nohtml.
Zitat von: justme1968 am 20 Mai 2014, 21:18:56
aber es ist nicht unbedingt zum automatischen weiter verarbeiten gedacht.
Dann ist es m.E. ziemlich sinnlos.
Sorry - im Moment ist mein Frustpegel grade sehr hoch, nach all den Stunden, die ich jetzt mit dem Modul zugebracht habe, ohne auch nur den geringsten Nutzen in Bezug auf die ganz am Anfang stehende Frage (wie kann ich die letzten Schaltevents abfragen?) erkennen zu können.
Für mich ist das grade nix Ganzes und nix Halbes. Ein Spielzeug für Frontend-Fetischisten, aber ansonsten zu nix zu gebrauchen. Lass mich mal eine Nacht drüber schlafen, vielleicht kann ich Dir dann beschreiben, was meiner Ansicht nach Sinn machen könnte.
das modul ist primär zur anzeige im web frontend entstanden. dazu wird es von den augenblicklichen anwendern verwendet.
darum ging es im ursprünglichen thread auch primär.
weil es aber klar ist das es auch fälle gibt wo es um das automatische weiterverarbeiten geht habe ich das interne format umgestellt damit man auch an die daten kommt.
das modul passt nicht nicht auf das was du damit machen möchtest. warum du stunden brauchst um das festzustellen ist mir nicht ganz klar.
da ich nicht genau weiss was du wirklich machen möchtest kann ich noch keinen besseren vorschlag machen. aber so lange es nicht besser direkt in einer db aufgehoben ist denke ich ist das modul mit ein paar änderungen auch für dich zu verwenden. timestamp, device und event sind ja da.
Ich habe alleine Stunden gebraucht, um überhaupt erstmal events da rein zu bekommen. Um dann relativ schnell festzustellen, dass ich die Werte nicht wieder sinnvoll rausbekomme.
Wenn ich mir die ersten drei Beiträge in dem ursprünglichen Fragethread anschaue, komme ich zu einer anderen Intention, als das was Du jetzt gemacht hast. Aber ich hatte ja damals schon vor Deiner Idee "gewarnt", weil ich schon vermuten konnte, dass am Ende wieder etwas völlig anderes rauskommt.
Wieso fängst Du bei Deinen Entwicklungen immer (readingsGroups ist für mich ein genau so sinnloses Modul wie die readingsHistory im Moment) mit der Darstellung an, anstatt erstmal darüber nachzudenken, wie man die Daten am sinnvollsten gewinnt und speichert (dann wäre Dir im Vorfeld schon aufgefallen, dass das mit dem statefile die schlechteste aller denkbaren Ideen ist)? Die Anzeige von vorhandenen Daten ist doch immer der letzte (und meistens einfachste) Schritt. Ich sag nur "M-V-C"
Und könntest Du bei Gelegenheit den Fehler im Thread-Titel korrigieren?
@betateilchen: es geht hier weiter: http://forum.fhem.de/index.php/topic,23148.msg170425.html#msg170425 (http://forum.fhem.de/index.php/topic,23148.msg170425.html#msg170425)
vielleicht kann mal ein moderator den nicht ankündigungs teil in den anderen thread verschieben.
danke
andre
... und den Schreibfehler im Thread-Titel korrigieren, wenn schon der Threadersteller das trotz Hinweis nicht für nötig hält.
sei doch nicht so gereizt und unterstelle immer gleich etwas.