Homematic Geräte mit Funkprotokoll haben Eigenheiten welche man verstehen und überwachen muss, so man sein System unter Konrolle haben will. HMInfo ist ein Modul welches Methoden zu Verfügung stellt, damit umzugehen. Behandelt wird hier ausschliesslich die Homematic Funkprotokoll.

Das Protokoll

HMinfo
Zweck / Funktion
	HM Protokollereignisse kontrollieren
Allgemein
Typ	Hilfsmodul
Details
Dokumentation	EN / DE
Support (Forum)	HomeMatic
Modulname	98_HMinfo.pm
Ersteller	martinp876 (martinp876 / Wiki)
	Wichtig: sofern vorhanden, gilt im Zweifel immer die (englische) Beschreibung in der commandref!

Das Protokoll beruht in der Regel auf einem Handshake Verfahren. Nachrichten müssen von Empfänger quittert werden. Um mit einem Device kommunizieren zu können muss es allerdings empfangsbereit sein. Man muss die Devicetypen daher unterscheiden

Kommunikationstypen

Homematic bietet unterschiedliche Devices, teils batteriebetrieben. Die Energieversorgung ist der wesentliche Grund unterschiedliche Typen zu etablieren. Sollte ein batteriebetriebenes Device kontinuierlich auf Empfang sein senkt das die Lebensdauer der Batterie erheblich. Somit unterscheidet man

Config:Dieser Modus wird von allen Devices unterstützt. Hierbei wird das Device durch drücken einer Taste (typisch einer separaten, versteckten Taste) in den Mode versetzt. Die Taste wird gelegentlich auch Anlerntaste genannt. Das Device sendet hierbei eine Konfigmessage und bleibt einige Sekunden auf Empfang. Ein anderes Device hat nun die Chance mit dem Device zu kommunizieren.

Dieser Mode wird gerne zum Pairen genutzt.

Die FHEM Zentrale erkennt die Message und startet die Abarbeitung eventuell anhängiger Messages

normal:Typischerweise wird dieser Mode von allen Devices mit permanenter Stromversorgung unterstützt. Das Device ist kontinuierlich auf Empfang. Config wird von diesen Devices typisch nur zum pairen genutzt
wakeup:Batteriebetriebene Devices welche regelmäßig senden stellen gerne diesen Modus bereit. Einige Devices welche regelmäßig senden (Thermostate oder Fühler) bleiben nach senden der zyklischen Nachricht kurz auf Empfang. FHEM erkennt dies und sendet gegebenenfalls anhängige Nachrichten und Abfragen.
lazyConf:Einige modernere Devices, betteriebetrieben und unregemäßig sendent, stellen einen trägen Config mode bereit. Hierbei bleibt das Device auf Empfang, wenn dies einen Trigger gesendet hat.

Beispiel ist eine Fernbedienung welche nach drücken eines Buttons den Trigger sendet und dann kurz auf weitere Nachrichten wartet. Auch einige Bewegungsmelder unterstützen dies. Hier muss man also einen Trigger auslösen (Bewegung). Das Device reagiert nicht nach dem Senden der zyklischen Nachrichten.

Erfahrungsgemäß funktioniert dies allerdings nur, wenn das Device den Trigger an die Zentrale sendet. Es ist also ratsam, alle Kanäle (jeden einzeln) mit einem Kanal der Zentrale zu peeren. Es biete sich an, einen virtuellen Button der Zentrale zu nutzen, welche man mit allen Kanälen aller LazyConfig Devices peert.

burst:Burst ist ein Verfahren, schlafende Devices aufzuwecken. Einige sind im Dämmerschlaf und können durch einen Burst aufgeweckt werden. Burst ist ein Kommandosequenz welche der Initiator senden muss. Diese ist aufwändig, verbraucht einiges an Funkperformance (1% Regel) und weckt alle Burst Devices gleichzeitig auf. Als Daumenregel kann ein Device in einer Stunde 100 Bursts senden bevor die 1% Regel zuschlägt.

SD (Rauchdetektoren) verwenden tyisch burst. Sie müssen empfangsbereit sein, laufen mit Batterie und müssen demnach Sparsam sein.

burstCond:ist eine Variante des Burst. Der Burstmode kann bei ihnen freigeschaltet werden. Beispielsweise RT (Heizungsthermosrate) nutzen diesen Mode. Ein RT sendet regelmäßig seinen Status - und hierbei kann man über wakeup mit dem Device alle 3min kommunizieren. Nun muss ein RT aber auf Fensterkontakte reagieren können. Diese senden Asynchron. Man muss also sicherstellen, dass der Fensterkontakt einen Burst sendet und der RT auf Burst reagiert.

Conditional Burst wird in einem Register freigeschaltet.

Devices mit CondBurst stellen ein Kommando BurstXmit bereit. Hierbei wird von FHEM ein Burst gesendet und ene eventuell anstehende Kommunikation wird durhgeführt.

BurstXmit sollte nur bei Bedarf, beim Configurieren, genutzt werden. Typisch sollte man auf das normale erwachen des Devices warten um die Kommunikation nicht zu belasten.

In einem Sender (Fensterkontakt) Muss "peerNeedsBurst" einegeschaltet werden, wenn dieses mit einem Burst-Device gepeert ist.

HMinfo Kommandos zum Devicetyp

Um nun festzustellen, welchen Devicetyp man vorliegen hat kann man über das Attribut model seines Device in HMinfo klären

 get hm models
 get hm models -f <regexp>
 get hm models -f SD

FHEM Kommunikation

FHEM kennt alle Kommunikationstypen und behandelt diese entsprechend. Zu beachten ist, dass ein HM Gerät aus mehreren Entities besteht: Ein Device und ein oder mehrere Kanäle. Man kann mit den Kanälen nicht direkt kommunizieren. Die Kommunikation geht immer über das Device. So ist es in FHEM auch organisiert. Löst man ein Kommando für einen Kanal aus wir dies in die Abarbeitungsliste der Device gestellt. Je nach Komminukationstyp arbeitet FHEM die Liste schnellstmöglch ab.
Hierbei ist zu beachten, dass an die Devices über ein oder mehrere IOs gesendet wird. Auch hier wird wieder der Reihe nach vorgegangen, ein Device nach dem anderen.
Wir haben also gelernt, dass Kommandos, welche FHEM senden will, in den Kommando-Queues der Devices abgelegt werden. Will nun sehen, ob schon alles erledigt ist, oder ob Fehler aufgetreten sind, muss man den Status der Kommando-queue lesen. Dieser wird in den Internals welche mit prot (Protokol) beginnend ermittelt.

protState:Der gesamt-Zustand der Queue.
- CMDs_done