Homematic doch nicht bidirektional?

Begonnen von Omega, 02 Januar 2016, 10:11:22

Vorheriges Thema - Nächstes Thema

Omega

Ein Fensterschalter wird von Wandthermostat manchmal nicht verarbeitet.

Ausgangssituation: Terassentür wurde um 2016-01-01_16:45:05 geöffnet und um 2016-01-01_16:45:18 wieder geschlossen. Am nächsten Morgen habe ich gesehen, dass der Status lt. Wandthermostat noch auf ,,offen" stand. Ich habe dann kurz die Tür geöffnet und wieder geschlossen – danach war wieder alles ok. Aber der Raum war kalt und der WAF im Eimer.

Auszug aus FileLog_Wz.Terassentuer

2016-01-01_13:26:32 Wz.Terassentuer trigger_cnt: 1
2016-01-01_16:45:05 Wz.Terassentuer battery: ok
2016-01-01_16:45:05 Wz.Terassentuer contact: open (to vccu)
2016-01-01_16:45:05 Wz.Terassentuer open
2016-01-01_16:45:05 Wz.Terassentuer trigger_cnt: 2
2016-01-01_16:45:06 Wz.Terassentuer battery: ok
2016-01-01_16:45:06 Wz.Terassentuer contact: open (to Wz.Thermostat_Essecke)
2016-01-01_16:45:06 Wz.Terassentuer open
2016-01-01_16:45:06 Wz.Terassentuer trigger_cnt: 2
2016-01-01_16:45:06 Wz.Terassentuer battery: ok
2016-01-01_16:45:06 Wz.Terassentuer contact: open (to Wz.Thermostat_TV)
2016-01-01_16:45:06 Wz.Terassentuer open
2016-01-01_16:45:06 Wz.Terassentuer trigger_cnt: 2
2016-01-01_16:45:07 Wz.Terassentuer battery: ok
2016-01-01_16:45:07 Wz.Terassentuer contact: open (to Wz.Wandthermostat)
2016-01-01_16:45:07 Wz.Terassentuer open
2016-01-01_16:45:07 Wz.Terassentuer trigger_cnt: 2
2016-01-01_16:45:18 Wz.Terassentuer battery: ok
2016-01-01_16:45:18 Wz.Terassentuer contact: closed (to vccu)
2016-01-01_16:45:18 Wz.Terassentuer closed
2016-01-01_16:45:18 Wz.Terassentuer trigger_cnt: 3
2016-01-01_16:45:19 Wz.Terassentuer battery: ok
2016-01-01_16:45:19 Wz.Terassentuer contact: closed (to Wz.Thermostat_Essecke)
2016-01-01_16:45:19 Wz.Terassentuer closed
2016-01-01_16:45:19 Wz.Terassentuer trigger_cnt: 3
2016-01-01_16:45:19 Wz.Terassentuer battery: ok
2016-01-01_16:45:19 Wz.Terassentuer contact: closed (to Wz.Thermostat_TV)
2016-01-01_16:45:19 Wz.Terassentuer closed
2016-01-01_16:45:19 Wz.Terassentuer trigger_cnt: 3
2016-01-01_16:45:20 Wz.Terassentuer battery: ok
2016-01-01_16:45:20 Wz.Terassentuer contact: closed (to Wz.Wandthermostat)
2016-01-01_16:45:20 Wz.Terassentuer closed
2016-01-01_16:45:20 Wz.Terassentuer trigger_cnt: 3
2016-01-02_05:58:15 Wz.Terassentuer battery: ok
2016-01-02_05:58:15 Wz.Terassentuer contact: open (to vccu)
2016-01-02_05:58:15 Wz.Terassentuer open
2016-01-02_05:58:15 Wz.Terassentuer trigger_cnt: 4
2016-01-02_05:58:15 Wz.Terassentuer battery: ok
2016-01-02_05:58:15 Wz.Terassentuer contact: open (to Wz.Thermostat_Essecke)
2016-01-02_05:58:15 Wz.Terassentuer open
2016-01-02_05:58:15 Wz.Terassentuer trigger_cnt: 4
2016-01-02_05:58:15 Wz.Terassentuer battery: ok
2016-01-02_05:58:15 Wz.Terassentuer contact: open (to Wz.Thermostat_TV)
2016-01-02_05:58:15 Wz.Terassentuer open
2016-01-02_05:58:15 Wz.Terassentuer trigger_cnt: 4
2016-01-02_05:58:16 Wz.Terassentuer battery: ok
2016-01-02_05:58:16 Wz.Terassentuer contact: open (to Wz.Wandthermostat)
2016-01-02_05:58:16 Wz.Terassentuer open
2016-01-02_05:58:16 Wz.Terassentuer trigger_cnt: 4
2016-01-02_05:58:21 Wz.Terassentuer battery: ok
2016-01-02_05:58:21 Wz.Terassentuer contact: closed (to vccu)
2016-01-02_05:58:21 Wz.Terassentuer closed
2016-01-02_05:58:21 Wz.Terassentuer trigger_cnt: 5
2016-01-02_05:58:22 Wz.Terassentuer battery: ok
2016-01-02_05:58:22 Wz.Terassentuer contact: closed (to Wz.Thermostat_Essecke)
2016-01-02_05:58:22 Wz.Terassentuer closed
2016-01-02_05:58:22 Wz.Terassentuer trigger_cnt: 5
2016-01-02_05:58:22 Wz.Terassentuer battery: ok
2016-01-02_05:58:22 Wz.Terassentuer contact: closed (to Wz.Thermostat_TV)
2016-01-02_05:58:22 Wz.Terassentuer closed
2016-01-02_05:58:22 Wz.Terassentuer trigger_cnt: 5
2016-01-02_05:58:22 Wz.Terassentuer battery: ok
2016-01-02_05:58:22 Wz.Terassentuer contact: closed (to Wz.Wandthermostat)
2016-01-02_05:58:22 Wz.Terassentuer closed
2016-01-02_05:58:22 Wz.Terassentuer trigger_cnt: 5

Es ist zu sehen, dass der Schaltvorgang erkannt und weitergegeben wurde.


Auszug aus FileLog_Wz.Wandthermostat

2016-01-01_16:43:23 Wz.Wandthermostat_Climate desired-temp: 21.5
2016-01-01_16:43:23 Wz.Wandthermostat_Climate humidity: 48
2016-01-01_16:43:23 Wz.Wandthermostat_Climate measured-temp: 21.1
2016-01-01_16:43:23 Wz.Wandthermostat_Climate T: 21.1 desired: 21.5
2016-01-01_16:49:09 Wz.Wandthermostat_Climate desired-temp: 16.0
2016-01-01_16:49:09 Wz.Wandthermostat_Climate humidity: 48
2016-01-01_16:49:09 Wz.Wandthermostat_Climate measured-temp: 21.2
2016-01-01_16:49:09 Wz.Wandthermostat_Climate T: 21.2 desired: 16.0
2016-01-01_16:49:19 Wz.Wandthermostat battery: ok
2016-01-01_16:49:19 Wz.Wandthermostat batteryLevel: 2.5
2016-01-01_16:49:19 Wz.Wandthermostat desired-temp: 16.0
2016-01-01_16:49:19 Wz.Wandthermostat measured-temp: 21.2
2016-01-01_16:49:19 Wz.Wandthermostat_Climate boostTime: -
2016-01-01_16:49:19 Wz.Wandthermostat_Climate commReporting: off
2016-01-01_16:49:19 Wz.Wandthermostat_Climate controlMode: auto
2016-01-01_16:49:19 Wz.Wandthermostat_Climate desired-temp: 16.0
2016-01-01_16:49:19 Wz.Wandthermostat_Climate measured-temp: 21.2
2016-01-01_16:49:19 Wz.Wandthermostat_Climate T: 21.2 desired: 16.0
2016-01-01_16:49:19 Wz.Wandthermostat_Climate winOpenReporting: on
2016-01-01_16:51:41 Wz.Wandthermostat_Climate desired-temp: 16.0

Der Schaltvorgang ist aber sichtbar nicht angekommen.
Homematic baut doch eine bidirektionale Kommunikation auf, d.h. der Schalter müsste doch gemerkt haben, dass die Rückmeldung vom Wandthermostat fehlt und daher erneut senden.

Ein List des Schalters

Internals:
   DEF        21E7DC
   HMLAN1_MSGCNT 361
   HMLAN1_RAWMSG E21E7DC,0000,5E02A17C,FF,FFB2,18A04121E7DC2B0B86010500
   HMLAN1_RSSI -78
   HMLAN1_TIME 2016-01-02 05:58:22
   HMUSB_MSGCNT 331
   HMUSB_RAWMSG E21E7DC,0000,B49B2099,FF,FFA6,16B04121E7DC22DE80010500
   HMUSB_RSSI -90
   HMUSB_TIME 2016-01-02 05:58:22
   IODev      HMLAN1
   LASTInputDev HMLAN1
   MSGCNT     692
   NAME       Wz.Terassentuer
   NR         42
   NTFY_ORDER 50-Wz.Terassentuer
   STATE      closed
   TYPE       CUL_HM
   lastMsg    No:18 - t:41 s:21E7DC d:2B0B86 010500
   peerList   Wz.Thermostat_Essecke_WindowRec,Wz.Thermostat_TV_WindowRec,Wz.Wandthermostat_WindowRec,
   protLastRcv 2016-01-02 05:58:22
   protSnd    90 last_at:2016-01-02 05:58:21
   protState  CMDs_done
   rssi_at_HMLAN1 avg:-78.25 min:-102 max:-70 lst:-78 cnt:361
   rssi_at_HMUSB avg:-76.29 min:-90 max:-69 lst:-90 cnt:331
   Readings:
     2015-12-21 10:46:55   Activity        alive
     2015-09-03 16:17:35   CommandAccepted yes
     2015-09-03 16:17:34   D-firmware      2.1
     2015-09-03 16:17:34   D-serialNr      KEQ0550478
     2015-09-03 16:17:35   PairedTo        0x272E57
     2014-10-30 11:43:40   R-Wz.Thermostat_Essecke_WindowRec-expectAES off
     2014-10-30 11:43:40   R-Wz.Thermostat_Essecke_WindowRec-peerNeedsBurst on
     2014-10-30 11:43:40   R-Wz.Thermostat_TV_WindowRec-expectAES off
     2014-10-30 11:43:40   R-Wz.Thermostat_TV_WindowRec-peerNeedsBurst on
     2015-09-03 16:17:38   R-Wz.Wandthermostat_WindowRec-expectAES off
     2015-09-03 16:17:38   R-Wz.Wandthermostat_WindowRec-peerNeedsBurst on
     2014-10-30 11:43:38   R-cyclicInfoMsg on
     2014-10-09 14:02:52   R-eventDlyTime  3 s
     2014-10-30 11:43:38   R-pairCentral   0x272E57
     2014-10-30 11:43:38   R-sign          off
     2015-09-03 16:17:35   RegL_00:        02:01 09:01 0A:27 0B:2E 0C:57 10:01 14:06 00:00
     2015-09-03 16:17:36   RegL_01:        08:00 20:6C 21:03 22:64 30:06 00:00
     2015-09-03 16:17:37   RegL_04:Wz.Thermostat_Essecke_WindowRec 01:01 00:00
     2015-09-03 16:17:37   RegL_04:Wz.Thermostat_TV_WindowRec 01:01 00:00
     2015-09-03 16:17:38   RegL_04:Wz.Wandthermostat_WindowRec 01:01 00:00
     2015-12-31 14:07:08   alive           yes
     2016-01-02 05:58:22   battery         ok
     2016-01-02 05:58:22   contact         closed (to Wz.Wandthermostat)
     2015-12-31 14:07:08   cover           closed
     2015-11-20 14:41:44   lastBatChange   Fri Nov 20 14:41:44 2015
     2015-12-21 10:46:55   peerList        Wz.Thermostat_Essecke_WindowRec,Wz.Thermostat_TV_WindowRec,Wz.Wandthermostat_WindowRec,
     2015-12-31 14:07:08   powerOn         2015-12-31 14:07:08
     2015-12-31 14:07:08   recentStateType info
     2016-01-02 05:58:22   state           closed
     2016-01-02 05:58:22   trigger_cnt     5
   Helper:
     HM_CMDNR   24
     PONtest    0
     mId        0030
     rxType     4
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       newChn     +21E7DC,00,00,00
       nextSend   1451710702.78912
       rxt        0
       vccu       vccu
       p:
         21E7DC
         00
         00
         00
     Mrssi:
       mNo        18
       Io:
         HMLAN1     -76
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf   00
       qReqStat
     Role:
       chn        1
       dev        1
     Rssi:
       At_hmlan1:
         avg        -78.2576177285319
         cnt        361
         lst        -78
         max        -70
         min        -102
       At_hmusb:
         avg        -76.2960725075529
         cnt        331
         lst        -90
         max        -69
         min        -90
Attributes:
   IODev      HMLAN1
   IOgrp      vccu
   actCycle   028:00
   actStatus  alive
   autoReadReg 4
   devStateIcon open:fts_window_2w_open_r@red closed:fts_window_2w@green tilted:fts_window_2w_tilt@orange
   expert     2_full
   firmware   2.1
   icon       fts_window_2w
   model      HM-SEC-RHS
   peerIDs    00000000,22DE8003,22EC4D03,2B0B8603,
   room       Kueche,Wohnzimmer
   serialNr   KEQ0550478
   subType    threeStateSensor


Und ein List des Wandthermostaten:

Internals:
   DEF        2B0B86
   HMLAN1_MSGCNT 14518
   HMLAN1_RAWMSG E2B0B86,0000,5ED233DA,FF,FFB8,BB84702B0B8600000000D22F
   HMLAN1_RSSI -72
   HMLAN1_TIME 2016-01-02 09:45:03
   HMUSB_MSGCNT 14117
   HMUSB_RAWMSG E2B0B86,0000,B56AAD10,FF,FFC0,BB84702B0B8600000000D22F
   HMUSB_RSSI -64
   HMUSB_TIME 2016-01-02 09:45:03
   IODev      HMLAN1
   LASTInputDev HMUSB
   MSGCNT     28635
   NAME       Wz.Wandthermostat
   NR         207
   NTFY_ORDER 50-Wz.Wandthermostat
   STATE      CMDs_done
   TYPE       CUL_HM
   channel_01 Wz.Wandthermostat_Weather
   channel_02 Wz.Wandthermostat_Climate
   channel_03 Wz.Wandthermostat_WindowRec
   channel_06 Wz.Wandthermostat_remote
   channel_07 Wz.Wandthermostat_SwitchTr
   lastMsg    No:BB - t:70 s:2B0B86 d:000000 00D22F
   protCondBurst forced_off
   protLastRcv 2016-01-02 09:45:03
   protSnd    17 last_at:2016-01-02 00:58:42
   protState  CMDs_done
   rssi_HMLAN1 avg:-55 min:-55 max:-55 lst:-55 cnt:4
   rssi_at_HMLAN1 avg:-67.5 min:-86 max:-57 lst:-72 cnt:14518
   rssi_at_HMUSB avg:-70.78 min:-99 max:-63 lst:-64 cnt:14117
   Readings:
     2015-12-21 10:46:55   Activity        alive
     2016-01-02 05:58:22   CommandAccepted yes
     2015-09-03 16:25:00   D-firmware      1.2
     2015-09-03 16:25:00   D-serialNr      LEQ0441410
     2015-09-12 19:18:23   PairedTo        0x272E57
     2015-12-11 12:39:03   R-btnLock       off
     2014-10-30 11:06:16   R-burstRx       on
     2014-10-30 11:06:16   R-cyclicInfoMsg on
     2014-10-30 11:06:16   R-cyclicInfoMsgDis 0
     2014-10-30 11:06:16   R-globalBtnLock off
     2014-10-30 11:06:16   R-localResDis   off
     2014-09-01 11:19:54   R-lowBatLimitRT 2.2 V
     2015-09-12 18:27:12   R-modusBtnLock  off
     2015-09-03 16:00:39   R-pairCentral   0x272E57
     2015-12-11 12:39:03   RegL_00:        01:01 02:01 09:01 0A:27 0B:2E 0C:57 0F:00 11:00 12:16 16:00 18:00 19:00 1A:00 00:00
     2015-11-24 14:29:44   RegL_07:
     2016-01-02 09:37:42   battery         ok
     2016-01-02 09:37:42   batteryLevel    2.5
     2016-01-02 09:37:42   desired-temp    21.0
     2014-10-11 17:29:47   inhibit         set_off
     2016-01-02 09:37:42   measured-temp   21.0
     2015-09-03 15:51:38   powerOn         2015-09-03 15:51:38
     2015-09-03 15:51:38   recentStateType info
     2015-05-01 10:08:26   sabotageAttack  ErrIoAttack cnt:2
     2016-01-02 00:58:42   state           CMDs_done
     2016-01-02 00:58:42   time-request    -
   Helper:
     HM_CMDNR   187
     PONtest    1
     cSnd       11272E572B0B8686042B,11272E572B0B8686042B
     mId        00AD
     rxType     6
     Expert:
       def        1
       det        1
       raw        1
       tpl        1
     Io:
       newChn     +2B0B86,00,00,00
       nextSend   1451724304.09282
       rxt        0
       vccu       vccu
       p:
         2B0B86
         00
         00
         00
       prefIO:
         HMLAN1
     Mrssi:
       mNo        BB
       Io:
         HMLAN1     -70
         HMUSB      -64
     Prt:
       awake      0
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       dev        1
     Rssi:
       Hmlan1:
         avg        -55
         cnt        4
         lst        -55
         max        -55
         min        -55
       At_hmlan1:
         avg        -67.5013087202088
         cnt        14518
         lst        -72
         max        -57
         min        -86
       At_hmusb:
         avg        -70.7847984699301
         cnt        14117
         lst        -64
         max        -63
         min        -99
     Shregw:
       07         02
     Tmpl:
Attributes:
   IODev      HMLAN1
   IOgrp      vccu:HMLAN1
   actCycle   000:10
   actStatus  alive
   autoReadReg 5_readMissing
   burstAccess 0_off
   expert     251_anything
   firmware   1.2
   icon       hc_wht_regler
   model      HM-TC-IT-WM-W-EU
   msgRepeat  1
   room       Wohnzimmer
   serialNr   LEQ0441410
   subType    thermostat
   webCmd     getConfig:clear msgEvents


Ein set hm configCheck zeigt keine Fehler, den letzten Update habe ich am 16.12.2015 gemacht. Im Standardlog sehe ich auch nichts, was mit dem Problem im Zusammenhang stehen könnte. Um die relevante Uhrzeit passiert nichts.

2016.01.01 15:14:31 2: ZWDongle_0 transmit NO_ACK for 07
2016.01.01 16:53:52 3: CUL_HM set Zw_Stecker_LM_3_Sw on


Dieser Sachverhalt ist mir in der letzten Zeit mindestens 3 x aufgefallen, 2 x beim Wandthermostat im Wohnzimmer, 1 x beim Wandthermostat im Bad (da habe ich aber kein Beispiel zur Hand).

Habt ihr eine Idee, woran das liegen kann?
Was kann man ggf. machen, um wirklich sicherzustellen, dass die Kommandos ankommen und umgesetzt werden?

LG
Holger
NUC6i3SYH (FHEM 5.8 in VM)
Homematic: HMLAN, HMUSB, HM-Sec-SD, HM-CC-RT-DN, HM-TC-IT, ... + diverse weitere
LaCrosseGateway, ESPEasy
ZWave

A.Harrenberg

Hi,

bin zwar kein Fachmann für HomeMatic, aber der RSSI, also der "Signalpegel", für Deine Komponenten ist mit teilweise bis zu -90 dB sehr gering und deutet daher auf schlechten Empfang hin. Das sind jetzt zwar die Werte zwischen den Komponenten und der Zentrale. Da Du ja direkt gepaired hast wären die Werte zwischen den Komponenten untereinander interessant, die gibt es aber soweit ich weiß nicht...

Ich würde mal versuchen die Empfangsituationen zu verbessern... Zur größten Not gibt es Repeater:

http://www.elv.de/homematic-selektiver-funk-zwischenstecker-repeater-hm-sys-srp-pl-fertiggeraet.html
http://www.elv.de/homematic-selektiver-funk-zwischenstecker-repeater-hm-sys-srp-pl-komplettbausatz.html

Das mit dem bidirektionalen nutzt ja nix wenn der Sender dann zwar weiß das sein Paket nicht angekommen ist, wenn er es dann aber ein paar Mal (kein Ahnung wie oft HomeMatic es versucht) gesendet hat gibt er irgendwann auf.

Ich bin mir jetzt nicht sicher ob man sich nicht eine kleine Sicherheitsabfrage machen kann die periodisch den Status der Tür und den entsprechenden Status an den Heizungsthermostaten auslesen und vergleichen kann und im Fall von Unterschieden evtl. den Status von der Zentrale aus setzen könnte.

Gruß,
Andreas.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

MarcelK

Ich kenn den RHS nicht, aber meine Sensoren haben zwei Register "transmitTryMax" bzw. "transmDevTryMax" die angeben wie oft versucht wird. Meine stehen z.B. auf 6. Mach mal nen neuen GetConfig mit dem Sensor und schau ob's die da nicht auch gibt.

Gruss Marcel

Omega

@A.Harrenberg
Auf den 1. Blick ja, aber die schlechten Werte stammen vermutlich aus der Zeit mit Umbauten in der Nähe des HMLAN. Die RSSI-Messung habe ich mal neu aufgesetzt, dabei kommt aktuell das raus:

Wz.Terassentuer HMLAN1          Wz.Terassentuer  -76.0  -76.5  -77.0< -76.0    11
    Wz.Terassentuer HMUSB           Wz.Terassentuer  -83.0  -81.4  -87.0< -78.0     9
    Wz.Wandthermostat HMLAN1          Wz.Wandthermostat  -72.0  -70.9  -78.0< -67.0    16
    Wz.Wandthermostat HMUSB           Wz.Wandthermostat  -66.0  -68.9  -76.0< -65.0    15

Bei beiden Geräten steht das IODev auf dem HMLAN1 - also von daher denke ich nicht, dass der Empfang Schuld ist

@MarcelK
getconfig habe ich durchgeführt, die Register tauchen bei mir aber nicht auf

Gruß
Holger
NUC6i3SYH (FHEM 5.8 in VM)
Homematic: HMLAN, HMUSB, HM-Sec-SD, HM-CC-RT-DN, HM-TC-IT, ... + diverse weitere
LaCrosseGateway, ESPEasy
ZWave

viegener

Du könntest mal versuchen die Anzahl der Sendeversuche über das Attribut msgRepeat zu erhöhen. Meine Fenstersensoren unterstützen das.

Johannes
Kein Support über PM - Anfragen gerne im Forum - Damit auch andere profitieren und helfen können

frank

ZitatBei beiden Geräten steht das IODev auf dem HMLAN1 - also von daher denke ich nicht, dass der Empfang Schuld ist
hmm... fakt ist, dass der fk gesendet hat, und der wt nicht reagiert hat. grundsätzlich kann der wt empfangen, aber einmal hat es nicht funktioniert. somit war der empfang in diesem moment gestört. selbst mit brauchbaren rssi kann der funk gestört sein. in diesem fall sind die relevanten rssi nicht mal vorhanden. ich habe bei mir die antenne am fk freigelegt. http://www.techwriter.de/beispiel/funkeig1.htm

spiel mal mit attr expert am fk, dann solltest du die register sehen können. die 6 wiederholungen sollten aber ausreichen.

für 13 sekunden die thermostate zu- und aufdrehen ist aber auch bedenkenswert.  ;)

edit: msgrepeat bezieht sich aber nur auf die kommunikation mit der zentrale.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

A.Harrenberg

Hi,

entscheidend ist ja die Kommunikation zwischen dem Fenster/Tür-Kontakt und den drei Thermostaten. Die kommunizieren ja direkt und nicht über die Zentrale.

Da sich die ja normalerweise in einem Raum befinden sollte es da keine Probleme mit Reichweite geben, ich bin mir aber nicht sicher ob bei mehr als einem gepeerten Thermostat das als einzelne Nachricht rausgeht oder eine Art Multi-Cast gemacht wird. Es könnte dann nämlich sein das bei Multi-Cast KEINE Rückmeldung erfolgt, das ist aber nur eine wage Vermutung, dazu muss sich mal jemand mit mehr HomeMatic-Wissen äußern.

Die Register werden bei mir auch nicht angezeigt, mach mal ein get regList, dann siehst Du schon mal den Aufbau der Register mit den beiden beschriebenen Registern.
Wenn Deine Reading RegL-00 etc. enthalten kannst Du die mit get transmDevTryMax bzw. transmDevTryMax auslesen (stehen bei mir auch auf 6).
(mit dem Attribut expert = 3_all werden die Register auch angezeigt...)

Ich habe nur einen Fenstersensor im Einsatz, und damit bisher keine Probleme gehabt...

Gruß,
Andreas.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

frank

ZitatDa sich die ja normalerweise in einem Raum befinden sollte es da keine Probleme mit Reichweite geben, ich bin mir aber nicht sicher ob bei mehr als einem gepeerten Thermostat das als einzelne Nachricht rausgeht oder eine Art Multi-Cast gemacht wird. Es könnte dann nämlich sein das bei Multi-Cast KEINE Rückmeldung erfolgt, das ist aber nur eine wage Vermutung, dazu muss sich mal jemand mit mehr HomeMatic-Wissen äußern.
an jeden peer und die zentrale gibt es separate messages.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

frank

vielleicht hilft auch ein fw-update auf v1.3
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Omega

@all – Danke für die Unterstützung

expert = 3_all hat mir gleich die Register zur Anzeige gebracht. Beide (R-transmDevTryMax, R-transmitTryMax) stehen schon auf 6.

Zitat
für 13 sekunden die thermostate zu- und aufdrehen ist aber auch bedenkenswert.  ;)
Wenn man nur kurz etwas auf die Terasse stellt  ;). Gibt es dafür eine einfache Lösung? Die Geräte sprechen ja direkt miteinander und dafür kenne ich keine Eingriffsmöglichkeit. Ansonsten müsste ich doch alles auf die Zentrale umstellen. Da könnte ich dann eine entsprechende Programmlogik einrichten, wäre aber darauf angewiesen, dass die Zentrale immer läuft.

Zitat
Ich habe nur einen Fenstersensor im Einsatz, und damit bisher keine Probleme gehabt...
Ich habe ca. 10 Fensterkontakte. 1 x Drehgriff, der Rest normale HM-SEC-SC-2. Das Ganze seit ca 18 Monaten. Die beschriebenen Störungen habe ich aber erst seit ca. 3 – 4 Wochen. Änderungen in dem Bereich habe ich schon lange nicht mehr gemacht. Das Schlimme ist ja, dass der Fehler nicht bewusst reproduzierbar ist.

Zitat
fw-update auf v1.3
Steht auf meiner ToDo-Liste. Glauben tue ich es weniger, da ja bis auf die letzten Wochen alles funktioniert hat.

Schön wäre es, wenn es eine Funktion ähnlich hm configCheck gäbe, die Inkonsistenten aufzeigt (in meinem Fall: Fensterkontakt sagt: closed, Wandthermostat sagt: open). Dann könnte ich mir zumindest eine Meldung zuschicken und frühzeitig reagieren. Leider verstehe ich regex aber viel zu wenig, um so etwas umsetzen zu können.

LG
Holger
NUC6i3SYH (FHEM 5.8 in VM)
Homematic: HMLAN, HMUSB, HM-Sec-SD, HM-CC-RT-DN, HM-TC-IT, ... + diverse weitere
LaCrosseGateway, ESPEasy
ZWave

MarcelK

Zitat von: viegener am 02 Januar 2016, 13:37:12
Du könntest mal versuchen die Anzahl der Sendeversuche über das Attribut msgRepeat zu erhöhen. Meine Fenstersensoren unterstützen das.

"msgRepeat" ist nur für die Strecke FHEM->Sensor und selbst das wird laut CommandRef für Config-Geräte (wozu die Fenster-Sensoren gehören) nicht unterstützt. Klar kann man's setzen, das Attribut existiert für alle Devices, aber das ist in diesem Fall nur ein Placebo ;-)

Gruß Marcel

VB90

Versuche doch mal etwas ganz banales und checke mal die Batteriespannung an einem "fehlerhaften" SC.
Gedenk der Tatsache das es schon tadellos funktioniert hat, reicht vielleicht der Einsatz von neuen Batterien.

vb
Man muss das Rad nicht neu erfinden, nur wissen wie es gedreht wird.

frank

ZitatWenn man nur kurz etwas auf die Terasse stellt  ;). Gibt es dafür eine einfache Lösung? Die Geräte sprechen ja direkt miteinander und dafür kenne ich keine Eingriffsmöglichkeit. Ansonsten müsste ich doch alles auf die Zentrale umstellen. Da könnte ich dann eine entsprechende Programmlogik einrichten, wäre aber darauf angewiesen, dass die Zentrale immer läuft.
schon mal mit dem register eventDlyTime am fk gespielt? wenn zb 60 sek gesetzt sind, kommt die entsprechende meldung erst, wenn der geänderte zustand nach dieser zeit immer noch gilt. öffnen und wieder schliessen innerhalb von 60sek ergibt dann keine meldungen.

über die zentrale laufen lassen, kann auch vorteile haben, wie man sieht.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Omega

Super. eventDlyTime kannte ich bisher nur mit der Empfehlung, dass auf 3 Sek. zu setzen um Kommunikationsstörungen vorzubeugen. Gleich mal umgesetzt.  :D
Alle Wandthermostate sind jetzt auf 1.3, Batterie ist ok. Dann werde ich gleich mal ein Update anstoßen, um wieder ganz aktuell zu sein.

LG
Holger
NUC6i3SYH (FHEM 5.8 in VM)
Homematic: HMLAN, HMUSB, HM-Sec-SD, HM-CC-RT-DN, HM-TC-IT, ... + diverse weitere
LaCrosseGateway, ESPEasy
ZWave

MarcelK

Zitat von: Omega am 02 Januar 2016, 16:09:00
Super. eventDlyTime kannte ich bisher nur mit der Empfehlung, dass auf 3 Sek. zu setzen um Kommunikationsstörungen vorzubeugen. Gleich mal umgesetzt.  :D

Die 3 Sekunden waren glaub beim RHS empfohlen weil man zur "kippen" Stellung nur über die "öffnen" Stellung kommt und so unnötig gefunkt wird wenn man das Fenster eigentlich kippen will.