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 funksysteme sind CUL oder HMLAN Konfigurator. Im HMLAN wird auf ein paar Unterschiede hingewiesen bitte beachten. Es wird geraten für den generellen Betrieb von FHEM das Einsteiger Dokument zu lesen. Im Anhang findet sich ein Teil über den Aufbau und die Funktion von HM Geräten. Dies wird hier kurz angerissen.

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

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.

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.

Einstellungen

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
• serialNr
• firmware
• peerIDs
• .devInfo

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.

Empfohlene Attribute ausserhalb von HM

• event-on-change-reading .*

Register

Register sind Konfigurationsparameter, die in dem Device flash gespeichert werden. Der Zugriff ist indirekt, geht also nur über Methoden und Kommandos. Man kann die Konfiguration auslesen mit getConfig. In FHEM werden die Inhalte dann dargestellt. 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.

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

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 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.

Aktoren / Sensoren

Eine Übersicht und weitere Informationen über die von FHEM unterstützten HM-Geräte erreichen Sie über HMInfo.

Attribute / 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:

• HM-Sec-WDS Funk-Wassermelder
• HM-SEC-SC Tür-Fensterkontakt
• HM-Sec-RHS
• ...

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

Messages Sniffen

Um Probleme besser nachvollziehen zu können ist 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

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).

Links

• HomeMatic Homepage
• Hersteller eQ-3