HMinfo 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!

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

Das Protokoll

Das Protokoll beruht in der Regel auf einem Handshake Verfahren. Nachrichten müssen von Empfänger quittiert 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, batteriebetrieben und unregelmäßig sendend, 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 typisch 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 (Heizungsthermostate) 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 eine eventuell anstehende Kommunikation wird durchgefü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 Kommunikationstyp arbeitet FHEM die Liste schnellstmöglich 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 (Protokoll) beginnend ermittelt.

• protState:Der gesamt-Zustand der Queue.
  • CMDs_done: Alle Kommandos übertragen, es sind bei der letzten Übertragung keine Fehler aufgetreten
  • CMDs_done_Errors: Alle Kommandos übertragen, es sind beim letzten Fehler aufgetreten
  • CMDs_pending: Es stehen Kommandos zur Übertragung an. Es wird auf die Möglichkeit der Übertragung gewartet. Bspw. auf das Aufwachen eine wakeup-Devices.
  • CMDs_processing...: Die Kommandos aus der Queue werden gerade abgearbeitet. Dies kann je nach Device und Menge auch etwas dauern.
• protLastRcv: Zeitpunkt der letzten empfangenen Nachricht dieses Device
• protSnd: Zählt die gesendeten Nachrichten und zeigt den letzten Sendezeitpunkt an.
• protCmdPend: Anzahl der in der Kommando-Queue wartenden Nachrichten
• protResnd: Anzahl der (erfolgreich) wiederholten Nachrichten
• protCmdDel: Anzahl der auf Grund von Übertragungsproblemen gelöschten Nachrichten
• protResndFail: Anzahl der Wiederholungen welche nicht erfolgreich abgeschlossen werden konnten
• protNack: Anzahl der negativen Acknowledges, welche vom Devices empfangen wurden.
• protIOerr: Anzahl der Fehler, IO bedingt.

HMinfo Support zu Protokoll Ereignissen

Da nun einiges kontinuierlich passiert und die Anzahl der Devices typisch steigt bedarf es eine Übersicht, den Zustand des Systems zu überwachen:

 get hm protoEvents

zeigt eine Tabelle aller Devices, deren Zustand der Kommando-Queue und eine Statistik der Übertragungen. Nach dem '#' sollten keine Zähler stehen. Die dortigen bedeuten, dass einige Kommandos gelöscht wurden. Im Nachspann stehen Informationen über weitere Queues con CUL_HM. So bspw. devices bei welchen FHEM die Register noch lesen will (autoReadReg) falls dies über ein entsprechendes Attribut eingestellt wurde.
Will man aufräumen kann man

 set hm clearG msgEvents # löscht alle Zähler und leert die Kommando-Queue aller Devices
 set hm clearG msgErrors # löscht alle Zähler der Devices welche Fehler anzeigen.

Ein Löschen ist gelegentlich sinnvoll, da Fehler kontinuierlich akkumuliert werden. Wenn man die Fehler nun erfasst hat kann man diese zurücksetzen um neu auftretende besser zu erkennen.

Kommunikation Timing

Die Kommunikation setzt ein straffes Timing der Nachrichtenübermittlung voraus. Eine Nachricht muss in einem Zeitfenster von 100ms-250ms nach senden beantwortet werden. Aufgrund der Natur von FHEM mit IOs welche über unzureichende Betriebssysteme angeschlossen werden kann das Timing nur schwer gewährleistet werden. Verzögerungen durch LAN oder USB müssen berechnet werden

• HM-IOs: IO Devices von eq3 stellen eine Zeitstempel bereit welcher zur Kalkulation der Verzögerung genutzt werden kann. Das funktioniert in der Regel problemlos
• CUL: Da die CUL keinen Zeitstempel zu Verfügung stellt ist sie für HM Kommunikation nicht zu brauchen. Siehe TSCUL
• TSCUL: Durch einen FW Update kann eine CUL einen Zeitstempel generieren und schicken welcher diese dann

einem HM-IO gleichwertig macht. Das Timing kann aber auch durch Verzögerungen auf den Rechner, innerhalb oder außerhalb von FHEM gestört werden, wenn langsame oder hochpriore Tasks den Ablauf stören. apptime kann genutzt werden um Verzögerungen im System aufzudecken.

pairen: ist eine besondere Herausforderung. Hier müssen ggf. erst entities in FHEM angelegt werden, bevor geantwortet werden kann. Es ist nicht sinnvoll nach einem ersten pairing Versuch alle Entites aus FHEM wieder zu löschen. Sollte das pairen nicht funktioniert haben kann man die Kommando Queue leeren (set hm clearG msgEvents) und dann einen neuen Versuch starten.