set ohne Event möglich?

[Guybrush]

Vielleicht noch zur Klarstellung: Wenn NOTIFYDEF nicht gesetzt ist und/oder die trigger-regexp zu weit ist, wird der Code uU. zu oft aufgerufen oder durchlaufen und man hat ggf. in der Tat ein Problem. Ansonsten wäre es ggf. ein Indikator, dass irgendwas zu oft/an der falschen Stelle triggert.

Guter Hinweis! Aber hab ich das nicht schon maximal eingeschränkt?

Code Auswählen Erweitern


defmod Kinderzimmer_klein.Klima.Notify notify (KNX.Kinderzimmer_klein.Klima|Kinderzimmer_klein.Klima):\s?(on|off) {}


das triggert doch nur wenn state on oder off ist. Ansonsten triggern die KNX Devices bei mir alle mehrfach (state, g1 und last-sender). Mit der Regex aber nur wenns ein/aus geschaltet wird. Muss aber mal schauen, ob ich das nicht global für diese KNX readings abschalten kann. Wüsste jetzt nichts, wofür man da Notifys braucht und hab im KNX Modul selbst keine Option gesehen, mit der man das do_trigger beim Readings Schreiben beeinflussen kann

[Beta-User]

Guter Hinweis! Aber hab ich das nicht schon maximal eingeschränkt?

Code Auswählen Erweitern


defmod Kinderzimmer_klein.Klima.Notify notify (KNX.Kinderzimmer_klein.Klima|Kinderzimmer_klein.Klima):\s?(on|off) {}


An sich sieht das schon so aus, wobei das immer noch NOTIFYDEF kaputt macht und ich es daher nicht im Detail sagen kann, was da ggf. noch abläuft.

Fakt ist: Mein Code setzt NOTIFYDEF und funktioniert zumindest ohne "Geklackere" mit zwei ZWave-Devices völlig stressfrei - mit je genau einer "manuellen Einschaltung" gefolgt von genau einer "versklavten" (bzw. dasselbe für aus). (setReadingOnAck am IO ist allerdings gesetzt, ohne diese Einstellung habe ich nicht getestet).
Und genau das ist auch im Event-Monitor zu sehen (dein Log3 wird nur aufgerufen, wenn auch das notify läuft, richtig?)
Für alles andere müßte man den verbose-Level für die beteiligten Geräte hochdrehen und das näher ansehen.

[erwin]

...und hab im KNX Modul selbst keine Option gesehen, mit der man das do_trigger beim Readings Schreiben beeinflussen kann

FHEM standard Attribute 'event-on-...' sind auch im KNX-Modul unterstützt!

Aber grundsätzlich: dein notify triggert auf das 'state' reading (on/off)... - und damit mehrfach vom KNX-device!
Sinnvoller wäre auf das (der richtigen GA) entsprechende reading zu triggern, aber ohne list vom KNX-device ist das schwierig, konkret zu helfen.
Beispiel:

Code Auswählen Erweitern

defmod Kinderzimmer_klein.Klima.Notify notify (KNX.Kinderzimmer_klein.Klima\sg1|Kinderzimmer_klein.Klima):\s?(on|off) {}
... unter der Annahme, das reading heisst: g1
l.g. erwin

EDIT: genaugenommen brauchts den notify zweig für das KNX-device nicht, das könnte man im KNX-Device direkt erledigen, in etwa so:

Code Auswählen Erweitern

attr <knx-device> stateCmd { fhem "sleep 0.05 quiet;; set Kinderzimmer.klein.Klima $state" if ($gadName eq 'g1');; return $state;; }

[Beta-User]

Aber grundsätzlich: dein notify triggert auf das 'state' reading (on/off)... - und damit mehrfach vom KNX-device!

... was aber gleichgültig sein sollte, da ja nur auf ^on|off$ eingegrenzt. Von daher kann es eigentlich auch nicht sein, dass das betr. notify den KNX-Aktor (wegen Events des KNX-Devices!) auch direkt wieder schaltet, das ganze klingt danach, als würde "das andere Modul" irgendwas komisches veranstalten - was wiederum der Grund ist, warum ich den Event-Punkt an der Stelle so stresse. (@erwin:) Wir (Guybrush und meinereiner) hatten über diverse Aspekte an dem Modul (vermutlich) schon eine Diskussion per pm, diesen Teil hatte ich mir allerdings nicht angeschaut, zumal ich das vermutlich auch nicht wirklich nachvollziehen könnte ohne Gerät...

Was das KNX-Modul angeht (@Guybrush: das bezieht sich wieder auf eine andere interne Diskussion), fände ich es nach wie vor überlegenswert, ob man nicht die "Kommunikationsdaten" aus dem state raus hält und ein eigenes Reading dafür generiert (ggf. mit Attribut für backwards-Kompabilität).

Für "das andere" Modul wäre nach wie vor der Vorschlag, zwischen "es wurde gesendet" ("set on") und "es wurde geschaltet" ("on") etc. in "state" zu unterscheiden. Dann passieren bei entsprechend engem Trigger auch keine Mehrfachschaltungen woanders hin...

[Guybrush]

guter Punkt! Treibt natürlich die Komplexität nach oben, aber ich wollte da eh eine Queue einbauen, da die API regelmäßig irgendwelche Aussetzer hat und Befehle damit verschluckt werden. In dem Zuge dürfte das dann aber nur eine Trivialität sein zu integrieren.

Ansonsten wegen fehlender Testmöglichkeit. Gestern hatte ich laut Wetterstation 41,2 C hier. Ich brauche nicht zu erwähnen wie toll das mit Klima bei 23 C war (dank PV sogar für umsonst ). Wäre also eine Überlegung wert ein paar Testgeräte anzuschaffen . Wenn du die in Italiens kaufst und selbst installierst kostet dich das auch nur 3-4k in Gänze. Hab meine zweite hier auch komplett selbst installiert

@erwin - ich hab bei allen devices die standardnamen drin bzw nicht seperat benannt. du meinst, dass es grundsätzlich besser ist notify bei knx nicht auf state sonder g1 zu legen? offen gesagt hatte sich mir bislang noch nicht erschlossen warum es g1 neben state gibt. das macht nur sinn bei mehr als einer knx adresse was deswegen default auch bei 1 einzelnen so drin ist?

@betauser - ich hab dad mit dem notifydef immer noch nicht verstanden, wo das problem liegt. Sind das die Klammern, weil da matches zurückgegeben werden?

[erwin]

@Beta-User

... was aber gleichgültig sein sollte, da ja nur auf ^on|off$ eingegrenzt

stimmt so nicht ganz: es könnten in dem KNX-device mehrere dpt's definiert sein, die bei entsprechenden KNX-Bus msg's ihre "Kommunikationsdaten"-readings UND das state-reading setzen. Daher mein Einwand: mehrfach . Hab ich eigentlich schon geschrieben, dass ein list "knx-device" hilfreich wäre ? 

Was das KNX-Modul angeht (@Guybrush: das bezieht sich wieder auf eine andere interne Diskussion), fände ich es nach wie vor überlegenswert, ob man nicht die "Kommunikationsdaten" aus dem state raus hält und ein eigenes Reading dafür generiert (ggf. mit Attribut für backwards-Kompabilität).

Das ist jetzt schon möglich (state reading nicht setzen oder auch modifizieren), default ist (aus historischen Gründen) allerdings das state reading mit jeder msg vom KNX-Bus zu setzen, und zwar zusätzlich zum "kommunikationsdaten-reading"
Exakt auf dieses "Kommunikationsdaten" - reading hab ich mich im letzten post bezogen.
Die betreffenden Attribute sind: stateRegex und stateCmd. Beispiele gibts dazu im wiki.
l.g. erwin

[erwin]

offen gesagt hatte sich mir bislang noch nicht erschlossen warum es g1 neben state gibt. das macht nur sinn bei mehr als einer knx adresse was deswegen default auch bei 1 einzelnen so drin ist?

Ja das stimmt, allerdings gibts (fast) keinen KNX-Aktor, der keine Rückmeldungs GA hat.
Meine FHEM-KNX-definitionen beziehen sich alle auf Aktoren, die Verknüpfung mit den Tastern erfolgt ja ohnehin auf KNX/ETS Ebene.
l.g. erwin

[Beta-User]

ich hab dad mit dem notifydef immer noch nicht verstanden, wo das problem liegt. Sind das die Klammern, weil da matches zurückgegeben werden?

a) Das "Problem" ist (nur), dass das ineffizient ist, weil das notify dann (ohne gesetztes NOTIFYDEF) bei JEDEM Event (von allen Devices) aufgerufen wird und geprüft wird, ob die trigger-regexp paßt.
Mit gesetztem NOTIFYDEF nur noch bei den Geräten, die davon erfaßt sind...
Geht zwar schnell, aber "Kleinvieh macht auch..."

b) Die Erkennung der Devices erfolgt über eine Auswertung, deren oberster Trenner die Pipe ist. "Kaputt" machen also nicht die Klammern allein, sondern die Pipe-Zeichen innerhalb einer Klammer... Da aber Pipe ohne Klammer länger ist im Schreiben (und .* als Beginn eines Device-Namens auch nicht akzeptiert wird), sind es "gefühlt" die Klammern, die stören...

Fakt ist: meine trigger-regexp ist prinzipiell "sauber" (genug), um nur die gewünschten Events zu erfassen UND fhem.pl ein NOTIFYDEF erkennen zu lassen. Warum also nicht einfach übernehmen? (das optionale whitespace kannst du bequem knicken, an der Stelle kommt nie ein Leerzeichen!).

[Guybrush]

ich glaub ich hab bislang was anderes verstanden gehabt als du. du meinst mit NOTIFYDEV den Key "NOTIFYDEV" innerhalb des Hashs eines Moduls, worüber man steuern kann ob ein Notify über die notifyFn Funktion des jeweiligen Moduls verarbeitet werden soll oder nicht? Wenn da nichts (einschränkend) gesetzt ist oder die regex nicht sauber erkannt wird, wird von jedem device die Modul notifyFn Funktion aufgerufen? Und damit die Überprüfung richtig greift sollte man keine Pipes nutzen, weil diese für das Filtern des Devicenames nicht funktionieren?

[Beta-User]

ich glaub ich hab bislang was anderes verstanden gehabt als du. du meinst mit NOTIFYDEV den Key "NOTIFYDEV" innerhalb des Hashs eines Moduls, worüber man steuern kann ob ein Notify über die notifyFn Funktion des jeweiligen Moduls verarbeitet werden soll oder nicht? Wenn da nichts (einschränkend) gesetzt ist oder die regex nicht sauber erkannt wird, wird von jedem device die Modul notifyFn Funktion aufgerufen? Und damit die Überprüfung richtig greift sollte man keine Pipes nutzen, weil diese für das Filtern des Devicenames nicht funktionieren?

Das ist m.E. etwas "schräg" formuliert, und besser formulieren als schon geschehen kann ich wohl nicht...

Die summary ist und bleibt: Ohne gesetztes NOTIFYDEF (ja, das Internal) ist die Verarbeitungslogik etwas ineffizienter als mit (grober Anhaltspunkt: ist es gesetzt, spart das ca. 30% Laufzeit für jeden Eventhandler).

Es gibt eine Funktion, mit der man sehen kann, wie fhem.pl das auseinandernimmt, vielleicht hilft das weiter:

Code Auswählen Erweitern

{notifyRegexpCheck('(KNX.Kinderzimmer_klein.Klima\sg1|Kinderzimmer_klein.Klima):\s?(on|off)')}

[erwin]

Hi Beta-User,
danke für den hint!
Der Logik folgend müsste es dann so aussehen:

Code Auswählen Erweitern

{notifyRegexpCheck('(KNX.Kinderzimmer_klein.Klima: g1|Kinderzimmer_klein.Klima: on|Kinderzimmer_klein.Klima: off).*')}
...ist zwar nicht unbedingt elegant, aber erfüllt alle Bedingungen!

Aber wie schon geschrieben, das notify für's KNX device kann man sich sparen...
l.g.erwin

[Beta-User]

Gerne.

Habe jetzt nicht extra die Devices angelegt, aber falls solche vorhanden sind, sollten dann nur Zeilen mit "OK" zurückgeben werden. Allerdings dürfte das mit dem Leerzeichen Probleme geben, die müßten (so sie denn im Event vorhanden wären!) durch einen Punkt ersetzt werden.
Und ob die Erweiterung "nach hinten" für alle Events sinnvoll ist? Falls mal jemand on-for-timer setzt, greift das auch (was dann zu Doppelevents führt, wenn SetExtensions ins Spiel kommen).

Dagegen sollte

Code Auswählen Erweitern

{notifyRegexpCheck('KNX.Wohnen.Klima:g1.*|Wohnen.Klima:o[nf]+')}zwei "OK" zurückgeben und den "g1-Fall" unbeschänkt mit abdecken.

[erwin]

ja, 2 ok's, dass passt!
Ich hab die notifies jetzt nicht getestet, stehe immer noch mit den Leerzeichen auf Kriegsfuß 
Mein Versuch mit dem eventmonitor:

Code Auswählen Erweitern

2022-07-21 14:19:22.868 KNX Windspeed getG1: 1.18
create/modify device-button - ergibt das:

Code Auswählen Erweitern

define Windspeed_notify_1 notify Windspeed:getG1:.1.18 {}
also KEIN Leerzeichen zw. dev und reading ABER ein Leerzeichen zw. reading und Value!

Allerdings:

Code Auswählen Erweitern

2022-07-21 14:28:02.853 KNX Windspeed 8.7
define Windspeed_notify_1 notify Windspeed:8.7 {}
.. offensichtlich hat das was mit addStateEvent zu tun....

[Beta-User]

.. offensichtlich hat das was mit addStateEvent zu tun....

Eher andersrum: Es gibt das betr. Attribut, weil es manchmal (!) eben sinnvoller sein kann, das "volle Programm" (incl. Reading-Namen "state") auszuwerten. Siehe DoTrigger() in fhem.pl (bzw. die deviceEvents()-Funktion).

Ansonsten ist es eigentlich einfach: Der erste Doppelpunkt trennt Device und $EVENT, an der Stelle kommt nie ein Leerzeichen. Der kommt dann erst wieder nach dem Reading-Namen (so vorhanden), der dann immer mit einem Doppelpunkt+Leerzeichen ergänzt wird, um den eigentlichen Wert abzugrenzen. Mehr Ebenen gibt es nicht, daher endet die Doppelpunktorgie dann auch an der Stelle...

Man muss sich halt einmal daran gewöhnen, dass hier (bzw.: bei allen von Rudi's Eventhandlern) ausnahmsweise mal der Doppelpunkt das eigentliche (oberste) Trennzeichen darstellt, nicht wie sonst in FHEM üblich das Leerzeichen.

[Guybrush]

also das mit der notifyRegexpCheck ist mal schick! Hab grad sogar extra das Wiki nochmal aufgemacht und per Suche (!) gefunden. Das sollte man wirklich besser hervorheben bzw einen eigenen Punkt draus machen, z.b. unter "4.1.1 Suchmuster prüfen". Das ist ja wirklich auch für leute hilfreich, die regex beherrschen. Zumal es hier auch sonst genug Beiträge gibt bzgl. nicht funktionierender Suchmuster. Danke dafür