In der CommandRef finde ich dazu nichts, aber gibt es eine Möglichkeit mittels set den state eines devices zu aktualisieren ohne dass bei diesem ein event ausgelöst wird? Das kann man ja grundsätzlich bei ReadingsSingleUpdate() als Parameter bestimmen, aber bei set ist mir das nicht bekannt? ReadingsSingleUpdate kann ich auch nicht nutzen, da Notify den Hash nicht mit übergibt.
Mein Problem ist nämlich, dass ich Devices aus FHEM ein-/ausschalte, diese aber auch über KNX Taster gesteuert werden können. Auf den KNX Tastern ist ein Notify gebunden, was den State 1:1 bei den Devices überträgt (kein KNX, daher keine direkte Kommunikation zwischen Taster und Devices möglich). Das funktioniert soweit gut. Den Status des Devices erkennt FHEM auch, weshalb ich innerhalb von FHEM immer den aktuellen Status habe. Nun habe ich aber das Problem, dass die Devices auch händisch eingeschaltet werden können. Der Status wird von FHEM richtig aktualisiert, aber der KNX Taster bekommt davon nichts mit.
Das könnte man grundsätzlich ja auch per Notify machen, nur würde das dann einem endlosen Pingpong führen oder zumindest zu einem einem redundanten Ein/Ausschalt Befehl. event-min-interval kann ich nicht nutzen, da die Zustandsänderung des Devices mal sofort, mal aber auch Sekunden braucht und dann die Taster innerhalb des Devices nicht mehr wie gewollt funktionieren. Hier müsste ich also einen Interval bestimmen, innerhalb dessen in jedem Fall die Änderung durch wäre. Wenn man innerhalb des Interval aber den Zustand nochmal ändern würde, wäre der State wieder unterschiedlich. Ich bräuchte also eine Möglichkeit den State einer KNX Adresse zu aktualisieren, ohne dass ein Event gefeuert wird.
Übersehe ich hier irgendwas offensichtliches oder ist die einzige Möglichkeit das zu tun, dass man sich im Notify anhand von $NAME den $hash aus $modules holt? Also in etwa so:
define event notify <DEVICE> {
$hash = $modules{<Modul>}{defptr}{$NAME};
readingsSingleUpdate($hash, "state", $EVENT, 0);
}
https://fhem.de/commandref_DE.html#setstate
Sollte machen was du willst?
Gruß, Joachim
(etwas zu spät, aber wg. des 2. Teils)
Vielleicht hilft "setstate"?
Ansonsten kommst du an den Hash über $defs{DEVICE}, wobei readingsSingleUpdate in notify irgenwie unschön ist...
setstate macht leider genau das anders herum was ich brauche
setstate KNXDEVICE off
Notify auf KNXDEVICE wird ausgeführt, aber State wird nicht an KNX gesendet. Ich brauche etwas, was den State an KNX sendet ohne den Trigger auf KNXDEVICE auszuführen
Klingt für mich nach einem speziellen KNX-Problem, wenn du da auch irgendwas auf den Bus senden willst. (=> wäre wohl im KNX-Unterforum besser aufgehoben).
Bzgl. des notify hilft vielleicht (!) disabledAfterTrigger.
Nachtrag: Vielleicht wäre es eine Option, das über eine structure zu lösen und die dann immer nach dem zuletzt geschalteten (Einzel-) Gerät zu schalten?
also meines Erachtens nach ist das eher allgemein. Das ist ja hier nur ein konkretes Beispiel wo ich es brauche. Grundlegend dürfte das aber alle Module betreffen, solang hier 2 Module untereinander über notify kommunizieren.
disabledAfterTrigger wäre vielleicht eine Möglichkeit. Allerdings ist auch hier ein fester Sekundenwert anzugeben, was das auch wieder einschränkt :( . Jedenfalls interpretiere ich den code so, dass das Notify für die angegebene Zeit schlichtweg nur nicht ausgeführt wird. Theoretisch kann man also eine Taste da 2x hintereinander drücken, so dass mehrere Zustände innerhalb einer 1 Sekunde an den KNX Bus gesendet werden. Dann hat man wieder das Problem, dass es nur funktioniert, solang das keiner macht.
Vielleicht zeigst du mal das notify und lists von den Devices.
Wenn das (eigentlich) zwei Aktoren sind, sollte ein FILTER im notify (das auf Events beider Geräte hört) eigentlich ausreichend sein (schalte das Gerät, das nicht schon auf $EVENT steht auf $EVENT).
EDIT: so wie hier - https://forum.fhem.de/index.php/topic,124253.msg1188254.html#msg1188254
Ich bin mir nicht 100% sicher ob ich alles verstehe was "State übertragen" etc. genau bedeutet an Schaltlogik in und außerhalb FHEM.
Denke auch ein List der betroffenen Devices hilft vielleicht zielgerichteter zu helfen.
Was musst du denn beim KNX Taster "setzen", wenn du nicht über ihn schaltest?
Hat der ein Display und du willst ihn zur Korrekten Anzeige zwingen indem du nochmal den Status setzt der eigentlich durch FHEM schon aktiviert wurde?
Der Taster hat LEDs die den Zustand des Schaltobjektes anzeigen. Wenn das Gerät angeschaltet wird, soll also auch die LED leuchten, damit mans am Taster sieht, so dass die KNX Busadresse eben den richtigen Zustand auch haben muss. Davon ab ist das aber auch nicht so toll, wenn die Zustände unterschiedlich je Bus sind.
Beta-Users feedback bzgl. der Filterfunktion war aber ganz gut. Das geht zwar nicht direkt mit einem Filter im set, aber ich habs nun wie nachfolgend gelöst. Da wird dann zwar immer noch 3x das Notify aufgerufen, aber trotzdem nur einmal geschaltet. Ist zwar länger als das über ReadingsSingleUpdate zu machen, aber gefühlt sauberer, wenn man keine Funktionen zweckentfremdet
define Wohnen.Klima.Notify (KNX.Wohnen.Klima|Wohnen.Klima):\s?(on|off) {
Log3 $NAME, 4, "Wohnen.Klima.Notify called (name: $NAME - event: $EVENT - value: ".Value($NAME).")";
if ($NAME eq "KNX.Wohnen.Klima") {
Log3 $NAME, 4, "Wohnen.Klima.Notify: schalte Wohnen.Klima (Value: ".Value("Wohnen.Klima").")";
fhem "set Wohnen.Klima $EVENT";
} else {
if (Value("KNX.Wohnen.Klima") ne $EVENT) {
Log3 $NAME, 4, "Wohnen.Klima.Notify: schalte KNX.Wohnen.Klima (Value: ".Value("KNX.Wohnen.Klima").")";
fhem "set KNX.Wohnen.Klima $EVENT"
}
}
}
...jetzt gibt man sich so Mühe, eine Schreibweise zu verwenden, die NOTIFYDEF setzt, und dann wird es so verhunzt :o ::) ...
Und warum wollen alle unbedingt immer interpolieren? Einfache Quotes würden es doch hier (abgesehen von den Log3-Anweisungen) auch durchgängig tun (und warum man bei nicht-built-in Funktionen keine Klammern setzt, werde ich in diesem Leben vermutlich auch nicht mehr verstehen). Und Value(), na ja, ich mag es überhaupt nicht... Ist so "Wischi-Waschi"...
Die DoubleQuotes sind ja erstmal nicht schädlich und wären auch nur bei den if / Value anzupassen. Grundlegend verwende ich einfache Quotes immer nur dann, wenn ich nicht möchte, dass da Variablen ersetzt werden etc. Ist ja hier nun kein HPC, wo es um jede nanosekunde geht ;D
Was ist denn mit Value? Dachte das ist genau dafür oder ist das ein Relikt aus alten Versionen bzw. depricated? Man kanns auch über ReadingsVal machen, aber Value() ist da viel trivialer und macht unterm Strich doch das gleiche?
Mein Hauptaufreger war NOTIFYDEF...
Der Rest nur "Zugabe"...
Zitat von: Guybrush am 19 Juli 2022, 13:23:31
Die DoubleQuotes sind ja erstmal nicht schädlich und wären auch nur bei den if / Value anzupassen. Grundlegend verwende ich einfache Quotes immer nur dann, wenn ich nicht möchte, dass da Variablen ersetzt werden etc. Ist ja hier nun kein HPC, wo es um jede nanosekunde geht ;D
Der Punkt ist: Warum dreht man hier nicht allgemein die gedankliche Logik um und verwendet per default einfache Quotes und DoubleQuotes eben nur dann, wenn man wirklich interpolieren will...? Es gibt im ganzen FHEM-Code gefühlte 10.000 Tonnen von doppelten Quotes, die keiner braucht... Dafür finden sich dazu noch Myriaden von expliziten concatenations, die man bequem mit in den doppelten Quotes davor und danach unterbringen könnte. Irgendwann sollte man diese Art Kopierfehler einfach sein lassen, just my 2 ct.
Zitat
Was ist denn mit Value? Dachte das ist genau dafür oder ist das ein Relikt aus alten Versionen bzw. depricated? Man kanns auch über ReadingsVal machen, aber Value() ist da viel trivialer und macht unterm Strich doch das gleiche?
Wenn man genau weiß, dass man damit eigentlich eine InternalVal-Abfrage macht, ist alles gut. Das Problem ist: Den wenigsten ist das bewußt, und immer mal wieder taucht einer auf, dem eine stateFormat-Anweisung "komisch" auf die Füße fällt.
Warum funktioniert eigentlich mein FILTER-Vorschlag nicht direkt? Ich kann das Problem auf die Schnelle nicht erkennen.
Hi,
du hast uns bisher noch nicht die list's der betroffenen devices gezeigt, darum muss ich etwas raten :D
Ich interpretiere so:
1) Du hat einen KNX-Taster (mit LED) der brav seine Aktion an FHEM meldet.
2) Du hat ein NICHT KNX-device, dass mit diesem Taster ein/aus geschaltet wird.
.. und bis hierher funktioniert auch alles
zum KNX Taster: üblicherweise haben diese Taster mehrere Objekte, die auf GA's gemappt werden können (mittels ETS)
bei mir schaut das z.b. so aus:
obj.x = tastendruck kurz -> GA 1/1/1:dpt1 - in der ETS als toggle definiert
obj.y = status -> GA 1/1/2:dpt1 - wird im Taster intern für die "toggle" Funktion benötigt
obj.z = led -> GA 1/1/3:dpt1 - Led on/off
oder als def:
define <knx-device> KNX 1/1/1:dpt1:taster 1/1/2:status:get:nosuffix 1/1/3:led:set:nosuffix
Fall jetzt vom nicht KNX-Gerät der status (on/off) event kommt, macht das notify (nur auf das nicht-KNX-Gerät triggern!)
set <knx-device> status $EVTPART1
set <knx-device> led $EVTPART1
und alles wird gut....(ausser ich hab falsch geraten ;D )
l.g. erwin
der Filtervorschlag sähe ja so aus oder?
define Wohnen.Klima.Notify notify (KNX.Wohnen.Klima|Wohnen.Klima):\s?(on|off) set FILTER=state!=$EVENT $EVENT
das Problem da ist, dass ich bei einem Event von Wohnen.Klima den State von KNX.Wohnen.Klima bräuchte und vice versa. Mir ist jedenfalls nicht bekannt, dass man das über die Filterfunktion so direkt lösen könnte
was meinst du mit NOTIFYDEF? Steh da grad auf dem Schlauch
Ich wäre mit deinen Device-Bezeichnungen auf das hier gekommen:
define Wohnen.Klima.Notify notify KNX.Wohnen.Klima:o[nf]+|Wohnen.Klima:o[nf]+ set (KNX.Wohnen.Klima|Wohnen.Klima):FILTER=state!=$EVENT $EVENT
Zitat von: Guybrush am 19 Juli 2022, 13:41:04
das Problem da ist, dass ich bei einem Event von Wohnen.Klima den State von KNX.Wohnen.Klima bräuchte und vice versa. Mir ist jedenfalls nicht bekannt, dass man das über die Filterfunktion so direkt lösen könnte
Wieso? Du setzt einfach das andere Device auf den "Status" vom triggernden Device und gut ist...
Zitat
was meinst du mit NOTIFYDEF? Steh da grad auf dem Schlauch
Wenn du meine Definition übernimmst, solltest du (ggf. nach einem Browser-Refresh) den Unterschied in den Internals sehen ;) .
Zu den Details, auch was Performance angeht siehe auch (Kurzfassung): https://forum.fhem.de/index.php/topic,116701.0.html (https://forum.fhem.de/index.php/topic,116701.0.html), und (Langform) Grundsätzliche Codingfragen / Performance: https://forum.fhem.de/index.php/topic,117075.0.html (https://forum.fhem.de/index.php/topic,117075.0.html)
Zitat von: erwin am 19 Juli 2022, 13:38:18
set <knx-device> status $EVTPART1
set <knx-device> led $EVTPART1
und alles wird gut....(ausser ich hab falsch geraten ;D )
l.g. erwin
Du hast mit allem Recht - mein "Problem" ist nur, dass die Taster keine eigene Busadresse für den Status verwenden und stattdessen den Zustand des Schaltobjektes anzeigen. Aber du hast Recht - man könnte es auch so lösen, dass man da eine eigene KXN-Adresse für den Status anlegt und den Taster entsprechend parametrisiert. Dann könnte man das so machen wie du geschrieben hast.
Zitat von: Beta-User am 19 Juli 2022, 13:48:15
Wieso? Du setzt einfach das andere Device auf den "Status" vom triggernden Device und gut ist...
das geht leider nicht, da der State des Klima.Wohnen Devices nach Änderung nur Asynchron über httputils_nonblockingget aktualisiert wird und in der Zeit bis zur Response Ping-Pong zwischen dem KNX Device und der Klima gespielt würde - weil ja eben der Zustand noch unverändert ist. Deswegen hab ich bei mir auch den Zustand der KNX Adresse als Master definiert und prüfe nur die andere Richtung.
Zitat von: Guybrush am 19 Juli 2022, 13:54:49
das geht leider nicht, da der State des Klima.Wohnen Devices nach Änderung nur Asynchron über httputils_nonblockingget aktualisiert wird und in der Zeit bis zur Response Ping-Pong zwischen dem KNX Device und der Klima gespielt würde - weil ja eben der Zustand noch unverändert ist. Deswegen hab ich bei mir auch den Zustand der KNX Adresse als Master definiert und prüfe nur die andere Richtung.
Zeig' mal deine Events.
Und falls du die Option hast ( ;) ), das analog zu CUL_HM oder MQTT2_DEVICE (mit setStateList) zu machen: das notify triggert nur auf on/off (ok, etwas ungenau, da auch auf "onnnn" oder "of"). Wenn du beim Schreiben also den state gleich auf "set on" setzt, kannst du bequem das "on" abwarten, und dann ist entweder kein Device mehr da, das auf die devspec paßt, oder es ist eben noch das andere "gleichzuschalten" ;) .
Zitatkeine eigene Busadresse für den Status verwenden und stattdessen den Zustand des Schaltobjektes anzeigen
.. verstehe....
Falls das nicht änderbar ist:
Den nicht-KNX-Aktor nicht/nie direkt ein/ausschalten (in FHEM) sondern nur über die Taster-GA, also in meinem Beispiel:
set <knx-device> g1 onoder auch mit toggle:
set <knx-device> g1 toggle
attr <knx-device> KNX_toggle Wohnen.Klima:state.. wobei das reading 'state' vom NICHT KNX-device als ist-zustand für toggle genommen wird
l.g. erwin
Hmm, also doch ein KNX-Special....
Wobei mir das mit dem angeblichen Ping-Pong noch unklar ist. Das wäre m.E. doch nur dann ein Problem, wenn das Wohnen.Klima-Gerät zwischendurch einen "falschen" trigger absetzen würde? Also ein explizites "off" melden, wenn jemand auf "on" drückt? (Oder gibt es andere falsche trigger dazwischen?)
nicht so ganz. Das Problem da ist, dass das KNX Device sofort seinen Status ändert. Das ist auch ok. Das Problem ist hier konkret, dass das Nicht KNX Gerät bei einer Statusänderung diese erst an die API (Cloudlösung... :-\) überträgt und den State erst schreibt, wenn als Response ein "ok" zurück kam. Das ist grundlegend auch richtig so bzw. derzeit nicht anders möglich, da diese tolle API allzuoft down ist und nicht richtig funktioniert. Wäre das alles nicht so, wäre das hier ja ein total triviales Ding :D
Events sehen so aus:
2022.07.19 11:49:02 1: Wohnen.Klima.Notify called (name: KNX.Wohnen.Klima - event: off - value: off)
2022.07.19 11:49:02 1: Wohnen.Klima.Notify: schalte Wohnen.Klima
2022.07.19 11:49:02 1: Wohnen.Klima.Notify called (name: Wohnen.Klima - event: off - value: on)
2022.07.19 11:49:02 1: KNX.Wohnen.Klima hat bereits den Zustand
2022.07.19 11:49:07 1: Wohnen.Klima.Notify called (name: Wohnen.Klima - event: off - value: off)
2022.07.19 11:49:07 1: KNX.Wohnen.Klima hat bereits den Zustand
wenn der KNX Taster bedient wird, dann wird das Wohnen.Klima Device aktualisiert, welches asynchron eine API called um den neuen Status zu setzen (der dann wiederrum an das lokale Klimagerät geschickt wird... mega umständlich, aber ok). Zugleich wird vom Wohnen.Klima Device aber das gleiche Notify nochmal getriggert, nur eben für das Wohnen.Klima Device, was aber zu keinem Set mehr führt, da das KNX Device ja schon den neuen Status hat. Nachdem die API 5 Sekunden (!) später endlich mal reagiert, wird nochmal ein Trigger auf das Notify ausgelöst, was aber auch zu keinem neuen Set mehr führt. Funktioniert jetzt so, auch wenn andere Wege schöner sein dürften
da liegen 5 Sekunden zwischen dem Schreiben und der Response von der API. Das ist genau mein Problem...
Das ist doch das Log. oder? Ich hatte nach den Events gefragt ;) . Die siehst du im Event-Monitor, und du kannst das gerne mal eingrenzen auf die trigger-regexp von meinem notify...
Anders gesagt: Es ist ziemlich egal, wie lange es dauert, bis wer auch immer eine Rückmeldung gibt - solange dazwischen nichts "komisches" passiert, also ein alter Zustand nochmal triggernd (!) gemeldet wird.
ja ist es, aber ich logge ja alle events mit. Will die Klimageräte nicht ständig umschalten. Brauche die heute ;D
Ich glaube ich weiß um welche API es geht (die k***zt mich mittlerweile richtig an) und ich stehe kurz davor auf das hier umzusteigen:
https://smarthomestore.at/produkt/gateway-von-panasonic-nach-knx-bis-zu-1-innengeraete-intesis-by-hms-inknxpan001i000/?gclid=CjwKCAjwrNmWBhA4EiwAHbjEQGaw6S_I5K4iqsTqlnEJBVrIU2Dvv2xcC0rOKp9qa0f3v9gSqqPRfRoCsgMQAvD_BwE (https://smarthomestore.at/produkt/gateway-von-panasonic-nach-knx-bis-zu-1-innengeraete-intesis-by-hms-inknxpan001i000/?gclid=CjwKCAjwrNmWBhA4EiwAHbjEQGaw6S_I5K4iqsTqlnEJBVrIU2Dvv2xcC0rOKp9qa0f3v9gSqqPRfRoCsgMQAvD_BwE)
ad: 5 sekunden bis zur rückmeldung:
schau dir evtl. im wiki die seite 'KNX Device Definition - Beispiele' unter 'on/off device mit verzögerter Rückmeldung' an.
Damit könntest du zumindest in FHEM darstellen, das gerade eine API-Aktion pending ist....
l.g. erwin
OK, wenn das wirklich alles ist, sehe ich das Problem mit dem FILTER nicht: Das bewirkt genau, dass das ursprünglich auslösende KNX-Device nicht mehr angesprochen wird, da ja der (vermeintliche) Zielzustand dort bereits erreicht ist. Ob das 5 oder 20 Sekunden dauert ist dabei völlig gleichgültig... "Komisch" wird es nur, wenn jemand zwischendurch nochmal umschaltet, also solange die alte Anweisung noch auf dem Weg ist. Aber auch da sollte dann letztlich die 2. Anweisung durchdringen, da ja anscheinend der state gleich beim Absetzen der Anweisung auch umgeschaltet wird (so dass neuerliches zwischenzeitliches KNX-Gedrücke am Ende auch einen Schaltvorgang auslöst, der dann irgendwann rückgemeldet wird).
(Du kannst es gerne irgendwann ausprobieren, wenn es wieder besser paßt - oder ein MQTT2_DEVICE an einen anderen KNX-Aktor "versklaven". Da geht nur die Rückmeldung schneller, aber der (asynchrone) Ablauf ist identisch...)
Zitat von: EinEinfach am 19 Juli 2022, 14:56:03
Ich glaube ich weiß um welche API es geht (die k***zt mich mittlerweile richtig an) und ich stehe kurz davor auf das hier umzusteigen:
https://smarthomestore.at/produkt/gateway-von-panasonic-nach-knx-bis-zu-1-innengeraete-intesis-by-hms-inknxpan001i000/?gclid=CjwKCAjwrNmWBhA4EiwAHbjEQGaw6S_I5K4iqsTqlnEJBVrIU2Dvv2xcC0rOKp9qa0f3v9gSqqPRfRoCsgMQAvD_BwE (https://smarthomestore.at/produkt/gateway-von-panasonic-nach-knx-bis-zu-1-innengeraete-intesis-by-hms-inknxpan001i000/?gclid=CjwKCAjwrNmWBhA4EiwAHbjEQGaw6S_I5K4iqsTqlnEJBVrIU2Dvv2xcC0rOKp9qa0f3v9gSqqPRfRoCsgMQAvD_BwE)
Intensis läuft meine ich auch über eine Cloud.. Hatte ich mir vor längerer Zeit mal angeschaut und für mich entschieden, dass es einfacher ist über die ComfortCloud zu gehen. Auch wenn das mit extrem vielen Einschränkungen verbunden ist und ich eigentlich grundsätzlich Cloudlösungen vermeide, wo es nur geht.
Zitat von: Beta-User am 19 Juli 2022, 15:03:39
OK, wenn das wirklich alles ist, sehe ich das Problem mit dem FILTER nicht: Das bewirkt genau, dass das ursprünglich auslösende KNX-Device nicht mehr angesprochen wird, da ja der (vermeintliche) Zielzustand dort bereits erreicht ist.
hab das gerade mal testweise probiert. wenn ich vom knx Taster aus schalte wird die led mehrfach ein/aus geschaltet bis der state bei beiden gleich ist. Egal. Ich beobachte das jetzt mal und schaus mir noch in ein paar Tagen an. Hab grad noch größere Baustellen hier ;)
ZitatIntensis läuft meine ich auch über eine Cloud.. Hatte ich mir vor längerer Zeit mal angeschaut und für mich entschieden, dass es einfacher ist über die ComfortCloud zu gehen. Auch wenn das mit extrem vielen Einschränkungen verbunden ist und ich eigentlich grundsätzlich Cloudlösungen vermeide, wo es nur geht.
Die geht direkt auf den internen Bus, da ist weder ein Wifi noch ein LAN Anschluss, also ist Cloud Free. Der Preis schreckt mich nur ab, weil ich 4 Stück brauche
Zitat von: Guybrush am 19 Juli 2022, 15:18:35
hab das gerade mal testweise probiert. wenn ich vom knx Taster aus schalte wird die led mehrfach ein/aus geschaltet bis der state bei beiden gleich ist. Egal. Ich beobachte das jetzt mal und schaus mir noch in ein paar Tagen an. Hab grad noch größere Baustellen hier ;)
Dann erst mal viel Spaß.
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.
Zitat von: Beta-User am 19 Juli 2022, 15:52:33
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?
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
Zitat von: Guybrush am 19 Juli 2022, 18:00:56
Guter Hinweis! Aber hab ich das nicht schon maximal eingeschränkt?
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.
Zitat...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:
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:
attr <knx-device> stateCmd { fhem "sleep 0.05 quiet;; set Kinderzimmer.klein.Klima $state" if ($gadName eq 'g1');; return $state;; }
Zitat von: erwin am 20 Juli 2022, 09:55:08
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...
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 ;D). Wäre also eine Überlegung wert ein paar Testgeräte anzuschaffen ;D. 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?
@Beta-User
Zitat... 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 ? ;D
ZitatWas 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
Zitatoffen 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
Zitat von: Guybrush am 20 Juli 2022, 10:56:41
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!).
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?
Zitat von: Guybrush am 20 Juli 2022, 15:28:12
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:
{notifyRegexpCheck('(KNX.Kinderzimmer_klein.Klima\sg1|Kinderzimmer_klein.Klima):\s?(on|off)')}
Hi Beta-User,
danke für den hint!
Der Logik folgend müsste es dann so aussehen:
{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
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
{notifyRegexpCheck('KNX.Wohnen.Klima:g1.*|Wohnen.Klima:o[nf]+')}zwei "OK" zurückgeben und den "g1-Fall" unbeschänkt mit abdecken.
ja, 2 ok's, dass passt!
Ich hab die notifies jetzt nicht getestet, stehe immer noch mit den Leerzeichen auf Kriegsfuß ;D
Mein Versuch mit dem eventmonitor:
2022-07-21 14:19:22.868 KNX Windspeed getG1: 1.18
create/modify device-button - ergibt das:
define Windspeed_notify_1 notify Windspeed:getG1:.1.18 {}
also KEIN Leerzeichen zw. dev und reading ABER ein Leerzeichen zw. reading und Value!
Allerdings:
2022-07-21 14:28:02.853 KNX Windspeed 8.7
define Windspeed_notify_1 notify Windspeed:8.7 {}
:o .. offensichtlich hat das was mit addStateEvent zu tun....
Zitat von: erwin am 21 Juli 2022, 14:33:30
:o .. 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.
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 :)
Die Funktion gibt es noch nicht allzu lange, von daher ist es kein Wunder, dass es noch einige Stellen gibt, wo man das ggf. verlinken könnte. Die wichtigste hat Rudi aber eingebaut: FHEMWEB, also "jedermann's FHEM"...
Klicke mal auf das rote (!) beim REGEXP-Internal (f18 muss als Style verwendet werden), und du bekommst das auf dem Silbertablett serviert ;) ...