XIAOMI Fenstersensor: notify funkt nicht, DOIF schon

Begonnen von memento_10, 25 März 2020, 20:48:08

Vorheriges Thema - Nächstes Thema

memento_10

Hallo liebe FHEM-Gemeinde!

Ich probiere nun schon stundenlang herum, bin aber offenbar zu dämlich, meinen Fehler zu finden:

Ich habe seit Jahren FHTTK Fenstersensoren im Einsatz und ein entsprechendes notify welches mich benachrichtigt wenn ein Fenster zu lange offen und es draußen kalt ist.

Jetzt habe ich mir zusätzlich noch Fenstersensoren von XIAOMI Aqara geholt (die sind übrigens wirklich klein und reagieren blitzschnell in Verbindung mit dem Conbee Stick).

Nur kann ich machen was ich will, diese Sensoren triggern einfach mein notify nicht. Ich habe auch schon versucht mit dem Assistenten (im EventMonitor die Zeile markieren...) ein notify zu erstellen, das klappt auch nicht. Erstelle ich jedoch ein DOIF zum Testen funktioniert es sofort.

Kennt vielleicht jemand dieses Brett vor meinem Kopf?

List vom Sensor:


Internals:
   DEF        sensor 14  IODev=Conbee2
   FUUID      5e7b6fdd-f33f-705d-af7e-1bcbb2f1a605290c
   FVERSION   31_HUEDevice.pm:0.214800/2020-03-22
   ID         S14
   INTERVAL   
   IODev      Conbee2
   NAME       Fenster_Test
   NR         181
   STATE      closed
   TYPE       HUEDevice
   lastupdated 2020-03-25 18:50:56
   lastupdated_local 2020-03-25 19:50:56
   manufacturername LUMI
   modelid    lumi.sensor_magnet.aq2
   name       Fenster_Test
   on         1
   reachable  1
   swversion  20161128
   type       ZHAOpenClose
   uniqueid   00:15:8d:00:04:76:cf:8d-01-0006
   READINGS:
     2020-03-25 18:32:22   battery         100
     2020-03-25 18:32:22   reachable       1
     2020-03-25 19:50:56   state           closed
     2020-03-25 18:32:22   temperature     28
   helper:
     devtype    S
     reachable  0
     update_timeout 1
     configList:
     json:
       ep         1
       etag       7717fb791d19186808568321a4b43dca
       manufacturername LUMI
       modelid    lumi.sensor_magnet.aq2
       name       Fenster_Test
       swversion  20161128
       type       ZHAOpenClose
       uniqueid   00:15:8d:00:04:76:cf:8d-01-0006
       config:
         battery    100
         temperature 2800
       state:
         lastupdated 2020-03-25T18:50:56
     setList:
Attributes:
   IODev      Conbee2
   devStateIcon open:fts_window_1w_open@#e56524 closed:fts_window_1w
   model      lumi.sensor_magnet.aq2
   room       51_ZigBee,999_TEST
   verbose    0



Das Notify:
.*Fenster.* {
my $Offen = ReadingsVal($NAME, "state", 0);

if (($Offen eq "open" || $Offen eq "Open") && ReadingsVal($SELF, "Status_$NAME",0) eq "Closed" ) {
fhem("setreading $SELF Status_$NAME Open");

} elsif (($Offen eq "closed" || $Offen eq "Closed") && ReadingsVal($SELF, "Status_$NAME",0) eq "Open" ) {
fhem("setreading $SELF Status_$NAME Closed");
fhem("setreading $SELF Notification_$NAME Not Sent");
}

if (ReadingsVal($SELF, "Status_$NAME",0) eq "Open" && secondsSinceReadingChange($SELF, "Status_$NAME") > 600 &&
ReadingsVal($SELF, "Notification_$NAME",0) eq "Not Sent" && ReadingsNum("WetterLinz", "temperature", 0) < 10) {
fhem("set echo_Kueche speak Das $NAME ist zu lange offen!");
fhem("set echo_Bad speak Das $NAME ist zu lange offen!");
fhem("setreading $SELF Notification_$NAME Sent");
if (ReadingsNum("rr_Simon","durTimerAbsence_cr",0) < 10) {
fhem("set tbot msg $NAME zu lange offen!");
}
}

if (ReadingsVal($SELF, "Notification_$NAME",0) eq "Sent"
&& secondsSinceReadingChange($SELF, "Notification_$NAME") > 900) {
fhem("setreading $SELF Notification_$NAME Not Sent");
}
}


Vielen Dank schon mal im Voraus für jeden hilfreichen Denkanstoß!

LG
memento
FHEM auf Rpi4, OpenWRT auf Netgear Nighthawk, CUL868, FHT80, Tradfri, CUL433, tbot, alexa-fhem, ESP8266, Shelly 1+2, homebridge, Klingelerkennung über ESP, Anwesenheit per OpenWRT

MadMax-FHEM

EventMonitor öffnen, Event markieren, create/modify, fertig...

https://wiki.fhem.de/wiki/Event_monitor

Vermutlich reicht schon den ersten .* wegzulassen...
...weil Fenster halt nun mal "vorne dran" nix hat...
...daher passt dann die RegEx .*Fenster.* nicht...

Wobei das RegEx eh sehr "weit" fasst -> reagiert auf sehr viel (unnötiges) "Zeug"...

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)

memento_10

Zitat von: MadMax-FHEM am 25 März 2020, 20:51:57
EventMonitor öffnen, Event markieren, create/modify, fertig...

Das habe ich ja bereits versucht, das klappt wenn ich damit ein DOIF erstelle aber eben nicht mit einem notify...

Zitat von: MadMax-FHEM am 25 März 2020, 20:51:57Wobei das RegEx eh sehr "weit" fasst -> reagiert auf sehr viel (unnötiges) "Zeug"...
Ich weiß, das habe ich immer weiter reduziert, weil es eben nicht angesprungen ist. Ursprünglich war auch das .* am Anfang nicht vorhanden, war dann eher schon ein Versuch aus Verzweiflung..  ;)

LG
memento
FHEM auf Rpi4, OpenWRT auf Netgear Nighthawk, CUL868, FHT80, Tradfri, CUL433, tbot, alexa-fhem, ESP8266, Shelly 1+2, homebridge, Klingelerkennung über ESP, Anwesenheit per OpenWRT

MadMax-FHEM

Zeig doch mal ein list von einem vom EventMonitor erzeugten Notify...

Ich kann mir wirklich nicht vorstellen warum das nicht gehen soll...

Und dann am besten auch noch einen Auszug aus dem Eventmonitor...

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)

MadMax-FHEM

Außerdem ist das was danach kommt, also dein if-Zeugs mit $Self usw. vermutlich nur bei DOIF "vorhanden" und da du das mit UND prüfst wird es vermutlich NIE wahr, darum löst (verm.) das Notify aus...
...ABER: es passiert nichts...

Daher (mache ich so) mache doch zunächt mal eine Logausgabe, damit siehst du, dass das Notify funktioniert...

Wenn ich Variablen nutze, dann gebe ich auch die noch mit aus, dann sehe ich auch, wie die "belegt" sind...

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)

memento_10

Zitat von: MadMax-FHEM am 25 März 2020, 21:17:41
Außerdem ist das was danach kommt, also dein if-Zeugs mit $Self usw. vermutlich nur bei DOIF "vorhanden" und da du das mit UND prüfst wird es vermutlich NIE wahr, darum löst (verm.) das Notify aus...
...ABER: es passiert nichts...

Meine Güte, Du hast natürlich recht!!

Die Bedingung kann nie wahr werden, weil das Reading $SELF Status_$NAME noch nicht gesetzt ist. Sobald ich das einmal manuell erstellt habe triggert auch das notify richtig.
Vielen Dank, für Deine Unterstützung!

Jetzt habe ich nur noch das soeben erkannte Problem, dass das notify mit den FHTTK gut funktioniert weil die immer wieder Ihren aktuellen Status schicken, der XIAOMI jedoch nicht. Der updated nur wenn sich sein Status wirklich ändert und somit kommt auch keine Warnung.

LG
memento
FHEM auf Rpi4, OpenWRT auf Netgear Nighthawk, CUL868, FHT80, Tradfri, CUL433, tbot, alexa-fhem, ESP8266, Shelly 1+2, homebridge, Klingelerkennung über ESP, Anwesenheit per OpenWRT

MadMax-FHEM

#6
Wenn du Events brauchst/willst wo keine sind, dann kannst du mal nach: "Plot abriss vermeiden" suchen...

Oder ein zyklisches at mit "setreading Gerätename Readingname ReadingsVal("Gerätename", "Readingname","Ersatzwert")"

Also einfach zyklisch den aktuellen Wert "drüber setzen"... ;)

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)

memento_10

Und nochmals danke Joachim!

Ich hatte es zuerst mit event-min-interval versucht, aber das klappt nicht.

Mit einem at die Werte mit 'sich selbst' überschreiben lassen funkt einwandfrei!  :)

Vielen Dank und frohes Basteln/Tüfteln/Werken in einer Zeit in welcher viele von uns zu Hause sind.

LG
Simon
FHEM auf Rpi4, OpenWRT auf Netgear Nighthawk, CUL868, FHT80, Tradfri, CUL433, tbot, alexa-fhem, ESP8266, Shelly 1+2, homebridge, Klingelerkennung über ESP, Anwesenheit per OpenWRT

MadMax-FHEM

Gerne.

Ja min-interval funzt so nicht...

Würde nur gehen, wenn durch z.B. event-on-change Events "unterdrückt" würden (aber prinzipiell "da" sind/wären)...
...wenn aber KEINE Events "da" sind werden dadurch keine "erfunden" ;)

Wenn es jetzt so läuft, dann doch bitte noch ein [gelöst] vor den ersten Post...

Viel Spaß noch, 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)

flummy1978

Hallöchen,

auch wenn es bereits erledig ist, würde ich gern meine Lösung für dieses "Problem" vorstellen.....


((Licht.*|REL.*|.*_SD_.*|HEAT_EG_WZ_infrarot_Sw):(on|off|.*on|.*off)$|(TK_EG_BD.*:(open|closed))|(TK_OG_SZ_fenster1:(open|closed))|D1_Temp_SZ:on) {
$EVTPART0 = "on" if $EVTPART0 eq "open";
$EVTPART0 = "off" if $EVTPART0 eq "closed";
auto_onfortimer($NAME,$EVTPART0) }


Dieses notify reagiert so ziemlich auf alle meine Licht, Steckdosen und POW Geräte die eingebrunden sind und eben auch das SZ Fenster. Es erkennt lediglich on und off (für Fenster wird open / closed in on / off gewandelt.
Die weitere Verarbeitung bleibt dann natürlich selbst überlassen. In meinem fall, wird die Sub "auto_onfortimer" aufgerufen.

Dort habe es so gelöst, dass in den betroffnen Geräten ein TIMER_announce und / oder TIMER_set definiert sein muss. Nach Ablauf dieser Zeit gibt es dann eine Nachricht (TIMER_announcemsg) UND / ODER das Gerät wird lediglich ausgeschaltet. Ausschalten macht beim Fenster keinen Sinn, deshalb gibt es dort einfach nur eine Meldung nach X Sekunden. Ein Beispiel ist dann:

attr TIMER_announce 270
attr TIMER_announcemsg Abstellkammerlicht wird in 30 Sekunden ausgeschaltet
attr TIMER_set 300

Damit bekomme ich nach 4:30 Min eine Nachricht auf mein Wunschgerät und nach 5:00 Min wird ausgeschaltet.

Ich muss sagen, das hat sich in den Bereichen bewährt, wo ich gern mal vergessen habe abzuschalten / Fenster zu schließen (Licht Keller, Abstellkammer, die Infrarotheizung oder eben das Schlafzimmer Fenster)

Vielleicht ist das ja auch eine Anregung für andere, das Ganze globaler für mehrere Geräte zu machen :)

Viele Grüße
Andreas

KyleK

@memento_10
Wirf doch mal einen Blick hierauf: https://forum.fhem.de/index.php/topic,36504.0.html

Das funktioniert sehr generisch, ich verwende es mit Fensterkontakten von MAX! und von Aqara.
FHEM on Raspberry Pi 3B+
CUL868
7x MAX! Thermostat, 8x MAX! Fensterkontakte
Conbee II + deConz, TradFri Lampen, Osram Smart+ Steckdosen