Rauchmelder peeren und pairen

Begonnen von Peterson, 03 April 2014, 07:26:41

Vorheriges Thema - Nächstes Thema

betateilchen

Zitat von: Prof. Dr. Peter Henning am 04 April 2014, 15:24:50Ein hoher Anteil an Innovationen kommt daher, dass jemand sich nicht an "Das geht nicht" oder "das macht man nicht" gehalten hat.

Das streite ich nicht ab. Aber die Sensibilität der Menschen gegenüber einem Rauchmelder nimmt einfach ab, wenn der Rauchmelder auch noch ganz andere Dinge signalisiert. Das ist wie bei Alarmanlagen in der Nachbarschaft: Irgendwann interessiert die Sirene niemanden mehr. Es geht nicht nur im die Menschen IN der Wohnung selbst. Als Hauseigentümer magst und kannst Du das anders sehen. Aber in einem Mehrfamilienhaus ist der "Missbrauch" eines Rauchmelders für mich definitiv ein No-Go.

-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Peterson

Hallöchen,

ich habe es nun hinbekommen.
Ich habe nicht die Anleitung im Wiki benutzt und mich an folgenden Eintrag http://forum.fhem.de/index.php/topic,9934.105.html langehängelt. (Danke an crissiloop für den Beitrag)

Hier nochmal in meinen Worten (als jemand, der nciht sehr Tief im Thema drin steckt und damit stepbystep dazulernt ohne gleich wegen zu viel Zeit frustriert zu werden) wie ich das zum Fliegen bekommen habe:

Folgendes war für mich wichtig:
- An FHEM sollen die Infos ankommen um z.B. im Alarmfall zusätzlich Lampen einzuschalten
- Von FHEM sollen die Rauchmelder aktiviert werden können für Alarmanlage, Wassereinbruch o.ä.
- Die Rauchmelder sollen authak ohne "Zentrale" im Verbund funktionieren

Es wurde schon viel über die Sinnhaftigkeit bestimmter obiger Punkte gesprochen. Der Einsatz soll jeder für sich festlegen. (Bitte Diskutionen hierüber  bitte in eigenem separaten Beitrag führen)

So jetzt geht es los:

1.   Rauchmelder einzeln mit der Zentrale pairen
- Es werden Einträge (wie gewohnt) in der fhem.cfg vorgenommen
- mit rename können die Bezeichnungen natürlich geändert werden (wäre vorteilhaft)

2.   Einen virtuellen Aktor definieren (Kommandozeile): define RM_TeamDev CUL_HM 999999
- Die ,,999999" ist die HMID, welche nirgendswo anders in der Konfig verwendet werden darf
- Wenn man einem Device nicht direkt mit einem Aktor verbindet, erhält er keine Rückmeldungen, wird also immer orange und rot blinken, wenn man einen Befehl absetzt. Dieser wird zwar von fhem verarbeitet, fhem weiß aber nicht, dass es etwas zurückmelden soll. Daher solltet man einen virtuellen Aktor anlegen und das Device dann mit diesem verbinden.

3.   Anzahl Kanäle definieren (Kommandozeile): set RM_TeamDev virtual 1
- Autocreate muss aktiv sein
- Es wird ,,RM_TeamDev_Btn1" erzeugt

4.   Umbennen von ,,RM_TeamDev_Btn1": rename RM_TeamDev_Btn1  Rauchmelder_Team
- für die bessere Lesbarkeit und Nachvollziehbarkeit

5.   Jeden Rauchmelder mit dem virtuellen SDLead (Kanal des virtuellen Aktors) peeren: set Rauchmelder_Team peerChan 0 <Rauchmelder1> single set
- Jeder Rauchmelder bekommt in seiner Konfiguration in der PeerID Zeile einen zusätzlichen Eintrag, der sich aus der HMID und der Channelnummer zusammensetzt. Dieser ist bei jedem Rauchmelder gleich
- Beim virtuellen Aktor werden alle HMIDs jedes Rauchmelders mit jeweils der Channel-ID unter peerIDs geschrieben

7.   Channel als internal in der PeerList: sdTeam add sdLead

8.   ,,Save config"

So habe ich getestet:
- In der Web-Gui von FHEM unter Everything und Rauchmelder_Team in der Zeile set ... AlarmOn aktivieren:
Die Rauchmelder piepsen leicht verzögert und nicht synchron (Gehörschutz wäre angebracht)
- In der Web-Gui von FHEM unter Everything und Rauchmelder_Team in der Zeile set ... AlarmOff deaktivieren:
- Rauchmelder ohne Zentrale testen:
-- HM-CFG-LAN Stromstecker ziehen und laut Anleitung Funk-Vernetzung testen (Kapitel 9.3)
Alle Rauchmelder piepsen leise aber nicht synchron.
Der auslösende Rauchmelder piepst jedoch nicht. Hier weiss ich nicht ob dies ein Problem ist, d.h. ob dieser im Alarmfall auch nicht piepst. Ich gehe davon aus dass dies nicht der Fall ist. Ich werde es bei Gelegenheit auch nochmal testen, wenn nicht jemand anderes an Infos beisteuern kann.

An dieser Stelle aus eigenem Interesse  noch eine Frage von meiner Seite um mehr zu verstehen:
Kannn jemand mir noch die einzelnen Schritte detailierter beschreiben (hat zwar crissiloop bereits getan, aber für mich  noch nicht so schlüssig), was da passiert. Vor allem interessiert mich, wie die Rauchmelder es mitbekommen haben, dass diese zusammen authak im Verbund auch ohne "Zentrale" arbeiten.

Auf diesem möchte ich nochmal allgemein hier einen Hinweis loswerden in der Annahme, dass es einigen Neueinsteigern auch so geht:
Bitte ergänzt den Wiki Beitrag mit solchen Detailbeschreibungen auch wenn der Wiki Eintrag auch richtig ist. Wie schon jemand geschrieben hat: Viele Wege führen nach Rom - warum also nicht auch diese Wege (Lösungsansätze) mitteilen.

Also zum Schluss noch ein dickes Lob: Ich habe wieder einmal gemerkt, dass ohne dieses Forum und den Beteiligten, die hier tatkräftig mitwirken,  das FHEM Projekt nicht so stark voran kommen würde - also weiter so. Ich werde mich auch versuchen hier weiter einzubringen.

Gruß,

Peterson
FHEM 5.5 auf RPI + HM-CFG-LAN

martinp876

Hallo Paterson,

hm - wann hast du in Wiki nachgesehen?
Ich sehe kaum einen Unterschied deiner Anleitung zu
http://www.fhemwiki.de/wiki/HM-SEC-SD_Rauchmelder#virtueller_TeamLead

Gruss Martin

Peterson

Hallo Martin,

in der Tat ich habe mir das Wiki vor einigen Wochen angesehen und jetzt sehe ich, dass es einige Anpassungen gibt. Ich finde es gut, dass man hier am Ball bleibt.

Mir fällt jedoch auf, dass diese Anleitung sehr ausführlich ist, aber auch dadurch einen Einsteiger verwirren kann. Aus diesem Grund habe ich nur noch mal das Ganze verkürzt aufgeschrieben und auch nochmal das Ziel aufgezeigt.

Vielleicht als Anregung/Ergänzung zu dem Wiki (Bitte verstehe mich nicht falsch und es soll auch nicht entmutigen damit weiterzumachen):
- Für mich war es, auch aufgrund der teilweise auch widersprüchlichen Forenbeiträge verwirrend wie ich mein Ziel erreichen kann, sprich authage Nutzung der SDs im Verbund als auch die Ansteuerung und der Erhalt von Infos von den SDs. Ich konnte nicht erkennen, dass der Wiki-Eintrag dafür geeignet ist.

Vielleicht sollte man im Wiki Eingangs die Verwendungsvarianten, sprich
- Einzeln mit Zentrale
- Mehrfach mit Zentrale
- Mehrfach authag aber mit Zentrale (mein Fall)
- Mehrere Teams/Gruppierungen

nennen und eventuell Vor- und Nachteile aufzeigen. Somit erhält der Leser erst einmal die Möglichkeit sich für eine Lösungsvariante zu entscheiden bzw. sich klar zu werden auf welche Variante man sich was einlässt.
Im weiteren Wiki sollte entsprechend die Varianten berücksichtigt werden.

- Das bei mir unter 1. Beschriebene habe ich nicht gefunden oder herausgelesen.

- Die Beschreibung mit den Teams  und dem virtuellen Team war für mich ein Knackpunkt. Ich habe für mich nicht herausfinden können, wie dies mit dem peeren und pairen zusammenhängt, sprich beeinflusst dass eine das andere bzw. funktoniert das damit so wie ich es vorhabe.
Verwirrt hat mich auch das "können/sollte". Die Abgrenzung für mein Vorhaben konnte ich nicht vornehmen, sprich was ist für mich notwendig. Hier wäre eine Differenzierung vielleicht aufschlussreich, wie "für Variante 1,... sollte man dies ..."

- Die Reihenfolge "Teamlead", "Kommandos", "Virtueller Teamlead" war noch für mich verwirrend. Ich habe mich gewundert, warum zum Teamlead kein Kommando dazugeschrieben wurde. Verstanden habe ich es jetzt so, dass der Absatz "Teamlead" und "virtueller Teamlead" eigentlich zusammen gehören und zweiten zwingend ist .

Das ist nun meine subjektive Meinung. Ob meine Anregungen bzw. meine Infos in das Wiki einfließen (sollen/können) ist dem Verfasser (ich weiss ob Du das bist) vorbehalten. Ich finde es gut, dass hier auch darauf eingegangen wird und dieskutiert wird (Jedoch habe ich keine ahnung ob das hier im Beitrag richtig positioniert ist).

Gruß,

Peterson
FHEM 5.5 auf RPI + HM-CFG-LAN

Pfriemler

Danke für so eine Erklärung, die werde ich beim Einrichten meiner sechs neuen Rauchmelder noch brauchen ... aber tut mir doch bitte den Gefallen und schreibt "autark" mal endlich richtig, sonst krieg ich noch Augenkrebs (wegduck) ...

Geht nich gips nich

"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

martinp876

Zitataufgrund der teilweise auch widersprüchlichen Forenbeiträge...
kann ich nichts machen... wiki sollte korrekt sein. Wenn einer in Foren etwas falsches postet ist es so... Foren enthalten manchmal "seltene Ansichten". In Wiki sollte es aber zumindest stimmen.

Zitat- Einzeln mit Zentrale
- Mehrfach mit Zentrale
- Mehrfach authag aber mit Zentrale (mein Fall)

So viele Fälle gibt es nicht. Wir sind im FHEM Forum - also gibt es immer eine Zentrale. Das heisst nicht, dass die Zentrale zum Betrieb benötigt wird, heulen werden die Melder trotzdem.
=> wie für alle Devices gilt: pairen
Es gibt den Fall mit und ohne "virtual team lead". Das ist eine gewisse ansichtssache. Ein Einzelner wird exakt wie eine Gruppe eingerichtet. Absolut kein Unterscheid.
Es gibt nur einen Hinweis dass ich eine Gruppe immer mit einem Virtuellen Teamlead einrichten würde und einen Einzelnen ohne (da könnte es etwas übertrieben sein).

Zitat- Mehrere Teams/Gruppierungen
hm  - das sollte dann jeder selbst wissen. Ich muss, wenn nicht einen Lichtschalter einrichte doch auch kein Kapitel für den 2. machen. Die Melder bekommen einfach eine andere teamId. Die Teams haben aber auch garnichts mit einander zu tun. Muss man das Beschreiben?

Wenn man es einfach machen will sollte man nur den Vorgang mit virtuellen Lead beschreiben. Keine Wahlmöglichkeit für den einfachen User, keine Nachteile. Aber dann sind einige evtl enttäuscht.

Zitatnennen und eventuell Vor- und Nachteile aufzeigen
hm - das steht im Wesentlichen drin. Das aber genau verwirrt newcomer - die wollen nicht viel lesen sondern erfolge sehen.
ZitatSomit erhält der Leser erst einmal die Möglichkeit sich für eine Lösungsvariante zu entscheiden bzw. sich klar zu werden auf welche Variante man sich was einlässt.
das steht doch jetzt drin. Ob er es abschätzen kann?

Zitat- Das bei mir unter 1. Beschriebene habe ich nicht gefunden oder herausgelesen.
was soll das sein? Gibt es ja garnicht. Bist du sicher, das du verstanden hast, wie es funktioniert? Vielleicht ist die Anleitung zu schlecht.

ZitatDie Beschreibung mit den Teams  und dem virtuellen Team war für mich ein Knackpunkt. Ich habe für mich nicht herausfinden können, wie dies mit dem peeren und pairen zusammenhängt
mit pairen schon einmal garnicht. Regel 1: gepairt wird immer und jeder. Steht auch beim SD gleich unter hinweise zum Betrieb - mit Link!
Unter virtualTeamLead steht dann, wie man einen anlegt und 2. wie man jeden SD damit peert. hm - was noch? Da ist man fertig.
ZitatVerwirrt hat mich auch das "können/sollte".
du solltest halt am Ende prüfen, ob es klappt - wenn du es nicht machst, hast du es nicht gemacht. Das erzeugen eines vtl könnte so aussehen - die HMId musst du anpassen, den namen,.... den rest solltest du verstehen können.

Zitatdass der Absatz "Teamlead" und "virtueller Teamlead" eigentlich zusammen gehören und zweiten zwingend ist .
nein. TeamLead brauchst du eigentlich immer. Einen Virtuellen Empfehle ich - brauchen tust du ihn nicht.
ZitatIch habe mich gewundert, warum zum Teamlead kein Kommando dazugeschrieben wurde.
was meinst du? Es gibt Kommandos, die an das Team gerichtet werden. Diese müssen Im Namen der Teams gesendet werden - also vom TeamLead. Und beschrieben sind sie doch - fehlt etwas?

Ich werde es mit noch einmal ansehen - danke für das feedback! Vielleicht war einiges noch nicht verstanden (was bedeuten würde, dass die Beschreibung evtl zu schwer ist)
Verbessern kann man es sicher.
Was klar sein muss: Generelle HM Dinge werden in generellen Kapiteln beschrieben (pairen, auch peeren).

Gruss Martin

no_Legend

#21
Hallo,

eure Diskussion und die Anleitungen hier sind echt gut. Kompliment.
Habe es damit hin bekommen, meine drei Rauchmelder zusammen zu bekommen.

Jetzt hab ich aber noch ein paar fragen
1. Was mache ich wenn ich mehrere Teams machen will?
2. bei mir steht unter den peerIds nichts, muss man das von hand eintragen?

Danke und Gruß Robert
Docker FHEM immer aktuell,4x HMLAN, CUL443, CUL868 -homekit/siri -tablet ui -homebridge
Device, diverse:
Homematic, Shelly, Tasmota, MQTT, Unifi Network usw.

martinp876

Zitat1. Was mache ich wenn ich mehrere Teams machen will?
du musst jedes Team einzeln definieren. Die Teams sind dann komplett unabhängig. Du brauchst mehrere TeamLeads

Zitat2. bei mir steht unter den peerIds nichts, muss man das von hand eintragen?
in den realen SDs sind diese eingetregen (sollten...) und können mit getConfig ausgelesen werden.
Bei einem virtuellen wird dies beim peeren eingetragen. Du musst aber save machen um es zu speichern.


no_Legend

Danke für deine Antwort Martin,

Ich bin mir nicht sicher ob ich überhaupt verschiedene Teams ausbauen soll.
Da wir im Haus auf mehreren Stockwerken wohnen, sollte man eigentlich geweckt werden egal wo es brennt.

Gruß Robert
Docker FHEM immer aktuell,4x HMLAN, CUL443, CUL868 -homekit/siri -tablet ui -homebridge
Device, diverse:
Homematic, Shelly, Tasmota, MQTT, Unifi Network usw.

martinp876

nur ein team ist der Normalfall. Das andere ist - der vollständigkeit halber und für Leute, die einen sinnvollen Einsatz dafür haben

Pfriemler

Ich habe auch erwogen, einen Melder in ein separates Team auszulagern und als Akustikmelder - zB Alarmvorwarner im Schlafzimmer - zu missbrauchen. Eine gegenseitige Verkettung lässt sich mit ein paar notifys realisieren, funzt dann aber nicht, wenn FHEM ausfällt. Da ich hier auf Nummer sicher gehen will, wird's wieder ein Team ...

Geht nich gips nich

"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

no_Legend

Ich habe jetzt auch ein Team gemacht.
Alles andere war mir dann doch zu unsicher.
Wenns mal im Keller brennt und im 1OG bekommts keiner mit, muss ja nicht sein.

Danke für eure Hilfe.

Gruß Robert
Docker FHEM immer aktuell,4x HMLAN, CUL443, CUL868 -homekit/siri -tablet ui -homebridge
Device, diverse:
Homematic, Shelly, Tasmota, MQTT, Unifi Network usw.

Frank S.

Moin.

Ich habe mir nun auch drei Rauchmelder HM-SEC-SD zugelegt und habe sie gerade nach der Anleitung in FHEM eingebunden. Als Test habe ich den Befehl "set Rauchmelder_Team AlarmOn" ausgeführt. Die Rauchmelder haben sich nicht akustisch gemeldet. Nach einieger Zeit habe ich dann den Alarm wieder mit "set Rauchmelder_Team AlarmOff" ausgeschaltet.

In alle drei Logfiles der Melder sind folgender Einträge vorhanden.

2014-12-01_19:07:43 Rauchmelder_1 off
2014-12-01_19:07:43 Rauchmelder_1 smoke_detect: -
2014-12-01_19:07:43 Rauchmelder_1 smoke-Alarm_0B
2014-12-01_19:07:43 Rauchmelder_1 smoke_detect: RM_TeamDev
2014-12-01_19:08:28 Rauchmelder_1 off
2014-12-01_19:08:28 Rauchmelder_1 smoke_detect: -


Wenn ich nun mittels Taster am Rauchmelder einen Alarm auslöse meldet sich nur dieser akustisch. Im Logfile gibt es auch keine Meldung.

Liegt hier nun ein Fehler im System vor, oder habe ich nur etwas falsch getestet?

Schöne Grüße
Frank

Pfriemler

Die Anleitung im Wiki sieht mehrere Verfahren vor, welches hast Du benutzt? einen separat definierten TeamLeader?
Die Kommandos müssten korrekt "alarmOn" und "alarmOff" heißen (also kleiner Anfangsbuchstabe). Geht bequemer übers Webinterface beim Teamleader. War vielleicht auch nur hier ein Schreibfehler.
Das Log zeigt aber dass was passiert. So sieht es zumindest bei mir auch aus, wenn ich per TeamLeader einen Global-Alarm triggere.

"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

CQuadrat

Hallo Zusammen,

da das ganze ja doch sehr sicherheitsrelevant ist und ich ich hier keine hunderprozentige Aussage zu den beiden nachfolgenden Zitaten finden kann:

Zitat von: Prof. Dr. Peter Henning am 03 April 2014, 22:03:49
Der Wiki - Artikel ist leider komplett umgeschrieben worden, und eine sicherheitsrelevante Sache ist dabei komplett im Nebel verschwunden.

Ein Alarm wird nur unter denjenigen Rauchmeldern weiter gegeben, die untereinander vernetzt sind - und zwar über den "Teamleader".  Wenn man nur einen virtuellen Teamleader anlegt, existiert dieser in FHEM und jeder einzelne Rauchmelder kennt nur FHEM als Teamleader. Das hat zur Folge, dass die Weitergabe eines Alarms nicht unabhängig von FHEM stattfindet.

LG

pah

und

Zitat von: betateilchen am 04 April 2014, 14:01:06
Da wette ich locker dagegen.

Frage:
Arbeiten die Rauchmelder auch mit einem in FHEM angelegten virtuellem Teamleader ohne FHEM (z.B. wegen Ausfall) unabhängig und werden im Alarmierungsfall alle Rauchmelder (Reichweite vorausgesetzt) aktiviert? Hat das schon einmal jemand getestet? Meine Rauchmelder sind noch unterwegs. Von der Antwort ist abhängig, ob ich mit einem virtuellen Teamleader arbeiten werde.

Danke für eine Klarstellung.


Christoph
FHEM auf Mini-ITX-Server mit Intel Quad-Core J1900:
+ HM: HM-LAN, HM-USB, HM-MOD-UART mit div. HM-Komponenten
+ RFXtrx: Funkwetterstation Bresser mit ext. Thermometer, Regenmesser und Windmesser
+ TUL (KNX-Anbindung), MQTT, SONOS (div. Gimmicks), OneWire, Hue