HomeMatic: Unterschied zwischen den Versionen
Rohan (Diskussion | Beiträge) K (→Fhem als Zentrale: Hinweis und Link auf HM-CFG-USB eingetragen) |
K (Schreibweise "HomeMatic") |
||
(46 dazwischenliegende Versionen von 20 Benutzern werden nicht angezeigt) | |||
Zeile 1: | Zeile 1: | ||
''' | '''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. | ||
Das ähnliche klingende '''''[[HomeMatic IP]]''''' ist eine neue Generation von Geräten und Funkprotokoll (HM-IP: IP over BidCos). Die dort angebotenen Geräte lassen sich über den Einsatz einer (physischen) CCU2 (bzw. CCU3) oder anderen Lösungen wie [https://github.com/leonsio/YAHM YAHM], [https://github.com/alexreinert/piVCCU piVCCU], raspberrymatic oder {{Link2Forum|Topic=97295|LinkText=DebMatic}} usw. und den [[HMCCU|HomeMatic-Modulen]] integrieren. | |||
'''HomeMatic''' (HM) | |||
=Grundlagen= | =Grundlagen= | ||
Zeile 8: | Zeile 7: | ||
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. | 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. | ||
{{Hinweis|Das Einsteiger-pdf ''[http://fhem.de/Heimautomatisierung-mit-fhem.pdf Heimautomatisierung mit FHEM]'' enthält einen sehr umfangreichen Anhang mit weiteren Informationen zur Funktionsweise und zur Einbindung von HomeMatic-Geräten (BidCoS mit dem Modul CUL_HM) in FHEM.}} | |||
==Voraussetzungen== | ==Voraussetzungen== | ||
Für den Betrieb ohne Zentrale sind keine weiteren Voraussetzungen zu erfüllen. | Für den Betrieb ohne Zentrale sind keine weiteren Voraussetzungen zu erfüllen. | ||
===Zentrale von eQ-3=== | ===Zentrale von eQ-3=== | ||
Vom Hersteller eQ-3 selbst wird eine Zentrale (derzeit aktuell | Vom Hersteller eQ-3 selbst wird eine Zentrale (derzeit aktuell CCU3) und Windows-Software zur Steuerung und Auswertung der HM-Komponenten angeboten. Diese Zentrale kann wie eingangs dargestellt über das Modul [[HMCCU]] in FHEM eingebunden werden und dann neben HM-IP- und HM-wired-Komponenten auch solche mit BidCoS verwalten. | ||
=== | |||
===FHEM als Zentrale=== | |||
''' | Zur Kommunikation mit HomeMatic benötigt FHEM eine Schnittstelle, die im 868,3-MHz-Band funken kann. Infrage kommen: | ||
{{Randnotiz|RNTyp=r|RNText=Nicht geeignet ist das Funkmodul aus dem "Charly"-Bausatz von eQ-3; mit diesem kann ausschließlich eine CCU aufgebaut werden, zu nutzen mit den HMCCU-Modulen!}}* [[HM-MOD-RPI-PCB HomeMatic Funkmodul für Raspberry Pi]] (RPI, WLAN, LAN, USB) | |||
* [[HM-LGW-O-TW-W-EU Funk-LAN Gateway]] (LAN) | |||
* [[HM-CFG-LAN]] (oft auch "HMLAN" genannt; LAN; nicht mehr lieferbar) | |||
* [[HM-CFG-USB USB Konfigurations-Adapter|HM-CFG-USB]] (USB, nicht mehr lieferbar) | |||
* [[CUL]] und andere Geräte mit CC110x-Transceiver, [[CUNO]], SelbstbauCUL, nanoCUL, umgeflashter MAX-Cube, MapleCUx, CUNX usw. (USB, GPIO, LAN , WLAN) | |||
Erfahrungsgemäß ist der Einsatz originaler HomeMatic IOs empfehlenswert, da es bei allen CUL-Derivaten immer wieder zu Schwierigkeiten kommen kann, vor allem in größeren Installationen und bei der Kommunikation mit komplexeren Geräten. Wer dennoch einen CUL für HomeMatic verwenden will, sollte eine speziell für den Betrieb mit HomeMatic optimierte CUL-firmware ({{Link2Forum|Topic=24436|LinkText=tsculfw - TimeStamp Firmware}}) verwenden. Bei HomeMatic ist das Timing der Telegramme entscheidend sonst kann es zu "MISSING_ACK" bzw. "RESPONSE TIMEOUT:RegisterRead" u.ä. Meldungen kommen! Zusätzlich sind '''unbedingt''' die Hinweise im Artikel [[AES Encryption]] zu beachten! | |||
Für ''HomeMatic Wired'' benötigt man eine RS485-Schnittstelle. Das "offizielle" Gateway [[HomeMatic Wired RS485 LAN Gateway|HMW-LGW-O-DR-GS-EU]] (LAN) funktioniert prinzipiell mit FHEM, der Einsatz wird aber nicht empfohlen. Hier gibt es Alternativen dazu: [[Serial/Netzwerk-RS485-Adapter]]. | |||
===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="<span style="color: maroon; font-weight: bold;">0xABCDEF</span>" 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"?}} | |||
== | ==Protokoll== | ||
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. | 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 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. | *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 | 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 | |||
Die Kenntnis des Dokumentes [http://fhem.de/Heimautomatisierung-mit-fhem.pdf Einsteigerdokuments "Heimautomatisierung mit | ==Firmware== | ||
Angaben zur Aktualisierung der Firmware der HomeMatic Geräte finden sich zum Beispiel in dem [https://heinz-otto.blogspot.com/2016/11/homematic-firmwareupdate.html Blog von Otto] und im {{Link2Forum|Topic=59301|Message=506762|LinkText=Forum}}. | |||
=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)=== | === Einrichten des IO-Devices (Funkschnittstelle)=== | ||
Zuerst muss ein IO-Device eingerichtet werden, um mit HM Geräten kommunizieren zu können. | Zuerst muss ein IO-Device eingerichtet werden, um mit HM Geräten kommunizieren zu können. Hier ist eine Liste der [[HomeMatic#FHEM als Zentrale|Schnittstellen]]. | ||
=== Struktur von HM Geräten=== | === Struktur von HM Geräten=== | ||
HM Geräte sind logisch in ein '''Device''' und ein oder mehrere '''Kanäle''' gegliedert. Jedes Device und jeder | 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. <br> | ||
Ausnahme: Sollte ein Gerät nur einen Kanal haben | Ausnahme: Sollte ein Gerät nur einen Kanal haben werden diese zusammen in einer Entity angelegt. | ||
====Device==== | ====Device==== | ||
Das Device ist für die Kommunikation verantwortlich. Es sortiert und ordnet die zu sendenden und empfangenden Nachrichten. | 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 [[ | Man kann prüfen, ob alle Nachrichten übertragen sind, oder ob es Probleme gegeben hat. Die Variablen "prot..." geben Auskunft darüber. Siehe auch [[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. | 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. | ||
Einige Devices unterstützen mehrere Modi parallel. | |||
===== Config===== | ===== Config===== | ||
Wird von allen Devices unterstützt, auch wenn es bei Always kaum genutzt werden kann. | 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- | Man setzt die Kommandos in FHEM ab und diese warten in der Kommando-Queue. | ||
Wenn die | 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. | ||
Config wird bei allen Devices zum | |||
===== Always===== | ===== Always===== | ||
Trifft man meist bei netzbetriebenen Geräten an, da diese kein Problem mit dem Energieverbrauch haben. Man kann immer mit dem Device kommunizieren. | Trifft man meist bei netzbetriebenen Geräten an, da diese kein Problem mit dem Energieverbrauch haben. Man kann immer mit dem Device kommunizieren. | ||
===== Burst===== | ===== Burst===== | ||
Nur der Empfänger des Device ist aktiv. Über eine Aufweck- | 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 Anderen ist die Aufweck-Sequenz funktechnisch aufwändig und belastet die maximal erlaubte Sendekapazität des IO device je Stunde. | ||
===== ConditionalBurst===== | ===== 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 | 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===== | ===== LazyConfig===== | ||
Kommandos in der Queue werden bearbeitet, wenn eine Aktion vom Device ausgeht. So zum Beispiel ein Tastendruck bei einer Fernbedienung. | 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. | Dieser mode wird von CUL/CUNO nicht unterstützt. FHEM ignoriert diese Option automatisch und wartet i.A. auf ein Config. | ||
===== Wakeup===== | ===== 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. | 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==== | ||
Ein Kanal ist die Funktionseinheit des Geräts. Hier ist die Funktion des Sensors oder Aktors realisiert. | 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. <br /> | |||
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. <br /> | |||
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=== | === Variablen=== | ||
Wie alle FHEM Entities werden 4 Gruppen von Daten unterstützt: | Wie alle FHEM Entities werden 4 Gruppen von Daten unterstützt: | ||
* Internals: Im Web-Interface sichtbare Variablen, die allgemeine Informationen über den Zustand enthalten. | * Internals: Im Web-Interface sichtbare Variablen, die allgemeine Informationen über den Zustand enthalten. | ||
* Readings: Im Web-Interface sichtbare Variablen. Sie werden aus von | * Readings: Im Web-Interface sichtbare Variablen. Sie werden aus von Entities empfangenen Nachrichten generiert. Man kann mit notify Trigger auf diese 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. | * 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 | * 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==== | ==== Internals==== | ||
Viele Variablen sind nicht HM spezifisch - deren Bedeutung muss | Viele Variablen sind nicht HM spezifisch - deren Bedeutung muss im allgemeinen Teil nachgelesen werden. Spezifische Variablen sind: | ||
*Device | *Device | ||
** channel_xx: Liste der Kanäle, die dem Device zugeordnet sind. | ** channel_xx: Liste der Kanäle, die dem Device zugeordnet sind. | ||
** prot... : Gruppe von Daten zum Zustand des | ** prot... : Gruppe von Daten zum Zustand des [[HomeMatic#Protokol|Protokolls]], also der Kommunikation mit dem Device. | ||
** rssi...: Gruppe von Daten die den | ** rssi...: Gruppe von Daten die den [[HomeMatic#Rssi|Empfangspegel]] des Device bei IOs, Peers und Repeatern darstellt. | ||
*Kanäle | *Kanäle | ||
** device: Das übergeordnete Device | ** device: Das übergeordnete Device | ||
** chanNo: Die Kanalnummer | ** chanNo: Die Kanalnummer | ||
** peerList: Ist die Entity mit einem anderen gepeert | ** peerList: Ist die Entity mit einem anderen gepeert, so 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==== | ||
Readings für HM | Readings für HM Entities 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. <br> | 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. <br> | ||
So ist nach einem "set Licht on" der Zustand des Licht erst | So ist nach einem "set Licht on" der Zustand des Licht erst einmal "set_on". Mit der Antwort des Device wird es dann auf "on" gesetzt. <br> | ||
Register machen eine Ausnahme: | Register machen eine Ausnahme: | ||
=====Register===== | =====Register===== | ||
Register sind Konfigurationsparameter, die '''im Device flash''' gespeichert werden. Daten, die Registern | Register sind Konfigurationsparameter, die '''im Device flash''' gespeichert werden. Daten, die Registern zugeordnet sind, beginnen mit "R-". Sollte das Register einem peer zugeordnet sein kommt dieser danach. Der Namen ist also '''R-<peer>-<registerName>'''. | ||
'''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 | 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 eine gewisse Vorsicht im Umgang damit walten lassen. Register können mit '''regSet''' gesetzt werden. Ob die gelesenen Register komplett sind prüft [[HMInfo#Integritätsprüfungen|configCheck]]. Da einige Entities viele Register haben kann man mit dem Attribut '''expert''' die Sichtbarkeit steuern (siehe auch [[HMInfo#Infos|Register]]). | ||
Da einige Entities viele Register haben kann man mit dem Attribut '''expert''' die Sichtbarkeit steuern | |||
siehe auch | Von einigen Devices sind Register schwer zu lesen, z.B. config devices. Man kann die Register-Readings [[HMInfo#archConfig|archivieren]] und beim reboot wieder [[HMInfo#archConfig|laden]]. | ||
Von einigen Devices sind Register schwer zu lesen, z.B. config devices. Man kann die Register-Readings | |||
==== Attribute==== | ==== Attribute==== | ||
Attribute sind i. | 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.<br> | ||
Hier werden nur '''HM spezifische Attribute''' besprochen.<br> | Hier werden nur '''HM spezifische Attribute''' besprochen.<br> | ||
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'''. | 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'''. | ||
Zeile 104: | Zeile 178: | ||
Attribute für HM Entities am Device, die der User steuern kann | Attribute für HM Entities am Device, die der User steuern kann | ||
* msgRepeat: kann man im Device einstellen. Es legt fest | * msgRepeat: kann man im Device einstellen. Es legt fest, wie 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. | * 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 | Empfohlene Attribute außerhalb von HM | ||
Zeile 112: | Zeile 186: | ||
===Kommandos=== | ===Kommandos=== | ||
====Allgemein==== | ====Allgemein==== | ||
* get <name> cmdList | *<code>get <name> cmdList</code> | ||
* clear [readings|register|rssi|msgEvents] | ::Zeigt alle Kommandos mit Parametern für diese Entity an | ||
*<code>clear [readings|register|rssi|msgEvents]</code> | |||
::Löschen von Readings oder Zählern | |||
====Register kommandos==== | ====Register kommandos==== | ||
* set <name> getConfig | *<code>set <name> getConfig</code> | ||
* set <name> regSet [prep|exec] <regName> <value> ... [<peerChannel>] | ::Liest alle Peers und Register. Auf ein Device angewendet werden auch '''alle''' Channels ausgelesen | ||
* set <name> regbulk ... | *<code>set <name> regSet [prep|exec] <regName> <value> ... [<peerChannel>]</code> | ||
::Schreiben eines Registerwerts. Das Kommando landet im Kommandstack | |||
*<code>set <name> regbulk ...</code> | |||
::Kommando zum Setzen von Rohdaten und ganzen Registerlisten. Außer zum Rekonfigurieren eines ganzen Device eher nicht für den User zu gebrauchen | |||
*<code>set <name> sign [on|off]</code> | |||
::Setzt das Register um AES einzuschalten. Man sollte sich über AES '''vorher''' einlesen!! | |||
*<code>get <name> regList</code> | |||
::Zeigt alle Register, die diese Entity '''unterstützt''' - inkl. Beschreibung und Wertebereich. Als Anfänger sollte man einmal hinsehen! | |||
*<code>get <name> reg all</code> | |||
::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.<br> | Um FHEM zu erlauben, Nachrichten an das Device zu richten muss FHEM gepairt werden.<br> | ||
Das Senden der Nachrichten macht IMMER das Device - ein Kanal selbst kann nicht wirklich senden. | Das Senden der Nachrichten macht IMMER das Device - ein Kanal selbst kann nicht wirklich senden. | ||
====Protokoll==== | ====Protokoll==== | ||
Da für das Senden das Device verantwortlich ist sind hier die entsprechenden Informationen zu finden. Zu Beachten sind die | 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 | * protState: Der Zustand der Protokollmaschine | ||
** CMDs_done: alle Nachrichten übertragen, | ** 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_done_Error:xx : es hat xx Fehler bei der letzten Übertragung gegeben. | ||
** CMDs_pending: Nachrichten warten auf das Senden | ** CMDs_pending: Nachrichten warten auf das Senden | ||
Zeile 153: | Zeile 237: | ||
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. <br> | 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. <br> | ||
Eine Übersicht kann man mit HMInfo | Eine Übersicht kann man mit HMInfo [[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.<br> | 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.<br> | ||
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.<br> | 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.<br> | ||
Die Zähler können mit '''set <device> clear rssi''' rückgesetzt werden.<br> | Die Zähler können mit '''set <device> clear rssi''' rückgesetzt werden.<br> | ||
Eine Übersicht | Eine Übersicht erhält man mit HMInfo [[HMInfo#RSSI|Rssi]]. Das Löschen der Zähler aller HM devices ist von HMInfo aus möglich.<br> | ||
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 === | ||
: ''→ Siehe auch: [[Pairing (HomeMatic)]]'' | |||
: ''→ Anleitung: [[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. | |||
Um | === Peeren === | ||
: ''→ Siehe auch: [[Peering (HomeMatic)]]'' | |||
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 == | == HMInfo == | ||
: ''→ Siehe auch: [[HMInfo]]'' | |||
== Besondere | Bei der Betreuung einer HomeMatic-Installation ist das Modul [[HMInfo]] sehr hilfreich. Es stellt eine Übersicht der HomeMatic-Komponenten zur Verfügung, kann die Konfiguration prüfen und Alarmierungen gesammelt auswerten. | ||
== Besondere Entities == | |||
=== Virtuelle Entities === | === Virtuelle Entities === | ||
Zeile 183: | Zeile 278: | ||
jetzt hat man ein virtuelles Device mit 10 Kanälen angelegt. | 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.<br> | Die die gültigen Kommandos kann man wie immer mit '''get <entity> cmdList''' erfahren.<br> | ||
Auch einem Virtuellen Device sollte man das '''Attribut IODev | Auch einem Virtuellen Device sollte man das '''Attribut IODev''' bzw. '''IOgrp''' setzen. | ||
=== IO Entities === | === 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=== | === 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 | Einige Devices der HM-Geräteserie senden periodisch Nachrichten. Manche alle 3 Minuten, andere alle 3 Tage. Wenn so eine Zeit für ein Device spezifiziert ist, wird diese automatisch vom ActionDetector überwacht.<br> | ||
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. | 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" | Die Kontrollinstanz ist ein Pseudo-Gerät "ActionDetector" mit der HMId "000000" | ||
Zeile 229: | Zeile 335: | ||
* [[CUL]] (also gleichzeitig)? | * [[CUL]] (also gleichzeitig)? | ||
* [[Slider für HM-Rolladensteuerung anzeigen]] | * [[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, | * 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 == | == Probleme == | ||
=== Messages Sniffen === | === Messages Sniffen === | ||
Um Probleme besser nachvollziehen zu können, kann man | Um Probleme besser nachvollziehen zu können, kann man [[HomeMatic Nachrichten sniffen]] | ||
=== Daten können empfangen werden, Befehle werden nicht übertragen === | === Daten können empfangen werden, Befehle werden nicht übertragen === | ||
Das kann mehrere Ursachen haben: | 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 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 | * 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 | === Notifys und anderes funktionieren nach einem FHEM-Neustart nicht mehr oder nicht mehr zeitnah === | ||
Obwohl HomeMatic wegen der | Obwohl HomeMatic wegen der höheren 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 | 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 | Je nach Anzahl der Geräte kann es dazu kommen, 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 | 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 | Ab diesem Moment werden eben auch keine anderen Befehle mehr an weitere HM-Geräte geschickt, da das Funkkontingent 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. | Alternativ können so viele HM-Geräte wie möglich auf ''autoReadReg 0_off'' gesetzt werden. | ||
Siehe auch: [[1% Regel]] | Siehe auch: [[1% Regel]] | ||
=== Spannungsversorgung === | === Spannungsversorgung === | ||
Die Batterielebensdauer der | Die Batterielebensdauer der HomeMatic 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. | 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. | ||
Zeile 272: | Zeile 376: | ||
[[Kategorie:HomeMatic Components]] | [[Kategorie:HomeMatic Components]] | ||
[[Kategorie:Glossary]] | [[Kategorie:Glossary]] | ||
[[Kategorie:868MHz]] |
Aktuelle Version vom 2. Dezember 2021, 16:36 Uhr
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.
Das ähnliche klingende HomeMatic IP ist eine neue Generation von Geräten und Funkprotokoll (HM-IP: IP over BidCos). Die dort angebotenen Geräte lassen sich über den Einsatz einer (physischen) CCU2 (bzw. CCU3) oder anderen Lösungen wie YAHM, piVCCU, raspberrymatic oder DebMatic usw. und den HomeMatic-Modulen integrieren.
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.
![Info blue.png](/w/images/thumb/7/7e/Info_blue.png/40px-Info_blue.png)
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 CCU3) und Windows-Software zur Steuerung und Auswertung der HM-Komponenten angeboten. Diese Zentrale kann wie eingangs dargestellt über das Modul HMCCU in FHEM eingebunden werden und dann neben HM-IP- und HM-wired-Komponenten auch solche mit BidCoS verwalten.
FHEM als Zentrale
Zur Kommunikation mit HomeMatic benötigt FHEM eine Schnittstelle, die im 868,3-MHz-Band funken kann. Infrage kommen:
![X mark.svg](/w/images/thumb/a/a2/X_mark.svg/20px-X_mark.svg.png)
- HM-MOD-RPI-PCB HomeMatic Funkmodul für Raspberry Pi (RPI, WLAN, LAN, USB)
- HM-LGW-O-TW-W-EU Funk-LAN Gateway (LAN)
- HM-CFG-LAN (oft auch "HMLAN" genannt; LAN; nicht mehr lieferbar)
- HM-CFG-USB (USB, nicht mehr lieferbar)
- CUL und andere Geräte mit CC110x-Transceiver, CUNO, SelbstbauCUL, nanoCUL, umgeflashter MAX-Cube, MapleCUx, CUNX usw. (USB, GPIO, LAN , WLAN)
Erfahrungsgemäß ist der Einsatz originaler HomeMatic IOs empfehlenswert, da es bei allen CUL-Derivaten immer wieder zu Schwierigkeiten kommen kann, vor allem in größeren Installationen und bei der Kommunikation mit komplexeren Geräten. Wer dennoch einen CUL für HomeMatic verwenden will, sollte eine speziell für den Betrieb mit HomeMatic optimierte CUL-firmware (tsculfw - TimeStamp Firmware) verwenden. Bei HomeMatic ist das Timing der Telegramme entscheidend sonst kann es zu "MISSING_ACK" bzw. "RESPONSE TIMEOUT:RegisterRead" u.ä. Meldungen kommen! Zusätzlich sind unbedingt die Hinweise im Artikel AES Encryption zu beachten!
Für HomeMatic Wired benötigt man eine RS485-Schnittstelle. Das "offizielle" Gateway HMW-LGW-O-DR-GS-EU (LAN) funktioniert prinzipiell mit FHEM, der Einsatz wird aber nicht empfohlen. Hier gibt es Alternativen dazu: Serial/Netzwerk-RS485-Adapter.
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 /usr/local/etc/config/rfd/BidCoS-RF.dev
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 address
-Attributs. Die dort angegebene hexadezimale Zahl (hier 0xABCDEF
) 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 /etc/config_templates/crypttool.cfg
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"? |
Protokoll
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.
Firmware
Angaben zur Aktualisierung der Firmware der HomeMatic Geräte finden sich zum Beispiel in dem Blog von Otto und im Forum.
Betrieb mit FHEM
Die Kenntnis des Dokumentes 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. Hier ist eine Liste der Schnittstellen.
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
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 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 Anderen 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
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: phyLevel = (((0% o Ch1) o Ch2) o Ch3) [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 (Vorergebnis o Kanal)]
Wert | Bedeutung | 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: 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 Entities empfangenen Nachrichten generiert. Man kann mit notify Trigger auf diese 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 im allgemeinen Teil nachgelesen werden. Spezifische Variablen sind:
- Device
- channel_xx: Liste der Kanäle, die dem Device zugeordnet sind.
- prot... : Gruppe von Daten zum Zustand des Protokolls, also der Kommunikation mit dem Device.
- rssi...: Gruppe von Daten die den Empfangspegel des Device bei IOs, Peers und Repeatern darstellt.
- Kanäle
- device: Das übergeordnete Device
- chanNo: Die Kanalnummer
- peerList: Ist die Entity mit einem anderen gepeert, so 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 Entities 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 einmal "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 zugeordnet 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 eine gewisse Vorsicht im Umgang damit walten lassen. Register können mit regSet gesetzt werden. Ob die gelesenen Register komplett sind prüft configCheck. Da einige Entities viele Register haben kann man mit dem Attribut expert die Sichtbarkeit steuern (siehe auch Register).
Von einigen Devices sind Register schwer zu lesen, z.B. config devices. Man kann die Register-Readings archivieren und beim reboot wieder laden.
Attribute
Attribute sind i.A. Parameter, die das Verhalten der Entity steuern. Sie werden mit save in fhem.cfg oder einem seiner subfiles gespeichert. Nach einer Änderung sollte der User ein "save" machen, sonst sind diese nach einem Reboot verloren.
Hier werden nur HM spezifische Attribute besprochen.
Attribute, die das System automatisch anlegt. Sollten diese nicht mehr stimmen kann der User anlernen am Device drücken und sie werden wieder hergestellt. Der User sollte sie nicht ändern.
- model
- subType
- peerIDs: HMIds der peers. Wird gelegentlich verschoben!
- serialNr: auslaufend - durch Reading D-serianNr ersetzt
- firmware: auslaufend - durch Reading D-firmware ersetzt
Attribute für HM Entities, die der User steuern kann
- webCmd: FHEM setzt ggf. einen Default, der User kann dies anpassen
- expert: schaltet mehr oder weniger Readings sichtbar - dient der Übersichtlichkeit des Web-Interface.
- autoReadReg: steuert das automatische Lesen der Konfiguration - ggf. zeitverzögert um Resourcen zu schonen. Es wird Level 5 empfohlen
Attribute für HM Entities am Device, die der User steuern kann
- msgRepeat: kann man im Device einstellen. Es legt fest, wie 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 auch alle Channels ausgelesen
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. Außer zum Rekonfigurieren 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 - inkl. Beschreibung und Wertebereich. Als Anfänger sollte man einmal hinsehen!
get <name> reg all
- Zeigt alle Register, die diese Entity hat und den aktuellen Wert
Kommunikation
Die Kommunikation zwischen Device und der Zentrale folgt einem Protokoll. Für die meisten Nachrichten erwartet der Sender eine Empfangsbestätigung. FHEM beachtet das Protokoll und implementiert es entsprechend der Fähigkeiten des IO device.
Grundsätzlich kann jedes Device an jedes andere Nachrichten senden. Damit dies auch einen erfolg hat, müssen die Kanäle gepeert werden.
Um FHEM zu erlauben, Nachrichten an das Device zu richten muss FHEM gepairt werden.
Das Senden der Nachrichten macht IMMER das Device - ein Kanal selbst kann nicht wirklich senden.
Protokoll
Da für das Senden das Device verantwortlich ist sind hier die entsprechenden Informationen zu finden. Zu Beachten sind die Übertragungsmodi, die ein Device unterstützt. Die Internals "prot..." enthalten alle notwendigen Daten.
- protState: Der Zustand der Protokollmaschine
- CMDs_done: alle Nachrichten übertragen, 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 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 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
- → Siehe auch: Pairing (HomeMatic)
- → Anleitung: 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: Peering (HomeMatic)
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: HMInfo
Bei der Betreuung einer HomeMatic-Installation ist das Modul HMInfo sehr hilfreich. Es stellt eine Übersicht der HomeMatic-Komponenten zur Verfügung, kann die Konfiguration prüfen und Alarmierungen gesammelt auswerten.
Besondere Entities
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 bzw. IOgrp 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 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 ein 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
- 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
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öheren 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 es dazu kommen, 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 Funkkontingent 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 HomeMatic 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.