HMinfo: Unterschied zwischen den Versionen

Aus FHEMWiki
K (HM durch hm ersetzte (bei allen FHEM Befehlen))
K (Ph1959de verschob die Seite HMInfo nach HMinfo: Seitentitel auf Modulnamen geändert)
 
(48 dazwischenliegende Versionen von 13 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
'''HMInfo''' ist ein Modul, das alle [[HomeMatic]] repräsentiert. Es bietet Funktionen zur Übersicht, Kontrolle, Archivierung  und, begrenzt, zur Programmierung der Homematic Komponenten. Somit soll es eine Hilfestellung bei Konfiguration und Fehlerbehandlung geben.  
{{Infobox Modul
|ModPurpose=Übersicht über alle HomeMatic Geräte
|ModType=h
|ModCmdRef=HMinfo
|ModForumArea=HomeMatic
|ModTechName=98_HMinfo.pm
|ModOwner=martinp876 ({{Link2FU|251|martinp876}} / [[Benutzer Diskussion:Martinp876|Wiki]])
}}
[[HMInfo]] ist ein Modul, das einen Überblick über alle definierten [[HomeMatic]] Geräte gibt. Es bietet Funktionen zur Übersicht, Kontrolle, Archivierung  und - begrenzt - zur Programmierung der HomeMatic Komponenten. Somit soll es eine Hilfestellung bei Konfiguration und Fehlerbehandlung geben.  
   
   
== Definition ==  
== Definition ==  
HMInfo wird erstellt / angelegt mit dem Befehl
HMInfo wird erstellt / angelegt mit dem Befehl
:<code>define hm HMinfo</code>
:<code>define hm HMinfo</code>
Danach können alle Funktionen aufgelistet werden mit
Danach können alle Funktionen aufgelistet werden mit
:<code>get hm help</code>
:<code>get hm help</code>


== Integritätsprüfungen ==
== Integritätsprüfungen ==
Zu berücksichtigen bei allen Funktionen von HMInfo ist die Tatsache, dass die Prüfung jeweils auf den innerhalb von FHEM vorliegenden Informationen passiert. Erste Korrekturmaßnahme ist daher immer von den betroffenen Devices die Informationen mit einem set <Device> getConfig zu aktualisieren. Dabei ist darüber hinaus zu berücksichtigen, dass entsprechend der konfigurierten Kommunikationsmethode (z.B. config) einige Devices erst nach einer gewissen Zeit oder nach Betätigen der Anlerntaste die Informationen als Antwort zurückliefern.
Befehle, um die Gültigkeit von verschiedenen HomeMatic Eigenschaften zu überprüfen:
Befehle, um die Gültigkeit von verschiedenen HomeMatic Eigenschaften zu überprüfen:
{| class="wikitable"
 
! Erläuterungen !! Definition
=== peerCheck ===
|-
Mit dem Befehl
| Überprüfen, ob alle peerings auch beidseitig sind:
:<code>get hm peerCheck</code>
| <code>set hm peerCheck</code>
wird der Zustand der Peerings überprüft, d.h., ob alle [[Peering (HomeMatic)|Peerings]] auch beidseitig sind. Mögliche Meldungen, die eine Überarbeitung und/oder Korrektur von Definitionen erforderlich machen können:
|-
;peer not verified. Check that peer is set on both sides
| Überprüfen, ob alle register korrekt gelesen wurden:
:ausgegebener Wert (z.B.): actorChan p:switchChan
| <code>set hm regCheck</code>
:erforderliche Korrekturmaßnahme: Erneutes setzen des Links und Sicherstellen, dass das Kommando das entsprechende Device auch erreicht hat (s.o., ggf. bei Bedarf die Anlerntaste betätigen).
|-
 
| Kombination von peerCheck und regCheck
=== regCheck ===
| <code>set hm configCheck</code>
Mit dem Befehl
|}
:<code>get hm regCheck</code>
wird überprüft, ob alle Register korrekt gelesen wurden. Mögliche Meldungen:
;missing register list
:ausgegebener Wert (z.B.): <code>dev01Ch01:  RegL_01: </code>
:erforderliche Korrekturmaßnahme: <code>set dev01Ch01 getConfig</code>
:oder <code>device01Ch01: .RegL_03:sensor01Ch01,.RegL_03:sensor01Ch02</code>
:erforderliche Korrekturmaßnahme: Deutet darauf hin, dass nicht alle Informationen aus einem Device gelesen wurden. Ein set <Device> getConfig sollte alle Register auslesen. Sicherstellen, dass das Kommando zum Auslesen das entsprechende Device auch erreicht und eine Antwort geliefert hat (s.o., ggf. bei Bedarf die Anlerntaste betätigen).
;Register changes pending
:ausgegebener Wert (z.B.): <code>sensor01Ch01</code>
:erforderliche Korrekturmaßnahme: Ein set <Device> getConfig sollte alle Register auslesen. Sicherstellen, dass das Kommando das entsprechende Device auch erreicht und eine Antwort geliefert hat (s.o., ggf. bei Bedarf die Anlerntaste betätigen).
 
=== configCheck ===
Mit dem Befehl
:<code>get hm configCheck</code> werden die Befehle '''peerCheck''' und '''regCheck''' ausgeführt. Zusätzlich können noch Ergebnisse auftauchen wie
;PairedTo mismatch to IODev
:ausgegebener Wert (z.B.): <code>sensor01Ch01 paired:0x000000 IO attr: xxxxxx.</code>
:erforderliche Korrekturmaßnahme: IODevice in den hmPairForSec Modus versetzen, Pairing-Modus am Device aktivieren und dadurch das pairing wiederholen. Ein Anschließendes set <Device> getConfig kann nicht schaden. Sicherstellen, dass das Kommando zum Auslesen das entsprechende Device auch erreicht und eine Antwort geliefert hat (s.o., ggf. bei Bedarf die Anlerntaste betätigen).


== Anzeigen zur Übertragungssituation ==
== Anzeigen zur Übertragungssituation ==
===RSSI ===
===RSSI ===
  get hm rssi [<filter>]
;<code>get hm rssi [<filter>]</code>
Erzeugt eine Tabelle aller RSSI Werte.
:Erzeugt eine Tabelle aller RSSI Werte.
  set hm clear [<filter>] rssi
;<code>set hm clear [<filter>] rssi</code>
setzt die RSSI Werte aller devices gemäß filter zurück. Eine neue Messung kann beginnen
:setzt die RSSI Werte aller devices gemäß filter zurück. Eine neue Messung kann beginnen


===protoEvents ===
===protoEvents ===
  getHM protoEvents [<filter>][short|long]
;<code>get hm protoEvents [<filter>][short|long] </code>
Es wird eine Tabelle mit allen wichtigen Ereignissen zur Datenübertragung erzeugt. Dies beinhaltet Wiederholungen sowie Übertragungsfehler.  
Siehe [[HMinfo Protokoll]]
short ist eine Fassung ohne Zeitstempel und lässt sich besser am Bildschirm darstellen.
:Es wird eine Tabelle mit allen wichtigen Ereignissen zur Datenübertragung erzeugt. Dies beinhaltet Wiederholungen sowie Übertragungsfehler.  
Ausserdem kann man sehen, welche Abfragen noch in der queue sind, z.B. durch autoReadReg erzeugt.  
<code>short</code> ist eine Fassung ohne Zeitstempel und lässt sich besser am Bildschirm darstellen.
Ausserdem kann man sehen, welche Abfragen noch in der Queue sind, z.B. durch <code>autoReadReg</code> erzeugt.  
Die Zustände aller für HM zuständigen IOs sind beinhaltet.  
Die Zustände aller für HM zuständigen IOs sind beinhaltet.  
Alles in allen ist hier ein kompletter Überblick zur Kommunikation zu sehen. Insbesondere bei
Alles in allem ist hier ein kompletter Überblick zur Kommunikation zu sehen. Der Befehl
  set hm clear [<filter>] Protocol
set hm clear [<filter>] Protocol
setzt die Protokol Einträge aller gemäß filter zurück. Kann gut vor einer Konfigurations-aktion genutzt werden um hinterher zu kontrollieren, ob Fehler aufgetreten sind.  
setzt die Protokoleinträge aller HomeMatic-Geräte gemäß Filter zurück. Das kann gut vor einer Konfigurationsaktion genutzt werden um zu kontrollieren, ob Fehler aufgetreten sind.<br>
Für tieferes Verständnis siehe [[HMinfo Protokoll]]


===msgStat===
===msgStat===
  set hm msgStat
;<code>set hm msgStat </code>
Statistic der Übertragenen Messages insgesamt. Es gibt eine Tabelle über die letzten 24h und eine über die letzte Woche.  
:Statistic der Übertragenen Messages insgesamt. Es gibt eine Tabelle über die letzten 24h und eine über die letzte Woche.  


== Speichern von Konfigurationen==
== Speichern von Konfigurationen==
HMInfo speichert Konfigurationen der Geräte in Files. Mit dem Attribut configDir kann man eine directory festlegen, in die alles geschrieben wird.
HMInfo speichert Konfigurationen der Geräte in Files. Mit dem Attribut configDir kann man ein Verzeichnis festlegen, in das alles geschrieben wird.


=== saveConfig===
=== saveConfig===
Peers und Register werden in ein file geschrieben. Die Daten kann man ggf. wieder in ein gerät oder ein Austauschgerät schreiben. Die Speicherung erfolgt kumulativ, man kann alles in ein File schreiben.  
[[Peering (HomeMatic)|Peers]] und Register werden in eine Datei geschrieben. Die Daten kann man ggf. wieder in ein Gerät oder ein Austauschgerät schreiben. Die Speicherung erfolgt kumulativ, man kann alles in eine Datei schreiben.  
set hm saveConfig [<filter>] [<file>]  
:<code>set hm saveConfig [<filter>] [<file>] </code>


=== archConfig ===
=== archConfig ===
Arbeitet prinzipiell wie saveConfig. Es werden jedoch nur vollständige Registersätze gespeichert, was einen höheren Level an Sicherheit der Dateninhalte gewährt.   
Arbeitet prinzipiell wie saveConfig. Es werden jedoch nur vollständige Registersätze gespeichert, was einen höheren Level an Sicherheit der Dateninhalte gewährt.   
set hm archConfig [-a] [<file>]
:<code>set hm archConfig [-a] [<file>] </code>
Mit dem '''Attribut autoArchive''' kann man einstellen, dass automatisch nach erfolgreichen Lesen einer Device-Konfiguration diese archiviert wird.  
Mit dem '''Attribut autoArchive''' kann man einstellen, dass automatisch nach erfolgreichem Lesen einer Device-Konfiguration diese archiviert wird.  
Das Speichern erfolgt kumulativ. Ab einer Filegröße von 1MB wird gepurged, also alles bis auf den neusten Eintrag jeder Entity gelöscht.   
Das Speichern erfolgt kumulativ. Ab einer Dateigröße von 1MB wird gepurged, also alles bis auf den neusten Eintrag jeder Entity gelöscht.   


Um eine Konfiguration zu sichern, sollte eine Kopie des Archivs gemacht werden. Das Archiv wird bei Gelegenheit überschrieben.  
Um eine Konfiguration zu sichern, sollte eine Kopie des Archivs gemacht werden. Das Archiv wird bei Gelegenheit überschrieben.  


Template erstellen:
Template erstellen:
set hm saveConfig -f ^meinDevice$ <myTempalteFile>
:<code>set hm saveConfig -f ^meinDevice$ <myTemplateFile> </code>


=== loadConfig ===
=== loadConfig ===
  set hm loadConfig [<filter>] [<filename>]  
;<code>set hm loadConfig [<filter>] [<filename>] </code>
Liest die Registerwerte, welche für eine Entity in einem File gespeichert sind, zurück in die Readings. Sollten die Register schon in FHEM vorhanden sein, wird '''nicht''' überschrieben.  
:Liest die Registerwerte, die für eine Entity in einem File gespeichert sind, zurück in die Readings. Sollten die Register schon in FHEM vorhanden sein, wird '''nicht''' überschrieben.  
Sinn macht dies beispielsweise für remotes, welche nicht automatisch gelesen werden sollen. Man kann somit nach einem system-reboot die Register "rekonstruieren" und wieder darstellen.  
Sinn macht dies beispielsweise für remotes, die nicht automatisch gelesen werden sollen. Man kann somit nach einem system-reboot die Register "rekonstruieren" und wieder darstellen.  
Es liegt im ermessen des User, eine bekannt aktuelle Version der Register einzulesen.  
Es liegt im ermessen des User, eine bekannt aktuelle Version der Register einzulesen.  
=== purgeConfig===
=== purgeConfig===
  set hm purgeConfig [<filename>]  
;<code>set hm purgeConfig [<filename>] </code>
Löscht alle älteren Datensätze in einem File.  
:Löscht alle älteren Datensätze in einem File.


== Konfigurationen bearbeiten ==
== Konfigurationen bearbeiten ==
=== Templates ===
=== Templates ===
HMInfo erlaubt das Erstellen und Nutzen von Tempaltes. Das sind Schablonen, die das Setzen von Registern abstrahieren und auf eine höhere Ebene heben. So kann man das Setzen der Konfiguration eines Aktors beispielsweise um mit einem Bewegungsmelder zusammen zu arbeiten in einem Kommando zusammenfassen.
HMInfo erlaubt das Erstellen und Nutzen von Templates. Das sind Schablonen, die das Setzen von Registern abstrahieren und auf eine höhere Ebene heben. So kann man das Setzen der Konfiguration eines Aktors beispielsweise um mit einem Bewegungsmelder zusammen zu arbeiten in einem Kommando zusammenfassen.
Faktisch setzt das Template also eine Gruppe von Registern auf ein mal.
Faktisch setzt das Template also eine Gruppe von Registern auf einmal.
 
====templateList ====
====templateList ====
Die vorhandenen templates kann man mit templateList sehen.  
Die vorhandenen templates kann man mit templateList sehen.  
Zeile 96: Zeile 125:
     SwJtOff          :dlyOn
     SwJtOff          :dlyOn
     SwJtOn          :on
     SwJtOn          :on
Ein templaetList auf ein einzelnes Template zeigt die Details, was das Template verändern wird.
Ein templateList auf ein einzelnes Template zeigt im Detail, was das Template verändern wird.


====templateSet ====
====templateSet ====
Um ein Template auf einen Aktor anzuwenden muss man neben den spezifischen Parametern angeben, für welchen Peer es gelten soll und ob es bei einem kurzen oder langen Tastendruck angewendet werden soll.  
Um ein Template auf einen Aktor anzuwenden,muss man den Bereich wählen, auf den er angewendet werden soll. Je nach template kann das die Gruppe der Register zu einem [[Peering (HomeMatic)|Peer]], zu short oder long eines Peer oder Register ohne peer sein.  
   set hm templateSet <entity> <templateName> <peer:[long|short]> [<param1> ...]  
   set hm templateSet <entity> <templateName> <peer:[long|short]> [<param1> ...]  
   set hm templateSet Licht1 autoOff FB1_Btn2:short 10
   set hm templateSet Licht1 autoOff FB1_Btn2:short 10
   set hm templateSet Licht1 SwOn FB1_Btn2:long
   set hm templateSet Licht1 SwOn FB1_Btn2:long
Licht1 soll, wenn ein kurzer Trigger von FB1_Btn2 kommt für 10 sec eingeschaltet werden, dann aus gehen (Treppenhausfunktion). Kommt aber ein langer Tastendruck wird das Licht dauerhaft eingeschaltet.  
  set hm templateSet Licht1 SwOff FB1_Btn2:short
  set hm templateSet Licht1 SwOnOff FB1_Btn2:both
  set hm templateSet LichtDev setHost 0
Licht1 soll, wenn ein kurzer Trigger von FB1_Btn2 kommt für 10 sec eingeschaltet werden, dann ausgehen (Treppenhausfunktion). Kommt aber ein langer Tastendruck wird das Licht dauerhaft eingeschaltet.  
   set hm templateSet Licht1 motionOnSw MD1:short 30 20
   set hm templateSet Licht1 motionOnSw MD1:short 30 20
Der Switch Aktor Licht1 soll mit einem Bewegungsmelder betrieben werden. Der Bewegungsmelder sendet keine 'langen' Trigger sondern nur kurze. Im Beispiel wird Licht1 für 30 Sekunden angeschaltet, wenn der Bewegungsmelder einen Trigger sendet UND es dunkler ist als "20" (Brightness level).  
Der Switch Aktor Licht1 soll mit einem Bewegungsmelder betrieben werden. Der Bewegungsmelder sendet keine 'langen' Trigger sondern nur kurze. Im Beispiel wird Licht1 für 30 Sekunden eingeschaltet, wenn der Bewegungsmelder einen Trigger sendet UND es dunkler ist als "20" (Brightness level).


====templateDef ====
====templateDef ====
Neben den vorbereiteten Templates kann der User eigene definieren oder von anderen Usern sich Templates geben lassen. Die Definition von Templates ist für erfahrene User gedacht, um gegensatz zur Nutzung eines Templates mit set - das ist für Anfänger gedacht.  
Neben den vorbereiteten Templates kann der User eigene definieren oder von anderen Usern sich Templates geben lassen. Die Definition von Templates ist für erfahrene User gedacht, im Gegensatz zur Nutzung eines Templates mit set - das ist für Anfänger gedacht. Man kann sein template manuell definieren oder ein bekanntes Device als Muster nutzen (fromMaster). Ein Template kann nur Gruppen von Registern setzen, nicht alle Register eines Device. Um die Gruppen anzusprechen muss man "peer" wie folgt setzen:
   set hm templateDef <templateName> <param1[:<param2>...] <description> <reg1>:<val1> [<reg2>:<val2>] ...  
  0            Register ohne peer
   set hm templateDef myTemplate anzeit:auszeit "licht schaltet ständig an und aus" OnTime:anzeit OffTime:auszeit OnDly:0
  <peer>:both  Register eines peers
mit diesem Template wird die Anzeit und die Auszeit eines Schalt-Aktors auf den vom User gewünschten Wert gesetzt. Die Verzögerung OnDly wird auf 0 gesetzt.
  <peer>:short Register eines peers nur Short
  <peer>:long  Register eines peers nur Long
setzen.
Man kann das template "dynamisch" gestalten, indem man einzelne Register beim templateSet übergibt.
Erst einmal statische Templates. Param ist hier "0"
 
   set hm templateDef <templateName> <param1[:<param2>...]> <description> <reg1>:<val1> [<reg2>:<val2>] ...  
 
  set hm templateDef t1 0 "TP1" OnTime:10 OffTime:20 OnDly:0
 
  set hm templateDef t1 fromMaster <entity> 0
  set hm templateDef t2 fromMaster <entity> <peer>:both
  set hm templateDef t3 fromMaster <entity> <peer>:short
  set hm templateDef t4 fromMaster <entity> <peer>:long
 
  set hm templateDef t4 fromMaster LichtWz remoteBtn1:long
 
Dynamische Templates haben eine Parameterliste (bis zu 9) <param1[:<param2>...]>. Diese werden als p0 bis p8 genutzt - der Name ist dabei egal, er dient dem User also Hilfe beim templateList
   set hm templateDef myTemplate anzeit:auszeit "licht schaltet ständig an und aus" OnTime:p0 OffTime:p1 OnDly:0
 
  set hm templateDef myAutoOff AnZeit "treppenhausschalter" ActionType:jmpToTarget OffTime:unused OnTime:p0 SwJtDlyOff:dlyOn SwJtDlyOn:no SwJtOff:dlyOn SwJtOn:on
 
Die "Anzeit" ist der erste Parameter, also p0. Der Wert, den man bei Set einträgt wird in OnTime geschrieben. OnTime:p0
 
Beim Definieren eines Templates wird die Registergültigkeit nicht geprüft. Das kommt beim Set.
 
Mit dem Parameter del kann ein (fehlerhaftes) Template (hier myTemplate) wieder gelöscht werden.  
 
  set hm templateDef myTemplate del


====templateChk ====
====templateChk ====
Man kann prüfen, ob ein Aktor/Peer gemäss einem tempalte programmiert ist.  
Template definitionen und zuweisungen (set) kann man mit
  set hm archConfig
speichern und mit
  set hm loadConfig
mach einem reboot laden. Welche templates einer entity zugewiesen sind kann man mit
  attr <entity> expert 12
in den Readings sichtbar machen. Siehe auch templateUsg.
 
Man kann prüfen, ob ein Aktor/[[Peering (HomeMatic)|Peer]] gemäss einem Template programmiert ist. Sinnvoll ist eine komplette Prüfung aller zugewiesenen templates. Man kann aber auch filtern.
  get hm templateChk
  get hm templateChk [<filter>]
   get hm templateChk [<filter>] <templateName> <peer:[long|short]> [<param1> ...]  
   get hm templateChk [<filter>] <templateName> <peer:[long|short]> [<param1> ...]  
   get hm templateChk -f Rollo RolloHoch self01 5
   get hm templateChk -f Rollo RolloHoch self01 5
Es wird geprüft für alle HM-Komponenten, die "Rollo" im Namen haben (siehe [[Filter]]) dem (hoffentlich vorhandenen) template "RolloHoch" verglichen. Geprüft wird nur der Peer "self01", aber für long UND short.
Es wird geprüft für alle HM-Komponenten, die "Rollo" im Namen haben (siehe [[HMInfo#Filter|Filter]]) dem (hoffentlich vorhandenen) template "RolloHoch" verglichen. Geprüft wird nur der Peer "self01", aber für long UND short.
  get hm templateChk -f Rollo RolloHoch self01:sort 5
:<code>get hm templateChk -f Rollo RolloHoch self01:sort 5 </code>
das selbe, aber nur für short Einträge
das selbe, nur für short Einträge


===Temperaturlisten===
====templateUsg ====
HMInfo bietet verschiedenen Methoden, Temperaturlisten für Thermostate (TC oder RT) zu verwalten und zu nutzen. Prinzip ist, dass die Temperaturlisten in einem Konfigurationsfile Abgelegt werden. Der Filename ist frei wählbar - der Default ist '''tempList.cfg'''.
Gibt eine Liste der zugewiesenen templates zurück
Für alle Kommandos können die [[Filter]] genutzt werden.
  get hm templateUsg 
Voraussetzung für die Kommandos ist, dass die Daten aus dem Device gelesen wurden - die in FHEM vorhandenen Daten werden als korrekt angenommen. Siehe auch '''autoReagReg''' Attribut der HM Komponenten.
   get hm templateUsg sortTemplate
====speichern ====
   get hm templateUsg sortPeer
   set hm tempList save <filename>
Die in FHEM vorhandenen Temperaturlisten aller devices (hier ist kein Filter gesetzt also alle) in das File <filename> geschrieben. Man kann dieses als Basis nehmen um seine Temperaturlisten zu bearbeiten.
====prüfen====
   set hm tempList verify <filename>
HMInfo vergleicht die im File abgelegten Temperaturlisten mit denen, in FHEM vorliegenden. Unterschieden werden gemeldet. Es wird nichts in das Device geschrieben oder verändert


====restore====
====templateExe ====
  set hm tempList restore <filename>
Nach einem loadConfig oder einem templateChk können Fehler erkannt worden sein, die Register entsprächen nicht dem Template. Mit diesem Kommando werden alle nicht korrekten Register in die Devices geschrieben. Sollten die Werte stimmen, wird nichts gemacht.  
Es werden alle temperaturlisten aus dem File in die dafür eingerichteten Komponenten eingetragen. Dabei werden ausschließlich die Änderungen geschrieben. Liegen keine Unterschieden zwischen File in Daten vor, wird auch nichts geschrieben. Ein mehrfaches anwendend des Kommandos ist also keine Belastung des Systems.
:<code>set hm templateExe </code>
Will man das '''Schreiben''' ungeachtet der vorhandenen Daten '''erzwingen''' sollte man mit "clear Register" die in FHEM vorhandenen Einträge löschen und dann ein tempList restore ausführen.
Das Kommando kann also bedenkenlos eingesetzt werden, wenn die templates schon stimmen. Es wird nichts gesendet, keine Funklast erzeugt.
====Aufbau Tempfile====
Zu erstmaligen Erstellen eines Files nutzt man am Einfachsten das Kommando tempList save.  


  entities:HK1,HK2
====templateDel ====
  R_0_tempListSat>08:00 14.0 15:00 18.0 21:30 19.0 24:00 14.0
eine Zuweisung des Templates kann gelöscht werden
  R_1_tempListSun>08:00 14.0 15:00 18.0 21:30 19.0 24:00 14.0
:<code>set hm templateDel <entity> <template> </code>
  R_2_tempListMon>07:00 14.0 16:00 18.0 21:00 19.0 24:00 14.0
  R_3_tempListTue>07:00 14.0 13:00 16.0 16:00 18.0 21:00 19.0 24:00 15.0
  R_4_tempListWed>07:00 14.0 16:00 18.0 21:00 19.0 24:00 14.0
  R_5_tempListThu>07:00 14.0 16:00 18.0 21:00 19.0 24:00 14.0
  R_6_tempListFri>07:00 14.0 13:00 16.0 16:00 18.0 21:00 19.0 24:00 14.0
  entities:HK3
  R_0_tempListSat>08:00 14.0 15:00 18.0 21:30 19.0 24:00 14.0
  R_1_tempListSun>08:00 14.0 15:00 18.0 21:30 19.0 24:00 14.0
  R_2_tempListMon>07:00 14.0 16:00 18.0 21:00 19.0 24:00 14.0
  R_3_tempListTue>07:00 14.0 13:00 16.0 16:00 18.0 21:00 19.0 24:00 15.0
  R_4_tempListWed>07:00 14.0 16:00 18.0 21:00 19.0 24:00 14.0 
  R_5_tempListThu>07:00 14.0 16:00 18.0 21:00 19.0 24:00 14.0
  R_6_tempListFri>07:00 14.0 13:00 16.0 16:00 18.0 21:00 19.0 24:00 14.0


Die Zeile '''entities''' legt fest, für welche Komponenten die nachfolgende Liste gültig sein soll. Die Erste ist also gültig für HK1 und HK2, die Zweite für HK3.
===Temperaturlisten===
Will man identisch Listen für mehrere Komponenten nutzen, schreibt man deren Namen einfach in die liste der Entities.
HMInfo bietet verschiedene Methoden, Temperaturlisten für Thermostate (CC-TC, TC-IT oder RT) zu verwalten und zu nutzen. Siehe hierzu [[HomeMatic HMInfo TempList/Weekplan|Homematic Weekplan]]
Zu Beachten ist, das nach ändern der Liste ein erneutes templistSave auf den gleichen Filenamen die Daten verändern kann. Es könnte daher ratsam sein, den Filenamen einer manuell bearbeiteten Konfiguration nicht beim Default zu belassen.
 
====tempList Templates====
User möchten möglicherweise die Temperaturlisten einer Komponente über das Jahr verändern (sommer und Winterprofil). Dazu kann man Templates festlegen. Das ganze funktioniert wie das Kommando tempList mit dem Unterschied, dass der Namen des Templates angegeben werden kann.
Im File wird der Name des Templates in der Zeile Entities eingegeben, identisch wir der Name einer Komponente.
  set hm tempListTmpl -f hkWZ wzSommer restore tempListFile.cfg
Allen Thermostate mit hkWZ im Namen wird die Templiste, die im File tempListFile.cfg unter entity "wzSommer" abgelegt ist überschrieben. Wie bei tempList restore wird auch hier nur geschrieben, wenn ein Unterschied erkannt wird.  


=== Registersätze kopieren ===
=== Registersätze kopieren ===
HMInfo erlaubt das kopieren von Register-Listen. Über Register wird ein HM-Gerät eingestellt und die Register sind in Listen gruppiert. Die Reaktion und das Verhalten eines Aktors auf einen Trigger eines Sensors wird in dem Registersatz zu diesem Peer komplett beschrieben.  
HMInfo erlaubt das Kopieren von Register-Listen. Über Register wird ein HM-Gerät eingestellt und die Register sind in Listen gruppiert. Die Reaktion und das Verhalten eines Aktors auf einen Trigger eines Sensors wird in dem Registersatz zu diesem [[Peering (HomeMatic)|Peer]] komplett beschrieben.  
Durch die Möglichkeit einen solchen Registersatz im Device zu kopieren kann man das Verhalten, das man für einen Knopf/Sensor festgelegt hat identisch in einen 2. kopieren.  
Durch die Möglichkeit einen solchen Registersatz im Device zu kopieren kann man das Verhalten, das man für einen Knopf/Sensor festgelegt hat, identisch in einen zweiten kopieren. HMInfo geht davon aus, dass die vom Gerät gelesene Konfiguration vor dem Kommando aktuell und komplett ist.  
HMInfo geht davon aus, dass die vom Gerät gelesene Konfiguration vor dem Kommando aktuell und komplett ist.  
  set hm cpRegs Licht1:FB3_Btn2 Licht3:FB1_Btn4
  set hm cpRegs Licht1:FB3_Btn2 Licht3:FB1_Btn4
  set hm cpRegs Licht2:FB3_Btn2 Licht2:FB1_Btn4
  set hm cpRegs Licht2:FB3_Btn2 Licht2:FB1_Btn4
  set hm cpRegs Licht4:FB3_Btn2 Licht4:FB5_Btn2
  set hm cpRegs Licht4:FB3_Btn2 Licht4:FB5_Btn2
Die obigen Beispiele bewirken der reihen nach:
Die obigen Beispiele bewirken der Reihe nach:
Duplizieren das Verhalten, das Fernbedienungsknopf 2 der Fernbedienung 3 bei Aktor Licht1 hervorruft auch nach Licht3 für Fernbedienungsknopf4 der Fernbedienung 1.
Duplizieren das Verhalten, das Fernbedienungsknopf 2 der Fernbedienung 3 bei Aktor Licht1 hervorruft auch nach Licht3 für Fernbedienungsknopf4 der Fernbedienung 1.
Duplizieren das Verhalten, das Fernbedienungsknopf 2 der Fernbedienung 3 bei Aktor Licht2 hervorruft auch nach Licht2 (selber Aktor) für Fernbedienungsknopf4 der Fernbedienung 1.
Duplizieren das Verhalten, das Fernbedienungsknopf 2 der Fernbedienung 3 bei Aktor Licht2 hervorruft auch nach Licht2 (selber Aktor) für Fernbedienungsknopf4 der Fernbedienung 1.


== web Einträge und Readings ==
== Web Einträge und Readings ==
Readings und Internals von HMInfo bieten eine Zusammenfassung des Zustands aller HM Komponenten. Diese sind in Fehler '''ERR' , Warnungen '''W_''' und Information '''I_''' untergliedert. Die Prüfung und Erneuerung der Zähler und Werte wird mit:
Readings und Internals von HMInfo bieten eine Zusammenfassung des Zustands aller HM Komponenten. Diese sind in Fehler '''ERR''' , Warnungen '''W_''' und Information '''I_''' untergliedert. Die Prüfung und Erneuerung der Zähler und Werte wird mit:
  set hm update
:<code>set hm update </code>
erreicht. Mit dem Attribut autoUpdate kann man es automatisch regelmäßig starten.
erreicht. Mit dem Attribut autoUpdate kann man es automatisch regelmäßig starten.


=== Fehlermeldungen ===
=== Fehlermeldungen ===
Als Fehler erkannte Zustände werden in Variablem beginnend mit '''ERR''' dargestellt. Erfasste Fehler sind Kritische RSSI werte und Protokoll/Übertragungsfehler. Ausserdem kann man im Attribut sumERROR eintragen, welche Readings zu einer Fehlermeldung führen sollen. Eingetragen werden:
Als Fehler erkannte Zustände werden in Variablen beginnend mit '''ERR''' dargestellt. Erfasste Fehler sind kritische RSSI Werte und Protokoll-/Übertragungsfehler. Ausserdem kann man im Attribut sumERROR eintragen, welche Readings zu einer Fehlermeldung führen sollen. Eingetragen werden:
Reading:<gutwert>. Wenn ein Reading mit einen anderen als dem "gutwert" gefunden wird, wird dies alarmiert.  
Reading:<gutwert>. Wenn ein Reading mit einem anderen als dem "gutwert" gefunden wird, wird dies alarmiert.  
Beispiel:  
Beispiel:  
  battery:ok
:<code>battery:ok </code>
hat eine HM Komponente ein Reading "battery" und dieses hat einen anderen Wert als "ok" wird dies alarmiert.  
hat eine HM Komponente ein Reading "battery" und dieses hat einen anderen Wert als "ok" wird dies alarmiert.  
In den Readings von HMInfo würde im Feherfall
In den Readings von HMInfo würde im Fehlerfall
   internal:
   internal:
     ERR_names <devicename1>,<devicename2>
     ERR_names <devicename1>,<devicename2>
Zeile 194: Zeile 237:
     ERR_battery low:2
     ERR_battery low:2


Der default aller Error-meldungen ist
Der default aller Fehlermeldungen ist
battery:ok,sabotageError:off,powerError:ok,overload:off,overheat:off,reduced:off,motorError:no,error:none,uncertain:yes,smoke_detect:none,cover:closed
:<code>battery:ok,sabotageError:off,powerError:ok,overload:off,overheat:off,reduced:off,motorError:no,error:none,uncertain:yes,smoke_detect:none,cover:closed </code>


Diese zusammenfassung der Fehlermeldungen könnte man nutzen, um über notify einen Alarm auszulösen oder eine email zusenden.  
Diese Zusammenfassung der Fehlermeldungen könnte man nutzen, um über notify einen Alarm auszulösen oder eine E-Mail zu senden.  


=== Warnungen===
=== Warnungen===
Hierzu gehören Wiederholungen von Nachrichten (nicht aber Abbrüche, das sind Fehler). Es wird auch ausstehendes Lesen der Konfiguration, welches durch autoReadReg getriggert wird hier angezeigt.  
Hierzu gehören Wiederholungen von Nachrichten (nicht aber Abbrüche, das sind Fehler). Es wird auch ausstehendes Lesen der Konfiguration, das durch autoReadReg getriggert wird, hier angezeigt.  


=== Statusmeldungen ===
=== Statusmeldungen ===
Analog zu den Fehlermeldungen kann man mit dem Attribut sumStatus gewisse Readings zählen lassen. Beipiel wäre  
Analog zu den Fehlermeldungen kann man mit dem Attribut sumStatus gewisse Readings zählen lassen. Beipiel wäre  
   attr HM sumStatus motor
   attr HM sumStatus motor
HMInfo zeigt in dem Reading I_sum_motor dann an, welcher Inhalt des Readings "motor"  wie oft gefinden wurde. Es könnte so aussehen
HMInfo zeigt in dem Reading I_sum_motor dann an, welcher Inhalt des Readings "motor"  wie oft gefunden wurde. Es könnte so aussehen
   stop:on:4;stop:1;
   stop:on:4;stop:1;
4 Komponenten stehen auf motor: stop:on und einer steht auf motor: stop
Vier Komponenten stehen auf motor: stop:on und eine steht auf motor: stop


Das Internal '''I_HM_IOdevices''' zeigt die von HM Komponenten genutzten IOs und deren State.  
Das Internal '''I_HM_IOdevices''' zeigt die von HM Komponenten genutzten IOs und deren State.  
Zeile 216: Zeile 259:
   get hm models -f remote
   get hm models -f remote
   get hm models -f HM_RC
   get hm models -f HM_RC
zeigt alle in FHEM unterstützten Modelle und deren wesentliche Parameter. Man kann mittels regexp die Liste filtern.
Zeigt alle in FHEM unterstützten Modelle und deren wesentliche Parameter. Man kann mittels regexp die Liste filtern.


   get hm param [<typefilter>] [-f <nameFilter>] parameter1 parameter2
   get hm param [<typefilter>] [-f <nameFilter>] parameter1 parameter2
Zeile 227: Zeile 270:


   get hm peerXref[<typefilter>] [-f <nameFilter>]
   get hm peerXref[<typefilter>] [-f <nameFilter>]
gibt an, wer mit wem gepeert ist
gibt an, wer mit wem [[Peering (HomeMatic)|gepeert]] ist


== Rücksetzen von Variablen uns Zählern ==
== Rücksetzen von Variablen und Zählern ==
  set HM clear [<typeFilter>] [Protocol|readings|msgStat|register|rssi]
  set HM clear [<typeFilter>] [Protocol|readings|msgStat|register|rssi]
*register löscht alle Register-readings
*register löscht alle Register-readings
Zeile 238: Zeile 281:


== Filter ==
== Filter ==
Kommandos in HMInfo wirken auf alle HM Komponenten. Man kann dies mit Hilfe der Filter einschränken. Zum einen gibt es '''modelsFilter''', womit man nur devices, nur channels, nur virtuellen Entities bearbeiten kann
Kommandos in HMInfo wirken auf alle HM Komponenten. Man kann dies mit Hilfe der Filter einschränken. Zum einen gibt es '''modelsFilter''', womit man nur devices, nur channels, nur virtuelle Entities bearbeiten kann
     set <name> <cmd> '''[-dcasevi]'''  [params]
     set <name> <cmd> '''[-dcasevi]'''  [params]
         entities according to list will be processed"
         entities according to list will be processed"
Zeile 252: Zeile 295:
Ein auf '''-d''' gefiltertes Kommando wird nur auf devices, nicht aber auf channels angewendet.  
Ein auf '''-d''' gefiltertes Kommando wird nur auf devices, nicht aber auf channels angewendet.  


Dann gibt es noch dem '''nameFilter''', mit dem man mittels regexp auf dem Namen der Entity gefiltert werden kann
Dann gibt es noch den '''nameFilter''', mit dem mittels regexp auf den Namen der Entity gefiltert werden kann
   -f Rollo # alle Entities mit Rollo im Namen
   -f Rollo # alle Entities mit Rollo im Namen
   -f ^Rollo$ # nur Entity mit Namen "Rollo"
   -f ^Rollo$ # nur Entity mit Namen "Rollo"
Zeile 265: Zeile 308:




=Attribute=
== Attribute ==
* '''configDir''' bietet die Möglichkeit ein directory zu definieren, in welches HMInfo Files ablegen und von welchem es die Files lesen wird.
* '''configFilename''' legt einen default Namen fest, der bei save und archive genutzt wird.
* '''autoArchive ''' automatisch archivieren von vollständigen Konfigurationen.
* '''autoArchive ''' automatisch archivieren von vollständigen Konfigurationen.
* '''autoUpdate''' started regelmäsig das Komamndo "update". Die Wiederholzeit wird eingestellt mit hh:mm. Sinnvoll erscheint z.B. alle 5 Minuten, also 00:05.  
* '''autoUpdate''' startet regelmäßig das Komamndo "update". Die Wiederholzeit wird eingestellt mit hh:mm. Sinnvoll erscheint z.B. alle 5 Minuten, also 00:05.
* '''configDir''' bietet die Möglichkeit, ein Verzeichnis zu definieren, in das HMInfo Dateien ablegen und von dem es die Dateien lesen wird. Default ist fhem_root.
= Quellen =
* '''configFilename''' legt einen default Namen fest, der bei save und archive genutzt wird. Default ist regSave.cfg.
* Thread [http://forum.fhem.de/index.php?topic=11035.0 HMinfo] im Fhem Forum
* '''hmAutoReadScan''' zeitinterval in Minuten, in denen CUL_HM prüft, ob offene autoRead bereitstehen und die IOs die Kapazität haben. Default ist 4 min.
* Thread [http://forum.fhem.de/index.php/topic,20119.0.html HMINfo, Intention, Sinn und Zweck] im Fhem Forum
== Weiterführende Links ==
* [[HomeMatic Templates]]
 
== Quellen ==  
* Thread {{Link2Forum|Topic=11035|LinkText=HMinfo}} im FHEM Forum
* Thread {{Link2Forum|Topic=20119|LinkText=HMINfo, Intention, Sinn und Zweck}} im FHEM Forum


[[Kategorie:HomeMatic Components]]
[[Kategorie:HomeMatic supportDevice]]
[[Kategorie:HOWTOS]]
[[Kategorie:HOWTOS]]

Aktuelle Version vom 3. Dezember 2021, 12:10 Uhr

HMinfo
Zweck / Funktion
Übersicht über alle HomeMatic Geräte
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!

HMInfo ist ein Modul, das einen Überblick über alle definierten HomeMatic Geräte gibt. Es bietet Funktionen zur Übersicht, Kontrolle, Archivierung und - begrenzt - zur Programmierung der HomeMatic Komponenten. Somit soll es eine Hilfestellung bei Konfiguration und Fehlerbehandlung geben.

Definition

HMInfo wird erstellt / angelegt mit dem Befehl

define hm HMinfo

Danach können alle Funktionen aufgelistet werden mit

get hm help

Integritätsprüfungen

Zu berücksichtigen bei allen Funktionen von HMInfo ist die Tatsache, dass die Prüfung jeweils auf den innerhalb von FHEM vorliegenden Informationen passiert. Erste Korrekturmaßnahme ist daher immer von den betroffenen Devices die Informationen mit einem set <Device> getConfig zu aktualisieren. Dabei ist darüber hinaus zu berücksichtigen, dass entsprechend der konfigurierten Kommunikationsmethode (z.B. config) einige Devices erst nach einer gewissen Zeit oder nach Betätigen der Anlerntaste die Informationen als Antwort zurückliefern.

Befehle, um die Gültigkeit von verschiedenen HomeMatic Eigenschaften zu überprüfen:

peerCheck

Mit dem Befehl

get hm peerCheck

wird der Zustand der Peerings überprüft, d.h., ob alle Peerings auch beidseitig sind. Mögliche Meldungen, die eine Überarbeitung und/oder Korrektur von Definitionen erforderlich machen können:

peer not verified. Check that peer is set on both sides
ausgegebener Wert (z.B.): actorChan p:switchChan
erforderliche Korrekturmaßnahme: Erneutes setzen des Links und Sicherstellen, dass das Kommando das entsprechende Device auch erreicht hat (s.o., ggf. bei Bedarf die Anlerntaste betätigen).

regCheck

Mit dem Befehl

get hm regCheck

wird überprüft, ob alle Register korrekt gelesen wurden. Mögliche Meldungen:

missing register list
ausgegebener Wert (z.B.): dev01Ch01: RegL_01:
erforderliche Korrekturmaßnahme: set dev01Ch01 getConfig
oder device01Ch01: .RegL_03:sensor01Ch01,.RegL_03:sensor01Ch02
erforderliche Korrekturmaßnahme: Deutet darauf hin, dass nicht alle Informationen aus einem Device gelesen wurden. Ein set <Device> getConfig sollte alle Register auslesen. Sicherstellen, dass das Kommando zum Auslesen das entsprechende Device auch erreicht und eine Antwort geliefert hat (s.o., ggf. bei Bedarf die Anlerntaste betätigen).
Register changes pending
ausgegebener Wert (z.B.): sensor01Ch01
erforderliche Korrekturmaßnahme: Ein set <Device> getConfig sollte alle Register auslesen. Sicherstellen, dass das Kommando das entsprechende Device auch erreicht und eine Antwort geliefert hat (s.o., ggf. bei Bedarf die Anlerntaste betätigen).

configCheck

Mit dem Befehl

get hm configCheck werden die Befehle peerCheck und regCheck ausgeführt. Zusätzlich können noch Ergebnisse auftauchen wie
PairedTo mismatch to IODev
ausgegebener Wert (z.B.): sensor01Ch01 paired:0x000000 IO attr: xxxxxx.
erforderliche Korrekturmaßnahme: IODevice in den hmPairForSec Modus versetzen, Pairing-Modus am Device aktivieren und dadurch das pairing wiederholen. Ein Anschließendes set <Device> getConfig kann nicht schaden. Sicherstellen, dass das Kommando zum Auslesen das entsprechende Device auch erreicht und eine Antwort geliefert hat (s.o., ggf. bei Bedarf die Anlerntaste betätigen).

Anzeigen zur Übertragungssituation

RSSI

get hm rssi [<filter>]
Erzeugt eine Tabelle aller RSSI Werte.
set hm clear [<filter>] rssi
setzt die RSSI Werte aller devices gemäß filter zurück. Eine neue Messung kann beginnen

protoEvents

get hm protoEvents [<filter>][short|long]

Siehe HMinfo Protokoll

Es wird eine Tabelle mit allen wichtigen Ereignissen zur Datenübertragung erzeugt. Dies beinhaltet Wiederholungen sowie Übertragungsfehler.

short ist eine Fassung ohne Zeitstempel und lässt sich besser am Bildschirm darstellen. Ausserdem kann man sehen, welche Abfragen noch in der Queue sind, z.B. durch autoReadReg erzeugt. Die Zustände aller für HM zuständigen IOs sind beinhaltet. Alles in allem ist hier ein kompletter Überblick zur Kommunikation zu sehen. Der Befehl 

set hm clear [<filter>] Protocol

setzt die Protokoleinträge aller HomeMatic-Geräte gemäß Filter zurück. Das kann gut vor einer Konfigurationsaktion genutzt werden um zu kontrollieren, ob Fehler aufgetreten sind.
Für tieferes Verständnis siehe HMinfo Protokoll

msgStat

set hm msgStat
Statistic der Übertragenen Messages insgesamt. Es gibt eine Tabelle über die letzten 24h und eine über die letzte Woche.

Speichern von Konfigurationen

HMInfo speichert Konfigurationen der Geräte in Files. Mit dem Attribut configDir kann man ein Verzeichnis festlegen, in das alles geschrieben wird.

saveConfig

Peers und Register werden in eine Datei geschrieben. Die Daten kann man ggf. wieder in ein Gerät oder ein Austauschgerät schreiben. Die Speicherung erfolgt kumulativ, man kann alles in eine Datei schreiben.

set hm saveConfig [<filter>] [<file>]

archConfig

Arbeitet prinzipiell wie saveConfig. Es werden jedoch nur vollständige Registersätze gespeichert, was einen höheren Level an Sicherheit der Dateninhalte gewährt.

set hm archConfig [-a] [<file>]

Mit dem Attribut autoArchive kann man einstellen, dass automatisch nach erfolgreichem Lesen einer Device-Konfiguration diese archiviert wird. Das Speichern erfolgt kumulativ. Ab einer Dateigröße von 1MB wird gepurged, also alles bis auf den neusten Eintrag jeder Entity gelöscht.

Um eine Konfiguration zu sichern, sollte eine Kopie des Archivs gemacht werden. Das Archiv wird bei Gelegenheit überschrieben.

Template erstellen:

set hm saveConfig -f ^meinDevice$ <myTemplateFile>

loadConfig

set hm loadConfig [<filter>] [<filename>]
Liest die Registerwerte, die für eine Entity in einem File gespeichert sind, zurück in die Readings. Sollten die Register schon in FHEM vorhanden sein, wird nicht überschrieben.

Sinn macht dies beispielsweise für remotes, die nicht automatisch gelesen werden sollen. Man kann somit nach einem system-reboot die Register "rekonstruieren" und wieder darstellen. Es liegt im ermessen des User, eine bekannt aktuelle Version der Register einzulesen.

purgeConfig

set hm purgeConfig [<filename>]
Löscht alle älteren Datensätze in einem File.

Konfigurationen bearbeiten

Templates

HMInfo erlaubt das Erstellen und Nutzen von Templates. Das sind Schablonen, die das Setzen von Registern abstrahieren und auf eine höhere Ebene heben. So kann man das Setzen der Konfiguration eines Aktors beispielsweise um mit einem Bewegungsmelder zusammen zu arbeiten in einem Kommando zusammenfassen. Faktisch setzt das Template also eine Gruppe von Registern auf einmal.

templateList

Die vorhandenen templates kann man mit templateList sehen. 

 get hm templateList
 
 SwOnCond         params:level cond               Info:switch: execute only if condition [geLo|ltLo] level is below limit
 SwToggle         params:                         Info:Switch: toggle on trigger
 autoOff          params:time                     Info:staircase - auto off after

Die Liste der verfügbaren Tempaltes, deren Parameter falls nötig und eine kurze Info, was das Template bewirken soll 

 get hm templateList autoOff

 autoOff          params:time                     Info:staircase - auto off after

Ein templateList auf ein einzelnes Template zeigt im Detail, was das Template verändern wird.

templateSet

Um ein Template auf einen Aktor anzuwenden,muss man den Bereich wählen, auf den er angewendet werden soll. Je nach template kann das die Gruppe der Register zu einem Peer, zu short oder long eines Peer oder Register ohne peer sein. 

 set hm templateSet <entity> <templateName> <peer:[long|short]> [<param1> ...] 
 set hm templateSet Licht1 autoOff FB1_Btn2:short 10
 set hm templateSet Licht1 SwOn FB1_Btn2:long
 set hm templateSet Licht1 SwOff FB1_Btn2:short
 set hm templateSet Licht1 SwOnOff FB1_Btn2:both
 set hm templateSet LichtDev setHost 0

Licht1 soll, wenn ein kurzer Trigger von FB1_Btn2 kommt für 10 sec eingeschaltet werden, dann ausgehen (Treppenhausfunktion). Kommt aber ein langer Tastendruck wird das Licht dauerhaft eingeschaltet. 

 set hm templateSet Licht1 motionOnSw MD1:short 30 20

Der Switch Aktor Licht1 soll mit einem Bewegungsmelder betrieben werden. Der Bewegungsmelder sendet keine 'langen' Trigger sondern nur kurze. Im Beispiel wird Licht1 für 30 Sekunden eingeschaltet, wenn der Bewegungsmelder einen Trigger sendet UND es dunkler ist als "20" (Brightness level).

templateDef

Neben den vorbereiteten Templates kann der User eigene definieren oder von anderen Usern sich Templates geben lassen. Die Definition von Templates ist für erfahrene User gedacht, im Gegensatz zur Nutzung eines Templates mit set - das ist für Anfänger gedacht. Man kann sein template manuell definieren oder ein bekanntes Device als Muster nutzen (fromMaster). Ein Template kann nur Gruppen von Registern setzen, nicht alle Register eines Device. Um die Gruppen anzusprechen muss man "peer" wie folgt setzen: 

 0            Register ohne peer
 <peer>:both  Register eines peers
 <peer>:short Register eines peers nur Short
 <peer>:long  Register eines peers nur Long

setzen. Man kann das template "dynamisch" gestalten, indem man einzelne Register beim templateSet übergibt. Erst einmal statische Templates. Param ist hier "0" 

 set hm templateDef <templateName> <param1[:<param2>...]> <description> <reg1>:<val1> [<reg2>:<val2>] ... 

 set hm templateDef t1 0 "TP1" OnTime:10 OffTime:20 OnDly:0 

 set hm templateDef t1 fromMaster <entity> 0 
 set hm templateDef t2 fromMaster <entity> <peer>:both 
 set hm templateDef t3 fromMaster <entity> <peer>:short
 set hm templateDef t4 fromMaster <entity> <peer>:long

 set hm templateDef t4 fromMaster LichtWz remoteBtn1:long

Dynamische Templates haben eine Parameterliste (bis zu 9) <param1[:<param2>...]>. Diese werden als p0 bis p8 genutzt - der Name ist dabei egal, er dient dem User also Hilfe beim templateList 

 set hm templateDef myTemplate anzeit:auszeit "licht schaltet ständig an und aus" OnTime:p0 OffTime:p1 OnDly:0

 set hm templateDef myAutoOff AnZeit "treppenhausschalter" ActionType:jmpToTarget OffTime:unused OnTime:p0 SwJtDlyOff:dlyOn SwJtDlyOn:no SwJtOff:dlyOn SwJtOn:on

Die "Anzeit" ist der erste Parameter, also p0. Der Wert, den man bei Set einträgt wird in OnTime geschrieben. OnTime:p0

Beim Definieren eines Templates wird die Registergültigkeit nicht geprüft. Das kommt beim Set.

Mit dem Parameter del kann ein (fehlerhaftes) Template (hier myTemplate) wieder gelöscht werden. 

 set hm templateDef myTemplate del

templateChk

Template definitionen und zuweisungen (set) kann man mit 

 set hm archConfig

speichern und mit 

 set hm loadConfig

mach einem reboot laden. Welche templates einer entity zugewiesen sind kann man mit 

 attr <entity> expert 12

in den Readings sichtbar machen. Siehe auch templateUsg.

Man kann prüfen, ob ein Aktor/Peer gemäss einem Template programmiert ist. Sinnvoll ist eine komplette Prüfung aller zugewiesenen templates. Man kann aber auch filtern. 

 get hm templateChk 
 get hm templateChk [<filter>] 
 get hm templateChk [<filter>] <templateName> <peer:[long|short]> [<param1> ...] 
 get hm templateChk -f Rollo RolloHoch self01 5

Es wird geprüft für alle HM-Komponenten, die "Rollo" im Namen haben (siehe Filter) dem (hoffentlich vorhandenen) template "RolloHoch" verglichen. Geprüft wird nur der Peer "self01", aber für long UND short.

get hm templateChk -f Rollo RolloHoch self01:sort 5

das selbe, nur für short Einträge

templateUsg

Gibt eine Liste der zugewiesenen templates zurück 

 get hm templateUsg  
 get hm templateUsg sortTemplate
 get hm templateUsg sortPeer

templateExe

Nach einem loadConfig oder einem templateChk können Fehler erkannt worden sein, die Register entsprächen nicht dem Template. Mit diesem Kommando werden alle nicht korrekten Register in die Devices geschrieben. Sollten die Werte stimmen, wird nichts gemacht.

set hm templateExe

Das Kommando kann also bedenkenlos eingesetzt werden, wenn die templates schon stimmen. Es wird nichts gesendet, keine Funklast erzeugt.

templateDel

eine Zuweisung des Templates kann gelöscht werden

set hm templateDel <entity> <template>

Temperaturlisten

HMInfo bietet verschiedene Methoden, Temperaturlisten für Thermostate (CC-TC, TC-IT oder RT) zu verwalten und zu nutzen. Siehe hierzu Homematic Weekplan

Registersätze kopieren

HMInfo erlaubt das Kopieren von Register-Listen. Über Register wird ein HM-Gerät eingestellt und die Register sind in Listen gruppiert. Die Reaktion und das Verhalten eines Aktors auf einen Trigger eines Sensors wird in dem Registersatz zu diesem Peer komplett beschrieben. Durch die Möglichkeit einen solchen Registersatz im Device zu kopieren kann man das Verhalten, das man für einen Knopf/Sensor festgelegt hat, identisch in einen zweiten kopieren. HMInfo geht davon aus, dass die vom Gerät gelesene Konfiguration vor dem Kommando aktuell und komplett ist. 

set hm cpRegs Licht1:FB3_Btn2 Licht3:FB1_Btn4
set hm cpRegs Licht2:FB3_Btn2 Licht2:FB1_Btn4
set hm cpRegs Licht4:FB3_Btn2 Licht4:FB5_Btn2

Die obigen Beispiele bewirken der Reihe nach: Duplizieren das Verhalten, das Fernbedienungsknopf 2 der Fernbedienung 3 bei Aktor Licht1 hervorruft auch nach Licht3 für Fernbedienungsknopf4 der Fernbedienung 1. Duplizieren das Verhalten, das Fernbedienungsknopf 2 der Fernbedienung 3 bei Aktor Licht2 hervorruft auch nach Licht2 (selber Aktor) für Fernbedienungsknopf4 der Fernbedienung 1.

Web Einträge und Readings

Readings und Internals von HMInfo bieten eine Zusammenfassung des Zustands aller HM Komponenten. Diese sind in Fehler ERR , Warnungen W_ und Information I_ untergliedert. Die Prüfung und Erneuerung der Zähler und Werte wird mit:

set hm update

erreicht. Mit dem Attribut autoUpdate kann man es automatisch regelmäßig starten.

Fehlermeldungen

Als Fehler erkannte Zustände werden in Variablen beginnend mit ERR dargestellt. Erfasste Fehler sind kritische RSSI Werte und Protokoll-/Übertragungsfehler. Ausserdem kann man im Attribut sumERROR eintragen, welche Readings zu einer Fehlermeldung führen sollen. Eingetragen werden: Reading:<gutwert>. Wenn ein Reading mit einem anderen als dem "gutwert" gefunden wird, wird dies alarmiert. Beispiel:

battery:ok

hat eine HM Komponente ein Reading "battery" und dieses hat einen anderen Wert als "ok" wird dies alarmiert. In den Readings von HMInfo würde im Fehlerfall 

 internal:
   ERR_names <devicename1>,<devicename2>
 Readings:
   ERR_battery low:2

Der default aller Fehlermeldungen ist

battery:ok,sabotageError:off,powerError:ok,overload:off,overheat:off,reduced:off,motorError:no,error:none,uncertain:yes,smoke_detect:none,cover:closed

Diese Zusammenfassung der Fehlermeldungen könnte man nutzen, um über notify einen Alarm auszulösen oder eine E-Mail zu senden.

Warnungen

Hierzu gehören Wiederholungen von Nachrichten (nicht aber Abbrüche, das sind Fehler). Es wird auch ausstehendes Lesen der Konfiguration, das durch autoReadReg getriggert wird, hier angezeigt.

Statusmeldungen

Analog zu den Fehlermeldungen kann man mit dem Attribut sumStatus gewisse Readings zählen lassen. Beipiel wäre 

 attr HM sumStatus motor

HMInfo zeigt in dem Reading I_sum_motor dann an, welcher Inhalt des Readings "motor" wie oft gefunden wurde. Es könnte so aussehen 

 stop:on:4;stop:1;

Vier Komponenten stehen auf motor: stop:on und eine steht auf motor: stop

Das Internal I_HM_IOdevices zeigt die von HM Komponenten genutzten IOs und deren State.

Infos

 get hm models [-f <regexp>]
 get hm models
 get hm models -f remote
 get hm models -f HM_RC

Zeigt alle in FHEM unterstützten Modelle und deren wesentliche Parameter. Man kann mittels regexp die Liste filtern. 

 get hm param [<typefilter>] [-f <nameFilter>] parameter1 parameter2
 get hm param -d IODev DEF model
 get hm param -c -f Rollo peerList

man kann sich listen von Parametern anzeigen lassen 

 get hm register [<typefilter>] [-f <nameFilter>]

zeigt Register in tabellarischer Form. 

 get hm peerXref[<typefilter>] [-f <nameFilter>]

gibt an, wer mit wem gepeert ist

Rücksetzen von Variablen und Zählern

set HM clear [<typeFilter>] [Protocol|readings|msgStat|register|rssi]
  • register löscht alle Register-readings
  • readings löscht alle readings
  • Protocol löscht alle Protokol-einträge, pending Kommandos und Protokoll-fehler.
  • rssi löscht alle ermittelten RSSI Werte
  • msgStat setzt die Message Statistik zurück

Filter

Kommandos in HMInfo wirken auf alle HM Komponenten. Man kann dies mit Hilfe der Filter einschränken. Zum einen gibt es modelsFilter, womit man nur devices, nur channels, nur virtuelle Entities bearbeiten kann 

    set <name> <cmd> [-dcasevi]  [params]
       entities according to list will be processed"
         d - device   :include devices"
         c - channels :include channels"
         i - ignore   :include devices marked as ignore"
         v - virtual  :supress fhem virtual"
         p - physical :supress physical"
         a - aktor    :supress actor"
         s - sensor   :supress sensor"
         e - empty    :include results even if requested fields are empty"

Ein auf -d gefiltertes Kommando wird nur auf devices, nicht aber auf channels angewendet.

Dann gibt es noch den nameFilter, mit dem mittels regexp auf den Namen der Entity gefiltert werden kann 

 -f Rollo # alle Entities mit Rollo im Namen
 -f ^Rollo$ # nur Entity mit Namen "Rollo"
 -f Rollo$ # nur Entity deren Name auf Rollo endet

Die Filter kann man kombinieren mit 

 -c -f Rollo # alle Kanäle mit Rollo im Namen

Beispiel: Zeige mir die Parameter IODev und room der Devices mit Rollo im Namen 

 set hm param -d -f Rollo IODev room


Attribute

  • autoArchive automatisch archivieren von vollständigen Konfigurationen.
  • autoUpdate startet regelmäßig das Komamndo "update". Die Wiederholzeit wird eingestellt mit hh:mm. Sinnvoll erscheint z.B. alle 5 Minuten, also 00:05.
  • configDir bietet die Möglichkeit, ein Verzeichnis zu definieren, in das HMInfo Dateien ablegen und von dem es die Dateien lesen wird. Default ist fhem_root.
  • configFilename legt einen default Namen fest, der bei save und archive genutzt wird. Default ist regSave.cfg.
  • hmAutoReadScan zeitinterval in Minuten, in denen CUL_HM prüft, ob offene autoRead bereitstehen und die IOs die Kapazität haben. Default ist 4 min.

Weiterführende Links

Quellen

Abgerufen von „http://wiki.fhem.de/w/index.php?title=HMinfo&oldid=36476“