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, die FHEM SW und ein IO-Device. HM bietet wired und Funk Systeme an.
Geeignete IOs für HM-Funk sind CUL oder HMLAN Konfigurator. Einige Vor- bzw. Nachteile dieser Funkschnittstellen werden im Artikel HMLAN Konfigurator beschrieben. Im Anhang findet sich ein Teil über den Aufbau und die Funktion von HM Geräten. Dies wird hier kurz angerissen, die Kenntniss des Dokumentes "Heimautomatisierung-mit-fhem" wird vorausgesetzt.

Vorteile von FHEM gegenüber 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

Einrichten des IO-Devices (Funkschnittstelle)

Zuerst muss ein IO-Device eingerichtet werden, um mit HM Geräten kommunizieren zu können. Siehe hierzu HMLAN Konfigurator.

Struktur von HM Geräten

HM Geräte sind logisch in ein Device und ein oder mehrere Kanäle gegliedert. Jedes Device und jeder Kanal (Channel) wird in einer Entity in FHEM repräsentiert.
Ausnahme: Sollte ein Gerät nur einen Kanal haben wird dieser in einer Entity mit dem Device eingerichtet.

Device

Das Device ist für die Kommunikation verantwortlich. Es sortiert und ordnet die zu sendenden und empfangenden Nachrichten. Man kann prüfen, ob alle Nachrichten übertragen sind, oder ob es Probleme gegeben hat. Die Variablen "prot..." geben Auskunft darüber. Siehe auch Homematic_HMInfo#protoEvents. Zu beachten sind zudem die Übertragungsmodi. Nicht alle Devices sind ständig auf Empfang - FHEM muss berücksichtigen, wann gesendet werden kann. In protState kann man sehen, ob Kommandos auf Verarbeitung warten, also pending sind. Einige Devices unterstützen mehrere Modi parallel.

Config

Wird von allen Devices unterstützt, auch wenn es bei Always kaum genutzt werden kann. Man setzt die Kommandos in FHEM ab und diese warten in der Kommando-queue. Wenn die config-funktion am Device ausgelöst wird (Anlerntaste drücken) sendet FHEM die wartenden Nachrichten der Reihe nach. Config wird bei allen Devices zum pairen genutzt.

Always

Trifft man meist bei netzbetriebenen Geräten an, da diese kein Problem mit dem Energieverbrauch haben. Man kann immer mit dem Device kommunizieren.

Burst

Nur der Empfänger des Device ist aktiv. Über eine Aufweck-sequenz kann das Device geweckt werden. Man kann quasi immer mit dem Device kommunizieren. Nachteil des Aufwecken ist zum Einen, dass immer ALLE Devices im Funknetz geweckt werden, was deren Batterie belastet. Zum Andere ist die Aufweck-sequenz funktechnisch aufwändig und belastet die maximal erlaubte Sendekapazität des IO device je Stunde.

ConditionalBurst

Bei einigen Devices kann man den Burst mode zuschalten. Dies sind Devices, die zusätzlich über andere modi verfügen, so z.B. wakeup. Schaltet man burst-empfang ein kann man immer und sofort mit dem Device reden, es kostet aber etwas mehr Batterie. Siehe hierzu Attribut burstAccess, Kommando burstXmit und Register burstRx

LazyConfig

Kommandos in der Queue werden bearbeitet, wenn eine Aktion vom Device ausgeht. So zum Beispiel ein Tastendruck bei einer Fernbedienung. Dieser mode wird von CUL/CUNO nicht unterstützt. FHEM ignoriert diese Option automatisch und wartet i.a. auf ein Config.

Wakeup

Die Devices wachen regelmäßig auf und senden Daten, z.B. Temperatursensoren. Zu diesem Zeitpunkt kann FHEM die Nachrichten übertragen. Die Aufwachperiode ist unterschiedlich von 3 min bis zu 24h.

Kanal

Ein Kanal ist die Funktionseinheit des Geräts. Hier ist die Funktion des Sensors oder Aktors realisiert.

Variablen

Wie alle FHEM Entities werden 4 Gruppen von Daten unterstützt:

• Internals: Im Web-Interface sichtbare Variablen, die allgemeine Informationen über den Zustand enthalten.
• Readings: Im Web-Interface sichtbare Variablen. Sie werden aus von Entites empfangenen Nachrichten generiert. Man kann mit notify Trigger auf die setzen. Readings werden im Statefile bei save und gewissen neustarts gesichert und beim Booten eingelesen. Readings haben einen Zeitstempel.
• Attribute: Im Web-Interface sichtbare Variablen. Über sie kann man die Eigenschaften der Entity in FHEM steuern.
• Helper: Im Web-Interface nicht sichtbare Variablen. Man kann sie mit dem Kommando 'list' sehen. Es sind hilfsvariablen, die für den User keine Bedeutung haben sollen.

Internals

Viele Variablen sind nicht HM spezifisch - deren Bedeutung muss in allgemeinen Teil nachgelesen werden. Spezifische Variablen sind:

• Device
  • channel_xx: Liste der Kanäle, die dem Device zugeordnet sind.
  • prot... : Gruppe von Daten zum Zustand des Protokolls, also der Kommunikation mit dem Device.
  • rssi...: Gruppe von Daten die den Empfangspegel des Device bei IOs, Peers und Repeatern darstellt.

• Kanäle
  • device: Das übergeordnete Device
  • chanNo: Die Kanalnummer
  • peerList: Ist die Entity mit einem anderen gepeert ist steht hier der Name der Peers. Siehe auch attribut peerIDs und Reading peerList. Diese Variable ist mit dem peer verlinkt, man kann darauf 'clicken'.

Readings

Readings für HM Entites unterliegenden allgemeinen FHEM Regeln. Generell gilt, dass ein Wert, der von FHEM gesetzt wurde mit dem prefix "set_" versehen wird. Wenn der Zustand bestätigt ist wird das set_ entfernt. Sollte man also ein Reading mit diesem prefix haben, das sich nicht selbst entfernt sollt man unbedingt den Zustand kontrollieren.
So ist nach einem "set Licht on" der Zustand des Licht erst einemal "set_on". Mit der Antwort des Device wird es dann auf "on" gesetzt.
Register machen eine Ausnahme:

Register

Register sind Konfigurationsparameter, die im Device flash gespeichert werden. Daten, die Registern zureordnet sind beginnen mit "R-". Sollte das Register einem peer zugeordnet sein kommt dieser danach. Der Namen ist also R-<peer>-<registerName>
Der Zugriff ist indirekt, geht also nur über Methoden und Kommandos. Man kann die Konfiguration (Register und peers) mit getConfig aus dem Device lesen und in FHEM dargestellen. FHEM bemüht sich, die angezeigten Register aktuell zu halten - der User muss aber ein gewisse Vorsicht im Umgang damit walten lassen. Register können mit regSet gesetzt werden. Ob die gelesenen Register komplett sind prüft configCheck. Da einige Entities viele Register haben kann man mit dem Attribut expert die Sichtbarkeit steuern.
siehe auch register.
Von einigen Devices sind Register schwer zu lesen, z.B. config devices. Man kann die Register-Readings archivieren und beim reboot wieder laden.

Attribute

Attribute sind i.a. Parameter, die das Verhalten der Entity steuern. Sie werden mit save in fhem.cfg oder einem seiner subfiles gespeichert. Nach einer Änderung sollte der User ein "save" machen, sonst sind diese nach einem Reboot verloren.
Hier werden nur HM spezifische Attribute besprochen.
Attribute, die das System automatisch anlegt. Sollten diese nicht mehr stimmen kann der User anlernen am Device drücken und sie werden wieder hergestellt. Der User sollte sie nicht ändern.

• model
• subType
• peerIDs: HMIds der peers. Wird gelegentlich verschoben!
• serialNr: auslaufend - durch Reading D-serianNr ersetzt
• firmware: auslaufend - durch Reading D-firmware ersetzt

Attribute für HM Entities, die der User steuern kann

• webCmd: FHEM setzt ggf. einen Default, der User kann dies anpassen
• expert: schaltet mehr oder weniger Readings sichtbar - dient der Übersichtlichkeit des Web-Interface.
• autoReadReg: steuert das automatische Lesen der Konfiguration - ggf. zeitverzögert um Resourcen zu schonen. Es wird Level 5 empfohlen

Attribute für HM Entities am Device, die der User steuern kann

• msgRepeat: kann man im Device einstellen. Es legt fest wir oft eine Nachricht wiederholt werden soll, falls sie nicht empfangen wird. Beachte, dass unabhängig davon ein HMLAN/USB immer 3-mal probiert zu senden. Insbesondere bei Burst Devices sollte man einen niedrigen level einstellen.
• IODev: Sollte man auf das IO device setzen, über das zu diesem Device gesendet werden soll. Es wird i.a. beim Pairen gesetzt.

Empfohlene Attribute außerhalb von HM

• event-on-change-reading .*

Kommandos

Allgemein

• get <name> cmdList # zeigt alle Kommandos mit Parametern für diese Entity an
• clear [readings|register|rssi|msgEvents] # löschen von Readings oder Zählern

Register kommandos

• set <name> getConfig # liest alle Peers und Register. Auf ein Device angewendet werden ALLE channels auch gelesen
• set <name> regSet [prep|exec] <regName> <value> ... [<peerChannel>] #schreiben eines Registerwerts. Das Kommando landet im Kommandstack
• set <name> regbulk ...# kommando zum setzen von rohdaten und ganzen Registerlisten. Ausser zum re-configurieren eines ganzen Device eher nicht für den User zu gebrauchen

• set <name> sign [on|off # setzt das Register um AES einzuschalten. Man sollte sich über AES vorher einlesen!!

• get <name> regList # zeigt alle Register, die diese Entity unterstützt - incl Beschreibung und Wertebereich. Als Anfänger sollte man einmal hinsehen!
• get <name> reg all # zeigt alle Register, die diese Entity hat und den aktuellen Wert

Kommunikation

Die Kommunikation zwischen Device und der Zentrale folgt einem Protokoll. Für die meisten Nachrichten erwartet der Sender eine Empfangsbestätigung. FHEM beachtet das Protokoll und implementiert es entsprechend der Fähigkeiten des IO device.
Grundsätzlich kann jedes Device an jedes andere Nachrichten senden. Damit dies auch einen erfolg hat, müssen die Kanäle gepeert werden.
Um FHEM zu erlauben, Nachrichten an das Device zu richten muss FHEM gepairt werden.
Das Senden der Nachrichten macht IMMER das Device - ein Kanal selbst kann nicht wirklich senden.

Protokoll

Da für das Senden das Device verantwortlich ist sind hier die entsprechenden Informationen zu finden. Zu Beachten sind die Übertragungsmodi, die ein Device unterstützt. Die Internals "prot..." enthalten alle notwendigen Daten.

• protState: Der Zustand der Protokollmaschine
  • CMDs_done: alle Nachrichten übertragen, eine Fehler in diesem Durchgang aufgetreten
  • CMDs_done_Error:xx : es hat xx Fehler bei der letzten Übertragung gegeben.
  • CMDs_pending: Nachrichten warten auf das Senden
  • CMDs_processing... : die Nachrichtenübertragung ist im Gange
  • Info_Cleared: die Protokoll Statistik wurde rückgesetzt
• protCmdPend: Anzahl der Nachrichten, die auf das Senden warten
• protCmdDel: Anzahl gelöschter Nachrichten aufgrund von Fehlern
• protCmdNack: Anzahl der negativen Acknowledges
• protCmdResnd: Anzahl der Wiederholungen - die Nachrichten wurden nicht gelöscht.
• protCmdResndFail: Anzahl der fehlgeschlagenen Wiederholungen - die Nachrichten wurden gelöscht.
• protCmdIOerr: Anzahl der IO Fehler - Übertragung war nicht Möglich, weil das IO Device Probleme hatte. Der Grund sollte im IO Device nachgesehen werden.
• protCmdIOdly: Anzahl der Verzögerungen aufgrund von IO Problemen
• protCmdTimedOn: Anzahl der Nachrichten, wenn ein Timer im Device genutzt wird - z.B. durch on-for-timer
• protCmdRcv: Anzahl empfangene Nachrichten
• protCmdSnd: Anzahl gesendete Nachrichten
• protCmdErrIoId_...: Anzahl der Sendeversuche zum Device von einer anderen Zentrale
• protCmdErrIoAttack: Anzahl der Sendeversuche zum Device die nicht von FHEM kam- es könnte ein Versuch sein, das System zu hacken. Dies wird auch im Reading sabotageAttack ausgegeben und man kann ein notify darauf ansetzen.

• protCmdEvt_AESCom: Anzahl der AES Nachrichten von Device
• protCmdEvt_AESKey: Benutzter AES key

Die Zähler können mit set <device> clear msgEvents rückgesetzt werden. Dies kann vor Konfigurationsänderungen Sinn machen, um Probleme besser erkennen zu können.
Eine Übersicht kann man mit HMInfo protoEvents erhalten. Auch das Löschen aller Zähler ist von HMInfo aus möglich.

Rssi

Zeigt den Empfangspegel, den ein Device von einem Anderen misst. Die Variablen sind in Internals abgelegt. Angegeben werden minimale und maximale Wert. Außerdem wird der Durchschnitt und die Anzahl der Nachrichten ausgewertet.
HM liefert Empfangspegel am IO Device (FHEM standard) aber auch den Empfangspegel am Device selbst. Ebenfalls ausgewertet werden Pegel, welche beim Senden zwischen Peers erreicht werden.
Die Zähler können mit set <device> clear rssi rückgesetzt werden.
Eine Übersicht erkält man mit HMInfo Rssi. Das Löschen der Zähler aller HM devices ist von HMInfo aus möglich.

Man kann RSSI kontinuierlich aufzeichnen, wenn das Attribut rssiLog im Device gesetzt ist. Es wird ein Reading rssi_<name> erzeugt. Das generelle setzen dieses Attributs wird aus Performance-gründen nicht empfohlen.

Pair / Peer bzw. pairen und peeren

HM Geräte können mit und ohne Zentrale betrieben werden. In FHEM wird davon ausgegangen, dass Geräte immer von einer Zentrale aus gesteuert werden können. Um dies zu erreichen muss das Device mit der Zentrale gepairt werden.

=> Devices Pairen

Um einen Betrieb (auch)ohne Zentrale zu ermöglichen kann man Kanäle peeren. Hier bei wird ein Sensor-Kanal mit einem Aktor-Kanal verknüpft werden. siehe Channels peeren für Details.

HMInfo

Mit HMInfo kann man eine Übersicht der HM Installation erhalten, Konfiguration prüfen und Alarme gesammelt auswerten.

Besondere Entites

Virtuelle Entities

Virtuelle Entities sind nicht reale HM Devices und Kanäle. Man kann sie als Sender und Empfänger nutzen, auch im Zusammenhang mit Rauchmeldern oder zur Steuerung von Heizungsventilen. Die spezifischen Anwendungen sind im entsprechenden Kapitel nachzulesen.
Angelegt wird das Device, dann wird per Kommando eine Anzahl Kanäle angelegt.

 define <virtDev> CUL_HM 112233
 set <virtDev> virtual 10

jetzt hat man ein virtuelles Device mit 10 Kanälen angelegt. Die die gültigen Kommandos kann man wie immer mit get <entity> cmdList erfahren.
Auch einem Virtuellen Device sollte man das Attribut IODev setzen .

IO Entities

Analog virtuellen Entities kann man auch IO entities erzeugen. IO ist nicht ganz korrekt, eigentlich sind es Kanäle einer Zentrale. Da diese in FHEM nicht abgebildet wird sind sie teilweise in den IOs realisiert.
Faktisch ist es ein Kanal, der der HMId des gewählten IO device zugeordnet ist. Aktuell wird dieser Kanal nicht in FHEM dargestellt. Man kann diese Entity jedoch peeren.
Man kann jeder HMId bis zu 50 Kanäle zuweisen. Da mehrere IO devices die gleiche HMId nutzen können, teilen sich diese in diesem Fall die Kanäle.

Action Detector

Einige Devices in der HM serie senden periodisch Nachrichten. Manche alle 3 min, andere alle 3 Tage. Wenn so eine Zeit für einen Device spezifiziert ist wird diese automatisch vom ActionDetector überwacht.
Meist sind dies batteriebetriebene Geräte. Sollte aus irgendwelchen Gründen der Batteriealarm übersehen werden und das Gerät keine Nachricht mehr senden wird es auf Dead gesetzt.

• attribut
  • actCycle: gibt an, in welchen Abständen sich das Device melden muss
  • actStatus: gibt den Zustand an
    • alive: Device hat sich in der erwarteten Zeit min einmal gemeldet
    • dead: Device hat sich in der erwarteten Zeit nicht gemeldet
    • unknown: Device hat sich nicht gemeldet, es ist aber seit dem letzten reboot die Zykluszeit noch nicht abgelaufen.

• readings
  • Activity: entsprechend dem actStatus.

• get
  • listDevice: Gibt alle Objekte zurück
  • listDevice notActive: Gibt alle Objekte zurück die nicht "alive" sind
  • listDevice alive: Gibt alle Objekte zurück die "alive" sind
  • listDevice unknown: Gibt alle Objekte zurück die "unknown" sind
  • listDevice dead: Gibt alle Objekte zurück die "dead" sind

In der Entity actionDetector kann man die Infos gesammelt einsehen.
Der User kann durch das Setzen des Attributs actCycle jedes Device in diese Liste aufnehmen. Es wird dann geprüft, ob sich das Device in dieser Zeit auch meldet. Der User muss dies aber selbst sicherstellen.

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

Messages Sniffen

Um Probleme besser nachvollziehen zu können, kann man Nachrichten mitsniffen

Daten können empfangen werden, Befehle werden nicht übertragen

Das kann mehrere Ursachen haben:

• Pairing nicht abgeschlossen (bei den Readings "PairedTo" bzw. "R-pairCentral" steht der Wert set_0x1A2B3C). Das Pairing ist erst dann erfolgreich abgeschlossen, wenn das set_ fehlt, also nur noch (beispielhaft) "0x1A2B3C" steht. Siehe HomeMatic_Devices_pairen
• Sender (CUL/HM-LAN) und Empfänger (HM-Device) stehen zu nah (RSSI-Werte bei ~ "-17") beieinander
• Sender (CUL/HM-LAN) und Empfänger (HM-Device) stehen zu weit (RSSI-Werte bei unter ~ "-80") voneinander entfernt
• ...

Notifys und anderes funktionieren nach einem Fhem-Neustart nicht mehr oder nicht mehr zeitnah

Obwohl HomeMatic wegen der höhren Datenübertragungsrate wesentlich weniger von der 1% Regel betroffen ist als z.b. FS20 oder FHT, so kann es dennoch zu Funkkontingentüberschreitungen kommen.

Insbesondere ist bei FHEM Versionen ab Oktober 2013 das Attribut autoReadReg auf "4_reqStatus" gesetzt. Damit wird für jedes HM-Device mit diesem so gesetzten Attribut beim Fhem-Start ein getConfig durchgeführt, was viel Funkverkehr erfordert.

Je nach Anzahl der Geräte kann dazu führen, dass insgesamt zu viel Funklast erzeugt wird, im Logfile erscheint dann eine Meldung wie:

2013.10.03 13:41:18 2: HMLAN_Parse: HMLAN1 new condition ERROR-Overload

Ab diesem Moment werden eben auch keine anderen Befehle mehr an weitere HM-Geräte geschickt, da das Funkkontigent aufgebraucht ist. Erst nach einer Stunde kann erneut gesendet werden. Als Notbehelf kann die Funkschnittstelle resetted oder (HMLAN Konfigurator) kurz stromlos gemacht werden. Dann wird der Zähler wieder auf Null gesetzt.

Alternativ können so viele HM-Geräte wie möglich auf autoReadReg 0_off gesetzt werden.

Siehe auch: 1% Regel

Spannungsversorgung

Die Batterielebensdauer der HomaMatic Komponenten ist durchwachsen. Besonders die mitgelieferten Batterien sind mitunter schon nach wenigen Wochen leer, trotzdem werden öfters keine battery low Meldung erzeugt. Bei Störung des Funkverkehrs (z.b. blinkendes Antennensymbol im HM-CC-TC und kurzes piepen zur vollen Stunde von morgens bis abends, fehlende ACK Meldungen, nicht auslösende IR-Bewegungssensoren und ähnliches) sollte also immer auch eine schlechte Spannungsversorgung in Betracht gezogen werden.

Gute neue Batterien halten jedoch i.d.R. 12 Monate und mehr, auch Lebensdauern über 2 Jahre sind bei einigen Geräten (Tür/Fensterkontakte, Sender, Retroanzeige, IR-Bewegungsmelder) keine Seltenheit.

Links

• HomeMatic Homepage
• Hersteller eQ-3