Notify abschaltbar

Begonnen von martinp876, 14 Juni 2021, 07:50:29

Vorheriges Thema - Nächstes Thema

martinp876

mit der notifyFn kann man sich bei Triggern enrolen. Wie kann man sich unrolen?
Notify wird in fhem mit (min) 2 Bedeutungen genutzt: Als User Notify und "intern" im Zusammenhang mit Trigger. Ich nutze hier nun Trigger, da ich Intern bespreche. Das Impliziert die Nutzung der NotifyFn durch DoTrigger
Details:
Ein Modul legt fest, dass dessen Entites bei "triggern" benachtichtigt werden. Hat man nun wie bei allen HW-Interface module viele Entites will man nicht immer alle an Trigger hängen. Man kann es einschränken - aber nicht abschalten.
1) wo finde ich die Dokumentation der Funktionen für Entwickler, wie ich Trigger bedienen kann? notifyRegexpChanged sollte wohl das Interface sein - allerdings steht es nirgendwo.
2) es gibt nun einig Entites, welche keine Trigger benötigen. Ich erwarte eigentlich bei allen Funktionen die ein Einschalten bieten auch ein Abschalten. Ein notifyRegexpChanged("entity",0) wäre cool - allerdings wird nun alles eingeschaltet statt abgeschaltet.

Da es sich hier um eine performance-kritische Funktion handelt, welche aber  mächtig, wichtig und kritisch ist, muss zwingend auch eine Abschaltung zu Verfügung stehen.

Eigentlich würde ich den Default auf abgeschaltet setzen. Von einem Modulentwickler kann ich erwarten, dass er sich um das Einschalten kümmert.

Hilfreich (eigentlich zwingend) ist eine Dokumentation hierzu. Falls es das schon gibt, hätte ich gerne einen Link. Ein Forum ist aus meiner Sicht keine Festlegung/Dokumentation.

Natürlich kann ich mir etwas basteln.... das ist aber wie fast alles basteln hässlich.

rudolfkoenig

Zitatmit der notifyFn kann man sich bei Triggern enrolen. Wie kann man sich unrolen?
"unrolen" war kein Entwurfsziel, man kann es aber loesen, indem man NotifyFn aus dem Modul-Hash entfernt.

ZitatNotify wird in fhem mit (min) 2 Bedeutungen genutzt: Als User Notify und "intern" im Zusammenhang mit Trigger.
Ich sehe das anders. Alle Module, die sich dafuer anmelden, bekommen Events. Manche Module ermoeglichen damit dem Benutzer eine direkte Interaktion mit Events, das ist aber nicht mehr als ein erwuenschtes Nebeneffekt.

Zitat1) wo finde ich die Dokumentation der Funktionen für Entwickler, wie ich Trigger bedienen kann?
Im Quellcode, im Development Abschnitt des Forums, oder durch Nachfrage hier im Forum.

Zitates gibt nun einig Entites, welche keine Trigger benötigen. Ich erwarte eigentlich bei allen Funktionen die ein Einschalten bieten auch ein Abschalten.
notifyRegexpChanged zeigt dem Framework mit einem Regexp, fuer welche Geraete eine Benachrichtigung erwuenscht ist, damit das Modul nicht fuer alle Events aufgerufen wird. Je nach Anzahl der Instanzen und Events kann das hilfreich sein. Eine Negativliste gibt es nicht. Die Einschraenkung auf die bestellten Geraete ist nur dann garantiert, falls notifyRegexpChanged die einzelnen Geraete aus dem Regexp extrahieren kann. Wie notifyRegexpChanged "denkt", kann man mit der Funktion notifyRegexpCheck sehen.

martinp876

Zitat"unrolen" war kein Entwurfsziel, man kann es aber loesen, indem man NotifyFn aus dem Modul-Hash entfernt.
Ich will nicht das ganze Modul unrolen. Also keine Option. Hoffentlich kommt noch das orginal Ziel um die Performance zu schonen.
ZitatIch sehe das anders. Alle Module, die sich dafuer anmelden, bekommen Events.
angelehnt. Leider bekomme nicht alle module die Events sondern alleEntites. Wir reden hier von Faktor 100 oder mehr.
Du machst dir die Arbeit in der Zentrale, je entity festzulegen, ob und von welchem counterpart informiert wird. Das ist ein heiden aufwand. Sogar ein Abschalten wird berücksichtigt (ignore Auswertung - was ich für fraglich halte!). Aber abschalten geht nicht. Es wäre echt einfach einzubauen - nahezu null Aufwand für dich.

ZitatManche Module ermoeglichen damit dem Benutzer eine direkte Interaktion mit Events, das ist aber nicht mehr als ein erwuenschtes Nebeneffekt.
unklar, was du mir sagen willst. Das ist alles ok für mich. Man muss es ja nicht abschalten, man kann.

ZitatIm Quellcode, im Development Abschnitt des Forums, oder durch Nachfrage hier im Forum.
also keine Doku. Ein Wiki wäre schön. Für module wird das gemacht - für die Zentrale nicht.
Forum ist nicht geeignet. Ich muss mich durch längliche Diskussionen wühlen umzu sehen, wie es diskutiert wurde. Manchmal sehe ich dann auch, waas das Ergebniss war. Die Nachfrage hat nun keine wirkliche erklärung gebracht, welche Methoden der kernal zu offiziell Verfügung stellt.
Das ist möglich, es so zu machen, ist für den Entwickler einfach und am Ende doch dünn. Eben eine Bastellösung.
Wenn du den gleichen anspruch an dich stellst wie an Modulentwickler hätten wir ein "internal command-ref" und ein "wiki for developers".
Aber gut - werden ich eben code lesen und experimientieren und hoffen, dass der Code beim nächsten Update nicht leicht anders ist - wie bisher.

ZitatnotifyRegexpChanged zeigt dem Framework mit einem Regexp, fuer welche Geraete eine Benachrichtigung erwuenscht ist, damit das Modul nicht fuer alle Events aufgerufen wird. Je nach Anzahl der Instanzen und Events kann das hilfreich sein.
klar, das ist einfach zu sehen.

ZitatEine Negativliste gibt es nicht.
wäre auch quatsch.
ZitatDie Einschraenkung auf die bestellten Geraete ist nur dann garantiert, falls notifyRegexpChanged die einzelnen Geraete aus dem Regexp extrahieren kann.
perfekt.

ZitatWie notifyRegexpChanged "denkt", kann man mit der Funktion notifyRegexpCheck sehen.
das habe ich doch gesehen. alles klar.

Das Problem ist, dass die Einschränkung nur akreptiert wird, wenn min eine Entity gefuden wurde. Wenn nicht werden alle zugelassen.
Setze ich ignore wird kein trigger ausgelöst (mir unklar, warum ICH DIR den code erkläre, du weisst es ja schon).
Ignore hat aber viele Auswirkungen. Ich will nur die Liste der Entites welche meine Entites triggern auf "leer" setzen (können). Das kann ich natürlich machen, wenn ich eben nicht deine Funktionen nutzen sondern einfach direkt zugreife. Das will ich aber vermeiden - so etwas macht man nicht (auch wenn es klappt).
Alles was ich will ist ein
notifyRegexpChanged(<entity>,"none");
wobei ich "notifyRegexpChanged" also programmer-interface sehe ( nicht dokumentiert, aber der Code sagt es mir, also hoffe ich). "none" oder 0 oder '-' oder sonst etwas... ist mir egal. Doku im code wäre schön, wenn schon kein wiki kommen wird.

rudolfkoenig

ZitatAlles was ich will ist ein
notifyRegexpChanged(<entity>,"none");

Das verursacht aber Probleme, wenn jemand ein Geraet mit dem Namen none anlegt.

Ich habe das Feature deswegen als notifyRegexpChanged($defs{X},$regexp,1); implementiert, d.h. wenn der dritte, optionale Parameter gesetzt ist, dann wird der zweite Parameter ignoriert, $defs{X}{disableNotifyFn}=1 gesetzt, woraufhin createNtfyHash() den Empfaenger X in keinen der Benachrichtigungs-Schlangen reinpackt.

Mit einem erneuten notifyRegexpChanged ohne den dritten Parameter kann man das Abschalten rueckgaengig machen.

martinp876

ok, damit kann ich leben

Kommentieren möchte ich dennoch
"none" ware nur ein Vorschlag - und nicht final durchdacht. Auch ein "0" wäre möglich- oder ein unzulässiges Zeichen "%"

"NOTIFY_ORDER" wird nicht gelöscht - das ist unsauber - bitte aufräumen.

"notifyRegexpChanged" habe ich nun als "Programmer-Interface-to-Kernel-Method" identifizert. Ansgar merkte an, man solle nr Methoden nutzen, welche du herzu "freigegeben" hat. Nachdem es keine Doku für Programmer gibt (Forum akzeptiere ich nicht als Doku) - wie ist das gedacht? Jeder nutzt die Methode und greift darauf zu, wie er es meint/versteht. Verantwortlich ist jeder für sich selbst... aber man will ja möglichst konform bleiben. Da ist es hilfreich zu wissen, was "Konform" ist.


nun betrachte ich einmal das Notify-geschehen und zerlege es:
"notifyRegexpChanged" ist das Programmer-interface mit welchem der Programmer eine Entity enrolen kann, sich bei Notifications zu anderen Entites enrolen kann.
Ich kann eine Regex eingeben welche den Namen der Entites parsed. Für mich wenig hilfreich, da ich eher bestimmte Typen zuweisen werden oder Attribute von Entites auswerten würden. => den Usecase "regex for names" verstehe ich nicht - das kann nur für Anwender sinnvoll sein, wenn überhaupt.
Die Regex wird nicht gespeichert. Wenn ich also will, dass ich von allen Entites "Licht.*" notifiziert werden kann ich das einrichten. Einmalig. Nun definiere ich eine neue Entity "Licht_neuesZimmer". Schon geht es nicht. Will ich das automatisch haben muss ich ein Notify auf "global define" machen und nach jedem trigger "notifyRegexpChanged" erneut ausführen. Dann erst macht es Spass.
Übrigens gilt dies  auh bei jedem "RENAME" und "DELETE". Genau das baue ich gerade ein.

Ich bin wieder bei meinem alten Punkt: Ich kann damit leben und implementiere es, wie ich meine.
Wie FHEM (also du) es "meint" ist nicht dokumentiert.


Dennoch: ich werden nun best möglich einbauen
Mein Anspruch ist der, welchen andere Systeme schon seit Jahr(zehnt)en haben: Name ist Attribute, UUIDs steuern Zuordnungen. Will sagen: wenn ich eine Zuordnung "explizit" mache, also bspw "notify meEntity for trigger from otherEntity" dann sollte das Bestand haben über Rename hinaus. Ein "Rename otherEntity renamedEntity" hat zur Folge, dass das notify "notify meEntity for trigger from renamedEntity" zur Folge hat.
Das sind semantische Felstlegungen. Eine UUID haben wir nun (FUUID) - welche aber leider nicht fix ist.
Ich beende das hier... ich denke jedem professionellen Programmierer/Architekten sind die Konsequenzen dieser Festlegung klar - da muss/müsste einiges geschehen.


martinp876

Ich bin nun (endlich)  dabei, mir einmal das Trigger Konzept anzusehen und die Performace  zu optimieren. Mangels Dokumentation muss ich es experimentell machen oder einige Kernal Funktionen durchpflügen.

Bei CUL_HM interessiert mich die Konfiguration meiner "linked entites" - bspw IOs. Tut sich hier etwas werden ich aktiv werden (beim Ausführen ist es eigentlich etwas spät).

Ich lerne nun. Situation: ich haben ein Entity1 welche über Entity2 informiert werden will.
1) notifyRegexpChanged($defs{Entity1},"Entity2",0) enroled
2) Trigger bekommt Entity1 wenn ein Reading von Entity2 mit Trigger gesetzt wird
2a) Filtern auf einelne Readings ist Sache des Moduls
3) Entity1 wird nicht über Änderung der Konfiguration von Entity2 informiert. D.h. wenn sich ein Attribut von Entity2  ändert, ein Rename, delete,....
4) Konfigurationselemente werden über "global" notifiziert. Benötige ich Notifikationen zur Konfiguration ist es notwendig, notifyRegexpChanged($defs{Entity1},"global",0) zu setzen
4a) Notifikationen zu Konfigutaion werden von Kernel nicht vorgefiltert - man wird immer über alles informiert
4b) global notifications betreffen neben Konfiguration auch Initialization/save/rereadcfg,...
4c) global setzt keine Notifikation ab, wenn "global-Init" abgeschlossen ist. Stattdessen erhält man ein Init für jedes einzelne Device. Was zu diesem Zeitpunkt genau passiert ist, ist noch nicht schriftlich definiert.
5) soll eine Entity nicht notifiziert werden muss ein notifyRegexpChanged($defs{Entity1},"",1) abgesetzt werden. Programmierer  sollten dies dringend für alle Enities einstellen welche nicht notifiziert werden.

Man sollte darauf hinweisen, dass Attribute über die entsprechende Funktion zu ändern sind um notifikationen zu ermöglichen.

Eine Regelung/Empfehlung wäre hilfreich, wer sich notifizieren lässt. Ich sehe ein IO als Server für IO funktionen. Das Device ist dann der Client, welcher den Server nutzt.
Typisch kennt der Client den Server (wenn fix zugeordent) und nicht umgekehrt. Also wär der Grundsatz: Der Client lässt sich über Server Änderungen informieren.
Bei CUL_HM ist es natürlcih notwendig, dass das Modul sich um die Config-Notifikation und zuweisung kümmert. Technisch könnte sich jede Entity bei global enrolen - das wäre aber alles andere als Produktiv. CUL_HM wird dies optimieren - für das ganze Modul

Und Nachsatz: Natürlcih ist es Sache des Modul-Programmers sich hier zu kümmern und die Konfig auch im laufenden Betrieb auf Stand zu halten.

So in der Art stelle ich mir eine Dokumentation vor. Wer das hier im Forum findet weiss nin, was ich gedacht haben - aber er hat keine Ahnung, was davon Rudi hält, was er einbaut, wann etwas geändert wird. Das ist der Unterschied "Forum/Diskussion" zu Dokumentation/Requirement/Spezifikation.

Ich hätte mir jede Menge Arbeit gespart ( ok, einen Teil habe ich selbst verschuldet)