Nachricht wenn Thermostat Fenster geschlossen nicht erkannt hat

[teichtaucher]

Hi,
ich habe ein kleines Problem. Und zwar bekommt manchmal mein Homematic Wandthermostat nicht mit wenn ein Fenster geschlossen ist. Fensterkontakt und Wandthermostat sind gepeert und die Fenstererkennung funktioniert zu 95% einwandfrei. Doch gerade heute morgen gab es den Fall dass das Wohnzimmer kalt war weil wir gestern abend kurz ein Fenster offen hatten. Meistens hilft dann Fenster kurz auf und wieder zu. Dann wird es auch wieder warm
Jetzt würde ich mir gern was basteln. Ich habe an ein doif gedacht wenn das Fenster geschlossen ist und das Thermostat nach 5 Sekunden noch Fenster offen erkennt soll eine Nachricht per Telegram verschickt werden (Telegram ist schon eingerichtet). Also sowas in der Art

Code Auswählen Erweitern


define ku.fd.Schiebetuer.GeschlossenErkannt doif ([ku.fk.Schiebetuer] eq "closed")) (doif (wz.wt.Heizung_WindowRec eq "open")(set gl.tb.Telegram message Wohnzimmer Fenster geschlossen nicht erkannt!))

wait 5


- Kann ich doif schachteln oder ist das nicht so elegant
- Wie kann ich den Status von wz.wt.Heizung_WindowRec richtig auslesen? Das Thermostat ist noch mit anderen Fensterkontakten gepeered. Ich fände es schön wenn es global für alle gepeerten Kontakte funktioniert.
- Vielleicht gibt es ja noch eine elegantere Lösung z.B. über notify.

Danke für Eure Hilfe!

[frank]

das eleganteste wäre eine 100% erkennung. 

zeig mal je ein list vom fk und vom window_rec channel des thermostats.

[teichtaucher]

Hier der Fensterkontakt:

Code Auswählen Erweitern



Internals:
   DEF        44257C
   FUUID      5cb63bfb-f33f-d318-6683-f8d5e56a3dd28e23
   HMLAN1_MSGCNT 6307
   HMLAN1_RAWMSG E44257C,0000,04BB724F,FF,FFBC,7CA61044257C30123506010000
   HMLAN1_RSSI -68
   HMLAN1_TIME 2019-11-19 14:06:39
   IODev      gl.gw.Wemos
   LASTInputDev HMLAN1
   MSGCNT     18827
   NAME       ku.fk.Schiebetuer
   NOTIFYDEV  global
   NR         60
   NTFY_ORDER 50-ku.fk.Schiebetuer
   STATE      closed
   TYPE       CUL_HM
   chanNo     01
   gl.gw.Wemos_MSGCNT 12520
   gl.gw.Wemos_RAWMSG 050100267CA61044257C30123506010000
   gl.gw.Wemos_RSSI -38
   gl.gw.Wemos_TIME 2019-11-19 14:06:39
   lastMsg    No:7C - t:10 s:44257C d:301235 06010000
   protCmdDel 2
   protLastRcv 2019-11-19 14:06:39
   protRcv    12551 last_at:2019-11-19 14:06:39
   protRcvB   1497 last_at:2019-11-19 06:49:25
   protResnd  9 last_at:2019-04-20 01:42:06
   protResndFail 2 last_at:2019-04-20 02:36:09
   protSnd    6946 last_at:2019-11-19 14:06:39
   protState  CMDs_done
   rssi_at_HMLAN1 cnt:6307 min:-94 max:-51 avg:-64.9 lst:-68
   rssi_at_gl.gw.Wemos cnt:12520 min:-58 max:-32 avg:-39.57 lst:-38
   READINGS:
     2019-04-16 22:33:16   Activity        alive
     2018-07-19 08:03:50   CommandAccepted no
     2017-09-16 11:54:39   D-firmware      1.0
     2017-09-16 11:54:39   D-serialNr      MEQ1723075
     2019-04-19 23:01:38   PairedTo        0x301235
     2017-09-16 12:20:32   R-cyclicInfoMsg on
     2017-09-16 12:20:33   R-eventDlyTime  0 s
     2017-09-16 12:20:32   R-pairCentral   0x301235
     2017-09-16 12:20:32   R-sabotageMsg   on
     2017-09-16 12:20:33   R-sign          on
     2019-04-19 23:01:38   RegL_00.         00:00 02:01 09:01 0A:30 0B:12 0C:35 10:01 14:06
     2019-04-19 23:01:39   RegL_01.         00:00 08:01 20:9C 21:00 30:06
     2017-09-16 11:54:41   aesCommToDev    ok
     2017-09-16 11:54:40   aesKeyNbr       00
     2019-11-19 14:06:39   alive           yes
     2019-11-19 14:06:39   battery         ok
     2019-11-19 14:06:39   contact         closed (to VCCU)
     2019-04-19 23:01:25   powerOn         2019-04-19 23:01:25
     2019-11-19 14:06:39   recentStateType info
     2019-11-19 14:06:39   sabotageError   off
     2019-11-19 14:06:39   state           closed
     2017-10-01 17:31:23   trigDst_2E75D1  noConfig
     2017-10-01 17:31:22   trigDst_2E7BB3  noConfig
     2017-10-01 17:31:23   trigDst_301235  noConfig
     2017-10-01 17:31:22   trigDst_5241B3  noConfig
     2017-10-10 15:23:32   trigDst_HM_2E75D1 noConfig
     2017-10-10 15:23:31   trigDst_HM_2E7BB3 noConfig
     2017-10-10 15:23:31   trigDst_HM_3CF0F8 noConfig
     2017-10-10 15:23:31   trigDst_HM_5241B3 noConfig
     2019-11-19 06:49:25   trigDst_az.ht.Heizung noConfig
     2019-11-19 06:49:25   trigDst_ku.ht.Heizung noConfig
     2019-11-19 06:49:26   trigDst_wz.Ht.Couch noConfig
     2019-11-19 06:49:26   trigDst_wz.ht.Essecke noConfig
     2019-11-19 06:49:26   trigger_cnt     72
   helper:
     HM_CMDNR   124
     PONtest    0
     cSnd       0130123544257C0103,0130123544257C0103
     getCfgList all
     getCfgListNo ,4
     mId        00C7
     peerFriend peerAct,peerVirt
     peerOpt    4:threeStateSensor
     regLst     0,1,4p
     rxType     28
     supp_Pair_Rep 0
     ack:
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newCh      1
       newChn     +44257C,00,00,00
       nextSend   1574168799.29818
       prefIO     
       rxt        2
       vccu       VCCU
       p:
         44257C
         00
         00
         00
     mRssi:
       mNo        7C
       io:
         HMLAN1:
           -68
           -68
         gl.gw.Wemos:
           -30
           -30
     prt:
       bErr       0
       sProc      0
       sleeping   0
       rspWait:
     q:
       qReqConf   
       qReqStat   
     regCollect:
     role:
       chn        1
       dev        1
     rpt:
       IO         gl.gw.Wemos
       flg        A
       ts         1574168799.20831
       ack:
         HASH(0x20b4a30)
         7C800230123544257C00
     rssi:
       at_HMLAN1:
         avg        -64.9007452037417
         cnt        6307
         lst        -68
         max        -51
         min        -94
       at_gl.gw.Wemos:
         avg        -39.5717252396166
         cnt        12520
         lst        -38
         max        -32
         min        -58
     shadowReg:
Attributes:
   IODev      HMLAN1
   IOgrp      VCCU
   actCycle   002:50
   actStatus  alive
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.0
   model      HM-SEC-SCo
   peerIDs   
   room       Kueche
   serialNr   MEQ1723075
   subType    threeStateSensor


Und hier der Window_rec

Code Auswählen Erweitern


Internals:
   DEF        31DC4203
   FUUID      5cb63bfd-f33f-d318-73b5-d420a606779dfe72
   NAME       wz.wt.Heizung_WindowRec
   NOTIFYDEV  global
   NR         83
   NTFY_ORDER 50-wz.wt.Heizung_WindowRec
   STATE      last:wz.fk.Garten:closed
   TYPE       CUL_HM
   chanNo     03
   device     wz.wt.Heizung
   peerList   ku.fk.Schiebetuer,wz.fk.Garten,
   READINGS:
     2017-10-01 20:32:20   R-sign          off
     2019-03-17 09:23:50   RegL_01.        00:00 08:00
     2019-03-17 09:23:51   RegL_03.ku.fk.Schiebetuer_chn-01 00:00 04:32
     2019-03-17 09:23:52   RegL_03.wz.fk.Garten_chn-01 00:00 04:32
     2019-03-17 09:23:52   RegL_07.ku.fk.Schiebetuer_chn-01 00:00 05:0A
     2019-03-17 09:23:52   RegL_07.wz.fk.Garten_chn-01 00:00 05:18
     2019-04-16 22:33:27   peerList        ku.fk.Schiebetuer,wz.fk.Garten,
     2019-04-16 22:33:27   state           unknown
     2019-11-19 06:48:44   trigLast        wz.fk.Garten:closed
     2019-11-19 06:48:44   trig_wz.fk.Garten Closed_236
   helper:
     peerFriend peerSens,peerVirt
     peerOpt    3:thermostat,7p:thermostat
     regLst     1,3p,7p
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     role:
       chn        1
Attributes:
   model      HM-TC-IT-WM-W-EU
   peerIDs    00000000,44257C01,58BBFC01,
   room       Wohnzimmer
   stateFormat last:trigLast


[rabehd]

wenn das Fenster geschlossen ist und das Thermostat nach 5 Sekunden noch Fenster offen erkennt

Sowas kenne ich von Homematic (bei mir) nicht.

Da wäre zuerst mal zu klären, ob der Fenstersensor überhaupt mitbekommen hat das das Fenster geschlossen wurde?

Wie kann ich den Status von wz.wt.Heizung_WindowRec richtig auslesen? Das Thermostat ist noch mit anderen Fensterkontakten gepeered.

War, glaube ich, hier schon mal Thema. Forensuche schon ausprobiert?

[MadMax-FHEM]

Doch das kann ich nachvollziehen.

Und ja der Fenstersensor erkennt das geschlossene Fenster und meldet auch brav an fhem...
...aber auf dem WT ist immer noch das Fenster-Offen-Symbol (und somit auch die Heizung "unten").

Ich denke es ging halt das Funktelegramm verloren?
- Wobei ich kein "rotes Blinken" am FK gesehen habe (zumindest nicht bewusst)...
- Wobei der FK ja ein paar Mal wiederholt!?

Was ich mir da "gebastelt" habe ist folgendes:

Ein notify was eben auf "geschlossenes Fenster" lauscht:

Code Auswählen Erweitern


defmod nCheckWinOpenReading notify Fenster_.*:closed {my_CheckWinOpenReading($NAME, "notify")}


Und eben eine Sub, die dann gleich und mit einem at später noch mal prüft (weil es schon mal etwas dauern kann, bis das Reading "umschlägt")...

Hier die Sub für myUtils:

Code Auswählen Erweitern


#########################################
# Helper to check if a Wandthermostat missed a closed message of a window
sub my_CheckWinOpenReading($$)
{
  my ($Device, $CallOption)  = @_;
  my @DeviceParts = split(/_/, $Device);
  my $Channel = "Wandthermostat_" . $DeviceParts[1] . "_WindowRec";
  my $WinOpenReading = (split(/:/, ReadingsVal($Channel, "trigLast", "x:open")))[1];
  my $AtName = "atCheckWinOpenReading_" . $Device;

  Log3(undef, 3, "my_CheckWinOpenReading     Device: $Device      ChannelName: $Channel     WinOpenReading: $WinOpenReading      CallOption: $CallOption");
 
  if($WinOpenReading eq "open")
  {
    if($CallOption eq "notify")
    {
      fhem("defmod $AtName at +00:00:10 {my_CheckWinOpenReading(\"$Device\", \"timer\")}");
    }
    elsif($CallOption eq "timer")
    {
      fhem("set $myTelegramBot message $Channel hat falschen WinOpenStatus.");
    }
  }
}


Wichtig ist halt die "Namensgebung", damit man von Fenster auf WT schließen kann.

Bei mir "einfach", da die Namensgebung wie folgt ist:

Fenster_Raum
Wandthermostat_Raum_Kanal

Ob das Reading was mit dem "icon" (Fenster-Offen) und somit mit dem Runterdrehen der Heizung zu tun hat...
...hab ich noch nicht zweifelsfrei herausgefunden...

Vielleicht hilft es, vielleicht wird es auch durch mehr "Tester" klarer was man da tun kann...

Gruß, Joachim

[Beta-User]

Ich habe zwischenzeitlich alle direkten FK-Peerings aufgehoben und arbeite nur noch mit etwas myUtils Code, ähnlich wie MadMax-FHEM, nur dass bei mir die Zugehörigkeiten über userAttr festgelegt werden.

Weitere Hinweise und links einsch. kleiner commandref ist hier zu finden:
https://forum.fhem.de/index.php/topic,104523.msg984028.html#msg984028

[frank]

@teichtaucher

die list sind ja ziehmlich outdated.
fhem weiss nicht viel über die peerings der devices.

ich empfehle erst mal ein "get hminfo configCheck" ab zu arbeiten.
ich würde erst alle daten in fhem löschen mit "set clear all" und dann alles neu einlesen mit "set getConfig".

am fehlverhalten des fk ändert das allerdings nichts.


eventuell verbessert sich die erkennung, wenn das register eventDlyTime im fk auf zb 1s gesetzt wird.

[Omega]

Dieses Phänomen kenne ich leider auch. Obwohl alle Zustände korrekt erkannt werden (alle Readings im Fensterkontakt und im Wandthermostat sehen das Fenster als geschlossen an) bleibt das Fenster-Offen-Icon in der Anzeige des Wandthermostats. Und damit unterbleibt die Meldung an die dazugehörigen Thermostaten.
Meine Lösung dazu: in einem DOIF prüfe ich, ob Wandthermostat_Climate:desired-temp den Wert meiner Fenster-offen-Temperatur hat UND gleichzeitig, ob der Status des dazugehörigen Fensters closed ist. Wenn ja, kommt eine entsprechende Meldung.

LG
Holger