Hallo zusammen,
ich habe heute in der aktuellen c't einen Artikel über Rauchmelder (http://www.heise.de/ct/inhalt/2014/11/178/) mit dem Titel: Brandmelder im Eigenbau gelesen.
Basis ist ein Raspberry Pi mit CCD und entsprechenden Homematic Rauchmeldern, hier auch der Link zur Projektseite (http://www.heise.de/ct/14/11/links/178.shtml).
Da ich nicht der Experte in Sachen Homematic bin, kann ich nicht beurteilen, ob das gut ist, was die Jungs von c't machen. Auf jeden Fall ist fhem mit dabei, was ich gut finde ;)
Gruß PeMue
Hallo PeMue,
habe ich auch gerade gelesen; und selbst keine Erfahrung mit HM. Liest sich erst mal gut, wenn auch etwas "trocken" und mangels Bilder sowie den genannten 300 Euro für den FHEM-Erstkontakt wenig einladend. Vielleicht kann man mit CUL und Standardgehäuse noch etwas einsparen, jedoch ist das Display im RasPi schon toll.
Gewundert hatte mich, das Skriptaufrufe in's System nötig sind. Vielleicht kann das noch jemand beleuchten und begründen. Gerne der Autor selbst?
Viele Grüße, Ricardo
da ich kein CT abo habe, kann ich den Artikel nicht lesen.
Wenn ich die 2 Zeilen Überschrift lese interpretieren ich, dass hier das Device zyklisch abgefragt wird.
Das könnt ich mit einem Zyklischen "at" in FHEM erreichen, einfach einen Statusrequest absetzen.
FHEM bietet aktuell
- batterylow Erkennung vom Device
- Actiondektor, der ein ausgefallenes Device alarmiert
HM hat die zyklische Meldung des SD auf 3 Tage gesetzt - um Batterie zu sparen. Ich unterstelle, die wissen, was sie tun. Wenn ihr jetzt häufiger Abfragt werdet ihr mehr Batterien brauchen.
Ihr habt also aktuell eine vorwarnung UND eine Fehler-alarmierung. Jetzt braucht ihr noch eine Auswertung. Das könnt ihr so penetrant wie gewünscht machen. z.B. einen teamcall an alle SDs schicken, wenn einer ausgefallen ist - zyklisch alle 1h oder so.
Kann das ct system mehr?
@Ricardo: es sind wohl die notifys gemeint in bezug auf
ZitatSkriptaufrufe in's System
sie starten einfach nur eigene scripte zur Ansteuerung des displays. hätten sie auch ein fhem modul bauen können :-)
code von ct:
define RauchmelderAlarm notify EG_.*_RM.:smoke-Alarm_.* { system ("/usr/local/bmz/bin/set_status $NAME alarm") }
define RauchmelderBatterie notify EG_.*_RM.:[Bb]attery:.[^o][^k].* { system ("/usr/local/bmz/bin/set_status $NAME lowbatt") }
define RauchmelderOffline notify EG_.*_RM.:MISSING.* { system ("/usr/local/bmz/bin/set_status $NAME offline") }
define RauchmelderNAlarm notify EG_.*_RM.:off.* { system ("/usr/local/bmz/bin/del_status $NAME alarm") }
define RauchmelderNBatterie notify EG_.*_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") }hier zu laden http://www.heise.de/ct/14/11/links/178.shtml (letzter punkt)
Also Battery-reading und Actiondetector sollten alles notwendige liefern.
HMInfo würde auch schon alarme "sammeln" - nicht nur für smoke detector.
Ob Batterien des SD öfter als alle 3 Tage geprüft werden müssen... glaube ich nicht - wie gesagt, geht mit "at" zyklisch.