fhem 4 Nerds or users?

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