HMinfo Protokoll

Aus FHEMWiki
Version vom 4. Januar 2018, 19:56 Uhr von Martinp876 (Diskussion | Beiträge) (Die Seite wurde neu angelegt: „{{Infobox Modul |ModPurpose=HM Protokollereignisse kontrollieren |ModType=h |ModCmdRef=HMinfo |ModForumArea=HomeMatic |ModTechName=98_HMinfo.pm |ModOwner=marti…“)
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
Zur Navigation springen Zur Suche springen
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 Konrolle haben will. HMInfo ist ein Modul welches Methoden zu Verfügung stellt, damit umzugehen. Behandelt wird hier ausschliesslich die Homematic Funkprotokoll.

Das Protokoll

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