event nach stateFormat

[Rudibarani]

Hallo zusammen,

ich habe MQTT-Device (Kamera), die ein Reading "triggered_val" erzeugt. Der Wert ist größer als Null, wenn eine Bewegung erkannt wurde. Ich würde dies gerne im Status des Devices reflektieren und nach einer Weile über einen Watchdog wieder zurücksetzen.

Ich setzte daher folgendes stateFormat ein:

Code Auswählen Erweitern


{(ReadingsVal('MQTT2_Instar_MQTT','triggered_val',0) > 0)?"on":"off"}


Wenn ich manuell über einen Set-Befehl das Reading setze, sehe ich im Event-Monitor (MQTT2_Instar_MQTT.*) aber nur:

Code Auswählen Erweitern


2020-11-17 13:07:59 MQTT2_DEVICE MQTT2_Instar_MQTT triggered
2020-11-17 13:07:59 MQTT2_DEVICE MQTT2_Instar_MQTT triggered_val: 2


Was muss ich tun, damit es auch ein Event MQTT2_Instar_MQTT.on oder MQTT2_Instar_MQTT.off gibt?
Das Internal STATE hat immer den richtigen Wert - darauf kann ich aber keinen Watchdog programmieren, weil Internals nach meinem Kenntnisstand keine Events auslösen.

Hat jemand eine Idee?

[Beta-User]

klingt nach einem userReading, das du hier haben willst?

Rücksetzen dann ggf. mit setreading, das triggert dann auch.

[Rudibarani]

Danke für die Idee. Ich werde das mal ausprobieren und könnte mir vorstellen, dass das tatsächlich klappt.

Aber dennoch eine Grundsatzfrage: Wäre es nicht denkbar, dass auch eine Änderung von state durch stateFormat (optional) ein Event erzeugt? Oder anders herum - was spricht dagegen?

[Beta-User]

Events gehören zur "Reading-Ebene", stateFormat  und devStateIcon kommen in der Informationsverarbeitungskette erst danach. Eventuell könnte man (mit sleep...?) den Code irgendwie dazu überreden, ein setreading oder trigger auszuführen, aber das ist durch die Brust ins Auge und tendenziell "Schleifenanfällig", weswegen fhem.pl sowas teilweise auch unterbindet.

Kurz: Man nehme die Methode, die dafür gemacht ist, alles andere kann ins Auge gehen...

Du könntest übrigens uU. zumindest für die "motion"-Verarbeitung auch direkt über die readingList vorgehen, aber für einen Vorschlag dazu würde ich eine RAW-Definition benötigen und Info, in welcher Form die Infos übermittelt werden (JSON?).

[Rudibarani]

Danke Dir - wieder was dazu gelernt!

Kurz: Man nehme die Methode, die dafür gemacht ist, alles andere kann ins Auge gehen...

Ich hab es mir jetzt leicht gemacht, und das ganze mit einem Dummy gelöst. 

[Beta-User]

...selber schuld...

(Dieses dummy-Geschubse geht mir auf den Zeiger. Es macht für mich keinen Sinn, die Info von einem Device ohne Not auf weitere zu verteilen. Wenn es gute Gründe dafür gibt: ok, aber sonst...?)

[Rudibarani]

Ich hab es auch lieber clean - aber für so eine Kleinigkeit wollte ich Dir jetzt nicht die Zeit stehlen, dir das JSON anzusehen und und und...
Danke aber dennoch für das Angebot!

[Beta-User]

Na ja, userReadings gäbe es ja auch noch. Wenn du da einen sauberen trigger festlegst, sollte das eigentlich schneller gehen, wie einen dummy+Eventhandler anzulegen... Und dann wäre "alles beeinander" (und du könntest direkt den passenden Wert für "motion" zurückgeben).

[Rudibarani]

Du hast Recht. Ich werde mich heute Abend nochmal dran setzen und das wieder zusammen führen. Würde mir auch besser gefallen. Danke!