HomeMatic
HomeMatic (HM) ist ein System zur Steuerung und Überwachung von zahlreichen Aufgaben und Situationen im Haus. Anfangs gab es nur auf Funk (868,3 MHz) basierende Sensoren und Aktoren, 2008 kamen die ersten "wired"-Komponenten (basierend auf RS485) auf. Es kann zur Heizungs- und Lichtsteuerung, Temperatur-, Luftfeuchte- und Feuchtemessung, Zutrittskontrolle, als Wasser-, Brand- und Bewegungsmelder sowie als Wetterstation (Wind, Regen, Licht, Temperatur und Luftfeuchte) usw. eingesetzt werden. Zusätzlich gibt es noch Fernbedienungen und Statusdisplays.
Da, wo es notwendig ist, sind die Geräte rückkanalfähig, soll heißen, dass ein Aktor (z.B. Lichtschalter) an die Steuerungseinheit zurückmeldet, ob er einen Schaltbefehl erhalten hat (ACK für Acknowledgement, also Empfangsbestätigung). Erkennt der Aktor den Befehl nicht, sendet er ein NACK. Kommt vom Aktor keine Rückmeldung innerhalb einer festgelegten Zeit, meldet FHEM ein MISSING ACK im FHEM-Log.
Vom Hersteller eQ-3 selbst wird entsprechende Hard- und Software für den Aufbau einer HM-Zentrale zur Steuerung und Auswertung der HM-Komponenten angeboten. Diese ist aber nur in Verbindung mit HM-Geräten nutzbar.
Betrieb mit FHEM
Für den Einsatz mit FHEM benötigt man die entsprechende Rechner-Hardware, FHEM selbst und einen Übertragungs- bzw. Konfigurationsadapter (Interface) wie z.B. CUL oder HMLAN Konfigurator.
Beachten Sie bitte vor der Auswahl des o.a. Adapters diesen Artikel.
Vorteile von FHEM statt der eQ-3-Software:
- betriebssystemunabhängig
- paralleler Betrieb mit Geräten anderer Hersteller (z.B. FS20, mit 2. Adapter!)
- FHEM läuft auf einigen NAS-Systemen, FritzBoxen oder auch z.B. einem RaspBerry Pi
- <bitte ergänzen>
Wichtig: Falls Sie sich (zunächst) für den CUL-Betrieb entscheiden, setzen Sie die erforderliche HMID bitte unter Berücksichtigung dieses Links (HMID nur aus Großbuchstaben und Zahlen). Dies erleichtert einen späteren Wechsel auf HM-LAN.
Hinweis: Sofern Sie (Konfigurations-)Befehle (egal ob set ... oder get ...) per FHEM an einen HM-Sensor bzw. -Aktor absetzen, müssen Sie auf deren Verarbeitung warten, bis der Sensor/Aktor von sich aus Kontakt mit der HM-Zentrale (hier: FHEM) aufnimmt. Solange sehen Sie in den Readings des HM-Device den Hinweis CMDs pending. Einige Sensoren nehmen nur bei Änderung ihres Status (z.B. HM-Sec-SC, HM-Sec-RHS) Kontakt zur Zentrale auf. Die Kontaktaufnahme dauert in der Regel ca. 5 Minuten. Um diese Kommunikation zu erzwingen bzw. vorzuziehen, können Sie an dem Aktor/Sensor entweder die Anlerntaste (beim HM-CC-TC die <OK>-Taste) für ca. 5 Sekunden drücken oder den Zustand des HM-Gerätes verändern (z.B. Türe/Fenster öffnen).
Pair / Peer bzw. pairen und peeren
HM-Geräte können unter- bzw. miteinander gepeert werden, wenn z.B. ein Sensor einen Aktor direkt (ohne Zentrale) steuern soll.
HM-Geräte müssen andererseits mit einer Zentrale gepairt werden, wenn diese Zentrale die Geräte (um-)konfigurieren bzw. steuern oder zumindest auslesen können soll.
Der Vorgang des Peerens mittels Anlerntaste(n) muss durchgeführt werden bevor auch nur eines der zu peerenden Geräte mit einer Zentrale gepairt wird. Ansonsten muss dieser Peer-Vorgang durch FHEM-Befehle vorgenommen werden.
=> weitere Infos zum Pairen und Peeren
Aktoren / Sensoren
Eine Übersicht und weitere Informationen über die von FHEM unterstützten HM-Geräte erreichen Sie über diese Seite.
Atttribute / Eigenschaften / Readings
Alle Aktoren/Sensoren verfügen über Attribute (Eigenschaften), Register und Readings, die mittels FHEM ausgelesen und/oder verändert werden können.
Beispiel: Die Ausgabe der Eigenschaften, Register und sonstiger Attribute eines HM-SEC-SC Tür-Fensterkontakt erfolgt durch den Befehl
list EG.WZ.Tuerkontakt
wobei EG.WZ.Tuerkontakt dem per rename angepassten Namen des SC entspricht (kann bei Ihnen natürlich anders lauten):
Internals: CHANGED DEF 1BB0CF EVENTS 11 HMLAN1_MSGCNT 15 HMLAN1_RAWMSG R842D4EED,0001,7C73E9F4,FF,FFC1,9FA0101BB0CF123ABC0201010000 HMLAN1_RSSI -63 HMLAN1_TIME 2013-03-19 20:43:14 IODev HMLAN1 LASTInputDev HMLAN1 MSGCNT 15 NAME EG.WZ.Tuerkontakt NR 119 STATE MISSING ACK TYPE CUL_HM lastMsg No:9F - t:10 s:1BB0CF d:123ABC 0201010000 protCmdDel 3 protLastRcv 2013-03-19 20:43:14 protResnd 2 last_at:2013-03-19 20:37:33 protResndFail 1 last_at:2013-03-19 20:37:36 protSnd 7 last_at:2013-03-19 20:43:14 protState CMDs_done rssi_at_HMLAN1 avg:-58.66 min:-77 max:-50 lst:-63 cnt:15 Readings: 2013-03-19 20:43:11 Activity: alive 2013-03-19 20:43:12 CommandAccepted yes 2013-03-19 20:43:13 PairedTo 0x0 2013-03-19 20:43:14 R-EG.WZ.Heizung_WindowRec-expectAES off 2013-03-19 20:43:14 R-EG.WZ.Heizung_WindowRec-peerNeedsBurst on 2013-03-19 20:43:13 R-cyclicInfoMsg on 2013-03-19 20:43:14 R-eventDlyTime 0 s 2013-03-19 20:43:13 R-intKeyVisib invisib 2013-03-19 20:43:14 R-ledOnTime 0.5 s 2013-03-19 20:43:14 R-msgScPosA closed 2013-03-19 20:43:14 R-msgScPosB open 2013-03-19 20:43:13 R-pairCentral 0x0 2013-03-19 20:43:13 R-sabotageMsg on 2013-03-19 20:43:13 R-transmDevTryMax 6 2013-03-19 20:43:14 R-transmitTryMax 6 2013-03-19 20:43:13 RegL_00: 02:00 09:01 0A:00 0B:00 0C:00 10:01 14:06 00:00 2013-03-19 20:43:14 RegL_01: 08:00 20:60 21:00 22:64 30:06 00:00 2013-03-19 20:43:14 RegL_04:EG.WZ.Heizung_WindowRec 01:01 00:00 2013-03-19 20:37:23 alive yes 2013-03-19 20:37:23 battery ok 2013-03-19 20:37:24 contact open (to EG.WZ.Heizung) 2013-03-19 20:37:23 cover open 2013-03-19 20:43:13 peerList EG.WZ.Heizung_WindowRec, 2013-03-19 20:37:36 state MISSING ACK Helper: mId 002F peerIDsRaw ,1AD19403,00000000 rxType 12 Rssi: At_hmlan1: avg -58.6666666666667 cnt 15 lst -63 max -50 min -77 Shadowreg: Attributes: actCycle 028:00 actStatus alive expert 2_full firmware 2.0 fp_GrundrissEG 465,1077,1,Terrassentüre model HM-SEC-SC peerIDs 00000000,1AD19403, room EG.WohnZ serialNr JEQ0383824 subType threeStateSensor
Erläuterungen zu einzelnen Ausgabezeilen:
HMLAN1_RAWMSG R842D4EED,0001,7C73E9F4,FF,FFC1,9FA0101BB0CF123ABC0201010000
Hier erfolgte eine Kommunikation zwischen dem Gerät mit der REF-ID 1BB0CF (HM-Sec-SC) und der Zentrale mit der HMID 123ABC.
HMLAN1_RSSI -63
Die Sende-/Empfangsstärke der letzten Funkübertragung. Dies ist im Zusammenhang mit der Zeile
rssi_at_HMLAN1 avg:-58.66 min:-77 max:-50 lst:-63 cnt:15
zu sehen, welche den Durchschnitts- (avg), Min-, Max- und nochmal den letzten (lst) Wert von insgesamt (cnt) 15 Funkübertragungen angibt.
PairedTo 0x0 ... R-pairCentral 0x0
weist darauf hin, dass hier noch kein Pairing des HM-Sec-SC mit dem HMLAN-Konfigurator abgeschlossen wurde.
IODev HMLAN1 LASTInputDev HMLAN1
Die (letzte) Kommunikation erfolgte mit dem Device HMLAN1 (hier der Klarname des HMLAN-Konfigurators, der Zentrale).
2013-03-19 20:43:13 R-cyclicInfoMsg on
Hat der HM-Sec-SC fast 24 Stunden nichts zu melden gehabt (Tür/Fenster wurde nicht geöffnet/geschlossen), wird zumindest eine Batteriestatus-Meldung an die Zentrale geschickt. Dies ist aber nur bei den Three-State-Sensoren erforderlich (siehe unten).
2013-03-19 20:43:13 peerList EG.WZ.Heizung_WindowRec,
in Verbindung mit
peerIDsRaw ,1AD19403,00000000 ... peerIDs 00000000,1AD19403,
Der HM-Sec-SC ist mit dem HM-CC-TC Funk-Wandthermostat (Raumtemperaturregler) mit dem Namen EG.WZ.Heizung (Geräte-ID 1AD194) und dessen Channel _WindowRec (Kanal 03) mit der ID 1AD194 03gepeert. Über diesen erfolgt auch die Steuerung. Steht hier nur die 00000000,, ist kein Peering erfolgt und der SC kann nicht gesteuert werden.
firmware 2.0
Bei HM-Geräten ohne Display kann nur über das Auflisten der Attribute die Firmware-Version in Erfahrung gebracht werden.
Besonderheiten
Three-State-Sensoren
Bei allen(?) HM-Devices, die von FHEM als "CUL_HM_threeStateSensor_1A2B3C" erkannt und eingebunden werden, gibt es eine Besonderheit bei den Batteriezuständen zu beachten.
Zu den Three-State-Sensoren gehören:
Regulär sendet ein Three-State-Sensor (TSS) keine Meldungen über den Zustand der Batterien an FHEM bzw. nur dann, wenn der Sensor seinen Zustand ändert (z.B. auf <=> zu). Um dies zu ändern, müssen im TSS bestimmte Registerwerte gesetzt werden. Hierzu ist die in diesem Forenthread dargestellte Vorgehensweise erforderlich (bitte auch nachfolgende Thread-Beiträge beachten).
Beim HM-SEC-SC/RHS z.B. kann man die Register nur beschreiben, indem der Anlernknopf im Batteriefach gedrückt wird.
Ablauf:
Um das entsprechende Register zu setzen, muss man zunächst in FHEM folgende Befehle
set CUL_HM_threeStateSensor_1A2B3C getConfig set CUL_HM_threeStateSensor_1A2B3C regSet cyclicInfoMsg on
eingeben. Danach siehst man in FHEM beim Device, dass mindestens ein Kommando zur Übertragung ansteht ("cmd pending") und in den "Readings", dass das cyclicInfoMsg-register geschrieben werden soll ("set_on"). Jetzt ist am SC/RHS der Anlernknopf zu drücken. Danach noch mal
set CUL_HM_threeStateSensor_1A2B3C getConfig
eingeben, ggfls. Anlernknopf drücken. Jetzt sollten keine "pending-commands" mehr zu sehen sein und in den "Readings"
R-cyclicInfoMsg on
statt set_on stehen. Ab jetzt kommt regelmäßig eine Batteriemeldung, wenn der TSS etwa 24 Stunden lang nicht betätigt wurde. Zudem kann das Device jetzt auch vom ActionDetector unterstützt werden.
Hinweis: Das funktioniert seit dem 20.03.2013 auch beim HM-Sec-WDS Funk-Wassermelder (nach einem update).
Virtuelle Aktorkanäle
Mit den HM-Geräten
- HM-LC-Dim1PWM-CV Dimmaktor PWM DC-LED
- HM-LC-Dim1TPBU-FM 1-Kanal-Dimmer UP
- <bitte ergänzen>
sind erstmalig virtuelle Aktorkanäle und Verknüpfungslogiken eingeführt worden. Das bedeutet, dass Aktionen unabhängig von der Verfügbarkeit der HM-Zentralen (CCU, FHEM mit HM-LAN-Konfigurator) direkt zwischen verschiedenen Aktoren/Sensoren und dem Gerät mit den virtuellen Aktorkanälen festgelegt werden können.
Eine offizielle Unterstützung seitens FHEM gibt es z.Zt. (16.2.2013) noch nicht (Korrektur: siehe unten unter "Anmerkung:").
Wer jedoch erste Versuche mit FHEM starten möchte, kann - nachdem der entsprechende Aktor in FHEM angelernt wurde - wie folgt verfahren:
in der fhem. cfg müssen Sie nach
define <dimmerDevice> CUL_HM 1C062D
(wobei "1C062D" bei Ihnen anders lauten kann)
folgendes einfügen
define <dimmerDevice>_SW CUL_HM 1C062D01 <= 1C062D + 01 = 1. virt. Kanal define <dimmerDevice>_SW_V1 CUL_HM 1C062D02 <= 1C062D + 02 = 2. virt. Kanal define <dimmerDevice>_SW_V2 CUL_HM 1C062D03 <= 1C062D + 03 = 3. virt. Kanal
(die Anmerkungen oben ab "<= ...." bitte nicht einfügen).
Danach "save"n Sie ihre fhem.cfg und machen zumindest ein rereadcfg. Jetzt sehen Sie die virtuellen Kanäle und können ihre ersten Versuche mit den virtuellen Kanälen nach dem o.a. Artikel starten (so Sie entsprechende Aktoren besitzen).
Anmerkung: Zwischenzeitlich ist eine Änderung vorgenommen worden. Mittels des Kommandos
set <dimmerDevice> regSet intKeyVisib visib
können die virtuellen Kanäle sichtbar gemacht werden.
Kommando zurück lautet:
set <dimmerDevice> regSet intKeyVisib invisib
Damit werden die virtuellen Kanäle wieder versteckt bzw. unsichtbar gemacht.
Action Detector - Batteriebetriebene HomeMatic-Geräte
In Fhem ist für batteriebetriebene HomeMatic-Geräte ein sogenannter Action-Detector integriert. Dieser ist dazu gedacht festzustellen, wenn ein batteriebetriebenes Gerät ausfällt ohne noch Zeit für die Meldung "Battery low" gehabt zu haben.
Der Eintrag in diese Überwachung erfolgt bei eingeschaltetem autocreate automatisch, kann alternativ aber durch das Attribut actCycle (siehe commandref) explizit gesetzt werden (sogar für nicht batteriebetriebene Geräte). Bei 'allen Geräten sollte dann aber auch das Register cyclicInfoMsg auf on gesetzt sein (siehe oben unter Three State Sensor).
Burst-Modus
Näheres zum Burst-Modus lesen Sie bitte hier.
Tipps / HowTos / Beispiele
- HM Devices pairen zum Pairen der Geräte untereinander.
- CUL (also gleichzeitig)?
- Slider für HM-Rolladensteuerung anzeigen
- Für den "Fall der Fälle": Erstellen Sie eine Liste aller HM-Geräte mit den Installationsorten, HM-Namen, Fhem-Namen und den Geräte-IDs. Falls Sie sich ihr Fhem einmal zerschießen, wird diese Liste sehr hilfreich sein. Zur Abwicklung von Gewährleistungsansprüchen sind Daten über Kaufdatum und Lieferant (bei größeren Installationen mit Zukauf in zeitlichen Abständen) ebenfalls angebracht.
Probleme
Notifys und anderes funktionieren nach einem Fhem-Neustart nicht mehr oder nicht mehr zeitnah
Im Logfile von Fhem erscheint nach einem Neustart die Meldung
2013.10.03 13:41:18 2: HMLAN_Parse: HMLAN1 new condition ERROR-Overload
Wenn Sie schon mehrere HomeMatic-Geräte haben und (seit Mitte Oktober 2013) ein Fhem-Update durchgeführt haben, wird / wurde das Attribut autoReadReg (sofern es noch nicht gesetzt war) auf "4_reqStatus" gesetzt. Damit wird für jedes HM-Device mit diesem so gesetzten Attribut beim Fhem-Start ein getConfig durchgeführt. Dies kann dazu führen, dass insgesamt zu viel Funklast vom HMLAN erzeugt wird. Diese Last ist aber begrenzt und wird vom HMLAN bei Überschreitung mit der o.a. Meldung quittiert. Ab diesem Moment werden eben auch keine anderen Befehle mehr an weitere HM-Geräte geschickt. Nach ca. 1 Stunde sollte der Spuk vorbei sein. Als Notbehelf können Sie auch den HMLAN kurz von der Spannungsversorgung trennen. Dann wird der Zähler wieder auf Null gesetzt.
Um solche Vorfälle für die Zukunft zu minimieren oder auszuschließen, sollten Sie so viele HM-Geräte wie möglich auf autoReadReg 0_off setzen.
Spannungsversorgung
Bisherige Erfahrungen mit einigen HM-CC-TC, HM-SEC-SC und HM-CC-VD über nun ca. 13 Monate zeigen durchwachsene Erfahrungen mit der Haltbarkeit der in diesen HM-Geräten eingesetzten Batterien (Mignon/AA bzw. LR44). Einige ab Werk mitgelieferte Batterien hatten bereits direkt bei Wareneingang eine bedenklich niedrige Spannung und wurden direkt ersetzt, andere gaben nach drei bis vier Wochen "den Geist auf".
Insgesamt kann man von ca. 12 Monaten ausgehen, was die ausreichende Spannungslage in den batteriebetriebenen HM-Geräten anbelangt. Obwohl die Aktoren und Sensoren eine battery low Meldung erzeugen sollten, wenn die Spannung zu gering ist, ist dies hier bisher nur einmal vorgekommen (an einem HM-Sec-SC). Meistens hat sich eine zu niedrige Spannung in einer Störung des Funkverkehrs geäußert (blinkendes Antennensymbol im HM-CC-TC und kurzes piepen zur vollen Stunde von morgens bis abends).