set ohne Event möglich?

Guybrush · 19 Juli 2022, 13:49:43

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 )
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.

Guybrush · 19 Juli 2022, 13:54:49

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.

Beta-User · 19 Juli 2022, 14:12:01

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"

.

erwin · 19 Juli 2022, 14:16:16

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:

Code Auswählen

set <knx-device> g1 on
oder auch mit toggle:

Code Auswählen

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

Beta-User · 19 Juli 2022, 14:29:40

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?)

Guybrush · 19 Juli 2022, 14:43:58

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

Events sehen so aus:

Code Auswählen


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...

Beta-User · 19 Juli 2022, 14:51:42

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.

Guybrush · 19 Juli 2022, 14:54:28

ja ist es, aber ich logge ja alle events mit. Will die Klimageräte nicht ständig umschalten. Brauche die heute

EinEinfach · 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

erwin · 19 Juli 2022, 14:59:38

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

Beta-User · 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. 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...)

Guybrush · 19 Juli 2022, 15:12:33

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

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.

Guybrush · 19 Juli 2022, 15:18:35

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

EinEinfach · 19 Juli 2022, 15:25:26

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

Beta-User · 19 Juli 2022, 15:52:33

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.