fhem 4 Nerds or users?

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