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

[Ellert]

readingsList kann man sparen, alles was per set kommt, wird als Reading gespeichert.

Aktuell funktioniert  im Dummy nur die Kombination readingList und seLlist, ohne readingList wäre es dann eine neue Funktionalität.

[justme1968]

Erschreckend, dass Module wie LightScene ihren NOTIFYDEF nicht setzen

nein. ich finde es nicht erschreckend. zum einen ist LightScene sehr viel älter als NOTIFYDEF und zum anderen hat LightScene einige eigene Optimierungen eingebaut die nicht unbedingt schlechter als NOTIFYDEF sind. wenn z.b. kein browser offen ist wird die NotifyFn sehr früh direkt wieder verlassen.

im übrigen waren für NOTIFYDEF auch einige runden nötig weil die ersten versionen ohne cache zu langsam waren.

das heisst nicht das sich das ganze nicht noch optimieren lässt, aber zumindest habe ich bisher noch keine meldung gesehen das LightScene tatsächliche performance probleme hat. ganz so schlimm ist es also wohl nicht.

ich glaube es gibt stellen in fhem an denen eine optimierung deutlich mehr bringt. by the way: hast du mal gemessen wie die performance unterschiede zwischen vielen kleinen notifys für jede der 12 tasten im vergleich zu einer version mit einem notify für alle tasten und anschließendervVerzweigung sind?

[rudolfkoenig]

readingList ist in dummy notwendig, damit die set Argumente nicht im state landen.
Da ich nicht vorhabe, im notify state zu aendern, ist es da nicht notwendig.

[martinp876]

 nun - nachdem mein Threat gekapert wurde mache ich noch einen Versuch.

Angesprochen hatte ich eigentlich die (natürlich aus meiner Sicht) unpassende Defintion bspw von Notify. Weiter sehe ich nicht, dass dies für den User - insbesondere bei der aktuellen Doku-Lage wirklich einfacher ist. Es ist möglich, das aktuelle notify auch clever zu nutzen. Unterstützt wird es nicht, im Gegenteil.
Schade, dass sich schon alle arrangiert haben und somit zufrieden sind.
Stattdessen wird über readingList diskutiert oder setList. Konkret habe ich hierzu keine Meinung, da mich er Konkrekte Implementierungsplan, Syntax uns Semantik interessert. Scheinen alle zu wissen, ok - aber schon wieder ein abdriften.

Wie ich mit ein Notify vorstelle kann man im Anhang sehen. Es ist noch tuning notwendig....
Den WebInterface Wizzard müsste ich noch löschen. Doku ist auch noch nicht enthalten...
Ich werden das nicht veröffentlichen... Wäre aber schön, wenn das Ürsprüngliche Thema wieder betrachtet wird.
Erinnerung: keine parameter sondern Attribute
Bewertung unter ignorieren der aktuellen Implementierung - wie würde man es jetzt erstellen (grüne Wiese!). Erst danach: Wie kommt man da hin.

Btw: Mehrere Readings im Bulk zu setzen ist nicht meine Problem. Mache ich regelmäßig mit Userreadings.

Wäre schön, wenn wenigstens käme: das wollen wir nicht, weil inkonsistent.
Aber wer glaubt schon an den Weihnachtsmann

[rudolfkoenig]

Wäre schön, wenn wenigstens käme: das wollen wir nicht, weil inkonsistent.

Ich will das nicht, weil mAn der Nutzen in keinen sinvollen Verhaeltnis zum Aufwand ist.

[Benni]

Ich bin nicht abgeneigt, setList in notify einzubauen, falls auch Andere dafuer sind.
readingsList kann man sparen, alles was per set kommt, wird als Reading gespeichert.

Hallo Rudi,

Ich würde gerne nochmal auf diesen "Nebenkriegsschauplatz" aus der vorangegangenen Diskussion zurückkommen.

Das würde u.a. den Umweg über sertreading, sowie wahrscheinlich diverse userattr ersparen und natürlich die Eingabe vereinfachen

Was mir dabei allerdings zum Glück noch fehlen würde wäre, dass notify auch stateFormat unterstützt. Bisher ist zwar devStateIcon vorhanden, aber der Vollständigkeit halber sollte m.E. auch stateFormat dabei sein.

Mit dieser Kombination könnte ich zumindest bei mir eine ganze Menge dummy-Devices und teilw. readingsProxy los werden.

Vielleicht magst du deiner Unabgeneigtheit bei Gelegenheit noch nachgeben?

Eventuell fände das auch noch der eine oder andere gut, dann kann er das ja gerne noch kund tun.
(Müsste man ggf. mal noch außerhalb des Developer-Bereichs abfragen?)

gb#

[rudolfkoenig]

Ich warte nur auf Meldungen, hier: https://forum.fhem.de/index.php/topic,123956 gibt es schon eine Umfrage, bisher ohne Feedback.
Diese Diskussion sollte auch da weitergefuehrt werden.
Bei zwei Leuten bin ich ja schon fast soweit, was zu tun

[martinp876]

Ich habe notify nun einmal nach meinem dafürhalten umgebaut. Ist aktuell nicht aufwärts kompatibel - kann man aber machen. Dennoch sehe ich hier einige dinge realisiert welche Rudi sowieso wieder ablehnen wird . Alles in allem sind hier m.E. einige Aspekte realisiert welche ich mir wünschen würden - unabhängig von notify. JEDES! module sollte nach diesen Grundsätzen arbeiten - oder abgewandelt, klar. Aber Grundsätze eben.
Das schränkt die Freiheit der Programmierer ein - was m.E. kein Schaden sein muss.
Und eigentlich ist es nicht so weit weg von allem - nur eben STRICT! Wird nicht gerne gesehen hier.
Grundsätze sein
1) CPU performance @ operations
2) memory performance
3) CPU performance @ config
4) WISIWIG

Die Kommandos werden definiert auf Module ebene und/oder auf entity Ebene. Vielen Modulen wird die Modulebene reichen (notify bspw) - einigen nicht (CUL_HM,...).
Jedes Kommando wird spezifiziert - möglichst komplett mit Parametern.
Der Parser "ntf_cmdParser" prüft die Kommandos und deren Parameter nach Anzahl und Inhalt gemäß Spec. Default Parameter werden automatich eingefügt.
=> beim Abarbeiten der Kommandos kann sich der Programierer darauf verlassen, dass mandatory params auch vorhanden sind
=> der User kann mit "get cmdList" sehen, was programmiert ist - direkt. Nicht von einer Kopie sondern im Orginal
=> Defaults werden gesetzt - automatisch
=> die replies bei fehleingabe sind standartisiert
>>> die Funktion ntf_cmdParser ist generisch und kann so für jedes Modul eingesetzt werden. Eigentlich sollte es eine kernal funktion sein. Eigentlich sollte sie automatisch ausgeführt werden.

Ein starres System? nein.
- Kommandos können auf Modul-ebene on-the-fly nachgereicht/modufiziert werden - ok. der Programmer muss ein re-eval starten.
  eingebaut haben ich zum testen alle Kommandos mit "tst.*". Hier kann der geneigte Programmer einmal neue Kommandos einpflegen und löschen. Diese Funktionen sind natürlich nicht relevant für notify, nur zur Evaluierung.
- Parameter mit "Dynamic Option List" werden automatisch gearbeitet. Sowohl in drop-down listen alsauch im parser

=> der Anwender bekommt nun konsistente Eingabe - bspw wenn ein Kommando keinen Parameter hat wird auch KONSEQUENT! noArg eingetragen. Eine Schlamperei welche ich schon häufig gesehen habe.

=> die Performance  des beliebten und wichtigen Kommandos "set xx ?" und "get xx ?" liegt deutlich unter 1ms!

Eingebaut sind set, get und auch attr. Leider ist das Handling bei attr abweichend - nun ja. Dennoch habe ich den selben Algorithmus eingebaut.
Die Funktion "ntf_AttrCheck" ist hier notwendig - siehe Implementierung. Hier wird auch konsequent durchgesetzt, dass nur gültige Attribute zugelassen sind. Der User muss also erst UserAttribute definieren bevor er sie nutzen kann. Wenn er UserAttribute löscht mussen auch die Attribute gelöscht werden. Eine hässliche Lücke in fhem welche schon seit beginn besteht. Das handling der userAttr habe ich noch nicht drin werde ich in ntf aber noch machen.
==> es kann nicht sein, dass attribute eingetragen werden können welche eine Reboot nach Save nicht überleben!


So - nun noch eine etwas weichere Forderung - notification/rename/define/... . Notifications von "global" sind - im Gegensatz zu allen anderen  - Config-notifications. Alle anderen sind "operational-notifications".
Jedes Modul  - übergreifend - Konfigurationsänderungen berücksichtigen. Das ist eigentlich standard. fhem hinkt hier weit hinterher.
Beispiel: Ich habe ein Notify welches auf  die Entity "LichtWohnLinks" triggert. Mache ich ein Rename von LichtWohnLinks nach LichtWohnraumLinks muss das notify automatisch! angepasst werden. Das trifft natürlich nicht auf "LichtWohn.*" zu. Alle nicht-unique entites werden nicht angefasst.


Fürs erste einmal gut. Zum Eigentlichen Notify nehme ich getrennt Stellung, kommt noch.

=> ich werde nur noch so arbeiten, auch wenn das Konzept -  wie vorhersehbar - abgelehnt wird.

[martinp876]

so, nun abgegrenzt die (einseitige) Diskussion zum Notify.
das "ntf" Spielzeug zeigt, wie es bei mir aussehen würde. Wenn "notify" nicht auf einen angemessenen Stand gebracht wird werde ich wohl mit meiner Version arbeiten. Natürlich ungefährlich - sieht ja keiner.
Was macht den Unterschied:

Pseudo -attribute in der Kommandozeile sind ein no-go. Nicht diskutable und nur durch historische Hintergründe zu rechtfertigen. Dieser Tage geht es garnicht.
Aus meiner Sicht schwierige Trennung des "trigger-Filter" nach trigger-device und trigger-event. Das kann man deutlich sauberer machen - für mich ist das ein schwer zu behandender Klumpen.
Wenn man es stringent macht kann man auch das enrolen beim Notify-filter wasserdicht UND flexibel gestalten. Einfaches Beispiel ist:
- triggerDevice ist ein regex (oder device-spec) wie la.* oder "attr room schlafzimmer"
- die betreffenden Devices werden identifizert und angemeldet
- bei einer config-Änderung (rename, define, delete, attr) werden die Devices neu gesucht und enroled
=> eigentlich nichts besonderes, so muss das.

ich habe 2 Optionen zur Trigger-erkennung vorgesehen - combined und getrennt nach triggerName und triggerEvent

Bei Trigger-combined kann man über ein Kommando neue trigger addieren oder alte entfernen. Es ist KEIN fancy web-interface notwendig.
=> man sollte erst versuchen, die Funktionen mit Bordmitteln zu lösen bevor man extra-frontends einbaut. Aus meiner Sicht ist das frontend-addon schlicht unnötig.

Falls Rudi mit den Argument kommt, attribute darf man nicht verändern müsste ich die Augen verdrehen. Das Define wird aktuell manipuliert - auf seltsame weise. Bei mit klappt es nicht, da es nur bei einigen wenigen Formen der Trigger-filter klappt.
Nein, die aktuelle Implementierung halte ich für kompliziert, unfelxibel und auch noch unschön.

Selbstverständlich werden in den Readings wesentliche daten automaisch angezeigt (eigentlich eine Selbstverständlichkeit). So ist das letzte triggernde Device als auch das event zu sehen. m.E. immer sinnvoll und auch extrem hilfreich beim Einrichten und Testen.

Gets waren bisher wohl auch verpönt. Ein get trgFilter zeigt mir, welche events von welchem Device mir dieses Notify auslösen.
"shEnroled" könnte man weglassen, bei mir bleibt es noch.

Was ich noch nicht bearbeitet habe ist, die probably assiciated list auf Stand zu bingen. Warum ich das internal "NOTIFYDEV" permannent brauche ist mir unklar - insbesonderen wenn die Liste lang wird stört mich der Eintrag mehr , als er nutzt. Hier könnte man zumindest smart abkürzen.
=> ein standard-get ala shEnroled ist deutlich besser, da sortiert und formatiert

Ach ja, neben den gets sind die "get list" und "get cmdList" eigentlich kernal-kommandos. Die sollten immer da sein. "get  notifyEnroled"  würde dazu passen.

Alles zusammen ist das meine beta-Version. Sicher nicht bug-frei und es werden mir noch Verbesserungen einfallen.

Das bestehende Notify auf einen "Modernen" Stand zu konvertieren ist mit Sicherheit möglich - wenn man will

Ich gehe davon aus, dass der Vorschlag den üblichen Weg meiner Vorschläge folgt. Damit werde ich mich wohl alles auf meine "ntf" umstellen. Notify ist machbar aber nicht tragbar für mich.

Und noch einmal - die seltsamen sonder-kommandos "tst.*" sind nur zum Ausprobieren für programmierer - mit notify habe sie nichts zu tun.
Frohe Weihnachten.

[martinp876]

scheint keinen mehr zu interessieren - verstanden.
Hier nun eine schon recht gute Version.
Die generische Prüfung von get/set ist lauffähig - parameter-check operational, dynamic-options funktioniert. Default-options klappt
get cmds und get list sollten generisch sein

zum eigentliche Notify
mit trgDevice kann man devspec nutzen. Wie es der Anwender erwaren kann wird die devspec ständig überwacht und angepasst. Renames werden erfasst genau wie definitionen.
Natürlich werden Attribute nur zugelassen, wenn sie definiert sind (sollte selbstverständlich sein)
Initialize wird berücksichtigt und attribute erst danach kontrolliert (selbstverständlich?!)

ntf_cmdParser werden ich ein
myKernal_cmdParser
umsetzen, da es auch vom "at" modul und allen anderen meinen Module genutzt werden wird.

Keine Angst, ich werde das nicht einchecken - das werde ich privat nutzen.
Und jetzt lasse ich euch in ruhe - mit dem Gefühl, dass Innovation und Struktur nicht wirklich ein Thema hier ist -noch nicht einmal diskutiert wird. Schade

[martinp876]

so, zumindest einer hat sich noch interessiert, daher poste ich meine aktuelle Version - und erkläre sie.
Hier beschreibe ich jetzt einmal das API für den Sys-Configurator und wo ich die Vorteile sehe
1) die attribtue werden, wie schon beschrieben, in attributen, nicht im define abgebildet. Selbsterklärend.

2) trigger-namen
- werden sauber im Kernal notify-hash angemeldet
- können als "devspec" mit regex eingetragen werden - oder auch nicht. Natürlich auch regex für namen
- kernal-notify wird auf Stand gehalten bei allen Config Änderungen (rename, define,ignore,...)
- devspec auswertungen sind eingeschränkt. Es werden nur "config" relevante elemente betrachtet. D.h. Readings werden ausgeklammtert. Internals sind eingeschränkt, da diese nicht sauber unterschieden werden. Attribute sind Konfigurationen.

3) Der User hat mittlerweise 3 Möglichkeiten, den trigger-filter zu gestalten. Ihm muss bewusst sein, das ein trigger-filter besteht aus
<device>:<reading>: <value>
wobei er ":" und ": " beachten muss. Sicher ein lustige Falle... naja
a) explizit: attribute "tgrDevice", "trgReading","trgReadValue" können eingetragen werden. ALLE mit regex. Diese Optionwäre wohl für Anfänger passend.
Vorteil: Der User kann sich seine Readings ansehen und entscheiden: Diesen will ich haben. Die ":" werden automatisch gesetzt
b) readingPacked:"tgrDevice", "trgEvent"
Als trgEvent ist "<reading>:  <readingValue>" einzutragen. Den ": " muss er selbst setzen.
Vorteil: man kann lustige Kompinationen aus reading und value gestalten.
trgEvent wird kumulativ zu "trgReading","trgReadValue" eingebaut.
c) allIn: "tgrCombined".
Der Konfigurator erstellt eine komma-separierte Liste aus Filtern. Sehr mächtig - für Fortgeschrittene. Das Format ist wie bisher. Evtl muss beim "Komma" nachgebessert werden.
Das Modul erkennt automatisch die hier enthaltenen "trgNames" und meldet sie an.
Auch dieses attr wird kumulativ eingebaut.

4) entity Info
der User kann nun seltsame konfiguraionen erstellen und fragt sich, was nun eigentlich Sache ist. Es ist natürlich PFLICHT!!! ihn hier zu unterstützen.
a) get trgFilter
gibt eine Aufstellung zurück, welche entites nur gefiltert werden und welche Readings/values hier relevant sind
(ich sollte noch einbauen, dass Readings und values deutlich unterschieden werden in der Anzeige - gute Idee)
b) get shEnrolled
zeigt hart an, welche entites von Kernal nun durchgereicht werden.
Vorteil zu "NOTIFYDEV": die Liste könnte länger werden. NOTIFYDEV kann hier den gesamten Bildschirm versauen
NOTIFYDEV ist nicht vorhanden wenn .* eingetragen wird. Das ist sowieso irreführend.
NOTIFYDEV brauche ich eigentlich nicht. Geschmackssache

5)Readings
es ist eigentlich selbstredend, dass die letzten Trigger als Reading  erscheinen.

6) Aufräumen
ein "set clear" sollte immer zu verfügung stehen, alte Readings zu entfernen. Ein cleansweep erleichtert das debuggen.

7)logTrgNames
nun, hilfreiche für eine Übersicht.

Defizite:
- ntf ist nicht eingebunden in "events" und den autmatischen update. Eine kleinigkeit, es zu machen. Für mich persönlich irrelevant - so arbeite ich nicht.
- tgdCmds muss man manuell eintagen. Da "set" recht schmall ist könnte hier ein wizzard helfen. Allerdings sind meine Kommandos typisch nicht durch einen wizzard zu lösen. Dennoch eine Option.
- ein paar kleinigkeiten welche ich nachbessern werden.

[martinp876]

bugfix ( noch nicht bug-free - sorry)

[martinp876]

noch ein Nachtrag:
alle trigger sind gleich - nur einige sind gleicher.
"Global" ist eine andere Kategorie von triggern. Die sind hier reingewurstet... macht es nicht einfacher, aber möglich.
Global bietet alle Sys-Kommandos sowie die eigenen Readings. Da der Kernal hier nicht unterscheidet muss es der Anwender. Glücklicherweise kommt es nur selten vor.
Programmer allerdings mussen es berücksichtigen.

[Beta-User]

Also, ich würde das gerne mal aus User-Perspektive verstehen wollen. Daher hier der Versuch, mit der letzten ntf-Version folgende Aufgabe zu lösen:

Die Fritzbox meldet regelmäßig, welche mac-Adressen noch da sind bzw. wer ggf. dann inaktiv geworden ist. Die mac-Adressen sind - soweit interessant - einzelnen RESIDENTS-Instanzen zugeordnet, anderer Code ist dann dafür zuständig festzustellen, ob daraus ein "present" gebastelt werden soll usw..

Meine aktuelle Lösung:

Code: [Auswählen]

define rr_xn_MAC_Check notify Fritzbox:mac_.*:.* {\
  chop($EVTPART0);;\
  my $target = getKeyValue($EVTPART0);;\
  return if !$target;;\
  $EVTPART1 eq "inactive" \
  ? fhem("setreading $target smartphone absent")\
  : fhem("setreading $target smartphone present");;\
}Die Zuordnung von mac-Adresse erfolgt also derzeit (zugegebenermaßen: etwas überkompliziert) über das Auslesen der Werte aus uniqueId (früher mal mit 'fhem("set TYPE=dummy:FILTER=smartphone_MAC=$EVTPART0 smartphone absent");;\'). Nachdem ich gestern erst darüber nachdenken mußte, wie man die Zuordnung aktualisiert, wenn mal wieder jemand das Smartphone getauscht hat, stellt sich die Frage, wie man sowas mit ntf so löst, dass der "user" das unfallfrei hinbekommt.

Also mutig ans Werk.

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...? Jetzt habe ich zwar diese "event-to-action"-Tabelle via Attributen vor meinem geistigen Auge, bin aber im Prinzip bei "Defizit #2" angelangt:

tgdCmds muss man manuell eintagen. Da "set" recht schmall ist könnte hier ein wizzard helfen. Allerdings sind meine Kommandos typisch nicht durch einen wizzard zu lösen. Dennoch eine Option.

Eventuell könnte es helfen, eine Art "devspec-to-action"-Attributliste generieren zu können, aber für meine Aufgabe bräuchte es dann vermutlich ein Attribut pro mac-Adresse und Richtung. Auch nicht unbedingt selbsterklärend aus reiner User-Sicht.
Aus "Konfigurator"-Warte fehlen mir vermutlich noch ein paar Beispiele, wie man sowas zweckmäßigerweise löst, aus heutiger Sicht werde ich wohl das notify-Perl so erweitern, dass die mac-Adressen per Hash einem RESIDENT zugewiesen werden, dann ist der Teil an einem Ort vereint.

Bilanz aus meiner Sicht zu einigen anderen angerissenen Punkte bis hierher:
- wie NOTIFYDEV ermittelt wird, ist für viele User (nicht nur bei notify, auch bei ähnlichen Modlen wie FileLog, DbLog und watchdog) unverständlich. Ein besserer Parser wäre super, ist aber vermutlich nicht "günstig" zu bekommen (meine eigenen Versuche, dazu einen Vorschlag zu machen, habe ich irgendwann mangels Erfolg eingestellt, immerhin kann man als "Wissender" mit der dafür vorgesehenen Funktion feststellen, an welcher Stelle es hakt).
- den "wizzard" (für notify und at) habe ich in der Vergangenheit wenn, dann nur versehentlich "genutzt", den Drang, diese Funktion auszuschalten (siehe z.B. https://forum.fhem.de/index.php/topic,123819.msg1185275.html#msg1185275), kann ich daher durchaus nachvollziehen...

Der Strauß ist also groß, und ich würde jetzt gerne erst mal wissen, wie die "Muster"-Lösung zu meinem obigen Problem ggf. aussehen könnte.

[martinp876]

1) meine FB Implementierung funktioniert wieder einmal nicht. Somit kann ich es nicht nachstellen - also alles "Trocken"

2) dass Modul-specific attr alphabetisch einsortiert werden habe ich bereits angemerkt und es sollte nach etwas hin und her nun so eingebaut sein. Grundsätzlich kann ich das  nicht beeinflussen.

3) zu 2.: nun könntest du das reading-value eingeben, wenn du willst. Default ist "alles", also ".*"
  -> eine Einbindung in den Event-Monitor ist jederzeit möglich - da ich es nicht brauche habe ich es noch nicht realisiert. Hier ist auch jede Menge Luft nach oben...

4) das Kommando
   hier hast du tatsächlich recht, es gibt keine Unterstützung. Ist aber kein Konzept-problem und ich kann es auf unterscheidliche Arten lösen.
   a) notify unterstützt dies mit der web-application. Diesen Teil könnte man einbauen... Das unterstützt "einfache" Kommandos (welche auch gebraucht werden)
   b) Die Implementierung wie bei "registern" in CUL_HM - also ein pop-up. Ist deutlich schöner finden ich. Die Funktion ist erst einmal identisch. Allerdings kann man die Liste VIEL! schöner machen
   c) Komplexe Kommandos kann man nur schwer unterstützen. Hier hat der konfigurator explizit die Freiheit, coole Sachen zu machen. Das ist ein Grund, warum ich fhem gewählt haben.

Also: du kannst dein Kommando wie bisher in

Code: [Auswählen]

attr rr_xn_MAC_Check trgCmd {\
  chop($EVTPART0);;\
  my $target = getKeyValue($EVTPART0);;\
  return if !$target;;\
  $EVTPART1 eq "inactive" \
  ? fhem("setreading $target smartphone absent")\
  : fhem("setreading $target smartphone present");;\
}
eingeben.
=> schlechter ist das nicht - besser auch nicht.

Um für dein Anliegen nun einen Vorschlag zu machen (ich suche auch hier nach einer Lösung) müsste ich die Readings sehen. Du musst das Event in den Namen in FHEM übersetzen.

Code: [Auswählen]

{fhem ("setreading $EVTPART0 smartphone ".($EVTPART1 eq "inactive"?"absent":"present"))}sollte hinreichend sein. Wenn es das target nicht gibt, wird nichts gemacht - das Kommando prüft es sowieso - musst du nicht.
Das mit "getKeyValue" kenne ich nicht, wäre aber

Code: [Auswählen]

{fhem ("setreading ".getKeyValue($EVTPART0)." smartphone ".($EVTPART1 eq "inactive"?"absent":"present"))}Eine Zeile, alles drin.
Wenn meine FB wieder einmal antwortet werde ich es noch einmal ansehen. Allerding ist das auch ein modul, mit dem ich überhaupt nicht zufrieden bin. Ich würde sagen, man hat wert auf user-feindliche Darstellung gewählt.
btw: ist das Attribut "trgCmd" nicht verständlich? Welcher Name wäre besser, um zu erfassen, dass hier das "Commando" hinterlegt werden soll, welches bei erfolgreichem Trigger ausgeführt werden soll.

Zum ntf:
Ich werden "state" immer explizit eingeben - das ist in deiner Version  noch nicht enthalten. Grundsätzlich sollte man beim Erstellen eines API prüfen, ob es komplitzert ist. Wenn man das beschreibt und ma viel schreiben muss um es zu erklären, ist es komplex.
ntf besteht im Wesentlichen aus dem Event-Filter und sekundär aus den Kommando.
Ich beschreiben einmal, wie ich "ntf" dokumentieren würde (also mal schnell so runter...)

ntf is a module to execute commands dependant on events. I.e. the event triggers the command defined by ntf "trgCmd".
An event raised when a reading of a device is set or changed. See also "event-on-change-reading" and "event-on-update-reading". An event ist assembled as
       <deviceName>:<readingName>: <readingValue>

Da wäre nun einfache - anzumerke ist, um komplett zu sein
- der Programmierer kann das Triggern von Events unterbinden. da wartet man nun lange.
- das "state" reading wird ausgeblendet - was das erstellen und parsen des strings absolut unnötig verkompliziert. Ich bin schon oft hierrüber gestolpert - und nutze nun das Reading "state" grundlätzlich nicht für filter. In ntf habe ich nun umgeschaltet auf "state" einblenden - immer.
- konfigurationen sind zu erklären. Also alle events von "global". auch auf diese kann man triggern. Allerding ist das Format unterschiedliche. Auch ist keine Liste dokumentiert, was hier alles kommen kann (und wann)

So, jetzt FB reparieren