Rauchmelder RESPONSE TIMEOUT:RegisterRead

[Muff Potter 24]

- welches IODev ist beim SD in Internals und im Attr eingetragen? Bei beiden CCD
- Welche HMId ist beim IO eingetragen das beim SD als IO eingetragen ist? Beim RM finde ich HM_CMDNR 1 und mId 0042
und mit list CCD:

Code Auswählen Erweitern

Internals:
   CCD_MSGCNT 3
   CCD_TIME   2016-11-16 19:31:51
   CMDS       mCFiAZGMRTVWXefltux
   Clients    :CUL_HM:HMS:CUL_IR:STACKABLE_CC:
   DEF        /dev/ttyAMA0@38400 1234
   DeviceName /dev/ttyAMA0@38400
   FD         11
   FHTID      1234
   NAME       CCD
   NR         43
   NR_CMD_LAST_H 5
   PARTIAL
   RAWMSG     A0D00A41032CAC2F1123406010000F9
   RSSI       -77.5
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.57 CSM868
   initString X21
Ar
   Matchlist:
     1:CUL_HM   ^A....................
     8:HMS      ^810e04....(1|5|9).a001
     D:CUL_IR   ^I............
     H:STACKABLE_CC ^\*
   Readings:
     2016-11-15 22:35:06   cmds             m C F i A Z G M R T V W X e f l t u x
     2016-11-16 19:31:51   state           Initialized
     2016-11-16 20:56:02   version         V 1.57 CSM868
   XMIT_TIME:
     1479321111.31277
     1479324353.33343
     1479324358.04911
     1479324390.25388
     1479324393.41915
   Helper:
     32cac2:
       QUEUE:
     32cfee:
       QUEUE:
     32d02f:
       QUEUE:
Attributes:
   rfmode     HomeMatic

[Otto123]

Du hast keine HMId eingetragen (attr ccd hmId fehlt). Damit wird F1+FHTID genommen (habe ich vor wenigen Minuten gelernt  )
Also bei dir F11234.

Ob hmInfo damit klar kommt weiß ich nicht.

Gruß Otto

[Muff Potter 24]

Das war ein SUPERTIP....
hminfo meldet zum erstenmal keine Fehler. Das hatte ich noch nie. Vielen Dank dafür. Endlich geht was vorran.

Wie könnte ich nun weiter vorgehen:
Wen ich die Anleitung von Martin richtig verstehe und das peering löse, bekomme ich bei Ausfall von FHEM keinen Feueralarm.
Das möchte ich nicht.
Oder soll ich es wie in der CT´beschrieben mit mehreren notify für jeden einzelnen RM versuchen:

Code Auswählen Erweitern

define RauchmelderAlarm notify EG_Flur_RM.:smoke-Alarm_.* { system ("/usr/local/bmz/bin/set_status $NAME alarm")  }
define RauchmelderBatterie notify EG_Flur_RM.:[Bb]attery:.[^o][^k].* { system ("/usr/local/bmz/bin/set_status $NAME lowbatt") }
define RauchmelderOffline notify EG_Flur_RM.:MISSING.* { system ("/usr/local/bmz/bin/set_status $NAME offline") }
define RauchmelderNAlarm notify EG_Flur_RM.:off.* { system ("/usr/local/bmz/bin/del_status $NAME alarm") }
define RauchmelderNBatterie notify EG_Flur_RM.:[Bb]attery:.ok.* { system ("/usr/local/bmz/bin/del_status $NAME lowbatt") }
define RauchmelderNOffline notify EG_.*_RM.:alive.* { system ("/usr/local/bmz/bin/del_status $NAME offline") }

[Otto123]

genau genommen melden Rauchmelder kein Feuer sondern Rauch. Das ist unabhängig von FHEM - immer! Er gibt Signal bei Rauch, ansonsten ist er kaputt und nicht FHEM.
Du hast aktuell die Melder untereinander gepeert? Dann melden die alle Alarm wenn einer Rauch ermittelt. Den Status melden alle Melder an FHEM, eventuell ist die Meldung unterschiedlich, das weiß ich nicht genau. Immerhin hat ja einer Rauch und die anderen machen nur mit. Es würde ein notify reichen um ein Mail zu schicken, wie sinnvoll das ist? Man kann bei allen mit einem notify den Batteriestatus abfragen. Wie das geht steht im Wiki.
Der virtuelle Teamlead hat folgenden Vorteil, steht im Wiki!

Nutzt man nur einen einzelnen SD, kann/sollte man diesen mit sich selbst teamen (peerChan). In allen andere Fällen braucht man einen TeamLead um eine team-ID zu erhalten. Man kann hierzu einen der SDs nutzen. Wird dieser einmal ausgewechselt, hat man allerdings seine team-ID verloren.
Wenn man mit Zentrale (FHEM) arbeitet, gibt es eigentlich keinen vernünftigen Grund (ausser 1-SD-Teams), einen der SDs als lead zu nutzen. Man kann genauso gut einen virtuellen Aktor bauen und diesen zum Lead machen. Das ergibt eine sauberere Struktur.

Also was willst Du? Warum betreibst Du den ganzen Aufwand? Jetzt sag ich es nochmal anders: Lass es so, alles ist gut. Oder wenn Du willst mach es so wie im Wiki.

Gruß Otto

[Muff Potter 24]

Was ich möchte habe ich schon mehrmals geschrieben:
Ich habe meine 10 RM gepeert damit ich z.B. bei einem Brand in der Garage und gleichzeitigem Stromausfall auch ohne FHEM gewarnt werde.
Ich möchte/ habe die RM mit FHEM gepairt um die Systemzustände der RM überwachen zu können und eine Email bei Änderungen (Rauch, Melder nicht erreichbar usw.) zu bekommen. Bei Abwesenheit und Feueralarm - Email kann ich meine im Haus verbauten Kameras abfragen und sehen ob es wirklich brennt.

Wenn ich das Wiki richtig verstanden habe brauche ich den virt. teamlead um eine mail verschicken zu können. Den virt. Teamlead kann ich aber nur einrichten, wenn ich das zuvor durchgeführte peering löse. Und ab hier beisst sich die Katze in den Schwanz. Ich kann das eine nicht tun ohne das andere zu lassen. Und da wollte ich nur wissen ob ich das richtig verstanden habe. Das ist alles....
Nichts für ungut....

Muff

[Otto123]

Du liest immer nicht richtig, oder hast eine Art negativen Wunschlesemodus aktiv:
Zitat Wiki

Alarme
Meldet ein SD einen Alarm, wird dieser in dem SD und im TeamLead angezeigt.
Nutzt man HMinfo, wird ein Rauchalarm auch hier als "Error" gemeldet. In HMinfo wird dies für alle SD-teams im System gemacht.
Nützliche Notifies
Codefragmente, die man einsetzen kann. Ggf. muss man etwas anpassen, zumindest können sie als Anregung nützlich sein.
Bei Alarm email schicken und Licht im Flur anschalten

Wo steht da was vom virtuellen Teamlead? Da steht nur Teamlead - und Du hast doch Einen! Frage den ab und alles ist gut!
Baue das notify aus dem Wiki ein und erzeuge an einem x-beliebigen RM einen Rauchalarm und Du wirst sehen das es funktioniert!

Gruß Otto

[Muff Potter 24]

Nach stundenlangem Lesen habe ich da wohl einiges durcheinander gebracht. Jetzt nochmal gelesen und so hoffe, ich auch verstanden.  Danke das du mich in die richtige Richtung gebracht hast. Ich werde es in den nächsten Tagen umsetzen und mich dann nochmal melden.
Vielen dank nochmal
Muff