Roto_ZEL-STG-RM-FFK quittiert rot mit HMUARTLGW

[rolf]

Habe bisher zwei Raspberrys mit HM-CFG-USB-2-Sticks als HMLANDs im Haus eingesetzt - verteilt auf zwei Stockwerke. Habe jetzt mal den ersten davon durch einen Raspberry mit HM-MOD-UART und externer Antenne ersetzt - angebunden an FHEM per Socat. Umstellung funktionierte problemlos - RSSI-Werte und auch Schaltzeiten hab sich verbessert.
Ein Problem jedoch habe ich jetzt festgestellt - habe mehrere Fenstersensoren vom Typ Roto_ZEL-STG-RM-FFK im Einsatz - im Prinzip OEM-Devices von Roto auf Basis von HM-Sec-SC.
Diese Fenstersensoren kommunzieren zwar sauber mit FHEM - beim Oeffnen/Schliessen jedoch quittiert der Fenstersensor mit roter Anzeige wenn er vom HMUARGLGW bedient wird - trage
ich den Fenstersensor eine Stock tiefer und er wird vom "alten" HM-CFG-USB-2-Stick bedient, dann quittiert der Fenstersensor mit gruen.

List des Fenstersensors:

Code Auswählen Erweitern


Internals:
   CFGFN      /opt/fhem/FHEM/OGFenstersensoren.cfg
   DEF        1A189D
   EGhmlan_MSGCNT 112
   EGhmlan_RAWMSG E1A189D,0000,35CEF3E1,FF,FFB6,14A4411A189D257488011300
   EGhmlan_RSSI -74
   EGhmlan_TIME 2017-12-06 08:24:08
   IODev      OGhmlan
   LASTInputDev EGhmlan
   MSGCNT     227
   NAME       OG_Schlafzimmer_Fenster_Links
   NOTIFYDEV  global
   NR         2786
   NTFY_ORDER 50-OG_Schlafzimmer_Fenster_Links
   OGhmlan_MSGCNT 115
   OGhmlan_RAWMSG 0501012C14A4411A189D257488011300
   OGhmlan_RSSI -44
   OGhmlan_TIME 2017-12-06 08:24:08
   STATE      closed
   TYPE       CUL_HM
   lastMsg    No:14 - t:41 s:1A189D d:257488 011300
   protEvt_AESCom-ok 4 last_at:2017-12-06 05:49:46
   protLastRcv 2017-12-06 08:24:08
   protResnd  3 last_at:2017-12-06 05:50:14
   protSnd    121 last_at:2017-12-06 08:24:08
   protState  CMDs_done
   rssi_at_EGhmlan lst:-74 max:-56 min:-86 avg:-66.99 cnt:112
   rssi_at_OGhmlan min:-80 cnt:107 avg:-57.59 lst:-44 max:-36
   READINGS:
     2017-12-06 05:52:09   Activity        alive
     2017-12-06 05:51:58   CommandAccepted yes
     2017-12-06 05:52:09   D-firmware      2.0
     2017-12-06 05:52:09   D-serialNr      JRT0004452
     2017-12-06 05:52:10   PairedTo        0x123456
     2017-12-06 05:52:10   R-cyclicInfoMsg on
     2017-12-06 05:51:14   R-eventDlyTime  0 s
     2017-12-06 05:51:14   R-ledOnTime     0.5 s
     2017-12-06 05:51:14   R-msgScPosA     closed
     2017-12-06 05:51:14   R-msgScPosB     open
     2017-12-06 05:51:14   R-pairCentral   0x123456
     2017-12-06 05:51:14   R-sabotageMsg   on
     2017-12-06 05:51:14   R-sign          off
     2017-12-06 05:51:14   R-transmDevTryMax 6
     2017-12-06 05:51:14   R-transmitTryMax 6
     2017-12-06 05:52:10   RegL_00.          02:01 09:01 0A:25 0B:74 0C:88 10:01 14:06 00:00
     2017-12-06 05:52:11   RegL_01.          08:00 20:60 21:00 22:64 30:06 00:00
     2017-12-06 05:52:56   alive           yes
     2017-12-06 08:24:08   battery         ok
     2017-12-06 08:24:08   contact         closed (to vccu)
     2017-12-06 05:52:56   recentStateType info
     2017-12-06 05:52:56   sabotageError   off
     2017-12-06 08:24:08   state           closed
     2017-12-06 08:24:08   trigger_cnt     19
   helper:
     HM_CMDNR   20
     PONtest    0
     cSnd       012574881A189D01040000000001,012574881A189D0103
     mId        0082
     peerIDsRaw ,00000000
     rxType     12
     supp_Pair_Rep 0
     tmplChg    0
     ack:
     expert:
       def        1
       det        1
       raw        1
       tpl        0
     io:
       newChn     +1A189D,00,01,00
       nextSend   1512545048.56893
       rxt        2
       vccu       vccu
       p:
         1A189D
         00
         01
         00
       prefIO:
         OGhmlan
     mRssi:
       mNo        14
       io:
         EGhmlan    -74
         OGhmlan    -42
     prt:
       bErr       0
       sProc      0
       sleeping   1
       try        1
       rspWait:
     q:
       qReqConf
       qReqStat
     role:
       chn        1
       dev        1
     rpt:
       IO         OGhmlan
       flg        A
       ts         1512545048.38796
       ack:
         HASH(0x66ae6f0)
         1480022574881A189D0101C800
     rssi:
       at_EGhmlan:
         avg        -66.9910714285714
         cnt        112
         lst        -74
         max        -56
         min        -86
       at_OGhmlan:
         avg        -57.5981308411215
         cnt        107
         lst        -44
         max        -36
         min        -80
     shadowReg:
     tmpl:
Attributes:
   IODev      OGhmlan
   IOgrp      vccu:OGhmlan
   actCycle   028:00
   actStatus  alive
   alarmDevice Sensor
   alarmSettings alarm4,alarm6,|OG_Schlafzimmer_Fenster_Links:open|OG_Schlafzimmer_Fenster_Links|on
   autoReadReg 3_onChange
   devStateIcon open:fts_window_1w_open@red  closed:fts_window_1w@green
   event-on-change-reading state
   expert     3_allReg+raw
   firmware   2.0
   group      Fenster
   icon       fts_window_1w
   model      Roto_ZEL-STG-RM-FFK
   peerIDs    00000000,
   room       OGSchlafzimmer
   serialNr   JRT0004452
   subType    threeStateSensor
   userattr   room_map structexclude


Habe mal per attr model HM-SEC-SC eingetragen - brachte aber leider keine Veränderung.

Wer kann helfen ? - danke vorab !

[rolf]

Nachdem ich jetzt auch meinen zweiten HMLAND-Sender im Haus auf HMUART umgestellt habe, ist das Phaenomen verschwunden - d.h. die Roto_ZEL-STG-RM-FFK Sensoren quittieren wieder mit gruener LED. Problem also hat sich von selbst gelöst.