Define mit parameter? Warum keine Attribute z.b. bei at oder notify

[martinp876]

So, FB operational.
Ich kann die readings zu inactive nicht finden. Somit ist es schwer zu helfen oder grundsätzliche Empfehlungen zu geben.

[Beta-User]

So, FB operational.
Ich kann die readings zu inactive nicht finden. Somit ist es schwer zu helfen oder grundsätzliche Empfehlungen zu geben.

Das ist ein Event, der nur genau einmal kommt, wenn ein Gerät sich "abgemeldet" hat:

Code Auswählen Erweitern

2021-12-12 07:07:58 FRITZBOX Fritzbox mac_24_6F_28_A2_76_B0: OMGBuero (WLAN, 0 / 0 Mbit/s, 0)
2021-12-12 07:07:58 FRITZBOX Fritzbox mac_00_80_41_E1_31_E9: WIZnet-1
2021-12-12 07:07:58 FRITZBOX Fritzbox mac_84_F3_EB_EF_FB_7F: inactive


Das Problem mit meinem notify ist aber noch ein ganz anderes: die Ergebnisse waren bei mehreren Geräten zunehmend zufällig...
Um das Problem mit einem notify zu lösen, muss man tiefer graben:

Code Auswählen Erweitern

defmod rr_xn_MAC_Check notify Fritzbox:mac_.*:.* {\
  my $targets = {\
    "mac_A1_99_75_5E_7A_BB:" => "rr_Mann",\
    "mac_E1_DC_FF_EE_62_C3:" => "rr_Frau"\
  };;\
  for my $evt ( deviceEvents($defs{Fritzbox},0) ) {\
    my $target = $targets->{$EVTPART0} // next;;\
    $evt =~ m{inactive\z}xms \
    ? fhem("setreading $target smartphone absent")\
    : fhem("setreading $target smartphone present");;\
  }\
}

....(aus mehreren Gründen) unschön...

PS: Bandwurm-concats finde ich nicht gut, dann um der Leserlichkeit willen lieber eine Zeile mehr. (zugegeben: Geschmackssache).

[martinp876]

Ich denke ich habe dich falsch abgeholt. Zur Bewertung von ntf betrachten wir, was du bislang hast:
   trgDevice ist auf eine einzige Entity gesetzt
   trgReading is gesetzt auf einen Filter. Da mehrere Readings ausgewertet werden sollen sieht es aus wie "mac.*"
                     zu beachten: alle Eingaben sind "umfassend". Es muss der komplette String definiert werden. ggf eben mit .* abschliessen
   trgReadValue: muss nicht gesetzt werden - steht per default auf ".*", also alles.
==> nun ist ntf scharf. Device UND reading sind angegeben. Sollte ein Event eintreten werden die Readings hierzu erzeugt.
ntf debug support
  - get trgFilter: zeigt, welcher Filter real aktiv ist. Hier ist auch zu sehen, dass "^.*$" gefiltert wird. Kann evtl nicht jeder lesen, sollte aber doch vielen helfen. Bei mit ist es

trigger:
   myFritz -> ^(mac_.*: .*)$

Reading list
lastTrgDevice  myFritz
lastTrgEvent   mac_00_A0_DE_A8_39_3F: stereo
lastTrgReadVal   stereo
lastTrgReading   mac_00_A0_DE_A8_39_3F
log_myFritz   mac_00_A0_DE_A8_39_3F: stereo

==> noch vor der Definition des Kommandos kann man prüfen, dass der Filter sitzt.
+++ Ich gebe ntf hier 0.5 Punkte vorsprung auf notify wegen (deutlich) besserer debug Optionen built in
set clear readings macht einen cleansweep und ist ebenfalls hilfreich die Übersicht zu behalten.

-----------------------------------------
so nun mal zu den interessanten Dingen - langsam steigernd:
hast du mehrere FBs (ok, nicht realistisch, aber für die Erklärung hinreichend).
a) attr trgDevice einfach um die 2. Instanz erweitern (Hacken setzen). Die Readings sind identisch. Das ist einfacher als notify
+++ Ich geben ntf noch einmal 0.3 Punkte für selektive editierbarkeit

b) wir sind fortgeschrittene Configuratoren (oder kopieren eine Vorlage). Ziel ist es, alle FBs aus unserem System AUTOMATISCH!!! in das notify einzubinden. Alle FBs haben "TYPE=FRITZBOX". Wir können also devspec nutzen. Jetzt muss man tippen... keine hacken setzen

Code Auswählen Erweitern

attr trgDevice TYPE=FRITZBOX
Jetzt kommen wir in den wirklich coolen Bereich. Ich behaupte, der service ist full-featured (irgend eine Lücke wird man noch finden)
b1) mit "get shEnrolled" kannst du sofort kontrollieren, welche entites für das notify zugelassen sind.
b2) get trgFilter zeigt dir, welche realen Filter aktiv sind.
*** test: mache ein "define AA FRITZBOX". Schon hast du ein weiteres test-device.
b3) full featured: ntf evaluiert die settings @entry, nicht @operation. Notifies werden nur zugelassen, wenn entites auch spezifiziert sind. ok, ".*" geht auch... wenn der Anwender es herausfordert. ntf hält die Liste über die gesamte Systemlaufzeit aktuell. D.h. alle define/delete/rename/ignore werden berücksichtigt - übrigens auch alle attribute. Änderungen werden umgehend eingearbeitet.
+++ Hierfür geben ich ntf 2 dicke Punkte - mindestens.

###> am Ende ist ntf eigetnlich nur auch einem Stand, den man erwarten kann. Kein gebastel, keine unleserlichen String-schlangen welche auch noch gemicht ein müssen, kein attribut im Define. Ganz wichtig: Performance - alles wird zur Config-Zeit vorgearbeitet und AUF STAND GEHALTEN! in FHEM leider nicht üblich.

Praktische Anwendung: ich habe ein notify welches die Ventilstellung der Heizkörper zusammenfasst (und eines welches die Anzahl der eingeschlateten Lichter auswertet).
Um die HKs zu erfassen kann man

Code Auswählen Erweitern

trgDevice model=HM-CC-RT-DN:FILTER=i:DEF=......04
trgEvent ValvePosition.*
filtert mir alle RTs aus CUL_HM und das Reading ValvePosition.
Bei anderen Familien muss man natürlich anders filtern.

Nachsatz:
ich habe noch 2 Bugs entdeckt  beim Setzen von trgDevice ist trgReading nicht betrachet worden - und get trgFilter sollte schöner werden. Reading und value separieren.

[martinp876]

Zu deinem letzten Post:
FRITZBOX ist .... nun hier ist room-for-improvement.
ich werde damit nicht arbeiten - macht einen Sinn. De-Factor habe ich bereits eine private Version. Ich habe gerade auf die offizielle zurück gestellt - nur um zu testen.

Für die Verifikation von ntf sollte es aber reichen, erst einmal auf "mac_.*" zu filtern.

Ach ja, wer wert auf performance legt sollte
attr .* event-on-change-reading .*
setzen. zumindest für CUL_HM ist das praktikabel
attr TYPE=CUL_HM event-on-change-reading .*

[martinp876]

ok, have it.
Also 1) bitte ntf weiter prüfen. Ich habe neben den angegebenen Vorteilen noch einige grundsätzliche Verbesserungen welche ich schritt für schritt erkläre. Nicht alle sind User-sichtbar.
2) FRITZBOX ist .... non-of-my-style. De-facto kann ich es nicht nutzen. daher habe ich vor einiger Zeit einmal begonnen, es umzuschreiben. Es ist nicht auf meinem aktuellen Standard von einem "system-konformen" modul - aber für mich schon deutlich besser.

a) Im Anhang eine neue Version von ntf mit i) korrigiertem Verhalten beim trgDevice setzen und ii) verbesserte Darstellung von get trgFilter
b)im Anhang meine unfertige Version von FRITZBOX. Du solltest vorher eine Sicherungskopie machen. Die Implementierung ersetzt FRITZBOX und ist nicht parallel zu installieren wie etwa ntf. Es reicht allerdings, die Einstellungen deiner FB zu kopieren und bei Rückbau wieder auszuführen.


Solltest du beides aktiv haben kannst du

Code Auswählen Erweitern

define a ntf
attr a trgDevice TYPE=FRITZBOX
attr a trgReading IP_.*active
attr a trgCmd {$EVENT=~ m/IP_(.*)_active: (.)/;fhem ("setreading $SELF $1 active:$2")}

attr TYPE=FRITZBOX readingOn IPState

wenn du dann durch bist mit pre-test kannst du live gehen

Code Auswählen Erweitern

attr a trgCmd {$EVENT=~ m/IP_(.*)_active: (.)/;fhem ("setreading $1 smartphone ".($2?"active":"inactive")}
set a clear readings


So einfach könnte es sein, wenn module ein sinnvolles API haben

[martinp876]

So, und nun side-topic. Sync von FB zu presence.
1) ich nutze meine Version von FRITZBOX. Die allgemein-gültige ist nicht nutzbar für mich
2) ich nutze meine Version von Presence. Die allgemeingültige ist nicht nur nicht nutzbar sondern schlicht gefährlich. Primär unkontrolliertes Nutzen von BlockingCall

Um Presence mit FB zu kopplen und die Namen zu synchronisieren bin ich über die IP adresse gegangen.

damit (mein) Fritzbox das passende Reading ausspuckt ist

Code Auswählen Erweitern

attr TYPE=FRITZBOX readingOn IPName
zu setzen.

Code Auswählen Erweitern

attr myNtf   trgCmd     {$EVENT =~ m/IP_(.*?):.*active:(.).*ip:(.*)/;
my($pr)=devspec2array("TYPE=PRESENCE:FILTER=ADDRESS=$3");
fhem ("setreading $pr FBname $1;setreading $pr FBstate ".($2?"active":"off"))}

attr myNtf    trgDevice  TYPE=FRITZBOX
attr myNtf   trgReadValue active:.*
attr myNtf   trgReading IP_.*

Das Command muss natürlich komplett in das attr trgCmd gepastet werden.

Im Presence-modul erscheint dann der FB-name des Geräts so wieder der Zustand.

FRITZBOX ist wie gesagt nicht fertig..... das genügt  nicht meinen Ansprüchen. Anregungen gerne.

Aber bitte erst ntf!

[Beta-User]

Ich denke ich habe dich falsch abgeholt.

Weiß nicht.

Folgendes war bei mir aus dem Ausgangspost hängen geblieben:
- Die funktionalen Teile je in ein eigenes Attribut packen wäre für's Editieren einfacher (Zustimmung)
- Das einzelne notify (ohne "globales" trigger-Kommando) testen zu können wäre nett (verhaltene Zustimmung)
- notify ist schweigsam (erledigt)

Dazu kam der "teaser" mit der universellen Fernbedienungslösung. Klang erst mal unübersichtlich, war ja aber auch auf der "alten" Basis gestrickt. Wenn es irgendwas (aus User-Sicht) einfacher gemacht hätte, wäre das ein echter Fortschritt. Das hat mich ermutigt zu dem Experiment mit der Fritte, da ähnlich, aber nicht gleich.

Mein Feedback zu den originalen Themen:

1. define ohne Parameter ist nett. Keine Vorüberlegungen dazu, auf was eigentlich reagiert werden soll oder "gib-Ruhe"-Klammern erforderlich. Soweit angenehm.

2. Unter ntf (also leider: sehr weit hinten...) finden sich dann einige Attribute, deren Namen einigermaßen selbsterklärend sind.
- trgDevice (Fritzbox) mit einfachem Klick ausgewählt => angenehm!
- trgReading mit regex ist auch noch selbsterklärend.

3. und nun...?

Im Prinzip hat sich durch den Exkurs jetzt relativ wenig geändert, außer, dass mir in dem Zuge noch ein paar andere Probleme ins Bewußtsein gekommen sind (dazu weiter unten).

Weiterer Aspekt war, insbesondere auch auf rename-Events zu reagieren. An sich finde ich den Gedanken charmant, es hapert in meiner persönlichen Bewertung dabei aber auch wieder an einer Stelle: Manchmal muss/will ich Geräte tauschen - und da geht es mir z.B. auch bei LightScene gegen den Strich, dass das das rename des alten Devices nachführt. Ich will nämlich das neue erst mal 1:1 dort haben, was nicht geht, wenn man es nicht über die DEF lösen kann (also namentlich bei Wechsel des TYPE (ich nutze configDB, der Taschenspieler-Trick cfg-Edit geht daher nicht!))...

Soweit also erst mal zu den Kernaspekten - ich hoffe, die soweit vollständig erfasst zu haben.

Jetzt kommen hier aber am konkreten Beispiel weitere Aspekte auf den Tisch, deren Beurteilung mal wieder im oberen Bereich (oder oberhalb) meines Gesamtverständnisses liegen. Jetzt müssen plötzlich noch andere Module (unabhängig von der Berechtigung mancher Kritikpunkte!) mitspielen, damit alles wieder zusammenpaßt. Grundsätzlich bin ich ja für eine gewisse Einheitlichkeit, aber ab dem Punkt glaube ich nicht, dass genügend Leute mitziehen werden, um FHEM an so vielen Punkten umzugestalten - so das im Einzelfall überhaupt möglich ist.

Meine aktuelle Gemütslage ist:
- Das Ganze ist mir jetzt zu groß, ich will eigentlich nach Möglichkeit nur Module nutzen, die im svn verfügbar sind und mir nicht an jeder Ecke eine Sonderlocke reinziehen. Ganz blöd ist es, wenn ich im Forum ggf. irgendeinen Thread beobachten muss, ob's was neues gibt, wenn der Code nicht von mir selber ist. Wenn's was zu kritisieren gibt, ist es erlaubt, den betreffenden Maintainer (möglichst mit "F"-Ton) zu kontaktieren und darum zu bitten, Mißsstände zu beseitigen (das betrifft namentlich das PRESENCE-Ding, über das viele User stolpern!). Wenn das nicht klappt, wäre es besser, direkt "PRESENCE2" im svn anzubieten, oder die alternative Version nach contrib zu packen.
- Den "Wizzard" finde ich übrigens auch nicht besonders gelungen, und würde mir wünschen, den ohne "Startnotify" abschalten zu können.

Der eigentliche Haken ist m.E. folgender:
Völlig egal, wie man das im Detail aufdröselt, es kommen sehr schnell viele Aspekte zusammen, bei denen man als "Konfigurator"/"Administrator" oder "User" schlicht und ergreifend wissen muss, wie die interne Abarbeitungs-Logik ist. Das meiste ist dabei weitaus anspruchsvoller, wie durch passende <trigger>-Angaben dafür zu sorgen, dass NOTIFYDEV erzeugt wird (was ja auch "nur" ca. 30% Performancegewinn ist). Da ich meine notify (etc.) eher selten ändere, ist der Aspekt der leichteren Editierbarkeit für mich sekundär.

Dennoch finde ich weiter den Gedanken erwägenswert, insbesondere den <command> in ein Attribut auszulagern (gilt für notify, at und watchdog).

Die weiteren Probleme im Detail:
- Durch das Trennen von Device und weiterem Event ergeben sich neue, ggf. unbeabsichtigte Kombinationsmöglichkeiten. Ich fürchte, viele werden das nicht verstehen (nicht immer liegen bei mir identische Kommandos auf derselben Taste verschiedener Taster!);
- <trigger> ist in der "notify"-Schreibweise in einigen Modulen (z.B. auch FileLog und DbLog) zu finden. Wenn man es neu macht, müßte das für alle gelten, sonst muss man wieder zusätzliche Syntax lernen. Wenn also Attribut, kommt m.E. bestenfalls die "trgCombined"-Variante in Betracht;
- Die Abarbeitungsreihenfolge wird (im praktischen Leben fast ausschließlich) durch den Device-Namen bestimmt. Steht nirgends, aber bei verketteten Eventhandlern (z.B. infolge der setreading-Kommandos) muss man das beachten;
- "rename" ist von Übel, und egal, ob man es durch "Nachführen" löst, oder durch "User muss wissen, was er tut" (und überall manuell nacharbeiten), die gefundene Lösung wird nicht alle Probleme beseitigen. Als "Admin" sollte man sich einmalig eingehend damit befassen, wie Devices zu benennen sind, und damit sollte es dann "gut sein". Beim Tauschen hat man so oder so diverse Problemchen;
- bei Bulk-Events (oder zusätzlichen, zwischenzeitlichen setreading-Kommandos) muss der Eventhandler das berücksichtigen, wenn ggf. auch mehrere Events gleichzeitig passen können und jedes eine andere Aktion auslösen soll. Auch das steht vermutlich - wenn überhaupt - eher versteckt in der Doku.

Kurz meine Schlussfolgerung bis hierher: Man muss so oder so für komplexere Setups soviel wissen, dass es nur ein kleiner Schitt vorwärts wäre, die Syntax in Attribute zu verpacken. Von mir aus gerne, aber das weitere Aufdröseln schafft neue Probleme und macht es insgesamt auch nicht signifikant übersichtlicher, eher im Gegenteil, sobald es komplexer wird.

(EDIT: Formatierung)

[martinp876]

Ich sehe die Schlacht als verloren.  Übringen finde auch ich es schade, dass ich mir so viele Module umschreiben muss. Aber Fritzbox ist schlicht unbrauchbar, wenn ich das "acticve von IP Adressen tracken will, Presence schiesst gleich dsa System ab (keine Übertreibung),...
Notify ist teil-funktional.
Aber der ganze Threat ist nur in Development weil ich versuchte, ein paar coading - nein besser Architecture, API und handling-guidelines zur Diskussion zu stellen. Am Beispiel notify.

Ich halte meine Version an verscheidenen Stellen immer noch für deutlich Überlegen. Am Ende aber ist klar, dass beide Versionen Events filtern und darauf hin Kommandos ausführen.
Da ich keine Beschreibung geliefert habe wurde es evlt nicht verstanden (ich dachte in diesem Forumteil wird das erkannt).
Am Ende werden ich das API einmal an beispielen Erklären - dann habt ihr Ruhe von mir

Weiterer Aspekt war, insbesondere auch auf rename-Events zu reagieren.

Das ist nicht ein Aspekt sondern vielen.
1) ich triggere auf "room=Wohn" (devspec versteht sich). ein Modul IST VERPFLICHTET, alle Renames und Attr room änderungen zu folgen
2) rename eines CUL_HM device wird dessen assitiation (peerings) mitnehmen. das MUSS ich mitnehmen.
=> faktisch denke ich, dass alle HW entites durch umbenennen nicht zu resetzen sind.
=> wenn ich also bei rename NICHT alle mitziehe geht es halbe-halbe aus. Jeder Profi würde das nicht gelten lassen
=> wenn du eine entity "tauschen" willst sollte man eine entsprechende Funktion bauen. "replace" bspw.
##> Ich betrachte es als schlicht schlchter Stil, wenn man Funktionen "missbraucht" - nur weil keine Systemfunktion gebaut ist.
##> eine Dokumentation wäre notwendig (mehr als commandref!) welche die Semantik beschreibt. "Was soll rename erreichen". Daran kann sich dann jeder halten.
Beispiel: Ein notify auf entity "dev1" - dev1 ist angemeldet. Nun ein Rename "dev1" nach "dev2". def1 ist angemeldet , gibt es nicht mehr. ganz schlechter Stil. def2 ist abgekoppelt, kein notify... geht für mich garnicht. Nach save/reboot könnte sich dann auch noch alles ändern. NO!

Jetzt müssen plötzlich noch andere Module (unabhängig von der Berechtigung mancher Kritikpunkte!) mitspielen

das ist keineswegs der Fall. ntf ist selfcontained.
ok, ich hätte gerne 2 Funktionen in der Kernal - oder besser die Platform-utilitits verschoben. Aber das ist eine 2. Sache.
Was ich dir empfohlen habe ist eine Presence-Lösung welche meine (nutzbare) FB-Lösung nutzt und meine (low-perfornamce, stable) presence lösung nutzt und über notify kopplet. ntf ist hier m.E. die bessere, aber nicht die einzige Lösung.
==> ich habe den Yamaha networkplayer auf Stand gebracht... der Entwickler hat dies dankbarerweise übernommen und auf der Basis weiter gemacht. Das war super - eine Zusammenarbeit.
-- ich finde es  nicht cool, die Module anfassen zu müssen, aber wenn ich die ergebnisse schlicht für unbrauchbar halten bleibt mir nichts anderes übrig. Fix it or leave it.
Bei Presence gab es übrigens zuspruch - eingecheckt habe ich nichts- alles privat.

Das Ganze ist mir jetzt zu groß, ich will eigentlich nach Möglich.....

hier hast du mich abgehängt. Du musst nur ntf einspielen und es funktioniert. - kann hier und da noch getunt werden, sicher. ntf liefert alleine keine Lösung zut IP-Addressen Überwachung. war klar - oder?

Wenn das nicht klappt, wäre es besser, direkt "PRESENCE2" im svn anzubieten, oder die alternative Version nach contrib zu packen.

so etwas hasse ich. dem Anwender x optionen presence anzubieten und er muss raten, was der Unterschied ist. Ich biete etwas an - im Forum. Wenn der Entwickler nicht einsteigt und es keine höhere Instanz gibt ist es eben nur privat. Sieht keine mehr der nicht nachfragt. Ich stelle es gerne zu Verfügung, zur Diskussion. Aber fhem vernichten mit tausend varianten zum gleichen Thema - ich nicht.
==> das genau sind aber Themen für dieses Forum hier. Es gibt aber - ausser von dir - keine inhaltliche Diskussion. Also Ende Gelände.

als "Konfigurator"/"Administrator" oder "User" schlicht und ergreifend wissen muss, wie die interne Abarbeitungs-Logik ist

Logisch - imme. Notify genauso wie ntf. Commandref noch nicht geschrieben. Ein Versuch siehe unten.

Durch das Trennen von Device und weiterem Event ergeben sich neue, ggf. unbeabsichtigte Kombinationsmöglichkeiten.

saubere Konfigurationsmöglichkeinte!

<trigger> ist in der "notify"-Schreibweise i

Also über Namen der Attribute kann man reden - das ist nicht der Kern hier - oder? Event ist ein Ereignis. Trigger der Auslöser. Notify ... nn ja. Defacto ist es ein Event-FILTER welcher ddas kommado tieggert (eher nicht notifiziert). Aber das ist nicht das kernthema.

Die Abarbeitungsreihenfolge wird (im praktischen Leben fast ausschließlich) durch den Device-Namen bestimmt

Es gibt keine reihenfolge. Siehe unten.

bei Bulk-Events (oder zusät

Hier mus sich in der Tat nacharbeiten. das kann komplex werden - aber ich denke anders als du gerade denkst. Erst einmal wird ein Kommando ausgelöst, wenn der ... filter... passt. Nur über "$NAME, $EVENT" könnten es mehrer kommandos werden. Das werde ich noch bedenken... gute Tip.
#######################

So jetzt das versprochene commandref-quicky
ntf filters events which are issued by READINGS setting for devices. ntf will filter the events. Once the filter is passed the command is executed.
An Event is defined as
"<device>:<readingName>: <readingvalue>"
Filter can be assigned to ntf in multiple ways.
1) trgDevice matches <device> AND trgReading matches <readingName> AND tgrReadvalue matches <readingvalue>
OR
2) trgDevice matches <device> AND trgEvent matches "<readingName>: <readingvalue>"
OR
3) trgCombined matches "<device>:<readingName>: <readingvalue>"

examples
trgDevice="basementLight";trgReading="level";tgrReadvalue=".*";
==> filter passed any time, level is set for basementLight

trgDevice="b.*";trgReading="level";tgrReadvalue=".*";
==> filter passed any time, level is set for any device named b.*

trgDevice="room=living";trgReading="level";tgrReadvalue=".*";
==> filter passed any time, level is set for any device with the attribut "room" = living

trgDevice="basementLight";trgReading="level";tgrReadvalue="100";
==> filter passed any time, level is set to 100  for basementLight

trgDevice="(basementLight|level1.*)";trgReading="level";tgrReadvalue="100";
==> filter passed any time, level is set to 100  for devices basementLight and any device named level1.*

trgDevice="basementLight";trgEvent="lev.*x.*7"
==> filter passed any time, "readingName. readingvalue" matches "lev.*x.*7"  basementLight

ntf willkeep the trgDevice up to date for any configuration changes. I.e. if the filter is type=CUL_HM an da new device is defined NTF will immediately consider this. This is appliable for all device-spec definitions.
trgDevice assignements comply to devspec but will not consider filtering on readings. Just attributs, NAME and TYPE are valid.

trgCombined allowes very deticated filtering - howver it is recommended for experts only.  Example
trgCombined=".*light.*100.*" will trigger if just the string is matched - no matter whether is applies tothe device, the reading or teh value.
It can be use e.g. like
trgCombined="(light1:level:.100|light2:level:.50)" will tigger if light1 is on 100 or light2 is on level 50.

Anmerkung:
ntf ist m.E. deutlich effizienter im Assignment der deivces zu den notifications. Das ist ewenig sichtbar aber für mich sehr wichtig. a) dass es nicht sichtbar ist (so etwas läuftin Hintergrund) und b) dass es effizient ist.
Beschreibung ist (wäre) nicht final. Mir muss ich es nicht erklären - also wird es nie geschrieben.

Set/Get Parser ist ein anderes thema - genauso spannend - zu viel hier. Zu viel für das auditorium hier.
Frohe weihnachten, da wars wohl

[Damian]

Wenn FHEM-User ntf nutzen sollen, dann musst du es in einem anderen Board publizieren, hier wird sich keiner von denen verlaufen

[martinp876]

wie ich sagte- werde ich nicht.
Es gibt ausreichend Optionen für Event->notify->trigger. Noch ein weiteres verwirrt - der Anwender muss sich erst einmal klar werden, was der Unterschied ist. Manche Unterschiede sind sichtbar, andere habe eine andere Ablauf/Config systematik welche für den Anwender unsichtbar, aber optimal sein soll. Am Ende hängt dies zusammen, ist ein Gesamtkonzept. Das klar zu machen ist ... geradezu unfair dem Anwender gegenüber.
Ich habe es hier gepostet da ich die "Technologie" - oder Methodik präsentieren/Diskutieren/darstellen wollte. Eine wirkliche Diskussion über das "Angebot" hätte ich mir von Programmierern gewünscht, daher auch dieses Forum.
Leider hat es nicht stattgefunden.
=> eine Abstimmung mit den Füssen ist möglicherweise üblich, aber ich werden mich daran nicht beteiligen.
Wie gesagt, keine Diskussion, Ziel nicht erreicht, Thema beendet.