Hallo erstmal,
ich möchte eine Liste der letzten Schaltevents (z,B, die letzten 5 mit Timestamp) von meinen ENOCEAN und HM Schaltern im WebInterface anzeigen lassen, z.B. in einer Liste. Im RSS-Workshop Kann mir vielleicht jemanden einen Tipp geben, mit welcher FHEM-Funktionen das umzusetzen wäre? Im RSS-Workshop habe ich so etwas im Screenshot von betateilchen gesehen, aber halt für RSS.
Besten Dank für eure Hilfe
Guido
Steht das nicht alles im Logfile? Das kann man doch im Webinterface aufrufen.
Zitat von: bads am 02 Mai 2014, 15:37:42
Im RSS-Workshop habe ich so etwas im Screenshot von betateilchen gesehen, aber halt für RSS.
Das ist ein Dummy, der als Speicher dient und für jeden Event ein Reading hat. Dazu gibt es eine Funktion, die bei jedem neuen Event getriggert wird und die Daten um eine Stelle weiterschiebt, d.h.
Speicherzelle3 = Speicherzelle2
Speicherzelle2 = Speicherzelle1
Speicherzelle1 = neuer Wert
Der jeweils älteste Wert geht dabei verloren. Das Ganze läßt sich nahezu beliebig kaskadieren und funktioniert mittels setreading auf den Dummy.
sub rotateLastLog() {
for (my $i=8;$i>0;$i--){
my $l = $i-1;
$l = ReadingsVal("LastLog","LastLog$l","-");
fhem("setreading LastLog LastLog$i $l");
}
my $a = localtime(time); fhem("setreading LastLog LastLog1 $a");
return;
}
Im Beispiel heißt der Dummy "LastLog" und hat die Readings "LastLog1" bis "LastLog8".
Danke,
in die Richtung hatte ich auch schon vermutet. Jetzt muss ich nur noch irgendwie eine vernünftige Anzeige dazu basteln.
zur anzeige schau dir mal readingsGroup an.
eventuell wäre es noch gut die ganzen fhem( "setreading...") aufrufe durch einen readingsBeginUpdate/readingsEndUpdate block und readingsBulkUpdate zu ersetzen. das sollte bei so vielen readings einiges bringen.
gruss
andre
Ach Andre, manchmal würde ich mir wünschen, Du würdest Dich bei Deinen Antworten öfters mal in die Rolle eines Anfängers versetzen. Jemand, der schon mit dem Verschieben von Werten innerhalb von Variablen ein Problem hat, hat doch von den fhem-internen Funktionen readingd*Update ohnehin noch nie was gehört und ist froh, wenn er den fhem() Befehl versteht.
ist es dann nicht um so wichtiger gleich die 'richtige' lösung zu zeigen und zu erklären warum statt eine nicht optimale version zu zeigen (die nicht wirklich weniger komplex ist) und die dann x mal kopiert und verwendet wird ohne auch nur eine idee zu haben warum es anders besser wäre?
Die frage nach einem "Event-Log" kam ja in letzter Zeit wirklich oft. Ich würde auch gerne eine Übersicht haben in der die von mir gewünschten letzten Schaltvorgänge oder Events z.b Presence angezeigt werden. Im Logfile findet sich immer alles im jeweiligen Log-Level...
Vielleicht kann ja einer von euch mal erklären wie man so etwas erstellt - genial wäre eine art eigenes Log-Level welches man per attribut auch at oder notify geben könnte.
Zitat von: justme1968 am 03 Mai 2014, 09:47:35
ist es dann nicht um so wichtiger gleich die 'richtige' lösung zu zeigen
Für Entwickler ja, für reine Anwender nicht. Für die readings*Updates müsstest Du dem Anwender nämlich auch erst einmal erklären, was ein $hash ist und wie man damit umgeht - bei setreading muss er sich darum keine Gedanken machen.
Genau für die Zielgruppe "reiner Anwender" wurde der fhem() Befehl geschaffen: um fhem Befehle, die man aus der Kommandozeile kennt, auch in eigenen Funktionen der 99_myUtils zu verwenden.
Und Du kannst nicht wirklich behaupten, dass meine vorgeschlagene Lösung FALSCH sei.
ich habe nie gesagt das es falsch ist. nur das es ungeschickt ist aus jedem event 8 zusätzliche neue zu erzeugen.
das dein lösung auch schon mindestens zwei stufen über einsteiger ist wirst auch du zugeben. da sind so viele konzepte wie variablen, readings kopieren, myUtuls, perl, das mischen von perl und fhem, schleifen, stringverarbeitung, localtime das das readingsUpdate & co den kohl auch nicht mehr fett macht.
das deine Antwort didaktisch geschickter war als meine heißt glaube ich nicht das man sie so als ideallösung stehen lassen sollte ohne auf die probleme hin zu weisen.
Zitat von: der-Lolo am 03 Mai 2014, 10:04:03
Die frage nach einem "Event-Log" kam ja in letzter Zeit wirklich oft. Ich würde auch gerne eine Übersicht haben in der die von mir gewünschten letzten Schaltvorgänge oder Events z.b Presence angezeigt werden. Im Logfile findet sich immer alles im jeweiligen Log-Level...
Vielleicht kann ja einer von euch mal erklären wie man so etwas erstellt - genial wäre eine art eigenes Log-Level welches man per attribut auch at oder notify geben könnte.
Über so etwas hab ich auch schon mehrmals nachgedacht aber bin auf nichts vernünftiges gekommen.
was genau wollt ihr denn sehen?
nur die zeiten? oder das event? oder beides?
reicht es wenn es im web frontend zu sehen ist? soll es auch auf der kommando zeile funktionieren? oder sogar persistent gespeichert werden so das es nach einem neustadt auch noch da ist?
ich könnte mir eine art 'history' modul vorstellen das man per regex auf device und readings konfigurieren kann.
wichtig ist zu unterscheiden ob es wirklich um log einträge gehen soll oder um device events. das ist ein grundlegender unterschied. ich denke es geht um device events oder ?
mein vorschlag wäre es nicht persistent zu machen und keine readings zu verwenden (zumindest keine zusätzlichen events zu triggern).
ich könnte mir vorstellen so etwas als reines anzeige modul mit de readingsGroup als grundlage zu bauen. oder sogar direkt dort rein.
sag mir wenn ich wieder mal übers ziel hinaus schieße :)
gruss
andre
edit: oder man baut etwas so wie average das die history direkt ins original device steckt. aber auch wieder ohne events zu triggern.
toll wäre wenn es ähnlich wie devStateIcon ein attribut gäbe in dem man eine art userLogMap schreiben könnte...
attr fritzCall userLogMap missed:Verpasster Anruf
attr SonosBad userLogMap appeared:Sonos Bad abspielbereit play:Wiedergabe im Bad gestartet
attr handyPresent userLogMap absent:Michael ist gegangen present:Michael ist gekommen
attr timer_hzg userLogMap on:Nachtabsenkung ausgeschaltet off:Nachtabsenkung eingeschaltet
attr LS_Wohnen userLogMap hell:Lichtszene hell im Wohnzimmer gewählt Dunkel:Lichtszene Dunkel im Wohnzimmer gewählt AUS:Licht im Wohnzimmer ausgeschaltet
userLog wäre dann eine group die einfach überall, also auch im Dashboard rollierend auf x einträge festgelegt angezeigt werden könnte... Das Dashboard bietet die möglichkeit eine spalte Bottom zu definieren, in dieser würde ich gerne einen Timestamp ohne Datum und den jeweils passenden Eintrag von userLogMap sehen.
userLogMap müsste dann als attribut in allen möglichen Modulen zur verfügung stehen, das ist glaube ich das schwierigste...
07:05 Verpasster anruf von 0815/4711
06:40 Michael ist gegangen
06:20 Wiedergabe im Bad gestartet
06:19 Sonos Bad abspielbereit
06:00 Nachtabsenkung ausgeschaltet
Edit:
über die Log funktion mache ich das teilweise selbst - problem ist das es ja nur im logfile sichtbar ist.
Zitat{Log 1, "Micha ist nach Hause gekommen..."}
wenn es nun ein eigenes LogLevel z.b. 6 gäbe könnte man jeder funktion problemlos einen eigenen log hinzufügen - diesen dann benutzen um ihn in einer rollierenden Liste anzuzeigen...
ausserdem müsste dann Log6 auch zur verfügung stehen wenn verbose auf 3 steht.
wenn es in jedem modul selber zu sehen sein soll wäre der weg über etwas das wie average funktioniert der richtige. aber nur wenn die history auch im device selber angesehen wird. sonst ist es unnötiger overhade.
eine gruppe die nur ein bestimmtes reading aus einem device anzeigt geht nicht. das könnte aber readingsGroup machen.
wenn eh alle history events angezeigt werden sollen wäre ein einziges history device richtig bei dem alle in frage kommenden device/reading kombinationen als filter konfiguriert werden können. ein device -> so wenig overhead wie möglich
ich denke es ist sinnvoll die anzeige so zu optimieren das events zum update nur dann erzeugt werden wenn die anzeige auch aktiv ist. d.h. es sollten im anderen fall keine zusätzlichen events erzeugt werden.
die Konfiguration auf ebene jedes devices zu machen hat zwar den charm das es gleich den kontext hat, es hat aber den nachteil das es dann nur ein mal pro device möglich ist. eine konfiguration die z.b. pro stockwerk ein display hat und nur die events dieses stockwerks anzeigt und zusätzlich bestimmte globale geht z.b. nicht. es ist auch schwieriger zu optimieren wenn die information an unterschiedlichen stellen zusammengesucht werden muss.
die konfigurierbarkeit von device/reading kombinationen habe ich in readings group, eine notifyFn die auf events lauscht auch. die optimierung das keine zusätzlichen events erzeugt werden wenn es nicht nötig ist gibt es da auch.
ich glaube ich probiere mal wie das aussehen würden
Achtung Gefahr! Andre hat mal wieder eine Idee ... (denk an die Schaukel!)
also die idee ist nicht von mir. ich sammle nur. (und auch das mit den extentions war von dir :) )
und egal was du es drehst: im gegensatz zu allen schaukeln hat mein patch funktioniert, hat alle ebenen von ganz einfach bis komplett konfigurierbar abgedeckt, hätte sich auf die minimal lösung abspecken lassen und hätte im gegensatz zu rudis version auch bei dir und deiner oma funktioniert.
die version über log 6 gefällt mir je mehr ich drüber nachdenke immer besser...
so könnte man ja auch den auslöser mitgeben und sich die events die eingetragen werden sauber aussuchen...
Manchmal weiss man bei euch beiden echt nicht wann ihr euch wirklich streitet - oder wann es gekabbel oder ironie ist...
Zitat von: der-Lolo am 03 Mai 2014, 12:08:44
oder wann es gekabbel oder ironie ist...
einfach: in 99,9% der Fälle ist es das :)
sorry Leute,
hatte nicht beabsichtigt das meine Frage so ausufert ;-) Meine ursprüngliches Ansinnen war es dies in einem mehrzeiligen Textfeld in Fhemweb darzustellen und dann über ein notify jeweils (wie in einem Ringbuffer) mit den letzten Events zu füllen. Da es wohl nicht so etwas wie eine allgemeine Möglichkeit eigene Informationen zur reinen Darstellung, wie eine Readonly-Textbox gibt, wollte jetzt mal ausprobieren so etwas über einen weblink einzubinden. ideal aus meiner Sicht wäre, wenn es eine Darstellungsmöglichkeit geben würde ein Logfile zu spezifizieren und die Anzahl der letzten x Zeilen die jeweils angezeigt werden sollen. Mit dem Unix-kommando tail sollte so etwas gehen und müsste halt nur bei einem Refresh (longpoll) jeweils aktualisiert werden. Da ich aber keine Ahnung von FHEMWEB habe, stehe ich etwas auf dem Schlauch, denn ein Device passt hier ja nicht?
guido
das ganze über ein log files also erst raus schreiben und dann wieder einlesen zu lösen ist die schlechteste variante.
wenn doch schon alles in fhem da ist ist es besser das drekt zu verwenden und so wenig wie möglich umwege und overhead zu erzeugen.
ich hab mal eine test version gebaut und bin am spielen.
die zusätzlichen events wenn man das ganze per readings macht sind wirklich nicht zu vernachlässigen. da rauscht ganz schön was durch den event monitor wenn man nichts optimiert.
das gilt auch für den update per longpoll. das scrollen durch neu schreiben aller sichtbaren zeilen hat genau das gleiche problem.
eine ressourcen schonende lösung würde das ganze wie der event monitor machen und nur neue zeilen zum browser senden und dort scrollen.
das ganze wäre dann im prinzip ein device das sich wie ein event monitor mit konfigurierbarem filter und größe verhält.
ich schau mal ob man den richtigen event monitor wieder verwenden kann.
Wow - das klingt toll..!
Ich bin sehr gespannt was da rauskommt...
here we go...
33_readingsHistory.pm ist ein normales fhem modul, fhemweb_readingsHistory.js muss nach .../www/pgm2
danach kannst du dir mitdefine <name> readingsHistory <device>:<readings> [<device>:<readings> [...]]ein history device definieren. <device> und <readings> sind jeweils reguläre ausdrücke. alles was matched wird in der history angezeigt.
<device> kann auch ein TYPE=xyz sein und <readings> auch einfach eine durch komma getrennte liste.
über das attribut rows kannst du konfigurieren wie viele zeilen die history umfassen soll.
das ganz sollte recht sparsam mir den ressourcen umgehen. es werden keine events erzeugt wenn das history device nicht auf dem monitor sichtbar ist und es werden immer nur die zusätzliche zeilen zum browser geschickt.
was noch nicht umgesetzt ist ist eine feste breite. d.h die anzeige ist zur zeit so breit wie die breiteste zeile. das kann man per stylesheet ändern.
was noch kommten könnte wenn es genug interesse gibt: ein attribut historyReadings für alle devices in dem man die default readings die in der history erscheinen sollen pro device konfguriert. im history device selber würde man diese liste dann ergänzen oder überschreiben.
gruss
andre
edit1-3: die device namen sind jetzt (optional) links die man anklicken kann. mapping der device namen wie bei readingsGroup ist auch möglich. die history wird bei 'save' gespeichert und beim neustart wieder geladen.
edit4: fix für das problem das die liste beim öffnen eines raumes manchmal leer war
edit5: es gibt jetzt ein 'set <device> add ...' um eine zeile von hand hinzuzufügen und ein 'set <device> clear' um die history zu löschen
edit5: %DEVICE geht jetzt im mapping
edit6:
- es ist möglich ein history device zu definieren ohne einen device/reading parameter anzugeben. das device hängt sich dann nicht ins globale notify ein und lässt sich nur mit 'set <device> add' füllen.
- mit timestampFormat kann man das format des timestamp angeben. siehe perl POSIX strftime
- mit valueFormat kann man den string der für ein reading/event ausgegeben wird frei konfigurieren. bei undef wird diese zeile übersprungen.
edit7: notify order fix
Echt super was du da gezaubert hast von sowas hab ich geträumt! :)
Bin gerade am rumspielen und mir ist aufgefallen das die Liste einen Neustart nicht überlebt. Kann man das noch speichern?
2 Ideen hätte ich noch:
mapping Attribut wie bei readingsGroups zum Umbennen
link Attribut um direkt zum device zu kommen.
Was meinst du dazu?
Grüße
das habe ich mir alles schon überlegt. das meiste ist auch recht einfach.
kommt aber nur wenn es auch wirklich jemand benutzt :)
gruss
andre
Ich benutze es auf alle Fälle :)
Mal sehn was der-lolo sagt, aber ich bin begeistert
Mit der regexp komm ich noch nicht klar. Ich schaff es nicht nur das on in der history auszugeben.
22:41:28 sys_s0EingangAllgemein pin: on
Das müsste dann ja
sys_s0EingangAllgemein:pin:.on
sein oder? Es kommen aber immer on und off Ereignisse in die history.
Im event monitor sieht das so aus: 2014-05-03 22:45:43.525 dummy sys_s0EingangAllgemein pin: on
Hast du eine Idee was ich falsch mache?
Grüße
Edit:
Hin und wieder verschwindet auch die Liste beim aktualisieren oder beim history device öffnen (detail Ansicht). Kommt aber, denk ich, nur vor solange die Liste noch nicht vollständig ist.
die regexp gehen nur für device und reading namen. nicht für reading werte.
der code ist noch aus der readingsGroup. für die history könnte man das ändern. aber nur wenn du mir sehr gut erklärst warum du on haben willst und off nicht...
gruss
andre
ps: ich hab das fhem modul eben noch mal ausgestauscht. die device namen sind jetzt links die man anklicken kann.
pps: das mapping der device namen geht jetzt auch.
Du hast wirklich flinke Finger - ich werd mir das morgen anschauen, bin schon gespannt.
die liste wird jetzt beim 'save' auch gespeichert und beim starten wieder geladen.
gute nacht :)
wenn ich mir das ganze so anschaue könnte man dem ganzen vielleicht ein get verpassen um an die history zu kommen.
Hallo Andre,
ich habe das readingsHistory Modul gerade mal eingebaut - erstmal nur mit meinem Handy in der DEF
Wenn ich nun Bluetooth abschalte bekomme ich
Zitat09:49:05 z1compact absent
undefined
undefined
undefined
undefined
undefined
undefined
bei ersten versuch war es noch
Zitat09:49:05 z1compact absent
undefined
undefined
scheint so als ob die undefined Einträge hochzählen - was ist denn überhaupt mit undefined gemeint?
Ausserdem fällt mir auf das - wenn ich den Raum verlasse und wieder öffne die Liste leer ist...
Das erklärtest du ja bereits, wenn ich alles richtig verstanden habe.
So erfüllt readingsHistory allerdings nicht ganz das was ich mir vorstellte. Ich hätte ja gerne eine Anzeige von ausgewählten durchgeführten Events im "lesbarem" Text gehabt.
z1compact absent ist ja zwar schon eine aussage, wenn es aber wirklich nutzbar sein soll im sinne wie ich es mir vorstelle müsste man auf die Ausgabe Einfluss nehmen können.
z1compact absent = Michael ist gegangen
wäre eben auch für die Dame des Hauses lesbar - und somit ein Hinweis darauf was innerhalb der Automatisierung geschaltet wurde.
erklärst Du mir bitte ausserdem nochmal die definitions Möglichkeiten?
define Events readingsHistory z1compact:state have ich nun.
wäre dann [<device>:<readings> [...]] die Möglichkeit weitere Geräte hinzuzufügen? und am Ende dann soviele ]]]] wie zusätzliche Definitionen?
Hallo!
Zitat von: justme1968 am 03 Mai 2014, 22:53:45
die regexp gehen nur für device und reading namen. nicht für reading werte.
der code ist noch aus der readingsGroup. für die history könnte man das ändern. aber nur wenn du mir sehr gut erklärst warum du on haben willst und off nicht...
Ich wollte nur mal durchprobieren was alles geht, derzeit fällt mir dazu auch kein Anwendungsbereich ein.
Einen Fehler hab ich noch:
- Die History wird beim Seiten-aktualisieren gelöscht, wenn die Liste noch nicht vollständig ist.
Und noch 2 Ideen ::)
- Ein Attribut um auch den Tag + Jahr einzublenden zB 04. Mai 2014 - 10:03:56
- Ein Attribut um nach x Sekunden automatisch zu speichern (Keine Ahnung wie performance intensiv das speichern ist) Idee dahinter: Wenn FHEM unter Tags irgendwann mal abstürzen sollte (Stromausfall), dann sind alle Logs seit dem letzten Save weg.
Grüße
Zitat von: der-Lolo am 04 Mai 2014, 10:03:08
wäre dann [<device>:<readings> [...]] die Möglichkeit weitere Geräte hinzuzufügen? und am Ende dann soviele ]]]] wie zusätzliche Definitionen?
Ja.
Ich hab zB zum Testen
wzDeckenfluter:state wzTV:state wzSonosS5:state Wohnzimmer:statewz.*:state geht zB auch.
Grüße
die undefined zeilen sind 'leere' history einträge. ich have vergessen die leer zu machen. die sollten sich aber nach und nach füllen.
wenn du einen raum verlässt und wieder öffnest sollte die liste nicht leer sein sondern die liste sollte im hintergrund weiter gefüllt werden und du siehst immer den aktuellen stand. das schaue ich mir an.
dazu musst du die devices und events mappen. das geht wie bei readingsGroup aber zur zeit nur für device namen. das einfachste ist deinem device einen alias zu geben. also z.b. 'Michael'. ansonsten schau dir mal mapping in der commendref von readingsGroup an. das mappen des kompletten events kommt noch.
du kannst einfach mehrere device:readings parameter aneinander hängen. beides können regex sein. device kann z.b. auch etwas wie 'TYPE=presence' sein. die eckigen klammern bedeuten optionale parameter. die werden in der definition nicht mit geschrieben.
das formatieren der zeit per attribut kommt noch.
automatisch speichern kannst du über ein einfaches at das save aufruft. dann hast du nicht nur die history sondern alles richtig gespeichert. jede stunde zum beispiel.
gruss
andre
Zitat von: fhainz am 04 Mai 2014, 10:09:46
Einen Fehler hab ich noch:
- Die History wird beim Seiten-aktualisieren gelöscht, wenn die Liste noch nicht vollständig ist.
Ist wahrscheinlich das gleiche wie ich meine mit "raumwechsel"
bzgl. undefined - OK, klar - ich habe rows auf 8 gesetzt mein Fehler also..
EDIT: tatsächlich wenn die Liste einmal vollständig gefüllt war - also kein undefined mehr auftaucht wird sie auch gespeichert. Und ist nach einem raumwechsel noch mit all ihren eintragen vorhanden.
ich hab das problem gefunden und die beiden files oben im post aktualisiert.
die liste sollte nicht mehr leer sein auch wenn sie nicht vollständig gefüllt war. beim neustart wird ein mal die reihenfolge der alten events falsch sein. das ist erledigt wenn die alten zeilen raus gescrollt sind.
gruss
andre
Funktioniert jetzt danke!
Ein seltsames verhalten hab ich da noch. Ich schalte eine IT-Steckdose mit einem notify das von einer FS20 TC8 getriggert wird. Die on/off Events kommen immer 2x aber nur an der ersten position der Liste.
Ich hab ein video gemacht, kann es schlecht beschreiben.
Grüße
Zitat von: justme1968 am 03 Mai 2014, 22:53:45der code ist noch aus der readingsGroup. für die history könnte man das ändern. aber nur wenn du mir sehr gut erklärst warum du on haben willst und off nicht...
Zitat von: fhainz am 04 Mai 2014, 10:09:46
Ich wollte nur mal durchprobieren was alles geht, derzeit fällt mir dazu auch kein Anwendungsbereich ein.
Ich logge via hourcounter die Anzahl der Kaffee's pro Tag. Der trigger für hourcounter ist ein reading doKaffee das entweder 1 oder 0 ist. Wenn der Brühvorgang (> 1000 W) startet wird doKaffee auf 1 gesetzt und wenn die SD wieder 0W hat dann wird entsprechend eine 0 gesetzt. Ich weiß, notwenig oder wichtig ist das ganze überhaupt nicht, aber ich will meinen Kaffee Konsum ein wenig einschränken und so hab ich den überblick ;)
Wenn ich das nun in der History abbilden will (zB Kaffee Brühvorgang gestartet) dann brauch ich die 0 nicht. Kaffee Brühvorgang beendet muss/soll ja nicht unbedingt in die History.
Keine Ahnung wieviel Arbeit das sein würde das Modul auf value zu erweitern bzw. wieviel Arbeit du da überhaupt reinstecken willst. Meine Ideen sollen auf keinen Fall unverschämt klingen, bin mit dem derzeitigen Stand schon sehr glücklich und froh das du dir überhaupt die Mühe machst! :)
Grüße
lol
doKaffee! sehr geil...
Ich bin auch schon sehr begeistert, genau so etwas hatte ich mir vorgestellt...
Wie ich schon sagte - wenn nun noch ein Frauen lesbarer Text aus den Events wird ist die Begeisterung riesig.
es gab noch einen kleinen fehler beim zählen der zeilen. die reparierte version hab ich wieder oben angehängt.
ich kann das mit den doppelten zeilen aber nicht reproduzieren. sehr seltsam. welcher browser ist das? was genau siehst du im event monitor? passiert es auch bei einem ganz neu angelegten device?
die neue version oben hat jetzt ein 'set <device> add ...' um eine zeile von hand hinzuzufügen und ein 'set <device> clear' um die history zu löschen. du musst beide files austauschen.
das mit dem kaffe würde ich anders lösen :) entweder würde ich ein (user) reading letzterKaffe verwenden das immer den richtigen timestamp hat (so wie motion beim bewegungsmelder) oder ich würde wenn tigger ein 'virtuelles' reading erzeugen und das in die history stecken.
aber ich schaue mal ob ich das valueFormat aus der readingsGroup übernehme. dann kann man zum einen den value frei formatieren und auch undef zurück geben wenn ein wert ignoriert werden soll.
gruss
andre
Zitat von: justme1968 am 04 Mai 2014, 13:06:41
ich kann das mit den doppelten zeilen aber nicht reproduzieren. sehr seltsam. welcher browser ist das? was genau siehst du im event monitor? passiert es auch bei einem ganz neu angelegten device?
mit der neuen version funktioniert's! ;DZitat von: justme1968 am 04 Mai 2014, 13:06:41
aber ich schaue mal ob ich das valueFormat aus der readingsGroup übernehme. dann kann man zum einen den value frei formatieren und auch undef zurück geben wenn ein wert ignoriert werden soll.
Das wär super! :)
Grüße
set Events add its genau das was ich haben wollte...
Du bist ein Held Andre! 1000 Dank!
Zitat von: justme1968 am 04 Mai 2014, 13:06:41ich kann das mit den doppelten zeilen aber nicht reproduzieren. sehr seltsam. welcher browser ist das? was genau siehst du im event monitor? passiert es auch bei einem ganz neu angelegten device?
Es funktioniert nur wenn die detail Übersicht offen ist. Wenn ich die Raumansicht offen hab klappts nicht.
Browser: Safari, FireFox OS X
Zitat von: EventMonitor2014-05-04 13:27:38.968 readingsHistory testHistory history: 13:27:38 <a href="/fhem?detail=wzSonosS5">Sonos S5</a> on
2014-05-04 13:27:38.969 IT wzSonosS5 on
2014-05-04 13:27:38.969 FS20 wzT2T3 toggle
Hab das device neu angelegt, das selbe.
Mit dem mapping scheint auch noch etwas nicht zu passen. Ich bekomme in jeder history den Alias angezeigt obwohl kein mapping gesetzt ist. Hatte vorher mal ein mapping %ALIAS aber das hab ich wieder gelöscht.
Grüße
Hmm. es sollte unabhängig von raum oder detail sein. ich habe auch safari. schaue nachher noch mal.
der alias ist der default. wie bei readingsGroup auch. wenn du das device môchtest musst du %DEVICE setzen.
gruss
andre
Wenn ich nur %DEVICE eingebe kommt der Name der readingsHistory.
mapping { <deviceName> => '<einName>' }
sollte ja auch klappen oder?
@fhainz: geb mir mal ein mapping Beispiel - das verstehe ich noch nicht so ganz...
zB attr <name> mapping { d_vzLichtStatus => 'Vorzimmer Licht' }
Das sollte den Namen des device d_vzLichtStatus in Vorzimmer Licht umbennen, wie bei readingsGroups. Leider tut sich bei mir nix.
das mapping für device namen sollte jetzt funktionieren. also die einfache variante mit %DEVICE und auch die mit dem hash. das einfachste ist aber immer noch für die devices einen alias zu setzen.
das mit der doppelten zeile kann ich weder in der detail noch in der raum ansicht reproduzieren.
bitte steck mal die history in einen eigenen raum. hast du das problem da auch?
was sagt der seiten quelltext? taucht die zeile da auch zwei mal auf?
gruss
andre
Bei mir hagelt es nur so doppelte Einträge - ich sehe das aber jetzt eher als Hinweis darauf das meine notifys mehrfach triggern.
Ich hab da noch ein Thema mit HM, LightScene, HUE und WifiLight - ich glaube da mache ich aber besser einen eigenen thread zu auf.
mapping funktioniert, danke!
An den eigenen Raum hatte ich auch schon gedacht. Keine Änderung.
Mir fällt aber gerade auf, dass wenn ich die Seite aktualisiere die 2. Zeile wieder weg ist.
Im Seiten Quelltext sehe ich die Zeile gar nicht. Ich vermute das liegt daran das der html code per JavaScript reingeschrieben wird.
Zitat von: der-Lolo am 04 Mai 2014, 14:58:25
Bei mir hagelt es nur so doppelte Einträge
auch in der detailansicht oder nur in der raumansicht? Verschwinden die doppelten Einträge beim Aktualisieren?
sowohl in der Raum als auch in der Detail Ansicht - es verschwindet auch nichts beim aktualisieren...
Wie gesagt vermute ich aber das meine notifys mehrfach kommen. Habe das schonmal beobachtet über den EventMonitor, scheint so als ob immer wenn ein reading geändert wird auch das notify triggert. Dabei spielt es keine rolle ob ich auf ein spezielles reading trigger oder auf das internal STATE. Hier ist echt ein wurm drin bei mir.
ok dann ist das sicher was anderes als bei mir.
so ein verhalten hatte ich teilweise auch bis ich meine notifys mit regexp eingeschränkt hab. seit dem klappt es ganz gut.
wenn die doppelten zeilen nach einem seiten refresh noch da sind waren es wirklich doppelte notifys.
wenn sie nach einem refresh weg sind liegt es am aktualisieren per javascript. wenn es im quelltest nicht da ist macht der browser etwas komisches. ich verstehe noch nicht genau was. bei mir geht es wie gesagt immer.
ich schaue es mir noch an.
ansonsten: ja natürlich wird bei jeder änderung eines readings ein notify getriggert. aber auch nur jeweils ein mal. wenn du trotzdem mehrfache aufrufe bekommst ist deine regex im notify nicht genau genug.
gruss
andre
ich lande also wieder bei diesem REGEX Teufelszeug... Den kram hab ich noch nie so recht verstanden.
Ich glaub ich habs: Das Problem tritt nur auf wenn das history device in einer Gruppe ist!
das ist wirklich nicht weiter schwierig wenn du es dir einfach mal in ruhe anschaust. vielleicht hilft dir das hier: http://www.troubleshooters.com/codecorn/littperl/perlreg.htm (http://www.troubleshooters.com/codecorn/littperl/perlreg.htm) oder das: http://www.cs.tut.fi/~jkorpela/perl/regexp.html (http://www.cs.tut.fi/~jkorpela/perl/regexp.html).
gruss
andre
ich hab das zeug auch bisher nie verstanden. ist aber ganz einfach.
Schau dir im Event Monitor die Ausgabe an. Zb.
dummy sys_s0EingangAllgemein power: 311.93
. findet jedes beliebiges Zeichen
: übernimmst du einfach.
* alles folgende
alle events des device
sys_s0EingangAllgemein.*
nur power:
sys_s0EingangAllgemein.power:.*
Diese Seite hat mir sehr weitergeholfen:
http://www.troubleshooters.com/codecorn/littperl/perlreg.htm
Grüße
Edit:
Oder geh in ein FileLog device detail. Wenn du eventTypes (http://www.fhem.de/commandref.html#eventTypes) definiert hast, siehst du da alle device inkl. passender regexp!
Der "." findet jedes beliebige Zeichen und nicht nur eine Leerstelle.
Danke, hab ich ausgebessert und um * ergänzt.
Stimmt so oder?
Boah - da hatte ich aber lange zeit ein echtes brett vor dem Kopf, danke euch beiden...
Ich bin einfach immer mit dem Device Namen ins notify gesprungen und habe dann im notify mit IF auf mein gewünschtes Reading geprüft... Ich wusste es halt nicht besser.
Ich glaube ich habe jetzt zwar wahnsinnig viel Arbeit alles anzupassen, danach läuft aber sicher vieles stabiler.
ich hab das problem mit der gruppe gefunden. und auch eine idee wie es zu fixen ist.
das ganze ist aber ein viel tieferliegendes problem in fhemweb und ich weiss nicht ob rudi mit dem fix einverstanden ist.
gruss
andre
Ok, schauen wir mal was Rudi dazu sagt. Ich hoffe ja, ich wollte mir eine History in einer Gruppe im Dashboard anzeigen.
Ich hab deinen Patch mal ausprobiert. Brauch ich noch eine andere 33_readingsHistory.pm? Nur mit diesem patch klappt es besser, aber noch nicht perfekt :)
Soll heißen: Ich mache einen raum auf, schalte den aktor und nix passiert. Ab dem 2. mal schalten kommen dann alle Befehle an, nach dem Aktualisieren ist auch der 1. Befehl wieder da.
Grüße
Hallo zusammen,
vielen Dank für das schöne Modul (und insgesamt für fhem)!!! Habe schon Stunden nach was Ähnlichem gesucht und nichts gefunden.
Würde gerne beim Befehl set <device> add eine Variable nutzen. Dazu habe ich folgendes probiert:
define UserLog readingsHistory HomeStatus ....
...
define Test dummy
define Test_n notify Test set UserLog add $EVENT
Es gibt einen neuen Eintrag nur mit Uhrzeit, aber keinem weiteren Inhalt.
Frage1: Muss ich die Variable irgendwie anders einfügen?
Ich verwende die Ausgabe innerhalb eines Floorplan, die Einträge werden hier nicht linksbündig sondern zentriert angezeigt.
Frage2: wo kann ich linksbündig, Schriftgröße, Farbe, etc. einstellen?
weitere Idee: kann man eine Farbe beim set mitgeben (z.B. wichtigere Events in rot)
Danke Michi
warum der umweg über das notify? einfach Test:state mit um define von deinem UserLog angeben. alles andere geht automatisch.
oder per trigger ein event auslösen das 'passt'.
formatierung geht noch nicht. das kommt noch.
gruss
andre
Danke für die schnelle Antwort! Ich möchte den Text in meinem "Eventlog" wegen dem "WAF" selbst bestimmen und z.B. folgendes erzeugen:
23:11 Bewegung Kelleraufgang -in rot nur wenn Homestatus=2(schlafen), da zu dieser Zeit hier keiner sein sollte
18:59 Türklingel - nur wenn Homestatus >1, keiner daheim, super wäre hier gleich ein html-link auf das Bild von der Außenkamera welches beim Klingeln aufgezeichnet wurde-
18:57 Anruf 0891234567 -bzw. falls Name bekannt- 18:57 Anruf Michi
18:53 Bewegungsmelder Garage Batterie wechseln -Meldung soll nur einmal am Tag kommen-
Bestimmte Events (z.B. Bewegungsmelder) werden nur im Log aufgenommen wenn es Nacht war oder niemand zu Hause war (abhängig von Homestatus), wenn man dann das Haus verlässt oder schlafen geht wird das Log gelöscht damit man immer nur die Events von der letzten "Abwesenheit" bekommt. Andere Meldungen sollen in einer bestimmten Zeit nur einmal kommen (z.B. Batterie) Deshalb verwende ich das notify um entsprechende Bedingungen abzufragen.
Grüße Michi
@fhainz: rudi hat meinen patch vorschlag gestern schon eingecheckt.
da sich im prinzip das komplette verhalten im hintergrund geändert hat kann es sein das ich am modul jetzt noch was nachziehen muss. was bedeutet nicht perfekt ?
@michaelfhem: (fast) genau so soll es dann aus dem modul möglich sein. schau dir mal die formatierungsmöglichkeiten bei readingsGroup an.
gruss
andre
Nach dem update funktionierts perfekt danke! Keine Ahnung was da gestern noch war, vielleicht ein Kopierfehler.
Grüße
@rene: vielen Dank.
Das ist genau das was ich wollte. Zwei Fragen habe ich noch:
1) wird das Modul ab jetzt immer bei Update mit verteilt
2) bisher bekomme ich nur die Uhrzeit + Event angezeigt, kann auch das Datum hinzugefügt werden?
guido
das modul gibt es noch nicht per update. der aktuelle stand ist in ein paar stunden zusammengeschrieben und es ist noch nicht klar wie viele interessenten es wirklich gibt.
das formatieren von zeit/datum und nachricht steht noch auf der todo liste.
gruss
andre
Klasse Andre!
Kann ich damit auch ein Eventlog so wie im Screenshot angezeigt hinbekommen?
im prinzip ja. jedenfalls wenn ich das mappen des events noch einbaue. dazu bin ich noch nicht gekommen.
die idee ist aber das das format so frei konfigurierbar ist das es geht.
wohin zeigt dein info link? einfach nur aufs device?
gruss
andre
Nein ich habe das über einen Dummy und einer zentralen Funktíon
sendmsg "Hier kommt der Text rein";
gelöst.
Damit habe ich dann auch die Möglichkeit, Push Nachrichten, XBMC oder Email in einer Funktion auszulösen.
ich meine sie grünen info dinger in deinem screenshot :)
kapiert. das ist nur eine art level?
Achso :-) Das ist reiner Text!
INFO
WARNING
CRITICAL
Also eine Art Severity des Events!
ich war schneller :)
der teil wäre bis jetzt noch nicht vorgesehen.
aber ich überlege eh gerade die info intern etwas mehr zu strukturieren. da würde ich das dann mit unterbringen.
Du bist der beste! ;)
ich hab hier: http://forum.fhem.de/index.php/topic,23148.msg165046.html#msg165046 (http://forum.fhem.de/index.php/topic,23148.msg165046.html#msg165046) ein kleines update hoch geladen:
- es ist möglich ein history device zu definieren ohne einen device/reading parameter anzugeben. das device hängt sich dann nicht ins globale notify ein und lässt sich nur mit 'set <device> add' füllen.
- mit timestampFormat kann man das format des timestamp angeben. siehe perl POSIX strftime
- mit valueFormat kann man den string der für ein reading/event ausgegeben wird frei konfigurieren. bei undef wird diese zeile übersprungen.
gruss
andre
Probiere ich am WE aus! Ich schaffe das leider in der Woche nicht mehr!
Hallo Andre,
Danke fürs Update. Hab schon drauf gewartet! Kannst Du ein Beispiel zur Verwendung posten. mir ist nicht klar wie ich valueFormat für die verschiedenen Event Parameter, die ich mit set device add hinzufüge, angebe. Bei mir ändert sich an der Ausgabe erstmal gar nichts. Kann ich jetzt auch mapping verwenden?
Grüße Michi
Hatte auch schon so etwas im Kopf :-)
Meine Idee dazu ist:
Alle SET Befehle im Commandhandler zu loggen...
Konfigurierbarer Ringpuffer mit timestamp und den Daten die abgeschickt wurden ...
Damit sollte sich jeder Anwender dann seine eigenen Daten fischen können
Integration so "einfach" wie fhem.cfg in eine dB zu schicken
Nur meine Gedanken
Ralf
Gesendet von meinem iPad mit Tapatalk HD
das wäre noch mal eine andere ebene.
wobei die set aber aber nur ein teil sind und du damit alle reinen sensoren und auch die antwort eines aktor auf das set nicht mit bekommen würdest.
umgekehrt bekommst du hier über state und die anderen readings fast alles mit wenn du das möchtest.
gruss
andre
Zitat von: justme1968 am 08 Mai 2014, 17:16:51
das wäre noch mal eine andere ebene.
wobei die set aber aber nur ein teil sind und du damit alle reinen sensoren und auch die antwort eines aktor auf das set nicht mit bekommen würdest.
umgekehrt bekommst du hier über state und die anderen readings fast alles mit wenn du das möchtest.
gruss
andre
Hallo Andre,
na klar bekomme ich nur die gesendeten Befehle, ABER auch die Befehle, die im Hintergrund abgesetzt werden. Brauche ich ein Reading muss ich dieses sowieso mir aus aus den Details raussuchen und entsprechend verarbeiten...
mit bräunlichen Füßen
Ralf
Ich habe das ja mit einer zentralen Funktion (genauso wie die fhem log Funktion) gelöst. Die kann man so nutzen wie man sie benötigt! ( Devise unabhängig) weiterhin können beliebige Emitter ( pushover, Email, xbmc Nachrichten) mit eingebaut werden! Das einzige Problem ist die synchrone Verarbeitung von fhem, die unter Umstaenden fuer eine Verarbeitungsverzoegerung in fhem sorgen kann!
@michaelfhem: schau dir mal die doku zur readngsGroup und die beispiele im wiki an. valueFormat funktioniert genau so.
wenn ich am wochenende dazu komme mache ich noch ein beispiel.
gruss
andre
Ist wirklich Klasse geworden! Danke!
Ich hab noch ein Problem mit dem mapping. Folgendes funktioniert nicht, bei valueFormat funktioniert das aber schon.
mapping { allgEventHistoryMapping($DEVICE,$READING,$VALUE); }
99_myUtils:
sub allgEventHistoryMapping($$$){
my $device = shift;
my $reading = shift;
my $value = shift;
if( $device eq "d_vzLichtStatus" ){
return 'Vorzimmer Licht'
}
}
Hast du eine Idee?
Grüße
zur zeit wird die {<perl>} version von mapping nur ein mal am anfang ausgewertet und nicht pro device. das ist kompatibel zur readingsGroup. gefällt mir aber nicht. ich muss noch ein paar dinge testen bevor ich das umstellen kann ohne das die es probleme mit der kompatibilität gibt.
am besten verwendest du erst mal die version mit dem hash:mapping { "d_vzLichtStatus" => "Vorzimmer Licht",... }oder du gibst jedem device eine alias.
gruss
andre
Ok, alles klar danke. Dann gedulde ich mich noch.
Alias verwende ich wo es möglich ist, aber hin und wieder will ich einen anderen namen als den alias, der in raumübersicht ja richtig ist aber in der history eventuell nicht passt.
Die variante mit dem hash hatte ich bisher, aber ich wollte es auslagern in die 99_myUtils.
Grüße
du kannst den hash auslagern wenn du ihn aus der 99_myUtils routine zurück gibst:
attr <device> mapping {myHash()}
my %history_mapping_hash = ( "d_vzLichtStatus" => "Vorzimmer Licht",... );
sub
myHash()
{
return \%history_mapping_hash;
}
Ok, das versuch ich gleichmal!
Danke!
Kann es sein das zB
if( $value =~ m/.*addLog/){
undef;
}
als letztes in der sub stehen muss? Wenn ich nach dieser if noch eine if stehen hab klappt das nicht.
Grüße
wenn es keine syntax fehler gibt ich die reihenfolge nicht wichtig. jedenfalls wenn es kein logisches problem gibt.
was steht denn im log?
Im Log steht nix.
Das klappt nicht
sub allgEventHistoryValueFormat($$$){
my $device = shift;
my $reading = shift;
my $value = shift;
.
.
.
if( $value =~ m/.*addLog/){
undef;
}
if( $device eq "geofancy" && $value eq "home" ){
"ist zu Hause angekommen";
}
elsif( $device eq "geofancy" && $value eq "work" ){
"ist in der Arbeit angekommen";
}
elsif( $device eq "geofancy" && $value eq "underway" ){
"ist unterwegs";
}
}
Wenn ich die 2 if blöcke wieder umdrehe hab ich die addLog events wieder in der history.
Ich hab noch ein komisches Problem:
Definiert sind 2 history devices
Internals:
CFGFN
DEF wzDeckenfluter:state
HAS_DataDumper 1
NAME allgEventHistory
NR 320
NTFY_ORDER 50-allgEventHistory
STATE Initialized
TYPE readingsHistory
mayBeVisible 1
Content:
wzDeckenfluter 1
DEVICES:
ARRAY(0x7fcd131006c8)
Readings:
Fhem:
last_update 1399819410.55462
lines:
16:44:14 <a href="/fhem?detail=wzDeckenfluter">Deckenfluter</a> toggle
16:44:11 <a href="/fhem?detail=wzDeckenfluter">Deckenfluter</a> toggle
16:44:10 <a href="/fhem?detail=wzDeckenfluter">Deckenfluter</a> toggle
16:44:09 <a href="/fhem?detail=wzDeckenfluter">Deckenfluter</a> toggle
16:44:08 <a href="/fhem?detail=wzDeckenfluter">Deckenfluter</a> toggle
Attributes:
room 9.8 Event Log
Internals:
CFGFN
DEF wzDeckenfluter:state
HAS_DataDumper 1
NAME testHistory
NR 322
NTFY_ORDER 50-testHistory
STATE Initialized
TYPE readingsHistory
mayBeVisible 1
Content:
wzDeckenfluter 1
DEVICES:
ARRAY(0x7fcd11c336e8)
Fhem:
last_update 1399819586.31474
lines:
16:44:14 <a href="/fhem?detail=wzDeckenfluter">Deckenfluter</a> off
16:44:14 <a href="/fhem?detail=wzDeckenfluter">Deckenfluter</a> toggle
16:44:11 <a href="/fhem?detail=wzDeckenfluter">Deckenfluter</a> on
16:44:11 <a href="/fhem?detail=wzDeckenfluter">Deckenfluter</a> toggle
16:44:10 <a href="/fhem?detail=wzDeckenfluter">Deckenfluter</a> off
Attributes:
room 9.8 Event Log
Eigenartigerweise haben beide Unterschiedliche ausgaben. :o
Den toggle output wollte ich in der history ausblenden und nur bei on/off reagieren, dann hab ich in der andern history, die zu dem Zeitpunkt noch ein einem anderen raum war, den output gesehen.
Ich hab dann alle attr's (mapping,valueFormat,timestampFormat) aus der allgEventHistory entfernt aber keine Änderung. Anschließend FHEM neugestartet, Server neugestartet, allgEventHistory gelöscht und wieder neudefiniert, kein Unterschied.
Hintergrund ist folgender: Ich schalte mit einer FS20 TC8 Fernbedienung eine FS20-ST. Nachdem in FHEM nur toggle ankommt und die und die FHEM-untoggle Funktionen für mich nicht funktionieren hab ich mir selbst eine gschrieben die z.Z. funktioniert.
wzDeckenfluter.toggle {
if( OldValue("wzDeckenfluter") eq "on" ){
fhem("set wzDeckenfluter off");
}
else{
fhem("set wzDeckenfluter on");
}
}
Hast du eine Idee?
wenn du in einem notify noch mal ein set aufrufst hängt es von der reihenfolge in der die notifys aufgerufen werden ab wer welche events sieht.
bau mal bitte im history modul in die readingsHistory_Initialize sub ein
$hash->{NotifyOrderPrefix} = "51-";ein und schau ob es dann passt.
das andere problem muss ich noch in ruhe nachstellen.
gruss
andre
Danke, das wars! Nun funktionierts in jeder history :)
Klar, keinen Stress! Bei dem Problem bin ich auch gerade dran. Nachdem ich alle if bis auf das erste mit elsif ersetzt hab, scheint es zu funktionieren. Obwohl das ja eigentlich keinen unterschied machen sollte, oder?
Grüße
du musst 'return undef;' verwenden. sonst geht es einfach mit dem nächsten if weiter :)
Super, nun funktioniert das auch :D
Danke!!
Grüße
hab das modul eben eingecheckt: http://forum.fhem.de/index.php/topic,23739.0.html (http://forum.fhem.de/index.php/topic,23739.0.html)
gruss
andre
Hallo!
Ich bekomme auf der Konsole diese Fehlermeldungen.
ZitatServer:fhem Fabian$ Prototype mismatch: sub main::readingsHistory_Notify ($$$) vs ($$) at ./FHEM/33_readingsHistory.pm line 482.
Subroutine readingsHistory_Notify redefined at ./FHEM/33_readingsHistory.pm line 329.
Kannst du etwas damit anfangen?
Grüße
das ist inzwischen schon behoben. kommt morgen im update.
gruss
andre
Alles klar. Danke
Grüße
Wenn ich das DEF in einem readingsHistory ändere, sollten eigentlich alle Einträge, die nicht mehr zu dem DEF passen, aus der Liste verschwinden.
Gibts die Ausgabe von "get history" auch in einem vernünftigen Format?
(http://up.picr.de/18347674ee.jpg)
1400612419.2916 Melder_TEingang closed 21:00:19 <a href="/fhem?detail=Melder_TEingang">Melder_TEingang</a>
1400612415.34162 Melder_TEingang open 21:00:15 <a href="/fhem?detail=Melder_TEingang">Melder_TEingang</a>
ZitatWenn ich das DEF in einem readingsHistory ändere, sollten eigentlich alle Einträge, die nicht mehr zu dem DEF passen, aus der Liste verschwinden.
das sehe ich nicht unbedingt so. es gibt mindestens so viele fälle bei denen die komplette history trotzdem erhalten bleiben soll.
wie wäre ein 'set <device> purge' kommando um alles zu löschen das zu devices gehört die nicht mehr teil der history sind ?
Bring bitte erstmal das Modul in eine überhaupt (abseits vom Frontend) sinnvoll nutzbare Form, bevor Du über solche Kleinigkeiten nachdenkst.
Wollen wir die Diskussion (die ich ganz bewußt hierher verlegt hatte, was Du ignoriert hast) eigentlich hier oder im Ankündigungsthread weiterführen?
Zitat von: justme1968 am 20 Mai 2014, 21:35:09
da ich nicht genau weiss was du wirklich machen möchtest
was ich machen möchte, ist ganz einfach erklärt. Ich will am Ende diese Liste in meinem RSS haben:
(http://up.picr.de/18348426go.png)
Das geht im RSS Layout prinzipiell mit EINEM EINZIGEN Befehl, wenn die Daten in einem vernünftigen Format vorliegen.
ZitatWollen wir die Diskussion (die ich ganz bewußt hierher verlegt hatte, was Du ignoriert hast) eigentlich hier oder im Ankündigungsthread weiterführen?
ich hatte nicht ignoriert sondern zufällig als erstes den anderen thread gesehen. wir sollen hier weiter diskutieren.
deshalb die antwort auf deinen post im anderen thread auch hier:
ZitatIch 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"
sorry. ich verstehe immer noch nicht warum es stunden dauert events da rein zu bekommen...
der thread heisst
Anzeige der letzten Schaltevents in FHEMWEB da geht es eindeutig um die anzeige. und es gibt scheinbar mehr als einen anweder der so damit glücklich ist.
das du eine andere intention hast ist jetzt klar. das heisst aber nicht das es nicht für andere passt. das etwas anderes dabei raus kommt als das was du dir vorgestellt hat mag sein. auch das trifft nicht auf alle zu. ich hab übrigens noch mal geschaut und für mich geht aus dem ursprünglichen posts z.b. nicht hervor was du damit tun möchtest.
bei readingsGroup geht es um die darstellung und nur um die darstellung sogar explizit um die darstellung ohne daten zu halten. das ist der grund aus dem das modul entstanden ist. es ist die einzige möglichkeit interaktiv meherer readings unterschiedlicher devices im frontend darzustellen ohne den overhead von dummys, hin und her kopiererei und unnötigen events.
wenn du bei deinem rss gewurschtel keinen anwendungsfall für die readingsGroup hat ist das ok. das gilt für mich umgekehrt genau so. ein paar hundert anwender benutzen das modul. das ist für mich alles andere als sinnlos.
im history modul ging es für mich um die darstellung und das frontend. um daten zu speichern habe ich eine db. dazu brauche ich kein history modul.
das mit dem state file hast du missverstanden. ich verwende nicht das statefile um daten zu speichern sondern um rauszufinden in welches verzeichnis ich meine daten persistent speichern kann. daran ist nichts schlecht es funktioniert zuverlässig und ohne probleme so lange nicht confgDB dazwischen funkt. oder positiv ausgedrückt mit config db nicht mehr nötig. leider aber nicht ohne
wenn du der meinung bis das darstellung und user interface der einfachste schritt sind und der letze sein sollte sind ein paar dinge die die software entwicklung in den letzten jahrzehnten betreffen an dir vorbei gegangen und es ist kein wunder das du mit dem abrunde tief hässlichen rss kram zufrieden bist.
m-v-c ist für ein reines frontend modul absolut unpassend. kein wunder das es hier missverständnisse gibt. readingsGroup ist nur 'c' und das war readingsHistory (auch laut thread titel) bisher auch.
und was den model und view teil angeht... so ganz ernst genommen ist es in der config db ja nun auch nicht. files 1:1 in eine db zu stecken ist nicht modelliert. es ist zwar schön kompatibel aber den vorteil ein paar generationen aufzuheben hätte auch ein einfaches cvs/svn oder was auch immer repository gehabt.
ZitatBring bitte erstmal das Modul in eine überhaupt (abseits vom Frontend) sinnvoll nutzbare Form, bevor Du über solche Kleinigkeiten nachdenkst.
das modul ist in einem sinnvoll nutzbaren zustand. vielleicht für dich (noch?) nicht. und nicht ich habe darüber nachgedacht sondern das war eine antwort auf einen kommentar von dir.
aber abseits vom anregenden aneinander vorbei reden... wie wäre es etwas produktives zu tun?
wusste ich doch das es um rss geht :)
Zitatwenn die Daten in einem vernünftigen Format vorliegen
aber lass dir doch nicht die würmer aus der nase ziehen würdest du jetzt sagen. welches format brauchst du? vermutlich ist das schneller eingebaut als die ganzen antworten geschrieben.
Zitat von: justme1968 am 20 Mai 2014, 22:41:27
files 1:1 in eine db zu stecken ist nicht modelliert. es ist zwar schön kompatibel aber den vorteil ein paar generationen aufzuheben hätte auch ein einfaches cvs/svn oder was auch immer repository gehabt.
Man merkt, dass Du Dich noch nie damit beschäftigt hast, was configDB wirklich tut. Das ist an sich ja nicht schlimm, dann solltest Du aber bitte auch nicht solch einen Quark von Dir geben.
das ist nicht mehr quark als das was du zu readingsGroup zu sagen hattest...
Dein Quark ist schlichtweg falsch.
Mein Quark entbehrt (wie von Dir bestätigt) nicht einer tatsächlichen Grundlage, nämlich dem Problem, dass readingsHistory mit configDB nicht sinnvoll/korrekt/wie vorgesehen funktioniert.
beliebige files 1:1 in eine db zu stecken ist kein Beispiel für mvc. nicht nicht mal ein schlechtes. sondern eben quark. erst recht wenn es dabei probleme mit der reihenfolgen der zeilen gibt.
mit deinem quark waren eher die kommentare zur readinsGroup und das es falsch ist bei einem frontend modul mit der darstellung anzufangen. das entbehrt in der tat jeder grundlage.
das readingsHistory zur zeit tatsächlich nicht persistent speichern kann wenn configDB aktiv ist ist kein prinzipielles problem sondern liegt daran das es mit configDB eine nicht rückwärts kompatible änderung gegeben hat die einen workaround lahm legt der ansonsten einwandfrei funktioniert. es gibt auch ohne config db für manche module die notwendigkeit etwas persistent zu speichern. das ist aber mit den generischen read und weite routinen erledigt. ich muss sie nur einbauen.
Btw: readingsHistory funktioniert super mit configDB!
Zitat von: justme1968 am 21 Mai 2014, 00:20:49
beliebige files 1:1 in eine db zu stecken ist kein Beispiel für mvc. nicht nicht mal ein schlechtes. sondern eben quark. erst recht wenn es dabei probleme mit der reihenfolgen der zeilen gibt.
Du redest immer noch Quark - genauer: Du weisst überhaupt nicht, wovon Du redest und stellst hier falsche Behauptungen über Dinge auf, die überhaupt nichts miteinander zu tun haben.
Davon abgesehen: Ich hatte configDB nirgends als Beispiel für mvc angeführt. Kann es auch nie sein, da ich bei der Entwicklung nicht so arbeiten konnte, wie ich es eigentlich gerne getan hätte, sondern in ein sehr enges Korsett gepresst war, um das Ganz für den Anwender so transparent wie möglich umzusetzen.
Zitat von: justme1968 am 20 Mai 2014, 21:18:56
ich verwende $attr{global}{statefile} um rauszufinden wo ich mein eigenes file hin schreiben kann.
Jetzt mal unabhängig davon, ob ein Anwender configDB nutzt oder fhem.cfg: Das Attribut "statefile" ist doch rein optional. Es macht für mich überhaupt keinen Sinn, ein solches Attribut als Basis für eine Ortsbestimmung zur Speicherung von "wichtigen" Daten zu verwenden. Das Attribut kann auch bei Verwendung von fhem.cfg fehlen, und das wäre sogar völlig "legal".
dann sind wie beide scheinbar genau so gut im schlechte beispiele finden.
statefile ist nur in so fern optional das der aktuelle zustand nicht gespeichert werden kann wenn es nicht gesetzt ist.
das gilt ganz genau so auch für meine module. es ist also logisch und konsistent. erst recht da das speichern an das save kommando geknüpft ist.
die aktuelle dokumentation in verbindung mit configDB aber nicht da hier der aktuelle zustand scheinbar auch bei fehlendem statefile attribut gespeichert wird.
und ob die daten "wichtig" sind liegt ganz beim anwender.
Bei mir speichert das Modul gar nichts. Und heute kriege ich auch wieder keine events mehr - ohne dass ich seit gestern irgendwas verändert hätte, ausser dem Update heute morgen.
Für mich ist das absolut unbenutzbar und fliegt deshalb jetzt wieder raus. Aber ich werde die Entwicklung weiter beobachten, um zu sehen, ob doch noch was sinnvolles rauskommt.
schön. dann hat sich sie diskussion ja erledigt.
mit Sicherheit nicht.
Zitat von: justme1968 am 21 Mai 2014, 09:18:06
die aktuelle dokumentation in verbindung mit configDB aber nicht da hier der aktuelle zustand scheinbar auch bei fehlendem statefile attribut gespeichert wird.
Damit hat configDB an sich nichts zu tun, das Speichern der state-Daten erfolgt über die fhem-eigene Funktion WriteStatefile() aus der fhem.pl
@betateilchen
grundsätzlich sehe ich immer wieder von DIR provokante, gespitzte, und BREMSENDE kommentare über mehrere module.
mir scheint als wolltest du nicht VERBESSERN, sondern bremsen und demotivieren.
du bist mit sicherheit NICHT der beste hier. also spiel doch einfach mit indem du sinnvoll programmierst und unterstützt.
hier ist doch eine gemeinschaft, die gegenseitig sich unterstützen sollte, und nicht PROVOZIEREN !
ich bin mit verschiedenen modulen von justme1968 sehr glücklich. sie funktionieren und bringen funktionen die bisher noch NICHT vorhanden waren.
wenn du selbst ein modul entwirfst das auf der idee und der möglichkeit von justme1968 aufbaut, hast du etwas verbessert.
aber ich stelle immer wieder fest, "das ist gar nicht dein ziel".
ich verstehe nur nicht "warum"?
grüsse an alle die hier selbst verbessern und selbst weiterentwickeln und sich gegenseitig unterstützen OHNE sich bremsen zu lassen !! :D
Hallo andre!
Auf meinem 2. System (Raspberry Pi, aktuelles FHEM) funktioniert die Longpoll Aktualisierung nicht bzw wird sie im Browser nicht angezeigt. Erst nach dem Aktualisieren der Seite sind die neuen Events da. In der Safari JavaScript Konsole wird der longpoll ausgeführt und es gibt auch keinen Fehler. Ich habs auch mir FireFox versucht, ändert nichts. Auf meiner Haupt Installation funktioniert alles tip top.
Zitat[Log] Loading /fhem/pgm2/jquery.min.js (fhemweb.js, line 14)
[Log] Longpoll: (fhemweb.js, line 14)
[Log] Longpoll: bwHistory-history<<08 Jun 2014 10:54:21 Kein Wasser mehr in der Tonne. Steuerung wurde deaktiviert.<<08 Jun 2014 10:54:21...(203) (fhemweb.js, line 14)
[Log] Longpoll: bwHistory-history-ts<<2014-06-08 10:54:21<<2014-06-08 10:54:21 (fhemweb.js, line 14)
[Log] Longpoll: bwHistory-history<<08 Jun 2014 10:54:24 Steuerung wurde wieder aktivert.<<08 Jun 2014 10:54:24 Steuerung wurde...(149) (fhemweb.js, line 14)
[Log] Longpoll: bwHistory-history-ts<<2014-06-08 10:54:24<<2014-06-08 10:54:24 (fhemweb.js, line 14)
Internals:
CFGFN
DEF
HAS_DataDumper 1
NAME bwHistory
NOTIFYDEV global
NR 94
NTFY_ORDER 51-bwHistory2
STATE Initialized
TYPE readingsHistory
mayBeVisible 1
Content:
DEVICES:
Fhem:
last_update 1402217176.82106
history:
ARRAY(0x16962d0)
ARRAY(0x164ac38)
ARRAY(0x13ae6e8)
ARRAY(0x1650940)
ARRAY(0x16aa678)
Helper:
Attributes:
room Bewässerung
timestampFormat %d %b %Y %T Die Daten bekommt das device über eine sub Funktion aus der 99_myUtils.
zb
fhem("set bwHistory add Blumen: ".secToTime($duration)." - Gewürze: ".secToTime($durationVentil)." (Avg: $tempAve°C FC: $fcTemp °C)");Hast du eine Idee woran das liegen kann?
Grüße
geht longpoll für andere devices?
geht es mit einem einfachen 'add test' ?
auf den ersten blick hätte ich den bindestrich im string in verdacht. geht es ohne ?
gruss
andre
- geht longpoll für andere devices?
Ja, longpoll funktioniert bei anderen Devices ganz normal.
- geht es mit einem einfachen 'add test' ?
leider nein.
- auf den ersten blick hätte ich den bindestrich im string in verdacht. geht es ohne ?
Nein, auch keine Änderung.
Zusätzlich hab ich auch die andere Variante versucht, auch hier funktioniert der longpoll nicht.
Grüße
ganz blöde frage: liegt das fhemweb_readingsHistory.js unter .../www/pgm2 ? kannst du im js debugger sehen das es auch geladen wird?
gruss
andre
Das wars!
Ich habe nachdem ich meinem post abgesetzt habe ein force update gemacht, nichtmal das hat die Datei geladen. Hab dann in svn nachgesehen, die Datei ist nicht (mehr) unter www/pgm2 eingecheckt.
Nachdem ich die Datei aus meinem andern System eingespielt hab, klappt es wunderbar.
Grüße
hab es (wieder?) eingecheckt.
gruss
andre
Servus!
ich steig mal frech mittendrin ein: :P
In der Commandref gibt es für readingsHistory kein Beispiel (unter "Examples") für die Definition:
Define
define <name> readingsHistory [<device>[:regex] [<device-2>[:regex-2] ... [<device-n>[:regex-n]]]]
Notes:
<device> can be of the form INTERNAL=VALUE where INTERNAL is the name of an internal value and VALUE is a regex.
If regex is a comma separatet list it will be used as an enumeration of allowed readings.
if no device/reading argument is given only lines with 'set add ...' are displayed.
Examples:
Set
Könnte man da bitte eins einstellen - am besten eins mit Regex-Definition?
Herzlichen Dank!
Gruß,
Frank
define rh readingsHistory .*
gruss
andre
Ausgeklügeltes Regex! :P
Eigentlich meinte ich die Online-Doku, trotzdem Danke!
Hallo Andre,
kannst DU mit folgendder Fehlermeldung etwas anfangen?
2014.10.07 21:21:37 1: PERL WARNING: Use of uninitialized value in pattern match (m//) at ./FHEM/33_readingsHistory.pm line 240.
2014.10.07 21:21:37 3: stacktrace:
2014.10.07 21:21:37 3: main::__ANON__ called by ./FHEM/33_readingsHistory.pm (240)
2014.10.07 21:21:37 3: main::readingsHistory_2html called by ./FHEM/33_readingsHistory.pm (319)
2014.10.07 21:21:37 3: main::readingsHistory_detailFn called by ./FHEM/01_FHEMWEB.pm (1369)
2014.10.07 21:21:37 3: main::FW_showRoom called by ./FHEM/01_FHEMWEB.pm (736)
2014.10.07 21:21:37 3: main::FW_answerCall called by ./FHEM/01_FHEMWEB.pm (393)
2014.10.07 21:21:37 3: main::FW_Read called by fhem.pl (2902)
2014.10.07 21:21:37 3: main::CallFn called by fhem.pl (594)
Danke und Grüße Michi
kann es sein das du eine readingsHistory ohne devices im define hast ?
wenn ja ist es ab morgen behoben.
gruss
andre
Hi Andre,
ich nutze das Modul um mir im FHEMWEB verschiedene für mich wichtige Events anzuzeigen (letzter Anrufer, Batteriemeldungen, Tuerklingel etc.):
define UserLog readingsHistory
attr UserLog fp_Groundfloor 1,1,0,
attr UserLog fp_Handyfloor 120,25,1,
attr UserLog mapping alias
attr UserLog noheading 1
attr UserLog room allgemein
attr UserLog rows 8
attr UserLog style style="font-size:20px;;text-align:left;;color:white"
in passenden Notify schreibe ich jetzt Events ins Userlog:
define TuerKlingel_n notify P_Tuerklingel.* { if(Value("HomeStatus") > 1)\
{\
fhem("set UserLog add Tuerklingel");;\
}\
}
Oft sehe ich diese Fehlermeldung im Log wenn ich im FHEMweb eine extrem lange Ladezeit habe (30s)
Use of uninitialized value in pattern match (m//) at ./FHEM/33_readingsHistory.pm line 240.
Ob das damit zusammen hängt kann ich nicht sagen.
beantwortet das Deine Frage?
Grüße Michi
die meldung sollte ab morgen weg sein.
gruss
andre
Danke, Problem scheint weg zu sein.
PS: Danke für das Modul an sich!
Grüße Michi
Kann ich den Pfad für das Savefile von rH irgendwie ändern? Auch auffällig ist, das bei Verlust der Datei keine neue angelegt wird, was bei anderen Fhem Logs üblich ist.
du kannst den pfad nicht ändern. es ist kein log file sondern ein save file um den aktuellen zustand über einen neustart zu retten. es steht da wo das fhem save file auch steht.
das file wird nicht bei jedem event geschrieben sondern nur bei einem save. dann wird es aber auf jeden fall neu angelegt wenn es nicht vorhanden ist.
gruss
andre
Hallo Andre (Justme1986)!
Ich habe ein Problem mit dem Modul im Zusammenhang mit dem Alarm Modul (95_Alarm.pm) von pah.
Ich würde gerne die Statemeldungen des Alarmmoduls in einer ReadingHistory anzeigen, allerdings werden da keine Eintrage angezeigt. Wenn ich das ganze mit einem Dummy ausprobiere funktioniert alles wie es soll...
Das Alarmmodul hat einen etwas komplexeren Status, das Problem bleibt aber auch bestehen wenn ich dort die Anzeige des State auf reinen Text beschränke. (Kennst Du das Modul?)
Ich wüsste jetzt nicht einmal welche Daten ich Dir zukommen lassen kann damit Du da evtl. helfen könntest...
Wenn Du eine Idee hättest was ich ausprobieren könnte wäre ich Dir sehr dankbar!
Gruß,
Andreas.
kannst du die meldungen die du in der readingsHistory anzeigen willst im event monitor sehen?
wenn ja: poste sie einfach mal
wenn nein: das alarm modul erzeugt nicht die passenden events und es kann auch nichts angezeigt werden.
gruss
andre
Hi Andre,
wow, das war jetzt aber gefühle 0.5 Sekunden Reaktionszeit...
Tja, leider wird im Eventmonitor nichts von dem Modul angezeigt.
Wie werden den Events so erzeugt das sie auch im Eventmonitor und damit in der ReadingHistory erscheinen? Vielleicht kann ich ja in dem Alarmmodul mal suchen wo der State gesetzt wird. Allerdings habe ich von Perl und den internas von FHEM noch nicht so viel Ahnung. Aber man zerbricht ja bekanntlich an seinen Aufgaben ,-)
Wenn Du mir da vielleicht auch noch einen Hinweis geben könntest?
Danke schon mal,
Andreas.
irgendwo sollte es einen readingsBulkUpdate oder readingsSingleUpdate aufruf mit state als parameter geben.
bei readingsSingleUpdate muss der vierte parameter eine 1 sein statt einer 0, bei readingsBulkUpdate muss das darauf folgende readingsEndUpdate als zweiten parameter eine 1 und keine 0 haben.
gruss
andre
Hallo Andre,
Zitat von: justme1968 am 26 April 2015, 20:00:08
irgendwo sollte es einen readingsBulkUpdate oder readingsSingleUpdate aufruf mit state als parameter geben.
bei readingsSingleUpdate muss der vierte parameter eine 1 sein statt einer 0, bei readingsBulkUpdate muss das darauf folgende readingsEndUpdate als zweiten parameter eine 1 und keine 0 haben.
gruss
andre
super, habe gerade schon im Modul gesucht und es wird mit readingsSingleUpate gemacht.
Werde mir mal eine Kopie vom Modul anlegen und überall wo der state gesetzt wird eine 1 reinschreiben. Wenn das funktioniert frage ich pah mal ob er das übernimmt.
Hätte das irgendwelche weitreichenden Folgen, außer mehr event-"traffic"?
Danke,
Andreas.
keine weiteren folgen. und die anzahl der events sollte spätestens mit einem event-on-change überschaubar sein.
gruss
andre
Hallo Andre,
so, hab' das mal eben eingebaut, funktioniert!
Werde pah mal fragen ob er das evtl. so einbaut oder konfigurierbar macht.
Vielen Dank!
Andreas.
Danke für das Modul! Bin erst spät drauf gestoßen, aber ist zu 100% das, was ich schon länger gesucht habe! ;)
ich würde gern z.B.: bei einem Schalter nur den state:on in der readingsHistory anzeigen lassen wollen. Also nicht alle state.
Im Moment sieht meine readingsHistory so aus: "DEF AA:state; internscharf:state; unscharf:state" <dies funktioniert auch aber es werden halt alle state angezeigt.
ich habe es so versucht aer dies geht leider nicht: "DEF internscharf:on; unscharf:on"
kann ich mit readingsHistory imme rnur alle state abfangen oder wie müsste der Code für einen einzelnen Schaltbefehl aussehen?
Gruß Thomas
Thema wurde verschoben und hier weitergeführt
http://forum.fhem.de/index.php/topic,44490.0.html