fhem 4 Nerds or users?

Begonnen von martinp876, 02 Oktober 2022, 08:52:11

Vorheriges Thema - Nächstes Thema

martinp876

ich werde in diesem Thread thematisieren, wie ich fhem aus Anwendersicht sehe, warum ich meine dass es verbessert werden sollte und auch ein paar Vorschläge machen. Da in der Natur der Sache liegt, dass ich viel meckern werde vorne weg einmalig ein paar Statements von mir:
- es gibt (sehr) viele gute Dinge in fhem - diese sind nicht mein Thema. Also sorry, wenn ich das nicht immer erwähne.
- es gibt sehr viele bessere und kompetentere Personen und Entwickler bei FHEM als mich. Auch hier werde ich bei meinen Aussagen keine Rücksicht nehmen, es geht mir um den Inhalt.
- ich werden in einzelnen Posts Themen ansprechen - wild gewürfelt - um darzulegen, wo ich potential sehe und mir eigentlich Änderungen wünsche
- einige Anpassungen würden einen Paradigmenshift benötigen. Viel in fhem ist gewachsen, nicht designt. Ich halte es dennoch für wert, hier Anpassungen durchzuführen.

? Warum Änderungen, klappt doch alles. Diese Frage ist gerechtfertigt.
Nun, erst einmal stellt sich die Frage, für wen fhem gedacht ist. In der homeautomation gibt es einige Rollen:
+ User - nutzt das System zu hause. Bsp: meine Frau. Sie will noch nicht einmal wissen, dass FHEM in Einsatz ist. Keine Programmierkenntnisse, kein Bedarf. Aufgaben: Schaltet Lichter ein (wenn es nicht automtisch geht) und liest Wettervorhersagen.
+ Admin(istrator) - betreut das system, wechselt rechtzeitig Batterien, erkennt Probleme (Fehler, tote Devices) und kann diese bedingt beheben. Das macht auch meine Frau
+ designer - setzt das System auf. Entscheidet oder realisiert die Technologie. Erstellt Verknüpfungen. Kümmert sich um Ausfallsicherheit und Konzepte. Das ist der eigentliche FHEM-Kunde.
    Zu unterscheiden sind 2 extreme: Nerd versus User. Der User will einfache Konzepte, devices in das System einzubinden (virtuelle oder physische). Das System muss alle notwendigen und typischen Einstellungen automatisch vornehmen. Devices sollten im Default  hochkommen. Einige, möglichst wenige Einstellungen können vorgenommen werden und sind als solche zu erkennen. Eine Flut von Optionen ist nicht zielführend.
    Der Nerd will viele Optionen - und mehr noch - automatismen (oder diese erstellen können) um sein System zu konfigurieren.

Bei den Anwendern vergleich ich einmal mit Appel, Andriod, windows, linux.
Appel Anwender erklären mir uni sono dass das System macht, was man will - ohne dass man viel einstellen muss. geht einfach.
Android geht in eine ähnlich Richtung, lässt mehr zu, hat mehr Probleme
Windows ist hier  noch deutlich hinter Andriod, holt aber auf mit app handling.
Linux nun ist klar auf dem Nerd level. Ich richte gerade einen neuen Raspberry ein. Das macht evtl einem Nerd Spass - wenn man viele Knöpfchen drücken darf und alles umstellen kann. Am Ende macht es auch nichts anderes, war nur anstrengender.
==>wo positioniert sich FHEM?

Ich verstehe meinen Kollegen, welcher sich gegen FHEM entschieden hat - mit der Begründung: da muss man programmieren, es geht nix automatisch.

Das ist so in etwa meine Basis, auf der ich fhem und dessen Module nun beurteilen und reviewen werden. Alles meine persönliche Meinung! Ich werden es auch nicht wirklich diskutieren, ich mache das lange genug. Ich kann die Aussage verteidigen, mehr nicht. Es gibt immer mehr als eine Lösung - wenn ich also etwas vorschlage gibt es mit Sicherheit alternativen!

Was wünsche ich mir:
FHEM könnte die Zeile hier definieren. Designruls und einfacheres "designer-API" ist mein Ziel.

Beispiele folgen

martinp876

Erstes Beispiel: die Sektion "Internals" im primär Entity-Frontend.

Es ist mir nicht bekannt, wo definiert ist, was in dieser Sektion dargestellt werden soll. Internals als sichtbare Gruppe von Daten belegt einen der wertvollsten Plätze in der Darstellung. Hier sollten aus meiner Sicht maximal komprimiert und somit auch nur wichtige Informationen stehen.
Wichtig definiert sich als: kann der Anwender hiermit auch etwas anfangen?
und Sortiert: das bedeutet "nicht alphabetisch". Alphabetisch ist aus meiner Sicht auf die Faulheit des Verantwortlichen zurückzuführen - hilft den Anwender entsprechend wenig
Änderbar: Internals bietet die Option, Werte zu ändern durch anclicken. Leider ist das nicht konsequent durchgezogen

von den default (kernal) angewendeten Infos sind (aus meiner Sicht ) wichtig: Type, Name, Definition, State.
Nicht hilfreich sind FUUID, NR, CFGFN.
Fraglich sind die Informationen zu notify.

Meine Forderungen sind:
- die default Daten sind IMMER als erste Zeilen darzustellen, damit ich diese immer sofort sehe und nicht suchen muss
- "NAME" sollte wir auch DEF durch anclicken änderbar sein, also mit rename verknüpft werden
- tiefere informationen, welche nicht sichtbar sind (FUUID,...) kann man über ein get kommando abfragen. OHNE Sichtbarkeit in global "showinternalvalues" umschalten zu müssen (das ist eh ein Scherz :) )
- cfgfn nutze ich schon immer - und immer intensiver. Das ist dann doch eher nerdisch. Also doch unsichtbar!
- ein Satz "get" kommandos über welche man die verborgenen Infos darstellen kann. Ich habe hier "list" als standard in allen meinen frisierten Modulen eingebaut. Man kann ALLE infos sehen, auch die hidden ones. Ist nicht nur wünschenswert sondern ein MUSS!
- eine guideline, was ein Entwickler hier darstellen sollen.
  # keine doppelte Information (bei Presence wird die IP Adresse im Define und explizit dargestellt! Gleiches gilt für Mode
  # Vereinzelte Daten (MODE, ADDRESS,...) müssen einfach automatisiert abfragbar sein. UNABHÄNGIG von der Sichtbarkeit. (die "." Kennung ist technisch einfach für den Programmierer - ansonsten eine Katastrophe)

Internals bietet - im Gegensatz zu readings und attibuten die mögichkeit der Verlinkung. Das ist cool und verleitet(e mich) dazu, assoziierte entites in Internal darzustellen. Probably assiciated ist eine schwache Alternative - werde ich noch kommentieren.
=> also bitte 1) komprimieren 2) sinnvoll sortieren 3) modifikationsoptionen komplettieren 4) guidelines für Entwickler bereitstellen und durchsetzen

martinp876

Sektion "READINGS"

klare Ansage: nichts ist schlechter als falsche Information - besser ist keine Information.
Ich will mich auf Readings verlassen können, wenn sich angezeigt werden. Zu oft nun habe ich gesehen, wie Readings überfrachtet sind, nicht aufgeräumt werden, veraltet sind, geraten sind,....
Das trifft insbesondere auf entites mit vielen mögliche Readings zu. Fritzbox, Stereoanlagen, Wettervorhersagen aber auch Devices mit teils komplexen Konfigurationsmöglichkeiten.

1) Selbstredend muss der Entwickler nicht mehr aktuelle oder abgewählte Readings "LÖSCHEN".
  a) wenn ich den Anzeigemode umschalten kann müssen die nicht mehr gewünschten Readings ENTFERNT werden. Bei HMCCU kann man darstellen, mit oder ohne führende Kanalnummer. Bitte abgewähltes Löschen!!!
  b) bei der Stereoanlage werden die dem Mode entsprechenden Readings angezeigt (radio oder CD oder streaming oder...)  . Also die nicht gewählten Modi löschen!!!
2) wenn die Readings nicht garantiert werden können, müssen diese kenntlich gemacht werden. Wenn bspw ein Device nicht mehr erreichar ist (batterie leer, webseite  nicht erreichbar,...) darf doch ein State "on/off" angezeigt werden. Vielmehr MUSS hier "unknown" zum ausdruck gebracht werden - oder unreachable - oder "übergeordneter Fehler". Man kann gerne vorher retries einbauen
3) bei entites mit extrem vielen Readings kann es sinn machen, die Sichtbarkeit umzuschalten. Die aktuelle Implementierung über "." prefix ist allerdings mehr als schwach. gefordert ist klar:
- Das Abfragen von ReadingsVal muss unabhängig sein von dessen Sichtbarkeit

Ich sehe hier - insbesondere bei entites mit vielen Readings - entsprechende "get" kommandos in welchen man die Readings lesbar aufbereitet darstellen kann. Ein klarer Grund, warum ich Fritzbox umgebaut habe. Das Readings Handling entsprach nicht meinem Anspruch. Einiges war knapp daneben. Aber Knapp daneben ist eben auch vorbei.

==> A) unterstützung des Kernals sichtbarkeit zu schalten um übersicht ermöglichen zu KÖNNEN - ohne sich die Finger zu brechen (wie in CUL_HM) B) disziplin der Entwickler, nicht einfach Readings rauszuko... und dem Anwender das aufwischen zu überlassen C) hierarchische Fehlermeldungen und Readings-handling durch den Entwickler D) NIE ungültige/unsichere Readings stehen lassen. Wenn ich es nicht weiss, darf ich es nicht sagen!



Wernieman

Habe es jetzt nur überflogen (Soyrry) aber noch eine Ergänzung zum ersten Post:
Apple: Viele User sind Glücklich damit, das das System einfach läuft (Apple Weg). Wenn Du es aber nicht so willst wie Appel, kämpst Du nicht nur mit Deinem Problem sondern auch mit Apple
Linux: Genau anders Herum ....

Sorry aber Du gibst den Apple Weg zu viel Positives. Es ist einfach nur ein anderer Weg (Der Konzern bestimmt, was für Dich gut ist).

Ich finde gut, das z.B: FHEM es genau so nicht macht (viele Wege führen nach Rom .. ähh zum Hausautomationssystem). Dafür bezahlt man diese Freiheit aber mit Komplexität.
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

martinp876

ZitatSorry aber Du gibst den Apple Weg zu viel Positives.
sehe ich definitiv nicht so - und das als nicht-apple user. Ich habe noch nicht einmal appel Erfahrungen. Allerdings sollte man sich die Aussagen der AppelJünger auf der Zunge zergehen lassen!
Und - falls es nicht klar geworden ist - ich will Beides. geht das? Ich meine schon. Das System soll in einer sinnvollen und typischen Konfiguration AUTOMATISCH hochkommen. Also nicht das System (das auch) aber eben auch jede Entity für sich. Es ist mir hier wurscht wenn mir einer dann erklärt "das kann man doch einstellen".
Einstellungen will ich für Ausnahmen und "meinen seltsamen Geschmack" machen können.
Für mich ist es schon etwas frustrierend, dass ich bei jedem 2. Modul welches ich implementiere mit Attributen und oder Readings zugesch...adet werde. Bis es das macht, was man sich vorstellt muss man sich durch gefühlt 1000 sonder-parameter wühlen welche Einer aus Hundert möchte - sonst aber kein Schwein interessiert - um dann eine Einstellung zu finden welche macht was man will. De-facto bin ich schon mehrfach zur Selbstversorgung übergegangen. Ich kapere die Module und schreibe sie um. Eigentlich finde ich das traurig.

Wenn FHEM den Linux-Weg geht, (Sytem kommt nackt hoch - da stehen dann alle Möglichkeinten offen es zu konfigurieren) werden min 80% der möglichen User (nutzer einer Haussteuerung) sich gegen das System entscheiden. Und das zurecht, da, wenn sie verstorben sind die Ehefrau das System mangels Maintainbarkeit entsorgen muss - keine Chance!

Aber - wie auch schon erwähnt: Mir ist klar, dass ich hier in einer Nerd-gemeinde poste und somit nur meiner Ansichten und Ideen poste, meine Seele entlaste - aber ohne wirkliche Aussicht auf Erfolg. Who knows, vielleicht dringe ich doch mit dem einen oder anderen durch.
Und Sorry, eigentlich müsste es mir klar sein - unter Lunix-Nerds resultiert das positive Erwähnen von Appel im sofortigen Einstellen des Weiterlesens.

martinp876

So, nun eines meiner für mich wichtigen Anliegen: Sichtbarkeit und Darstellung: VISIBILITY
Zuerst einmal mein Wunsch:
- bei der Darstellung einer Entity auf der typischen Webseite fordere ich eine übersichtliche und prägnante Darstellung. Statische Sortierung (NICHT Alphabetisch!)
- keine überflüssigen und redundanten Daten
- eine Daumenregel besagte einmal, dass die Darstellung auf eine Seite passen muss - und damit meine ich nicht einen hochkant aufgestellten 4K Bildschirm!
- Optional: Man kann die Darstellung "verbreitern" durch einen expert-mode
- Das "list" Kommando muss immer und auf jeder Seite zugänglich sein. Ich habe hier ein get <entity> list in allen von mir frisierten Modulen reingepackt.
- die unsichtbaren Daten müssen schnell und einfach sichtbar gemacht werden können (aktuell ein Alptraum, siehe unten die real-satire)
- die Sichtbarkein von Daten(Readings/Attributen) darf sich nicht auf deren Auswertung und Abfrage auswirken. Siehe noch weiter unten

Sichtbarkeitsumschaltung - real-satire:
Eine Anleitung, wie man sich alle (ALLE) Daten einer Entity ansehen kann, also auch die nicht sichtbaren:
Der typische Anwender will braucht die nicht-sichtbaren Daten nicht sehen? stimmt so nicht. Zu aller erste werden im Frontend nicht alle daten angezeigt (gut so). die "helper" sind unsichtbar - und der glückliche User einer guten Implementierung muss diese auch nie betrachten. Allerdings versteckt der sorgsame Entwickler auch Readings, welche das Frontend überladen würden. Hidden Attribute sind zwar nicht für den User gdacht, doch ggf. darf er sie schon sehen.
Nun, erst einmal kann der Anwender ein "list" machen um die helper zu sehen. Nein, nicht von der Webseite, das wäre zu einfach. Tippen macht doch auch Spass - los gehts. Dann sieht man alles - nun ja, fast. Da muss noch mehr sein.
Also - mit wenigen hundert clicks kann man das erreichen: navigiere geschwind auf die "global" Seite und setze das Attribut "showInternalValues" auf 1. Nee, internal bezieht sich nicht auf "INTERNALS", das ist ein Scherz des Erstellers. Es geht hier im "hidden" Daten aus allen Gruppen. Also eigentlich ein "showHiddenData". Nun kannst du wieder ein "List" eintippen, schon kommt mehr. Ach ja, die Webseite ist auch gleich voller geworden - da werden die die Daten auch gleich reingepresst. Du wolltest doch nur einmal kurz guggen? wird schon. Oh - das ist ein globaler parameter - also sind nun alle Webseiten aufgeblasen worden. Na, schau dir nur alles gut an, was dich nicht interessiert. Wenn du fertig bist geschwind zurück zu global clicksen und das Attribut rücksetzen. Dann ist alles wieder weg - hoffentlich hast du dir alles gemerkt oder eine Kopie gezogen.
=> Ich als klein-Nerd habe mir hierzu ein list sowie ein list-full gebaut - auch in cul_hm unter get zu besichtingen. Alles immer explizit in Perl zu programmieren ist mir auch zu blöd.

Sorry, konnte ich mir nicht verkneifen - ich hoffe es wurde inhaltlich verstanden - nicht böse gemeint!
Zur Sichtbbarkeint von Readings: In CUL_HM hatte ich das Problem zu viele (wichtige aber nicht zu Darstellung geeignete ) Readings verwalten zu müssen. Dies habe ich auf bei einigen anderen Modulen so gesehen - nur wenige Entwickler allerdings machen hier etwas.
Um es mit Bordmitteln zu lösen ist mir nur der "." präfix angeboten worden. Ziemlich dünn und viel Arbeit für mich. Da ich dem Anwender (definitiv) bieten wollte, die Readings zu sehen biete ich
- Umschalten der Sichtbarkeit von Readings auf mehreren Leveln
- Auslesen jedes einzelnen Readings unter ignorieren des Sichtbarkeitspräfix
- "get list" mit sichtbarkeits-optionen

Zusammenfassend: es gibt nicht nur eine Lösung, die Darstellung auf ein sinnvolles Niveau zu heben. Aber eine (konsequente) würde reichen. "."Präfix ist eine mehr als schwache Lösung, auch wenn sie dem Kernal einen schlanken Fuss macht.

martinp876

Nächster Beitrag: dblog - das Module und btw Umgang mir Readings.

Beim Aufsetzen meines neuen Raspberry (noch in Arbeit) habe ich auch das DBlog neu aufsetzen müssen. Und da das neue System "übersichtlich" erstellt werden soll gehe ich die Elemente halbwegs systematisch durch.
dblog ist ein super module - aber verbessern kann man immer etwas. Daher meine Stellungnahme - und natürlich zum gesamten Umfeld wie ich es überblicke.

Grundsätziiche Betrachtung - "wozu sollte loggin gut sein" - use cases
1) dblog ist ein modul zum loggen von Events zwecks späterer Auswertung
2) aktuelle Daten werden aus den Module geholt - dblog ist hier nicht die Anlaufstelle
3) geloggte Daten sind immer historisch - current ist daher m.E. unnötig und verkompliziert alles komplett unnötig. hat mich 1 tag gekostet, die falsche Einstellung zu finden.
4) Auswertung historischer Daten und Darstellung ist grundsätzlich eine Sekundäraufgabe. Auswertungen sind eigentlich nur im sekundärprozess erlaubt.
5) Auswertungen müssen interaktiv alsauch im batch möglich sein. So bswp Grafiken (batch) oder historische Readings/Verläufe analysieren (gelegentich interaktiv).

Meine Analyse der Primärfunktion der Datenbank: speichern von Daten zur Analyse
- wie schon erwähnt sehe ich keine Grund für die "current" Tabelle. Dass der user hier überhaupt mit behelligt wird ist schade/überflüssig.
- logging in der Datenbank ist m.E. ein muss, das file-log ist eher eine Spielerei - also danke für die Implementierung!!
- dass in der Datenbank "events" zusätzlich zu "reading/value/unit" abgelegt wird ist unnötig und eine alte fhem-spielerei (unspezifiziertes filtern)
- die Datenbank sollte dem Anwender Optionen zu Verfügung stellen, die Datenmenge zu begrenzen. Meine Datenbank war 2GB (ich haben nicht aufgepasst) - was mein System crashen kann. Der User könnte bspw einstellen, dass daten max 2 Jahre alt sein sollten. Max Dateigröße sollte man ggf auch einstellen können. Dann alte Daten so lange gekürzt bis die Grenze erreicht ist - nach Datum. Ich habe auch subtilere Ideen im Kopf.... long-history und short-history readings. => die Analyse findet natürlich im Hintergrund statt - bspw täglich einmal.
- Dem Anwender kann man Hilfe und Ratschläge zum sparsamen Umgang mit Daten anheim geben. Das spart erheblich Daten und erhöht signifikant die Performance. Hier ist zu aller erst event-on-change-readings .* zu erwähnen. fhem generiert ungemein viele sinnlose Daten, wenn man es nicht bremst (schade, sollte umgekehrt sein). Es ist vollkommen ausreichend Änderungen zu speichern.

Performance - ein erheblicher Punkt:
- Bei Auswertungen (so habe ich einmal eine Temperaturgrafik über 1a erstellen lassen) blockieren das System. Schlicht ein no-go. 1) natürlich müssen solche Auswertungen möglich sein! Natürlich dürfen solche Auswertungen das Schalten NICHT!!! bremsen
- Nahezu alle Auswertungen sind demnach non-blocking durchzuführen. Das Bedarf an einigen Stellen etwas mehr Koordination. Einige "Kunden" von dblog erwarten eine direkte Antwort - non-blocking geht erst einmal nicht. Da müsste man mehr tun.
- Non-Blocking... damit meine ich - zumindest an dieser Stelle  nicht "forken". Ich gehe davon aus, dass den Entwicklern klar ist, wie forken funktioniert. Eine wiederkehrende Anforderung immer wieder zu forken ist ... unterirdisch. Gerade bei dbLog bietet sich ein eigener Prozess an, welcher kontinuierlich läuft, die Aufgaben erledigt und Ergebnisse postet. Nun bin ich hier nicht der Held in der Implementierung - bei Presence ist das schon am Laufen. Und die Freaks könnten das sicher spielend implementieren.
=> forken blockiert mein System regelmäßig - macht die ganze Himbeere instabiler. das geht besser!

Das User-interface
dblog hat ein paar sonder- verhalten implementiert. Bspw wird nach dem reconnect ein Status "alles ok" ausgegeben. Dabei wird die Seite umgeschaltet. Man muss ein "back" eingeben um die Seite wieder zu sehen. Der Browser für FHEM User ist aber wohl am Besten ein "Kiosk" Browser (ausser zum Entwickeln). - und da gibt es kein Back.
Im Commandref sind "get" Kommandos beschrieben. Diese sind nicht im Userinterface sichtbar. Geht nicht.

Das Umfeld:
ein m.E. sinnvolle Funktion ist (und ich haben sie schon lange gesucht) das anzeigen historischer Readings. Dafür habe ich doch die Datenbank!. Bspw die letzten 10 Readings eine Device oder eines Device/Readings anzuzeigen geht exterm schnell wenn man es korrekt programmiert (so ist DBlog aufgestellt - sehr gut).  Allerdings ist diese Funktion nicht im User-interface.
Anwendung: ich will nachsehen, wie der controllmode meiner heizung umgestellt wird - zeige mir die letzten 10 (oder 3) ereignisse. oder Power-ups. oder...
Da finde ich doch ein Modul readingsHistory - super idee. Nutze ich das doch... schade. das ist kein Readigns-history sondern ein ReadingsLogger (falscher Name) welcher quasi eine Konkurrenz zur Datenbank ist. Warum den so etwas? Das geht doch auch im Eventlog. Etwas viel durcheinander.
=> ein nerd hat freude, so viele ähnliche und von einander unabhängige Funktionen zu finden und spielen zu können.
=> der systematische Anwänder ist mit Eventlog und einem vollstädigen dblog userinterface komplett bedient. Mehr braucht es nicht.

Das User interface:
leider bedarf es neben dblog auch noch dbrep.
aber auch bei dbrep vermisse ich wirklich einfache verfahren, Auswertungen zu machen. Ich sehe erst einmal folgende Anwendungen im interaktiven Bereich:
- Übersicht: welche Devices sind in der Datenbank - mit welchen Readings (das query dauert <<1s)
- Statistiken: wieviele Readings welchen Typs sind in der DB? evlt nach Monaten gezählt. Das gibt eine schnelle Übersicht, ob die Aufzeichnungen funktionieren und wo sich Datenmengen ansammeln.
- recent logs. halte ich für extrem sinnvoll - schnell mal nachzusehen, was die letzten x Event dieses Readings waren. Sicher eher nicht hilfreiche bei Temperatur - aber bei control aktionen.

Richtig cool ist es nun, wenn man die History nicht aus der dblog entity sondern aus dem Device lesen kann. ich clicke auf ein Reading und sage: Statistik - oder last10Events. das ist dann professionell. Allerdings wird hier "interaktionzwischen modulen" verlangt.
dblog könnte auch coole get-kommandos für alle entites zu Verfügung stellen, welche geloggt werden...  Das nenne ich dann User-Freundliche

So alles etwas unkoordiniert - aber macht man es richtig ist es für fhem und die aktuelle Struktur ein dicker Brocken.

Abschliessend: WICHTG!!! dblog ist für das was es anbietet prima implementiert. Das Wiki ist super!!! also bitte nicht negativ auffassen.

Ich werden mir nun mein eigenes dbrep bauen, da ich nicht erwarte, dass etwas passeirt :(





DS_Starter

#7
Moin,

Zitat
Ich werden mir nun mein eigenes dbrep bauen, da ich nicht erwarte, dass etwas passeirt :(

Warum sollte nichts passieren? Bisschen komische Einstellung findest du nicht ?
Irgendwie kränkend.

Aber davon abgesehen, im DbRep gibt es den Setter sqlSpecial. Hier sind einige Statements versammelt welche die von dir gewünschten Reports erledigen

Zitat
aber auch bei dbrep vermisse ich wirklich einfache verfahren, Auswertungen zu machen. Ich sehe erst einmal folgende Anwendungen im interaktiven Bereich:
- Übersicht: welche Devices sind in der Datenbank - mit welchen Readings (das query dauert <<1s)
- Statistiken: wieviele Readings welchen Typs sind in der DB? evlt nach Monaten gezählt. Das gibt eine schnelle Übersicht, ob die Aufzeichnungen funktionieren und wo sich Datenmengen ansammeln.
- recent logs. halte ich für extrem sinnvoll - schnell mal nachzusehen, was die letzten x Event dieses Readings waren. Sicher eher nicht hilfreiche bei Temperatur - aber bei control aktionen.

Ich biete immer wieder an neue Statements mit aufzunehmen die von allgemeinen Interesse sind.
Das mache ich i.A. recht zügig wie es meine Zeit erlaubt.
Es gibt in "Sonstiges" eine Thread zu DbRep. Da kann man sowas gerne platzieren und mitarbeiten.

LG,
Heiko
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

martinp876

ZitatWarum sollte nichts passieren? Bisschen komische Einstellung findest du nicht ?
Irgendwie kränkend.
nicht gegen dich - Erfahrung.
Mit dir habe ich keine persönlichen Erfahrungen - also nichts für ungut.
Kleine Änderungen habe ich schon erlebt. Systematischere Anpassungen eher nicht. Es ist ein gewisser Frust bei mir. Weil ich mir aber die Mühe mache hier zu schreiben habe ich nicht aufgegeben.
Und wenn ich mit jemandem auch einmal grundlegendes diskutieren kann kann sich das schnell ändern.

Mein Problem - oder besser mein Anliegen ist, dass ich bei einigen der Services erst relativ weit in die Tiefen gehen muss um sicher etwas umsetzen zu können.
Ich habe diverse Elemente angesprochen bei dbLog oder dbRep. Nachdem du geantwortet  hast (danke!) fange ich einmal mit dem Simpel User interface an:
- ich habe dblog - dank dem wirklich guten wiki - ziemlich schnell installieren können. (Bei mysql sollte man aktuell m.E. MariaDB Version 10 anführen - alles ander ist nach meinen Erkenntnissen Vergangenheit)
- dann habe ich einen Fehler gemacht und History nicht ausgewählt. Das müsste nicht sein meine ich, da ich keine Notwendigkeit für current sehe.
+ um das ausfindig zu machen habe ich einige Zeit gebraucht. U.a. wegen dem fehlenden Frontend - siehe weiter unten.
=> kann man current nicht einfach abklemmen? Ok, kompatibilität. man kann aber den default auf history setzen und current faktisch ausphasen/in den hintergrund schieben.

Die Keys in der Datenbank sind Device und Reading - diese lassen sich schnell bearbeiten. Daher lässt sich schon einmal ein
get loggedEntries (device|reading|deviceReeading)
erstellen. damit kann der Anwender sehr schnell sehen, welche Einträge in der Datenbank sind. Das ist ein Kommando welches man "clicken" kann. Es sollte als popup am Bildschirm erscheinen damit man es ggf in einen Editor/excel/whatever kopieren kann. Keine riesen Reading-orgien!.

Das 2. wichtige Kommando ist langsamer aber aktueller.
get logEntryCnt [<regexp>]
gibt eine Tabelle welche für jeden der Einträge der regeexp anzeigt, wie viele Einträge im jeweiligen Monat vorhanden sind. Das hilft zu erkennen, was es evtl nicht mehr gibt (renamed oder abgeschaltet) und was performance frisst. also:
                        22Oct   22Sep   22Aug    22Jul
HzWohn:temp        325      105         -       284
.....

Fehlt eine Idee zur zeitlichen Eingrenzung - da es aber eh kein click kommando ist geht es schon
get dblog logEntryCnt Hz.* temp.* 2022-01-01 2022-11-30

so in der Richtung





DS_Starter

#9
Zitat
- dann habe ich einen Fehler gemacht und History nicht ausgewählt. Das müsste nicht sein meine ich, da ich keine Notwendigkeit für current sehe.
Wundert mich etwas. Eigentlich braucht der User nichts auswählen. Die Nutzung der history Tabelle ist der default.
Die current benötigt man wenn man in dem SVG Erstellungseditor eine Vorschlagsliste (Drop Down) erhalten will.
Ist in der Commandref beschrieben, aber offensichtlich nicht eindeutig genug.

Zitat
kann man current nicht einfach abklemmen? Ok, kompatibilität. man kann aber den default auf history setzen und current faktisch ausphasen/in den hintergrund schieben.
siehe oben, dann ist es wahrscheinlich klarer.

Zitat
dass in der Datenbank "events" zusätzlich zu "reading/value/unit" abgelegt wird ist unnötig und eine alte fhem-spielerei (unspezifiziertes filtern)
Habe ich auch so gesehen und das Attr colEvent eingebaut um das Feld EVENTS nicht mehr füllen zu lassen wenn man es möchte.

Allgemein habe ich die Strategie dass DbLog sich ausschließlich um das Logging der Daten kümmern soll.
Zur Auswertung und Datenpflege kommt DbRep zum Einsatz. Historisch bedingt (ist ja schon ein sehr altes Modul) gibt es auch gewisse Auswertungsszenarien und die sollen aus Kompatibilitätsgründen auch drin bleiben. Das waren explizite User Wünsche.
Neue Auswertungen und Pflegetasks kommen nur noch ins DbRep.

Auch ich habe Erfahrungen gemacht. DbLog ist ein zentrales Modul welches mindestens 1451 Definitionen hat.
Fehler und Probleme in FHEM wurden sehr oft mit DbLog in Verbindung gebracht, insbesondere wenn Änderungen in DbLog im Update enthalten waren. Ob nun berechtigt oder nicht sei mal dahingestellt, aber es hat mich sehr viel Freizeit und Nerven gekostet diesen Zustand zu stabilisieren, sodass ich heute auch wieder Zeit habe mich um neue Module und Weiterentwicklungen kümmern zu können.
Deswegen will ich den Änderungsrythmus von DbLog minimal halten. Die Änderungsfrequenz bezüglich Auswertungen und Pflege im DbRep ist deutlich höher und lässt sich auch besser umsetzen ohne den Loggingprozess aus Usersicht zu stören.
Aus oben beschriebenen Gründen werde ich im bestehenden DbLog nur vorsichtig und stellenweise Änderungen einbringen.

Auf meinem Entwicklungsplan steht schon lange ein neues DbLogNG als Nachfolger von DbLog welches bestimmte Nachteile von DbLog, angefangen vom Datenmodell bis hin zur FHEM-Integration, beheben soll.
Aber ich schiebe es schon ewig vor mir her, andere Dinge waren/sind wichtiger gewesen und der Zeitfonds ist begrenzt.


Aber nochmal zu
Zitat
Die Keys in der Datenbank sind Device und Reading - diese lassen sich schnell bearbeiten. Daher lässt sich schon einmal ein
Code: [Auswählen]

get loggedEntries (device|reading|deviceReeading)

erstellen. damit kann der Anwender sehr schnell sehen, welche Einträge in der Datenbank sind.
Es gibt im DbRep den Setter sqlSpecial allDevReadCount der genau das ausgibt. Ist das Attr sqlResultFormat = table gesetzt, bekommt man eine aufbereitete Tabelle ausgegeben und keine Einzelreadings. Kann man mit Copy&Paste nach Excel übertragen. Json ist auch möglich.
Die Ausführung ist asynchron denn der Report kann schon je nach Größe und Performance der DB längere Zeit dauern, bei mir z.B. 35s bei 54Mio Einträgen, und bei synchroner Arbeitsweise FHEM blockieren würde.

Die Anregung mit dem get ... mit dem Popup nehme ich aber gerne für DbRep auf.
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

martinp876

ZitatDie current benötigt man wenn man in dem SVG Erstellungseditor eine Vorschlagsliste (Drop Down) erhalten will.
wieso? geht doch auch mit history - ähnliche Geschwindigkeit.
Und für User ist die Auswahl dann ungeeignet, da man den Zusammenhang nicht kennt. Ich wusste das nicht und hätte current abgeschaltet. Wenn es WIRKLICH benötigt wird dann mache es IMMMER - bedingungslos. Da denst späer keiner mehr dran. Aber besser: Auswahlliste aus History erzeugen: 40ms. Besser nocht- soche Daten in dblog halten, als Tabelle.
select DEVICE,READING  from history group by DEVICE,READING;

Zitatsiehe oben, dann ist es wahrscheinlich klarer.
Performance? Glaube ich nicht. Das geht m.E. besser, einfacher, unkomplizierter. (meine Meinung).
=> jeder einstellknopf der gespart werden kann ist ein schlecher einstelleknopf. Dieser bringt m.E. keine Vorteile - da gibt es kritischeres. Im Übrigen ist die manuelle Auswahlliiste ein eher seltenes Ereignis. Ersparnis geht also gegen Null.

ZitatHabe ich auch so gesehen und das Attr colEvent eingebaut um das Feld EVENTS nicht mehr füllen zu lassen wenn man es möchte.
Super. Besser wäre (ich wieder): kein Einstellknopf. Ichwiederhole mich. Ich werden es abschalten.
=> was passiert, wenn ich umschalte mit den alten Daten und ggf mit etwas unsauberen Abfragen?
=> sauber wäre der schmerzliche Weg: bei Abschalten spalte löschen, bei Einschalte spalte generieren.

ZitatAllgemein habe ich die Strategie dass DbLog sich ausschließlich um das Logging der Daten kümmern soll.
a) im Commandref sind "get" geschrieben welche nicht sichtbar sind. Entweder- oder...
b) count finde ich unangebracht - insbesondere das nonblocking. Faktisch sagt es mir nichts. Evtl ist schon seit Monaten nichts mehr geloggt, da steht immer noch ein count. Blocking ist ein desaster aus meiner Sicht. Es kann zu timeouts beim keep-alive von IO Devices führen.
Aber sonst habe ich es auch so verstanden. Einige Komamndos sind dennoch fraglich für mich:
Warum braucht es addLog und addCacheLine? Soll addLog ein addFilter oder changeFilter sein? Dann wäre der Name Filter (für mich) intuitiver.

set <name> configCheck
super Anwendung. 2 Anmerkungen: Wenn alles ok ist wird sehr viel text geschrieben (verbose) und am Ende klein "ok". Mir wäre bei Fehler die ausführliche Beschreibung wichtig, bei o reicht mir ein ok.
2. Ausgaben sind in einem Pop-up Fenster (m.E.) immer besser - jeden falls sollte der Kontext nicht verschwinden. Kurz: ein "back" sollte man nie nutzen müssen. Zum einen gefällt es mir nicht und etwas greifbarer: im Kiosk Browser sind keine Back Knöpf sichtbar. Und KioskBrowser sind (die Anwendung habe ich lange gesucht) DAS interface für Haussteuerungen.

set <name> deleteOldDays <n>
  Delete records from history older than <n> days. Number of deleted records will be written into reading lastRowsDeleted.
set <name> deleteOldDaysNbl <n>
  Is identical to function "deleteOldDays" whereupon deleteOldDaysNbl will be executed non-blocking.
  Note: Even though the function itself is non-blocking, you have to set DbLog into the asynchronous mode (attr asyncMode = 1) to avoid a blocking situation of FHEM !

1) warum 2 Kommandos? NBL könnte eine Option sein
2) Blocking geht eigentlich garnicht. warum muss es das überhaupt geben?
3) mein Kommando wäre
deleteOldDays (<n>|<date>) "Filter:"[<device:reading>]

ZitateraseReadings
:
1) warum kein Filter
2) hoffentlich NBL
3) könnte in deleteOldDays aufgehen.
4) warum bleibt "state" erhalten?

ZitatreduceLog
1) warum muss es das blocking geben?
2) ich habe gerade mit verwunderung Log-zeilen angesehen. da sind doppelte drin  und auch Daten, wenn sich die Values nicht verändern.
=> ich brauche kein Log, wenn die Values gleich sind. Das braucht eigentlich keiner
=> offensichtlich wird Event-on-change-reading nicht berücksichtigt. Das würde meine datenbank scheinbar erheblich verkleinern. Ich gehe dem noch einmal nach. Irre ich mich hier - nein, geprüft.
=> zum Bereinigen wäre ein remove duplicats und remove-non-change hilfreich.

ZitatbulkInsert
warum kann in User das auswählen? Für wen macht das Sinn? Warum machst du es nicht einfach?

ZitatDeswegen will ich den Änderungsrythmus von DbLog minimal halten.
ok.

ZitatAber ich schiebe es schon ewig vor mir her, andere Dinge waren/sind wichtiger gewesen und der Zeitfonds ist begrenzt.
Auch klar - ich komme kaum dazu meine Anwendung zu stabilisieren - verstehe ich also.

ZitatEs gibt im DbRep den Setter sqlSpecial allDevReadCount der genau das ausgibt. Ist das Attr sqlResultFormat = table gesetzt, bekommt man eine aufbereitete Tabelle ausgegeben und keine Einzelreadings. Kann man mit Copy&Paste nach Excel übertragen. Json ist auch möglich.
das meine ich mit nerd interface. Schon wenn man alle 7 Hebel zieht geht es ab. Gibt es auch etwas für User?

Ich sehe bspw ein Kommando wie
{my ($devSpec,$readSpec,$cnt) = ("((ha|la)).*,lw.*","(.*Valve.*)",20);;
$devSpec = "^(".join("\|",split(",",$devSpec)).')$';;
$readSpec = "^(".join("\|",split(",",$readSpec)).')$';;
my @a = split("\n",fhem("get dbrep sqlCmdBlocking select DEVICE,READING  from history group by DEVICE,READING"));;
my %search;;my $ret ="";;
foreach my $etr (@a){my ($d,$r) = split('\|',$etr);;if($d=~m/$devSpec/ && $r=~m/$readSpec/){$search{"$d#$r"}=1}}
foreach(keys %search){my ($d,$r)= split("#",$_);;$ret .= "\n".fhem("get dbrep sqlCmdBlocking select TIMESTAMP,DEVICE,READING,VALUE,UNIT from (select * from history where device = \"$d\" and reading = \"$r\" order by TIMESTAMP desc limit $cnt)as x")}
$ret =~ s/\|/\t/g;;
$ret}

So etwas (du verstehst sicher, was ich meine) halte ich für hilfreich. Sollte die Liste der Devices/readings ge-cached sein geht es noch schneller.
das Komamndo ist also
get mytools recentReadings <devicespec> [<readingspec>] [<count>]

etwas ähnliches werde ich für die Statistik bauen.
Allen wird NBL -  logisch! mit sauberer Abfrage, nur ein NBL job.

Und wenn ich mich Anstrenge baue ich irgendwann einmal eine TaskExe Prozess welcher keinen Fork macht (warum muss ich ständig eine Prozess incl allerseiner Daten kopieren - je grösser je schlechter - wenn eigentlich garncihts davon brauche

Aber vielleicht wird es noch etwas

martinp876

Ich nehme das mit "event-on-change-reading .*" zurück - mein Fehler. ich habe hier ein forced-event implementiert - und es funktioniert. Also alles gut hier.

DS_Starter

#12
ZitatWenn es WIRKLICH benötigt wird dann mache es IMMMER - bedingungslos.
Nein, oft muß man diese Vorschlagsliste unterbinden um im SVG Editor Freitext für Funktionen eingeben zu können.
Patch für einen erweiterten SVG Editor der dieses Manko beseitigt nehme ich gern entgegen.

Zitat
Super. Besser wäre (ich wieder): kein Einstellknopf. Ichwiederhole mich. Ich werden es abschalten.
=> was passiert, wenn ich umschalte mit den alten Daten und ggf mit etwas unsauberen Abfragen?
=> sauber wäre der schmerzliche Weg: bei Abschalten spalte löschen, bei Einschalte spalte generieren.
Wie geschrieben ich bin den Supportaufwand leid wenn ich etwas abschalte was historisch gewachsen ist.
User verwenden diese Spalte um eigene Informationen dort abzulegen, was durchaus sinnvoll sein kann.
Warum zwangsbeschneiden ? Nicht sinnvoll aus meiner Sicht.

Zitat
b) count finde ich unangebracht - insbesondere das nonblocking. Faktisch sagt es mir nichts. Evtl ist schon seit Monaten nichts mehr geloggt, da steht immer noch ein count. Blocking ist ein desaster aus meiner Sicht. Es kann zu timeouts beim keep-alive von IO Devices führen.
Sehe ich auch so und wollte alle Funktionen die nichts mit Logging zu tun haben entfernen.
Aber User sahen das anders und wollten die offensichtlich lieb gewonnenen Funktionen behalten. Ok, dann soll es so bleiben. Endlose Diskussionen dazu werde ich vermeiden, dafür ist mir meine Freizeit einfach zu schade.

Zitat
Einige Komamndos sind dennoch fraglich für mich:
Warum braucht es addLog und addCacheLine? Soll addLog ein addFilter oder changeFilter sein? Dann wäre der Name Filter (für mich) intuitiver.
Diese Funktionen sind im Gegenteil sehr hilfreich. Sind keine Filter und erlauben Werte ohne Events zu loggen.
Dazu empfehle ich die Commandref vielleicht nochmal zu lesen.

Zitat
1) warum 2 Kommandos? NBL könnte eine Option sein
2) Blocking geht eigentlich garnicht. warum muss es das überhaupt geben?
3) mein Kommando wäre
Wollte ich auch schon alles entfernen weil Auswertungen im DbRep, aber siehe oben .... User wünschten die Beibehaltung.
Ok, dann ist es so.


reduceLog

siehe oben.

Zitat
eraseReadings
Hat nichts mit der DB zu tun und löscht nur die Readings im Device.


bulkInsert
warum kann in User das auswählen?

Hatte einen Grund, müßte den aber wieder eruieren.  ;)

Zitat
das meine ich mit nerd interface. Schon wenn man alle 7 Hebel zieht geht es ab. Gibt es auch etwas für User?
Schon klar, meinen letzten Satz
   "Die Anregung mit dem get ... mit dem Popup nehme ich aber gerne für DbRep auf."
hast du jetzt aber geflissentlich überlesen.  ;)

Zitat
Ich sehe bspw ein Kommando wie ...
Klar, nehme solche Anregungen gerne entgegen um für den User sinnvolle Hilfen zu liefern.
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

martinp876

ZitatNein, oft muß man diese Vorschlagsliste unterbinden um im SVG Editor Freitext für Funktionen eingeben zu können.
Patch für einen erweiterten SVG Editor der dieses Manke beseitigt nehme ich gern entgegen.
workarounds in module einzubauen um unzulänglichkeinten in anderen auszubessern ist fraglich. Das ist eine never ending story. Besser man reapariert an der Quelle

ZitatDiese Funktionen sind im Gegenteil sehr hilfreich. Sind keine Filter und erlauben Werte ohne Events zu loggen.
Dazu empfehle ich die Commandref vielleicht nochmal zu lesen.
Ich habe keinesfalls in abrede gestellt, dass es hilfreich ist.  Warum aber 2 und was ist der Unterschied? AddCache line ist klar - ein event wird in den cache geschrieben udnlandet irgendwann in der Datenbank.
Add log added ein...was? Event in die Datenbank? Log nach irgendwo? Eine tricky Nerd Funktion? Diesen Teil verstehe ich nicht.
Wenn mit cache gearbeitet wird addieren wir events in den Cache - sonst in die Datenbank. Was gibt es noch= Warum muss man das extern steuern?

Nun - wenn die Nerds die Operhand haben und unnütze Kommandos alle extre haben wollen ist das exterm unübesichtlich auf Dauer. Wäre schön, wenn man diese Kommandos für normal-user ausblenden könnte. Ein Attribut "NerdsOnly" könnt seltsame Kommandos freischalten die eigentlich keiner braucht.
===> genau so ist FHEM aufgebaut - jemand will eine Sonderlocke schon ist sie drin. Übersichtlichkeit ist eben etwas anderes.
===> Auch so etwas meine ich mit "es ändert sich dann doch nix am Ende. Keiner traut sich einmal aufzuräumen. Es gibt am Ende immer einen Grund, doch nix zu machen
Sogar wenn wir uns einig sind passiert nichts, kein Cleanup.
Und ja, auch ich kenne die User "aber das hat sich jetzt geändert - ich will alles beim Alten lassen"

Es gibt unterschiedliche Optionen, Kommandos auszuphasen. Bsp:
- komandos werden nicht mehr in der Dropdown listen angezeigt, können noch ausgeführt werden
- ein Not-Recommended Kommentar kann als erstes im Commandref stehen - "wird irgendwann entfernt"
- Kommandos werden per default ausgeblendet aber mit "oldschool" attribut wieder sichtbar - für endliche Zeit.


Hier noch ein entwurf meiner geplanten Statistik
{my ($devSpec,$readSpec) = ("((ha|la)).*,lw.*","(.*)");;
$devSpec = "^(".join("\|",split(",",$devSpec)).')$';;
$readSpec = "^(".join("\|",split(",",$readSpec)).')$';;
my @a = split("\n",fhem("get dbrep sqlCmdBlocking select DEVICE,READING  from history group by DEVICE,READING"));;
my (%searchD,%searchR);;my $ret ="";;
foreach my $etr (@a){my ($d,$r) = split('\|',$etr);;if($d=~m/$devSpec/ && $r=~m/$readSpec/){$searchD{$d}=1;;$searchR{$r}=1}}
my $filterD = join(" or ",map{" device = \"$_\""}keys %searchD);;
my $filterR = join(" or ",map{" reading = \"$_\""}keys %searchR);;
my $retSql = fhem("get dbrep sqlCmdBlocking select DEVICE,READING,count(TIMESTAMP)as cnt,date_format(timestamp,'%y-%m') as YY_MM from history where ($filterD) and ($filterR) group by DEVICE,READING,month(TIMESTAMP),year(timestamp)");;
my %result;;my %pH;;
foreach my $line (split("\n",$retSql)){my ($d,$r,$c,$p)=split('\|',$line);;$pH{$p}=1;;$result{$d}{$r}{$p}=$c}
my $print = "device\treading\t".join("\t",sort keys %pH);;
foreach my $dev (sort keys %result){foreach my $rd(sort keys %{$result{$dev}}){$print .= "\n$dev\t$rd\t".join("\t",map{defined($result{$dev}{$rd}{$_})?$result{$dev}{$rd}{$_}:"-"}sort keys %pH)}}
$print
}

Ich gehe davon aus, dass ein User kein SQL kann und schon garnicht optimieren will. Das kostet Zeit - und der will es nur Nutzen, nicht entwickeln.
Die Regexp könnte erkennen - zumindest einfache. Im einfachsten Fall listet er nur Devices, auch gut.

DS_Starter

Zitat
Add log added ein...was? Event in die Datenbank? Log nach irgendwo? Eine tricky Nerd Funktion? Diesen Teil verstehe ich nicht.
Wenn mit cache gearbeitet wird addieren wir events in den Cache - sonst in die Datenbank. Was gibt es noch= Warum muss man das extern steuern?
Nix tricky Nerd. Mit addLog werden Readings aktiv von Devices abgefragt die keine Events erzeugen (sollen). Auch kann die Abfrage zu einem dedizierten Zeitpunkt erfolgen weil man es braucht, zum Beispiel um korrespondierende Werte verschiedener Devices zum gleichen Zeitpunkt in der DB zu haben.
Wie die Daten in die DB kommen wird entschieden in welchem Modus das Device läuft, der User muß sich nicht darum kümmern.
addCacheLine bietet den Usern die Möglichkeit Daten aus eigenem Code (MyUtils etc.) in den Cache zu stellen und so in der DB zu speichern.

Zitat
===> genau so ist FHEM aufgebaut - jemand will eine Sonderlocke schon ist sie drin. Übersichtlichkeit ist eben etwas anderes.
===> Auch so etwas meine ich mit "es ändert sich dann doch nix am Ende. Keiner traut sich einmal aufzuräumen. Es gibt am Ende immer einen Grund, doch nix zu machen
Sogar wenn wir uns einig sind passiert nichts, kein Cleanup.
Nun man kann es durchaus andersherum sehen. Man sollte auch damit klar kommen mehr zur Verfügung zu haben als man persönlich meint zur Verfügung haben zu müssen bzw. man selbst als notwendig ansieht. Und das Verhältnis von Aufwand und Nutzen solcher Cleanup-Aktionen ist auch wichtig, zumal wir diese Tätigkeit völlig in unserer Freizeit leisten. Aber wem erzähle ich das ... 

Oh man, ich verwende schon wieder viel zuviel Zeit für Diskussionen ....  wollte das doch eigentlich vermeiden ;)
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter