Rauchmelder

[Kruemel]

Hallo allerseits,
ich bin einen Schritt weiter.

Mit dem notify....

define Feueralarm_Mail2 notify RM1:smoke-Alarm { FB_mail('meine@@mail.de' (@@mail.de'),'Feueralarm: '. ReadingsVal("RM1","smoke_detect",""),'Rauchmelder ausgelöst') }
attr Feueralarm_Mail2 room System

bekomme ich jetzt Mails, mit den Namen der Rauchmelder, die den Rauch gemeldet haben.

Jetzt habe ich die Frage:
- wie setzt man nach dem Testen mit Rauch die Rauchmelder wieder zurück?

Der RM der den Rauch gemeldet hat steht auf state = off
Der Master RM, steht auf state = smoke-Alarm, und smoke_detect = RMx,....

Ich habe mal ein set StatusRequest auf beide probiert. Das state = off ging weg.
Der Master steht zur Zeit immer Missing Ack.
Ich habe hier mal ein set reset RM1 gemacht. Hat das irgendetwas kaputt gemacht?
Habe bisher nichts gefunden was den Befehl erklärt.


Hat jemand eine Idee?

Liebe Grüße

Wolfgang

[martinp876]

Hallo Wolfgang,

einen reset erklären traue ich mich nicht. Bei Aktoren werden alle channel-register rückgesetzt und die peers gelöscht. Ob das pairing erhalten bleibt kann ich nicht sagen.
Ich erwarte, dass der reset equivalent dem reset am Device ist. Beschreibung obliegt HM, FHEM sendet es nur.

Ich erwarte ferner, dass bei deinem device die peers gelöscht sind, er also nicht mehr team-mitglied ist. Das kannst du aber durch lesen der Config klären - alle team-member müssen den gleichen peer haben.

Das state = off ging weg.

was heisst das? wohin? state ist immer da, welchen wert hat es den angenommen?

Ist der master schon mitglied seines teams?

Gruss Martin

[Kruemel]

Hallo Martin,

fuer mich als Laie sieht es aus, als wenn das peering noch vorhanden ist.
Ich habe drei Dateien mit aktuellen Screenshots der drei Rauchmelder beigelegt.
RM1 ist der Master und mit sich selbst gepeert (peerList ... self01,). RM2 und RM2 jeweils mit RM1 (peerList..... RM1_chn:01,).

RM1 reagiert für mich auch als Master und meldet den von RM1, RM2 oder RM3 erfassten Rauch weiter.
(smoke_detect .... RM3,RM3,RM3,RM2,RM2,RM2,RM2,RM2,RM2,)

Durch das "Missing Ack" an RM1 ist mit bisher keine funktionale Einschränkung aufgefallen.

Zur Zeit werte den Rauchalarm mit dem folgenden Eintrage aus:

define Feueralarm notify RM1:smoke-Alarm { FB_mail('meine@@mail.de' (@@mail.de'),'FHEM-Feueralarm: '. ReadingsVal("RM1","smoke_detect",""),'Rauchmelder ausgelöst') }

Dafür müsste natürlich nach einem Test mit Rauch der Inhalt von RM1:smoke_detect auf none zurückgesetzt werden.
Sonst schickt das notify fleissig weiter Mails.

Der Rauchmeldende RM steht nach Rauchmeldung auf state = "off", und muss ebenfalls in einen neutralen Zustand zurückgesetzt werden.
Dies habe ich durch "set RMx StatusRequest" geschafft.

Mein Problem ist zur Zeit das Missing Ack an RM1 und das ich nicht weiss, wie man einem Test mit Rauch, den RM1 bzw. smoke-detect wieder zurücksetzt.

Vielen Dank für Deine Hilfe.

Wolfgang

[martinp876]

hallo Wolfgang,

nebenbei: ob der RM1 wirklich weitermeldet zweifle ich an. Fakt ist, dass die RMs mit der team-id (also der des 'master') senden. Das sieht dann so aus, ist aber nicht so. Der Master weiss nicht, dass er master ist. Es wird einzig seine id zum senden verwendet.

daher würde ich immer einen virtuellen Aktor zum Master machen. Man hat dann eine saubere trennung zwischen "group" und meldern. (Muss man aber nicht so machen)

zum Problem: der state sollte natürlich immer korrekt sein. du sprichst mehrere szenarien an:

1) missing-ack: ist dass noch so? bei welchen Kommando? nur bei RM1 oder auch bei anderen?
2) state:
a) wie löst du den Alarm/test aus?
b) was verstehst du unter "nach dem test"? Also wie beendest du den test? commando, RM taste,...?
c) der "quell-rm" setzt sich nicht selbst zurück, kann aber über statusRequest aktuallisiert werden

Mache bitte eine Beschreibung der Abläufe mit den detail wie oben nachgefragt - damit ich es auch verstehe.
ggf ist ein mitschnitt der rohmessages hilfreich - damit evtl. verbesserungen eingebaut werden können

Gruss Martin

[Kruemel]

Hallo Martin,

danke für deiner Rückmeldung.

1) missing-ack: ist dass noch so? bei welchen Kommando? nur bei RM1 oder auch bei anderen?
- ja ist noch so, hat nur der RM1
- u.a.bei set StatusRequest, set getConfig

2) state:
a) wie löst du den Alarm/test aus?
- mit Rauch

b) was verstehst du unter "nach dem test"? Also wie beendest du den test? commando, RM taste,...?
- ich habe den auslösenden RM (quell-rm gefällt mir) mit Rauch beaufschlagt und piepen lassen, bis die
  anderen beiden RM auch anfingen zu piepen. Dann habe am quell-rm mit der Taste quittiert und den quell-rm
  damit beruhigt. Mit einem Versatz
  von einigen Sek. hörten die anderen dann auch auf.
- danach ist bei RM1 die Variable? smoke_detector nicht mehr auf none, sondern enthält den Namen des
  quell-rm, ggf. mehrfach, je nach dem wie lange der quell-rm den Rauch angezeigt hat.
- hier die Frage: wie wird smoke_detector wieder zu "none"?

c) der "quell-rm" setzt sich nicht selbst zurück, kann aber über statusRequest aktuallisiert werden
- ja, das habe ich auch festgestellt. Der quell-rm steht nachdem er den Rauch detektiert hat auf state=off.
  Dieses kann man mit set quell-rm StatusRequest auf alive zurücksetzen.

Einen virtuellen Aktor habe ich versucht einzurichten. Hat aber bisher nicht geklappt.
Vlt. kannst du mir ja hierbei helfen.

Wenn du zur Beurteilung rohmessages braucht, bitte ich um eine Tipp wie ich diese erstellen soll. Für mich ist fhem noch ziemlich neu. Ich finde es aber sehr interessant.

Gruß

Wolfgang

[martinp876]

Hallo Wolfgang,

- der quell-rm steht nach dem test auf 'off'? Das ist für mich ok
- doppelmeldungen werden ab der nächsten Version verschwinden, schon in SVN
- kann es sein, dass der Alarm im RM1 nicht auf off gegangen ist, weil noch SDs in der Alarm-liste waren? probier eseinmal mit Version 3920
 Gruss Martin

[Kruemel]

Hallo Martin,
wie macht man den Wechsel auf die Version?
Komplettes Update mit Update?

Kann man sich ansehen, welche Version man gerade hat?

Gruss

Wolfgang

[tborgans]

Hallo,

schaust du hier:

http://fhem.de/commandref_DE.html#update

http://fhem.de/commandref_DE.html#fheminfo

Gruß
Thomas

[Kruemel]

Hallo,

danke für die Info.
Was ist mit Version 3920 gemeint.
Mit fheminfo sehe ich aktuell keine ähnlich lautende Angabe.

Gruss
Wolfgang

Fhem info:
  Release  : 5.4
  Branch   : DEVELOPMENT
  OS       : linux
  Arch     : mips-linux
  Perl     : v5.12.2

Defined modules:
  CUL_HM     : 5
  FHEMWEB    : 6
  FileLog    : 6
  HMLAN      : 1
  at         : 1
  autocreate : 1
  notify     : 2
  telnet     : 1

Defined models per module:
  CUL_HM     : HM-SEC-RHS,HM-SEC-SD

Transmitting this information during an update:
  not set (Note: You can change this via the global attribute sendStatistics)

[Kruemel]

Hallo,
ich habe das Update gemacht. fheminfo zeigt für mich keine erkennbare Differenz.
Aber der Actiondetector zeigt jetzt:
status_RM1  unknown 2013-09-17 23:33:02.
Vor dem Update wurde hier für RM1 alive angezeigt.

RM1 ist zeigt weiterhin Missing Ack (siehe unten).
smoke_detect bleibt mit den letzten quell-rm beschrieben.

Activity
   
unknown
   
2013-09-17 23:23:02
Activity:
   
alive
   
2013-09-15 22:55:49
peerList
   
self01,
   
2013-09-17 23:23:02
smoke_detect
   
RM3,RM3,RM3,RM2,RM2,RM2,RM2,RM2,RM2,
   
2013-09-14 17:29:20
smoke_forward
   
none
   
2013-09-14 17:29:20
state
   
MISSING ACK
   
2013-09-17 23:37:19

Was kann ich als nächstes probieren?

Gruß

Wolfgang

[martinp876]

hi,

die version der einzelnen module (files) steht in den ersten Zeilen.
Files kann man aus SVN laden

3920 sollte heute per update bereitstehen
3920 verhindert doppelte Einträge in die Alarmliste - das könnte das Problem schon lösen

deine aktuellen Readings sind sicher noch alt. Wenn es einen neuen Alarm gibt darf kein RM doppelt gemeldet werden.
Besser du machst erst ein
set RM1 clear Readings
FHEM wartet auf ein 'alarm-off' von RM2 und RM3

oder:
probiere erst einmal einen statusrequest für RM2 und RM3

das missing ack ist eine 2. Baustelle. da musst du einmal roh-messages loggen - und dann statusRequest vom RM1 und einem anderen.

Gruss Martin

[Kruemel]

Hallo,

ich weiss nicht was die nächsten Schritten sein sollen.

Wo kann ich prüfen ob ich die 3920 habe? In welcher Datei?
Was heisst SVN?

Wie kann man ro-daten loggen?
.....

Sorry.

Gruß

Wolfgang

[betateilchen]

gib mal in der Befehlszeile vom frontend "version" ein (ohne Anführungszeichen) dann siehst Du für alle Module die Versionsnummer

SVN heißt Subversion und ist ein häufig von Softwareentwicklern genutztes Versionskontrollsystem.

[martinp876]

rohdaten loggen mit
attr global verbose 1
attr global mseclog 1
attr <hmlan> loglevel 1

daten enden im allgemeinen logfile

[Kruemel]

Hallo,

ich will kurzen Zwischenstand geben.
Habe auf die 3920 upgedatet und danach die Rauchmelder neu eingerichtet.
Ich wollte einen Neuanfang machen.
Bin dann wie folgt vorgegangen.

1. in FHEM Verbindung zu HM-LAN-CFG beendet
2. Alle Geräte aus HM-LAN-CFG entfernt, alle Geräte auf Werkseinstellungen zurückgesetzt
3. Alle Geräte in HM-LAN-CFG neu eingerichtet, die Rauchmelder werden jeweils als Gerät und als eigene Rauchmeldergruppe angelegt.
4. Die Rauchmeldergruppen von RM2 und RM3 gelöscht und die Rauchmelder mit der Gruppe von RM1 verbunden.
5. AES für HM-LAN-CFG abgestellt
6. in FHEM die Verbindung zu HM-LAN-CFG wieder eingerichtet.
7. set CUL_HM hmPairForSec 600
8. bei jedem Rauchmelder (RM1, RM2 und RM3) die Anlerntaste gedrückt, bei jedem wurde nur die rote LED angezeigt
   http://....:8083/fhem war dann einige Minuten nicht per Browser zu öffnen.
9. rename auf die Namen RM1,2,3 durchgeführt
10. attr room für RM1,2,3 gemacht
11. Versuch einen virtuellen Rauchmelder einzurichten.
    Hierfür die folgenden Zeilen in die fhem.cfg eingegeben.
   
   define sdTeam CUL_HM 11223301
   set sdTeam virtual 1
   attr sdTeam model HM-SEC-SDTeam
   attr sdTeam subType smokeDetector
 
12.Nach speichern und rereadcfg  steht folgendes in der fhem.cfg

   define sdTeam CUL_HM 112233
   attr sdTeam expert 2_full
   attr sdTeam model virtual_1
   attr sdTeam peerIDs
   attr sdTeam subType virtual
   attr sdTeam webCmd press short:press long

   define sdTeam_Btn1 CUL_HM 11223301
   attr sdTeam_Btn1 expert 1
   attr sdTeam_Btn1 model virtual_1
   attr sdTeam_Btn1 peerIDs
   attr sdTeam_Btn1 room System
   attr sdTeam_Btn1 webCmd press short:press long
   define FileLog_sdTeam_Btn1 FileLog ./log/sdTeam_Btn1-%Y.log sdTeam_Btn1
   attr FileLog_sdTeam_Btn1 logtype text
   attr FileLog_sdTeam_Btn1 room System

13.Jetzt peering von RM1,2 und3 zum virtuellen Rauchmelder

   set sdTeam_BTN1 peerChan 0 RM1 single set actor
   set sdTeam_BTN1 peerChan 0 RM2 single set actor
   set sdTeam_BTN1 peerChan 0 RM3 single set actor

   Im virtuellen Rauchmelder sdTeam_BTN1 steht danach keine peerID


14. Plötzlich sind dann RM2 und RM3 wieder mit RM1 gepeert.
    Kann es sein, das die beim HM-LAN-CFG eingerichtete Gruppe hier jetzt wirkt ???
    Und deshalb die Peer-Versuche im Punkt 13 nicht zur Wirkung kamen  ???

    RM1: peerList self01, 2013-09-23 21:29:43
    RM2: peerList RM1_chn:01, 2013-09-23 21:24:49
    RM3: peerList RM1_chn:01, 2013-09-23 21:21:39


Der Zustand ist im Moment, dass alle 3 Rauchmelder im state = alive stehen.
Einen Test mit Rauch kann ich heute nicht mehr machen.
Es gibt jetzt (evtl. neu) ein attr actstatus. Das steht manchmal auf unknown. Der Actiondetector scheint jetzt auf actstatus auszuwerten.
state = alive und actstatus = unknown ergibt im Actiondetector ein unknown device.

Meine Bitte:
- könnt ihr Euch bitte den Verlauf der Einrichtung ansehen. Ist das so ok?
- kann es sein, dass ich die virtuelle Gruppierung im HM-LAN-CFG weglassen muss um eine virtuelle Gruppe in FHEM einrichten zu können?
- Wieso gehen die Geräte im Actiondetector jetzt auf unknown, obwohl der state auf alive steht?

Vielen Dank für die Hilfe.

Gruß

Wolfgang