Anzeige der letzten Schaltevents in FHEMWEB

[justme1968]

Wenn 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 ?

[betateilchen]

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?

[betateilchen]

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.

[justme1968]

Wollen 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:

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"

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.

Bring 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

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

[betateilchen]

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.

[justme1968]

das ist nicht mehr quark als das was du zu readingsGroup zu sagen hattest...

[betateilchen]

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.

[justme1968]

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.

[fhainz]

Btw: readingsHistory funktioniert super mit configDB!

[betateilchen]

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.

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

[justme1968]

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.

[betateilchen]

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.

[justme1968]

schön. dann hat sich sie diskussion ja erledigt.

[betateilchen]

mit Sicherheit nicht.

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

[Chris__1]

@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 !!