HMinfo: Unterschied zwischen den Versionen
K (Diverse Tippfehler korrigiert) |
|||
Zeile 25: | Zeile 25: | ||
== Anzeigen zur Übertragungssituation == | == Anzeigen zur Übertragungssituation == | ||
===RSSI === | ===RSSI === | ||
;<code>get hm rssi [<filter>]</code> | |||
Erzeugt eine Tabelle aller RSSI Werte. | :Erzeugt eine Tabelle aller RSSI Werte. | ||
;<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 === | ||
;<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. | :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. | 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. | 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. | 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 allen ist hier ein kompletter Überblick zur Kommunikation zu sehen. Insbesondere bei | ||
:<code>set hm clear [<filter>] Protocol </code> | |||
setzt die Protokol Einträge aller gemäß | setzt die Protokol Einträge aller gemäß Filter zurück. Kann gut vor einer Konfigurationsaktion genutzt werden, um hinterher zu kontrollieren, ob Fehler aufgetreten sind. | ||
===msgStat=== | ===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 | 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 | 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. | ||
:<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. | ||
:<code>set hm archConfig [-a] [<file>] </code> | |||
Mit dem '''Attribut autoArchive''' kann man einstellen, dass automatisch nach | Mit dem '''Attribut autoArchive''' kann man einstellen, dass automatisch nach erfolgreichem Lesen einer Device-Konfiguration diese archiviert wird. | ||
Das Speichern erfolgt kumulativ. Ab einer | 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: | ||
:<code>set hm saveConfig -f ^meinDevice$ <myTempalteFile> </code> | |||
=== loadConfig === | === loadConfig === | ||
;<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, 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. | ||
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, welche 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=== | ||
;<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 | 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 | 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 98: | ||
SwJtOff :dlyOn | SwJtOff :dlyOn | ||
SwJtOn :on | SwJtOn :on | ||
Ein | 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 neben den spezifischen Parametern angeben, für welchen Peer es gelten soll und ob es bei einem kurzen oder langen Tastendruck angewendet werden soll. | ||
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 | 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 | 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, | 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. | ||
set hm templateDef <templateName> <param1[:<param2>...] <description> <reg1>:<val1> [<reg2>:<val2>] ... | set hm templateDef <templateName> <param1[:<param2>...] <description> <reg1>:<val1> [<reg2>:<val2>] ... | ||
set hm templateDef myTemplate anzeit:auszeit "licht schaltet ständig an und aus" OnTime:anzeit OffTime:auszeit OnDly:0 | set hm templateDef myTemplate anzeit:auszeit "licht schaltet ständig an und aus" OnTime:anzeit OffTime:auszeit OnDly:0 | ||
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. | |||
====templateChk ==== | ====templateChk ==== | ||
Man kann prüfen, ob ein Aktor/Peer gemäss einem | Man kann prüfen, ob ein Aktor/Peer gemäss einem Template programmiert ist. | ||
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 [[Homematic 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 | get hm templateChk -f Rollo RolloHoch self01:sort 5 | ||
das selbe, | das selbe, nur für short Einträge | ||
===Temperaturlisten=== | ===Temperaturlisten=== | ||
HMInfo bietet | HMInfo bietet verschiedene Methoden, Temperaturlisten für Thermostate (CC-TC, TC-IT oder RT) zu verwalten und zu nutzen. Prinzip ist, dass die Temperaturlisten in einer Konfigurationsdatei abgelegt werden. Der Dateiname ist frei wählbar. | ||
Für alle Kommandos können die [[Filter]] genutzt werden. | Für alle Kommandos können die [[Homematic HMInfo#Filter|Filter]] genutzt werden. | ||
Beim Prüfen und Speichern wird davon ausgegangen, dass die Register und Daten in FHEM aktuell sind. Die Funktionen speichern und vergleichen aus Performancegründen nicht direkt | Beim Prüfen und Speichern wird davon ausgegangen, dass die Register und Daten in FHEM aktuell sind. Die Funktionen speichern und vergleichen aus Performancegründen nicht direkt im Device sondern die Daten, die FHEM schon gelesen hat. | ||
Siehe auch ''' | Siehe auch '''autoReadReg''' Attribut der HM Komponenten. | ||
==== | |||
====Speichern ==== | |||
Die in FHEM vorhandenen Temperaturlisten aller devices (hier ist kein Filter gesetzt also alle) in | ;<code>set hm tempList save <filename> <code> | ||
==== | :Die in FHEM vorhandenen Temperaturlisten aller devices (hier ist kein Filter gesetzt, also alle) werden in die Datei <filename> geschrieben. Man kann dieses als Basis nehmen, um seine Temperaturlisten zu bearbeiten. | ||
====Prüfen==== | |||
HMInfo vergleicht die | ;<code>set hm tempList verify <filename> </code> | ||
==== | :HMInfo vergleicht die in der Datei abgelegten Temperaturlisten mit den in FHEM vorliegenden. Unterschiede werden gemeldet. Es wird nichts in das Device geschrieben oder verändert. | ||
Es werden alle | ====Restore==== | ||
;<code>set hm tempList restore <filename> </code> | |||
:Es werden alle Temperaturlisten aus der Datei in die dafür eingerichteten Komponenten eingetragen. Dabei werden ausschließlich die Änderungen geschrieben. Liegen keine Unterschiede zwischen Dateiinhalt und aktuellen Daten vor, wird auch nichts geschrieben. Ein mehrfaches anwenden des Kommandos ist also keine Belastung des Systems. | |||
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. | 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. | ||
==== | |||
Der Default- | ====Defaults==== | ||
Der Default-Dateiname ist '''tempList.cfg'''. | |||
Das default-template ist der Name des Device. Ist im Device das '''Attribut tempListTmpl''' gesetzt wird dies zum Vergleich oder | Die Datei steht im fhem-root Verzeichnis. Hat man das Attribut configDir gesetzt und gibt kein Verzeichnis an, wird die Datei im spezifizierten Verzeichnis gesucht. | ||
Das default-template ist der Name des Device. Ist im Device das '''Attribut tempListTmpl''' gesetzt, wird dies zum Vergleich oder Setzen genutzt. | |||
====Aufbau Tempfile==== | ====Aufbau Tempfile==== | ||
Zum erstmaligen Erstellen einer Datei nutzt man am einfachsten das Kommando tempList save. | |||
entities:HK1,HK2 | entities:HK1,HK2 | ||
Zeile 161: | Zeile 167: | ||
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. | 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. | ||
Will man | Will man identische Listen für mehrere Komponenten nutzen, schreibt man deren Namen einfach in die Liste der Entities. | ||
Zu Beachten ist, | Zu Beachten ist, dass nach Ändern der Liste ein erneutes templistSave auf den gleichen Dateinamen die Daten verändern kann. Es ist daher ratsam, den Dateinamen einer manuell bearbeiteten Konfiguration nicht beim Default zu belassen. | ||
====tempList Templates==== | ====tempList Templates==== | ||
User möchten möglicherweise die Temperaturlisten einer Komponente über das Jahr verändern ( | 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. | ||
<!-- Die zweite Hälfte des folgenden Satzes ergibt derzeit keinen Sinn. Was genau ist da gemeint? --> | |||
In der Datei wird der Name des Templates in der Zeile Entities eingegeben, identisch wir(?) der Name einer Komponente. | |||
:<code>set hm tempListTmpl -f hkWZ wzSommer restore tempListFile.cfg <code> | |||
Alle 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 | 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 | 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 | 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 == | ||
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: | ||
:<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 | 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 einen anderen als dem "gutwert" gefunden wird, wird dies alarmiert. | ||
Beispiel: | Beispiel: | ||
:<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 Feherfall | ||
Zeile 201: | Zeile 208: | ||
battery:ok,sabotageError:off,powerError:ok,overload:off,overheat:off,reduced:off,motorError:no,error:none,uncertain:yes,smoke_detect:none,cover:closed | battery:ok,sabotageError:off,powerError:ok,overload:off,overheat:off,reduced:off,motorError:no,error:none,uncertain:yes,smoke_detect:none,cover:closed | ||
Diese | Diese Zusammenfassung der Fehlermeldungen könnte man nutzen, um über notify einen Alarm auszulösen oder eine E-Mail zu senden. | ||
=== Warnungen=== | === Warnungen=== | ||
Zeile 209: | Zeile 216: | ||
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 | 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; | ||
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 220: | Zeile 227: | ||
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. | |||
get hm param [<typefilter>] [-f <nameFilter>] parameter1 parameter2 | get hm param [<typefilter>] [-f <nameFilter>] parameter1 parameter2 | ||
Zeile 233: | Zeile 240: | ||
gibt an, wer mit wem gepeert ist | gibt an, wer mit wem gepeert ist | ||
== Rücksetzen von Variablen | == 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 242: | Zeile 249: | ||
== 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 | 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 256: | Zeile 263: | ||
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 | 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 269: | Zeile 276: | ||
=Attribute= | == Attribute == | ||
* '''configDir''' bietet die Möglichkeit ein | * '''configDir''' bietet die Möglichkeit ein Verzeichnis zu definieren, in welches HMInfo Dateien ablegen und von welchem es die Dateien lesen wird. | ||
* '''configFilename''' legt einen default Namen fest, der bei save und archive genutzt 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''' | * '''autoUpdate''' startet regelmäßig das Komamndo "update". Die Wiederholzeit wird eingestellt mit hh:mm. Sinnvoll erscheint z.B. alle 5 Minuten, also 00:05. | ||
= Quellen = | == Quellen == | ||
* Thread [http://forum.fhem.de/index.php?topic=11035.0 HMinfo] im Fhem Forum | * Thread [http://forum.fhem.de/index.php?topic=11035.0 HMinfo] im Fhem Forum | ||
* Thread [http://forum.fhem.de/index.php/topic,20119.0.html HMINfo, Intention, Sinn und Zweck] im Fhem Forum | * Thread [http://forum.fhem.de/index.php/topic,20119.0.html HMINfo, Intention, Sinn und Zweck] im Fhem Forum |
Version vom 1. August 2014, 11:08 Uhr
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.
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
Befehle, um die Gültigkeit von verschiedenen HomeMatic Eigenschaften zu überprüfen:
Erläuterungen | Definition |
---|---|
Überprüfen, ob alle peerings auch beidseitig sind: | set hm peerCheck
|
Überprüfen, ob alle register korrekt gelesen wurden: | set hm regCheck
|
Kombination von peerCheck und regCheck | set hm configCheck
|
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]
- 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 allen ist hier ein kompletter Überblick zur Kommunikation zu sehen. Insbesondere bei
set hm clear [<filter>] Protocol
setzt die Protokol Einträge aller gemäß Filter zurück. Kann gut vor einer Konfigurationsaktion genutzt werden, um hinterher zu kontrollieren, ob Fehler aufgetreten sind.
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$ <myTempalteFile>
loadConfig
set hm loadConfig [<filter>] [<filename>]
- 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.
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. 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 neben den spezifischen Parametern angeben, für welchen Peer es gelten soll und ob es bei einem kurzen oder langen Tastendruck angewendet werden soll.
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
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.
set hm templateDef <templateName> <param1[:<param2>...] <description> <reg1>:<val1> [<reg2>:<val2>] ... set hm templateDef myTemplate anzeit:auszeit "licht schaltet ständig an und aus" OnTime:anzeit OffTime:auszeit OnDly:0
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.
templateChk
Man kann prüfen, ob ein Aktor/Peer gemäss einem Template programmiert ist.
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
Temperaturlisten
HMInfo bietet verschiedene Methoden, Temperaturlisten für Thermostate (CC-TC, TC-IT oder RT) zu verwalten und zu nutzen. Prinzip ist, dass die Temperaturlisten in einer Konfigurationsdatei abgelegt werden. Der Dateiname ist frei wählbar. Für alle Kommandos können die Filter genutzt werden. Beim Prüfen und Speichern wird davon ausgegangen, dass die Register und Daten in FHEM aktuell sind. Die Funktionen speichern und vergleichen aus Performancegründen nicht direkt im Device sondern die Daten, die FHEM schon gelesen hat. Siehe auch autoReadReg Attribut der HM Komponenten.
Speichern
set hm tempList save <filename>
- Die in FHEM vorhandenen Temperaturlisten aller devices (hier ist kein Filter gesetzt, also alle) werden in die Datei <filename> geschrieben. Man kann dieses als Basis nehmen, um seine Temperaturlisten zu bearbeiten.
Prüfen
set hm tempList verify <filename>
- HMInfo vergleicht die in der Datei abgelegten Temperaturlisten mit den in FHEM vorliegenden. Unterschiede werden gemeldet. Es wird nichts in das Device geschrieben oder verändert.
Restore
set hm tempList restore <filename>
- Es werden alle Temperaturlisten aus der Datei in die dafür eingerichteten Komponenten eingetragen. Dabei werden ausschließlich die Änderungen geschrieben. Liegen keine Unterschiede zwischen Dateiinhalt und aktuellen Daten vor, wird auch nichts geschrieben. Ein mehrfaches anwenden des Kommandos ist also keine Belastung des Systems.
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.
Defaults
Der Default-Dateiname ist tempList.cfg.
Die Datei steht im fhem-root Verzeichnis. Hat man das Attribut configDir gesetzt und gibt kein Verzeichnis an, wird die Datei im spezifizierten Verzeichnis gesucht.
Das default-template ist der Name des Device. Ist im Device das Attribut tempListTmpl gesetzt, wird dies zum Vergleich oder Setzen genutzt.
Aufbau Tempfile
Zum erstmaligen Erstellen einer Datei nutzt man am einfachsten das Kommando tempList save.
entities:HK1,HK2
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
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.
Will man identische Listen für mehrere Komponenten nutzen, schreibt man deren Namen einfach in die Liste der Entities.
Zu Beachten ist, dass nach Ändern der Liste ein erneutes templistSave auf den gleichen Dateinamen die Daten verändern kann. Es ist daher ratsam, den Dateinamen 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.
In der Datei 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
Alle 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
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 einen 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 Feherfall
internal:
ERR_names <devicename1>,<devicename2>
Readings:
ERR_battery low:2
Der default aller Error-meldungen 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, welches 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
- configDir bietet die Möglichkeit ein Verzeichnis zu definieren, in welches HMInfo Dateien ablegen und von welchem es die Dateien lesen wird.
- configFilename legt einen default Namen fest, der bei save und archive genutzt wird.
- 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.
Quellen
- Thread HMinfo im Fhem Forum
- Thread HMINfo, Intention, Sinn und Zweck im Fhem Forum