Anzeige der letzten Schaltevents in FHEMWEB

[bads]

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

[topfi]

Steht das nicht alles im Logfile? Das kann man doch im Webinterface aufrufen.

[betateilchen]

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.

Code Auswählen Erweitern


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".

[bads]

Danke,

in die Richtung hatte ich auch schon vermutet. Jetzt muss ich nur noch irgendwie eine vernünftige Anzeige dazu basteln.

[justme1968]

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

[betateilchen]

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.

[justme1968]

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?

[der-Lolo]

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.

[betateilchen]

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.

[justme1968]

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.

[fhainz]

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.

[justme1968]

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.

[der-Lolo]

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.

{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.

[justme1968]

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

[betateilchen]

Achtung Gefahr! Andre hat mal wieder eine Idee ... (denk an die Schaukel!)