FHEM Forum

Hallo,
bin am planen einer einfacher Sicherheitsanlage für unsere Wohnung.
Möchte dazu HM Rauchmelder, ein TFK für 4 Türe im Flür und kleine sender (zum scharf/unscharf machen) benutzen.

Bin aber auf einige negative Bewertungen im Internet gestoßen - die Melder lösen angeblich Alarm manchmal ohne irgendwelche Grund aus.
Es ist natürlich nicht schön - wenn in der Nacht, oder wenn niemand da ist  wird Alarm ohne Grund ausgelöst.

Wie sieht es aus mit Erfahrungen hier im Forum?

Danke.

Hallo,

ich nutze die Hm Rauchmelder mit einer CCU und habe keine Fehlalarme aber wenn ich im Keller Staub mache löst er aus (was ja richtig ist) und in diesem Fall nehme ich ihn einfach ab und die Batterie aus dem Melder. Einmal habe ich ihn vergessen nach den Arbeiten wieder zu Aktivieren und es erst zwei Wochen später bemerkt aber in der Homematic CCU keine Servicemeldung erhalten! Also wenn es um Sicherheit geht finde ich dies ein NO GO!

LG

Franz

Bei mir gab es noch nie Fehlalarme. In der Küche nehme ich den beim Kochen, wenn es viel Dampf/Rauch gibt schonmal ab und leg ihn ins Esszimmer. Da wird er a) nicht vergessen und b) kommuniziert er weiter mit seiner Zentrale. Die Zentrale (fhem und CCU2) merkt bei mir übrigens einen fehlenden Rauchmelder.

@betateilchen, wieviele davon hast du denn? und fuehst du den monatlichen abgleich/kalibrierung aus?
ich bin auch am ueberlegen welche RM ich nehmen soll und hab mir wegen der vielen negativen rezessionen noch keine von homematic "getraut".

Zitat von: micomat am 12 März 2014, 11:00:04@betateilchen, wieviele davon hast du denn?

inzwischen vier

Zitat von: micomat am 12 März 2014, 11:00:04und fuehst du den monatlichen abgleich/kalibrierung aus?

nö. Ein Rauchmelder, um den ich mich einmal pro Monat "kümmern" muss, ist für mich keine Lösung.


Und nochwas: Ein Rauchmelder sollte nicht als Sirenenersatz für eine Alarmanlage missbraucht werden!

Zitat von: betateilchen am 12 März 2014, 11:04:04
nö. Ein Rauchmelder, um den ich mich einmal pro Monat "kümmern" muss, ist für mich keine Lösung.

full ack :)
okay, vielleicht traue ich mich dann doch noch irgend wann.

danke
markus

wenn du die Batterie vergisst einzulegen und das nicht bemerkts ist das ein Konzeptfehler.
fhem ueberwacht das regelmaessige melden eines jeden (actiondetector). dann bekommst du ein Reading und kannst aktionen verknuepfen - wenn du willst auch einen Rauchalarm ausloesen (falls betateilchen es erlaubt;-) )

SDs melden sich alle 3 Tage - also spaetestend nach 3 Tagen bekommst du den Trigger.
Kann man auch ueber HMInfo loesen - hier werden Alarme "konsolidiert" und man kann sich eine email triggern lassen

Zitat von: martinp876 am 12 März 2014, 11:31:26dann bekommst du ein Reading und kannst aktionen verknuepfen - wenn du willst auch einen Rauchalarm ausloesen

Ich empfehle für einen solchen Fall zur Zustand-Signalisierung lieber den teamCall.

macht sinn. Sollte man aber regelmaessig wiederholt werden. Vielleicht ist gerade keiner im Haus zu diesem Zeitpunkt.

Meine Strategie ist beides nicht. Ich versuche systemkritische Warnungen und Alarme zu sammeln und dann eine email zu senden. Die besagt im Wesentlichen: hey, Admin - wird Zeit, dass du mal vorbei schaust. Alle wichtigen Alarme und stati sollten dann in einem Fenster zu sehen sein. Gestaffelt nach  level: info/warning/alarm/critical.
Das ist in HMInfo realisiert und voreingestellt. Der Admin kann weitere Alarme aufnehmen.
von HMInfo kann der Admin dann in die Tiefe gehen und weitere Details suchen.

ich hab HMinfo immer noch nicht kapiert  :(

welchen Teil?
Man muss es nicht nutzen oder moegen. Aber zu verstehen sollte es sein. Ich versuche es noch einmal
Technisch:
FHEM hat eine Entity CUL_HM welche der User nicht sieht. Es ist eine Modul und diese haben (zumindest hier) kein sichtbares interface. HMInfo stellt dies dar. Ferner stellt HMInfo kommandos zur Auswertung und uebersicht ueber die HM installation von FHEM zu Verfuegung
=> HMInfo ist nach dem layering model der HM layer. Entities die mit define...CUL_HM angelgt werden sind HM-units, wenn du so willst.

Ziel:
generell eine uebersicht der HM komponennten zu bekommen, das zusammenspiel erfassen zu koennen. HM komponenten sind vielfaeltig programmierbar - man kann einiges falsch machen, vergessen uebersehen.... Einiges passiert zeitverzoegert - ist es fertig? Wo finde ich den Systemstatus.
a) Die HMInfo webansicht soll eine uebersicht ueber Alarme geben. Mit dem HMInfo cmd 'update' wird der status refreshed. natuerlich kann man es automatisch refreshen (attr autoUpdate) - alle paar Minuten.
Zu finden sind dann
- alle batteriealarme
- alle actiondetector events
- protocol probleme
...
siehe attribut sumERROR und sumInfo- welche du auch anpassen kannst
Es gibt infos ueber RSSI,....
==> wenn ein Alarm aufschlaegt will ich den hier sehen. Und auch wichtigeInfos.

b) pruefen der Konfig (checkConfig - auch checkPeers,...)
dieser Teil ist sicher nicht komplett. Ziel ist, dem User zu helfen Fehlkonfigurationen zu finden. Der Teil ist sicher nicht komplett und sollte weiter ausgebaut werden. Er wird auch nicht zyklisch ausgefuerht. Es soll erkannt werden: peering ist nicht beidseitig, burst ist nicht eingeschatet, IO device nicht korrekt programmiert.
Wie gesagt, hier ist noch arbeit notwendig. Wenn es "kompletter" ist sollte es in der Lage sein fehleinstellungen der Register anzuzeigen oder Hinweise zu geben.
-> ideen willkommen, was geprueft werden sollte
-> es sind komplette und aktuelle Regisersaetze notwendig, um deren Inhalt zu checken

c) Register Verwaltung
von einigen Devices sind register schwer zu bekommen...  (config, wakeup once a day). Man kann mit saveConfig alle regsiter speichern oder mit archive den letzen gelesenen Stand automatisch speichern. Ggf. kann man den Stand auch wieder einspielen. Das Verwalten von templisten geht in die gleiche Richtung.

d) templates
user - insbesodere Anfaenger haben Probleme mit statemachines und dem allgemeinen Verstaendniss der HM Teile. Entsprechend der Config software kann man hier die Register auf highleven basis setzen. Also "treppenhausschalter" "motion detector-licht mit daemmerungswert"
Es gibt ein paar vorgefertigte Templates - man kann welche selber definieren. Man kann pruefen, ob das template in Device entsprechend eingebaut ist (verify).
Und schlieslich kann man von einem Channel zum anderen ein settingkopieren - straight forward

e) Uebersichten/tabellen/statistiken
sind, was die ueberschrift sagt.
RSSI und message stat ist eher selten im Gebrauch. Immer interessant ist das protoEvents fenster. Hier ist zu sehen, was FHEM reledigt hat, wer noch offen ist, was schief gegangen ist

f) clear
ist die logische Konsequens aus e). Man kann die Tabellen loeschen wenn man neu anfaengt zu pruefen oder zu konfigurieren. RSSI, Register, Protoevents.

g) param
- anzeigen einer Liste bestimmer parameter/variablen aller Devices

Im Gegensatz zu anderen Sammelaktionen die FHEM zu Verfuegung stellt kennt HMInfo die HM struktur (device ,channel, virtual). Filtern kann man ueberall (nur devices/channel/virtual) und mit regexp.

mehr ist nicht drin

Moin,

bzgl. Rauchmelder habe ich mal ein vlt. doofe Frage.
Alarmieren sich die Rauchmelder im Falle eines Falles untereinander, wenn ich mehrere Rauchmelder, wie vorgeschlagen, erst paire und dann über die Zentrale peere, wenn die Zentrale "out of order" ist?

ja.
Du musst die SDs in ein Team zusammenfassen (also jeden mit der teamID peeren)
der Alarmieren den sendet einen alarm 3 mal (weil es kein ACK gibt) und alle Teammitglieder heulen mit.
Eine Zentrale ist bei korrektem teaming nicht notwendig, es gibt auch keinen "master".
das korrekte teaming kannst du praktisch mit teamCall testen (allo piepen 10 mal)

Hast Du eigentlich schonmal gesucht, ob man die Notbeleuchtung des SD irgendwie unabhängig vom Alarm schalten kann?

habe ich nichts gefunden. Weder Kommando noch Register

Nachtrag: hat die Erklaerung zu HMInfo weitergeholfen? Evtl habe ich nicht verstanden was du meinst. Oder wolltest du nur sagen "das braucht man nicht, macht man alles anders"?