fhem 4 Nerds or users?

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

[martinp876]

Sorry 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]

Moin,

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

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

[martinp876]

Warum 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

Code Auswählen Erweitern

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.

Code Auswählen Erweitern

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]

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

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.

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

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.

[martinp876]

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

Code Auswählen Erweitern

select DEVICE,READING  from history group by DEVICE,READING;

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

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.

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.

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

Code Auswählen Erweitern

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.

Code Auswählen Erweitern

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>]

eraseReadings

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

reduceLog

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.

bulkInsert

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

Deswegen will ich den Änderungsrythmus von DbLog minimal halten.

ok.

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

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.

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

Code Auswählen Erweitern

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

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

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.

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.

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.

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.

Code Auswählen Erweitern


reduceLog

siehe oben.

eraseReadings

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

Code Auswählen Erweitern


bulkInsert
warum kann in User das auswählen?

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

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. 

Ich sehe bspw ein Kommando wie ...

Klar, nehme solche Anregungen gerne entgegen um für den User sinnvolle Hilfen zu liefern.

[martinp876]

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

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.

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

Code Auswählen Erweitern

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

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.

===> 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

[martinp876]

Mit addLog werden Readings aktiv von Devices abgefragt die keine Events erzeugen (sollen).

ok, also
addCacheLine schreibt eine frei definierte Zeile in den Cache - und dann in die Datenbank. Hierbei wird nichts weiter geprüft. Also Device oder Reading müssen nicht existieren.
Ah: Es erlaubt das setzen des Typs ohne Kontrolle. Ein Device kann dann mit 2 Typen im Log stehen... na ja - Typ werte ich sowieso nicht aus.

AddLog liest die Werte der Readings gemäß devicespec und logged diese. Wenn nicht, dann...

Nun bin ich ein Pedant wenn es um die Wortwahl geht. Ich will das Kommando schon am Wort verstehen.
- einmal geht es um eine Lien, dann um ein Log.
- einmal wird der Cache erwähnt, das andere mal nicht.
=> ich mache mir (weil eben Pedant) gedaken darüber, was mir die unterschiedliche Syntax sagen will.
Einfach wäre, wenn das absetzen eine forced-logs unabhängig von Async oder Sync ist. Man führt das Log einfach den Processing zu.
==> Es ist nicht beschrieben, was addCacheLog im Sync mode macht. Garnichts da kein Cache?

addLog kann bspw gut genutzt werden, um nach Mitternacht Readings zu "Forcen". Anwendung: ich nutze immer Event-OnChange-Reading .* . Das ist super - jedoch kann es sein, dass bspw die Wunschtemperatur eines HK erst um 7:00 geändert wird. In einem Graph welcher um Mitternacht beginnt fehlt also der Startwert. Eine Option wäre das regelmässig force-loggen des Wertes alles HK.

==> Nicht beschrieben ist, was addChacheLine macht, wenn mehrere Readings passend sind. Werden dann alle geloggt?

Unschön die eigenwllige Syntax beim Trenner von addCacheLine. Wäre auch mit Whitespace gegangen und " als klammer.

addCacheLine ist also ein "forceLog" oder besser addLog da u.a. auch der Timestamp gesetzt wird.
addLog ist demnach ein triggerLogReading. Hier wird kein Zeitstempel gesetzt und es wird nur ausgeführt, wenn auch das/ein Device existiert. Unit kann man nicht setzen (warum?). Und man kann auch ReadingNamen neu einbauen - was sich mit  addCacheLine überschneidet.

Zusammengefasst: ich hätte mir eine bessere Abgrenzung der Kommandos gewünscht - evtl ist es ja auch nur eines? Am meisten stört mich das "cache" im Namen. Diese Details verlangen dir zur Kompletten Definition der Kommandos einiges an erklärung ab, welche evtl nicht notwendig sind.

Wie wäre es gewesen mit
forcelog <devspec> <readingExp> [<defaultvalue>] [(<timestamp>|now)]
DevSepc: if devicematch is found all matched deivces are processed. If no match is found and devSpec is a valid name-string devspec is uesd as name (even if non-existant).
readingExp: all selected devices are searched for this reading-pattern. Any Match will be added to the Reading list to be processed.
default value: this will be set al value to each of the Device/Reading pair of the device/Reading list where the Reading does not exist.
timestamp: if given this will be set as timestamp. For "now" or it not given the current time will be used.

Unit und Type könnten genause addiert werden. Auch einfach wäre die Nutzung von Prefix m Kommando
forcelog <devspec> <readingExp> [-v:<defaultvalue>] [-t:(<timestamp>|now)]  [-u:unit]

Ich denke du kannst dir den Rest denken.

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

schon klar - auch ich werde für meinen Entwickeranteil nicht bezahlt - wen sagst du das.

Evtl sollte ich das(mein) Zeil noch einmal klarstellen:
Ein Modul sollte erst einmal einfach in Gan zubringensein und sich beherrschen lassen. Für Nerds sollte definitv! Optionen zu Verfügung stehen, lustige Sachen zu impemetieren (das ist das Ween von FHEM!)
=> wenn ich von Optionen und Funktionen überflutzt werden ist das kein guter Einstieg.
=> Typische Kommandos müssen vorgefertigt vorhanden sein um die Basisabeit zu erledigen. Basisarbeit bei einer Datenbank sind die primären Abfragen - welche man definieren sollte. Diese müssen bspw ohne SQL Kenntnisse erfolgen können

[martinp876]

Ich finde unsere Diskussion sehr interessant - möchte aber noch einmal anders anfangen. Wir sind schon im Detail - und meine Anregung in diesem Thread soll sein, etwas mehr "User" zu denken - Nerd ist schon sehr viel in FHEM.

Mit ist auch vollkommen klar, wie die Module entstanden sind, sich entwickeln und welche Probleme man hat ein einzelnes Kommando wieder auszuphasen. Viele Module sind gewachsen und nicht designed. Man hat mal angefangen, dann hat es sich entwickeln (war bei mir meist nicht anders). Um rückwirkend struktur in das User-Interface zu bekommen bedarf es großer Durchsetzungskraft. Könnte sich aber lohnen.

Daher die Anregung, deine (wichtige)  Funktion DB-logging ohne jegliche Hstorie , aber mit der Erfahrung zu betrachten und das Userinterface zu gestalten.
Wichtigste Frage: was sind die Use-Cases:
a) Generieren von Grafiken - diese Daten werden von Programmieren aus der DB geholt
b) lesen der letzten x Readings - weil ich wissen will, wie oft mein Device resetet, der Lichtschalter betätigt wird. Wann das letzte Mal sich en Reading geädert hat. => ein getLastEvents
c) statistik zur Auswertung, was wo wie oft passiert. Tabelle nach Monaten, Tagen oder Wochen sind denkbar.
d) welche Readings werden geloggt, seit wann und wie lange? Daraus kann/will ich schnell er erkennen, dass alles was ich will geloggt wird und nix anderes

Maintenance:
c) Ist meine DB noch connected? Automatischer Reconnect, Wie oft tritt das auf - Zähler. Der Admin-User muss beurteilen, ob die DB stabil connected ist.
d) wann wurde das letzte mal erfolgreich geschrieben
e) automatische Größenbeschränkung der Datenbank. Alte Einträge werden bspw. täglich oder wöchentlich (reicht auch) nach Kriterien gelöscht

Wenn es 2 Module geben muss (DBlog und DBrep) sollte diese klar und logisch abgegrenzt sein. Eigentlich will ich das schon am Namen sehen DBserver und DBreader
Ziel wäre bei mir immer, wenn ich ein Modul instanzieren erkenne ich die wichtigsten Kommandos sofort - ohne commandref. Nach möglich möglichkeit per drop-down.

Und haltet mir ungülige Kommandos fern. Wenn ich bspw im Sync mode bin gibt es keinen Cache.
-> alle cache kommandos werden ausgeblendet
-> beim Umschalten von async nach sync muss der cache gepusht werden.
-> ungültige Readings werden IMMER automatisch Entfernt.

Übrigens kann man beim Booten oder definieren auch automatisch Attribute setzen. Beim Reboot muss man etwas vorsichtig sein, geht aber auch. Der Anwender hat dann schon einmal die Wichtigsten Defaults vorliegenund kann diese ändern. Halte ich für exterm hilfreich, da diese Defaults dann nicht hidden sind.

Das ganze ist nicht komplett - ich hoffe die Idee ist verstanden.

[Adimarantis]

Hi Martin,

ich finde die Diskussion recht interessant. In meinem Modul (Signalbot) habe ich mir schon Gedanken gemacht, wie ich Dinge für den Anwender so einfach wie möglich halten kann. Da stoße ich allerdings als Programmierer auch oft an meine Grenzen, denn die ganzen "Tipps&Tricks" wie man FHEM Web dazu bekommt gewisse Dinge komfortabler zu gestalten sind nicht wirklich schön dokumentiert.

Ein paar Dinge die ich dazu realisiert habe sind
- Benutzerführung in der detailFn für den Registrierungsprozess
- Reduktion der langen "set" Listen durch kontextsensitive Liste (nur anbieten was gerade auch Sinn macht) und zweistufige set Befehle (also z.B. statt 5 set groupXXX Befehle, set group -> XXX -> argument - hat mir Rudi extra eingebaut )
- Hauptfunktionalität (bei mir das Senden einer Nachricht) zusätzlich als Widget am Anfang

Was ich mir auch gewünscht hätte, wäre die Möglichkeit die "set/get" Liste selbst zu sortieren, statt stur alphabetisch. Ist ein Grund für mein "send" Widget, da "s" leider im Alphabet recht weit hinten kommt und so bei "set" etwas an erster Stelle steht was eher nicht so häufig gebraucht wird. Der Author von Telegrambot hat das mit einem "_" vorneweg gelöst - unschön, dass man so einen Workaround braucht.

Alles was darunter kommt (Internals, Readings) nehme ich zugegebenermaßen als gegeben hin. Ich wüsste jetzt spontant nicht wie man die ganzen Internals ausblendet (bzw. relevante Daten beibehält), meine Readings sind auch gewachsen und könnten übersichtlicher sein.

Wenn ich da Richtung "User" gehen wollte, dann müssten die Internal und Readings in ihrer Form weg, und dafür die relevanten Infos ein einer schön aufbereiteten Form - so dass es eben bei "normaler" Aulösung auf eine Seite passt.
Statt der Attribute bräuchte man einen Config Editor, der möglichst noch mehr Hilfestellung gibt und die Einstellungen thematisch statt alphabetisch gruppiert sowie gleich auf gewisse Abhängigkeiten achtet.
Statt komplexer Syntax für die Favoritenliste müsste auch ein schöner Editor her.

All das übersteigt aber mein Wissen über die Möglichkeiten in FHEM Web. Da müsste erstmal ein gut dokumentiertes Baukasten System her -> halbwegs einheitliches Look&Feel und nicht jeder erfindet das Rad neu.

My 2 cents...

Jörg

[martinp876]

Hallo Jörg,
korrekt, sortieren wäre cool. Ich habe an einigen Stellen die Komamndos, Readings und Attribute entsprechend gesetzt.

Alles was darunter kommt (Internals, Readings) nehme ich zugegebenermaßen als gegeben hin

Ich eigentlich nicht. Readings, ok. Internals: hier plädiere ich vehement für eine Sortierung der Standards. Also Name/Typ/Def und sonstige Teile gehören an die Spitze in eine fixe Reihenfolge.

Ich wüsste jetzt spontant nicht wie man die ganzen Internals ausblendet (bzw. relevante Daten beibehält), meine Readings sind auch gewachsen und könnten übersichtlicher sein.

Nun, immer wenn du die Daten in der Hand hast ist es einfach, evlt aber anstrengend (für dich).  Alles was jemand anders setzt kannst du nicht beeinflussen.
1)Es ist dir sicher bekannt, dass internals nur in der ersten Ebene sichtbar sind. Wenn du also Daten benötigst kannst du diese in einem Sub-Hash verstecken.
2) alle Variablen welche mit "." beginnen sind erst einmal unsichtbar. Mit dem Attribut global showInternalValues kann man hier umschalten.

Man könnte viel besser machen. Einiges kannst du aber erreichen - allerdings kenne ich deine Anwendung nicht. in CUL_HM habe ich einiges Realisiert... auch hier ist einiges gewachsen - also nicht optimal aber ich bin weitgehend zufrieden.

Hier ein paar ideen welche ich realisiert habe - unter den Einschränkungen der FHEM Möglichkeiten. Hintergrund: CUL_HM bedient einige unterschiedliche Geräten (Homematic eben). Diese haben unterschiedliche Kommandos, Parameter und Attribute. Ziel ist, ausschliessliche gültige zuzulassen, alle anderen stringent verhindern.

1) es gibt immer ein get cmdList (short|long) welches sämtliche Kommandos dieser Entity auflistet - mit kompletter Syntax und ggf kleinem Text. Ich parse alle Kommandos exakt nach dieser Syntax - immer - in einer Funktion. Du erkennst Optionen, Defaults,... das ganze voll dynamisch. Sollte sich also eine neue Kombination ergeben wird diese eingepflegt. Die Sortierung gestalte ich
2) ein "get list (normal|full) sollte nie fehlen. list normal zeigtdas gleiche an wie das manuell eingetippte Kommando - nur ohne tippen. List full zeigt mir auch das, was ich nur sehen kann, wenn ich vorher attr global showInternalValues 1 mache an. Das ist ein no-go. Wenn ich einmal wirklich sehen will, was gespeicher ist muss das sofort gehen.
3) in Internals habe ich zu viel eingetragen. Hier plädiere ich für ein "get deviceInfo" mit einer Liste von optionen, was man darstellen soll - in einer entsprechenden Form. Internals ist m.E. einem Kurzstatus vorbehalten. Die meisten anderen Daten schaue ich mir nur gelegentlich an.
Selbstverständlich solltest du eine get Funktionvorbereiten um Daten automatisch abzufragen.
4) Bei CUL_HM haben die devices teils unendliche viele "Register", also Readings. Hier habe ich mehrere Methoden eingbaut, diese Sichtbar zu machen.
4a) Readings sind hidden also mit ".". Über ein "get" kann man die Register visualisieren - in tabellenform nach meinem Design
4b) über das Reading "expert" kann man einstellen, was man in den Readings sehen will. Das ist natürlich  dank der nahezu komplett fehlenden Unterstützung von FHEM wirklich arbeit. Ich baue den Punkt vor die Readings und nehme ihn weg, je nach mode. dabei mus sich sicherstellen, dass bei Abfragen (welche ich in der Hand habe) der Punkt ignoriert wird, also immer das korrekte Ergebniss kommt. Am Ende denke ich, dass es sich gelohnt hat. Dennoch hätte ich mir eine bessere Option des Kernal gewünscht.
=> damit kann ich die Readings wirklich kurz und übersichtlich halten und doch alles zu verfügung stellen - sogar auf 2 Ebenen, je nach Geschmack.
5) Obsolete Readings werden konsequent eliminiert (wenn identifizierbar).
6) für Attribute gilt gleiches wie für commands: nur gültige werden erlaubt
7) ich setze einige Attribute bei der Definition auf default Wert. Grund: ich bin der Meinung, dass einige Defaults dem Anwender gezeugt werden sollten. Das erhöht die Aufmerksamkeit. Weiter mache ich auch einen Vorschlag (attr webCmd) indem ich enen m.e. sinnvollen Default setzt.
7a) das Vorgehen hat zur Konsequenz, dass ich defaults von User-aktionen unterschieden muss. Insbesondere beim Reboot komme die Attribute in ungeordneter Folge zur Verarbeitung. Hier funktioniert der Parser nicht, da es abhängigkeiten gibt.
=> ich kann die Attribute beim Reboot erst prüfen, wenn alle da sind. Also ist es zwingend, sich einen Post-init-trigger zu setzen - wenn init_done auf 1 geht. Dann gebe ich CUL_HM die Zeit, Attribute zu prüfen, ggf auch zu löschen und Parameterlisten zu erstellen.
Wenn du abhängigkeiten zu anderen Entites hast, deren Namen oder Attributen, ist es deine Pflicht, eine Teilchen auf Stand zu halten. Du musst dich also über abhängige Änderungen informieren lassen und nachziehen. Ordentlich in Notify einhängen. Mein getuntes "Notify" erkenne renames von entites und passt die Einstellungen automatisch auf verschiedenen Ebenen an.
9) in CUL_HM kann man über "readingOnDead" erreichen, dasss selektierte Readings auf dead oder 0 gesetzt werden. Es hat mich aufgeregt  - und ist schlicht unterirdisch, dass, wenn sich ein device nicht meldet, immer noch Messwerte angezeigt werden. Wo gibts den so was.
10) semantisch korrekte Namen - konsequent genutzt. Hier habe ich sicher Defizite. Beispiel ist dblog üer das ich gerade brüte. "cache" ist m.E. schlicht falsch, wir haben hier einen WriteBuffer. Alle Kommandos und Attribute könne man also mit "wb" beginnen lassen. Damit wäre auch Synchron/Async erledigt Wir hätten einen Bufferd/non-buffered mode. Du musst deine Anwendung dahingehend durchforsten. Ein eingeführter Begriff ist nahezu nicht mehr zu entfernen.
11) Zeil meine rKommandos ist immer, es mit "click" zu lösen. Bei dbLog ist set count und set countNbl m.E. schlecht.Ich hätte sein set count (blocking|nonBlocking) definiet (oder blocking eliminiert)

Esgibt noch ein paar mehr details. Nicht von mir (und daher) aber Super isr das Interface zur Programmierung von Registern in CUL_HM. Das ist echt Usergeführt.

Wichtig ist auch, Ausgaben über pop-ups zu gestalten.
Ich habe lange gesucht nach einem Frontend. Mit TabletUI kann man Webseiten gestalten - bisher das Beste. Man kann alles, ist aber schonkompliziert amEnde etwas cooles zu bauen. Aber das alleine reicht nicht - nun habe ich den Kioskbrowser entdeckt. Das beide zusammen ermöglicht endlich, ein tablet zu Haussteuerung aufzustellen. Für jedermann erreichbar.
Jetzt kommts: Hier gibt es keinen "back" Button. Daher mussen alle Ausgaben auf der Seite erfolgen oder in enem Popup.

Sicher gibt es noch mehr, sich auszutauschen... und meine ideen sind weder einzig  noch alternativlos. Es ist ein Anfang, meine ich. Wenn FHEM aus der Basis heraus etwas mehr unsterstützen würden ginge deutlich mehr!

[Adimarantis]

Hi Martin,

internals lege ich grundsätzlich in $hash->{helper} und damit unsichtbar.
Trotzdem zähle ich 11 internals bei meinem Modul, von denen ich nur "STATE", "VERSION"  und "model" absichtlich setze (letzters wegen der statistics).
Vom Rest ist vielleicht gerade noch "TYPE" für den Anwender interessant. Der Rest braucht bloss Platz.
Readings aufräumen muss ich glücklicherweise eigentlich nicht, da die bei mir recht konstant sind. Lediglich mein "lastError" für aynchrone Fehlermeldungen sollte ich vielleicht nach eine Weile auf "ok" setzen - eine Fehlermeldung die schon Tage alt ist verwirrt erstmal (auch wenn man das am Datum erkennen könnte).

Thema fork() übrigens: Da habe ich bei Signalbot und auf RPI_1Wire (rewrite von GPIO4) viel Aufwand reingesetzt das ganz oder zumindest weitgehend zu vermeiden. Das sieht aber anscheinend nicht jeder so, wie ich schon bei Diskussionen gemerkt habe.

Aber vielleicht genug Beweihräucherung, wie toll wir das alles schon in unseren Modulen gelöst haben.
Auch wenn ich gerne einiges ändern würde, weigere ich mich einfach massig Zeit in Workarounds zu hängen, weil das FHEMWEB Framework es nicht hergibt - und das ist nunmal Stand der Dinge. Alle anderen Frontends erfordern, dass der User seine Oberfläche individuell zusammenstellt. Um mehr für "User" zu tun (und ggf. auch mehr zu gewinnen) muss der Standard besser werden.
Mal zusammengefasst:
-> Mehr Kontrolle für den Moduldesigner über Darstellung (alles ein/ausblendbar, sortierbar, dynamisch)
-> Widgetbaukasten um modulspezifische Ersatzdarstellungen für Internals, Readings, Attribute etc. zu machen: Tabellen, sich gegenseitig beinflussbare Pulldowns, Eingabefelder mit Syntaxcheck ("save" Button für mehrere Einstellungen gleichzeitig, der einen Plausicheck machen kann und dann Felder z.B. einfärbt die korrigiert werden müssen)
-> Designguidelines und Dokumentation dazu.

Ich denke viel geht sogar schon. FHEMWEB kann viel, ist aber alles versteckt. Wenn ich mir "Babble" anschaue, dann hat pah hier irgendwie eine Darstellung hingekriegt, in der man eben keine Internals etc. mehr sieht. Das ist aber irgendwie ein "Room" - in der Device Ansicht schaut es wieder "normal" aus.

Vielleicht braucht es dazu aber doch eine Alternative zu FHEMWeb die ein moderneres Look&Feel für "user" implementiert (FHEMWEB ist dann für "nerds" ).
Das muss aber dann trotzdem immer in der Lage sein einen Default View zu erzeugen, ohne dass der Anwender oder Moduldesigner Hand anlegen muss.
Problematisch wirds dann, wenn schon in die FHEMWEB Trickkiste gegriffen wurde - da funktioniert dann evtl. nicht mehr alles.
Dieser Default kann ja eher Minimalistisch sein - der Weg zum "nerd" Modus in FHEMWEB steht ja offen.

Leider ist das eine extrem aufwändige Grundrenovierung für die wahrscheinlich keiner Zeit bzw. notwendiges KnowHow hat.
Sowas geht auch nur kooperativ. Das Prinzip ein Modul - ein Maintainer wird da nicht mehr funktionieren.

Da müsste das ganze FHEM Projekt in ein gemeinschaftliches OpenSource Projekt (GitHub?) umgewandelt werden, bei dem jeder PRs für jedes Modul machen darf.
Wäre vielleicht ohnehin ein erster Schritt. Habe schon so oft gesehen, dass Maintainer (aktuell) nicht erreichbar waren und zwar Fixes oder Anpassungen vorgeschlagen werden, aber sich keiner "traut" das auch einzuchecken (nicht dass man dann implizit plötzlich Maintainer wird).
Bei einem PR Ansatz sollte zwar möglichst der Maintainer Änderungen vornehmen und PRs akzeptieren. Wenn er aber nicht zeitnah reagiert und genug andere die Änderung gut finden, sollte sie genauso gemerged werden.

Jörg

[martinp876]

om Rest ist vielleicht gerade noch "TYPE" für den Anwender interessant. Der Rest braucht bloss Platz.

genau meine Meinung. Diese Daten (auch manchmal interessant - aber wohl selten) muss man über ein "get deviceInfo" abfragen können - oder über ein InternalVal was auch hidden unterstützt.
==> Rudi müsste über seinen Schatten springen.

Thema fork() übrigens: ...

Fork muss man sinnvoll einsetzen. Ich sehe das so:
Prio A) der operationelle Ablauf, also die Steuerung, das keepalive, die Device kommunikation dürfen nicht gestört werden. Ein einzelner Task sollte eine bestimmte Länge nicht überschreiten. HM IOs haben einen 30s timer - wenn das keepalive nicht kommt müssen sie neu synchronisieren. Viel schärfer sind die Timingvorgaben der HM Protokolle. Hier werden Antworten <<1s erwartet.
==> alles das display, manualle Abfragen u.ä. betrifft MUSS in den Hintergrund. Wenn einige Entwickler ihr Modul als den Nabel der Schöpfung einordnen kann ich das nicht verstehen.
==> wo genau die Grenze ist, ist scher zu Entschieden.

Forken) Ich hoffen jeden ist kla, dass beim Forken immer eine komplette Kopie des Prozesses gemacht wird. Je grösser der Prozess um so mehr resourcen werden der CPU genommen. Bei jeden Forken neu.
=> in CUL_HM / HMInfo forke ich für einen Config-check. Zum Einen benötige ich sowieso viele Informationen, und zum Anderen dauern die Auswertungen etwas. Und drittens wird das nur selten aufgerufen. Somit ein klassischer Fall für "forken".

Externener Prozess) in Presence hatte jemand zum Pingen der BT Teilnehmer einen externen Prozess erstellt. Optimal. Der Prozess wird ständig gebraucht und es braucht nahezu null info um einen Auftrag zu erteilen. Leider wurde IP-Ping über Forken in einer geradezu chaotischen Weise implementiert.
Im Falle von DBlog ist ein externer Prozess genau das, was man benötigt. Wenn ich aktuell eine Grafik erstellen lasse und 1 Jahr als Zeitraum eingeben bleibt alles stehen.... geht garnicht.

Aber vielleicht genug Beweihräucherung, wie toll wir das alles schon in unseren Modulen gelöst haben.

klar - und das geht oft in die falsche Richtung los. Meine Beispiele sollen Anregungen sein, dass etwas geht. Es gibt auch deutliche bessere Lösungen - und jeder Fall liegt etwas anders.

Um mehr für "User" zu tun (und ggf. auch mehr zu gewinnen) muss der Standard besser werden.

genau weil ich dieser Meinung bin habe ich diesen Threat gestartet.

FHEMWEB kann viel, ist aber alles versteckt.

Korrekt. Ich nutze TabletUI - ist aber doch sehr anstrengend, eine sinnvolle und vor allem sinnvol programmierte Oberfläche zu schaffen.

Dieser Default kann ja eher Minimalistisch sein - der Weg zum "nerd" Modus in FHEMWEB steht ja offen.

Und das ist wichtig. Ich wünsche mir einen Nerd-Zugang wenn ich einmal etwas sonderbares machen will. Aber  erst einmal sollte man einschalten und spielen können.

Leider ist das eine extrem aufwändige Grundrenovierung für die wahrscheinlich keiner Zeit bzw. notwendiges KnowHow hat.

Ich will eine "User-Admin" oberfläche (FHEM-web) um das System zu beherrschen und ein Tablet-UI für meine Frau (Kiosk Browser führe ich gerade ein).

[martinp876]

Noch ein Beispiel zu DBlog  - event filtering. das hätte man m.E. einfacher machen und beschreiben können.

Code Auswählen Erweitern

define <name> DbLog <configfilename> <regexp>
<regexp> is identical to the specification of regex in the FileLog definition.

<regexp> sollte eigentich <eventFilter> heissen man beschreibt den Inhalt nicht die Syntax.
Die korrekte Syntax ist
define <name> DbLog <configfilename> [<eventFilter>]
da eventfilter optional ist.
in Filelog ist unklar, ob der Filter optional ist.
Ich bin wieder einmal der Ansicht, dass der Filter ein Attribut sein müsste. Unklar ist, ob mehrere Kombinationen zulässig sind wie man das implementiert. Also (wz:level.*|sz:temp.*). Die Beschreibung ist hier zu dünn.
Bei DBlog ist es demnach genauso unklar - hier hat man aber die Option, jedem Device ein Attribut mitzugeben. Nein, sogar zwei.
=> es hätte definitiv auch eines gereicht: DBeventFilter.
da es nun 2 sind stellt sich die Frage, wie das ganze verarbeitet wird. On Top kommt noch der DBlogSeletionMode.

Die Beschreibung ist schon cool:

Exclude: DbLog behaves just as usual.

ok - aber was ist usual?
und warum braucht es den Mode, wenn es doch 2 Attribtute gibt? Ist ein Übersteuern notwendig?

Wenn ich nun include und exclude defnieren - und on Top noch den Übergreifenden Filter habe - wie geht das denn nun?
Kann man das nicht einfacher Beschreiben wie z.B.
event => filter by global Filter => apply DBexclude filter => apply DBinclude filter
noch etwas ausschmücken, damit kann ich etwas anfangen.
Einfacher ist
event => filter by global Filter => apply DB devicelevel filter
der Devicelevel Filter kann auch ausschliessen.

So und nun sind einfacher Anwender verunsicht - wird mein Event das nächste Mal auch geloggt? Nun helfen wir ihm doch. Einige Optionen:
- DBlog hat ein "get deviceFilter" welcher alle devices und deren Filter anzeigt. Auch die welche gar nicht geloggt werden oder die, welche alles loggen lassen.
- ein SimulateFilter macht in jeden Fall sind. Hier werden alle aktuell vorhandenen Readings dem Filter unterzogen und der User erhällt eine liste aller ereignisse, welche geloggt würden, würde das event eintreffen. Selbstredent kann man die Analyse auf devices ein schränken
=> Der User muss sich dann keine Gedanken machen und seltsame Evnts generieren.Wysiwyg war einmal in.

damit hatte ich 2 Attribute weg optimiert und eine Validierungsoption geschaffen, welch e definitiv von Usernund Nerds genutzt werden kann.

[martinp876]

nun habe ich doch im Code nachgesehen um zu verstehen, wie Include/Exclude funktioniert.
Hierbei hätte ich etwas Anregungen die Performance betreffend. Das Modul klinkt sich ja nun bei allen Readings und Events ein - somit erwarte ich maxmale Performance.
Kleinigkeit: Wenn man my $name     = $hash->{NAME}; definiert und den Namen extrahiert macht es sinn, diesen auch durchgängig zu nutzen. Bei dev_ahsh dito.

Ich sehe weiterhin dass der Include/Exclude string jedes mal frisch gelesen und zerlegt wird. Das ist nicht notwendig, so etwas macht man, wenn das Attribut gesetzt oder geändert wird. Man kann sich hier prächtig in die Notifies des Kernal einhängen und immer auf Stand bleiben.
Jedel Mal zerlegen geht eigentlich garnicht-

[DS_Starter]

Ich will mich nur nochmal ganz kurz zu der folgenden Aussage äußern:

Wenn ich aktuell eine Grafik erstellen lasse und 1 Jahr als Zeitraum eingeben bleibt alles stehen.... geht garnicht.

Dir ist schon klar, dass dies nichts mit DbLog zu tun hat sondern mit den Attributen im FHEMWEB, oder ?
Du hattest ja schon configCheck ausgeführt, aber vermutlich den folgenden Inhalt geflissentlich ignoriert:

Result of plot generation method check

WARNING - at least one of your FHEMWEB devices has attribute "plotfork = 1" and/or attribute "plotEmbed = 2" not set.

WEB: plotfork=1 / plotEmbed=2
WEB.BLACK: plotfork=1 / plotEmbed=1
WEBSSChatBot: plotfork=1 / plotEmbed=2
WEBphone: plotfork=1 / plotEmbed=2
WEBtablet: plotfork=1 / plotEmbed=2

Recommendation: You should set attribute "plotfork = 1" and "plotEmbed = 2" in relevant devices. If these attributes are not set, blocking situations may occure when creating plots. Note: Your system must have sufficient memory to handle parallel running Perl processes. See also global attribute "blockingCallMax".

Ich wollte das nur fachlich richtig stellen weil es eher in die Kategorie FHEMWEB gehört was vermutlich auch noch in deiner Betrachtung Platz finden wird.

Nunja es freut mich jedenfalls dass du dich so intensiv mit DbLog beschäftigst. Dann habe ich wenigstens eine Stichpunktliste was ich alles überarbeiten könnte wenn ich mich mal wieder Zeit investieren will um mich mit dem Modul auseinanderzusetzen.
Vielen Dank für die viele Zeit die du hier investierst .... endlich mal jemand mit Durchblick, Respekt.

[martinp876]

nun, hatte ich nicht gesehen - sorry.
Habe es gleich geprüft.
1) plotfork war schon gesetzt
2) plotEmbed war nicht gesetzt - sollte also bei einem Raspi3 auf 2 defaulten.
=> damit sollte ich auf Stand sein. Deine Auswertung betrachtet nicht die Defaults. Verständlich, da sie nicht wirklich abfragbar sind. Sollte man auch ändern... wenn ich ein nicht gesetztes Attribut abfrage und dies einen default Wert hat. Dies ist aber wieder einmal ein Kernel Problem.

Zu dbLog abschliessend von meiner Seite (wir sind ja hier auf der Wunschseite ):
mir würde eine Lean-Version des DBlog gefallen, welche sich von den alten Zöpfen verabschiedet. Wir waren uns bei fast allem eigentlich einig, wie wir es machen würden. De facto würde ich bezüglich des User-Interface einen cleansweep machen und nur das realisieren, was sinn macht. Ich fasse noch einmal die kernpunkte zusammen (weil ich zusammenfassungen mag). Da ich bei einer Umstellung dieser Art erhebliche Probleme in der kompatibilität sehe würde ich an deiner Stelle den harten Schritt gehen und en dblogLean oder dglog2 auf den Markt bringen. Das aktuelle Modul würde ich als phase-out markieren und die Maintenance einstellen (wenn das 2. fertig ist).

Die Punkte welche ich mir wünsche
- nur history, kein current. Diese Auswahl aus allen Kommandos entfernen
- cache/async/... nach writeBuffer(-mode) umlabeln.  Alles hierzu beginnt mit "wb". Einschalten über Attribut wbTimer=0 (sofortiges schreiben ist faktisch ohne Buffer, also sync). wbMaxSize sind die maximalen Einträge im Buffer. Wenn erreicht wird geschrieben. Wenn schreiben schief geht wird der Buffer um max x% überzogen, dass wird weggeworfen. ==> es MUSS ein Limit geben. Auch wbTimer sollte einen Wertebereich haben 0=unbuffered, 300...80xxx(1 Tag) ist der zulässige Wertebereich - default ist 30min. 100000= use enMacSize only
- das Filtering hatten wir gerade
- alle config Angelegenheiten werden zur config-zeit erledigt (das sollte alle module so handhabe). Wenn also bspw ein Attribut dbFilter in jeder entity angeboten wird ist es die Pflicht von dbLog als faktischer owner auch die ünersicht zu behalten und es zur config-zeit zu verarbeiten.
-- typisch kommt man dann zum Ergebnis, dass man sich über alle attr/define/defmod/rename informieren lässt und hier anpasst.
-- dblog ist einem notify sehr ähnlich, eigentlich ist es eines - mit fixer exe. Da ich mit dem standard notify nicht einverstanden war habe ich es umgeschrieben und all das  - zumindest versucht - zu berücksichtigen. Bei mir klappts Will sagen, kein hexenwerk, sogar ich kann das
- dblog muss sich bei notify natürlich ordnungsgemäß enrolen - für alle Devices
- ein deamon-prozess sollte erstellt werden (da bin ich nicht fit - aber für die Könner sollte es kein Problem sein.
- ein Modul - so auch dbLog - sollte renames berücksichtigen. Das betrifft insbesondere den Filter aus dem Define. Ich werden diesen nie benutzen... eigentlich würde ich ihn streichen. Aber wenn er schon da ist müssen die Devices identifiziert werden, welche gefiltert werden. Und das bei jedem umbenennen und jeder neu-definition neu. Auch bei Attributänderungen wenn bspw devspec2array genutzt werden darf.
==> Grundsatz: wenn bspw ein rename eines devices stattfindet oder attribute gesetzt werden muss das system SOFORT genauso reagieren wie es nach einem reboot reagieren würde. Keine Diskussion möglich zu diesem Punkt.

Sicher werden/würden beim Überarbeiten weitere Punkte erkennbar...
Freut mich, wenn mein Anliegen zumindest verstanden ist.
freut mich richtig, wenn es (vielleicht auch nur in Teilen) umgesetzt wird.
Da ich auch nur begrenzt Zeit habe kann ich nicht immer am Ball bleiben.... ausser HomeAutomation habe ich noch ein weiteres Leben .
Jedenfalls danke fürs zuhören, wer bis hier unten gelesen hat.

[martinp876]

So - Themawechsel zu "propably associated":
=> ich halte dieses Feature für extrem wichtig und hilfreich, wenn man bei wachsenden Systemen als Admin den Überblick behalten will.
Allerdings muss ich feststellen, dass ich mit der aktuellen Implementierung nahezu komplett unzufrieden bin. So kann ich eigentlich nichts mit anfangen.
Es mag an den Anforderungen und dem Anspruch liegen, welche man sich stellt, wenn man so etwas baut.

Aktuell bewerte ich die Implementierung als: muss einfach zu implementieren sein, wenig code, automatisch. Kein Anspruch auf Vollständigkeit oder Bezug.

Mein Anspruch ist:
- max effort, eine vollständige List der Abhängigkeiten zu erzeugen
- klassifizieren der Abhängigkeiten
- evlt 2nd level dependancies anzeigen.

Aktuell werden abhängigkeinten aus den "defines" er einzelnen entites destiliert. Taucht ein devicename  im define einer entits auf ist das wohl eine Abhägigkeit. Also "define aaa myType bbb:ccc:ddd" => aaa hat abhängigkeinten zu bbb, ccc und ddd.
=> das ist schon etwas flach. Schon wenn man mit reg-exp arbeitet oder devspec tauchen extreme Lücken auf.

Btw: damit wird mir auch klar, warum Rudi darauf besteht, die eigentlichen Attribute eines Notify im define zu verarbeiten. Ausmeiner sicht ist und bleibt das ... sagen wir unsauber.

geht das besser? nun - klar geht das. Man muss nur stringent umsetzen, was es schon gibt. Bei Abhängigkeiten ist notify das perfekte Beispiel - und sollte (nach meinem Wusch) auch sinngemäß bei allen anderen modulen so umgesetzt werden:

Notify hat trigger und executes. Es kommen events von devices herein und es werden ggf andere devices angetriggerd (execute-section).
Die trigger-devices wären eigentlich einfach zu identifizieren. Egal ob in Kommandizeile oder per Attribut - es gibt immer einen "string" welcher die triggering-devices identifiziert. Dabei ist es wurscht on es ein devspec, eine liste oder eine regexp ist. Was zulässig ist wird in der Spec den Notify festgelegt.
=> nun ist es Aufgabe des notify alle devices zu identifizieren, welche in diese liste gehören - ZUR CONFIG-ZEIT!!! Notify wird sich dann für alle devices enrolen um trigger zu erhalten.
=> konsequenz ist, dass notify sich über config Änderngen informieren lässt, wenn notendig. Notify wird dann Anpassungen vornehmen und sich unrolen der enrolen.
=> es wird notwendig sein, sich beim Reboot erst nach dem init_done zu enrolen - vorher macht es keinen Sinn, da die Attribute fehlen.

Einst habe ich eine renovierung des notfy vorgeschlagen - diese habe ich bei mir realisiert (eine Frühe Versionsteht noch im Forum)

=> macht man es also richtig kann man probably associated  aus der Enrolement -Tabelle entnehmen. Und zwar KOMPETT! Aktuell wird das komplett ignoriert - schade.
=> das kann man alles einführen, ohne das User-interface zu verändern!

So nun habe wir die input-trigger komplett abgefrühstückt.
Bei den exeutes wird es schwerer. Der User kann hier wilde Dinge machen bis hin zu perl-code. Hier ist wird man also keine komplette Liste garantieren können. Man kann aber einiges erfassen:
wenn fhem-kommandos abgesetzt werden kann man die Empfänger tracken - und vermelden.
wenn diese spezifiziert sind kann man das ebenso.

Sonderfall. Lightscene - hier will man ggf eine 2. Stufe einbauen und erkennen, welche entites über light-scene getriggert werden.

So und nun - was will ich an Auswertung geliefert bekommen. Associated reicht mir natürlich nicht. In welcher Beziehung stehen die Entits?

Zu jeder Beziehung will ich den Typ wissen. Wie das aussehen soll habe ich noch nicht komplett durchdacht - und es gibt sowieso nicht nur eine korrekte Lösung.
So sehe ich folgende notwendigkeinten
My entity
- is triggered by (Bsp: notifies welche meine entity triggern, auch Scene welche es nutzen
- triggers (welche notifies lassen sich durch meine Readings triggern?)
- Trigger level (neuer Begriff). Wie oben schon erwähnt ist es die Pflicht einiger Entites sich übe config Änderungen informieren zu lassen. Das ist eine komplett andere Baustelle als Events und Readings auszuwerten. Somit muss ich unterschieden  zwischen triggers-config und triggers-event.
- direct-triggers und direct-triggered sind ebenfall Optionen. Bei CUL_HM und sicher auch bei anderen "familien" kann man devices direkt verknüpfen. Das will ich selbstredend auch dargestellt haben.
- display und logging würde ich in eine eigene Kategorie packen. Also fhemweb, dblog und filelog.
- Physikalische Beziehungen (kanäle eines devics)

So weit bin ich nun erst einmal. Selbstverständlich will man dann das ganze per get abrufen können. Systemweit wäre das ein Aufgabe für global. Auch in jedem Device kann man das abfragen.

Wofür das gut ist... sollte auf der Hand liegen. Will ich mein System pflegen und ein Device austauschen will ich wissen, was ich einst gemacht haben. Wer schaltet alles mein Licht an? Wo muss ich es berücksichtigen? Bin ich nach einem Rename noch aktuell? Was ist passiert - besser was ist Stand?

Ohne Disziplin beim Aufsetzen der  Module kann man das Ziel nicht erreichen (daher mein Abschied vom standard-notify - zu schlecht). Wenn man aber sich an die eigenen Ansätze hält wäre es gar nicht so komplex.
=> mein Wunsch ist also eine Beziehungsabelle mit der man arbeiten kann.
=> da ich schon bei notify und Freunden gescheitert bin werde ich mich bei Gelegenheit ans Werk machen, es selbst zu bauen. Unsaubere Module wir notify könne nicht berücksichtigt werden - daher nutze ich ausschließliche mein "ntf"

[martinp876]

Anbei mein erster Versuch zu impementieren / darzustellen was ich bei DBlog für den User erwarte. Also alles deutlich vereinfacht - weniger Attribute,... hatten wir schon.

in Myutils habe ich meine ersten Versuche realisiert, die Datenbank admistrieren zu können. Aktuell benötige ich 5 Kommandos (also setup/connect usw werden sowieso gebraucht)

Code Auswählen Erweitern

getDBfilter devices:({.*},<regexp>|devspec)[,(<regexp>|devspec)[,...]]
getDBStat devices:({.*},<regexp>|devspec)[,(<regexp>|devspec)[,...]] readings:[({.*}|<regexp>)[,<regexp>[,...]]] spawn:[{{m}|d|w|y)] spawnCnt:[{{12}|1..24)]
getDBinfo devices:({.*},<regexp>|devspec)[,(<regexp>|devspec)[,...]] readings:[({.*}|<regexp>)[,<regexp>[,...]]] lines:[({5}|<count>)] statistics:[({n}|y)])
getDBdelPrep devices:({.*},<regexp>|devspec)[,(<regexp>|devspec)[,...]] readings:[({.*}|<regexp>)[,<regexp>[,...]]]
getDBdelExe [({-}|confirm)]


Ich bin ein Freund der strickten Syntax-Beschreibung. De-facto werden ich die Kommandos nach der Beschreibung aus. Es läuft in meinen Module ein "commandParser" welcher prüft, ob die Syntax eingehalten ist. Die Liste der Kommandos ist als "get" abzurufen- der Anwender kann sich also auf den Inhalt verlassen, da es auch exakt so kodiert ist.
geprüft wird:
- Anzahl der Parameter min/max
- Wertebereiche (so definiert)
- default werte
- Optionslisten (wenn möglich) werden in die Kommandos eingepflegt.
In CUL_HM gibt es noch dynamische Parameterlisten automatisiert - das geht hier zu weit.
Syntax ist strict, also einfach zu lernen.
[]: optional
(.|.|.): Lite von werten (optionsliste)
<> : beschriebener wert -also undefinierter String
xx..yy: Wertebeireich
{}default wert (macht nur sinn, wenn der Parameter optional ist.
Das Schöne ist, bei der Kommandoauswertung sind alle Parameter gesetzt, auch die optionalen, welche weggelassen wurden. Und der Anwender sieht, was der Default ist.
=> für mich Userfreundliche
=> wäre cool, wenn so etwas eine Zentralfunktion ist. Es lässt sich ALLES! realisieren. mit "..." wird die Parameter-Zählung übersprungen.

Zu den Funktionen:
getDBfilter gibt mir eine Liste der Readings des Device welche geloggt werden, wenn ein Event generiert ist. Die Liste kann man nach Devices und Readings mit regexp filtern. Devices auch mit DevSpec. Ich habe geschlampt, da ich nur mit Include arbeite. Die systematisch Implementierung sollte über den real genutzten Filter geprüft werden.
=> praktische Überprüfung der Einstellungen, so ähnlich wie eine Simulation.

getDBinfo ist eine einfache Abfrage aus der Datenbank. Es sind keine SQL Kenntnisse notwendig. Die Abfrage ist optimiert auf Performance. Der Nutzen:
liste aller Readings eines Device (lines = 1) oder einer Gruppe von Devices
Liste der letzten x Readings (lines = x) oder events. Ich kann auf die Schnelle alle powerOn events abfragen - oder die letzten 3. einfach "getDbInfo .* powerOn 3"
Das kann ich mit den Tabelt am Sofa bedienen.

getDBStat gibt mir Auskunft über die nutzung der Datenbank. Mittelfristig sehr wichtig meine ich. Ich bekomme eine Tabelle der Events mit 2 bis 24 Spalten in welchen die Anzahl der Ereignisse gezählt sind. Ich bevorzuge monatlich.
Nutzen: Ich kann erkennen, ob die Anzahl der Readings zu meinen erwartungen oasst und für alle gleiche Readings ähnlich ist.
Ich kann erkennen, welche Readings unangemessen Daten erzeugen. (Bei Temp Messwerten werden ich mir etwas einfallen lassen, da 0,1Grad schicht nicht geloggt werden müssen)
=> hierzu weiter unten mehr

getDBdelPrep Vorgereitung zum Löschen von Readings aus der Datenbank. mit diesem Kommando werden alle Device/Reading paare identifizert, welche gelöscht werden sollen.
Da löschen eine Quittung verlangt muss ein getDBdelExe mit confirm folgen - sonst wird das Löschen abgesagt. Es wie aktuell über ein Attribut freizu schalten ist mir zu gefährlich!
Hier besteht noch optimierungsbedarf. Bspw "keep the latest xxx entries" oer "Lösche alles vor <datum>"

Performance:
Ich habe meinen Stand der Erkenntnisse eingepflegt. Wenn es jemand besser kann würde ich gerne lernen.
Das ganze geht nicht non-blocking - wobei ich forken ablehne. En Sub-prozess muss her - werde ich mir noch bauen.
Bei den Versuchen konnte ich Erkenntnisse gewinnen und meine Befürchtungen bestätigen, was es bedeutet und wie man vorgehen sollte. Viele Daten machen Auswertungen langsam (oh wunder) -also sollte man nsbesondere es dem "user"  einfach machen, daten zu sparen.
1) event on change reading .* löst etliche Probleme. Damit erübrigt sich auf das komische Interval-Zeug in den DB-filtern.
1a) mit Event-on-change-reading .* kann es zu Problemen in der Grafik kommen. Lässt sich lösen. Einfach einen Wert um 23:59 und um 00:01 erzwingen. Funktioniert be mir wunderbar. das sind im Jahr 720 Werte je Device/Reading  welche es benötigen. Zur Gegenrechnung: ein CUL_HM Thermostat schickt alle 3min denn Staus, gemessene temp, desired-tem, valvePos und sonst noch etwas. Zusammen sind das in der  Stunde 60 Werte, im Jahr 175200 Werte je Reading. Und die meisten bleiben gleich.
=> schafft Wege und erklärt dem Anwender wie es sein System sinnvoll einrichtet.

Ich gehe beim Anwender(admin) davon aus, dass er listen erzeugen kann. Regexp (einfache) können auch noch viele. Und zum Schluss devspec - die gehobenen Klasse der FHEM Anwender.
FEHM Nerds können die Kommandos auch nutzen - und hätten weiterhin den Zugriff auf volle SQL-Kommandos. Und wenn ihnen die Datenflut gefällt können sie das steuern. Nerds machen, was sie wollen - dürfen sie ja auch.

[martinp876]

habe mich etwas tiefer mit dbLog beschäfftigt und werde es nun endlich für meine Anwendung nutzbar zu machen.
1) es gibt einige Details mehr zu beachten, also ich anfänglich vor hatte
2) technisch habe ich keine Probleme mit den beiden Modulen!!! Ich haben  nicht hineingeschaut - aber das habe ich auch nicht vor.
3) was probleme hervorruft ist die Performance. Damit sollte man einen User nicht alleine lassen. Dazu also meine heutigen Einlassungen

Performance: hier sind 2 Facetten zu betrachten
a) non-blocking. Das ist primär. Kommandos können hier sehr schnell lange dauern. ein Sub-prozess wäre also sinnvoll.
aa) es ist en timeout eingebaut, welcher fhem wieder frei gibt. das sind per default 100s. Wer will 100s auf das schalten eines Lichts warten, weil jemand einen DB-job gestartet hat? Das muss besser werden... also alles auslagern
ab) wenn dblog abbricht wird der Datenbank-prozess nicht gestoppt. Die CP wird also weiter belastet, die Datenbank sowieso. Bei Veränderungen, also delete/update wird die Datenbank weiter verändert - im Hintergrund. Dabei hat der User "abbruch" signalisiert bekommen
b) Die CPU Performance ist natürlich auch ein Problem. Mein System ist faktisch stehen geblieben... keine Lichter meher schaltbar,... ein no-go.


Wie bekommt man das system schneller? nun, erst einmal weniger Daten loggen. Das ist primär!. Das sollte man dem Anwender klar machen und eine einfache prozedur festlegen, wie er es erreichen kann. Man kann viel des nachfolgenden in DBlog erledigen - ich plädiere aber auf System-vorhandene Einstellungen. Man muss nicht alles doppelt machen.

I) event-on-change-reading .*
das sollte man immer (IMMER) einbauen. Das erübrigt dann auch die aufräum-kommandos in dbrep (duplicates). das in dbrep vorhandene Kommando macht eh nicht was ich brauche. Der Reihe nach
Ia) nur Änderungen loggen und notifizieren ist immer das mittel der Wahl. Man kann alles lösen, was jemand hier anführen wird. Die Datenflut rechtfertigt es in keinem Fall
Ib) typisches Problem ist die Grafik. Bei statschen Werten fehlt oft der Start-wert - oder Endwert. Das sieht hässlich aus. Nun, das ist lösbar. Grafiken beginnen in unseren Fällen immer an GANZEN TAGEN. Also schreibe ich per Notify um Mitternacht immer die kritischen Werte für 23:59 und 00:01 in die Datanbank. Das ist notwendig für sehr langsame Werte - also Wunsch-temp. gemessene temp ändert sich sowieso
Ic) das Implementerte entfernen von Duplikaten hilft mir also nicht, da der letzte Wert behalten wird (braucht niemand) aber an den tagenGrenzen nichts zu finden ist.
II) schnell ändernde Werte
gemessene Temperatur ändert sich ständig. 0,1° kann ich aber sowieso nicht darstellen. Ich generiere also einen geglätteten Wert. Der zu loggenden Messwert wird nur geändert, wenn er min 0,3° abweicht. Zusammen mit "Event-on-change-readings" reduziert sich ein Log gigantisch!

Die Aufgabe ist also, methoden zu generieren, mit denen der Anwender einfach eine schlanke Datenbank betreiben kann - mit Werten die er braucht und keine, welche nur Balast sind.

Ich brüte noch darüber - vielleicht hat jemand eine gute Idee.
Der Nerd in mir baut natürlich etwas lokal auf - ich komme vorran... dem User will ich so etwas nicht zumuten. Das Aufräumen der Datenbank ist ätzend - auch mit etwas tieferem Wissen

==> das Anzeigen von Grafiken ist schlicht zu langsam. Jahres-ansichten sind eine Katastrophe.

[martinp876]

heute eine Einlassung zu Datenhygiene. Wie kann man - für  normal-User  - die geloggten Daten sinnvoll gestalten. Wie kann ein User dies in den Griff bekommen.
Meine Datenbank ist - da ich sie einfach habe laufen lassen (so solll es m.E. sein) auf über 2 GB angewachsen. Grundsätzlich hatte ich schon einiges eingeschränkt - was nicht unbedingt selbstverständlich ist.
Grundsätzlich sollte geloggt werden zum Zwecke der späteren Auswertung. Grafiken oder manuelle Auswertungen in Sonderfällen.
Viele Daten bedeuten lange Auswertungen. Die Datenbank hat ein eigenleben und verbraucht erheblich CPU im Hintergrund - was am Ende das Ganze System verlangsamt. Ein Nerd wird sich dessen annehmen - aber eigentlich sollte es mehr plug&play bieten.

Nun - zu betrachten ist
Breite: Welche Readings sollen geloggt werden
Tiefe: Wie lang sollen Daten gespeichert werden
Höhe: welche Werte eines Readings sollen abgelegt werden.

Breite:
Dieser Teil ist schwierig. Der User muss entschieden, as er will. Dennoch kann die Datenbank applikation unterstützen in dem sie den User zeigt, was er eingestellt hat. (mein voriges Beispiel "simFilter". Halte ich für zwingend und längst überfällig. Zum 2. wäre eine Systematik hilfreich - d.h. alle meine HK Thermstate sollten gleich sein. Ein neues sollte automatisch mit den Filtern versehen werden. Ist aber nicht einfach - eine gute Idee ist gefragt, um es EINFACH für den User zu implementieren.

Tiefe:
das ist einfach. Man kann die Zeit begrenzen und die Datenbank löscht Einträge älter als XXXX . Das wird regelmäßig geprüft. ggf kann die Grenze die Filegröße  als Maßzahl nehmen.
Ich denke 2 -3 Jahre werde ich bei mir einstellen. Muss ich wohl extern machen.

Höhe:
Das ist nun der wirklich interessante Teil - hier kann man einiges machen und erreichen!!.
a) keine Doppelten Werte
event-on-change-reading ist das stichwort. Doppelte Werte sind definitiv nicht notwendig und eines sinnvollen Systems nicht würdig. Es gibt hier aus meiner Sicht eine Fussangel: Grafiken. die Linien beginnen erst mit dem ersten Wert im Zeitraum und enden mit dem Letzten. Das wäre einfach lösbar - wenn man nur will. Wir dein Zeitraum 1.1.2022 - 31.1.2022 dargestellt muss die Datenbank den letzten Wertvor 1.1.2022 automatisch zur Werteliste addieren. Für den Endwert ist der letzte Wert bis ans Ende oder zum aktuellen Datum verlängern.
=> Die Abfrage ist ziemlich einfach - kann sogar ich selbst erstellen (habe es schon)

b) jitter entfernen.
Bei Messwerten jittert der Wert gerne um die Auflösung - also um die letzte dargestellte Stelle. Bei Temperaturen beobachte ich das regelmäßig - und für eine Grafische Dastellung , auch über lange Zeiträume - brauche ich keine 0.1°. +-0,2° sind schon viel besser - mir reichen sogar -+0,4°. Ein Smoother ist also sinnvoll.
Ich habe hierzu ein notify gebaut welches das erledigt und Readings mit "S" postfix addiert. geloggt werden dann sind weichgezeichneten.
=> die Auswertungen sind bei mir am Start - be Bedarf könnte ich helfen.

Ich halte es für ein unding, dass ein user sich um solche Dinge kümmern muss um ein effizientes System an den Start zu bekommen. daher hier dieser Post.

Ich werden wohl wieder alles selbst bauen (habe das meiste...). Wirklich hilfreich wäre der Grafik-extender welche die angefragten Messewerte am Anfang und Ende des Zeitraums "verlängert". Wenn das nicht eingebaut wird werde ich es wohl auch selbst machen.
=> Wer erwartet, dass ein normal-user so etwas auf die Reihe bekommt - oder die Muse und Zeit investiert? Daher siehe ich FHEM als ein Nerd-System. Alles machbar - man muss es aber selbst tun.

[CoolTux]

Hallo Martin,

Deine Arbeit, hier bei den Anmerkungen, aber auch Deine eigenen Entwicklungen welche Du in fremde Module investierst sind hilfreich und sicherlich sinnvoll für andere Entwickler. Auf jeden Fall für den Modulautor dessen Modul Du erweiterst.

Was spricht dagegen Deine Erweiterungen welche Du machst dem Modulauthor per Patch zu kommen zu lassen?
Ansonsten empfinde ich die meisten Deiner Anmerkungen hier als wirklich Hilfreich und man merkt das Du Dir hier echt Gedanken gemacht hast. Über einen längeren Zeitraum.

Grüße

[Beta-User]

Nur mal kurz:
- "Weichzeichnen" kann man auch mit passenden Einstellungen für "event-on-change-reading", dazu braucht man nichts doppeln (mAn. ist Doppelung genau der falsche Weg!).
- Start- und Endwerte (außerhalb des eigentlichen Zeitrahmens bekannte Reading-Werte) für SVG kann logProxy bereitstellen
- "Muster" für "kopierwillige User" könnte u.a. auch "archetype" bereitstellen (das ist ähnlich (!) wie deine m.E. überkomplexe "post-init"-config!) (Es gibt dazu einen support-Thread, da findest du auch ein Beispiel für CUL_HM-Heizungs-Geräte, das hilft dir vielleicht zu verstehen, was es tut)

Das sind alles eher (aus Einsteigersicht) "unerklärte" Ansätze für den jeweiligen Anwendungsfall, also "nerd-typisch". Vielleicht sollte man checken, ob die Ansätze "richtig" sind, und wenn ja kann man  versuchen,
a) das "userfreundlicher" zu erklären bzw. die Leute erst mal dahin führen, dass sie es "einfach machen" (ähnlich wie attrTemplate bei MQTT2_DEVICE), und
b) die tools ggf. zu verbessern bzw. die damit gezeigten "Musterlösungen".

Alles "auf den Kopf" stellen zu wollen (und sich (mit DBLog, mehr oder weniger) genau ein Modul rauszupicken (!)) ist m.E. in der Entwicklergemeinde eher nicht vermittelbar.

Just my2ct.

Ansonsten empfinde ich die meisten Deiner Anmerkungen hier als wirklich Hilfreich und man merkt das Du Dir hier echt Gedanken gemacht hast. Über einen längeren Zeitraum.

Dem kann ich im Übrigen nur zustimmen!
Meine Anmerkung möge bitte nicht als "geht nicht"-Kritik verstanden sein, es geht eher um den Weg...

[martinp876]

Hi,
danke für das feedback.
CoolTux
1) ich lasse das immer dem Moderator zu kommen. Ich wollte shon viel weiter sein - werde aber jetzt doch erst meine Installation zu DBLog auf einen Stand bringen, welcher m.E. sinnvoll ist. Hierbei werde ich mir Werkzeuge Entwickeln ( wohl ein muDbMgmt (my Utility Database management - Modul) welches dann ein Frontend für User bietet - so wie ich es mir vorstellen. Das ist m.E. der beste Weg, dem Entwickler darzulegen, was ich meine. Ich komme bei DBlog von einem Detail zum nächsten. Am Ende muss es aber ein Gesamtkomzept geben - möglichst einfach und gleichförmig. Das Konzept ist klar, die Umsetzung dauert.

Beta-User
1) mir nicht klar, wie ich mit event-on-change-readings "weichzeichnen" kann. Doppelt ist klar der falsche Weg (daher biete ich meine Anpassungen nur an und veröffentliche keine Konkurenz-Module). Event-on-change-reading .* ist und bleibt für mich das A und O einer Datenerfassung. ALLES, was damit nicht geht ist einfach schlecht implementiert - m.E. Bastelwerk. Harte Aussage, ok. Bei mir geht es.
=> Wie kann ich mit Event-on-change-readings nur dann Events erzeugen, wenn sich die Temperatur um +-0,3° ändert? Tip würde mich interessieren.
=> mein Weichzeichnen ist ein level mehr zu event-on-change-readings.* . Wenn ich erst einmal optimiere, dann möglichst umfassend.
2) Start und Ende... wie geht das?
Die Aufgabe ist: meine desired-temp ändert sich um 7:00, 15:00, 20:00. In der 2-Tage Grafik beginnt die Linie also nicht um 00:00:00 sondern um 07:00:00. Sie endet um 20:00, nicht um 22:31 wenn ich den Graphen ansehe.
Den letzten Wert vor dem Darstellungszeitraum kann die Datenbank easy zu verfügung stellen. Ich haben die Anpassung schon vorbereitet. Die estrapulation auf das Ende es Darstellungszeitraums man auch einfach machen - das kann die DB oder auch SVG. Ich würdas das extrapulieren der Werte ich beide Richtungen an einer Stelle machen - also in der DB. Da ist dann konsequent
=> welche Lösung gibt es schon jetzt?
So erhalte ich den letzten Wert vor Zeitraum aus der DB

Code Auswählen Erweitern

(SELECT DATE_FORMAT(TIMESTAMP, '%Y-%m-%d %H:%i:%s'), DEVICE, READING, VALUE FROM history WHERE 1=1
                               AND DEVICE = 'haLnge_Clima'
                               AND READING = 'measured-tempS'
                               AND TIMESTAMP < STR_TO_DATE('2022-11-11 00:00:00', '%Y-%m-%d %H:%i:%s')
                               ORDER BY TIMESTAMP DESC
                               limit 1)
union
(SELECT DATE_FORMAT(TIMESTAMP, '%Y-%m-%d %H:%i:%s'), DEVICE, READING, VALUE FROM history WHERE 1=1
                               AND DEVICE = 'haLnge_Clima'
                               AND READING = 'measured-tempS'
                               AND TIMESTAMP >= STR_TO_DATE('2022-11-11 00:00:00', '%Y-%m-%d %H:%i:%s')
                               AND TIMESTAMP <= STR_TO_DATE('2022-11-13 00:00:00', '%Y-%m-%d %H:%i:%s')
                               ORDER BY TIMESTAMP);

Ich würde die Auswirkungen noch testen und ggf den Timestamp frisieren - auch für den Endwert.

3) meine Einlassungen hier sind für Entwickler, nachzudenken, on sie uerfreundlich oder für Nerds das Frontend gestalten. Ich versuche es anhand von Beispielen darzustellen - und mein Weg ist definitiv nicht der einzige. Nur ist das Angebotene in manchen Fällen einfach nicht das, was ich mir erwarte. Und ganz klar - manche sind super!!!

Zu DBlog und meinen Recherchen. Eigentlich wollte ich nicht so tief eintauchen...
Ich prüfe gerade meine Einstellungen und haben geprüft, was so geloggt wird. Hierzu einmal verbose 5 gesetzt.
=> DBlog lässt sich tatsächlich über alle Events informieren. Das sollte dringend abgeschaltet werden. Ok, es ist bei mir so, dass ich die Kriese bekomme wenn ich so etwas sehe.
Ich habe SelectionModemode "include" eingestellt. Zuerst Text im Commandref könnte üerarbeitet werden.

Exclude: DbLog behaves just as usual. This means everything specified in the regex in DEF will be logged by default and anything excluded via the DbLogExclude attribute will not be logged
Include: Nothing will be logged, except the readings specified via regex in the DbLogInclude attribute (in source devices). Neither the Regex set in DEF will be considered nor the device name of the source device itself.
Exclude/Include: Just almost the same as Exclude, but if the reading matches the DbLogExclude attribute, then it will further be checked against the regex in DbLogInclude whicht may possibly re-include the already excluded reading.

"DbLog behaves just as usual. " ist eine coole Aussage - sagt mir nix.

Code Auswählen Erweitern

Exclude: logs any reading except if excluded by DbLogExclude. DbLogInclude is ignored
(DbLog Include sollte dann aber gleich aus der Liste verschwinden!)

Code Auswählen Erweitern

Include: logs nothing except if included DbLogInclude. DbLogExclude is ignored
(DbLog Exclude sollte dann aber gleich aus der Liste verschwinden!)

Code Auswählen Erweitern

Exclude/Include: logs any reading except if excluded by DbLogExclude. The exclude can be oderruled by DBinclude
macht dieser Mode Sinn? na meinet wegen.

Aber nun zur Performance.
Ich habe "selectionMode" include gewählt - m.E. das was einfach zu verstehen ist. In meiner Anwendung gäbe es nichts anderes. Der User kann mit "attr .* DBinclude .*"fix alles einschalten.
Ich erwarte schlicht von einem guten Modul, dass es sich nun bei Notify überall einhängt, bei welchen das Attribut DBinclude gesetzt ist. Alle notifies anderer Devices werden ignoriert.
Das Bedarf natürlich, dass man code investiert. Man muss sich an "global" hängen und bei Define/delete/rename/defmod aktiv werden genauso wie beim setzen des Attribut DBloginclude.
Wie das geht habe ich in meiner Variante des Notify durchexerziert. It machbar, kostet etwas Hirnschmalz, etwas performance bei Init und ein wenig bei Konfig (attr change). Operational ist es dann ein Gewinn!

Im Exclude mode gilt das gleiche - hier klammere ich alle Devices aus, welche ich nicht loggen will. Exclude ist m.E. ... wie soll ich ses freundlich sagen ... quatsch? alles zu loggen ist Aufgabe der NSA. Nun ja, aber nun sollte ich wenigstens eine Methode haben, ein device auszuklammern. also "DBexclude .*"

Allein schon, wenn ich mir hier überlege, wie ich einem Anwender klar machen will, wie er  den einen Mode gegen den anderen Bewerten muss komme ich zum Schluss " zu kompliziert".

Mein Vorschlag zum Frontend zu diesem Detail: Weniger ist mehr

a) selection mode ist immer include  ein Attribut braucht es nicht mehr
b) DbLogExclude braucht es nicht mehr
c) DbLogInclude wird genutzt. Will ich alles loggen mache ich ein .* - das sollte einem Anwender klar zu machen sein - man sollte davon abraten
Exclude kann man einfach mit !(temperature|status) realiseiren - sollte kein Problem sein.
includeExclude lässt sich auch machen - hier bräuchte ich eine Idee, warum ich so etwas machen soll. Dann kann ich einen Vorschlag machen evtl !(exclude1|!excude2)||(include1|include2)

[DS_Starter]

Guten Morgen,

ich möchte ein grundsätzliches Statement zur allgemeinen Kenntnisnahme abgeben.
Ich werde auf _keinen_ Fall Änderungen im DbLog übernehmen die zu dem bisherigen Verhalten inkompatibel sind und das Setting beim User auf den Kopf stellen.
Dann kommt nämlich das heraus was wir bei Homematic hatten ... monatelangen Stress mit Fehlern die zumindest bei mir dazu geführt haben dass ich das/die Module vom Update ausgeschlossen habe. Das wird es bei DbLog nicht geben !
Ich möchte das nur klargestellt haben, damit es nicht irgendwann Diskussionen deswegen gibt.

Was aber herauskommen kann ist ein Nachfolger für DbLog zu entwerfen; was ich schon lange vorhatte (DbLogNG); welcher bestimmte Unzulänglichkeiten des bisherigen Moduls beseitigt (z.B. BlockingCall). Hier wäre auch Augenmerk darauf zu richten den SVG Editor voll nutzbar zu machen (Stichwort Erhalt erstellter Codes im plot-File).

Und Martin ... der Hinweis ist nicht despektierlich gemeint .... denke bitte daran dass du nicht der Nabel der Welt bist.
Wenn du der Meinung bist etwas so und nicht anders zu brauchen oder im Umkehrschluss etwas nicht als benötigt ansiehst heißt es noch lange nicht dass andere User diese Meinung teilen.

Just my2ct.

[Beta-User]

Beta-User
1) mir nicht klar, wie ich mit event-on-change-readings "weichzeichnen" kann. Doppelt ist klar der falsche Weg (daher biete ich meine Anpassungen nur an und veröffentliche keine Konkurenz-Module). Event-on-change-reading .* ist und bleibt für mich das A und O einer Datenerfassung. ALLES, was damit nicht geht ist einfach schlecht implementiert - m.E. Bastelwerk. Harte Aussage, ok. Bei mir geht es.
=> Wie kann ich mit Event-on-change-readings nur dann Events erzeugen, wenn sich die Temperatur um +-0,3° ändert? Tip würde mich interessieren.
=> mein Weichzeichnen ist ein level mehr zu event-on-change-readings.* . Wenn ich erst einmal optimiere, dann möglichst umfassend.

Ich teile nach wie vor NICHT die Meinung, dass "event-on-change-reading .*" eine allumfassend (!) gute Lösung ist. Das Attribut kennt nämlich bereits einen threshold...
Und man kann das wunderbar ergänzen mit "min-interval", was du wüßtest, wenn du den Thread zu archetype 2022 gelesen hättest. Hier also mal Klartext dazu:

Code Auswählen Erweitern

defmod Thermostat_EssZi_Climate CUL_HM 2642E802
attr Thermostat_EssZi_Climate devStateIcon {devStateIcon_Clima($name)}
attr Thermostat_EssZi_Climate event-min-interval measured-temp:900,desired-temp:1800,humidity:1800
attr Thermostat_EssZi_Climate event-on-change-reading measured-temp:0.2,.*
attr Thermostat_EssZi_Climate genericDeviceType thermostat
attr Thermostat_EssZi_Climate group Heizung
attr Thermostat_EssZi_Climate icon hm-tc-it-wm-w-eu
attr Thermostat_EssZi_Climate model HM-TC-IT-WM-W-EU
attr Thermostat_EssZi_Climate peerIDs 00000000,2E7A0802,2E7BA002
attr Thermostat_EssZi_Climate rhasspySpecials priority:inRoom=desired-temp,temperature,humidity
attr Thermostat_EssZi_Climate room Esszimmer,Steuerung->Heizung
attr Thermostat_EssZi_Climate sortby 1
attr Thermostat_EssZi_Climate tempListTmpl none
attr Thermostat_EssZi_Climate webCmd desired-temp
attr Thermostat_EssZi_Climate widgetOverride desired-temp:knob,min:4.5,max:31.5,angleArc:180,width:40,height:40,fgColor:#FF9900,bgColor:#CCCCCC,step:0.5,lineCap:round,angleOffset:225
Wie man das DIREKT beim Anlegen des Devices automatisiert als Attributsatz bekommt? Link zum Beitrag im archetype-Thread: https://forum.fhem.de/index.php/topic,125930.msg1209967.html#msg1209967

2) Start und Ende... wie geht das?
Die Aufgabe ist: meine desired-temp ändert sich um 7:00, 15:00, 20:00. In der 2-Tage Grafik beginnt die Linie also nicht um 00:00:00 sondern um 07:00:00. Sie endet um 20:00, nicht um 22:31 wenn ich den Graphen ansehe.

https://wiki.fhem.de/wiki/LogProxy#Erweitern_des_zu_plottenden_Bereichs_um_ausserhalb_liegende_Anfangs-_und_Endwerte

[Beta-User]

Ich werde auf _keinen_ Fall Änderungen im DbLog übernehmen die zu dem bisherigen Verhalten inkompatibel sind und das Setting beim User auf den Kopf stellen.

Dem kann ich nur zustimmen!

Nach meiner bisherigen Erfahrung (ich gehöre zu den wenigen Maintainern, die auch mal was ausgephast oder Module radikal umgebaut haben), sind es übrigens in der Regel NICHT die nerds, die mit derartigen Veränderungen ihre Probleme haben, sondern eher die "Gelegenheits-User", die alle paar Jahre mal ein update machen und dann Fehlermeldungen entweder schon gar nicht erst finden oder selbst einfache (im Sinne von "häufigen") Meldungen im Log  nicht interpretieren können und dann darauf bestehen, dass alles bleibt, wie es ist...

(Bestes Beispiel in diesem Thread hier ist der "Anlass" für Doppelung von Funktionen in DBLog und DbRep).

[enno]

Moin zusammen,

ich melde mich mal als User. Die Idee etwas zu verbessern halte ich für eine Gute Idee. Aber ich möchte die Aussage von DS_Starter unterstreichen!

Ich werde auf _keinen_ Fall Änderungen im DbLog übernehmen die zu dem bisherigen Verhalten inkompatibel sind und das Setting beim User auf den Kopf stellen.
Dann kommt nämlich das heraus was wir bei Homematic hatten ... monatelangen Stress mit Fehlern die zumindest bei mir dazu geführt haben dass ich das/die Module vom Update ausgeschlossen habe. Das wird es bei DbLog nicht geben !

Mich hat die Änderung bei Homematic ziemlich heftig getroffen. Das Modul ist eines der wichtigsten in meiner FHEM Installation. Nach der Erfahrung wie geändert wurde, steht es  bei mir immer noch auf  "exclude" und ich mache das Update immer erst mehrere Tage später um im Forum zu erkennen, ob es unerwünschte Nebenwirkungen hat.

Damit ziehe ich mich wieder raus und lese weiter interessiert mit.

Gruss
  Enno

[martinp876]

@DS_Starter:

Ich werde auf _keinen_ Fall Änderungen im DbLog übernehmen die zu dem bisherigen Verhalten inkompatibel sind und das Setting beim User auf den Kopf stellen.

das habe ich erwartet, ist die übliche Reaktion und endet meist damit, dass ich die Anwendung an meine Bedürfnisse selbst anpasse.

Was aber herauskommen kann ist ein Nachfolger für DbLog zu entwerfen

das hatte ich betreits vorgeschlagen - wäere mir lieber!

Und Martin ... der Hinweis ist nicht despektierlich gemeint .... denke bitte daran dass du nicht der Nabel der Welt bist.

da hast du recht. Dennoch werde ich meine Meinung kund tun - sonst hatte ich gleich schweigen müssen. Das, was ich hier mache ist ein Diskusionsbeitrag. Es gibt immer (ich hatte es, denke ich mehrfach erwähnt) mehrere Wege zum Ziel.

Ich teile nach wie vor NICHT die Meinung, dass "event-on-change-reading .*" .... mit "min-interval",

hier werden wir nicht zusammen kommen. So gut wie alle Automation systeme sind "edge-triggered". "level triggered" ist  nur selten notwendig. Wäre schön, wenn ich einmal eine Anwendung sehen könnte, bei der es nicht möglich ist.
Für min-interval sehe ich keine Anwendung.
a) mit event-on-change-reading kann es genutzt werden um doppelte Meldungen des gleichen Ereignisses abzufangen (bei Homematic wenn ein Ack und dann ein Status kommt, welche beide das gleiche Reading setzen, kann man eines unterdrücken)
b) ohne event-on-change-reading fehlt mir die Fantasie. Da werden ggf Anderungen weggefiltert... Die Anwendung kenne ich nicht.
c) zu Trigger werde ich noch einen eigenen Post erstellen - das läuft aktuell nicht so wie ich mir das vorstellen

Danke für den Link zur extrapulation der Readings. Werde ich mir noch ansehen.

ah, 2. Einwad zu Änderungen. Aber ich hatte doch eh schon vorgeschlagen, ein "lean-Logging" modul zu bauen - habt ihr das übersehen? Aus meiner Sicht kann das aktuelle nicht nach "lean" umgebaut werden. Das ist alles viel zu verzettelt... da muss man (die Meinung vom Nabel so viel anpassen, dass ein merge nicht möglich ist.

Oh - noch ein 3. Verängstigter.  Muss ich noch einmal antworten
1) ich werde nichts an dem Modul ändern - wie auch. Stand nie zur Diskussion
2) ich stelle hier da, was mir am Modul nicht gefällt. Ich die MEINUNG vom Nabel. Kann(SOLLTE) diskutiert werden und um andere Meinungen angereichert werden.
3) die Betrachtung bewertet das Modul explizit OHNE die angabe, ob und wie es implementiert wird/werden könnte/werden sollte/werden KANN. Mir ist bei der Betrachtung explizit EGAL ob es einen update geben kann. All das schränkt die freie Sicht ein. Die Frage ist: Wie sollte(könnte) ein DbLog aussehen - mit der Erfahrung aus der aktuellen Implementierung.
4) Ob, wie und wer es dann realisiert diskutiere ich hier und jetzt doch garnicht.

Einen Umbau des aktullen Moduls halte ich (ich wiederhole mich zum x-ten mal) für nicht machbar.
I) wenn ein neues Modul gebaut wird, werde ich es mir ansehen
2) wie das neuen Modul funktionieren könnte kann (auch hier) erarbeitet werden
3) erst einmal feasibility, dann requirements, dann implementieren.

==> ich experimentiere gerade mit einem Add-on Modul welches unter Nutzung von DbLog und DbRef ein für mich sinnvolles Userinterface zu Verfügung stellt. Ich denke ich kann in kürze einen unausgereiften Prototypen vorstellen. ACHTUNG: mein Modul ist als Experiment gedacht.  Es ist die schlechteste Lösung und wird NIE in FHEM Einzug halten. Ich sammle damit Erfahrungen. Ihr werdet sehen, wenn ihr interesse habt.

###########################################################
eigentlich wollte ich heute zum Thema Performance das Logging ansprechen.
Mir ist seit Jahren (also Performance Spinner) unwohl bei der Art, wie in FHEM debug-logs gehändelt werden. Typisch ist ein

Code Auswählen Erweitern

Log3 ($name, 4, "DbLog $name -> DbLogType is: $DbLogType");
Sicher wissen alle Programmierer, was hier passiert:
a) der Log-string wird generiert
b) die 3 Argumente werden als call-by-value in den Stack der subroutine "Log3" kopiert
c) in Log3  prüft name, errechnet den Loglevel, vergleicht den Loglevel und entscheidet über das Printen
d) der Text wird geloggt (wenn Bedingung erfüllt ist).

Wird der Text geloggt ist das alles ok. Die meisten Logs allerdings werden nicht gedruckt. Hier wird dennoch der Text "errechnet" und kopiert.
I) es sollte erst geprüft werden, ob wir loggen wollen, dann wird der String errechnet
II) ein call by reference macht deutlich mehr Sinn
=> im Code sieht es dann nicht mehr so cool aus... schade. Aber es werden nicht kontinuierlich sinnlose Dinge errechnet und kopiert.

Code Auswählen Erweitern

LogMe($name,,$loglevel,\"hallo $a") if(LogLvl($name,$loglevel))
wäre mein Voschlag. Dann würde ich mich deutlich wohler fühlen und mehr Logs einbauen - zum Debuggen.
Ich denke ich muss in dieem Kreis nicht erklären: "LogLvl" prüft, ob gedruckt werden soll, LogMe druck dann - wobei der String nur errechnet wird, wenn eine Druckzusage erteile wurde. Ausserdem wird nicht der String sondern die Adresse kopiert.

Programmierer sollten dennoch mit den Logs haushalten. Wenn ich code finde wie:

Code Auswählen Erweitern

  if($memcount && $dolog && !$hash->{HELPER}{".RUNNING_PID"}) {     
      Log3 ($name, 4, "DbLog $name -> ################################################################");
      Log3 ($name, 4, "DbLog $name -> ###      New database processing cycle - asynchronous        ###");
      Log3 ($name, 4, "DbLog $name -> ################################################################");
      Log3 ($name, 4, "DbLog $name -> MemCache contains $memcount entries to process");
      Log3 ($name, 4, "DbLog $name -> DbLogType is: $DbLogType");

löst es bei mir komplettes unverständnis aus - insbesondere in einer notify-routine

Code Auswählen Erweitern

  if($vb4show && !$hash->{HELPER}{".RUNNING_PID"}) {
      Log3 $name, 4, "DbLog $name -> ################################################################";
      Log3 $name, 4, "DbLog $name -> ###              start of new Logcycle                       ###";
      Log3 $name, 4, "DbLog $name -> ################################################################";
      Log3 $name, 4, "DbLog $name -> number of events received: $max of device: $dev_name";
  }


A) warum der Log so wichtig ist, dass es 3 Zeilen Header rechtfertigt ist mir unklar. Wennd das jeder Module-owner so sieht wird das log ausch schnell voll.
B) mir vollkommen unklar, wie man 4 mal bedingungslos die gleiche Routine aufrufen kann, wo man es doch in einem einzigen Aufruf erledigen kann. In einer doch recht stark frequentierten notify-routine
=> Das ist noch einmal ein ganz anderer level. Wenn so codiert wird kann ich mir ersparen, mir über Performance Gedanken zu machen.

[martinp876]

das 2. Performance Thema für mich heute sind Notification.
Bei meinen DB Untersuchungen haben ich mich wieder einmal und noch etwas genauer mit notifies befasst. Insbesondere mit dem Hintergrund, die Einträge in die LogDb auf ein sinnvolles mass zu reduzieren. Das erhöht die Performance an mehr als ener Stelle!

Der Status ist (so wie ich es aktuell kenne)
- faktisch alle Readings sollten vom Programm heraus trigger aufrufen. Der User geht typisch davon aus und als Codierer will ich das nicht vorschreiben. De-facto mache ich bei CUL_HM ausnahmen bei "Register-daten". Alles andere ist "Trigger-fähig"
- Wer event-on-update-reading liebt soll es nutzen - mache ich ggf zu debug zwecken - ist hilfreiche. Ich werde immer (und mir muss hier keiner folgen!) propagieren, dass event-on-change-reading .* genutzt wird. Das reduziert die CPU Last erheblich.
- Rudi hat nun schon geraume Zeit implementiert, dass  notfications von Trigger-Devices nur an enroled Processing-Devices gehen. Nicht ganz korrekt: un-enroled Processing-Devices werden automatisch überall enrolled.  Diesen unsauberen Fall betrachte ich hier nicht - das ist schlamperei und sollte korrigiert werden.
- Das filtern von Readings ist vom Processing-device vorznehmen.

Nun ist es faktisch so (ich bringe noch 2 Beispiele) dann die Notifikation bei jeder Änderung IRGENDEINES Readings stattfindet.
Beispiel:
ein CUL_HM RT liefert temperaturwerte auf Kanal 1 und 4. Weiter wird die Temperatur von einem möglichen TC auch noch gemeldet.
=> alle 3 Minuten erhalte ich einen Temperatur-wert - mehrfach den gleichen.
=> loggen muss ich den nur einmal -  es wird nicht wärmer oder kälter durch mehrfaches schreiben - nur langsamer.
=> Bei Temperaturmessungen schwankt der Messwert um 0.1° - was in der Auswertung und einer Grafik irrelevant ist. Für meinen Fall reicht es, bei Änderungen von +-0.3° zu loggen

also baue ich ein user-reading (ich hatte ein notif - viel cooler. Allerdings macht das noch mehr stress - also abgeschafft) welches ein "meas-tempS" für "smooth" erstellt. Schnell geschrieben.
==> ich logge also nur nioch meas-tempS, das Log ist geschmeidiger, die Grafiken deutlich schneller.
Was ich als User aber nicht abstellen kann ist, dass jede Änderung von meas-temp einen Trigger auslöst und alles geprüft werden muss. Na wenigstens identische Werte erzeugen keine Last

Auch event-min-interval gibt keine Hilfe hier. Entweder werden potentielle Änderungen unterdrückt oder es werden doch alle Änderungen processed.

Ich überlege, wie ich als User das  Auslösen eines Triggers durch bestimmte Readings unterdrücken kann.
Zum einen ärgern mich die RTs/TCs - das sind einige - vorhersehbarer unnötiger Verkehr.
Weiter habe ich einen Power-sensor welcher kontinuierlich eine Änderung in der Leistung sieht und tatsächlich alle paar Sekunden einen Trigger schicke für den es überhaupt keinen Empfänger gibt.

Sollte es ein attribut "no-Event-for-reading" geben stellt sich die Frage, wie man das user-geeignet befüllen kann. Bei der Datenbank könnte ich mir eine Auswertung über DBinclude vorstellen. Bei notifies kann es etwas ähnliches geben.

Eine Professionelle  SW hatte einen Mechanismus, wie sich en Device bei einem anderen für gewisse Readings enrolled. Kein Enrolement, kein Trigger .

Für mein System nähere ich mich einer Lösung, das system wirklich nutzbar zu machen. DerAnspruch hier ist aber: Wie kann man das automatich schaffen.

p.s. Auf die Anwendungen, warum man Event-on-update-reading brauche bin ich gespannt Damit auch evnt-min-interval. Aus meiner Sicht unnötig. So etwas gibt es auch noch replizerit in DbLog... man kann es nicht oft genug haben, glaube ich   nichts für ungut.

Die Beispiele später....

[Beta-User]

Martin, irgendwie habe ich den Eindruck, dass die Möglichkeiten, die mit event-on-change-reading bereits da sind, immer noch nicht bei dir angekommen sind.

[martinp876]

Martin, irgendwie habe ich den Eindruck, dass die Möglichkeiten, die mit event-on-change-reading bereits da sind, immer noch nicht bei dir angekommen sind.

das ist sicher möglich. Aber ich sehe es gerade nicht.
Machen wir ein Beispiel (nicht real, aber  du verstehst es sicher)

RT sendet: meas-tempS erstelle ich mit einen UserReading weil ich das Rauschen der Messung weder triggern und schon garnicht loggen will. Wenn meas-temp um +-0,3 von meas-tempS abweicht wird meas-tempS upgedated.
Annahme: ich bin für RT enroled (ich will ja meas-tempS abfangen.
Event-on-change-reading
(t) bedeutet ein notify wird gestartet, (-) kein notify
t1: des-temp: 20 (-) meas-temp: 19,3 (t) controlmode: auto  (-) meas-tempS: 19,3 (-)
t2: des-temp: 20 (-) meas-temp: 19,4 (t) controlmode: auto  (-) meas-tempS: 19,3 (-)
t3: des-temp: 20 (-) meas-temp: 19,2 (t) controlmode: auto  (-) meas-tempS: 19,3 (-)
t4: des-temp: 20 (-) meas-temp: 19,4 (t) controlmode: auto  (-) meas-tempS: 19,3 (-)
t5: des-temp: 20 (-) meas-temp: 19,3 (t) controlmode: auto  (-) meas-tempS: 19,3 (-)
t6: des-temp: 23 (t) meas-temp: 19,3 (-) controlmode: auto  (-) meas-tempS: 19,3 (-)
t7: des-temp: 23 (-) meas-temp: 19,5 (t) controlmode: auto  (-) meas-tempS: 19,3 (-)
t8: des-temp: 22 (t) meas-temp: 19,7 (t) controlmode: auto  (-) meas-tempS: 19,7 (t)
t9: des-temp: 22 (-) meas-temp: 20,3 (t) controlmode: auto  (-) meas-tempS: 20,3 (t)

==> Resultat: mein notify wird getriggert für jeden der timestamps. ich brauche nur t8/t9.

Nun setze ich evOnChRead .* und minInterval auf 2 ticks.
t1: des-temp: 20 (-) meas-temp: 19,3 (t) controlmode: auto  (-) meas-tempS: 19,3 (-)
t2: des-temp: 20 (-) meas-temp: 19,4 (t) controlmode: auto  (t) meas-tempS: 19,3 (-)
t3: des-temp: 20 (t) meas-temp: 19,2 (t) controlmode: auto  (-) meas-tempS: 19,3 (t)
t4: des-temp: 20 (-) meas-temp: 19,4 (t) controlmode: auto  (-) meas-tempS: 19,3 (-)
t5: des-temp: 20 (-) meas-temp: 19,3 (t) controlmode: auto  (t) meas-tempS: 19,3 (-)
t6: des-temp: 23 (t) meas-temp: 19,3 (-) controlmode: auto  (-) meas-tempS: 19,3 (t)
t7: des-temp: 23 (-) meas-temp: 19,5 (t) controlmode: auto  (-) meas-tempS: 19,3 (-)
t8: des-temp: 22 (t) meas-temp: 19,7 (t) controlmode: auto  (t) meas-tempS: 19,7 (t)
t9: des-temp: 22 (-) meas-temp: 20,3 (t) controlmode: auto  (-) meas-tempS: 20,3 (t)

==> Resultat: mein notify wird getriggert für jeden der timestamps. ich brauche nur t8/t9.

##> wie kann ich einstellen, dass ich nur 2 trigger erhalte? Ok, deal: wenn ein anderes notfify auch T6 braucht, dann bekomme ich das eben auch.
##> anders gefragt: ich will dass niemand vom Plappermaul meas-temp notifiziert wird. niemand ausser mein userReading (welches die Glättung macht)

--> ich kann sicherstellen, dass nur meas-tempS geloggt wird (das ist ja einfach).

Fakt: ich haben ein power-meter welches quasi kontinuierlich triggert (alle paar sekunden - echtzeit!) und keiner will dieses Reading.

So, wenn es eine Einstellung gibt, die das leistet bin ich mehr als erfreut sie kennen zu lernen. Die suche ich tatsächlich dringend.

[martinp876]

ich habe mir extend und offset aus svg angesehen. Am ende nicht das, was ich brauche und was robust ist.
Offset: die Angabe holt aus der Datenbank einfach alle werte aus dem Zeitraum "vor dem Zeitraum", verarbeitet dies und los gehts.
Unschön ist dabei
- ich weiss nicht, wie lange ich vorher nachsehen muss - will ich auch nicht wissen. Das kann Tage her sein!
- wenn viele Werte gesampelt sind muss svg viele verarbeiten und filtern. Ich brauche aber nur einen einzigen.

extend:
typisch stelle ich die Grafiken bis zum "jetzt" dar. Da kommt kein Wert mehr.
Also wieder ein Beispiel: Desired-temp. Drehe ich in den Raum nie. Wir haben Zeitpunkt T9. Der Graph geht von T5 bis T12(T12 ist Zukunft)
1) von T9 bis T12 werden keine Linien gezeichnet (Zukunft)
2) um T-20 wurde desTemp auf17 gestellt. Um T7 auf 20.
3) der Grap soll also T5=17, T6=17, T7=20, T8=20, T9=20, T10=, T11=, T12=

Anforderung an ein inteligentes System:
- hole alle Messwerte von T5 bis T12
- hole den letzten Wert vor T5
  passe den Zeitstempel an, so dass T5-0,000001 gesetzt ist (1 sec vor T5)
- wenn curtime < T12: setze Tcur auf value T12
- wenn curtime > T12: setze T12 auf den letzte gefundenen Wert

Der Vorschlag bietet mir das nicht. Ich habe aktuell zwar nicht meinen Vorschlag am Start, dennoch denke ich ist meiner effizienter also dein Angebot. Aber eher nerd-ware. Nichts für jedermann.

[Icinger]

##> wie kann ich einstellen, dass ich nur 2 trigger erhalte? Ok, deal: wenn ein anderes notfify auch T6 braucht, dann bekomme ich das eben auch.
##> anders gefragt: ich will dass niemand vom Plappermaul meas-temp notifiziert wird. niemand ausser mein userReading (welches die Glättung macht)

Ohne mich in euren Dialog hier einmischen zu wollen, aber wo liegt das Problem? Wozu ein (unnötiges) Userreading?

Code Auswählen Erweitern


attr <device> event-on-change meas-tempS:0,3

gibt dir doch nur genau diese 2 Events, welche du haben willst?? Oder versteh ich da grad was nicht?

[martinp876]

Ohne mich in euren Dialog hier einmischen zu wollen, aber wo liegt das Problem? Wozu ein (unnötiges) Userreading

Vielleicht habe ich mich falsch ausgedrückt: das normale Reading will ich ausblenden.
Das Userreading ist das für mich sinnvolle.

Nein. ALLE Readings eines device werden durchgereicht. Kennst du den notify Mechanismus von fhem?
1) der Modulschreiber definiert Readings und legt (typisch unveränderlich) fest, welches Trigger auslösen darf. Das sind meist alle, da der Anwender entscheiden darf, was er nutzen will.
2) im kernal darf sich jeder notify Empfänger enrolen WEN er sehen will. Aber WAS er sehen will muss er selbst filtern.

Jede notify entity welche ein Reading  von device A haben will bekommt alle und muss suchen und filtern.

Achtung: Anwender welche das notify Modul nutzen sehen das nicht. Das filtern macht das Modul im Hintergrund.

Ich habe da ein paar Plappermäulchen welche viele Readings Posten. Ein extrem fleißiger und dann einige, dafür mehrere, nicht so heftige.

Mit event-on-change kann man schon einmal viel reduzieren. Regelmäßige Sender wie Thermostate und Thermometer senden unermüdlich. Oft die identischen Werte. Das kann man unterbinden, was ich konsequent mache und empfehle. Das ist Blindleistung.

Ich will, wenn ich es schon anfasse würde ich es gerne konsequent und bestmöglich machen. Da sind zum einen Trigger und zum 2. Die logs.

Logging habe ich im Griff: Messwerte werden geglättet um das Rauschen der Sensoren nicht loggen zu müssen. Bspw Temperaturen welche um 0.1 Grad wackeln sind für Auswertungen irrelevant.
Vorteile eines systematisch sparsamen Umgangs mit Ressourcen liegt auf der Hand und zahlt sich aus je größer die Installation ist.

Aus deinen Anmerkungen vermute ich, dass du nie hinter die Kulissen gesehen hast

[Beta-User]

...ich bin vielleicht nicht der erfahrenste Code-Leser, aber nach meinem Verständnis des userReadings-Codes in fhem.pl funktioniert kein userReading ohne trigger. Der kann mehr oder weniger eng sein, ist aber erforderlich. Das vorausgeschickt, KANN ein zusätzliches userReading NIE so "sparsam" (im Sinne von effizient) sein wie ein (gefiltertes) Original-Reading.

Und dass ".*" (für den Rest) und eine Hysterese (z.B. für measured-temp) nebeneinander in event-on-change-reading möglich sind, könnte man bestimmt auch besser verstehen, wenn "man" mal in den Code schauen würde, statt irgendeinen (m.E. kruden) workaround zu verteidigen. Jedenfalls scheint mir so, dass Icingers und meine praktischen Erfahrungen die sind, dass das völlig ausreicht, um die "gesprächigen" CUL_HM-Geräte sinnvoll zu bändigen (und einiges mehr, falls man noch geschwätzigeres Zeug hat, das es durchaus gibt, wenn man die Augen nur weit genug aufmacht.)

Nur mein 2ct. als Perl-Novize...

[Beta-User]

Irgendwie so ruhig hier?

Das mit dem Loggen fand ich auch eine Überlegung wert und werde das in jedem Fall bei der Überarbeitung von YAMAHA_AVR mit einfließen lassen. Da gibt es auch einige Interpolationen auf den verbose-Leveln 4 und 5, die man sich überwiegend sparen kann, wenn man vorab den gewünschten Level abcheckt. Das ist dann allerdings eine Doppelung zu dem, was Log3 sowieso tut, von daher werde ich das auch beschränken auf 4 und 5.

Sieht (im Moment; fhem.pl-Routinen ohne korrekte Klammern und "@a" etc. gehen eigentlich gar nicht!) konkret so aus (gepackagte Version, von daher bitte nicht an dem kurzen Funktionsnamen aufhängen):

Code Auswählen Erweitern

Log3 $name, 5, "YAMAHA_AVR ($name) - set ".join(" ", @a) if _Log3Demand($hash,5);

und

Code Auswählen Erweitern

sub _Log3Demand {
    my $hash = shift // return 0;
    my $lvl  = shift // 3;

    my $lcllvl = AttrVal($hash->{NAME}, 'verbose', undef);
    return $lcllvl <= $lvl if defined $lcllvl;
    return $lvl <= AttrVal('global', 'verbose', 0);
}

@Martin: Wenn wir schon beim Thema Effizienz im Coden sind: in CUL_HM finden sich ziemlich viele doppelte Quotes. Why?

(OT: frank hat eine konsolidierte CUL_HM-Version im Angebot, die diverse Kleinigkeiten gradezieht, die v.a. ihm nach den letzen Durchgängen noch so aufgefallen sind. Läuft stressfrei, soweit ich das beurteilen kann, vielleicht findest du mal Zeit, dir das näher anzusehen).

[Franz Tenbrock]

Hallo
ich bin ja schon ein paar Jahre hier registiert
einige Jahre lief meine Anlage ohne Probleme und mit nur ganz wenigen Erweiterungen
Ich habe so die Vermutung, dass alles die hier was geschrieben haben alles andere als normale User sind.
DB log kenne ich vomm Namen seit Jahren hatte aber bisher immer Angst es anzuwenden,
fhem.cfg läuft  und ich verstehe auch den Code der da steht.

Ich bin seit 40 Jahren Windows user und nur wegen FHEM quäle ich mich mit Linux, ein Buchstabe fals und nichts geht mehr.
ok schlank, schnell und etrem vielseitig aber für jemanden der nur ganz selten davor sitzt wirklich eine Qual.
Ich bin jemand der sich in ein Thema auch reinquält, viel sind da heute aber anders gestrickt.
Wenn eine App nicht das macht was man will nimmt man halt eine andere.

Was aus meiner Sicht besser gepflegt und auch in einfacherer Sprache gepflegt werden sollte ist das Wiki
User, nicht Nerds, kennen die Sprache nicht so gut, verstehen häufig nicht warum hier ein Komma ohne Leerstelle stehen muss etc.
Es gibt ewig lange Threads und es gehört schon viel Enthusiasmus dazu sich nach Feierabend da durch zu quälen, sie sind so lang, weil eben im Wiki es nicht für den einfachen user dokumentiert ist.

Ich habe mich in den letzten Tagen zB durch die readingsGroup gequält, kleineste Fehler im Code und nichts geht
Damians DOIFs haben mich so fasziniert dass ich es auch haben wollte, ok die Temperaturdarstellung von meiner Heizungsanlage habe ich nun, aber es hat mich fast 3 Stunden gekostet bis es so war, dass ich einen Mehrwert davon hatte.
Dann wollte ich mal eben schnell Tankenclever.de von ihm, Code kopiert, aber es klappt nicht, keine Ahnung warum nicht, warum weiss ich es nicht, weil ich eben den ganzen Code noch nicht verstehe, es wird einfach zu viel da an Wissen vorrausgesetzt
zB diese Zeile hier:
attr Tankstelle devStateIcon {ui_Table::ring(ReadingsVal("$name","Diesel",0),1.00,1.40,120,0,"Diesel",90,undef,2)."
was bedeuten die gnazen Zahlen da hinten ?  man müsste ewig lesen um zu wissen was dies bedeutet, mit probieren kommt man da kaum weiter
Fakt ist, weil ich die Zeile nicht verstehe komme ich nicht weiter
ich würde mir so was wünschen wie dies hier
1.00 = Spritpreis, 1.40= maximaler Preis, 120 = Farbe
ich hoffe ihr versteht was ich meine.
Damian hat so viel Code veröffentlicht, 1000 Dank dafür,
hier nur die Erklärung woran mancher user scheitert, nicht der Nerd.

also nicht böse sein.

habe seit 2,5 Jahren nach meiner Selbstständigkeit einen neuen Job als Angestellter, In der 2 Woche meinte eine Angestellte zu mir: das haben wir schon immer so gemacht, da war mir rausgerutscht : das heisst aber noch lange nicht das dies richtig war

interessante und auch hoch wichtige Diskussion

noch was zum Schluß
Ich hatte 10 Jahre mit 2 Freunden ein Softwareprojekt (maxidoc), ich Anwender und meine Patientenwaren die Anwender, mein Freund der Programmierer. Fast täglich habe ich mit dem programmierer zusammen gesessen und die Probleme aus Anwendersicht besprochen, und die Software entsprechend angepasst. nur wenn der Endanwender damit klar kommt nutzt es allen.

[KölnSolar]

Jetzt kenne ich den Grund für Deine "plötzliche" u. "dauerhafte" Reduzierung Deiner Forum-Aktivitäten. 

habe seit 2,5 Jahren nach meiner Selbstständigkeit einen neuen Job als Angestellter

Ich denke auch, dass das

Was aus meiner Sicht besser gepflegt und auch in einfacherer Sprache gepflegt werden sollte ist das Wiki

der Kern ist. Die Diskussion hier, war mir bisher viel zu detailliert, bereits zu sehr in der Tiefe, dass man sich gedanklich ausklinkt.
Im Sinne von der "Der Fisch...am Kopf..." ist es
1. das Wiki, das für einen einfachen Einstieg neuer User oder eines neuen (ausgereiften) Themas helfen sollte, es aber nicht tut.
2. eine Neuentwicklung immer von einem Nerd ausgeht, dem maintainer eines Moduls.
3. "Standards" für einen maintainer kaum zu finden, oder veraltet, oder ....  sind.

Meine Vorschläge:
zu 2.: wir brauchen nicht "den" maintainer, sondern ein maintainer team. Ich habe mich bisher strikt geweigert das wiki zu pflegen, weil ich als maintainer eben nicht die user Brille aufhabe, sondern aus technischer Sicht und entwicklungshistorisch beschreibe.
zu 1. ohne Wiki, welches von einem "Gremium" begutachtet wird, keine Freigabe
zu 3.
- technische Begutachtung  durch ein "Gremium", sonst keine Freigabe
- technische Standards

Und wo ich das so schreibe, komme ich dem wahren Problem näher Es fehlt uns an Struktur und Organisation.

Prima Erkenntnis. Aber wer soll es wie machen ? Der arme Rudi wird zwar gerne kritisiert, aber er wird auch von uns allen ziemlich allein gelassen.

Ich schließe dann mit der Frage, zumal es gut zu meinen 1. Zeilen passt: Wer committed sich, für was auch immer, Verantwortung zu übernehmen ? Nur so kommt man zu

Struktur und Organisation

Standards

Wiki

Aber ich sehe in meiner Glaskugel schon den nächsten Thread von Rudi, wo er vergeblich nach maintainer-Nachfolge sucht, die community sich aber wieder wegduckt...

[martinp876]

Erst einmal antworten
1) User-readings: Die Einlassung verstehe ich nicht. Klar funktionieren User-readings nur mit einem Trigger. Das ist, wenn nichts angegeben, jegliches Event welches durch die "eigene" entity ausgelöst wird. Dann kann man das noch einschränken - liegt in der Verantwortung des Users. Ich denke nicht , je etwas anderes behauptet zu haben. Das User-Reading wird vom kernal ausgefüllt und kann dann schon sparsam sein.
=> ein Orginal-Reading ist immer "besser" - WENN es zu Verfügung steht.
Ah, jetzt habe ich deinen Punkt: wenn das orginal-Reading kein Event auslöst wird auch das User-Reading nicht ausgeführt. Guter Punkt - scheint korrekt. Werde ich beachten!
Aber: ich habe Orginal-Readings welche SEHR heftig sind und welche ich nicht brauche. Möglich, dass es jemanden interessiert. Also wäre es cool, dies auf User-Ebene abschalten zu können. Es handelt sich um einen seltenen, aber ärgerlichen Fall. Nachdem es bi mir nur auf eine Entity mit einem Reading zutrifft kann man es aushalten....

=> EIGENTLICH... will ich einen Glättungs-algo welcher das übliche Rauschen der Messwerte filtert. WIE man das user-geeignet implementieren KÖNNTE (alles konjunktiv) habe ich noch nicht überlegt. Ich will das orginal schon sehen - allerdings will ich nur das geglättete loggen (falls ich es loggen will). Trigger kann ich auch auf das geglättete auslösen.
==> ich werden mir einmal Gedanken machen, wie ich es lösen könnte - INCL triggeroption! logisch.

Und dass ".*" (für den Rest) ... 

super a) kann man das nachlesen? b) Dokumentation ist der code von event-on-change-readings? Nix "lesbares"? wäre schade, wenn hier Möglichkeiten bereit gestellt werden, welche nur im Code nachzuvollziehen sind. Und ohne Spec besteht die Gefahr, dass es beim nächsten Update nicht mehr geht, weil der Autor es anders "gemeint" hat und es kein "Feature" war.

@Martin: Wenn wir schon beim Thema Effizienz im Coden sind: in CUL_HM finden sich ziemlich viele doppelte Quotes. Why?

Hm... vielleicht habe ich nicht gut nachgelesen, bei meiner Perl-selbst-lern phase. "hallo" ist weniger effizient als 'hallo' ? ich hatte es in meiner Anfangsphase einmal versucht, auszumessen - ohne erkennbare performance-änderung. Ich nehmen es gerne auf und werde es korrigieren.

Ich habe so die Vermutung, dass alles die hier was geschrieben haben alles andere als normale User sind.

in dieser Ecke des Forums erwarte ich, dass a) selbstverständlich jeder etwas posten kann - aber b) es um substantielle inhaltliche Fragen von fhem geht, also die Fragen a programmer und super-user geht.

DB...fhem.cfg

ich betrachte aktuell nur das Logging in die datenbank statt in files. Die konfiguration habe ich immernoch in files und bleibe weiter dabei. Ich sehe hier keinen Vorteil.
Grund: Logs werden gerne "ausgewertet" (z.B. Grafiken) und hierbei muss "gesucht" werden. Das kann, macht man es richtig - eine Datenbank effizient. Hier ist auch viel mehr "alarm". Es wird ständig geschrieben und gelesen. Die Datenmengen sind ganz anders - und wenn man nicht irgendwann stoppt wird die Datenbank riesig, da endlos fortgeschrieben wird. Hier suche ich Ansätze, wie ich das beherrschen kann und nicht beherrscht werde. Ich bin gelegentlich Nerd - Am Sofa mit Tablet bin ich User. Und mein Ziel ist, es von hier erfassen zu können.

Ich bin seit 40 Jahren Windows user ...will nimmt man halt eine andere.

nun - linux finde ich gerade an dieser Stelle prima -allerdings ist das nachinstallieren von Module tatsächlich umständlich und nicht mein Metier.
FHEM allerdings sollte vom OS weitgehend unabhängig sein. Perl ist Perl. Die Funktionen und expressions sind ein-eindeutig. Case-sensitiv ist ... geschmackssache. Ich finden es konsequent.
Egal, Geschmackssache.

Was aus meiner Sicht besser gepflegt und auch in einfacherer Sprache gepflegt werden sollte ist das Wiki

Wiki ist exterm unterschiedlicher Level. Und in der Tat wird der Level oft nicht unterschieden. User/Installation/Background/example,...
Ich bin tatsächlich ein Freund der guten alten Doku (so hatte ich auch einst den Anhang zu CUL_HM im Einsteiger-Doc geschrieben.
=> ICH muss bei jedem Dokument, welches ich schreibe, wissen für wen es ist. Programmer, nerd,user, anwender. Sonst kann ich die Sprache nicht treffen.
1) eine Doku sollte alle Optionen enthalten, welche angeboten werden. Um das Modul und dessen Doku "verständich" zu halten stellt sich die ERSTE Frage für den Programmer: brauche ich wirklich alle optionen? Ist da notwendig oder sinnvoll? Welche Optionen sind "expert-level" und können von "user" ignoriert werden,.... das ist, was ich hier ansprechen will/wollte.

Es gibt ewig lange Threads ... user dokumentiert ist.

ich bin zu 120% bei dir: Grundlegende Erkenntnisse aus Threats MÜSSEN in die Doku Einzug halten. Es ist ... fraglich... ob ein ein Threat als Doku gelten soll. Hier werden dinge diskutiert, wieder verworfen, wieder eingeführt. Das will keiner lesen, ich will wissen, was hier und jetzt angesagt ist.

Ich habe mich in den letzten Tagen zB durch die readingsGroup gequält, kleineste Fehler im Code und nichts geht

Code-fehler sind code-fehler. Ich kenne deine Fehler nicht. Die Frage ist allerdings, welche Hilfestellung readings-group zum debuggen liefern könnte. Hier wäre ein tutorial für user sicher hilfreich. Mir fehlen auch SEHR häufig GUTE Beispiele für die Anwendung von Attributen und Modulen. Das muss ich dann experimentell ermitteln - schade

attr Tankstelle devStateIcon {ui_Table::ring(ReadingsVal("$name","Diesel",0),1.00,1.40,120,0,"Diesel",90,undef,2)."
was bedeuten die gnazen Zahlen da hinten ?  man müsste ewig lesen um zu wissen was dies bedeutet, mit probieren kommt man da kaum weiter

ich sehe das "?" jetzt nicht in diesem Statement. Allerdings: Perl-code ist für Fortgeschrittene, genauso wie regexp. Das eignet man sich an der muss darauf verzichten. Aber auch das ist, was ich hier meine: der "simple-admin-User" sollte ohne Perl/SQL/regexp Lösungen finden können. der Advanced user beherrscht Perl - zumindest grundsätzlich und kann coolere Dinge einbauen. und der Nerd kann wie immer alles und coole/irre/fantastische/eigene Dinge implementieren.

ich würde mir so was wünschen wie dies hier
1.00 = Spritpreis, 1.40= maximaler Preis, 120 = Farbe

verstehe ich - ist sicher machbar. Ich kenne jetzt die Funktion nicht und gehe davon aus, dass es  eine generische Funktion ist, nicht nur für Spritpreise. Die Funktion "ring" muss also sauber und einfach erklärt sein (ist sie das) - und zwar an einer Stelle, an der man danach sucht. So in der Art (aus der Hüfte, ich kenne sie nicht)

Code Auswählen Erweitern

rng(value,param2,upperLevel,color,param5,param6,label,param8,param9)
value  : value to be displayed - must be a number
param2: ???
upperLevel : upper level. If value is above this limit the color changes - oder so etwas
color: display color if below upperLevel
param5 :??
param6:??
label: label to be displayed
param8 :??
param9 :??

so etwas geht in die Richtung API-definition. natürlich wäre eine Beschreibung, was es grundsätzlich macht hilfreich. Das sollte für jeden Funktion vorliegen, welche eine User zu Verfügung gestellt wird. Sicher habe ich hier auch Leichen im Keller

also nicht böse sein.

wir äußern hier unsere Ansichten - konstruktiv. Wie könnte man hier böse sein. Auch meine Anmerkungen sind konstruktiv gemeint - und nie alternativlos.

das haben wir schon immer so gemacht, da war mir rausgerutscht : das heisst aber noch lange nicht das dies richtig war

eine der dümmsten Bemerkungen, welche nicht nur du zu hören bekommst. Auch gerne "früher waren wir noch schlechter" - zumindest inhaltlich. 

[martinp876]

@KölnSolar
ich sehe einen Freigabeprozess als kritisch. In einer Firma mit festen Angestellten gerne. Wenn FHEM hier so etwas stemmen kann, auch gerne. Aber ich habe hier zweifel.

Ich sehe allerdings erst einmal eine triviale und für viele unangenehme  Aufgabe: ein Dokument(ation), wie Module und interfaces zu gestallten sind und was zu dokumentieren ist. das Team,was das erstellt sollte betrachten für wen das Modul/Interface gemacht wird. Also: wie kann das modul vom User betrieben werden, wie vom advanced und wie vom nerd? Wie kann man ihnen das nahebringen.

Anhand so eines Dokuments mir "guidelines" kann man dann ein UI und das gesamte Modul bewerten. Man kann den Entwickler befragen, diskutieren, und am Ende nach einer Einigung Verbeserungen erreichen.
=> Threats sind, wie schon im vorigen Post erwähnt - definitv keine Art der Dokumentation, sondern der Diskussion

[Adimarantis]

Auf die Gefahr mich zu wiederholen:
Das Konzept der individuellen Maintainer ist denke ich überholt. Schaut man sich die gängigen Open Source Projekte an, dann ist dies immer ein Gemeinschaftswerk welches z.B. über die Prozesse die GitHub mit Pull Requests and Reviews zur Verfügung stellt zusammengehalten wird.
Es gibt genug "verwaiste" Module (viele davon nicht offiziell, aber in Realität ist der Maintainer einfach nicht mehr aktiv), von denen Patches gehandelt werden, sich keiner traut tatsächlich etwas einzuchecken, sei es weil er dem Orginalautor nicht auf die Füße treten will oder Bedenken hat implizit zum Maintainer zu werden.

Eine echte gemeinsame Code Basis, mit PR Prozessen würde m.E. einige Probleme lösen
- Einhaltung von Mindeststandards
- Verwaiste Module bekämen zumindest die Chance auf eine Minimalwartung
- Direktes Feedback bzgl. Verbesserungen (da könnte Martin seine Anmerkungen gleich als PR einbringen)

Jetzt wäre ich auch nicht super begeistert, wenn andere ständig in meinen Modulen rumfuhrwerken oder ich erst ewig auf Feedback für meine eigenen Änderungen warten muss. Der Prozess müsste also schon so gestaltet sein, das der jeweilige Hauptmaintainer ohne Feedback committen kann, bzw. das letzte Wort bei der Übernahme von Patches hat.
Wenn aber ein Patch schon x Wochen unkommentiert steht, und ein Gremium aus Powerdeveloppern genug "Daumen hoch" gibt, dann kommts rein und gut.

Würde natürlich bedeuten, dass man FHEM z.B. auf GitHub umziehen müsste und das Projekt entsprechend konfigurieren müsste. Das ist Arbeit und für den Schritt müsste es erstmal eine Mehrheit geben und natürlich jemanden der sich die Migration antut.

Thema Wiki: Da kann doch schon jetzt jeder Mitarbeiten und es gibt auch die entsprechende Historie um Änderungen nachzuvollziehen. Ist ja auch Sinn eine Wikis. Da braucht es denke ich keinen Freigabeprozess. Diesbezüglich ist Dokumentation nicht so kritisch wie Code und kann bei Fehlern schnell vom Entdecker korrigiert werden. Vielleicht muss man hier die "User" mehr motivieren Beiträge zu leisten. Also @Franz: Wenn du nach einem Abend voll durchwühlen von Threads ein Aha-Erlebnis hattest, dann einfach im Wiki ergänzen - oder eben Nerd-Sprache durch allgemeinverständliches ersetzen. Wikis leben davon dass alle mitmachen.
Das gilt aber eben auch für die Maintainer: Jede Frage die im Forum beantwortet wird, sollte gleich ins Wiki einfliessen, damit sie nicht nochmal 10 Seiten später gestellt wird. Bei Signalbot habe ich mich bemüht das so zu halten - schon allein weil ich die selbe Frage eben NICHT zweimal beantworten will.

Jörg

[martinp876]

so, eigentlich wollte ich einen Post über "event-on-change-reading" verfassen.
Ich habe aktuell wieder einmal relevante Performance Probleme den Grund kenne ich noch nicht - beim Suche allerdings finde ich immer wieder Dinge welche "mir nicht gefallen".

Zum Hintergrund ist sicher den Programmieren bekannt, wie fhem mit Events umgeht. Das ist nicht schlecht, meine ich. Allerdings sollten die Programmierer es verstehen und es den Usern leicht gemacht werden, eine effiziente Struktur zu erstellen - ohne sich mit Details befassen zu müssen.

Der FHEM Ablauf ist:
a) eine Entity erzeugt Readings welche von Programmierer typisch auf "erzeuge Events" eingestellt sind. Wenn diese als Bulk abgesetzt werden, werden diese auch als bulk weiter verarbeitet.
b) über event-on-change-reading kann der User den Kernal steuern und die weitere Event-notifikation stoppen, wenn sich das Reading nicht geändert hat.
c) der Kernal notifiziert jede enroled entity. D.h. die Notify funktion wird aufgerufen
c1) ein Modul enroled (erst einmal)jede einzelne seiner Entities für alle readings jedes devices.
c2) jede Entity hat die Möglichkeit zu selektieren, von welchen entites sie events erhalten will. Oder ob überhaupt
=>wichtig - Beispiel: CUL_HM hat sich für notifcations enroled um config-änderngen bewerten zu können. Es macht aber keinen Sinn, dass jede CUL_HM entity notifizert wird. Daher schalten alle bis auf eine CUL_HM entites die notifikation ab. CUL_HM selbst, also die verbleibenden Entity greift konfigurations-änderungen ab (global) welche attr/rename/define/delete beinhalten.
c3) jede enitiy welche notifikationen benötigt sollt einschränken, von welchern entity dies notwendig ist. Rudi hat hier einen recht effizienten mechanismus implementiert.
c4) jede entity muss dann die Readings/events filtern welche sie verarbeiten will. Readings werden nicht vom kernal gefiltert.

So - nun on-change oder on-update? 
Ich betrachte das (und diskutiere es mit mir hier) anhand von 3 Typen von Readings:
Sporadische Events
Typ: Events wie Licht-An/Aus, also schalt-events. Button-press,... HT Mode Einstellungen
Eigenschaften: sind verhältnissmäßig selten. Nicht zyklisch. Können mehrfach gemeldet werden. Bei CUL_HM durch statusmeldungen, in ACK messages, aber auch in Zyklischen Messages. Auch durch manuellen Status-nachfragen (status-Request). Ein Hoematic-RT Thermostat schickt bspw den aktuellem Mode (auto/manual/...) alle 3 Min mit der regelmäßigen Status-message

Verhalten/Auswertung: interressant ist nur die Änderung. Wenn der Status erreicht ist gilt er fortan bis zur nächsten Änderung. Nachdem - bis auf Ausnahmen - eh keine regelmäßige statusmeldung erfolgt kann man diese events getrost auf "changes-only" stellen. Alles andere kostet notifications. Was sollen diese bringen?
Gefahr: User hatten schon fehlerhafte notifies geschrieben in welchen sie ein "toggel" programmieren wollten, wenn ein Button-Press notifiziert wird. das kann leicht in ins Auge gehen, wenn man "update" als option hat.
periodische Events
das sind typisch Temperaturmessungen. Ein RT oder Bewegungsmelder mit helligkeit sind wie alles Sensoren ein Beispiel.
Der Zustand des Ventils eines HK-Therosataten ändert sich nur selten. Es geht auch stufing. Wie vor kann (muss) ich davon ausgehen, dass der Wert stabil ist, bis eine Änderung vermeldet wird. also "change" ist vollkommen hinreichend.
Auf den Controll-mode trifft das in noch schärferer Form zu. Noch weniger änderungen.
Die Wunschtemperatur dito
die gemessene Temperatur - eigentlich auch. Nun, die Änderung ist eine interpolation... aber wenn sich nichts ändert - ändert sich nichts... "change" ist hinreichend.
special Events
hier sehe ich 2 Beispiele -Motion-detection und Button-press
Ich habe den Motion-detector übernommen welcher "motion" signalisierte wenn eben Motion erkannt wurde. Das Reading stand IMMER auf "Motion" - den Rest musste man im Timestamp nachsehen. Eigentlich ist das realitätsfern. de-facto ist ein MD im Mode "motion" oder "non-motion". Er tastet ab und vermeldet "motion" wenn motion - und wichtig - wenn kein Motion gemeldet wird ist er auf "no-motion"! Dass das Device nicht ständig "no-Motion" sendet macht sinn- zu viele Messages. Aber das ist kein Grund, warum die Zentrale das nicht abbildet.
Ich habe mich also mit den MD von Homematic befasst - und siehe da - es werden ausgiebig timer mitgesendet welche der Zentrale erlauben, non-motion zu generieren.  Das geht mit jedem MD!!!
=> wenn das nicht implementiert ist hat der Programmierer seinen Job nicht vollendet!
Bei Button-Press ist es ähnlich. Man kann ein Event erzeugen, welches anzeigt, ob es ein neuer oder schon verarbeiteter "press" ist

##> ALLE Readings können so gestelltet werden, dass man OHNE PROBLEME auf "change" triggern kann
##> sollte das mit einem Reading nicht funktionieren ist zu hinterfragen, ob das Reading schlecht implementiert ist . Besser wäre dann, die Quelle des Problems zu bearbeiten .

Event-on-update
alles was man auf "update" stehen lässt kann man nachträglich filtern. Das kostet Performance, da es erst weitergeleitet wird und am Ende gefiltert wird. Jedes Notify muss das für sich selbst machen. Kostenfrei ist das nicht zu haben.


Meine (Nabel-)Schlussfolgerung
bisher habe ich alles problemlos mit event-on-change readings hinbekommen. Bei CUL_HM sowieso. In der Tat würde ich gerne noch mehr wegfiltern!
Für einen "user" wäre die Anweisung " setze alles auf "notify-by-change" eine klare und einfache Anweisung. Noch besser: könnte man in global als default setzen (da man schon verpasst hat , es als default zu setzen). einfacher geht kaum.

Die Auswertung:
Es besteht ein Problem bei Grafiken. Allgemein: wenn ich wissen will, welchen Wert die Desired-temp am 01.12.2022 11.11.11 hatte kann die Datenbank den letzten Wert vor dem Timestamp suchen und mir geben. Das ist einfach und schnell aus der DB abzufragen. 
Es gibt also noch etwas zu tun - aber nur work, keine Probleme

So nun warte ich auf die Gegendarstellung mit Beispiel. Also: wo geht "change" nicht? was geht nicht und wie kann man einem User sagen und vermitteln wie er es einzustellen hat?
Bin gespannt.

[martinp876]

@Jörg,

alles ok.
Dennoch vermisse ich die guidelines - in schriftform. Nicht in Chats/emails/threats. Etwas gegen das man messen kann. Das ist unabhängig vom Maintainer!!!!!!!

[frank]

so, eigentlich wollte ich einen Post über "event-on-change-reading" verfassen.
Ich habe aktuell wieder einmal relevante Performance Probleme den Grund kenne ich noch nicht - beim Suche allerdings finde ich immer wieder Dinge welche "mir nicht gefallen".

vielleicht hast du dir selbst ein bein gestellt? 
denn viele cul_hm user haben ggf erhebliche event probleme, wenn sie die default einstellung "attr commStInChn on" nutzen.

grundsätzlich macht die event philosophie in fhem (alle events on update) jedem irgend wann probleme, wenn man nicht selbst aktiv wird und gegensteuert.
dadurch lässt man alle erst mal an die wand laufen, finde ich. anders herum wäre humaner.

theoretisch könnte mittlerweile jeder maintainer alle events im code auf change setzen.
wenn wirklich mal ein event on update gebraucht wird, hätte jeder user die möglichkeit das über das bestens versteckte attr forceEvents zu ändern.

[martinp876]

Hall Frank
a) commStInChn... vielleicht. Sollte ein Service sein. Könnte ich auf "no-Event" setzen Aber wieso macht es in diesem Zudammenhang so viele Schwierigkeinten?

grundsätzlich macht die event philosophie in fhem (alle events on update) jedem irgend wann probleme, wenn man nicht selbst aktiv wird und gegensteuert.
dadurch lässt man alle erst mal an die wand laufen, finde ich. anders herum wäre humaner.

genau meine Meinung!

theoretisch könnte mittlerweile jeder maintainer alle events im code auf change setzen.

das halte ich nun einmal für eine ganz schlechte Idee. Mehrere Gründe
I) der Kernel hat diesen Filter vorgesehen. Ich hatte das schon vor ~8 Jahren - zu meiner Anfangszeit - im code vorsehen wollen. Da es aber der Kernel macht sollte es auch dort bleiben
II) wenn es jeder einzeln einbaut kommt nur ein durcheinander heraus. Es wird noch chaotischer. Bitte bitte nicht
III) man kann es (wie immer) nicht umstellen - das klappt dann bei allen Usern erst einmal nicht mehr.
IV) Vorschlag wäre, ein "attr global event-default onChange" vorzusehen. Dann kann es jeder selbst einbauen. Überall vermerken, das dies bestCurrentPractice ist.
Und für Ausnahmefälle und Testfälle event-on-update - ist kein Schaden. "level: expert"

---------------------------------------
so hier meine Bewertung zu Performance. Ich habe eine Performance-improvement-aktion meines Systems gestartet... und mein altes Schlachtross apptime ausgepackt. Verrichtet immernoch gute Dienst.

Code Auswählen Erweitern

name                                     function                               max    count      total  average   maxDly   avgDly TS Max call     param Max call
iolgw:keepAlive                          HMUARTLGW_Ready                         11   705628   66566.75     0.09     0.00     0.00 03.12. 05:34:46 HASH(iolgw:keepAlive)
rhasspyMQTT2                             MQTT2_CLIENT_connect                    20   705628  282105.81     0.40     0.00     0.00 02.12. 20:09:49 HASH(rhasspyMQTT2)
hlt                                      HMLAN_Ready                             13   532835  136090.24     0.26     0.00     0.00 03.12. 10:08:04 HASH(hlt)
ScnFlur                                  LightScene_Notify                       90   207844   29151.06     0.14     0.00     0.00 02.12. 17:02:23 HASH(ScnFlur); HASH(lfTreppeK)
ScnGarden                                LightScene_Notify                      123   207844   12286.72     0.06     0.00     0.00 03.12. 09:48:33 HASH(ScnGarden); HASH(loDoorBall)
ScnWohn                                  LightScene_Notify                      128   207844   15218.93     0.07     0.00     0.00 03.12. 10:22:03 HASH(ScnWohn); HASH(laLnge)
WEB                                      FW_Notify                                1   207844    3724.10     0.02     0.00     0.00 03.12. 14:42:36 HASH(WEB); HASH(prRHMccu)
WEBphone                                 FW_Notify                               10   207844    2189.22     0.01     0.00     0.00 03.12. 09:02:21 HASH(WEBphone); HASH(hwEss)
WEBtablet                                FW_Notify                                4   207844    2109.08     0.01     0.00     0.00 03.12. 12:12:59 HASH(WEBtablet); HASH(hb_Clima)
avgWeather                               average_Notify                          18   207844  117909.35     0.57     0.00     0.00 02.12. 16:34:13 HASH(avgWeather); HASH(h_burner_Pwr)
dayTemp                                  average_Notify                          11   207844   81143.11     0.39     0.00     0.00 02.12. 15:13:38 HASH(dayTemp); HASH(hwSalon)
et                                       eventTypes_Notify                       12   207844   66164.58     0.32     0.00     0.00 02.12. 17:04:43 HASH(et); HASH(haLnge)
hZheating                                average_Notify                          14   207844   79150.21     0.38     0.00     0.00 02.12. 18:00:48 HASH(hZheating); HASH(hb_Clima)
hlt                                      HMLAN_Notify                             7   207844    4511.92     0.02     0.00     0.00 02.12. 19:08:55 HASH(hlt); HASH(ScnGarden)
ht                                       HMtemplate_Notify                        4   207844    4752.56     0.02     0.00     0.00 03.12. 00:03:13 HASH(ht); HASH(ccu)
pa_stereo                                YAMAHA_NP_Notify                         3   207844    4635.76     0.02     0.00     0.00 02.12. 17:04:43 HASH(pa_stereo); HASH(haLnge_Clima)
rg_Thermostate                           readingsGroup_Notify                    32   207844   34197.16     0.16     0.00     0.00 02.12. 14:59:38 HASH(rg_Thermostate); HASH(global)
rg_battery                               readingsGroup_Notify                    25   207844   30899.62     0.15     0.00     0.00 02.12. 14:59:38 HASH(rg_battery); HASH(global)
rg_critic                                readingsGroup_Notify                    64   207844   23780.12     0.11     0.00     0.00 02.12. 14:59:38 HASH(rg_critic); HASH(global)
rg_heater                                readingsGroup_Notify                    98   207844   24188.40     0.12     0.00     0.00 02.12. 14:59:38 HASH(rg_heater); HASH(global)
rg_pres                                  readingsGroup_Notify                    49   207844   24539.70     0.12     0.00     0.00 02.12. 14:59:38 HASH(rg_pres); HASH(global)
testme                                   weekprofile_Notify                      58   207844    6213.75     0.03     0.00     0.00 02.12. 14:59:38 HASH(testme); HASH(global)
tmr-CUL_HM_sndIfOpen                     sndIfOpen                              296   180830  130026.17     0.72  8610.98     7.51 03.12. 10:24:10 sndIfOpen:ioPCB
ioPCB                                    HMUARTLGW_Read                        8815    87505 1068272.91    12.21     0.00     0.00 03.12. 10:22:10 HASH(ioPCB)
b                                        ntf_Notify                              44    60070   19345.37     0.32     0.00     0.00 02.12. 14:59:37 HASH(b); HASH(global)
iolgw                                    HMUARTLGW_Read                        1389    45741  519093.68    11.35     0.00     0.00 02.12. 14:32:14 HASH(iolgw)
dblog                                    myDbMgmt_Log                            18    36262   33632.65     0.93     0.00     0.00 03.12. 00:27:14 HASH(dblog); HASH(WetterSchnaittach)
tmr-YAMAHA_NP_GetStatus                  HASH(0x3ff1ac0)                         18    24850   91124.21     3.67  4374.70    18.90 02.12. 20:08:53 HASH(pa_stereo)
deviceStateHM                            ntf_Notify                              45    19125   24414.36     1.28     0.00     0.00 02.12. 20:26:48 HASH(deviceStateHM); HASH(h_s_aussen)
tmr-HMUARTLGW_CheckCredits               HMUARTLGW_CheckCredits                  11    12793   38103.78     2.98  7943.95    12.71 03.12. 05:23:06 HMUARTLGW_CheckCredits:iolgw
ntfy_burnCnt                             ntf_Notify                              35    10124    3551.01     0.35     0.00     0.00 02.12. 14:59:38 HASH(ntfy_burnCnt); HASH(global)
d_rpc178046BidCos_RF                     HMCCURPCPROC_Read                      331     8681  813479.43    93.71     0.00     0.00 02.12. 20:37:10 HASH(d_rpc178046BidCos_RF)
tmr-HttpUtils_TimeoutErr                 HASH_unnamed                             8     6647    4929.60     0.74  7267.81    39.07 02.12. 18:37:04 HASH(0x83d8ed8)
telnetPort                               telnet_Read                             12     4588   12198.61     2.66     0.00     0.00 02.12. 15:08:03 HASH(telnetPort)
h_burner_SenPwr                          CUL_HM_Set                               5     3963    5442.84     1.37     0.00     0.00 03.12. 10:25:08 HASH(h_burner_SenPwr); h_burner_SenPwr; ?
prBtPhonePapa                            PRESENCE_lanBtRead                     181     3318   23721.05     7.15     0.00     0.00 03.12. 15:12:50 HASH(prBtPhonePapa)
tmr-DbLog_execmemcache                   HASH(0x2a55e50)                         59     3007   55652.52    18.51  4340.53    35.18 02.12. 18:42:20 HASH(dblog)
tmr-PRESENCE_daemonScanScheduler         HASH(0x6113cb8)                        244     3007  257726.17    85.71  4389.95    52.30 02.12. 20:28:31 HASH(PsnceDaemon)
prBtTablet                               PRESENCE_lanBtRead                     209     2333   15337.98     6.57     0.00     0.00 03.12. 15:08:38 HASH(prBtTablet)

es zeigt mir mit wenigen clicks genau, was ich wissen will.
Mein System ist auf "change-Event for all " eingestellt.
Die Auswertung ist auf Anzahl ereignisse eingestellt und sortiert. Schnell sieht man, was erst einmal falsch läuft und was ganz einfach zu beheben wäre - gefunden?

Die beiden high-runner sind pflicht- keep alive muss so oft kommen. MQTT2 - kenne ich noch nicht... kann ich abschalten.
HMLAN ready ... muss ich prüfen.

So nun die Bösewichte. Alle danach haben identisch 207844 aufrufe aus notify erhalten. Sie dauern nicht lange, ok. Aber unnötig. Offensichtlich haben sie sich pauschal eingetragen bei notify und werden bei ALLEN notifies alarmiert. Das macht schon einmal gar keinen Sinn.
Die WEB interfaces lasse ich durchgehen.
LightScene könnte kinderleicht eintragen, bei wem sie notifizert werden wollen.
ReadingsGroup dito - etwas komplizierter, aber machbar.
Average... ebenso
=> wenn ich nun event-on-update nutzen würde wäre da noch schlechter.
hm - nun muss ich wohl für die Module ein add-on erstellen bei welchem ich das Enrolen übernehmen. So werde ich das nicht lassen...
Merke: das sind zig-fach zu viele Aufrufe
Und: der kernel macht alles richtig - die Modul-schreiber sind das Problem.

Anzumerken: mein gepimptes dblog-notify  myDbMgmt_Log  braucht nur noch 36510 Aufrufe. Gesamtzeit 34sec. Mal sehen, ob es noch schneller geht.
Und hier werden ALLE events und entites geprüft, von welchen wir etwas loggen wollen. Ich bin auf den Weg....

[Beta-User]

a) commStInChn... vielleicht. Sollte ein Service sein. Könnte ich auf "no-Event" setzen Aber wieso macht es in diesem Zudammenhang so viele Schwierigkeinten?

Weil die meisten User das Thema "Event-Minimierung" (und NOTIFYDEV) nicht wirklich auf dem Schirm haben, und erst dann was tun, wenn es "komisch" wird (überbordende Logs oder Performance-Probleme).

Wir merken halt, dass das ein echter "Dauerbrenner" ist, und die Sinnhaftigkeit des defaults hat sich der Mehrheit der CUL_HM-User bisher nicht erschlossen.

Zum Thema "Doku zu event-on-change-reading". In der commandref steht (das zu finden ist wieder eine andere Sache):

Wenn hinter dem Namen eines "readings" eine :Schwelle angegeben ist, wird das Event nur getriggert wenn die Änderung grösser als diese Schwelle ist.

Soweit also völlig klar. Das einzige, was in der Doku fehlt, ist der Hinweis, dass alle diese Attribute der Reihe nach abgearbeitet werden wie vom User angegeben und bei einem Treffer dann "Schluss" ist.
Nicht so ganz deutlich steht auch nicht dort, dass das jeweils als eine Art "whitelist" zu sehen ist: Wenn da was steht, wird auch nur das geprüft und der Rest (bei eocr) stillgelegt.

Rudi freut sich bestimmt über einen Patch, denn dass das so ist, ist kein Zufall...

Doku/Wiki ist aber in der Tat ein Thema allgemein ein Thema, und (halb-) verwaiste Module (und deren Kennzeichnung) sind es auch, ebenso die Frage, wie man es den Usern "einfach" machen kann, "gute" Einstellungen zu finden (und diese zu verstehen, damit sie sie ggf. anpassen können).

Es gibt dazu bereits diverse Wege. Gut angenommen wird attrTemplate bei MQTT2_DEVICE und HTTPMOD (weil man da eben "alles" über Attribute konfiguriert).
Komplett unverstanden ist archetype, aber auch das könnte vielen Usern das Leben erleichtern. (Und dann gibt es noch weitere Tools, die ich aber auch nicht vertieft kenne oder nutze).

Wahrscheinlich wiederhole ich mich da mal wieder, aber mAn. braucht es nicht unbedingt neue Tools, sondern eine Art "gemeinsames Verständnis", wie die Dinge zu sein haben und was man Usern ggf. einfach empfehlen sollte (selbst, wenn es "ultrakompliziert" aussieht). Ändern können es die Einsteigenden dann immer noch...

Nachtrag noch zum Thema "Aktualisierungen sehen": event-on-change-reading (auch mit "Schwelle" verhindert nicht das Aktualisieren des timestamps. Das kann man zusätzlich unterdrücken, aber man sieht, ob ein Device noch lebt!

Nachtrag  zu ".*": Bei Tastern ist das Kontraproduktiv, und manche Module verarbeiten auch nur, was irgendeine Gegenstelle ihnen schickt. Das ggf. mit watchdog-Funktionen aufzubohren geht zwar, aber warum einen workaround für ein Problem schaffen, das man selbst mit "Dogmatismus" generiert hat...?

[Icinger]

Um nochmal kurz auf

zB diese Zeile hier:
attr Tankstelle devStateIcon {ui_Table::ring(ReadingsVal("$name","Diesel",0),1.00,1.40,120,0,"Diesel",90,undef,2)."
was bedeuten die gnazen Zahlen da hinten ?  man müsste ewig lesen um zu wissen was dies bedeutet, mit probieren kommt man da kaum weiter

zurückzukommen:

Was genau wäre an

Code Auswählen Erweitern

ring ($value,$min,$max,$minColor,$maxColor,$unit, $sizeHalf,$colorRef,$decFont,$model,$lightness)

$value     # darzustellender Wert
$min       # minimaler Wert, optional, default=0
$max       # maximaler Wert, optional, default=100
$minColor  # Farbe (hue: 0-360) des kleinsten Wertes, optional, default = undef
$maxColor  # Farbe (hue: 0-360) des maximalen Wertes, optional, default = undef
$unit      # Einheit des Wertes, optional, default = undef
$sizeHalf  # "<size>,<half ring>" size: Größe der Grafik, optional, default = 100, half ring: 1 für Halbring
$colorRef  # Referenz auf eine Funktion, die zu einem Wert einen Farbwert (hue: 0-360) bestimmt, oder eine Referenz auf eine Arrayliste mit Grenzwerten und Farben, optional, default = undef
$decFont   # "<Anzahl der Nachkommastellen>,<Schrift-SVG-Attribute Wert>,<Schrift-SVG-Attribute Einheit>", optional
$model      # '<Farbverlauf>,<Min/Max>,<Innenring>,<Zeigerstärke>,<Modus>',
            #   Farbverlauf: 1 für monochrom,
            #   Min/Max: Style-SVG-Attribute oder 1 zum Anzeigen der Min-/Maxwerte,
            #   Innenring: Style-SVG-Attribute oder 1 zum Anzeigen des Innenringes, Zeigerstärke: in Pixel,
            #   Zeigerstärke: Breite des Zeigers,
            #   Modus: 0 Standard Min-Max, 1 Min-Null-Max, 2 Null-Min/Max,
            #   alle Parameter sind optional, default keine Angaben: ',,,,,'
$lightness  # Helligkeit einzelner Elemente (0-100) "<ring>,<inner ring>,<minMax>,<unit>,<value>", optional, default: "50,50,50,40,50"
Wird $colorFunc nicht angegeben, so wird der Farbwert zwischen $minColor und $maxColor linear interpoliert
noch besser zu beschreiben? Steht genau da, wo es sein soll -> im Wiki
siehe https://wiki.fhem.de/wiki/DOIF/uiTable_Schnelleinstieg#Farbskalierte_Anzeige_eines_Zahlenwertes_mit_Hilfe_der_universellen_SVG-Funktion_ring

[martinp876]

Weil die meisten User das Thema "Event-Minimierung" (und NOTIFYDEV) nicht wirklich auf dem Schirm haben, und erst dann was tun, wenn es "komisch" wird (überbordende Logs oder Performance-Probleme).

das Problem ist nicht nur ein User-Problem - auch gestandene Module-owner schlampen - erheblich!

Wir merken halt, dass das ein echter "Dauerbrenner" ist, und die Sinnhaftigkeit des defaults hat sich der Mehrheit der CUL_HM-User bisher nicht erschlossen.

CUL_HM User? Das ist ein allgemeines Problem. Das trifft alle Module.

FHEM Admins könnten schnell etwas dagegen unternehmen. Und wenn immer wieder langjährige "Berater" davor warnen, auf Event-On-Change umzustellen hemmt es die Umsetzung ungemein. Der User braucht zwingend eine einfache Methode, die Events einzudämmen. Mehr noch: der User sollte eigentlich erst einmal garnichts machen müssen - es muss default sein.

Wenn hinter dem Namen eines "readings" eine :Schwelle angegeben ist, wird das Event nur getriggert wenn die Änderung grösser als diese Schwelle ist.

ok, werde ich testen.
Mit Attribute meinst du die Liste der Parameter des Attributs? Ok, ich bin ein Stinker und selbst nicht immer konsequent. "event-on-change-reading" ist ein Attribut welches eine Liste von Parametern enthalten kann. Anderer Vorschlag zur Wortwahl?
Ein Beispiel wäre hier definitiv cool:
attr xxx event-on-change-reading .*,measured-temp:0.5
oder
attr xxx event-on-change-reading measured-temp:0.5,.*
Das meintest du mit "er Reihe nach". Wie gesagt ein Beispiel würde einem User sicher helfen.
Interessant ist hier dann auch die Wirkung. Wenn sich also die measured-temp um nur 0.3° ändert: wird die Webseite upgedated? Notifys werden nicht getriggert. Einem Programmierer und Nerd sind die Fragen sicher klar. Dem User muss klar gemacht werden (ein satz) was es bedeutet, wenn KEIN Event getriggert wird.

Es gibt dazu bereits diverse Wege. Gut angenommen wird attrTemplate bei MQTT2_DEVICE

kenne ich nicht, hört sich aber gut an. Ich bin ein großer Freund von templates. Dennoch: Meine erste Forderung ist, dass sich ein Module oder eine Entity schon bei der Definition erst einmal in einer standard konfig selbst einrichtet. Der Anwender kann dann rumspielen. optimieren ider es zertören. Aber die erste Konfig sollte einfach erst einmal das sein, was der Anwender typisch will.

... braucht es nicht unbedingt neue Tools, sondern eine Art "gemeinsames Verständnis", wie...

100% Zustimmung.  Ein gemeinsames Verständnis, wie man ein Modul designen sollt wünsche ich mir schon lange. Die Liste meiner offenen Punkte ist lang. Ich kenne keine Dokumentation, was man in Internals schreiben sollte, was die UUID soll, wie man mit renames umgehen sollte, .....
Mein Vorschlag wäre demnach ein Dokument zu erstellen (wie hier schon einmal erwähnt ist das Forum eine Diskussionsplattform - keine Dokumentation) was die Bedeutung der einzelnen Elemente ist. Schriftlich ist unabdingbar. Wiki ist möglich, ein PDF würde ich bevorzugen.
Beispiel: wenn ein rename stattfindet ist es Aufgabe der einzelnen Elemente welche auf das referenzierte Element verweisen, das rename nachzuziehen. Kann man auch anders definieren. wovon ich abrate. Dennoch: definiert ist es nicht.

Nachtrag noch zum Thema "Aktualisierungen sehen": event-on-change-reading (auch mit "Schwelle" verhindert nicht das Aktualisieren des timestamps. Das kann man zusätzlich unterdrücken, aber man sieht, ob ein Device noch lebt!

Das mit den Timestamp ist auch sinnvoll. Der sollte schon aktualisiert werden. Auch der Wert, wenn er unter der Schwelle liegt. Nur die Benachrichtigung an andere Module wird unterbunden. Das betrifft dann auch das Logging im File oder der DB.
=> wie man sieht ist hier etwas Text zu hinterlegen, damit der Anwender auch erfassen kann, was "event-on..." bedeutet.

Nachtrag  zu ".*": Bei Tastern ist das Kontraproduktiv, und manche Module verarbeiten auch nur, was irgendeine Gegenstelle ihnen schickt. Das ggf. mit watchdog-Funktionen aufzubohren geht zwar, aber warum einen workaround für ein Problem schaffen, das man selbst mit "Dogmatismus" generiert hat...?

verstehe ich nicht. Wenn du auf CUL_HM Buttons anspielst: mit event-on-change-reading kann man ganz einfach nur einen Trigger erhalten. Konsequente Einstellung des Systems. Einen Kostenlosen Zähler erhält an auch. Man kann erkennen wer antwortet. Man kann eigentlich alles sehen. Und doppelte Trigger erhält man nicht. Ein Zusatzmodul ist nicht notwendig. Ein Module-owner muss die angebotenen Readings gemäß den geltenden Regeln generieren. Nur sind die Regeln eben nicht definiert. Das Dokument fehlt.

@Icinger: Perfekt. Das muss auch ein User erfassen können.

[KölnSolar]

Sorry Martin, wenn ich weniger zu Deinen Detailfragen beitrage, sondern Deinem Threadtitel.

Dazu schmeiße ich mal diesen Link zu Wiki-Thema Development in die Runde. Ich bezweifle, dass den jeder kennt(nutzt), der als "Entwickler" klassifiziert ist. DevelopmentModuleIntro ist eine sehr gute Basis. Hier werden Fragestellungen aus diesem Thread zu events, Internals aufgegriffen. Auch readings. Aber kein Hinweis auf die Kombi reading-event. Dass es überhaupt die Funktionalität gibt, dass readings nie ein event erzeugen oder nur bei inhaltlicher Änderung, findet sich erst in DevelopmentModuleAPI#Readings_.2F_Events, das vermutlich noch weniger Entwickler kennen. Und eine guidline, wie was einzusetzen ist fehlt gänzlich. Die Verbindung zu den diversen event-...-Attributen ebenso.

Die Versionsgeschichte der DevelopmentGuidelinesReadings spricht Bände, dass ein guter Ansatz im Sande verlaufen ist.

Thema Wiki: Da kann doch schon jetzt jeder Mitarbeiten und es gibt auch die entsprechende Historie um Änderungen nachzuvollziehen. Ist ja auch Sinn eine Wikis. Da braucht es denke ich keinen Freigabeprozess. Diesbezüglich ist Dokumentation nicht so kritisch wie Code und kann bei Fehlern schnell vom Entdecker korrigiert werden. Vielleicht muss man hier die "User" mehr motivieren Beiträge zu leisten. Also @Franz: Wenn du nach einem Abend voll durchwühlen von Threads ein Aha-Erlebnis hattest, dann einfach im Wiki ergänzen - oder eben Nerd-Sprache durch allgemeinverständliches ersetzen. Wikis leben davon dass alle mitmachen.

ist meines Erachtens der Trugschluss aus "viel hilft viel". Fühle ich mich jetzt berufen, an den vorgenannten Dokumenten "rumzuwurschteln"? NEVER. Aus Ehrfurcht vor denen, die die Beiträge bis hierhin entwickelt haben, schmeiße ich doch nicht die Struktur und Inhalte über den Haufen. Ich arbeite aber gerne mit oder mache einem "Gremium" Vorschläge für Änderungen.

Nun bin ich dann doch irgendwie wieder bei Martins "Detailfragen" gelandet.

Und wer ändert nun das Wiki mit den in diesem Thread gemachten Hinweisen, damit man den nächsten Martin einfach auf das dortige Dokument verweisen kann ?

[Beta-User]

das Problem ist nicht nur ein User-Problem - auch gestandene Module-owner schlampen - erheblich!

Das mag sein, aber es macht m.E. auch keinen großen Sinn, "Entwicklungs-Interessierte" mit "noch mehr" Zeug zu belasten, das sie unbedingt beachten müssen, und das im ersten Moment unverständlich erscheint.

Einen (Qualitäts-) Review  machen zu lassen, trauen sich viele leider nicht, erfahrungsgemäß werden zielführende Tipps allerdings doch in der Regel gerne angenommen. Das Problem ist halt oft, dass "irgendeine" (häufig leider "schlechte") Vorlage (ähnliches Modul) kopiert wird, und dann noch aus Unerfahrenheit weitere Böcke geschossen werden.

CUL_HM User? Das ist ein allgemeines Problem. Das trifft alle Module.

Jein. Es tritt halt empirisch gesehen gerne in der Kombination von CUL_HM (ohne abgeschaltete Kommunikationsreadings) und MQTT auf (da kann aber das Modul nichts dafür!).

Und ich habe vor einiger Zeit eine Testversion von VALVES ins Forum gestellt, die sehr viel seltener triggert als die alte. Das werde ich wieder umstellen, weil diese Art Einstellung in User-Hand gehört. Warum? Ich will die virtuelle Ventilöffnung an eine MCU senden, die die Vorlauftemperatur entsprechend ändert. Bekommt die nicht regelmäßig einen aktuellen Wert, funktioniert das so nicht, und man muss einen umständlichen workaround bauen. Wußte ich nur "damals" noch nicht...

ERGO: Die Entscheidung, was wann warum wie oft triggern soll gehört in User-Hand! Der Modulautor sollte das nicht zu sehr einschränken.

FHEM Admins könnten schnell etwas dagegen unternehmen. Und wenn immer wieder langjährige "Berater" davor warnen, auf Event-On-Change umzustellen hemmt es die Umsetzung ungemein.

Jedenfalls ich warne NUR (!) vor dem (m.E. engstirnigen!) Festhalten an der pauschalen Empfehlung, einfach überall 

Code Auswählen Erweitern

attr DEVICE event-on-change-reading .*
zu setzen. Das ist einfach zu kurz gesprungen, weil man nämlich mit

Code Auswählen Erweitern

attr DEVICE event-on-change-reading measured-temp:0.3,.*
GENAU DAS erreichen kann, was du als eine Art "Goldstandard" anzusehen scheinst.

Und GENAU DAS kann archetype automatisiert bei der Definition eines neuen Gerätes  verteilen, und zwar so, wie es der USER vorher eingerichtet hat. Ich hasse es dagegen, wenn mir Module vorschreiben wollen, wie Attribute gefüllt zu sein haben. Zum einen macht es den Code unleserlich, und zum anderen kann der Modulautor nicht wissen, was ich mit den Infos machen will. Er kann gerne (!!!) einen Vorschlag machen, aber das sollte m.E. nicht direkt im Modul stehen, es gibt dafür - wie bereits erwähnt - andere Wege! Man muss sie nur kennen...

Deswegen kann ich Sätze wie

der User sollte eigentlich erst einmal garnichts machen müssen - es muss default sein.

nicht unterstützen. Der User muss (!) sich Gedanken machen, wie sein System funktionieren soll, und man kann und sollte ihm Vorschläge machen.

Ich warte übrigens seit Jahren (!) darauf, dass jemand für die als "geschätzig" bekannten Shelly einen Vorschlag liefert für Event-minimierende Attributeinstellungen, die ich dann auch in attrTemplate aufnehmen würde - nur leider bisher Fehlanzeige. Keine Idee, warum...
(Ich nutze die selbst nicht (mehr) und habe keine Neigung, da was aus dem Elfenbeinturm raus vorzugeben. Übrigens auch weil ich möchte, dass das Thema besser bei den Usern ankommt).

Beispiel: wenn ein rename stattfindet ist es Aufgabe der einzelnen Elemente welche auf das referenzierte Element verweisen, das rename nachzuziehen. Kann man auch anders definieren. wovon ich abrate. Dennoch: definiert ist es nicht.

Schwierig. Im Moment haben wir keine "replace" Funktion, und das ist bei mir der Hauptanwendungsfall für rename... Da will ich aber grade haben, dass (z.B. LightScene) das mit den beiden Umbenennungen nicht nachvollzieht! Und über die Implikationen für devspec-basierte Eventhandler haben wir auch schon ein paar Mal ergebnislos nachgedacht...

Im Übrigen spreche ich nicht immer nur von CUL_HM! Meine Welt ist etwas "bunter", es gibt da u.a. noch ZWave, HUEDevice, MQTT-basierte Hardware mit diverser Funktionalität und MySensors...
Bei den Tastern hatte ich an HUEDevice-Geräte gedacht, aber dasselbe "Problem" besteht, wenn man die z.B. über zigbee2mqtt einbindet. Auch da darf "eocr" nicht auf ".*" stehen...

Was das Wiki angeht, ist es aus mehreren Gründen nicht so einfach, da Hand anzulegen. Zum ersten muss man wirklich sehr tief drin sein, um da überhaupt Hand anzulegen, und zum anderen müßte man z.B. auch ein gemeinsames Verständnis dazu haben, was Hilfsmittel wie PBP/perlcritic angeht. Da sind Prototypen z.B. extrem hinderlich.

Auch stilistisch stellt sich manche Frage. Beispiel gefällig:

Code Auswählen Erweitern

sub X_Define($$) {
my ( $hash, $def ) = @_;
my @a = split( "[ \t][ \t]*", $def );
...Warum schreibt man das so? Meine Module sehen in der Regel an der Stelle so aus:

Code Auswählen Erweitern

sub Define {
    my $hash = shift // return;
    my $def  = shift // return;
    my @arr  = split m{\s+}xms, $def;
    my $name = shift @arr;


Und zu Prototypen ein aktuelles Beispiel. Vorzufinden war da:

Code Auswählen Erweitern

sub MODULE_ParseResponse($$$) {
    my ( $param, $err, $data ) = @_;   
   
Aha. Der Modulautor meint, man braucht zwingend drei Argumente für diese Funktion. Denkste... Es geht so weiter:

Code Auswählen Erweitern

    my $hash = $param->{hash};
    my $queue_hash = $param->{hash};
    my $cmd = $param->{cmd};
    my $arg = $param->{arg};
    my $options = $param->{options};
    $data = "" unless(defined($data));
    $err = "" unless(defined($err));

So einen Code kann jedenfalls ich nicht warten...

Jetzt sieht das so aus:

Code Auswählen Erweitern

sub ParseResponse {
    my $param = shift // return;
    my $err   = shift // q{};
    my $data  = shift // q{};

Und mittelfristig gibt es dann noch ein "carp" dazu, damit auch klarer wird, warum es nicht klappt, wenn man das einen zwingende Argument nicht übergibt...

Kurz: Es gibt insgesamt ein Haufen Punkte, über die man sich mal einigen sollte, wie das mittelfristig aussehen soll.

[martinp876]

@KölnSolar
Ich bin mir nicht gazz sicher, as du aussagen willst, aber: ich habe die Dokumente nicht durchgearbeitet. Werde ich ohl einmal machen, danke dafür.
Am Ende bewerte ich hier (aus meiner Nabel sicht - und diskutierbar!!!) was aktuell Sache ist, was ich so sehe.
Was ich nicht erkennen kann auf den Ersten Blick ist eine übergreifende Philosiphie, eine Zielgruppe. Ich (also ICH!) bin der Meinung, das einiges doch "automatisch" oder "per default" eingestellt werden sollte (user geeignet) und für experten (nerds) modifiziert werden kann - nicht umgekehrt. Also erst einmal alles offen lassen, es dann "nutzbar" zu machen kann man mit Einstellungen erreichen.
Beides möglich, klar.
Ich mache das an Details fest, anders befürchte ich, kann ich es nicht rüber bringen.

@Beta-User

ERGO: Die Entscheidung, was wann warum wie oft triggern soll gehört in User-Hand! Der Modulautor sollte das nicht zu sehr einschränken.

das sehe ich genauso - sorry, wenn es nicht so rüber gekommen ist.

Code Auswählen Erweitern

attr DEVICE event-on-change-reading measured-temp:0.3,.*

da hast du recht. gehe ich weiter unten darauf ein.

Der User muss (!) sich Gedanken machen, wie sein System funktionieren soll, und man kann und sollte ihm Vorschläge machen.

hm. klar muss er das. Aber das System kann doch in einem sinnvollen Default hochkommen. Dann merkt der User was es macht und passt es an. Oder es kommt im Default hoch und er ändert es gleich. Das System kommt immer in einem Default hoch - nur eben in welchen. Ich befürworte ein "geschmeidiges" welches automatisch ein "gut funktionierenes" system abbildet. Selbstverständlich!!! kann man es nach allen Seiten personalisieren.

[quoteI]m Übrigen spreche ich nicht immer nur von CUL_HM! Meine Welt ist etwas "bunter", [/quote]
Ist mir klar

Aha. Der Modulautor meint, man braucht zwingend drei Argumente für diese Funktion. Denkste... Es geht so weiter:

ich habe einen Command-parser geschrieben für get/set und Attr - werde ich später einmal zeigen. Ich finde ihn cool (oh wunder, habe ihn selbst gemacht ).

Aber beim Code-review bin ich eigentlich nicht.
---------------------------------
Mein Thema heute ist eigentlich Event-on-change-reading. Und, danke Beta-User. In meiner unendlichen Ignoranz habe ich den optionalen Threshold verdrängt. Das ist wirklich gut - und der Rückbau meines Systems hat mir einen halben Tag gekostet ( wegen der langsamen Datenbank).

Ich denke hier fehlt noch deutlich mehr info für den User.  Umrissen muss man erklären, wie es funktioniert und welche Auswirkungen es hat. Warum sollte der User events sparen, wenn er nicht weiss, warum?

Erklärung zum Ablauf
S

ystem bahaviour readings, events, notifications:
readings are set by the module based on aktivities or sensors which are processed by the entity.
Typically a reading causes an event, which can be processed by other entites in the system.
The event will be passed to entites in the system that enroled for notification from the sourcing entity.
The notified entity filters the readings and values it is interessted in and executes the programmed action.

User can reduce system load by supressing events from readings.
By default an event is generated upon update of a reading. I.e. if the reading is updated with the same value an event is triggered.
By "event-on-change-reading" user can restrict events to "trigger only if the value changed".
For even more reduction the user can programm a threshold for numerical readings. I.e. only if the value of a reading has changed for more than "xx" then trigger an event.
This is especially to be considered for sensor readings. Very often a sensor reads a value (thermometer in 0.1°C) with a high resolution. A jitter is the result and the reading might change with every repetition. Typically it is sufficient to only trigger for changes higher than 0.2 or even 0.5 degree.

Backside or supressing events:
as described above: if no event is issued no other entity is notified about the change. This also includes web-frontend as well as logging entites. Explicitely:you will be notified about changes of a reading in the browser (red marking of the changed value, update of value) only, if an event is triggered.
Secondly also the data to be logged to the history-database is captured if an event is triggered. Remind that this feature can be used to restrict data in the history database. Subsequently the less data will improve speed of evaluating this data - e.g. for graphics

Note that default for readings is "event-on-update".
As a matter of fact we have
event-on-update
event-on-change
event-on-threshold (included in attr event-on-change-reading)

system recommendation is to setup
attr device event-on-change-reading thrReading1:thr1,thrReading2:thr2,thrReading3:thr3,changedReading
attr device event-on-update-reading updtReading1,updtReading2

it is recommended that event-on-change-reading ends with ".*"
also "on-update" should be used with care - it typically is not necessary

Der text ist so auf die Schnelle - geht sicher besser. Im Commandref würde ich leicht andres schreiben und im Wiki ausführlicher.
Klar zu stellen ist, wie threshold GENAU funktioniert. Was passiert mit
25,3°C
temp:25,3
noTempmeasured


--------------------
ansonsten bin ich mit den Performance verbesserungen schon einmal selbst zufrieden bis hier her. Da es aber etas gedauert hat frage ich mich eben: wie kann man diesen Weg dem "user" ersparen. das ist das Ziel des Threats

[Beta-User]

  Sorry, wenn ich etwas sehr deutlich gewesen sein sollte.

Den Text finde ich prinzipiell gut, die "abers":
- Die Einleitung versteht vermutlich kein Mensch auf Anhieb, da besteht die Gefahr, dass der Rest untergeht;
- Wahrscheinlich wird das mit dem Threshold klarer, wenn man ausdrücklich darauf hinweist, dass der nur für rein numerische Reading-Inhalte gelten kann (und Zahlen dann im englischen Text dann auch in der englischen Notation erscheinen sollten). Man könnte (in der Langform!) aufnehmen, dass man readingsChange benutzen kann, wenn ein Modul unbedingt meint, die Einheit mit reinknödeln zu müssen.
- Was ".*" angeht, sind wir fast einer Meinung: Man sollte darüber nachdenken, aber ausdrücklich NICHT bei Tastern!

Was sinnvolle Defaults angeht, bleibt die Frage, wer die wo wie "vorschlagen" sollte. Vielleicht wirfst du nochmal einen Blick auf "archetype", jetzt wird vielleicht klarer, warum ich darauf gleich zu Beginn mal hingewiesen hatte. (Ja, die Syntax ist gewöhnungsbedürftig, und ja, es ist ein großes Problem, einem User klarzumachen, dass es eventuell sinnvoll ist, Devices zu definieren, die er "null und gar nicht" versteht.)
PS: igami wollte das Modul damals "default" nennen .

PPS: Meine Xiaomi-Bluetooth-Sensoren meinen, dass man Temperaturen mit 2 Stellen hinter dem Komma messen müßte (und die ZigBees auch, wenn ich das richtig im Kopf habe)...

PPS 2: Es fehlt ggf. dann noch der Hinweis auf "timestamp-on-change-reading". Mich interessiert eigentlich insbesondere bei Aktoren nicht, wann die sich das letzte Mal gemeldet haben, sondern eher, seit wann etwas ein- oder ausgeschaltet wurde.

[martinp876]

@ Beta-user
Ich bin auch deutlich - hoffentlich nicht angreifend. Deutlich ist ok und willkommen. Wir wollen vorwärts kommen, Fakten und Meinungen aussprechen und ausdiskutieren.

Den Text finde ich prinzipiell gut, die "abers":

alles klar. Ich habe das einfach einmal runtergeschrieben und nicht einmal überarbeitet (keine Zeit). Der Text ist gemeint als Anregung und Vorlagen für den, der die Doku machen wird.

dass der nur für rein numerische Reading-Inhalte gelten kann

genau das fehlt. Und  was passiert, wenn der Wert nicht numerisch ist. Dann fallen wir auf "on change" zurück. Kann man vermuten, sollte man nachlesen können.

Was ".*" angeht,

ich bleibe der Meinung, dass "event-on-change-reading" mit "/\.\*$/" matchen, als Enden sollte. Aber sicher hast du recht, dass einige Elemente das nicht unterstützen (Buttons unterschiedlicher Familien?) . Nun sind wir bei a) "meinungen" und b) real existierenden Modulen. Unsere Meinung divergiert und Module sind ger einmal Fakt.

Was sinnvolle Defaults angeht, bleibt die Frage, wer die wo wie "vorschlagen" sollte.

Meine Meinung: die Kerngruppe sollte einmal "richtlinien niederschreiben" wie man sich das vorstellt (und ob man sich das vorstellt). Ich habe immer noch keine Indikation, dass es gewünscht ist (von mir schon).
Ein Kernsatz, welcher dann noch ausgebaut werden sollte könnte sein:
"Nach dem inkarneren einer Entitys sollte dies funktionsfähig und mir allen sinnvollen attributen ausgestattet sein, um es typisch nutzen zu können".
Ich sehe hier bspw dass Icons gefüllt sein könnten, webCmd, bei HMCCU würde ich mir bei Schalten wünschen, dass "on" und "off" erscheinen wie bei allen anderen Module,...
Auch Event-on-change-reading könnte gesetzt werden - bspw incl thresholdvalues. Ich fände es gut - dann sehe ich die defaults und weiss, was sache ist. Ich dann es hinnehmen, nachlesen oder ändern. Was mehr könnte ich wollen.
Da jedes Modul unterschiedliche Ausprägungen hat ist es nur eine Richtlinie.
Weiter muss das Modul erkennen, ob der Anwender den Wert überschrieben hat udn muss diesen dann akzeptieren. Das kostet etwas Aufwand bspw bei reboot. In CUL_HM mache ich so etwas - ich muss dann nach "init-done" aufräumen.

Meine Xiaomi-Bluetooth-Sensoren meinen, ...

die Thresholds kann man nicht pauschal machen - glaube ich. und evtl ist auch das sinnvoll... aber bei Raumtemperatur, selbst wenn der Wert am Sensor stimmen sollte...

Mich interessiert eigentlich insbesondere bei Aktoren nicht, wann die sich das letzte Mal gemeldet haben, sondern eher, seit wann etwas ein- oder ausgeschaltet wurde.

mit "on-change" kannst du das einfach aus der Datenbank extrahieren. Und fix geht das auch. Es gibt wohl weitere Module die irgendwie Daten tracken - verstehe ich nicht, das macht die Datenbank.
Ich habe das schon fertig (diesen Teil) - vielleicht zeige ich es morgen, wenn ich es schaffe.

Heute habe ich erst einmal das erledigt, was mich schon lange stört: dann bei Grafiken der Anfangswert nicht gesetzt ist. Also bei "on-change" wird mögl. die Solltemp am Tag 1 um 20:00 gesetzt und dann am Tag3 um 10:00 wieder.Eine Grafik von Tag2 + 3 startet dann erst am Tag3, 10:00. Bisher habe ich  mir einen extrem hässichen Workaround erstellt.
Im Anhang nun eine Modufikation in dblog welche die Daten auffüllt. Das Reading zur Grafik-Startzeit wird auf den Wert des letzten Readings vor Startzeit gesetzt - der sollte ja eben der gültige sein. Weiter habe ich den Wert "jetzt" auf den letzten gesetzt gemessenen, wenn der Zeitraum das "jetzt" beinhaltet.
Wie ich das implementiere ist mir noch nicht klar. Am Besten wird es im Orginal geändert.

[martinp876]

Ich fasse einmal zusammen:
bezüglich EOCR (EventChangeReading) und EOTHR ( Threshold variante) herrscht in diesem kleinen Kreis Einigkeit (bis auf Buttons ). EOCR ist minimum, EOTHR sollte eingepflegt werden, EOUR ist zum Spielen und für specials.
So weit so gut. Wenn allerdings nicht die nächten Schritte eingeleitet werden, geht es aus wie das legendäre Hornbascher Schiessen.
Aktuell ist ja faktisch (fast) alles vorhanden, ein geschmeidiges System zu erstellen - nur muss eben der User den steinigen Weg gehen (Thema des Threats - remember!)

Zuerst sollte sie der Enge Führungskreis dazu kommitten, dass es Ziel ist, das System per Default "geschmeidig" hoch zu bringen. In diesem Fall müsste der Entwickler für sein Modul und dessen Elemente die Attribute mit sinnvollen Werten vorbelegen.
1) Führungskreis sieht es genauso. Wenn nicht wird es nichts werden
2) Richtlinien für Entwickle werden erstellt und dokumentiert, dass der Entwickler sein Modul "geschmeidig" erstellen soll und bspw EOCR/EOTHR sinnvoll vorbelegen soll. Das ist natürlich nur ein Beispiel
3) die Doku für den Anwender sollte im Commandref knackig kurz und mit sauberen Begriffen hinterlegt werden (EOTHR).  Ein Wiki kann dass dann klarlegen. Für einen Anwender ist ein übergreifendes HowTo-setup a lean system eigentlich ein MUSS. Ich kann nicht erwarten, dass er alle wiki - und am Besten noch die Threats durchliest um alles zu ergrunden. Das macht keinen Spass.
4) das system sollte die Einstellungen übergreifend realisieren. D.h. wenn EOCR gesetzt ist MUSS in SVG-Diagrammen der Startpunkt auch errechnet werden. Ebenso wie der Endpunkt. Das habe ich im Beispiel ein post vorher erledigt (halt, da fehlt noch der Endwert... hole ich nach). Ich würde mich freuen, wenn das realisiert wird. Ansonsten muss ich schon wieder ein Modul presonalisieren - das ist  nicht mein Ansinnen.

Bin gespannt, ob sich etwas bewegt - die grundsätzliche Zustimmung scheint mir im Threat ja vorhanden zu sein.

[martinp876]

nun einmal das angekündigte Modul (die Module) wie ich (der Nabel ) sich eine User-freundlichere Version des DB-UI vorstellen kann. ich kommentier, was ich gemacht habe. Der Stand ist für mich nicht endgültig, aber schon einmal nutzbar.

Hilfsmodul MCAO  - meine Erweiterung des Kernal für command und attribut parsing
Ich habe es als modul gestaltet - was nicht zwingend notwendig ist. Die Funktion ist, kommandos und attribute systematisch zu parsen. Effizient, hoffe ich doch.
- der Anwender definiert die Kommandos (get, set, attr) syntax-konform. in einer struktur.
- das modul prüft die Anzahl der Parameter (required, optional), setzt default-werte ein, prüft Parameter-listen, wenn definiert. Das Prüfen ist dann standartisiert und funktioniert immer identisch
- 2 Komamndos werden vom Modul selbst abgewickelt:
  + get cmdList: Der Anwender bekommt die Liste der Kommandos und der Optionen angezeigt. Und auch die Default-Werte. und zwar immer identisch
  + get list: hier kann der Anwender ein List machen und sehen, was so alles in der Entity steht. ok, geht so auch , aber nicht ber click, wo es hin gehört. Weiter kann er die versteckten Elemente sehen ohne umständlich showInternalVals schalten zu müssen. Sollte auch nerds gefallen. Und die 3. Option ist, die Elemente des Moduls (also notify, CUL_HM, dgLog,...) sichtbar machen. Natürlich nur vom eigenen Modul
  => beide Funktionen halte ich für schlicht notwendig und fair. Die Implementierung ist komplett und könnte für jedes (JEDES) modul genutzt werden
- noarg wird automatisch gesetzt, wenn passend
- man kann kommandos auf Modul-ebene definieren oder je entity. Das ist bei dbLog nicht notwendig, wohl aber bei HW-familien. Hier können einzelne Entites unterschiedliche kommandos haben, einige sind aber gemeinsam
- dynamische Option-list halte ich für besonders effizient. Der Programmierer kann im Kommando einen Platzhalten hinterlegen und über eine Variable eine Liste von Elementen zuweisen. Die Prüfung auf "korrekt" erfolgt automatisch. Die Option-List bei Kommandos mit einem Parameter wird automatisch erzeugt.
- kommandos werden zur setup-time vorkompiliert - die performance zur runtime sollte gut sein

Die Funktion setze ich bei mehreren Module ein (mein modufiziertes Notify, Präsenc,... auch bei dem muDbMgmt

muDbMgmt - MyUtil.DbManagement
das ist ein Overlay vom Overlay. Ich wollte weder dbLog noch dbRep anfassen. Und bitte klar zur Kenntnis nehmen: beide Module besitzen Funktionen welche hilfreich aussehen und welche ich nicht überblickt. Ich habe nicht den Anspruch noch das Wissen an einigen Stellen, das alles zu ersetzen.
Was ich will? Zum Einen will ich zeigen, was mMn fehlt und zum anderen werden ich es nutzen und weiter entwickeln wenn es nicht implementiert wird.

Nun, was kann es.
- es ist z bedienen ohne SQL Kenntnisse. Das ist eine Kernforderung von mir
- get cmdList ist natürlich vorhanden - take a look
- get recList zeigt mir eine Liste der Readings aus der Datenbank. Filtern ist empfohlen: DeviceName (regexp) readingName (regexp) anzahl records je reading
  + ich kann schnell und unkompliziert sehen, welche Readings zu einem device angelegt sind (get recList myDevice .*)
  + ich kann schnell und unkompliziert sehen, welche devices ein Reading nutzen, bzw was geloggt wurde (get recList .* measured-temp)
  + ich kann schnell und unkompliziert die letzte Aktionen eines device sehen (get recList myDevice powerUp 20)
  => das, meine ich, ist ein einfaches und effizientes interface. Ich habe keine Beschränckung eingebaut - also  nicht gleich die ganze DB auf einmal anzeigen lassen
-get recStat - zeigt mir - mit ähnlichen Parametern wie oben, an, wie viele datensätze zu einem Reading in den letzten Zeiträumen angefallen sind (tag, woche, monat, jahr)
- dbInfo zeigt mir, welche Prozesse laufen und wie groß die DB ist
- ich kann suchen lassen, was ein dbInclude eigentich alles loggen würden. Ein prima Test der Einstellungen
- ich kann prüfen, was in der DB steht und gemäß meinen aktuellen Filtern garnicht auftauchen sollte
- lsit sowieso

- set rename - unbenennen der Devices oder Readings
- einfache Löschkommandos

- dblog enroled sich für die Entites, welche geloggt werden sollen (eigentlich ein Muss)
- ich habe DbExclude eliminiert (meine variante - alles andere ist zu kompliziert und nicht notwendig)

den Rest könnt ihr testen. Ich werden es  noch weiter kompletieren - zumindest für mich.

Das eine oder andere kann gesehen werden falls sich jemand traut, es zu testen.
Die Kernpunkte noch einmal
- effizienz: alles was zur Konfig-Zeit erledigt werden kann ist vorzbereiten
- weniger Attribute ist mehr
- sichtbarkeit ist mir wichtig
- für die DB muss der user essenzielle Daten ohne SQL Kenntnissen abfragen können.

[martinp876]

nun, das Interesse scheint endlich an diesem Themenkomplex - und ich bin erst bei der Datenbank.

Also ich kann und werden auf Auswertungen wie ich sie hier vorgesehen habe nicht verzichten (können) und muss wohl wieder ein modul an meine Bedrüfnisse anpassen. Ich bin evtl nerd, am Sofa aber immer "user-admin". und da muss es funktionieren.
- vervollständigen von Record-Anfragen für Grafiken  (Erster/Letzter Wert) sind bei nutzung von EOCR oder gar EOTHR unverzichtbar. Der User muss das nicht einstellen, das muss das System leisten. Hier das gewünschte Gesamtverhalten des Systems betrachten!
==> ein muss für mich!
- statistische Auswertung (get recStat , also record statistic) ist für die Evaluierung der Sinnhaltigkeit der DB unverzichtbar. Die Auswertung MUSS ohne Kenntnisse der Datenbanksprache erfolgen. M.E. der Schlüssel, die Datenbank selbst auswerten zu können
==> ein muss für mich!
- records auslesen (get recList) ist wie die statistik ein muss . es ergänzt die statistik und gibt mir Einblick, was geloggt wird. Weiter ist es ein simple Möglichkeit, bswp die letzten Power-Up der Devices auszuwerten.
--> aus meine Sicht sind damit die lustigen Reading-History Anstrengungen obsolet. Wenn ich mir eine Datenbank leiste muss sie mir über die History auskunft erteilen können. Der Nerd kann nun evaluieren, wo die Unterschiede der unterschiedlichen Anwendungen liegen.... Der User könnte genervt sein: brauche ich dies oder das, habe ich das richtige, na ja, klappt - fragen wir nicht weiter.....
==> für mich also eine Muss für ALLE historischen Auswertungen - manuell.
- get dbInfo: das ist eigentlich extrem wichtig - aber noch nicht vollendet. bei meinen "umstellungen", also dem umbenennen von Readings war die DB Stunden beschäfftigt - und ich meine Stunden. FHEM dbLog hatte schon lange aufgegeben, aber die mariabd nicht. Ich brauche also eine Auswertung welche mir zeigt, was in der DB ab geht, welche kommandos noch laufen,...
==> das ist tatsächlich unverzichtbar - muss aber noch vollendet werden.
- die Filter-auswertungen sind ein unverzichtbares Hilfsmittel für Anwender, insbesondere Einsteiger. Die Funktion welche mir zeigt, welche meiner Readings geloggt würden sowie die Funktion welcher meiner geloggten records gemäß Filter nicht passen sind elementare Hilfsmittel für den Admin. Hier kann er probieren, was er an/ein-gestellt hat.

- für die maintenance der records sind rename und delete wichtig. Da 2-stufige Verfahren ist m.E. der Löschfreigaben über Attr überlegen, da selektiver.

Und wichtig  beim Lesen meiner Kommentare
1) ich bin zwar, wie schon festgestellt, der Nabel. Gerne können/sollen anderen Näbel hier kommentieren
2) ich betrachte die DB aus meiner Sicht und nur selektiv. Bspw ist der Fokus auf mariaDB - oracle, SQL,... betrachte ich nicht. Die Implementierung ist also nicht vollständig
3) ein wirklich innovativer Schritt nach vorne ist nur mit einer neuen "lean-DB" machbar (hatten wir schon). Ich werde mit dem 3rd level modul die aktuelle DB nach meinem Gusto tunen bis es eine Option gibt, welcher ich zustimmen kann
4) mit diesen Kommentaren will ich in keiner Weise die Anstrengungen und Ergebnisse des aktuellen DB Moduls in den Schatten stellen. Ich bedanke mch selbstverständlich für die geleistete Arbeit. Ich setze nur in Top was ich zum Arbeiten benötige -und wünsche mir, dass es in ählicher Form integriert wird.

Für die Allgemeinheit - bin ich der Einzige, der mit dem User-frontend nicht "zurecht" kommt? Sind die Funktionen für alle anderen hinreichend und hinreichend simplifiziert?

[Beta-User]

Na ja, zum einen ist es so, dass grade ja nicht irgendwie ein (komplett) neues Hardwaremodul im Raum steht (MATTER anywhere?), und die bestehenden sind von den betreffenden Usern anscheinend (*hust*) so gut verstanden, dass diese Themen offenbar nicht als vordringlich wahrgenommen werden.

Von daher wäre jede "Vorgabe" der "zentralen Steuerungsgruppe" eigentlich indirekt eine Art Aufruf an alle Maintainer bestehender Module, irgendwas umzustellen. Aus nachvollziehbaren Gründen ist da die Bereitschaft von allen Seiten aber eher gebremst...

Von meiner Seite noch eine Anmerkung:
Aus "User"-Perspektive zu denken, und dann das Vorhandensein einer Datenbanklösung für (hisorische) Reading-Werte vorauszusetzen, ist imo bereits "nerdig". Ich bin stark im Zweifel, ob der "normale Wald-Feld-Wiesen-FHEM-Admin" sich überhaupt eine Datenbank antun sollte. Wenn er sich sowieso mit sowas auskennt: kein Ding. Aber sonst...? Fährt dieser Admin-Typ ggf. besser mit FileLog, gönnt sich das Loggen von ein paar mehr Werten (event-min-interval), und wüßte gerne, wie er schnell findet, wie mit logProxy Anfangs- und Endwerte ermittelt werden können (was auch unter dBLog funktioniert, afaik).

Da wir bei Änderungen sind und welche seltsamen Blüten das treiben kann, wenn irgendwann der Hintergrund für bestimmte Empfehlungen nicht mehr klar ist, speziell für dich noch ein Link: https://forum.fhem.de/index.php/topic,93074.msg1252299.html#msg1252299 und die drei Beiträge vorher .

[martinp876]

und die bestehenden sind von den betreffenden Usern anscheinend (*hust*) so gut verstanden, dass diese Themen offenbar nicht als vordringlich wahrgenommen werden.

wenn ich jetzt sage, dass mich dies nicht interessiert bitte ich es richtig zu verstehen.
- Deine Aussage bedeutet: Wir werden nichts ändern, alles ist (hinreichend) gut so.
-- natürlich - und das verstehe ich auch - hat man Probleme mit dem "Bestand" welcher Änderungen (mit unter exterm) erschwert
-- auch wenn ich es verstehe muss/werde ich es nicht akzeptieren. ich muss es hinnehmen oder an den Stellen anpassen - selbstverstämdlich nur für mich. Also keine Gefahr für andere
-- jeglicher Fortschritt (wobei erst einmal vereinbart und festgelegt werden sollte, wo man hin will) ist damit faktisch gestoppt

Von daher wäre jede "Vorgabe" der "zentralen Steuerungsgruppe" eigentlich indirekt eine Art Aufruf an alle Maintainer bestehender Module, irgendwas umzustellen.

ich stimme nicht zu, FHEM könnte -und macht schon - Vorgaben welche Maintainer befolgen - schneller/langsamer/garnicht. Beispiel Notify - Rudi hat hier ein (notwendiges, sinnvolles, ...) verhalten eingebaut, bei welchem sich Clients enrolen können um effizient gefilterte Notifikatioen erhalten. Technisch finde ich es zwar leicht zu kurz gesprungen und änderungen sind nicht effizient druchzuführen (hätte ich anders gemacht, Stichwort vorwärts/rückwärts referenzierung) - aber faktisch KANN und SOLLTE sich hier jede Entity eintragen oder eben nicht. Ähnliches kann man auf jeder Ebene anbieten.
=> erst einmal muss man festlegen, wo man hin will, wenn man könnte. Dann erst an die Realisierung denken.
Leider erlebe ich es ständig und überall, dass man sich (faktisch) weigert wirklich frei nachzudenken, wie es sein sollte und dann überlegt, wie man das schaffen kann. Wenn man schon zu beginn Angst hat, nichts schaffen zu können sollte man erst garnicht anfangen.

Ich bin stark im Zweifel, ob der "normale Wald-Feld-Wiesen-FHEM-Admin" sich überhaupt eine Datenbank antun sollte

mir nicht klar, auf welchem Level du gerade denkst. Ich habe die Datenbank nun seit Jahren genutzt. Sie hat stabil Tonnen von Daten welche ich nicht brauche geloggt. Kann man so lassen.
Dennoch:
a) das Gesamtvolumen war schon über 2GB von denen ich nicht mehr als  ~200MB benötigte
b) das Aufräumen faktisch Tage dauerte - mit einem Erheblichen Anteil an Rechenzeit
c) die Darstellung von Grafiken unangenehm lange dauert, weil zu viele sinnlose Daten eingelagert wurde

Wenn er sich sowieso mit sowas auskennt: kein Ding.

Mit verlaub - quatsch. Ich will, dass jemand der kein SQL kann den Inhalt der Datenbank erkennen und steuern kann. Namen ist kein Nerd-wissen. einfache Regexp muss ein Admin über kurz oder lang beherrschen.

Aber tenendtiell bn ich bei dir. DBlog ist m.E. an einigen Stellen zu komplex. Ich stelle die Frage, welche kommandos notwendig sind.
Include und Exclude würde ich auf include reduzieren
current und history MUSS  man einstellen und wer versteht das wirklich? Bei Grafiken muss man es einstellen - und dann wird immer history genutzt. Hm - warum muss ich den User damit belästigen?
=> ich habe mich nicht mit allen Optionen und Kommandos von DBlog befasst - aber ich meine dass einige nicht notwendig sind!
=> der User sollte einfache Kommandos haben, um festzustellen, was so in der DB steht, Daten abfragen kann (WYSIWYG) seine Filter prüfen kann. Das ist aktuell m.E. nicht der Fall.
=> wie schon viel weiter oben erwähnt würde ich ein "lean-DB" Modul bauen - da das aktuelle aus ( wie immer ) historischen Gründen nicht reformierbar ist.

===>>> wo will FHEM hin?

[martinp876]

Bei meinen nächsten Schritten (eigentlich will ich "relations" einmal sinnvoll und umfassend darstelen können) bin ich bei lightScene hängen geblieben.
Zuerst einmal nutzt lightScene nicht die Möglichkeit, "notify" vorfiltern zu lassen. Das ist erst einmal einfach und ich überneheme es für das Modul. Damit löse ich kein wirkliches Problem sondern nur eine Unsauber/Performace-verschwendung welche der Maintainer sicher nur übersehen hat. Bei diesem Modul ist es so einfach wie fast nirgends anderswo - und ebenso effizient.

De-fakto muss man nur "Modify" und "Define" von LightScene in der "config" Section abfangen und bearbeiten.
Nun, dann kommt man unweigerlich auf  das allgemeine "delete" und "rename".
Erst einmal definition
Config data / Config action / Config time
Die Configuration ist die Einrichtung des Systems. Bei FHEM ist dies primär das "Define" und die "Attr". Davon abgeleitet werden dann oft der HW geschuldete Einstellungen welche auch konfigurations Charakter haben.

davon abzutrennen sind
operational data
also readings.

Ich bin der Meinung, dass jede Entity (also der Maintainer des dazugehörenden Moduls) stehts zur Config Zeit die entsprechenden Daten prüfen muss und sämtliche Aktionen und Prüfungen druchführen muss. Eine Prüfung zur Laufzeit ist a) zu spät und b) nicht effizient.

Rename als Beispiel - hier das Modul LightScene
LightSzene nutzt explizit benannte "clients" welche gesteuert werden sollen. Ich befürworte folgendes vorgehen

• clients werden nur akzeptiert, wenn sich auch existieren
• Während der FEHM Init-Phase werden temporär undefined Clients akzeptiert - nach der Init-Phase ist aufzuräumen
• wird ein Client aus FHEM gelöscht muss er auch aus der LightScene Entity gelöscht werden
• wird ein Client umbenannt muss er auch aus der LightScene Entity umbenannt werden
• wie mit "Ignored"  clients zu verfahren ist muss LightScene selbst definieren

Das Ganze ist (aus meiner Nabel Sicht) natürlich generell zu betrachten. Es stellen sich die Fragen am Beispiel "Rename"

• was ist der Key einer entity? FUUID oder NAME
• soll ein rename machen, was rename suggeriert? Also "umbenennen ohne entlinken"?
• Eine Configuration wirklich zu prüfen und die Entites SEINES Module (aus Maintainer Sicht) auf Stand zu halten ist nicht unerheblich aufwand. Es ist aber lösbar - und es ist es auc meiner Sicht wert. Die Alternative ist, dass es der User machen muss
• soll ein Rename zur Entlinkung genutzt werden? Das ist aktuell fast durchgängig der Fall - und ich stimme nicht zu!
• die Prüfung der Konfig ist mit unter aufwändiger, insbesondere bei Regexp bspw bei Notify. das Notify sollte sich "enrolen" -auch wenn man regexp nutzt. Nun, bei Notify ist es mir egal, da ich mich hier selbständig gemacht habe. mein "ntf" enroled sich IMMER und bei JEDER Config Änderung korrekt beim Kernel.

Ich befürworte eine Festlegung, wie die FHEM Philosophie und somit die Richtlinie sein soll. Aktuel kann ich das nicht erkennen. gefühlt ist "schlanker Code" sowie "dont change - someone might complain" oder "da nicht alle mit machen sollte man es lassen" deutlich wichtiger als
"schlanke Bedienung"/"Vereintlichung"

[LutzG]

Hallo @martinp876,

ich kann zwar nichts produktives beisteuern, möchte aber Mal meinen Senf dazu geben.

Ich möchte dich nicht angreifen und kann (fachlich) nicht nachvollziehen, was du genau am Code bemängelst, aber, wie ich es verstanden habe, verdient niemand hier mit fhem seine Brötchen. Fast alle opfern ihre Freizeit um fhem zu entwickeln. Ein harter Kern leistet hier unermüdlich und unentgeltlich Support: Ubrigens, vielen Dank dafür!

Und, wie ich es verstanden habe, hat fhem nicht ein Einziger entwickelt und einige Entwickler sind nicht mehr aktiv, daher ist das für mich logisch:

gefühlt ist "schlanker Code" sowie "dont change - someone might complain" oder "da nicht alle mit machen sollte man es lassen" deutlich wichtiger als "schlanke Bedienung"/"Vereintlichung"

Und, wie ich es verstanden habe, lebt fhem von (konkreten) Vorschlägen, die die (freiwilligen / unfreiwilligen) Modulauthoren übernehmen können. Außer Kritik - die ich zwar fachlich fundiert und intertessant finde, ist bei mir nur der Vorschlag mit der Datenbank hängen geblieben, der aber, wegen zu tiefgreifender Änderungen, nicht übernommen werden kann.

===>>> wo will FHEM hin?

Ich empfinde dich fachlich kompetent, mach doch bitte Mal einen (konkreten) umsetzbaren Vorschlag! Mit deinen Know-How könnte ich mir vorstellen, dass du da schon Ideen hast.

Noch Mal, ich will dich nicht angreifen!

Viele Grüße,

Lutz

[Beta-User]

Mal wieder ein paar eher kurze Anmerkungen:

- Entgegen dem, was anscheinend angekommen ist, bin ich kein Verfechter von "don't touch, someone might complain". Ich habe nur Verständnis dafür, dass manche Maintainer keine große Neigung haben, sich Beschwerden von "normalen Usern" anzutun, indem sie irgendwas anfassen. (Bei fast allen Modulen, die ich zwischenzeitlich angefasst habe, hat sich irgendwas geändert - ich hoffe, meist zum besseren (leider nicht immer gleich und stressfrei))
- Deutlich befürworte ich auch "Vorgaben" für Maintainer, wie bestimmte Dinge gelöst werden sollten (und finde auch die "enroll"-Logig von deinem ntfy gut!). Fängt bei der Benennung von Readings an; dazu hatte ich hier mal einen Vorstoß gemacht: https://forum.fhem.de/index.php/topic,117933.0.html (Popcorn anyone?)

Über den Weg kann man streiten, und ich bin nicht wirklich happy, wenn zu den gegebenen Stichworten (v.a. attrTemplate) nichts zurückkommt, und ansonsten (gefühlt) eher Vorschläge kommen, dass alle Maintainer sich um (meine Meinung!) komplett unwichtige Dinge wie rename kümmern sollen. Dass ich das als löblich beschriebene Verhalten von LightScene für kontraproduktiv empfinde, hatte ich bereits dargelegt, und jedenfalls ich bin nicht bereit, in irgendeinem meiner Module großen Aufwand damit zu treiben, rename komfortabler zu machen. "rename" gehört m.E. nicht in Userhände, Namen sind "technisches Zeug", das nur der Admin anfassen sollte. User können gerne "alias" vergeben, aber das war es dann! (Die FUIID ist nicht wirklich portabel oder manipulierbar und daher  mAn. (intern!) eigentlich komplett irrelevant).

OT:
- Nebenbei bei Gelegenheit irgendwann mal diverse patches zu reviewen, und dann Rückmeldung dazu zu geben, in die andere einen gewissen Aufwand gesteckt haben, wäre auch nicht verkehrt.
- "private" Versionen sind ja schön und gut, aber eigentlich auch nicht Sinn der Sache. Selbst wenn diverse Vorschläge mehrfach (noch?) nicht aufgegriffen wurden, gibt es zuhauf Beispiele, dass gute und innovative Ideen dann irgendwann ihren Weg in die "allgemeine Code-Basis" finden. Und genau so sollte es auch sein.

[martinp876]

Ich habe nur Verständnis dafür, dass manche Maintainer keine große Neigung haben, sich Beschwerden von "normalen Usern" anzutun,...

ich verstehe das auch... auch wenn ich nicht dahinter stehe. Und natürlich nciht bedingungslos! - in jede Richtung.

Deutlich befürworte ich auch "Vorgaben" für Maintainer, ....

genau diese (oder besser : einige dieser) wollte ich hier anregen, diskutueren und dann festlegen (lassen).

und ich bin nicht wirklich happy, wenn zu den gegebenen Stichworten (v.a. attrTemplate) nichts zurückkommt, und ansonsten (gefühlt) eher Vorschläge kommen, dass alle Maintainer sich um (meine Meinung!) komplett unwichtige Dinge wie rename kümmern sollen.

nun, ich sehe hier keine Wertigkeit zwischen den beiden Elementen.  ich bin ein extremer Befürworter von "Templates" - wie genau "attrTemplate" funktionieren soll... ich kenne es halt nicht. Aber du weist sicher, dass ich schon an ein paar Stellen Templates eingeführt habe - mit mehr oder weniger Erfolg (gemessen an der Nutzung).

Bei LightScene werden ich wohl hand anlegen und eine "config-shell" dazu montieren. Das ist einfach zu lösen, kein großer Aufwand - und dann kann man das Modul-zentrische Denken näher an ein System-zentrisches Denken heranführen. Ich habe einmal aussenstehende befragt, was sie von einem "Rename" erwarten. Das Feedback war, dass ein rename die Verlinkungen um System nicht beeinflussen sollte (Paradebeispiel LightScene).

diverse patches zu reviewen, und dann Rückmeldung dazu zu geben

patches oder code? Bis auf grob schlechten Code ist es VIEL wichtiger, auf die Einhaltung von Regeln zu reviewen. Dann erst kommt der Code.

"private" Versionen sind ja schön und gut, aber eigentlich auch nicht Sinn der Sache.

sie sind nicht schön und gut. Aber privat und in der Verantwortung des Anwenders. Presence war schlicht unbrauchbar durch die kathastrophale Nutzung von Blocking - die Auswertung im Nachgang ebenso. Notify ist strukturell schlecht angelegt was das enrolen schon einmal schwierg macht. Ich habe ein alternatives Konzept vorgestellt, ist nicht angekommen. Es wird also keine Änderung auch nur in die Richtung geben. Das Modul kann ich leicht selbst stemmen - und ich störe auch niemanden, da es niemand sehen kann. FritzBox ... da hätte ich evtl auf Anpassungen warten können. Nun, ich habe nicht gewartet und es zusammen mit Presence und Notify effizient und allgemeingültig umgesetzt. Yamaha Stereo hatte nichts, was ich als User-Interface hätte gelten lassen - nicht bedeinbar. Nun, meine Änderungen sind hier angenommen worden - allerdings muss ich hier meinen Teil noch zurückführen... wenn ich Lust habe.

System-Zentrisch vs modul-Zentrisch am Beispiel LightScene und deviceNamen
LightScene benötigt nativ eine Liste von entites, welche "behandelt" werden.
- lightScene sollte nur entites "annehmen", welche auch existieren
- werden entities gelösche sollten sie auch aus LigthScene verschwinden
- werden entites umbenannt ist dies auch in LigthScene zu implementieren. Komplett und umfassend
- während Init hat man schon immer das Problem, dass man nicht weis, was noch kommt (Stichwort zulassen nur definierter entites). Hier ist - wie bei fast allen modulen : Während init wird alles zugelassen, mit EndInit wird aufgeräumt

Es gibt etliche Doku für Entwickler... ich kann garnicht alles lesen. So suche ich bspw was FUUID machen soll und warum das hässliche Teil so störend in Internals residert - und was es mir sagen soll. Nun, muss ich wohl im Code nachlesen. Ein Kapitel, was in Internals publikumswirksam angeboten werden sollte habe ich auf die Schnelle nicht gefunden.
ABER: CoProcess scheint ein Lichtblick... muss ich einmal untersuchen

[Beta-User]

wie genau "attrTemplate" funktionieren soll... ich kenne es halt nicht. Aber du weist sicher, dass ich schon an ein paar Stellen Templates eingeführt habe - mit mehr oder weniger Erfolg (gemessen an der Nutzung).

Bei CUL_HM ist es eine Insellösung. Das Hilfsmodul AttrTemplate ist eine (selbständig nutzbare) Erweiterung zu SetExtensions und daher im Prinzip von jedem Modul nutzbar - und zwar so, dass eben gerade NICHT der Maintainer alle Hardware dieser Welt haben muss, um "Vorschläge" (!) für (hautpsächlich, aber nicht exklusiv!) Attribute (oder Attribut-Sätze) bereitstellen zu können. Selbstredend könnte (!) man die auch z.B. per Timer nach $init_done anwenden lassen, falls man "fertig vorkunfigurieren" will.

Das versuche ich jetzt zum x-ten Mal zu vermitteln, aber "jemand" will (gefühlt) unbedingt die Maintainer mit umfassenden Konfigurationsaufgaben tracktieren. Unverständnis meinerseits, warum du das noch nicht angesehen hast (zum Testen: nimm HTTPMOD und - sagen wir - updates für Homematic, Benzinpreise, einen Wasserstand in deiner Nähe...).

Ich habe einmal aussenstehende befragt, was sie von einem "Rename" erwarten. Das Feedback war, dass ein rename die Verlinkungen um System nicht beeinflussen sollte (Paradebeispiel LightScene).

Das ist mir schon alles soweit klar. Es ist nur schlicht und ergreifend nach meiner persönlichen Bewertung völlig am Thema vorbei und "Elfenbeinturm". "rename" gehört nach der Ersteinrichtung eines devices in die Giftkiste und basta! Man mache sich einmal Gedanken für ein vernünftiges Namensschema und damit sollte es sich im wesentlichen haben.

patches oder code? Bis auf grob schlechten Code ist es VIEL wichtiger, auf die Einhaltung von Regeln zu reviewen. Dann erst kommt der Code.

Wieder Theorie. Klar sollte man erst wissen, was eigentlich wie gelöst werden sollte. Aber nebenbei bekannte Problemchen zu lösen (konkret: in CUL_HM) schadet doch nicht, zumal, wenn es funktionierenden Code gibt...

Presence war schlicht unbrauchbar durch die kathastrophale Nutzung von Blocking - die Auswertung im Nachgang ebenso.

Da bin ich völlig bei dir und wundere mich bis heute, warum der Maintainer den Ball nicht aufgenommen hat. Vermute: Du hast ihn irgendwo verloren - entweder fachlich oder alleine wegen des Tones, keine Ahnung. Aber mind. das Blocking-Thema MUSS m.E. Eingang in die allgemeine Code-Basis finden.

FritzBox ... da hätte ich evtl auf Anpassungen warten können. Nun, ich habe nicht gewartet und [...]

Da wäre es super, wenn du ggf. mal einen Blick auf die aktuellen Aktivitäten von JoWiemann werfen könntest. Der aktuelle offizielle Maintainer ist leider grade sehr ruhig.

Yamaha Stereo hatte nichts, was ich als User-Interface hätte gelten lassen - nicht bedeinbar.

Falls das YAMAHA_AVR ist: Da bin  zwischenzeitlich ich der Ansprechpartner und würde mich freuen, wenn du mir einen Link oä. hättest, damit ich mir das mal ansehen kann. Falls Patch: Bitte nicht gegen die aktuelle Version laufen lassen, da ist sehr viel (ausnahmsweise soweit erkennbar geräuschlos) geändert, sondern gegen eine, die ein paar Monate alt ist.

- während Init hat man schon immer das Problem, dass man nicht weis, was noch kommt (Stichwort zulassen nur definierter entites). Hier ist - wie bei fast allen modulen : Während init wird alles zugelassen, mit EndInit wird aufgeräumt

Das Prinzip ist super und hat in der Regel Einzug in meine Module gefunden.
Schade ist eigentlich nur, dass fhem.pl das nur bedingt unterstützt und man bei CUL_HM solche Klimmzüge veranstalten muss, dass das zum richtigne Zeitpunkt aufgerufen wird...

So suche ich bspw was FUUID machen soll und warum das hässliche Teil so störend in Internals residert - und was es mir sagen soll. Nun, muss ich wohl im Code nachlesen.

Da steht es vermutlich auch nicht, es gibt aber den "Einführungs-Thread": https://forum.fhem.de/index.php/topic,95902.0.html

ABER: [...] scheint ein Lichtblick... muss ich einmal untersuchen

Korrekt: es ist durchaus Bewegung in manchen Dingen drin, man muss nur die Augen aufmachen .

[martinp876]

so, nun habe ich noch einmal über Beta-User's einwandnachgedacht, was am loggen nun nerdisch ist und das User-geeignet.
Eigentlich ist user-geeignet ein vorgehen, bei welchem man nicht zwischen File und DB entschieden muss. Der User will nur, dass Readings schnell, effizient, platzsparend gesichert werden und dass man sie abfragen kann - automatisch für Graphen und manuell zum Nachvollziehen von Eregnissen. Und extrahieren nach - typisch - ein Tabellenformat (csv?)
genau dieses Interface werde ich mir schaffen - entschlacken des DBlog durch ein encapsulation-modul. Damit will ich nicht wieder ein Modul privatisieren.

und dann denkt man einmal kurz nach und fragt sich (als nerd) warum dblog anstatt filelog? Ich habe es gemacht, um eine schnellere und effizientere Verarbeitung zu bekommen. Jetzt kommt das  nachdenken und die DB Struktur:
Wir haben EINE Tabelle mit device, reading, value, timestamp, module, unit,reading$value&unit
das ist reiclich ineffizient und einer DB nicht würdig. Nimmt man sich die 15min welche notwendig sind, eine grundsätzliche Struktur der DB zu erstellen kommt man auf

• Tabelle "entity" mit eID, entity(device), module
• Tabelle "reading" mit rID, reading(name), unit,format(optional)
• Tabelle "record" mit eID, rID, value, timestamp
• Tabelle "timerange" mit tID,year, month (optionale Tabelle für schnelle Indizierung der Zeiten)
• Tabelle "valueList" mit vID,rID,value (optionale Tabelle, sehr effizient, in FHEM wohl eher nicht durchsetztbar)

das ist dann einer Datenbank würdig - vielleicht kann es einer noch besser. Die Vorteile liegen auf der Hand - ich wiederhole:

• ein "Record" wird kleiner, da nicht immer Device und Reading  als string gespeichert werden. Unit und Type entfallen
• das suchen müsste deutlich schneller werden, da nach keys gefiltert wird, was eine datenbank gerne macht
• ein rename eines Device ist ein spaziergang: ein einziges Record wird umgestellt und fertig
• einem Device (entity) kann man leicht weitere Parameter zum Filtern zuordnen - kostet nix mehr
• indizierter timerange ist effizient
• eine optionale Tabelle eID, rID könnte geführt werden um schnell Übersichten erstellen zu können

Oh man, beta-user - was tust du mir an. jetzt steckt das im Kopf und ich werden mit der aktuellen Implementierung nie mehr zufrieden sein. Das läuft leider wieder auf eine private Lösung hinaus.

Und hier wiederhole ich von weiter oben: Auf Basis der Erkenntnisse der aktuellen Implentierung plädiere ich für eine "lean" version des DBlog. Eine Evolutionslösung sehe ich nicht mehr - das kann man nicht mehr verkaufen. Eine Revolutionslösung ist erforderlich.

Die aktuelle Implementeirung overall macht an einigen Stellen dem Entwickler einen schlanke Fuss, an anderen Stellen sind Sonderlocken für ambitionierte Spezialuser im Einsatz. Weiter fehlen Anpassungen an die "best current practice" von fhem wie (das oft nicht eingehaltene Gebot) die Anbindung an Notify. Und dann sind mittlerweile Optimierungen naheliegend.
=> was bleibt mir also übrig? private, wenn ich in absehbarer Zeit Resultate sehen will
=> schon allein die unverständliche Implementierug zu "get start/end Value for SVG range retrieve" ist seit Jahren unbefriedigend und nur mit absolt hässlichen prozessen lösbar. Es hat mich 2h gekostet, es umfassend und befriedigend zu lösen - wenn ich die Funktion privatisieren.

Schade, dass FHEM doch so resistent ist gegen systematisch Ansätze... meine Nabel-Sicht

[martinp876]

Bei CUL_HM ist es eine Insellösung.

korrekt. Hier handelt es sich um 2 Ansätze: Device-programming und Temperatur-Profile
Ersteres kann man m.E. nicht generisch machen, da device-programming sicher bei anderen familien auch angesagt ist - aber ein program/verify/reload sehr unterschiedlich sein kann/wird.

CUL_HM stellt überhaupt keine Attribut-Sätze zu Verfügung - hier kann man gerne (nein, man sollte) eine allgemeine Lösung nutzen. Machbar ist das aber nur für wirklich User-steuernden Attribute.

Selbstredend könnte (!) man die auch z.B. per Timer nach $init_done anwenden lassen, falls man "fertig vorkunfigurieren" will.

Falscher Ansatz. Es gibt ein Event  nach Init-done. Das ist zu nutzen. Timer ist quatsch (ok, hatte ich auch einmal ...)

aber "jemand" will (gefühlt) unbedingt die Maintainer mit umfassenden Konfigurationsaufgaben tracktieren.

verstehe ich nicht. Wer ausser der Maintainer kann das? reden wir von unterschiedlichen Dingen?
Beispiel LightScene. Angenommen mein Ansatz ist
define myScene LightScene Dev1 Dev2 Dev3
=> wenn Dev2 nicht existent ist, dann... a) verweigere ich das Kommando (2nd best) b) lösche ich Dev2 aus dem Define und habe ein
define myScene LightScene Dev1 Dev3
Um das rund zu machen muss ich wissen, welche einträge in meinem Define (oder Attribut?) relevant sind für diese Prüfung. Vorhanden sein ist ja nur eine Option - was mache ich mit "ignore"?
Der Code ist also abstrakt

Code Auswählen Erweitern


notify global initialize
   # init is done, all entites are defined and attributes are set - generik define is done
   # no check my lightScene entites
#   foreach (entity with type lightScene){ no necessary if called per lightScene entity
     foreach (device associated with entity){
       remove from definition if (dvice not defined);
     }   
#   }
notify global rename
   modify defintion, rename device if (oldname is used by lightScene)
notify global delete
   modify defintion, remove device if (oldname is used by lightScene)

ggf kann man "ignore" noch betrachten... würde ich aber nicht löschen, nur ignoreiren.
wer ausser dem ModuleOwner weiss, welche Beziehung wie gestaltet werden soll? In CUL_HM sind direktverknüpfungen bspw eine andere Kategorie .

Unverständnis meinerseits, warum du das noch nicht angesehen hast

verstehe nicht, was du in diesem Kontext meinst.

"rename" gehört nach der Ersteinrichtung eines devices in die Giftkiste und basta!

sorry, nee. Das geht besser. Da spiel ich nicht mit. Warum sollte ich auch? FHEM ist hier einfach schlecht aufgestellt. Das hättem an besser machen können - und man kann. Typisch ist ein Name ein Attribut  - bei FHEM ist es ein, nein DER Key. Und obendrein habe wir noch eine "NR" und eine "FUUID".
De facto könnte man die korrelationen zwichen den devices wie eine DB aufsetzen. Ein (typischerweise hidden) key wird für Verknüpfungen "intern" genutzt. Der User sieht Namen, klar. Die Keys könnte man ansehen, wenn man das normale Frontend nutzt muss man es nicht.
FHEM hat hier EINIGE strukturelle Defizite

Aber nebenbei bekannte Problemchen zu lösen (konkret: in CUL_HM) schadet doch nicht, zumal, wenn es funktionierenden Code gibt...

klar sollten Probleme gelöst werden, das ist kein entweder/oder. Am Besten gleich in die richtige Richtung. Da sind wir schon bei einander.

Du hast ihn irgendwo verloren - entweder fachlich oder alleine wegen des Tones, keine Ahnung. Aber mind. das Blocking-Thema MUSS m.E. Eingang in die allgemeine Code-Basis finden.

Ich bin sicher direkt, aber will nicht verletzende sein. In diesem Fall ist das Modul - und das ist eben Fakt - tötlich. Das kann ich nun einmal nicht schön reden. Man kann es unterschiedlich Lösen - und die Meinige ist sicher nur eine.
Ich könnte meine Lösung zu Verfügung stellen (eine Version ist schon irgendwo im Forum). Es ist -noch- allgemein nutzbar. aber ich habe schon den Commandparser genutzt auf den ich nie mehr verzichten werde! Irgendwann werden ich auf co-process umstellen und das Blocking komplett aus "meinem" presence nehmen. Sogar das um faktoren schlankere blocking ist unpassend an dieser Stelle.

Fritzbox

kann ich einmal ansehen. Ich habe die interne Struktur umgestellt, die Darstellung auf der Front und insbesondere das Handling der aktiven/inactive network-devices. FB ist ein sehr komplexes Gebilde und man muss sich erst einmal klar werden, was es eigentlich bedeinen soll. Das ist "allgemein" ziemlich schwer. Ich habe meine Entscheidungen getroffen. Mal sehen, ob ich zurück kommen kann.
Wie aber kann man "varianten" folgen, also bspw JoWiemann? Ich bin  nicht in der Lage, vielen Threats im Forum zu folgen - keine Zeit.

YAMAHA_AVR

nein, YAMAHA_NP. Das wichtigste fehlende Element war die "Senderwahl". man konnte eigentlich alles einstellen. Quelle/stream/song - also bspw Radio/network/Group/AntenneBayern
=> die Hierarchie ist komplex bei Yamaha.
Als User will ich "favoriten" verwalten können.
a) ich hangele mich zum Stream (Yamaha bietet das "seitenweise"-immer 16 Einträge, dann Bllättern- an - das will ich NIE sehen am Frontend
b) ich gehe auf "memory" , also definieren den Stream als Favorit
c) ich kann favoriten direkt anwählen. Die Anlage startet/wählt die Quelle/hangelt sich durch die internen Tabellen/ startet den Stream
d) dasdirekte Anwählen eine favoriten muss blind aus jeder Lebenslage funktionieren.
das ist die primäre Aufgabe einer Fernbedienung.

man bei CUL_HM solche Klimmzüge veranstalten muss,

ich denke da bin ich mittlerweile weiter... nur noch nicht implementeirt in CUL_HM. Das dortige funktioniert aber auch stabil - kein Grund zu ändern, ausser schönerer Code.

es gibt aber den "Einführungs-Thread"

und da rollen sich meine Zehennägel. Thread... das ist eine Diskussion. Wie wäre es mit einer Definition? ne, dann werde ich es weiter ignorieren.
Gilt auch für diesen Threat: Sollte etwas zählbares herauskommen so muss es dokumentiert werden - sonst ist es faktisch nicht existent. Threat ist keine Doku.

Korrekt: es ist durchaus Bewegung in manchen Dingen drin, man muss nur die Augen aufmachen

zum einen bin ich ungeduldig ungd löse meine Probleme bei auffinden und zum anderen habe ich nicht die Zeit so viele Threats zu überprüfen, ob sch doch einmal etwas tut. Wir werden sehen.

Ich deute auf die Probleme! Wenn ich insgesamt unzufrieden wäre und die Probleme nicht lösbar ersceinen würden hatte ich kein fhem mehr.

[Beta-User]

CUL_HM stellt überhaupt keine Attribut-Sätze zu Verfügung - hier kann man gerne (nein, man sollte) eine allgemeine Lösung nutzen. Machbar ist das aber nur für wirklich User-steuernden Attribute.

Anlass der Diskussion waren u.a. auch zu häufige Events. Da sind wir bei "commStInCh off" und den "readingFnAttributes" => in dem Teil machbar (falls der Maintainer sich nicht sowieso für den ersten Punkt für einen anderen default entscheidet)...

Code Auswählen Erweitern

Falscher Ansatz. Es gibt ein Event  nach Init-done. Das ist zu nutzen. Timer ist quatsch (ok, hatte ich auch einmal ...)
Event ist m.E. auch nicht der beste Ansatz. Ein spezieller Aufruf aus fhem.pl heraus wäre eigentlich richtig. Jedenfalls ist es Unsinn, eine notify-Funktion nur zu dem einen Zweck zu bauen und dann bei praktisch allen Instanzen zu deaktivieren (alleine das Gelumpe, um rereadcfg funktional zu machen...!)

Und ob es Attribute geben muss, die nicht dem user-Zugriff unterliegen, ist eine weitere solche Frage in Richtung fhem.pl. MAn. bräuchte man eine eigene Kategorie von (Konfigurations-) Infos, die in der cfg gespeichert werden, aber dem User-Zugriff prinzipiell entzogen sind (und/oder nur per ausdrücklichem "force" vom User geschrieben werden können).

verstehe ich nicht. Wer ausser der Maintainer kann das? reden wir von unterschiedlichen Dingen?

Der Maintainer kann und muss sich um strukturelle Dinge kümmern. Aber jedes Einzeldevice mit seinen Sonderlocken nachzupflegen, ist nicht sinnvoll. Siehe aktuelle Probleme bei "Shelly" mit den 2nd. Gen-Geräten. Wenn irgend möglich, sollte man die Gerätekonfiguration im Detail und die Modulfunktionalität möglichst trennen (ähnlich wie ZWave das macht).

Beispiel LightScene. Angenommen mein Ansatz ist
define myScene LightScene Dev1 Dev2 Dev3
=> wenn Dev2 nicht existent ist, dann... a) verweigere ich das Kommando (2nd best) b) lösche ich Dev2 aus dem Define und habe ein
define myScene LightScene Dev1 Dev3

Nogo! Wenn der User "Unsinn" haben will, MUSS ihm das Programm zurückmelden, dass er irgendwas falsch gemacht hat und das so nicht klappt. Und zwar möglichst so, dass er es verstehen kann.

Betr. LightScene (ich habe das nicht bestellt!): https://forum.fhem.de/index.php/topic,131193.0.html
Es müßte also entweder eine "silent"-Option für rename geben, oder eine "replace"-Option in LightScene.
Der Aufwand steht in keiner Relation zum Ertrag, jedenfalls solange, wie der NAME DAS Key-Element zur Identifizierung eines Gerätes in FHEM ist. Wenn es Pläne gäbe, das zu ändern, gerne, aber solange das so ist, gehört rename weiter in die Giftküche!

verstehe nicht, was du in diesem Kontext meinst.

Ich versuche dir nun zum x-ten Mal zu verklickern, dass das zumindest in Teilen Teil der Lösung sein kann, du "maulst" weiter darüber, was alles angeblich nicht "gut" ist. Ich verstehe also schlicht nicht, warum du dir das nicht ansiehst. Es wäre einfach, also kommt es bei mir als hartnäckige Weigerung an, die (in manchen Bereichen) etablierten Lösungsansätze wenigstens zur Kenntnis zu nehmen.... Gleiches Spiel wie mit dem Threshold bei event-on-change-reading.

sorry, nee. Das geht besser. Da spiel ich nicht mit. Warum sollte ich auch? FHEM ist hier einfach schlecht aufgestellt. Das hättem an besser machen können - und man kann. Typisch ist ein Name ein Attribut  - bei FHEM ist es ein, nein DER Key. Und obendrein habe wir noch eine "NR" und eine "FUUID".

Ja, es ist historisch gewachsen und schlecht vermittelbar. OK, geschenkt. Aber es ist Fakt. Also kann man für den Moment nicht anders, als "rename" in die Giftküche zu verbannen.
Und ja, in einer schönen neuen Welt würde man statt "NAME" vielleicht "Identifier" schreiben, und ja, die Idee, die ganzen Verknüpfungen und "Vielleicht"-Abhängigkeiten noch besser transparent zu machen (aus der cfg heraus!), würde ich auch unterstützen!

Ich bin sicher direkt, aber will nicht verletzende sein. In diesem Fall ist das Modul - und das ist eben Fakt - tötlich. Das kann ich nun einmal nicht schön reden. Man kann es unterschiedlich Lösen - und die Meinige ist sicher nur eine.

Mir ist das klar, und ich mag nicht weiter spekulieren, warum das bisher nicht aufgegriffen wurde und würde mir nur wünschen, dass es aufgegriffen wird (auf welche Weise auch immer das Problem dann schließliuch gelöst wird).

Wie aber kann man "varianten" folgen, also bspw JoWiemann? Ich bin  nicht in der Lage, vielen Threats im Forum zu folgen - keine Zeit.

Modulversionen in Threads sind ein Problem, und die Hoffnung ist, dass das irgendwann offiziell eingecheckt wird. Es gab aber auch noch ein paar ungelöste Probleme, die zuerst (erprobt) gelöst werden sollten.

nein, YAMAHA_NP.

OK, da bin ich dann mangels Nutzung raus.

ich denke da bin ich mittlerweile weiter... nur noch nicht implementeirt in CUL_HM. Das dortige funktioniert aber auch stabil - kein Grund zu ändern, ausser schönerer Code.

Klingt interessant. Ich war jedenfalls froh, endlich überhaupt funktionalen Code zu haben, der dann immer zum richtigen Zeitpunkt ausgeführt wurde... Bessere Unterstützung von fhem.pl wäre wünschenswert, s.o..

und da rollen sich meine Zehennägel. Thread... das ist eine Diskussion. Wie wäre es mit einer Definition? ne, dann werde ich es weiter ignorieren.

Du wolltest Infos. Der Thread ist nicht lang, und evtl. findet sich ja ein Mitleser, der die wesentlichen Punkte ins Wiki übernimmt (falls da nicht schon was zu finden ist).

Gilt auch für diesen Threat: Sollte etwas zählbares herauskommen so muss es dokumentiert werden - sonst ist es faktisch nicht existent. Threat ist keine Doku.

Fully agreed. whodunnit?

zum einen bin ich ungeduldig ungd löse meine Probleme bei auffinden und zum anderen habe ich nicht die Zeit so viele Threats zu überprüfen, ob sch doch einmal etwas tut. Wir werden sehen.

Auch klar. Es ist nur frustrierend, wenn dann nicht mal auf expliziten Hinweis die Bereitschaft da zu sein scheint, vorhandene Ansätze/Infos/whatever zur Kenntnis zu nehmen.

Es ist nun einmal Realität, dass "die Doku" nicht perfekt ist, und es auch keinen gibt, der das leisten könnte, eine perfekte Doku zu erstellen.

Ich deute auf die Probleme! Wenn ich insgesamt unzufrieden wäre und die Probleme nicht lösbar ersceinen würden hatte ich kein fhem mehr.

Mir ist das klar. Nicht alle kommen aber mit dem Ton (und der fachlichen Höhe der Kritik) klar. Das ist so richtig schade...

[martinp876]

ok, werde CUL_HM werde ich einmal prüfen... und hoffentlich auf einen besseren Stand bringen. Werde dich informieren.

Event ist m.E. auch nicht der beste Ansatz. Ein spezieller Aufruf aus fhem.pl heraus wäre eigentlich richtig.

prefekt - aber nicht zwingend.

Jedenfalls ist es Unsinn, eine notify-Funktion nur zu dem einen Zweck zu bauen und dann bei praktisch allen Instanzen zu deaktivieren

nun, fast richtig. Du sprichts insbesondere Familien mit mehreren oder vielen entites an (bspw CUL_HM). Ich verfolge hier den Ansatz des "modul-notify". Typisch wird im Modul eine Notify Funktion instanziiert und dann werden alle Modul-entites damit beglückt. Ich habe (und hoffenrtlich macht das jeder andere Maintainer auch so) nur eine Instanz, welche enroled ist. Ich schalte alle anderen Instanzen auf "disableNotifyFn". Aber... aber... 'eigentlich' sollte es ganz anders gelöst werden. Die FHEM Struktur ist zu schwach ausgebildet.
- Eigenlich will ich in so einem Fall ein Notify für das Modul - keine der Instanzen muss notifiziert werden.
- eine Modul-Instanz existiert - nur schemenhaft. Das ist echt schade.
-- bei Modulen welche nur eine Instanz haben (oder typisch nur eine...) macht es keinen Unterschied (HmInfo,HmTemplate, DbLog, DbRep,....)
-- bei CUL_HM habe ich die Modul-Instanz schon häufig schmerzlich vermisst. HMInfo gibt es ausschliesslich, weil ein ein CUL_Module nicht visualisiert werden kann. Auch ActionDetector wäre nicht existent oder notwendig. Alles Workarounds um die schwache Architektur von FHEM an dieser Stelle
=> eine schlanke Implementierung lässt sich erreichen - dank der schwachen FHEM Architektur aber nur umständlich
=> eine Modul-Instanz könnte so viel...
#-> fhem unterscheidet nur sehr schwach zwischen den Datentypen. Ich sehe hier "Config" und "Reading". "Internal" ist ein ungeordnetes Durcheinander - sowohl vom Inhalt als auc in der Darstellung (alphabetisch ist formal eine Art der Sortierung, aber eigentlich doch sehr schwach - na halt einfach zu implementieren)

EIGNTLICH... ist es nicht ausreichend zu Informieren, wann der Kernel mit init fertig ist. Es könte noch abhänggkeiten zwischen den Modulen geben... ok, das kann jeder Maintainer abfangen. Man muss dann klar erklären, wie der Ablauf ist.
Einen sauberen Ablauf bei Startup hinzubekommen bedarf des Nachdenkens - und der klaren Kommunikation, dass ein Maintainer es nachschlagen kann. Ich sehe hier
- einlesen aller define und attr OHNE Prüfung in den Module (AttrFn nicht aufrufen) Ich schalte es in den meisten Modulen ab.
- in der post-init phase prüft jedes Modul (oder jede Entity) die Attribute und schiebt diese durch die AttrFn. Interne Abhängigkeiten werden erzeugt. Änderungen (falls Failed) werden über AttrFn gesetzt und alle werden informiert und reagieren ihrerseits
==> das ist für FHEM zu groß - muss doch jeder selbst.

EIGENTLICH.... brauche jedes Modul hier oder da ein Notify für Config-changes (also global). Irgend eine Abhängigkeit haben alle

Und ob es Attribute geben muss, die nicht dem user-Zugriff unterliegen ist eine weitere solche Frage in Richtung fhem.pl. MAn. bräuchte man eine eigene Kategorie von (Konfigurations-) Infos

100% Zustimmung. So lange es keine Konfig-Section gibt ist das eben best-effort. Ich sehe keine Möglichkeit, so etwas durchzusetzen. Wenn du es schaffst - ich bin dein größter Fan. Ich stehe hinter dir (da ist es nicht so gefährlich )

Nogo! Wenn der User "Unsinn" haben will, MUSS ihm das Programm zurückmelden, dass er irgendwas falsch gemacht hat und das so nicht klappt. Und zwar möglichst so, dass er es verstehen kann.

Betr. LightScene (ich habe das nicht bestellt!): https://forum.fhem.de/index.php/topic,131193.0.html
Es müßte also entweder eine "silent"-Option für rename geben, oder eine "replace"-Option in LightScene.

eine Modulspezifische Lösung für rename/replace ist nicht akzeptabel. Da sind wir uns sicher einig. Ich sehe gelegentlich, wie module-owner eigene Lösungen in Modul-Kommandos giessen, weil sie die Generelle Lösung nicht kennen/verstehen oder als nicht ausreichend empfinden. Oder eine Mischung, weil der Aufwand, das generelle Vorgehen zu nutzenAufwand bedeutet. Die Extra-Meile ist zu lang.  Der einfache Weg ist - mache es selbst. Sehr schade

Zu LightScene - ich bin wieder einmal leicht enttäuscht. Nun ja, lässt sich leicht beheben. Es zeigt aber sehr schön die Schwachstellen.
Ausgangspunkt: Ich habe nun LightScene "an Config angebunden" was bedeutet, dass LightScene define/modify abgefangen werden und sämtliche Rename/delete geprüft werden. Selbstverständlich auch die Startup Phase berücksichtigt. Kostet max 20 Zeilen code in einem separaten Modul (eine Funktion!) plus - sagen wir 20 Zeilen in einer notify function welche "global" (also config) abfängt.
Die Erkenntnisse:
LightScene erlaubt das eintragen jeglicher Strings als Entity ohne jegliche Prüfung. Finde ich schlecht, kann man aber machen. Trägt man jedoch auch nur eine nicht existente Entity ein kommt es (an einer Stelle) zu etlichen Fehlermeldungen.
=> LightScene erlaubt nicht-existente devices, behandelt es aber nicht. Ich haben icht alle probiert... zumindest eine Stelle existiert
Wie sollte nun ein Modul (Beispielhaft LightScene) funktionieren

• alle eintites werden erlaubt
  der Umgang mit nicht existenten Devices muss abgefangen werden, an allen Stellen
  dem User sollten nicht existente Devices deutlich gemacht werden
  Grundsätzlich ein geschmeidiger Weg, löst viele Probleme - wenn KOMPLETT implementiert
• nur instanziierte Devices werden erlaubt (mein Favorit)
  der User muss auch hier unformiert werden über falsche Einträge
  ich würden die nicht akzeptierten Devices aus der Liste entfernen, alle anderen zulassen und eine Info absetzen (bis auf die Info habe ich schon alles)
  
• notifications
  lightScene muss sich für notifies enrolen. Hierzu muss es sich selbst bei "global" enrolen (hätten wir eine Modul instanz könnte diese den Job cool übernehmen). Sämtliche rename/delete sind zu prüfen!!! 
• rename
  bei einem Rename ist die Entität in der Deviceliste ebenfalls zu renamen und alle davon abhängigen Schritte sind einzuleiten.
• delete
  in Fall 1 ist das Device einfach auf "failed" zu setzen - User Notifikation.... dafür muss aber auch jedes Define abgfangen werden. Sollte ein Device mit diesem Namen inkarniert werden muss man sich enrolen.
  In fall 2 werden gelöschte Devices entfernt, definitionen sind nicht zu betrachten. Fehlermendungen gibt es nicht, da Löcschen eben löschen ist - umfassend.
• Device list in define
  In FHEM ist es common practice in der Defintion die Attribute mitzugeben. Eine (sehr schwache) Art, die fehlende Config-Section zu umgehen. Baue ich ein Modul wird das nie der Fall sein. Pro/Contra:
  die Pro liste ist kurz: Man kann die Attribute im Define mitgeben.
  Die Kontra-Liste ist schon länger:
  - man kann gerne Attribute beim Define mitgeben - diese dann aber nach "attribut" eintragen ("config" existiert immer noch nicht)
  Wäre die Liste der Devices einer LightScene Entity als Attribut verankert könnte man diese einfach editieren. Man könnte drop-down listen zur Selektion nutzen. Ein LightSzene ohne Devices ist möglich (eine leere Hülle) welche initial erstellt wird. Aktuell wird das abgelehnt (seltsam - ich kann ein nicht existentes Device eintragen, nicht aber eine leere Liste

Ich höre hier einmal auf.... die Details machen die Musik - und da gibt es etliche.

Du wolltest Infos. Der Thread ist nicht lang, und evtl.

ich unterscheide Dokumentation und Implementierungen sowie Diskussionen. Eine Doku beschreibt das Verhalten, die klaren Regeln, den Ist-Stand wie es gelöst ist. Das gehört in ein Dokument - wegen mir Wiki. Hier steht, was fakt ist - hinreichend tief um es umsetzen zu können - zumindes für SunnyDay. Ich sollte die Chance haben, es verstehen zu können.
Diskussionen sind fortlaufend - es kommen Details hinzu, werden verworfen,... abgewandelt.... irgendwann wird es implementiert und sollte dokumentiert werden. Diskussionen haben exterm wenig in dokumentation verloren (aushanmen sind möglich)
Implementierungen können in die Doku einzug halten. Gerne auch in Threats und Erlebnisberichten - wie hat jemand etwas besonderes gelöst. Threats sind hier üblich, möglich und absolut ok.
Doku im Threat lehne ich ab weil typisch schlicht nirgendwo das Ergebniss steht und ich probieren kann, ob der gelesene Diskussionsstand nun auch realisiert wurde - und in welcher Form

Wenn dire Doku nicht perfekt ist, ist das ok. Perfekte Doku ist WIRKLICH anstrengend. Grundsätzliche Doku wäre aber wünschenswert. Betrachte ich einmal meine Schuldigkeit (CUL_HM) meine ich, nicht sooo schlecht da zu stehen. Grundsätzliche Doku ist (immer noch) in einer Sektion des Einsteiger Dokuments vorhanden. Das habe ich damals so gut ich kann umfassend erstellt (natürlich nicht perfekt!!!) und es hat immernoch Gültigkeit, ich meine uneingeschränkt.
Kommandos sind im commandref unddie Syntax in get cmdList überall enthalten. Perfekt? sicher nicht. Ich denke aber keine schlechte Basis.

Ich habe mich mit coProcess befasst kurz. Hierzu gibt es ein Wiki - super, da kann ich als einsteigen. Schade, zu früh gefreut.
Es gibt ein Kapitel "Starten und Stoppen" - alles klar.
Beschrieben ist ein Komamndo start, stop und dann noch terminate.
What the hack--- sorry, wenn ich jemanden auf die Füsse trete aber ehrlich - das kann ich nur in die Tonne treten.
Terminate ohne incarnate. Wasa macht terminate? Was macht stop? was start?

dann cmdFn. offensichtlich ein get kommando.
Wo ist den der Prozess beschrieben, welcher gestartet werden kann? ist das eine perl funktion?
ok, die WikiSeite ist im Aufbau - die Funktion wird aber schon in verschiedenen Module verwendet.
Was soll ich sagen - die Doku (wiki) kann sicher noch werden- Ist-Stand ist, dass es akum zu lesen wert ist und man sich wohl wieder einmal an den code halten muss.
Und wieder einmal frage ich mich, warum es ein shutdown und ein delaiecshtdown geben muss . Wäre nicht ein Delay-timer als Parameter sinnvoll? Dann machen die auch noch etwas anderes. einmal terminale und einmal stop. einmal mit reason, einmal ohne. Und jeder ausser mir versteht sicher, was passiert. Ich werden den Code inspizieren MÜSSEN um es zu verstehen. Code ist sehr oft die einzige wirkliche Dokumentation.

Ich stoppe hier einmal  - ich komme schon wieder von einem zum anderen Thema.
Wäre schon, einmal ein paar Pflöcke in die so grüne Wiese der FHEM Ziele zu schlagen. Wir verwenden nur verschiebbare Marker. Jeder macht was er will und alle machen mit. Und dann müssen sich noch alle an den einen Anpassen, wenn er eine neue Locke frisiert hat. Das hält einen geistig flexibel

[Beta-User]

Kurz: Die Idee einer "ModuleNotifyFn()" finde ich zumindest für den ersten Eindruck klasse. Falls das "alle GLOBAL"-Events wären, würde man damit (so die immer zuerst aufgerufen würden!) auch dieses verwurstelte Initialisierungsthema in CUL_HM sauber lösen können und könnte auf einen separaten Routinen-Aufruf dafür verzichten...

[martinp876]

Die Idee einer "ModuleNotifyFn()" finde ich zumindest für den ersten Eindruck klasse.

wie gesagt, habe ich schon realisiert (CUL_HM). Alles andere wäre wahnsinn!. Aber das darf nicht das Ende der Fahnenstange sein. Das Modul könnt viel mehr können.

Falls das "alle GLOBAL"-Events wären, würde man damit (so die immer zuerst aufgerufen würden!) auch dieses verwurstelte Initialisierungsthema in CUL_HM sauber lösen können und könnte auf einen separaten Routinen-Aufruf dafür verzichten...

unklar. Die Routine brauche ich sowieso. Nur der Trigger wäre anders. CUL_HM Konzept zum Init:
Aufgabe:
+ CUL_HM hat als "HW-familie" sehr viele Entites (mit unter). Notifications je Entity sind möglich - aber alles andere als effizient
+ Attribute und Konfigurationen parsed CUL_HM (wie jedes verantwortliche Module) bei der Eingabe. Wenn man eine "relation" zu anderen entites herstellt muss diese möglich und gültig sein
    Es ist somit selbstverpflichtung, das "prüfen" durchgängig und IMMER aufrecht zu erhalten (auch wenn anstrengend). Das bedeuted
    ++ bei/nach init
    ++ bei config-changes JEGLICHEN devices
+ fhem initialisiert bei Startup entites alsauch deren Attribute in zufälliger Reihenfolge. Eine Prüfung der Relationen kann nicht "on-the-flight" durchgeführt werden und muss im Nachgang erfolgen.
+ es muss damit gerechnet werden, dass einige Werte sich im Config-file geändert haben - man kann nicht darauf vertrauen, dass es schon einmal alles geprüft wurde.
+ CUL_HM setzt ein paar Attribute auf default-werte. Es muss erkannt werden, ob der User diese gelöscht hat, um den User-wunsch nicht zu überschreiben.

Das Vorgehen bei Init/restart
> während init werden alle Attribute akzeptiert - ohne jegliche Prüfung
> mit ende "INITIALIZE" werden ALLE entites von CUL_HM durch den parser gejagt. Es wird gnadenlos ausgesiebt - akzeptiert wird, was durch den parser läuft
> in CUL_HM wird per timer regelmäßig geprüft, ob init geschlossen ist. Diesen Timer könnte man sparen - mehr nicht.
Vorgehen "on-the-flight"
> betrachtet werden config-änderungen (die kommen alle von global), also attr/delete/rename/...
> CUL_HM disabled notifications für alle entites bis auf das "primary device" (interne Bedeutung). diese enroled sich ausschliesslich für global
> wird eine entiy umbenannt wird geprüft, ob CUL_HM (eine der entities) eine beziehung unterhält für welche CUL_HM verantwortlich ist. Ist dem so wird das rename nachgezogen.
> wird eine entity gelöscht wird auch die Beziehung entfernt. Gnadenlos - was sonst, ist ja weg
    >>> wird eine entity entfernt und danach eine neuen mit dem gleichen Namen incarniert wird diese NICHT verlinkt. gleiches bei nachträglichem "rename". Das entspricht gänger praxis in eigentlich alles Systemen, warum also nicht bei FHEM?
> selbstverständliche wird die relation "primaryDevice" zu Modul ebenso überwacht. Sollte dies gelöscht werden macht sich das Modul auf die Suche nach einem anderen. Es kann nur einen geben! nicht 2, nicht null.


Vorgehen anderer Module meist nicht konsequent:
- userAttr erlaubt dem User, attribute selbst zuzulassen. Das ist eine Kernal funktion, also auch eine Kernal Aufgabe es zu prüfen.
   + im Betrieb kann der User beliebige Attribute definieren. Auch speichern ist erlaubt.
   + nach dem Reboot sind alle verschunden, wenn sie ncht über userAttr angemeldet sind. Das halte ich schlicht für dünn:
     ++ der kernal sollte nur attribute zulassen, welche auf "enroled" sind
     ++ daraus folgend wird ein Attribut gelöscht, wenn der user es aus der userAttr liste entfernt
     ++ alternativ kann der User keine elemente aus userAttr löschen, welche noch verwendet werden
Das ist nur ein Beispiel. Bei Modulen will ich mich noch nicht einmal beschweren - der Kernel macht es ja auch nicht... .
Es ist halt so, dass dieses ganze Händling erheblicher Aufwand ist, nicht so viel spass macht, keine "features" bringt und somit wenig Ehre einbringt. Wenn man das will muss zuerst einmal der König des Kernal mit guten Beispiel vorangehen. Wenn es aber nicht gewünscht ist, dass macht der kernal alles schon jetzt richtig.
=> ich kenne halt die Philosophie nicht.

###################
und wieder einmal komme ich vom 100ertsten ins 1000sentste. Ich habe einmal die doku aufgeschlagen - Wiki
https://wiki.fhem.de/wiki/DevelopmentGuidelines
und wollte die definition oder zumindest die Idee von "Internals" verstehen.

System Internals: werden vom Framework (fhem.pl) benötigt/verwendet/erkannt, z.B. NAME, NR, CHANGED

unklar, was das sein soll. Gibt es "internals" und "System Internals"? Nach dieser Definition
  - steht IMMER viel zu viel in Internals.
  - frage ich mich, warum diese auf der Webseite dargestellt werden. Es reicht, wenn sie dargestellt werden KÖNNEN (get deviceInfo o.ä.)
  - wäre schon zu wissen, was fhem.pl mit "NR" macht - vs UUID.

Ablage im Programm

in der "Ablage " werden Readings und helper beschrieben - recht geenrisch. Die weitere Einteilung hat keine weitere Bedeutung da keine Funktion abgeleitet ist.
"fhem" ist eine nicht existente rubrik - soll wohl "internals" darstellen. "wird nicht gespeichert" ist falsch, da "DEF" in Interal auftaucht und wohl gespeichert wird.
"attr" fehlt. Wir haben nur 3 "Behälter" - da könnte man doch 3 beschreiben.

Status
Kurze Zusammenfassung der wichtigsten Information des Geräts. Was man in einer Übersicht über die Geräte sehen möchte

vollkommen unklar. "STATE ist ein Internal". Hier wird von mehreren Daten gesprochen? Dann gibt es das  nicht
=> in dem Dokument interessiert mich nicht, was alles vor Jahren diskutiert wurde - wiki hat hierzu eine Discussion section - auch das Forum bietet sich an. Hier wünsche ich mir zu lesen, was fakt ist - oder was letzten Endes gewünscht ist.

Attribute vs. Internals
Die Unterscheidung zwischen Attributen und Internals ist nicht eindeutig. Manche define-Parameter sind optional, und man kann define-Parameter mit "modify" ändern. Insofern könnte man theoretisch einen der beiden Verfahren (modify vs. attribute) ablösen.

das ist eine schlechte Ausdrucksweise.
Internals sind nicht editier oder einstellbar - ausgenommen das Define. Hier wird ausl von "Attr" vs "define-associated-parameter" gesprochen. Um es klar zu stellen:
wenn ich ein Device in CUL_HM definiere adressieren ich ein physkalisches device anhand seiner Adresse. Einiges am Device ist fix: es ist ein Schalter, hat Eigenschaften,... das ist "unveränderliche Parameter" (deviceType, deviceGroup, numberOfChannels, Configuration options,...). Next kann man das device (manchmal) konfigurieren (also CUL_HM jargon Register setzen und peeren).
=> was sollte man nun in Internals darstellen? Mit Sicherheit muss es gespeichert werden, da es nicht ohne weiteres wiederbeschaffbar ist....
Aber - "define-associated-parameter" sind zwar beliebt in FHEM - ich allerdings lehne sie eher ab. Ich habe mich hierzu schon einmal zu notify geäussert - und mein privat "ntfy" auf Attribut Basis realisiert. DBlog hat szwar versucht, die def-param von fileLog zu übernehmen, sich aber doch (gute Entscheidung) für eine Attribut Lösung entschieden.

###>> wäre cool, wenn nach all den Jahren eine definition der Ziele abgelegt würde.
m.E. habe ich in CUL_HM VIEL ZU VIEL Einträge in Internals.
so erst einmal wieder genug Text

no job is finished until the paperwork is done
Illustrationen im Internet ausreichend vorhanden.

[Beta-User]

wie gesagt, habe ich schon realisiert (CUL_HM). Alles andere wäre wahnsinn!. Aber das darf nicht das Ende der Fahnenstange sein. Das Modul könnt viel mehr können.

Es ist realisiert, ja. Ich kenne zufällig die Details, und behaupte: Es ist nicht verallgemeinerbar, wie es da gelöst ist, weil CUL_HM sich "nach vorne mogeln" muss, um die Erstinitialisierung zum richtigen Zeitpunkt zu machen. Wäre ein "echtes Modul-notify" von fhem.pl direkt unterstützt, bräuchte man die ganzen Klimmzüge nicht (auch nicht mit dem "einen notify-Device").

Und klar, man braucht eine Funktion, um zu reagieren. In der Regel findet sind aber bei "echten Event-Handlern" ziemlich zu Beginn der NotifyFn() eine Unterscheidung zwischen "GLOBAL"-Events und dem Rest, die nicht mehr miteinander zu tun haben, wie dass sie zwischen dem "administrativen Teil" ("muss ich Attribute, Relationen, NOTIFYDEF etc. checken?") und dem funktionalen Teil (ist es ein "normales" Event?) unterscheiden.

Kurz: Eine Krücke!
Kann man auch gleich sauber trennen, und die richtige sub aufrufen...

Just my2ct zu diesem Aspekt.

PS: seit vorhin läuft bei mir diese Version von CUL_HM: https://forum.fhem.de/index.php/topic,131251.msg1254487.html#msg1254487

[martinp876]

Es ist nicht verallgemeinerbar, wie es da gelöst ist

ich habe es nicht generisch geschrieben. Es ist konzeptionell gemeint. Ob ein Modul das braucht muss es selbst wissen. Wenn es dies braucht kann ich den Code in 30min entwerfen. CUL_HM ist aus eine frühen Phase von mir, als ich noch überhaupt kein Notify nutzte. Sagte ich aber schon.

weil CUL_HM sich "nach vorne mogeln" muss

das verstehe ich nun überhaupt nicht. Stehen noch mehr in der Schlange? gibt es eine Reihenfolge (ähnlich Linux init)? Dann wird es komliziert... aktuell gehe ich davon aus, dass die Reihenfolge egal ist. Wenn ich durch bin und andere Module dann an ihren Attribute spielen muss ich mich enroled haben und werde darauf reagieren. Was also meist du mit "nach vorne drängeln"?
Übrigens: Der Kernal sollte mehr init-stufen verwalten. Einmal wenn er selbst fertig ist und dann wenn die Module fertig sind.
=> das kann ganze einfach sein, wenn jeder mit notify arbeitet. Nach Kernal "initalized" werden alle Module welche sich enroled haben drankommen. Damit ist sichergestellt, dass erst nach dem letzten Modul der Betrieb beginnen kann.
Oh: ich denke aus "notifyFN" heraus kann man nicht triggern. Das könnte ein Problem sein.... schliesslich werden neuen Notifies generiert!

In der Regel findet sind aber bei "echten Event-Handlern" ziemlich zu Beginn der NotifyFn() eine Unterscheidung zwischen "GLOBAL"-Events und dem Rest,

Das kann man dem Entwickler anbieten, kann er aber auch selbst. Ob er eine eigene Funktion erstellt oder nicht ist nicht wesentlich. der Kernel bietet einen Funktionsakter für Rename an - ein subset von global. Verstehe ich nicht, kann man, aber warum?
=> man muss einfach erst einmal dokumentieren (schon wieder dieses Unwort) wie das mit notify funktioniert
++ alle config infos kommen über global (attr/define/...)
++ readings werden en-block gemeldet wenn readingsBulk genutzt wird.
++ eine beispielfunktion könnte erstellt werden, warum nicht
??> warum dürfen die Funktionen nichts mehr mit einander zu tun haben? Du bist bei der Realisierung. Erst einmal sollten wir uns (nicht nur wie beide...) auf das Konzept einigen, was ein Modul zu leisten hat. Ein Kardinal-fehler schon jetzt die Realisierung im Detail zu besprechen. Ist ein Modul nun verpflichtet, die Attribute auf Stand zu halten? Dann erst einmal das fixieren. Schriftlich in Großbuchstaben. Sonst wird das nix. Die Umsetzung kann unterschiedliche sein und CUL_HM muss es nicht machen wie ein Notify.

##> BITTE - erst einigen und artikulieren, was ein Modul leisten soll.

[Beta-User]

das verstehe ich nun überhaupt nicht. Stehen noch mehr in der Schlange? gibt es eine Reihenfolge (ähnlich Linux init)? Dann wird es komliziert...

JA!

Alle Modul-Instanzen, die "enroled" sind, werden in einer ganz bestimmten Reihenfolge abgearbeitet, und wir beide haben das für CUL_HM UND seine IO-Module SEHR AKKURAT festgenagelt! (gilt wohl auch für HMinfo).

Stichwort: Das Internal NTFY_ORDER - und wo kommt bei CUL_HM die "48"her...?!? (ich kenne die Antwort!)

Können wir jetzt endlich diese Diskussion auch als beendet betrachten? Es macht m.E. unbedingt Sinn, die Initialisierung durch "den Kernal" sauber zu ermöglichen, und dabei auch mitzuteilen, an welcher Stelle der Kette was passieren soll. (Nochmal schreibe ich das jetzt nicht mehr).

[martinp876]

ich weiss aktuell nicht, wo die 48 herkommt.

ps.: Ich habe gerade event-on-change-reading mit "thr" versehen Das ist ein Kernel Attribut - welches leider nicht geparsed wird beim Eintragen und zu erheblichen Fehlern führen kann. Sicher nicht so wichtig, wie die Order und das der Kernel weiss, wann CUL_HM an der reihe ist.
Ich fände es wichtiger, wenn wir das Verständnis hätten, welche Instanz für was verantwortlich ist. Da sehe ich  erheblicht größeren Bedarf.

Aber sorry, wenn ich dich aufrege, dann werde ich eben nichts mehr sagen - weiter gekommen sind wir eh kein Stück.
tschau - guten Rutsch.

[Beta-User]

Vorab: Danke für's Einchecken!

https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/10_CUL_HM.pm#L213 ist die aktuelle Lösung für die "48".

Und nein, ich bin nicht allzu aufgeregt, ist schon ok, wenn man wichtige Dinge 3-4 mal wiederholen muss. (Ist nicht ganz so ironisch gemeint, wie es vielleicht klingt ).

Was das Parsen von threshold-Angaben angeht, ist das imo Aufgabe des Codes, aus dem das Attribut kommt. Rudi würde sich vermutlich über einen patch freuen (es gab da in dem Umfeld aber auch jüngst updates, weiß nicht, ob das mit gefixt wurde).

Und ja: Es gibt sicher wichtigeres wie diese Detailfrage...

Guten Rutsch auch euch allen!

Auf ein konstruktives 2023!!!

[martinp876]

Passend zum Thema "usability" - also "fhem 4 Nerds or users?" oder "wie wünsche ich(man) sich ein Userinterface" stelle ich nun einmal vor, wie ich DBlog für mich nutzbar gemacht habe.
Status DB-logging module-suite - meine Beurteilung
Das Modul logged - das macht es und das ist die primäre Aufgage und die ist erfüllt. Ansonsten habe ich das Gefühl man implementiert eine Eierlegende Wollmilchsau. Das kann man machen - ich erwarte aber dann, dass der Anwender klar geführt wird und es ihm einfach gemacht wird. Das kann ich nicht erkennen. Kommandos welche in meine entity nicht möglich sind (ich nutze bspw mysql) will ich nicht sehen.
Das ausführen von SQL queries ist eine schöne Option - alles was ich typisch brauche sollte(MUSS) ohne dies gehen.
Komplizierte Sachverhalte wie "current" und "History" sind kaum vertändlich - und aus meiner Sicht komplett unnötig.
Filter wie "include" UND "exclude" sind verwirrend, komplex und auf allen Ebenen (user bis base-processing) eigentlich nur störend

Meine überarbeitung des UI - und etwas mehr
ich habe nun eine Version am Start welche meine primären Anforderungen erfüllt. Ich kann was ich brauche vom Sofa aus bedienen.
Um mich nicht komplett zu entkoppeln habe ich ein Front-end auf das Frontend montiert - und ein paar einzelne Funktionen aus DBlog frisiert (performacen,... functionality)
meine Implementierung ist nicht mehr kompatibel, da ich bspw "DBexclude" komplett entfernt habe.
=> wenn ihr euch also die Mühe macht mein UI zu verstehen versucht das von einer "greenfield" sicht aus zu machen. Was ist gut/wünschenswert im Detail/von Ansatz.

Meine Ziele im Detail - Performance / usabilits/ sinn und zweck
mich hat schon immer gestört, das ich die Daten nicht manuell und einfach einsehen kann. Das MUSS ohne SQL möglich sein. Weiterhin kann man dieDatenbank schnell auslasten. Effiziente Auswertungen sind also notwendig und müssen im Hintergrund vorbereitet werden.
Primär will ich die lethten x Readings einer entity auslesen können - mitnormalen Filtern.
Da meine DB im Hintergrund sich auf 2GB aufgebläht hat musste ich aufräumen. Hierzu sind statistiken hilfreich: wer ferkelt meine Datenbank voll, wo sind viele Datensätze. Daraus kann ich dann die korrekten Filter bauen (event-on-change-reading,...)
Die unterstützung der automatischen Abfragen (Grafiken) von "on-change" ist .... unterirdisch. Bei einer Abfrage eines Zeitraums (letzte Woche) muss als Startwert der letzte Wert VOR der letzten Wocheeingetragen werden. Und mit Zeitstempel "ende letzte Woche" muss der letzte Wert vor Ende letzte Woche genommen werden. Eigentich auf der Hand liegend

Meine neuen Kommandos

Code Auswählen Erweitern

commands for sets
  recDelExe :[({noConfirm}|confirm)] 'confirm and execute deletion of prepared records'
  recDelPrepRead :(filterFail|devices:({.*},-regexp-|-devspec-) 'readings:'[({.*}|-regexp-)] 'prepare deletion of records'
  recDelPrepSel :(-devRecList-|fltrFailDev|fltrFailReadings) 'multiple,(filterFail|-devRecList-)'
  recRenDev :-oldDeviceName- -newDeviceName- 'rename a devide in database'
  recRenReading :'devices:'(.*|-regexp-|-devspec-) -oldReadingName- -newReadingName-

commands for gets
  cmd :HASH(0x4dafca8)
  cmdList :[({short}|long)]
  dbInfo :'status information about database'
  filterScreen :'devices:'textField-long,[({.*}|-regexp-|-devspec-)] 'readings:'[({.*}|-regexp-)]'which records would be stored?'
  list :[({default}|hidden|module)]
  listDB :(-DBentities-)'list of DB processing entites'
  recAverage :'devices:'({.*}|-regexp-|-devspec-) 'readings:'[({.*}|-regexp-)] 'lines:'[({5}|1..1000)] 'cycle:'[({3600}|3600..100000)]
  recFltrTest :'stored records that do not match include filtering'
  recList :'devices:'({.*}|-regexp-|-devspec-) 'readings:'[({.*}|-regexp-)] 'lines:'[({5}|1..1000)]
  recStat :'devices:'({.*}|-regexp-|-devspec-) 'readings:'[({.*}|-regexp-)] 'spawn:'[({m}|d|w|y)] 'spawnCnt:'[({12}|1..24)]
Alle Kommandos sind selbstverständlich syntaktisch korrekt hier beschrieben und werden automatisch von einem generischen Parser ausgewertet. Das Kommando get cmdList wird natürlich generisch für alle meine Module ausgeführt. Aber das ist eine weitere Baustelle - eingenes Thema.

get recList
ich kann die letzten x werte eines Device und eines Readings ansehen. Alles als regexp.
Anwendung:
get regList .* batteryLevel 20  => battery-level - max 20 Einträge (die letzten) zur Prüfung des Batterieverhaltens
get recList .* level 1 => den aktuelle Level jedes Devices (also current - ohne current).
get recList presen.* prese.* => die letzten Einträge in presence. Ich prüfe damit bspw die stabilität von infrastrukturgeräten (hat meine NAS aussetzer?)
auuch flackernde Readings kann ich erkennen und den Filter anpassen

get recStat
sselbsterkärend meine ich. Welche Devices und welche Readings werden geloggt oder nicht. Da der Zeitraum der Gruppierung wählbar ist kann man veränderungen leicht untersuchen

recFltrTest
Aktell sind filter eingestellt (DBinclude). Welche Readings sind in der Datenbank und würden jetzt nicht mehr erfasst?
=>siehe auch set recDelPrepSel fltrFailDev. Dies selektiert die vermeintilch falschen records und bereitet das Löschen vor. Ausführung mit set recDelExe confirm
gleiches auf readings level.
So kann ich - wenn ich das wünsche - gelöschte devices aus der DB entfernen.

filterScreen
sehr hilfreich bein Einrichten. Es zeigt mir an, welche der aktuelle Readings geloggt würden (wenn ein Event ausgelöst wird)

rename
hier gibt es schon funktionen in DBrep. Ich habe meine entsprechend meier Nomenklatur selbst erstellt

Performace
DBlog trägt sich nicht in die Notify liste des kernals ein. Kein Wunder, das ist auch sehr komplex mit Include/exclude. Da ich nur noch include strickt nutze kann ich das sauber identifizieren. Die Notify liste wird selbstverstndlich on-the-flight upgadated. Mit dem Eintragen/löschen des Attributs DBinclude wird das gemacht.
Somit kann ich auch filter vorbereiten, die Readings auszuwerten.
=> deutlich weniger Notifies werden aufgerufen
=> wenn das notify ausgeführt wird ist der Readings-filter schnell, da per referenz.

DB-Performace
die SQL auswertungen sind optimiert. Bei den ersten Versuchen hat sich die DB minutenlang verrannt. Das ist ein nogo und ich habe optimiert. Der User kann nun ziemlich sorglos aggieren.
Eigentlich müsste man die DB struktur optimieren Aktuell ist die DB und eine flache Tabelle. Eines meiner offenen Projekte, hier hilfstabellen zu erstellen - da mit die DB auch den Namen Datenbank verdient und nicht "tabelle mit ein paar Funktionen"

=>das Userinterface ist "kleiner und leichter"
=> operational performance ist verbessert - weitere Schritte ausstehend in der DB vor allem
=>vom Sofa as kann ich alles einfach austwerten.

sich erhabe ich ein paar details vergessen zu erwähnen. kann ich auf Nachfrage nachreichen. Da ich die einfache bedienung nun habe kann ich zu der Umständlichen, mit Features überladenen Version nicht zurück - wie ich selbst befürchtet haben. Eine "leichte" version von DBlog wäre also mein Wunsch. ggf erfülle ich ihn mir selbst.