FHEMWiki - Benutzerbeiträge [de]

FileLog

2019-12-27T01:57:28Z

Cori: Attr ignoreRegexp für global ergänzt

{{Infobox Modul
|ModPurpose=Protokollierung von Fhem-Ereignissen
|ModType=h
|ModForumArea=Automatisierung
|ModTechName=92_FileLog.pm
|ModOwner=rudolfkoenig ({{Link2FU|8|Forum}} / [[Benutzer Diskussion:Rudolfkoenig|Wiki]])}}

Das Modul [[FileLog]] dient zur Protokollierung von Ereignissen in Fhem. Die Einträge werden in eine einfache Textdatei geschrieben. Zur Protokollierung in eine Datenbank kann alternativ oder auch parallel das Modul [[DbLog]] verwendet werden.

Logdateien sind die Basis für die Erstellung von Diagrammen ([[SVG]]).

== Definition ==
Details in der {{Link2CmdRef|Anker=FileLogdefine}}.

== Attribute ==
Über {{Link2CmdRef|Anker=FileLogattr|Label=Attribute}} lässt sich unter anderem auch festlegen, wie die Archivierung von Logdateien durchgeführt werden soll (Archivierungsbefehl, -pfad sowie Anzahl von Archivgenerationen).

Wenn bestimmte Zeilen '''nicht''' in die Logdatei geschrieben werden sollen, ist das Attribut ''ignoreRegexp'' hilfreich. Wenn beispielsweise alle Zeilen, die die Zeichenfolge "AbCd" oder "CdEf" enthalten '''nicht''' geloggt werden sollen, dann wäre
:<code>attr <log-name> ignoreRegexp .*AbCd.*|.*CdEf.*</code>
eine Attributdefinition, die das ermöglicht.

Dies bezieht sich aber nur auf normale FileLog-Instanzen. Falls Events aus dem globalen FHEM-Logfile ausgeschlossen werden sollen, muss man das Attribut in '''global''' angeben. (Zusammenhang siehe [[#Globale Logdatei und "fakelog"|Globale Logdatei und "fakelog"]])
:<code>attr global ignoreRegexp .*AbCd.*|.*CdEf.*</code>

== Funktionen ==
''FileLog'' bietet Funktionen wie ''reopen'', ''absorb'' und ''get''. Details dazu sind in der {{Link2CmdRef|Anker=FileLogset}} zu finden.

Sofern eine Instanz vom Objekt [[eventTypes]] angelegt ist, bietet die Detailansicht eines FileLog eine komfortable Möglichkeit, die regulären Ausdrücke für den/die Filter zu bearbeiten. Siehe hierzu auch diesen {{Link2Forum|Topic=12557|Message=75436}}.

== Globale Logdatei und "fakelog" ==
Die globale Logdatei (üblicherweise als fhem.log bezeichnet) für Fhem wird mit dem Attribut
:<code>attr global logfile XXX</code>
für das ''global''-Objekt definiert, wobei für ''XXX'' normalerweise <code>./log/fhem-%Y-%m.log</code> verwendet wird.

Um das ''fhem.log'' über das [[FHEMWEB|Web Interface]] anzeigen zu können, ist ein weiterer Eintrag in der [[Konfiguration]] erforderlich, nämlich:
:<code>define Logfile FileLog XXX fakelog</code>
Das ''XXX'' muss '''zwingend''' durch den gleichen Wert ersetzt werden, wie in der Definition des globalen ''logfile'' Attributs, weil anderenfalls unterschiedliche Dateien verwendet werden - mit dem Effekt, dass die über das Web Interface angezeigte Datei nicht die erwarteten Einträge enthält (Details dazu auch in diesem {{Link2Forum|Topic=40041|Message=323315|LinkText=Forenbeitrag}}).

== Werte auslesen ==
Manchmal möchte man Daten aus den Logs abrufen ohne händisch in den Logfiles herumzuwühlen. Dies ist insb. auch dann hilfreich, wenn man eigenen Funktionen, Notifys oder spezielle Plots entwirft, bei denen man auf Logdaten zugreifen möchte.

Grundsätzlich beschrieben ist dies in der {{Link2CmdRef|Lang=de|Anker=FileLog}} und unterscheidet sich minimal (aber entscheidend) von der Struktur bei [[DbLog#Werte_auslesen|DbLogs]].

Hier ein paar Beispiele, was man damit anstellen kann:

* <code>get FileLog_FHT_3a32 - - 2016-10-01 2016-10-03</code> alle Einträge des FileLog_FHT_3a32 vom 01.10.-03.10.2016
* <code>get FileLog_FHT_3a32 - - 2016-10-01_08:00:00 2016-10-01_16:00:00</code> alle Einträge des FileLog_FHT_3a32 von 8-16 Uhr am 01.10.2016
* <code>get FileLog_FHT_3a32 - - 2016-10-01_08:00:00 2016-10-01_16:00:00 4:measured:0:</code> nur die Temperatur-Werte
* <code>{ ReadingsTimestamp("FHT_3a32","state","0") }</code> Timestamp des aktuellen state des FHT_3a32
* <code>{ OldTimestamp("FHT_3a32") }</code> Timestamp des letzten state des FHT_3a32
* <code>{ time_str2num(OldTimestamp("FHT_3a32")) }</code> Timestamp in Sekunden des letzten state des FHT_3a32
* ...
Weitere Beispiele kann man sich gut aus den SVG-Dateien ziehen.

== Links ==
* {{Link2Forum|Topic=40041|Message=323315|LinkText=Forenbeitrag}} zum Thema fhem.log / fakelog

[[Kategorie:Logging]]

HM-MOD-EM-8bit 3-Kanal-Sendemodul mit 8-Bit-Datenkanal

2018-01-16T20:36:40Z

Cori: /* Bekannte Probleme */ Leerzeichen zw. Kanalname und Befehl eingefügt

{{Infobox Hardware
|Bild=HM-MOD-EM-8bit.jpg
|Bildbeschreibung=3-Kanal-Sendemodul mit 8-Bit-Datenkanal
|HWProtocol=HomeMatic
|HWType=Sender (Sensor oder Remote)
|HWCategory=HomeMatic
|HWComm=Funk 868MHz
|HWChannels=3
|HWVoltage=2-3,3V bzw. 3,5-12V
|HWPowerConsumption=typisch 30 bzw. 60µA, bis 28mA (Sendevorgang)
|HWPoweredBy=Batterie oder Kleinspannung
|HWSize=42x22x12mm
|HWDeviceFHEM=[[CUL_HM]]
|HWManufacturer=ELV / eQ-3
}}


[[HM-MOD-EM-8bit]] ist ein Modul für eigene Hardware-Entwicklungen (ähnlich dem 8-Kanal-Sendemodul [[HM-MOD-EM-8]]) zum Übermitteln von Schaltbefehlen oder Kontaktzuständen

== Features ==
Offenes (gehäuseloses) Einbaumodul mit ingesamt 3 Eingangskanälen. Kanal 1 und 2 sind einkanalige Signaleingänge, anders als beim [[HM-MOD-EM-8]] fest als Taster-Interface (sendet Short- bzw. Long-Trigger) konfiguriert. Kanal 3 besitzt 8 Dateneingänge (Bits), deren Zustand zusammengefasst als ein Byte interpretiert und mit diesem Wert gesendet werden. Wann ein Wert gesendet wird, kann mit sieben verschiedenen Modi eingestellt werden, wahlweise unter Einbeziehung einer weiteren Signalleitung, die als Trigger- oder Freigabeleitung dient.

Alle Einzelleitungen können wahlweise als Taster bzw. Schalter gegen GND und/oder als spannungsempfindlicher Eingang (2-24V) beschaltet werden, ähnlich dem 8-Kanal-Modul [[HM-MOD-EM-8]]. Beide Möglichkeiten können gleichzeitig benutzt werden und sind intern ODER-verknüpft. Dabei ist zu beachten, dass im Auslieferungszustand die Datenleitungen wie auch die Freigabeleitung logisch negativ betrachtet werden, d.h. ein offener Anschluss wird als logisch HIGH interpretiert, der übermittelte Wert von 8 offenen Dateneingängen ist also insgesamt "FF". Für die acht Datenleitungen kann jedoch je Leitung festgelegt werden, ob der Signalpegel am Eingang invertiert interpretiert werden soll.

Das Modul ist in Grenzen pinkompatibel zum [[HM-MOD-EM-8]]. Dessen acht Eingangskanäle entsprechen nunmehr den Datenleitungen. Für die Datenübernahmeleitung sowie die zusätzlichen Tastereingänge (Kanal 1 und 2) als auch dem ebenfalls von außen steuerbaren Konfigurationstaster wurden zahlreiche bisher intern mit GND verbundenen Pins benutzt, so dass für GND jetzt nur noch Pin12 verfügbar ist. Stromversorgung und die Ausgänge der Statusleitungen (Status_R, Status_G, Status_S) sind unverändert.

'''Weitere technische Daten:'''

* Eingangsimpedanz der Spannungseingänge: 10 kOhm (und eine Basis-Emitter-Strecke eines Transistors)
* Mindestwerte für Eingänge für ein sicheres Erkennen: 5,6 µA (experimentell ermittelt) / 0,7 V / ca. 780 kOhm bei 5V
* Höchstwiderstand am Tastereingang: 33 kOhm (experimentell ermittelt)
* Gewicht: 8 g

Aktuelle Firmware: 1.0 (Stand Mai 2017)

== Hinweise zu Inbetriebnahme und Installation ==
Das Modul ist nur als ARR-Bausatz erhältlich (Stand Mai 2017). Es ist auf einer Leiterplatte mit Steckkontakten untergebracht, das auf eigene Schaltungen gesockelt werden kann. Es verfügt über insgesamt 12 Eingänge für Taster sowie 12 Eingänge für eine Spannung von 2-24V, die über Transistoren die Eingänge des Prozessors parallel zu den Tasteneingängen kurzschließen (ODER-Verknüpfung). Außerdem gibt es Ausgänge für drei Status-LEDs (rot, grün wie für HM als Sendequittung üblich sowie einen dritten Ausgang, der aktiv ist, solange das Modul selbst sendet). Das Gerät besitzt einen Konfigurationstaster und eine onboard-LED, die im Auslieferungszustand jedoch nur den Batteriestatus meldet (bei schwacher Batterie) und keine Sendedaten quittiert, um Strom zu sparen. Die LED kann aber über Register eingeschaltet werden und sendet dann wie üblich mit gelb und ggf. rot oder grün als Quittung.

Die Stromversorgung erfolgt über Batterie (2-3,3 V) oder Kleinspannung 3,5-12 V.

== Betrieb mit FHEM ==
Das Modul muss zur Pairen manuell in den Konfigurationsmodus versetzt werden (onboard-Taster), empfängt dann aber Konfigurationstelegramme im Zusammenhang mit Sendevorgängen, z.B. bei Statusänderungen an den Eingängen (sog. lazyConfig). Dies erleichtert die nachträgliche Konfiguration bereits eingebauter Module.
Das Anlernen erfolgt in FHEM wie üblich. Danach stellt das Gerät 3 Kanäle (_Btn_01 und _Btn_02 sowie _Tr) bereit. Alle drei können direkt mit anderen Aktoren gepeert oder FHEM-intern verarbeitet werden.

Der Übermittlungsmodus der Kanäle 1 und 2 ist auf "button" festgelegt und nicht änderbar, für Kanal 3 wird er mit dem Register <code>dataTransCond</code> bestimmt und ggf. mit dem Zeitregister <code>stabFltTime</code> ergänzt. '''Zu beachten ist, dass der Pegel der Eingänge "ungewohnt" behandelt wird: Ein Eingang wird als HIGH interpretiert, wenn er unbeschaltet ist (Taster offen oder keine Spannung angelegt), und als LOW wenn er mit Taster oder Spannung aktiviert ist.'''

Modus 1-3: Sendung bei Änderung des Pegels an DU30 (Taster-Eingang, offen=HIGH, geschlossen=LOW) bzw. Spannungseingang DUI30 (offen HIGH, mit Spannung LOW):
* Modus 1 (<code>lvlChng_H_L</code>): Senden bei Änderung HIGH->LOW
* Modus 2 (<code>lvlChng_L_H</code>): Senden bei Änderung LOW->HIGH
* Modus 3 (<code>lvlChng_any</code>): Senden bei HIGH->LOW und LOW->HIGH

Modus 4 und 6: Senden bei Änderungen einer oder mehrerer Datenleitungen, wenn diese länger als die "Datenstabilitätsfilterzeit" (<code>stabFltTime</code>) anliegen (bei kurzen Änderungen erfolgt keine Sendung - ähnlich dem <code>eventFilterTime</code> bei Sensoren: Sendung erst x Sekunden nachdem es eine Änderung gab)
* Modus 4 (<code>stbl4TimeEnable</code>): Sendung erfolgt wenn Datenübertragungseingang HIGH
* Modus 6 (<code>stbl4TimeDisable</code>): Sendung erfolgt wenn Datenübertragungseingang LOW

Modus 5 und 7: Senden sofort bei Änderung, danach Mindest-Wartezeit (ebenfalls <code>stabFltTime</code>, ähnlich dem <code>minInterval</code> etwa bei Bewegungsmeldern - Wartezeit nach Meldung einer Bewegung)
* Modus 5 (<code>sndImmediateEnable</code>): Sendung erfolgt wenn Datenübertragungseingang HIGH (bei LOW erfolgt keine Sendung)
* Modus 7 (<code>sndImmediateDisable</code>): Sendung erfolgt wenn Datenübertragungseingang LOW (bei HIGH erfolgt keine Sendung)

Beispiel: das Modul soll den Datenzustand 2 Sekunden nach der letzten Datenänderung an den Leitungen senden, wenn der Datenfreigabeeingang (DU30 oder DUI30) unbeschaltet ist (DUI30 darf auch auf GND liegen): 
<code>set ''<Name-des-Datenkanals>'' regSet dataTransCond stbl4Time'''Enable'''

set ''<Name-des-Datenkanals>'' regSet stabFltTime 2</code>.

Die acht Register <code>dInProp0</code> bis <code>dInProp7</code> legen zudem fest, ob der Eingang normal (Wert off = 0 bei Tasterbetätigung oder Spannung am Eingang) oder invertiert (Wert on = 1 bei Tasterbetätigung oder Spannung am Eingang) behandelt wird. So kann man zumindest bei den Dateneingängen die eher gewohnte Logik wiederherstellen.

Auf Device-Ebene lässt sich durch Setzen des Registers <code>ledMode</code> die onboard-LED für Sendequittungen ein- bzw. ausschalten: <code>set ''EM-8-Device'' regSet ledMode on</code> bzw. <code>off</code>.

Konfigurationen werden wie üblich per <code>set ''<Name-des-Gerätes-bzw-Kanals>'' regSet ''<Registername Wert>''</code> durchgeführt, wenn FHEM den aktuellen Status der Register besitzt, wozu ggf. zuvor ein <code>getConfig</code> ausgelöst werden muss. Zudem muss die Konfigurationstaste oder ein Eingang betätigt werden.

Will man eine reine binäre Auflistung der Eingänge, kann man folgendes Attribut für den 3. Kanal setzen: 
<code>attr ''<Name-des-Datenkanals>'' userReadings inputs {ReadingsVal($name,'state',0)=~/([0-9A-F]{2})/;reverse(sprintf("%08b",abs(hex($1)-255)))}</code> 
Dadurch wird ein neues Reading mit dem Namen ''inputs'' generiert, das die Zustände als 1 bzw. 0 anzeigt. Anzeige: <code>inputs 11000000</code> (Eingang 0 und 1 geschlossen) 
Die Auflistung erfolgt dabei in Lesereihenfolge, d.h. links ist Eingang 0 und rechts Eingang 7. Somit kann über ein einfaches <code>substr(ReadingsVal(''<Name-des-Datenkanals>'','inputs',0),x,1)</code> der Zustand des x-ten Einganges erfragt werden. 
''(Hinweis: Für eine einfache Lesbarkeit bedeutet 1 verbunden und 0 nicht verbunden, entgegen der Standardlogik des Bausatzes (siehe weiter oben). Die Formel für das UserReading funktioniert so nur, wenn die Standardeinstellungen für dInProp\d noch gelten. Ansonsten muss einfach die Subtraktion mit 255 entfernt werden.)''

== Bekannte Probleme ==
Derzeit (''Jan 18'') ist beim Register <code>stabFltTime</code> nur die Angabe vom Werten größer 10s möglich. Möchte man aber kleinere Werte benutzen, ist dies über ein <code>set ''<Name-des-Datenkanals>'' regBulk RegL_01 xxx</code> möglich. Dazu für xxx einfach (bei gesetztem ''expert 3_allReg+raw'') den Inhalt von ''RegL_01'' nehmen und zum Wert von ''B1'' die gewünschte Anzahl an Sekunden addieren/subtrahieren.

Ob die beim [[HM-MOD-EM-8]] vorhandenen Probleme beim Senden an Aktoren mit Burst sowie die hohe Funklast beim Durchkonfigurieren hier ebenfalls zu Problemen führen, muss noch untersucht werden.

== Links ==
* [https://files.elv.com/Assets/Produkte/15/1502/150253/Downloads/150253-HM-Mod-EM-8Bit_UM_160817_web.pdf Bedienungsanleitung bei ELV]
* {{Link2Forum|Topic=67333|LinkText=Diskussion im Forum}} (als das Modul neu war)

[[Kategorie:HomeMatic Components]]
[[Kategorie:Schalter (Sender)]]

HM-MOD-EM-8bit 3-Kanal-Sendemodul mit 8-Bit-Datenkanal

2018-01-16T20:34:46Z

Cori: Hinweis entfernt: Reg LED-Mode noch nicht funktional

{{Infobox Hardware
|Bild=HM-MOD-EM-8bit.jpg
|Bildbeschreibung=3-Kanal-Sendemodul mit 8-Bit-Datenkanal
|HWProtocol=HomeMatic
|HWType=Sender (Sensor oder Remote)
|HWCategory=HomeMatic
|HWComm=Funk 868MHz
|HWChannels=3
|HWVoltage=2-3,3V bzw. 3,5-12V
|HWPowerConsumption=typisch 30 bzw. 60µA, bis 28mA (Sendevorgang)
|HWPoweredBy=Batterie oder Kleinspannung
|HWSize=42x22x12mm
|HWDeviceFHEM=[[CUL_HM]]
|HWManufacturer=ELV / eQ-3
}}


[[HM-MOD-EM-8bit]] ist ein Modul für eigene Hardware-Entwicklungen (ähnlich dem 8-Kanal-Sendemodul [[HM-MOD-EM-8]]) zum Übermitteln von Schaltbefehlen oder Kontaktzuständen

== Features ==
Offenes (gehäuseloses) Einbaumodul mit ingesamt 3 Eingangskanälen. Kanal 1 und 2 sind einkanalige Signaleingänge, anders als beim [[HM-MOD-EM-8]] fest als Taster-Interface (sendet Short- bzw. Long-Trigger) konfiguriert. Kanal 3 besitzt 8 Dateneingänge (Bits), deren Zustand zusammengefasst als ein Byte interpretiert und mit diesem Wert gesendet werden. Wann ein Wert gesendet wird, kann mit sieben verschiedenen Modi eingestellt werden, wahlweise unter Einbeziehung einer weiteren Signalleitung, die als Trigger- oder Freigabeleitung dient.

Alle Einzelleitungen können wahlweise als Taster bzw. Schalter gegen GND und/oder als spannungsempfindlicher Eingang (2-24V) beschaltet werden, ähnlich dem 8-Kanal-Modul [[HM-MOD-EM-8]]. Beide Möglichkeiten können gleichzeitig benutzt werden und sind intern ODER-verknüpft. Dabei ist zu beachten, dass im Auslieferungszustand die Datenleitungen wie auch die Freigabeleitung logisch negativ betrachtet werden, d.h. ein offener Anschluss wird als logisch HIGH interpretiert, der übermittelte Wert von 8 offenen Dateneingängen ist also insgesamt "FF". Für die acht Datenleitungen kann jedoch je Leitung festgelegt werden, ob der Signalpegel am Eingang invertiert interpretiert werden soll.

Das Modul ist in Grenzen pinkompatibel zum [[HM-MOD-EM-8]]. Dessen acht Eingangskanäle entsprechen nunmehr den Datenleitungen. Für die Datenübernahmeleitung sowie die zusätzlichen Tastereingänge (Kanal 1 und 2) als auch dem ebenfalls von außen steuerbaren Konfigurationstaster wurden zahlreiche bisher intern mit GND verbundenen Pins benutzt, so dass für GND jetzt nur noch Pin12 verfügbar ist. Stromversorgung und die Ausgänge der Statusleitungen (Status_R, Status_G, Status_S) sind unverändert.

'''Weitere technische Daten:'''

* Eingangsimpedanz der Spannungseingänge: 10 kOhm (und eine Basis-Emitter-Strecke eines Transistors)
* Mindestwerte für Eingänge für ein sicheres Erkennen: 5,6 µA (experimentell ermittelt) / 0,7 V / ca. 780 kOhm bei 5V
* Höchstwiderstand am Tastereingang: 33 kOhm (experimentell ermittelt)
* Gewicht: 8 g

Aktuelle Firmware: 1.0 (Stand Mai 2017)

== Hinweise zu Inbetriebnahme und Installation ==
Das Modul ist nur als ARR-Bausatz erhältlich (Stand Mai 2017). Es ist auf einer Leiterplatte mit Steckkontakten untergebracht, das auf eigene Schaltungen gesockelt werden kann. Es verfügt über insgesamt 12 Eingänge für Taster sowie 12 Eingänge für eine Spannung von 2-24V, die über Transistoren die Eingänge des Prozessors parallel zu den Tasteneingängen kurzschließen (ODER-Verknüpfung). Außerdem gibt es Ausgänge für drei Status-LEDs (rot, grün wie für HM als Sendequittung üblich sowie einen dritten Ausgang, der aktiv ist, solange das Modul selbst sendet). Das Gerät besitzt einen Konfigurationstaster und eine onboard-LED, die im Auslieferungszustand jedoch nur den Batteriestatus meldet (bei schwacher Batterie) und keine Sendedaten quittiert, um Strom zu sparen. Die LED kann aber über Register eingeschaltet werden und sendet dann wie üblich mit gelb und ggf. rot oder grün als Quittung.

Die Stromversorgung erfolgt über Batterie (2-3,3 V) oder Kleinspannung 3,5-12 V.

== Betrieb mit FHEM ==
Das Modul muss zur Pairen manuell in den Konfigurationsmodus versetzt werden (onboard-Taster), empfängt dann aber Konfigurationstelegramme im Zusammenhang mit Sendevorgängen, z.B. bei Statusänderungen an den Eingängen (sog. lazyConfig). Dies erleichtert die nachträgliche Konfiguration bereits eingebauter Module.
Das Anlernen erfolgt in FHEM wie üblich. Danach stellt das Gerät 3 Kanäle (_Btn_01 und _Btn_02 sowie _Tr) bereit. Alle drei können direkt mit anderen Aktoren gepeert oder FHEM-intern verarbeitet werden.

Der Übermittlungsmodus der Kanäle 1 und 2 ist auf "button" festgelegt und nicht änderbar, für Kanal 3 wird er mit dem Register <code>dataTransCond</code> bestimmt und ggf. mit dem Zeitregister <code>stabFltTime</code> ergänzt. '''Zu beachten ist, dass der Pegel der Eingänge "ungewohnt" behandelt wird: Ein Eingang wird als HIGH interpretiert, wenn er unbeschaltet ist (Taster offen oder keine Spannung angelegt), und als LOW wenn er mit Taster oder Spannung aktiviert ist.'''

Modus 1-3: Sendung bei Änderung des Pegels an DU30 (Taster-Eingang, offen=HIGH, geschlossen=LOW) bzw. Spannungseingang DUI30 (offen HIGH, mit Spannung LOW):
* Modus 1 (<code>lvlChng_H_L</code>): Senden bei Änderung HIGH->LOW
* Modus 2 (<code>lvlChng_L_H</code>): Senden bei Änderung LOW->HIGH
* Modus 3 (<code>lvlChng_any</code>): Senden bei HIGH->LOW und LOW->HIGH

Modus 4 und 6: Senden bei Änderungen einer oder mehrerer Datenleitungen, wenn diese länger als die "Datenstabilitätsfilterzeit" (<code>stabFltTime</code>) anliegen (bei kurzen Änderungen erfolgt keine Sendung - ähnlich dem <code>eventFilterTime</code> bei Sensoren: Sendung erst x Sekunden nachdem es eine Änderung gab)
* Modus 4 (<code>stbl4TimeEnable</code>): Sendung erfolgt wenn Datenübertragungseingang HIGH
* Modus 6 (<code>stbl4TimeDisable</code>): Sendung erfolgt wenn Datenübertragungseingang LOW

Modus 5 und 7: Senden sofort bei Änderung, danach Mindest-Wartezeit (ebenfalls <code>stabFltTime</code>, ähnlich dem <code>minInterval</code> etwa bei Bewegungsmeldern - Wartezeit nach Meldung einer Bewegung)
* Modus 5 (<code>sndImmediateEnable</code>): Sendung erfolgt wenn Datenübertragungseingang HIGH (bei LOW erfolgt keine Sendung)
* Modus 7 (<code>sndImmediateDisable</code>): Sendung erfolgt wenn Datenübertragungseingang LOW (bei HIGH erfolgt keine Sendung)

Beispiel: das Modul soll den Datenzustand 2 Sekunden nach der letzten Datenänderung an den Leitungen senden, wenn der Datenfreigabeeingang (DU30 oder DUI30) unbeschaltet ist (DUI30 darf auch auf GND liegen): 
<code>set ''<Name-des-Datenkanals>'' regSet dataTransCond stbl4Time'''Enable'''

set ''<Name-des-Datenkanals>'' regSet stabFltTime 2</code>.

Die acht Register <code>dInProp0</code> bis <code>dInProp7</code> legen zudem fest, ob der Eingang normal (Wert off = 0 bei Tasterbetätigung oder Spannung am Eingang) oder invertiert (Wert on = 1 bei Tasterbetätigung oder Spannung am Eingang) behandelt wird. So kann man zumindest bei den Dateneingängen die eher gewohnte Logik wiederherstellen.

Auf Device-Ebene lässt sich durch Setzen des Registers <code>ledMode</code> die onboard-LED für Sendequittungen ein- bzw. ausschalten: <code>set ''EM-8-Device'' regSet ledMode on</code> bzw. <code>off</code>.

Konfigurationen werden wie üblich per <code>set ''<Name-des-Gerätes-bzw-Kanals>'' regSet ''<Registername Wert>''</code> durchgeführt, wenn FHEM den aktuellen Status der Register besitzt, wozu ggf. zuvor ein <code>getConfig</code> ausgelöst werden muss. Zudem muss die Konfigurationstaste oder ein Eingang betätigt werden.

Will man eine reine binäre Auflistung der Eingänge, kann man folgendes Attribut für den 3. Kanal setzen: 
<code>attr ''<Name-des-Datenkanals>'' userReadings inputs {ReadingsVal($name,'state',0)=~/([0-9A-F]{2})/;reverse(sprintf("%08b",abs(hex($1)-255)))}</code> 
Dadurch wird ein neues Reading mit dem Namen ''inputs'' generiert, das die Zustände als 1 bzw. 0 anzeigt. Anzeige: <code>inputs 11000000</code> (Eingang 0 und 1 geschlossen) 
Die Auflistung erfolgt dabei in Lesereihenfolge, d.h. links ist Eingang 0 und rechts Eingang 7. Somit kann über ein einfaches <code>substr(ReadingsVal(''<Name-des-Datenkanals>'','inputs',0),x,1)</code> der Zustand des x-ten Einganges erfragt werden. 
''(Hinweis: Für eine einfache Lesbarkeit bedeutet 1 verbunden und 0 nicht verbunden, entgegen der Standardlogik des Bausatzes (siehe weiter oben). Die Formel für das UserReading funktioniert so nur, wenn die Standardeinstellungen für dInProp\d noch gelten. Ansonsten muss einfach die Subtraktion mit 255 entfernt werden.)''

== Bekannte Probleme ==
Derzeit (''Jan 18'') ist beim Register <code>stabFltTime</code> nur die Angabe vom Werten größer 10s möglich. Möchte man aber kleinere Werte benutzen, ist dies über ein <code>set ''<Name-des-Datenkanals>''regBulk RegL_01 xxx</code> möglich. Dazu für xxx einfach (bei gesetztem ''expert 3_allReg+raw'') den Inhalt von ''RegL_01'' nehmen und zum Wert von ''B1'' die gewünschte Anzahl an Sekunden addieren/subtrahieren.

Ob die beim [[HM-MOD-EM-8]] vorhandenen Probleme beim Senden an Aktoren mit Burst sowie die hohe Funklast beim Durchkonfigurieren hier ebenfalls zu Problemen führen, muss noch untersucht werden.
== Links ==
* [https://files.elv.com/Assets/Produkte/15/1502/150253/Downloads/150253-HM-Mod-EM-8Bit_UM_160817_web.pdf Bedienungsanleitung bei ELV]
* {{Link2Forum|Topic=67333|LinkText=Diskussion im Forum}} (als das Modul neu war)

[[Kategorie:HomeMatic Components]]
[[Kategorie:Schalter (Sender)]]

HM-MOD-EM-8bit 3-Kanal-Sendemodul mit 8-Bit-Datenkanal

2018-01-16T20:31:03Z

Cori: Absatz zu userReading für eine binäre Anzeige der Eingänge

{{Infobox Hardware
|Bild=HM-MOD-EM-8bit.jpg
|Bildbeschreibung=3-Kanal-Sendemodul mit 8-Bit-Datenkanal
|HWProtocol=HomeMatic
|HWType=Sender (Sensor oder Remote)
|HWCategory=HomeMatic
|HWComm=Funk 868MHz
|HWChannels=3
|HWVoltage=2-3,3V bzw. 3,5-12V
|HWPowerConsumption=typisch 30 bzw. 60µA, bis 28mA (Sendevorgang)
|HWPoweredBy=Batterie oder Kleinspannung
|HWSize=42x22x12mm
|HWDeviceFHEM=[[CUL_HM]]
|HWManufacturer=ELV / eQ-3
}}


[[HM-MOD-EM-8bit]] ist ein Modul für eigene Hardware-Entwicklungen (ähnlich dem 8-Kanal-Sendemodul [[HM-MOD-EM-8]]) zum Übermitteln von Schaltbefehlen oder Kontaktzuständen

== Features ==
Offenes (gehäuseloses) Einbaumodul mit ingesamt 3 Eingangskanälen. Kanal 1 und 2 sind einkanalige Signaleingänge, anders als beim [[HM-MOD-EM-8]] fest als Taster-Interface (sendet Short- bzw. Long-Trigger) konfiguriert. Kanal 3 besitzt 8 Dateneingänge (Bits), deren Zustand zusammengefasst als ein Byte interpretiert und mit diesem Wert gesendet werden. Wann ein Wert gesendet wird, kann mit sieben verschiedenen Modi eingestellt werden, wahlweise unter Einbeziehung einer weiteren Signalleitung, die als Trigger- oder Freigabeleitung dient.

Alle Einzelleitungen können wahlweise als Taster bzw. Schalter gegen GND und/oder als spannungsempfindlicher Eingang (2-24V) beschaltet werden, ähnlich dem 8-Kanal-Modul [[HM-MOD-EM-8]]. Beide Möglichkeiten können gleichzeitig benutzt werden und sind intern ODER-verknüpft. Dabei ist zu beachten, dass im Auslieferungszustand die Datenleitungen wie auch die Freigabeleitung logisch negativ betrachtet werden, d.h. ein offener Anschluss wird als logisch HIGH interpretiert, der übermittelte Wert von 8 offenen Dateneingängen ist also insgesamt "FF". Für die acht Datenleitungen kann jedoch je Leitung festgelegt werden, ob der Signalpegel am Eingang invertiert interpretiert werden soll.

Das Modul ist in Grenzen pinkompatibel zum [[HM-MOD-EM-8]]. Dessen acht Eingangskanäle entsprechen nunmehr den Datenleitungen. Für die Datenübernahmeleitung sowie die zusätzlichen Tastereingänge (Kanal 1 und 2) als auch dem ebenfalls von außen steuerbaren Konfigurationstaster wurden zahlreiche bisher intern mit GND verbundenen Pins benutzt, so dass für GND jetzt nur noch Pin12 verfügbar ist. Stromversorgung und die Ausgänge der Statusleitungen (Status_R, Status_G, Status_S) sind unverändert.

'''Weitere technische Daten:'''

* Eingangsimpedanz der Spannungseingänge: 10 kOhm (und eine Basis-Emitter-Strecke eines Transistors)
* Mindestwerte für Eingänge für ein sicheres Erkennen: 5,6 µA (experimentell ermittelt) / 0,7 V / ca. 780 kOhm bei 5V
* Höchstwiderstand am Tastereingang: 33 kOhm (experimentell ermittelt)
* Gewicht: 8 g

Aktuelle Firmware: 1.0 (Stand Mai 2017)

== Hinweise zu Inbetriebnahme und Installation ==
Das Modul ist nur als ARR-Bausatz erhältlich (Stand Mai 2017). Es ist auf einer Leiterplatte mit Steckkontakten untergebracht, das auf eigene Schaltungen gesockelt werden kann. Es verfügt über insgesamt 12 Eingänge für Taster sowie 12 Eingänge für eine Spannung von 2-24V, die über Transistoren die Eingänge des Prozessors parallel zu den Tasteneingängen kurzschließen (ODER-Verknüpfung). Außerdem gibt es Ausgänge für drei Status-LEDs (rot, grün wie für HM als Sendequittung üblich sowie einen dritten Ausgang, der aktiv ist, solange das Modul selbst sendet). Das Gerät besitzt einen Konfigurationstaster und eine onboard-LED, die im Auslieferungszustand jedoch nur den Batteriestatus meldet (bei schwacher Batterie) und keine Sendedaten quittiert, um Strom zu sparen. Die LED kann aber über Register eingeschaltet werden und sendet dann wie üblich mit gelb und ggf. rot oder grün als Quittung. ''(temporärer Hinweis: Das zugehörige Register ledMode ist im Moment nicht verfügbar)''

Die Stromversorgung erfolgt über Batterie (2-3,3 V) oder Kleinspannung 3,5-12 V.

== Betrieb mit FHEM ==
Das Modul muss zur Pairen manuell in den Konfigurationsmodus versetzt werden (onboard-Taster), empfängt dann aber Konfigurationstelegramme im Zusammenhang mit Sendevorgängen, z.B. bei Statusänderungen an den Eingängen (sog. lazyConfig). Dies erleichtert die nachträgliche Konfiguration bereits eingebauter Module.
Das Anlernen erfolgt in FHEM wie üblich. Danach stellt das Gerät 3 Kanäle (_Btn_01 und _Btn_02 sowie _Tr) bereit. Alle drei können direkt mit anderen Aktoren gepeert oder FHEM-intern verarbeitet werden.

Der Übermittlungsmodus der Kanäle 1 und 2 ist auf "button" festgelegt und nicht änderbar, für Kanal 3 wird er mit dem Register <code>dataTransCond</code> bestimmt und ggf. mit dem Zeitregister <code>stabFltTime</code> ergänzt. '''Zu beachten ist, dass der Pegel der Eingänge "ungewohnt" behandelt wird: Ein Eingang wird als HIGH interpretiert, wenn er unbeschaltet ist (Taster offen oder keine Spannung angelegt), und als LOW wenn er mit Taster oder Spannung aktiviert ist.'''

Modus 1-3: Sendung bei Änderung des Pegels an DU30 (Taster-Eingang, offen=HIGH, geschlossen=LOW) bzw. Spannungseingang DUI30 (offen HIGH, mit Spannung LOW):
* Modus 1 (<code>lvlChng_H_L</code>): Senden bei Änderung HIGH->LOW
* Modus 2 (<code>lvlChng_L_H</code>): Senden bei Änderung LOW->HIGH
* Modus 3 (<code>lvlChng_any</code>): Senden bei HIGH->LOW und LOW->HIGH

Modus 4 und 6: Senden bei Änderungen einer oder mehrerer Datenleitungen, wenn diese länger als die "Datenstabilitätsfilterzeit" (<code>stabFltTime</code>) anliegen (bei kurzen Änderungen erfolgt keine Sendung - ähnlich dem <code>eventFilterTime</code> bei Sensoren: Sendung erst x Sekunden nachdem es eine Änderung gab)
* Modus 4 (<code>stbl4TimeEnable</code>): Sendung erfolgt wenn Datenübertragungseingang HIGH
* Modus 6 (<code>stbl4TimeDisable</code>): Sendung erfolgt wenn Datenübertragungseingang LOW

Modus 5 und 7: Senden sofort bei Änderung, danach Mindest-Wartezeit (ebenfalls <code>stabFltTime</code>, ähnlich dem <code>minInterval</code> etwa bei Bewegungsmeldern - Wartezeit nach Meldung einer Bewegung)
* Modus 5 (<code>sndImmediateEnable</code>): Sendung erfolgt wenn Datenübertragungseingang HIGH (bei LOW erfolgt keine Sendung)
* Modus 7 (<code>sndImmediateDisable</code>): Sendung erfolgt wenn Datenübertragungseingang LOW (bei HIGH erfolgt keine Sendung)

Beispiel: das Modul soll den Datenzustand 2 Sekunden nach der letzten Datenänderung an den Leitungen senden, wenn der Datenfreigabeeingang (DU30 oder DUI30) unbeschaltet ist (DUI30 darf auch auf GND liegen): 
<code>set ''<Name-des-Datenkanals>'' regSet dataTransCond stbl4Time'''Enable'''

set ''<Name-des-Datenkanals>'' regSet stabFltTime 2</code>.

Die acht Register <code>dInProp0</code> bis <code>dInProp7</code> legen zudem fest, ob der Eingang normal (Wert off = 0 bei Tasterbetätigung oder Spannung am Eingang) oder invertiert (Wert on = 1 bei Tasterbetätigung oder Spannung am Eingang) behandelt wird. So kann man zumindest bei den Dateneingängen die eher gewohnte Logik wiederherstellen.

Auf Device-Ebene lässt sich durch Setzen des Registers <code>ledMode</code> die onboard-LED für Sendequittungen ein- bzw. ausschalten: <code>set ''EM-8-Device'' regSet ledMode on</code> bzw. <code>off</code>. ''(temporärer Hinweis: Diese Funktion ist aktuell (Mai 2017) in FHEM noch nicht verfügbar, ebenso wie <code>lowBatLimitBA2</code> zum Einstellen der low-Batt-Erkennungsschwelle)''

Konfigurationen werden wie üblich per <code>set ''<Name-des-Gerätes-bzw-Kanals>'' regSet ''<Registername Wert>''</code> durchgeführt, wenn FHEM den aktuellen Status der Register besitzt, wozu ggf. zuvor ein <code>getConfig</code> ausgelöst werden muss. Zudem muss die Konfigurationstaste oder ein Eingang betätigt werden.

Will man eine reine binäre Auflistung der Eingänge, kann man folgendes Attribut für den 3. Kanal setzen: 
<code>attr ''<Name-des-Datenkanals>'' userReadings inputs {ReadingsVal($name,'state',0)=~/([0-9A-F]{2})/;reverse(sprintf("%08b",abs(hex($1)-255)))}</code> 
Dadurch wird ein neues Reading mit dem Namen ''inputs'' generiert, das die Zustände als 1 bzw. 0 anzeigt. Anzeige: <code>inputs 11000000</code> (Eingang 0 und 1 geschlossen) 
Die Auflistung erfolgt dabei in Lesereihenfolge, d.h. links ist Eingang 0 und rechts Eingang 7. Somit kann über ein einfaches <code>substr(ReadingsVal(''<Name-des-Datenkanals>'','inputs',0),x,1)</code> der Zustand des x-ten Einganges erfragt werden. 
''(Hinweis: Für eine einfache Lesbarkeit bedeutet 1 verbunden und 0 nicht verbunden, entgegen der Standardlogik des Bausatzes (siehe weiter oben). Die Formel für das UserReading funktioniert so nur, wenn die Standardeinstellungen für dInProp\d noch gelten. Ansonsten muss einfach die Subtraktion mit 255 entfernt werden.)''

== Bekannte Probleme ==
Derzeit (''Jan 18'') ist beim Register <code>stabFltTime</code> nur die Angabe vom Werten größer 10s möglich. Möchte man aber kleinere Werte benutzen, ist dies über ein <code>set ''Channel-Name'' regBulk RegL_01 xxx</code> möglich. Dazu für xxx einfach (bei gesetztem ''expert 3_allReg+raw'') den Inhalt von ''RegL_01'' nehmen und zum Wert von ''B1'' die gewünschte Anzahl an Sekunden addieren/subtrahieren.

Ob die beim [[HM-MOD-EM-8]] vorhandenen Probleme beim Senden an Aktoren mit Burst sowie die hohe Funklast beim Durchkonfigurieren hier ebenfalls zu Problemen führen, muss noch untersucht werden.
== Links ==
* [https://files.elv.com/Assets/Produkte/15/1502/150253/Downloads/150253-HM-Mod-EM-8Bit_UM_160817_web.pdf Bedienungsanleitung bei ELV]
* {{Link2Forum|Topic=67333|LinkText=Diskussion im Forum}} (als das Modul neu war)

[[Kategorie:HomeMatic Components]]
[[Kategorie:Schalter (Sender)]]

HM-MOD-EM-8bit 3-Kanal-Sendemodul mit 8-Bit-Datenkanal

2018-01-16T20:08:01Z

Cori: Umgehung stabFltTime-Fehler

{{Infobox Hardware
|Bild=HM-MOD-EM-8bit.jpg
|Bildbeschreibung=3-Kanal-Sendemodul mit 8-Bit-Datenkanal
|HWProtocol=HomeMatic
|HWType=Sender (Sensor oder Remote)
|HWCategory=HomeMatic
|HWComm=Funk 868MHz
|HWChannels=3
|HWVoltage=2-3,3V bzw. 3,5-12V
|HWPowerConsumption=typisch 30 bzw. 60µA, bis 28mA (Sendevorgang)
|HWPoweredBy=Batterie oder Kleinspannung
|HWSize=42x22x12mm
|HWDeviceFHEM=[[CUL_HM]]
|HWManufacturer=ELV / eQ-3
}}


[[HM-MOD-EM-8bit]] ist ein Modul für eigene Hardware-Entwicklungen (ähnlich dem 8-Kanal-Sendemodul [[HM-MOD-EM-8]]) zum Übermitteln von Schaltbefehlen oder Kontaktzuständen

== Features ==
Offenes (gehäuseloses) Einbaumodul mit ingesamt 3 Eingangskanälen. Kanal 1 und 2 sind einkanalige Signaleingänge, anders als beim [[HM-MOD-EM-8]] fest als Taster-Interface (sendet Short- bzw. Long-Trigger) konfiguriert. Kanal 3 besitzt 8 Dateneingänge (Bits), deren Zustand zusammengefasst als ein Byte interpretiert und mit diesem Wert gesendet werden. Wann ein Wert gesendet wird, kann mit sieben verschiedenen Modi eingestellt werden, wahlweise unter Einbeziehung einer weiteren Signalleitung, die als Trigger- oder Freigabeleitung dient.

Alle Einzelleitungen können wahlweise als Taster bzw. Schalter gegen GND und/oder als spannungsempfindlicher Eingang (2-24V) beschaltet werden, ähnlich dem 8-Kanal-Modul [[HM-MOD-EM-8]]. Beide Möglichkeiten können gleichzeitig benutzt werden und sind intern ODER-verknüpft. Dabei ist zu beachten, dass im Auslieferungszustand die Datenleitungen wie auch die Freigabeleitung logisch negativ betrachtet werden, d.h. ein offener Anschluss wird als logisch HIGH interpretiert, der übermittelte Wert von 8 offenen Dateneingängen ist also insgesamt "FF". Für die acht Datenleitungen kann jedoch je Leitung festgelegt werden, ob der Signalpegel am Eingang invertiert interpretiert werden soll.

Das Modul ist in Grenzen pinkompatibel zum [[HM-MOD-EM-8]]. Dessen acht Eingangskanäle entsprechen nunmehr den Datenleitungen. Für die Datenübernahmeleitung sowie die zusätzlichen Tastereingänge (Kanal 1 und 2) als auch dem ebenfalls von außen steuerbaren Konfigurationstaster wurden zahlreiche bisher intern mit GND verbundenen Pins benutzt, so dass für GND jetzt nur noch Pin12 verfügbar ist. Stromversorgung und die Ausgänge der Statusleitungen (Status_R, Status_G, Status_S) sind unverändert.

'''Weitere technische Daten:'''

* Eingangsimpedanz der Spannungseingänge: 10 kOhm (und eine Basis-Emitter-Strecke eines Transistors)
* Mindestwerte für Eingänge für ein sicheres Erkennen: 5,6 µA (experimentell ermittelt) / 0,7 V / ca. 780 kOhm bei 5V
* Höchstwiderstand am Tastereingang: 33 kOhm (experimentell ermittelt)
* Gewicht: 8 g

Aktuelle Firmware: 1.0 (Stand Mai 2017)

== Hinweise zu Inbetriebnahme und Installation ==
Das Modul ist nur als ARR-Bausatz erhältlich (Stand Mai 2017). Es ist auf einer Leiterplatte mit Steckkontakten untergebracht, das auf eigene Schaltungen gesockelt werden kann. Es verfügt über insgesamt 12 Eingänge für Taster sowie 12 Eingänge für eine Spannung von 2-24V, die über Transistoren die Eingänge des Prozessors parallel zu den Tasteneingängen kurzschließen (ODER-Verknüpfung). Außerdem gibt es Ausgänge für drei Status-LEDs (rot, grün wie für HM als Sendequittung üblich sowie einen dritten Ausgang, der aktiv ist, solange das Modul selbst sendet). Das Gerät besitzt einen Konfigurationstaster und eine onboard-LED, die im Auslieferungszustand jedoch nur den Batteriestatus meldet (bei schwacher Batterie) und keine Sendedaten quittiert, um Strom zu sparen. Die LED kann aber über Register eingeschaltet werden und sendet dann wie üblich mit gelb und ggf. rot oder grün als Quittung. ''(temporärer Hinweis: Das zugehörige Register ledMode ist im Moment nicht verfügbar)''

Die Stromversorgung erfolgt über Batterie (2-3,3 V) oder Kleinspannung 3,5-12 V.

== Betrieb mit FHEM ==
Das Modul muss zur Pairen manuell in den Konfigurationsmodus versetzt werden (onboard-Taster), empfängt dann aber Konfigurationstelegramme im Zusammenhang mit Sendevorgängen, z.B. bei Statusänderungen an den Eingängen (sog. lazyConfig). Dies erleichtert die nachträgliche Konfiguration bereits eingebauter Module.
Das Anlernen erfolgt in FHEM wie üblich. Danach stellt das Gerät 3 Kanäle (_Btn_01 und _Btn_02 sowie _Tr) bereit. Alle drei können direkt mit anderen Aktoren gepeert oder FHEM-intern verarbeitet werden.

Der Übermittlungsmodus der Kanäle 1 und 2 ist auf "button" festgelegt und nicht änderbar, für Kanal 3 wird er mit dem Register <code>dataTransCond</code> bestimmt und ggf. mit dem Zeitregister <code>stabFltTime</code> ergänzt. '''Zu beachten ist, dass der Pegel der Eingänge "ungewohnt" behandelt wird: Ein Eingang wird als HIGH interpretiert, wenn er unbeschaltet ist (Taster offen oder keine Spannung angelegt), und als LOW wenn er mit Taster oder Spannung aktiviert ist.'''

Modus 1-3: Sendung bei Änderung des Pegels an DU30 (Taster-Eingang, offen=HIGH, geschlossen=LOW) bzw. Spannungseingang DUI30 (offen HIGH, mit Spannung LOW):
* Modus 1 (<code>lvlChng_H_L</code>): Senden bei Änderung HIGH->LOW
* Modus 2 (<code>lvlChng_L_H</code>): Senden bei Änderung LOW->HIGH
* Modus 3 (<code>lvlChng_any</code>): Senden bei HIGH->LOW und LOW->HIGH

Modus 4 und 6: Senden bei Änderungen einer oder mehrerer Datenleitungen, wenn diese länger als die "Datenstabilitätsfilterzeit" (<code>stabFltTime</code>) anliegen (bei kurzen Änderungen erfolgt keine Sendung - ähnlich dem <code>eventFilterTime</code> bei Sensoren: Sendung erst x Sekunden nachdem es eine Änderung gab)
* Modus 4 (<code>stbl4TimeEnable</code>): Sendung erfolgt wenn Datenübertragungseingang HIGH
* Modus 6 (<code>stbl4TimeDisable</code>): Sendung erfolgt wenn Datenübertragungseingang LOW

Modus 5 und 7: Senden sofort bei Änderung, danach Mindest-Wartezeit (ebenfalls <code>stabFltTime</code>, ähnlich dem <code>minInterval</code> etwa bei Bewegungsmeldern - Wartezeit nach Meldung einer Bewegung)
* Modus 5 (<code>sndImmediateEnable</code>): Sendung erfolgt wenn Datenübertragungseingang HIGH (bei LOW erfolgt keine Sendung)
* Modus 7 (<code>sndImmediateDisable</code>): Sendung erfolgt wenn Datenübertragungseingang LOW (bei HIGH erfolgt keine Sendung)

Beispiel: das Modul soll den Datenzustand 2 Sekunden nach der letzten Datenänderung an den Leitungen senden, wenn der Datenfreigabeeingang (DU30 oder DUI30) unbeschaltet ist (DUI30 darf auch auf GND liegen): 
<code>set ''<Name-des-Datenkanals>'' regSet dataTransCond stbl4Time'''Enable'''

set ''<Name-des-Datenkanals>'' regSet stabFltTime 2</code>.

Die acht Register <code>dInProp0</code> bis <code>dInProp7</code> legen zudem fest, ob der Eingang normal (Wert off = 0 bei Tasterbetätigung oder Spannung am Eingang) oder invertiert (Wert on = 1 bei Tasterbetätigung oder Spannung am Eingang) behandelt wird. So kann man zumindest bei den Dateneingängen die eher gewohnte Logik wiederherstellen.

Auf Device-Ebene lässt sich durch Setzen des Registers <code>ledMode</code> die onboard-LED für Sendequittungen ein- bzw. ausschalten: <code>set ''EM-8-Device'' regSet ledMode on</code> bzw. <code>off</code>. ''(temporärer Hinweis: Diese Funktion ist aktuell (Mai 2017) in FHEM noch nicht verfügbar, ebenso wie <code>lowBatLimitBA2</code> zum Einstellen der low-Batt-Erkennungsschwelle)''

Konfigurationen werden wie üblich per <code>set ''<Name-des-Gerätes-bzw-Kanals>'' regSet ''<Registername Wert>''</code> durchgeführt, wenn FHEM den aktuellen Status der Register besitzt, wozu ggf. zuvor ein <code>getConfig</code> ausgelöst werden muss. Zudem muss die Konfigurationstaste oder ein Eingang betätigt werden.

== Bekannte Probleme ==
Derzeit (''Jan 18'') ist beim Register <code>stabFltTime</code> nur die Angabe vom Werten größer 10s möglich. Möchte man aber kleinere Werte benutzen, ist dies über ein <code>set ''Channel-Name'' regBulk RegL_01 xxx</code> möglich. Dazu für xxx einfach (bei gesetztem ''expert 3_allReg+raw'') den Inhalt von ''RegL_01'' nehmen und zum Wert von ''B1'' die gewünschte Anzahl an Sekunden addieren/subtrahieren.

Ob die beim [[HM-MOD-EM-8]] vorhandenen Probleme beim Senden an Aktoren mit Burst sowie die hohe Funklast beim Durchkonfigurieren hier ebenfalls zu Problemen führen, muss noch untersucht werden.
== Links ==
* [https://files.elv.com/Assets/Produkte/15/1502/150253/Downloads/150253-HM-Mod-EM-8Bit_UM_160817_web.pdf Bedienungsanleitung bei ELV]
* {{Link2Forum|Topic=67333|LinkText=Diskussion im Forum}} (als das Modul neu war)

[[Kategorie:HomeMatic Components]]
[[Kategorie:Schalter (Sender)]]

XBMC

2017-08-13T20:53:15Z

Cori: Webadresse zum Kodi-Wiki korrigiert

{{Infobox Modul
|ModPurpose=Abspielen von Medien (Musik, Video, Bilder)
|ModType=d
|ModForumArea=Multimedia
|ModTechName=70_XBMC.pm
|ModOwner={{Link2FU|6776|vbs}}
}}

'''KODI''' (früher XBox Media Center (XBMC) genannt) ist eine unter den Bestimmungen der GPL erhältliche freie Media-Center Software. Sie dient dem Abspielen von Videos, Bildern und Musik von DVD, Festplatte und Server sowie der Wiedergabe von Audio- und Video-Datenströmen aus dem Internet. (Quelle: [http://kodi.tv/ kodi.tv])

Ein weiteres Media-Center System, das mit diesem Modul zusammenarbeitet, ist das aus einem XBMC Fork entstandene [https://plex.tv PLEX Media-Server] System.

Aktuelle Versionen von Plex Home Theater haben nur noch eine sehr eingeschränkte Kompatibilität zum XBMC/KODI API und zeigen z.B. keine Informationen mehr über die aktuell gespielten Medien an. Die Beta-Version eines plex-spezifischen Moduls wird in diesem {{Link2Forum|Topic=43052|Message=353477|LinkText=Post im Forum}} vorgestellt.

== Zielsetzung ==
Dieses Modul ermöglicht das Steuern und Empfangen von Events von KODI und PLEX. Unter anderen sind damit vielfältige Verknüpfungen von Aktoren und
XBMC/Plex möglich.

Aktuelle Plex Home Theater (PHT) Versionen (ab etwa mitte November) liefern keine Informationen mehr zum abgespielten Titel (currentTitle,currentAlbum,...) sondern nur noch zum TransportState. Der Grund dafür ist noch nicht klar.

== Einbindung in FHEM ==

Für diese Modul wird das Perl JSON Modul benötigt. Auf einem Debian-basierten System (z.B RaspberryPI o.ä.) kann man das mit
dem folgenden Befehl installieren:
:<code>sudo apt-get install libjson-perl</code>

'''Beispieldefinition'''
:<code>define wz_XBMC XBMC <IP-Adresse> tcp <USERNAME> <PASSWORT></code>
:<code>attr wz_XBMC devStateIcon opened:rc_GREEN:on disconnected:rc_RED:off Initialized:message_socket_disabled</code>

'''Hinweis''' 
JSON RPC muss aktiviert sein. Näheres siehe hier: http://kodi.wiki/view/JSON_RPC#Enabling_JSON-RPC
Danach sollte ein Neustart von Kodi durchgeführt werden.

Erfolgreich getestet unter den Versionen
''KODI 14 und fhem 5.6''.

=== Lichtsteuerung durch KODI oder PLEX ===
Im folgenden Beispiel werden beim Starten eines Films die Lichter ausgeschaltet. Sobald die Pause-Taste gedrückt wird, wird das Licht wieder eingeschaltet.

<pre>
define notify_KODI_status notify wz_KODI:playStatus.* { if (ReadingsVal("wz_KODI", "type", "") eq "movie"){
if (ReadingsVal("wz_KODI", "playStatus", "") eq "playing"){
fhem("set FS20_Licht off");
}
if (ReadingsVal("wz_KODI", "playStatus", "") eq "paused"){
fhem("set FS20_Licht on");
}
}
}
</pre>

Mit Hilfe des Moduls [[LightScene]] kann man den voherigen Status der einzelnen Lampen auch speichern und nach dem Filmende wiederherstellen.
Anbei ein Code Beispiel:

<pre>
wz_KODI:playStatus.* {
my $media = ReadingsVal("wz_KODI","currentMedia","none");
my $isPlaying = ReadingsVal("wz_KODI","playStatus","n/a") eq "playing";
my $is3d = ReadingsVal("wz_KODI","3dfile","n/a") eq "on";
my $currentLightScene = Value("kino_licht");
Log 3, "Wiedergegebene Datei: " . $media . " isPlaying: " . $isPlaying. " is3d: " . $is3d . " currentLightScene: " . $currentLightScene;
if ($is3d && $isPlaying) {
if ($currentLightScene ne "3d_movie") {
Log 3, "Speichere aktuellen Zustand als temporäre Szene und ändere kino_licht scene auf 3d_movie...";
fhem("set kino_licht save tmp_pre_movie_state;");
fhem("set kino_licht scene 3d_movie;");
}
} elsif ($is3d && $currentLightScene eq "3d_movie") {
Log 3, "Der Film ist pausiert oder zu Ende, ändere LightScene zurück auf tmp_pre_movie_state...";
fhem("set kino_licht scene tmp_pre_movie_state;");
fhem("set kino_licht remove tmp_pre_movie_state;");
}
}
</pre>

Ein weiteres Beispiel mit dem Modul DOIF:
<pre>
#########################################################################
# Kodi: Lichtsteuerung
#########################################################################
define di_kodi_lichtsteuerung DOIF
(
[wz_KODI:playStatus] eq "playing" and [wz_KODI:currentMedia] ne "" and
(
[wz_KODI:type] eq "episode" or
[wz_KODI:type] eq "movie"
)
)
(set ls_Erdgeschoss scene Filmstart)
DOELSEIF (
[wz_KODI:playStatus] eq "paused" and [wz_KODI:currentMedia] ne "" and
(
[wz_KODI:type] eq "episode" or
[wz_KODI:type] eq "movie"
)
)
(set ls_Erdgeschoss scene Filmpause)
DOELSEIF (
[wz_KODI:playStatus] eq "stopped" and [wz_KODI:currentMedia] ne "" and
(
[wz_KODI:type] eq "episode" or
[wz_KODI:type] eq "movie"
)
)
(set ls_Erdgeschoss scene indirekt)
</pre>

Weitere Informationen dazu unter im Forenthread {{Link2Forum|Topic=32775|LinkText=Fragen zu LightScene}}

Alternative Lichtsteuerung in Abhängigkeit der Helligkeit {{Link2Forum|Topic=58381|LinkText=Lichtsteuerung in Abhängigkeit von Dämmerung und Fernseher / Mediaplayer}}

=== Nachrichten von FHEM an KODI und PLEX schicken ===
Der folgende Befehl schickt eine 5 Sekunden lange Info Nachricht an KODI.

:<code>fhem("set wz_KODI msg 'fhem' 'Licht wurde ausgeschaltet!' 5000 info");</code>

=== Thumbnail im Frontend anzeigen ===
In den readings von KODI gibt es einen thumbnail Wert. Um diesen als http link in einem http basierten Frontend darstellen zu können muss allerdings ein Userreading erstellt werden, denn der Pfad für http muss doppelt encoded werden. D.h. aus dem %2f muss ein %252f gemacht. Zusätzlich muss dem Wert noch ein http://IP_KODI:PORT_WEBSERVICE/image/ vorangestellt werden. Das funktioniert aber nur wenn die Bilder lokal abgelegt sind, nicht wenn die Bilder von z.b. thetvdb.com kommen.

:<code>http_thumbnail { my $val = (ReadingsVal("$name", "thumbnail", 0)); $val =~ s/\%2f/\%252f/g;; return "http://192.168.0.5:8080/image/".$val;; }</code>

Anschliessend kann http_thumbnail abgefragt werden und enthaelt den Link zum Bild

== Anzeigen von FHEM Daten im KODI ==
[[Datei:Xbmc.png|mini|right|300px|FHEM-Daten in KODI anzeigen]]

=== Vorbereitungen in KODI ===
Zuerst muss das Phyton Skript heruntergeladen werden ([http://forum.fhem.de/index.php?topic=14419.0 Thread im FHEM-Forum]) und mit dem XBMC Addon Manager installiert werden.

=== Vorbereitungen in FHEM ===
Anschließend muss das globale Attribut userattr mit "xbmcInfo" erweitert werden, und zwar entweder durch Bearbeitung der [[Konfiguration|FHEM Konfiguration]] oder durch Eingabe des Befehls
:<code>{fhem ("attr global userattr $attr{global}{userattr}"." xbmcInfo")}</code>
in das FHEM Befehlsfenster.

Danach muss ein Dummy mit den anzuzeigenden Daten erstellt werden:
:<code>attr <dummy-name> xbmcInfo <TYPE> <Reading[|Alias]> <[Reading[|Alias]]>...</code>

=== Konfiguration in KODI ===

[[Datei:FHEM-Info3.png|mini|right|200px|Konfigurationsschritt in KODI]]
Im KODI danach noch das ''Addon'' konfiguren (IP+Passwort).

[[Datei:FHEM-Info1.png|mini|right|200px|Beispielausgabe]]
[[Datei:FHEM-Info2.png|mini|right|200px|Beispielausgabe]]
'''Beispiele'''
<pre>
define KODI_dummy dummy
attr KODI_dummy xbmcInfo CUL_WS temperature|Temperatur humidity|Luftfeuchte

define KODI_dummy2 dummy
attr KODI_dummy2 xbmcInfo PID20 actuation|Ventil desired|Soll measured|Ist delta p_p|P-Anteil p_i|I-Anteil

define KODI_dummy3 dummy
attr KODI_dummy3 xbmcInfo FS20 state|Status name|Name

</pre>

----

=== HTPC via WakeOnLan (WOL) Funktion wecken ===
Einige HTPCs haben nicht die Möglichkeit diese via eines IR Kommandos zu starten. Alternativ kann hier die
sog. "WakeOnLan" Funktion genutzt werden. Diese bietes mittels eines speziellen TCP/UDP Paketes den Rechner zu starten. In FHEM gibt es dafür das Modul [[WOL]].
<pre>
define <NAME des PCs> WOL <MAC-Adresse> <IP> [<mode> [<repeat>]]
</pre>

'''Beispiel'''
<pre>
#########################################################################
# KODI - WakeOnLan Funktion
#########################################################################
define wol_zion WOL BC:AE:C5:B3:E1:3A 192.168.1.13 EW
attr wol_zion room _System
attr wol_zion sysCmd ./ether-wake
</pre>
'''Wichtiger Hinweis bei Betrieb auf einer Fritzbox'''

Sofern fhem nicht unter dem User root wird das ether-wake Kommando nicht funktionieren.
''Quick&Dirty Workaround: Mit Telnet auf der FritzBox einloggen und dann das Programm /usr/bin/ether-wake
in das fhem-Hauptverzeichnis kopieren. Zusätzlich muss das sog. "Sticky-Bit" mit dem Befehl 'chmod og+s ether-wake'
gesetzt werden.''

'''Einschalten des HTPCs'''
<pre>
set wol_zion on
</pre>

'''Ausschalten des HTPCs mittels KODI'''
<pre>
set wz_KODI shutdown
</pre>

== Links ==
* Thread über das Modul im {{Link2Forum|Topic=10075|LinkText=FHEM Forum}}
* Thread mit [http://forum.fhem.de/index.php?topic=14419.0 weiteren Informationen]

[[Kategorie:Unterhaltungselektronik]]
[[Kategorie:Code Snippets]]

HM-Sen-MDIR-O Funk-IR-Bewegungsmelder außen

2016-03-05T16:37:49Z

Cori: /* Konfiguration über Register */ inhaltliche Ergänzungen und Korrekturen

{{Infobox Hardware|Bild=HM-Sen-MDIR-O.jpg
|Bildbeschreibung=HM-Sen-MDIR-O
|HWProtocol=HomeMatic
|HWType=Sensor
|HWCategory=HomeMatic
|HWComm=868,3 MHz
|HWChannels=1
|HWPowerConsumption=unbekannt
|HWVoltage=4,5 V
|HWPoweredBy=Batterie, 3x LR06 (Mignon)
|HWSize=76 x 74 x 90 mm
|HWDeviceFHEM=[[CUL_HM]]
|HWManufacturer=eQ-3
}}

'''HM-Sen-MDIR-O'''
HomeMatic Funk-IR-Bewegungsmelder außen

== Features ==
PIR-Bewegungsmelder mit Helligkeitssensor zur Tag-/Nachtumschaltung.

'''Technische Daten:'''
* Erfassungswinkel: ca. 90°
* Erfassungsbereich: ca. 9 m
* Drehbar: 360°
* Neigbar: 45°
* Schutzart: IP 44

== Hinweise zur Inbetriebnahme und Installation ==
<Bitte ergänzen>

== Betrieb mit FHEM ==

Das Pairing sollte wie in [[HomeMatic Devices pairen]] beschrieben durchgeführt werden. Die Anlerntaste am Bewegungsmelder sollte hierzu nur kurz betätigt werden. Bei einer Betätigung von vier Sekunden wird der Melder nur bei Unterschreiten einer festgelegten Helligkeitsschwelle auslösen (weitere Informationen siehe Abschnitt ''Anlernen'' der Herstellerdokumentation).

'''Hinweis''': sobald einmal ein motion-Status erkannt wurde, verbleibt das Gerät in diesem Modus. Alle Konfigurationsbeispiele setzen also einen zusätzlichen watchdog voraus:

define WD_Reset_EG.Scheune.MotionDetect watchdog EG.Scheune.MotionDetect:motion 00:04:05 SAME setreading EG.Scheune.MotionDetect state nomotion

Dieser Umweg mit einem Watchdog läßt sich auch mit einer DOIF-Lösung verheiraten, siehe Beispiel '''Außenbeleuchtung zeitgesteuert und bei Bewegung schalten'''. Als Alternative kann auch auf die Uhrzeit der letzten Erkennung geprüft werden:

define di_lamp DOIF ([BM:state:sec] < 5)(set lamp on-for-timer 300)
attr di_lamp do always

=== Event-Monitor ===

In regelmäßigen Abständen werden die folgenden Daten vom Bewegungsmelder (hier: HM-Sen-MDIR-O-2) übermittelt:
<pre>
2014-11-19 16:31:24 CUL_HM HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer brightness: 120
2014-11-19 16:31:24 CUL_HM HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer cover: closed
2014-11-19 16:31:24 CUL_HM HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer battery: ok
</pre>

Wird Bewegung erkannt, wird Folgendes vom Gerät (hier: HM-Sen-MDIR-O-2) übermittelt:
<pre>
2014-11-19 16:27:55 CUL_HM HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer trigDst_2573FB: noConfig
2014-11-19 16:27:55 CUL_HM HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer motion
2014-11-19 16:27:55 CUL_HM HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer motion: on (to MyHMLAN)
2014-11-19 16:27:55 CUL_HM HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer motionCount: 235_next:116s
2014-11-19 16:27:55 CUL_HM HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer brightness: 120
</pre>

=== Log-Auszug ===

<Bitte ergänzen>

=== fhem.cfg ===

Bei eingeschaltetem Autocreate werden die erforderlichen Definitionen beim Pairen selbstständig erstellt (Beispiel: HM-Sen-MDIR-O-2).

<pre>
define HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer CUL_HM 2B033A
attr HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer IODev MyHMLAN
attr HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer actCycle 000:10
attr HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer actStatus alive
attr HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer autoReadReg 4_reqStatus
attr HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer expert 2_full
attr HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer firmware 1.6
attr HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer model HM-Sen-MDIR-O-2
attr HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer peerIDs 00000000,
attr HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer room CUL_HM
attr HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer serialNr LEQ0xxxxxx
attr HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer subType motionDetector
</pre>

=== Konfiguration über Register ===
==== Anzeige aller dekodierten Register ====
<nowiki>get <name> regList</nowiki>
zeigt alle moeglichen 'dekodierten' Register an. Fuer mdir sind dies alle, sollte also komplett sein. Hier findet man sowohl den Wertebereich alsauch eine (sehr) kleine Beschreibung.
Ausgabe:

<nowiki>
list: register | range | peer | description
0: pairCentral | 0 to 16777215 | | pairing to central
1: brightFilter | 0 to 7 | | brightness filter - ignore light at night
1: captInInterval | literal | | capture within interval options:on,off
1: evtFltrNum | 1 to 15 | | sensitivity - read each n-th puls
1: evtFltrPeriod | 0.5 to 7.5s | | event filter period
1: ledOnTime | 0 to 1.275s | | LED ontime
1: minInterval | literal | | minimum interval in sec options:240,60,120,30,15
4: peerNeedsBurst | literal | required | peer expects burst options:on,off
</nowiki>

;minInterval
: Minimales Interval in Sekunden vor dem Senden einer neuen Funknachricht. Der Standard ist 240. D.h. nach einer Bewegungs-Meldung werden erst nach min. 4 Minuten weitere Meldungen gesendet. Ob dafür neue Bewegungen nötig sind oder Bewegungen innerhalb des Intervalls ausreichen, regelt das Register captInInterval.
;captInInterval
: Sendet am Ende der "Sendepause" (minInterval) eine Funkmeldung, wenn Bewegungen innerhalb der Pause gemäß Filtereinstellungen eine Meldung ausgelöst hätten.
;brightFilter
: Filtert plötzliche Helligkeitsschwankungen aus und wirkt sich auf den Helligkeitswert aus. Dies soll bei motion-Meldungen an einen Aktor verhindern, dass durch plötzliche/kurzzeitige Beleuchtung ein falscher Helligkeitswert übermittelt wird. 0 Filtert nichts aus.
;evtFltrNum
: Filtert Bewegungen aus. Steht dieser Wert z.B. auf 5 so wird erst bei der fünften Bewegung die Meldung gesendet.
;evtFltrPeriod
: Gibt an wie viel Zeit zwischen zwei Bewegungen vergehen muss um für den evtFltrNum Filter gezählt zu werden. Steht dieser Wert auf 1 und evtFltrNum auf 5 so muss der Sensor 5 Sekunden Bewegungen registrieren um eine Meldung zu senden.
;ledOnTime
: Legt die Aufleuchtdauer der internen LED zur optischen Rückmeldung fest. Die LED leuchtet jedoch nur bei einer Funkübertragung auf. D.h. ist auch von minInterval abhängig.

=== Einsatzbeispiele (per Notify) ===

==== Gerät bei Bewegung schalten ====

Mit dem folgenden [[Notify]] kann z. B ein [[HM-LC-SW1-FM Schaltaktor 1-fach UP|Unterputz-Schaltaktor]] für die angegebene Zeit (in Sekunden) eingeschaltet werden - ein [[Homematic Peering Beispiele|Peeren]] ist dazu vorher nicht erforderlich. Das Einschalten passiert in diesem Beispiel unabhängig von der Helligkeit.

<pre>
define Notify_Bewegungsmelder_Haustuer notify HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer:motion set HM_LC_SW1_FM_298FB2_HaustuerLicht on-for-timer 300
</pre>

==== Außenbeleuchtung zeitgesteuert und bei Bewegung schalten ====

Das fortgeschrittene Beispiel steuert die Beleuchtung in Abhängigkeit von Uhrzeiten und zwei Bewegungsmeldern.

Dazu wird das Twilight-Modul verwendet:

define MyTwilight Twilight 54.2539407 9.0650127 1 12833034

wobei die Koordinaten und die Stadt-ID (letzte Zahl) angepaßt werden müßen.

''Zeitgesteuerte Außenbeleuchtung'' 
Ein Dummy namens '''D_TimerAussenlicht''' speichert, ob das Außenlicht über die Uhrzeitregelung aktiviert wurde:

define D_TimerAussenlicht dummy
attr D_TimerAussenlicht room Aussen

define AussenlichtONOFF DOIF (( [05:30-07:40|8] or [06:30-08:00|7] or [15:30-22:30] or ([15:30-01:00] and [PresTVWintergarten:state] eq "present")) and [MyTwilight:twilight_weather] < 40) \
(set D_TimerAussenlicht on, set Aussenlicht on) \
DOELSE \
(set D_TimerAussenlicht off, set Aussenlicht off)

Dies aktiviert die Außenbeleuchtung zwischen 05:30-07:40 an Werktagen oder zwischen 06:30-08:00 an Wochenenden oder Ferientagen oder zwischen 15:30-22:30 oder zwischen 15:30-01:00 sofern der Fernseher ('''PresTVWintergarten''') mit Hilfe des PRESENCE-Moduls erkannt wurde - aber nur, wenn es dunkel ist. Für die Erkennung der Dunkelheit wurde des Twilight-Modul verwendet und der Schwellwert auf 40 definiert. Wie in der Dokumentation ersichtlich, sind die angegebenen Uhrzeiten die möglichen START- und END-Zeiten - sollte die Dunkelheit (AND-Verknüpfung des Twilight-Modules) nicht ausreichen, wird das Licht später ein- oder früher ausgeschaltet.

''Bewegungsmelder'' 
Diese Lösung basiert auf der vorgeschlagenen Bewegungsmelder-Lösung mit DOIF, integriert jedoch das löschen des '''motion'''-Zustandes in den Bewegungsmeldern:

define D_MotionDetectHinten dummy

define DI_MotionHintenScheune DOIF ([EG.Scheune.MotionDetect] eq "motion" ) (set D_MotionDetectHinten on, set D_MotionDetectHinten off, setreading EG.Scheune.MotionDetect state nomotion)
attr DI_MotionHintenScheune do always

define DI_MotionHintenDurchgang DOIF ([EG.Durchgang.MotionDetect] eq "motion" ) (set D_MotionDetectHinten on, set D_MotionDetectHinten off, setreading EG.Durchgang.MotionDetect state nomotion)
attr DI_MotionHintenDurchgang do always

define DI_MotionLichtHinten DOIF ([D_MotionDetectHinten] eq "on" and [D_TimerAussenlicht] eq "off" and [MyTwilight:twilight_weather] < 40) \
(set LichtStruc.Aussen.Hinten on) \
DOELSE \
(set LichtStruc.Aussen.Hinten off)
attr DI_MotionLichtHinten wait 0:240

Der Dummy '''D_MotionDetectHinten''' wird von beiden Bewegungsmeldern (EG.Durchgang.MotionDetect und EG.Scheune.MotionDetect) getriggert. Sobald diese eine Bewegung erkennen, werden diese auf das Muster '''on''' gefolgt von '''off''' gesetzt. Direkt danach wird der motion-Status des auslösenden Bewegungsmelders gelöscht.

Das dritte DOIF reagiert auf einen Wechsel des Dummys (D_MotionDetectHinten) und prüft, ob das Außenlicht bereits zeitgesteuert (D_TimerAussenlicht, siehe Abschnitt oben) aktiviert wurde. Ist dies nicht der Fall und dunkel (Twilight-Modul und Abfrage) genug, wird die structure (LichtStruc.Aussen.Hinten) ohne Verzögerung für 240 Sekunden aktiviert.

Die Bewegungsmelder können dann ebenfalls auf eine 240-Sekunden-Verzögerung konfiguriert werden - die Lichter brennen ja bereits für diese Zeitdauer.

==== Gerät bei Bewegung in Abhängigkeit der Helligkeit schalten ====

Mit der nachfolgenden Notify-Definition werden zwei Log-Einträge erzeugt, eine Meldung auf der [[Enigma2 Receiver (Dreambox, VUplus etc.) steuern|Dreambox]] angezeigt, falls diese angeschaltet ist, und ein [[HM-LC-SW1-FM Schaltaktor 1-fach UP|Unterputz-Schaltaktor]] für die angegebene Zeit (in Sekunden) eingeschaltet, falls die gemessene Helligkeit am Bewegungsmelder kleiner oder gleich 90 ist.

Der Code ist hier so angegeben, wie er in der Weboberfläche nach einem Klick auf das [[Konfiguration|DEF-Feld]] übernommen werden kann.

<pre>
HM_BewegMelder_Carport:motion {
Log 1, "Trigger-Notify von BewegMelderCarport: @";
Log 1, ReadingsVal( "HM_BewegMelder_Carport", "brightness", "");
fhem( "set E2_Dreambox showText Bewegung am Carport" ) if ReadingsVal("E2_Dreambox","state","") eq "on";
if ( ReadingsVal( "HM_BewegMelder_Carport", "brightness", "") <= 90 ) {
fhem( "set HM_Sw1_GarageLED on-for-timer 300" );
}
}
</pre>

=== Einsatzbeispiele (per DOIF) ===

==== Aktor in Abhängigkeit der Helligkeit und innerhalb eines Zeitraums schalten ====

Voraussetzung: [[Twilight]]-Modul
Die Twilight-Abfragen könnten natürlich auch entfernt werden.

<pre>
define di_lampe DOIF (
(
[sensor:brightness] < 120 and
[?[twilight:ss_indoor]-23:59]
)
(set lampe on)
DOELSEIF
(
[sensor:brightness] > 80 and
[?04:00-[twilight:sr_indoor]]
)
(set lampe off)
</pre>

==== Aktor bei Bewegung einschalten (inkl. weiterer Gimmicks) ====

Benötigte Module: [[Twilight]] und [[Anwesenheitserkennung|Residents]]

Die Zeilen zum Residents und Twilight-Modul könnten natürlich auch entfernt werden.

<pre>
define di_lampe2 DOIF (
(
(
## Bewegungsmelder löst aus
[sensor:?motion] and
## nur wenn Lampe nicht zuvor manuell eingeschaltet wurde
[lampe:state] ne "on" and
## und wenn es nicht sowieso hell genug ist.
[?sensor:brightness] < 50
)
and
(
## entweder immer nachts
[?00:00-[twilight:sr_civil]] or
## oder wenn niemand daheim
[?rgr_Residents] ne "home"
)
)
(set lampe2 on-for-timer 180)
</pre>

=== Sonstiges ===

==== Anzeige der Uhrzeit der letzten Bewegung ====

Möchte man den Zeitpunkt der letzten erfassten Bewegung in der GUI sehen, so muss hierzu folgendes Attribut gesetzt werden.

<pre>
attr Sensor showtime 1
</pre>

== Bekannte Probleme ==
Geräte verfügen über keinen Sabotage-Kontakt.

== Links ==
Manual: [http://www.eq-3.de/Downloads/eq3/pdf_produkte/104108_HM-Sen-MDIR-O_V1.2_GE_eQ-3_20120510.pdf PDF HM-Sen-MDIR-O],
[http://www.eq-3.de/Downloads/eq3/pdf_produkte/HM-Sen-MDIR-O-2_UM_GE_131024.pdf PDF HM-Sen-MDIR-O-2]

[[Kategorie:HomeMatic Components]]
[[Kategorie:Lichtsensoren]]
[[Kategorie:Bewegungs- und Anwesenheitsmelder]]

HomeMatic Peering Beispiele

2016-03-04T22:04:06Z

Cori: /*Virtuelle Entities & IO Entities */ Absatz überarbeitet und ergänzt, Todo (Sinn Peering IO mit Aktor) erledigt und gelöscht

Dieser Artikel beschreibt wie mit FHEM Homematic Sensoren und Aktoren gepeert werden können. Peering ist nicht zu verwechseln mit Pairing, d.h. dem Verknüpfen von Homematic Geräten mit einer Zentrale (wie beispielsweise Fhem). Details zum Pairing findet man [[HomeMatic_Devices_pairen|'''hier''']].

= Grundlagen =
Beim ''Peering'' (deutsch sinngemäß: Verbindung von Gleichen) handelt es sich um das Verknüpfen von Kanälen (Channels) verschiedender HomeMatic-Geräte, um diese auch ohne Zentrale kommunizieren zu lassen. Nach dem Peering sendet meist ein Sensorkanal (remote, push-button, Bewegungsmelder,...) einen Trigger an einen Aktorkanal des anderen Gerätes.
Besonderheiten:
* peeren kann man nur Channels, nicht HomeMatic-Geräte. Die Peer-Listen der verschiedenen Kanäle eines Gerätes sind unabhängig voneinander.
* gepeert werden immer ein oder mehrere Sensorkanäle mit einem oder mehreren Aktorkanälen
* der Sensor sendet einen Trigger, evtl. mit einem Zusatzwert. Es ist ''immer'' der Aktorkanal, der festlegt, welche Aktion ergriffen wird. Ein Button kann demnach gleichzeitig ein Einschalter für einen Aktor und ein Ausschalter für einen anderen Aktor sein.

{{Hinweis|'''Achtung:''' Das in vielen mitgelieferten HomeMatic-Anleitungen beschriebene Peering von Kanälen ohne Zentrale funktioniert nur, wenn keines der beiden Geräte gepairt ist. Im Folgenden gehen wir davon aus, dass beide Geräte bereits mit einer Homematic-Zentrale (z.B. Fhem) [[HomeMatic_Devices_pairen|gepairt]] sind.}}

== Kommandos ==

=== peerChan ===

set <sensChan> peerChan 0 <actChan> [single|dual] [set|unset]

<code>peerChan</code> peert (verbindet) einen Sensorkanal mit einem Aktorkanal.
Dabei ist <code><sensChan></code> der Name des Sensorkanals und <code><actChan></code> der Name des Aktorkanals.

* Mit dem Schlüsselwort ''single'' wird genau dieser Sensorkanal gepeert.
* Mit dem Schlüsselwort ''dual'' werden zwei zusammengehörende Sensorkanäle mit dem Aktorkanal verknüpft. Die beiden Sensorkanäle lösen unterschiedliche Aktionen aus, beispielsweise ''an'' und ''aus''.
* Das Schlüsselwort ''set'' legt das Peering an, das Schlüsselwort ''unset'' hebt es auf.

Das Kommando unterliegt den allgemeinen [[HomeMatic#Kommunikation|Regeln]]. Es wirkt auf zwei Geräte gleichzeitig, weshalb beide Geräte beobachtet werden sollten – ggf. muss an einem oder beiden Geräten die Anlerntaste gedrückt werden.

=== peerIODev ===

set <actChan> peerIODev <IO> <chan> [set|unset]

<code>peerIODev</code> peert (verbindet) einen Aktorkanal mit einem I/O-Device.
Dabei ist <code><IO></code> der Namen des I/O-Devices und <code><chan></code> die Nummer des virtuellen Kanals ist. Kanäle von 1 bis 50 sind zulässig.

=== peerBulk ===

set <sensChan> peerBulk <peer1,peer2,...>

<code>peerBulk</code> dient der Wiederherstellung einer gesicherten Konfiguration.
Dieser Befehlt erlaubt eine Liste von Peers en-block in ein Gerät zu schreiben. Die Gegenstelle und die Kommunikation der Beiden wird nicht berücksichtigt.

==Sensoren ==
Ist ein Sensorkanal mit einem Aktorkanal gepeert, gibt es meist nur wenig mögliche Einstellungen. Wichtige Beispiele sind
* Notwendigkeit, den Peer mit einem burst aufzuwecken (Register peerNeedsBurst).
* Erwartung von AES-Verschlüsselung/Authentifizierung (Register expectAES).

===LED===
Ein ungepeerter Sensorkanal signalisiert einen Tastendruck meist mit gelber LED. Ist der Kanal gepeert, wird mit einer grünen LED signalisiert, dass ALLE Peers den Empfang des Triggers bestätigt (d.h. "ACK" gesendet) haben. Sollten nicht alle Peers eine Bestätigung senden, wird mit einer rot LED quittiert.

==Aktoren==
Ist ein Sensorkanal mit einem Aktorkanal gepeert, muss im Aktorkanal eingestellt werden, welche Trigger gültig sind und welche Aktionen ergriffen werden sollen. Im Channel wird ein Satz Register angelegt, die als Reading mit '''R-<peername>...''' zusammengefasst sind. Meist sind 2 Gruppen je Peer vorhanden, eine für langen '''lg''' und eine für kurzen '''sh''' Tastendruck. Die Register für long und short sind deckungsgleich, bis auf das Register multiExec in der Gruppe long.

Für das Setzen des Wertes im Aktorkanal gilt die Syntax
set <actChan> regSet <register> <value> <peername>
===Condition Table===
Mit den Registern der Condition Table '''CT''' kann man Trigger filtern. So sendet beispielsweise ein Fensterkontakt einen Trigger mit einem Zusatzwert open=200 oder closed=0. Die CT hat 2 Vergleichswerte, '''Hi''' und '''Lo'''. Der Zusatzwert des Triggers wird entsprechend des Einträgen in der CT verglichen. Ist der Schalter z.B. an, dann wird auf den Eintrag in '''CTon''' genutzt. Steht dort '''geLo''' wird gprüft, ob der Zusatzwert des triggers grösser oder gleich dem Lo-Wert ist. Ist dies nicht der Fall, wird keine Aktion ausgeführt.
Register zur Condition Table sind:
CtDlyOff | literal | Jmp on condition from delayOff options:geLo,between,outside,ltLo,geHi,ltHi
CtDlyOn | literal | Jmp on condition from delayOn options:geLo,between,outside,ltLo,geHi,ltHi
CtOff | literal | Jmp on condition from off options:geLo,between,outside,ltLo,geHi,ltHi
CtOn | literal | Jmp on condition from on options:geLo,between,outside,ltLo,geHi,ltHi
CtValHi |0 to 255 | Condition value high for CT table
CtValLo |0 to 255 | Condition value low for CT table
Remotes liefern keinen Zusatzwert. Die Conditon Table wird nicht genutzt.
===Jump Table===
In der Jump Table wird zusammen mit ActionType festgelegt, welche Aktion ein gültiger Trigger ausführen soll. Die Aktion ist vom Gerät abhängig.

===Interne Peers===
Aktoren können eingebaute oder direkt angeschlossene Taster oder Tasteneingänge haben, die auch als Peers verarbeitet werden. Normalerweise sind diese nicht sichtbar, sie können aber durch Absetzen des Befehls
set <device> regSet intKeysVisib visib
sichtbar und einstelllbar gemacht werden.

==Virtuelle Entities==
Soll ein FHEM-Befehl bei einem Aktor nicht nur eine Aktion auslösen, muss er mit einem Kanal einer [[HomeMatic#Virtuelle_Entities|virtuellen Entität]] oder einer [[HomeMatic#IO_Entities|IO Entität]] gepeert werden. Das Peering erfolgt wie bei realen Homematic-Geräten. Achtung: da diese virtuellen Peers nicht in einem realen Gerät gespeichert werden, ist nach der Definition ein '''Save config''' nötig. 
Dadurch lassen sich nicht nur einfache Befehle je Kanal aussenden, sondern die Peering-Listen in Aktoren nutzen um mit einem Funkbefehl z.B.
*Schleifen zu starten (z.B. bei Alarmauslösung ein Pulsieren der Beleuchtung, alle x Min eine kurze Unterbrechung, ...)
*Abläufe zu starten (z.B. Treppenhauslicht mit Vorwarnung bei Dimmern, ...)
*mehrere Aktoren gleichzeitig schalten zu lassen
Sonst müsste man für jede Zustandsänderung bzw. für jeden Aktor einen eigenen Befehl senden. Somit reagieren mehrere Aktoren auf ein FHEM-Kommando gleichzeitig.

===IO Entities===
[[HomeMatic#IO_Entities|IO Entities]] sind virtuelle Kanäle eines IO-Devices (z.B. [[Virtueller Controller VCCU|VCCU]], [[HM-CFG-LAN|HMLAN]], ...) und können somit gepeert werden. Hierfür gibt es das Kommando [[Homematic Peering Beispiele#peerIODev|peerIODev]].

= Beispiele=
== Peering der Kanäle einer Fernbedienung mit einem Aktor ==
Dabei muss beachtet werden, dass auf den Fernbedienungen immer zwei Buttons zusammengehören, also z.B. lock/unlock, open/light oder Btn01/Btn02, Btn03/Btn04. Achtung: Für ein erfolgreiches Peering muss ggf. auf der Fernbedienung die Anlerntaste gedrückt werden.

Bei einem "dual" Peering werden die beiden zusammengehörenden Kanäle der Fernbedienung mit einem Aktorkanal gepeert - einer der Buttons wirkt dann als "on", der andere als "off"-Schalter.

set fb_Btn03 peerChan 0 blind
peert die Buttons Btn03 und Btn04 mit dem Aktorkanal ''blind''

Bei einem "single" Peering wird nur einer der beiden Kanäle der Fernbedienung mit einem Aktorkanal gepeert - als Aktion wird dann im Aktorkanal ein "toggle" eingetragen.

set fb_Btn07 peerChan 0 blind single
peert nur den Button Btn07 mit dem Aktorkanal ''blind''

Das Unpeering, also das Löschen einer Paarung, erfolgt z.B. durch den Befehl
set fb_Btn07 peerChan 0 blind single unset

== Peering von I/O-Entities ==
<pre>
set blind peerIODev HMLAN1 5
set blind peerIODev HMLAN1 7 unset
</pre>

[[Kategorie:HomeMatic Components]]
[[Kategorie:HOWTOS]]
[[Kategorie:Examples]]

HomeMatic

2016-03-04T21:21:58Z

Cori: /* IO Entities */ falschen Satz gelöscht

'''Achtung, diese Seite wird derzeit im Sinne einer klareren Beschreibung überarbeitet'''

'''HomeMatic''' (HM) ist ein System des Herstellers eQ-3 zur Steuerung und Überwachung von zahlreichen Aufgaben und Situationen im Haus. Erhältlich sind sowohl Geräte mit Funkschnittstelle 868.3 MHz, als auch (seit 2008) drahtgebundene Geräte mit RS485-Schnittstelle. Im Programm sind Geräte zur Heizungs- und Lichtsteuerung, Temperatur-, Luftfeuchte- und Feuchtemessung, Zutrittskontrolle, als Wasser-, Brand- und Bewegungsmelder sowie als Wetterstation, ferner gibt es noch Fernbedienungen und Statusdisplays.

=Grundlagen=
HomeMatic-Geräte können untereinander ''gepeert'' werden (engl. ''peers'' = "Gleiche"), im einfachsten Fall kann deshalb bereits ein Sensor (z.B. ein Temperatursensor) mit einem Aktor (z.B. einem Heizkörperregler) verbunden werden und diesen steuern. Hierbei können mehrere Sensoren und Aktoren untereinander verbunden werden, die Vorstellung der "Gleichen" ist also zutreffend.

HomeMatic-Geräte können auch mit einer Zentrale verbunden (''gepairt'') werden, die dann einen Teil der Steuerungslogik übernehmen kann. Bei dieser Verbindung spricht man vom ''Pairing'', weil jedes HomeMatic-Gerät nur mit einer Zentrale verbunden werden kann. Gepairte Geräte können auch nicht mehr direkt gepeert werden - dies geht dann nur noch unter Beteiligung der Zentrale.

==Voraussetzungen==
Für den Betrieb ohne Zentrale sind keine weiteren Voraussetzungen zu erfüllen.
===Zentrale von eQ-3===
Vom Hersteller eQ-3 selbst wird eine Zentrale (derzeit aktuell CCU-2) und Windows-Software zur Steuerung und Auswertung der HM-Komponenten angeboten.

===Fhem als Zentrale===
Zur Kommunikation mit HomeMatic benötigt Fhem eine Schnittstelle, die im 868,3-MHz-Band funken kann. Infrage kommen:
* [[CUL]] (USB)
* [[HM-CFG-USB USB Konfigurations-Adapter|HM-CFG-USB]] (USB)
* [[CUNO]] (LAN)
* [[HM-CFG-LAN]] (oft auch "HMLAN" genannt; LAN)

Für ''HomeMatic Wired'' benötigt man eine RS485-Schnittstelle. Verfügbar sind:
* [[HomeMatic Wired RS485 LAN Gateway|HMW-LGW-O-DR-GS-EU]] (LAN)

===Migration von CCU-2 zu Fhem===
Der Umzug einer bestehenden HomeMatic Installation von einer HomeMatic CCU-2 auf Fhem ist möglich. Um die an die Zentrale angebundenen Devices in Fhem ohne größere Umkonfiguration weiter verwenden zu können, muß die HM-Id und, falls verwendet, die AES-Schlüssel der CCU-2 in Fhem übernommen werden. Um diese Daten aus der CCU-2 auszulesen, wird eine SSH-Verbindung (zum Beispiel mit PuTTY unter Windows) aufgebaut. Die HM-Id befindet sich in der Datei <code>/usr/local/etc/config/rfd/BidCoS-RF.dev</code> in einer Zeile wie dieser:

<device serial="BidCoS-RF" type="HM-RCV-50" address="0xABCDEF" aes_key_index="0" firmware_version="2.11.9" bidcos_interface="KEQ1234567" roaming="true">

Die HM-Id ist der Wert des <code>address</code>-Attributs. Die dort angegebene hexadezimale Zahl (hier <code>0xABCDEF</code>) ist die HM-Id und wird in Fhem ohne das "0x"-Präfix verwendet.

Falls AES-Schlüssel eingerichtet sind, sind diese in der Datei <code>/etc/config_templates/crypttool.cfg</code> zu finden und können 1:1 als Schlüssel im [[HM-CFG-LAN]] in der gleichen Reihenfolge hinterlegt werden.
{{Todo|Wie werden AES-Schlüssel in HM-CFG-LAN "hinterlegt"?}}

==Prototokoll==
HM-Geräte kommunizieren untereinander mit dem Protokoll ''Bidirectional Communication Standard'', abgekürzt ''BidCoS''. Jedes HM-Gerät enthält also Sender und Empfänger, das ist einer der wesentlichen Unterschiede z.B. zum FS20-System.
*Jedes HM-Gerät meldet beim Empfang eines Steuerbefehls durch einen Peer an diesen eine Bestätigung „ACK“ zurück. Erkennt das HM-Gerät den Befehl nicht, sendet es ein ''NACK''. Kommt vom HM-Gerät keine Rückmeldung innerhalb einer festgelegten Zeit, meldet der steuernde Peer ein ''MISSING ACK''.
*Jedes HM-Gerät meldet ferner seinen Status nach dem Erhalt eines Steuerbefehls zurück - so kann auch ein lokal am Gerät erfolgender Tastendruck in beim steuernden Peer oder in der Zentrale registriert werden.

Das Protokoll ''BidCoS'' wurde zum großen Teil entschlüsselt, seine offen verfügbare Variante heißt ''AskSin''. Unter Verwendung der AskSin-Library entstehen derzeit erste Geräte, die in das HomeMatic-System eingebunden werden können. Zur Unterscheidung zwischen HM und den neuen Geräten werden diese als [[HomeBrew]] (HB) bezeichnet.

=Betrieb mit Fhem=
Die Kenntnis des Dokumentes [http://fhem.de/Heimautomatisierung-mit-fhem.pdf Einsteigerdokuments "Heimautomatisierung mit Fhem"] wird vorausgesetzt. Im Anhang dieses Dokuments findet sich ein Teil über den Aufbau und die Funktion von HM-Geräten.

=== 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 (Gerät)''' und ein oder mehrere '''Channels (Kanäle)''' gegliedert. Jedes Device und jeder Channel wird in einer Entity in FHEM repräsentiert. 
Ausnahme: Sollte ein Gerät nur einen Kanal haben werden diese zusammen in einer Entity angelegt.
====Device (Gerät)====
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.

====Channel (Kanal)====
Ein Kanal ist die Funktionseinheit des Geräts. Hier ist die Funktion des Sensors oder Aktors realisiert. 
Nutzt ein Gerät nur einen Kanal, wird dieser in FHEM der Übersichtlichkeit halber nicht einzeln angelegt. Für die Kommandos und das Peering wird trotzdem die HM-ID des 1. Kanals verwendet. 
Nutzt ein Gerät hingegen mehrere Kanäle, werden diese per [[autocreate]] zusätzlich zum Device angelegt. Es ist aber möglich, bei Geräten mit virtuellen Kanälen, diese zu löschen und fehlende Attribute manuell dem Device hinzu zu fügen. Danach kann es wie ein 1-Kanal-Gerät genutzt werden. Allerdings werden die Kanäle beim erneuten Pairing von [[autocreate]] neu angelegt.

=====virtuelle Kanäle=====
Einige Dimmer unterstützen virtuelle Kanäle. Eigentlich haben sie keinen Hauptkanal sondern nur 3 virtuelle Kanäle, die je nach Verknüpfungslogik, den endgültigen Zustand des Aktors bestimmen. Dieses Verhalten wird in jedem Kanal per Register '''logicCombination''' gesetzt. 
Folgende Logik wird dabei angewendet: <tt>phyLevel = (((0% o Ch1) o Ch2) o Ch3)</tt> [o = Logik-Platzhalter] 
D.h. es wird immer der Kanal mit dem gesetzten Register mit dem vorherigen Teilergebnis kombiniert, angefangen mit Kanal1. 
Es gibt folgende Logik-Optionen: [einzelne Betrachtung von <tt>(Vorergebnis o Kanal)</tt>]
{|
!style="text-align:left;"|Wert!!style="text-align:left;"|Bedeutung!!style="text-align:left;"|Beispiel (alle Werte in %)
|-
|inactive||keine Verknüpfung|| 30 inactive 80 = 30
|-
|or||oder (höchster Wert zählt)|| 30 or 80 = 80
|-
|and||und (kleinster Wert zählt)|| 30 and 80 = 30
|-
|xor||entweder-oder (nur 1 Kanal darf über 0% sein)|| 30 xor 80 = 0 ''aber'' 30 xor 0 = 30
|-
|nor||oder negiert (höchster Wert subtrahiert von 100%)|| 30 nor 80 ''= !80'' = 20
|-
|nand||und negiert (niedrigster Wert subtrahiert von 100%)|| 30 nand 80 ''= !30'' = 70
|-
|orinv||oder mit invertiertem Kanal|| 30 orinv 80 ''= 30 or 20'' = 30
|-
|andinv||und mit invertiertem Kanal|| 30 andinv 80 ''= 30 and 20'' = 20
|-
|plus||Vorergebnis addiert mit Kanal|| 30 plus 80 = 100
|-
|minus||Vorergebnis subtrahiert mit Kanal|| 30 minus 80 = 0
|-
|mul||Vorergebnis multipliziert mit Kanal|| 30 mul 80 = 24
|-
|plusinv||Vorergebnis addiert mit invertiertem Kanal|| 30 plusinv 80 ''= 30 plus 20'' = 50
|-
|minusinv||Vorergebnis subtrahiert mit invertiertem Kanal|| 30 minusinv 80 ''= 30 minus 20'' = 10
|-
|mulinv||Vorergebnis multipliziert mit invertiertem Kanal|| 30 mulinv 80 ''= 30 mul 20'' = 6
|-
|invPlus||invertiertes Vorergebnis addiert mit Kanal|| 30 invPlus 80 ''= 70 plus 80'' = 100
|-
|invMinus||invertiertes Vorergebnis subtrahiert mit Kanal|| 30 invMinus 80 ''= 70 minus 80'' = 0
|-
|invMul||invertiertes Vorergebnis multipliziert mit Kanal|| 30 invMul 80 ''= 70 mul 80'' = 56
|}
: ''→ Siehe auch: [[HM-LC-Dim1PWM-CV Dimmaktor PWM DC-LED#Beispiele|Verknüpfungsbeispiel]]''

=== 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 [[HomeMatic#Protokol|Protokolls]], also der Kommunikation mit dem Device.
** rssi...: Gruppe von Daten die den [[HomeMatic#Rssi|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 [[Homematic_HMInfo#Integrit.C3.A4tspr.C3.BCfungen|configCheck]].
Da einige Entities viele Register haben kann man mit dem Attribut '''expert''' die Sichtbarkeit steuern. 
siehe auch [[Homematic_HMInfo#Infos|register]]. 
Von einigen Devices sind Register schwer zu lesen, z.B. config devices. Man kann die Register-Readings [[Homematic_HMInfo#archConfig|archivieren]] und beim reboot wieder [[Homematic_HMInfo#archConfig|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 [[HomeMatic#Device|Übertragungsmodi]], die ein Device unterstützt. Die Internals "prot..." enthalten alle notwendigen Daten.
* protState: Der Zustand der Protokollmaschine
** CMDs_done: alle Nachrichten übertragen, keine 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 [[Homematic_HMInfo#protoEvents|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, die beim Senden zwischen Peers erreicht werden. 
Die Zähler können mit '''set <device> clear rssi''' rückgesetzt werden. 
Eine Übersicht erhält man mit HMInfo [[Homematic_HMInfo#RSSI|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.

== Pairen und Peeren ==
: ''→ Siehe auch: [[Pairing und Peering]]''

HomeMatic-Geräte können mit einer Zentrale (Fhem) ''gepairt'' und mit anderen HM-Geräten ''gepeert'' werden.

=== Pairen ===
: ''→ Hauptartikel: [[HomeMatic Devices pairen]]''

HM-Geräte können mit und ohne Zentrale betrieben werden. Fhem geht davon aus, dass Geräte immer von einer Zentrale aus gesteuert werden können. Dazu muss das Gerät mit der Zentrale ''gepairt'' werden.

=== Peeren ===
: ''→ Siehe auch: [[Homematic Peering Beispiele]]

Um es Geräten zu ermöglichen auch ohne Zentrale zu interagieren (zum Beispiel wenn die Zentrale einen Defekt hat), können HM-Geräte untereinander ''gepeert'' werden.
Dazu wird ein Sensor-Kanal mit einem Aktor-Kanal verknüpft.

== HMInfo ==
: ''→ Siehe auch: [[Homematic HMInfo]]''

Bei der Betreuung einer HomeMatic-Installation ist das Modul [[Homematic_HMInfo|HMInfo]] sehr hilfreich. Es stellt eine Übersicht der HomeMatic-Komponenten zur Verfügung, kann die Konfiguration prüfen und Alarmierungen 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 ===
: ''→ Siehe auch: [[Virtueller Controller VCCU#Virtuelle Kanäle der VCCU]]

'''IO-Entities''' sind virtuelle Kanäle der Zentrale, mit denen andere HomeMatic-Geräte gepeert werden können. Diese Kanäle sind einem ''IO-Device'' zugeordnet – im Unterschied zu ''virtuellen Entities'' gibt es kein virtuelles Homematic-Gerät welches die Kanäle beherbergt.

Jedem IO-Device können bis zu 50 Kanäle zugewiesen werden. Wenn mehrere IO-Devices die gleiche HMId nutzen, zum Beispiel wenn ein [[Virtueller Controller VCCU|virtueller Controller]] verwendet wird, teilen sich diese IO-Devices die Kanäle.

'''Anlegen:'''

# IO-Device definieren
define <IO-Device> CUL_HM c0ffee
attr <IO-Device> model CCU-FHEM

# 4 IO-Entities definieren
set <IO-Device> virtual 4

=== Action Detector===
Einige Devices der HM-Geräteserie senden periodisch Nachrichten. Manche alle 3 Minuten, 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.
Die Kontrollinstanz ist ein Pseudo-Gerät "ActionDetector" mit der HMId "000000"

* 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

Durch das Setzen des Attributs im HM device wird der ActionDetector automatisch definiert - nach einem save steht er auch in der fhem.cfg.
Alternativ ist auch eine manuelle Definition möglich und sollte in etwa so aussehen:

define ActionDetector CUL_HM 000000
attr ActionDetector actCycle 30
attr ActionDetector event-on-change-reading .*
attr ActionDetector model ActionDetector

Die HMId "000000" darf nicht geändert werden.

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

* [[HomeMatic Devices pairen|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 [[Homematic_Nachrichten_sniffen|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 ==
* [http://www.homematic.com/ HomeMatic] Homepage
* Hersteller [http://www.eq-3.de eQ-3]

[[Kategorie:HomeMatic Components]]
[[Kategorie:Glossary]]

HomeMatic

2016-03-04T20:50:18Z

Cori: /*Struktur von HM Geräten*/ Ergänzung Kanäle

'''Achtung, diese Seite wird derzeit im Sinne einer klareren Beschreibung überarbeitet'''

'''HomeMatic''' (HM) ist ein System des Herstellers eQ-3 zur Steuerung und Überwachung von zahlreichen Aufgaben und Situationen im Haus. Erhältlich sind sowohl Geräte mit Funkschnittstelle 868.3 MHz, als auch (seit 2008) drahtgebundene Geräte mit RS485-Schnittstelle. Im Programm sind Geräte zur Heizungs- und Lichtsteuerung, Temperatur-, Luftfeuchte- und Feuchtemessung, Zutrittskontrolle, als Wasser-, Brand- und Bewegungsmelder sowie als Wetterstation, ferner gibt es noch Fernbedienungen und Statusdisplays.

=Grundlagen=
HomeMatic-Geräte können untereinander ''gepeert'' werden (engl. ''peers'' = "Gleiche"), im einfachsten Fall kann deshalb bereits ein Sensor (z.B. ein Temperatursensor) mit einem Aktor (z.B. einem Heizkörperregler) verbunden werden und diesen steuern. Hierbei können mehrere Sensoren und Aktoren untereinander verbunden werden, die Vorstellung der "Gleichen" ist also zutreffend.

HomeMatic-Geräte können auch mit einer Zentrale verbunden (''gepairt'') werden, die dann einen Teil der Steuerungslogik übernehmen kann. Bei dieser Verbindung spricht man vom ''Pairing'', weil jedes HomeMatic-Gerät nur mit einer Zentrale verbunden werden kann. Gepairte Geräte können auch nicht mehr direkt gepeert werden - dies geht dann nur noch unter Beteiligung der Zentrale.

==Voraussetzungen==
Für den Betrieb ohne Zentrale sind keine weiteren Voraussetzungen zu erfüllen.
===Zentrale von eQ-3===
Vom Hersteller eQ-3 selbst wird eine Zentrale (derzeit aktuell CCU-2) und Windows-Software zur Steuerung und Auswertung der HM-Komponenten angeboten.

===Fhem als Zentrale===
Zur Kommunikation mit HomeMatic benötigt Fhem eine Schnittstelle, die im 868,3-MHz-Band funken kann. Infrage kommen:
* [[CUL]] (USB)
* [[HM-CFG-USB USB Konfigurations-Adapter|HM-CFG-USB]] (USB)
* [[CUNO]] (LAN)
* [[HM-CFG-LAN]] (oft auch "HMLAN" genannt; LAN)

Für ''HomeMatic Wired'' benötigt man eine RS485-Schnittstelle. Verfügbar sind:
* [[HomeMatic Wired RS485 LAN Gateway|HMW-LGW-O-DR-GS-EU]] (LAN)

===Migration von CCU-2 zu Fhem===
Der Umzug einer bestehenden HomeMatic Installation von einer HomeMatic CCU-2 auf Fhem ist möglich. Um die an die Zentrale angebundenen Devices in Fhem ohne größere Umkonfiguration weiter verwenden zu können, muß die HM-Id und, falls verwendet, die AES-Schlüssel der CCU-2 in Fhem übernommen werden. Um diese Daten aus der CCU-2 auszulesen, wird eine SSH-Verbindung (zum Beispiel mit PuTTY unter Windows) aufgebaut. Die HM-Id befindet sich in der Datei <code>/usr/local/etc/config/rfd/BidCoS-RF.dev</code> in einer Zeile wie dieser:

<device serial="BidCoS-RF" type="HM-RCV-50" address="0xABCDEF" aes_key_index="0" firmware_version="2.11.9" bidcos_interface="KEQ1234567" roaming="true">

Die HM-Id ist der Wert des <code>address</code>-Attributs. Die dort angegebene hexadezimale Zahl (hier <code>0xABCDEF</code>) ist die HM-Id und wird in Fhem ohne das "0x"-Präfix verwendet.

Falls AES-Schlüssel eingerichtet sind, sind diese in der Datei <code>/etc/config_templates/crypttool.cfg</code> zu finden und können 1:1 als Schlüssel im [[HM-CFG-LAN]] in der gleichen Reihenfolge hinterlegt werden.
{{Todo|Wie werden AES-Schlüssel in HM-CFG-LAN "hinterlegt"?}}

==Prototokoll==
HM-Geräte kommunizieren untereinander mit dem Protokoll ''Bidirectional Communication Standard'', abgekürzt ''BidCoS''. Jedes HM-Gerät enthält also Sender und Empfänger, das ist einer der wesentlichen Unterschiede z.B. zum FS20-System.
*Jedes HM-Gerät meldet beim Empfang eines Steuerbefehls durch einen Peer an diesen eine Bestätigung „ACK“ zurück. Erkennt das HM-Gerät den Befehl nicht, sendet es ein ''NACK''. Kommt vom HM-Gerät keine Rückmeldung innerhalb einer festgelegten Zeit, meldet der steuernde Peer ein ''MISSING ACK''.
*Jedes HM-Gerät meldet ferner seinen Status nach dem Erhalt eines Steuerbefehls zurück - so kann auch ein lokal am Gerät erfolgender Tastendruck in beim steuernden Peer oder in der Zentrale registriert werden.

Das Protokoll ''BidCoS'' wurde zum großen Teil entschlüsselt, seine offen verfügbare Variante heißt ''AskSin''. Unter Verwendung der AskSin-Library entstehen derzeit erste Geräte, die in das HomeMatic-System eingebunden werden können. Zur Unterscheidung zwischen HM und den neuen Geräten werden diese als [[HomeBrew]] (HB) bezeichnet.

=Betrieb mit Fhem=
Die Kenntnis des Dokumentes [http://fhem.de/Heimautomatisierung-mit-fhem.pdf Einsteigerdokuments "Heimautomatisierung mit Fhem"] wird vorausgesetzt. Im Anhang dieses Dokuments findet sich ein Teil über den Aufbau und die Funktion von HM-Geräten.

=== 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 (Gerät)''' und ein oder mehrere '''Channels (Kanäle)''' gegliedert. Jedes Device und jeder Channel wird in einer Entity in FHEM repräsentiert. 
Ausnahme: Sollte ein Gerät nur einen Kanal haben werden diese zusammen in einer Entity angelegt.
====Device (Gerät)====
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.

====Channel (Kanal)====
Ein Kanal ist die Funktionseinheit des Geräts. Hier ist die Funktion des Sensors oder Aktors realisiert. 
Nutzt ein Gerät nur einen Kanal, wird dieser in FHEM der Übersichtlichkeit halber nicht einzeln angelegt. Für die Kommandos und das Peering wird trotzdem die HM-ID des 1. Kanals verwendet. 
Nutzt ein Gerät hingegen mehrere Kanäle, werden diese per [[autocreate]] zusätzlich zum Device angelegt. Es ist aber möglich, bei Geräten mit virtuellen Kanälen, diese zu löschen und fehlende Attribute manuell dem Device hinzu zu fügen. Danach kann es wie ein 1-Kanal-Gerät genutzt werden. Allerdings werden die Kanäle beim erneuten Pairing von [[autocreate]] neu angelegt.

=====virtuelle Kanäle=====
Einige Dimmer unterstützen virtuelle Kanäle. Eigentlich haben sie keinen Hauptkanal sondern nur 3 virtuelle Kanäle, die je nach Verknüpfungslogik, den endgültigen Zustand des Aktors bestimmen. Dieses Verhalten wird in jedem Kanal per Register '''logicCombination''' gesetzt. 
Folgende Logik wird dabei angewendet: <tt>phyLevel = (((0% o Ch1) o Ch2) o Ch3)</tt> [o = Logik-Platzhalter] 
D.h. es wird immer der Kanal mit dem gesetzten Register mit dem vorherigen Teilergebnis kombiniert, angefangen mit Kanal1. 
Es gibt folgende Logik-Optionen: [einzelne Betrachtung von <tt>(Vorergebnis o Kanal)</tt>]
{|
!style="text-align:left;"|Wert!!style="text-align:left;"|Bedeutung!!style="text-align:left;"|Beispiel (alle Werte in %)
|-
|inactive||keine Verknüpfung|| 30 inactive 80 = 30
|-
|or||oder (höchster Wert zählt)|| 30 or 80 = 80
|-
|and||und (kleinster Wert zählt)|| 30 and 80 = 30
|-
|xor||entweder-oder (nur 1 Kanal darf über 0% sein)|| 30 xor 80 = 0 ''aber'' 30 xor 0 = 30
|-
|nor||oder negiert (höchster Wert subtrahiert von 100%)|| 30 nor 80 ''= !80'' = 20
|-
|nand||und negiert (niedrigster Wert subtrahiert von 100%)|| 30 nand 80 ''= !30'' = 70
|-
|orinv||oder mit invertiertem Kanal|| 30 orinv 80 ''= 30 or 20'' = 30
|-
|andinv||und mit invertiertem Kanal|| 30 andinv 80 ''= 30 and 20'' = 20
|-
|plus||Vorergebnis addiert mit Kanal|| 30 plus 80 = 100
|-
|minus||Vorergebnis subtrahiert mit Kanal|| 30 minus 80 = 0
|-
|mul||Vorergebnis multipliziert mit Kanal|| 30 mul 80 = 24
|-
|plusinv||Vorergebnis addiert mit invertiertem Kanal|| 30 plusinv 80 ''= 30 plus 20'' = 50
|-
|minusinv||Vorergebnis subtrahiert mit invertiertem Kanal|| 30 minusinv 80 ''= 30 minus 20'' = 10
|-
|mulinv||Vorergebnis multipliziert mit invertiertem Kanal|| 30 mulinv 80 ''= 30 mul 20'' = 6
|-
|invPlus||invertiertes Vorergebnis addiert mit Kanal|| 30 invPlus 80 ''= 70 plus 80'' = 100
|-
|invMinus||invertiertes Vorergebnis subtrahiert mit Kanal|| 30 invMinus 80 ''= 70 minus 80'' = 0
|-
|invMul||invertiertes Vorergebnis multipliziert mit Kanal|| 30 invMul 80 ''= 70 mul 80'' = 56
|}
: ''→ Siehe auch: [[HM-LC-Dim1PWM-CV Dimmaktor PWM DC-LED#Beispiele|Verknüpfungsbeispiel]]''

=== 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 [[HomeMatic#Protokol|Protokolls]], also der Kommunikation mit dem Device.
** rssi...: Gruppe von Daten die den [[HomeMatic#Rssi|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 [[Homematic_HMInfo#Integrit.C3.A4tspr.C3.BCfungen|configCheck]].
Da einige Entities viele Register haben kann man mit dem Attribut '''expert''' die Sichtbarkeit steuern. 
siehe auch [[Homematic_HMInfo#Infos|register]]. 
Von einigen Devices sind Register schwer zu lesen, z.B. config devices. Man kann die Register-Readings [[Homematic_HMInfo#archConfig|archivieren]] und beim reboot wieder [[Homematic_HMInfo#archConfig|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 [[HomeMatic#Device|Übertragungsmodi]], die ein Device unterstützt. Die Internals "prot..." enthalten alle notwendigen Daten.
* protState: Der Zustand der Protokollmaschine
** CMDs_done: alle Nachrichten übertragen, keine 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 [[Homematic_HMInfo#protoEvents|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, die beim Senden zwischen Peers erreicht werden. 
Die Zähler können mit '''set <device> clear rssi''' rückgesetzt werden. 
Eine Übersicht erhält man mit HMInfo [[Homematic_HMInfo#RSSI|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.

== Pairen und Peeren ==
: ''→ Siehe auch: [[Pairing und Peering]]''

HomeMatic-Geräte können mit einer Zentrale (Fhem) ''gepairt'' und mit anderen HM-Geräten ''gepeert'' werden.

=== Pairen ===
: ''→ Hauptartikel: [[HomeMatic Devices pairen]]''

HM-Geräte können mit und ohne Zentrale betrieben werden. Fhem geht davon aus, dass Geräte immer von einer Zentrale aus gesteuert werden können. Dazu muss das Gerät mit der Zentrale ''gepairt'' werden.

=== Peeren ===
: ''→ Siehe auch: [[Homematic Peering Beispiele]]

Um es Geräten zu ermöglichen auch ohne Zentrale zu interagieren (zum Beispiel wenn die Zentrale einen Defekt hat), können HM-Geräte untereinander ''gepeert'' werden.
Dazu wird ein Sensor-Kanal mit einem Aktor-Kanal verknüpft.

== HMInfo ==
: ''→ Siehe auch: [[Homematic HMInfo]]''

Bei der Betreuung einer HomeMatic-Installation ist das Modul [[Homematic_HMInfo|HMInfo]] sehr hilfreich. Es stellt eine Übersicht der HomeMatic-Komponenten zur Verfügung, kann die Konfiguration prüfen und Alarmierungen 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 ===
: ''→ Siehe auch: [[Virtueller Controller VCCU#Virtuelle Kanäle der VCCU]]

'''IO-Entities''' sind virtuelle Kanäle der Zentrale, mit denen andere HomeMatic-Geräte gepeert werden können. Diese Kanäle sind einem ''IO-Device'' zugeordnet – im Unterschied zu ''virtuellen Entities'' gibt es kein virtuelles Homematic-Gerät welches die Kanäle beherbergt.

Jedem IO-Device können bis zu 50 Kanäle zugewiesen werden. Wenn mehrere IO-Devices die gleiche HMId nutzen, zum Beispiel wenn ein [[Virtueller Controller VCCU|virtueller Controller]] verwendet wird, teilen sich diese IO-Devices die Kanäle.

'''Anlegen:'''

# IO-Device definieren
define <IO-Device> CUL_HM c0ffee
attr <IO-Device> model CCU-FHEM

# 4 IO-Entities definieren
set <IO-Device> virtual 4

Aktuell werden IO-Entities in Fhem nicht dargestellt.

=== Action Detector===
Einige Devices der HM-Geräteserie senden periodisch Nachrichten. Manche alle 3 Minuten, 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.
Die Kontrollinstanz ist ein Pseudo-Gerät "ActionDetector" mit der HMId "000000"

* 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

Durch das Setzen des Attributs im HM device wird der ActionDetector automatisch definiert - nach einem save steht er auch in der fhem.cfg.
Alternativ ist auch eine manuelle Definition möglich und sollte in etwa so aussehen:

define ActionDetector CUL_HM 000000
attr ActionDetector actCycle 30
attr ActionDetector event-on-change-reading .*
attr ActionDetector model ActionDetector

Die HMId "000000" darf nicht geändert werden.

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

* [[HomeMatic Devices pairen|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 [[Homematic_Nachrichten_sniffen|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 ==
* [http://www.homematic.com/ HomeMatic] Homepage
* Hersteller [http://www.eq-3.de eQ-3]

[[Kategorie:HomeMatic Components]]
[[Kategorie:Glossary]]

HomeMatic

2016-03-03T01:17:03Z

Cori: /* virtuelle Kanäle */

'''Achtung, diese Seite wird derzeit im Sinne einer klareren Beschreibung überarbeitet'''

'''HomeMatic''' (HM) ist ein System des Herstellers eQ-3 zur Steuerung und Überwachung von zahlreichen Aufgaben und Situationen im Haus. Erhältlich sind sowohl Geräte mit Funkschnittstelle 868.3 MHz, als auch (seit 2008) drahtgebundene Geräte mit RS485-Schnittstelle. Im Programm sind Geräte zur Heizungs- und Lichtsteuerung, Temperatur-, Luftfeuchte- und Feuchtemessung, Zutrittskontrolle, als Wasser-, Brand- und Bewegungsmelder sowie als Wetterstation, ferner gibt es noch Fernbedienungen und Statusdisplays.

=Grundlagen=
HomeMatic-Geräte können untereinander ''gepeert'' werden (engl. ''peers'' = "Gleiche"), im einfachsten Fall kann deshalb bereits ein Sensor (z.B. ein Temperatursensor) mit einem Aktor (z.B. einem Heizkörperregler) verbunden werden und diesen steuern. Hierbei können mehrere Sensoren und Aktoren untereinander verbunden werden, die Vorstellung der "Gleichen" ist also zutreffend.

HomeMatic-Geräte können auch mit einer Zentrale verbunden (''gepairt'') werden, die dann einen Teil der Steuerungslogik übernehmen kann. Bei dieser Verbindung spricht man vom ''Pairing'', weil jedes HomeMatic-Gerät nur mit einer Zentrale verbunden werden kann. Gepairte Geräte können auch nicht mehr direkt gepeert werden - dies geht dann nur noch unter Beteiligung der Zentrale.

==Voraussetzungen==
Für den Betrieb ohne Zentrale sind keine weiteren Voraussetzungen zu erfüllen.
===Zentrale von eQ-3===
Vom Hersteller eQ-3 selbst wird eine Zentrale (derzeit aktuell CCU-2) und Windows-Software zur Steuerung und Auswertung der HM-Komponenten angeboten.

===Fhem als Zentrale===
Zur Kommunikation mit HomeMatic benötigt Fhem eine Schnittstelle, die im 868,3-MHz-Band funken kann. Infrage kommen:
* [[CUL]] (USB)
* [[HM-CFG-USB USB Konfigurations-Adapter|HM-CFG-USB]] (USB)
* [[CUNO]] (LAN)
* [[HM-CFG-LAN]] (oft auch "HMLAN" genannt; LAN)

Für ''HomeMatic Wired'' benötigt man eine RS485-Schnittstelle. Verfügbar sind:
* [[HomeMatic Wired RS485 LAN Gateway|HMW-LGW-O-DR-GS-EU]] (LAN)

===Migration von CCU-2 zu Fhem===
Der Umzug einer bestehenden HomeMatic Installation von einer HomeMatic CCU-2 auf Fhem ist möglich. Um die an die Zentrale angebundenen Devices in Fhem ohne größere Umkonfiguration weiter verwenden zu können, muß die HM-Id und, falls verwendet, die AES-Schlüssel der CCU-2 in Fhem übernommen werden. Um diese Daten aus der CCU-2 auszulesen, wird eine SSH-Verbindung (zum Beispiel mit PuTTY unter Windows) aufgebaut. Die HM-Id befindet sich in der Datei <code>/usr/local/etc/config/rfd/BidCoS-RF.dev</code> in einer Zeile wie dieser:

<device serial="BidCoS-RF" type="HM-RCV-50" address="0xABCDEF" aes_key_index="0" firmware_version="2.11.9" bidcos_interface="KEQ1234567" roaming="true">

Die HM-Id ist der Wert des <code>address</code>-Attributs. Die dort angegebene hexadezimale Zahl (hier <code>0xABCDEF</code>) ist die HM-Id und wird in Fhem ohne das "0x"-Präfix verwendet.

Falls AES-Schlüssel eingerichtet sind, sind diese in der Datei <code>/etc/config_templates/crypttool.cfg</code> zu finden und können 1:1 als Schlüssel im [[HM-CFG-LAN]] in der gleichen Reihenfolge hinterlegt werden.
{{Todo|Wie werden AES-Schlüssel in HM-CFG-LAN "hinterlegt"?}}

==Prototokoll==
HM-Geräte kommunizieren untereinander mit dem Protokoll ''Bidirectional Communication Standard'', abgekürzt ''BidCoS''. Jedes HM-Gerät enthält also Sender und Empfänger, das ist einer der wesentlichen Unterschiede z.B. zum FS20-System.
*Jedes HM-Gerät meldet beim Empfang eines Steuerbefehls durch einen Peer an diesen eine Bestätigung „ACK“ zurück. Erkennt das HM-Gerät den Befehl nicht, sendet es ein ''NACK''. Kommt vom HM-Gerät keine Rückmeldung innerhalb einer festgelegten Zeit, meldet der steuernde Peer ein ''MISSING ACK''.
*Jedes HM-Gerät meldet ferner seinen Status nach dem Erhalt eines Steuerbefehls zurück - so kann auch ein lokal am Gerät erfolgender Tastendruck in beim steuernden Peer oder in der Zentrale registriert werden.

Das Protokoll ''BidCoS'' wurde zum großen Teil entschlüsselt, seine offen verfügbare Variante heißt ''AskSin''. Unter Verwendung der AskSin-Library entstehen derzeit erste Geräte, die in das HomeMatic-System eingebunden werden können. Zur Unterscheidung zwischen HM und den neuen Geräten werden diese als [[HomeBrew]] (HB) bezeichnet.

=Betrieb mit Fhem=
Die Kenntnis des Dokumentes [http://fhem.de/Heimautomatisierung-mit-fhem.pdf Einsteigerdokuments "Heimautomatisierung mit Fhem"] wird vorausgesetzt. Im Anhang dieses Dokuments findet sich ein Teil über den Aufbau und die Funktion von HM-Geräten.

=== 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.
=====virtuelle Kanäle=====
Einige Dimmer unterstützen virtuelle Kanäle. Eigentlich haben sie keinen Hauptkanal sondern nur 3 virtuelle Kanäle, die je nach Verknüpfungslogik, den endgültigen Zustand des Aktors bestimmen. Dieses Verhalten wird in jedem Kanal per Register '''logicCombination''' gesetzt. 
Folgende Logik wird dabei angewendet: <tt>phyLevel = (((0% o Ch1) o Ch2) o Ch3)</tt> [o = Logik-Platzhalter] 
D.h. es wird immer der Kanal mit dem gesetzten Register mit dem vorherigen Teilergebnis kombiniert, angefangen mit Kanal1. 
Es gibt folgende Logik-Optionen: [einzelne Betrachtung von <tt>(Vorergebnis o Kanal)</tt>]
{|
!style="text-align:left;"|Wert!!style="text-align:left;"|Bedeutung!!style="text-align:left;"|Beispiel (alle Werte in %)
|-
|inactive||keine Verknüpfung|| 30 inactive 80 = 30
|-
|or||oder (höchster Wert zählt)|| 30 or 80 = 80
|-
|and||und (kleinster Wert zählt)|| 30 and 80 = 30
|-
|xor||entweder-oder (nur 1 Kanal darf über 0% sein)|| 30 xor 80 = 0 ''aber'' 30 xor 0 = 30
|-
|nor||oder negiert (höchster Wert subtrahiert von 100%)|| 30 nor 80 ''= !80'' = 20
|-
|nand||und negiert (niedrigster Wert subtrahiert von 100%)|| 30 nand 80 ''= !30'' = 70
|-
|orinv||oder mit invertiertem Kanal|| 30 orinv 80 ''= 30 or 20'' = 30
|-
|andinv||und mit invertiertem Kanal|| 30 andinv 80 ''= 30 and 20'' = 20
|-
|plus||Vorergebnis addiert mit Kanal|| 30 plus 80 = 100
|-
|minus||Vorergebnis subtrahiert mit Kanal|| 30 minus 80 = 0
|-
|mul||Vorergebnis multipliziert mit Kanal|| 30 mul 80 = 24
|-
|plusinv||Vorergebnis addiert mit invertiertem Kanal|| 30 plusinv 80 ''= 30 plus 20'' = 50
|-
|minusinv||Vorergebnis subtrahiert mit invertiertem Kanal|| 30 minusinv 80 ''= 30 minus 20'' = 10
|-
|mulinv||Vorergebnis multipliziert mit invertiertem Kanal|| 30 mulinv 80 ''= 30 mul 20'' = 6
|-
|invPlus||invertiertes Vorergebnis addiert mit Kanal|| 30 invPlus 80 ''= 70 plus 80'' = 100
|-
|invMinus||invertiertes Vorergebnis subtrahiert mit Kanal|| 30 invMinus 80 ''= 70 minus 80'' = 0
|-
|invMul||invertiertes Vorergebnis multipliziert mit Kanal|| 30 invMul 80 ''= 70 mul 80'' = 56
|}
: ''→ Siehe auch: [[HM-LC-Dim1PWM-CV Dimmaktor PWM DC-LED#Beispiele|Verknüpfungsbeispiel]]''

=== 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 [[HomeMatic#Protokol|Protokolls]], also der Kommunikation mit dem Device.
** rssi...: Gruppe von Daten die den [[HomeMatic#Rssi|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 [[Homematic_HMInfo#Integrit.C3.A4tspr.C3.BCfungen|configCheck]].
Da einige Entities viele Register haben kann man mit dem Attribut '''expert''' die Sichtbarkeit steuern. 
siehe auch [[Homematic_HMInfo#Infos|register]]. 
Von einigen Devices sind Register schwer zu lesen, z.B. config devices. Man kann die Register-Readings [[Homematic_HMInfo#archConfig|archivieren]] und beim reboot wieder [[Homematic_HMInfo#archConfig|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 [[HomeMatic#Device|Übertragungsmodi]], die ein Device unterstützt. Die Internals "prot..." enthalten alle notwendigen Daten.
* protState: Der Zustand der Protokollmaschine
** CMDs_done: alle Nachrichten übertragen, keine 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 [[Homematic_HMInfo#protoEvents|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, die beim Senden zwischen Peers erreicht werden. 
Die Zähler können mit '''set <device> clear rssi''' rückgesetzt werden. 
Eine Übersicht erhält man mit HMInfo [[Homematic_HMInfo#RSSI|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.

== Pairen und Peeren ==
: ''→ Siehe auch: [[Pairing und Peering]]''

HomeMatic-Geräte können mit einer Zentrale (Fhem) ''gepairt'' und mit anderen HM-Geräten ''gepeert'' werden.

=== Pairen ===
: ''→ Hauptartikel: [[HomeMatic Devices pairen]]''

HM-Geräte können mit und ohne Zentrale betrieben werden. Fhem geht davon aus, dass Geräte immer von einer Zentrale aus gesteuert werden können. Dazu muss das Gerät mit der Zentrale ''gepairt'' werden.

=== Peeren ===
: ''→ Siehe auch: [[Homematic Peering Beispiele]]

Um es Geräten zu ermöglichen auch ohne Zentrale zu interagieren (zum Beispiel wenn die Zentrale einen Defekt hat), können HM-Geräte untereinander ''gepeert'' werden.
Dazu wird ein Sensor-Kanal mit einem Aktor-Kanal verknüpft.

== HMInfo ==
: ''→ Siehe auch: [[Homematic HMInfo]]''

Bei der Betreuung einer HomeMatic-Installation ist das Modul [[Homematic_HMInfo|HMInfo]] sehr hilfreich. Es stellt eine Übersicht der HomeMatic-Komponenten zur Verfügung, kann die Konfiguration prüfen und Alarmierungen 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 ===
: ''→ Siehe auch: [[Virtueller Controller VCCU#Virtuelle Kanäle der VCCU]]

'''IO-Entities''' sind virtuelle Kanäle der Zentrale, mit denen andere HomeMatic-Geräte gepeert werden können. Diese Kanäle sind einem ''IO-Device'' zugeordnet – im Unterschied zu ''virtuellen Entities'' gibt es kein virtuelles Homematic-Gerät welches die Kanäle beherbergt.

Jedem IO-Device können bis zu 50 Kanäle zugewiesen werden. Wenn mehrere IO-Devices die gleiche HMId nutzen, zum Beispiel wenn ein [[Virtueller Controller VCCU|virtueller Controller]] verwendet wird, teilen sich diese IO-Devices die Kanäle.

'''Anlegen:'''

# IO-Device definieren
define <IO-Device> CUL_HM c0ffee
attr <IO-Device> model CCU-FHEM

# 4 IO-Entities definieren
set <IO-Device> virtual 4

Aktuell werden IO-Entities in Fhem nicht dargestellt.

=== Action Detector===
Einige Devices der HM-Geräteserie senden periodisch Nachrichten. Manche alle 3 Minuten, 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.
Die Kontrollinstanz ist ein Pseudo-Gerät "ActionDetector" mit der HMId "000000"

* 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

Durch das Setzen des Attributs im HM device wird der ActionDetector automatisch definiert - nach einem save steht er auch in der fhem.cfg.
Alternativ ist auch eine manuelle Definition möglich und sollte in etwa so aussehen:

define ActionDetector CUL_HM 000000
attr ActionDetector actCycle 30
attr ActionDetector event-on-change-reading .*
attr ActionDetector model ActionDetector

Die HMId "000000" darf nicht geändert werden.

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

* [[HomeMatic Devices pairen|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 [[Homematic_Nachrichten_sniffen|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 ==
* [http://www.homematic.com/ HomeMatic] Homepage
* Hersteller [http://www.eq-3.de eQ-3]

[[Kategorie:HomeMatic Components]]
[[Kategorie:Glossary]]

HM-LC-Dim1PWM-CV Dimmaktor PWM DC-LED

2016-03-03T01:15:26Z

Cori: /* virtuelle Kanäle */

'''HM-LC-Dim1PWM-CV Dimmaktor PWM DC-LED'''
= Features =

Dimmaktor für LED-Leuchtmittel (z.B. LED-Leisten oder Flex-Stripes '''ohne Vorschaltgerät'''), deren Betriebsspannung 12 oder 24 V beträgt. Geeignet / vorgesehen für die Zwischendeckenmontage.

'''Technische Daten:'''
* Spannungsversorgung: 12 - 24 V (DC)
* Stromaufnahme (ohne Last): ~ 45 mA
* Anschlussleistung: max. 60 VA (5 A bei 12 V, 2,5 A bei 24 V)
* Lastbereich: 0 - 60 VA
* Geräteschutz: Überlast- und Temperatursicherung
* Maße(B x H x T): 40 x 32 x 164 mm

= Hinweise zur Hardware-Installation =

Der Dimmaktor benötigt eingangsseitig eine Gleichspannung von 12 oder 24 V.

= Hinweise zum Betrieb mit FHEM =

Das Pairen mit FHEM wird in [[HomeMatic Devices pairen|dieser Anleitung]] erläutert.

== Besonderheiten ==

Siehe [[HomeMatic#Besonderheiten|hier]]

== virtuelle Kanäle ==
Per autocreate wird das Device und 3 Kanäle angelegt. Diese sind virtuelle Kanäle und ergeben je nach Konfiguration zusammen das physische Level des Aktors. 
Ein Anwendungsbeispiel dazu weiter unten. 
Siehe [[HomeMatic#virtuelle Kanäle]]

== FHEM Config-Auszug ==
<pre>
define WZ.LEDdimmer CUL_HM 1D06D2
attr WZ.LEDdimmer .devInfo 410100
attr WZ.LEDdimmer .stc 20
attr WZ.LEDdimmer firmware 2.2
attr WZ.LEDdimmer model HM-LC-Dim1PWM-CV
attr WZ.LEDdimmer peerIDs
attr WZ.LEDdimmer room CUL_HM
attr WZ.LEDdimmer serialNr JEQ1567425
attr WZ.LEDdimmer subType dimmer
attr WZ.LEDdimmer webCmd toggle:on:off:statusRequest
</pre>

== Mögliche DIM-Operationen ==

<pre>
<bitte einfügen / erläutern>
</pre>

== FHEM-Log-Auszug ==

Bei attr global verbose 5 erscheint folgendes in der FHEM-Log-Datei (incl. Pair-Vorgang):
<pre>
<Datum>_<Zeit> 3: CUL_HM Unknown device CUL_HM_HM_LC_Dim1PWM_CV_1D06D2, please define it
<Datum>_<Zeit> 5: Triggering global (1 changes)
<Datum>_<Zeit> 5: Notify loop for global UNDEFINED CUL_HM_HM_LC_Dim1PWM_CV_1D06D2 CUL_HM 1D06D2 A1A0384001D06D20000002200674A45513033373931383020410100
<Datum>_<Zeit> 2: autocreate: define CUL_HM_HM_LC_Dim1PWM_CV_1D06D2 CUL_HM 1D06D2 A1A0384001D06D20000002200674A45513033373931383020410100
<Datum>_<Zeit> 3: CUL_HM pair: CUL_HM_HM_LC_Dim1PWM_CV_1D06D2 dimmer, model HM-LC-Dim1PWM-CV serialNr JEQ1567425
<Datum>_<Zeit> 5: Triggering CUL_HM_HM_LC_Dim1PWM_CV_1D06D2 (1 changes)
<Datum>_<Zeit> 5: Notify loop for CUL_HM_HM_LC_Dim1PWM_CV_1D06D2 R-pairCentral: set_0x123456
<Datum>_<Zeit> 5: HMLAN_Send: +1D06D2,00,00,
<Datum>_<Zeit> 5: HMLAN_Send: SE334EDD2,00,00000000,01,E334EDD2,AEA0011234561D06D200050000000000
<Datum>_<Zeit> 5: Triggering global (2 changes)
<Datum>_<Zeit> 2: autocreate: define FileLog_CUL_HM_HM_LC_Dim1PWM_CV_1D06D2 FileLog /opt/fhem/log/CUL_HM_HM_LC_Dim1PWM_CV_1D06D2-%Y-%m.log CUL_HM_HM_LC_Dim1PWM_CV_1D06D2
</pre>
== Event monitor ==
<pre>
<Datum>_<Zeit> CUL_HM CUL_HM_HM_LC_Dim1PWM_CV_1D06D2 R-pairCentral: set_0x123456
<Datum>_<Zeit> Global global UNDEFINED CUL_HM_HM_LC_Dim1PWM_CV_1D06D2 CUL_HM 1D06D2 A1A0384001D06D20000002200674A45513033373931383020410100
<Datum>_<Zeit> Global global DEFINED CUL_HM_HM_LC_Dim1PWM_CV_1D06D2
<Datum>_<Zeit> Global global DEFINED FileLog_CUL_HM_HM_LC_Dim1PWM_CV_1D06D2
</pre>

== Device-Log ==

Nach einem rename auf einen "verständlichen" Namen:
<pre>
<Datum>_<Zeit> WZ.LEDdimmer deviceMsg: 99.5 % (to HMLAN1)
<Datum>_<Zeit> WZ.LEDdimmer dim: down:99.5 %
<Datum>_<Zeit> WZ.LEDdimmer overload: off
<Datum>_<Zeit> WZ.LEDdimmer overheat: off
<Datum>_<Zeit> WZ.LEDdimmer reduced: off
<Datum>_<Zeit> WZ.LEDdimmer 99.5 %
<Datum>_<Zeit> WZ.LEDdimmer deviceMsg: off (to HMLAN1)
<Datum>_<Zeit> WZ.LEDdimmer dim: stop:off
<Datum>_<Zeit> WZ.LEDdimmer off
<Datum>_<Zeit> WZ.LEDdimmer set_toggle
<Datum>_<Zeit> WZ.LEDdimmer deviceMsg: on (to HMLAN1)
<Datum>_<Zeit> WZ.LEDdimmer dim: stop:on
<Datum>_<Zeit> WZ.LEDdimmer on
<Datum>_<Zeit> WZ.LEDdimmer set_off
<Datum>_<Zeit> WZ.LEDdimmer set_100
<Datum>_<Zeit> WZ.LEDdimmer set_0
</pre>

= Beispiele =
== Eingangslicht/Treppenhauslicht mit Bewegungsmelder ==
Dank der 3 virt. Kanäle kann man den Dimmer mit Bewegungsmeldern und Schaltern koppeln ohne das der Wert des anderen überschrieben wird, wenn diese unterschiedlichen Kanälen zugeordnet sind. Z.B. wird das Licht nicht vollständig ausgehen, wenn per Taster (das z.B. 100%-ige Licht) ausgeschaltet wird, der vom Bewegungsmelder gesetzte Timer (z.B. nur mit 50%) aber noch nicht abgelaufen ist. 
Ein Beispiel für die Verknüpfung aus dämmerungsgesteuerter Helligkeit, Bewegungsmelder und Taster wäre:
phyLevel = (((0% or Ch1) mul Ch2) plus Ch3)
* Ch1: Dämmerungskanal (or)
*: wird per FHEM bei einbrechender Dämmerung eingeschaltet und per <code>set ''Ch1'' 25 0 3600</code> innerhalb einer Stunde auf 25% gedimmt
*: bei beginnendem Sonnenaufgang reicht dann ein <code>set ''Ch1'' 100 300 3600</code> um innerhalb einer Stunde auf 100% hoch zu dimmen und nach weiteren 5 min automatisch aus zu gehen
*:: Die 3600Sek sind nur beispielhaft. Ich verwende eine berechnete Zeitspanne bis <code>sunset('horizon=-12')</code> bzw. <code>sunrise('horizon=0')</code>
* Ch2: Bewegungskanal (mul)
*: Bei erneuten Triggern sollte der Dimmer stets bei on gehalten bzw. wieder dahin versetzt werden. Außerdem ist es angebracht ein dezentes Flackern kurz vor dem Ausschalten (DlyOff) einzubauen und man kann die Ramp-Zeiten ruhig etwas verlängern. 
*: Durch die Verknüpfung per Multiplikation wird das Vorwarnen (Flackern) auch über den Ch1 weitergegeben, was bei einer Und-Verknüpfung nicht erfolgen würde. 
*: Für den Peer werden daher folgende Register gesetzt:
<pre>
shActionTypeDim = jmpToTarget
shDimJtDlyOff = on
shDimJtDlyOn = rampOn
shDimJtOff = dlyOn
shDimJtOn = on
shDimJtRampOff = rampOn
shDimJtRampOn = on
shOffDly = 15 s
shOffDlyBlink = on
shOffDlyNewTime = 0.6 s
shOffDlyOldTime = 9.4 s
shOffDlyStep = 20 %
shOnTime = 90 s
shRampOffTime = 2.5 s
shRampOnTime = 2.5 s
</pre>
* Ch3: Tasterkanal (plus)
*: Nur die Verknüpfung per Addition weicht von der Standardeinstellung ab. Somit kann die Helligkeit beim Hochdimmen per langem Tastendruck sofort erhöht werden. Bei der Oder-Verknüpfung erhält man erst eine Helligkeitserhöhung, wenn Ch3 die Kombination aus Ch1&2 übersteigt.

= Links =

Anleitung: [http://www.eq-3.de/Downloads/eq3/pdf_produkte/HM-LC-Dim1PWM-CV_UM_GE_eQ-3_110922.pdf PDF]

[[Kategorie:HomeMatic Components]]
[[Kategorie:Dimmer]]

HomeMatic

2016-03-03T01:14:37Z

Cori:

'''Achtung, diese Seite wird derzeit im Sinne einer klareren Beschreibung überarbeitet'''

'''HomeMatic''' (HM) ist ein System des Herstellers eQ-3 zur Steuerung und Überwachung von zahlreichen Aufgaben und Situationen im Haus. Erhältlich sind sowohl Geräte mit Funkschnittstelle 868.3 MHz, als auch (seit 2008) drahtgebundene Geräte mit RS485-Schnittstelle. Im Programm sind Geräte zur Heizungs- und Lichtsteuerung, Temperatur-, Luftfeuchte- und Feuchtemessung, Zutrittskontrolle, als Wasser-, Brand- und Bewegungsmelder sowie als Wetterstation, ferner gibt es noch Fernbedienungen und Statusdisplays.

=Grundlagen=
HomeMatic-Geräte können untereinander ''gepeert'' werden (engl. ''peers'' = "Gleiche"), im einfachsten Fall kann deshalb bereits ein Sensor (z.B. ein Temperatursensor) mit einem Aktor (z.B. einem Heizkörperregler) verbunden werden und diesen steuern. Hierbei können mehrere Sensoren und Aktoren untereinander verbunden werden, die Vorstellung der "Gleichen" ist also zutreffend.

HomeMatic-Geräte können auch mit einer Zentrale verbunden (''gepairt'') werden, die dann einen Teil der Steuerungslogik übernehmen kann. Bei dieser Verbindung spricht man vom ''Pairing'', weil jedes HomeMatic-Gerät nur mit einer Zentrale verbunden werden kann. Gepairte Geräte können auch nicht mehr direkt gepeert werden - dies geht dann nur noch unter Beteiligung der Zentrale.

==Voraussetzungen==
Für den Betrieb ohne Zentrale sind keine weiteren Voraussetzungen zu erfüllen.
===Zentrale von eQ-3===
Vom Hersteller eQ-3 selbst wird eine Zentrale (derzeit aktuell CCU-2) und Windows-Software zur Steuerung und Auswertung der HM-Komponenten angeboten.

===Fhem als Zentrale===
Zur Kommunikation mit HomeMatic benötigt Fhem eine Schnittstelle, die im 868,3-MHz-Band funken kann. Infrage kommen:
* [[CUL]] (USB)
* [[HM-CFG-USB USB Konfigurations-Adapter|HM-CFG-USB]] (USB)
* [[CUNO]] (LAN)
* [[HM-CFG-LAN]] (oft auch "HMLAN" genannt; LAN)

Für ''HomeMatic Wired'' benötigt man eine RS485-Schnittstelle. Verfügbar sind:
* [[HomeMatic Wired RS485 LAN Gateway|HMW-LGW-O-DR-GS-EU]] (LAN)

===Migration von CCU-2 zu Fhem===
Der Umzug einer bestehenden HomeMatic Installation von einer HomeMatic CCU-2 auf Fhem ist möglich. Um die an die Zentrale angebundenen Devices in Fhem ohne größere Umkonfiguration weiter verwenden zu können, muß die HM-Id und, falls verwendet, die AES-Schlüssel der CCU-2 in Fhem übernommen werden. Um diese Daten aus der CCU-2 auszulesen, wird eine SSH-Verbindung (zum Beispiel mit PuTTY unter Windows) aufgebaut. Die HM-Id befindet sich in der Datei <code>/usr/local/etc/config/rfd/BidCoS-RF.dev</code> in einer Zeile wie dieser:

<device serial="BidCoS-RF" type="HM-RCV-50" address="0xABCDEF" aes_key_index="0" firmware_version="2.11.9" bidcos_interface="KEQ1234567" roaming="true">

Die HM-Id ist der Wert des <code>address</code>-Attributs. Die dort angegebene hexadezimale Zahl (hier <code>0xABCDEF</code>) ist die HM-Id und wird in Fhem ohne das "0x"-Präfix verwendet.

Falls AES-Schlüssel eingerichtet sind, sind diese in der Datei <code>/etc/config_templates/crypttool.cfg</code> zu finden und können 1:1 als Schlüssel im [[HM-CFG-LAN]] in der gleichen Reihenfolge hinterlegt werden.
{{Todo|Wie werden AES-Schlüssel in HM-CFG-LAN "hinterlegt"?}}

==Prototokoll==
HM-Geräte kommunizieren untereinander mit dem Protokoll ''Bidirectional Communication Standard'', abgekürzt ''BidCoS''. Jedes HM-Gerät enthält also Sender und Empfänger, das ist einer der wesentlichen Unterschiede z.B. zum FS20-System.
*Jedes HM-Gerät meldet beim Empfang eines Steuerbefehls durch einen Peer an diesen eine Bestätigung „ACK“ zurück. Erkennt das HM-Gerät den Befehl nicht, sendet es ein ''NACK''. Kommt vom HM-Gerät keine Rückmeldung innerhalb einer festgelegten Zeit, meldet der steuernde Peer ein ''MISSING ACK''.
*Jedes HM-Gerät meldet ferner seinen Status nach dem Erhalt eines Steuerbefehls zurück - so kann auch ein lokal am Gerät erfolgender Tastendruck in beim steuernden Peer oder in der Zentrale registriert werden.

Das Protokoll ''BidCoS'' wurde zum großen Teil entschlüsselt, seine offen verfügbare Variante heißt ''AskSin''. Unter Verwendung der AskSin-Library entstehen derzeit erste Geräte, die in das HomeMatic-System eingebunden werden können. Zur Unterscheidung zwischen HM und den neuen Geräten werden diese als [[HomeBrew]] (HB) bezeichnet.

=Betrieb mit Fhem=
Die Kenntnis des Dokumentes [http://fhem.de/Heimautomatisierung-mit-fhem.pdf Einsteigerdokuments "Heimautomatisierung mit Fhem"] wird vorausgesetzt. Im Anhang dieses Dokuments findet sich ein Teil über den Aufbau und die Funktion von HM-Geräten.

=== 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.
=====virtuelle Kanäle=====
Einige Dimmer unterstützen virtuelle Kanäle. Eigentlich haben sie keinen Hauptkanal sondern nur 3 virtuelle Kanäle, die je nach Verknüpfungslogik, den endgültigen Zustand des Aktors bestimmen. Dieses Verhalten wird in jedem Kanal per Register '''logicCombination''' gesetzt. 
Folgende Logik wird dabei angewendet: <tt>phyLevel = (((0% o Ch1) o Ch2) o Ch3)</tt> [o = Logik-Platzhalter] 
D.h. es wird immer der Kanal mit dem gesetzten Register mit dem niedrigeren Teilergebnis kombiniert, angefangen mit Kanal1. 
Es gibt folgende Logik-Optionen: [einzelne Betrachtung von <tt>(Vorergebnis o Kanal)</tt>]
{|
!style="text-align:left;"|Wert!!style="text-align:left;"|Bedeutung!!style="text-align:left;"|Beispiel (alle Werte in %)
|-
|inactive||keine Verknüpfung|| 30 inactive 80 = 30
|-
|or||oder (höchster Wert zählt)|| 30 or 80 = 80
|-
|and||und (kleinster Wert zählt)|| 30 and 80 = 30
|-
|xor||entweder-oder (nur 1 Kanal darf über 0% sein)|| 30 xor 80 = 0 ''aber'' 30 xor 0 = 30
|-
|nor||oder negiert (höchster Wert subtrahiert von 100%)|| 30 nor 80 ''= !80'' = 20
|-
|nand||und negiert (niedrigster Wert subtrahiert von 100%)|| 30 nand 80 ''= !30'' = 70
|-
|orinv||oder mit invertiertem Kanal|| 30 orinv 80 ''= 30 or 20'' = 30
|-
|andinv||und mit invertiertem Kanal|| 30 andinv 80 ''= 30 and 20'' = 20
|-
|plus||Vorergebnis addiert mit Kanal|| 30 plus 80 = 100
|-
|minus||Vorergebnis subtrahiert mit Kanal|| 30 minus 80 = 0
|-
|mul||Vorergebnis multipliziert mit Kanal|| 30 mul 80 = 24
|-
|plusinv||Vorergebnis addiert mit invertiertem Kanal|| 30 plusinv 80 ''= 30 plus 20'' = 50
|-
|minusinv||Vorergebnis subtrahiert mit invertiertem Kanal|| 30 minusinv 80 ''= 30 minus 20'' = 10
|-
|mulinv||Vorergebnis multipliziert mit invertiertem Kanal|| 30 mulinv 80 ''= 30 mul 20'' = 6
|-
|invPlus||invertiertes Vorergebnis addiert mit Kanal|| 30 invPlus 80 ''= 70 plus 80'' = 100
|-
|invMinus||invertiertes Vorergebnis subtrahiert mit Kanal|| 30 invMinus 80 ''= 70 minus 80'' = 0
|-
|invMul||invertiertes Vorergebnis multipliziert mit Kanal|| 30 invMul 80 ''= 70 mul 80'' = 56
|}
: ''→ Siehe auch: [[HM-LC-Dim1PWM-CV Dimmaktor PWM DC-LED#Beispiele|Verknüpfungsbeispiel]]''

=== 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 [[HomeMatic#Protokol|Protokolls]], also der Kommunikation mit dem Device.
** rssi...: Gruppe von Daten die den [[HomeMatic#Rssi|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 [[Homematic_HMInfo#Integrit.C3.A4tspr.C3.BCfungen|configCheck]].
Da einige Entities viele Register haben kann man mit dem Attribut '''expert''' die Sichtbarkeit steuern. 
siehe auch [[Homematic_HMInfo#Infos|register]]. 
Von einigen Devices sind Register schwer zu lesen, z.B. config devices. Man kann die Register-Readings [[Homematic_HMInfo#archConfig|archivieren]] und beim reboot wieder [[Homematic_HMInfo#archConfig|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 [[HomeMatic#Device|Übertragungsmodi]], die ein Device unterstützt. Die Internals "prot..." enthalten alle notwendigen Daten.
* protState: Der Zustand der Protokollmaschine
** CMDs_done: alle Nachrichten übertragen, keine 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 [[Homematic_HMInfo#protoEvents|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, die beim Senden zwischen Peers erreicht werden. 
Die Zähler können mit '''set <device> clear rssi''' rückgesetzt werden. 
Eine Übersicht erhält man mit HMInfo [[Homematic_HMInfo#RSSI|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.

== Pairen und Peeren ==
: ''→ Siehe auch: [[Pairing und Peering]]''

HomeMatic-Geräte können mit einer Zentrale (Fhem) ''gepairt'' und mit anderen HM-Geräten ''gepeert'' werden.

=== Pairen ===
: ''→ Hauptartikel: [[HomeMatic Devices pairen]]''

HM-Geräte können mit und ohne Zentrale betrieben werden. Fhem geht davon aus, dass Geräte immer von einer Zentrale aus gesteuert werden können. Dazu muss das Gerät mit der Zentrale ''gepairt'' werden.

=== Peeren ===
: ''→ Siehe auch: [[Homematic Peering Beispiele]]

Um es Geräten zu ermöglichen auch ohne Zentrale zu interagieren (zum Beispiel wenn die Zentrale einen Defekt hat), können HM-Geräte untereinander ''gepeert'' werden.
Dazu wird ein Sensor-Kanal mit einem Aktor-Kanal verknüpft.

== HMInfo ==
: ''→ Siehe auch: [[Homematic HMInfo]]''

Bei der Betreuung einer HomeMatic-Installation ist das Modul [[Homematic_HMInfo|HMInfo]] sehr hilfreich. Es stellt eine Übersicht der HomeMatic-Komponenten zur Verfügung, kann die Konfiguration prüfen und Alarmierungen 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 ===
: ''→ Siehe auch: [[Virtueller Controller VCCU#Virtuelle Kanäle der VCCU]]

'''IO-Entities''' sind virtuelle Kanäle der Zentrale, mit denen andere HomeMatic-Geräte gepeert werden können. Diese Kanäle sind einem ''IO-Device'' zugeordnet – im Unterschied zu ''virtuellen Entities'' gibt es kein virtuelles Homematic-Gerät welches die Kanäle beherbergt.

Jedem IO-Device können bis zu 50 Kanäle zugewiesen werden. Wenn mehrere IO-Devices die gleiche HMId nutzen, zum Beispiel wenn ein [[Virtueller Controller VCCU|virtueller Controller]] verwendet wird, teilen sich diese IO-Devices die Kanäle.

'''Anlegen:'''

# IO-Device definieren
define <IO-Device> CUL_HM c0ffee
attr <IO-Device> model CCU-FHEM

# 4 IO-Entities definieren
set <IO-Device> virtual 4

Aktuell werden IO-Entities in Fhem nicht dargestellt.

=== Action Detector===
Einige Devices der HM-Geräteserie senden periodisch Nachrichten. Manche alle 3 Minuten, 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.
Die Kontrollinstanz ist ein Pseudo-Gerät "ActionDetector" mit der HMId "000000"

* 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

Durch das Setzen des Attributs im HM device wird der ActionDetector automatisch definiert - nach einem save steht er auch in der fhem.cfg.
Alternativ ist auch eine manuelle Definition möglich und sollte in etwa so aussehen:

define ActionDetector CUL_HM 000000
attr ActionDetector actCycle 30
attr ActionDetector event-on-change-reading .*
attr ActionDetector model ActionDetector

Die HMId "000000" darf nicht geändert werden.

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

* [[HomeMatic Devices pairen|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 [[Homematic_Nachrichten_sniffen|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 ==
* [http://www.homematic.com/ HomeMatic] Homepage
* Hersteller [http://www.eq-3.de eQ-3]

[[Kategorie:HomeMatic Components]]
[[Kategorie:Glossary]]

HM-LC-Dim1PWM-CV Dimmaktor PWM DC-LED

2016-03-03T01:11:27Z

Cori:

'''HM-LC-Dim1PWM-CV Dimmaktor PWM DC-LED'''
= Features =

Dimmaktor für LED-Leuchtmittel (z.B. LED-Leisten oder Flex-Stripes '''ohne Vorschaltgerät'''), deren Betriebsspannung 12 oder 24 V beträgt. Geeignet / vorgesehen für die Zwischendeckenmontage.

'''Technische Daten:'''
* Spannungsversorgung: 12 - 24 V (DC)
* Stromaufnahme (ohne Last): ~ 45 mA
* Anschlussleistung: max. 60 VA (5 A bei 12 V, 2,5 A bei 24 V)
* Lastbereich: 0 - 60 VA
* Geräteschutz: Überlast- und Temperatursicherung
* Maße(B x H x T): 40 x 32 x 164 mm

= Hinweise zur Hardware-Installation =

Der Dimmaktor benötigt eingangsseitig eine Gleichspannung von 12 oder 24 V.

= Hinweise zum Betrieb mit FHEM =

Das Pairen mit FHEM wird in [[HomeMatic Devices pairen|dieser Anleitung]] erläutert.

== Besonderheiten ==

Siehe [[HomeMatic#Besonderheiten|hier]]

== virtuelle Kanäle ==
Per autocreate wird das Device und 3 Kanäle angelegt. Diese sind virtuelle Kanäle und ergeben je nach Konfiguration zusammen das physische Level des Aktors. 
Ein Anwendungsbeispiel dazu weiter unten.
Siehe [[HomeMatic#virtuelle Kanäle]]

== FHEM Config-Auszug ==
<pre>
define WZ.LEDdimmer CUL_HM 1D06D2
attr WZ.LEDdimmer .devInfo 410100
attr WZ.LEDdimmer .stc 20
attr WZ.LEDdimmer firmware 2.2
attr WZ.LEDdimmer model HM-LC-Dim1PWM-CV
attr WZ.LEDdimmer peerIDs
attr WZ.LEDdimmer room CUL_HM
attr WZ.LEDdimmer serialNr JEQ1567425
attr WZ.LEDdimmer subType dimmer
attr WZ.LEDdimmer webCmd toggle:on:off:statusRequest
</pre>

== Mögliche DIM-Operationen ==

<pre>
<bitte einfügen / erläutern>
</pre>

== FHEM-Log-Auszug ==

Bei attr global verbose 5 erscheint folgendes in der FHEM-Log-Datei (incl. Pair-Vorgang):
<pre>
<Datum>_<Zeit> 3: CUL_HM Unknown device CUL_HM_HM_LC_Dim1PWM_CV_1D06D2, please define it
<Datum>_<Zeit> 5: Triggering global (1 changes)
<Datum>_<Zeit> 5: Notify loop for global UNDEFINED CUL_HM_HM_LC_Dim1PWM_CV_1D06D2 CUL_HM 1D06D2 A1A0384001D06D20000002200674A45513033373931383020410100
<Datum>_<Zeit> 2: autocreate: define CUL_HM_HM_LC_Dim1PWM_CV_1D06D2 CUL_HM 1D06D2 A1A0384001D06D20000002200674A45513033373931383020410100
<Datum>_<Zeit> 3: CUL_HM pair: CUL_HM_HM_LC_Dim1PWM_CV_1D06D2 dimmer, model HM-LC-Dim1PWM-CV serialNr JEQ1567425
<Datum>_<Zeit> 5: Triggering CUL_HM_HM_LC_Dim1PWM_CV_1D06D2 (1 changes)
<Datum>_<Zeit> 5: Notify loop for CUL_HM_HM_LC_Dim1PWM_CV_1D06D2 R-pairCentral: set_0x123456
<Datum>_<Zeit> 5: HMLAN_Send: +1D06D2,00,00,
<Datum>_<Zeit> 5: HMLAN_Send: SE334EDD2,00,00000000,01,E334EDD2,AEA0011234561D06D200050000000000
<Datum>_<Zeit> 5: Triggering global (2 changes)
<Datum>_<Zeit> 2: autocreate: define FileLog_CUL_HM_HM_LC_Dim1PWM_CV_1D06D2 FileLog /opt/fhem/log/CUL_HM_HM_LC_Dim1PWM_CV_1D06D2-%Y-%m.log CUL_HM_HM_LC_Dim1PWM_CV_1D06D2
</pre>
== Event monitor ==
<pre>
<Datum>_<Zeit> CUL_HM CUL_HM_HM_LC_Dim1PWM_CV_1D06D2 R-pairCentral: set_0x123456
<Datum>_<Zeit> Global global UNDEFINED CUL_HM_HM_LC_Dim1PWM_CV_1D06D2 CUL_HM 1D06D2 A1A0384001D06D20000002200674A45513033373931383020410100
<Datum>_<Zeit> Global global DEFINED CUL_HM_HM_LC_Dim1PWM_CV_1D06D2
<Datum>_<Zeit> Global global DEFINED FileLog_CUL_HM_HM_LC_Dim1PWM_CV_1D06D2
</pre>

== Device-Log ==

Nach einem rename auf einen "verständlichen" Namen:
<pre>
<Datum>_<Zeit> WZ.LEDdimmer deviceMsg: 99.5 % (to HMLAN1)
<Datum>_<Zeit> WZ.LEDdimmer dim: down:99.5 %
<Datum>_<Zeit> WZ.LEDdimmer overload: off
<Datum>_<Zeit> WZ.LEDdimmer overheat: off
<Datum>_<Zeit> WZ.LEDdimmer reduced: off
<Datum>_<Zeit> WZ.LEDdimmer 99.5 %
<Datum>_<Zeit> WZ.LEDdimmer deviceMsg: off (to HMLAN1)
<Datum>_<Zeit> WZ.LEDdimmer dim: stop:off
<Datum>_<Zeit> WZ.LEDdimmer off
<Datum>_<Zeit> WZ.LEDdimmer set_toggle
<Datum>_<Zeit> WZ.LEDdimmer deviceMsg: on (to HMLAN1)
<Datum>_<Zeit> WZ.LEDdimmer dim: stop:on
<Datum>_<Zeit> WZ.LEDdimmer on
<Datum>_<Zeit> WZ.LEDdimmer set_off
<Datum>_<Zeit> WZ.LEDdimmer set_100
<Datum>_<Zeit> WZ.LEDdimmer set_0
</pre>

= Beispiele =
== Eingangslicht/Treppenhauslicht mit Bewegungsmelder ==
Dank der 3 virt. Kanäle kann man den Dimmer mit Bewegungsmeldern und Schaltern koppeln ohne das der Wert des anderen überschrieben wird, wenn diese unterschiedlichen Kanälen zugeordnet sind. Z.B. wird das Licht nicht vollständig ausgehen, wenn per Taster (das z.B. 100%-ige Licht) ausgeschaltet wird, der vom Bewegungsmelder gesetzte Timer (z.B. nur mit 50%) aber noch nicht abgelaufen ist. 
Ein Beispiel für die Verknüpfung aus dämmerungsgesteuerter Helligkeit, Bewegungsmelder und Taster wäre:
phyLevel = (((0% or Ch1) mul Ch2) plus Ch3)
* Ch1: Dämmerungskanal (or)
*: wird per FHEM bei einbrechender Dämmerung eingeschaltet und per <code>set ''Ch1'' 25 0 3600</code> innerhalb einer Stunde auf 25% gedimmt
*: bei beginnendem Sonnenaufgang reicht dann ein <code>set ''Ch1'' 100 300 3600</code> um innerhalb einer Stunde auf 100% hoch zu dimmen und nach weiteren 5 min automatisch aus zu gehen
*:: Die 3600Sek sind nur beispielhaft. Ich verwende eine berechnete Zeitspanne bis <code>sunset('horizon=-12')</code> bzw. <code>sunrise('horizon=0')</code>
* Ch2: Bewegungskanal (mul)
*: Bei erneuten Triggern sollte der Dimmer stets bei on gehalten bzw. wieder dahin versetzt werden. Außerdem ist es angebracht ein dezentes Flackern kurz vor dem Ausschalten (DlyOff) einzubauen und man kann die Ramp-Zeiten ruhig etwas verlängern. 
*: Durch die Verknüpfung per Multiplikation wird das Vorwarnen (Flackern) auch über den Ch1 weitergegeben, was bei einer Und-Verknüpfung nicht erfolgen würde. 
*: Für den Peer werden daher folgende Register gesetzt:
<pre>
shActionTypeDim = jmpToTarget
shDimJtDlyOff = on
shDimJtDlyOn = rampOn
shDimJtOff = dlyOn
shDimJtOn = on
shDimJtRampOff = rampOn
shDimJtRampOn = on
shOffDly = 15 s
shOffDlyBlink = on
shOffDlyNewTime = 0.6 s
shOffDlyOldTime = 9.4 s
shOffDlyStep = 20 %
shOnTime = 90 s
shRampOffTime = 2.5 s
shRampOnTime = 2.5 s
</pre>
* Ch3: Tasterkanal (plus)
*: Nur die Verknüpfung per Addition weicht von der Standardeinstellung ab. Somit kann die Helligkeit beim Hochdimmen per langem Tastendruck sofort erhöht werden. Bei der Oder-Verknüpfung erhält man erst eine Helligkeitserhöhung, wenn Ch3 die Kombination aus Ch1&2 übersteigt.

= Links =

Anleitung: [http://www.eq-3.de/Downloads/eq3/pdf_produkte/HM-LC-Dim1PWM-CV_UM_GE_eQ-3_110922.pdf PDF]

[[Kategorie:HomeMatic Components]]
[[Kategorie:Dimmer]]