HM-SEC-SD-2 neu

Begonnen von martinp876, 21 März 2015, 17:28:26

Vorheriges Thema - Nächstes Thema

elmer

Im Log habe ich zuerst nachgesehen, aber da war nichts zu sehen.

Im Team Leader gibt es nur einen Eintrag der von der Zeit passt: trigger_cnt 2

Sagt dieser Eintrag etwas aus, welcher Melder es war?

CoolTux

Zeig doch mal ein list vom Teamleader. Bei mir steht sowas wie

recentAlarm als Reading. Habe aber auch keine Lust hier zu raten was du genau hast.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

elmer

Internals:
   CUL_0_MSGCNT 1
   CUL_0_RAWMSG A0E01A6104937FA7319730601000023::-60:CUL_0
   CUL_0_RSSI -60
   CUL_0_TIME 2017-12-10 12:42:20
   DEF        4937FA
   IODev      meinLGW
   LASTInputDev meinLGW
   MSGCNT     2
   NAME       HM_4937FA
   NOTIFYDEV  global
   NR         288
   NTFY_ORDER 50-HM_4937FA
   STATE      off
   TESTNR     1
   TYPE       CUL_HM
   lastMsg    No:01 - t:10 s:4937FA d:731973 0601000023
   meinLGW_MSGCNT 1
   meinLGW_RAWMSG 0501002701A6104937FA7319730601000023
   meinLGW_RSSI -39
   meinLGW_TIME 2017-12-10 12:42:20
   peerList   self01,
   protCmdDel 1
   protLastRcv 2017-12-10 12:42:20
   protResnd  1 last_at:2017-12-10 12:42:13
   protResndFail 1 last_at:2017-12-10 12:42:19
   protSnd    2 last_at:2017-12-10 12:42:20
   protState  CMDs_done
   rssi_at_CUL_0 min:-60 lst:-60 max:-60 avg:-60 cnt:1
   rssi_at_meinLGW lst:-39 min:-39 avg:-39 cnt:1 max:-39
   rssi_meinLGW lst:-35 min:-35 max:-35 cnt:1 avg:-35
   sdTeam     sdLead
   READINGS:
     2017-06-29 18:35:04   .D-devInfo      000100
     2017-06-29 18:35:04   .D-stc          CE
     2017-06-29 18:35:14   .R-devRepeatCntMax 0
     2017-10-21 16:35:53   .peerListRDate  2017-10-21 16:35:53
     2017-12-10 12:42:20   .protLastRcv    2017-12-10 12:42:20
     2017-12-10 12:40:58   Activity        alive
     2017-06-30 17:38:20   CommandAccepted yes
     2017-06-29 18:35:04   D-firmware      1.0
     2017-06-29 18:35:04   D-serialNr      NBO0016402
     2017-10-21 16:35:53   PairedTo        0x731973
     2017-06-29 18:35:14   R-pairCentral   0x731973
     2017-10-21 16:35:53   RegL_00.        02:01 0A:73 0B:19 0C:73 16:00 1F:00 00:00
     2017-07-01 14:22:18   aesCBCCounter   0000FC
     2017-06-30 17:38:20   aesCommToDev    ok
     2017-06-30 17:38:20   aesKeyNbr       02
     2017-12-10 12:42:20   alarmTest       ok
     2017-12-10 12:42:20   battery         ok
     2017-12-10 12:42:20   eventNo         01
     2017-12-10 12:42:20   level           0
     2017-12-10 12:40:58   peerList        self01,
     2017-10-24 23:50:25   powerOn         2017-10-24 23:50:25
     2017-12-10 12:42:20   recentStateType info
     2017-10-21 16:35:53   sdRepeat        off
     2017-12-10 12:42:20   smokeChamber    ok
     2017-12-10 12:42:20   smoke_detect    none
     2017-12-10 12:42:20   state           off
     2017-07-01 11:11:12   teamCall        from VCCU:05
     2017-12-10 10:36:06   trigger_cnt     2
   helper:
     HM_CMDNR   1
     cSnd       ,017319734937FA010E
     fkt        sdLead2
     mId        00AA
     rxType     6
     supp_Pair_Rep 0
     ack:
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +4937FA,00,01,00
       nextSend   1512906141.24551
       rxt        0
       vccu       VCCU
       p:
         4937FA
         00
         01
         00
       prefIO:
         meinLGW
     mRssi:
       mNo        01
       io:
         CUL_0      -60
         meinLGW    -37
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
     rpt:
       IO         CUL_0
       flg        A
       ts         1512906140.92009
       ack:
         HASH(0x40108e8)
         0180027319734937FA00
     rssi:
       at_CUL_0:
         avg        -60
         cnt        1
         lst        -60
         max        -60
         min        -60
       at_meinLGW:
         avg        -39
         cnt        1
         lst        -39
         max        -39
         min        -39
       meinLGW:
         avg        -35
         cnt        1
         lst        -35
         max        -35
         min        -35
     tmpl:
Attributes:
   IODev      meinLGW
   IOgrp      VCCU:meinLGW
   actCycle   099:00
   actStatus  alive
   alias      Rauchmelder Flur
   autoReadReg 4_reqStatus
   devStateIcon .*off:secur_smoke_detector@green .*on:secur_smoke_detector@red
   event-on-change-reading .*
   expert     2_raw
   firmware   1.0
   fp_Wohnung 211,1328,1,Flur,
   model      HM-SEC-SD-2
   msgRepeat  1
   peerIDs    00000000,4937FA01,
   room       System Geräte
   serialNr   NBO0016402
   subType    smokeDetector

CoolTux

Ich sehe da nur einen Rauchmelder der mit sich selbst gepeert ist und somit Teamleader. Mitglieder im Team sehe ich keine weiteren.

Deine Frage kann ich leider nicht beantworten.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

elmer

Hab ich mir schon gedacht das ich das damals beim einrichten nicht richtig gemacht habe, bei allen anderen Rauchmeldern steht bei peer list der HM_4937FA drin.

Nur beim eigentlichen TeamLeader steht self1, keine Ahnung wieso, im Erdgeschoss wurde einmal durch starke Rauchentwicklung beim Kochen Alarm ausgelöst und der TeamLeader ist im ersten Stock.

Obwohl im TeamLeader self1 steht kam sofort per Pushover die Meldung das die Feuermelder Alarm ausgelöst haben.

Otto123

Moin,

für erfolgreiches peering muss in beiden Geräten der jeweils andere als Peer drin stehen.
hmInfo configCheck hilft relativ einfach solche Fehler aufzuspüren.

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

elmer

Ok, bei config Check bekomme ich nichts angezeigt, wenn ich aber peerXref mache bekomme ich folgendes angezeigt.

peerXref done:
x-ref list
    HM_4711B0 => HM_4937FA
    HM_4937FA => self01
    HM_4937FD => HM_4937FA
    HM_493885 => HM_4937FA
   

Otto123

Und so sollte das bei Rauchmeldern richtig aussehen.
Meine Umgebung:
    Rauchmelder_Team => RmAZ RmFlur RmSZ
    RmAZ => Rauchmelder_Team
    RmFlur => Rauchmelder_Team
    RmSZ => Rauchmelder_Team


Dein list bedeutet: Kein Fehler ( hatte configCheck gemeldet)
xref:
Du hast einfach nur einseitig gepeert.  Du hast  nur den Team mit sich gepeert, die anderen zwar mit dem Team aber den Team nicht mit den anderen.

Gruß Otto

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Christian Uhlmann

Ich glaube es ist noch anders. Wieviele RM hast du? 3 oder 4? Was ist HM_4937FA für ein Gerät, ist das ein RM oder ein virtueller Teamlead? Wenn es ein RM ist, dann ist da in FHEM nicht viel mit Steuerung, außer halt die Events die du mitbekommst.
Host: Debian Buster als VM / XCP-NG
Gateways: DuoFern Stick, CUL433 Revolt, CUL MAX, HMLan, HM-USB 2, LaCrosseGateway
Devices: 12x Rademacher Rollos, 6x TX 29 DT-HT, 10x HM-CC-RT-DN, 14x MAX Fensterkontakte, Diverse HM Aktoren für Licht, Klingel, Gong, Eingangstür, ESPEasy, Sonoff mit Tasmota

Otto123

Es ist ein Rauchmelder als Teamleader. Ein virtueller hätte eine 8 stellige HMID.

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

automatisierer

Das ist einfach nur das ganz normale aneinander anlernen ohne FHEM. So steht es in der Bedienungsanleitung.

Zitat6.1.1
Funk-Rauchwarnmelder aneinander anlernen
Die ersten beiden Rauchwarnmelder im System definieren eine Gruppenadresse.
Jeder weitere Rauchwarnmelder kann an einen beliebigen
bereits im System befindlichen Rauchwarnmelder angelernt werden und
erhält automatisch die vorab definierte Gruppenadresse.

Das Auswerten eines Alarms sollte ja kein Problem sein, nur steuern (alarm_off oder ähnlich) geht nicht.


M_I_B

... kleiner Zwischenwurf / Bericht:

Der Erste der drei RM ist inzwischen gestorben... Der meldet zwar noch Rauch (testet meine Frau gelegentlich bei Ofen anmachen ^^), ansonsten aber ist der aus Sicht von FHEM tot...
Von jetzt auf gleich steht das Ding auf MISSING ACK und ist nicht mehr zur Zusammenarbeit zu bewegen, auch nicht durch Ausschalten, eine Nacht liegen lassen und Einschalten, auch nicht durch neues Anlernen und andere Sachen, die man so versucht...

Manchmal kommt er zurück direkt nach dem Einschalten, aber bereits ein getConfig scheitert mit MISSING ACK oder RESPONSE TIMEOUT:RegisterRead. Sieht dann z.B. wie u.s. aus...

Jemand eine Idee, ob man den noch retten kann oder Tonne?!?

Internals:
   .triggerUsed 1
   CFGFN      /opt/fhem/_HW/HM.sensoren.cfg
   DEF        48F213
   IODev      SCC2
   LASTInputDev SCC2
   MSGCNT     18
   NAME       HM1RM2
   NOTIFYDEV  global
   NR         65
   NTFY_ORDER 50-HM1RM2
   SCC2_MSGCNT 11
   SCC2_RAWMSG A1301144148F21348F2130101960000061F6B73F9::-64.5:SCC2
   SCC2_RSSI  -64.5
   SCC2_TIME  2017-12-16 18:00:38
   STATE      RESPONSE TIMEOUT:RegisterRead
   TYPE       CUL_HM
   UFO1_MSGCNT 7
   UFO1_RAWMSG E48F213,0000,001CF638,FF,FF98,01144148F21348F2130101960000061F6B73F9
   UFO1_RSSI  -104
   UFO1_TIME  2017-12-16 18:00:38
   lastMsg    No:01 - t:41 s:48F213 d:48F213 0101960000061F6B73F9
   peerList   Team_RM,
   protCmdDel 5
   protLastRcv 2017-12-16 18:00:38
   protResnd  6 last_at:2017-12-16 18:00:34
   protResndFail 3 last_at:2017-12-16 18:00:40
   protSnd    3 last_at:2017-12-16 18:00:24
   protState  CMDs_done_Errors:1
   rssi_at_SCC2 min:-68.5 max:-53.5 cnt:8 lst:-64.5 avg:-62.62
   rssi_at_UFO1 cnt:5 lst:-104 avg:-99 min:-104 max:-96
   READINGS:
     2017-12-16 18:00:33   .D-devInfo      000100
     2017-12-16 18:00:33   .D-stc          CE
     2017-12-16 18:00:38   .protLastRcv    2017-12-16 18:00:38
     2017-12-16 18:00:33   Activity        alive
     2017-12-16 18:00:33   D-firmware      1.0
     2017-12-16 18:00:33   D-serialNr      NEQ0244324
     2017-12-16 17:55:28   alarmTest       ok
     2017-12-16 17:55:28   battery         ok
     2017-12-16 17:55:28   level           0
     2017-12-16 17:55:28   powerOn         2017-12-16 17:55:28
     2017-12-16 17:55:28   recentStateType info
     2017-12-16 17:55:28   smokeChamber    ok
     2017-12-16 18:00:40   state           RESPONSE TIMEOUT:RegisterRead
     2017-12-16 18:00:35   trigger_cnt     1
     RegL_00.:
       VAL       
   helper:
     HM_CMDNR   1
     PONtest    1
     cSnd       01F1000048F213010E,01F1000048F21300040000000000
     getCfgListNo
     mId        00AA
     rxType     6
     supp_Pair_Rep 0
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +48F213,00,00,00
       nextSend   1513443638.98199
       rxt        0
       vccu       VCCU
       p:
         48F213
         00
         00
         00
     mRssi:
       mNo        01
       io:
         SCC2       -62.5
         UFO1       -104
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
     rssi:
       at_SCC2:
         avg        -62.625
         cnt        8
         lst        -64.5
         max        -53.5
         min        -68.5
       at_UFO1:
         avg        -99
         cnt        5
         lst        -104
         max        -96
         min        -104
     tmpl:
Attributes:
   IODev      UFO1
   IOgrp      VCCU
   actCycle   099:00
   actStatus  alive
   alias      Rauchmelder
   autoReadReg 4_reqStatus
   devStateIcon off:secur_smoke_detector@gray on:secur_smoke_detector@red smoke-Alarm.*:secur_smoke_detector@red
   expert     2_raw
   firmware   1.0
   group      _90 HW - HM.RM
   model      HM-SEC-SD-2
   msgRepeat  2
   peerIDs    00000000,00001101,
   room       311 - Wohnzimmer,313 - Esszimmer
   serialNr   NEQ0244324
   subType    smokeDetector
   webCmd     :

pc1246

Moin Micha
Wieso Tonne, der ist doch noch gar nicht so alt. Und eq3 kann ruhig mal bluten!
Gruss Christoph
HP T610
Onkyo_AVR;3 Enigma2; SB_Server ; SB_Player; HM-USB mit 15 HM-CC-RT-DN, 3 HM_WDS10_TH_O, 6 HM-Sec-SCo, 4 HM-Sec-MDIR-2, 1 HM-Sen-MDIR-O-2, 8 Ferion 5000 OW ; PhilipsTV; 4 harmony hub; Jeelink mit 9 PCA301; Somfy; S7-300; 3 LGW; HUE; HM-IP auf Charly

Otto123

#598
Hi Micha,

das Verhalten, was Du beschreibst ist eigentlich zu erwarten. Der ist nicht tot, der ist nur nicht gepairt.
Also pairen und er sollte auf Deine Befehle reagieren.  ;)

Beim Einschalten werden einige Readings aktualisiert, das ist typisches Verhalten.

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

M_I_B

@Christoph:
Ne, eine Rückgabe geht nicht. Die sind modifiziert (Schalter-MOD) und somit raus aus der Garantie. Zudem bin ich seit einiger Zeit kein Kunde mehr bei ELV/eQ3 und will mit dem Laden auch nichts mehr zu tun haben; die haben mich ein mal zu oft verar***t...

@Otto:
Doch, die waren und sind gepairt. Gestern Nacht noch alle mehrfach auf Werkszustand gesetzt, neu gepairt und einem Leader zugewiesen. Das hat auch nach unzähligen Versuchen nur teilweise geklappt. Z.B. war es nicht möglich, alle RM dem Leader zuzuweisen, oder aber auch ein "getConfig" scheitert mit den genannten Problemen... Mal der eine, mal der andere, mal mehrere... Dann mal wieder "ohhh, alle sauber gepairt!" und dann funktionieren die Zuweisungen an den Leadre nicht oder nur teilweise... Und das kann keinesfalls ein Reichweitenproblemen sein, denn umzu -50dbi ist ein einwandfreier Wert...

Also egal wie man das sieht... Ich für meine Teil habe die in die Gruppe des üblichen eQ3- Murkses eingeordnet und werde mich im neuen Jahr nach einer Alternative umschauen. Die sind mir einfach viel zu unzuverlässig... und gerade auf sicherheitstechnische Einrichtungen sollte man sich verlassen können...