[Gelöst] DOIF anstatt Notify

Begonnen von Kuehnhackel, 28 Juli 2020, 15:15:51

Vorheriges Thema - Nächstes Thema

Kuehnhackel

Hallo bräuchte mal Hilfe.
Ich erhalte über meine Sonoff-Bridge eine Meldung, dass der Bewegungmelder "D3D5DE" ausgelöst hat als ein notify
define myNotify notify MQTT2_DVES_BF00E2:json_raw:.*"Data":"D3D5DE".* set Wintergarten_3er on
was so in FHEM auch funktioniert. Aber ich möchte gerne noch Bedingungen hinzufügen, z.B. das erst die Lampe angehen soll, wenn ein spezieller Lux-Wert erreicht ist.

Wie bekomme ich
MQTT2_DVES_BF00E2:json_raw:.*"Data":"D3D5DE".*
in einem DOIF "vearbeitet"?

(([MQTT2_DVES_BF00E2:json_raw:.*"Data":"D3D5DE".*] and [Lux_Dachboden:BH1750_Illuminance]< 500) (set Wintergarten_3er on)

Danke
Ralf

MadMax-FHEM

#1
Warum ein DOIF!?

Frag doch einfach im notify den Lux-Wert ab...


define myNotify notify MQTT2_DVES_BF00E2:json_raw:.*"Data":"D3D5DE".* {if(ReadingsNum("Lux_Dachboden","BH1750_Illuminance",0) < 500){fhem("set Wintergarten_3er on")}}


EDIT: sofern das Device mit dem Lux-Wert "Lux_Dachboden" heißt und das Reading mit dem Lux-Wert "BH1750_Illuminance"...

EDIT:
Zitat von: Kuehnhackel am 28 Juli 2020, 15:15:51
Ich erhalte über meine Sonoff-Bridge eine Meldung, dass der Bewegungmelder "D3D5DE" ausgelöst hat als ein notify
ist "Quatsch", du bekommst eher einen Event... ;)

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Kuehnhackel

Danke, werde ich gleich mal versuchen.

Gruß Ralf

rudolfkoenig

Fuer die Liebhaber der kryptischen Schreibweise, mit leicht anderen Ergebnis:
defmod myNotify notify MQTT2_DVES_BF00E2:json_raw:.*"Data":"D3D5DE".* set Wintergarten_3er {([Lux_Dachboden:BH1750_Illuminance]<500 ? "on":"off")}

Btw.: gibt es einen Grund, warum die Daten in json_raw landen (und damit unhandlich sind) und nicht per json2nameValue in Einzel-Readings/Events umgewandelt werden?

Beta-User

Zitat von: rudolfkoenig am 28 Juli 2020, 15:55:12
Btw.: gibt es einen Grund, warum die Daten in json_raw landen (und damit unhandlich sind) und nicht per json2nameValue in Einzel-Readings/Events umgewandelt werden?
Jein... Läßt man "nur" json2nameValue() auf den JSON los, wird das Ergebnis uU. etwas indifferent (und mit den meisten Daten fängt man dann auch nicht wirklich was an; das ist eigentlich nur ein Klon von tasmota_ir, mit dem ich etwas länger rumexperimentiert hatte). Wenn man das verbessern wollte, müßte man das Protokoll auch mit (als Prefix) auslesen, usw., usf.. Von daher ist die notify-Regex über den kompletten JSON vermutlich die effizientere Variante und das (ziemlich "unfertige") attrTemplate "tasmota_rf" läßt den JSON "as is".
Es stellt aber daneben ein Reading "Data" bereit, das die eigentliche Information (mMn) enthält - hätte eigentlich gedacht, dass das halbwegs einleuchtend für die user ist. Aber wie sagt es die desc: "NOTE: still widely untested..." - es gibt nicht mehr so viele Leute, die 433MHz-Gerätschaften nutzen, und wenn, wird meistens CUL/Signalduino als IO verwendet.
Jedenfalls scheint keiner so ein richtiges Interesse an dieser Tasmota-Variante zu haben, von daher gibt's da eben auch keine strukturierte Herangehensweise (bin schon froh, dass jemand wenigstens die "key"-Variante als "fertig" getestet hat: https://forum.fhem.de/index.php/topic,112680.msg1074879.html#msg1074879).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

MadMax-FHEM

Zitat von: rudolfkoenig am 28 Juli 2020, 15:55:12
Fuer die Liebhaber der kryptischen Schreibweise, mit leicht anderen Ergebnis:
defmod myNotify notify MQTT2_DVES_BF00E2:json_raw:.*"Data":"D3D5DE".* set Wintergarten_3er {([Lux_Dachboden:BH1750_Illuminance]<500 ? "on":"off")}

Von "off" war nie die Rede ;)

Macht aber nat. Sinn...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Kuehnhackel

Zitat von: Beta-User am 28 Juli 2020, 16:25:31
... es gibt nicht mehr so viele Leute, die 433MHz-Gerätschaften nutzen, und wenn, wird meistens CUL/Signalduino als IO verwendet.
Jedenfalls scheint keiner so ein richtiges Interesse an dieser Tasmota-Variante zu haben, von daher gibt's da eben auch keine strukturierte Herangehensweise (bin schon froh, dass jemand wenigstens die "key"-Variante als "fertig" getestet hat: https://forum.fhem.de/index.php/topic,112680.msg1074879.html#msg1074879).

Das ist wohl wahr. Ich habe diese 433mhz Bew.-Melder getestet mit CUL usw. Die waren aber sehr unzuverlässig. Dann habe ich die PIR-HC SR 501 mit Wemos ausprobiert, von 3 Stück funktioniert einer oder macken. Dann habe ich jetzt diese Bew.-Melder in Zusammenhang mit einer Sonoff-Bridge installiert und die funktionieren wie sie sollen. Deswegen back to 433 Mhz

Gruß Ralf