http://wiki.fhem.de/w/api.php?action=feedcontributions&feedformat=atom&user=Martinp876FHEMWiki - Benutzerbeiträge [de]2026-04-06T12:31:13ZBenutzerbeiträgeMediaWiki 1.43.6http://wiki.fhem.de/w/index.php?title=Apptime&diff=35103Apptime2021-02-28T18:25:25Z<p>Martinp876: rechtschreibb korrektur</p>
<hr />
<div>{{SEITENTITEL:apptime}}<br />
{{Infobox Modul<br />
|ModPurpose=Ausführungszeit von Applikationen (Modulen) protokollieren<br />
|ModType=cmd<br />
|ModCmdRef=apptime<br />
|ModForumArea=Sonstiges<br />
|ModTechName=98_apptime.pm<br />
|ModOwner=Martin/martinp876 ({{Link2FU|251|Forum}}/[[Benutzer Diskussion:Martinp876|Wiki]])<br />
}}<br />
<br />
Mit dem Befehl [[apptime]] wird das Protokollieren von Ausführungszeiten von Modulen und Funktionen gestartet. apptime hilft herauszufinden, WER blockiert; [[perfmon]] ist der Indikator, DASS ETWAS blockiert (siehe diesen {{Link2Forum|Topic=39253|Message=314155}} im Forum).<br />
<br />
== Voraussetzungen ==<br />
Keine.<br />
<br />
== Anwendung ==<br />
=== Aktivieren ===<br />
Die Überwachung der Ausführungszeiten wird mit dem Befehl ''apptime'' (einzugeben in das [[Konfiguration|Befehlseingabefeld]]) gestartet.<br />
<br />
=== Beenden ===<br />
Um ''apptime'' zu beenden, muss FHEM neu gestartet werden.<br />
<br />
Die aufgelaufenen protokollierten Werte können mit dem Befehl <br />
:<code>apptime clear</code><br />
zurückgesetzt werden.<br />
<br />
=== Auswertung ===<br />
Die von ''apptime'' protokollierten Informationen können durch Eingabe des Befehls<br />
:<code>apptime</code><br />
abgerufen werden. Ein (Beispiel!) Auszug aus der resultierenden Tabelle:<br />
<pre><br />
name function max count total average maxDly <br />
myJee JeeLink_Read 139 20 298 14.90 0 HASH(myJee) <br />
myCUL CUL_Read 76 6 233 38.83 0 HASH(myCUL) <br />
...<br />
</pre><br />
Die Felder haben folgende Bedeutung:<br />
<br />
<pre><br />
name: Entity, für die es ausgeführt wird<br />
Wenn 'tmr-' vor dem Namen steht ist es durch einen Timer (InternalTimer) aufgerufen worden. <br />
function: Name der Funktion, die ausgeführt wird<br />
param max call: Input-Parameter an die Funktion beim längsten Aufruf<br />
max: maximale Laufzeit in ms<br />
count: Anzahl der Aufrufe<br />
total: akkumulierte Laufzeit der Funktion in ms<br />
average: durchschnittliche Laufzeit (total/count) in ms. <br />
</pre><br />
<br />
<br />
<br />
{{Randnotiz|RNTyp=y|RNText=Bitte beachten: der Parameter für die Sortierung nach Spalte ''function'' lautet ''fun'''k'''tion''!}}<br />
Durch Angabe eines Parameters <br />
:<code>apptime [count|function|average|max|name|total]</code><br />
wird die Tabelle nach den Werten der entsprechenden Spalte sortiert.<br />
<br />
Soll die komplette Tabelle ausgegeben werden, muss zusätzlich zum Spaltennamen noch der Parameter ''all'' angegeben werden (z.B.):<br />
:<code>apptime count all</code><br />
<br />
== Anwendungsbeispiele ==<br />
<br />
== Links ==<br />
* ...</div>Martinp876http://wiki.fhem.de/w/index.php?title=HomeMatic_Templates&diff=31776HomeMatic Templates2019-12-01T13:22:00Z<p>Martinp876: /* Template aus Device */</p>
<hr />
<div>{{Infobox Modul<br />
|ModPurpose=templates bedienen und verwalten<br />
|ModType=h<br />
|ModCmdRef=HMtemplate<br />
|ModForumArea=HomeMatic<br />
|ModTechName=98_HMtemplate.pm<br />
|ModOwner=martinp876 ({{Link2FU|251|martinp876}} / [[Benutzer Diskussion:Martinp876|Wiki]])<br />
}}<br />
Templates sind Vorlagen im Allgemeinen. Hier werden Vorlagen zur Programmierung der Register von HM Devices behandelt. <br />
= Warum Templates =<br />
Templates sind ein Weg, die Register der HM RF Devices zu setzen, zu kontrollieren und zu replizieren. <br />
Warum braucht man nun Templates? Register lassen sich doch einfach ohne Templates setzen. Warum sich damit befassen?<br />
Nun, die Gründe sind vielfältig - und eigentlich unabdingbar für alle, die ein geordnetes System verwalten wollen. <br />
;Register ohne Template - Schwachstellen<br />
:Register werden, wie bekannt, remanent in den HM-Devices gespeichert. FHEM hat eine Kopie dieser Daten welche über getConfig aufgefrischt werden können. Setzt man nun in einem Device ein Register ist dies erst einmal erledigt. Nun kann sich das Register verändern bzw muss überprüft werden, wenn <br />
* das Device ausgetauscht wird<br />
* das Device reseted wird - kommt auch einmal vor<br />
* ein FW bug oder ein HW Defekt vorliegt<br />
* das Schreiben der Registerwerte nicht erfolgreich war<br />
:Weiter ist es praktisch die gewünschten Settings, also das eingestellte Verhalten <br />
* zu verifizieren<br />
* zu kopieren<br />
:ohne sich einzelne Registerzu merken oder wieder herzuleiten. <br />
<br />
Anzumerken ist, dass die Nutzung von Templates das Bedienen der Register nicht abschaltet oder übersteuert sondern nur ergänzt. <br />
<br />
Templates heben das Bedienen der Register von der Assembler ebene auf eine Hochsprachen-Ebene. Nicht ohne Grund ist die erste Bedienung der Register in der eq3-CCU quasi per Template. Register werden nur im Expert mode sichtbar. <br />
<br />
= Was bieten Templates =<br />
Wie schon im Einsteigerdoc beschrieben hat ein HM Device remanente Register, welche von FHEM gesetzt werden können und die Funktions- und Arbeitsweise definieren. FHEM selbst hat bestenfalls eine Kopie dieser Daten.<br />
<br />
;soll-Register Verwaltung<br />
:Da FHEM nur eine Kopie der ist-Registerwerte verwaltet lebt man erst grundsätzlich in einer fragilen Welt. Eine Soll-Wert Verwaltung der Register bietet nur in Templates. <br />
;Funktionen für Einsteiger<br />
:Nicht-Experten sollten primär Templates nutzen - um Funktionen zu realisieren. Der Anwender holt sich ein Template und kopiert es in sein System. Nun kann er<br />
* die Funktion nutzen. Es muss die Register nicht verstehen<br />
* Die Funktion nutzen, testen und die Register evaluieren und daran zu lernen<br />
* Die Funktion erweitern, modifizieren und an seine Bedürfnisse anpassen<br />
;Verwalten von Funktionen statt Registern<br />
:Als Experten kann man evtl. Register zeilsicher setzen. Wirklich? Wenn man sich eine clevere Lösung ausgedacht hat und sie reproduzieren will kann man einfach noch einmal nachdenken, nachlesen, ... und schon hat man es wieder. Oder man hat ein Template definiert das man einfach nutzt und repliziert.<br />
;Lernen aus Templates<br />
:Templates sind nicht verschlüsselt. Hat oder bekommt man ein Template kann man die dort gesetzten Register einfach einsehen - und wenn man will verstehen was gemacht wurde.<br />
;Globales Anpassen aller Devices<br />
:Hat man festgestellt, dass eine Funktion sub-optimal ist kann man das Template ändern und diese Änderungen allen Devices zu Gute kommen lassen. Auf einmal.<br />
;Funktionen parametrieren<br />
:Der Anwender hat typisch den Wunsch, eine Funktion zu relaisieren, aber einen Parameter will er bei jeder Anwendung anpassen. So will ich typischerweise, dass nach einem ON-Trigger immer eine automatische Abschaltung eingestellt wird, was das Vergessen des Ausschaltes verhindern soll. Die Anschaltzeit ist aber im Wohnzimmer eher 6h, im Treppenhaus aber 2h und bei einem Bewegungsmelder 10min. <br />
:Hier kann man nun immer das gleiche Template nutzen. Die Abschaltzeit wird separat eingestellt und ist per Kommando modifizierbar. Weiter ist sie in den Readings sichtbar.<br />
;Anwendungsbeispiel Lichtschalter<br />
:Grundsätzlich sind Lichtschalter erst einmal einfach: An/Aus Was kann man schon "templaten"?<br />
:Ich habe diverse Lichter und einige zugehörige Schalter. Da meine Fernbedienungen nur eine endliche Anzahl Knöpfe haben muss ich mir ein Konzept überlegen. Nutzen kann ich bei einem Wippschalter 2 Buttons (Knöpfe) und unterscheide bei jedem langer oder kurzer Druck. Bei Schaltern benötige ich demnach Templates für On, Off, Toggle. Nun kann ich jeder Paarung Aktor/Sensor und hier Long/Short eine Funktion zuweisen. <br />
:Nun nutze ich Buttons um bei pressLong das Licht 1 zu toggeln, bei PressShort toggelt es Licht 2. <br />
:Was programmiert ist kann man in HmInfo ermitteln über <br />
*get hm peerUsg<br />
:Wie das erstellt wird, wird weiter unten erklärt<br />
<br />
= Grundsätzliches zum Template =<br />
Templates (hier) ist nun also eine Sammlung von Registern welche in einem Device gesetzt werden können. <br />
<br />
== Template Granularität ==<br />
Man kann nicht alle Register eines Device in einem Template abbilden. Das wäre technisch komplex und macht auch von der Anwendung her keinen Sinn. <br />
<br />
*Aus Sicht der Funktion sollte man Templates nach deren Funktionen zusammenfassen.<br />
*Aus Sicht des Devices sollte man Templates nach der Struktur des Device zusammenstellen.<br />
*Die Implementierung erlaubt es, Templates für jedes Register einzeln zu erstellen.<br><br />
*Weniger Templates erhöhen die Übersichtlichkeit<br />
Die technische Lösung legt folgende Templates nahe:<br />
#Alle Register eines Kanals oder Device - ausgenommen peer abhängige Register<br />
#Alle Register eines Kanals eines Peers für short oder long<br />
#Alle Register eines Kanals eines Peers nur für short<br />
#Alle Register eines Kanals eines Peers nur für long<br />
Ob man 2. oder die Kombination aus 3. und 4. nutzt ist Geschmackssache. <br><br />
Ein typischer Einsatz sind Schalter und Dimmer bei denen man die Aktionen der Peers festlegen will.<br />
;usecase Template Granularität Dimmer<br />
:Mit Peer1 soll bei short ein und bei long ausgeschaltet werden<br />
:Mit Peer2 soll bei short getoggelt und bei long nicht geschaltet werden<br />
:Mit Peer3 soll bei short nicht geschaltet und bei long getoggelt werden<br />
:Mit Peer4 ist ein MotionDetector welcher bei short und einer bestimmten Helligkeit einschaltet, timed. Allerdings sollen Aktionen der anderen Peers oder der Zentrale das Licht dauer-ein schalten.<br />
<br />
== Template Flexibilität ==<br />
Templates sind starr... und können parametriert werden. Also semistarr. Was jetzt? Nun man kann Templates mir bis zu 9 Parametern versehen. Sinnvoll sind wohl eher bis zu 3. <br><br />
Beispiele sind:<br />
*Treppenhausschaltern - mit einem Parameter kann man Einschaltdauer je Instanziierung festlegen. Sinnvoll könnte eine Treppenhausschaltung generell sein, nicht nur im Treppenhaus. Man kann generell alle Lichter nach ein paar Stunden ausschalten.<br />
*Heizungstemplate - Boosttime: Man kann allen RTs das gleiche Template geben - allerdings kann man z.B. die Boosttime indivituell einstellen. <br />
*MotionDetector Clients: Bei den Peers des Motiondetector (also den Schaltern) stellt man ein, wann diese reagieren sollen und wie lange diese brennen sollen. <br />
<br />
== Template Verwaltung==<br />
Templates werden zusammen mit Registern verwaltet. Man benötigt demnach HMinfo. Sowohl die Templatedefinition als auch die Templatezuweisung werden im File zusammen mit den gelesenen Registern gesichert. Nach einem Einlesen dieses Files werden auch die Templates und deren Zuordnung neu erstellt.<br />
<br />
== Template Editieren==<br />
Die aktuell einfachste Möglichkeit ein Template zu modifizieren ist, HMtemplate zu nutzen. HMtemplate ist ein Editor. Für den Betrieb wird es nicht genutzt. <br />
<br />
<br />
=Das eigenen Konzept=<br />
Für die Verknüpfung von HM Entities muss man 2 Ebenen unterschieden, Architektur und Verhalten.<br />
==Architektur==<br />
Beim Erstellen der Architektur legt man fest, welche Entities untereinander verknüpft werden. Dies geschieht durch peeren. Templates unterstützen nicht die Architektur. Es ist demnach notwendig die Peerings durchzuführen bevor an ein Template darauf anwenden kann. <br />
==Verhalten==<br />
Hier kommen die Templates zum Tragen. Mit Templates definiert man die Register der Entities und somit das Verhalten und die Reaktion der Entites bspw auf Trigger von Sensoren.<br />
===Welchen templateTyp brauche ich===<br />
Wie in Granularität beschrieben kann man insbesondere beim Peerverhalten templates für ''short'', ''long'' oder ''both'' ertellen. Nutzt man short/long braucht man weniger Templates (Basics sind on/off/ignore/toggle) muss allerdings mehr Templates zuweisen, als Reaktion auf short UND long.<br><br />
Bei both braucht man mehr Templates (OnOff/OnIgnore/OffIgnore/IgnoreOff/ToggleIgnore/...) braucht aber nur die Hälfte der Zuweisungen zu den realen Entities. <br />
<br />
===Welche Parameter muss ich einstellen===<br />
Bei der Erstellung eine Templates werden dessen Parameter durch Attribute vorgegeben. Durch '''set save''' wird dann das Template schlussendlich definiert. Folgende Parameter/Attribute werden genutzt:<br />
*'''tpl_description''': ist ein Freitext welcher beschreiben soll, was das Template macht und wie es parametriert wird<br />
*'''tpl_params''': hier werden evtl Parameter definiert mit welchen die Instanziierung des Templates angepasst werden kann. Bspw. könnte die Einschaltzeit variable gestalltet werden. Bei einem Dimmer könnt man den Level und die Rampe eingeben, also 2 Parameter. Man vergibt also, ":" getrennt, eine Liste von Paramtern. Die Namen sind frei wählbar. <br><br />
:''timeOn:ramp'' würde 2 Parameter definieren, welche später in den Registern genutzt werden können<br />
*'''tpl_type''': definiert den Typ. Diesen muss man zuerst festlegen. Es konnte ''peer-Short'',''peer-Long'',''peer-Both'' oder ''basic'' sein. Nach der Auswahl des Typs kann man die Entity (source) wählen. Es alle Entities angeboten, welche entsprechende Registersätze zu Verfügung stellen.<br />
*'''tpl_source''': legt bei der Definition eines Templates fest, von welcher Entity die Register für die Vorlage genutzt werden sollen. Ein Browser-Refresh könnte notwendig sein um die Auswahlliste upzudaten<br />
*'''tpl_peer''': muss man auswählen, so man einen "peer" typ gewählt hat. An Browser-refresh denken. <br />
*'''Reg_xxx''': An Browser-refresh denken. Hat man nun die Vorlage ausgewählt und den Refresh gemach werden nun Register als Attribute angeboten. <br><br />
:Zunächst sollte man Registerattribute löschen, welche man für das Template nicht benötigt. Achtung: eine Option gelöschte Registerattribute wieder nachzutragen ist nicht vorgesehen. So schlimm ist es allerdings nicht - man muss halt noch einmal alle Lesen und von Vorne löschen. <br><br />
:Sinnvoll kann es sein, die Condition Table Register komplett zu eliminieren wenn man Reaktionen auf Taster definieren will. Will man ''ignore'' definieren, also keine Reaktion bspw auf ''long'', dann kann man alles löschen bis auf ActionType usw. <br><br />
:Sinnvoll ist es, nur notwendige Register der Funktion zu bearbeiten, da sonst die Anwendung des Templates eingeschränkt wird. <br><br />
:Es sollten aber alle Register der Funktion enthalten sein, da die Prüfung auch nur diese berücksichtigt und bei einem Umprogrammieren nicht klar ist, was vorher in einem Register gestanden ist.<br />
===Register Werte setzen===<br />
Nun das eigentliche - das setzen der Registerinhalte. Dies wird begrenzt unterstützt. Sollte das Register durch ''literals'' definiert werden erscheint beim Setzen eine drop-down Liste mit den Optionen. <br><br />
Nicht unterstützt wird das Setzen von Werten. Es gibt aktuell keine Option, hier eine Hilfe einzublenden. Die Wertebereiche sind dem regList der Entity zu entnehmen. <br><br />
Eine weitere Besonderheit ist die Granularität der Werte. Insbesondere durch das Float Format einiger Werte sind nicht alle Werte möglich. Trägt man bspw eine Ontime von 10000 ein wird dies erst einmal akzeptiert. Allerdings wird der Wert beim Schreiben umgerechnet in den nächstmöglichen (welcher 9600 ist). Bei der Prüfung der Template Anwendung wird der Unterschied angemerkt. Am Einfachsten wird nun das Template angepasst und alles ist gut.<br><br />
<br><br />
Nun tpl_params. Diese muss man anstelle des Registerwerts einsetzen. Hat man bspw <br><br />
tpl_params timeOn:rampTime<br><br />
definiert setzt man in das Register ''OnTime'' den Wert ''timeOn'' ein. Und eben das Rampenregiste den Wert ''rampTime''. Der Wert wird dann beim Template Instanziieren - also Anwenden - durch den Individuellen ersetzt.<br />
<br />
=Getting started=<br />
Was muss man also tun? Wenn man noch nichts eingerichtet hat:<br />
define hm HMinfo<br />
attr hm autoArchive 1<br />
attr hm autoLoadArchive 1_load<br />
attr hm configFilename regConfig.cfg<br />
define ht HMtemplate<br />
<br />
==Template erstellen und bearbeiten==<br />
Templates kann man erstellen, in dem man die Register einer Entity nimmt und bearbeitet. Auch das Kopieren und Bearbeiten eines vorhandenen Templates ist möglich. Und man kann Templates exportieren/importieren.<br />
===Template aus vorhandener Programmierung erstellen===<br />
Aufgabe ist es, aus einem existierenden, programmierten Device ein Template zu erstellen. Wir haben <br />
*device ''myDev''<br />
*Channel ''myChan''<br />
*Channel gepeert mit ''myChanPeer''<br />
Der Kanal ist ein Schalter und wir wollen einen Parameter im Template nutzen um die Anschaltzeit variabel zu steuern. Wir werden also den Parameter ''timeOn'' nutzen. Das Template soll ''my1stTmpl'' genannt werden. Weiter soll das gesamte Verhalten des ''myChanPeer'' definiert werden, also short UND long. <br />
set ht define my1stTmpl<br />
attr ht tpl_param timeOn # name des Parameters - hier nur einer<br />
attr ht tpl_description "mein erstes Template"<br />
attr ht tpl_type peer-both<br />
<refresh browser> # select liste der attribute wird neu eingelesen<br />
attr ht tpl_source myChan<br />
<refresh browser> # select liste der attribute wird neu eingelesen<br />
attr ht tpl_peer myChanPeer<br />
<refresh browser> # select liste der attribute wird neu eingelesen<br />
attr ht Reg_shOnTime timeOn # setzen des parameters<br />
<br />
bei Bedarf können weitere Register verändert werde. <br><br />
Nun sind wir fertig. Möglich, aber nicht notwendig ist es, unnötige Register aus dem Template zu entfernen. Dies sind in diesem Fall bspw. alle Ct register. Das Attribut des Registers wird einfach gelöscht. <br />
set ht save<br />
set ht dismiss<br />
<br />
===Template Varianten speichern===<br />
Ist man beim Erstellen von Templates kann man mti saveAs das Template als neues unter einem anderen Namen sichern. <br />
===Template editieren===<br />
Mit Edit kann man die Werte der Register ändern oder vorhandene Register aus dem Template entfernen. Ein Hinzufügen von Registern wird nicht unterstützt. Hier fehlt die Referenz um anzubieten, was möglich ist.<br />
===Template kopieren===<br />
Dies wird ebenfalls mit edit erreicht. Das Template wird mit saveAs unter einem neuen Namen gespeichert.<br />
===Template export-import===<br />
Will man Templates exportieren nutzt man <br><br />
get ht <templatename><br />
Es wird ein kommando ausgegeben welches man in die Kommandozeile pasten kann, was dann der import ist.<br><br />
Dies kann man nutzen um Templates zu tauschen. Hat man ein ''gutes oder komplexes'' Template kann man dies der Allgemeinheit zu Verfügung stellen.<br><br />
Im besten Fall muss der User sich nicht mehr um Register kümmern, da komfortable Templates das besser abdecken.<br />
<br />
==Template einem Kanal zuweisen==<br />
Jetzt haben wir ein Template welches long UND short eines Kanals kontrollieren soll. Dies wollen wir jetzt anwenden auf unsere Kanal/Peer Kompinationen "sw1/peer1", "sw1/peer2", "sw2/peer1" und "sw2/peer3". Für alle benötigen wir unterschiedliche Abschaltzeiten (warum? eure Sache). <br />
set ht select my1stTmpl<br />
attr ht entity sw1<br />
<refresh browser><br />
attr ht ePeer peer1<br />
attr ht tpl_param_timeOn 30<br />
set ht apply<br />
attr ht ePeer peer2<br />
attr ht tpl_param_timeOn 180<br />
set ht apply<br />
<br />
attr ht entity sw2<br />
<refresh browser><br />
attr ht ePeer peer1<br />
attr ht tpl_param_timeOn 70<br />
set ht apply<br />
<br />
attr ht ePeer peer3<br />
attr ht tpl_param_timeOn 1000<br />
set ht apply<br />
<br />
set ht dismiss<br />
Die Register der Entities werden passend in das Device geschrieben.<br />
<br />
==Template editieren==<br />
Nun soll das Template grundsätzlich modfiziert werden. <br />
<br />
set ht edit my1stTmpl<br />
attr ht Reg_<name> <value><br />
attr ht Reg_<name2> <value2><br />
attr ht Reg_<name3> <value3><br />
set ht save<br />
==Template kopieren und editieren==<br />
Nun soll das Template grundsätzlich modfiziert werden. <br />
<br />
set ht select my1stTmpl<br />
attr ht Reg_<name> <value><br />
attr ht Reg_<name2> <value2><br />
attr ht Reg_<name3> <value3><br />
set ht saveAs my2ndTmpl<br />
==Template weitergeben==<br />
Will man Templates weitergeben geht das mit<br />
get ht my1stTmpl<br />
Das Kommando kann dann direkt in die Kommandozeile kopiert werden und das Template ist definiert.<br />
=Verwaltung und Überblick=<br />
Nun hat man Templates definiert und Instanziiert. Wie soll man den Überblick behalten? HMtemplate ist ein Editor - also nicht wirklich hierfür geeignet. HMinfo macht die Verwaltung. <br />
==Template Überblick==<br />
Will man sehen, was man so an Templates nutzt kann man eine Überscht unterschedliche sortiert ausgeben lassen - in HMinfo (hm).<br />
get hm templateUsgG sortTemplate<br />
get hm templateUsgG sortPeer<br />
get hm templateUsgG all<br />
Sowie eine Liste von Regiserlisten, welche noch kein Template nutzen (noch in Bau!!)<br />
get hm templateUsgG noTmpl<br />
Eine Liste der Verfügbaren Templates erhält man mit <br />
get hm templateList all<br />
und die Register eines Templates mit <br />
get hm templateList <templateName><br />
oder<br />
set ht select <templateName><br />
==Template prüfen==<br />
Templates werden auf korrekte Implementierung in der Entity anhand eines Vergleichs der gelesenen Registern mit den gewünschten Regitern geprüft. Es ist also notwendig, dass die Registerwerte in der FHEM Kopie aktuell sind. Dann reicht ein <br />
get hm configCheck<br />
Sollte es zu Unstimmigkeiten kommen werden mit <br />
set hm templateExe<br />
alle Unstimmigkeiten überschrieben. Klar, wie immer, muss FHEM warten, bis ein Device angesprochen werden kann (Übertragungsmode) und dass die IOs nicht überlastet werden. Die Gefahr einer Überlast ist gering wenn man nicht gleich alles überschreiben will. <br><br />
Wie immer ist es hilfreich den Status der Übertragung im Blick zu haben:<br />
get hm protoEvents<br />
Wenn zu viel passiert ist und man protoEvents aufräumen muss dann (Achtung: es werden alle ausstehenden Kommandos gelöscht und müssen neu aktiviert werden!)<br />
set hm clearG msgEvents<br />
==Template löschen==<br />
set ht delete <tempateName><br />
Achtung: vorher müssen alle Referenzen des Templates entfernt worden sein. <br />
<br />
=Templates in den Entites=<br />
Ist eine Entity mit einem Template verknüpft wird dies in den Readings angezeigt. Dies kann man sichtbar machen - und eine Anzeige von Registern in den Readings sollte dann nicht mehr notwendig sein. Empfohlen wird, den expoer mode auf rein Templates umzustellen<br />
attr TYPE=CUL_HM:FILTER=DEF=......:FILTER=subType!=virtual expert 12_templOnly<br />
deleteattr TYPE=CUL_HM:FILTER=DEF=........ expert<br />
deleteattr TYPE=CUL_HM:FILTER=subType=virtual expert<br />
<br />
=Beispiele und Ideen=<br />
<br />
Neben den typischen Templates für Schalter kann (sollte) man auch bspw für RTs einsetzen. Temperaturlisten sind nicht im Angebot. Hier gibt es bereits andere Verfahren die besser passen. Allerdings experimentire ich bei meinen RTs mit den Regelparametern und will diese dann generell setzen. Alle RTs (bei mir) sollen die gleiche Regelung haben. Ich nutze 3 Templates für meine RTs<br />
* '''HeatDefDev''': Das Device des RT wird auf Standartwerte gesetzt. Hier nutze ich einen Parameter um die Tasten zu sperren. Dies brauche ich nicht bei allen RTs sondern nur bei denen, welche ich mit einem TC gepeert habe. Hier ist eine Lokale Änderung am TC vorzunehmen. <br />
* '''HeatDefault''':Die Standart-Regelung. Auch hier habe ich Parameter vorgesehen. Die Devices sind identisch... bis auf die Boostzeit und die maximals Ventilöffnung. Je nach Hk begrenze ich ValveMax - hängt von den baulichen Gegebenheiten ab. Boost nutze ich im Bad zum entfeuchten.<br />
* '''HeatRemote''': mein ''guteNacht'' Knopf macht auch vor RTs nicht halt. Ich haben an einer Remote einen Button mit allen Lichtern und RTs im Wohnbereich gekoppelt. Beim Drücken wird das Licht abgeschaltet und dieHeizung gedrosselt - bspw wenn ich als letzter ins Bett gehe. Daher brauche ich einen Parameter ''Temperatur'' um das induviduell je RT einzustellen. <br />
set hm templateDef HeatDefDev BtnLock "Default RT Device register" globalBtnLock:off localResDis:off modusBtnLock:off backOnTime:10 cyclicInfoMsg:on lowBatLimitRT:2.1 burstRx:on cyclicInfoMsgDis:0 btnLock:p0<br />
set hm templateDef HeatDefault boost:valveMax "myDefault RT settings, enter boostTime and valveMax" regAdaptive:offDeter reguIntI:20 nightTemp:17 tempOffset:0.0K dayTemp:21 reguIntPstart:5 reguExtI:20 showWeekday:off reguExtP:25 reguIntP:25 tempMax:30.5 tempMin:4.5 valveMaxPos:p1 valveOffsetRt:0 modePrioManu:all daylightSaveTime:on boostPos:30 decalcWeekday:Sat showInfo:time decalcTime:11:00 btnNoBckLight:off reguExtPstart:5 noMinMax4Manu:off modePrioParty:all valveErrPos:15 boostPeriod:p0<br />
set hm templateDef HeatRemote temp "heatRemote set temperature" CtrlRc:autoAndTemp TempRC:p0<br />
<br><br />
In der Übersicht für 2 RTs ergibt ein get hm templateUsg<br />
haEss |0 |HeatDefDev|BtnLock:off <br />
haEss_Clima |0 |HeatDefault|boost:5 valveMax:15 <br />
haEss_remote |FB8_1:short |HeatRemote|temp:13 <br />
haEss_remote |FB8_5:long |HeatRemote|temp:13 <br />
haEss_remote |FB8_5:short |HeatRemote|temp:19 <br />
haLnge |0 |HeatDefDev|BtnLock:off <br />
haLnge_Clima |0 |HeatDefault|boost:5 valveMax:15 <br />
haLnge_remote |FB8_1:short |HeatRemote|temp:13 <br />
haLnge_remote |FB8_5:long |HeatRemote|temp:13 <br />
haLnge_remote |FB8_5:short |HeatRemote|temp:19 <br />
<br />
<br />
<br />
[[Kategorie:HomeMatic supportDevice]]<br />
[[Kategorie:HOWTOS]]</div>Martinp876http://wiki.fhem.de/w/index.php?title=HomeMatic_Templates&diff=31775HomeMatic Templates2019-12-01T13:14:17Z<p>Martinp876: /* Was bieten Templates */</p>
<hr />
<div>{{Infobox Modul<br />
|ModPurpose=templates bedienen und verwalten<br />
|ModType=h<br />
|ModCmdRef=HMtemplate<br />
|ModForumArea=HomeMatic<br />
|ModTechName=98_HMtemplate.pm<br />
|ModOwner=martinp876 ({{Link2FU|251|martinp876}} / [[Benutzer Diskussion:Martinp876|Wiki]])<br />
}}<br />
Templates sind Vorlagen im Allgemeinen. Hier werden Vorlagen zur Programmierung der Register von HM Devices behandelt. <br />
= Warum Templates =<br />
Templates sind ein Weg, die Register der HM RF Devices zu setzen, zu kontrollieren und zu replizieren. <br />
Warum braucht man nun Templates? Register lassen sich doch einfach ohne Templates setzen. Warum sich damit befassen?<br />
Nun, die Gründe sind vielfältig - und eigentlich unabdingbar für alle, die ein geordnetes System verwalten wollen. <br />
;Register ohne Template - Schwachstellen<br />
:Register werden, wie bekannt, remanent in den HM-Devices gespeichert. FHEM hat eine Kopie dieser Daten welche über getConfig aufgefrischt werden können. Setzt man nun in einem Device ein Register ist dies erst einmal erledigt. Nun kann sich das Register verändern bzw muss überprüft werden, wenn <br />
* das Device ausgetauscht wird<br />
* das Device reseted wird - kommt auch einmal vor<br />
* ein FW bug oder ein HW Defekt vorliegt<br />
* das Schreiben der Registerwerte nicht erfolgreich war<br />
:Weiter ist es praktisch die gewünschten Settings, also das eingestellte Verhalten <br />
* zu verifizieren<br />
* zu kopieren<br />
:ohne sich einzelne Registerzu merken oder wieder herzuleiten. <br />
<br />
Anzumerken ist, dass die Nutzung von Templates das Bedienen der Register nicht abschaltet oder übersteuert sondern nur ergänzt. <br />
<br />
Templates heben das Bedienen der Register von der Assembler ebene auf eine Hochsprachen-Ebene. Nicht ohne Grund ist die erste Bedienung der Register in der eq3-CCU quasi per Template. Register werden nur im Expert mode sichtbar. <br />
<br />
= Was bieten Templates =<br />
Wie schon im Einsteigerdoc beschrieben hat ein HM Device remanente Register, welche von FHEM gesetzt werden können und die Funktions- und Arbeitsweise definieren. FHEM selbst hat bestenfalls eine Kopie dieser Daten.<br />
<br />
;soll-Register Verwaltung<br />
:Da FHEM nur eine Kopie der ist-Registerwerte verwaltet lebt man erst grundsätzlich in einer fragilen Welt. Eine Soll-Wert Verwaltung der Register bietet nur in Templates. <br />
;Funktionen für Einsteiger<br />
:Nicht-Experten sollten primär Templates nutzen - um Funktionen zu realisieren. Der Anwender holt sich ein Template und kopiert es in sein System. Nun kann er<br />
* die Funktion nutzen. Es muss die Register nicht verstehen<br />
* Die Funktion nutzen, testen und die Register evaluieren und daran zu lernen<br />
* Die Funktion erweitern, modifizieren und an seine Bedürfnisse anpassen<br />
;Verwalten von Funktionen statt Registern<br />
:Als Experten kann man evtl. Register zeilsicher setzen. Wirklich? Wenn man sich eine clevere Lösung ausgedacht hat und sie reproduzieren will kann man einfach noch einmal nachdenken, nachlesen, ... und schon hat man es wieder. Oder man hat ein Template definiert das man einfach nutzt und repliziert.<br />
;Lernen aus Templates<br />
:Templates sind nicht verschlüsselt. Hat oder bekommt man ein Template kann man die dort gesetzten Register einfach einsehen - und wenn man will verstehen was gemacht wurde.<br />
;Globales Anpassen aller Devices<br />
:Hat man festgestellt, dass eine Funktion sub-optimal ist kann man das Template ändern und diese Änderungen allen Devices zu Gute kommen lassen. Auf einmal.<br />
;Funktionen parametrieren<br />
:Der Anwender hat typisch den Wunsch, eine Funktion zu relaisieren, aber einen Parameter will er bei jeder Anwendung anpassen. So will ich typischerweise, dass nach einem ON-Trigger immer eine automatische Abschaltung eingestellt wird, was das Vergessen des Ausschaltes verhindern soll. Die Anschaltzeit ist aber im Wohnzimmer eher 6h, im Treppenhaus aber 2h und bei einem Bewegungsmelder 10min. <br />
:Hier kann man nun immer das gleiche Template nutzen. Die Abschaltzeit wird separat eingestellt und ist per Kommando modifizierbar. Weiter ist sie in den Readings sichtbar.<br />
;Anwendungsbeispiel Lichtschalter<br />
:Grundsätzlich sind Lichtschalter erst einmal einfach: An/Aus Was kann man schon "templaten"?<br />
:Ich habe diverse Lichter und einige zugehörige Schalter. Da meine Fernbedienungen nur eine endliche Anzahl Knöpfe haben muss ich mir ein Konzept überlegen. Nutzen kann ich bei einem Wippschalter 2 Buttons (Knöpfe) und unterscheide bei jedem langer oder kurzer Druck. Bei Schaltern benötige ich demnach Templates für On, Off, Toggle. Nun kann ich jeder Paarung Aktor/Sensor und hier Long/Short eine Funktion zuweisen. <br />
:Nun nutze ich Buttons um bei pressLong das Licht 1 zu toggeln, bei PressShort toggelt es Licht 2. <br />
:Was programmiert ist kann man in HmInfo ermitteln über <br />
*get hm peerUsg<br />
:Wie das erstellt wird, wird weiter unten erklärt<br />
<br />
= Grundsätzliches zum Template =<br />
Templates (hier) ist nun also eine Sammlung von Registern welche in einem Device gesetzt werden können. <br />
<br />
== Template Granularität ==<br />
Man kann nicht alle Register eines Device in einem Template abbilden. Das wäre technisch komplex und macht auch von der Anwendung her keinen Sinn. <br />
<br />
*Aus Sicht der Funktion sollte man Templates nach deren Funktionen zusammenfassen.<br />
*Aus Sicht des Devices sollte man Templates nach der Struktur des Device zusammenstellen.<br />
*Die Implementierung erlaubt es, Templates für jedes Register einzeln zu erstellen.<br><br />
*Weniger Templates erhöhen die Übersichtlichkeit<br />
Die technische Lösung legt folgende Templates nahe:<br />
#Alle Register eines Kanals oder Device - ausgenommen peer abhängige Register<br />
#Alle Register eines Kanals eines Peers für short oder long<br />
#Alle Register eines Kanals eines Peers nur für short<br />
#Alle Register eines Kanals eines Peers nur für long<br />
Ob man 2. oder die Kombination aus 3. und 4. nutzt ist Geschmackssache. <br><br />
Ein typischer Einsatz sind Schalter und Dimmer bei denen man die Aktionen der Peers festlegen will.<br />
;usecase Template Granularität Dimmer<br />
:Mit Peer1 soll bei short ein und bei long ausgeschaltet werden<br />
:Mit Peer2 soll bei short getoggelt und bei long nicht geschaltet werden<br />
:Mit Peer3 soll bei short nicht geschaltet und bei long getoggelt werden<br />
:Mit Peer4 ist ein MotionDetector welcher bei short und einer bestimmten Helligkeit einschaltet, timed. Allerdings sollen Aktionen der anderen Peers oder der Zentrale das Licht dauer-ein schalten.<br />
<br />
== Template Flexibilität ==<br />
Templates sind starr... und können parametriert werden. Also semistarr. Was jetzt? Nun man kann Templates mir bis zu 9 Parametern versehen. Sinnvoll sind wohl eher bis zu 3. <br><br />
Beispiele sind:<br />
*Treppenhausschaltern - mit einem Parameter kann man Einschaltdauer je Instanziierung festlegen. Sinnvoll könnte eine Treppenhausschaltung generell sein, nicht nur im Treppenhaus. Man kann generell alle Lichter nach ein paar Stunden ausschalten.<br />
*Heizungstemplate - Boosttime: Man kann allen RTs das gleiche Template geben - allerdings kann man z.B. die Boosttime indivituell einstellen. <br />
*MotionDetector Clients: Bei den Peers des Motiondetector (also den Schaltern) stellt man ein, wann diese reagieren sollen und wie lange diese brennen sollen. <br />
<br />
== Template Verwaltung==<br />
Templates werden zusammen mit Registern verwaltet. Man benötigt demnach HMinfo. Sowohl die Templatedefinition als auch die Templatezuweisung werden im File zusammen mit den gelesenen Registern gesichert. Nach einem Einlesen dieses Files werden auch die Templates und deren Zuordnung neu erstellt.<br />
<br />
== Template Editieren==<br />
Die aktuell einfachste Möglichkeit ein Template zu modifizieren ist, HMtemplate zu nutzen. HMtemplate ist ein Editor. Für den Betrieb wird es nicht genutzt. <br />
<br />
<br />
=Das eigenen Konzept=<br />
Für die Verknüpfung von HM Entities muss man 2 Ebenen unterschieden, Architektur und Verhalten.<br />
==Architektur==<br />
Beim Erstellen der Architektur legt man fest, welche Entities untereinander verknüpft werden. Dies geschieht durch peeren. Templates unterstützen nicht die Architektur. Es ist demnach notwendig die Peerings durchzuführen bevor an ein Template darauf anwenden kann. <br />
==Verhalten==<br />
Hier kommen die Templates zum Tragen. Mit Templates definiert man die Register der Entities und somit das Verhalten und die Reaktion der Entites bspw auf Trigger von Sensoren.<br />
===Welchen templateTyp brauche ich===<br />
Wie in Granularität beschrieben kann man insbesondere beim Peerverhalten templates für ''short'', ''long'' oder ''both'' ertellen. Nutzt man short/long braucht man weniger Templates (Basics sind on/off/ignore/toggle) muss allerdings mehr Templates zuweisen, als Reaktion auf short UND long.<br><br />
Bei both braucht man mehr Templates (OnOff/OnIgnore/OffIgnore/IgnoreOff/ToggleIgnore/...) braucht aber nur die Hälfte der Zuweisungen zu den realen Entities. <br />
<br />
===Welche Parameter muss ich einstellen===<br />
Bei der Erstellung eine Templates werden dessen Parameter durch Attribute vorgegeben. Durch '''set save''' wird dann das Template schlussendlich definiert. Folgende Parameter/Attribute werden genutzt:<br />
*'''tpl_description''': ist ein Freitext welcher beschreiben soll, was das Template macht und wie es parametriert wird<br />
*'''tpl_params''': hier werden evtl Parameter definiert mit welchen die Instanziierung des Templates angepasst werden kann. Bspw. könnte die Einschaltzeit variable gestalltet werden. Bei einem Dimmer könnt man den Level und die Rampe eingeben, also 2 Parameter. Man vergibt also, ":" getrennt, eine Liste von Paramtern. Die Namen sind frei wählbar. <br><br />
:''timeOn:ramp'' würde 2 Parameter definieren, welche später in den Registern genutzt werden können<br />
*'''tpl_type''': definiert den Typ. Diesen muss man zuerst festlegen. Es konnte ''peer-Short'',''peer-Long'',''peer-Both'' oder ''basic'' sein. Nach der Auswahl des Typs kann man die Entity (source) wählen. Es alle Entities angeboten, welche entsprechende Registersätze zu Verfügung stellen.<br />
*'''tpl_source''': legt bei der Definition eines Templates fest, von welcher Entity die Register für die Vorlage genutzt werden sollen. Ein Browser-Refresh könnte notwendig sein um die Auswahlliste upzudaten<br />
*'''tpl_peer''': muss man auswählen, so man einen "peer" typ gewählt hat. An Browser-refresh denken. <br />
*'''Reg_xxx''': An Browser-refresh denken. Hat man nun die Vorlage ausgewählt und den Refresh gemach werden nun Register als Attribute angeboten. <br><br />
:Zunächst sollte man Registerattribute löschen, welche man für das Template nicht benötigt. Achtung: eine Option gelöschte Registerattribute wieder nachzutragen ist nicht vorgesehen. So schlimm ist es allerdings nicht - man muss halt noch einmal alle Lesen und von Vorne löschen. <br><br />
:Sinnvoll kann es sein, die Condition Table Register komplett zu eliminieren wenn man Reaktionen auf Taster definieren will. Will man ''ignore'' definieren, also keine Reaktion bspw auf ''long'', dann kann man alles löschen bis auf ActionType usw. <br><br />
:Sinnvoll ist es, nur notwendige Register der Funktion zu bearbeiten, da sonst die Anwendung des Templates eingeschränkt wird. <br><br />
:Es sollten aber alle Register der Funktion enthalten sein, da die Prüfung auch nur diese berücksichtigt und bei einem Umprogrammieren nicht klar ist, was vorher in einem Register gestanden ist.<br />
===Register Werte setzen===<br />
Nun das eigentliche - das setzen der Registerinhalte. Dies wird begrenzt unterstützt. Sollte das Register durch ''literals'' definiert werden erscheint beim Setzen eine drop-down Liste mit den Optionen. <br><br />
Nicht unterstützt wird das Setzen von Werten. Es gibt aktuell keine Option, hier eine Hilfe einzublenden. Die Wertebereiche sind dem regList der Entity zu entnehmen. <br><br />
Eine weitere Besonderheit ist die Granularität der Werte. Insbesondere durch das Float Format einiger Werte sind nicht alle Werte möglich. Trägt man bspw eine Ontime von 10000 ein wird dies erst einmal akzeptiert. Allerdings wird der Wert beim Schreiben umgerechnet in den nächstmöglichen (welcher 9600 ist). Bei der Prüfung der Template Anwendung wird der Unterschied angemerkt. Am Einfachsten wird nun das Template angepasst und alles ist gut.<br><br />
<br><br />
Nun tpl_params. Diese muss man anstelle des Registerwerts einsetzen. Hat man bspw <br><br />
tpl_params timeOn:rampTime<br><br />
definiert setzt man in das Register ''OnTime'' den Wert ''timeOn'' ein. Und eben das Rampenregiste den Wert ''rampTime''. Der Wert wird dann beim Template Instanziieren - also Anwenden - durch den Individuellen ersetzt.<br />
<br />
=Getting started=<br />
Was muss man also tun? Wenn man noch nichts eingerichtet hat:<br />
define hm HMinfo<br />
attr hm autoArchive 1<br />
attr hm autoLoadArchive 1_load<br />
attr hm configFilename regConfig.cfg<br />
define ht HMtemplate<br />
<br />
==Template erstellen und bearbeiten==<br />
Templates kann man erstellen, in dem man die Register einer Entity nimmt und bearbeitet. Auch das Kopieren und Bearbeiten eines vorhandenen Templates ist möglich. Und man kann Templates exportieren/importieren.<br />
===Template aus Device===<br />
Aufgabe ist es, aus einem existierenden Device ein Template zu erstellen. Wir haben <br />
device ''myDev''<br />
Channel ''myChan''<br />
Channel gepeert mit ''myChanPeer''.<br><br />
Der Kanal ist ein Schalter und wir wollen einen Parameter im Template nutzen: Die Anschaltzeit soll bei der Nutzung des Templates variabel eingesetzt werden. Wir werden also den Parameter ''timeOn'' nutzen. Das Template soll ''my1stTmpl'' genannt werden. Weiter soll das gesamte Verhalten des ''myChanPeer'' definiert werden, also short UND long. <br />
set ht define my1stTmpl<br />
attr ht tpl_param timeOn # name des Parameters - hier nur einer<br />
attr ht tpl_description "mein erstes Template"<br />
attr ht tpl_type peer-both<br />
<refresh browser> # select liste der attribute wird neu eingelesen<br />
attr ht tpl_source myChan<br />
<refresh browser> # select liste der attribute wird neu eingelesen<br />
attr ht tpl_peer myChanPeer<br />
<refresh browser> # select liste der attribute wird neu eingelesen<br />
attr ht Reg_shOnTime timeOn # setzen des parameters<br />
<br />
nun können weitere Register verändert werde. <br />
Sinnvoll ist es, unnötige Register aus dem Template zu entfernen. Dies sind in diesem Fall bspw. alle Ct register. Das Attribut des Registers wird einfach gelöscht. <br />
set ht save<br />
set ht dismiss<br />
===Template Varianten speichern===<br />
Ist man beim Erstellen von Templates kann man mti saveAs das Template als neues unter einem anderen Namen sichern. <br />
===Template editieren===<br />
Mit Edit kann man die Werte der Register ändern oder vorhandene Register aus dem Template entfernen. Ein Hinzufügen von Registern wird nicht unterstützt. Hier fehlt die Referenz um anzubieten, was möglich ist.<br />
===Template kopieren===<br />
Dies wird ebenfalls mit edit erreicht. Das Template wird mit saveAs unter einem neuen Namen gespeichert.<br />
===Template export-import===<br />
Will man Templates exportieren nutzt man <br><br />
get ht <templatename><br />
Es wird ein kommando ausgegeben welches man in die Kommandozeile pasten kann, was dann der import ist.<br><br />
Dies kann man nutzen um Templates zu tauschen. Hat man ein ''gutes oder komplexes'' Template kann man dies der Allgemeinheit zu Verfügung stellen.<br><br />
Im besten Fall muss der User sich nicht mehr um Register kümmern, da komfortable Templates das besser abdecken.<br />
<br />
==Template einem Kanal zuweisen==<br />
Jetzt haben wir ein Template welches long UND short eines Kanals kontrollieren soll. Dies wollen wir jetzt anwenden auf unsere Kanal/Peer Kompinationen "sw1/peer1", "sw1/peer2", "sw2/peer1" und "sw2/peer3". Für alle benötigen wir unterschiedliche Abschaltzeiten (warum? eure Sache). <br />
set ht select my1stTmpl<br />
attr ht entity sw1<br />
<refresh browser><br />
attr ht ePeer peer1<br />
attr ht tpl_param_timeOn 30<br />
set ht apply<br />
attr ht ePeer peer2<br />
attr ht tpl_param_timeOn 180<br />
set ht apply<br />
<br />
attr ht entity sw2<br />
<refresh browser><br />
attr ht ePeer peer1<br />
attr ht tpl_param_timeOn 70<br />
set ht apply<br />
<br />
attr ht ePeer peer3<br />
attr ht tpl_param_timeOn 1000<br />
set ht apply<br />
<br />
set ht dismiss<br />
Die Register der Entities werden passend in das Device geschrieben.<br />
<br />
==Template editieren==<br />
Nun soll das Template grundsätzlich modfiziert werden. <br />
<br />
set ht edit my1stTmpl<br />
attr ht Reg_<name> <value><br />
attr ht Reg_<name2> <value2><br />
attr ht Reg_<name3> <value3><br />
set ht save<br />
==Template kopieren und editieren==<br />
Nun soll das Template grundsätzlich modfiziert werden. <br />
<br />
set ht select my1stTmpl<br />
attr ht Reg_<name> <value><br />
attr ht Reg_<name2> <value2><br />
attr ht Reg_<name3> <value3><br />
set ht saveAs my2ndTmpl<br />
==Template weitergeben==<br />
Will man Templates weitergeben geht das mit<br />
get ht my1stTmpl<br />
Das Kommando kann dann direkt in die Kommandozeile kopiert werden und das Template ist definiert.<br />
=Verwaltung und Überblick=<br />
Nun hat man Templates definiert und Instanziiert. Wie soll man den Überblick behalten? HMtemplate ist ein Editor - also nicht wirklich hierfür geeignet. HMinfo macht die Verwaltung. <br />
==Template Überblick==<br />
Will man sehen, was man so an Templates nutzt kann man eine Überscht unterschedliche sortiert ausgeben lassen - in HMinfo (hm).<br />
get hm templateUsgG sortTemplate<br />
get hm templateUsgG sortPeer<br />
get hm templateUsgG all<br />
Sowie eine Liste von Regiserlisten, welche noch kein Template nutzen (noch in Bau!!)<br />
get hm templateUsgG noTmpl<br />
Eine Liste der Verfügbaren Templates erhält man mit <br />
get hm templateList all<br />
und die Register eines Templates mit <br />
get hm templateList <templateName><br />
oder<br />
set ht select <templateName><br />
==Template prüfen==<br />
Templates werden auf korrekte Implementierung in der Entity anhand eines Vergleichs der gelesenen Registern mit den gewünschten Regitern geprüft. Es ist also notwendig, dass die Registerwerte in der FHEM Kopie aktuell sind. Dann reicht ein <br />
get hm configCheck<br />
Sollte es zu Unstimmigkeiten kommen werden mit <br />
set hm templateExe<br />
alle Unstimmigkeiten überschrieben. Klar, wie immer, muss FHEM warten, bis ein Device angesprochen werden kann (Übertragungsmode) und dass die IOs nicht überlastet werden. Die Gefahr einer Überlast ist gering wenn man nicht gleich alles überschreiben will. <br><br />
Wie immer ist es hilfreich den Status der Übertragung im Blick zu haben:<br />
get hm protoEvents<br />
Wenn zu viel passiert ist und man protoEvents aufräumen muss dann (Achtung: es werden alle ausstehenden Kommandos gelöscht und müssen neu aktiviert werden!)<br />
set hm clearG msgEvents<br />
==Template löschen==<br />
set ht delete <tempateName><br />
Achtung: vorher müssen alle Referenzen des Templates entfernt worden sein. <br />
<br />
=Templates in den Entites=<br />
Ist eine Entity mit einem Template verknüpft wird dies in den Readings angezeigt. Dies kann man sichtbar machen - und eine Anzeige von Registern in den Readings sollte dann nicht mehr notwendig sein. Empfohlen wird, den expoer mode auf rein Templates umzustellen<br />
attr TYPE=CUL_HM:FILTER=DEF=......:FILTER=subType!=virtual expert 12_templOnly<br />
deleteattr TYPE=CUL_HM:FILTER=DEF=........ expert<br />
deleteattr TYPE=CUL_HM:FILTER=subType=virtual expert<br />
<br />
=Beispiele und Ideen=<br />
<br />
Neben den typischen Templates für Schalter kann (sollte) man auch bspw für RTs einsetzen. Temperaturlisten sind nicht im Angebot. Hier gibt es bereits andere Verfahren die besser passen. Allerdings experimentire ich bei meinen RTs mit den Regelparametern und will diese dann generell setzen. Alle RTs (bei mir) sollen die gleiche Regelung haben. Ich nutze 3 Templates für meine RTs<br />
* '''HeatDefDev''': Das Device des RT wird auf Standartwerte gesetzt. Hier nutze ich einen Parameter um die Tasten zu sperren. Dies brauche ich nicht bei allen RTs sondern nur bei denen, welche ich mit einem TC gepeert habe. Hier ist eine Lokale Änderung am TC vorzunehmen. <br />
* '''HeatDefault''':Die Standart-Regelung. Auch hier habe ich Parameter vorgesehen. Die Devices sind identisch... bis auf die Boostzeit und die maximals Ventilöffnung. Je nach Hk begrenze ich ValveMax - hängt von den baulichen Gegebenheiten ab. Boost nutze ich im Bad zum entfeuchten.<br />
* '''HeatRemote''': mein ''guteNacht'' Knopf macht auch vor RTs nicht halt. Ich haben an einer Remote einen Button mit allen Lichtern und RTs im Wohnbereich gekoppelt. Beim Drücken wird das Licht abgeschaltet und dieHeizung gedrosselt - bspw wenn ich als letzter ins Bett gehe. Daher brauche ich einen Parameter ''Temperatur'' um das induviduell je RT einzustellen. <br />
set hm templateDef HeatDefDev BtnLock "Default RT Device register" globalBtnLock:off localResDis:off modusBtnLock:off backOnTime:10 cyclicInfoMsg:on lowBatLimitRT:2.1 burstRx:on cyclicInfoMsgDis:0 btnLock:p0<br />
set hm templateDef HeatDefault boost:valveMax "myDefault RT settings, enter boostTime and valveMax" regAdaptive:offDeter reguIntI:20 nightTemp:17 tempOffset:0.0K dayTemp:21 reguIntPstart:5 reguExtI:20 showWeekday:off reguExtP:25 reguIntP:25 tempMax:30.5 tempMin:4.5 valveMaxPos:p1 valveOffsetRt:0 modePrioManu:all daylightSaveTime:on boostPos:30 decalcWeekday:Sat showInfo:time decalcTime:11:00 btnNoBckLight:off reguExtPstart:5 noMinMax4Manu:off modePrioParty:all valveErrPos:15 boostPeriod:p0<br />
set hm templateDef HeatRemote temp "heatRemote set temperature" CtrlRc:autoAndTemp TempRC:p0<br />
<br><br />
In der Übersicht für 2 RTs ergibt ein get hm templateUsg<br />
haEss |0 |HeatDefDev|BtnLock:off <br />
haEss_Clima |0 |HeatDefault|boost:5 valveMax:15 <br />
haEss_remote |FB8_1:short |HeatRemote|temp:13 <br />
haEss_remote |FB8_5:long |HeatRemote|temp:13 <br />
haEss_remote |FB8_5:short |HeatRemote|temp:19 <br />
haLnge |0 |HeatDefDev|BtnLock:off <br />
haLnge_Clima |0 |HeatDefault|boost:5 valveMax:15 <br />
haLnge_remote |FB8_1:short |HeatRemote|temp:13 <br />
haLnge_remote |FB8_5:long |HeatRemote|temp:13 <br />
haLnge_remote |FB8_5:short |HeatRemote|temp:19 <br />
<br />
<br />
<br />
[[Kategorie:HomeMatic supportDevice]]<br />
[[Kategorie:HOWTOS]]</div>Martinp876http://wiki.fhem.de/w/index.php?title=HomeMatic_Templates&diff=31774HomeMatic Templates2019-12-01T13:13:35Z<p>Martinp876: /* Was bieten Templates */</p>
<hr />
<div>{{Infobox Modul<br />
|ModPurpose=templates bedienen und verwalten<br />
|ModType=h<br />
|ModCmdRef=HMtemplate<br />
|ModForumArea=HomeMatic<br />
|ModTechName=98_HMtemplate.pm<br />
|ModOwner=martinp876 ({{Link2FU|251|martinp876}} / [[Benutzer Diskussion:Martinp876|Wiki]])<br />
}}<br />
Templates sind Vorlagen im Allgemeinen. Hier werden Vorlagen zur Programmierung der Register von HM Devices behandelt. <br />
= Warum Templates =<br />
Templates sind ein Weg, die Register der HM RF Devices zu setzen, zu kontrollieren und zu replizieren. <br />
Warum braucht man nun Templates? Register lassen sich doch einfach ohne Templates setzen. Warum sich damit befassen?<br />
Nun, die Gründe sind vielfältig - und eigentlich unabdingbar für alle, die ein geordnetes System verwalten wollen. <br />
;Register ohne Template - Schwachstellen<br />
:Register werden, wie bekannt, remanent in den HM-Devices gespeichert. FHEM hat eine Kopie dieser Daten welche über getConfig aufgefrischt werden können. Setzt man nun in einem Device ein Register ist dies erst einmal erledigt. Nun kann sich das Register verändern bzw muss überprüft werden, wenn <br />
* das Device ausgetauscht wird<br />
* das Device reseted wird - kommt auch einmal vor<br />
* ein FW bug oder ein HW Defekt vorliegt<br />
* das Schreiben der Registerwerte nicht erfolgreich war<br />
:Weiter ist es praktisch die gewünschten Settings, also das eingestellte Verhalten <br />
* zu verifizieren<br />
* zu kopieren<br />
:ohne sich einzelne Registerzu merken oder wieder herzuleiten. <br />
<br />
Anzumerken ist, dass die Nutzung von Templates das Bedienen der Register nicht abschaltet oder übersteuert sondern nur ergänzt. <br />
<br />
Templates heben das Bedienen der Register von der Assembler ebene auf eine Hochsprachen-Ebene. Nicht ohne Grund ist die erste Bedienung der Register in der eq3-CCU quasi per Template. Register werden nur im Expert mode sichtbar. <br />
<br />
= Was bieten Templates =<br />
Wie schon im Einsteigerdoc beschrieben hat ein HM Device remanente Register, welche von FHEM gesetzt werden können und die Funktions- und Arbeitsweise definieren. FHEM selbst hat bestenfalls eine Kopie dieser Daten.<br />
<br />
;soll-Register Verwaltung<br />
:Da FHEM nur eine Kopie der ist-Registerwerte verwaltet lebt man erst grundsätzlich in einer fragilen Welt. Eine Soll-Wert Verwaltung der Register bietet nur in Templates. <br />
;Funktionen für Einsteiger<br />
:Nicht-Experten sollten primär Templates nutzen - um Funktionen zu realisieren. Der Anwender holt sich ein Template und kopiert es in sein System. Nun kann er<br />
* die Funktion nutzen. Es muss die Register nicht verstehen<br />
* Die Funktion nutzen, testen und die Register evaluieren und daran zu lernen<br />
* Die Funktion erweitern, modifizieren und an seine Bedürfnisse anpassen<br />
;Verwalten von Funktionen statt Registern<br />
:Als Experten kann man evtl. Register zeilsicher setzen. Wirklich? Wenn man sich eine clevere Lösung ausgedacht hat und sie reproduzieren will kann man einfach noch einmal nachdenken, nachlesen, ... und schon hat man es wieder. Oder man hat ein Template definiert das man einfach nutzt und repliziert.<br />
;Lernen aus Templates<br />
:Templates sind nicht verschlüsselt. Hat oder bekommt man ein Template kann man die dort gesetzten Register einfach einsehen - und wenn man will verstehen was gemacht wurde.<br />
;Globales Anpassen aller Devices<br />
:Hat man festgestellt, dass eine Funktion sub-optimal ist kann man das Template ändern und diese Änderungen allen Devices zu Gute kommen lassen. Auf einmal.<br />
;Funktionen parametrieren<br />
:Der Anwender hat typisch den Wunsch, eine Funktion zu relaisieren, aber einen Parameter will er bei jeder Anwendung anpassen. So will ich typischerweise, dass nach einem ON-Trigger immer eine automatische Abschaltung eingestellt wird, was das Vergessen des Ausschaltes verhindern soll. Die Anschaltzeit ist aber im Wohnzimmer eher 6h, im Treppenhaus aber 2h und bei einem Bewegungsmelder 10min. <br />
:Hier kann man nun immer das gleiche Template nutzen. Die Abschaltzeit wird separat eingestellt und ist per Kommando modifizierbar. Weiter ist sie in den Readings sichtbar.<br />
;Anwendungsbeispiel Lichtschalter<br />
:Grundsätzlich sind Lichtschalter erst einmal einfach: An/Aus Was kann man schon "templaten"?<br />
:Ich habe diverse Lichter und einige zugehörige Schalter. Da meine Fernbedienungen nur eine endliche Anzahl Knöpfe haben muss ich mir ein Konzept überlegen. Nutzen kann ich bei einem Wippschalter 2 Buttons (Knöpfe) und unterscheide bei jedem langer oder kurzer Druck. Bei Schaltern benötige ich demnach Templates für On, Off, Toggle. Nun kann ich jeder Paarung Aktor/Sensor und hier Long/Short eine Funktion zuweisen. <br />
:Nun nutze ich Buttons um bei pressLong das Licht 1 zu toggeln, bei PressShort toggelt es Licht 2. <br />
:Was programmiert ist kann man in HmInfo ermitteln über <br />
*get hm peerUsg<br />
<br />
= Grundsätzliches zum Template =<br />
Templates (hier) ist nun also eine Sammlung von Registern welche in einem Device gesetzt werden können. <br />
<br />
== Template Granularität ==<br />
Man kann nicht alle Register eines Device in einem Template abbilden. Das wäre technisch komplex und macht auch von der Anwendung her keinen Sinn. <br />
<br />
*Aus Sicht der Funktion sollte man Templates nach deren Funktionen zusammenfassen.<br />
*Aus Sicht des Devices sollte man Templates nach der Struktur des Device zusammenstellen.<br />
*Die Implementierung erlaubt es, Templates für jedes Register einzeln zu erstellen.<br><br />
*Weniger Templates erhöhen die Übersichtlichkeit<br />
Die technische Lösung legt folgende Templates nahe:<br />
#Alle Register eines Kanals oder Device - ausgenommen peer abhängige Register<br />
#Alle Register eines Kanals eines Peers für short oder long<br />
#Alle Register eines Kanals eines Peers nur für short<br />
#Alle Register eines Kanals eines Peers nur für long<br />
Ob man 2. oder die Kombination aus 3. und 4. nutzt ist Geschmackssache. <br><br />
Ein typischer Einsatz sind Schalter und Dimmer bei denen man die Aktionen der Peers festlegen will.<br />
;usecase Template Granularität Dimmer<br />
:Mit Peer1 soll bei short ein und bei long ausgeschaltet werden<br />
:Mit Peer2 soll bei short getoggelt und bei long nicht geschaltet werden<br />
:Mit Peer3 soll bei short nicht geschaltet und bei long getoggelt werden<br />
:Mit Peer4 ist ein MotionDetector welcher bei short und einer bestimmten Helligkeit einschaltet, timed. Allerdings sollen Aktionen der anderen Peers oder der Zentrale das Licht dauer-ein schalten.<br />
<br />
== Template Flexibilität ==<br />
Templates sind starr... und können parametriert werden. Also semistarr. Was jetzt? Nun man kann Templates mir bis zu 9 Parametern versehen. Sinnvoll sind wohl eher bis zu 3. <br><br />
Beispiele sind:<br />
*Treppenhausschaltern - mit einem Parameter kann man Einschaltdauer je Instanziierung festlegen. Sinnvoll könnte eine Treppenhausschaltung generell sein, nicht nur im Treppenhaus. Man kann generell alle Lichter nach ein paar Stunden ausschalten.<br />
*Heizungstemplate - Boosttime: Man kann allen RTs das gleiche Template geben - allerdings kann man z.B. die Boosttime indivituell einstellen. <br />
*MotionDetector Clients: Bei den Peers des Motiondetector (also den Schaltern) stellt man ein, wann diese reagieren sollen und wie lange diese brennen sollen. <br />
<br />
== Template Verwaltung==<br />
Templates werden zusammen mit Registern verwaltet. Man benötigt demnach HMinfo. Sowohl die Templatedefinition als auch die Templatezuweisung werden im File zusammen mit den gelesenen Registern gesichert. Nach einem Einlesen dieses Files werden auch die Templates und deren Zuordnung neu erstellt.<br />
<br />
== Template Editieren==<br />
Die aktuell einfachste Möglichkeit ein Template zu modifizieren ist, HMtemplate zu nutzen. HMtemplate ist ein Editor. Für den Betrieb wird es nicht genutzt. <br />
<br />
<br />
=Das eigenen Konzept=<br />
Für die Verknüpfung von HM Entities muss man 2 Ebenen unterschieden, Architektur und Verhalten.<br />
==Architektur==<br />
Beim Erstellen der Architektur legt man fest, welche Entities untereinander verknüpft werden. Dies geschieht durch peeren. Templates unterstützen nicht die Architektur. Es ist demnach notwendig die Peerings durchzuführen bevor an ein Template darauf anwenden kann. <br />
==Verhalten==<br />
Hier kommen die Templates zum Tragen. Mit Templates definiert man die Register der Entities und somit das Verhalten und die Reaktion der Entites bspw auf Trigger von Sensoren.<br />
===Welchen templateTyp brauche ich===<br />
Wie in Granularität beschrieben kann man insbesondere beim Peerverhalten templates für ''short'', ''long'' oder ''both'' ertellen. Nutzt man short/long braucht man weniger Templates (Basics sind on/off/ignore/toggle) muss allerdings mehr Templates zuweisen, als Reaktion auf short UND long.<br><br />
Bei both braucht man mehr Templates (OnOff/OnIgnore/OffIgnore/IgnoreOff/ToggleIgnore/...) braucht aber nur die Hälfte der Zuweisungen zu den realen Entities. <br />
<br />
===Welche Parameter muss ich einstellen===<br />
Bei der Erstellung eine Templates werden dessen Parameter durch Attribute vorgegeben. Durch '''set save''' wird dann das Template schlussendlich definiert. Folgende Parameter/Attribute werden genutzt:<br />
*'''tpl_description''': ist ein Freitext welcher beschreiben soll, was das Template macht und wie es parametriert wird<br />
*'''tpl_params''': hier werden evtl Parameter definiert mit welchen die Instanziierung des Templates angepasst werden kann. Bspw. könnte die Einschaltzeit variable gestalltet werden. Bei einem Dimmer könnt man den Level und die Rampe eingeben, also 2 Parameter. Man vergibt also, ":" getrennt, eine Liste von Paramtern. Die Namen sind frei wählbar. <br><br />
:''timeOn:ramp'' würde 2 Parameter definieren, welche später in den Registern genutzt werden können<br />
*'''tpl_type''': definiert den Typ. Diesen muss man zuerst festlegen. Es konnte ''peer-Short'',''peer-Long'',''peer-Both'' oder ''basic'' sein. Nach der Auswahl des Typs kann man die Entity (source) wählen. Es alle Entities angeboten, welche entsprechende Registersätze zu Verfügung stellen.<br />
*'''tpl_source''': legt bei der Definition eines Templates fest, von welcher Entity die Register für die Vorlage genutzt werden sollen. Ein Browser-Refresh könnte notwendig sein um die Auswahlliste upzudaten<br />
*'''tpl_peer''': muss man auswählen, so man einen "peer" typ gewählt hat. An Browser-refresh denken. <br />
*'''Reg_xxx''': An Browser-refresh denken. Hat man nun die Vorlage ausgewählt und den Refresh gemach werden nun Register als Attribute angeboten. <br><br />
:Zunächst sollte man Registerattribute löschen, welche man für das Template nicht benötigt. Achtung: eine Option gelöschte Registerattribute wieder nachzutragen ist nicht vorgesehen. So schlimm ist es allerdings nicht - man muss halt noch einmal alle Lesen und von Vorne löschen. <br><br />
:Sinnvoll kann es sein, die Condition Table Register komplett zu eliminieren wenn man Reaktionen auf Taster definieren will. Will man ''ignore'' definieren, also keine Reaktion bspw auf ''long'', dann kann man alles löschen bis auf ActionType usw. <br><br />
:Sinnvoll ist es, nur notwendige Register der Funktion zu bearbeiten, da sonst die Anwendung des Templates eingeschränkt wird. <br><br />
:Es sollten aber alle Register der Funktion enthalten sein, da die Prüfung auch nur diese berücksichtigt und bei einem Umprogrammieren nicht klar ist, was vorher in einem Register gestanden ist.<br />
===Register Werte setzen===<br />
Nun das eigentliche - das setzen der Registerinhalte. Dies wird begrenzt unterstützt. Sollte das Register durch ''literals'' definiert werden erscheint beim Setzen eine drop-down Liste mit den Optionen. <br><br />
Nicht unterstützt wird das Setzen von Werten. Es gibt aktuell keine Option, hier eine Hilfe einzublenden. Die Wertebereiche sind dem regList der Entity zu entnehmen. <br><br />
Eine weitere Besonderheit ist die Granularität der Werte. Insbesondere durch das Float Format einiger Werte sind nicht alle Werte möglich. Trägt man bspw eine Ontime von 10000 ein wird dies erst einmal akzeptiert. Allerdings wird der Wert beim Schreiben umgerechnet in den nächstmöglichen (welcher 9600 ist). Bei der Prüfung der Template Anwendung wird der Unterschied angemerkt. Am Einfachsten wird nun das Template angepasst und alles ist gut.<br><br />
<br><br />
Nun tpl_params. Diese muss man anstelle des Registerwerts einsetzen. Hat man bspw <br><br />
tpl_params timeOn:rampTime<br><br />
definiert setzt man in das Register ''OnTime'' den Wert ''timeOn'' ein. Und eben das Rampenregiste den Wert ''rampTime''. Der Wert wird dann beim Template Instanziieren - also Anwenden - durch den Individuellen ersetzt.<br />
<br />
=Getting started=<br />
Was muss man also tun? Wenn man noch nichts eingerichtet hat:<br />
define hm HMinfo<br />
attr hm autoArchive 1<br />
attr hm autoLoadArchive 1_load<br />
attr hm configFilename regConfig.cfg<br />
define ht HMtemplate<br />
<br />
==Template erstellen und bearbeiten==<br />
Templates kann man erstellen, in dem man die Register einer Entity nimmt und bearbeitet. Auch das Kopieren und Bearbeiten eines vorhandenen Templates ist möglich. Und man kann Templates exportieren/importieren.<br />
===Template aus Device===<br />
Aufgabe ist es, aus einem existierenden Device ein Template zu erstellen. Wir haben <br />
device ''myDev''<br />
Channel ''myChan''<br />
Channel gepeert mit ''myChanPeer''.<br><br />
Der Kanal ist ein Schalter und wir wollen einen Parameter im Template nutzen: Die Anschaltzeit soll bei der Nutzung des Templates variabel eingesetzt werden. Wir werden also den Parameter ''timeOn'' nutzen. Das Template soll ''my1stTmpl'' genannt werden. Weiter soll das gesamte Verhalten des ''myChanPeer'' definiert werden, also short UND long. <br />
set ht define my1stTmpl<br />
attr ht tpl_param timeOn # name des Parameters - hier nur einer<br />
attr ht tpl_description "mein erstes Template"<br />
attr ht tpl_type peer-both<br />
<refresh browser> # select liste der attribute wird neu eingelesen<br />
attr ht tpl_source myChan<br />
<refresh browser> # select liste der attribute wird neu eingelesen<br />
attr ht tpl_peer myChanPeer<br />
<refresh browser> # select liste der attribute wird neu eingelesen<br />
attr ht Reg_shOnTime timeOn # setzen des parameters<br />
<br />
nun können weitere Register verändert werde. <br />
Sinnvoll ist es, unnötige Register aus dem Template zu entfernen. Dies sind in diesem Fall bspw. alle Ct register. Das Attribut des Registers wird einfach gelöscht. <br />
set ht save<br />
set ht dismiss<br />
===Template Varianten speichern===<br />
Ist man beim Erstellen von Templates kann man mti saveAs das Template als neues unter einem anderen Namen sichern. <br />
===Template editieren===<br />
Mit Edit kann man die Werte der Register ändern oder vorhandene Register aus dem Template entfernen. Ein Hinzufügen von Registern wird nicht unterstützt. Hier fehlt die Referenz um anzubieten, was möglich ist.<br />
===Template kopieren===<br />
Dies wird ebenfalls mit edit erreicht. Das Template wird mit saveAs unter einem neuen Namen gespeichert.<br />
===Template export-import===<br />
Will man Templates exportieren nutzt man <br><br />
get ht <templatename><br />
Es wird ein kommando ausgegeben welches man in die Kommandozeile pasten kann, was dann der import ist.<br><br />
Dies kann man nutzen um Templates zu tauschen. Hat man ein ''gutes oder komplexes'' Template kann man dies der Allgemeinheit zu Verfügung stellen.<br><br />
Im besten Fall muss der User sich nicht mehr um Register kümmern, da komfortable Templates das besser abdecken.<br />
<br />
==Template einem Kanal zuweisen==<br />
Jetzt haben wir ein Template welches long UND short eines Kanals kontrollieren soll. Dies wollen wir jetzt anwenden auf unsere Kanal/Peer Kompinationen "sw1/peer1", "sw1/peer2", "sw2/peer1" und "sw2/peer3". Für alle benötigen wir unterschiedliche Abschaltzeiten (warum? eure Sache). <br />
set ht select my1stTmpl<br />
attr ht entity sw1<br />
<refresh browser><br />
attr ht ePeer peer1<br />
attr ht tpl_param_timeOn 30<br />
set ht apply<br />
attr ht ePeer peer2<br />
attr ht tpl_param_timeOn 180<br />
set ht apply<br />
<br />
attr ht entity sw2<br />
<refresh browser><br />
attr ht ePeer peer1<br />
attr ht tpl_param_timeOn 70<br />
set ht apply<br />
<br />
attr ht ePeer peer3<br />
attr ht tpl_param_timeOn 1000<br />
set ht apply<br />
<br />
set ht dismiss<br />
Die Register der Entities werden passend in das Device geschrieben.<br />
<br />
==Template editieren==<br />
Nun soll das Template grundsätzlich modfiziert werden. <br />
<br />
set ht edit my1stTmpl<br />
attr ht Reg_<name> <value><br />
attr ht Reg_<name2> <value2><br />
attr ht Reg_<name3> <value3><br />
set ht save<br />
==Template kopieren und editieren==<br />
Nun soll das Template grundsätzlich modfiziert werden. <br />
<br />
set ht select my1stTmpl<br />
attr ht Reg_<name> <value><br />
attr ht Reg_<name2> <value2><br />
attr ht Reg_<name3> <value3><br />
set ht saveAs my2ndTmpl<br />
==Template weitergeben==<br />
Will man Templates weitergeben geht das mit<br />
get ht my1stTmpl<br />
Das Kommando kann dann direkt in die Kommandozeile kopiert werden und das Template ist definiert.<br />
=Verwaltung und Überblick=<br />
Nun hat man Templates definiert und Instanziiert. Wie soll man den Überblick behalten? HMtemplate ist ein Editor - also nicht wirklich hierfür geeignet. HMinfo macht die Verwaltung. <br />
==Template Überblick==<br />
Will man sehen, was man so an Templates nutzt kann man eine Überscht unterschedliche sortiert ausgeben lassen - in HMinfo (hm).<br />
get hm templateUsgG sortTemplate<br />
get hm templateUsgG sortPeer<br />
get hm templateUsgG all<br />
Sowie eine Liste von Regiserlisten, welche noch kein Template nutzen (noch in Bau!!)<br />
get hm templateUsgG noTmpl<br />
Eine Liste der Verfügbaren Templates erhält man mit <br />
get hm templateList all<br />
und die Register eines Templates mit <br />
get hm templateList <templateName><br />
oder<br />
set ht select <templateName><br />
==Template prüfen==<br />
Templates werden auf korrekte Implementierung in der Entity anhand eines Vergleichs der gelesenen Registern mit den gewünschten Regitern geprüft. Es ist also notwendig, dass die Registerwerte in der FHEM Kopie aktuell sind. Dann reicht ein <br />
get hm configCheck<br />
Sollte es zu Unstimmigkeiten kommen werden mit <br />
set hm templateExe<br />
alle Unstimmigkeiten überschrieben. Klar, wie immer, muss FHEM warten, bis ein Device angesprochen werden kann (Übertragungsmode) und dass die IOs nicht überlastet werden. Die Gefahr einer Überlast ist gering wenn man nicht gleich alles überschreiben will. <br><br />
Wie immer ist es hilfreich den Status der Übertragung im Blick zu haben:<br />
get hm protoEvents<br />
Wenn zu viel passiert ist und man protoEvents aufräumen muss dann (Achtung: es werden alle ausstehenden Kommandos gelöscht und müssen neu aktiviert werden!)<br />
set hm clearG msgEvents<br />
==Template löschen==<br />
set ht delete <tempateName><br />
Achtung: vorher müssen alle Referenzen des Templates entfernt worden sein. <br />
<br />
=Templates in den Entites=<br />
Ist eine Entity mit einem Template verknüpft wird dies in den Readings angezeigt. Dies kann man sichtbar machen - und eine Anzeige von Registern in den Readings sollte dann nicht mehr notwendig sein. Empfohlen wird, den expoer mode auf rein Templates umzustellen<br />
attr TYPE=CUL_HM:FILTER=DEF=......:FILTER=subType!=virtual expert 12_templOnly<br />
deleteattr TYPE=CUL_HM:FILTER=DEF=........ expert<br />
deleteattr TYPE=CUL_HM:FILTER=subType=virtual expert<br />
<br />
=Beispiele und Ideen=<br />
<br />
Neben den typischen Templates für Schalter kann (sollte) man auch bspw für RTs einsetzen. Temperaturlisten sind nicht im Angebot. Hier gibt es bereits andere Verfahren die besser passen. Allerdings experimentire ich bei meinen RTs mit den Regelparametern und will diese dann generell setzen. Alle RTs (bei mir) sollen die gleiche Regelung haben. Ich nutze 3 Templates für meine RTs<br />
* '''HeatDefDev''': Das Device des RT wird auf Standartwerte gesetzt. Hier nutze ich einen Parameter um die Tasten zu sperren. Dies brauche ich nicht bei allen RTs sondern nur bei denen, welche ich mit einem TC gepeert habe. Hier ist eine Lokale Änderung am TC vorzunehmen. <br />
* '''HeatDefault''':Die Standart-Regelung. Auch hier habe ich Parameter vorgesehen. Die Devices sind identisch... bis auf die Boostzeit und die maximals Ventilöffnung. Je nach Hk begrenze ich ValveMax - hängt von den baulichen Gegebenheiten ab. Boost nutze ich im Bad zum entfeuchten.<br />
* '''HeatRemote''': mein ''guteNacht'' Knopf macht auch vor RTs nicht halt. Ich haben an einer Remote einen Button mit allen Lichtern und RTs im Wohnbereich gekoppelt. Beim Drücken wird das Licht abgeschaltet und dieHeizung gedrosselt - bspw wenn ich als letzter ins Bett gehe. Daher brauche ich einen Parameter ''Temperatur'' um das induviduell je RT einzustellen. <br />
set hm templateDef HeatDefDev BtnLock "Default RT Device register" globalBtnLock:off localResDis:off modusBtnLock:off backOnTime:10 cyclicInfoMsg:on lowBatLimitRT:2.1 burstRx:on cyclicInfoMsgDis:0 btnLock:p0<br />
set hm templateDef HeatDefault boost:valveMax "myDefault RT settings, enter boostTime and valveMax" regAdaptive:offDeter reguIntI:20 nightTemp:17 tempOffset:0.0K dayTemp:21 reguIntPstart:5 reguExtI:20 showWeekday:off reguExtP:25 reguIntP:25 tempMax:30.5 tempMin:4.5 valveMaxPos:p1 valveOffsetRt:0 modePrioManu:all daylightSaveTime:on boostPos:30 decalcWeekday:Sat showInfo:time decalcTime:11:00 btnNoBckLight:off reguExtPstart:5 noMinMax4Manu:off modePrioParty:all valveErrPos:15 boostPeriod:p0<br />
set hm templateDef HeatRemote temp "heatRemote set temperature" CtrlRc:autoAndTemp TempRC:p0<br />
<br><br />
In der Übersicht für 2 RTs ergibt ein get hm templateUsg<br />
haEss |0 |HeatDefDev|BtnLock:off <br />
haEss_Clima |0 |HeatDefault|boost:5 valveMax:15 <br />
haEss_remote |FB8_1:short |HeatRemote|temp:13 <br />
haEss_remote |FB8_5:long |HeatRemote|temp:13 <br />
haEss_remote |FB8_5:short |HeatRemote|temp:19 <br />
haLnge |0 |HeatDefDev|BtnLock:off <br />
haLnge_Clima |0 |HeatDefault|boost:5 valveMax:15 <br />
haLnge_remote |FB8_1:short |HeatRemote|temp:13 <br />
haLnge_remote |FB8_5:long |HeatRemote|temp:13 <br />
haLnge_remote |FB8_5:short |HeatRemote|temp:19 <br />
<br />
<br />
<br />
[[Kategorie:HomeMatic supportDevice]]<br />
[[Kategorie:HOWTOS]]</div>Martinp876http://wiki.fhem.de/w/index.php?title=HomeMatic_Templates&diff=31771HomeMatic Templates2019-12-01T11:48:02Z<p>Martinp876: /* Warum Templates */</p>
<hr />
<div>{{Infobox Modul<br />
|ModPurpose=templates bedienen und verwalten<br />
|ModType=h<br />
|ModCmdRef=HMtemplate<br />
|ModForumArea=HomeMatic<br />
|ModTechName=98_HMtemplate.pm<br />
|ModOwner=martinp876 ({{Link2FU|251|martinp876}} / [[Benutzer Diskussion:Martinp876|Wiki]])<br />
}}<br />
Templates sind Vorlagen im Allgemeinen. Hier werden Vorlagen zur Programmierung der Register von HM Devices behandelt. <br />
= Warum Templates =<br />
Templates sind ein Weg, die Register der HM RF Devices zu setzen, zu kontrollieren und zu replizieren. <br />
Warum braucht man nun Templates? Register lassen sich doch einfach ohne Templates setzen. Warum sich damit befassen?<br />
Nun, die Gründe sind vielfältig - und eigentlich unabdingbar für alle, die ein geordnetes System verwalten wollen. <br />
;Register ohne Template - Schwachstellen<br />
:Register werden, wie bekannt, remanent in den HM-Devices gespeichert. FHEM hat eine Kopie dieser Daten welche über getConfig aufgefrischt werden können. Setzt man nun in einem Device ein Register ist dies erst einmal erledigt. Nun kann sich das Register verändern bzw muss überprüft werden, wenn <br />
* das Device ausgetauscht wird<br />
* das Device reseted wird - kommt auch einmal vor<br />
* ein FW bug oder ein HW Defekt vorliegt<br />
* das Schreiben der Registerwerte nicht erfolgreich war<br />
:Weiter ist es praktisch die gewünschten Settings, also das eingestellte Verhalten <br />
* zu verifizieren<br />
* zu kopieren<br />
:ohne sich einzelne Registerzu merken oder wieder herzuleiten. <br />
<br />
Anzumerken ist, dass die Nutzung von Templates das Bedienen der Register nicht abschaltet oder übersteuert sondern nur ergänzt. <br />
<br />
Templates heben das Bedienen der Register von der Assembler ebene auf eine Hochsprachen-Ebene. Nicht ohne Grund ist die erste Bedienung der Register in der eq3-CCU quasi per Template. Register werden nur im Expert mode sichtbar. <br />
<br />
= Was bieten Templates =<br />
Wie schon im Einsteigerdoc beschrieben hat ein HM Device remanente Register, welche von FHEM gesetzt werden können und die Funktions- und Arbeitsweise definieren. FHEM selbst hat bestenfalls eine Kopie dieser Daten.<br />
<br />
;soll-Register Verwaltung<br />
:Da FHEM nur eine Kopie der ist-Registerwerte verwaltet lebt man erst grundsätzlich in einer fragilen Welt. Eine Soll-Wert Verwaltung der Register bietet nur in Templates. <br />
;Funktionen für Einsteiger<br />
:Nicht-Experten sollten primär Templates nutzen - um Funktionen zu realisieren. Der Anwender holt sich ein Template und kopiert es in sein System. Nun kann er<br />
* die Funktion nutzen. Es muss die Register nicht verstehen<br />
* Die Funktion nutzen, testen und die Register evaluieren und daran zu lernen<br />
* Die Funktion erweitern, modifizieren und an seine Bedürfnisse anpassen<br />
;Verwalten von Funktionen statt Registern<br />
:Als Experten kann man evtl. Register zeilsicher setzen. Wirklich? Wenn man sich eine clevere Lösung ausgedacht hat und sie reproduzieren will kann man einfach noch einmal nachdenken, nachlesen, ... und schon hat man es wieder. Oder man hat ein Template definiert das man einfach nutzt und repliziert.<br />
;Lernen aus Templates<br />
:Templates sind nicht verschlüsselt. Hat oder bekommt man ein Template kann man die dort gesetzten Register einfach einsehen - und wenn man will verstehen was gemacht wurde.<br />
;Globales Anpassen aller Devices<br />
:Hat man festgestellt, dass eine Funktion sub-optimal ist kann man das Template ändern und diese Änderungen allen Devices zu Gute kommen lassen. Auf einmal.<br />
;Funktionen parametrieren<br />
:Der Anwender hat typisch den Wunsch, eine Funktion zu relaisieren, aber einen Parameter will er bei jeder Anwendung anpassen. So will ich typischerweise, dass nach einem ON-Trigger immer eine automatische Abschaltung eingestellt wird, was das Vergessen des Ausschaltes verhindern soll. Die Anschaltzeit ist aber im Wohnzimmer eher 6h, im Treppenhaus aber 2h und bei einem Bewegungsmelder 10min. <br />
:Hier kann man nun immer das gleiche Template nutzen. Die Abschaltzeit wird separat eingestellt und ist per Kommando modifizierbar. Weiter ist sie in den Readings sichtbar.<br />
<br />
= Grundsätzliches zum Template =<br />
Templates (hier) ist nun also eine Sammlung von Registern welche in einem Device gesetzt werden können. <br />
<br />
== Template Granularität ==<br />
Man kann nicht alle Register eines Device in einem Template abbilden. Das wäre technisch komplex und macht auch von der Anwendung her keinen Sinn. <br />
<br />
*Aus Sicht der Funktion sollte man Templates nach deren Funktionen zusammenfassen.<br />
*Aus Sicht des Devices sollte man Templates nach der Struktur des Device zusammenstellen.<br />
*Die Implementierung erlaubt es, Templates für jedes Register einzeln zu erstellen.<br><br />
*Weniger Templates erhöhen die Übersichtlichkeit<br />
Die technische Lösung legt folgende Templates nahe:<br />
#Alle Register eines Kanals oder Device - ausgenommen peer abhängige Register<br />
#Alle Register eines Kanals eines Peers für short oder long<br />
#Alle Register eines Kanals eines Peers nur für short<br />
#Alle Register eines Kanals eines Peers nur für long<br />
Ob man 2. oder die Kombination aus 3. und 4. nutzt ist Geschmackssache. <br><br />
Ein typischer Einsatz sind Schalter und Dimmer bei denen man die Aktionen der Peers festlegen will.<br />
;usecase Template Granularität Dimmer<br />
:Mit Peer1 soll bei short ein und bei long ausgeschaltet werden<br />
:Mit Peer2 soll bei short getoggelt und bei long nicht geschaltet werden<br />
:Mit Peer3 soll bei short nicht geschaltet und bei long getoggelt werden<br />
:Mit Peer4 ist ein MotionDetector welcher bei short und einer bestimmten Helligkeit einschaltet, timed. Allerdings sollen Aktionen der anderen Peers oder der Zentrale das Licht dauer-ein schalten.<br />
<br />
== Template Flexibilität ==<br />
Templates sind starr... und können parametriert werden. Also semistarr. Was jetzt? Nun man kann Templates mir bis zu 9 Parametern versehen. Sinnvoll sind wohl eher bis zu 3. <br><br />
Beispiele sind:<br />
*Treppenhausschaltern - mit einem Parameter kann man Einschaltdauer je Instanziierung festlegen. Sinnvoll könnte eine Treppenhausschaltung generell sein, nicht nur im Treppenhaus. Man kann generell alle Lichter nach ein paar Stunden ausschalten.<br />
*Heizungstemplate - Boosttime: Man kann allen RTs das gleiche Template geben - allerdings kann man z.B. die Boosttime indivituell einstellen. <br />
*MotionDetector Clients: Bei den Peers des Motiondetector (also den Schaltern) stellt man ein, wann diese reagieren sollen und wie lange diese brennen sollen. <br />
<br />
== Template Verwaltung==<br />
Templates werden zusammen mit Registern verwaltet. Man benötigt demnach HMinfo. Sowohl die Templatedefinition als auch die Templatezuweisung werden im File zusammen mit den gelesenen Registern gesichert. Nach einem Einlesen dieses Files werden auch die Templates und deren Zuordnung neu erstellt.<br />
<br />
== Template Editieren==<br />
Die aktuell einfachste Möglichkeit ein Template zu modifizieren ist, HMtemplate zu nutzen. HMtemplate ist ein Editor. Für den Betrieb wird es nicht genutzt. <br />
<br />
<br />
=Das eigenen Konzept=<br />
Für die Verknüpfung von HM Entities muss man 2 Ebenen unterschieden, Architektur und Verhalten.<br />
==Architektur==<br />
Beim Erstellen der Architektur legt man fest, welche Entities untereinander verknüpft werden. Dies geschieht durch peeren. Templates unterstützen nicht die Architektur. Es ist demnach notwendig die Peerings durchzuführen bevor an ein Template darauf anwenden kann. <br />
==Verhalten==<br />
Hier kommen die Templates zum Tragen. Mit Templates definiert man die Register der Entities und somit das Verhalten und die Reaktion der Entites bspw auf Trigger von Sensoren.<br />
===Welchen templateTyp brauche ich===<br />
Wie in Granularität beschrieben kann man insbesondere beim Peerverhalten templates für ''short'', ''long'' oder ''both'' ertellen. Nutzt man short/long braucht man weniger Templates (Basics sind on/off/ignore/toggle) muss allerdings mehr Templates zuweisen, als Reaktion auf short UND long.<br><br />
Bei both braucht man mehr Templates (OnOff/OnIgnore/OffIgnore/IgnoreOff/ToggleIgnore/...) braucht aber nur die Hälfte der Zuweisungen zu den realen Entities. <br />
<br />
===Welche Parameter muss ich einstellen===<br />
Bei der Erstellung eine Templates werden dessen Parameter durch Attribute vorgegeben. Durch '''set save''' wird dann das Template schlussendlich definiert. Folgende Parameter/Attribute werden genutzt:<br />
*'''tpl_description''': ist ein Freitext welcher beschreiben soll, was das Template macht und wie es parametriert wird<br />
*'''tpl_params''': hier werden evtl Parameter definiert mit welchen die Instanziierung des Templates angepasst werden kann. Bspw. könnte die Einschaltzeit variable gestalltet werden. Bei einem Dimmer könnt man den Level und die Rampe eingeben, also 2 Parameter. Man vergibt also, ":" getrennt, eine Liste von Paramtern. Die Namen sind frei wählbar. <br><br />
:''timeOn:ramp'' würde 2 Parameter definieren, welche später in den Registern genutzt werden können<br />
*'''tpl_type''': definiert den Typ. Diesen muss man zuerst festlegen. Es konnte ''peer-Short'',''peer-Long'',''peer-Both'' oder ''basic'' sein. Nach der Auswahl des Typs kann man die Entity (source) wählen. Es alle Entities angeboten, welche entsprechende Registersätze zu Verfügung stellen.<br />
*'''tpl_source''': legt bei der Definition eines Templates fest, von welcher Entity die Register für die Vorlage genutzt werden sollen. Ein Browser-Refresh könnte notwendig sein um die Auswahlliste upzudaten<br />
*'''tpl_peer''': muss man auswählen, so man einen "peer" typ gewählt hat. An Browser-refresh denken. <br />
*'''Reg_xxx''': An Browser-refresh denken. Hat man nun die Vorlage ausgewählt und den Refresh gemach werden nun Register als Attribute angeboten. <br><br />
:Zunächst sollte man Registerattribute löschen, welche man für das Template nicht benötigt. Achtung: eine Option gelöschte Registerattribute wieder nachzutragen ist nicht vorgesehen. So schlimm ist es allerdings nicht - man muss halt noch einmal alle Lesen und von Vorne löschen. <br><br />
:Sinnvoll kann es sein, die Condition Table Register komplett zu eliminieren wenn man Reaktionen auf Taster definieren will. Will man ''ignore'' definieren, also keine Reaktion bspw auf ''long'', dann kann man alles löschen bis auf ActionType usw. <br><br />
:Sinnvoll ist es, nur notwendige Register der Funktion zu bearbeiten, da sonst die Anwendung des Templates eingeschränkt wird. <br><br />
:Es sollten aber alle Register der Funktion enthalten sein, da die Prüfung auch nur diese berücksichtigt und bei einem Umprogrammieren nicht klar ist, was vorher in einem Register gestanden ist.<br />
===Register Werte setzen===<br />
Nun das eigentliche - das setzen der Registerinhalte. Dies wird begrenzt unterstützt. Sollte das Register durch ''literals'' definiert werden erscheint beim Setzen eine drop-down Liste mit den Optionen. <br><br />
Nicht unterstützt wird das Setzen von Werten. Es gibt aktuell keine Option, hier eine Hilfe einzublenden. Die Wertebereiche sind dem regList der Entity zu entnehmen. <br><br />
Eine weitere Besonderheit ist die Granularität der Werte. Insbesondere durch das Float Format einiger Werte sind nicht alle Werte möglich. Trägt man bspw eine Ontime von 10000 ein wird dies erst einmal akzeptiert. Allerdings wird der Wert beim Schreiben umgerechnet in den nächstmöglichen (welcher 9600 ist). Bei der Prüfung der Template Anwendung wird der Unterschied angemerkt. Am Einfachsten wird nun das Template angepasst und alles ist gut.<br><br />
<br><br />
Nun tpl_params. Diese muss man anstelle des Registerwerts einsetzen. Hat man bspw <br><br />
tpl_params timeOn:rampTime<br><br />
definiert setzt man in das Register ''OnTime'' den Wert ''timeOn'' ein. Und eben das Rampenregiste den Wert ''rampTime''. Der Wert wird dann beim Template Instanziieren - also Anwenden - durch den Individuellen ersetzt.<br />
<br />
=Getting started=<br />
Was muss man also tun? Wenn man noch nichts eingerichtet hat:<br />
define hm HMinfo<br />
attr hm autoArchive 1<br />
attr hm autoLoadArchive 1_load<br />
attr hm configFilename regConfig.cfg<br />
define ht HMtemplate<br />
<br />
==Template erstellen und bearbeiten==<br />
Templates kann man erstellen, in dem man die Register einer Entity nimmt und bearbeitet. Auch das Kopieren und Bearbeiten eines vorhandenen Templates ist möglich. Und man kann Templates exportieren/importieren.<br />
===Template aus Device===<br />
Aufgabe ist es, aus einem existierenden Device ein Template zu erstellen. Wir haben <br />
device ''myDev''<br />
Channel ''myChan''<br />
Channel gepeert mit ''myChanPeer''.<br><br />
Der Kanal ist ein Schalter und wir wollen einen Parameter im Template nutzen: Die Anschaltzeit soll bei der Nutzung des Templates variabel eingesetzt werden. Wir werden also den Parameter ''timeOn'' nutzen. Das Template soll ''my1stTmpl'' genannt werden. Weiter soll das gesamte Verhalten des ''myChanPeer'' definiert werden, also short UND long. <br />
set ht define my1stTmpl<br />
attr ht tpl_param timeOn # name des Parameters - hier nur einer<br />
attr ht tpl_description "mein erstes Template"<br />
attr ht tpl_type peer-both<br />
<refresh browser> # select liste der attribute wird neu eingelesen<br />
attr ht tpl_source myChan<br />
<refresh browser> # select liste der attribute wird neu eingelesen<br />
attr ht tpl_peer myChanPeer<br />
<refresh browser> # select liste der attribute wird neu eingelesen<br />
attr ht Reg_shOnTime timeOn # setzen des parameters<br />
<br />
nun können weitere Register verändert werde. <br />
Sinnvoll ist es, unnötige Register aus dem Template zu entfernen. Dies sind in diesem Fall bspw. alle Ct register. Das Attribut des Registers wird einfach gelöscht. <br />
set ht save<br />
set ht dismiss<br />
===Template Varianten speichern===<br />
Ist man beim Erstellen von Templates kann man mti saveAs das Template als neues unter einem anderen Namen sichern. <br />
===Template editieren===<br />
Mit Edit kann man die Werte der Register ändern oder vorhandene Register aus dem Template entfernen. Ein Hinzufügen von Registern wird nicht unterstützt. Hier fehlt die Referenz um anzubieten, was möglich ist.<br />
===Template kopieren===<br />
Dies wird ebenfalls mit edit erreicht. Das Template wird mit saveAs unter einem neuen Namen gespeichert.<br />
===Template export-import===<br />
Will man Templates exportieren nutzt man <br><br />
get ht <templatename><br />
Es wird ein kommando ausgegeben welches man in die Kommandozeile pasten kann, was dann der import ist.<br><br />
Dies kann man nutzen um Templates zu tauschen. Hat man ein ''gutes oder komplexes'' Template kann man dies der Allgemeinheit zu Verfügung stellen.<br><br />
Im besten Fall muss der User sich nicht mehr um Register kümmern, da komfortable Templates das besser abdecken.<br />
<br />
==Template einem Kanal zuweisen==<br />
Jetzt haben wir ein Template welches long UND short eines Kanals kontrollieren soll. Dies wollen wir jetzt anwenden auf unsere Kanal/Peer Kompinationen "sw1/peer1", "sw1/peer2", "sw2/peer1" und "sw2/peer3". Für alle benötigen wir unterschiedliche Abschaltzeiten (warum? eure Sache). <br />
set ht select my1stTmpl<br />
attr ht entity sw1<br />
<refresh browser><br />
attr ht ePeer peer1<br />
attr ht tpl_param_timeOn 30<br />
set ht apply<br />
attr ht ePeer peer2<br />
attr ht tpl_param_timeOn 180<br />
set ht apply<br />
<br />
attr ht entity sw2<br />
<refresh browser><br />
attr ht ePeer peer1<br />
attr ht tpl_param_timeOn 70<br />
set ht apply<br />
<br />
attr ht ePeer peer3<br />
attr ht tpl_param_timeOn 1000<br />
set ht apply<br />
<br />
set ht dismiss<br />
Die Register der Entities werden passend in das Device geschrieben.<br />
<br />
==Template editieren==<br />
Nun soll das Template grundsätzlich modfiziert werden. <br />
<br />
set ht edit my1stTmpl<br />
attr ht Reg_<name> <value><br />
attr ht Reg_<name2> <value2><br />
attr ht Reg_<name3> <value3><br />
set ht save<br />
==Template kopieren und editieren==<br />
Nun soll das Template grundsätzlich modfiziert werden. <br />
<br />
set ht select my1stTmpl<br />
attr ht Reg_<name> <value><br />
attr ht Reg_<name2> <value2><br />
attr ht Reg_<name3> <value3><br />
set ht saveAs my2ndTmpl<br />
==Template weitergeben==<br />
Will man Templates weitergeben geht das mit<br />
get ht my1stTmpl<br />
Das Kommando kann dann direkt in die Kommandozeile kopiert werden und das Template ist definiert.<br />
=Verwaltung und Überblick=<br />
Nun hat man Templates definiert und Instanziiert. Wie soll man den Überblick behalten? HMtemplate ist ein Editor - also nicht wirklich hierfür geeignet. HMinfo macht die Verwaltung. <br />
==Template Überblick==<br />
Will man sehen, was man so an Templates nutzt kann man eine Überscht unterschedliche sortiert ausgeben lassen - in HMinfo (hm).<br />
get hm templateUsgG sortTemplate<br />
get hm templateUsgG sortPeer<br />
get hm templateUsgG all<br />
Sowie eine Liste von Regiserlisten, welche noch kein Template nutzen (noch in Bau!!)<br />
get hm templateUsgG noTmpl<br />
Eine Liste der Verfügbaren Templates erhält man mit <br />
get hm templateList all<br />
und die Register eines Templates mit <br />
get hm templateList <templateName><br />
oder<br />
set ht select <templateName><br />
==Template prüfen==<br />
Templates werden auf korrekte Implementierung in der Entity anhand eines Vergleichs der gelesenen Registern mit den gewünschten Regitern geprüft. Es ist also notwendig, dass die Registerwerte in der FHEM Kopie aktuell sind. Dann reicht ein <br />
get hm configCheck<br />
Sollte es zu Unstimmigkeiten kommen werden mit <br />
set hm templateExe<br />
alle Unstimmigkeiten überschrieben. Klar, wie immer, muss FHEM warten, bis ein Device angesprochen werden kann (Übertragungsmode) und dass die IOs nicht überlastet werden. Die Gefahr einer Überlast ist gering wenn man nicht gleich alles überschreiben will. <br><br />
Wie immer ist es hilfreich den Status der Übertragung im Blick zu haben:<br />
get hm protoEvents<br />
Wenn zu viel passiert ist und man protoEvents aufräumen muss dann (Achtung: es werden alle ausstehenden Kommandos gelöscht und müssen neu aktiviert werden!)<br />
set hm clearG msgEvents<br />
==Template löschen==<br />
set ht delete <tempateName><br />
Achtung: vorher müssen alle Referenzen des Templates entfernt worden sein. <br />
<br />
=Templates in den Entites=<br />
Ist eine Entity mit einem Template verknüpft wird dies in den Readings angezeigt. Dies kann man sichtbar machen - und eine Anzeige von Registern in den Readings sollte dann nicht mehr notwendig sein. Empfohlen wird, den expoer mode auf rein Templates umzustellen<br />
attr TYPE=CUL_HM:FILTER=DEF=......:FILTER=subType!=virtual expert 12_templOnly<br />
deleteattr TYPE=CUL_HM:FILTER=DEF=........ expert<br />
deleteattr TYPE=CUL_HM:FILTER=subType=virtual expert<br />
<br />
=Beispiele und Ideen=<br />
<br />
Neben den typischen Templates für Schalter kann (sollte) man auch bspw für RTs einsetzen. Temperaturlisten sind nicht im Angebot. Hier gibt es bereits andere Verfahren die besser passen. Allerdings experimentire ich bei meinen RTs mit den Regelparametern und will diese dann generell setzen. Alle RTs (bei mir) sollen die gleiche Regelung haben. Ich nutze 3 Templates für meine RTs<br />
* '''HeatDefDev''': Das Device des RT wird auf Standartwerte gesetzt. Hier nutze ich einen Parameter um die Tasten zu sperren. Dies brauche ich nicht bei allen RTs sondern nur bei denen, welche ich mit einem TC gepeert habe. Hier ist eine Lokale Änderung am TC vorzunehmen. <br />
* '''HeatDefault''':Die Standart-Regelung. Auch hier habe ich Parameter vorgesehen. Die Devices sind identisch... bis auf die Boostzeit und die maximals Ventilöffnung. Je nach Hk begrenze ich ValveMax - hängt von den baulichen Gegebenheiten ab. Boost nutze ich im Bad zum entfeuchten.<br />
* '''HeatRemote''': mein ''guteNacht'' Knopf macht auch vor RTs nicht halt. Ich haben an einer Remote einen Button mit allen Lichtern und RTs im Wohnbereich gekoppelt. Beim Drücken wird das Licht abgeschaltet und dieHeizung gedrosselt - bspw wenn ich als letzter ins Bett gehe. Daher brauche ich einen Parameter ''Temperatur'' um das induviduell je RT einzustellen. <br />
set hm templateDef HeatDefDev BtnLock "Default RT Device register" globalBtnLock:off localResDis:off modusBtnLock:off backOnTime:10 cyclicInfoMsg:on lowBatLimitRT:2.1 burstRx:on cyclicInfoMsgDis:0 btnLock:p0<br />
set hm templateDef HeatDefault boost:valveMax "myDefault RT settings, enter boostTime and valveMax" regAdaptive:offDeter reguIntI:20 nightTemp:17 tempOffset:0.0K dayTemp:21 reguIntPstart:5 reguExtI:20 showWeekday:off reguExtP:25 reguIntP:25 tempMax:30.5 tempMin:4.5 valveMaxPos:p1 valveOffsetRt:0 modePrioManu:all daylightSaveTime:on boostPos:30 decalcWeekday:Sat showInfo:time decalcTime:11:00 btnNoBckLight:off reguExtPstart:5 noMinMax4Manu:off modePrioParty:all valveErrPos:15 boostPeriod:p0<br />
set hm templateDef HeatRemote temp "heatRemote set temperature" CtrlRc:autoAndTemp TempRC:p0<br />
<br><br />
In der Übersicht für 2 RTs ergibt ein get hm templateUsg<br />
haEss |0 |HeatDefDev|BtnLock:off <br />
haEss_Clima |0 |HeatDefault|boost:5 valveMax:15 <br />
haEss_remote |FB8_1:short |HeatRemote|temp:13 <br />
haEss_remote |FB8_5:long |HeatRemote|temp:13 <br />
haEss_remote |FB8_5:short |HeatRemote|temp:19 <br />
haLnge |0 |HeatDefDev|BtnLock:off <br />
haLnge_Clima |0 |HeatDefault|boost:5 valveMax:15 <br />
haLnge_remote |FB8_1:short |HeatRemote|temp:13 <br />
haLnge_remote |FB8_5:long |HeatRemote|temp:13 <br />
haLnge_remote |FB8_5:short |HeatRemote|temp:19 <br />
<br />
<br />
<br />
[[Kategorie:HomeMatic supportDevice]]<br />
[[Kategorie:HOWTOS]]</div>Martinp876http://wiki.fhem.de/w/index.php?title=HMinfo_Protokoll&diff=24315HMinfo Protokoll2018-01-04T20:13:25Z<p>Martinp876: </p>
<hr />
<div>{{Infobox Modul<br />
|ModPurpose=HM Protokollereignisse kontrollieren<br />
|ModType=h<br />
|ModCmdRef=HMinfo<br />
|ModForumArea=HomeMatic<br />
|ModTechName=98_HMinfo.pm<br />
|ModOwner=martinp876 ({{Link2FU|251|martinp876}} / [[Benutzer Diskussion:Martinp876|Wiki]])<br />
}}<br />
<br />
Homematic Geräte mit Funkprotokoll haben Eigenheiten welche man verstehen und überwachen muss, so man sein System unter Konrolle haben will. <br />
HMInfo ist ein Modul welches Methoden zu Verfügung stellt, damit umzugehen. <br />
Behandelt wird hier ausschliesslich die Homematic Funkprotokoll. <br />
<br />
=Das Protokoll=<br />
Das Protokoll beruht in der Regel auf einem Handshake Verfahren. Nachrichten müssen von Empfänger quittert werden. Um mit einem Device kommunizieren zu können muss es allerdings empfangsbereit sein. Man muss die Devicetypen daher unterscheiden<br />
==Kommunikationstypen==<br />
Homematic bietet unterschiedliche Devices, teils batteriebetrieben. Die Energieversorgung ist der wesentliche Grund unterschiedliche Typen zu etablieren. Sollte ein batteriebetriebenes Device kontinuierlich auf Empfang sein senkt das die Lebensdauer der Batterie erheblich. Somit unterscheidet man<br />
* '''[[Config]]''':Dieser Modus wird von [[allen]] Devices unterstützt. Hierbei wird das Device durch drücken einer Taste (typisch einer separaten, versteckten Taste) in den Mode versetzt. Die Taste wird gelegentlich auch Anlerntaste genannt. Das Device sendet hierbei eine Konfigmessage und bleibt einige Sekunden auf Empfang. Ein anderes Device hat nun die Chance mit dem Device zu kommunizieren.<br />
:Dieser Mode wird gerne zum Pairen genutzt. <br />
:Die FHEM Zentrale erkennt die Message und startet die Abarbeitung eventuell anhängiger Messages<br />
* '''[[normal]]''':Typischerweise wird dieser Mode von allen Devices mit permanenter Stromversorgung unterstützt. Das Device ist kontinuierlich auf Empfang. Config wird von diesen Devices typisch nur zum pairen genutzt<br />
* '''[[wakeup]]''':Batteriebetriebene Devices welche regelmäßig senden stellen gerne diesen Modus bereit. Einige Devices welche regelmäßig senden (Thermostate oder Fühler) bleiben nach senden der zyklischen Nachricht kurz auf Empfang. FHEM erkennt dies und sendet gegebenenfalls anhängige Nachrichten und Abfragen. <br />
* '''[[lazyConf]]''':Einige modernere Devices, betteriebetrieben und unregemäßig sendent, stellen einen trägen Config mode bereit. Hierbei bleibt das Device auf Empfang, wenn dies einen Trigger gesendet hat. <br />
:Beispiel ist eine Fernbedienung welche nach drücken eines Buttons den Trigger sendet und dann kurz auf weitere Nachrichten wartet. Auch einige Bewegungsmelder unterstützen dies. Hier muss man also einen Trigger auslösen (Bewegung). Das Device reagiert nicht nach dem Senden der zyklischen Nachrichten.<br />
:Erfahrungsgemäß funktioniert dies allerdings nur, wenn das Device den Trigger an die Zentrale sendet. Es ist also ratsam, alle Kanäle (jeden einzeln) mit einem Kanal der Zentrale zu peeren. Es biete sich an, einen virtuellen Button der Zentrale zu nutzen, welche man mit allen Kanälen aller LazyConfig Devices peert.<br />
* '''[[burst]]''':Burst ist ein Verfahren, schlafende Devices aufzuwecken. Einige sind im Dämmerschlaf und können durch einen Burst aufgeweckt werden. Burst ist ein Kommandosequenz welche der Initiator senden muss. Diese ist aufwändig, verbraucht einiges an Funkperformance (1% Regel) und weckt [[alle]] Burst Devices gleichzeitig auf. Als Daumenregel kann ein Device in einer Stunde 100 Bursts senden bevor die 1% Regel zuschlägt. <br />
:SD (Rauchdetektoren) verwenden tyisch burst. Sie müssen empfangsbereit sein, laufen mit Batterie und müssen demnach Sparsam sein. <br />
* '''[[burstCond]]''':ist eine Variante des Burst. Der Burstmode kann bei ihnen freigeschaltet werden. Beispielsweise RT (Heizungsthermosrate) nutzen diesen Mode. Ein RT sendet regelmäßig seinen Status - und hierbei kann man über wakeup mit dem Device alle 3min kommunizieren. Nun muss ein RT aber auf Fensterkontakte reagieren können. Diese senden Asynchron. Man muss also sicherstellen, dass der Fensterkontakt einen Burst sendet und der RT auf Burst reagiert. <br />
:Conditional Burst wird in einem Register freigeschaltet. <br />
:Devices mit CondBurst stellen ein Kommando BurstXmit bereit. Hierbei wird von FHEM ein Burst gesendet und ene eventuell anstehende Kommunikation wird durhgeführt. <br />
:BurstXmit sollte nur bei Bedarf, beim Configurieren, genutzt werden. Typisch sollte man auf das normale erwachen des Devices warten um die Kommunikation nicht zu belasten. <br />
:In einem Sender (Fensterkontakt) Muss "peerNeedsBurst" einegeschaltet werden, wenn dieses mit einem Burst-Device gepeert ist. <br />
===HMinfo Kommandos zum Devicetyp===<br />
Um nun festzustellen, welchen Devicetyp man vorliegen hat kann man über das Attribut model seines Device in HMinfo klären<br />
get hm models<br />
get hm models -f <regexp><br />
get hm models -f SD<br />
==FHEM Kommunikation==<br />
FHEM kennt alle Kommunikationstypen und behandelt diese entsprechend. Zu beachten ist, dass ein HM Gerät aus mehreren Entities besteht: Ein Device und ein oder mehrere Kanäle. Man kann mit den Kanälen nicht direkt kommunizieren. Die Kommunikation geht immer über das Device. So ist es in FHEM auch organisiert. Löst man ein Kommando für einen Kanal aus wir dies in die Abarbeitungsliste der Device gestellt. Je nach Komminukationstyp arbeitet FHEM die Liste schnellstmöglch ab. <br><br />
Hierbei ist zu beachten, dass an die Devices über ein oder mehrere IOs gesendet wird. Auch hier wird wieder der Reihe nach vorgegangen, ein Device nach dem anderen. <br><br />
Wir haben also gelernt, dass Kommandos, welche FHEM senden will, in den Kommando-Queues der Devices abgelegt werden. Will nun sehen, ob schon alles erledigt ist, oder ob Fehler aufgetreten sind, muss man den Status der Kommando-queue lesen. Dieser wird in den '''Internals''' welche mit '''[[prot]]''' (Protokol) beginnend ermittelt.<br />
*'''protState''':Der gesamt-Zustand der Queue. <br />
**[[CMDs_done]]: Alle Kommandos übertragen, es sind bei [[der letzten]] Übertragung keine Fehler aufgetreten<br />
**[[CMDs_done_Errors:<no>]]: Alle Kommandos übertragen, es sind bei [[der letzten]] Fehler aufgetreten<br />
**[[CMDs_pending]]: Es stehen Kommandos zur Übertragung an. Es wird auf die Möglichkeit der Übertragung gewartet. Bspw. auf das Aufwachen eine wakeup Devices.<br />
**[[CMDs_processing...]]: Die Kommandos aus der Queue werden gerade abgearbeitet. Dies kann je nach Device und Menge auch etwas dauern. <br />
*'''protLastRcv''': Zeitpunkt der letzten empfangenen Nachricht dieses Device<br />
*'''protSnd''': Zählt die gesenderen Nachrichten und zeigt den letzten Sendezetpunkt an. <br />
*'''protCmdPend''': Anzahl der in der Kommando-Queue wartenden Nachrichten<br />
*'''protResnd''': Anzahl der (erfolgreich) wiederholten Nachrichten <br />
*'''protCmdDel''': Anzahl der auf Grund von Übertragungsproblemen gelöchten Nachrichten<br />
*'''protResndFail''': Anzahl der Wiederholungen welche nicht erfolgreich abgschlossen werden konnten<br />
*'''protNack''': Anzahl der negativen Acknowledges, welche vom Devices empfangen wurden. <br />
*'''protIOerr''': Anzahl der Fehler, IO bedingt.<br />
===HMinfo Support zu Protokoll Ereignissen===<br />
Da nun einiges kontinuierlich passiert und die Anzahl der Devices typisch steigt bedarf es eine Übersicht, den Zustand des Systems zu überwachen:<br />
get hm protoEvents<br />
zeigt eine Tabelle aller Devices, deren Zustand der Kommando-Queue und eine Statitik der Übertragungen. Nach dem '#' sollten keine Zähler stehen. Die dortigen bedeuten, dass einige Kommandos gelöscht wurden. <br />
Im Nachspann stehen Informationen über weitere Queues con CUL_HM. So bspw devices bei welchen FHEM die Register noch lesen will (autoReadReg) falls dies über ein entsprechendes Attribut eingestellt wurde. <br><br />
Will man aufräumen kann man <br />
set hm clearG msgEvents # löscht alle Zähler und [[leert die Kommando-Queue]] '''aller''' Devices<br />
set hm clearG msgErrors # löscht alle Zähler der Devices welche Fehler anzeigen.<br />
Ein Löschen ist gelegentlich sinnvoll, da Fehler kontinuierlch akkumuliert werden. Wenn man die Fehler nun erfasst hat kann man diese zurücksetzen um neu auftretende besser zu erkennen. <br />
==Kommunikation Timing==<br />
Die Kommunikation setzt ein straffes Timing der Nachrichtenübermittlung voraus. Eine Nachricht muss in einem Zeitfenster von 100ms-250ms nach senden beantwortet werden. Aufgrund der Natur von FHEM mit IOs welche über unzureichende Betriebssysteme angeschlossen werden kann das Timing nur schwer gewährleistet werden. Verzogerungen durch LAN oder USB müssen berechnet werden<br />
*HM-IOs: IO Devices von eq3 stellen eine Zeitstempel bereit welcher zur Kalkulation der Verzögerung genutzt werden kann. Das funktioniert in der Regel problemlos<br />
*CUL: Da die CUL keinen Zeitstempel zu Verfügung stellt ist sie für HM Kommunikation nicht zu brauchen. Siehe TSCUL<br />
*TSCUL: Durch einen FW Update kann eine CUL einen Zeitstempel generieren und schicken welcher diese dann <br />
einem HM-IO gleichwertig macht. <br />
Das Timing kann aber auch durch Verzögerungen auf den Rechner, innerhalb oder ausserhalb von FHEM gestört werden, wenn langsame oder hochpriore Tasks den Ablauf stören. apptime kann genutzt werden um verzögerungen im System aufzudecken.<br />
pairen: ist eine besondere Herausforderung. Hier müssen ggf. erst entities in FHEM angelegt werden, bevor geantwortet werden kann. Es ist nicht sinnvoll nach einem ersten pairing Versuch alle Entites aus FHEM wieder zu löschen. Sollte das pairen nicht funktioniert haben kann man die Kommando Queue leeren (set hm clearG msgEvents) und dann einen neuen Versuch starten. <br />
<br />
[[Kategorie:HomeMatic supportDevice]]<br />
[[Kategorie:HOWTOS]]</div>Martinp876http://wiki.fhem.de/w/index.php?title=HMinfo_Protokoll&diff=24314HMinfo Protokoll2018-01-04T20:12:40Z<p>Martinp876: </p>
<hr />
<div>{{Infobox Modul<br />
|ModPurpose=HM Protokollereignisse kontrollieren<br />
|ModType=h<br />
|ModCmdRef=HMinfo<br />
|ModForumArea=HomeMatic<br />
|ModTechName=98_HMinfo.pm<br />
|ModOwner=martinp876 ({{Link2FU|251|martinp876}} / [[Benutzer Diskussion:Martinp876|Wiki]])<br />
}}<br />
<br />
Homematic Geräte mit Funkprotokoll haben Eigenheiten welche man verstehen und überwachen muss, so man sein System unter Konrolle haben will. <br />
HMInfo ist ein Modul welches Methoden zu Verfügung stellt, damit umzugehen. <br />
Behandelt wird hier ausschliesslich die Homematic Funkprotokoll. <br />
<br />
=Das Protokoll=<br />
Das Protokoll beruht in der Regel auf einem Handshake Verfahren. Nachrichten müssen von Empfänger quittert werden. Um mit einem Device kommunizieren zu können muss es allerdings empfangsbereit sein. Man muss die Devicetypen daher unterscheiden<br />
==Kommunikationstypen==<br />
Homematic bietet unterschiedliche Devices, teils batteriebetrieben. Die Energieversorgung ist der wesentliche Grund unterschiedliche Typen zu etablieren. Sollte ein batteriebetriebenes Device kontinuierlich auf Empfang sein senkt das die Lebensdauer der Batterie erheblich. Somit unterscheidet man<br />
* '''[[Config]]''':Dieser Modus wird von [[allen]] Devices unterstützt. Hierbei wird das Device durch drücken einer Taste (typisch einer separaten, versteckten Taste) in den Mode versetzt. Die Taste wird gelegentlich auch Anlerntaste genannt. Das Device sendet hierbei eine Konfigmessage und bleibt einige Sekunden auf Empfang. Ein anderes Device hat nun die Chance mit dem Device zu kommunizieren.<br />
:Dieser Mode wird gerne zum Pairen genutzt. <br />
:Die FHEM Zentrale erkennt die Message und startet die Abarbeitung eventuell anhängiger Messages<br />
* '''[[normal]]''':Typischerweise wird dieser Mode von allen Devices mit permanenter Stromversorgung unterstützt. Das Device ist kontinuierlich auf Empfang. Config wird von diesen Devices typisch nur zum pairen genutzt<br />
* '''[[wakeup]]''':Batteriebetriebene Devices welche regelmäßig senden stellen gerne diesen Modus bereit. Einige Devices welche regelmäßig senden (Thermostate oder Fühler) bleiben nach senden der zyklischen Nachricht kurz auf Empfang. FHEM erkennt dies und sendet gegebenenfalls anhängige Nachrichten und Abfragen. <br />
* '''[[lazyConf]]''':Einige modernere Devices, betteriebetrieben und unregemäßig sendent, stellen einen trägen Config mode bereit. Hierbei bleibt das Device auf Empfang, wenn dies einen Trigger gesendet hat. <br />
:Beispiel ist eine Fernbedienung welche nach drücken eines Buttons den Trigger sendet und dann kurz auf weitere Nachrichten wartet. Auch einige Bewegungsmelder unterstützen dies. Hier muss man also einen Trigger auslösen (Bewegung). Das Device reagiert nicht nach dem Senden der zyklischen Nachrichten.<br />
:Erfahrungsgemäß funktioniert dies allerdings nur, wenn das Device den Trigger an die Zentrale sendet. Es ist also ratsam, alle Kanäle (jeden einzeln) mit einem Kanal der Zentrale zu peeren. Es biete sich an, einen virtuellen Button der Zentrale zu nutzen, welche man mit allen Kanälen aller LazyConfig Devices peert.<br />
* '''[[burst]]''':Burst ist ein Verfahren, schlafende Devices aufzuwecken. Einige sind im Dämmerschlaf und können durch einen Burst aufgeweckt werden. Burst ist ein Kommandosequenz welche der Initiator senden muss. Diese ist aufwändig, verbraucht einiges an Funkperformance (1% Regel) und weckt [[alle]] Burst Devices gleichzeitig auf. Als Daumenregel kann ein Device in einer Stunde 100 Bursts senden bevor die 1% Regel zuschlägt. <br />
:SD (Rauchdetektoren) verwenden tyisch burst. Sie müssen empfangsbereit sein, laufen mit Batterie und müssen demnach Sparsam sein. <br />
* '''[[burstCond]]''':ist eine Variante des Burst. Der Burstmode kann bei ihnen freigeschaltet werden. Beispielsweise RT (Heizungsthermosrate) nutzen diesen Mode. Ein RT sendet regelmäßig seinen Status - und hierbei kann man über wakeup mit dem Device alle 3min kommunizieren. Nun muss ein RT aber auf Fensterkontakte reagieren können. Diese senden Asynchron. Man muss also sicherstellen, dass der Fensterkontakt einen Burst sendet und der RT auf Burst reagiert. <br />
:Conditional Burst wird in einem Register freigeschaltet. <br />
:Devices mit CondBurst stellen ein Kommando BurstXmit bereit. Hierbei wird von FHEM ein Burst gesendet und ene eventuell anstehende Kommunikation wird durhgeführt. <br />
:BurstXmit sollte nur bei Bedarf, beim Configurieren, genutzt werden. Typisch sollte man auf das normale erwachen des Devices warten um die Kommunikation nicht zu belasten. <br />
:In einem Sender (Fensterkontakt) Muss "peerNeedsBurst" einegeschaltet werden, wenn dieses mit einem Burst-Device gepeert ist. <br />
===HMinfo Kommandos zum Devicetyp===<br />
Um nun festzustellen, welchen Devicetyp man vorliegen hat kann man über das Attribut model seines Device in HMinfo klären<br />
get hm models<br />
get hm models -f <regexp><br />
get hm models -f SD<br />
==FHEM Kommunikation==<br />
FHEM kennt alle Kommunikationstypen und behandelt diese entsprechend. Zu beachten ist, dass ein HM Gerät aus mehreren Entities besteht: Ein Device und ein oder mehrere Kanäle. Man kann mit den Kanälen nicht direkt kommunizieren. Die Kommunikation geht immer über das Device. So ist es in FHEM auch organisiert. Löst man ein Kommando für einen Kanal aus wir dies in die Abarbeitungsliste der Device gestellt. Je nach Komminukationstyp arbeitet FHEM die Liste schnellstmöglch ab. <br><br />
Hierbei ist zu beachten, dass an die Devices über ein oder mehrere IOs gesendet wird. Auch hier wird wieder der Reihe nach vorgegangen, ein Device nach dem anderen. <br><br />
Wir haben also gelernt, dass Kommandos, welche FHEM senden will, in den Kommando-Queues der Devices abgelegt werden. Will nun sehen, ob schon alles erledigt ist, oder ob Fehler aufgetreten sind, muss man den Status der Kommando-queue lesen. Dieser wird in den '''Internals''' welche mit '''[[prot]]''' (Protokol) beginnend ermittelt.<br />
*'''protState''':Der gesamt-Zustand der Queue. <br />
**[[CMDs_done]]: Alle Kommandos übertragen, es sind bei [[der letzten]] Übertragung keine Fehler aufgetreten<br />
**[[CMDs_done_Errors:<no>]]: Alle Kommandos übertragen, es sind bei [[der letzten]] Fehler aufgetreten<br />
**[[CMDs_pending]]: Es stehen Kommandos zur Übertragung an. Es wird auf die Möglichkeit der Übertragung gewartet. Bspw. auf das Aufwachen eine wakeup Devices.<br />
**[[CMDs_processing...]]: Die Kommandos aus der Queue werden gerade abgearbeitet. Dies kann je nach Device und Menge auch etwas dauern. <br />
*'''protLastRcv''': Zeitpunkt der letzten empfangenen Nachricht dieses Device<br />
*'''protSnd''': Zählt die gesenderen Nachrichten und zeigt den letzten Sendezetpunkt an. <br />
*'''protCmdPend''': Anzahl der in der Kommando-Queue wartenden Nachrichten<br />
*'''protResnd''': Anzahl der (erfolgreich) wiederholten Nachrichten <br />
*'''protCmdDel''': Anzahl der auf Grund von Übertragungsproblemen gelöchten Nachrichten<br />
*'''protResndFail''': Anzahl der Wiederholungen welche nicht erfolgreich abgschlossen werden konnten<br />
*'''protNack''': Anzahl der negativen Acknowledges, welche vom Devices empfangen wurden. <br />
*'''protIOerr''': Anzahl der Fehler, IO bedingt.<br />
===HMinfo Support zu Protokoll Ereignissen===<br />
Da nun einiges kontinuierlich passiert und die Anzahl der Devices typisch steigt bedarf es eine Übersicht, den Zustand des Systems zu überwachen:<br />
get hm protoEvents<br />
zeigt eine Tabelle aller Devices, deren Zustand der Kommando-Queue und eine Statitik der Übertragungen. Nach dem '#' sollten keine Zähler stehen. Die dortigen bedeuten, dass einige Kommandos gelöscht wurden. <br />
Im Nachspann stehen Informationen über weitere Queues con CUL_HM. So bspw devices bei welchen FHEM die Register noch lesen will (autoReadReg) falls dies über ein entsprechendes Attribut eingestellt wurde. <br><br />
Will man aufräumen kann man <br />
set hm clearG msgEvents # löscht alle Zähler und [[leert die Kommando-Queue]] '''aller''' Devices<br />
set hm clearG msgErrors # löscht alle Zähler der Devices welche Fehler anzeigen.<br />
Ein Löschen ist gelegentlich sinnvoll, da Fehler kontinuierlch akkumuliert werden. Wenn man die Fehler nun erfasst hat kann man diese zurücksetzen um neu auftretende besser zu erkennen. <br />
==Kommunikation Timing==<br />
Die Kommunikation setzt ein straffes Timing der Nachrichtenübermittlung voraus. Eine Nachricht muss in einem Zeitfenster von 100ms-250ms nach senden beantwortet werden. Aufgrund der Natur von FHEM mit IOs welche über unzureichende Betriebssysteme angeschlossen werden kann das Timing nur schwer gewährleistet werden. Verzogerungen durch LAN oder USB müssen berechnet werden<br />
*HM-IOs: IO Devices von eq3 stellen eine Zeitstempel bereit welcher zur Kalkulation der Verzögerung genutzt werden kann. Das funktioniert in der Regel problemlos<br />
*CUL: Da die CUL keinen Zeitstempel zu verfügung stellt ist sie für HM Kommunikation nicht zu brauchen. Siehe TSCUL<br />
*TSCUL: Durch einen FW Update kann eine CUL einen Zeitstempel generieren und schicken welcher diese dann <br />
einem HM-IO gleichwertig macht. <br />
Das Timing kann aber auch durch Verzögerungen auf den Rechner, innerhalb oder ausserhalb von FHEM gestört werden, wenn langsame oder hochpriore Tasks den Ablauf stören. apptime kann genutzt werden um verzögerungen im System aufzudecken.<br />
pairen: ist eine besondere Herausforderung. Hier müssen ggf. erst entities in FHEM angelegt werden, bevor geantwortet werden kann. Es ist nicht sinnvoll nach einem ersten pairing Versuch alle Entites aus FHEM wieder zu löschen. Sollte das pairen nicht funktioniert haben kann man die Kommando Queue leeren (set hm clearG msgEvents) und dann einen neuen Versuch starten. <br />
<br />
[[Kategorie:HomeMatic supportDevice]]<br />
[[Kategorie:HOWTOS]]</div>Martinp876http://wiki.fhem.de/w/index.php?title=HMinfo_Protokoll&diff=24312HMinfo Protokoll2018-01-04T19:58:58Z<p>Martinp876: </p>
<hr />
<div>{{Infobox Modul<br />
|ModPurpose=HM Protokollereignisse kontrollieren<br />
|ModType=h<br />
|ModCmdRef=HMinfo<br />
|ModForumArea=HomeMatic<br />
|ModTechName=98_HMinfo.pm<br />
|ModOwner=martinp876 ({{Link2FU|251|martinp876}} / [[Benutzer Diskussion:Martinp876|Wiki]])<br />
}}<br />
<br />
Homematic Geräte mit Funkprotokoll haben Eigenheiten welche man verstehen und überwachen muss, so man sein System unter Konrolle haben will. <br />
HMInfo ist ein Modul welches Methoden zu Verfügung stellt, damit umzugehen. <br />
Behandelt wird hier ausschliesslich die Homematic Funkprotokoll. <br />
<br />
=Das Protokoll=<br />
Das Protokoll beruht in der Regel auf einem Handshake Verfahren. Nachrichten müssen von Empfänger quittert werden. Um mit einem Device kommunizieren zu können muss es allerdings empfangsbereit sein. Man muss die Devicetypen daher unterscheiden<br />
==Kommunikationstypen==<br />
Homematic bietet unterschiedliche Devices, teils batteriebetrieben. Die Energieversorgung ist der wesentliche Grund unterschiedliche Typen zu etablieren. Sollte ein batteriebetriebenes Device kontinuierlich auf Empfang sein senkt das die Lebensdauer der Batterie erheblich. Somit unterscheidet man<br />
* '''[[Config]]''':Dieser Modus wird von [[allen]] Devices unterstützt. Hierbei wird das Device durch drücken einer Taste (typisch einer separaten, versteckten Taste) in den Mode versetzt. Die Taste wird gelegentlich auch Anlerntaste genannt. Das Device sendet hierbei eine Konfigmessage und bleibt einige Sekunden auf Empfang. Ein anderes Device hat nun die Chance mit dem Device zu kommunizieren.<br />
:Dieser Mode wird gerne zum Pairen genutzt. <br />
:Die FHEM Zentrale erkennt die Message und startet die Abarbeitung eventuell anhängiger Messages<br />
* '''[[normal]]''':Typischerweise wird dieser Mode von allen Devices mit permanenter Stromversorgung unterstützt. Das Device ist kontinuierlich auf Empfang. Config wird von diesen Devices typisch nur zum pairen genutzt<br />
* '''[[wakeup]]''':Batteriebetriebene Devices welche regelmäßig senden stellen gerne diesen Modus bereit. Einige Devices welche regelmäßig senden (Thermostate oder Fühler) bleiben nach senden der zyklischen Nachricht kurz auf Empfang. FHEM erkennt dies und sendet gegebenenfalls anhängige Nachrichten und Abfragen. <br />
* '''[[lazyConf]]''':Einige modernere Devices, betteriebetrieben und unregemäßig sendent, stellen einen trägen Config mode bereit. Hierbei bleibt das Device auf Empfang, wenn dies einen Trigger gesendet hat. <br />
:Beispiel ist eine Fernbedienung welche nach drücken eines Buttons den Trigger sendet und dann kurz auf weitere Nachrichten wartet. Auch einige Bewegungsmelder unterstützen dies. Hier muss man also einen Trigger auslösen (Bewegung). Das Device reagiert nicht nach dem Senden der zyklischen Nachrichten.<br />
:Erfahrungsgemäß funktioniert dies allerdings nur, wenn das Device den Trigger an die Zentrale sendet. Es ist also ratsam, alle Kanäle (jeden einzeln) mit einem Kanal der Zentrale zu peeren. Es biete sich an, einen virtuellen Button der Zentrale zu nutzen, welche man mit allen Kanälen aller LazyConfig Devices peert.<br />
* '''[[burst]]''':Burst ist ein Verfahren, schlafende Devices aufzuwecken. Einige sind im Dämmerschlaf und können durch einen Burst aufgeweckt werden. Burst ist ein Kommandosequenz welche der Initiator senden muss. Diese ist aufwändig, verbraucht einiges an Funkperformance (1% Regel) und weckt [[alle]] Burst Devices gleichzeitig auf. Als Daumenregel kann ein Device in einer Stunde 100 Bursts senden bevor die 1% Regel zuschlägt. <br />
:SD (Rauchdetektoren) verwenden tyisch burst. Sie müssen empfangsbereit sein, laufen mit Batterie und müssen demnach Sparsam sein. <br />
* '''[[burstCond]]''':ist eine Variante des Burst. Der Burstmode kann bei ihnen freigeschaltet werden. Beispielsweise RT (Heizungsthermosrate) nutzen diesen Mode. Ein RT sendet regelmäßig seinen Status - und hierbei kann man über wakeup mit dem Device alle 3min kommunizieren. Nun muss ein RT aber auf Fensterkontakte reagieren können. Diese senden Asynchron. Man muss also sicherstellen, dass der Fensterkontakt einen Burst sendet und der RT auf Burst reagiert. <br />
:Conditional Burst wird in einem Register freigeschaltet. <br />
:Devices mit CondBurst stellen ein Kommando BurstXmit bereit. Hierbei wird von FHEM ein Burst gesendet und ene eventuell anstehende Kommunikation wird durhgeführt. <br />
:BurstXmit sollte nur bei Bedarf, beim Configurieren, genutzt werden. Typisch sollte man auf das normale erwachen des Devices warten um die Kommunikation nicht zu belasten. <br />
:In einem Sender (Fensterkontakt) Muss "peerNeedsBurst" einegeschaltet werden, wenn dieses mit einem Burst-Device gepeert ist. <br />
===HMinfo Kommandos zum Devicetyp===<br />
Um nun festzustellen, welchen Devicetyp man vorliegen hat kann man über das Attribut model seines Device in HMinfo klären<br />
get hm models<br />
get hm models -f <regexp><br />
get hm models -f SD<br />
==FHEM Kommunikation==<br />
FHEM kennt alle Kommunikationstypen und behandelt diese entsprechend. Zu beachten ist, dass ein HM Gerät aus mehreren Entities besteht: Ein Device und ein oder mehrere Kanäle. Man kann mit den Kanälen nicht direkt kommunizieren. Die Kommunikation geht immer über das Device. So ist es in FHEM auch organisiert. Löst man ein Kommando für einen Kanal aus wir dies in die Abarbeitungsliste der Device gestellt. Je nach Komminukationstyp arbeitet FHEM die Liste schnellstmöglch ab. <br><br />
Hierbei ist zu beachten, dass an die Devices über ein oder mehrere IOs gesendet wird. Auch hier wird wieder der Reihe nach vorgegangen, ein Device nach dem anderen. <br><br />
Wir haben also gelernt, dass Kommandos, welche FHEM senden will, in den Kommando-Queues der Devices abgelegt werden. Will nun sehen, ob schon alles erledigt ist, oder ob Fehler aufgetreten sind, muss man den Status der Kommando-queue lesen. Dieser wird in den '''Internals''' welche mit '''[[prot]]''' (Protokol) beginnend ermittelt.<br />
*'''protState''':Der gesamt-Zustand der Queue. <br />
**[[CMDs_done]]: Alle Kommandos übertragen, es sind bei [[der letzten]] Übertragung keine Fehler aufgetreten<br />
**[[CMDs_done_Errors:<no>]]: Alle Kommandos übertragen, es sind bei [[der letzten]] Fehler aufgetreten<br />
**[[CMDs_pending]]: Es stehen Kommandos zur Übertragung an. Es wird auf die Möglichkeit der Übertragung gewartet. Bspw. auf das Aufwachen eine wakeup Devices.<br />
**[[CMDs_processing...]]: Die Kommandos aus der Queue werden gerade abgearbeitet. Dies kann je nach Device und Menge auch etwas dauern. <br />
*'''protLastRcv''': Zeitpunkt der letzten empfangenen Nachricht dieses Device<br />
*'''protSnd''': Zählt die gesenderen Nachrichten und zeigt den letzten Sendezetpunkt an. <br />
*'''protCmdPend''': Anzahl der in der Kommando-Queue wartenden Nachrichten<br />
*'''protResnd''': Anzahl der (erfolgreich) wiederholten Nachrichten <br />
*'''protCmdDel''': Anzahl der auf Grund von Übertragungsproblemen gelöchten Nachrichten<br />
*'''protResndFail''': Anzahl der Wiederholungen welche nicht erfolgreich abgschlossen werden konnten<br />
*'''protNack''': Anzahl der negativen Acknowledges, welche vom Devices empfangen wurden. <br />
*'''protIOerr''': Anzahl der Fehler, IO bedingt.<br />
===HMinfo Support zu Protokoll Ereignissen===<br />
Da nun einiges kontinuierlich passiert und die Anzahl der Devices typisch steigt bedarf es eine Übersicht, den Zustand des Systems zu überwachen:<br />
get hm protoEvents<br />
zeigt eine Tabelle aller Devices, deren Zustand der Kommando-Queue und eine Statitik der Übertragungen. Nach dem '#' sollten keine Zähler stehen. Die dortigen bedeuten, dass einige Kommandos gelöscht wurden. <br />
Im Nachspann stehen Informationen über weitere Queues con CUL_HM. So bspw devices bei welchen FHEM die Register noch lesen will (autoReadReg) falls dies über ein entsprechendes Attribut eingestellt wurde. <br><br />
Will man aufräumen kann man <br />
set hm clearG msgEvents # löscht alle Zähler und [[leert die Kommando-Queue]] '''aller''' Devices<br />
set hm clearG msgErrors # löscht alle Zähler der Devices welche Fehler anzeigen.<br />
Ein Löschen ist gelegentlich sinnvoll, da Fehler kontinuierlch akkumuliert werden. Wenn man die Fehler nun erfasst hat kann man diese zurücksetzen um neu auftretende besser zu erkennen. <br />
<br />
<br />
[[Kategorie:HomeMatic supportDevice]]<br />
[[Kategorie:HOWTOS]]</div>Martinp876http://wiki.fhem.de/w/index.php?title=HMinfo_Protokoll&diff=24311HMinfo Protokoll2018-01-04T19:28:32Z<p>Martinp876: </p>
<hr />
<div>{{Infobox Modul<br />
|ModPurpose=HM Protokollereignisse kontrollieren<br />
|ModType=h<br />
|ModCmdRef=HMinfo<br />
|ModForumArea=HomeMatic<br />
|ModTechName=98_HMinfo.pm<br />
|ModOwner=martinp876 ({{Link2FU|251|martinp876}} / [[Benutzer Diskussion:Martinp876|Wiki]])<br />
}}<br />
<br />
Homematic Geräte mit Funkprotokoll haben Eigenheiten welche man verstehen und überwachen muss, so man sein System unter Konrolle haben will. <br />
HMInfo ist ein Modul welches Methoden zu Verfügung stellt, damit umzugehen. <br />
Behandelt wird hier ausschliesslich die Homematic Funkprotokoll. <br />
<br />
=Das Protokoll=<br />
Das Protokoll beruht in der Regel auf einem Handshake Verfahren. Nachrichten müssen von Empfänger quittert werden. Um mit einem Device kommunizieren zu können muss es allerdings empfangsbereit sein. Man muss die Devicetypen daher unterscheiden<br />
==Kommunikationstypen==<br />
Homematic bietet unterschiedliche Devices, teils batteriebetrieben. Die Energieversorgung ist der wesentliche Grund unterschiedliche Typen zu etablieren. Sollte ein batteriebetriebenes Device kontinuierlich auf Empfang sein senkt das die Lebensdauer der Batterie erheblich. Somit unterscheidet man<br />
* '''[[Config]]''':Dieser Modus wird von [[allen]] Devices unterstützt. Hierbei wird das Device durch drücken einer Taste (typisch einer separaten, versteckten Taste) in den Mode versetzt. Die Taste wird gelegentlich auch Anlerntaste genannt. Das Device sendet hierbei eine Konfigmessage und bleibt einige Sekunden auf Empfang. Ein anderes Device hat nun die Chance mit dem Device zu kommunizieren.<br />
:Dieser Mode wird gerne zum Pairen genutzt. <br />
:Die FHEM Zentrale erkennt die Message und startet die Abarbeitung eventuell anhängiger Messages<br />
* '''[[normal]]''':Typischerweise wird dieser Mode von allen Devices mit permanenter Stromversorgung unterstützt. Das Device ist kontinuierlich auf Empfang. Config wird von diesen Devices typisch nur zum pairen genutzt<br />
* '''[[wakeup]]''':Batteriebetriebene Devices welche regelmäßig senden stellen gerne diesen Modus bereit. Einige Devices welche regelmäßig senden (Thermostate oder Fühler) bleiben nach senden der zyklischen Nachricht kurz auf Empfang. FHEM erkennt dies und sendet gegebenenfalls anhängige Nachrichten und Abfragen. <br />
* '''[[lazyConf]]''':Einige modernere Devices, betteriebetrieben und unregemäßig sendent, stellen einen trägen Config mode bereit. Hierbei bleibt das Device auf Empfang, wenn dies einen Trigger gesendet hat. <br />
:Beispiel ist eine Fernbedienung welche nach drücken eines Buttons den Trigger sendet und dann kurz auf weitere Nachrichten wartet. Auch einige Bewegungsmelder unterstützen dies. Hier muss man also einen Trigger auslösen (Bewegung). Das Device reagiert nicht nach dem Senden der zyklischen Nachrichten.<br />
:Erfahrungsgemäß funktioniert dies allerdings nur, wenn das Device den Trigger an die Zentrale sendet. Es ist also ratsam, alle Kanäle (jeden einzeln) mit einem Kanal der Zentrale zu peeren. Es biete sich an, einen virtuellen Button der Zentrale zu nutzen, welche man mit allen Kanälen aller LazyConfig Devices peert.<br />
* '''[[burst]]''':Burst ist ein Verfahren, schlafende Devices aufzuwecken. Einige sind im Dämmerschlaf und können durch einen Burst aufgeweckt werden. Burst ist ein Kommandosequenz welche der Initiator senden muss. Diese ist aufwändig, verbraucht einiges an Funkperformance (1% Regel) und weckt [[alle]] Burst Devices gleichzeitig auf. Als Daumenregel kann ein Device in einer Stunde 100 Bursts senden bevor die 1% Regel zuschlägt. <br />
:SD (Rauchdetektoren) verwenden tyisch burst. Sie müssen empfangsbereit sein, laufen mit Batterie und müssen demnach Sparsam sein. <br />
* '''[[burstCond]]''':ist eine Variante des Burst. Der Burstmode kann bei ihnen freigeschaltet werden. Beispielsweise RT (Heizungsthermosrate) nutzen diesen Mode. Ein RT sendet regelmäßig seinen Status - und hierbei kann man über wakeup mit dem Device alle 3min kommunizieren. Nun muss ein RT aber auf Fensterkontakte reagieren können. Diese senden Asynchron. Man muss also sicherstellen, dass der Fensterkontakt einen Burst sendet und der RT auf Burst reagiert. <br />
:Conditional Burst wird in einem Register freigeschaltet. <br />
:Devices mit CondBurst stellen ein Kommando BurstXmit bereit. Hierbei wird von FHEM ein Burst gesendet und ene eventuell anstehende Kommunikation wird durhgeführt. <br />
:BurstXmit sollte nur bei Bedarf, beim Configurieren, genutzt werden. Typisch sollte man auf das normale erwachen des Devices warten um die Kommunikation nicht zu belasten. <br />
:In einem Sender (Fensterkontakt) Muss "peerNeedsBurst" einegeschaltet werden, wenn dieses mit einem Burst-Device gepeert ist. <br />
===HMinfo Kommandos zum Devicetyp===<br />
Um nun festzustellen, welchen Devicetyp man vorliegen hat kann man über das Attribut model seines Device in HMinfo klären<br />
get hm models<br />
get hm models -f <regexp><br />
get hm models -f SD<br />
==FHEM Kommunikation==<br />
FHEM kennt alle Kommunikationstypen und behandelt diese entsprechend. Zu beachten ist, dass ein HM Gerät aus mehreren Entities besteht: Ein Device und ein oder mehrere Kanäle. Man kann mit den Kanälen nicht direkt kommunizieren. Die Kommunikation geht immer über das Device. So ist es in FHEM auch organisiert. Löst man ein Kommando für einen Kanal aus wir dies in die Abarbeitungsliste der Device gestellt. Je nach Komminukationstyp arbeitet FHEM die Liste schnellstmöglch ab. <br><br />
Hierbei ist zu beachten, dass an die Devices über ein oder mehrere IOs gesendet wird. Auch hier wird wieder der Reihe nach vorgegangen, ein Device nach dem anderen. <br><br />
Wir haben also gelernt, dass Kommandos, welche FHEM senden will, in den Kommando-Queues der Devices abgelegt werden. Will nun sehen, ob schon alles erledigt ist, oder ob Fehler aufgetreten sind, muss man den Status der Kommando-queue lesen. Dieser wird in den '''Internals''' welche mit '''[[prot]]''' (Protokol) beginnend ermittelt.<br />
*'''protState''':Der gesamt-Zustand der Queue. <br />
**[[CMDs_done]]: Alle Kommandos übertragen, es sind bei [[der letzten]] Übertragung keine Fehler aufgetreten<br />
**[[CMDs_done_Errors:<no>]]: Alle Kommandos übertragen, es sind bei [[der letzten]] Fehler aufgetreten<br />
**[[CMDs_pending]]: Es stehen Kommandos zur Übertragung an. Es wird auf die Möglichkeit der Übertragung gewartet. Bspw. auf das Aufwachen eine wakeup Devices.<br />
**[[CMDs_processing...]]: Die Kommandos aus der Queue werden gerade abgearbeitet. Dies kann je nach Device und Menge auch etwas dauern. <br />
*'''protLastRcv''': Zeitpunkt der letzten empfangenen Nachricht dieses Device<br />
*'''protSnd''': Zählt die gesenderen Nachrichten und zeigt den letzten Sendezetpunkt an. <br />
*'''protCmdPend''': Anzahl der in der Kommando-Queue wartenden Nachrichten<br />
*'''protResnd''': Anzahl der (erfolgreich) wiederholten Nachrichten <br />
*'''protCmdDel''': Anzahl der auf Grund von Übertragungsproblemen gelöchten Nachrichten<br />
*'''protResndFail''': Anzahl der Wiederholungen welche nicht erfolgreich abgschlossen werden konnten<br />
*'''protNack''': Anzahl der negativen Acknowledges, welche vom Devices empfangen wurden. <br />
*'''protIOerr''': Anzahl der Fehler, IO bedingt.<br />
<br />
<br />
[[Kategorie:HomeMatic supportDevice]]<br />
[[Kategorie:HOWTOS]]</div>Martinp876http://wiki.fhem.de/w/index.php?title=HMinfo_Protokoll&diff=24310HMinfo Protokoll2018-01-04T19:09:02Z<p>Martinp876: </p>
<hr />
<div>{{Infobox Modul<br />
|ModPurpose=HM Protokollereignisse kontrollieren<br />
|ModType=h<br />
|ModCmdRef=HMinfo<br />
|ModForumArea=HomeMatic<br />
|ModTechName=98_HMinfo.pm<br />
|ModOwner=martinp876 ({{Link2FU|251|martinp876}} / [[Benutzer Diskussion:Martinp876|Wiki]])<br />
}}<br />
<br />
Homematic Geräte mit Funkprotokoll haben Eigenheiten welche man verstehen und überwachen muss, so man sein System unter Konrolle haben will. <br />
HMInfo ist ein Modul welches Methoden zu Verfügung stellt, damit umzugehen. <br />
Behandelt wird hier ausschliesslich die Homematic Funkprotokoll. <br />
<br />
=Das Protokoll=<br />
Das Protokoll beruht in der Regel auf einem Handshake Verfahren. Nachrichten müssen von Empfänger quittert werden. Um mit einem Device kommunizieren zu können muss es allerdings empfangsbereit sein. Man muss die Devicetypen daher unterscheiden<br />
==Kommunikationstypen==<br />
Homematic bietet unterschiedliche Devices, teils batteriebetrieben. Die Energieversorgung ist der wesentliche Grund unterschiedliche Typen zu etablieren. Sollte ein batteriebetriebenes Device kontinuierlich auf Empfang sein senkt das die Lebensdauer der Batterie erheblich. Somit unterscheidet man<br />
* '''[[Config]]''':Dieser Modus wird von [[allen]] Devices unterstützt. Hierbei wird das Device durch drücken einer Taste (typisch einer separaten, versteckten Taste) in den Mode versetzt. Die Taste wird gelegentlich auch Anlerntaste genannt. Das Device sendet hierbei eine Konfigmessage und bleibt einige Sekunden auf Empfang. Ein anderes Device hat nun die Chance mit dem Device zu kommunizieren.<br />
:Dieser Mode wird gerne zum Pairen genutzt. <br />
:Die FHEM Zentrale erkennt die Message und startet die Abarbeitung eventuell anhängiger Messages<br />
* '''[[normal]]''':Typischerweise wird dieser Mode von allen Devices mit permanenter Stromversorgung unterstützt. Das Device ist kontinuierlich auf Empfang. Config wird von diesen Devices typisch nur zum pairen genutzt<br />
* '''[[wakeup]]''':Batteriebetriebene Devices welche regelmäßig senden stellen gerne diesen Modus bereit. Einige Devices welche regelmäßig senden (Thermostate oder Fühler) bleiben nach senden der zyklischen Nachricht kurz auf Empfang. FHEM erkennt dies und sendet gegebenenfalls anhängige Nachrichten und Abfragen. <br />
* '''[[lazyConf]]''':Einige modernere Devices, betteriebetrieben und unregemäßig sendent, stellen einen trägen Config mode bereit. Hierbei bleibt das Device auf Empfang, wenn dies einen Trigger gesendet hat. <br />
:Beispiel ist eine Fernbedienung welche nach drücken eines Buttons den Trigger sendet und dann kurz auf weitere Nachrichten wartet. Auch einige Bewegungsmelder unterstützen dies. Hier muss man also einen Trigger auslösen (Bewegung). Das Device reagiert nicht nach dem Senden der zyklischen Nachrichten.<br />
:Erfahrungsgemäß funktioniert dies allerdings nur, wenn das Device den Trigger an die Zentrale sendet. Es ist also ratsam, alle Kanäle (jeden einzeln) mit einem Kanal der Zentrale zu peeren. Es biete sich an, einen virtuellen Button der Zentrale zu nutzen, welche man mit allen Kanälen aller LazyConfig Devices peert.<br />
* '''[[burst]]''':Burst ist ein Verfahren, schlafende Devices aufzuwecken. Einige sind im Dämmerschlaf und können durch einen Burst aufgeweckt werden. Burst ist ein Kommandosequenz welche der Initiator senden muss. Diese ist aufwändig, verbraucht einiges an Funkperformance (1% Regel) und weckt [[alle]] Burst Devices gleichzeitig auf. Als Daumenregel kann ein Device in einer Stunde 100 Bursts senden bevor die 1% Regel zuschlägt. <br />
:SD (Rauchdetektoren) verwenden tyisch burst. Sie müssen empfangsbereit sein, laufen mit Batterie und müssen demnach Sparsam sein. <br />
* '''[[burstCond]]''':ist eine Variante des Burst. Der Burstmode kann bei ihnen freigeschaltet werden. Beispielsweise RT (Heizungsthermosrate) nutzen diesen Mode. Ein RT sendet regelmäßig seinen Status - und hierbei kann man über wakeup mit dem Device alle 3min kommunizieren. Nun muss ein RT aber auf Fensterkontakte reagieren können. Diese senden Asynchron. Man muss also sicherstellen, dass der Fensterkontakt einen Burst sendet und der RT auf Burst reagiert. <br />
:Conditional Burst wird in einem Register freigeschaltet. <br />
:Devices mit CondBurst stellen ein Kommando BurstXmit bereit. Hierbei wird von FHEM ein Burst gesendet und ene eventuell anstehende Kommunikation wird durhgeführt. <br />
:BurstXmit sollte nur bei Bedarf, beim Configurieren, genutzt werden. Typisch sollte man auf das normale erwachen des Devices warten um die Kommunikation nicht zu belasten. <br />
:In einem Sender (Fensterkontakt) Muss "peerNeedsBurst" einegeschaltet werden, wenn dieses mit einem Burst-Device gepeert ist. <br />
===HMinfo Kommandos zum Devicetyp===<br />
Um nun festzustellen, welchen Devicetyp man vorliegen hat kann man über das Attribut model seines Device in HMinfo klären<br />
get hm models<br />
get hm models -f <regexp><br />
get hm models -f SD<br />
==FHEM Kommunikation==<br />
FHEM kennt alle Kommunikationstypen und behandelt diese entsprechend. Zu beachten ist, dass ein HM Gerät aus mehreren Entities besteht: Ein Device und ein oder mehrere Kanäle. Man kann mit den Kanälen nicht direkt kommunizieren. Die Kommunikation geht immer über das Device. So ist es in FHEM auch organisiert. Löst man ein Kommando für einen Kanal aus wir dies in die Abarbeitungsliste der Device gestellt. Je nach Komminukationstyp arbeitet FHEM die Liste schnellstmöglch ab. <br><br />
Hierbei ist zu beachten, dass an die Devices über ein oder mehrere IOs gesendet wird. Auch hier wird wieder der Reihe nach vorgegangen, ein Device nach dem anderen. <br><br />
Wir haben also gelernt, dass Kommandos, welche FHEM senden will, in den Kommando-Queues der Devices abgelegt werden. Will nun sehen, ob schon alles erledigt ist, oder ob Fehler aufgetreten sind, muss man den Status der Kommando-queue lesen. Dieser wird in den '''Internals''' welche mit '''[[prot]]''' (Protokol) beginnend ermittelt.<br />
*'''protState''':Der gesamt-Zustand der Queue. <br />
**CMDs_done<br />
<br />
[[Kategorie:HomeMatic supportDevice]]<br />
[[Kategorie:HOWTOS]]</div>Martinp876http://wiki.fhem.de/w/index.php?title=HMinfo_Protokoll&diff=24309HMinfo Protokoll2018-01-04T18:56:10Z<p>Martinp876: Die Seite wurde neu angelegt: „{{Infobox Modul |ModPurpose=HM Protokollereignisse kontrollieren |ModType=h |ModCmdRef=HMinfo |ModForumArea=HomeMatic |ModTechName=98_HMinfo.pm |ModOwner=marti…“</p>
<hr />
<div>{{Infobox Modul<br />
|ModPurpose=HM Protokollereignisse kontrollieren<br />
|ModType=h<br />
|ModCmdRef=HMinfo<br />
|ModForumArea=HomeMatic<br />
|ModTechName=98_HMinfo.pm<br />
|ModOwner=martinp876 ({{Link2FU|251|martinp876}} / [[Benutzer Diskussion:Martinp876|Wiki]])<br />
}}<br />
<br />
Homematic Geräte mit Funkprotokoll haben Eigenheiten welche man verstehen und überwachen muss, so man sein System unter Konrolle haben will. <br />
HMInfo ist ein Modul welches Methoden zu Verfügung stellt, damit umzugehen. <br />
Behandelt wird hier ausschliesslich die Homematic Funkprotokoll. <br />
<br />
=Das Protokoll=<br />
Das Protokoll beruht in der Regel auf einem Handshake Verfahren. Nachrichten müssen von Empfänger quittert werden. Um mit einem Device kommunizieren zu können muss es allerdings empfangsbereit sein. Man muss die Devicetypen daher unterscheiden<br />
==Kommunikationstypen==<br />
Homematic bietet unterschiedliche Devices, teils batteriebetrieben. Die Energieversorgung ist der wesentliche Grund unterschiedliche Typen zu etablieren. Sollte ein batteriebetriebenes Device kontinuierlich auf Empfang sein senkt das die Lebensdauer der Batterie erheblich. Somit unterscheidet man<br />
* '''[[Config]]''':Dieser Modus wird von [[allen]] Devices unterstützt. Hierbei wird das Device durch drücken einer Taste (typisch einer separaten, versteckten Taste) in den Mode versetzt. Die Taste wird gelegentlich auch Anlerntaste genannt. Das Device sendet hierbei eine Konfigmessage und bleibt einige Sekunden auf Empfang. Ein anderes Device hat nun die Chance mit dem Device zu kommunizieren.<br />
:Dieser Mode wird gerne zum Pairen genutzt. <br />
:Die FHEM Zentrale erkennt die Message und startet die Abarbeitung eventuell anhängiger Messages<br />
* '''[[normal]]''':Typischerweise wird dieser Mode von allen Devices mit permanenter Stromversorgung unterstützt. Das Device ist kontinuierlich auf Empfang. Config wird von diesen Devices typisch nur zum pairen genutzt<br />
* '''[[wakeup]]''':Batteriebetriebene Devices welche regelmäßig senden stellen gerne diesen Modus bereit. Einige Devices welche regelmäßig senden (Thermostate oder Fühler) bleiben nach senden der zyklischen Nachricht kurz auf Empfang. FHEM erkennt dies und sendet gegebenenfalls anhängige Nachrichten und Abfragen. <br />
* '''[[lazyConf]]''':Einige modernere Devices, betteriebetrieben und unregemäßig sendent, stellen einen trägen Config mode bereit. Hierbei bleibt das Device auf Empfang, wenn dies einen Trigger gesendet hat. <br />
:Beispiel ist eine Fernbedienung welche nach drücken eines Buttons den Trigger sendet und dann kurz auf weitere Nachrichten wartet. Auch einige Bewegungsmelder unterstützen dies. Hier muss man also einen Trigger auslösen (Bewegung). Das Device reagiert nicht nach dem Senden der zyklischen Nachrichten.<br />
:Erfahrungsgemäß funktioniert dies allerdings nur, wenn das Device den Trigger an die Zentrale sendet. Es ist also ratsam, alle Kanäle (jeden einzeln) mit einem Kanal der Zentrale zu peeren. Es biete sich an, einen virtuellen Button der Zentrale zu nutzen, welche man mit allen Kanälen aller LazyConfig Devices peert.<br />
* '''[[burst]]''':Burst ist ein Verfahren, schlafende Devices aufzuwecken. Einige sind im Dämmerschlaf und können durch einen Burst aufgeweckt werden. Burst ist ein Kommandosequenz welche der Initiator senden muss. Diese ist aufwändig, verbraucht einiges an Funkperformance (1% Regel) und weckt [[alle]] Burst Devices gleichzeitig auf. Als Daumenregel kann ein Device in einer Stunde 100 Bursts senden bevor die 1% Regel zuschlägt. <br />
:SD (Rauchdetektoren) verwenden tyisch burst. Sie müssen empfangsbereit sein, laufen mit Batterie und müssen demnach Sparsam sein. <br />
* '''[[burstCond]]''':ist eine Variante des Burst. Der Burstmode kann bei ihnen freigeschaltet werden. Beispielsweise RT (Heizungsthermosrate) nutzen diesen Mode. Ein RT sendet regelmäßig seinen Status - und hierbei kann man über wakeup mit dem Device alle 3min kommunizieren. Nun muss ein RT aber auf Fensterkontakte reagieren können. Diese senden Asynchron. Man muss also sicherstellen, dass der Fensterkontakt einen Burst sendet und der RT auf Burst reagiert. <br />
:Conditional Burst wird in einem Register freigeschaltet. <br />
:Devices mit CondBurst stellen ein Kommando BurstXmit bereit. Hierbei wird von FHEM ein Burst gesendet und ene eventuell anstehende Kommunikation wird durhgeführt. <br />
:BurstXmit sollte nur bei Bedarf, beim Configurieren, genutzt werden. Typisch sollte man auf das normale erwachen des Devices warten um die Kommunikation nicht zu belasten. <br />
:In einem Sender (Fensterkontakt) Muss "peerNeedsBurst" einegeschaltet werden, wenn dieses mit einem Burst-Device gepeert ist. <br />
==HMinfo Kommandos zum Devicetyp==<br />
Um nun festzustellen, welchen Devicetyp man vorliegen hat kann man über das Attribut model seines Device in HMinfo klären<br />
get hm models<br />
get hm models -f <regexp><br />
get hm models -f SD</div>Martinp876http://wiki.fhem.de/w/index.php?title=HMinfo&diff=24308HMinfo2018-01-04T16:39:15Z<p>Martinp876: </p>
<hr />
<div>{{Infobox Modul<br />
|ModPurpose=Übersicht über alle HomeMatic Geräte<br />
|ModType=h<br />
|ModCmdRef=HMinfo<br />
|ModForumArea=HomeMatic<br />
|ModTechName=98_HMinfo.pm<br />
|ModOwner=martinp876 ({{Link2FU|251|martinp876}} / [[Benutzer Diskussion:Martinp876|Wiki]])<br />
}}<br />
<br />
'''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. <br />
<br />
== Definition == <br />
HMInfo wird erstellt / angelegt mit dem Befehl<br />
:<code>define hm HMinfo</code><br />
<br />
Danach können alle Funktionen aufgelistet werden mit<br />
:<code>get hm help</code><br />
<br />
== Integritätsprüfungen ==<br />
Zur 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.<br />
<br />
Befehle, um die Gültigkeit von verschiedenen HomeMatic Eigenschaften zu überprüfen:<br />
<br />
=== peerCheck ===<br />
Mit dem Befehl <br />
:<code>get hm peerCheck</code><br />
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:<br />
;peer not verified. Check that peer is set on both sides <br />
:ausgegebener Wert (z.B.): actorChan p:switchChan<br />
: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).<br />
<br />
=== regCheck ===<br />
Mit dem Befehl <br />
:<code>get hm regCheck</code><br />
wird überprüft, ob alle Register korrekt gelesen wurden. Mögliche Meldungen:<br />
;missing register list <br />
:ausgegebener Wert (z.B.): <code>dev01Ch01: RegL_01: </code><br />
:erforderliche Korrekturmaßnahme: <code>set dev01Ch01 getConfig</code><br />
:oder <code>device01Ch01: .RegL_03:sensor01Ch01,.RegL_03:sensor01Ch02</code><br />
: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).<br />
;Register changes pending <br />
:ausgegebener Wert (z.B.): <code>sensor01Ch01</code><br />
: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).<br />
<br />
=== configCheck ===<br />
Mit dem Befehl <br />
:<code>get hm configCheck</code> werden die Befehle '''peerCheck''' und '''regCheck''' ausgeführt. Zusätzlich können noch Ergebnisse auftauchen wie<br />
;PairedTo mismatch to IODev<br />
:ausgegebener Wert (z.B.): <code>sensor01Ch01 paired:0x000000 IO attr: xxxxxx.</code><br />
: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).<br />
<br />
== Anzeigen zur Übertragungssituation ==<br />
===RSSI ===<br />
;<code>get hm rssi [<filter>]</code><br />
:Erzeugt eine Tabelle aller RSSI Werte.<br />
;<code>set hm clear [<filter>] rssi</code><br />
:setzt die RSSI Werte aller devices gemäß filter zurück. Eine neue Messung kann beginnen<br />
<br />
===protoEvents ===<br />
;<code>get hm protoEvents [<filter>][short|long] </code><br />
Siehe [[Himfo Protokol]]<br />
:Es wird eine Tabelle mit allen wichtigen Ereignissen zur Datenübertragung erzeugt. Dies beinhaltet Wiederholungen sowie Übertragungsfehler. <br />
<code>short</code> ist eine Fassung ohne Zeitstempel und lässt sich besser am Bildschirm darstellen.<br />
Ausserdem kann man sehen, welche Abfragen noch in der Queue sind, z.B. durch <code>autoReadReg</code> erzeugt. <br />
Die Zustände aller für HM zuständigen IOs sind beinhaltet. <br />
Alles in allem ist hier ein kompletter Überblick zur Kommunikation zu sehen. Der Befehl<br />
set hm clear [<filter>] Protocol<br />
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><br />
Für tieferes Verständnis siehe [[Himfo Protokol]]<br />
<br />
===msgStat===<br />
;<code>set hm msgStat </code><br />
:Statistic der Übertragenen Messages insgesamt. Es gibt eine Tabelle über die letzten 24h und eine über die letzte Woche. <br />
<br />
== Speichern von Konfigurationen==<br />
HMInfo speichert Konfigurationen der Geräte in Files. Mit dem Attribut configDir kann man ein Verzeichnis festlegen, in das alles geschrieben wird.<br />
<br />
=== saveConfig===<br />
[[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. <br />
:<code>set hm saveConfig [<filter>] [<file>] </code><br />
<br />
=== archConfig ===<br />
Arbeitet prinzipiell wie saveConfig. Es werden jedoch nur vollständige Registersätze gespeichert, was einen höheren Level an Sicherheit der Dateninhalte gewährt. <br />
:<code>set hm archConfig [-a] [<file>] </code><br />
Mit dem '''Attribut autoArchive''' kann man einstellen, dass automatisch nach erfolgreichem Lesen einer Device-Konfiguration diese archiviert wird. <br />
Das Speichern erfolgt kumulativ. Ab einer Dateigröße von 1MB wird gepurged, also alles bis auf den neusten Eintrag jeder Entity gelöscht. <br />
<br />
Um eine Konfiguration zu sichern, sollte eine Kopie des Archivs gemacht werden. Das Archiv wird bei Gelegenheit überschrieben. <br />
<br />
Template erstellen:<br />
:<code>set hm saveConfig -f ^meinDevice$ <myTemplateFile> </code><br />
<br />
=== loadConfig ===<br />
;<code>set hm loadConfig [<filter>] [<filename>] </code><br />
: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. <br />
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. <br />
Es liegt im ermessen des User, eine bekannt aktuelle Version der Register einzulesen. <br />
<br />
=== purgeConfig===<br />
;<code>set hm purgeConfig [<filename>] </code><br />
:Löscht alle älteren Datensätze in einem File.<br />
<br />
== Konfigurationen bearbeiten ==<br />
=== Templates ===<br />
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.<br />
Faktisch setzt das Template also eine Gruppe von Registern auf einmal.<br />
<br />
====templateList ====<br />
Die vorhandenen templates kann man mit templateList sehen. <br />
get hm templateList<br />
<br />
SwOnCond params:level cond Info:switch: execute only if condition [geLo|ltLo] level is below limit<br />
SwToggle params: Info:Switch: toggle on trigger<br />
autoOff params:time Info:staircase - auto off after <time>, extend time with each trigger<br />
motionOnDim params:ontime brightness Info:Dimmer: on for time if MDIR-brightness below level<br />
motionOnSw params:ontime brightness Info:Switch: on for time if MDIR-brightness below level<br />
Die Liste der verfügbaren Tempaltes, deren Parameter falls nötig und eine kurze Info, was das Template bewirken soll<br />
<br />
get hm templateList autoOff<br />
<br />
autoOff params:time Info:staircase - auto off after <time>, extend time with each trigger<br />
ActionType :jmpToTarget<br />
OffTime :111600<br />
OnTime :time<br />
SwJtDlyOff :dlyOn<br />
SwJtDlyOn :no<br />
SwJtOff :dlyOn<br />
SwJtOn :on<br />
Ein templateList auf ein einzelnes Template zeigt im Detail, was das Template verändern wird.<br />
<br />
====templateSet ====<br />
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. <br />
set hm templateSet <entity> <templateName> <peer:[long|short]> [<param1> ...] <br />
set hm templateSet Licht1 autoOff FB1_Btn2:short 10<br />
set hm templateSet Licht1 SwOn FB1_Btn2:long<br />
set hm templateSet Licht1 SwOff FB1_Btn2:short<br />
set hm templateSet Licht1 SwOnOff FB1_Btn2:both<br />
set hm templateSet LichtDev setHost 0<br />
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. <br />
set hm templateSet Licht1 motionOnSw MD1:short 30 20<br />
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).<br />
<br />
====templateDef ====<br />
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:<br />
0 Register ohne peer<br />
<peer>:both Register eines peers<br />
<peer>:short Register eines peers nur Short<br />
<peer>:long Register eines peers nur Long<br />
setzen.<br />
Man kann das template "dynamisch" gestalten, indem man einzelne Register beim templateSet übergibt. <br />
Erst einmal statische Templates. Param ist hier "0"<br />
<br />
set hm templateDef <templateName> <param1[:<param2>...]> <description> <reg1>:<val1> [<reg2>:<val2>] ... <br />
<br />
set hm templateDef t1 0 "TP1" OnTime:10 OffTime:20 OnDly:0 <br />
<br />
set hm templateDef t1 fromMaster <entity> 0 <br />
set hm templateDef t2 fromMaster <entity> <peer>:both <br />
set hm templateDef t3 fromMaster <entity> <peer>:short<br />
set hm templateDef t4 fromMaster <entity> <peer>:long<br />
<br />
set hm templateDef t4 fromMaster LichtWz remoteBtn1:long<br />
<br />
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<br />
<br />
set hm templateDef myTemplate anzeit:auszeit "licht schaltet ständig an und aus" OnTime:p0 OffTime:p1 OnDly:0<br />
<br />
set hm templateDef myAutoOff AnZeit "treppenhausschalter" ActionType:jmpToTarget OffTime:unused OnTime:p0 SwJtDlyOff:dlyOn SwJtDlyOn:no SwJtOff:dlyOn SwJtOn:on<br />
<br />
Die "Anzeit" ist der erste Parameter, also p0. Der Wert, den man bei Set einträgt wird in OnTime geschrieben. OnTime:p0<br />
<br />
Beim Definieren eines Templates wird die Registergültigkeit nicht geprüft. Das kommt beim Set.<br />
<br />
Mit dem Parameter del kann ein (fehlerhaftes) Template (hier myTemplate) wieder gelöscht werden. <br />
<br />
set hm templateDef myTemplate del<br />
<br />
====templateChk ====<br />
Template definitionen und zuweisungen (set) kann man mit <br />
set hm archConfig<br />
speichern und mit <br />
set hm loadConfig<br />
mach einem reboot laden. Welche templates einer entity zugewiesen sind kann man mit <br />
attr <entity> expert 12<br />
in den Readings sichtbar machen. Siehe auch templateUsg.<br />
<br />
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. <br />
get hm templateChk <br />
get hm templateChk [<filter>] <br />
get hm templateChk [<filter>] <templateName> <peer:[long|short]> [<param1> ...] <br />
get hm templateChk -f Rollo RolloHoch self01 5<br />
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.<br />
get hm templateChk -f Rollo RolloHoch self01:sort 5<br />
das selbe, nur für short Einträge<br />
<br />
====templateUsg ====<br />
Gibt eine Liste der zugewiesenen templates zurück<br />
get hm templateUsg <br />
get hm templateUsg sortTemplate<br />
get hm templateUsg sortPeer<br />
<br />
====templateExe ====<br />
Nach einem loadConfig oder einem templateChk können Fehler erkannt worden sein, die Register entspreche nicht dem Template. Mit diesem Kommando werden alle nicht korrekten Register in die Devices geschrieben. Sollte die Werte stimmen wird nichts gemacht. <br />
set hm templateExe<br />
<br />
Das Kommando kann also bedenkenlos eingesetzt werden, wenn die templates schon stimmen. Es wird nichts gesendet, keine Funklast erzeugt.<br />
<br />
====templateDel ====<br />
eine zuweisung des Templates kann gelöscht werden<br />
set hm templateDel <entity> <template><br />
<br />
===Temperaturlisten===<br />
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]]<br />
<br />
=== Registersätze kopieren ===<br />
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. <br />
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. <br />
HMInfo geht davon aus, dass die vom Gerät gelesene Konfiguration vor dem Kommando aktuell und komplett ist. <br />
set hm cpRegs Licht1:FB3_Btn2 Licht3:FB1_Btn4<br />
set hm cpRegs Licht2:FB3_Btn2 Licht2:FB1_Btn4<br />
set hm cpRegs Licht4:FB3_Btn2 Licht4:FB5_Btn2<br />
Die obigen Beispiele bewirken der Reihe nach:<br />
Duplizieren das Verhalten, das Fernbedienungsknopf 2 der Fernbedienung 3 bei Aktor Licht1 hervorruft auch nach Licht3 für Fernbedienungsknopf4 der Fernbedienung 1.<br />
Duplizieren das Verhalten, das Fernbedienungsknopf 2 der Fernbedienung 3 bei Aktor Licht2 hervorruft auch nach Licht2 (selber Aktor) für Fernbedienungsknopf4 der Fernbedienung 1.<br />
<br />
== Web Einträge und Readings ==<br />
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:<br />
:<code>set hm update </code><br />
erreicht. Mit dem Attribut autoUpdate kann man es automatisch regelmäßig starten.<br />
<br />
=== Fehlermeldungen ===<br />
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:<br />
Reading:<gutwert>. Wenn ein Reading mit einen anderen als dem "gutwert" gefunden wird, wird dies alarmiert. <br />
Beispiel: <br />
:<code>battery:ok </code><br />
hat eine HM Komponente ein Reading "battery" und dieses hat einen anderen Wert als "ok" wird dies alarmiert. <br />
In den Readings von HMInfo würde im Feherfall<br />
internal:<br />
ERR_names <devicename1>,<devicename2><br />
Readings:<br />
ERR_battery low:2<br />
<br />
Der default aller Error-meldungen ist<br />
battery:ok,sabotageError:off,powerError:ok,overload:off,overheat:off,reduced:off,motorError:no,error:none,uncertain:yes,smoke_detect:none,cover:closed<br />
<br />
Diese Zusammenfassung der Fehlermeldungen könnte man nutzen, um über notify einen Alarm auszulösen oder eine E-Mail zu senden. <br />
<br />
=== Warnungen===<br />
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. <br />
<br />
=== Statusmeldungen ===<br />
Analog zu den Fehlermeldungen kann man mit dem Attribut sumStatus gewisse Readings zählen lassen. Beipiel wäre <br />
attr HM sumStatus motor<br />
HMInfo zeigt in dem Reading I_sum_motor dann an, welcher Inhalt des Readings "motor" wie oft gefunden wurde. Es könnte so aussehen<br />
stop:on:4;stop:1;<br />
Vier Komponenten stehen auf motor: stop:on und eine steht auf motor: stop<br />
<br />
Das Internal '''I_HM_IOdevices''' zeigt die von HM Komponenten genutzten IOs und deren State. <br />
<br />
== Infos ==<br />
get hm models [-f <regexp>]<br />
get hm models<br />
get hm models -f remote<br />
get hm models -f HM_RC<br />
Zeigt alle in FHEM unterstützten Modelle und deren wesentliche Parameter. Man kann mittels regexp die Liste filtern.<br />
<br />
get hm param [<typefilter>] [-f <nameFilter>] parameter1 parameter2<br />
get hm param -d IODev DEF model<br />
get hm param -c -f Rollo peerList<br />
man kann sich listen von Parametern anzeigen lassen <br />
<br />
get hm register [<typefilter>] [-f <nameFilter>]<br />
zeigt Register in tabellarischer Form. <br />
<br />
get hm peerXref[<typefilter>] [-f <nameFilter>]<br />
gibt an, wer mit wem [[Peering (HomeMatic)|gepeert]] ist<br />
<br />
== Rücksetzen von Variablen und Zählern ==<br />
set HM clear [<typeFilter>] [Protocol|readings|msgStat|register|rssi]<br />
*register löscht alle Register-readings<br />
*readings löscht '''alle''' readings<br />
*Protocol löscht alle Protokol-einträge, pending Kommandos und Protokoll-fehler. <br />
*rssi löscht alle ermittelten RSSI Werte<br />
*msgStat setzt die Message Statistik zurück<br />
<br />
== Filter ==<br />
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<br />
set <name> <cmd> '''[-dcasevi]''' [params]<br />
entities according to list will be processed"<br />
d - device :include devices"<br />
c - channels :include channels"<br />
i - ignore :include devices marked as ignore"<br />
v - virtual :supress fhem virtual"<br />
p - physical :supress physical"<br />
a - aktor :supress actor"<br />
s - sensor :supress sensor"<br />
e - empty :include results even if requested fields are empty"<br />
<br />
Ein auf '''-d''' gefiltertes Kommando wird nur auf devices, nicht aber auf channels angewendet. <br />
<br />
Dann gibt es noch den '''nameFilter''', mit dem mittels regexp auf den Namen der Entity gefiltert werden kann<br />
-f Rollo # alle Entities mit Rollo im Namen<br />
-f ^Rollo$ # nur Entity mit Namen "Rollo"<br />
-f Rollo$ # nur Entity deren Name auf Rollo endet<br />
<br />
Die Filter kann man kombinieren mit <br />
-c -f Rollo # alle Kanäle mit Rollo im Namen<br />
<br />
Beispiel: <br />
Zeige mir die Parameter IODev und room der Devices mit Rollo im Namen<br />
set hm param -d -f Rollo IODev room<br />
<br />
<br />
== Attribute ==<br />
* '''autoArchive ''' automatisch archivieren von vollständigen Konfigurationen.<br />
* '''autoUpdate''' startet regelmäßig das Komamndo "update". Die Wiederholzeit wird eingestellt mit hh:mm. Sinnvoll erscheint z.B. alle 5 Minuten, also 00:05.<br />
* '''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.<br />
* '''configFilename''' legt einen default Namen fest, der bei save und archive genutzt wird. Default ist regSave.cfg.<br />
* '''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.<br />
== Weiterführende Links ==<br />
* [[HomeMatic Templates]]<br />
<br />
== Quellen == <br />
* Thread [http://forum.fhem.de/index.php?topic=11035.0 HMinfo] im FHEM Forum<br />
* Thread {{Link2Forum|Topic=20119|LinkText=HMINfo, Intention, Sinn und Zweck}} im FHEM Forum<br />
<br />
[[Kategorie:HomeMatic supportDevice]]<br />
[[Kategorie:HOWTOS]]</div>Martinp876http://wiki.fhem.de/w/index.php?title=HMinfo&diff=24307HMinfo2018-01-04T16:38:45Z<p>Martinp876: </p>
<hr />
<div>{{Infobox Modul<br />
|ModPurpose=Übersicht über alle HomeMatic Geräte<br />
|ModType=h<br />
|ModCmdRef=HMinfo<br />
|ModForumArea=HomeMatic<br />
|ModTechName=98_HMinfo.pm<br />
|ModOwner=martinp876 ({{Link2FU|251|martinp876}} / [[Benutzer Diskussion:Martinp876|Wiki]])<br />
}}<br />
<br />
'''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. <br />
<br />
== Definition == <br />
HMInfo wird erstellt / angelegt mit dem Befehl<br />
:<code>define hm HMinfo</code><br />
<br />
Danach können alle Funktionen aufgelistet werden mit<br />
:<code>get hm help</code><br />
<br />
== Integritätsprüfungen ==<br />
Zur 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.<br />
<br />
Befehle, um die Gültigkeit von verschiedenen HomeMatic Eigenschaften zu überprüfen:<br />
<br />
=== peerCheck ===<br />
Mit dem Befehl <br />
:<code>get hm peerCheck</code><br />
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:<br />
;peer not verified. Check that peer is set on both sides <br />
:ausgegebener Wert (z.B.): actorChan p:switchChan<br />
: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).<br />
<br />
=== regCheck ===<br />
Mit dem Befehl <br />
:<code>get hm regCheck</code><br />
wird überprüft, ob alle Register korrekt gelesen wurden. Mögliche Meldungen:<br />
;missing register list <br />
:ausgegebener Wert (z.B.): <code>dev01Ch01: RegL_01: </code><br />
:erforderliche Korrekturmaßnahme: <code>set dev01Ch01 getConfig</code><br />
:oder <code>device01Ch01: .RegL_03:sensor01Ch01,.RegL_03:sensor01Ch02</code><br />
: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).<br />
;Register changes pending <br />
:ausgegebener Wert (z.B.): <code>sensor01Ch01</code><br />
: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).<br />
<br />
=== configCheck ===<br />
Mit dem Befehl <br />
:<code>get hm configCheck</code> werden die Befehle '''peerCheck''' und '''regCheck''' ausgeführt. Zusätzlich können noch Ergebnisse auftauchen wie<br />
;PairedTo mismatch to IODev<br />
:ausgegebener Wert (z.B.): <code>sensor01Ch01 paired:0x000000 IO attr: xxxxxx.</code><br />
: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).<br />
<br />
== Anzeigen zur Übertragungssituation ==<br />
===RSSI ===<br />
;<code>get hm rssi [<filter>]</code><br />
:Erzeugt eine Tabelle aller RSSI Werte.<br />
;<code>set hm clear [<filter>] rssi</code><br />
:setzt die RSSI Werte aller devices gemäß filter zurück. Eine neue Messung kann beginnen<br />
<br />
===protoEvents ===<br />
;<code>get hm protoEvents [<filter>][short|long] </code><br />
Siehe [[Himfo Protokol]]<br />
:Es wird eine Tabelle mit allen wichtigen Ereignissen zur Datenübertragung erzeugt. Dies beinhaltet Wiederholungen sowie Übertragungsfehler. <br />
<code>short</code> ist eine Fassung ohne Zeitstempel und lässt sich besser am Bildschirm darstellen.<br />
Ausserdem kann man sehen, welche Abfragen noch in der Queue sind, z.B. durch <code>autoReadReg</code> erzeugt. <br />
Die Zustände aller für HM zuständigen IOs sind beinhaltet. <br />
Alles in allem ist hier ein kompletter Überblick zur Kommunikation zu sehen. Der Befehl<br />
set hm clear [<filter>] Protocol<br />
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ändniss siehe [[Himfo Protokol]]<br />
<br />
===msgStat===<br />
;<code>set hm msgStat </code><br />
:Statistic der Übertragenen Messages insgesamt. Es gibt eine Tabelle über die letzten 24h und eine über die letzte Woche. <br />
<br />
== Speichern von Konfigurationen==<br />
HMInfo speichert Konfigurationen der Geräte in Files. Mit dem Attribut configDir kann man ein Verzeichnis festlegen, in das alles geschrieben wird.<br />
<br />
=== saveConfig===<br />
[[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. <br />
:<code>set hm saveConfig [<filter>] [<file>] </code><br />
<br />
=== archConfig ===<br />
Arbeitet prinzipiell wie saveConfig. Es werden jedoch nur vollständige Registersätze gespeichert, was einen höheren Level an Sicherheit der Dateninhalte gewährt. <br />
:<code>set hm archConfig [-a] [<file>] </code><br />
Mit dem '''Attribut autoArchive''' kann man einstellen, dass automatisch nach erfolgreichem Lesen einer Device-Konfiguration diese archiviert wird. <br />
Das Speichern erfolgt kumulativ. Ab einer Dateigröße von 1MB wird gepurged, also alles bis auf den neusten Eintrag jeder Entity gelöscht. <br />
<br />
Um eine Konfiguration zu sichern, sollte eine Kopie des Archivs gemacht werden. Das Archiv wird bei Gelegenheit überschrieben. <br />
<br />
Template erstellen:<br />
:<code>set hm saveConfig -f ^meinDevice$ <myTemplateFile> </code><br />
<br />
=== loadConfig ===<br />
;<code>set hm loadConfig [<filter>] [<filename>] </code><br />
: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. <br />
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. <br />
Es liegt im ermessen des User, eine bekannt aktuelle Version der Register einzulesen. <br />
<br />
=== purgeConfig===<br />
;<code>set hm purgeConfig [<filename>] </code><br />
:Löscht alle älteren Datensätze in einem File.<br />
<br />
== Konfigurationen bearbeiten ==<br />
=== Templates ===<br />
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.<br />
Faktisch setzt das Template also eine Gruppe von Registern auf einmal.<br />
<br />
====templateList ====<br />
Die vorhandenen templates kann man mit templateList sehen. <br />
get hm templateList<br />
<br />
SwOnCond params:level cond Info:switch: execute only if condition [geLo|ltLo] level is below limit<br />
SwToggle params: Info:Switch: toggle on trigger<br />
autoOff params:time Info:staircase - auto off after <time>, extend time with each trigger<br />
motionOnDim params:ontime brightness Info:Dimmer: on for time if MDIR-brightness below level<br />
motionOnSw params:ontime brightness Info:Switch: on for time if MDIR-brightness below level<br />
Die Liste der verfügbaren Tempaltes, deren Parameter falls nötig und eine kurze Info, was das Template bewirken soll<br />
<br />
get hm templateList autoOff<br />
<br />
autoOff params:time Info:staircase - auto off after <time>, extend time with each trigger<br />
ActionType :jmpToTarget<br />
OffTime :111600<br />
OnTime :time<br />
SwJtDlyOff :dlyOn<br />
SwJtDlyOn :no<br />
SwJtOff :dlyOn<br />
SwJtOn :on<br />
Ein templateList auf ein einzelnes Template zeigt im Detail, was das Template verändern wird.<br />
<br />
====templateSet ====<br />
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. <br />
set hm templateSet <entity> <templateName> <peer:[long|short]> [<param1> ...] <br />
set hm templateSet Licht1 autoOff FB1_Btn2:short 10<br />
set hm templateSet Licht1 SwOn FB1_Btn2:long<br />
set hm templateSet Licht1 SwOff FB1_Btn2:short<br />
set hm templateSet Licht1 SwOnOff FB1_Btn2:both<br />
set hm templateSet LichtDev setHost 0<br />
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. <br />
set hm templateSet Licht1 motionOnSw MD1:short 30 20<br />
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).<br />
<br />
====templateDef ====<br />
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:<br />
0 Register ohne peer<br />
<peer>:both Register eines peers<br />
<peer>:short Register eines peers nur Short<br />
<peer>:long Register eines peers nur Long<br />
setzen.<br />
Man kann das template "dynamisch" gestalten, indem man einzelne Register beim templateSet übergibt. <br />
Erst einmal statische Templates. Param ist hier "0"<br />
<br />
set hm templateDef <templateName> <param1[:<param2>...]> <description> <reg1>:<val1> [<reg2>:<val2>] ... <br />
<br />
set hm templateDef t1 0 "TP1" OnTime:10 OffTime:20 OnDly:0 <br />
<br />
set hm templateDef t1 fromMaster <entity> 0 <br />
set hm templateDef t2 fromMaster <entity> <peer>:both <br />
set hm templateDef t3 fromMaster <entity> <peer>:short<br />
set hm templateDef t4 fromMaster <entity> <peer>:long<br />
<br />
set hm templateDef t4 fromMaster LichtWz remoteBtn1:long<br />
<br />
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<br />
<br />
set hm templateDef myTemplate anzeit:auszeit "licht schaltet ständig an und aus" OnTime:p0 OffTime:p1 OnDly:0<br />
<br />
set hm templateDef myAutoOff AnZeit "treppenhausschalter" ActionType:jmpToTarget OffTime:unused OnTime:p0 SwJtDlyOff:dlyOn SwJtDlyOn:no SwJtOff:dlyOn SwJtOn:on<br />
<br />
Die "Anzeit" ist der erste Parameter, also p0. Der Wert, den man bei Set einträgt wird in OnTime geschrieben. OnTime:p0<br />
<br />
Beim Definieren eines Templates wird die Registergültigkeit nicht geprüft. Das kommt beim Set.<br />
<br />
Mit dem Parameter del kann ein (fehlerhaftes) Template (hier myTemplate) wieder gelöscht werden. <br />
<br />
set hm templateDef myTemplate del<br />
<br />
====templateChk ====<br />
Template definitionen und zuweisungen (set) kann man mit <br />
set hm archConfig<br />
speichern und mit <br />
set hm loadConfig<br />
mach einem reboot laden. Welche templates einer entity zugewiesen sind kann man mit <br />
attr <entity> expert 12<br />
in den Readings sichtbar machen. Siehe auch templateUsg.<br />
<br />
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. <br />
get hm templateChk <br />
get hm templateChk [<filter>] <br />
get hm templateChk [<filter>] <templateName> <peer:[long|short]> [<param1> ...] <br />
get hm templateChk -f Rollo RolloHoch self01 5<br />
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.<br />
get hm templateChk -f Rollo RolloHoch self01:sort 5<br />
das selbe, nur für short Einträge<br />
<br />
====templateUsg ====<br />
Gibt eine Liste der zugewiesenen templates zurück<br />
get hm templateUsg <br />
get hm templateUsg sortTemplate<br />
get hm templateUsg sortPeer<br />
<br />
====templateExe ====<br />
Nach einem loadConfig oder einem templateChk können Fehler erkannt worden sein, die Register entspreche nicht dem Template. Mit diesem Kommando werden alle nicht korrekten Register in die Devices geschrieben. Sollte die Werte stimmen wird nichts gemacht. <br />
set hm templateExe<br />
<br />
Das Kommando kann also bedenkenlos eingesetzt werden, wenn die templates schon stimmen. Es wird nichts gesendet, keine Funklast erzeugt.<br />
<br />
====templateDel ====<br />
eine zuweisung des Templates kann gelöscht werden<br />
set hm templateDel <entity> <template><br />
<br />
===Temperaturlisten===<br />
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]]<br />
<br />
=== Registersätze kopieren ===<br />
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. <br />
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. <br />
HMInfo geht davon aus, dass die vom Gerät gelesene Konfiguration vor dem Kommando aktuell und komplett ist. <br />
set hm cpRegs Licht1:FB3_Btn2 Licht3:FB1_Btn4<br />
set hm cpRegs Licht2:FB3_Btn2 Licht2:FB1_Btn4<br />
set hm cpRegs Licht4:FB3_Btn2 Licht4:FB5_Btn2<br />
Die obigen Beispiele bewirken der Reihe nach:<br />
Duplizieren das Verhalten, das Fernbedienungsknopf 2 der Fernbedienung 3 bei Aktor Licht1 hervorruft auch nach Licht3 für Fernbedienungsknopf4 der Fernbedienung 1.<br />
Duplizieren das Verhalten, das Fernbedienungsknopf 2 der Fernbedienung 3 bei Aktor Licht2 hervorruft auch nach Licht2 (selber Aktor) für Fernbedienungsknopf4 der Fernbedienung 1.<br />
<br />
== Web Einträge und Readings ==<br />
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:<br />
:<code>set hm update </code><br />
erreicht. Mit dem Attribut autoUpdate kann man es automatisch regelmäßig starten.<br />
<br />
=== Fehlermeldungen ===<br />
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:<br />
Reading:<gutwert>. Wenn ein Reading mit einen anderen als dem "gutwert" gefunden wird, wird dies alarmiert. <br />
Beispiel: <br />
:<code>battery:ok </code><br />
hat eine HM Komponente ein Reading "battery" und dieses hat einen anderen Wert als "ok" wird dies alarmiert. <br />
In den Readings von HMInfo würde im Feherfall<br />
internal:<br />
ERR_names <devicename1>,<devicename2><br />
Readings:<br />
ERR_battery low:2<br />
<br />
Der default aller Error-meldungen ist<br />
battery:ok,sabotageError:off,powerError:ok,overload:off,overheat:off,reduced:off,motorError:no,error:none,uncertain:yes,smoke_detect:none,cover:closed<br />
<br />
Diese Zusammenfassung der Fehlermeldungen könnte man nutzen, um über notify einen Alarm auszulösen oder eine E-Mail zu senden. <br />
<br />
=== Warnungen===<br />
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. <br />
<br />
=== Statusmeldungen ===<br />
Analog zu den Fehlermeldungen kann man mit dem Attribut sumStatus gewisse Readings zählen lassen. Beipiel wäre <br />
attr HM sumStatus motor<br />
HMInfo zeigt in dem Reading I_sum_motor dann an, welcher Inhalt des Readings "motor" wie oft gefunden wurde. Es könnte so aussehen<br />
stop:on:4;stop:1;<br />
Vier Komponenten stehen auf motor: stop:on und eine steht auf motor: stop<br />
<br />
Das Internal '''I_HM_IOdevices''' zeigt die von HM Komponenten genutzten IOs und deren State. <br />
<br />
== Infos ==<br />
get hm models [-f <regexp>]<br />
get hm models<br />
get hm models -f remote<br />
get hm models -f HM_RC<br />
Zeigt alle in FHEM unterstützten Modelle und deren wesentliche Parameter. Man kann mittels regexp die Liste filtern.<br />
<br />
get hm param [<typefilter>] [-f <nameFilter>] parameter1 parameter2<br />
get hm param -d IODev DEF model<br />
get hm param -c -f Rollo peerList<br />
man kann sich listen von Parametern anzeigen lassen <br />
<br />
get hm register [<typefilter>] [-f <nameFilter>]<br />
zeigt Register in tabellarischer Form. <br />
<br />
get hm peerXref[<typefilter>] [-f <nameFilter>]<br />
gibt an, wer mit wem [[Peering (HomeMatic)|gepeert]] ist<br />
<br />
== Rücksetzen von Variablen und Zählern ==<br />
set HM clear [<typeFilter>] [Protocol|readings|msgStat|register|rssi]<br />
*register löscht alle Register-readings<br />
*readings löscht '''alle''' readings<br />
*Protocol löscht alle Protokol-einträge, pending Kommandos und Protokoll-fehler. <br />
*rssi löscht alle ermittelten RSSI Werte<br />
*msgStat setzt die Message Statistik zurück<br />
<br />
== Filter ==<br />
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<br />
set <name> <cmd> '''[-dcasevi]''' [params]<br />
entities according to list will be processed"<br />
d - device :include devices"<br />
c - channels :include channels"<br />
i - ignore :include devices marked as ignore"<br />
v - virtual :supress fhem virtual"<br />
p - physical :supress physical"<br />
a - aktor :supress actor"<br />
s - sensor :supress sensor"<br />
e - empty :include results even if requested fields are empty"<br />
<br />
Ein auf '''-d''' gefiltertes Kommando wird nur auf devices, nicht aber auf channels angewendet. <br />
<br />
Dann gibt es noch den '''nameFilter''', mit dem mittels regexp auf den Namen der Entity gefiltert werden kann<br />
-f Rollo # alle Entities mit Rollo im Namen<br />
-f ^Rollo$ # nur Entity mit Namen "Rollo"<br />
-f Rollo$ # nur Entity deren Name auf Rollo endet<br />
<br />
Die Filter kann man kombinieren mit <br />
-c -f Rollo # alle Kanäle mit Rollo im Namen<br />
<br />
Beispiel: <br />
Zeige mir die Parameter IODev und room der Devices mit Rollo im Namen<br />
set hm param -d -f Rollo IODev room<br />
<br />
<br />
== Attribute ==<br />
* '''autoArchive ''' automatisch archivieren von vollständigen Konfigurationen.<br />
* '''autoUpdate''' startet regelmäßig das Komamndo "update". Die Wiederholzeit wird eingestellt mit hh:mm. Sinnvoll erscheint z.B. alle 5 Minuten, also 00:05.<br />
* '''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.<br />
* '''configFilename''' legt einen default Namen fest, der bei save und archive genutzt wird. Default ist regSave.cfg.<br />
* '''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.<br />
== Weiterführende Links ==<br />
* [[HomeMatic Templates]]<br />
<br />
== Quellen == <br />
* Thread [http://forum.fhem.de/index.php?topic=11035.0 HMinfo] im FHEM Forum<br />
* Thread {{Link2Forum|Topic=20119|LinkText=HMINfo, Intention, Sinn und Zweck}} im FHEM Forum<br />
<br />
[[Kategorie:HomeMatic supportDevice]]<br />
[[Kategorie:HOWTOS]]</div>Martinp876http://wiki.fhem.de/w/index.php?title=HMinfo&diff=24306HMinfo2018-01-04T16:37:30Z<p>Martinp876: </p>
<hr />
<div>{{Infobox Modul<br />
|ModPurpose=Übersicht über alle HomeMatic Geräte<br />
|ModType=h<br />
|ModCmdRef=HMinfo<br />
|ModForumArea=HomeMatic<br />
|ModTechName=98_HMinfo.pm<br />
|ModOwner=martinp876 ({{Link2FU|251|martinp876}} / [[Benutzer Diskussion:Martinp876|Wiki]])<br />
}}<br />
<br />
'''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. <br />
<br />
== Definition == <br />
HMInfo wird erstellt / angelegt mit dem Befehl<br />
:<code>define hm HMinfo</code><br />
<br />
Danach können alle Funktionen aufgelistet werden mit<br />
:<code>get hm help</code><br />
<br />
== Integritätsprüfungen ==<br />
Zur 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.<br />
<br />
Befehle, um die Gültigkeit von verschiedenen HomeMatic Eigenschaften zu überprüfen:<br />
<br />
=== peerCheck ===<br />
Mit dem Befehl <br />
:<code>get hm peerCheck</code><br />
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:<br />
;peer not verified. Check that peer is set on both sides <br />
:ausgegebener Wert (z.B.): actorChan p:switchChan<br />
: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).<br />
<br />
=== regCheck ===<br />
Mit dem Befehl <br />
:<code>get hm regCheck</code><br />
wird überprüft, ob alle Register korrekt gelesen wurden. Mögliche Meldungen:<br />
;missing register list <br />
:ausgegebener Wert (z.B.): <code>dev01Ch01: RegL_01: </code><br />
:erforderliche Korrekturmaßnahme: <code>set dev01Ch01 getConfig</code><br />
:oder <code>device01Ch01: .RegL_03:sensor01Ch01,.RegL_03:sensor01Ch02</code><br />
: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).<br />
;Register changes pending <br />
:ausgegebener Wert (z.B.): <code>sensor01Ch01</code><br />
: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).<br />
<br />
=== configCheck ===<br />
Mit dem Befehl <br />
:<code>get hm configCheck</code> werden die Befehle '''peerCheck''' und '''regCheck''' ausgeführt. Zusätzlich können noch Ergebnisse auftauchen wie<br />
;PairedTo mismatch to IODev<br />
:ausgegebener Wert (z.B.): <code>sensor01Ch01 paired:0x000000 IO attr: xxxxxx.</code><br />
: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).<br />
<br />
== Anzeigen zur Übertragungssituation ==<br />
===RSSI ===<br />
;<code>get hm rssi [<filter>]</code><br />
:Erzeugt eine Tabelle aller RSSI Werte.<br />
;<code>set hm clear [<filter>] rssi</code><br />
:setzt die RSSI Werte aller devices gemäß filter zurück. Eine neue Messung kann beginnen<br />
<br />
===protoEvents ===<br />
;<code>get hm protoEvents [<filter>][short|long] </code><br />
* [[Himfo Protokol]]<br />
:Es wird eine Tabelle mit allen wichtigen Ereignissen zur Datenübertragung erzeugt. Dies beinhaltet Wiederholungen sowie Übertragungsfehler. <br />
<code>short</code> ist eine Fassung ohne Zeitstempel und lässt sich besser am Bildschirm darstellen.<br />
Ausserdem kann man sehen, welche Abfragen noch in der Queue sind, z.B. durch <code>autoReadReg</code> erzeugt. <br />
Die Zustände aller für HM zuständigen IOs sind beinhaltet. <br />
Alles in allem ist hier ein kompletter Überblick zur Kommunikation zu sehen. Der Befehl<br />
set hm clear [<filter>] Protocol<br />
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 />
<br />
===msgStat===<br />
;<code>set hm msgStat </code><br />
:Statistic der Übertragenen Messages insgesamt. Es gibt eine Tabelle über die letzten 24h und eine über die letzte Woche. <br />
<br />
== Speichern von Konfigurationen==<br />
HMInfo speichert Konfigurationen der Geräte in Files. Mit dem Attribut configDir kann man ein Verzeichnis festlegen, in das alles geschrieben wird.<br />
<br />
=== saveConfig===<br />
[[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. <br />
:<code>set hm saveConfig [<filter>] [<file>] </code><br />
<br />
=== archConfig ===<br />
Arbeitet prinzipiell wie saveConfig. Es werden jedoch nur vollständige Registersätze gespeichert, was einen höheren Level an Sicherheit der Dateninhalte gewährt. <br />
:<code>set hm archConfig [-a] [<file>] </code><br />
Mit dem '''Attribut autoArchive''' kann man einstellen, dass automatisch nach erfolgreichem Lesen einer Device-Konfiguration diese archiviert wird. <br />
Das Speichern erfolgt kumulativ. Ab einer Dateigröße von 1MB wird gepurged, also alles bis auf den neusten Eintrag jeder Entity gelöscht. <br />
<br />
Um eine Konfiguration zu sichern, sollte eine Kopie des Archivs gemacht werden. Das Archiv wird bei Gelegenheit überschrieben. <br />
<br />
Template erstellen:<br />
:<code>set hm saveConfig -f ^meinDevice$ <myTemplateFile> </code><br />
<br />
=== loadConfig ===<br />
;<code>set hm loadConfig [<filter>] [<filename>] </code><br />
: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. <br />
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. <br />
Es liegt im ermessen des User, eine bekannt aktuelle Version der Register einzulesen. <br />
<br />
=== purgeConfig===<br />
;<code>set hm purgeConfig [<filename>] </code><br />
:Löscht alle älteren Datensätze in einem File.<br />
<br />
== Konfigurationen bearbeiten ==<br />
=== Templates ===<br />
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.<br />
Faktisch setzt das Template also eine Gruppe von Registern auf einmal.<br />
<br />
====templateList ====<br />
Die vorhandenen templates kann man mit templateList sehen. <br />
get hm templateList<br />
<br />
SwOnCond params:level cond Info:switch: execute only if condition [geLo|ltLo] level is below limit<br />
SwToggle params: Info:Switch: toggle on trigger<br />
autoOff params:time Info:staircase - auto off after <time>, extend time with each trigger<br />
motionOnDim params:ontime brightness Info:Dimmer: on for time if MDIR-brightness below level<br />
motionOnSw params:ontime brightness Info:Switch: on for time if MDIR-brightness below level<br />
Die Liste der verfügbaren Tempaltes, deren Parameter falls nötig und eine kurze Info, was das Template bewirken soll<br />
<br />
get hm templateList autoOff<br />
<br />
autoOff params:time Info:staircase - auto off after <time>, extend time with each trigger<br />
ActionType :jmpToTarget<br />
OffTime :111600<br />
OnTime :time<br />
SwJtDlyOff :dlyOn<br />
SwJtDlyOn :no<br />
SwJtOff :dlyOn<br />
SwJtOn :on<br />
Ein templateList auf ein einzelnes Template zeigt im Detail, was das Template verändern wird.<br />
<br />
====templateSet ====<br />
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. <br />
set hm templateSet <entity> <templateName> <peer:[long|short]> [<param1> ...] <br />
set hm templateSet Licht1 autoOff FB1_Btn2:short 10<br />
set hm templateSet Licht1 SwOn FB1_Btn2:long<br />
set hm templateSet Licht1 SwOff FB1_Btn2:short<br />
set hm templateSet Licht1 SwOnOff FB1_Btn2:both<br />
set hm templateSet LichtDev setHost 0<br />
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. <br />
set hm templateSet Licht1 motionOnSw MD1:short 30 20<br />
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).<br />
<br />
====templateDef ====<br />
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:<br />
0 Register ohne peer<br />
<peer>:both Register eines peers<br />
<peer>:short Register eines peers nur Short<br />
<peer>:long Register eines peers nur Long<br />
setzen.<br />
Man kann das template "dynamisch" gestalten, indem man einzelne Register beim templateSet übergibt. <br />
Erst einmal statische Templates. Param ist hier "0"<br />
<br />
set hm templateDef <templateName> <param1[:<param2>...]> <description> <reg1>:<val1> [<reg2>:<val2>] ... <br />
<br />
set hm templateDef t1 0 "TP1" OnTime:10 OffTime:20 OnDly:0 <br />
<br />
set hm templateDef t1 fromMaster <entity> 0 <br />
set hm templateDef t2 fromMaster <entity> <peer>:both <br />
set hm templateDef t3 fromMaster <entity> <peer>:short<br />
set hm templateDef t4 fromMaster <entity> <peer>:long<br />
<br />
set hm templateDef t4 fromMaster LichtWz remoteBtn1:long<br />
<br />
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<br />
<br />
set hm templateDef myTemplate anzeit:auszeit "licht schaltet ständig an und aus" OnTime:p0 OffTime:p1 OnDly:0<br />
<br />
set hm templateDef myAutoOff AnZeit "treppenhausschalter" ActionType:jmpToTarget OffTime:unused OnTime:p0 SwJtDlyOff:dlyOn SwJtDlyOn:no SwJtOff:dlyOn SwJtOn:on<br />
<br />
Die "Anzeit" ist der erste Parameter, also p0. Der Wert, den man bei Set einträgt wird in OnTime geschrieben. OnTime:p0<br />
<br />
Beim Definieren eines Templates wird die Registergültigkeit nicht geprüft. Das kommt beim Set.<br />
<br />
Mit dem Parameter del kann ein (fehlerhaftes) Template (hier myTemplate) wieder gelöscht werden. <br />
<br />
set hm templateDef myTemplate del<br />
<br />
====templateChk ====<br />
Template definitionen und zuweisungen (set) kann man mit <br />
set hm archConfig<br />
speichern und mit <br />
set hm loadConfig<br />
mach einem reboot laden. Welche templates einer entity zugewiesen sind kann man mit <br />
attr <entity> expert 12<br />
in den Readings sichtbar machen. Siehe auch templateUsg.<br />
<br />
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. <br />
get hm templateChk <br />
get hm templateChk [<filter>] <br />
get hm templateChk [<filter>] <templateName> <peer:[long|short]> [<param1> ...] <br />
get hm templateChk -f Rollo RolloHoch self01 5<br />
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.<br />
get hm templateChk -f Rollo RolloHoch self01:sort 5<br />
das selbe, nur für short Einträge<br />
<br />
====templateUsg ====<br />
Gibt eine Liste der zugewiesenen templates zurück<br />
get hm templateUsg <br />
get hm templateUsg sortTemplate<br />
get hm templateUsg sortPeer<br />
<br />
====templateExe ====<br />
Nach einem loadConfig oder einem templateChk können Fehler erkannt worden sein, die Register entspreche nicht dem Template. Mit diesem Kommando werden alle nicht korrekten Register in die Devices geschrieben. Sollte die Werte stimmen wird nichts gemacht. <br />
set hm templateExe<br />
<br />
Das Kommando kann also bedenkenlos eingesetzt werden, wenn die templates schon stimmen. Es wird nichts gesendet, keine Funklast erzeugt.<br />
<br />
====templateDel ====<br />
eine zuweisung des Templates kann gelöscht werden<br />
set hm templateDel <entity> <template><br />
<br />
===Temperaturlisten===<br />
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]]<br />
<br />
=== Registersätze kopieren ===<br />
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. <br />
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. <br />
HMInfo geht davon aus, dass die vom Gerät gelesene Konfiguration vor dem Kommando aktuell und komplett ist. <br />
set hm cpRegs Licht1:FB3_Btn2 Licht3:FB1_Btn4<br />
set hm cpRegs Licht2:FB3_Btn2 Licht2:FB1_Btn4<br />
set hm cpRegs Licht4:FB3_Btn2 Licht4:FB5_Btn2<br />
Die obigen Beispiele bewirken der Reihe nach:<br />
Duplizieren das Verhalten, das Fernbedienungsknopf 2 der Fernbedienung 3 bei Aktor Licht1 hervorruft auch nach Licht3 für Fernbedienungsknopf4 der Fernbedienung 1.<br />
Duplizieren das Verhalten, das Fernbedienungsknopf 2 der Fernbedienung 3 bei Aktor Licht2 hervorruft auch nach Licht2 (selber Aktor) für Fernbedienungsknopf4 der Fernbedienung 1.<br />
<br />
== Web Einträge und Readings ==<br />
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:<br />
:<code>set hm update </code><br />
erreicht. Mit dem Attribut autoUpdate kann man es automatisch regelmäßig starten.<br />
<br />
=== Fehlermeldungen ===<br />
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:<br />
Reading:<gutwert>. Wenn ein Reading mit einen anderen als dem "gutwert" gefunden wird, wird dies alarmiert. <br />
Beispiel: <br />
:<code>battery:ok </code><br />
hat eine HM Komponente ein Reading "battery" und dieses hat einen anderen Wert als "ok" wird dies alarmiert. <br />
In den Readings von HMInfo würde im Feherfall<br />
internal:<br />
ERR_names <devicename1>,<devicename2><br />
Readings:<br />
ERR_battery low:2<br />
<br />
Der default aller Error-meldungen ist<br />
battery:ok,sabotageError:off,powerError:ok,overload:off,overheat:off,reduced:off,motorError:no,error:none,uncertain:yes,smoke_detect:none,cover:closed<br />
<br />
Diese Zusammenfassung der Fehlermeldungen könnte man nutzen, um über notify einen Alarm auszulösen oder eine E-Mail zu senden. <br />
<br />
=== Warnungen===<br />
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. <br />
<br />
=== Statusmeldungen ===<br />
Analog zu den Fehlermeldungen kann man mit dem Attribut sumStatus gewisse Readings zählen lassen. Beipiel wäre <br />
attr HM sumStatus motor<br />
HMInfo zeigt in dem Reading I_sum_motor dann an, welcher Inhalt des Readings "motor" wie oft gefunden wurde. Es könnte so aussehen<br />
stop:on:4;stop:1;<br />
Vier Komponenten stehen auf motor: stop:on und eine steht auf motor: stop<br />
<br />
Das Internal '''I_HM_IOdevices''' zeigt die von HM Komponenten genutzten IOs und deren State. <br />
<br />
== Infos ==<br />
get hm models [-f <regexp>]<br />
get hm models<br />
get hm models -f remote<br />
get hm models -f HM_RC<br />
Zeigt alle in FHEM unterstützten Modelle und deren wesentliche Parameter. Man kann mittels regexp die Liste filtern.<br />
<br />
get hm param [<typefilter>] [-f <nameFilter>] parameter1 parameter2<br />
get hm param -d IODev DEF model<br />
get hm param -c -f Rollo peerList<br />
man kann sich listen von Parametern anzeigen lassen <br />
<br />
get hm register [<typefilter>] [-f <nameFilter>]<br />
zeigt Register in tabellarischer Form. <br />
<br />
get hm peerXref[<typefilter>] [-f <nameFilter>]<br />
gibt an, wer mit wem [[Peering (HomeMatic)|gepeert]] ist<br />
<br />
== Rücksetzen von Variablen und Zählern ==<br />
set HM clear [<typeFilter>] [Protocol|readings|msgStat|register|rssi]<br />
*register löscht alle Register-readings<br />
*readings löscht '''alle''' readings<br />
*Protocol löscht alle Protokol-einträge, pending Kommandos und Protokoll-fehler. <br />
*rssi löscht alle ermittelten RSSI Werte<br />
*msgStat setzt die Message Statistik zurück<br />
<br />
== Filter ==<br />
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<br />
set <name> <cmd> '''[-dcasevi]''' [params]<br />
entities according to list will be processed"<br />
d - device :include devices"<br />
c - channels :include channels"<br />
i - ignore :include devices marked as ignore"<br />
v - virtual :supress fhem virtual"<br />
p - physical :supress physical"<br />
a - aktor :supress actor"<br />
s - sensor :supress sensor"<br />
e - empty :include results even if requested fields are empty"<br />
<br />
Ein auf '''-d''' gefiltertes Kommando wird nur auf devices, nicht aber auf channels angewendet. <br />
<br />
Dann gibt es noch den '''nameFilter''', mit dem mittels regexp auf den Namen der Entity gefiltert werden kann<br />
-f Rollo # alle Entities mit Rollo im Namen<br />
-f ^Rollo$ # nur Entity mit Namen "Rollo"<br />
-f Rollo$ # nur Entity deren Name auf Rollo endet<br />
<br />
Die Filter kann man kombinieren mit <br />
-c -f Rollo # alle Kanäle mit Rollo im Namen<br />
<br />
Beispiel: <br />
Zeige mir die Parameter IODev und room der Devices mit Rollo im Namen<br />
set hm param -d -f Rollo IODev room<br />
<br />
<br />
== Attribute ==<br />
* '''autoArchive ''' automatisch archivieren von vollständigen Konfigurationen.<br />
* '''autoUpdate''' startet regelmäßig das Komamndo "update". Die Wiederholzeit wird eingestellt mit hh:mm. Sinnvoll erscheint z.B. alle 5 Minuten, also 00:05.<br />
* '''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.<br />
* '''configFilename''' legt einen default Namen fest, der bei save und archive genutzt wird. Default ist regSave.cfg.<br />
* '''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.<br />
== Weiterführende Links ==<br />
* [[HomeMatic Templates]]<br />
<br />
== Quellen == <br />
* Thread [http://forum.fhem.de/index.php?topic=11035.0 HMinfo] im FHEM Forum<br />
* Thread {{Link2Forum|Topic=20119|LinkText=HMINfo, Intention, Sinn und Zweck}} im FHEM Forum<br />
<br />
[[Kategorie:HomeMatic supportDevice]]<br />
[[Kategorie:HOWTOS]]</div>Martinp876http://wiki.fhem.de/w/index.php?title=HomeMatic_Templates&diff=23952HomeMatic Templates2017-12-30T14:52:08Z<p>Martinp876: </p>
<hr />
<div>{{Infobox Modul<br />
|ModPurpose=templates bedienen und verwalten<br />
|ModType=h<br />
|ModCmdRef=HMtemplate<br />
|ModForumArea=HomeMatic<br />
|ModTechName=98_HMtemplate.pm<br />
|ModOwner=martinp876 ({{Link2FU|251|martinp876}} / [[Benutzer Diskussion:Martinp876|Wiki]])<br />
}}<br />
Templates sind Vorlagen im Allgemeinen. Hier werden Vorlagen zur Programmierung der Register von HM Devices behandelt. <br />
= Warum Templates =<br />
Die Frage, warum man Register nicht einfach setzt sondern Templates nutzen sollte kommt immer wieder auf. Schliesslich sind wie alle Spezialisten...<br />
Die Wahrheit allerdings bildet das nicht ab. Den auch den Spezialisten sei angeraten, Templates zu nutzen. Ja, warum den, was bieten Templates? Hierzu muss man verstehen wir FHEM, HM, Devices, Kanäle und peers zusammen hängen. <br />
<br />
Wie schon im Einsteigerdoc beschrieben hat ein HM Device remanente Register welche von FHEM gesetzt werden können und die Funktions- und Arbeitsweise definieren. FHEM selbst hat bestenfalls eine Kopie dieser Daten.<br />
;soll-Register Verwaltung<br />
:Da FHEM nur eine Kopie der Registerwerte verwaltet lebt man erst einmal in einer fragilen Welt. Registerwerte können sich ändern durch:<br />
* Reset des Device<br />
* Batteriefehler<br />
* inkorrektes Schreiben und Übertragungsfehler<br />
* Austausch eines Device<br />
:Nach Lesen der Device Register hat FHEM einen neue Kopie - dies muss aber nicht den Wunschregistern entsprechen. Templates sind eine Ansammlung von Wunschregister. Somit können unterschiedliche Mechanismen genutzt werden, das System zu verwalten, prüfen und korrigieren.<br />
;Funktionen für Einsteiger<br />
:Nicht-Experten sollten primär Templates nutzen - um Funktionen zu realisieren, und wenn gewünscht, Experten zu werden. Templares kann man einfach austauschen und dann anwenden.<br />
;Verwalten von Funktionen statt Registern<br />
:Als Experten kann man sicher die Register zeilsicher setzen. Wirklich? Wenn man sich eine clevere Lösung ausgedacht hat und sie reproduzieren will kann man einfach noch einmal nachdenken, nachlesen,... und schon hat man es wieder. Oder man hat ein Template definiert das man einfach nutzt.<br />
; Lernen aus Templates<br />
:Templates sind nicht verschlüsselt. Hat oder bekommt man ein Template kann man die dort gesetzten Register einfach einsehen - und wenn man will verstehen was gemacht wurde. <br />
;Globales Anpassen aller Devices <br />
: Hat man festgestellt, dass eine Funktion sub-optimal ist kann man das Temlate ändern und diese Änderungen allen Devices zu gute kommen lassen. Auf einmal. <br />
<br />
= Grundsätzliches zum Template =<br />
Templates (hier) ist nun also eine Sammlung von Registern welche in einem Device gesetzt werden können. <br />
<br />
== Template Granularität ==<br />
Man kann nicht alle Register eines Device in einem Template abbilden. Das wäre technisch komplex und macht auch von der Anwendung her keinen Sinn. <br />
<br />
*Aus Sicht der Funktion sollte man Templates nach deren Funktionen zusammenfassen.<br />
*Aus Sicht des Devices sollte man Templates nach der Struktur des Device zusammenstellen.<br />
*Die Implementierung erlaubt es, templates für jedes Register einzeln zu erstellen.<br><br />
*Weniger Templates erhöhen die Übersichtlichkeit<br />
Die technische Lösung legt folgenden Templates nahe<br />
#Alle Register eines Kanals oder Device - ausgenommen peer abhängige Register<br />
#Alle Register eines Kanals eines Peers für short oder long<br />
#Alle Register eines Kanals eines Peers nur für short<br />
#Alle Register eines Kanals eines Peers nur für long<br />
Ob man 2. oder die Kombination aus 3. und 4. nutzt ist Geschmackssache. <br><br />
Ein typischer Einsatz sind Schaltern und Dimmer bei welchen man die Aktionen der Peers festlegen will.<br />
;usecase Template Granularität Dimmer<br />
:Mit Peer1 soll bei short ein und bei long ausgeschaltet werden<br />
:Mit Peer2 soll bei short getoggelt und bei long nicht geschaltet werden<br />
:Mit Peer3 soll bei short nicht geschaltet und bei long getoggelt werden<br />
:Mit Peer4 ist ein MotionDetector welcher bei short und einer bestimmten Helligkeit einschaltet, timed. Allerdings sollen Aktionen der anderen Peers oder der Zentrale das Licht dauer-ein schalten.<br />
<br />
== Template Flexibilität ==<br />
Templates sind starr... und können parametriert werden. Also semistarr. Was jetzt? Nun man kann Templates mir bis zu 9 Parametern versehen. Sinnvoll sind wohl eher bis zu 3. <br><br />
Beispiele sind:<br />
*Treppenhausschaltern - mit einem Parameter kann man Einschaltdauer je Instanziierung festlegen. Sinnvoll könnte eine Treppenhausschaltung generell sein, nicht nur im Treppenhaus. Man kann generell alle Lichter nach ein paar Stunden ausschalten.<br />
*Heizungstemplate - Boosttime: Man kann allen RTs das gleiche Template geben - allerdings kann man z.B. die Boosttime indivituell einstellen. <br />
*MotionDetector Clients: Bei den Peers des Modtion detector (also den Schaltern) stellt man ein, dann diese reagieren sollen und wie lange diese brennen sollen. <br />
<br />
== Template Verwaltung==<br />
Templates werden zusammen mit Registern verwaltet. Man benötigt demnach HMinfo. Sowohl die Template definition alsauch die Template Zuweisung werden im File zusammen mit den gelesenen Registern gesichert. Nach einem Einlesen dieses Files werden auch die Templates und deren Zuordnung neu erstellt.<br />
<br />
== Template Editieren==<br />
Die aktuell einfachste Möglichkeit ein Template zu modifizieren ist, HMtemplate zu nutzen. HMtemplate ist ein Editor. Für den Betrieb wird es nicht genutzt. <br />
<br />
<br />
=Das eigenen Konzept=<br />
Für die Verknüpfung von HM Entities muss man 2 Ebenen unterschieden, Architektur und Verhalten.<br />
==Architektur==<br />
Beim Erstellen der Architektur legt man fest, welche Entities untereinander verknüpft werden. Dies geschieht durch peeren. Templates unterstützen nicht die Architektur. Es ist demnach notwendig die Peerings durchzuführen bevor an ein Template darauf anwenden kann. <br />
==Verhalten==<br />
Hier kommen die Templates zum Tragen. Mit Templates definiert man die Register der Entities und somit das Verhalten und die Reaktion der Entites bspw auf Trigger von Sensoren.<br />
===Welchen templateTyp brauche ich===<br />
Wie in Granularität beschrieben kann man insbesondere beim Peerverhalten templates für ''short'', ''long'' oder ''both'' ertellen. Nutzt man short/long braucht man weniger Templates (Basics sind on/off/ignore/toggle) muss allerdings mehr Templates zuweisen, als Reaktion auf short UND long.<br><br />
Bei both braucht man mehr Templates (OnOff/OnIgnore/OffIgnore/IgnoreOff/ToggleIgnore/...) braucht aber nur die Hälfte der Zuweisungen zu den realen Entities. <br />
<br />
===Welche Parameter muss ich einstellen===<br />
Bei der Erstellung eine Templates werden dessen Parameter durch Attribute vorgegeben. Durch '''set save''' wird dann das Template schlussendlich definiert. Folgende Parameter/Attribute werden genutzt:<br />
*'''tpl_description''': ist ein Freitext welcher beschreiben soll, was das Template macht und wie es parametriert wird<br />
*'''tpl_params''': hier werden evtl Parameter definiert mit welchen die Instanziierung des Templates angepasst werden kann. Bspw. könnte die Einschaltzeit variable gestalltet werden. Bei einem Dimmer könnt man den Level und die Rampe eingeben, also 2 Parameter. Man vergibt also, ":" getrennt, eine Liste von Paramtern. Die Namen sind frei wählbar. <br><br />
:''timeOn:ramp'' würde 2 Parameter definieren, welche später in den Registern genutzt werden können<br />
*'''tpl_type''': definiert den Typ. Diesen muss man zuerst festlegen. Es konnte ''peer-Short'',''peer-Long'',''peer-Both'' oder ''basic'' sein. Nach der Auswahl des Typs kann man die Entity (source) wählen. Es alle Entities angeboten, welche entsprechende Registersätze zu Verfügung stellen.<br />
*'''tpl_source''': legt bei der Definition eines Templates fest, von welcher Entity die Register für die Vorlage genutzt werden sollen. Ein Browser-Refresh könnte notwendig sein um die Auswahlliste upzudaten<br />
*'''tpl_peer''': muss man auswählen, so man einen "peer" typ gewählt hat. An Browser-refresh denken. <br />
*'''Reg_xxx''': An Browser-refresh denken. Hat man nun die Vorlage ausgewählt und den Refresh gemach werden nun Register als Attribute angeboten. <br><br />
:Zunächst sollte man Registerattribute löschen, welche man für das Template nicht benötigt. Achtung: eine Option gelöschte Registerattribute wieder nachzutragen ist nicht vorgesehen. So schlimm ist es allerdings nicht - man muss halt noch einmal alle Lesen und von Vorne löschen. <br><br />
:Sinnvoll kann es sein, die Condition Table Register komplett zu eliminieren wenn man Reaktionen auf Taster definieren will. Will man ''ignore'' definieren, also keine Reaktion bspw auf ''long'', dann kann man alles löschen bis auf ActionType usw. <br><br />
:Sinnvoll ist es, nur notwendige Register der Funktion zu bearbeiten, da sonst die Anwendung des Templates eingeschränkt wird. <br><br />
:Es sollten aber alle Register der Funktion enthalten sein, da die Prüfung auch nur diese berücksichtigt und bei einem Umprogrammieren nicht klar ist, was vorher in einem Register gestanden ist.<br />
===Register Werte setzen===<br />
Nun das eigentliche - das setzen der Registerinhalte. Dies wird begrenzt unterstützt. Sollte das Register durch ''literals'' definiert werden erscheint beim Setzen eine drop-down Liste mit den Optionen. <br><br />
Nicht unterstützt wird das Setzen von Werten. Es gibt aktuell keine Option, hier eine Hilfe einzublenden. Die Wertebereiche sind dem regList der Entity zu entnehmen. <br><br />
Eine weitere Besonderheit ist die Granularität der Werte. Insbesondere durch das Float Format einiger Werte sind nicht alle Werte möglich. Trägt man bspw eine Ontime von 10000 ein wird dies erst einmal akzeptiert. Allerdings wird der Wert beim Schreiben umgerechnet in den nächstmöglichen (welcher 9600 ist). Bei der Prüfung der Template Anwendung wird der Unterschied angemerkt. Am Einfachsten wird nun das Template angepasst und alles ist gut.<br><br />
<br><br />
Nun tpl_params. Diese muss man anstelle des Registerwerts einsetzen. Hat man bspw <br><br />
tpl_params timeOn:rampTime<br><br />
definiert setzt man in das Register ''OnTime'' den Wert ''timeOn'' ein. Und eben das Rampenregiste den Wert ''rampTime''. Der Wert wird dann beim Template Instanziieren - also Anwenden - durch den Individuellen ersetzt.<br />
<br />
=Getting started=<br />
Was muss man also tun? Wenn man noch nichts eingerichtet hat:<br />
define hm HMinfo<br />
attr hm autoArchive 1<br />
attr hm autoLoadArchive 1_load<br />
attr hm configFilename regConfig.cfg<br />
define ht HMtemplate<br />
<br />
==Template erstellen und bearbeiten==<br />
Templates kann man erstellen, in dem man die Register einer Entity nimmt und bearbeitet. Auch das Kopieren und Bearbeiten eines vorhandenen Templates ist möglich. Und man kann Templates exportieren/importieren.<br />
===Template aus Device===<br />
Aufgabe ist es, aus einem existierenden Device ein Template zu erstellen. Wir haben <br />
device ''myDev''<br />
Channel ''myChan''<br />
Channel gepeert mit ''myChanPeer''.<br><br />
Der Kanal ist ein Schalter und wir wollen einen Parameter im Template nutzen: Die Anschaltzeit soll bei der Nutzung des Templates variabel eingesetzt werden. Wir werden also den Parameter ''timeOn'' nutzen. Das Template soll ''my1stTmpl'' genannt werden. Weiter soll das gesamte Verhalten des ''myChanPeer'' definiert werden, also short UND long. <br />
set ht define my1stTmpl<br />
attr ht tpl_param timeOn # name des Parameters - hier nur einer<br />
attr ht tpl_description "mein erstes Template"<br />
attr ht tpl_type peer-both<br />
<refresh browser> # select liste der attribute wird neu eingelesen<br />
attr ht tpl_source myChan<br />
<refresh browser> # select liste der attribute wird neu eingelesen<br />
attr ht tpl_peer myChanPeer<br />
<refresh browser> # select liste der attribute wird neu eingelesen<br />
attr ht Reg_shOnTime timeOn # setzen des parameters<br />
<br />
nun können weitere Register verändert werde. <br />
Sinnvoll ist es, unnötige Register aus dem Template zu entfernen. Dies sind in diesem Fall bspw. alle Ct register. Das Attribut des Registers wird einfach gelöscht. <br />
set ht save<br />
set ht dismiss<br />
===Template Varianten speichern===<br />
Ist man beim Erstellen von Templates kann man mti saveAs das Template als neues unter einem anderen Namen sichern. <br />
===Template editieren===<br />
Mit Edit kann man die Werte der Register ändern oder vorhandene Register aus dem Template entfernen. Ein Hinzufügen von Registern wird nicht unterstützt. Hier fehlt die Referenz um anzubieten, was möglich ist.<br />
===Template kopieren===<br />
Dies wird ebenfalls mit edit erreicht. Das Template wird mit saveAs unter einem neuen Namen gespeichert.<br />
===Template export-import===<br />
Will man Templates exportieren nutzt man <br><br />
get ht <templatename><br />
Es wird ein kommando ausgegeben welches man in die Kommandozeile pasten kann, was dann der import ist.<br><br />
Dies kann man nutzen um Templates zu tauschen. Hat man ein ''gutes oder komplexes'' Template kann man dies der Allgemeinheit zu Verfügung stellen.<br><br />
Im besten Fall muss der User sich nicht mehr um Register kümmern, da komfortable Templates das besser abdecken.<br />
<br />
==Template einem Kanal zuweisen==<br />
Jetzt haben wir ein Template welches long [[und]] short eines Kanals kontrollieren soll. Dies wollen wir jetzt anwenden auf unsere Kanal/Peer Kompinationen "sw1/peer1", "sw1/peer2", "sw2/peer1" und "sw2/peer3". Für alle benötigen wir unterschiedliche Abschaltzeiten (warum? eure Sache). <br />
set ht select my1stTmpl<br />
attr ht entity sw1<br />
<refresh browser><br />
attr ht ePeer peer1<br />
attr ht tpl_param_timeOn 30<br />
set ht apply<br />
attr ht ePeer peer2<br />
attr ht tpl_param_timeOn 180<br />
set ht apply<br />
<br />
attr ht entity sw2<br />
<refresh browser><br />
attr ht ePeer peer1<br />
attr ht tpl_param_timeOn 70<br />
set ht apply<br />
<br />
attr ht ePeer peer3<br />
attr ht tpl_param_timeOn 1000<br />
set ht apply<br />
<br />
set ht dismiss<br />
Die Register der Entities werden passend in das Device geschrieben.<br />
<br />
==Template editieren==<br />
Nun soll das Template grundsätzlich modfiziert werden. <br />
<br />
set ht edit my1stTmpl<br />
attr ht Reg_<name> <value><br />
attr ht Reg_<name2> <value2><br />
attr ht Reg_<name3> <value3><br />
set ht save<br />
==Template kopieren und editieren==<br />
Nun soll das Template grundsätzlich modfiziert werden. <br />
<br />
set ht select my1stTmpl<br />
attr ht Reg_<name> <value><br />
attr ht Reg_<name2> <value2><br />
attr ht Reg_<name3> <value3><br />
set ht saveAs my2ndTmpl<br />
==Template weitergeben==<br />
Will man Templates weitergeben geht das mit<br />
get ht my1stTmpl<br />
Das Kommando kann dann direkt in die Kommandozeile kopiert werden und das Template ist definiert.<br />
=Verwaltung und Überblick=<br />
Nun hat man Templates definiert und Instanziiert. Wie soll man den Überblick behalten? HMtemplate ist ein Editor - also nicht wirklich hierfür geeignet. HMinfo macht die Verwaltung. <br />
==Template Überblick==<br />
Will man sehen, was man so an Templates nutzt kann man eine Überscht unterschedliche sortiert ausgeben lassen - in HMinfo (hm).<br />
get hm templateUsgG sortTemplate<br />
get hm templateUsgG sortPeer<br />
get hm templateUsgG all<br />
Sowie eine Liste von Regiserlisten, welche noch kein Template nutzen (noch in Bau!!)<br />
get hm templateUsgG noTmpl<br />
Eine Liste der Verfügbaren Templates erhält man mit <br />
get hm templateList all<br />
und die Register eines Templates mit <br />
get hm templateList <templateName><br />
oder<br />
set ht select <templateName><br />
==Template prüfen==<br />
Templates werden auf korrekte Implementierung in der Entity anhand eines Vergleichs der gelesenen Registern mit den gewünschten Regitern geprüft. Es ist also notwendig, dass die Registerwerte in der FHEM Kopie aktuell sind. Dann reicht ein <br />
get hm configCheck<br />
Sollte es zu Unstimmigkeiten kommen werden mit <br />
set hm templateExe<br />
alle Unstimmigkeiten überschrieben. Klar, wie immer, muss FHEM warten, bis ein Device angesprochen werden kann (Übertragungsmode) und dass die IOs nicht überlastet werden. Die Gefahr einer Überlast ist gering wenn man nicht gleich alles überschreiben will. <br><br />
Wie immer ist es hilfreich den Status der Übertragung im Blick zu haben:<br />
get hm protoEvents<br />
Wenn zu viel passiert ist und man protoEvents aufräumen muss dann (Achtung: es werden alle ausstehenden Kommandos gelöscht und müssen neu aktiviert werden!)<br />
set hm clearG msgEvents<br />
==Template löschen==<br />
set ht delete <tempateName><br />
Achtung: vorher müssen alle Referenzen des Templates entfernt worden sein. <br />
<br />
=Templates in den Entites=<br />
Ist eine Entity mit einem Template verknüpft wird dies in den Readings angezeigt. Dies kann man sichtbar machen - und eine Anzeige von Registern in den Readings sollte dann nicht mehr notwendig sein. Empfohlen wird, den expoer mode auf rein Templates umzustellen<br />
attr TYPE=CUL_HM:FILTER=DEF=......:FILTER=subType!=virtual expert 12_templOnly<br />
deleteattr TYPE=CUL_HM:FILTER=DEF=........ expert<br />
deleteattr TYPE=CUL_HM:FILTER=subType=virtual expert<br />
<br />
=Beispiele und Ideen=<br />
<br />
Neben den typischen Templates für Schalter kann (sollte) man auch bspw für RTs einsetzen. Temperaturlisten sind nicht im Angebot. Hier gibt es bereits andere Verfahren die besser passen. Allerdings experimentire ich bei meinen RTs mit den Regelparametern und will diese dann generell setzen. Alle RTs (bei mir) sollen die gleiche Regelung haben. Ich nutze 3 Templates für meine RTs<br />
* '''HeatDefDev''': Das Device des RT wird auf Standartwerte gesetzt. Hier nutze ich einen Parameter um die Tasten zu sperren. Dies brauche ich nicht bei allen RTs sondern nur bei denen, welche ich mit einem TC gepeert habe. Hier ist eine Lokale Änderung am TC vorzunehmen. <br />
* '''HeatDefault''':Die Standart-Regelung. Auch hier habe ich Parameter vorgesehen. Die Devices sind identisch... bis auf die Boostzeit und die maximals Ventilöffnung. Je nach Hk begrenze ich ValveMax - hängt von den baulichen Gegebenheiten ab. Boost nutze ich im Bad zum entfeuchten.<br />
* '''HeatRemote''': mein ''guteNacht'' Knopf macht auch vor RTs nicht halt. Ich haben an einer Remote einen Button mit allen Lichtern und RTs im Wohnbereich gekoppelt. Beim Drücken wird das Licht abgeschaltet und dieHeizung gedrosselt - bspw wenn ich als letzter ins Bett gehe. Daher brauche ich einen Parameter ''Temperatur'' um das induviduell je RT einzustellen. <br />
set hm templateDef HeatDefDev BtnLock "Default RT Device register" globalBtnLock:off localResDis:off modusBtnLock:off backOnTime:10 cyclicInfoMsg:on lowBatLimitRT:2.1 burstRx:on cyclicInfoMsgDis:0 btnLock:p0<br />
set hm templateDef HeatDefault boost:valveMax "myDefault RT settings, enter boostTime and valveMax" regAdaptive:offDeter reguIntI:20 nightTemp:17 tempOffset:0.0K dayTemp:21 reguIntPstart:5 reguExtI:20 showWeekday:off reguExtP:25 reguIntP:25 tempMax:30.5 tempMin:4.5 valveMaxPos:p1 valveOffsetRt:0 modePrioManu:all daylightSaveTime:on boostPos:30 decalcWeekday:Sat showInfo:time decalcTime:11:00 btnNoBckLight:off reguExtPstart:5 noMinMax4Manu:off modePrioParty:all valveErrPos:15 boostPeriod:p0<br />
set hm templateDef HeatRemote temp "heatRemote set temperature" CtrlRc:autoAndTemp TempRC:p0<br />
<br><br />
In der Übersicht für 2 RTs ergibt ein get hm templateUsg<br />
haEss |0 |HeatDefDev|BtnLock:off <br />
haEss_Clima |0 |HeatDefault|boost:5 valveMax:15 <br />
haEss_remote |FB8_1:short |HeatRemote|temp:13 <br />
haEss_remote |FB8_5:long |HeatRemote|temp:13 <br />
haEss_remote |FB8_5:short |HeatRemote|temp:19 <br />
haLnge |0 |HeatDefDev|BtnLock:off <br />
haLnge_Clima |0 |HeatDefault|boost:5 valveMax:15 <br />
haLnge_remote |FB8_1:short |HeatRemote|temp:13 <br />
haLnge_remote |FB8_5:long |HeatRemote|temp:13 <br />
haLnge_remote |FB8_5:short |HeatRemote|temp:19 <br />
<br />
<br />
<br />
[[Kategorie:HomeMatic supportDevice]]<br />
[[Kategorie:HOWTOS]]</div>Martinp876http://wiki.fhem.de/w/index.php?title=HomeMatic_Templates&diff=23951HomeMatic Templates2017-12-30T14:50:53Z<p>Martinp876: </p>
<hr />
<div>{{Infobox Modul<br />
|ModPurpose=templates bedienen und verwalten<br />
|ModType=h<br />
|ModCmdRef=HMtemplate<br />
|ModForumArea=HomeMatic<br />
|ModTechName=98_HMtemplate.pm<br />
|ModOwner=martinp876 ({{Link2FU|251|martinp876}} / [[Benutzer Diskussion:Martinp876|Wiki]])<br />
}}<br />
Templates sind Vorlagen im Allgemeinen. Hier werden Vorlagen zur Programmierung der Register von HM Devices behandelt. <br />
= Warum Templates =<br />
Die Frage, warum man Register nicht einfach setzt sondern Templates nutzen sollte kommt immer wieder auf. Schliesslich sind wie alle Spezialisten...<br />
Die Wahrheit allerdings bildet das nicht ab. Den auch den Spezialisten sei angeraten, Templates zu nutzen. Ja, warum den, was bieten Templates? Hierzu muss man verstehen wir FHEM, HM, Devices, Kanäle und peers zusammen hängen. <br />
<br />
Wie schon im Einsteigerdoc beschrieben hat ein HM Device remanente Register welche von FHEM gesetzt werden können und die Funktions- und Arbeitsweise definieren. FHEM selbst hat bestenfalls eine Kopie dieser Daten.<br />
;soll-Register Verwaltung<br />
:Da FHEM nur eine Kopie der Registerwerte verwaltet lebt man erst einmal in einer fragilen Welt. Registerwerte können sich ändern durch:<br />
* Reset des Device<br />
* Batteriefehler<br />
* inkorrektes Schreiben und Übertragungsfehler<br />
* Austausch eines Device<br />
:Nach Lesen der Device Register hat FHEM einen neue Kopie - dies muss aber nicht den Wunschregistern entsprechen. Templates sind eine Ansammlung von Wunschregister. Somit können unterschiedliche Mechanismen genutzt werden, das System zu verwalten, prüfen und korrigieren.<br />
;Funktionen für Einsteiger<br />
:Nicht-Experten sollten primär Templates nutzen - um Funktionen zu realisieren, und wenn gewünscht, Experten zu werden. Templares kann man einfach austauschen und dann anwenden.<br />
;Verwalten von Funktionen statt Registern<br />
:Als Experten kann man sicher die Register zeilsicher setzen. Wirklich? Wenn man sich eine clevere Lösung ausgedacht hat und sie reproduzieren will kann man einfach noch einmal nachdenken, nachlesen,... und schon hat man es wieder. Oder man hat ein Template definiert das man einfach nutzt.<br />
; Lernen aus Templates<br />
:Templates sind nicht verschlüsselt. Hat oder bekommt man ein Template kann man die dort gesetzten Register einfach einsehen - und wenn man will verstehen was gemacht wurde. <br />
;Globales Anpassen aller Devices <br />
: Hat man festgestellt, dass eine Funktion sub-optimal ist kann man das Temlate ändern und diese Änderungen allen Devices zu gute kommen lassen. Auf einmal. <br />
<br />
= Grundsätzliches zum Template =<br />
Templates (hier) ist nun also eine Sammlung von Registern welche in einem Device gesetzt werden können. <br />
<br />
== Template Granularität ==<br />
Man kann nicht alle Register eines Device in einem Template abbilden. Das wäre technisch komplex und macht auch von der Anwendung her keinen Sinn. <br />
<br />
*Aus Sicht der Funktion sollte man Templates nach deren Funktionen zusammenfassen.<br />
*Aus Sicht des Devices sollte man Templates nach der Struktur des Device zusammenstellen.<br />
*Die Implementierung erlaubt es, templates für jedes Register einzeln zu erstellen.<br><br />
*Weniger Templates erhöhen die Übersichtlichkeit<br />
Die technische Lösung legt folgenden Templates nahe<br />
#Alle Register eines Kanals oder Device - ausgenommen peer abhängige Register<br />
#Alle Register eines Kanals eines Peers für short oder long<br />
#Alle Register eines Kanals eines Peers nur für short<br />
#Alle Register eines Kanals eines Peers nur für long<br />
Ob man 2. oder die Kombination aus 3. und 4. nutzt ist Geschmackssache. <br><br />
Ein typischer Einsatz sind Schaltern und Dimmer bei welchen man die Aktionen der Peers festlegen will.<br />
;usecase Template Granularität Dimmer<br />
:Mit Peer1 soll bei short ein und bei long ausgeschaltet werden<br />
:Mit Peer2 soll bei short getoggelt und bei long nicht geschaltet werden<br />
:Mit Peer3 soll bei short nicht geschaltet und bei long getoggelt werden<br />
:Mit Peer4 ist ein MotionDetector welcher bei short und einer bestimmten Helligkeit einschaltet, timed. Allerdings sollen Aktionen der anderen Peers oder der Zentrale das Licht dauer-ein schalten.<br />
<br />
== Template Flexibilität ==<br />
Templates sind starr... und können parametriert werden. Also semistarr. Was jetzt? Nun man kann Templates mir bis zu 9 Parametern versehen. Sinnvoll sind wohl eher bis zu 3. <br><br />
Beispiele sind:<br />
*Treppenhausschaltern - mit einem Parameter kann man Einschaltdauer je Instanziierung festlegen. Sinnvoll könnte eine Treppenhausschaltung generell sein, nicht nur im Treppenhaus. Man kann generell alle Lichter nach ein paar Stunden ausschalten.<br />
*Heizungstemplate - Boosttime: Man kann allen RTs das gleiche Template geben - allerdings kann man z.B. die Boosttime indivituell einstellen. <br />
*MotionDetector Clients: Bei den Peers des Modtion detector (also den Schaltern) stellt man ein, dann diese reagieren sollen und wie lange diese brennen sollen. <br />
<br />
== Template Verwaltung==<br />
Templates werden zusammen mit Registern verwaltet. Man benötigt demnach HMinfo. Sowohl die Template definition alsauch die Template Zuweisung werden im File zusammen mit den gelesenen Registern gesichert. Nach einem Einlesen dieses Files werden auch die Templates und deren Zuordnung neu erstellt.<br />
<br />
== Template Editieren==<br />
Die aktuell einfachste Möglichkeit ein Template zu modifizieren ist, HMtemplate zu nutzen. HMtemplate ist ein Editor. Für den Betrieb wird es nicht genutzt. <br />
<br />
<br />
=Das eigenen Konzept=<br />
Für die Verknüpfung von HM Entities muss man 2 Ebenen unterschieden, Architektur und Verhalten.<br />
==Architektur==<br />
Beim Erstellen der Architektur legt man fest, welche Entities untereinander verknüpft werden. Dies geschieht durch peeren. Templates unterstützen nicht die Architektur. Es ist demnach notwendig die Peerings durchzuführen bevor an ein Template darauf anwenden kann. <br />
==Verhalten==<br />
Hier kommen die Templates zum Tragen. Mit Templates definiert man die Register der Entities und somit das Verhalten und die Reaktion der Entites bspw auf Trigger von Sensoren.<br />
===Welchen templateTyp brauche ich===<br />
Wie in Granularität beschrieben kann man insbesondere beim Peerverhalten templates für ''short'', ''long'' oder ''both'' ertellen. Nutzt man short/long braucht man weniger Templates (Basics sind on/off/ignore/toggle) muss allerdings mehr Templates zuweisen, als Reaktion auf short UND long.<br><br />
Bei both braucht man mehr Templates (OnOff/OnIgnore/OffIgnore/IgnoreOff/ToggleIgnore/...) braucht aber nur die Hälfte der Zuweisungen zu den realen Entities. <br />
<br />
===Welche Parameter muss ich einstellen===<br />
Bei der Erstellung eine Templates werden dessen Parameter durch Attribute vorgegeben. Durch '''set save''' wird dann das Template schlussendlich definiert. Folgende Parameter/Attribute werden genutzt:<br />
*'''tpl_description''': ist ein Freitext welcher beschreiben soll, was das Template macht und wie es parametriert wird<br />
*'''tpl_params''': hier werden evtl Parameter definiert mit welchen die Instanziierung des Templates angepasst werden kann. Bspw. könnte die Einschaltzeit variable gestalltet werden. Bei einem Dimmer könnt man den Level und die Rampe eingeben, also 2 Parameter. Man vergibt also, ":" getrennt, eine Liste von Paramtern. Die Namen sind frei wählbar. <br><br />
:''timeOn:ramp'' würde 2 Parameter definieren, welche später in den Registern genutzt werden können<br />
*'''tpl_type''': definiert den Typ. Diesen muss man zuerst festlegen. Es konnte ''peer-Short'',''peer-Long'',''peer-Both'' oder ''basic'' sein. Nach der Auswahl des Typs kann man die Entity (source) wählen. Es alle Entities angeboten, welche entsprechende Registersätze zu Verfügung stellen.<br />
*'''tpl_source''': legt bei der Definition eines Templates fest, von welcher Entity die Register für die Vorlage genutzt werden sollen. Ein Browser-Refresh könnte notwendig sein um die Auswahlliste upzudaten<br />
*'''tpl_peer''': muss man auswählen, so man einen "peer" typ gewählt hat. An Browser-refresh denken. <br />
*'''Reg_xxx''': An Browser-refresh denken. Hat man nun die Vorlage ausgewählt und den Refresh gemach werden nun Register als Attribute angeboten. <br><br />
:Zunächst sollte man Registerattribute löschen, welche man für das Template nicht benötigt. Achtung: eine Option gelöschte Registerattribute wieder nachzutragen ist nicht vorgesehen. So schlimm ist es allerdings nicht - man muss halt noch einmal alle Lesen und von Vorne löschen. <br><br />
:Sinnvoll kann es sein, die Condition Table Register komplett zu eliminieren wenn man Reaktionen auf Taster definieren will. Will man ''ignore'' definieren, also keine Reaktion bspw auf ''long'', dann kann man alles löschen bis auf ActionType usw. <br><br />
:Sinnvoll ist es, nur notwendige Register der Funktion zu bearbeiten, da sonst die Anwendung des Templates eingeschränkt wird. <br><br />
:Es sollten aber alle Register der Funktion enthalten sein, da die Prüfung auch nur diese berücksichtigt und bei einem Umprogrammieren nicht klar ist, was vorher in einem Register gestanden ist.<br />
===Register Werte setzen===<br />
Nun das eigentliche - das setzen der Registerinhalte. Dies wird begrenzt unterstützt. Sollte das Register durch ''literals'' definiert werden erscheint beim Setzen eine drop-down Liste mit den Optionen. <br><br />
Nicht unterstützt wird das Setzen von Werten. Es gibt aktuell keine Option, hier eine Hilfe einzublenden. Die Wertebereiche sind dem regList der Entity zu entnehmen. <br><br />
Eine weitere Besonderheit ist die Granularität der Werte. Insbesondere durch das Float Format einiger Werte sind nicht alle Werte möglich. Trägt man bspw eine Ontime von 10000 ein wird dies erst einmal akzeptiert. Allerdings wird der Wert beim Schreiben umgerechnet in den nächstmöglichen (welcher 9600 ist). Bei der Prüfung der Template Anwendung wird der Unterschied angemerkt. Am Einfachsten wird nun das Template angepasst und alles ist gut.<br><br />
<br><br />
Nun tpl_params. Diese muss man anstelle des Registerwerts einsetzen. Hat man bspw <br><br />
tpl_params timeOn:rampTime<br><br />
definiert setzt man in das Register ''OnTime'' den Wert ''timeOn'' ein. Und eben das Rampenregiste den Wert ''rampTime''. Der Wert wird dann beim Template Instanziieren - also Anwenden - durch den Individuellen ersetzt.<br />
<br />
=Getting started=<br />
Was muss man also tun? Wenn man noch nichts eingerichtet hat:<br />
define hm HMinfo<br />
attr hm autoArchive 1<br />
attr hm autoLoadArchive 1_load<br />
attr hm configFilename regConfig.cfg<br />
define ht HMtemplate<br />
<br />
==Template erstellen und bearbeiten==<br />
Templates kann man erstellen, in dem man die Register einer Entity nimmt und bearbeitet. Auch das Kopieren und Bearbeiten eines vorhandenen Templates ist möglich. Und man kann Templates exportieren/importieren.<br />
===Template aus Device===<br />
Aufgabe ist es, aus einem existierenden Device ein Template zu erstellen. Wir haben <br />
device ''myDev''<br />
Channel ''myChan''<br />
Channel gepeert mit ''myChanPeer''.<br><br />
Der Kanal ist ein Schalter und wir wollen einen Parameter im Template nutzen: Die Anschaltzeit soll bei der Nutzung des Templates variabel eingesetzt werden. Wir werden also den Parameter ''timeOn'' nutzen. Das Template soll ''my1stTmpl'' genannt werden. Weiter soll das gesamte Verhalten des ''myChanPeer'' definiert werden, also short UND long. <br />
set ht define my1stTmpl<br />
attr ht tpl_param timeOn # name des Parameters - hier nur einer<br />
attr ht tpl_description "mein erstes Template"<br />
attr ht tpl_type peer-both<br />
<refresh browser> # select liste der attribute wird neu eingelesen<br />
attr ht tpl_source myChan<br />
<refresh browser> # select liste der attribute wird neu eingelesen<br />
attr ht tpl_peer myChanPeer<br />
<refresh browser> # select liste der attribute wird neu eingelesen<br />
attr ht Reg_shOnTime timeOn # setzen des parameters<br />
<br />
nun können weitere Register verändert werde. <br />
Sinnvoll ist es, unnötige Register aus dem Template zu entfernen. Dies sind in diesem Fall bspw. alle Ct register. Das Attribut des Registers wird einfach gelöscht. <br />
set ht save<br />
set ht dismiss<br />
===Template Varianten speichern===<br />
Ist man beim Erstellen von Templates kann man mti saveAs das Template als neues unter einem anderen Namen sichern. <br />
===Template editieren===<br />
Mit Edit kann man die Werte der Register ändern oder vorhandene Register aus dem Template entfernen. Ein Hinzufügen von Registern wird nicht unterstützt. Hier fehlt die Referenz um anzubieten, was möglich ist.<br />
===Template kopieren===<br />
Dies wird ebenfalls mit edit erreicht. Das Template wird mit saveAs unter einem neuen Namen gespeichert.<br />
===Template export-import===<br />
Will man Templates exportieren nutzt man <br><br />
get ht <templatename><br />
Es wird ein kommando ausgegeben welches man in die Kommandozeile pasten kann, was dann der import ist.<br><br />
Dies kann man nutzen um Templates zu tauschen. Hat man ein ''gutes oder komplexes'' Template kann man dies der Allgemeinheit zu Verfügung stellen.<br><br />
Im besten Fall muss der User sich nicht mehr um Register kümmern, da komfortable Templates das besser abdecken.<br />
<br />
==Template einem Kanal zuweisen==<br />
Jetzt haben wir ein Template welches long [[und]] short eines Kanals kontrollieren soll. Dies wollen wir jetzt anwenden auf unsere Kanal/Peer Kompinationen "sw1/peer1", "sw1/peer2", "sw2/peer1" und "sw2/peer3". Für alle benötigen wir unterschiedliche Abschaltzeiten (warum? eure Sache). <br />
set ht select my1stTmpl<br />
attr ht entity sw1<br />
<refresh browser><br />
attr ht ePeer peer1<br />
attr ht tpl_param_timeOn 30<br />
set ht apply<br />
attr ht ePeer peer2<br />
attr ht tpl_param_timeOn 180<br />
set ht apply<br />
<br />
attr ht entity sw2<br />
<refresh browser><br />
attr ht ePeer peer1<br />
attr ht tpl_param_timeOn 70<br />
set ht apply<br />
<br />
attr ht ePeer peer3<br />
attr ht tpl_param_timeOn 1000<br />
set ht apply<br />
<br />
set ht dismiss<br />
Die Register der Entities werden passend in das Device geschrieben.<br />
<br />
==Template editieren==<br />
Nun soll das Template grundsätzlich modfiziert werden. <br />
<br />
set ht edit my1stTmpl<br />
attr ht Reg_<name> <value><br />
attr ht Reg_<name2> <value2><br />
attr ht Reg_<name3> <value3><br />
set ht save<br />
==Template kopieren und editieren==<br />
Nun soll das Template grundsätzlich modfiziert werden. <br />
<br />
set ht select my1stTmpl<br />
attr ht Reg_<name> <value><br />
attr ht Reg_<name2> <value2><br />
attr ht Reg_<name3> <value3><br />
set ht saveAs my2ndTmpl<br />
==Template weitergeben==<br />
Will man Templates weitergeben geht das mit<br />
get ht my1stTmpl<br />
Das Kommando kann dann direkt in die Kommandozeile kopiert werden und das Template ist definiert.<br />
=Verwaltung und Überblick=<br />
Nun hat man Templates definiert und Instanziiert. Wie soll man den Überblick behalten? HMtemplate ist ein Editor - also nicht wirklich hierfür geeignet. HMinfo macht die Verwaltung. <br />
==Template Überblick==<br />
Will man sehen, was man so an Templates nutzt kann man eine Überscht unterschedliche sortiert ausgeben lassen - in HMinfo (hm).<br />
get hm templateUsgG sortTemplate<br />
get hm templateUsgG sortPeer<br />
get hm templateUsgG all<br />
Sowie eine Liste von Regiserlisten, welche noch kein Template nutzen (noch in Bau!!)<br />
get hm templateUsgG noTmpl<br />
Eine Liste der Verfügbaren Templates erhält man mit <br />
get hm templateList all<br />
und die Register eines Templates mit <br />
get hm templateList <templateName><br />
oder<br />
set ht select <templateName><br />
==Template prüfen==<br />
Templates werden auf korrekte Implementierung in der Entity anhand eines Vergleichs der gelesenen Registern mit den gewünschten Regitern geprüft. Es ist also notwendig, dass die Registerwerte in der FHEM Kopie aktuell sind. Dann reicht ein <br />
get hm configCheck<br />
Sollte es zu Unstimmigkeiten kommen werden mit <br />
set hm templateExe<br />
alle Unstimmigkeiten überschrieben. Klar, wie immer, muss FHEM warten, bis ein Device angesprochen werden kann (Übertragungsmode) und dass die IOs nicht überlastet werden. Die Gefahr einer Überlast ist gering wenn man nicht gleich alles überschreiben will. <br><br />
Wie immer ist es hilfreich den Status der Übertragung im Blick zu haben:<br />
get hm protoEvents<br />
Wenn zu viel passiert ist und man protoEvents aufräumen muss dann (Achtung: es werden alle ausstehenden Kommandos gelöscht und müssen neu aktiviert werden!)<br />
set hm clearG msgEvents<br />
==Template löschen==<br />
set ht delete <tempateName><br />
Achtung: vorher müssen alle Referenzen des Templates entfernt worden sein. <br />
<br />
=Templates in den Entites=<br />
Ist eine Entity mit einem Template verknüpft wird dies in den Readings angezeigt. Dies kann man sichtbar machen - und eine Anzeige von Registern in den Readings sollte dann nicht mehr notwendig sein. Empfohlen wird, den expoer mode auf rein Templates umzustellen<br />
attr TYPE=CUL_HM:FILTER=DEF=......:FILTER=subType!=virtual expert 12_templOnly<br />
deleteattr TYPE=CUL_HM:FILTER=DEF=........ expert<br />
deleteattr TYPE=CUL_HM:FILTER=subType=virtual expert<br />
<br />
=Beispiele und Ideen=<br />
Neben den typischen Templates für Schalter kann (sollte) man auch bspw für RTs einsetzen. Temperaturlisten sind nicht im Angebot. Hier gibt es bereits andere Verfahren die besser passen. Allerdings experimentire ich bei meinen RTs mit den Regelparametern und will diese dann generell setzen. Alle RTs (bei mir) sollen die gleiche Regelung haben. Ich nutze 3 Templates für meine RTs<br />
* '''HeatDefDev''': Das Device des RT wird auf Standartwerte gesetzt. Hier nutze ich einen Parameter um die Tasten zu sperren. Dies brauche ich nicht bei allen RTs sondern nur bei denen, welche ich mit einem TC gepeert habe. Hier ist eine Lokale Änderung am TC vorzunehmen. <br />
* '''HeatDefault''':Die Standart-Regelung. Auch hier habe ich Parameter vorgesehen. Die Devices sind identisch... bis auf die Boostzeit und die maximals Ventilöffnung. Je nach Hk begrenze ich ValveMax - hängt von den baulichen Gegebenheiten ab. Boost nutze ich im Bad zum entfeuchten.<br />
* '''HeatRemote''': mein ''guteNacht'' Knopf macht auch vor RTs nicht halt. Ich haben an einer Remote einen Button mit allen Lichtern und RTs im Wohnbereich gekoppelt. Beim Drücken wird das Licht abgeschaltet und dieHeizung gedrosselt - bspw wenn ich als letzter ins Bett gehe. Daher brauche ich einen Parameter ''Temperatur'' um das induviduell je RT einzustellen. <br />
set hm templateDef HeatDefDev BtnLock "Default RT Device register" globalBtnLock:off localResDis:off modusBtnLock:off backOnTime:10 cyclicInfoMsg:on lowBatLimitRT:2.1 burstRx:on cyclicInfoMsgDis:0 btnLock:p0<br />
set hm templateDef HeatDefault boost:valveMax "myDefault RT settings, enter boostTime and valveMax" regAdaptive:offDeter reguIntI:20 nightTemp:17 tempOffset:0.0K dayTemp:21 reguIntPstart:5 reguExtI:20 showWeekday:off reguExtP:25 reguIntP:25 tempMax:30.5 tempMin:4.5 valveMaxPos:p1 valveOffsetRt:0 modePrioManu:all daylightSaveTime:on boostPos:30 decalcWeekday:Sat showInfo:time decalcTime:11:00 btnNoBckLight:off reguExtPstart:5 noMinMax4Manu:off modePrioParty:all valveErrPos:15 boostPeriod:p0<br />
set hm templateDef HeatRemote temp "heatRemote set temperature" CtrlRc:autoAndTemp TempRC:p0<br />
<br><br />
In der Übersicht für 2 RTs ergibt ein get hm templateUsg<br />
haEss |0 |HeatDefDev|BtnLock:off <br />
haEss_Clima |0 |HeatDefault|boost:5 valveMax:15 <br />
haEss_remote |FB8_1:short |HeatRemote|temp:13 <br />
haEss_remote |FB8_5:long |HeatRemote|temp:13 <br />
haEss_remote |FB8_5:short |HeatRemote|temp:19 <br />
haLnge |0 |HeatDefDev|BtnLock:off <br />
haLnge_Clima |0 |HeatDefault|boost:5 valveMax:15 <br />
haLnge_remote |FB8_1:short |HeatRemote|temp:13 <br />
haLnge_remote |FB8_5:long |HeatRemote|temp:13 <br />
haLnge_remote |FB8_5:short |HeatRemote|temp:19 <br />
<br />
<br />
<br />
[[Kategorie:HomeMatic supportDevice]]<br />
[[Kategorie:HOWTOS]]</div>Martinp876http://wiki.fhem.de/w/index.php?title=HomeMatic_Templates&diff=23950HomeMatic Templates2017-12-30T14:48:04Z<p>Martinp876: </p>
<hr />
<div>{{Infobox Modul<br />
|ModPurpose=templates bedienen und verwalten<br />
|ModType=h<br />
|ModCmdRef=HMtemplate<br />
|ModForumArea=HomeMatic<br />
|ModTechName=98_HMtemplate.pm<br />
|ModOwner=martinp876 ({{Link2FU|251|martinp876}} / [[Benutzer Diskussion:Martinp876|Wiki]])<br />
}}<br />
Templates sind Vorlagen im Allgemeinen. Hier werden Vorlagen zur Programmierung der Register von HM Devices behandelt. <br />
= Warum Templates =<br />
Die Frage, warum man Register nicht einfach setzt sondern Templates nutzen sollte kommt immer wieder auf. Schliesslich sind wie alle Spezialisten...<br />
Die Wahrheit allerdings bildet das nicht ab. Den auch den Spezialisten sei angeraten, Templates zu nutzen. Ja, warum den, was bieten Templates? Hierzu muss man verstehen wir FHEM, HM, Devices, Kanäle und peers zusammen hängen. <br />
<br />
Wie schon im Einsteigerdoc beschrieben hat ein HM Device remanente Register welche von FHEM gesetzt werden können und die Funktions- und Arbeitsweise definieren. FHEM selbst hat bestenfalls eine Kopie dieser Daten.<br />
;soll-Register Verwaltung<br />
:Da FHEM nur eine Kopie der Registerwerte verwaltet lebt man erst einmal in einer fragilen Welt. Registerwerte können sich ändern durch:<br />
* Reset des Device<br />
* Batteriefehler<br />
* inkorrektes Schreiben und Übertragungsfehler<br />
* Austausch eines Device<br />
:Nach Lesen der Device Register hat FHEM einen neue Kopie - dies muss aber nicht den Wunschregistern entsprechen. Templates sind eine Ansammlung von Wunschregister. Somit können unterschiedliche Mechanismen genutzt werden, das System zu verwalten, prüfen und korrigieren.<br />
;Funktionen für Einsteiger<br />
:Nicht-Experten sollten primär Templates nutzen - um Funktionen zu realisieren, und wenn gewünscht, Experten zu werden. Templares kann man einfach austauschen und dann anwenden.<br />
;Verwalten von Funktionen statt Registern<br />
:Als Experten kann man sicher die Register zeilsicher setzen. Wirklich? Wenn man sich eine clevere Lösung ausgedacht hat und sie reproduzieren will kann man einfach noch einmal nachdenken, nachlesen,... und schon hat man es wieder. Oder man hat ein Template definiert das man einfach nutzt.<br />
; Lernen aus Templates<br />
:Templates sind nicht verschlüsselt. Hat oder bekommt man ein Template kann man die dort gesetzten Register einfach einsehen - und wenn man will verstehen was gemacht wurde. <br />
;Globales Anpassen aller Devices <br />
: Hat man festgestellt, dass eine Funktion sub-optimal ist kann man das Temlate ändern und diese Änderungen allen Devices zu gute kommen lassen. Auf einmal. <br />
<br />
= Grundsätzliches zum Template =<br />
Templates (hier) ist nun also eine Sammlung von Registern welche in einem Device gesetzt werden können. <br />
<br />
== Template Granularität ==<br />
Man kann nicht alle Register eines Device in einem Template abbilden. Das wäre technisch komplex und macht auch von der Anwendung her keinen Sinn. <br />
<br />
*Aus Sicht der Funktion sollte man Templates nach deren Funktionen zusammenfassen.<br />
*Aus Sicht des Devices sollte man Templates nach der Struktur des Device zusammenstellen.<br />
*Die Implementierung erlaubt es, templates für jedes Register einzeln zu erstellen.<br><br />
*Weniger Templates erhöhen die Übersichtlichkeit<br />
Die technische Lösung legt folgenden Templates nahe<br />
#Alle Register eines Kanals oder Device - ausgenommen peer abhängige Register<br />
#Alle Register eines Kanals eines Peers für short oder long<br />
#Alle Register eines Kanals eines Peers nur für short<br />
#Alle Register eines Kanals eines Peers nur für long<br />
Ob man 2. oder die Kombination aus 3. und 4. nutzt ist Geschmackssache. <br><br />
Ein typischer Einsatz sind Schaltern und Dimmer bei welchen man die Aktionen der Peers festlegen will.<br />
;usecase Template Granularität Dimmer<br />
:Mit Peer1 soll bei short ein und bei long ausgeschaltet werden<br />
:Mit Peer2 soll bei short getoggelt und bei long nicht geschaltet werden<br />
:Mit Peer3 soll bei short nicht geschaltet und bei long getoggelt werden<br />
:Mit Peer4 ist ein MotionDetector welcher bei short und einer bestimmten Helligkeit einschaltet, timed. Allerdings sollen Aktionen der anderen Peers oder der Zentrale das Licht dauer-ein schalten.<br />
<br />
== Template Flexibilität ==<br />
Templates sind starr... und können parametriert werden. Also semistarr. Was jetzt? Nun man kann Templates mir bis zu 9 Parametern versehen. Sinnvoll sind wohl eher bis zu 3. <br><br />
Beispiele sind:<br />
*Treppenhausschaltern - mit einem Parameter kann man Einschaltdauer je Instanziierung festlegen. Sinnvoll könnte eine Treppenhausschaltung generell sein, nicht nur im Treppenhaus. Man kann generell alle Lichter nach ein paar Stunden ausschalten.<br />
*Heizungstemplate - Boosttime: Man kann allen RTs das gleiche Template geben - allerdings kann man z.B. die Boosttime indivituell einstellen. <br />
*MotionDetector Clients: Bei den Peers des Modtion detector (also den Schaltern) stellt man ein, dann diese reagieren sollen und wie lange diese brennen sollen. <br />
<br />
== Template Verwaltung==<br />
Templates werden zusammen mit Registern verwaltet. Man benötigt demnach HMinfo. Sowohl die Template definition alsauch die Template Zuweisung werden im File zusammen mit den gelesenen Registern gesichert. Nach einem Einlesen dieses Files werden auch die Templates und deren Zuordnung neu erstellt.<br />
<br />
== Template Editieren==<br />
Die aktuell einfachste Möglichkeit ein Template zu modifizieren ist, HMtemplate zu nutzen. HMtemplate ist ein Editor. Für den Betrieb wird es nicht genutzt. <br />
<br />
<br />
=Das eigenen Konzept=<br />
Für die Verknüpfung von HM Entities muss man 2 Ebenen unterschieden, Architektur und Verhalten.<br />
==Architektur==<br />
Beim Erstellen der Architektur legt man fest, welche Entities untereinander verknüpft werden. Dies geschieht durch peeren. Templates unterstützen nicht die Architektur. Es ist demnach notwendig die Peerings durchzuführen bevor an ein Template darauf anwenden kann. <br />
==Verhalten==<br />
Hier kommen die Templates zum Tragen. Mit Templates definiert man die Register der Entities und somit das Verhalten und die Reaktion der Entites bspw auf Trigger von Sensoren.<br />
===Welchen templateTyp brauche ich===<br />
Wie in Granularität beschrieben kann man insbesondere beim Peerverhalten templates für ''short'', ''long'' oder ''both'' ertellen. Nutzt man short/long braucht man weniger Templates (Basics sind on/off/ignore/toggle) muss allerdings mehr Templates zuweisen, als Reaktion auf short UND long.<br><br />
Bei both braucht man mehr Templates (OnOff/OnIgnore/OffIgnore/IgnoreOff/ToggleIgnore/...) braucht aber nur die Hälfte der Zuweisungen zu den realen Entities. <br />
<br />
===Welche Parameter muss ich einstellen===<br />
Bei der Erstellung eine Templates werden dessen Parameter durch Attribute vorgegeben. Durch '''set save''' wird dann das Template schlussendlich definiert. Folgende Parameter/Attribute werden genutzt:<br />
*'''tpl_description''': ist ein Freitext welcher beschreiben soll, was das Template macht und wie es parametriert wird<br />
*'''tpl_params''': hier werden evtl Parameter definiert mit welchen die Instanziierung des Templates angepasst werden kann. Bspw. könnte die Einschaltzeit variable gestalltet werden. Bei einem Dimmer könnt man den Level und die Rampe eingeben, also 2 Parameter. Man vergibt also, ":" getrennt, eine Liste von Paramtern. Die Namen sind frei wählbar. <br><br />
:''timeOn:ramp'' würde 2 Parameter definieren, welche später in den Registern genutzt werden können<br />
*'''tpl_type''': definiert den Typ. Diesen muss man zuerst festlegen. Es konnte ''peer-Short'',''peer-Long'',''peer-Both'' oder ''basic'' sein. Nach der Auswahl des Typs kann man die Entity (source) wählen. Es alle Entities angeboten, welche entsprechende Registersätze zu Verfügung stellen.<br />
*'''tpl_source''': legt bei der Definition eines Templates fest, von welcher Entity die Register für die Vorlage genutzt werden sollen. Ein Browser-Refresh könnte notwendig sein um die Auswahlliste upzudaten<br />
*'''tpl_peer''': muss man auswählen, so man einen "peer" typ gewählt hat. An Browser-refresh denken. <br />
*'''Reg_xxx''': An Browser-refresh denken. Hat man nun die Vorlage ausgewählt und den Refresh gemach werden nun Register als Attribute angeboten. <br><br />
:Zunächst sollte man Registerattribute löschen, welche man für das Template nicht benötigt. Achtung: eine Option gelöschte Registerattribute wieder nachzutragen ist nicht vorgesehen. So schlimm ist es allerdings nicht - man muss halt noch einmal alle Lesen und von Vorne löschen. <br><br />
:Sinnvoll kann es sein, die Condition Table Register komplett zu eliminieren wenn man Reaktionen auf Taster definieren will. Will man ''ignore'' definieren, also keine Reaktion bspw auf ''long'', dann kann man alles löschen bis auf ActionType usw. <br><br />
:Sinnvoll ist es, nur notwendige Register der Funktion zu bearbeiten, da sonst die Anwendung des Templates eingeschränkt wird. <br><br />
:Es sollten aber alle Register der Funktion enthalten sein, da die Prüfung auch nur diese berücksichtigt und bei einem Umprogrammieren nicht klar ist, was vorher in einem Register gestanden ist.<br />
===Register Werte setzen===<br />
Nun das eigentliche - das setzen der Registerinhalte. Dies wird begrenzt unterstützt. Sollte das Register durch ''literals'' definiert werden erscheint beim Setzen eine drop-down Liste mit den Optionen. <br><br />
Nicht unterstützt wird das Setzen von Werten. Es gibt aktuell keine Option, hier eine Hilfe einzublenden. Die Wertebereiche sind dem regList der Entity zu entnehmen. <br><br />
Eine weitere Besonderheit ist die Granularität der Werte. Insbesondere durch das Float Format einiger Werte sind nicht alle Werte möglich. Trägt man bspw eine Ontime von 10000 ein wird dies erst einmal akzeptiert. Allerdings wird der Wert beim Schreiben umgerechnet in den nächstmöglichen (welcher 9600 ist). Bei der Prüfung der Template Anwendung wird der Unterschied angemerkt. Am Einfachsten wird nun das Template angepasst und alles ist gut.<br><br />
<br><br />
Nun tpl_params. Diese muss man anstelle des Registerwerts einsetzen. Hat man bspw <br><br />
tpl_params timeOn:rampTime<br><br />
definiert setzt man in das Register ''OnTime'' den Wert ''timeOn'' ein. Und eben das Rampenregiste den Wert ''rampTime''. Der Wert wird dann beim Template Instanziieren - also Anwenden - durch den Individuellen ersetzt.<br />
<br />
=Getting started=<br />
Was muss man also tun? Wenn man noch nichts eingerichtet hat:<br />
define hm HMinfo<br />
attr hm autoArchive 1<br />
attr hm autoLoadArchive 1_load<br />
attr hm configFilename regConfig.cfg<br />
define ht HMtemplate<br />
<br />
==Template erstellen und bearbeiten==<br />
Templates kann man erstellen, in dem man die Register einer Entity nimmt und bearbeitet. Auch das Kopieren und Bearbeiten eines vorhandenen Templates ist möglich. Und man kann Templates exportieren/importieren.<br />
===Template aus Device===<br />
Aufgabe ist es, aus einem existierenden Device ein Template zu erstellen. Wir haben <br />
device ''myDev''<br />
Channel ''myChan''<br />
Channel gepeert mit ''myChanPeer''.<br><br />
Der Kanal ist ein Schalter und wir wollen einen Parameter im Template nutzen: Die Anschaltzeit soll bei der Nutzung des Templates variabel eingesetzt werden. Wir werden also den Parameter ''timeOn'' nutzen. Das Template soll ''my1stTmpl'' genannt werden. Weiter soll das gesamte Verhalten des ''myChanPeer'' definiert werden, also short UND long. <br />
set ht define my1stTmpl<br />
attr ht tpl_param timeOn # name des Parameters - hier nur einer<br />
attr ht tpl_description "mein erstes Template"<br />
attr ht tpl_type peer-both<br />
<refresh browser> # select liste der attribute wird neu eingelesen<br />
attr ht tpl_source myChan<br />
<refresh browser> # select liste der attribute wird neu eingelesen<br />
attr ht tpl_peer myChanPeer<br />
<refresh browser> # select liste der attribute wird neu eingelesen<br />
attr ht Reg_shOnTime timeOn # setzen des parameters<br />
<br />
nun können weitere Register verändert werde. <br />
Sinnvoll ist es, unnötige Register aus dem Template zu entfernen. Dies sind in diesem Fall bspw. alle Ct register. Das Attribut des Registers wird einfach gelöscht. <br />
set ht save<br />
set ht dismiss<br />
===Template Varianten speichern===<br />
Ist man beim Erstellen von Templates kann man mti saveAs das Template als neues unter einem anderen Namen sichern. <br />
===Template editieren===<br />
Mit Edit kann man die Werte der Register ändern oder vorhandene Register aus dem Template entfernen. Ein Hinzufügen von Registern wird nicht unterstützt. Hier fehlt die Referenz um anzubieten, was möglich ist.<br />
===Template kopieren===<br />
Dies wird ebenfalls mit edit erreicht. Das Template wird mit saveAs unter einem neuen Namen gespeichert.<br />
===Template export-import===<br />
Will man Templates exportieren nutzt man <br><br />
get ht <templatename><br />
Es wird ein kommando ausgegeben welches man in die Kommandozeile pasten kann, was dann der import ist.<br><br />
Dies kann man nutzen um Templates zu tauschen. Hat man ein ''gutes oder komplexes'' Template kann man dies der Allgemeinheit zu Verfügung stellen.<br><br />
Im besten Fall muss der User sich nicht mehr um Register kümmern, da komfortable Templates das besser abdecken.<br />
<br />
==Template einem Kanal zuweisen==<br />
Jetzt haben wir ein Template welches long [[und]] short eines Kanals kontrollieren soll. Dies wollen wir jetzt anwenden auf unsere Kanal/Peer Kompinationen "sw1/peer1", "sw1/peer2", "sw2/peer1" und "sw2/peer3". Für alle benötigen wir unterschiedliche Abschaltzeiten (warum? eure Sache). <br />
set ht select my1stTmpl<br />
attr ht entity sw1<br />
<refresh browser><br />
attr ht ePeer peer1<br />
attr ht tpl_param_timeOn 30<br />
set ht apply<br />
attr ht ePeer peer2<br />
attr ht tpl_param_timeOn 180<br />
set ht apply<br />
<br />
attr ht entity sw2<br />
<refresh browser><br />
attr ht ePeer peer1<br />
attr ht tpl_param_timeOn 70<br />
set ht apply<br />
<br />
attr ht ePeer peer3<br />
attr ht tpl_param_timeOn 1000<br />
set ht apply<br />
<br />
set ht dismiss<br />
Die Register der Entities werden passend in das Device geschrieben.<br />
<br />
==Template editieren==<br />
Nun soll das Template grundsätzlich modfiziert werden. <br />
<br />
set ht edit my1stTmpl<br />
attr ht Reg_<name> <value><br />
attr ht Reg_<name2> <value2><br />
attr ht Reg_<name3> <value3><br />
set ht save<br />
==Template kopieren und editieren==<br />
Nun soll das Template grundsätzlich modfiziert werden. <br />
<br />
set ht select my1stTmpl<br />
attr ht Reg_<name> <value><br />
attr ht Reg_<name2> <value2><br />
attr ht Reg_<name3> <value3><br />
set ht saveAs my2ndTmpl<br />
==Template weitergeben==<br />
Will man Templates weitergeben geht das mit<br />
get ht my1stTmpl<br />
Das Kommando kann dann direkt in die Kommandozeile kopiert werden und das Template ist definiert.<br />
=Verwaltung und Überblick=<br />
Nun hat man Templates definiert und Instanziiert. Wie soll man den Überblick behalten? HMtemplate ist ein Editor - also nicht wirklich hierfür geeignet. HMinfo macht die Verwaltung. <br />
==Template Überblick==<br />
Will man sehen, was man so an Templates nutzt kann man eine Überscht unterschedliche sortiert ausgeben lassen - in HMinfo (hm).<br />
get hm templateUsgG sortTemplate<br />
get hm templateUsgG sortPeer<br />
get hm templateUsgG all<br />
Sowie eine Liste von Regiserlisten, welche noch kein Template nutzen (noch in Bau!!)<br />
get hm templateUsgG noTmpl<br />
Eine Liste der Verfügbaren Templates erhält man mit <br />
get hm templateList all<br />
und die Register eines Templates mit <br />
get hm templateList <templateName><br />
oder<br />
set ht select <templateName><br />
==Template prüfen==<br />
Templates werden auf korrekte Implementierung in der Entity anhand eines Vergleichs der gelesenen Registern mit den gewünschten Regitern geprüft. Es ist also notwendig, dass die Registerwerte in der FHEM Kopie aktuell sind. Dann reicht ein <br />
get hm configCheck<br />
Sollte es zu Unstimmigkeiten kommen werden mit <br />
set hm templateExe<br />
alle Unstimmigkeiten überschrieben. Klar, wie immer, muss FHEM warten, bis ein Device angesprochen werden kann (Übertragungsmode) und dass die IOs nicht überlastet werden. Die Gefahr einer Überlast ist gering wenn man nicht gleich alles überschreiben will. <br><br />
Wie immer ist es hilfreich den Status der Übertragung im Blick zu haben:<br />
get hm protoEvents<br />
Wenn zu viel passiert ist und man protoEvents aufräumen muss dann (Achtung: es werden alle ausstehenden Kommandos gelöscht und müssen neu aktiviert werden!)<br />
set hm clearG msgEvents<br />
==Template löschen==<br />
set ht delete <tempateName><br />
Achtung: vorher müssen alle Referenzen des Templates entfernt worden sein. <br />
<br />
=Templates in den Entites=<br />
Ist eine Entity mit einem Template verknüpft wird dies in den Readings angezeigt. Dies kann man sichtbar machen - und eine Anzeige von Registern in den Readings sollte dann nicht mehr notwendig sein. Empfohlen wird, den expoer mode auf rein Templates umzustellen<br />
attr TYPE=CUL_HM:FILTER=DEF=......:FILTER=subType!=virtual expert 12_templOnly<br />
deleteattr TYPE=CUL_HM:FILTER=DEF=........ expert<br />
deleteattr TYPE=CUL_HM:FILTER=subType=virtual expert<br />
<br />
=Beispiele und Ideen=<br />
Neben den typischen Templates für Schalter kann (sollte) man auch bspw für RTs einsetzen. Temperaturlisten sind nicht im Angebot. Hier gibt es bereits andere Verfahren die besser passen. Allerdings experimentire ich bei meinen RTs mit den Regelparametern und will diese dann generell setzen. Alle RTs (bei mir) sollen die gleiche Regelung haben. Ich nutze 3 Templates für meine RTs<br />
* '''HeatDefDev''': Das Device des RT wird auf Standartwerte gesetzt. Hier nutze ich einen Parameter um die Tasten zu sperren. Dies brauche ich nicht bei allen RTs sondern nur bei denen, welche ich mit einem TC gepeert habe. Hier ist eine Lokale Änderung am TC vorzunehmen. <br />
* '''HeatDefault''':Die Standart-Regelung. Auch hier habe ich Parameter vorgesehen. Die Devices sind identisch... bis auf die Boostzeit und die maximals Ventilöffnung. Je nach Hk begrenze ich ValveMax - hängt von den baulichen Gegebenheiten ab. Boost nutze ich im Bad zum entfeuchten.<br />
* '''HeatRemote''': mein ''guteNacht'' Knopf macht auch vor RTs nicht halt. Ich haben an einer Remote einen Button mit allen Lichtern und RTs im Wohnbereich gekoppelt. Beim Drücken wird das Licht abgeschaltet und dieHeizung gedrosselt - bspw wenn ich als letzter ins Bett gehe. Daher brauche ich einen Parameter ''Temperatur'' um das induviduell je RT einzustellen. <br />
set hm templateDef HeatDefDev BtnLock "Default RT Device register" globalBtnLock:off localResDis:off modusBtnLock:off backOnTime:10 cyclicInfoMsg:on lowBatLimitRT:2.1 burstRx:on cyclicInfoMsgDis:0 btnLock:p0<br />
set hm templateDef HeatDefault boost:valveMax "myDefault RT settings, enter boostTime and valveMax" regAdaptive:offDeter reguIntI:20 nightTemp:17 tempOffset:0.0K dayTemp:21 reguIntPstart:5 reguExtI:20 showWeekday:off reguExtP:25 reguIntP:25 tempMax:30.5 tempMin:4.5 valveMaxPos:p1 valveOffsetRt:0 modePrioManu:all daylightSaveTime:on boostPos:30 decalcWeekday:Sat showInfo:time decalcTime:11:00 btnNoBckLight:off reguExtPstart:5 noMinMax4Manu:off modePrioParty:all valveErrPos:15 boostPeriod:p0<br />
set hm templateDef HeatRemote temp "heatRemote set temperature" CtrlRc:autoAndTemp TempRC:p0<br />
<br />
<br />
<br />
<br />
<br />
[[Kategorie:HomeMatic supportDevice]]<br />
[[Kategorie:HOWTOS]]</div>Martinp876http://wiki.fhem.de/w/index.php?title=HomeMatic_Templates&diff=23949HomeMatic Templates2017-12-30T14:11:11Z<p>Martinp876: </p>
<hr />
<div>{{Infobox Modul<br />
|ModPurpose=templates bedienen und verwalten<br />
|ModType=h<br />
|ModCmdRef=HMtemplate<br />
|ModForumArea=HomeMatic<br />
|ModTechName=98_HMtemplate.pm<br />
|ModOwner=martinp876 ({{Link2FU|251|martinp876}} / [[Benutzer Diskussion:Martinp876|Wiki]])<br />
}}<br />
Templates sind Vorlagen im Allgemeinen. Hier werden Vorlagen zur Programmierung der Register von HM Devices behandelt. <br />
= Warum Templates =<br />
Die Frage, warum man Register nicht einfach setzt sondern Templates nutzen sollte kommt immer wieder auf. Schliesslich sind wie alle Spezialisten...<br />
Die Wahrheit allerdings bildet das nicht ab. Den auch den Spezialisten sei angeraten, Templates zu nutzen. Ja, warum den, was bieten Templates? Hierzu muss man verstehen wir FHEM, HM, Devices, Kanäle und peers zusammen hängen. <br />
<br />
Wie schon im Einsteigerdoc beschrieben hat ein HM Device remanente Register welche von FHEM gesetzt werden können und die Funktions- und Arbeitsweise definieren. FHEM selbst hat bestenfalls eine Kopie dieser Daten.<br />
;soll-Register Verwaltung<br />
:Da FHEM nur eine Kopie der Registerwerte verwaltet lebt man erst einmal in einer fragilen Welt. Registerwerte können sich ändern durch:<br />
* Reset des Device<br />
* Batteriefehler<br />
* inkorrektes Schreiben und Übertragungsfehler<br />
* Austausch eines Device<br />
:Nach Lesen der Device Register hat FHEM einen neue Kopie - dies muss aber nicht den Wunschregistern entsprechen. Templates sind eine Ansammlung von Wunschregister. Somit können unterschiedliche Mechanismen genutzt werden, das System zu verwalten, prüfen und korrigieren.<br />
;Funktionen für Einsteiger<br />
:Nicht-Experten sollten primär Templates nutzen - um Funktionen zu realisieren, und wenn gewünscht, Experten zu werden. Templares kann man einfach austauschen und dann anwenden.<br />
;Verwalten von Funktionen statt Registern<br />
:Als Experten kann man sicher die Register zeilsicher setzen. Wirklich? Wenn man sich eine clevere Lösung ausgedacht hat und sie reproduzieren will kann man einfach noch einmal nachdenken, nachlesen,... und schon hat man es wieder. Oder man hat ein Template definiert das man einfach nutzt.<br />
; Lernen aus Templates<br />
:Templates sind nicht verschlüsselt. Hat oder bekommt man ein Template kann man die dort gesetzten Register einfach einsehen - und wenn man will verstehen was gemacht wurde. <br />
;Globales Anpassen aller Devices <br />
: Hat man festgestellt, dass eine Funktion sub-optimal ist kann man das Temlate ändern und diese Änderungen allen Devices zu gute kommen lassen. Auf einmal. <br />
<br />
= Grundsätzliches zum Template =<br />
Templates (hier) ist nun also eine Sammlung von Registern welche in einem Device gesetzt werden können. <br />
<br />
== Template Granularität ==<br />
Man kann nicht alle Register eines Device in einem Template abbilden. Das wäre technisch komplex und macht auch von der Anwendung her keinen Sinn. <br />
<br />
*Aus Sicht der Funktion sollte man Templates nach deren Funktionen zusammenfassen.<br />
*Aus Sicht des Devices sollte man Templates nach der Struktur des Device zusammenstellen.<br />
*Die Implementierung erlaubt es, templates für jedes Register einzeln zu erstellen.<br><br />
*Weniger Templates erhöhen die Übersichtlichkeit<br />
Die technische Lösung legt folgenden Templates nahe<br />
#Alle Register eines Kanals oder Device - ausgenommen peer abhängige Register<br />
#Alle Register eines Kanals eines Peers für short oder long<br />
#Alle Register eines Kanals eines Peers nur für short<br />
#Alle Register eines Kanals eines Peers nur für long<br />
Ob man 2. oder die Kombination aus 3. und 4. nutzt ist Geschmackssache. <br><br />
Ein typischer Einsatz sind Schaltern und Dimmer bei welchen man die Aktionen der Peers festlegen will.<br />
;usecase Template Granularität Dimmer<br />
:Mit Peer1 soll bei short ein und bei long ausgeschaltet werden<br />
:Mit Peer2 soll bei short getoggelt und bei long nicht geschaltet werden<br />
:Mit Peer3 soll bei short nicht geschaltet und bei long getoggelt werden<br />
:Mit Peer4 ist ein MotionDetector welcher bei short und einer bestimmten Helligkeit einschaltet, timed. Allerdings sollen Aktionen der anderen Peers oder der Zentrale das Licht dauer-ein schalten.<br />
<br />
== Template Flexibilität ==<br />
Templates sind starr... und können parametriert werden. Also semistarr. Was jetzt? Nun man kann Templates mir bis zu 9 Parametern versehen. Sinnvoll sind wohl eher bis zu 3. <br><br />
Beispiele sind:<br />
*Treppenhausschaltern - mit einem Parameter kann man Einschaltdauer je Instanziierung festlegen. Sinnvoll könnte eine Treppenhausschaltung generell sein, nicht nur im Treppenhaus. Man kann generell alle Lichter nach ein paar Stunden ausschalten.<br />
*Heizungstemplate - Boosttime: Man kann allen RTs das gleiche Template geben - allerdings kann man z.B. die Boosttime indivituell einstellen. <br />
*MotionDetector Clients: Bei den Peers des Modtion detector (also den Schaltern) stellt man ein, dann diese reagieren sollen und wie lange diese brennen sollen. <br />
<br />
== Template Verwaltung==<br />
Templates werden zusammen mit Registern verwaltet. Man benötigt demnach HMinfo. Sowohl die Template definition alsauch die Template Zuweisung werden im File zusammen mit den gelesenen Registern gesichert. Nach einem Einlesen dieses Files werden auch die Templates und deren Zuordnung neu erstellt.<br />
<br />
== Template Editieren==<br />
Die aktuell einfachste Möglichkeit ein Template zu modifizieren ist, HMtemplate zu nutzen. HMtemplate ist ein Editor. Für den Betrieb wird es nicht genutzt. <br />
<br />
<br />
=Das eigenen Konzept=<br />
Für die Verknüpfung von HM Entities muss man 2 Ebenen unterschieden, Architektur und Verhalten.<br />
==Architektur==<br />
Beim Erstellen der Architektur legt man fest, welche Entities untereinander verknüpft werden. Dies geschieht durch peeren. Templates unterstützen nicht die Architektur. Es ist demnach notwendig die Peerings durchzuführen bevor an ein Template darauf anwenden kann. <br />
==Verhalten==<br />
Hier kommen die Templates zum Tragen. Mit Templates definiert man die Register der Entities und somit das Verhalten und die Reaktion der Entites bspw auf Trigger von Sensoren.<br />
===Welchen templateTyp brauche ich===<br />
Wie in Granularität beschrieben kann man insbesondere beim Peerverhalten templates für ''short'', ''long'' oder ''both'' ertellen. Nutzt man short/long braucht man weniger Templates (Basics sind on/off/ignore/toggle) muss allerdings mehr Templates zuweisen, als Reaktion auf short UND long.<br><br />
Bei both braucht man mehr Templates (OnOff/OnIgnore/OffIgnore/IgnoreOff/ToggleIgnore/...) braucht aber nur die Hälfte der Zuweisungen zu den realen Entities. <br />
<br />
===Welche Parameter muss ich einstellen===<br />
Bei der Erstellung eine Templates werden dessen Parameter durch Attribute vorgegeben. Durch '''set save''' wird dann das Template schlussendlich definiert. Folgende Parameter/Attribute werden genutzt:<br />
*'''tpl_description''': ist ein Freitext welcher beschreiben soll, was das Template macht und wie es parametriert wird<br />
*'''tpl_params''': hier werden evtl Parameter definiert mit welchen die Instanziierung des Templates angepasst werden kann. Bspw. könnte die Einschaltzeit variable gestalltet werden. Bei einem Dimmer könnt man den Level und die Rampe eingeben, also 2 Parameter. Man vergibt also, ":" getrennt, eine Liste von Paramtern. Die Namen sind frei wählbar. <br><br />
:''timeOn:ramp'' würde 2 Parameter definieren, welche später in den Registern genutzt werden können<br />
*'''tpl_type''': definiert den Typ. Diesen muss man zuerst festlegen. Es konnte ''peer-Short'',''peer-Long'',''peer-Both'' oder ''basic'' sein. Nach der Auswahl des Typs kann man die Entity (source) wählen. Es alle Entities angeboten, welche entsprechende Registersätze zu Verfügung stellen.<br />
*'''tpl_source''': legt bei der Definition eines Templates fest, von welcher Entity die Register für die Vorlage genutzt werden sollen. Ein Browser-Refresh könnte notwendig sein um die Auswahlliste upzudaten<br />
*'''tpl_peer''': muss man auswählen, so man einen "peer" typ gewählt hat. An Browser-refresh denken. <br />
*'''Reg_xxx''': An Browser-refresh denken. Hat man nun die Vorlage ausgewählt und den Refresh gemach werden nun Register als Attribute angeboten. <br><br />
:Zunächst sollte man Registerattribute löschen, welche man für das Template nicht benötigt. Achtung: eine Option gelöschte Registerattribute wieder nachzutragen ist nicht vorgesehen. So schlimm ist es allerdings nicht - man muss halt noch einmal alle Lesen und von Vorne löschen. <br><br />
:Sinnvoll kann es sein, die Condition Table Register komplett zu eliminieren wenn man Reaktionen auf Taster definieren will. Will man ''ignore'' definieren, also keine Reaktion bspw auf ''long'', dann kann man alles löschen bis auf ActionType usw. <br><br />
:Sinnvoll ist es, nur notwendige Register der Funktion zu bearbeiten, da sonst die Anwendung des Templates eingeschränkt wird. <br><br />
:Es sollten aber alle Register der Funktion enthalten sein, da die Prüfung auch nur diese berücksichtigt und bei einem Umprogrammieren nicht klar ist, was vorher in einem Register gestanden ist.<br />
===Register Werte setzen===<br />
Nun das eigentliche - das setzen der Registerinhalte. Dies wird begrenzt unterstützt. Sollte das Register durch ''literals'' definiert werden erscheint beim Setzen eine drop-down Liste mit den Optionen. <br><br />
Nicht unterstützt wird das Setzen von Werten. Es gibt aktuell keine Option, hier eine Hilfe einzublenden. Die Wertebereiche sind dem regList der Entity zu entnehmen. <br><br />
Eine weitere Besonderheit ist die Granularität der Werte. Insbesondere durch das Float Format einiger Werte sind nicht alle Werte möglich. Trägt man bspw eine Ontime von 10000 ein wird dies erst einmal akzeptiert. Allerdings wird der Wert beim Schreiben umgerechnet in den nächstmöglichen (welcher 9600 ist). Bei der Prüfung der Template Anwendung wird der Unterschied angemerkt. Am Einfachsten wird nun das Template angepasst und alles ist gut.<br><br />
<br><br />
Nun tpl_params. Diese muss man anstelle des Registerwerts einsetzen. Hat man bspw <br><br />
tpl_params timeOn:rampTime<br><br />
definiert setzt man in das Register ''OnTime'' den Wert ''timeOn'' ein. Und eben das Rampenregiste den Wert ''rampTime''. Der Wert wird dann beim Template Instanziieren - also Anwenden - durch den Individuellen ersetzt.<br />
<br />
=Getting started=<br />
Was muss man also tun? Wenn man noch nichts eingerichtet hat:<br />
define hm HMinfo<br />
attr hm autoArchive 1<br />
attr hm autoLoadArchive 1_load<br />
attr hm configFilename regConfig.cfg<br />
define ht HMtemplate<br />
<br />
==Template erstellen und bearbeiten==<br />
Templates kann man erstellen, in dem man die Register einer Entity nimmt und bearbeitet. Auch das Kopieren und Bearbeiten eines vorhandenen Templates ist möglich. Und man kann Templates exportieren/importieren.<br />
===Template aus Device===<br />
Aufgabe ist es, aus einem existierenden Device ein Template zu erstellen. Wir haben <br />
device ''myDev''<br />
Channel ''myChan''<br />
Channel gepeert mit ''myChanPeer''.<br><br />
Der Kanal ist ein Schalter und wir wollen einen Parameter im Template nutzen: Die Anschaltzeit soll bei der Nutzung des Templates variabel eingesetzt werden. Wir werden also den Parameter ''timeOn'' nutzen. Das Template soll ''my1stTmpl'' genannt werden. Weiter soll das gesamte Verhalten des ''myChanPeer'' definiert werden, also short UND long. <br />
set ht define my1stTmpl<br />
attr ht tpl_param timeOn # name des Parameters - hier nur einer<br />
attr ht tpl_description "mein erstes Template"<br />
attr ht tpl_type peer-both<br />
<refresh browser> # select liste der attribute wird neu eingelesen<br />
attr ht tpl_source myChan<br />
<refresh browser> # select liste der attribute wird neu eingelesen<br />
attr ht tpl_peer myChanPeer<br />
<refresh browser> # select liste der attribute wird neu eingelesen<br />
attr ht Reg_shOnTime timeOn # setzen des parameters<br />
<br />
nun können weitere Register verändert werde. <br />
Sinnvoll ist es, unnötige Register aus dem Template zu entfernen. Dies sind in diesem Fall bspw. alle Ct register. Das Attribut des Registers wird einfach gelöscht. <br />
set ht save<br />
set ht dismiss<br />
===Template Varianten speichern===<br />
Ist man beim Erstellen von Templates kann man mti saveAs das Template als neues unter einem anderen Namen sichern. <br />
===Template editieren===<br />
Mit Edit kann man die Werte der Register ändern oder vorhandene Register aus dem Template entfernen. Ein Hinzufügen von Registern wird nicht unterstützt. Hier fehlt die Referenz um anzubieten, was möglich ist.<br />
===Template kopieren===<br />
Dies wird ebenfalls mit edit erreicht. Das Template wird mit saveAs unter einem neuen Namen gespeichert.<br />
===Template export-import===<br />
Will man Templates exportieren nutzt man <br><br />
get ht <templatename><br />
Es wird ein kommando ausgegeben welches man in die Kommandozeile pasten kann, was dann der import ist.<br><br />
Dies kann man nutzen um Templates zu tauschen. Hat man ein ''gutes oder komplexes'' Template kann man dies der Allgemeinheit zu Verfügung stellen.<br><br />
Im besten Fall muss der User sich nicht mehr um Register kümmern, da komfortable Templates das besser abdecken.<br />
<br />
==Template einem Kanal zuweisen==<br />
Jetzt haben wir ein Template welches long [[und]] short eines Kanals kontrollieren soll. Dies wollen wir jetzt anwenden auf unsere Kanal/Peer Kompinationen "sw1/peer1", "sw1/peer2", "sw2/peer1" und "sw2/peer3". Für alle benötigen wir unterschiedliche Abschaltzeiten (warum? eure Sache). <br />
set ht select my1stTmpl<br />
attr ht entity sw1<br />
<refresh browser><br />
attr ht ePeer peer1<br />
attr ht tpl_param_timeOn 30<br />
set ht apply<br />
attr ht ePeer peer2<br />
attr ht tpl_param_timeOn 180<br />
set ht apply<br />
<br />
attr ht entity sw2<br />
<refresh browser><br />
attr ht ePeer peer1<br />
attr ht tpl_param_timeOn 70<br />
set ht apply<br />
<br />
attr ht ePeer peer3<br />
attr ht tpl_param_timeOn 1000<br />
set ht apply<br />
<br />
set ht dismiss<br />
Die Register der Entities werden passend in das Device geschrieben.<br />
<br />
==Template editieren==<br />
Nun soll das Template grundsätzlich modfiziert werden. <br />
<br />
set ht edit my1stTmpl<br />
attr ht Reg_<name> <value><br />
attr ht Reg_<name2> <value2><br />
attr ht Reg_<name3> <value3><br />
set ht save<br />
==Template kopieren und editieren==<br />
Nun soll das Template grundsätzlich modfiziert werden. <br />
<br />
set ht select my1stTmpl<br />
attr ht Reg_<name> <value><br />
attr ht Reg_<name2> <value2><br />
attr ht Reg_<name3> <value3><br />
set ht saveAs my2ndTmpl<br />
==Template weitergeben==<br />
Will man Templates weitergeben geht das mit<br />
get ht my1stTmpl<br />
Das Kommando kann dann direkt in die Kommandozeile kopiert werden und das Template ist definiert.<br />
=Verwaltung und Überblick=<br />
[[Kategorie:HomeMatic supportDevice]]<br />
[[Kategorie:HOWTOS]]</div>Martinp876http://wiki.fhem.de/w/index.php?title=HomeMatic_Templates&diff=23948HomeMatic Templates2017-12-30T14:08:10Z<p>Martinp876: </p>
<hr />
<div>{{Infobox Modul<br />
|ModPurpose=templates bedienen und verwalten<br />
|ModType=h<br />
|ModCmdRef=HMtemplate<br />
|ModForumArea=HomeMatic<br />
|ModTechName=98_HMtemplate.pm<br />
|ModOwner=martinp876 ({{Link2FU|251|martinp876}} / [[Benutzer Diskussion:Martinp876|Wiki]])<br />
}}<br />
Templates sind Vorlagen im Allgemeinen. Hier werden Vorlagen zur Programmierung der Register von HM Devices behandelt. <br />
= Warum Templates =<br />
Die Frage, warum man Register nicht einfach setzt sondern Templates nutzen sollte kommt immer wieder auf. Schliesslich sind wie alle Spezialisten...<br />
Die Wahrheit allerdings bildet das nicht ab. Den auch den Spezialisten sei angeraten, Templates zu nutzen. Ja, warum den, was bieten Templates? Hierzu muss man verstehen wir FHEM, HM, Devices, Kanäle und peers zusammen hängen. <br />
<br />
Wie schon im Einsteigerdoc beschrieben hat ein HM Device remanente Register welche von FHEM gesetzt werden können und die Funktions- und Arbeitsweise definieren. FHEM selbst hat bestenfalls eine Kopie dieser Daten.<br />
;soll-Register Verwaltung<br />
:Da FHEM nur eine Kopie der Registerwerte verwaltet lebt man erst einmal in einer fragilen Welt. Registerwerte können sich ändern durch:<br />
* Reset des Device<br />
* Batteriefehler<br />
* inkorrektes Schreiben und Übertragungsfehler<br />
* Austausch eines Device<br />
:Nach Lesen der Device Register hat FHEM einen neue Kopie - dies muss aber nicht den Wunschregistern entsprechen. Templates sind eine Ansammlung von Wunschregister. Somit können unterschiedliche Mechanismen genutzt werden, das System zu verwalten, prüfen und korrigieren.<br />
;Funktionen für Einsteiger<br />
:Nicht-Experten sollten primär Templates nutzen - um Funktionen zu realisieren, und wenn gewünscht, Experten zu werden. Templares kann man einfach austauschen und dann anwenden.<br />
;Verwalten von Funktionen statt Registern<br />
:Als Experten kann man sicher die Register zeilsicher setzen. Wirklich? Wenn man sich eine clevere Lösung ausgedacht hat und sie reproduzieren will kann man einfach noch einmal nachdenken, nachlesen,... und schon hat man es wieder. Oder man hat ein Template definiert das man einfach nutzt.<br />
; Lernen aus Templates<br />
:Templates sind nicht verschlüsselt. Hat oder bekommt man ein Template kann man die dort gesetzten Register einfach einsehen - und wenn man will verstehen was gemacht wurde. <br />
;Globales Anpassen aller Devices <br />
: Hat man festgestellt, dass eine Funktion sub-optimal ist kann man das Temlate ändern und diese Änderungen allen Devices zu gute kommen lassen. Auf einmal. <br />
<br />
= Grundsätzliches zum Template =<br />
Templates (hier) ist nun also eine Sammlung von Registern welche in einem Device gesetzt werden können. <br />
<br />
== Template Granularität ==<br />
Man kann nicht alle Register eines Device in einem Template abbilden. Das wäre technisch komplex und macht auch von der Anwendung her keinen Sinn. <br />
<br />
*Aus Sicht der Funktion sollte man Templates nach deren Funktionen zusammenfassen.<br />
*Aus Sicht des Devices sollte man Templates nach der Struktur des Device zusammenstellen.<br />
*Die Implementierung erlaubt es, templates für jedes Register einzeln zu erstellen.<br><br />
*Weniger Templates erhöhen die Übersichtlichkeit<br />
Die technische Lösung legt folgenden Templates nahe<br />
#Alle Register eines Kanals oder Device - ausgenommen peer abhängige Register<br />
#Alle Register eines Kanals eines Peers für short oder long<br />
#Alle Register eines Kanals eines Peers nur für short<br />
#Alle Register eines Kanals eines Peers nur für long<br />
Ob man 2. oder die Kombination aus 3. und 4. nutzt ist Geschmackssache. <br><br />
Ein typischer Einsatz sind Schaltern und Dimmer bei welchen man die Aktionen der Peers festlegen will.<br />
;usecase Template Granularität Dimmer<br />
:Mit Peer1 soll bei short ein und bei long ausgeschaltet werden<br />
:Mit Peer2 soll bei short getoggelt und bei long nicht geschaltet werden<br />
:Mit Peer3 soll bei short nicht geschaltet und bei long getoggelt werden<br />
:Mit Peer4 ist ein MotionDetector welcher bei short und einer bestimmten Helligkeit einschaltet, timed. Allerdings sollen Aktionen der anderen Peers oder der Zentrale das Licht dauer-ein schalten.<br />
<br />
== Template Flexibilität ==<br />
Templates sind starr... und können parametriert werden. Also semistarr. Was jetzt? Nun man kann Templates mir bis zu 9 Parametern versehen. Sinnvoll sind wohl eher bis zu 3. <br><br />
Beispiele sind:<br />
*Treppenhausschaltern - mit einem Parameter kann man Einschaltdauer je Instanziierung festlegen. Sinnvoll könnte eine Treppenhausschaltung generell sein, nicht nur im Treppenhaus. Man kann generell alle Lichter nach ein paar Stunden ausschalten.<br />
*Heizungstemplate - Boosttime: Man kann allen RTs das gleiche Template geben - allerdings kann man z.B. die Boosttime indivituell einstellen. <br />
*MotionDetector Clients: Bei den Peers des Modtion detector (also den Schaltern) stellt man ein, dann diese reagieren sollen und wie lange diese brennen sollen. <br />
<br />
== Template Verwaltung==<br />
Templates werden zusammen mit Registern verwaltet. Man benötigt demnach HMinfo. Sowohl die Template definition alsauch die Template Zuweisung werden im File zusammen mit den gelesenen Registern gesichert. Nach einem Einlesen dieses Files werden auch die Templates und deren Zuordnung neu erstellt.<br />
<br />
== Template Editieren==<br />
Die aktuell einfachste Möglichkeit ein Template zu modifizieren ist, HMtemplate zu nutzen. HMtemplate ist ein Editor. Für den Betrieb wird es nicht genutzt. <br />
<br />
<br />
=Das eigenen Konzept=<br />
Für die Verknüpfung von HM Entities muss man 2 Ebenen unterschieden, Architektur und Verhalten.<br />
==Architektur==<br />
Beim Erstellen der Architektur legt man fest, welche Entities untereinander verknüpft werden. Dies geschieht durch peeren. Templates unterstützen nicht die Architektur. Es ist demnach notwendig die Peerings durchzuführen bevor an ein Template darauf anwenden kann. <br />
==Verhalten==<br />
Hier kommen die Templates zum Tragen. Mit Templates definiert man die Register der Entities und somit das Verhalten und die Reaktion der Entites bspw auf Trigger von Sensoren.<br />
===Welchen templateTyp brauche ich===<br />
Wie in Granularität beschrieben kann man insbesondere beim Peerverhalten templates für ''short'', ''long'' oder ''both'' ertellen. Nutzt man short/long braucht man weniger Templates (Basics sind on/off/ignore/toggle) muss allerdings mehr Templates zuweisen, als Reaktion auf short UND long.<br><br />
Bei both braucht man mehr Templates (OnOff/OnIgnore/OffIgnore/IgnoreOff/ToggleIgnore/...) braucht aber nur die Hälfte der Zuweisungen zu den realen Entities. <br />
<br />
===Welche Parameter muss ich einstellen===<br />
Bei der Erstellung eine Templates werden dessen Parameter durch Attribute vorgegeben. Durch '''set save''' wird dann das Template schlussendlich definiert. Folgende Parameter/Attribute werden genutzt:<br />
*'''tpl_description''': ist ein Freitext welcher beschreiben soll, was das Template macht und wie es parametriert wird<br />
*'''tpl_params''': hier werden evtl Parameter definiert mit welchen die Instanziierung des Templates angepasst werden kann. Bspw. könnte die Einschaltzeit variable gestalltet werden. Bei einem Dimmer könnt man den Level und die Rampe eingeben, also 2 Parameter. Man vergibt also, ":" getrennt, eine Liste von Paramtern. Die Namen sind frei wählbar. <br><br />
:''timeOn:ramp'' würde 2 Parameter definieren, welche später in den Registern genutzt werden können<br />
*'''tpl_type''': definiert den Typ. Diesen muss man zuerst festlegen. Es konnte ''peer-Short'',''peer-Long'',''peer-Both'' oder ''basic'' sein. Nach der Auswahl des Typs kann man die Entity (source) wählen. Es alle Entities angeboten, welche entsprechende Registersätze zu Verfügung stellen.<br />
*'''tpl_source''': legt bei der Definition eines Templates fest, von welcher Entity die Register für die Vorlage genutzt werden sollen. Ein Browser-Refresh könnte notwendig sein um die Auswahlliste upzudaten<br />
*'''tpl_peer''': muss man auswählen, so man einen "peer" typ gewählt hat. An Browser-refresh denken. <br />
*'''Reg_xxx''': An Browser-refresh denken. Hat man nun die Vorlage ausgewählt und den Refresh gemach werden nun Register als Attribute angeboten. <br><br />
:Zunächst sollte man Registerattribute löschen, welche man für das Template nicht benötigt. Achtung: eine Option gelöschte Registerattribute wieder nachzutragen ist nicht vorgesehen. So schlimm ist es allerdings nicht - man muss halt noch einmal alle Lesen und von Vorne löschen. <br><br />
:Sinnvoll kann es sein, die Condition Table Register komplett zu eliminieren wenn man Reaktionen auf Taster definieren will. Will man ''ignore'' definieren, also keine Reaktion bspw auf ''long'', dann kann man alles löschen bis auf ActionType usw. <br><br />
:Sinnvoll ist es, nur notwendige Register der Funktion zu bearbeiten, da sonst die Anwendung des Templates eingeschränkt wird. <br><br />
:Es sollten aber alle Register der Funktion enthalten sein, da die Prüfung auch nur diese berücksichtigt und bei einem Umprogrammieren nicht klar ist, was vorher in einem Register gestanden ist.<br />
===Register Werte setzen===<br />
Nun das eigentliche - das setzen der Registerinhalte. Dies wird begrenzt unterstützt. Sollte das Register durch ''literals'' definiert werden erscheint beim Setzen eine drop-down Liste mit den Optionen. <br><br />
Nicht unterstützt wird das Setzen von Werten. Es gibt aktuell keine Option, hier eine Hilfe einzublenden. Die Wertebereiche sind dem regList der Entity zu entnehmen. <br><br />
Eine weitere Besonderheit ist die Granularität der Werte. Insbesondere durch das Float Format einiger Werte sind nicht alle Werte möglich. Trägt man bspw eine Ontime von 10000 ein wird dies erst einmal akzeptiert. Allerdings wird der Wert beim Schreiben umgerechnet in den nächstmöglichen (welcher 9600 ist). Bei der Prüfung der Template Anwendung wird der Unterschied angemerkt. Am Einfachsten wird nun das Template angepasst und alles ist gut.<br><br />
<br><br />
Nun tpl_params. Diese muss man anstelle des Registerwerts einsetzen. Hat man bspw <br><br />
tpl_params timeOn:rampTime<br><br />
definiert setzt man in das Register ''OnTime'' den Wert ''timeOn'' ein. Und eben das Rampenregiste den Wert ''rampTime''. Der Wert wird dann beim Template Instanziieren - also Anwenden - durch den Individuellen ersetzt.<br />
<br />
=Getting started=<br />
Was muss man also tun? Wenn man noch nichts eingerichtet hat:<br />
define hm HMinfo<br />
attr hm autoArchive 1<br />
attr hm autoLoadArchive 1_load<br />
attr hm configFilename regConfig.cfg<br />
define ht HMtemplate<br />
<br />
==Template erstellen und bearbeiten==<br />
Templates kann man erstellen, in dem man die Register einer Entity nimmt und bearbeitet. Auch das Kopieren und Bearbeiten eines vorhandenen Templates ist möglich. Und man kann Templates exportieren/importieren.<br />
===Template aus Device===<br />
Aufgabe ist es, aus einem existierenden Device ein Template zu erstellen. Wir haben <br />
device ''myDev''<br />
Channel ''myChan''<br />
Channel gepeert mit ''myChanPeer''.<br><br />
Der Kanal ist ein Schalter und wir wollen einen Parameter im Template nutzen: Die Anschaltzeit soll bei der Nutzung des Templates variabel eingesetzt werden. Wir werden also den Parameter ''timeOn'' nutzen. Das Template soll ''my1stTmpl'' genannt werden. Weiter soll das gesamte Verhalten des ''myChanPeer'' definiert werden, also short UND long. <br />
set ht define my1stTmpl<br />
attr ht tpl_param timeOn # name des Parameters - hier nur einer<br />
attr ht tpl_description "mein erstes Template"<br />
attr ht tpl_type peer-both<br />
<refresh browser> # select liste der attribute wird neu eingelesen<br />
attr ht tpl_source myChan<br />
<refresh browser> # select liste der attribute wird neu eingelesen<br />
attr ht tpl_peer myChanPeer<br />
<refresh browser> # select liste der attribute wird neu eingelesen<br />
attr ht Reg_shOnTime timeOn # setzen des parameters<br />
<br />
nun können weitere Register verändert werde. <br />
Sinnvoll ist es, unnötige Register aus dem Template zu entfernen. Dies sind in diesem Fall bspw. alle Ct register. Das Attribut des Registers wird einfach gelöscht. <br />
set ht save<br />
set ht dismiss<br />
===Template Varianten speichern===<br />
Ist man beim Erstellen von Templates kann man mti saveAs das Template als neues unter einem anderen Namen sichern. <br />
===Template editieren===<br />
Mit Edit kann man die Werte der Register ändern oder vorhandene Register aus dem Template entfernen. Ein Hinzufügen von Registern wird nicht unterstützt. Hier fehlt die Referenz um anzubieten, was möglich ist.<br />
===Template kopieren===<br />
Dies wird ebenfalls mit edit erreicht. Das Template wird mit saveAs unter einem neuen Namen gespeichert.<br />
===Template export-import===<br />
Will man Templates exportieren nutzt man <br><br />
get ht <templatename><br />
Es wird ein kommando ausgegeben welches man in die Kommandozeile pasten kann, was dann der import ist.<br><br />
Dies kann man nutzen um Templates zu tauschen. Hat man ein ''gutes oder komplexes'' Template kann man dies der Allgemeinheit zu Verfügung stellen.<br><br />
Im besten Fall muss der User sich nicht mehr um Register kümmern, da komfortable Templates das besser abdecken.<br />
<br />
==Template einem Kanal zuweisen==<br />
Jetzt haben wir ein Template welches long [[und]] short eines Kanals kontrollieren soll. Dies wollen wir jetzt anwenden auf unsere Kanal/Peer Kompinationen "sw1/peer1", "sw1/peer2", "sw2/peer1" und "sw2/peer3". Für alle benötigen wir unterschiedliche Abschaltzeiten (warum? eure Sache). <br />
set ht select my1stTmpl<br />
attr ht entity sw1<br />
<refresh browser><br />
attr ht ePeer peer1<br />
attr ht tpl_param_timeOn 30<br />
set ht apply<br />
attr ht ePeer peer2<br />
attr ht tpl_param_timeOn 180<br />
set ht apply<br />
<br />
attr ht entity sw2<br />
<refresh browser><br />
attr ht ePeer peer1<br />
attr ht tpl_param_timeOn 70<br />
set ht apply<br />
<br />
attr ht ePeer peer3<br />
attr ht tpl_param_timeOn 1000<br />
set ht apply<br />
<br />
set ht dismiss<br />
Die Register der Entities werden passend in das Device geschrieben.<br />
<br />
==Template editieren==<br />
Nun soll das Template grundsätzlich modfiziert werden. <br />
<br />
set ht edit my1stTmpl<br />
attr ht Reg_<name> <value><br />
attr ht Reg_<name2> <value2><br />
attr ht Reg_<name3> <value3><br />
set ht save<br />
==Template kopieren und editieren==<br />
Nun soll das Template grundsätzlich modfiziert werden. <br />
<br />
set ht select my1stTmpl<br />
attr ht Reg_<name> <value><br />
attr ht Reg_<name2> <value2><br />
attr ht Reg_<name3> <value3><br />
set ht saveAs my2ndTmpl<br />
==Template weitergeben==<br />
Will man Templates weitergeben geht das mit<br />
get ht my1stTmpl<br />
Das Kommando kann dann direkt in die Kommandozeile kopiert werden und das Template ist definiert.<br />
[[Kategorie:HomeMatic supportDevice]]<br />
[[Kategorie:HOWTOS]]</div>Martinp876http://wiki.fhem.de/w/index.php?title=HomeMatic_Templates&diff=23947HomeMatic Templates2017-12-30T14:06:18Z<p>Martinp876: </p>
<hr />
<div>{{Infobox Modul<br />
|ModPurpose=templates bedienen und verwalten<br />
|ModType=h<br />
|ModCmdRef=HMtemplate<br />
|ModForumArea=HomeMatic<br />
|ModTechName=98_HMtemplate.pm<br />
|ModOwner=martinp876 ({{Link2FU|251|martinp876}} / [[Benutzer Diskussion:Martinp876|Wiki]])<br />
}}<br />
Templates sind Vorlagen im Allgemeinen. Hier werden Vorlagen zur Programmierung der Register von HM Devices behandelt. <br />
= Warum Templates =<br />
Die Frage, warum man Register nicht einfach setzt sondern Templates nutzen sollte kommt immer wieder auf. Schliesslich sind wie alle Spezialisten...<br />
Die Wahrheit allerdings bildet das nicht ab. Den auch den Spezialisten sei angeraten, Templates zu nutzen. Ja, warum den, was bieten Templates? Hierzu muss man verstehen wir FHEM, HM, Devices, Kanäle und peers zusammen hängen. <br />
<br />
Wie schon im Einsteigerdoc beschrieben hat ein HM Device remanente Register welche von FHEM gesetzt werden können und die Funktions- und Arbeitsweise definieren. FHEM selbst hat bestenfalls eine Kopie dieser Daten.<br />
;soll-Register Verwaltung<br />
:Da FHEM nur eine Kopie der Registerwerte verwaltet lebt man erst einmal in einer fragilen Welt. Registerwerte können sich ändern durch:<br />
* Reset des Device<br />
* Batteriefehler<br />
* inkorrektes Schreiben und Übertragungsfehler<br />
* Austausch eines Device<br />
:Nach Lesen der Device Register hat FHEM einen neue Kopie - dies muss aber nicht den Wunschregistern entsprechen. Templates sind eine Ansammlung von Wunschregister. Somit können unterschiedliche Mechanismen genutzt werden, das System zu verwalten, prüfen und korrigieren.<br />
;Funktionen für Einsteiger<br />
:Nicht-Experten sollten primär Templates nutzen - um Funktionen zu realisieren, und wenn gewünscht, Experten zu werden. Templares kann man einfach austauschen und dann anwenden.<br />
;Verwalten von Funktionen statt Registern<br />
:Als Experten kann man sicher die Register zeilsicher setzen. Wirklich? Wenn man sich eine clevere Lösung ausgedacht hat und sie reproduzieren will kann man einfach noch einmal nachdenken, nachlesen,... und schon hat man es wieder. Oder man hat ein Template definiert das man einfach nutzt.<br />
; Lernen aus Templates<br />
:Templates sind nicht verschlüsselt. Hat oder bekommt man ein Template kann man die dort gesetzten Register einfach einsehen - und wenn man will verstehen was gemacht wurde. <br />
;Globales Anpassen aller Devices <br />
: Hat man festgestellt, dass eine Funktion sub-optimal ist kann man das Temlate ändern und diese Änderungen allen Devices zu gute kommen lassen. Auf einmal. <br />
<br />
= Grundsätzliches zum Template =<br />
Templates (hier) ist nun also eine Sammlung von Registern welche in einem Device gesetzt werden können. <br />
<br />
== Template Granularität ==<br />
Man kann nicht alle Register eines Device in einem Template abbilden. Das wäre technisch komplex und macht auch von der Anwendung her keinen Sinn. <br />
<br />
*Aus Sicht der Funktion sollte man Templates nach deren Funktionen zusammenfassen.<br />
*Aus Sicht des Devices sollte man Templates nach der Struktur des Device zusammenstellen.<br />
*Die Implementierung erlaubt es, templates für jedes Register einzeln zu erstellen.<br><br />
*Weniger Templates erhöhen die Übersichtlichkeit<br />
Die technische Lösung legt folgenden Templates nahe<br />
#Alle Register eines Kanals oder Device - ausgenommen peer abhängige Register<br />
#Alle Register eines Kanals eines Peers für short oder long<br />
#Alle Register eines Kanals eines Peers nur für short<br />
#Alle Register eines Kanals eines Peers nur für long<br />
Ob man 2. oder die Kombination aus 3. und 4. nutzt ist Geschmackssache. <br><br />
Ein typischer Einsatz sind Schaltern und Dimmer bei welchen man die Aktionen der Peers festlegen will.<br />
;usecase Template Granularität Dimmer<br />
:Mit Peer1 soll bei short ein und bei long ausgeschaltet werden<br />
:Mit Peer2 soll bei short getoggelt und bei long nicht geschaltet werden<br />
:Mit Peer3 soll bei short nicht geschaltet und bei long getoggelt werden<br />
:Mit Peer4 ist ein MotionDetector welcher bei short und einer bestimmten Helligkeit einschaltet, timed. Allerdings sollen Aktionen der anderen Peers oder der Zentrale das Licht dauer-ein schalten.<br />
<br />
== Template Flexibilität ==<br />
Templates sind starr... und können parametriert werden. Also semistarr. Was jetzt? Nun man kann Templates mir bis zu 9 Parametern versehen. Sinnvoll sind wohl eher bis zu 3. <br><br />
Beispiele sind:<br />
*Treppenhausschaltern - mit einem Parameter kann man Einschaltdauer je Instanziierung festlegen. Sinnvoll könnte eine Treppenhausschaltung generell sein, nicht nur im Treppenhaus. Man kann generell alle Lichter nach ein paar Stunden ausschalten.<br />
*Heizungstemplate - Boosttime: Man kann allen RTs das gleiche Template geben - allerdings kann man z.B. die Boosttime indivituell einstellen. <br />
*MotionDetector Clients: Bei den Peers des Modtion detector (also den Schaltern) stellt man ein, dann diese reagieren sollen und wie lange diese brennen sollen. <br />
<br />
== Template Verwaltung==<br />
Templates werden zusammen mit Registern verwaltet. Man benötigt demnach HMinfo. Sowohl die Template definition alsauch die Template Zuweisung werden im File zusammen mit den gelesenen Registern gesichert. Nach einem Einlesen dieses Files werden auch die Templates und deren Zuordnung neu erstellt.<br />
<br />
== Template Editieren==<br />
Die aktuell einfachste Möglichkeit ein Template zu modifizieren ist, HMtemplate zu nutzen. HMtemplate ist ein Editor. Für den Betrieb wird es nicht genutzt. <br />
<br />
<br />
=Das eigenen Konzept=<br />
Für die Verknüpfung von HM Entities muss man 2 Ebenen unterschieden, Architektur und Verhalten.<br />
==Architektur==<br />
Beim Erstellen der Architektur legt man fest, welche Entities untereinander verknüpft werden. Dies geschieht durch peeren. Templates unterstützen nicht die Architektur. Es ist demnach notwendig die Peerings durchzuführen bevor an ein Template darauf anwenden kann. <br />
==Verhalten==<br />
Hier kommen die Templates zum Tragen. Mit Templates definiert man die Register der Entities und somit das Verhalten und die Reaktion der Entites bspw auf Trigger von Sensoren.<br />
===Welchen templateTyp brauche ich===<br />
Wie in Granularität beschrieben kann man insbesondere beim Peerverhalten templates für ''short'', ''long'' oder ''both'' ertellen. Nutzt man short/long braucht man weniger Templates (Basics sind on/off/ignore/toggle) muss allerdings mehr Templates zuweisen, als Reaktion auf short UND long.<br><br />
Bei both braucht man mehr Templates (OnOff/OnIgnore/OffIgnore/IgnoreOff/ToggleIgnore/...) braucht aber nur die Hälfte der Zuweisungen zu den realen Entities. <br />
<br />
===Welche Parameter muss ich einstellen===<br />
Bei der Erstellung eine Templates werden dessen Parameter durch Attribute vorgegeben. Durch '''set save''' wird dann das Template schlussendlich definiert. Folgende Parameter/Attribute werden genutzt:<br />
*'''tpl_description''': ist ein Freitext welcher beschreiben soll, was das Template macht und wie es parametriert wird<br />
*'''tpl_params''': hier werden evtl Parameter definiert mit welchen die Instanziierung des Templates angepasst werden kann. Bspw. könnte die Einschaltzeit variable gestalltet werden. Bei einem Dimmer könnt man den Level und die Rampe eingeben, also 2 Parameter. Man vergibt also, ":" getrennt, eine Liste von Paramtern. Die Namen sind frei wählbar. <br><br />
:''timeOn:ramp'' würde 2 Parameter definieren, welche später in den Registern genutzt werden können<br />
*'''tpl_type''': definiert den Typ. Diesen muss man zuerst festlegen. Es konnte ''peer-Short'',''peer-Long'',''peer-Both'' oder ''basic'' sein. Nach der Auswahl des Typs kann man die Entity (source) wählen. Es alle Entities angeboten, welche entsprechende Registersätze zu Verfügung stellen.<br />
*'''tpl_source''': legt bei der Definition eines Templates fest, von welcher Entity die Register für die Vorlage genutzt werden sollen. Ein Browser-Refresh könnte notwendig sein um die Auswahlliste upzudaten<br />
*'''tpl_peer''': muss man auswählen, so man einen "peer" typ gewählt hat. An Browser-refresh denken. <br />
*'''Reg_xxx''': An Browser-refresh denken. Hat man nun die Vorlage ausgewählt und den Refresh gemach werden nun Register als Attribute angeboten. <br><br />
:Zunächst sollte man Registerattribute löschen, welche man für das Template nicht benötigt. Achtung: eine Option gelöschte Registerattribute wieder nachzutragen ist nicht vorgesehen. So schlimm ist es allerdings nicht - man muss halt noch einmal alle Lesen und von Vorne löschen. <br><br />
:Sinnvoll kann es sein, die Condition Table Register komplett zu eliminieren wenn man Reaktionen auf Taster definieren will. Will man ''ignore'' definieren, also keine Reaktion bspw auf ''long'', dann kann man alles löschen bis auf ActionType usw. <br><br />
:Sinnvoll ist es, nur notwendige Register der Funktion zu bearbeiten, da sonst die Anwendung des Templates eingeschränkt wird. <br><br />
:Es sollten aber alle Register der Funktion enthalten sein, da die Prüfung auch nur diese berücksichtigt und bei einem Umprogrammieren nicht klar ist, was vorher in einem Register gestanden ist.<br />
===Register Werte setzen===<br />
Nun das eigentliche - das setzen der Registerinhalte. Dies wird begrenzt unterstützt. Sollte das Register durch ''literals'' definiert werden erscheint beim Setzen eine drop-down Liste mit den Optionen. <br><br />
Nicht unterstützt wird das Setzen von Werten. Es gibt aktuell keine Option, hier eine Hilfe einzublenden. Die Wertebereiche sind dem regList der Entity zu entnehmen. <br><br />
Eine weitere Besonderheit ist die Granularität der Werte. Insbesondere durch das Float Format einiger Werte sind nicht alle Werte möglich. Trägt man bspw eine Ontime von 10000 ein wird dies erst einmal akzeptiert. Allerdings wird der Wert beim Schreiben umgerechnet in den nächstmöglichen (welcher 9600 ist). Bei der Prüfung der Template Anwendung wird der Unterschied angemerkt. Am Einfachsten wird nun das Template angepasst und alles ist gut.<br><br />
<br><br />
Nun tpl_params. Diese muss man anstelle des Registerwerts einsetzen. Hat man bspw <br><br />
tpl_params timeOn:rampTime<br><br />
definiert setzt man in das Register ''OnTime'' den Wert ''timeOn'' ein. Und eben das Rampenregiste den Wert ''rampTime''. Der Wert wird dann beim Template Instanziieren - also Anwenden - durch den Individuellen ersetzt.<br />
<br />
=Getting started=<br />
Was muss man also tun? Wenn man noch nichts eingerichtet hat:<br />
define hm HMinfo<br />
attr hm autoArchive 1<br />
attr hm autoLoadArchive 1_load<br />
attr hm configFilename regConfig.cfg<br />
define ht HMtemplate<br />
<br />
==Template erstellen und bearbeiten==<br />
Templates kann man erstellen, in dem man die Register einer Entity nimmt und bearbeitet. Auch das Kopieren und Bearbeiten eines vorhandenen Templates ist möglich. Und man kann Templates exportieren/importieren.<br />
===Template aus Device===<br />
Aufgabe ist es, aus einem existierenden Device ein Template zu erstellen. Wir haben <br />
device ''myDev''<br />
Channel ''myChan''<br />
Channel gepeert mit ''myChanPeer''.<br><br />
Der Kanal ist ein Schalter und wir wollen einen Parameter im Template nutzen: Die Anschaltzeit soll bei der Nutzung des Templates variabel eingesetzt werden. Wir werden also den Parameter ''timeOn'' nutzen. Das Template soll ''my1stTmpl'' genannt werden. Weiter soll das gesamte Verhalten des ''myChanPeer'' definiert werden, also short UND long. <br />
set ht define my1stTmpl<br />
attr ht tpl_param timeOn # name des Parameters - hier nur einer<br />
attr ht tpl_description "mein erstes Template"<br />
attr ht tpl_type peer-both<br />
<refresh browser> # select liste der attribute wird neu eingelesen<br />
attr ht tpl_source myChan<br />
<refresh browser> # select liste der attribute wird neu eingelesen<br />
attr ht tpl_peer myChanPeer<br />
<refresh browser> # select liste der attribute wird neu eingelesen<br />
attr ht Reg_shOnTime timeOn # setzen des parameters<br />
<br />
nun können weitere Register verändert werde. <br />
Sinnvoll ist es, unnötige Register aus dem Template zu entfernen. Dies sind in diesem Fall bspw. alle Ct register. Das Attribut des Registers wird einfach gelöscht. <br />
set ht save<br />
set ht dismiss<br />
===Template Varianten speichern===<br />
Ist man beim Erstellen von Templates kann man mti saveAs das Template als neues unter einem anderen Namen sichern. <br />
===Template editieren===<br />
Mit Edit kann man die Werte der Register ändern oder vorhandene Register aus dem Template entfernen. Ein Hinzufügen von Registern wird nicht unterstützt. Hier fehlt die Referenz um anzubieten, was möglich ist.<br />
===Template kopieren===<br />
Dies wird ebenfalls mit edit erreicht. Das Template wird mit saveAs unter einem neuen Namen gespeichert.<br />
===Template export-import===<br />
Will man Templates exportieren nutzt man <br><br />
get ht <templatename><br />
Es wird ein kommando ausgegeben welches man in die Kommandozeile pasten kann, was dann der import ist.<br><br />
Dies kann man nutzen um Templates zu tauschen. Hat man ein ''gutes oder komplexes'' Template kann man dies der Allgemeinheit zu Verfügung stellen.<br><br />
Im besten Fall muss der User sich nicht mehr um Register kümmern, da komfortable Templates das besser abdecken.<br />
<br />
==Template einem Kanal zuweisen==<br />
Jetzt haben wir ein Template welches long und short eines Kanals kontrollieren soll. Dies wollen wir jetzt anwenden auf unsere Kanal/Peer Kompinationen "sw1/peer1", "sw1/peer2", "sw2/peer1" und "sw2/peer3". Für alle benötigen wir unterschiedliche Abschaltzeiten (warum? eure Sache). <br />
set ht select my1stTmpl<br />
attr ht entity sw1<br />
<refresh browser><br />
attr ht ePeer peer1<br />
attr ht tpl_param_timeOn 30<br />
set ht apply<br />
attr ht ePeer peer2<br />
attr ht tpl_param_timeOn 180<br />
set ht apply<br />
<br />
attr ht entity sw2<br />
<refresh browser><br />
attr ht ePeer peer1<br />
attr ht tpl_param_timeOn 70<br />
set ht apply<br />
<br />
attr ht ePeer peer3<br />
attr ht tpl_param_timeOn 1000<br />
set ht apply<br />
<br />
set ht dismiss<br />
Die Register der Entities werden passend in das Device geschrieben. <br />
==Template editieren==<br />
Nun soll das Template grundsätzlich modfiziert werden. <br />
<br />
set ht edit my1stTmpl<br />
attr ht Reg_<name> <value><br />
attr ht Reg_<name2> <value2><br />
attr ht Reg_<name3> <value3><br />
set ht save<br />
==Template kopieren und editieren==<br />
Nun soll das Template grundsätzlich modfiziert werden. <br />
<br />
set ht select my1stTmpl<br />
attr ht Reg_<name> <value><br />
attr ht Reg_<name2> <value2><br />
attr ht Reg_<name3> <value3><br />
set ht saveAs my2ndTmpl<br />
==Template weitergeben==<br />
Will man Templates weitergeben geht das mit<br />
get ht my1stTmpl<br />
Das Kommando kann dann direkt in die Kommandozeile kopiert werden und das Template ist definiert.<br />
[[Kategorie:HomeMatic supportDevice]]<br />
[[Kategorie:HOWTOS]]</div>Martinp876http://wiki.fhem.de/w/index.php?title=HomeMatic_Templates&diff=23946HomeMatic Templates2017-12-30T14:05:15Z<p>Martinp876: </p>
<hr />
<div>{{Infobox Modul<br />
|ModPurpose=templates bedienen und verwalten<br />
|ModType=h<br />
|ModCmdRef=HMtemplate<br />
|ModForumArea=HomeMatic<br />
|ModTechName=98_HMtemplate.pm<br />
|ModOwner=martinp876 ({{Link2FU|251|martinp876}} / [[Benutzer Diskussion:Martinp876|Wiki]])<br />
}}<br />
Templates sind Vorlagen im Allgemeinen. Hier werden Vorlagen zur Programmierung der Register von HM Devices behandelt. <br />
= Warum Templates =<br />
Die Frage, warum man Register nicht einfach setzt sondern Templates nutzen sollte kommt immer wieder auf. Schliesslich sind wie alle Spezialisten...<br />
Die Wahrheit allerdings bildet das nicht ab. Den auch den Spezialisten sei angeraten, Templates zu nutzen. Ja, warum den, was bieten Templates? Hierzu muss man verstehen wir FHEM, HM, Devices, Kanäle und peers zusammen hängen. <br />
<br />
Wie schon im Einsteigerdoc beschrieben hat ein HM Device remanente Register welche von FHEM gesetzt werden können und die Funktions- und Arbeitsweise definieren. FHEM selbst hat bestenfalls eine Kopie dieser Daten.<br />
;soll-Register Verwaltung<br />
:Da FHEM nur eine Kopie der Registerwerte verwaltet lebt man erst einmal in einer fragilen Welt. Registerwerte können sich ändern durch:<br />
* Reset des Device<br />
* Batteriefehler<br />
* inkorrektes Schreiben und Übertragungsfehler<br />
* Austausch eines Device<br />
:Nach Lesen der Device Register hat FHEM einen neue Kopie - dies muss aber nicht den Wunschregistern entsprechen. Templates sind eine Ansammlung von Wunschregister. Somit können unterschiedliche Mechanismen genutzt werden, das System zu verwalten, prüfen und korrigieren.<br />
;Funktionen für Einsteiger<br />
:Nicht-Experten sollten primär Templates nutzen - um Funktionen zu realisieren, und wenn gewünscht, Experten zu werden. Templares kann man einfach austauschen und dann anwenden.<br />
;Verwalten von Funktionen statt Registern<br />
:Als Experten kann man sicher die Register zeilsicher setzen. Wirklich? Wenn man sich eine clevere Lösung ausgedacht hat und sie reproduzieren will kann man einfach noch einmal nachdenken, nachlesen,... und schon hat man es wieder. Oder man hat ein Template definiert das man einfach nutzt.<br />
; Lernen aus Templates<br />
:Templates sind nicht verschlüsselt. Hat oder bekommt man ein Template kann man die dort gesetzten Register einfach einsehen - und wenn man will verstehen was gemacht wurde. <br />
;Globales Anpassen aller Devices <br />
: Hat man festgestellt, dass eine Funktion sub-optimal ist kann man das Temlate ändern und diese Änderungen allen Devices zu gute kommen lassen. Auf einmal. <br />
<br />
= Grundsätzliches zum Template =<br />
Templates (hier) ist nun also eine Sammlung von Registern welche in einem Device gesetzt werden können. <br />
<br />
== Template Granularität ==<br />
Man kann nicht alle Register eines Device in einem Template abbilden. Das wäre technisch komplex und macht auch von der Anwendung her keinen Sinn. <br />
<br />
*Aus Sicht der Funktion sollte man Templates nach deren Funktionen zusammenfassen.<br />
*Aus Sicht des Devices sollte man Templates nach der Struktur des Device zusammenstellen.<br />
*Die Implementierung erlaubt es, templates für jedes Register einzeln zu erstellen.<br><br />
*Weniger Templates erhöhen die Übersichtlichkeit<br />
Die technische Lösung legt folgenden Templates nahe<br />
#Alle Register eines Kanals oder Device - ausgenommen peer abhängige Register<br />
#Alle Register eines Kanals eines Peers für short oder long<br />
#Alle Register eines Kanals eines Peers nur für short<br />
#Alle Register eines Kanals eines Peers nur für long<br />
Ob man 2. oder die Kombination aus 3. und 4. nutzt ist Geschmackssache. <br><br />
Ein typischer Einsatz sind Schaltern und Dimmer bei welchen man die Aktionen der Peers festlegen will.<br />
;usecase Template Granularität Dimmer<br />
:Mit Peer1 soll bei short ein und bei long ausgeschaltet werden<br />
:Mit Peer2 soll bei short getoggelt und bei long nicht geschaltet werden<br />
:Mit Peer3 soll bei short nicht geschaltet und bei long getoggelt werden<br />
:Mit Peer4 ist ein MotionDetector welcher bei short und einer bestimmten Helligkeit einschaltet, timed. Allerdings sollen Aktionen der anderen Peers oder der Zentrale das Licht dauer-ein schalten.<br />
<br />
== Template Flexibilität ==<br />
Templates sind starr... und können parametriert werden. Also semistarr. Was jetzt? Nun man kann Templates mir bis zu 9 Parametern versehen. Sinnvoll sind wohl eher bis zu 3. <br><br />
Beispiele sind:<br />
*Treppenhausschaltern - mit einem Parameter kann man Einschaltdauer je Instanziierung festlegen. Sinnvoll könnte eine Treppenhausschaltung generell sein, nicht nur im Treppenhaus. Man kann generell alle Lichter nach ein paar Stunden ausschalten.<br />
*Heizungstemplate - Boosttime: Man kann allen RTs das gleiche Template geben - allerdings kann man z.B. die Boosttime indivituell einstellen. <br />
*MotionDetector Clients: Bei den Peers des Modtion detector (also den Schaltern) stellt man ein, dann diese reagieren sollen und wie lange diese brennen sollen. <br />
<br />
== Template Verwaltung==<br />
Templates werden zusammen mit Registern verwaltet. Man benötigt demnach HMinfo. Sowohl die Template definition alsauch die Template Zuweisung werden im File zusammen mit den gelesenen Registern gesichert. Nach einem Einlesen dieses Files werden auch die Templates und deren Zuordnung neu erstellt.<br />
<br />
== Template Editieren==<br />
Die aktuell einfachste Möglichkeit ein Template zu modifizieren ist, HMtemplate zu nutzen. HMtemplate ist ein Editor. Für den Betrieb wird es nicht genutzt. <br />
<br />
<br />
=Das eigenen Konzept=<br />
Für die Verknüpfung von HM Entities muss man 2 Ebenen unterschieden, Architektur und Verhalten.<br />
==Architektur==<br />
Beim Erstellen der Architektur legt man fest, welche Entities untereinander verknüpft werden. Dies geschieht durch peeren. Templates unterstützen nicht die Architektur. Es ist demnach notwendig die Peerings durchzuführen bevor an ein Template darauf anwenden kann. <br />
==Verhalten==<br />
Hier kommen die Templates zum Tragen. Mit Templates definiert man die Register der Entities und somit das Verhalten und die Reaktion der Entites bspw auf Trigger von Sensoren.<br />
===Welchen templateTyp brauche ich===<br />
Wie in Granularität beschrieben kann man insbesondere beim Peerverhalten templates für ''short'', ''long'' oder ''both'' ertellen. Nutzt man short/long braucht man weniger Templates (Basics sind on/off/ignore/toggle) muss allerdings mehr Templates zuweisen, als Reaktion auf short UND long.<br><br />
Bei both braucht man mehr Templates (OnOff/OnIgnore/OffIgnore/IgnoreOff/ToggleIgnore/...) braucht aber nur die Hälfte der Zuweisungen zu den realen Entities. <br />
<br />
===Welche Parameter muss ich einstellen===<br />
Bei der Erstellung eine Templates werden dessen Parameter durch Attribute vorgegeben. Durch '''set save''' wird dann das Template schlussendlich definiert. Folgende Parameter/Attribute werden genutzt:<br />
*'''tpl_description''': ist ein Freitext welcher beschreiben soll, was das Template macht und wie es parametriert wird<br />
*'''tpl_params''': hier werden evtl Parameter definiert mit welchen die Instanziierung des Templates angepasst werden kann. Bspw. könnte die Einschaltzeit variable gestalltet werden. Bei einem Dimmer könnt man den Level und die Rampe eingeben, also 2 Parameter. Man vergibt also, ":" getrennt, eine Liste von Paramtern. Die Namen sind frei wählbar. <br><br />
:''timeOn:ramp'' würde 2 Parameter definieren, welche später in den Registern genutzt werden können<br />
*'''tpl_type''': definiert den Typ. Diesen muss man zuerst festlegen. Es konnte ''peer-Short'',''peer-Long'',''peer-Both'' oder ''basic'' sein. Nach der Auswahl des Typs kann man die Entity (source) wählen. Es alle Entities angeboten, welche entsprechende Registersätze zu Verfügung stellen.<br />
*'''tpl_source''': legt bei der Definition eines Templates fest, von welcher Entity die Register für die Vorlage genutzt werden sollen. Ein Browser-Refresh könnte notwendig sein um die Auswahlliste upzudaten<br />
*'''tpl_peer''': muss man auswählen, so man einen "peer" typ gewählt hat. An Browser-refresh denken. <br />
*'''Reg_xxx''': An Browser-refresh denken. Hat man nun die Vorlage ausgewählt und den Refresh gemach werden nun Register als Attribute angeboten. <br><br />
:Zunächst sollte man Registerattribute löschen, welche man für das Template nicht benötigt. Achtung: eine Option gelöschte Registerattribute wieder nachzutragen ist nicht vorgesehen. So schlimm ist es allerdings nicht - man muss halt noch einmal alle Lesen und von Vorne löschen. <br><br />
:Sinnvoll kann es sein, die Condition Table Register komplett zu eliminieren wenn man Reaktionen auf Taster definieren will. Will man ''ignore'' definieren, also keine Reaktion bspw auf ''long'', dann kann man alles löschen bis auf ActionType usw. <br><br />
:Sinnvoll ist es, nur notwendige Register der Funktion zu bearbeiten, da sonst die Anwendung des Templates eingeschränkt wird. <br><br />
:Es sollten aber alle Register der Funktion enthalten sein, da die Prüfung auch nur diese berücksichtigt und bei einem Umprogrammieren nicht klar ist, was vorher in einem Register gestanden ist.<br />
===Register Werte setzen===<br />
Nun das eigentliche - das setzen der Registerinhalte. Dies wird begrenzt unterstützt. Sollte das Register durch ''literals'' definiert werden erscheint beim Setzen eine drop-down Liste mit den Optionen. <br><br />
Nicht unterstützt wird das Setzen von Werten. Es gibt aktuell keine Option, hier eine Hilfe einzublenden. Die Wertebereiche sind dem regList der Entity zu entnehmen. <br><br />
Eine weitere Besonderheit ist die Granularität der Werte. Insbesondere durch das Float Format einiger Werte sind nicht alle Werte möglich. Trägt man bspw eine Ontime von 10000 ein wird dies erst einmal akzeptiert. Allerdings wird der Wert beim Schreiben umgerechnet in den nächstmöglichen (welcher 9600 ist). Bei der Prüfung der Template Anwendung wird der Unterschied angemerkt. Am Einfachsten wird nun das Template angepasst und alles ist gut.<br><br />
<br><br />
Nun tpl_params. Diese muss man anstelle des Registerwerts einsetzen. Hat man bspw <br><br />
tpl_params timeOn:rampTime<br><br />
definiert setzt man in das Register ''OnTime'' den Wert ''timeOn'' ein. Und eben das Rampenregiste den Wert ''rampTime''. Der Wert wird dann beim Template Instanziieren - also Anwenden - durch den Individuellen ersetzt.<br />
<br />
=Getting started=<br />
Was muss man also tun? Wenn man noch nichts eingerichtet hat:<br />
define hm HMinfo<br />
attr hm autoArchive 1<br />
attr hm autoLoadArchive 1_load<br />
attr hm configFilename regConfig.cfg<br />
define ht HMtemplate<br />
<br />
==Template erstellen und bearbeiten==<br />
Templates kann man erstellen, in dem man die Register einer Entity nimmt und bearbeitet. Auch das Kopieren und Bearbeiten eines vorhandenen Templates ist möglich. Und man kann Templates exportieren/importieren.<br />
===Template aus Device===<br />
Aufgabe ist es, aus einem existierenden Device ein Template zu erstellen. Wir haben <br />
device ''myDev''<br />
Channel ''myChan''<br />
Channel gepeert mit ''myChanPeer''.<br><br />
Der Kanal ist ein Schalter und wir wollen einen Parameter im Template nutzen: Die Anschaltzeit soll bei der Nutzung des Templates variabel eingesetzt werden. Wir werden also den Parameter ''timeOn'' nutzen. Das Template soll ''my1stTmpl'' genannt werden. Weiter soll das gesamte Verhalten des ''myChanPeer'' definiert werden, also short UND long. <br />
set ht define my1stTmpl<br />
attr ht tpl_param timeOn # name des Parameters - hier nur einer<br />
attr ht tpl_description "mein erstes Template"<br />
attr ht tpl_type peer-both<br />
<refresh browser> # select liste der attribute wird neu eingelesen<br />
attr ht tpl_source myChan<br />
<refresh browser> # select liste der attribute wird neu eingelesen<br />
attr ht tpl_peer myChanPeer<br />
<refresh browser> # select liste der attribute wird neu eingelesen<br />
attr ht Reg_shOnTime timeOn # setzen des parameters<br />
<br />
nun können weitere Register verändert werde. <br />
Sinnvoll ist es, unnötige Register aus dem Template zu entfernen. Dies sind in diesem Fall bspw. alle Ct register. Das Attribut des Registers wird einfach gelöscht. <br />
set ht save<br />
set ht dismiss<br />
===Template Varianten speichern===<br />
Ist man beim Erstellen von Templates kann man mti saveAs das Template als neues unter einem anderen Namen sichern. <br />
===Template editieren===<br />
Mit Edit kann man die Werte der Register ändern oder vorhandene Register aus dem Template entfernen. Ein Hinzufügen von Registern wird nicht unterstützt. Hier fehlt die Referenz um anzubieten, was möglich ist.<br />
===Template kopieren===<br />
Dies wird ebenfalls mit edit erreicht. Das Template wird mit saveAs unter einem neuen Namen gespeichert.<br />
===Template export-import===<br />
Will man Templates exportieren nutzt man <br><br />
;get ht <templatename><br />
Es wird ein kommando ausgegeben welches man in die Kommandozeile pasten kann, was dann der import ist.<br><br />
Dies kann man nutzen um Templates zu tauschen. Hat man ein ''gutes oder komplexes'' Template kann man dies der Allgemeinheit zu Verfügung stellen.<br><br />
Im besten Fall muss der User sich nicht mehr um Register kümmern, da komfortable Templates das besser abdecken.<br />
<br />
==Template einem Kanal zuweisen==<br />
Jetzt haben wir ein Template welches long und short eines Kanals kontrollieren soll. Dies wollen wir jetzt anwenden auf unsere Kanal/Peer Kompinationen "sw1/peer1", "sw1/peer2", "sw2/peer1" und "sw2/peer3". Für alle benötigen wir unterschiedliche Abschaltzeiten (warum? eure Sache). <br />
set ht select my1stTmpl<br />
attr ht entity sw1<br />
<refresh browser><br />
attr ht ePeer peer1<br />
attr ht tpl_param_timeOn 30<br />
set ht apply<br />
attr ht ePeer peer2<br />
attr ht tpl_param_timeOn 180<br />
set ht apply<br />
<br />
attr ht entity sw2<br />
<refresh browser><br />
attr ht ePeer peer1<br />
attr ht tpl_param_timeOn 70<br />
set ht apply<br />
<br />
attr ht ePeer peer3<br />
attr ht tpl_param_timeOn 1000<br />
set ht apply<br />
<br />
set ht dismiss<br />
Die Register der Entities werden passend in das Device geschrieben. <br />
==Template editieren==<br />
Nun soll das Template grundsätzlich modfiziert werden. <br />
<br />
set ht edit my1stTmpl<br />
attr ht Reg_<name> <value><br />
attr ht Reg_<name2> <value2><br />
attr ht Reg_<name3> <value3><br />
set ht save<br />
==Template kopieren und editieren==<br />
Nun soll das Template grundsätzlich modfiziert werden. <br />
<br />
set ht select my1stTmpl<br />
attr ht Reg_<name> <value><br />
attr ht Reg_<name2> <value2><br />
attr ht Reg_<name3> <value3><br />
set ht saveAs my2ndTmpl<br />
==Template weitergeben==<br />
Will man Templates weitergeben geht das mit<br />
get ht my1stTmpl<br />
Das Kommando kann dann direkt in die Kommandozeile kopiert werden und das Template ist definiert.<br />
[[Kategorie:HomeMatic supportDevice]]<br />
[[Kategorie:HOWTOS]]</div>Martinp876http://wiki.fhem.de/w/index.php?title=HomeMatic_Templates&diff=23945HomeMatic Templates2017-12-30T13:58:12Z<p>Martinp876: </p>
<hr />
<div>{{Infobox Modul<br />
|ModPurpose=templates bedienen und verwalten<br />
|ModType=h<br />
|ModCmdRef=HMtemplate<br />
|ModForumArea=HomeMatic<br />
|ModTechName=98_HMtemplate.pm<br />
|ModOwner=martinp876 ({{Link2FU|251|martinp876}} / [[Benutzer Diskussion:Martinp876|Wiki]])<br />
}}<br />
Templates sind Vorlagen im Allgemeinen. Hier werden Vorlagen zur Programmierung der Register von HM Devices behandelt. <br />
= Warum Templates =<br />
Die Frage, warum man Register nicht einfach setzt sondern Templates nutzen sollte kommt immer wieder auf. Schliesslich sind wie alle Spezialisten...<br />
Die Wahrheit allerdings bildet das nicht ab. Den auch den Spezialisten sei angeraten, Templates zu nutzen. Ja, warum den, was bieten Templates? Hierzu muss man verstehen wir FHEM, HM, Devices, Kanäle und peers zusammen hängen. <br />
<br />
Wie schon im Einsteigerdoc beschrieben hat ein HM Device remanente Register welche von FHEM gesetzt werden können und die Funktions- und Arbeitsweise definieren. FHEM selbst hat bestenfalls eine Kopie dieser Daten.<br />
;soll-Register Verwaltung<br />
:Da FHEM nur eine Kopie der Registerwerte verwaltet lebt man erst einmal in einer fragilen Welt. Registerwerte können sich ändern durch:<br />
* Reset des Device<br />
* Batteriefehler<br />
* inkorrektes Schreiben und Übertragungsfehler<br />
* Austausch eines Device<br />
:Nach Lesen der Device Register hat FHEM einen neue Kopie - dies muss aber nicht den Wunschregistern entsprechen. Templates sind eine Ansammlung von Wunschregister. Somit können unterschiedliche Mechanismen genutzt werden, das System zu verwalten, prüfen und korrigieren.<br />
;Funktionen für Einsteiger<br />
:Nicht-Experten sollten primär Templates nutzen - um Funktionen zu realisieren, und wenn gewünscht, Experten zu werden. Templares kann man einfach austauschen und dann anwenden.<br />
;Verwalten von Funktionen statt Registern<br />
:Als Experten kann man sicher die Register zeilsicher setzen. Wirklich? Wenn man sich eine clevere Lösung ausgedacht hat und sie reproduzieren will kann man einfach noch einmal nachdenken, nachlesen,... und schon hat man es wieder. Oder man hat ein Template definiert das man einfach nutzt.<br />
; Lernen aus Templates<br />
:Templates sind nicht verschlüsselt. Hat oder bekommt man ein Template kann man die dort gesetzten Register einfach einsehen - und wenn man will verstehen was gemacht wurde. <br />
;Globales Anpassen aller Devices <br />
: Hat man festgestellt, dass eine Funktion sub-optimal ist kann man das Temlate ändern und diese Änderungen allen Devices zu gute kommen lassen. Auf einmal. <br />
<br />
= Grundsätzliches zum Template =<br />
Templates (hier) ist nun also eine Sammlung von Registern welche in einem Device gesetzt werden können. <br />
<br />
== Template Granularität ==<br />
Man kann nicht alle Register eines Device in einem Template abbilden. Das wäre technisch komplex und macht auch von der Anwendung her keinen Sinn. <br />
<br />
*Aus Sicht der Funktion sollte man Templates nach deren Funktionen zusammenfassen.<br />
*Aus Sicht des Devices sollte man Templates nach der Struktur des Device zusammenstellen.<br />
*Die Implementierung erlaubt es, templates für jedes Register einzeln zu erstellen.<br><br />
*Weniger Templates erhöhen die Übersichtlichkeit<br />
Die technische Lösung legt folgenden Templates nahe<br />
#Alle Register eines Kanals oder Device - ausgenommen peer abhängige Register<br />
#Alle Register eines Kanals eines Peers für short oder long<br />
#Alle Register eines Kanals eines Peers nur für short<br />
#Alle Register eines Kanals eines Peers nur für long<br />
Ob man 2. oder die Kombination aus 3. und 4. nutzt ist Geschmackssache. <br><br />
Ein typischer Einsatz sind Schaltern und Dimmer bei welchen man die Aktionen der Peers festlegen will.<br />
;usecase Template Granularität Dimmer<br />
:Mit Peer1 soll bei short ein und bei long ausgeschaltet werden<br />
:Mit Peer2 soll bei short getoggelt und bei long nicht geschaltet werden<br />
:Mit Peer3 soll bei short nicht geschaltet und bei long getoggelt werden<br />
:Mit Peer4 ist ein MotionDetector welcher bei short und einer bestimmten Helligkeit einschaltet, timed. Allerdings sollen Aktionen der anderen Peers oder der Zentrale das Licht dauer-ein schalten.<br />
<br />
== Template Flexibilität ==<br />
Templates sind starr... und können parametriert werden. Also semistarr. Was jetzt? Nun man kann Templates mir bis zu 9 Parametern versehen. Sinnvoll sind wohl eher bis zu 3. <br><br />
Beispiele sind:<br />
*Treppenhausschaltern - mit einem Parameter kann man Einschaltdauer je Instanziierung festlegen. Sinnvoll könnte eine Treppenhausschaltung generell sein, nicht nur im Treppenhaus. Man kann generell alle Lichter nach ein paar Stunden ausschalten.<br />
*Heizungstemplate - Boosttime: Man kann allen RTs das gleiche Template geben - allerdings kann man z.B. die Boosttime indivituell einstellen. <br />
*MotionDetector Clients: Bei den Peers des Modtion detector (also den Schaltern) stellt man ein, dann diese reagieren sollen und wie lange diese brennen sollen. <br />
<br />
== Template Verwaltung==<br />
Templates werden zusammen mit Registern verwaltet. Man benötigt demnach HMinfo. Sowohl die Template definition alsauch die Template Zuweisung werden im File zusammen mit den gelesenen Registern gesichert. Nach einem Einlesen dieses Files werden auch die Templates und deren Zuordnung neu erstellt.<br />
<br />
== Template Editieren==<br />
Die aktuell einfachste Möglichkeit ein Template zu modifizieren ist, HMtemplate zu nutzen. HMtemplate ist ein Editor. Für den Betrieb wird es nicht genutzt. <br />
<br />
<br />
=Das eigenen Konzept=<br />
Für die Verknüpfung von HM Entities muss man 2 Ebenen unterschieden, Architektur und Verhalten.<br />
==Architektur==<br />
Beim Erstellen der Architektur legt man fest, welche Entities untereinander verknüpft werden. Dies geschieht durch peeren. Templates unterstützen nicht die Architektur. Es ist demnach notwendig die Peerings durchzuführen bevor an ein Template darauf anwenden kann. <br />
==Verhalten==<br />
Hier kommen die Templates zum Tragen. Mit Templates definiert man die Register der Entities und somit das Verhalten und die Reaktion der Entites bspw auf Trigger von Sensoren.<br />
===Welchen templateTyp brauche ich===<br />
Wie in Granularität beschrieben kann man insbesondere beim Peerverhalten templates für ''short'', ''long'' oder ''both'' ertellen. Nutzt man short/long braucht man weniger Templates (Basics sind on/off/ignore/toggle) muss allerdings mehr Templates zuweisen, als Reaktion auf short UND long.<br><br />
Bei both braucht man mehr Templates (OnOff/OnIgnore/OffIgnore/IgnoreOff/ToggleIgnore/...) braucht aber nur die Hälfte der Zuweisungen zu den realen Entities. <br />
<br />
===Welche Parameter muss ich einstellen===<br />
Bei der Erstellung eine Templates werden dessen Parameter durch Attribute vorgegeben. Durch '''set save''' wird dann das Template schlussendlich definiert. Folgende Parameter/Attribute werden genutzt:<br />
*'''tpl_description''': ist ein Freitext welcher beschreiben soll, was das Template macht und wie es parametriert wird<br />
*'''tpl_params''': hier werden evtl Parameter definiert mit welchen die Instanziierung des Templates angepasst werden kann. Bspw. könnte die Einschaltzeit variable gestalltet werden. Bei einem Dimmer könnt man den Level und die Rampe eingeben, also 2 Parameter. Man vergibt also, ":" getrennt, eine Liste von Paramtern. Die Namen sind frei wählbar. <br><br />
:''timeOn:ramp'' würde 2 Parameter definieren, welche später in den Registern genutzt werden können<br />
*'''tpl_type''': definiert den Typ. Diesen muss man zuerst festlegen. Es konnte ''peer-Short'',''peer-Long'',''peer-Both'' oder ''basic'' sein. Nach der Auswahl des Typs kann man die Entity (source) wählen. Es alle Entities angeboten, welche entsprechende Registersätze zu Verfügung stellen.<br />
*'''tpl_source''': legt bei der Definition eines Templates fest, von welcher Entity die Register für die Vorlage genutzt werden sollen. Ein Browser-Refresh könnte notwendig sein um die Auswahlliste upzudaten<br />
*'''tpl_peer''': muss man auswählen, so man einen "peer" typ gewählt hat. An Browser-refresh denken. <br />
*'''Reg_xxx''': An Browser-refresh denken. Hat man nun die Vorlage ausgewählt und den Refresh gemach werden nun Register als Attribute angeboten. <br><br />
:Zunächst sollte man Registerattribute löschen, welche man für das Template nicht benötigt. Achtung: eine Option gelöschte Registerattribute wieder nachzutragen ist nicht vorgesehen. So schlimm ist es allerdings nicht - man muss halt noch einmal alle Lesen und von Vorne löschen. <br><br />
:Sinnvoll kann es sein, die Condition Table Register komplett zu eliminieren wenn man Reaktionen auf Taster definieren will. Will man ''ignore'' definieren, also keine Reaktion bspw auf ''long'', dann kann man alles löschen bis auf ActionType usw. <br><br />
:Sinnvoll ist es, nur notwendige Register der Funktion zu bearbeiten, da sonst die Anwendung des Templates eingeschränkt wird. <br><br />
:Es sollten aber alle Register der Funktion enthalten sein, da die Prüfung auch nur diese berücksichtigt und bei einem Umprogrammieren nicht klar ist, was vorher in einem Register gestanden ist.<br />
===Register Werte setzen===<br />
Nun das eigentliche - das setzen der Registerinhalte. Dies wird begrenzt unterstützt. Sollte das Register durch ''literals'' definiert werden erscheint beim Setzen eine drop-down Liste mit den Optionen. <br><br />
Nicht unterstützt wird das Setzen von Werten. Es gibt aktuell keine Option, hier eine Hilfe einzublenden. Die Wertebereiche sind dem regList der Entity zu entnehmen. <br><br />
Eine weitere Besonderheit ist die Granularität der Werte. Insbesondere durch das Float Format einiger Werte sind nicht alle Werte möglich. Trägt man bspw eine Ontime von 10000 ein wird dies erst einmal akzeptiert. Allerdings wird der Wert beim Schreiben umgerechnet in den nächstmöglichen (welcher 9600 ist). Bei der Prüfung der Template Anwendung wird der Unterschied angemerkt. Am Einfachsten wird nun das Template angepasst und alles ist gut.<br><br />
<br><br />
Nun tpl_params. Diese muss man anstelle des Registerwerts einsetzen. Hat man bspw <br><br />
tpl_params timeOn:rampTime<br><br />
definiert setzt man in das Register ''OnTime'' den Wert ''timeOn'' ein. Und eben das Rampenregiste den Wert ''rampTime''. Der Wert wird dann beim Template Instanziieren - also Anwenden - durch den Individuellen ersetzt.<br />
<br />
=Getting started=<br />
Was muss man also tun? Wenn man noch nichts eingerichtet hat:<br />
define hm HMinfo<br />
attr hm autoArchive 1<br />
attr hm autoLoadArchive 1_load<br />
attr hm configFilename regConfig.cfg<br />
define ht HMtemplate<br />
<br />
==Template erstellen und bearbeiten==<br />
===Template aus Device===<br />
Aufgabe ist es, aus einem existierenden Device ein Template zu erstellen. Wir haben <br />
device ''myDev''<br />
Channel ''myChan''<br />
Channel gepeert mit ''myChanPeer''.<br><br />
Der Kanal ist ein Schalter und wir wollen einen Parameter im Template nutzen: Die Anschaltzeit soll bei der Nutzung des Templates variabel eingesetzt werden. Wir werden also den Parameter ''timeOn'' nutzen. Das Template soll ''my1stTmpl'' genannt werden. Weiter soll das gesamte Verhalten des ''myChanPeer'' definiert werden, also short UND long. <br />
set ht define my1stTmpl<br />
attr ht tpl_param timeOn # name des Parameters - hier nur einer<br />
attr ht tpl_description "mein erstes Template"<br />
attr ht tpl_type peer-both<br />
<refresh browser> # select liste der attribute wird neu eingelesen<br />
attr ht tpl_source myChan<br />
<refresh browser> # select liste der attribute wird neu eingelesen<br />
attr ht tpl_peer myChanPeer<br />
<refresh browser> # select liste der attribute wird neu eingelesen<br />
attr ht Reg_shOnTime timeOn # setzen des parameters<br />
<br />
nun können weitere Register verändert werde. <br />
Sinnvoll ist es, unnötige Register aus dem Template zu entfernen. Dies sind in diesem Fall bspw. alle Ct register. Das Attribut des Registers wird einfach gelöscht. <br />
set ht save<br />
set ht dismiss<br />
===Template Varianten speichern===<br />
Ist man beim Erstellen von Templates kann man mti saveAs das Template als neues unter einem anderen Namen sichern. <br />
===Template editieren===<br />
Mit Edit kann man die Werte der Register ändern oder vorhandene Register aus dem Template entfernen. Ein Hinzufügen von Registern wird nicht unterstützt. Hier fehlt die Referenz um anzubieten, was möglich ist.<br />
===Template kopieren===<br />
Dies wird ebenfalls mit edit erreicht. Das Template wird mit saveAs unter einem neuen Namen gespeichert. <br />
<br />
==Template einem Kanal zuweisen==<br />
Jetzt haben wir ein Template welches long und short eines Kanals kontrollieren soll. Dies wollen wir jetzt anwenden auf unsere Kanal/Peer Kompinationen "sw1/peer1", "sw1/peer2", "sw2/peer1" und "sw2/peer3". Für alle benötigen wir unterschiedliche Abschaltzeiten (warum? eure Sache). <br />
set ht select my1stTmpl<br />
attr ht entity sw1<br />
<refresh browser><br />
attr ht ePeer peer1<br />
attr ht tpl_param_timeOn 30<br />
set ht apply<br />
attr ht ePeer peer2<br />
attr ht tpl_param_timeOn 180<br />
set ht apply<br />
<br />
attr ht entity sw2<br />
<refresh browser><br />
attr ht ePeer peer1<br />
attr ht tpl_param_timeOn 70<br />
set ht apply<br />
<br />
attr ht ePeer peer3<br />
attr ht tpl_param_timeOn 1000<br />
set ht apply<br />
<br />
set ht dismiss<br />
Die Register der Entities werden passend in das Device geschrieben. <br />
==Template editieren==<br />
Nun soll das Template grundsätzlich modfiziert werden. <br />
<br />
set ht edit my1stTmpl<br />
attr ht Reg_<name> <value><br />
attr ht Reg_<name2> <value2><br />
attr ht Reg_<name3> <value3><br />
set ht save<br />
==Template kopieren und editieren==<br />
Nun soll das Template grundsätzlich modfiziert werden. <br />
<br />
set ht select my1stTmpl<br />
attr ht Reg_<name> <value><br />
attr ht Reg_<name2> <value2><br />
attr ht Reg_<name3> <value3><br />
set ht saveAs my2ndTmpl<br />
==Template weitergeben==<br />
Will man Templates weitergeben geht das mit<br />
get ht my1stTmpl<br />
Das Kommando kann dann direkt in die Kommandozeile kopiert werden und das Template ist definiert.<br />
[[Kategorie:HomeMatic supportDevice]]<br />
[[Kategorie:HOWTOS]]</div>Martinp876http://wiki.fhem.de/w/index.php?title=HomeMatic_Templates&diff=23944HomeMatic Templates2017-12-30T13:57:40Z<p>Martinp876: </p>
<hr />
<div>{{Infobox Modul<br />
|ModPurpose=templates bedienen und verwalten<br />
|ModType=h<br />
|ModCmdRef=HMtemplate<br />
|ModForumArea=HomeMatic<br />
|ModTechName=98_HMtemplate.pm<br />
|ModOwner=martinp876 ({{Link2FU|251|martinp876}} / [[Benutzer Diskussion:Martinp876|Wiki]])<br />
}}<br />
Templates sind Vorlagen im Allgemeinen. Hier werden Vorlagen zur Programmierung der Register von HM Devices behandelt. <br />
= Warum Templates =<br />
Die Frage, warum man Register nicht einfach setzt sondern Templates nutzen sollte kommt immer wieder auf. Schliesslich sind wie alle Spezialisten...<br />
Die Wahrheit allerdings bildet das nicht ab. Den auch den Spezialisten sei angeraten, Templates zu nutzen. Ja, warum den, was bieten Templates? Hierzu muss man verstehen wir FHEM, HM, Devices, Kanäle und peers zusammen hängen. <br />
<br />
Wie schon im Einsteigerdoc beschrieben hat ein HM Device remanente Register welche von FHEM gesetzt werden können und die Funktions- und Arbeitsweise definieren. FHEM selbst hat bestenfalls eine Kopie dieser Daten.<br />
;soll-Register Verwaltung<br />
:Da FHEM nur eine Kopie der Registerwerte verwaltet lebt man erst einmal in einer fragilen Welt. Registerwerte können sich ändern durch:<br />
* Reset des Device<br />
* Batteriefehler<br />
* inkorrektes Schreiben und Übertragungsfehler<br />
* Austausch eines Device<br />
:Nach Lesen der Device Register hat FHEM einen neue Kopie - dies muss aber nicht den Wunschregistern entsprechen. Templates sind eine Ansammlung von Wunschregister. Somit können unterschiedliche Mechanismen genutzt werden, das System zu verwalten, prüfen und korrigieren.<br />
;Funktionen für Einsteiger<br />
:Nicht-Experten sollten primär Templates nutzen - um Funktionen zu realisieren, und wenn gewünscht, Experten zu werden. Templares kann man einfach austauschen und dann anwenden.<br />
;Verwalten von Funktionen statt Registern<br />
:Als Experten kann man sicher die Register zeilsicher setzen. Wirklich? Wenn man sich eine clevere Lösung ausgedacht hat und sie reproduzieren will kann man einfach noch einmal nachdenken, nachlesen,... und schon hat man es wieder. Oder man hat ein Template definiert das man einfach nutzt.<br />
; Lernen aus Templates<br />
:Templates sind nicht verschlüsselt. Hat oder bekommt man ein Template kann man die dort gesetzten Register einfach einsehen - und wenn man will verstehen was gemacht wurde. <br />
;Globales Anpassen aller Devices <br />
: Hat man festgestellt, dass eine Funktion sub-optimal ist kann man das Temlate ändern und diese Änderungen allen Devices zu gute kommen lassen. Auf einmal. <br />
<br />
= Grundsätzliches zum Template =<br />
Templates (hier) ist nun also eine Sammlung von Registern welche in einem Device gesetzt werden können. <br />
<br />
== Template Granularität ==<br />
Man kann nicht alle Register eines Device in einem Template abbilden. Das wäre technisch komplex und macht auch von der Anwendung her keinen Sinn. <br />
<br />
*Aus Sicht der Funktion sollte man Templates nach deren Funktionen zusammenfassen.<br />
*Aus Sicht des Devices sollte man Templates nach der Struktur des Device zusammenstellen.<br />
*Die Implementierung erlaubt es, templates für jedes Register einzeln zu erstellen.<br><br />
*Weniger Templates erhöhen die Übersichtlichkeit<br />
Die technische Lösung legt folgenden Templates nahe<br />
#Alle Register eines Kanals oder Device - ausgenommen peer abhängige Register<br />
#Alle Register eines Kanals eines Peers für short oder long<br />
#Alle Register eines Kanals eines Peers nur für short<br />
#Alle Register eines Kanals eines Peers nur für long<br />
Ob man 2. oder die Kombination aus 3. und 4. nutzt ist Geschmackssache. <br><br />
Ein typischer Einsatz sind Schaltern und Dimmer bei welchen man die Aktionen der Peers festlegen will.<br />
;usecase Template Granularität Dimmer<br />
:Mit Peer1 soll bei short ein und bei long ausgeschaltet werden<br />
:Mit Peer2 soll bei short getoggelt und bei long nicht geschaltet werden<br />
:Mit Peer3 soll bei short nicht geschaltet und bei long getoggelt werden<br />
:Mit Peer4 ist ein MotionDetector welcher bei short und einer bestimmten Helligkeit einschaltet, timed. Allerdings sollen Aktionen der anderen Peers oder der Zentrale das Licht dauer-ein schalten.<br />
<br />
== Template Flexibilität ==<br />
Templates sind starr... und können parametriert werden. Also semistarr. Was jetzt? Nun man kann Templates mir bis zu 9 Parametern versehen. Sinnvoll sind wohl eher bis zu 3. <br><br />
Beispiele sind:<br />
*Treppenhausschaltern - mit einem Parameter kann man Einschaltdauer je Instanziierung festlegen. Sinnvoll könnte eine Treppenhausschaltung generell sein, nicht nur im Treppenhaus. Man kann generell alle Lichter nach ein paar Stunden ausschalten.<br />
*Heizungstemplate - Boosttime: Man kann allen RTs das gleiche Template geben - allerdings kann man z.B. die Boosttime indivituell einstellen. <br />
*MotionDetector Clients: Bei den Peers des Modtion detector (also den Schaltern) stellt man ein, dann diese reagieren sollen und wie lange diese brennen sollen. <br />
<br />
== Template Verwaltung==<br />
Templates werden zusammen mit Registern verwaltet. Man benötigt demnach HMinfo. Sowohl die Template definition alsauch die Template Zuweisung werden im File zusammen mit den gelesenen Registern gesichert. Nach einem Einlesen dieses Files werden auch die Templates und deren Zuordnung neu erstellt.<br />
<br />
== Template Editieren==<br />
Die aktuell einfachste Möglichkeit ein Template zu modifizieren ist, HMtemplate zu nutzen. HMtemplate ist ein Editor. Für den Betrieb wird es nicht genutzt. <br />
<br />
<br />
=Das eigenen Konzept=<br />
Für die Verknüpfung von HM Entities muss man 2 Ebenen unterschieden, Architektur und Verhalten.<br />
==Architektur==<br />
Beim Erstellen der Architektur legt man fest, welche Entities untereinander verknüpft werden. Dies geschieht durch peeren. Templates unterstützen nicht die Architektur. Es ist demnach notwendig die Peerings durchzuführen bevor an ein Template darauf anwenden kann. <br />
==Verhalten==<br />
Hier kommen die Templates zum Tragen. Mit Templates definiert man die Register der Entities und somit das Verhalten und die Reaktion der Entites bspw auf Trigger von Sensoren.<br />
===Welchen templateTyp brauche ich===<br />
Wie in Granularität beschrieben kann man insbesondere beim Peerverhalten templates für ''short'', ''long'' oder ''both'' ertellen. Nutzt man short/long braucht man weniger Templates (Basics sind on/off/ignore/toggle) muss allerdings mehr Templates zuweisen, als Reaktion auf short UND long.<br><br />
Bei both braucht man mehr Templates (OnOff/OnIgnore/OffIgnore/IgnoreOff/ToggleIgnore/...) braucht aber nur die Hälfte der Zuweisungen zu den realen Entities. <br />
<br />
===Welche Parameter muss ich einstellen===<br />
Bei der Erstellung eine Templates werden dessen Parameter durch Attribute vorgegeben. Durch '''set save''' wird dann das Template schlussendlich definiert. Folgende Parameter/Attribute werden genutzt:<br />
*'''tpl_description''': ist ein Freitext welcher beschreiben soll, was das Template macht und wie es parametriert wird<br />
*'''tpl_params''': hier werden evtl Parameter definiert mit welchen die Instanziierung des Templates angepasst werden kann. Bspw. könnte die Einschaltzeit variable gestalltet werden. Bei einem Dimmer könnt man den Level und die Rampe eingeben, also 2 Parameter. Man vergibt also, ":" getrennt, eine Liste von Paramtern. Die Namen sind frei wählbar. <br><br />
:''timeOn:ramp'' würde 2 Parameter definieren, welche später in den Registern genutzt werden können<br />
*'''tpl_type''': definiert den Typ. Diesen muss man zuerst festlegen. Es konnte ''peer-Short'',''peer-Long'',''peer-Both'' oder ''basic'' sein. Nach der Auswahl des Typs kann man die Entity (source) wählen. Es alle Entities angeboten, welche entsprechende Registersätze zu Verfügung stellen.<br />
*'''tpl_source''': legt bei der Definition eines Templates fest, von welcher Entity die Register für die Vorlage genutzt werden sollen. Ein Browser-Refresh könnte notwendig sein um die Auswahlliste upzudaten<br />
*'''tpl_peer''': muss man auswählen, so man einen "peer" typ gewählt hat. An Browser-refresh denken. <br />
*'''Reg_xxx''': An Browser-refresh denken. Hat man nun die Vorlage ausgewählt und den Refresh gemach werden nun Register als Attribute angeboten. <br><br />
:Zunächst sollte man Registerattribute löschen, welche man für das Template nicht benötigt. Achtung: eine Option gelöschte Registerattribute wieder nachzutragen ist nicht vorgesehen. So schlimm ist es allerdings nicht - man muss halt noch einmal alle Lesen und von Vorne löschen. <br><br />
:Sinnvoll kann es sein, die Condition Table Register komplett zu eliminieren wenn man Reaktionen auf Taster definieren will. Will man ''ignore'' definieren, also keine Reaktion bspw auf ''long'', dann kann man alles löschen bis auf ActionType usw. <br><br />
:Sinnvoll ist es, nur notwendige Register der Funktion zu bearbeiten, da sonst die Anwendung des Templates eingeschränkt wird. <br><br />
:Es sollten aber alle Register der Funktion enthalten sein, da die Prüfung auch nur diese berücksichtigt und bei einem Umprogrammieren nicht klar ist, was vorher in einem Register gestanden ist.<br />
===Registerattribute setzen===<br />
Nun das eigentliche - das setzen der Registerinhalte. Dies wird begrenzt unterstützt. Sollte das Register durch ''literals'' definiert werden erscheint beim Setzen eine drop-down Liste mit den Optionen. <br><br />
Nicht unterstützt wird das Setzen von Werten. Es gibt aktuell keine Option, hier eine Hilfe einzublenden. Die Wertebereiche sind dem regList der Entity zu entnehmen. <br><br />
Eine weitere Besonderheit ist die Granularität der Werte. Insbesondere durch das Float Format einiger Werte sind nicht alle Werte möglich. Trägt man bspw eine Ontime von 10000 ein wird dies erst einmal akzeptiert. Allerdings wird der Wert beim Schreiben umgerechnet in den nächstmöglichen (welcher 9600 ist). Bei der Prüfung der Template Anwendung wird der Unterschied angemerkt. Am Einfachsten wird nun das Template angepasst und alles ist gut.<br><br />
<br><br />
Nun tpl_params. Diese muss man anstelle des Registerwerts einsetzen. Hat man bspw <br><br />
tpl_params timeOn:rampTime<br><br />
definiert setzt man in das Register ''OnTime'' den Wert ''timeOn'' ein. Und eben das Rampenregiste den Wert ''rampTime''. Der Wert wird dann beim Template Instanziieren - also Anwenden - durch den Individuellen ersetzt.<br />
<br />
=Getting started=<br />
Was muss man also tun? Wenn man noch nichts eingerichtet hat:<br />
define hm HMinfo<br />
attr hm autoArchive 1<br />
attr hm autoLoadArchive 1_load<br />
attr hm configFilename regConfig.cfg<br />
define ht HMtemplate<br />
<br />
==Template erstellen und bearbeiten==<br />
===Template aus Device===<br />
Aufgabe ist es, aus einem existierenden Device ein Template zu erstellen. Wir haben <br />
device ''myDev''<br />
Channel ''myChan''<br />
Channel gepeert mit ''myChanPeer''.<br><br />
Der Kanal ist ein Schalter und wir wollen einen Parameter im Template nutzen: Die Anschaltzeit soll bei der Nutzung des Templates variabel eingesetzt werden. Wir werden also den Parameter ''timeOn'' nutzen. Das Template soll ''my1stTmpl'' genannt werden. Weiter soll das gesamte Verhalten des ''myChanPeer'' definiert werden, also short UND long. <br />
set ht define my1stTmpl<br />
attr ht tpl_param timeOn # name des Parameters - hier nur einer<br />
attr ht tpl_description "mein erstes Template"<br />
attr ht tpl_type peer-both<br />
<refresh browser> # select liste der attribute wird neu eingelesen<br />
attr ht tpl_source myChan<br />
<refresh browser> # select liste der attribute wird neu eingelesen<br />
attr ht tpl_peer myChanPeer<br />
<refresh browser> # select liste der attribute wird neu eingelesen<br />
attr ht Reg_shOnTime timeOn # setzen des parameters<br />
<br />
nun können weitere Register verändert werde. <br />
Sinnvoll ist es, unnötige Register aus dem Template zu entfernen. Dies sind in diesem Fall bspw. alle Ct register. Das Attribut des Registers wird einfach gelöscht. <br />
set ht save<br />
set ht dismiss<br />
===Template Varianten speichern===<br />
Ist man beim Erstellen von Templates kann man mti saveAs das Template als neues unter einem anderen Namen sichern. <br />
===Template editieren===<br />
Mit Edit kann man die Werte der Register ändern oder vorhandene Register aus dem Template entfernen. Ein Hinzufügen von Registern wird nicht unterstützt. Hier fehlt die Referenz um anzubieten, was möglich ist.<br />
===Template kopieren===<br />
Dies wird ebenfalls mit edit erreicht. Das Template wird mit saveAs unter einem neuen Namen gespeichert. <br />
<br />
==Template einem Kanal zuweisen==<br />
Jetzt haben wir ein Template welches long und short eines Kanals kontrollieren soll. Dies wollen wir jetzt anwenden auf unsere Kanal/Peer Kompinationen "sw1/peer1", "sw1/peer2", "sw2/peer1" und "sw2/peer3". Für alle benötigen wir unterschiedliche Abschaltzeiten (warum? eure Sache). <br />
set ht select my1stTmpl<br />
attr ht entity sw1<br />
<refresh browser><br />
attr ht ePeer peer1<br />
attr ht tpl_param_timeOn 30<br />
set ht apply<br />
attr ht ePeer peer2<br />
attr ht tpl_param_timeOn 180<br />
set ht apply<br />
<br />
attr ht entity sw2<br />
<refresh browser><br />
attr ht ePeer peer1<br />
attr ht tpl_param_timeOn 70<br />
set ht apply<br />
<br />
attr ht ePeer peer3<br />
attr ht tpl_param_timeOn 1000<br />
set ht apply<br />
<br />
set ht dismiss<br />
Die Register der Entities werden passend in das Device geschrieben. <br />
==Template editieren==<br />
Nun soll das Template grundsätzlich modfiziert werden. <br />
<br />
set ht edit my1stTmpl<br />
attr ht Reg_<name> <value><br />
attr ht Reg_<name2> <value2><br />
attr ht Reg_<name3> <value3><br />
set ht save<br />
==Template kopieren und editieren==<br />
Nun soll das Template grundsätzlich modfiziert werden. <br />
<br />
set ht select my1stTmpl<br />
attr ht Reg_<name> <value><br />
attr ht Reg_<name2> <value2><br />
attr ht Reg_<name3> <value3><br />
set ht saveAs my2ndTmpl<br />
==Template weitergeben==<br />
Will man Templates weitergeben geht das mit<br />
get ht my1stTmpl<br />
Das Kommando kann dann direkt in die Kommandozeile kopiert werden und das Template ist definiert.<br />
[[Kategorie:HomeMatic supportDevice]]<br />
[[Kategorie:HOWTOS]]</div>Martinp876http://wiki.fhem.de/w/index.php?title=HomeMatic_Templates&diff=23940HomeMatic Templates2017-12-30T11:00:36Z<p>Martinp876: </p>
<hr />
<div>{{Infobox Modul<br />
|ModPurpose=templates bedienen und verwalten<br />
|ModType=h<br />
|ModCmdRef=HMtemplate<br />
|ModForumArea=HomeMatic<br />
|ModTechName=98_HMtemplate.pm<br />
|ModOwner=martinp876 ({{Link2FU|251|martinp876}} / [[Benutzer Diskussion:Martinp876|Wiki]])<br />
}}<br />
Templates sind Vorlagen im Allgemeinen. Hier werden Vorlagen zur Programmierung der Register von HM Devices behandelt. <br />
= Warum Templates =<br />
Die Frage, warum man Register nicht einfach setzt sondern Templates nutzen sollte kommt immer wieder auf. Schliesslich sind wie alle Spezialisten...<br />
Die Wahrheit allerdings bildet das nicht ab. Den auch den Spezialisten sei angeraten, Templates zu nutzen. Ja, warum den, was bieten Templates? Hierzu muss man verstehen wir FHEM, HM, Devices, Kanäle und peers zusammen hängen. <br />
<br />
Wie schon im Einsteigerdoc beschrieben hat ein HM Device remanente Register welche von FHEM gesetzt werden können und die Funktions- und Arbeitsweise definieren. FHEM selbst hat bestenfalls eine Kopie dieser Daten.<br />
;soll-Register Verwaltung<br />
:Da FHEM nur eine Kopie der Registerwerte verwaltet lebt man erst einmal in einer fragilen Welt. Registerwerte können sich ändern durch:<br />
* Reset des Device<br />
* Batteriefehler<br />
* inkorrektes Schreiben und Übertragungsfehler<br />
* Austausch eines Device<br />
:Nach Lesen der Device Register hat FHEM einen neue Kopie - dies muss aber nicht den Wunschregistern entsprechen. Templates sind eine Ansammlung von Wunschregister. Somit können unterschiedliche Mechanismen genutzt werden, das System zu verwalten, prüfen und korrigieren.<br />
;Funktionen für Einsteiger<br />
:Nicht-Experten sollten primär Templates nutzen - um Funktionen zu realisieren, und wenn gewünscht, Experten zu werden. Templares kann man einfach austauschen und dann anwenden.<br />
;Verwalten von Funktionen statt Registern<br />
:Als Experten kann man sicher die Register zeilsicher setzen. Wirklich? Wenn man sich eine clevere Lösung ausgedacht hat und sie reproduzieren will kann man einfach noch einmal nachdenken, nachlesen,... und schon hat man es wieder. Oder man hat ein Template definiert das man einfach nutzt.<br />
; Lernen aus Templates<br />
:Templates sind nicht verschlüsselt. Hat oder bekommt man ein Template kann man die dort gesetzten Register einfach einsehen - und wenn man will verstehen was gemacht wurde. <br />
;Globales Anpassen aller Devices <br />
: Hat man festgestellt, dass eine Funktion sub-optimal ist kann man das Temlate ändern und diese Änderungen allen Devices zu gute kommen lassen. Auf einmal. <br />
<br />
= Grundsätzliches zum Template =<br />
Templates (hier) ist nun also eine Sammlung von Registern welche in einem Device gesetzt werden können. <br />
<br />
== Template Granularität ==<br />
Man kann nicht alle Register eines Device in einem Template abbilden. Das wäre technisch komplex und macht auch von der Anwendung her keinen Sinn. <br />
<br />
*Aus Sicht der Funktion sollte man Templates nach deren Funktionen zusammenfassen.<br />
*Aus Sicht des Devices sollte man Templates nach der Struktur des Device zusammenstellen.<br />
*Die Implementierung erlaubt es, templates für jedes Register einzeln zu erstellen.<br><br />
*Weniger Templates erhöhen die Übersichtlichkeit<br />
Die technische Lösung legt folgenden Templates nahe<br />
#Alle Register eines Kanals oder Device - ausgenommen peer abhängige Register<br />
#Alle Register eines Kanals eines Peers für short oder long<br />
#Alle Register eines Kanals eines Peers nur für short<br />
#Alle Register eines Kanals eines Peers nur für long<br />
Ob man 2. oder die Kombination aus 3. und 4. nutzt ist Geschmackssache. <br><br />
Ein typischer Einsatz sind Schaltern und Dimmer bei welchen man die Aktionen der Peers festlegen will.<br />
;usecase Template Granularität Dimmer<br />
:Mit Peer1 soll bei short ein und bei long ausgeschaltet werden<br />
:Mit Peer2 soll bei short getoggelt und bei long nicht geschaltet werden<br />
:Mit Peer3 soll bei short nicht geschaltet und bei long getoggelt werden<br />
:Mit Peer4 ist ein MotionDetector welcher bei short und einer bestimmten Helligkeit einschaltet, timed. Allerdings sollen Aktionen der anderen Peers oder der Zentrale das Licht dauer-ein schalten.<br />
<br />
== Template Flexibilität ==<br />
Templates sind starr... und können parametriert werden. Also semistarr. Was jetzt? Nun man kann Templates mir bis zu 9 Parametern versehen. Sinnvoll sind wohl eher bis zu 3. <br><br />
Beispiele sind:<br />
*Treppenhausschaltern - mit einem Parameter kann man Einschaltdauer je Instanziierung festlegen. Sinnvoll könnte eine Treppenhausschaltung generell sein, nicht nur im Treppenhaus. Man kann generell alle Lichter nach ein paar Stunden ausschalten.<br />
*Heizungstemplate - Boosttime: Man kann allen RTs das gleiche Template geben - allerdings kann man z.B. die Boosttime indivituell einstellen. <br />
*MotionDetector Clients: Bei den Peers des Modtion detector (also den Schaltern) stellt man ein, dann diese reagieren sollen und wie lange diese brennen sollen. <br />
<br />
== Template Verwaltung==<br />
Templates werden zusammen mit Registern verwaltet. Man benötigt demnach HMinfo. Sowohl die Template definition alsauch die Template Zuweisung werden im File zusammen mit den gelesenen Registern gesichert. Nach einem Einlesen dieses Files werden auch die Templates und deren Zuordnung neu erstellt.<br />
<br />
== Template Editieren==<br />
Die aktuell einfachste Möglichkeit ein Template zu modifizieren ist, HMtemplate zu nutzen. HMtemplate ist ein Editor. Für den Betrieb wird es nicht genutzt. <br />
<br />
<br />
=Das eigenen Konzept=<br />
Für die Verknüpfung von HM Entities muss man 2 Ebenen unterschieden, Architektur und Verhalten.<br />
==Architektur==<br />
Beim Erstellen der Architektur legt man fest, welche Entities untereinander verknüpft werden. Dies geschieht durch peeren. Templates unterstützen nicht die Architektur. Es ist demnach notwendig die Peerings durchzuführen bevor an ein Template darauf anwenden kann. <br />
==Verhalten==<br />
Hier kommen die Templates zum Tragen. Mit Templates definiert man die Register der Entities und somit das Verhalten und die Reaktion der Entites bspw auf Trigger von Sensoren.<br />
===Welchen templateTyp brauche ich===<br />
Wie in Granularität beschrieben kann man insbesondere beim Peerverhalten templates für ''short'', ''long'' oder ''both'' ertellen. Nutzt man short/long braucht man weniger Templates (Basics sind on/off/ignore/toggle) muss allerdings mehr Templates zuweisen, als Reaktion auf short UND long.<br><br />
Bei both braucht man mehr Templates (OnOff/OnIgnore/OffIgnore/IgnoreOff/ToggleIgnore/...) braucht aber nur die Hälfte der Zuweisungen zu den realen Entities. <br />
<br />
===Welche Parameter muss ich einstellen===<br />
Bei der Erstellung eine Templates werden dessen Parameter durch Attribute vorgegeben. Durch '''set save''' wird dann das Template schlussendlich definiert. Folgende Parameter/Attribute werden genutzt:<br />
*'''tpl_description''': ist ein Freitext welcher beschreiben soll, was das Template macht und wie es parametriert wird<br />
*'''tpl_params''': hier werden evtl Parameter definiert mit welchen die Instanziierung des Templates angepasst werden kann. Bspw. könnte die Einschaltzeit variable gestalltet werden. Bei einem Dimmer könnt man den Level und die Rampe eingeben, also 2 Parameter. Man vergibt also, ":" getrennt, eine Liste von Paramtern. Die Namen sind frei wählbar. <br><br />
:''timeOn:ramp'' würde 2 Parameter definieren, welche später in den Registern genutzt werden können<br />
*'''tpl_type''': definiert den Typ. Diesen muss man zuerst festlegen. Es konnte ''peer-Short'',''peer-Long'',''peer-Both'' oder ''basic'' sein. Nach der Auswahl des Typs kann man die Entity (source) wählen. Es alle Entities angeboten, welche entsprechende Registersätze zu Verfügung stellen.<br />
*'''tpl_source''': legt bei der Definition eines Templates fest, von welcher Entity die Register für die Vorlage genutzt werden sollen. Ein Browser-Refresh könnte notwendig sein um die Auswahlliste upzudaten<br />
*'''tpl_peer''': muss man auswählen, so man einen "peer" typ gewählt hat. An Browser-refresh denken. <br />
*'''Reg_xxx''': An Browser-refresh denken. Hat man nun die Vorlage ausgewählt und den Refresh gemach werden nun Register als Attribute angeboten. <br><br />
:Zunächst sollte man Registerattribute löschen, welche man für das Template nicht benötigt. Achtung: eine Option gelöschte Registerattribute wieder nachzutragen ist nicht vorgesehen. So schlimm ist es allerdings nicht - man muss halt noch einmal alle Lesen und von Vorne löschen. <br><br />
:Sinnvoll kann es sein, die Condition Table Register komplett zu eliminieren wenn man Reaktionen auf Taster definieren will. Will man ''ignore'' definieren, also keine Reaktion bspw auf ''long'', dann kann man alles löschen bis auf ActionType usw. <br><br />
:Sinnvoll ist es, nur notwendige Register der Funktion zu bearbeiten, da sonst die Anwendung des Templates eingeschränkt wird. <br><br />
:Es sollten aber alle Register der Funktion enthalten sein, da die Prüfung auch nur diese berücksichtigt und bei einem Umprogrammieren nicht klar ist, was vorher in einem Register gestanden ist.<br />
===Registerattribute setzen===<br />
Nun das eigentliche - das setzen der Registerinhalte. Dies wird begrenzt unterstützt. Sollte das Register durch ''literals'' definiert werden erscheint beim Setzen eine drop-down Liste mit den Optionen. <br><br />
Nicht unterstützt wird das Setzen von Werten. Es gibt aktuell keine Option, hier eine Hilfe einzublenden. Die Wertebereiche sind dem regList der Entity zu entnehmen. <br><br />
Eine weitere Besonderheit ist die Granularität der Werte. Insbesondere durch das Float Format einiger Werte sind nicht alle Werte möglich. Trägt man bspw eine Ontime von 10000 ein wird dies erst einmal akzeptiert. Allerdings wird der Wert beim Schreiben umgerechnet in den nächstmöglichen (welcher 9600 ist). Bei der Prüfung der Template Anwendung wird der Unterschied angemerkt. Am Einfachsten wird nun das Template angepasst und alles ist gut.<br><br />
<br><br />
Nun tpl_params. Diese muss man anstelle des Registerwerts einsetzen. Hat man <br><br />
tpl_params timeOn:rampTime<br><br />
definiert setzt man in das Register OnTime den Wert timeOn ein. Und eben das rampenregiste den Wert rampTime<br />
<br />
=Getting started=<br />
Was muss man also tun? Wenn man noch nichts eingerichtet hat:<br />
define hm HMinfo<br />
attr hm autoArchive 1<br />
attr hm autoLoadArchive 1_load<br />
attr hm configFilename regConfig.cfg<br />
define ht HMtemplate<br />
<br />
==Template erstellen und bearbeiten==<br />
===Template aus Device===<br />
Aufgabe ist es, aus einem existierenden Device ein Template zu erstellen. Wir haben <br />
device ''myDev''<br />
Channel ''myChan''<br />
Channel gepeert mit ''myChanPeer''.<br><br />
Der Kanal ist ein Schalter und wir wollen einen Parameter im Template nutzen: Die Anschaltzeit soll bei der Nutzung des Templates variabel eingesetzt werden. Wir werden also den Parameter ''timeOn'' nutzen. Das Template soll ''my1stTmpl'' genannt werden. Weiter soll das gesamte Verhalten des ''myChanPeer'' definiert werden, also short UND long. <br />
set ht define my1stTmpl<br />
attr ht tpl_param timeOn # name des Parameters - hier nur einer<br />
attr ht tpl_description "mein erstes Template"<br />
attr ht tpl_type peer-both<br />
<refresh browser> # select liste der attribute wird neu eingelesen<br />
attr ht tpl_source myChan<br />
<refresh browser> # select liste der attribute wird neu eingelesen<br />
attr ht tpl_peer myChanPeer<br />
<refresh browser> # select liste der attribute wird neu eingelesen<br />
attr ht Reg_shOnTime timeOn # setzen des parameters<br />
<br />
nun können weitere Register verändert werde. <br />
Sinnvoll ist es, unnötige Register aus dem Template zu entfernen. Dies sind in diesem Fall bspw. alle Ct register. Das Attribut des Registers wird einfach gelöscht. <br />
set ht save<br />
set ht dismiss<br />
===Template Varianten speichern===<br />
Ist man beim Erstellen von Templates kann man mti saveAs das Template als neues unter einem anderen Namen sichern. <br />
===Template editieren===<br />
Mit Edit kann man die Werte der Register ändern oder vorhandene Register aus dem Template entfernen. Ein Hinzufügen von Registern wird nicht unterstützt. Hier fehlt die Referenz um anzubieten, was möglich ist.<br />
===Template kopieren===<br />
Dies wird ebenfalls mit edit erreicht. Das Template wird mit saveAs unter einem neuen Namen gespeichert. <br />
<br />
==Template einem Kanal zuweisen==<br />
Jetzt haben wir ein Template welches long und short eines Kanals kontrollieren soll. Dies wollen wir jetzt anwenden auf unsere Kanal/Peer Kompinationen "sw1/peer1", "sw1/peer2", "sw2/peer1" und "sw2/peer3". Für alle benötigen wir unterschiedliche Abschaltzeiten (warum? eure Sache). <br />
set ht select my1stTmpl<br />
attr ht entity sw1<br />
<refresh browser><br />
attr ht ePeer peer1<br />
attr ht tpl_param_timeOn 30<br />
set ht apply<br />
attr ht ePeer peer2<br />
attr ht tpl_param_timeOn 180<br />
set ht apply<br />
<br />
attr ht entity sw2<br />
<refresh browser><br />
attr ht ePeer peer1<br />
attr ht tpl_param_timeOn 70<br />
set ht apply<br />
<br />
attr ht ePeer peer3<br />
attr ht tpl_param_timeOn 1000<br />
set ht apply<br />
<br />
set ht dismiss<br />
Die Register der Entities werden passend in das Device geschrieben. <br />
==Template editieren==<br />
Nun soll das Template grundsätzlich modfiziert werden. <br />
<br />
set ht edit my1stTmpl<br />
attr ht Reg_<name> <value><br />
attr ht Reg_<name2> <value2><br />
attr ht Reg_<name3> <value3><br />
set ht save<br />
==Template kopieren und editieren==<br />
Nun soll das Template grundsätzlich modfiziert werden. <br />
<br />
set ht select my1stTmpl<br />
attr ht Reg_<name> <value><br />
attr ht Reg_<name2> <value2><br />
attr ht Reg_<name3> <value3><br />
set ht saveAs my2ndTmpl<br />
==Template weitergeben==<br />
Will man Templates weitergeben geht das mit<br />
get ht my1stTmpl<br />
Das Kommando kann dann direkt in die Kommandozeile kopiert werden und das Template ist definiert.<br />
[[Kategorie:HomeMatic supportDevice]]<br />
[[Kategorie:HOWTOS]]</div>Martinp876http://wiki.fhem.de/w/index.php?title=HomeMatic_Templates&diff=23939HomeMatic Templates2017-12-30T10:52:56Z<p>Martinp876: </p>
<hr />
<div>{{Infobox Modul<br />
|ModPurpose=templates bedienen und verwalten<br />
|ModType=h<br />
|ModCmdRef=HMtemplate<br />
|ModForumArea=HomeMatic<br />
|ModTechName=98_HMtemplate.pm<br />
|ModOwner=martinp876 ({{Link2FU|251|martinp876}} / [[Benutzer Diskussion:Martinp876|Wiki]])<br />
}}<br />
Templates sind Vorlagen im Allgemeinen. Hier werden Vorlagen zur Programmierung der Register von HM Devices behandelt. <br />
= Warum Templates =<br />
Die Frage, warum man Register nicht einfach setzt sondern Templates nutzen sollte kommt immer wieder auf. Schliesslich sind wie alle Spezialisten...<br />
Die Wahrheit allerdings bildet das nicht ab. Den auch den Spezialisten sei angeraten, Templates zu nutzen. Ja, warum den, was bieten Templates? Hierzu muss man verstehen wir FHEM, HM, Devices, Kanäle und peers zusammen hängen. <br />
<br />
Wie schon im Einsteigerdoc beschrieben hat ein HM Device remanente Register welche von FHEM gesetzt werden können und die Funktions- und Arbeitsweise definieren. FHEM selbst hat bestenfalls eine Kopie dieser Daten.<br />
;soll-Register Verwaltung<br />
:Da FHEM nur eine Kopie der Registerwerte verwaltet lebt man erst einmal in einer fragilen Welt. Registerwerte können sich ändern durch:<br />
* Reset des Device<br />
* Batteriefehler<br />
* inkorrektes Schreiben und Übertragungsfehler<br />
* Austausch eines Device<br />
:Nach Lesen der Device Register hat FHEM einen neue Kopie - dies muss aber nicht den Wunschregistern entsprechen. Templates sind eine Ansammlung von Wunschregister. Somit können unterschiedliche Mechanismen genutzt werden, das System zu verwalten, prüfen und korrigieren.<br />
;Funktionen für Einsteiger<br />
:Nicht-Experten sollten primär Templates nutzen - um Funktionen zu realisieren, und wenn gewünscht, Experten zu werden. Templares kann man einfach austauschen und dann anwenden.<br />
;Verwalten von Funktionen statt Registern<br />
:Als Experten kann man sicher die Register zeilsicher setzen. Wirklich? Wenn man sich eine clevere Lösung ausgedacht hat und sie reproduzieren will kann man einfach noch einmal nachdenken, nachlesen,... und schon hat man es wieder. Oder man hat ein Template definiert das man einfach nutzt.<br />
; Lernen aus Templates<br />
:Templates sind nicht verschlüsselt. Hat oder bekommt man ein Template kann man die dort gesetzten Register einfach einsehen - und wenn man will verstehen was gemacht wurde. <br />
;Globales Anpassen aller Devices <br />
: Hat man festgestellt, dass eine Funktion sub-optimal ist kann man das Temlate ändern und diese Änderungen allen Devices zu gute kommen lassen. Auf einmal. <br />
<br />
= Grundsätzliches zum Template =<br />
Templates (hier) ist nun also eine Sammlung von Registern welche in einem Device gesetzt werden können. <br />
<br />
== Template Granularität ==<br />
Man kann nicht alle Register eines Device in einem Template abbilden. Das wäre technisch komplex und macht auch von der Anwendung her keinen Sinn. <br />
<br />
*Aus Sicht der Funktion sollte man Templates nach deren Funktionen zusammenfassen.<br />
*Aus Sicht des Devices sollte man Templates nach der Struktur des Device zusammenstellen.<br />
*Die Implementierung erlaubt es, templates für jedes Register einzeln zu erstellen.<br><br />
*Weniger Templates erhöhen die Übersichtlichkeit<br />
Die technische Lösung legt folgenden Templates nahe<br />
#Alle Register eines Kanals oder Device - ausgenommen peer abhängige Register<br />
#Alle Register eines Kanals eines Peers für short oder long<br />
#Alle Register eines Kanals eines Peers nur für short<br />
#Alle Register eines Kanals eines Peers nur für long<br />
Ob man 2. oder die Kombination aus 3. und 4. nutzt ist Geschmackssache. <br><br />
Ein typischer Einsatz sind Schaltern und Dimmer bei welchen man die Aktionen der Peers festlegen will.<br />
;usecase Template Granularität Dimmer<br />
:Mit Peer1 soll bei short ein und bei long ausgeschaltet werden<br />
:Mit Peer2 soll bei short getoggelt und bei long nicht geschaltet werden<br />
:Mit Peer3 soll bei short nicht geschaltet und bei long getoggelt werden<br />
:Mit Peer4 ist ein MotionDetector welcher bei short und einer bestimmten Helligkeit einschaltet, timed. Allerdings sollen Aktionen der anderen Peers oder der Zentrale das Licht dauer-ein schalten.<br />
<br />
== Template Flexibilität ==<br />
Templates sind starr... und können parametriert werden. Also semistarr. Was jetzt? Nun man kann Templates mir bis zu 9 Parametern versehen. Sinnvoll sind wohl eher bis zu 3. <br><br />
Beispiele sind:<br />
*Treppenhausschaltern - mit einem Parameter kann man Einschaltdauer je Instanziierung festlegen. Sinnvoll könnte eine Treppenhausschaltung generell sein, nicht nur im Treppenhaus. Man kann generell alle Lichter nach ein paar Stunden ausschalten.<br />
*Heizungstemplate - Boosttime: Man kann allen RTs das gleiche Template geben - allerdings kann man z.B. die Boosttime indivituell einstellen. <br />
*MotionDetector Clients: Bei den Peers des Modtion detector (also den Schaltern) stellt man ein, dann diese reagieren sollen und wie lange diese brennen sollen. <br />
<br />
== Template Verwaltung==<br />
Templates werden zusammen mit Registern verwaltet. Man benötigt demnach HMinfo. Sowohl die Template definition alsauch die Template Zuweisung werden im File zusammen mit den gelesenen Registern gesichert. Nach einem Einlesen dieses Files werden auch die Templates und deren Zuordnung neu erstellt.<br />
<br />
== Template Editieren==<br />
Die aktuell einfachste Möglichkeit ein Template zu modifizieren ist, HMtemplate zu nutzen. HMtemplate ist ein Editor. Für den Betrieb wird es nicht genutzt. <br />
<br />
<br />
=Das eigenen Konzept=<br />
Für die Verknüpfung von HM Entities muss man 2 Ebenen unterschieden, Architektur und Verhalten.<br />
==Architektur==<br />
Beim Erstellen der Architektur legt man fest, welche Entities untereinander verknüpft werden. Dies geschieht durch peeren. Templates unterstützen nicht die Architektur. Es ist demnach notwendig die Peerings durchzuführen bevor an ein Template darauf anwenden kann. <br />
==Verhalten==<br />
Hier kommen die Templates zum Tragen. Mit Templates definiert man die Register der Entities und somit das Verhalten und die Reaktion der Entites bspw auf Trigger von Sensoren.<br />
===Welchen templateTyp brauche ich===<br />
Wie in Granularität beschrieben kann man insbesondere beim Peerverhalten templates für ''short'', ''long'' oder ''both'' ertellen. Nutzt man short/long braucht man weniger Templates (Basics sind on/off/ignore/toggle) muss allerdings mehr Templates zuweisen, als Reaktion auf short UND long.<br><br />
Bei both braucht man mehr Templates (OnOff/OnIgnore/OffIgnore/IgnoreOff/ToggleIgnore/...) braucht aber nur die Hälfte der Zuweisungen zu den realen Entities. <br />
<br />
===Welche Parameter muss ich einstellen===<br />
Bei der Erstellung eine Templates werden dessen Parameter durch Attribute vorgegeben. Durch '''set save''' wird dann das Template schlussendlich definiert. Folgende Parameter/Attribute werden genutzt:<br />
*'''tpl_description''': ist ein Freitext welcher beschreiben soll, was das Template macht und wie es parametriert wird<br />
*'''tpl_params''': hier werden evtl Parameter definiert mit welchen die Instanziierung des Templates angepasst werden kann. Bspw. könnte die Einschaltzeit variable gestalltet werden. Bei einem Dimmer könnt man den Level und die Rampe eingeben, also 2 Parameter. Man vergibt also, ":" getrennt, eine Liste von Paramtern. Die Namen sind frei wählbar. <br><br />
:''timeOn:ramp'' würde 2 Parameter definieren, welche später in den Registern genutzt werden können<br />
*'''tpl_type''': definiert den Typ. Diesen muss man zuerst festlegen. Es konnte ''peer-Short'',''peer-Long'',''peer-Both'' oder ''basic'' sein. Nach der Auswahl des Typs kann man die Entity (source) wählen. Es alle Entities angeboten, welche entsprechende Registersätze zu Verfügung stellen.<br />
*'''tpl_source''': legt bei der Definition eines Templates fest, von welcher Entity die Register für die Vorlage genutzt werden sollen. Ein Browser-Refresh könnte notwendig sein um die Auswahlliste upzudaten<br />
*'''tpl_peer''': muss man auswählen, so man einen "peer" typ gewählt hat. An Browser-refresh denken. <br />
*'''Reg_xxx''': An Browser-refresh denken. Hat man nun die Vorlage ausgewählt und den Refresh gemach werden nun Register als Attribute angeboten. <br><br />
:Zunächst sollte man Registerattribute löschen, welche man für das Template nicht benötigt. Achtung: eine Option gelöschte Registerattribute wieder nachzutragen ist nicht vorgesehen. So schlimm ist es allerdings nicht - man muss halt noch einmal alle Lesen und von Vorne löschen. <br><br />
:Sinnvoll kann es sein, die Condition Table Register komplett zu eliminieren wenn man Reaktionen auf Taster definieren will. Will man ''ignore'' definieren, also keine Reaktion bspw auf ''long'', dann kann man alles löschen bis auf ActionType usw. <br><br />
:Sinnvoll ist es, nur notwendige Register der Funktion zu bearbeiten, da sonst die Anwendung des Templates eingeschränkt wird. <br><br />
:Es sollten aber alle Register der Funktion enthalten sein, da die Prüfung auch nur diese berücksichtigt und bei einem Umprogrammieren nicht klar ist, was vorher in einem Register gestanden ist.<br />
===Registerattribute setzen===<br />
Nun das eigentliche - das setzen der Registerinhalte. Dies wird begrenzt unterstützt. Sollte das Register durch ''literals'' definiert werden erscheint beim Setzen eine drop-down Liste mit den Optionen. <br><br />
Nicht unterstützt wird das Setzen von Werten. Es gibt aktuell keine Option, hier eine Hilfe einzublenden. Die Wertebereiche sind dem regList der Entity zu entnehmen. <br><br />
Eine weitere Besonderheit ist die Granularität der Werte. Insbesondere durch das Float Format einiger Werte sind nicht alle Werte möglich. Trägt man bspw eine Ontime von 10000 ein wird dies erst einmal akzeptiert. Allerdings wird der Wert beim Schreiben umgerechnet in den nächstmöglichen (welcher 9600 ist). Bei der Prüfung der Template Anwendung wird der Unterschied angemerkt. Am Einfachsten wird nun das Template angepasst und alles ist gut.<br><br />
<br><br />
Nun tpl_params. Diese muss man anstelle des Registerwerts einsetzen. Hat man <br><br />
tpl_params timeOn:rampTime<br><br />
definiert setzt man in das Register OnTime den Wert timeOn ein. Und eben das rampenregiste den Wert rampTime<br />
<br />
=Getting started=<br />
Was muss man also tun? Wenn man noch nichts eingerichtet hat:<br />
define hm HMinfo<br />
attr hm autoArchive 1<br />
attr hm autoLoadArchive 1_load<br />
attr hm configFilename regConfig.cfg<br />
define ht HMtemplate<br />
<br />
==Template aus Device erstellen==<br />
Aufgabe ist es, aus einem existierenden Device ein Template zu erstellen. Wir haben <br />
device ''myDev''<br />
Channel ''myChan''<br />
Channel gepeert mit ''myChanPeer''.<br><br />
Der Kanal ist ein Schalter und wir wollen einen Parameter im Template nutzen: Die Anschaltzeit soll bei der Nutzung des Templates variabel eingesetzt werden. Wir werden also den Parameter ''timeOn'' nutzen. Das Template soll ''my1stTmpl'' genannt werden. Weiter soll das gesamte Verhalten des ''myChanPeer'' definiert werden, also short UND long. <br />
set ht define my1stTmpl<br />
attr ht tpl_param timeOn # name des Parameters - hier nur einer<br />
attr ht tpl_description "mein erstes Template"<br />
attr ht tpl_type peer-both<br />
<refresh browser> # select liste der attribute wird neu eingelesen<br />
attr ht tpl_source myChan<br />
<refresh browser> # select liste der attribute wird neu eingelesen<br />
attr ht tpl_peer myChanPeer<br />
<refresh browser> # select liste der attribute wird neu eingelesen<br />
attr ht Reg_shOnTime timeOn # setzen des parameters<br />
<br />
nun können weitere Register verändert werde. <br />
Sinnvoll ist es, unnötige Register aus dem Template zu entfernen. Dies sind in diesem Fall bspw. alle Ct register. Das Attribut des Registers wird einfach gelöscht. <br />
set ht save<br />
set ht dismiss<br />
==Template einem Kanal zuweisen==<br />
Jetzt haben wir ein Template welches long und short eines Kanals kontrollieren soll. Dies wollen wir jetzt anwenden auf unsere Kanal/Peer Kompinationen "sw1/peer1", "sw1/peer2", "sw2/peer1" und "sw2/peer3". Für alle benötigen wir unterschiedliche Abschaltzeiten (warum? eure Sache). <br />
set ht select my1stTmpl<br />
attr ht entity sw1<br />
<refresh browser><br />
attr ht ePeer peer1<br />
attr ht tpl_param_timeOn 30<br />
set ht apply<br />
attr ht ePeer peer2<br />
attr ht tpl_param_timeOn 180<br />
set ht apply<br />
<br />
attr ht entity sw2<br />
<refresh browser><br />
attr ht ePeer peer1<br />
attr ht tpl_param_timeOn 70<br />
set ht apply<br />
<br />
attr ht ePeer peer3<br />
attr ht tpl_param_timeOn 1000<br />
set ht apply<br />
<br />
set ht dismiss<br />
Die Register der Entities werden passend in das Device geschrieben. <br />
==Template editieren==<br />
Nun soll das Template grundsätzlich modfiziert werden. <br />
<br />
set ht edit my1stTmpl<br />
attr ht Reg_<name> <value><br />
attr ht Reg_<name2> <value2><br />
attr ht Reg_<name3> <value3><br />
set ht save<br />
==Template kopieren und editieren==<br />
Nun soll das Template grundsätzlich modfiziert werden. <br />
<br />
set ht select my1stTmpl<br />
attr ht Reg_<name> <value><br />
attr ht Reg_<name2> <value2><br />
attr ht Reg_<name3> <value3><br />
set ht saveAs my2ndTmpl<br />
==Template weitergeben==<br />
Will man Templates weitergeben geht das mit<br />
get ht my1stTmpl<br />
Das Kommando kann dann direkt in die Kommandozeile kopiert werden und das Template ist definiert.<br />
[[Kategorie:HomeMatic supportDevice]]<br />
[[Kategorie:HOWTOS]]</div>Martinp876http://wiki.fhem.de/w/index.php?title=HomeMatic_Templates&diff=23938HomeMatic Templates2017-12-30T10:31:22Z<p>Martinp876: </p>
<hr />
<div>{{Infobox Modul<br />
|ModPurpose=templates bedienen und verwalten<br />
|ModType=h<br />
|ModCmdRef=HMtemplate<br />
|ModForumArea=HomeMatic<br />
|ModTechName=98_HMtemplate.pm<br />
|ModOwner=martinp876 ({{Link2FU|251|martinp876}} / [[Benutzer Diskussion:Martinp876|Wiki]])<br />
}}<br />
Templates sind Vorlagen im Allgemeinen. Hier werden Vorlagen zur Programmierung der Register von HM Devices behandelt. <br />
= Warum Templates =<br />
Die Frage, warum man Register nicht einfach setzt sondern Templates nutzen sollte kommt immer wieder auf. Schliesslich sind wie alle Spezialisten...<br />
Die Wahrheit allerdings bildet das nicht ab. Den auch den Spezialisten sei angeraten, Templates zu nutzen. Ja, warum den, was bieten Templates? Hierzu muss man verstehen wir FHEM, HM, Devices, Kanäle und peers zusammen hängen. <br />
<br />
Wie schon im Einsteigerdoc beschrieben hat ein HM Device remanente Register welche von FHEM gesetzt werden können und die Funktions- und Arbeitsweise definieren. FHEM selbst hat bestenfalls eine Kopie dieser Daten.<br />
;soll-Register Verwaltung<br />
:Da FHEM nur eine Kopie der Registerwerte verwaltet lebt man erst einmal in einer fragilen Welt. Registerwerte können sich ändern durch:<br />
* Reset des Device<br />
* Batteriefehler<br />
* inkorrektes Schreiben und Übertragungsfehler<br />
* Austausch eines Device<br />
:Nach Lesen der Device Register hat FHEM einen neue Kopie - dies muss aber nicht den Wunschregistern entsprechen. Templates sind eine Ansammlung von Wunschregister. Somit können unterschiedliche Mechanismen genutzt werden, das System zu verwalten, prüfen und korrigieren.<br />
;Funktionen für Einsteiger<br />
:Nicht-Experten sollten primär Templates nutzen - um Funktionen zu realisieren, und wenn gewünscht, Experten zu werden. Templares kann man einfach austauschen und dann anwenden.<br />
;Verwalten von Funktionen statt Registern<br />
:Als Experten kann man sicher die Register zeilsicher setzen. Wirklich? Wenn man sich eine clevere Lösung ausgedacht hat und sie reproduzieren will kann man einfach noch einmal nachdenken, nachlesen,... und schon hat man es wieder. Oder man hat ein Template definiert das man einfach nutzt.<br />
; Lernen aus Templates<br />
:Templates sind nicht verschlüsselt. Hat oder bekommt man ein Template kann man die dort gesetzten Register einfach einsehen - und wenn man will verstehen was gemacht wurde. <br />
;Globales Anpassen aller Devices <br />
: Hat man festgestellt, dass eine Funktion sub-optimal ist kann man das Temlate ändern und diese Änderungen allen Devices zu gute kommen lassen. Auf einmal. <br />
<br />
= Grundsätzliches zum Template =<br />
Templates (hier) ist nun also eine Sammlung von Registern welche in einem Device gesetzt werden können. <br />
<br />
== Template Granularität ==<br />
Man kann nicht alle Register eines Device in einem Template abbilden. Das wäre technisch komplex und macht auch von der Anwendung her keinen Sinn. <br />
<br />
*Aus Sicht der Funktion sollte man Templates nach deren Funktionen zusammenfassen.<br />
*Aus Sicht des Devices sollte man Templates nach der Struktur des Device zusammenstellen.<br />
*Die Implementierung erlaubt es, templates für jedes Register einzeln zu erstellen.<br><br />
*Weniger Templates erhöhen die Übersichtlichkeit<br />
Die technische Lösung legt folgenden Templates nahe<br />
#Alle Register eines Kanals oder Device - ausgenommen peer abhängige Register<br />
#Alle Register eines Kanals eines Peers für short oder long<br />
#Alle Register eines Kanals eines Peers nur für short<br />
#Alle Register eines Kanals eines Peers nur für long<br />
Ob man 2. oder die Kombination aus 3. und 4. nutzt ist Geschmackssache. <br><br />
Ein typischer Einsatz sind Schaltern und Dimmer bei welchen man die Aktionen der Peers festlegen will.<br />
;usecase Template Granularität Dimmer<br />
:Mit Peer1 soll bei short ein und bei long ausgeschaltet werden<br />
:Mit Peer2 soll bei short getoggelt und bei long nicht geschaltet werden<br />
:Mit Peer3 soll bei short nicht geschaltet und bei long getoggelt werden<br />
:Mit Peer4 ist ein MotionDetector welcher bei short und einer bestimmten Helligkeit einschaltet, timed. Allerdings sollen Aktionen der anderen Peers oder der Zentrale das Licht dauer-ein schalten.<br />
<br />
== Template Flexibilität ==<br />
Templates sind starr... und können parametriert werden. Also semistarr. Was jetzt? Nun man kann Templates mir bis zu 9 Parametern versehen. Sinnvoll sind wohl eher bis zu 3. <br><br />
Beispiele sind:<br />
*Treppenhausschaltern - mit einem Parameter kann man Einschaltdauer je Instanziierung festlegen. Sinnvoll könnte eine Treppenhausschaltung generell sein, nicht nur im Treppenhaus. Man kann generell alle Lichter nach ein paar Stunden ausschalten.<br />
*Heizungstemplate - Boosttime: Man kann allen RTs das gleiche Template geben - allerdings kann man z.B. die Boosttime indivituell einstellen. <br />
*MotionDetector Clients: Bei den Peers des Modtion detector (also den Schaltern) stellt man ein, dann diese reagieren sollen und wie lange diese brennen sollen. <br />
<br />
== Template Verwaltung==<br />
Templates werden zusammen mit Registern verwaltet. Man benötigt demnach HMinfo. Sowohl die Template definition alsauch die Template Zuweisung werden im File zusammen mit den gelesenen Registern gesichert. Nach einem Einlesen dieses Files werden auch die Templates und deren Zuordnung neu erstellt.<br />
<br />
== Template Editieren==<br />
Die aktuell einfachste Möglichkeit ein Template zu modifizieren ist, HMtemplate zu nutzen. HMtemplate ist ein Editor. Für den Betrieb wird es nicht genutzt. <br />
<br />
<br />
=Das eigenen Konzept=<br />
Für die Verknüpfung von HM Entities muss man 2 Ebenen unterschieden, Architektur und Verhalten.<br />
==Architektur==<br />
Beim Erstellen der Architektur legt man fest, welche Entities untereinander verknüpft werden. Dies geschieht durch peeren. Templates unterstützen nicht die Architektur. Es ist demnach notwendig die Peerings durchzuführen bevor an ein Template darauf anwenden kann. <br />
==Verhalten==<br />
Hier kommen die Templates zum Tragen. Mit Templates definiert man die Register der Entities und somit das Verhalten und die Reaktion der Entites bspw auf Trigger von Sensoren.<br />
===Welchen templateTyp brauche ich===<br />
Wie in Granularität beschrieben kann man insbesondere beim Peerverhalten templates für ''short'', ''long'' oder ''both'' ertellen. Nutzt man short/long braucht man weniger Templates (Basics sind on/off/ignore/toggle) muss allerdings mehr Templates zuweisen, als Reaktion auf short UND long.<br><br />
Bei both braucht man mehr Templates (OnOff/OnIgnore/OffIgnore/IgnoreOff/ToggleIgnore/...) braucht aber nur die Hälfte der Zuweisungen zu den realen Entities. <br />
<br />
===Welche Parameter muss ich einstellen===<br />
Bei der Erstellung eine Templates werden dessen Parameter durch Attribute vorgegeben. Durch '''set save''' wird dann das Template schlussendlich definiert. Folgende Parameter/Attribute werden genutzt:<br />
*'''tpl_description''': ist ein Freitext welcher beschreiben soll, was das Template macht und wie es parametriert wird<br />
*'''tpl_params''': hier werden evtl Parameter definiert mit welchen die Instanziierung des Templates angepasst werden kann. Bspw. könnte die Einschaltzeit variable gestalltet werden. Bei einem Dimmer könnt man den Level und die Rampe eingeben, also 2 Parameter. Man vergibt also, ":" getrennt, eine Liste von Paramtern. Die Namen sind frei wählbar. <br><br />
:''timeOn:ramp'' würde 2 Parameter definieren, welche später in den Registern genutzt werden können<br />
*'''tpl_type''': definiert den Typ. Diesen muss man zuerst festlegen. Es konnte ''peer-Short'',''peer-Long'',''peer-Both'' oder ''basic'' sein. Nach der Auswahl des Typs kann man die Entity (source) wählen. Es alle Entities angeboten, welche entsprechende Registersätze zu Verfügung stellen.<br />
*'''tpl_source''': legt bei der Definition eines Templates fest, von welcher Entity die Register für die Vorlage genutzt werden sollen. Ein Browser-Refresh könnte notwendig sein um die Auswahlliste upzudaten<br />
*'''tpl_peer''': muss man auswählen, so man einen "peer" typ gewählt hat. An Browser-refresh denken. <br />
*'''Reg_xxx''': An Browser-refresh denken. Hat man nun die Vorlage ausgewählt und den Refresh gemach werden nun Register als Attribute angeboten. <br><br />
:Zunächst sollte man Registerattribute löschen, welche man für das Template nicht benötigt. Achtung: eine Option gelöschte Registerattribute wieder nachzutragen ist nicht vorgesehen. So schlimm ist es allerdings nicht - man muss halt noch einmal alle Lesen und von Vorne löschen. <br><br />
:Sinnvoll kann es sein, die Condition Table Register komplett zu eliminieren wenn man Reaktionen auf Taster definieren will. Will man ''ignore'' definieren, also keine Reaktion bspw auf ''long'', dann kann man alles löschen bis auf ActionType usw. <br><br />
:Sinnvoll ist es, nur notwendige Register der Funktion zu bearbeiten, da sonst die Anwendung des Templates eingeschränkt wird. <br><br />
:Es sollten aber alle Register der Funktion enthalten sein, da die Prüfung auch nur diese berücksichtigt und bei einem Umprogrammieren nicht klar ist, was vorher in einem Register gestanden ist.<br />
<br />
=Getting started=<br />
Was muss man also tun? Wenn man noch nichts eingerichtet hat:<br />
define hm HMinfo<br />
attr hm autoArchive 1<br />
attr hm autoLoadArchive 1_load<br />
attr hm configFilename regConfig.cfg<br />
define ht HMtemplate<br />
<br />
==Template aus Device erstellen==<br />
Aufgabe ist es, aus einem existierenden Device ein Template zu erstellen. Wir haben <br />
device ''myDev''<br />
Channel ''myChan''<br />
Channel gepeert mit ''myChanPeer''.<br><br />
Der Kanal ist ein Schalter und wir wollen einen Parameter im Template nutzen: Die Anschaltzeit soll bei der Nutzung des Templates variabel eingesetzt werden. Wir werden also den Parameter ''timeOn'' nutzen. Das Template soll ''my1stTmpl'' genannt werden. Weiter soll das gesamte Verhalten des ''myChanPeer'' definiert werden, also short UND long. <br />
set ht define my1stTmpl<br />
attr ht tpl_param timeOn # name des Parameters - hier nur einer<br />
attr ht tpl_description "mein erstes Template"<br />
attr ht tpl_type peer-both<br />
<refresh browser> # select liste der attribute wird neu eingelesen<br />
attr ht tpl_source myChan<br />
<refresh browser> # select liste der attribute wird neu eingelesen<br />
attr ht tpl_peer myChanPeer<br />
<refresh browser> # select liste der attribute wird neu eingelesen<br />
attr ht Reg_shOnTime timeOn # setzen des parameters<br />
<br />
nun können weitere Register verändert werde. <br />
Sinnvoll ist es, unnötige Register aus dem Template zu entfernen. Dies sind in diesem Fall bspw. alle Ct register. Das Attribut des Registers wird einfach gelöscht. <br />
set ht save<br />
set ht dismiss<br />
==Template einem Kanal zuweisen==<br />
Jetzt haben wir ein Template welches long und short eines Kanals kontrollieren soll. Dies wollen wir jetzt anwenden auf unsere Kanal/Peer Kompinationen "sw1/peer1", "sw1/peer2", "sw2/peer1" und "sw2/peer3". Für alle benötigen wir unterschiedliche Abschaltzeiten (warum? eure Sache). <br />
set ht select my1stTmpl<br />
attr ht entity sw1<br />
<refresh browser><br />
attr ht ePeer peer1<br />
attr ht tpl_param_timeOn 30<br />
set ht apply<br />
attr ht ePeer peer2<br />
attr ht tpl_param_timeOn 180<br />
set ht apply<br />
<br />
attr ht entity sw2<br />
<refresh browser><br />
attr ht ePeer peer1<br />
attr ht tpl_param_timeOn 70<br />
set ht apply<br />
<br />
attr ht ePeer peer3<br />
attr ht tpl_param_timeOn 1000<br />
set ht apply<br />
<br />
set ht dismiss<br />
Die Register der Entities werden passend in das Device geschrieben. <br />
==Template editieren==<br />
Nun soll das Template grundsätzlich modfiziert werden. <br />
<br />
set ht edit my1stTmpl<br />
attr ht Reg_<name> <value><br />
attr ht Reg_<name2> <value2><br />
attr ht Reg_<name3> <value3><br />
set ht save<br />
==Template kopieren und editieren==<br />
Nun soll das Template grundsätzlich modfiziert werden. <br />
<br />
set ht select my1stTmpl<br />
attr ht Reg_<name> <value><br />
attr ht Reg_<name2> <value2><br />
attr ht Reg_<name3> <value3><br />
set ht saveAs my2ndTmpl<br />
==Template weitergeben==<br />
Will man Templates weitergeben geht das mit<br />
get ht my1stTmpl<br />
Das Kommando kann dann direkt in die Kommandozeile kopiert werden und das Template ist definiert.<br />
[[Kategorie:HomeMatic supportDevice]]<br />
[[Kategorie:HOWTOS]]</div>Martinp876http://wiki.fhem.de/w/index.php?title=HomeMatic_Templates&diff=23937HomeMatic Templates2017-12-30T10:23:31Z<p>Martinp876: </p>
<hr />
<div>{{Infobox Modul<br />
|ModPurpose=templates bedienen und verwalten<br />
|ModType=h<br />
|ModCmdRef=HMtemplate<br />
|ModForumArea=HomeMatic<br />
|ModTechName=98_HMtemplate.pm<br />
|ModOwner=martinp876 ({{Link2FU|251|martinp876}} / [[Benutzer Diskussion:Martinp876|Wiki]])<br />
}}<br />
Templates sind Vorlagen im Allgemeinen. Hier werden Vorlagen zur Programmierung der Register von HM Devices behandelt. <br />
= Warum Templates =<br />
Die Frage, warum man Register nicht einfach setzt sondern Templates nutzen sollte kommt immer wieder auf. Schliesslich sind wie alle Spezialisten...<br />
Die Wahrheit allerdings bildet das nicht ab. Den auch den Spezialisten sei angeraten, Templates zu nutzen. Ja, warum den, was bieten Templates? Hierzu muss man verstehen wir FHEM, HM, Devices, Kanäle und peers zusammen hängen. <br />
<br />
Wie schon im Einsteigerdoc beschrieben hat ein HM Device remanente Register welche von FHEM gesetzt werden können und die Funktions- und Arbeitsweise definieren. FHEM selbst hat bestenfalls eine Kopie dieser Daten.<br />
;soll-Register Verwaltung<br />
:Da FHEM nur eine Kopie der Registerwerte verwaltet lebt man erst einmal in einer fragilen Welt. Registerwerte können sich ändern durch:<br />
* Reset des Device<br />
* Batteriefehler<br />
* inkorrektes Schreiben und Übertragungsfehler<br />
* Austausch eines Device<br />
:Nach Lesen der Device Register hat FHEM einen neue Kopie - dies muss aber nicht den Wunschregistern entsprechen. Templates sind eine Ansammlung von Wunschregister. Somit können unterschiedliche Mechanismen genutzt werden, das System zu verwalten, prüfen und korrigieren.<br />
;Funktionen für Einsteiger<br />
:Nicht-Experten sollten primär Templates nutzen - um Funktionen zu realisieren, und wenn gewünscht, Experten zu werden. Templares kann man einfach austauschen und dann anwenden.<br />
;Verwalten von Funktionen statt Registern<br />
:Als Experten kann man sicher die Register zeilsicher setzen. Wirklich? Wenn man sich eine clevere Lösung ausgedacht hat und sie reproduzieren will kann man einfach noch einmal nachdenken, nachlesen,... und schon hat man es wieder. Oder man hat ein Template definiert das man einfach nutzt.<br />
; Lernen aus Templates<br />
:Templates sind nicht verschlüsselt. Hat oder bekommt man ein Template kann man die dort gesetzten Register einfach einsehen - und wenn man will verstehen was gemacht wurde. <br />
;Globales Anpassen aller Devices <br />
: Hat man festgestellt, dass eine Funktion sub-optimal ist kann man das Temlate ändern und diese Änderungen allen Devices zu gute kommen lassen. Auf einmal. <br />
<br />
= Grundsätzliches zum Template =<br />
Templates (hier) ist nun also eine Sammlung von Registern welche in einem Device gesetzt werden können. <br />
<br />
== Template Granularität ==<br />
Man kann nicht alle Register eines Device in einem Template abbilden. Das wäre technisch komplex und macht auch von der Anwendung her keinen Sinn. <br />
<br />
*Aus Sicht der Funktion sollte man Templates nach deren Funktionen zusammenfassen.<br />
*Aus Sicht des Devices sollte man Templates nach der Struktur des Device zusammenstellen.<br />
*Die Implementierung erlaubt es, templates für jedes Register einzeln zu erstellen.<br><br />
*Weniger Templates erhöhen die Übersichtlichkeit<br />
Die technische Lösung legt folgenden Templates nahe<br />
#Alle Register eines Kanals oder Device - ausgenommen peer abhängige Register<br />
#Alle Register eines Kanals eines Peers für short oder long<br />
#Alle Register eines Kanals eines Peers nur für short<br />
#Alle Register eines Kanals eines Peers nur für long<br />
Ob man 2. oder die Kombination aus 3. und 4. nutzt ist Geschmackssache. <br><br />
Ein typischer Einsatz sind Schaltern und Dimmer bei welchen man die Aktionen der Peers festlegen will.<br />
;usecase Template Granularität Dimmer<br />
:Mit Peer1 soll bei short ein und bei long ausgeschaltet werden<br />
:Mit Peer2 soll bei short getoggelt und bei long nicht geschaltet werden<br />
:Mit Peer3 soll bei short nicht geschaltet und bei long getoggelt werden<br />
:Mit Peer4 ist ein MotionDetector welcher bei short und einer bestimmten Helligkeit einschaltet, timed. Allerdings sollen Aktionen der anderen Peers oder der Zentrale das Licht dauer-ein schalten.<br />
<br />
== Template Flexibilität ==<br />
Templates sind starr... und können parametriert werden. Also semistarr. Was jetzt? Nun man kann Templates mir bis zu 9 Parametern versehen. Sinnvoll sind wohl eher bis zu 3. <br><br />
Beispiele sind:<br />
*Treppenhausschaltern - mit einem Parameter kann man Einschaltdauer je Instanziierung festlegen. Sinnvoll könnte eine Treppenhausschaltung generell sein, nicht nur im Treppenhaus. Man kann generell alle Lichter nach ein paar Stunden ausschalten.<br />
*Heizungstemplate - Boosttime: Man kann allen RTs das gleiche Template geben - allerdings kann man z.B. die Boosttime indivituell einstellen. <br />
*MotionDetector Clients: Bei den Peers des Modtion detector (also den Schaltern) stellt man ein, dann diese reagieren sollen und wie lange diese brennen sollen. <br />
<br />
== Template Verwaltung==<br />
Templates werden zusammen mit Registern verwaltet. Man benötigt demnach HMinfo. Sowohl die Template definition alsauch die Template Zuweisung werden im File zusammen mit den gelesenen Registern gesichert. Nach einem Einlesen dieses Files werden auch die Templates und deren Zuordnung neu erstellt.<br />
<br />
== Template Editieren==<br />
Die aktuell einfachste Möglichkeit ein Template zu modifizieren ist, HMtemplate zu nutzen. HMtemplate ist ein Editor. Für den Betrieb wird es nicht genutzt. <br />
<br />
<br />
=Das eigenen Konzept=<br />
Für die Verknüpfung von HM Entities muss man 2 Ebenen unterschieden, Architektur und Verhalten.<br />
==Architektur==<br />
Beim Erstellen der Architektur legt man fest, welche Entities untereinander verknüpft werden. Dies geschieht durch peeren. Templates unterstützen nicht die Architektur. Es ist demnach notwendig die Peerings durchzuführen bevor an ein Template darauf anwenden kann. <br />
==Verhalten==<br />
Hier kommen die Templates zum Tragen. Mit Templates definiert man die Register der Entities und somit das Verhalten und die Reaktion der Entites bspw auf Trigger von Sensoren.<br />
===Welchen templateTyp brauche ich===<br />
Wie in Granularität beschrieben kann man insbesondere beim Peerverhalten templates für ''short'', ''long'' oder ''both'' ertellen. Nutzt man short/long braucht man weniger Templates (Basics sind on/off/ignore/toggle) muss allerdings mehr Templates zuweisen, als Reaktion auf short UND long.<br><br />
Bei both braucht man mehr Templates (OnOff/OnIgnore/OffIgnore/IgnoreOff/ToggleIgnore/...) braucht aber nur die Hälfte der Zuweisungen zu den realen Entities. <br />
<br />
===Welche Parameter muss ich einstellen===<br />
Bei der Erstellung eine Templates werden dessen Parameter durch Attribute vorgegeben. Durch '''set save''' wird dann das Template schlussendlich definiert. Folgende Parameter/Attribute werden genutzt:<br />
*'''tpl_description''': ist ein Freitext welcher beschreiben soll, was das Template macht und wie es parametriert wird<br />
*'''tpl_params''': hier werden evtl Parameter definiert mit welchen die Instanziierung des Templates angepasst werden kann. Bspw. könnte die Einschaltzeit variable gestalltet werden. Bei einem Dimmer könnt man den Level und die Rampe eingeben, also 2 Parameter. Man vergibt also, ":" getrennt, eine Liste von Paramtern. Die Namen sind frei wählbar. <br><br />
timeOn:ramp würde 2 Parameter definieren, welche später in den Registern genutzt werden können<br />
*'''tpl_type''': definiert den Typ. Diesen muss man zuerst festlegen. Es konnte ''peer-Short'',''peer-Long'',''peer-Both'' oder ''basic'' sein. Nach der Auswahl des Typs kann man die Entity (source) wählen. Es alle Entities angeboten, welche entsprechende Registersätze zu Verfügung stellen.<br />
*'''tpl_source''': legt bei der Definition eines Templates fest, von welcher Entity die Register für die Vorlage genutzt werden sollen. Ein Browser-Refresh könnte notwendig sein um die Auswahlliste upzudaten<br />
*'''tpl_peer''': muss man auswählen, so man einen "peer" typ gewählt hat. An Browser-refresh denken. <br />
*'''Reg_xxx''': An Browser-refresh denken. Hat man nun die Vorlage ausgewählt und den Refresh gemach werden nun Register als Attribute angeboten. <br><br />
Zunächst sollte man Registerattribute löschen, welche man für das Template nicht benötigt. Achtung: eine Option gelöschte Registerattribute wieder nachzutragen ist nicht vorgesehen. So schlimm ist es allerdings nicht - man muss halt noch einmal alle Lesen und von Vorne löschen. <br><br />
xx<br />
<br />
=Getting started=<br />
Was muss man also tun? Wenn man noch nichts eingerichtet hat:<br />
define hm HMinfo<br />
attr hm autoArchive 1<br />
attr hm autoLoadArchive 1_load<br />
attr hm configFilename regConfig.cfg<br />
define ht HMtemplate<br />
<br />
==Template aus Device erstellen==<br />
Aufgabe ist es, aus einem existierenden Device ein Template zu erstellen. Wir haben <br />
device ''myDev''<br />
Channel ''myChan''<br />
Channel gepeert mit ''myChanPeer''.<br><br />
Der Kanal ist ein Schalter und wir wollen einen Parameter im Template nutzen: Die Anschaltzeit soll bei der Nutzung des Templates variabel eingesetzt werden. Wir werden also den Parameter ''timeOn'' nutzen. Das Template soll ''my1stTmpl'' genannt werden. Weiter soll das gesamte Verhalten des ''myChanPeer'' definiert werden, also short UND long. <br />
set ht define my1stTmpl<br />
attr ht tpl_param timeOn # name des Parameters - hier nur einer<br />
attr ht tpl_description "mein erstes Template"<br />
attr ht tpl_type peer-both<br />
<refresh browser> # select liste der attribute wird neu eingelesen<br />
attr ht tpl_source myChan<br />
<refresh browser> # select liste der attribute wird neu eingelesen<br />
attr ht tpl_peer myChanPeer<br />
<refresh browser> # select liste der attribute wird neu eingelesen<br />
attr ht Reg_shOnTime timeOn # setzen des parameters<br />
<br />
nun können weitere Register verändert werde. <br />
Sinnvoll ist es, unnötige Register aus dem Template zu entfernen. Dies sind in diesem Fall bspw. alle Ct register. Das Attribut des Registers wird einfach gelöscht. <br />
set ht save<br />
set ht dismiss<br />
==Template einem Kanal zuweisen==<br />
Jetzt haben wir ein Template welches long und short eines Kanals kontrollieren soll. Dies wollen wir jetzt anwenden auf unsere Kanal/Peer Kompinationen "sw1/peer1", "sw1/peer2", "sw2/peer1" und "sw2/peer3". Für alle benötigen wir unterschiedliche Abschaltzeiten (warum? eure Sache). <br />
set ht select my1stTmpl<br />
attr ht entity sw1<br />
<refresh browser><br />
attr ht ePeer peer1<br />
attr ht tpl_param_timeOn 30<br />
set ht apply<br />
attr ht ePeer peer2<br />
attr ht tpl_param_timeOn 180<br />
set ht apply<br />
<br />
attr ht entity sw2<br />
<refresh browser><br />
attr ht ePeer peer1<br />
attr ht tpl_param_timeOn 70<br />
set ht apply<br />
<br />
attr ht ePeer peer3<br />
attr ht tpl_param_timeOn 1000<br />
set ht apply<br />
<br />
set ht dismiss<br />
Die Register der Entities werden passend in das Device geschrieben. <br />
==Template editieren==<br />
Nun soll das Template grundsätzlich modfiziert werden. <br />
<br />
set ht edit my1stTmpl<br />
attr ht Reg_<name> <value><br />
attr ht Reg_<name2> <value2><br />
attr ht Reg_<name3> <value3><br />
set ht save<br />
==Template kopieren und editieren==<br />
Nun soll das Template grundsätzlich modfiziert werden. <br />
<br />
set ht select my1stTmpl<br />
attr ht Reg_<name> <value><br />
attr ht Reg_<name2> <value2><br />
attr ht Reg_<name3> <value3><br />
set ht saveAs my2ndTmpl<br />
==Template weitergeben==<br />
Will man Templates weitergeben geht das mit<br />
get ht my1stTmpl<br />
Das Kommando kann dann direkt in die Kommandozeile kopiert werden und das Template ist definiert.<br />
[[Kategorie:HomeMatic supportDevice]]<br />
[[Kategorie:HOWTOS]]</div>Martinp876http://wiki.fhem.de/w/index.php?title=HomeMatic_Templates&diff=23936HomeMatic Templates2017-12-30T10:18:05Z<p>Martinp876: </p>
<hr />
<div>{{Infobox Modul<br />
|ModPurpose=templates bedienen und verwalten<br />
|ModType=h<br />
|ModCmdRef=HMtemplate<br />
|ModForumArea=HomeMatic<br />
|ModTechName=98_HMtemplate.pm<br />
|ModOwner=martinp876 ({{Link2FU|251|martinp876}} / [[Benutzer Diskussion:Martinp876|Wiki]])<br />
}}<br />
Templates sind Vorlagen im Allgemeinen. Hier werden Vorlagen zur Programmierung der Register von HM Devices behandelt. <br />
= Warum Templates =<br />
Die Frage, warum man Register nicht einfach setzt sondern Templates nutzen sollte kommt immer wieder auf. Schliesslich sind wie alle Spezialisten...<br />
Die Wahrheit allerdings bildet das nicht ab. Den auch den Spezialisten sei angeraten, Templates zu nutzen. Ja, warum den, was bieten Templates? Hierzu muss man verstehen wir FHEM, HM, Devices, Kanäle und peers zusammen hängen. <br />
<br />
Wie schon im Einsteigerdoc beschrieben hat ein HM Device remanente Register welche von FHEM gesetzt werden können und die Funktions- und Arbeitsweise definieren. FHEM selbst hat bestenfalls eine Kopie dieser Daten.<br />
;soll-Register Verwaltung<br />
:Da FHEM nur eine Kopie der Registerwerte verwaltet lebt man erst einmal in einer fragilen Welt. Registerwerte können sich ändern durch:<br />
* Reset des Device<br />
* Batteriefehler<br />
* inkorrektes Schreiben und Übertragungsfehler<br />
* Austausch eines Device<br />
:Nach Lesen der Device Register hat FHEM einen neue Kopie - dies muss aber nicht den Wunschregistern entsprechen. Templates sind eine Ansammlung von Wunschregister. Somit können unterschiedliche Mechanismen genutzt werden, das System zu verwalten, prüfen und korrigieren.<br />
;Funktionen für Einsteiger<br />
:Nicht-Experten sollten primär Templates nutzen - um Funktionen zu realisieren, und wenn gewünscht, Experten zu werden. Templares kann man einfach austauschen und dann anwenden.<br />
;Verwalten von Funktionen statt Registern<br />
:Als Experten kann man sicher die Register zeilsicher setzen. Wirklich? Wenn man sich eine clevere Lösung ausgedacht hat und sie reproduzieren will kann man einfach noch einmal nachdenken, nachlesen,... und schon hat man es wieder. Oder man hat ein Template definiert das man einfach nutzt.<br />
; Lernen aus Templates<br />
:Templates sind nicht verschlüsselt. Hat oder bekommt man ein Template kann man die dort gesetzten Register einfach einsehen - und wenn man will verstehen was gemacht wurde. <br />
;Globales Anpassen aller Devices <br />
: Hat man festgestellt, dass eine Funktion sub-optimal ist kann man das Temlate ändern und diese Änderungen allen Devices zu gute kommen lassen. Auf einmal. <br />
<br />
= Grundsätzliches zum Template =<br />
Templates (hier) ist nun also eine Sammlung von Registern welche in einem Device gesetzt werden können. <br />
<br />
== Template Granularität ==<br />
Man kann nicht alle Register eines Device in einem Template abbilden. Das wäre technisch komplex und macht auch von der Anwendung her keinen Sinn. <br />
<br />
*Aus Sicht der Funktion sollte man Templates nach deren Funktionen zusammenfassen.<br />
*Aus Sicht des Devices sollte man Templates nach der Struktur des Device zusammenstellen.<br />
*Die Implementierung erlaubt es, templates für jedes Register einzeln zu erstellen.<br><br />
*Weniger Templates erhöhen die Übersichtlichkeit<br />
Die technische Lösung legt folgenden Templates nahe<br />
#Alle Register eines Kanals oder Device - ausgenommen peer abhängige Register<br />
#Alle Register eines Kanals eines Peers für short oder long<br />
#Alle Register eines Kanals eines Peers nur für short<br />
#Alle Register eines Kanals eines Peers nur für long<br />
Ob man 2. oder die Kombination aus 3. und 4. nutzt ist Geschmackssache. <br><br />
Ein typischer Einsatz sind Schaltern und Dimmer bei welchen man die Aktionen der Peers festlegen will.<br />
;usecase Template Granularität Dimmer<br />
:Mit Peer1 soll bei short ein und bei long ausgeschaltet werden<br />
:Mit Peer2 soll bei short getoggelt und bei long nicht geschaltet werden<br />
:Mit Peer3 soll bei short nicht geschaltet und bei long getoggelt werden<br />
:Mit Peer4 ist ein MotionDetector welcher bei short und einer bestimmten Helligkeit einschaltet, timed. Allerdings sollen Aktionen der anderen Peers oder der Zentrale das Licht dauer-ein schalten.<br />
<br />
== Template Flexibilität ==<br />
Templates sind starr... und können parametriert werden. Also semistarr. Was jetzt? Nun man kann Templates mir bis zu 9 Parametern versehen. Sinnvoll sind wohl eher bis zu 3. <br><br />
Beispiele sind:<br />
*Treppenhausschaltern - mit einem Parameter kann man Einschaltdauer je Instanziierung festlegen. Sinnvoll könnte eine Treppenhausschaltung generell sein, nicht nur im Treppenhaus. Man kann generell alle Lichter nach ein paar Stunden ausschalten.<br />
*Heizungstemplate - Boosttime: Man kann allen RTs das gleiche Template geben - allerdings kann man z.B. die Boosttime indivituell einstellen. <br />
*MotionDetector Clients: Bei den Peers des Modtion detector (also den Schaltern) stellt man ein, dann diese reagieren sollen und wie lange diese brennen sollen. <br />
<br />
== Template Verwaltung==<br />
Templates werden zusammen mit Registern verwaltet. Man benötigt demnach HMinfo. Sowohl die Template definition alsauch die Template Zuweisung werden im File zusammen mit den gelesenen Registern gesichert. Nach einem Einlesen dieses Files werden auch die Templates und deren Zuordnung neu erstellt.<br />
<br />
== Template Editieren==<br />
Die aktuell einfachste Möglichkeit ein Template zu modifizieren ist, HMtemplate zu nutzen. HMtemplate ist ein Editor. Für den Betrieb wird es nicht genutzt. <br />
<br />
<br />
=Das eigenen Konzept=<br />
Für die Verknüpfung von HM Entities muss man 2 Ebenen unterschieden, Architektur und Verhalten.<br />
==Architektur==<br />
Beim Erstellen der Architektur legt man fest, welche Entities untereinander verknüpft werden. Dies geschieht durch peeren. Templates unterstützen nicht die Architektur. Es ist demnach notwendig die Peerings durchzuführen bevor an ein Template darauf anwenden kann. <br />
==Verhalten==<br />
Hier kommen die Templates zum Tragen. Mit Templates definiert man die Register der Entities und somit das Verhalten und die Reaktion der Entites bspw auf Trigger von Sensoren.<br />
===Welchen templateTyp brauche ich===<br />
Wie in Granularität beschrieben kann man insbesondere beim Peerverhalten templates für ''short'', ''long'' oder ''both'' ertellen. Nutzt man short/long braucht man weniger Templates (Basics sind on/off/ignore/toggle) muss allerdings mehr Templates zuweisen, als Reaktion auf short UND long.<br><br />
Bei both braucht man mehr Templates (OnOff/OnIgnore/OffIgnore/IgnoreOff/ToggleIgnore/...) braucht aber nur die Hälfte der Zuweisungen zu den realen Entities. <br />
<br />
===Welche Parameter muss ich einstellen===<br />
Bei der Erstellung eine Templates werden dessen Parameter durch Attribute vorgegeben. Durch '''set save''' wird dann das Template schlussendlich definiert. Folgende Parameter/Attribute werden genutzt:<br />
*'''tpl_description''': ist ein Freitext welcher beschreiben soll, was das Template macht und wie es parametriert wird<br />
*'''tpl_params''': hier werden evtl Parameter definiert mit welchen die Instanziierung des Templates angepasst werden kann. Bspw. könnte die Einschaltzeit variable gestalltet werden. Bei einem Dimmer könnt man den Level und die Rampe eingeben, also 2 Parameter. Man vergibt also, ":" getrennt, eine Liste von Paramtern. Die Namen sind frei wählbar. <br><br />
timeOn:ramp würde 2 Parameter definieren, welche später in den Registern genutzt werden können<br />
*'''tpl_type''': definiert den Typ. Diesen muss man zuerst festlegen. Es konnte ''peer-Short'',''peer-Long'',''peer-Both'' oder ''basic'' sein. Nach der Auswahl des Typs kann man die Entity (source) wählen. Es alle Entities angeboten, welche entsprechende Registersätze zu Verfügung stellen.<br />
*'''tpl_source''': legt bei der Definition eines Templates fest, von welcher Entity die Register für die Vorlage genutzt werden sollen. Ein Browser-Refresh könnte notwendig sein um die Auswahlliste upzudaten<br />
*'''tpl_peer''': muss man auswählen, so man einen "peer" typ gewählt hat. An Browser-refresh denken. <br />
*'''Reg_xxx''': An Browser-refresh denken. Hat man nun die Vorlage ausgewählt und den Refresh gemach werden nun Register als Attribute angeboten<br />
<br />
=Getting started=<br />
Was muss man also tun? Wenn man noch nichts eingerichtet hat:<br />
define hm HMinfo<br />
attr hm autoArchive 1<br />
attr hm autoLoadArchive 1_load<br />
attr hm configFilename regConfig.cfg<br />
define ht HMtemplate<br />
<br />
==Template aus Device erstellen==<br />
Aufgabe ist es, aus einem existierenden Device ein Template zu erstellen. Wir haben <br />
device ''myDev''<br />
Channel ''myChan''<br />
Channel gepeert mit ''myChanPeer''.<br><br />
Der Kanal ist ein Schalter und wir wollen einen Parameter im Template nutzen: Die Anschaltzeit soll bei der Nutzung des Templates variabel eingesetzt werden. Wir werden also den Parameter ''timeOn'' nutzen. Das Template soll ''my1stTmpl'' genannt werden. Weiter soll das gesamte Verhalten des ''myChanPeer'' definiert werden, also short UND long. <br />
set ht define my1stTmpl<br />
attr ht tpl_param timeOn # name des Parameters - hier nur einer<br />
attr ht tpl_description "mein erstes Template"<br />
attr ht tpl_type peer-both<br />
<refresh browser> # select liste der attribute wird neu eingelesen<br />
attr ht tpl_source myChan<br />
<refresh browser> # select liste der attribute wird neu eingelesen<br />
attr ht tpl_peer myChanPeer<br />
<refresh browser> # select liste der attribute wird neu eingelesen<br />
attr ht Reg_shOnTime timeOn # setzen des parameters<br />
<br />
nun können weitere Register verändert werde. <br />
Sinnvoll ist es, unnötige Register aus dem Template zu entfernen. Dies sind in diesem Fall bspw. alle Ct register. Das Attribut des Registers wird einfach gelöscht. <br />
set ht save<br />
set ht dismiss<br />
==Template einem Kanal zuweisen==<br />
Jetzt haben wir ein Template welches long und short eines Kanals kontrollieren soll. Dies wollen wir jetzt anwenden auf unsere Kanal/Peer Kompinationen "sw1/peer1", "sw1/peer2", "sw2/peer1" und "sw2/peer3". Für alle benötigen wir unterschiedliche Abschaltzeiten (warum? eure Sache). <br />
set ht select my1stTmpl<br />
attr ht entity sw1<br />
<refresh browser><br />
attr ht ePeer peer1<br />
attr ht tpl_param_timeOn 30<br />
set ht apply<br />
attr ht ePeer peer2<br />
attr ht tpl_param_timeOn 180<br />
set ht apply<br />
<br />
attr ht entity sw2<br />
<refresh browser><br />
attr ht ePeer peer1<br />
attr ht tpl_param_timeOn 70<br />
set ht apply<br />
<br />
attr ht ePeer peer3<br />
attr ht tpl_param_timeOn 1000<br />
set ht apply<br />
<br />
set ht dismiss<br />
Die Register der Entities werden passend in das Device geschrieben. <br />
==Template editieren==<br />
Nun soll das Template grundsätzlich modfiziert werden. <br />
<br />
set ht edit my1stTmpl<br />
attr ht Reg_<name> <value><br />
attr ht Reg_<name2> <value2><br />
attr ht Reg_<name3> <value3><br />
set ht save<br />
==Template kopieren und editieren==<br />
Nun soll das Template grundsätzlich modfiziert werden. <br />
<br />
set ht select my1stTmpl<br />
attr ht Reg_<name> <value><br />
attr ht Reg_<name2> <value2><br />
attr ht Reg_<name3> <value3><br />
set ht saveAs my2ndTmpl<br />
==Template weitergeben==<br />
Will man Templates weitergeben geht das mit<br />
get ht my1stTmpl<br />
Das Kommando kann dann direkt in die Kommandozeile kopiert werden und das Template ist definiert.<br />
[[Kategorie:HomeMatic supportDevice]]<br />
[[Kategorie:HOWTOS]]</div>Martinp876http://wiki.fhem.de/w/index.php?title=HomeMatic_Templates&diff=23935HomeMatic Templates2017-12-30T09:58:10Z<p>Martinp876: </p>
<hr />
<div>{{Infobox Modul<br />
|ModPurpose=templates bedienen und verwalten<br />
|ModType=h<br />
|ModCmdRef=HMtemplate<br />
|ModForumArea=HomeMatic<br />
|ModTechName=98_HMtemplate.pm<br />
|ModOwner=martinp876 ({{Link2FU|251|martinp876}} / [[Benutzer Diskussion:Martinp876|Wiki]])<br />
}}<br />
Templates sind Vorlagen im Allgemeinen. Hier werden Vorlagen zur Programmierung der Register von HM Devices behandelt. <br />
= Warum Templates =<br />
Die Frage, warum man Register nicht einfach setzt sondern Templates nutzen sollte kommt immer wieder auf. Schliesslich sind wie alle Spezialisten...<br />
Die Wahrheit allerdings bildet das nicht ab. Den auch den Spezialisten sei angeraten, Templates zu nutzen. Ja, warum den, was bieten Templates? Hierzu muss man verstehen wir FHEM, HM, Devices, Kanäle und peers zusammen hängen. <br />
<br />
Wie schon im Einsteigerdoc beschrieben hat ein HM Device remanente Register welche von FHEM gesetzt werden können und die Funktions- und Arbeitsweise definieren. FHEM selbst hat bestenfalls eine Kopie dieser Daten.<br />
;soll-Register Verwaltung<br />
:Da FHEM nur eine Kopie der Registerwerte verwaltet lebt man erst einmal in einer fragilen Welt. Registerwerte können sich ändern durch:<br />
* Reset des Device<br />
* Batteriefehler<br />
* inkorrektes Schreiben und Übertragungsfehler<br />
* Austausch eines Device<br />
:Nach Lesen der Device Register hat FHEM einen neue Kopie - dies muss aber nicht den Wunschregistern entsprechen. Templates sind eine Ansammlung von Wunschregister. Somit können unterschiedliche Mechanismen genutzt werden, das System zu verwalten, prüfen und korrigieren.<br />
;Funktionen für Einsteiger<br />
:Nicht-Experten sollten primär Templates nutzen - um Funktionen zu realisieren, und wenn gewünscht, Experten zu werden. Templares kann man einfach austauschen und dann anwenden.<br />
;Verwalten von Funktionen statt Registern<br />
:Als Experten kann man sicher die Register zeilsicher setzen. Wirklich? Wenn man sich eine clevere Lösung ausgedacht hat und sie reproduzieren will kann man einfach noch einmal nachdenken, nachlesen,... und schon hat man es wieder. Oder man hat ein Template definiert das man einfach nutzt.<br />
; Lernen aus Templates<br />
:Templates sind nicht verschlüsselt. Hat oder bekommt man ein Template kann man die dort gesetzten Register einfach einsehen - und wenn man will verstehen was gemacht wurde. <br />
;Globales Anpassen aller Devices <br />
: Hat man festgestellt, dass eine Funktion sub-optimal ist kann man das Temlate ändern und diese Änderungen allen Devices zu gute kommen lassen. Auf einmal. <br />
<br />
= Grundsätzliches zum Template =<br />
Templates (hier) ist nun also eine Sammlung von Registern welche in einem Device gesetzt werden können. <br />
<br />
== Template Granularität ==<br />
Man kann nicht alle Register eines Device in einem Template abbilden. Das wäre technisch komplex und macht auch von der Anwendung her keinen Sinn. <br />
<br />
*Aus Sicht der Funktion sollte man Templates nach deren Funktionen zusammenfassen.<br />
*Aus Sicht des Devices sollte man Templates nach der Struktur des Device zusammenstellen.<br />
*Die Implementierung erlaubt es, templates für jedes Register einzeln zu erstellen.<br><br />
*Weniger Templates erhöhen die Übersichtlichkeit<br />
Die technische Lösung legt folgenden Templates nahe<br />
#Alle Register eines Kanals oder Device - ausgenommen peer abhängige Register<br />
#Alle Register eines Kanals eines Peers für short oder long<br />
#Alle Register eines Kanals eines Peers nur für short<br />
#Alle Register eines Kanals eines Peers nur für long<br />
Ob man 2. oder die Kombination aus 3. und 4. nutzt ist Geschmackssache. <br><br />
Ein typischer Einsatz sind Schaltern und Dimmer bei welchen man die Aktionen der Peers festlegen will.<br />
;usecase Template Granularität Dimmer<br />
:Mit Peer1 soll bei short ein und bei long ausgeschaltet werden<br />
:Mit Peer2 soll bei short getoggelt und bei long nicht geschaltet werden<br />
:Mit Peer3 soll bei short nicht geschaltet und bei long getoggelt werden<br />
:Mit Peer4 ist ein MotionDetector welcher bei short und einer bestimmten Helligkeit einschaltet, timed. Allerdings sollen Aktionen der anderen Peers oder der Zentrale das Licht dauer-ein schalten.<br />
<br />
== Template Flexibilität ==<br />
Templates sind starr... und können parametriert werden. Also semistarr. Was jetzt? Nun man kann Templates mir bis zu 9 Parametern versehen. Sinnvoll sind wohl eher bis zu 3. <br><br />
Beispiele sind:<br />
*Treppenhausschaltern - mit einem Parameter kann man Einschaltdauer je Instanziierung festlegen. Sinnvoll könnte eine Treppenhausschaltung generell sein, nicht nur im Treppenhaus. Man kann generell alle Lichter nach ein paar Stunden ausschalten.<br />
*Heizungstemplate - Boosttime: Man kann allen RTs das gleiche Template geben - allerdings kann man z.B. die Boosttime indivituell einstellen. <br />
*MotionDetector Clients: Bei den Peers des Modtion detector (also den Schaltern) stellt man ein, dann diese reagieren sollen und wie lange diese brennen sollen. <br />
<br />
== Template Verwaltung==<br />
Templates werden zusammen mit Registern verwaltet. Man benötigt demnach HMinfo. Sowohl die Template definition alsauch die Template Zuweisung werden im File zusammen mit den gelesenen Registern gesichert. Nach einem Einlesen dieses Files werden auch die Templates und deren Zuordnung neu erstellt.<br />
<br />
== Template Editieren==<br />
Die aktuell einfachste Möglichkeit ein Template zu modifizieren ist, HMtemplate zu nutzen. HMtemplate ist ein Editor. Für den Betrieb wird es nicht genutzt. <br />
<br />
<br />
=Das eigenen Konzept=<br />
Für die Verknüpfung von HM Entities muss man 2 Ebenen unterschieden, Architektur und Verhalten.<br />
==Architektur==<br />
Beim Erstellen der Architektur legt man fest, welche Entities untereinander verknüpft werden. Dies geschieht durch peeren. Templates unterstützen nicht die Architektur. Es ist demnach notwendig die Peerings durchzuführen bevor an ein Template darauf anwenden kann. <br />
==Verhalten==<br />
Hier kommen die Templates zum Tragen. Mit Templates definiert man die Register der Entities und somit das Verhalten und die Reaktion der Entites bspw auf Trigger von Sensoren.<br />
===Welchen templateTyp brauche ich===<br />
Wie in Granularität beschrieben kann man insbesondere beim Peerverhalten templates für ''short'', ''long'' oder ''both'' ertellen. Nutzt man short/long braucht man weniger Templates (Basics sind on/off/ignore/toggle) muss allerdings mehr Templates zuweisen, als Reaktion auf short UND long.<br><br />
Bei both braucht man mehr Templates (OnOff/OnIgnore/OffIgnore/IgnoreOff/ToggleIgnore/...) braucht aber nur die Hälfte der Zuweisungen zu den realen Entities. <br />
<br />
=Getting started=<br />
Was muss man also tun? Wenn man noch nichts eingerichtet hat:<br />
define hm HMinfo<br />
attr hm autoArchive 1<br />
attr hm autoLoadArchive 1_load<br />
attr hm configFilename regConfig.cfg<br />
define ht HMtemplate<br />
<br />
==Template aus Device erstellen==<br />
Aufgabe ist es, aus einem existierenden Device ein Template zu erstellen. Wir haben <br />
device ''myDev''<br />
Channel ''myChan''<br />
Channel gepeert mit ''myChanPeer''.<br><br />
Der Kanal ist ein Schalter und wir wollen einen Parameter im Template nutzen: Die Anschaltzeit soll bei der Nutzung des Templates variabel eingesetzt werden. Wir werden also den Parameter ''timeOn'' nutzen. Das Template soll ''my1stTmpl'' genannt werden. Weiter soll das gesamte Verhalten des ''myChanPeer'' definiert werden, also short UND long. <br />
set ht define my1stTmpl<br />
attr ht tpl_param timeOn # name des Parameters - hier nur einer<br />
attr ht tpl_description "mein erstes Template"<br />
attr ht tpl_type peer-both<br />
<refresh browser> # select liste der attribute wird neu eingelesen<br />
attr ht tpl_source myChan<br />
<refresh browser> # select liste der attribute wird neu eingelesen<br />
attr ht tpl_peer myChanPeer<br />
<refresh browser> # select liste der attribute wird neu eingelesen<br />
attr ht Reg_shOnTime timeOn # setzen des parameters<br />
<br />
nun können weitere Register verändert werde. <br />
Sinnvoll ist es, unnötige Register aus dem Template zu entfernen. Dies sind in diesem Fall bspw. alle Ct register. Das Attribut des Registers wird einfach gelöscht. <br />
set ht save<br />
set ht dismiss<br />
==Template einem Kanal zuweisen==<br />
Jetzt haben wir ein Template welches long und short eines Kanals kontrollieren soll. Dies wollen wir jetzt anwenden auf unsere Kanal/Peer Kompinationen "sw1/peer1", "sw1/peer2", "sw2/peer1" und "sw2/peer3". Für alle benötigen wir unterschiedliche Abschaltzeiten (warum? eure Sache). <br />
set ht select my1stTmpl<br />
attr ht entity sw1<br />
<refresh browser><br />
attr ht ePeer peer1<br />
attr ht tpl_param_timeOn 30<br />
set ht apply<br />
attr ht ePeer peer2<br />
attr ht tpl_param_timeOn 180<br />
set ht apply<br />
<br />
attr ht entity sw2<br />
<refresh browser><br />
attr ht ePeer peer1<br />
attr ht tpl_param_timeOn 70<br />
set ht apply<br />
<br />
attr ht ePeer peer3<br />
attr ht tpl_param_timeOn 1000<br />
set ht apply<br />
<br />
set ht dismiss<br />
Die Register der Entities werden passend in das Device geschrieben. <br />
==Template editieren==<br />
Nun soll das Template grundsätzlich modfiziert werden. <br />
<br />
set ht edit my1stTmpl<br />
attr ht Reg_<name> <value><br />
attr ht Reg_<name2> <value2><br />
attr ht Reg_<name3> <value3><br />
set ht save<br />
==Template kopieren und editieren==<br />
Nun soll das Template grundsätzlich modfiziert werden. <br />
<br />
set ht select my1stTmpl<br />
attr ht Reg_<name> <value><br />
attr ht Reg_<name2> <value2><br />
attr ht Reg_<name3> <value3><br />
set ht saveAs my2ndTmpl<br />
==Template weitergeben==<br />
Will man Templates weitergeben geht das mit<br />
get ht my1stTmpl<br />
Das Kommando kann dann direkt in die Kommandozeile kopiert werden und das Template ist definiert.<br />
[[Kategorie:HomeMatic supportDevice]]<br />
[[Kategorie:HOWTOS]]</div>Martinp876http://wiki.fhem.de/w/index.php?title=HomeMatic_Templates&diff=23934HomeMatic Templates2017-12-30T09:50:34Z<p>Martinp876: </p>
<hr />
<div>{{Infobox Modul<br />
|ModPurpose=templates bedienen und verwalten<br />
|ModType=h<br />
|ModCmdRef=HMtemplate<br />
|ModForumArea=HomeMatic<br />
|ModTechName=98_HMtemplate.pm<br />
|ModOwner=martinp876 ({{Link2FU|251|martinp876}} / [[Benutzer Diskussion:Martinp876|Wiki]])<br />
}}<br />
Templates sind Vorlagen im Allgemeinen. Hier werden Vorlagen zur Programmierung der Register von HM Devices behandelt. <br />
= Warum Templates =<br />
Die Frage, warum man Register nicht einfach setzt sondern Templates nutzen sollte kommt immer wieder auf. Schliesslich sind wie alle Spezialisten...<br />
Die Wahrheit allerdings bildet das nicht ab. Den auch den Spezialisten sei angeraten, Templates zu nutzen. Ja, warum den, was bieten Templates? Hierzu muss man verstehen wir FHEM, HM, Devices, Kanäle und peers zusammen hängen. <br />
<br />
Wie schon im Einsteigerdoc beschrieben hat ein HM Device remanente Register welche von FHEM gesetzt werden können und die Funktions- und Arbeitsweise definieren. FHEM selbst hat bestenfalls eine Kopie dieser Daten.<br />
;soll-Register Verwaltung<br />
:Da FHEM nur eine Kopie der Registerwerte verwaltet lebt man erst einmal in einer fragilen Welt. Registerwerte können sich ändern durch:<br />
* Reset des Device<br />
* Batteriefehler<br />
* inkorrektes Schreiben und Übertragungsfehler<br />
* Austausch eines Device<br />
:Nach Lesen der Device Register hat FHEM einen neue Kopie - dies muss aber nicht den Wunschregistern entsprechen. Templates sind eine Ansammlung von Wunschregister. Somit können unterschiedliche Mechanismen genutzt werden, das System zu verwalten, prüfen und korrigieren.<br />
;Funktionen für Einsteiger<br />
:Nicht-Experten sollten primär Templates nutzen - um Funktionen zu realisieren, und wenn gewünscht, Experten zu werden. Templares kann man einfach austauschen und dann anwenden.<br />
;Verwalten von Funktionen statt Registern<br />
:Als Experten kann man sicher die Register zeilsicher setzen. Wirklich? Wenn man sich eine clevere Lösung ausgedacht hat und sie reproduzieren will kann man einfach noch einmal nachdenken, nachlesen,... und schon hat man es wieder. Oder man hat ein Template definiert das man einfach nutzt.<br />
; Lernen aus Templates<br />
:Templates sind nicht verschlüsselt. Hat oder bekommt man ein Template kann man die dort gesetzten Register einfach einsehen - und wenn man will verstehen was gemacht wurde. <br />
;Globales Anpassen aller Devices <br />
: Hat man festgestellt, dass eine Funktion sub-optimal ist kann man das Temlate ändern und diese Änderungen allen Devices zu gute kommen lassen. Auf einmal. <br />
<br />
= Grundsätzliches zum Template =<br />
Templates (hier) ist nun also eine Sammlung von Registern welche in einem Device gesetzt werden können. <br />
<br />
== Template Granularität ==<br />
Man kann nicht alle Register eines Device in einem Template abbilden. Das wäre technisch komplex und macht auch von der Anwendung her keinen Sinn. <br />
<br />
*Aus Sicht der Funktion sollte man Templates nach deren Funktionen zusammenfassen.<br />
*Aus Sicht des Devices sollte man Templates nach der Struktur des Device zusammenstellen.<br />
*Die Implementierung erlaubt es, templates für jedes Register einzeln zu erstellen.<br><br />
*Weniger Templates erhöhen die Übersichtlichkeit<br />
Die technische Lösung legt folgenden Templates nahe<br />
#Alle Register eines Kanals oder Device - ausgenommen peer abhängige Register<br />
#Alle Register eines Kanals eines Peers für short oder long<br />
#Alle Register eines Kanals eines Peers nur für short<br />
#Alle Register eines Kanals eines Peers nur für long<br />
Ob man 2. oder die Kombination aus 3. und 4. nutzt ist Geschmackssache. <br><br />
Ein typischer Einsatz sind Schaltern und Dimmer bei welchen man die Aktionen der Peers festlegen will.<br />
;usecase Template Granularität Dimmer<br />
:Mit Peer1 soll bei short ein und bei long ausgeschaltet werden<br />
:Mit Peer2 soll bei short getoggelt und bei long nicht geschaltet werden<br />
:Mit Peer3 soll bei short nicht geschaltet und bei long getoggelt werden<br />
:Mit Peer4 ist ein MotionDetector welcher bei short und einer bestimmten Helligkeit einschaltet, timed. Allerdings sollen Aktionen der anderen Peers oder der Zentrale das Licht dauer-ein schalten.<br />
<br />
== Template Flexibilität ==<br />
Templates sind starr... und können parametriert werden. Also semistarr. Was jetzt? Nun man kann Templates mir bis zu 9 Parametern versehen. Sinnvoll sind wohl eher bis zu 3. <br><br />
Beispiele sind:<br />
*Treppenhausschaltern - mit einem Parameter kann man Einschaltdauer je Instanziierung festlegen. Sinnvoll könnte eine Treppenhausschaltung generell sein, nicht nur im Treppenhaus. Man kann generell alle Lichter nach ein paar Stunden ausschalten.<br />
*Heizungstemplate - Boosttime: Man kann allen RTs das gleiche Template geben - allerdings kann man z.B. die Boosttime indivituell einstellen. <br />
*MotionDetector Clients: Bei den Peers des Modtion detector (also den Schaltern) stellt man ein, dann diese reagieren sollen und wie lange diese brennen sollen. <br />
<br />
== Template Verwaltung==<br />
Templates werden zusammen mit Registern verwaltet. Man benötigt demnach HMinfo. Sowohl die Template definition alsauch die Template Zuweisung werden im File zusammen mit den gelesenen Registern gesichert. Nach einem Einlesen dieses Files werden auch die Templates und deren Zuordnung neu erstellt.<br />
<br />
== Template Editieren==<br />
Die aktuell einfachste Möglichkeit ein Template zu modifizieren ist, HMtemplate zu nutzen. HMtemplate ist ein Editor. Für den Betrieb wird es nicht genutzt. <br />
=Das eigenen Konzept=<br />
Für die Verknüpfung von HM Entities muss man 2 Ebenen unterschieden:<br />
==Architektur==<br />
Beim Erstellen der Architektur legt man fest, welche Entities untereinander verknüpft werden. Dies geschieht durch peeren. Templates unterstützen nicht die Architektur. Es ist demnach notwendig die Peerings durchzuführen bevor an ein Template darauf anwenden kann. <br />
==Verhalten==<br />
Hier kommen die Templates zum Tragen. Mit Templates definiert man die Register der Entities und somit das Verhalten und die Reaktion der Entites bspw auf Trigger von Sensoren.<br />
===Welchen templateTyp brauche ich===<br />
Tem<br />
=Getting started=<br />
Was muss man also tun? Wenn man noch nichts eingerichtet hat:<br />
define hm HMinfo<br />
attr hm autoArchive 1<br />
attr hm autoLoadArchive 1_load<br />
attr hm configFilename regConfig.cfg<br />
define ht HMtemplate<br />
<br />
==Template aus Device erstellen==<br />
Aufgabe ist es, aus einem existierenden Device ein Template zu erstellen. Wir haben <br />
device ''myDev''<br />
Channel ''myChan''<br />
Channel gepeert mit ''myChanPeer''.<br><br />
Der Kanal ist ein Schalter und wir wollen einen Parameter im Template nutzen: Die Anschaltzeit soll bei der Nutzung des Templates variabel eingesetzt werden. Wir werden also den Parameter ''timeOn'' nutzen. Das Template soll ''my1stTmpl'' genannt werden. Weiter soll das gesamte Verhalten des ''myChanPeer'' definiert werden, also short UND long. <br />
set ht define my1stTmpl<br />
attr ht tpl_param timeOn # name des Parameters - hier nur einer<br />
attr ht tpl_description "mein erstes Template"<br />
attr ht tpl_type peer-both<br />
<refresh browser> # select liste der attribute wird neu eingelesen<br />
attr ht tpl_source myChan<br />
<refresh browser> # select liste der attribute wird neu eingelesen<br />
attr ht tpl_peer myChanPeer<br />
<refresh browser> # select liste der attribute wird neu eingelesen<br />
attr ht Reg_shOnTime timeOn # setzen des parameters<br />
<br />
nun können weitere Register verändert werde. <br />
Sinnvoll ist es, unnötige Register aus dem Template zu entfernen. Dies sind in diesem Fall bspw. alle Ct register. Das Attribut des Registers wird einfach gelöscht. <br />
set ht save<br />
set ht dismiss<br />
==Template einem Kanal zuweisen==<br />
Jetzt haben wir ein Template welches long und short eines Kanals kontrollieren soll. Dies wollen wir jetzt anwenden auf unsere Kanal/Peer Kompinationen "sw1/peer1", "sw1/peer2", "sw2/peer1" und "sw2/peer3". Für alle benötigen wir unterschiedliche Abschaltzeiten (warum? eure Sache). <br />
set ht select my1stTmpl<br />
attr ht entity sw1<br />
<refresh browser><br />
attr ht ePeer peer1<br />
attr ht tpl_param_timeOn 30<br />
set ht apply<br />
attr ht ePeer peer2<br />
attr ht tpl_param_timeOn 180<br />
set ht apply<br />
<br />
attr ht entity sw2<br />
<refresh browser><br />
attr ht ePeer peer1<br />
attr ht tpl_param_timeOn 70<br />
set ht apply<br />
<br />
attr ht ePeer peer3<br />
attr ht tpl_param_timeOn 1000<br />
set ht apply<br />
<br />
set ht dismiss<br />
Die Register der Entities werden passend in das Device geschrieben. <br />
==Template editieren==<br />
Nun soll das Template grundsätzlich modfiziert werden. <br />
<br />
set ht edit my1stTmpl<br />
attr ht Reg_<name> <value><br />
attr ht Reg_<name2> <value2><br />
attr ht Reg_<name3> <value3><br />
set ht save<br />
==Template kopieren und editieren==<br />
Nun soll das Template grundsätzlich modfiziert werden. <br />
<br />
set ht select my1stTmpl<br />
attr ht Reg_<name> <value><br />
attr ht Reg_<name2> <value2><br />
attr ht Reg_<name3> <value3><br />
set ht saveAs my2ndTmpl<br />
==Template weitergeben==<br />
Will man Templates weitergeben geht das mit<br />
get ht my1stTmpl<br />
Das Kommando kann dann direkt in die Kommandozeile kopiert werden und das Template ist definiert.<br />
[[Kategorie:HomeMatic supportDevice]]<br />
[[Kategorie:HOWTOS]]</div>Martinp876http://wiki.fhem.de/w/index.php?title=HomeMatic_Templates&diff=23933HomeMatic Templates2017-12-30T09:39:16Z<p>Martinp876: Kategorie</p>
<hr />
<div>{{Infobox Modul<br />
|ModPurpose=templates bedienen und verwalten<br />
|ModType=h<br />
|ModCmdRef=HMtemplate<br />
|ModForumArea=HomeMatic<br />
|ModTechName=98_HMtemplate.pm<br />
|ModOwner=martinp876 ({{Link2FU|251|martinp876}} / [[Benutzer Diskussion:Martinp876|Wiki]])<br />
}}<br />
Templates sind Vorlagen im Allgemeinen. Hier werden Vorlagen zur Programmierung der Register von HM Devices behandelt. <br />
= Warum Templates =<br />
Die Frage, warum man Register nicht einfach setzt sondern Templates nutzen sollte kommt immer wieder auf. Schliesslich sind wie alle Spezialisten...<br />
Die Wahrheit allerdings bildet das nicht ab. Den auch den Spezialisten sei angeraten, Templates zu nutzen. Ja, warum den, was bieten Templates? Hierzu muss man verstehen wir FHEM, HM, Devices, Kanäle und peers zusammen hängen. <br />
<br />
Wie schon im Einsteigerdoc beschrieben hat ein HM Device remanente Register welche von FHEM gesetzt werden können und die Funktions- und Arbeitsweise definieren. FHEM selbst hat bestenfalls eine Kopie dieser Daten.<br />
;soll-Register Verwaltung<br />
:Da FHEM nur eine Kopie der Registerwerte verwaltet lebt man erst einmal in einer fragilen Welt. Registerwerte können sich ändern durch:<br />
* Reset des Device<br />
* Batteriefehler<br />
* inkorrektes Schreiben und Übertragungsfehler<br />
* Austausch eines Device<br />
:Nach Lesen der Device Register hat FHEM einen neue Kopie - dies muss aber nicht den Wunschregistern entsprechen. Templates sind eine Ansammlung von Wunschregister. Somit können unterschiedliche Mechanismen genutzt werden, das System zu verwalten, prüfen und korrigieren.<br />
;Funktionen für Einsteiger<br />
:Nicht-Experten sollten primär Templates nutzen - um Funktionen zu realisieren, und wenn gewünscht, Experten zu werden. Templares kann man einfach austauschen und dann anwenden.<br />
;Verwalten von Funktionen statt Registern<br />
:Als Experten kann man sicher die Register zeilsicher setzen. Wirklich? Wenn man sich eine clevere Lösung ausgedacht hat und sie reproduzieren will kann man einfach noch einmal nachdenken, nachlesen,... und schon hat man es wieder. Oder man hat ein Template definiert das man einfach nutzt.<br />
; Lernen aus Templates<br />
:Templates sind nicht verschlüsselt. Hat oder bekommt man ein Template kann man die dort gesetzten Register einfach einsehen - und wenn man will verstehen was gemacht wurde. <br />
;Globales Anpassen aller Devices <br />
: Hat man festgestellt, dass eine Funktion sub-optimal ist kann man das Temlate ändern und diese Änderungen allen Devices zu gute kommen lassen. Auf einmal. <br />
<br />
= Grundsätzliches zum Template =<br />
Templates (hier) ist nun also eine Sammlung von Registern welche in einem Device gesetzt werden können. <br />
<br />
== Template Granularität ==<br />
Man kann nicht alle Register eines Device in einem Template abbilden. Das wäre technisch komplex und macht auch von der Anwendung her keinen Sinn. <br />
<br />
*Aus Sicht der Funktion sollte man Templates nach deren Funktionen zusammenfassen.<br />
*Aus Sicht des Devices sollte man Templates nach der Struktur des Device zusammenstellen.<br />
*Die Implementierung erlaubt es, templates für jedes Register einzeln zu erstellen.<br><br />
*Weniger Templates erhöhen die Übersichtlichkeit<br />
Die technische Lösung legt folgenden Templates nahe<br />
#Alle Register eines Kanals oder Device - ausgenommen peer abhängige Register<br />
#Alle Register eines Kanals eines Peers für short oder long<br />
#Alle Register eines Kanals eines Peers nur für short<br />
#Alle Register eines Kanals eines Peers nur für long<br />
Ob man 2. oder die Kombination aus 3. und 4. nutzt ist Geschmackssache. <br><br />
Ein typischer Einsatz sind Schaltern und Dimmer bei welchen man die Aktionen der Peers festlegen will.<br />
;usecase Template Granularität Dimmer<br />
:Mit Peer1 soll bei short ein und bei long ausgeschaltet werden<br />
:Mit Peer2 soll bei short getoggelt und bei long nicht geschaltet werden<br />
:Mit Peer3 soll bei short nicht geschaltet und bei long getoggelt werden<br />
:Mit Peer4 ist ein MotionDetector welcher bei short und einer bestimmten Helligkeit einschaltet, timed. Allerdings sollen Aktionen der anderen Peers oder der Zentrale das Licht dauer-ein schalten.<br />
<br />
== Template Flexibilität ==<br />
Templates sind starr... und können parametriert werden. Also semistarr. Was jetzt? Nun man kann Templates mir bis zu 9 Parametern versehen. Sinnvoll sind wohl eher bis zu 3. <br><br />
Beispiele sind:<br />
*Treppenhausschaltern - mit einem Parameter kann man Einschaltdauer je Instanziierung festlegen. Sinnvoll könnte eine Treppenhausschaltung generell sein, nicht nur im Treppenhaus. Man kann generell alle Lichter nach ein paar Stunden ausschalten.<br />
*Heizungstemplate - Boosttime: Man kann allen RTs das gleiche Template geben - allerdings kann man z.B. die Boosttime indivituell einstellen. <br />
*MotionDetector Clients: Bei den Peers des Modtion detector (also den Schaltern) stellt man ein, dann diese reagieren sollen und wie lange diese brennen sollen. <br />
<br />
== Template Verwaltung==<br />
Templates werden zusammen mit Registern verwaltet. Man benötigt demnach HMinfo. Sowohl die Template definition alsauch die Template Zuweisung werden im File zusammen mit den gelesenen Registern gesichert. Nach einem Einlesen dieses Files werden auch die Templates und deren Zuordnung neu erstellt.<br />
<br />
== Template Editieren==<br />
Die aktuell einfachste Möglichkeit ein Template zu modifizieren ist, HMtemplate zu nutzen. HMtemplate ist ein Editor. Für den Betrieb wird es nicht genutzt. <br />
<br />
=Getting started=<br />
Was muss man also tun? Wenn man noch nichts eingerichtet hat:<br />
define hm HMinfo<br />
attr hm autoArchive 1<br />
attr hm autoLoadArchive 1_load<br />
attr hm configFilename regConfig.cfg<br />
define ht HMtemplate<br />
<br />
==Template aus Device erstellen==<br />
Aufgabe ist es, aus einem existierenden Device ein Template zu erstellen. Wir haben <br />
device ''myDev''<br />
Channel ''myChan''<br />
Channel gepeert mit ''myChanPeer''.<br><br />
Der Kanal ist ein Schalter und wir wollen einen Parameter im Template nutzen: Die Anschaltzeit soll bei der Nutzung des Templates variabel eingesetzt werden. Wir werden also den Parameter ''timeOn'' nutzen. Das Template soll ''my1stTmpl'' genannt werden. Weiter soll das gesamte Verhalten des ''myChanPeer'' definiert werden, also short UND long. <br />
set ht define my1stTmpl<br />
attr ht tpl_param timeOn # name des Parameters - hier nur einer<br />
attr ht tpl_description "mein erstes Template"<br />
attr ht tpl_type peer-both<br />
<refresh browser> # select liste der attribute wird neu eingelesen<br />
attr ht tpl_source myChan<br />
<refresh browser> # select liste der attribute wird neu eingelesen<br />
attr ht tpl_peer myChanPeer<br />
<refresh browser> # select liste der attribute wird neu eingelesen<br />
attr ht Reg_shOnTime timeOn # setzen des parameters<br />
<br />
nun können weitere Register verändert werde. <br />
Sinnvoll ist es, unnötige Register aus dem Template zu entfernen. Dies sind in diesem Fall bspw. alle Ct register. Das Attribut des Registers wird einfach gelöscht. <br />
set ht save<br />
set ht dismiss<br />
==Template einem Kanal zuweisen==<br />
Jetzt haben wir ein Template welches long und short eines Kanals kontrollieren soll. Dies wollen wir jetzt anwenden auf unsere Kanal/Peer Kompinationen "sw1/peer1", "sw1/peer2", "sw2/peer1" und "sw2/peer3". Für alle benötigen wir unterschiedliche Abschaltzeiten (warum? eure Sache). <br />
set ht select my1stTmpl<br />
attr ht entity sw1<br />
<refresh browser><br />
attr ht ePeer peer1<br />
attr ht tpl_param_timeOn 30<br />
set ht apply<br />
attr ht ePeer peer2<br />
attr ht tpl_param_timeOn 180<br />
set ht apply<br />
<br />
attr ht entity sw2<br />
<refresh browser><br />
attr ht ePeer peer1<br />
attr ht tpl_param_timeOn 70<br />
set ht apply<br />
<br />
attr ht ePeer peer3<br />
attr ht tpl_param_timeOn 1000<br />
set ht apply<br />
<br />
set ht dismiss<br />
Die Register der Entities werden passend in das Device geschrieben. <br />
==Template editieren==<br />
Nun soll das Template grundsätzlich modfiziert werden. <br />
<br />
set ht edit my1stTmpl<br />
attr ht Reg_<name> <value><br />
attr ht Reg_<name2> <value2><br />
attr ht Reg_<name3> <value3><br />
set ht save<br />
==Template kopieren und editieren==<br />
Nun soll das Template grundsätzlich modfiziert werden. <br />
<br />
set ht select my1stTmpl<br />
attr ht Reg_<name> <value><br />
attr ht Reg_<name2> <value2><br />
attr ht Reg_<name3> <value3><br />
set ht saveAs my2ndTmpl<br />
==Template weitergeben==<br />
Will man Templates weitergeben geht das mit<br />
get ht my1stTmpl<br />
Das Kommando kann dann direkt in die Kommandozeile kopiert werden und das Template ist definiert.<br />
[[Kategorie:HomeMatic supportDevice]]<br />
[[Kategorie:HOWTOS]]</div>Martinp876http://wiki.fhem.de/w/index.php?title=HomeMatic_Templates&diff=23915HomeMatic Templates2017-12-29T16:17:00Z<p>Martinp876: </p>
<hr />
<div>{{Infobox Modul<br />
|ModPurpose=templates bedienen und verwalten<br />
|ModType=h<br />
|ModCmdRef=HMtemplate<br />
|ModForumArea=HomeMatic<br />
|ModTechName=98_HMtemplate.pm<br />
|ModOwner=martinp876 ({{Link2FU|251|martinp876}} / [[Benutzer Diskussion:Martinp876|Wiki]])<br />
}}<br />
Templates sind Vorlagen im Allgemeinen. Hier werden Vorlagen zur Programmierung der Register von HM Devices behandelt. <br />
= Warum Templates =<br />
Die Frage, warum man Register nicht einfach setzt sondern Templates nutzen sollte kommt immer wieder auf. Schliesslich sind wie alle Spezialisten...<br />
Die Wahrheit allerdings bildet das nicht ab. Den auch den Spezialisten sei angeraten, Templates zu nutzen. Ja, warum den, was bieten Templates? Hierzu muss man verstehen wir FHEM, HM, Devices, Kanäle und peers zusammen hängen. <br />
<br />
Wie schon im Einsteigerdoc beschrieben hat ein HM Device remanente Register welche von FHEM gesetzt werden können und die Funktions- und Arbeitsweise definieren. FHEM selbst hat bestenfalls eine Kopie dieser Daten.<br />
;soll-Register Verwaltung<br />
:Da FHEM nur eine Kopie der Registerwerte verwaltet lebt man erst einmal in einer fragilen Welt. Registerwerte können sich ändern durch:<br />
* Reset des Device<br />
* Batteriefehler<br />
* inkorrektes Schreiben und Übertragungsfehler<br />
* Austausch eines Device<br />
:Nach Lesen der Device Register hat FHEM einen neue Kopie - dies muss aber nicht den Wunschregistern entsprechen. Templates sind eine Ansammlung von Wunschregister. Somit können unterschiedliche Mechanismen genutzt werden, das System zu verwalten, prüfen und korrigieren.<br />
;Funktionen für Einsteiger<br />
:Nicht-Experten sollten primär Templates nutzen - um Funktionen zu realisieren, und wenn gewünscht, Experten zu werden. Templares kann man einfach austauschen und dann anwenden.<br />
;Verwalten von Funktionen statt Registern<br />
:Als Experten kann man sicher die Register zeilsicher setzen. Wirklich? Wenn man sich eine clevere Lösung ausgedacht hat und sie reproduzieren will kann man einfach noch einmal nachdenken, nachlesen,... und schon hat man es wieder. Oder man hat ein Template definiert das man einfach nutzt.<br />
; Lernen aus Templates<br />
:Templates sind nicht verschlüsselt. Hat oder bekommt man ein Template kann man die dort gesetzten Register einfach einsehen - und wenn man will verstehen was gemacht wurde. <br />
;Globales Anpassen aller Devices <br />
: Hat man festgestellt, dass eine Funktion sub-optimal ist kann man das Temlate ändern und diese Änderungen allen Devices zu gute kommen lassen. Auf einmal. <br />
<br />
= Grundsätzliches zum Template =<br />
Templates (hier) ist nun also eine Sammlung von Registern welche in einem Device gesetzt werden können. <br />
<br />
== Template Granularität ==<br />
Man kann nicht alle Register eines Device in einem Template abbilden. Das wäre technisch komplex und macht auch von der Anwendung her keinen Sinn. <br />
<br />
*Aus Sicht der Funktion sollte man Templates nach deren Funktionen zusammenfassen.<br />
*Aus Sicht des Devices sollte man Templates nach der Struktur des Device zusammenstellen.<br />
*Die Implementierung erlaubt es, templates für jedes Register einzeln zu erstellen.<br><br />
*Weniger Templates erhöhen die Übersichtlichkeit<br />
Die technische Lösung legt folgenden Templates nahe<br />
#Alle Register eines Kanals oder Device - ausgenommen peer abhängige Register<br />
#Alle Register eines Kanals eines Peers für short oder long<br />
#Alle Register eines Kanals eines Peers nur für short<br />
#Alle Register eines Kanals eines Peers nur für long<br />
Ob man 2. oder die Kombination aus 3. und 4. nutzt ist Geschmackssache. <br><br />
Ein typischer Einsatz sind Schaltern und Dimmer bei welchen man die Aktionen der Peers festlegen will.<br />
;usecase Template Granularität Dimmer<br />
:Mit Peer1 soll bei short ein und bei long ausgeschaltet werden<br />
:Mit Peer2 soll bei short getoggelt und bei long nicht geschaltet werden<br />
:Mit Peer3 soll bei short nicht geschaltet und bei long getoggelt werden<br />
:Mit Peer4 ist ein MotionDetector welcher bei short und einer bestimmten Helligkeit einschaltet, timed. Allerdings sollen Aktionen der anderen Peers oder der Zentrale das Licht dauer-ein schalten.<br />
<br />
== Template Flexibilität ==<br />
Templates sind starr... und können parametriert werden. Also semistarr. Was jetzt? Nun man kann Templates mir bis zu 9 Parametern versehen. Sinnvoll sind wohl eher bis zu 3. <br><br />
Beispiele sind:<br />
*Treppenhausschaltern - mit einem Parameter kann man Einschaltdauer je Instanziierung festlegen. Sinnvoll könnte eine Treppenhausschaltung generell sein, nicht nur im Treppenhaus. Man kann generell alle Lichter nach ein paar Stunden ausschalten.<br />
*Heizungstemplate - Boosttime: Man kann allen RTs das gleiche Template geben - allerdings kann man z.B. die Boosttime indivituell einstellen. <br />
*MotionDetector Clients: Bei den Peers des Modtion detector (also den Schaltern) stellt man ein, dann diese reagieren sollen und wie lange diese brennen sollen. <br />
<br />
== Template Verwaltung==<br />
Templates werden zusammen mit Registern verwaltet. Man benötigt demnach HMinfo. Sowohl die Template definition alsauch die Template Zuweisung werden im File zusammen mit den gelesenen Registern gesichert. Nach einem Einlesen dieses Files werden auch die Templates und deren Zuordnung neu erstellt.<br />
<br />
== Template Editieren==<br />
Die aktuell einfachste Möglichkeit ein Template zu modifizieren ist, HMtemplate zu nutzen. HMtemplate ist ein Editor. Für den Betrieb wird es nicht genutzt. <br />
<br />
=Getting started=<br />
Was muss man also tun? Wenn man noch nichts eingerichtet hat:<br />
define hm HMinfo<br />
attr hm autoArchive 1<br />
attr hm autoLoadArchive 1_load<br />
attr hm configFilename regConfig.cfg<br />
define ht HMtemplate<br />
<br />
==Template aus Device erstellen==<br />
Aufgabe ist es, aus einem existierenden Device ein Template zu erstellen. Wir haben <br />
device ''myDev''<br />
Channel ''myChan''<br />
Channel gepeert mit ''myChanPeer''.<br><br />
Der Kanal ist ein Schalter und wir wollen einen Parameter im Template nutzen: Die Anschaltzeit soll bei der Nutzung des Templates variabel eingesetzt werden. Wir werden also den Parameter ''timeOn'' nutzen. Das Template soll ''my1stTmpl'' genannt werden. Weiter soll das gesamte Verhalten des ''myChanPeer'' definiert werden, also short UND long. <br />
set ht define my1stTmpl<br />
attr ht tpl_param timeOn # name des Parameters - hier nur einer<br />
attr ht tpl_description "mein erstes Template"<br />
attr ht tpl_type peer-both<br />
<refresh browser> # select liste der attribute wird neu eingelesen<br />
attr ht tpl_source myChan<br />
<refresh browser> # select liste der attribute wird neu eingelesen<br />
attr ht tpl_peer myChanPeer<br />
<refresh browser> # select liste der attribute wird neu eingelesen<br />
attr ht Reg_shOnTime timeOn # setzen des parameters<br />
<br />
nun können weitere Register verändert werde. <br />
Sinnvoll ist es, unnötige Register aus dem Template zu entfernen. Dies sind in diesem Fall bspw. alle Ct register. Das Attribut des Registers wird einfach gelöscht. <br />
set ht save<br />
set ht dismiss<br />
==Template einem Kanal zuweisen==<br />
Jetzt haben wir ein Template welches long und short eines Kanals kontrollieren soll. Dies wollen wir jetzt anwenden auf unsere Kanal/Peer Kompinationen "sw1/peer1", "sw1/peer2", "sw2/peer1" und "sw2/peer3". Für alle benötigen wir unterschiedliche Abschaltzeiten (warum? eure Sache). <br />
set ht select my1stTmpl<br />
attr ht entity sw1<br />
<refresh browser><br />
attr ht ePeer peer1<br />
attr ht tpl_param_timeOn 30<br />
set ht apply<br />
attr ht ePeer peer2<br />
attr ht tpl_param_timeOn 180<br />
set ht apply<br />
<br />
attr ht entity sw2<br />
<refresh browser><br />
attr ht ePeer peer1<br />
attr ht tpl_param_timeOn 70<br />
set ht apply<br />
<br />
attr ht ePeer peer3<br />
attr ht tpl_param_timeOn 1000<br />
set ht apply<br />
<br />
set ht dismiss<br />
Die Register der Entities werden passend in das Device geschrieben. <br />
==Template editieren==<br />
Nun soll das Template grundsätzlich modfiziert werden. <br />
<br />
set ht edit my1stTmpl<br />
attr ht Reg_<name> <value><br />
attr ht Reg_<name2> <value2><br />
attr ht Reg_<name3> <value3><br />
set ht save<br />
==Template kopieren und editieren==<br />
Nun soll das Template grundsätzlich modfiziert werden. <br />
<br />
set ht select my1stTmpl<br />
attr ht Reg_<name> <value><br />
attr ht Reg_<name2> <value2><br />
attr ht Reg_<name3> <value3><br />
set ht saveAs my2ndTmpl<br />
==Template weitergeben==<br />
Will man Templates weitergeben geht das mit<br />
get ht my1stTmpl<br />
Das Kommando kann dann direkt in die Kommandozeile kopiert werden und das Template ist definiert.</div>Martinp876http://wiki.fhem.de/w/index.php?title=HomeMatic_Templates&diff=23914HomeMatic Templates2017-12-29T16:14:59Z<p>Martinp876: </p>
<hr />
<div>{{Infobox Modul<br />
|ModPurpose=templates bedienen und verwalten<br />
|ModType=h<br />
|ModCmdRef=HMtemplate<br />
|ModForumArea=HomeMatic<br />
|ModTechName=98_HMtemplate.pm<br />
|ModOwner=martinp876 ({{Link2FU|251|martinp876}} / [[Benutzer Diskussion:Martinp876|Wiki]])<br />
}}<br />
Templates sind Vorlagen im Allgemeinen. Hier werden Vorlagen zur Programmierung der Register von HM Devices behandelt. <br />
= Warum Templates =<br />
Die Frage, warum man Register nicht einfach setzt sondern Templates nutzen sollte kommt immer wieder auf. Schliesslich sind wie alle Spezialisten...<br />
Die Wahrheit allerdings bildet das nicht ab. Den auch den Spezialisten sei angeraten, Templates zu nutzen. Ja, warum den, was bieten Templates? Hierzu muss man verstehen wir FHEM, HM, Devices, Kanäle und peers zusammen hängen. <br />
<br />
Wie schon im Einsteigerdoc beschrieben hat ein HM Device remanente Register welche von FHEM gesetzt werden können und die Funktions- und Arbeitsweise definieren. FHEM selbst hat bestenfalls eine Kopie dieser Daten.<br />
;soll-Register Verwaltung<br />
:Da FHEM nur eine Kopie der Registerwerte verwaltet lebt man erst einmal in einer fragilen Welt. Registerwerte können sich ändern durch:<br />
* Reset des Device<br />
* Batteriefehler<br />
* inkorrektes Schreiben und Übertragungsfehler<br />
* Austausch eines Device<br />
:Nach Lesen der Device Register hat FHEM einen neue Kopie - dies muss aber nicht den Wunschregistern entsprechen. Templates sind eine Ansammlung von Wunschregister. Somit können unterschiedliche Mechanismen genutzt werden, das System zu verwalten, prüfen und korrigieren.<br />
;Funktionen für Einsteiger<br />
:Nicht-Experten sollten primär Templates nutzen - um Funktionen zu realisieren, und wenn gewünscht, Experten zu werden. Templares kann man einfach austauschen und dann anwenden.<br />
;Verwalten von Funktionen statt Registern<br />
:Als Experten kann man sicher die Register zeilsicher setzen. Wirklich? Wenn man sich eine clevere Lösung ausgedacht hat und sie reproduzieren will kann man einfach noch einmal nachdenken, nachlesen,... und schon hat man es wieder. Oder man hat ein Template definiert das man einfach nutzt.<br />
; Lernen aus Templates<br />
:Templates sind nicht verschlüsselt. Hat oder bekommt man ein Template kann man die dort gesetzten Register einfach einsehen - und wenn man will verstehen was gemacht wurde. <br />
;Globales Anpassen aller Devices <br />
: Hat man festgestellt, dass eine Funktion sub-optimal ist kann man das Temlate ändern und diese Änderungen allen Devices zu gute kommen lassen. Auf einmal. <br />
<br />
= Grundsätzliches zum Template =<br />
Templates (hier) ist nun also eine Sammlung von Registern welche in einem Device gesetzt werden können. <br />
<br />
== Template Granularität ==<br />
Man kann nicht alle Register eines Device in einem Template abbilden. Das wäre technisch komplex und macht auch von der Anwendung her keinen Sinn. <br />
<br />
*Aus Sicht der Funktion sollte man Templates nach deren Funktionen zusammenfassen.<br />
*Aus Sicht des Devices sollte man Templates nach der Struktur des Device zusammenstellen.<br />
*Die Implementierung erlaubt es, templates für jedes Register einzeln zu erstellen.<br><br />
*Weniger Templates erhöhen die Übersichtlichkeit<br />
Die technische Lösung legt folgenden Templates nahe<br />
#Alle Register eines Kanals oder Device - ausgenommen peer abhängige Register<br />
#Alle Register eines Kanals eines Peers für short oder long<br />
#Alle Register eines Kanals eines Peers nur für short<br />
#Alle Register eines Kanals eines Peers nur für long<br />
Ob man 2. oder die Kombination aus 3. und 4. nutzt ist Geschmackssache. <br><br />
Ein typischer Einsatz sind Schaltern und Dimmer bei welchen man die Aktionen der Peers festlegen will.<br />
;usecase Template Granularität Dimmer<br />
:Mit Peer1 soll bei short ein und bei long ausgeschaltet werden<br />
:Mit Peer2 soll bei short getoggelt und bei long nicht geschaltet werden<br />
:Mit Peer3 soll bei short nicht geschaltet und bei long getoggelt werden<br />
:Mit Peer4 ist ein MotionDetector welcher bei short und einer bestimmten Helligkeit einschaltet, timed. Allerdings sollen Aktionen der anderen Peers oder der Zentrale das Licht dauer-ein schalten.<br />
<br />
== Template Flexibilität ==<br />
Templates sind starr... und können parametriert werden. Also semistarr. Was jetzt? Nun man kann Templates mir bis zu 9 Parametern versehen. Sinnvoll sind wohl eher bis zu 3. <br><br />
Beispiele sind:<br />
*Treppenhausschaltern - mit einem Parameter kann man Einschaltdauer je Instanziierung festlegen. Sinnvoll könnte eine Treppenhausschaltung generell sein, nicht nur im Treppenhaus. Man kann generell alle Lichter nach ein paar Stunden ausschalten.<br />
*Heizungstemplate - Boosttime: Man kann allen RTs das gleiche Template geben - allerdings kann man z.B. die Boosttime indivituell einstellen. <br />
*MotionDetector Clients: Bei den Peers des Modtion detector (also den Schaltern) stellt man ein, dann diese reagieren sollen und wie lange diese brennen sollen. <br />
<br />
== Template Verwaltung==<br />
Templates werden zusammen mit Registern verwaltet. Man benötigt demnach HMinfo. Sowohl die Template definition alsauch die Template Zuweisung werden im File zusammen mit den gelesenen Registern gesichert. Nach einem Einlesen dieses Files werden auch die Templates und deren Zuordnung neu erstellt.<br />
<br />
== Template Editieren==<br />
Die aktuell einfachste Möglichkeit ein Template zu modifizieren ist, HMtemplate zu nutzen. HMtemplate ist ein Editor. Für den Betrieb wird es nicht genutzt. <br />
<br />
=Getting started=<br />
Was muss man also tun? Wenn man noch nichts eingerichtet hat:<br />
define hm HMinfo<br />
attr hm autoArchive 1<br />
attr hm autoLoadArchive 1_load<br />
attr hm configFilename regConfig.cfg<br />
define ht HMtemplate<br />
<br />
==Template aus Device erstellen==<br />
Aufgabe ist es, aus einem existierenden Device ein Template zu erstellen. Wir haben <br />
device ''myDev''<br />
Channel ''myChan''<br />
Channel gepeert mit ''myChanPeer''.<br><br />
Der Kanal ist ein Schalter und wir wollen einen Parameter im Template nutzen: Die Anschaltzeit soll bei der Nutzung des Templates variabel eingesetzt werden. Wir werden also den Parameter ''timeOn'' nutzen. Das Template soll ''my1stTmpl'' genannt werden. Weiter soll das gesamte Verhalten des ''myChanPeer'' definiert werden, also short UND long. <br />
set ht define my1stTmpl<br />
attr ht tpl_param timeOn # name des Parameters - hier nur einer<br />
attr ht tpl_description "mein erstes Template"<br />
attr ht tpl_type peer-both<br />
<refresh browser> # select liste der attribute wird neu eingelesen<br />
attr ht tpl_source myChan<br />
<refresh browser> # select liste der attribute wird neu eingelesen<br />
attr ht tpl_peer myChanPeer<br />
<refresh browser> # select liste der attribute wird neu eingelesen<br />
attr ht Reg_shOnTime timeOn # setzen des parameters<br />
<br />
nun können weitere Register verändert werde. <br />
Sinnvoll ist es, unnötige Register aus dem Template zu entfernen. Dies sind in diesem Fall bspw. alle Ct register. Das Attribut des Registers wird einfach gelöscht. <br />
set ht save<br />
set ht dismiss<br />
==Template einem Kanal zuweisen==<br />
Jetzt haben wir ein Template welches long und short eines Kanals kontrollieren soll. Dies wollen wir jetzt anwenden auf unsere Kanal/Peer Kompinationen "sw1/peer1", "sw1/peer2", "sw2/peer1" und "sw2/peer3". Für alle benötigen wir unterschiedliche Abschaltzeiten (warum? eure Sache). <br />
set ht select my1stTmpl<br />
attr ht entity sw1<br />
<refresh browser><br />
attr ht ePeer peer1<br />
attr ht tpl_param_timeOn 30<br />
set ht apply<br />
attr ht ePeer peer2<br />
attr ht tpl_param_timeOn 180<br />
set ht apply<br />
<br />
attr ht entity sw2<br />
<refresh browser><br />
attr ht ePeer peer1<br />
attr ht tpl_param_timeOn 70<br />
set ht apply<br />
<br />
attr ht ePeer peer3<br />
attr ht tpl_param_timeOn 1000<br />
set ht apply<br />
<br />
set ht dismiss<br />
Die Register der Entities werden passend in das Device geschrieben. <br />
==Template editieren==<br />
Nun soll das Template grundsätzlich modfiziert werden. <br />
<br />
set ht edit my1stTmpl<br />
attr ht Reg_<name> <value><br />
attr ht Reg_<name2> <value2><br />
attr ht Reg_<name3> <value3><br />
set ht save<br />
==Template kopieren und editieren==<br />
Nun soll das Template grundsätzlich modfiziert werden. <br />
<br />
set ht select my1stTmpl<br />
attr ht Reg_<name> <value><br />
attr ht Reg_<name2> <value2><br />
attr ht Reg_<name3> <value3><br />
set ht saveAs my2ndTmpl</div>Martinp876http://wiki.fhem.de/w/index.php?title=HomeMatic_Templates&diff=23913HomeMatic Templates2017-12-29T16:08:08Z<p>Martinp876: </p>
<hr />
<div>{{Infobox Modul<br />
|ModPurpose=templates bedienen und verwalten<br />
|ModType=h<br />
|ModCmdRef=HMtemplate<br />
|ModForumArea=HomeMatic<br />
|ModTechName=98_HMtemplate.pm<br />
|ModOwner=martinp876 ({{Link2FU|251|martinp876}} / [[Benutzer Diskussion:Martinp876|Wiki]])<br />
}}<br />
Templates sind Vorlagen im Allgemeinen. Hier werden Vorlagen zur Programmierung der Register von HM Devices behandelt. <br />
= Warum Templates =<br />
Die Frage, warum man Register nicht einfach setzt sondern Templates nutzen sollte kommt immer wieder auf. Schliesslich sind wie alle Spezialisten...<br />
Die Wahrheit allerdings bildet das nicht ab. Den auch den Spezialisten sei angeraten, Templates zu nutzen. Ja, warum den, was bieten Templates? Hierzu muss man verstehen wir FHEM, HM, Devices, Kanäle und peers zusammen hängen. <br />
<br />
Wie schon im Einsteigerdoc beschrieben hat ein HM Device remanente Register welche von FHEM gesetzt werden können und die Funktions- und Arbeitsweise definieren. FHEM selbst hat bestenfalls eine Kopie dieser Daten.<br />
;soll-Register Verwaltung<br />
:Da FHEM nur eine Kopie der Registerwerte verwaltet lebt man erst einmal in einer fragilen Welt. Registerwerte können sich ändern durch:<br />
* Reset des Device<br />
* Batteriefehler<br />
* inkorrektes Schreiben und Übertragungsfehler<br />
* Austausch eines Device<br />
:Nach Lesen der Device Register hat FHEM einen neue Kopie - dies muss aber nicht den Wunschregistern entsprechen. Templates sind eine Ansammlung von Wunschregister. Somit können unterschiedliche Mechanismen genutzt werden, das System zu verwalten, prüfen und korrigieren.<br />
;Funktionen für Einsteiger<br />
:Nicht-Experten sollten primär Templates nutzen - um Funktionen zu realisieren, und wenn gewünscht, Experten zu werden. Templares kann man einfach austauschen und dann anwenden.<br />
;Verwalten von Funktionen statt Registern<br />
:Als Experten kann man sicher die Register zeilsicher setzen. Wirklich? Wenn man sich eine clevere Lösung ausgedacht hat und sie reproduzieren will kann man einfach noch einmal nachdenken, nachlesen,... und schon hat man es wieder. Oder man hat ein Template definiert das man einfach nutzt.<br />
; Lernen aus Templates<br />
:Templates sind nicht verschlüsselt. Hat oder bekommt man ein Template kann man die dort gesetzten Register einfach einsehen - und wenn man will verstehen was gemacht wurde. <br />
;Globales Anpassen aller Devices <br />
: Hat man festgestellt, dass eine Funktion sub-optimal ist kann man das Temlate ändern und diese Änderungen allen Devices zu gute kommen lassen. Auf einmal. <br />
<br />
= Grundsätzliches zum Template =<br />
Templates (hier) ist nun also eine Sammlung von Registern welche in einem Device gesetzt werden können. <br />
<br />
== Template Granularität ==<br />
Man kann nicht alle Register eines Device in einem Template abbilden. Das wäre technisch komplex und macht auch von der Anwendung her keinen Sinn. <br />
<br />
*Aus Sicht der Funktion sollte man Templates nach deren Funktionen zusammenfassen.<br />
*Aus Sicht des Devices sollte man Templates nach der Struktur des Device zusammenstellen.<br />
*Die Implementierung erlaubt es, templates für jedes Register einzeln zu erstellen.<br><br />
*Weniger Templates erhöhen die Übersichtlichkeit<br />
Die technische Lösung legt folgenden Templates nahe<br />
#Alle Register eines Kanals oder Device - ausgenommen peer abhängige Register<br />
#Alle Register eines Kanals eines Peers für short oder long<br />
#Alle Register eines Kanals eines Peers nur für short<br />
#Alle Register eines Kanals eines Peers nur für long<br />
Ob man 2. oder die Kombination aus 3. und 4. nutzt ist Geschmackssache. <br><br />
Ein typischer Einsatz sind Schaltern und Dimmer bei welchen man die Aktionen der Peers festlegen will.<br />
;usecase Template Granularität Dimmer<br />
:Mit Peer1 soll bei short ein und bei long ausgeschaltet werden<br />
:Mit Peer2 soll bei short getoggelt und bei long nicht geschaltet werden<br />
:Mit Peer3 soll bei short nicht geschaltet und bei long getoggelt werden<br />
:Mit Peer4 ist ein MotionDetector welcher bei short und einer bestimmten Helligkeit einschaltet, timed. Allerdings sollen Aktionen der anderen Peers oder der Zentrale das Licht dauer-ein schalten.<br />
<br />
== Template Flexibilität ==<br />
Templates sind starr... und können parametriert werden. Also semistarr. Was jetzt? Nun man kann Templates mir bis zu 9 Parametern versehen. Sinnvoll sind wohl eher bis zu 3. <br><br />
Beispiele sind:<br />
*Treppenhausschaltern - mit einem Parameter kann man Einschaltdauer je Instanziierung festlegen. Sinnvoll könnte eine Treppenhausschaltung generell sein, nicht nur im Treppenhaus. Man kann generell alle Lichter nach ein paar Stunden ausschalten.<br />
*Heizungstemplate - Boosttime: Man kann allen RTs das gleiche Template geben - allerdings kann man z.B. die Boosttime indivituell einstellen. <br />
*MotionDetector Clients: Bei den Peers des Modtion detector (also den Schaltern) stellt man ein, dann diese reagieren sollen und wie lange diese brennen sollen. <br />
<br />
== Template Verwaltung==<br />
Templates werden zusammen mit Registern verwaltet. Man benötigt demnach HMinfo. Sowohl die Template definition alsauch die Template Zuweisung werden im File zusammen mit den gelesenen Registern gesichert. Nach einem Einlesen dieses Files werden auch die Templates und deren Zuordnung neu erstellt.<br />
<br />
== Template Editieren==<br />
Die aktuell einfachste Möglichkeit ein Template zu modifizieren ist, HMtemplate zu nutzen. HMtemplate ist ein Editor. Für den Betrieb wird es nicht genutzt. <br />
<br />
=Getting started=<br />
Was muss man also tun? Wenn man noch nichts eingerichtet hat:<br />
define hm HMinfo<br />
attr hm autoArchive 1<br />
attr hm autoLoadArchive 1_load<br />
attr hm configFilename regConfig.cfg<br />
define ht HMtemplate<br />
<br />
==Template aus Device erstellen==<br />
Aufgabe ist es, aus einem existierenden Device ein Template zu erstellen. Wir haben <br />
device ''myDev''<br />
Channel ''myChan''<br />
Channel gepeert mit ''myChanPeer''.<br><br />
Der Kanal ist ein Schalter und wir wollen einen Parameter im Template nutzen: Die Anschaltzeit soll bei der Nutzung des Templates variabel eingesetzt werden. Wir werden also den Parameter ''timeOn'' nutzen. Das Template soll ''my1stTmpl'' genannt werden. Weiter soll das gesamte Verhalten des ''myChanPeer'' definiert werden, also short UND long. <br />
set ht define my1stTmpl<br />
attr ht tpl_param timeOn # name des Parameters - hier nur einer<br />
attr ht tpl_description "mein erstes Template"<br />
attr ht tpl_type peer-both<br />
<refresh browser> # select liste der attribute wird neu eingelesen<br />
attr ht tpl_source myChan<br />
<refresh browser> # select liste der attribute wird neu eingelesen<br />
attr ht tpl_peer myChanPeer<br />
<refresh browser> # select liste der attribute wird neu eingelesen<br />
attr ht Reg_shOnTime timeOn # setzen des parameters<br />
<br />
nun können weitere Register verändert werde. <br />
Sinnvoll ist es, unnötige Register aus dem Template zu entfernen. Dies sind in diesem Fall bspw. alle Ct register. Das Attribut des Registers wird einfach gelöscht. <br />
set ht save<br />
set ht dismiss<br />
==Template einem Kanal zuweisen==<br />
Jetzt haben wir ein Template welches long und short eines Kanals kontrollieren soll. Dies wollen wir jetzt anwenden auf unsere Kanal/Peer Kompinationen "sw1/peer1", "sw1/peer2", "sw2/peer1" und "sw2/peer3". Für alle benötigen wir unterschiedliche Abschaltzeiten (warum? eure Sache). <br />
set ht select my1stTmpl<br />
attr ht entity sw1<br />
<refresh browser><br />
attr ht ePeer peer1<br />
attr ht tpl_param_timeOn 30<br />
set ht apply<br />
attr ht ePeer peer2<br />
attr ht tpl_param_timeOn 180<br />
set ht apply<br />
<br />
attr ht entity sw2<br />
<refresh browser><br />
attr ht ePeer peer1<br />
attr ht tpl_param_timeOn 70<br />
set ht apply<br />
<br />
attr ht ePeer peer3<br />
attr ht tpl_param_timeOn 1000<br />
set ht apply</div>Martinp876http://wiki.fhem.de/w/index.php?title=HomeMatic_Templates&diff=23912HomeMatic Templates2017-12-29T16:01:08Z<p>Martinp876: </p>
<hr />
<div>{{Infobox Modul<br />
|ModPurpose=templates bedienen und verwalten<br />
|ModType=h<br />
|ModCmdRef=HMtemplate<br />
|ModForumArea=HomeMatic<br />
|ModTechName=98_HMtemplate.pm<br />
|ModOwner=martinp876 ({{Link2FU|251|martinp876}} / [[Benutzer Diskussion:Martinp876|Wiki]])<br />
}}<br />
Templates sind Vorlagen im Allgemeinen. Hier werden Vorlagen zur Programmierung der Register von HM Devices behandelt. <br />
= Warum Templates =<br />
Die Frage, warum man Register nicht einfach setzt sondern Templates nutzen sollte kommt immer wieder auf. Schliesslich sind wie alle Spezialisten...<br />
Die Wahrheit allerdings bildet das nicht ab. Den auch den Spezialisten sei angeraten, Templates zu nutzen. Ja, warum den, was bieten Templates? Hierzu muss man verstehen wir FHEM, HM, Devices, Kanäle und peers zusammen hängen. <br />
<br />
Wie schon im Einsteigerdoc beschrieben hat ein HM Device remanente Register welche von FHEM gesetzt werden können und die Funktions- und Arbeitsweise definieren. FHEM selbst hat bestenfalls eine Kopie dieser Daten.<br />
;soll-Register Verwaltung<br />
:Da FHEM nur eine Kopie der Registerwerte verwaltet lebt man erst einmal in einer fragilen Welt. Registerwerte können sich ändern durch:<br />
* Reset des Device<br />
* Batteriefehler<br />
* inkorrektes Schreiben und Übertragungsfehler<br />
* Austausch eines Device<br />
:Nach Lesen der Device Register hat FHEM einen neue Kopie - dies muss aber nicht den Wunschregistern entsprechen. Templates sind eine Ansammlung von Wunschregister. Somit können unterschiedliche Mechanismen genutzt werden, das System zu verwalten, prüfen und korrigieren.<br />
;Funktionen für Einsteiger<br />
:Nicht-Experten sollten primär Templates nutzen - um Funktionen zu realisieren, und wenn gewünscht, Experten zu werden. Templares kann man einfach austauschen und dann anwenden.<br />
;Verwalten von Funktionen statt Registern<br />
:Als Experten kann man sicher die Register zeilsicher setzen. Wirklich? Wenn man sich eine clevere Lösung ausgedacht hat und sie reproduzieren will kann man einfach noch einmal nachdenken, nachlesen,... und schon hat man es wieder. Oder man hat ein Template definiert das man einfach nutzt.<br />
; Lernen aus Templates<br />
:Templates sind nicht verschlüsselt. Hat oder bekommt man ein Template kann man die dort gesetzten Register einfach einsehen - und wenn man will verstehen was gemacht wurde. <br />
;Globales Anpassen aller Devices <br />
: Hat man festgestellt, dass eine Funktion sub-optimal ist kann man das Temlate ändern und diese Änderungen allen Devices zu gute kommen lassen. Auf einmal. <br />
<br />
= Grundsätzliches zum Template =<br />
Templates (hier) ist nun also eine Sammlung von Registern welche in einem Device gesetzt werden können. <br />
<br />
== Template Granularität ==<br />
Man kann nicht alle Register eines Device in einem Template abbilden. Das wäre technisch komplex und macht auch von der Anwendung her keinen Sinn. <br />
<br />
*Aus Sicht der Funktion sollte man Templates nach deren Funktionen zusammenfassen.<br />
*Aus Sicht des Devices sollte man Templates nach der Struktur des Device zusammenstellen.<br />
*Die Implementierung erlaubt es, templates für jedes Register einzeln zu erstellen.<br><br />
*Weniger Templates erhöhen die Übersichtlichkeit<br />
Die technische Lösung legt folgenden Templates nahe<br />
#Alle Register eines Kanals oder Device - ausgenommen peer abhängige Register<br />
#Alle Register eines Kanals eines Peers für short oder long<br />
#Alle Register eines Kanals eines Peers nur für short<br />
#Alle Register eines Kanals eines Peers nur für long<br />
Ob man 2. oder die Kombination aus 3. und 4. nutzt ist Geschmackssache. <br><br />
Ein typischer Einsatz sind Schaltern und Dimmer bei welchen man die Aktionen der Peers festlegen will.<br />
;usecase Template Granularität Dimmer<br />
:Mit Peer1 soll bei short ein und bei long ausgeschaltet werden<br />
:Mit Peer2 soll bei short getoggelt und bei long nicht geschaltet werden<br />
:Mit Peer3 soll bei short nicht geschaltet und bei long getoggelt werden<br />
:Mit Peer4 ist ein MotionDetector welcher bei short und einer bestimmten Helligkeit einschaltet, timed. Allerdings sollen Aktionen der anderen Peers oder der Zentrale das Licht dauer-ein schalten.<br />
<br />
== Template Flexibilität ==<br />
Templates sind starr... und können parametriert werden. Also semistarr. Was jetzt? Nun man kann Templates mir bis zu 9 Parametern versehen. Sinnvoll sind wohl eher bis zu 3. <br><br />
Beispiele sind:<br />
*Treppenhausschaltern - mit einem Parameter kann man Einschaltdauer je Instanziierung festlegen. Sinnvoll könnte eine Treppenhausschaltung generell sein, nicht nur im Treppenhaus. Man kann generell alle Lichter nach ein paar Stunden ausschalten.<br />
*Heizungstemplate - Boosttime: Man kann allen RTs das gleiche Template geben - allerdings kann man z.B. die Boosttime indivituell einstellen. <br />
*MotionDetector Clients: Bei den Peers des Modtion detector (also den Schaltern) stellt man ein, dann diese reagieren sollen und wie lange diese brennen sollen. <br />
<br />
== Template Verwaltung==<br />
Templates werden zusammen mit Registern verwaltet. Man benötigt demnach HMinfo. Sowohl die Template definition alsauch die Template Zuweisung werden im File zusammen mit den gelesenen Registern gesichert. Nach einem Einlesen dieses Files werden auch die Templates und deren Zuordnung neu erstellt.<br />
<br />
== Template Editieren==<br />
Die aktuell einfachste Möglichkeit ein Template zu modifizieren ist, HMtemplate zu nutzen. HMtemplate ist ein Editor. Für den Betrieb wird es nicht genutzt. <br />
<br />
=Getting started=<br />
Was muss man also tun? Wenn man noch nichts eingerichtet hat:<br />
define hm HMinfo<br />
attr hm autoArchive 1<br />
attr hm autoLoadArchive 1_load<br />
attr hm configFilename regConfig.cfg<br />
define ht HMtemplate<br />
<br />
==Template aus Device erstellen==<br />
Aufgabe ist es, aus einem existierenden Device ein Template zu erstellen. Wir haben <br />
device ''myDev''<br />
Channel ''myChan''<br />
Channel gepeert mit ''myChanPeer''.<br><br />
Der Kanal ist ein Schalter und wir wollen einen Parameter im Template nutzen: Die Anschaltzeit soll bei der Nutzung des Templates variabel eingesetzt werden. Wir werden also den Parameter ''timeOn'' nutzen. Das Template soll ''my1stTmpl'' genannt werden. Weiter soll das gesamte Verhalten des ''myChanPeer'' definiert werden, also short UND long. <br />
set ht define my1stTmpl<br />
attr ht tpl_param timeOn # name des Parameters - hier nur einer<br />
attr ht tpl_description "mein erstes Template"<br />
attr ht tpl_type peer-both<br />
<refresh browser> # select liste der attribute wird neu eingelesen<br />
attr ht tpl_source myChan<br />
<refresh browser> # select liste der attribute wird neu eingelesen<br />
attr ht tpl_peer myChanPeer<br />
<refresh browser> # select liste der attribute wird neu eingelesen<br />
attr ht Reg_shOnTime timeOn # setzen des parameters<br />
<br />
nun können weitere Register verändert werde. <br />
Sinnvoll ist es, unnötige Register aus dem Template zu entfernen. Dies sind in diesem Fall bspw. alle Ct register. Das Attribut des Registers wird einfach gelöscht. <br />
set ht save<br />
set ht dismiss<br />
==Template einem Kanal zuweisen==<br />
Jetzt haben wir ein Template welches long und short eines Kanals kontrollieren soll. Dies wollen wir jetzt anwenden auf unsere Kanal/Peer Kompinationen "sw1/peer1","sw1/peer2","sw2/peer1","sw2/peer2".</div>Martinp876http://wiki.fhem.de/w/index.php?title=HomeMatic_Templates&diff=23908HomeMatic Templates2017-12-29T15:54:13Z<p>Martinp876: d</p>
<hr />
<div>{{Infobox Modul<br />
|ModPurpose=templates bedienen und verwalten<br />
|ModType=h<br />
|ModCmdRef=HMtemplate<br />
|ModForumArea=HomeMatic<br />
|ModTechName=98_HMtemplate.pm<br />
|ModOwner=martinp876 ({{Link2FU|251|martinp876}} / [[Benutzer Diskussion:Martinp876|Wiki]])<br />
}}<br />
Templates sind Vorlagen im Allgemeinen. Hier werden Vorlagen zur Programmierung der Register von HM Devices behandelt. <br />
= Warum Templates =<br />
Die Frage, warum man Register nicht einfach setzt sondern Templates nutzen sollte kommt immer wieder auf. Schliesslich sind wie alle Spezialisten...<br />
Die Wahrheit allerdings bildet das nicht ab. Den auch den Spezialisten sei angeraten, Templates zu nutzen. Ja, warum den, was bieten Templates? Hierzu muss man verstehen wir FHEM, HM, Devices, Kanäle und peers zusammen hängen. <br />
<br />
Wie schon im Einsteigerdoc beschrieben hat ein HM Device remanente Register welche von FHEM gesetzt werden können und die Funktions- und Arbeitsweise definieren. FHEM selbst hat bestenfalls eine Kopie dieser Daten.<br />
;soll-Register Verwaltung<br />
:Da FHEM nur eine Kopie der Registerwerte verwaltet lebt man erst einmal in einer fragilen Welt. Registerwerte können sich ändern durch:<br />
* Reset des Device<br />
* Batteriefehler<br />
* inkorrektes Schreiben und Übertragungsfehler<br />
* Austausch eines Device<br />
:Nach Lesen der Device Register hat FHEM einen neue Kopie - dies muss aber nicht den Wunschregistern entsprechen. Templates sind eine Ansammlung von Wunschregister. Somit können unterschiedliche Mechanismen genutzt werden, das System zu verwalten, prüfen und korrigieren.<br />
;Funktionen für Einsteiger<br />
:Nicht-Experten sollten primär Templates nutzen - um Funktionen zu realisieren, und wenn gewünscht, Experten zu werden. Templares kann man einfach austauschen und dann anwenden.<br />
;Verwalten von Funktionen statt Registern<br />
:Als Experten kann man sicher die Register zeilsicher setzen. Wirklich? Wenn man sich eine clevere Lösung ausgedacht hat und sie reproduzieren will kann man einfach noch einmal nachdenken, nachlesen,... und schon hat man es wieder. Oder man hat ein Template definiert das man einfach nutzt.<br />
; Lernen aus Templates<br />
:Templates sind nicht verschlüsselt. Hat oder bekommt man ein Template kann man die dort gesetzten Register einfach einsehen - und wenn man will verstehen was gemacht wurde. <br />
;Globales Anpassen aller Devices <br />
: Hat man festgestellt, dass eine Funktion sub-optimal ist kann man das Temlate ändern und diese Änderungen allen Devices zu gute kommen lassen. Auf einmal. <br />
<br />
= Grundsätzliches zum Template =<br />
Templates (hier) ist nun also eine Sammlung von Registern welche in einem Device gesetzt werden können. <br />
<br />
== Template Granularität ==<br />
Man kann nicht alle Register eines Device in einem Template abbilden. Das wäre technisch komplex und macht auch von der Anwendung her keinen Sinn. <br />
<br />
*Aus Sicht der Funktion sollte man Templates nach deren Funktionen zusammenfassen.<br />
*Aus Sicht des Devices sollte man Templates nach der Struktur des Device zusammenstellen.<br />
*Die Implementierung erlaubt es, templates für jedes Register einzeln zu erstellen.<br><br />
*Weniger Templates erhöhen die Übersichtlichkeit<br />
Die technische Lösung legt folgenden Templates nahe<br />
#Alle Register eines Kanals oder Device - ausgenommen peer abhängige Register<br />
#Alle Register eines Kanals eines Peers für short oder long<br />
#Alle Register eines Kanals eines Peers nur für short<br />
#Alle Register eines Kanals eines Peers nur für long<br />
Ob man 2. oder die Kombination aus 3. und 4. nutzt ist Geschmackssache. <br><br />
Ein typischer Einsatz sind Schaltern und Dimmer bei welchen man die Aktionen der Peers festlegen will.<br />
;usecase Template Granularität Dimmer<br />
:Mit Peer1 soll bei short ein und bei long ausgeschaltet werden<br />
:Mit Peer2 soll bei short getoggelt und bei long nicht geschaltet werden<br />
:Mit Peer3 soll bei short nicht geschaltet und bei long getoggelt werden<br />
:Mit Peer4 ist ein MotionDetector welcher bei short und einer bestimmten Helligkeit einschaltet, timed. Allerdings sollen Aktionen der anderen Peers oder der Zentrale das Licht dauer-ein schalten.<br />
<br />
== Template Flexibilität ==<br />
Templates sind starr... und können parametriert werden. Also semistarr. Was jetzt? Nun man kann Templates mir bis zu 9 Parametern versehen. Sinnvoll sind wohl eher bis zu 3. <br><br />
Beispiele sind:<br />
*Treppenhausschaltern - mit einem Parameter kann man Einschaltdauer je Instanziierung festlegen. Sinnvoll könnte eine Treppenhausschaltung generell sein, nicht nur im Treppenhaus. Man kann generell alle Lichter nach ein paar Stunden ausschalten.<br />
*Heizungstemplate - Boosttime: Man kann allen RTs das gleiche Template geben - allerdings kann man z.B. die Boosttime indivituell einstellen. <br />
*MotionDetector Clients: Bei den Peers des Modtion detector (also den Schaltern) stellt man ein, dann diese reagieren sollen und wie lange diese brennen sollen. <br />
<br />
== Template Verwaltung==<br />
Templates werden zusammen mit Registern verwaltet. Man benötigt demnach HMinfo. Sowohl die Template definition alsauch die Template Zuweisung werden im File zusammen mit den gelesenen Registern gesichert. Nach einem Einlesen dieses Files werden auch die Templates und deren Zuordnung neu erstellt.<br />
<br />
== Template Editieren==<br />
Die aktuell einfachste Möglichkeit ein Template zu modifizieren ist, HMtemplate zu nutzen. HMtemplate ist ein Editor. Für den Betrieb wird es nicht genutzt. <br />
<br />
=Getting started=<br />
Was muss man also tun? Wenn man noch nichts eingerichtet hat:<br />
define hm HMinfo<br />
attr hm autoArchive 1<br />
attr hm autoLoadArchive 1_load<br />
attr hm configFilename regConfig.cfg<br />
define ht HMtemplate<br />
<br />
==Template aus Device erstellen==<br />
Aufgabe ist es, aus einem existierenden Device ein Template zu erstellen. Wir haben <br />
device ''myDev''<br />
Channel ''myChan''<br />
Channel gepeert mit ''myChanPeer''.<br><br />
Der Kanal ist ein Schalter und wir wollen einen Parameter im Template nutzen: Die Anschaltzeit soll bei der Nutzung des Templates variabel eingesetzt werden. Wir werden also den Parameter ''timeOn'' nutzen. Das Template soll ''my1stTmpl'' genannt werden. Weiter soll das gesamte Verhalten des ''myChanPeer'' definiert werden, also short UND long. <br />
set ht define my1stTmpl<br />
attr ht tpl_param timeOn # name des Parameters - hier nur einer<br />
attr ht tpl_description "mein erstes Template"<br />
attr ht tpl_type peer-both<br />
<refresh browser> # select liste der attribute wird neu eingelesen<br />
attr ht tpl_source myChan<br />
<refresh browser> # select liste der attribute wird neu eingelesen<br />
attr ht tpl_peer myChanPeer<br />
<refresh browser> # select liste der attribute wird neu eingelesen</div>Martinp876http://wiki.fhem.de/w/index.php?title=HMinfo&diff=23901HMinfo2017-12-29T11:05:06Z<p>Martinp876: </p>
<hr />
<div>{{Infobox Modul<br />
|ModPurpose=Übersicht über alle HomeMatic Geräte<br />
|ModType=h<br />
|ModCmdRef=HMinfo<br />
|ModForumArea=HomeMatic<br />
|ModTechName=98_HMinfo.pm<br />
|ModOwner=martinp876 ({{Link2FU|251|martinp876}} / [[Benutzer Diskussion:Martinp876|Wiki]])<br />
}}<br />
<br />
'''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. <br />
<br />
== Definition == <br />
HMInfo wird erstellt / angelegt mit dem Befehl<br />
:<code>define hm HMinfo</code><br />
<br />
Danach können alle Funktionen aufgelistet werden mit<br />
:<code>get hm help</code><br />
<br />
== Integritätsprüfungen ==<br />
Zur 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.<br />
<br />
Befehle, um die Gültigkeit von verschiedenen HomeMatic Eigenschaften zu überprüfen:<br />
<br />
=== peerCheck ===<br />
Mit dem Befehl <br />
:<code>get hm peerCheck</code><br />
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:<br />
;peer not verified. Check that peer is set on both sides <br />
:ausgegebener Wert (z.B.): actorChan p:switchChan<br />
: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).<br />
<br />
=== regCheck ===<br />
Mit dem Befehl <br />
:<code>get hm regCheck</code><br />
wird überprüft, ob alle Register korrekt gelesen wurden. Mögliche Meldungen:<br />
;missing register list <br />
:ausgegebener Wert (z.B.): <code>dev01Ch01: RegL_01: </code><br />
:erforderliche Korrekturmaßnahme: <code>set dev01Ch01 getConfig</code><br />
:oder <code>device01Ch01: .RegL_03:sensor01Ch01,.RegL_03:sensor01Ch02</code><br />
: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).<br />
;Register changes pending <br />
:ausgegebener Wert (z.B.): <code>sensor01Ch01</code><br />
: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).<br />
<br />
=== configCheck ===<br />
Mit dem Befehl <br />
:<code>get hm configCheck</code> werden die Befehle '''peerCheck''' und '''regCheck''' ausgeführt. Zusätzlich können noch Ergebnisse auftauchen wie<br />
;PairedTo mismatch to IODev<br />
:ausgegebener Wert (z.B.): <code>sensor01Ch01 paired:0x000000 IO attr: xxxxxx.</code><br />
: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).<br />
<br />
== Anzeigen zur Übertragungssituation ==<br />
===RSSI ===<br />
;<code>get hm rssi [<filter>]</code><br />
:Erzeugt eine Tabelle aller RSSI Werte.<br />
;<code>set hm clear [<filter>] rssi</code><br />
:setzt die RSSI Werte aller devices gemäß filter zurück. Eine neue Messung kann beginnen<br />
<br />
===protoEvents ===<br />
;<code>get hm protoEvents [<filter>][short|long] </code><br />
:Es wird eine Tabelle mit allen wichtigen Ereignissen zur Datenübertragung erzeugt. Dies beinhaltet Wiederholungen sowie Übertragungsfehler. <br />
<code>short</code> ist eine Fassung ohne Zeitstempel und lässt sich besser am Bildschirm darstellen.<br />
Ausserdem kann man sehen, welche Abfragen noch in der Queue sind, z.B. durch <code>autoReadReg</code> erzeugt. <br />
Die Zustände aller für HM zuständigen IOs sind beinhaltet. <br />
Alles in allem ist hier ein kompletter Überblick zur Kommunikation zu sehen. Der Befehl<br />
set hm clear [<filter>] Protocol<br />
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 />
<br />
===msgStat===<br />
;<code>set hm msgStat </code><br />
:Statistic der Übertragenen Messages insgesamt. Es gibt eine Tabelle über die letzten 24h und eine über die letzte Woche. <br />
<br />
== Speichern von Konfigurationen==<br />
HMInfo speichert Konfigurationen der Geräte in Files. Mit dem Attribut configDir kann man ein Verzeichnis festlegen, in das alles geschrieben wird.<br />
<br />
=== saveConfig===<br />
[[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. <br />
:<code>set hm saveConfig [<filter>] [<file>] </code><br />
<br />
=== archConfig ===<br />
Arbeitet prinzipiell wie saveConfig. Es werden jedoch nur vollständige Registersätze gespeichert, was einen höheren Level an Sicherheit der Dateninhalte gewährt. <br />
:<code>set hm archConfig [-a] [<file>] </code><br />
Mit dem '''Attribut autoArchive''' kann man einstellen, dass automatisch nach erfolgreichem Lesen einer Device-Konfiguration diese archiviert wird. <br />
Das Speichern erfolgt kumulativ. Ab einer Dateigröße von 1MB wird gepurged, also alles bis auf den neusten Eintrag jeder Entity gelöscht. <br />
<br />
Um eine Konfiguration zu sichern, sollte eine Kopie des Archivs gemacht werden. Das Archiv wird bei Gelegenheit überschrieben. <br />
<br />
Template erstellen:<br />
:<code>set hm saveConfig -f ^meinDevice$ <myTemplateFile> </code><br />
<br />
=== loadConfig ===<br />
;<code>set hm loadConfig [<filter>] [<filename>] </code><br />
: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. <br />
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. <br />
Es liegt im ermessen des User, eine bekannt aktuelle Version der Register einzulesen. <br />
<br />
=== purgeConfig===<br />
;<code>set hm purgeConfig [<filename>] </code><br />
:Löscht alle älteren Datensätze in einem File.<br />
<br />
== Konfigurationen bearbeiten ==<br />
=== Templates ===<br />
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.<br />
Faktisch setzt das Template also eine Gruppe von Registern auf einmal.<br />
<br />
====templateList ====<br />
Die vorhandenen templates kann man mit templateList sehen. <br />
get hm templateList<br />
<br />
SwOnCond params:level cond Info:switch: execute only if condition [geLo|ltLo] level is below limit<br />
SwToggle params: Info:Switch: toggle on trigger<br />
autoOff params:time Info:staircase - auto off after <time>, extend time with each trigger<br />
motionOnDim params:ontime brightness Info:Dimmer: on for time if MDIR-brightness below level<br />
motionOnSw params:ontime brightness Info:Switch: on for time if MDIR-brightness below level<br />
Die Liste der verfügbaren Tempaltes, deren Parameter falls nötig und eine kurze Info, was das Template bewirken soll<br />
<br />
get hm templateList autoOff<br />
<br />
autoOff params:time Info:staircase - auto off after <time>, extend time with each trigger<br />
ActionType :jmpToTarget<br />
OffTime :111600<br />
OnTime :time<br />
SwJtDlyOff :dlyOn<br />
SwJtDlyOn :no<br />
SwJtOff :dlyOn<br />
SwJtOn :on<br />
Ein templateList auf ein einzelnes Template zeigt im Detail, was das Template verändern wird.<br />
<br />
====templateSet ====<br />
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. <br />
set hm templateSet <entity> <templateName> <peer:[long|short]> [<param1> ...] <br />
set hm templateSet Licht1 autoOff FB1_Btn2:short 10<br />
set hm templateSet Licht1 SwOn FB1_Btn2:long<br />
set hm templateSet Licht1 SwOff FB1_Btn2:short<br />
set hm templateSet Licht1 SwOnOff FB1_Btn2:both<br />
set hm templateSet LichtDev setHost 0<br />
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. <br />
set hm templateSet Licht1 motionOnSw MD1:short 30 20<br />
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).<br />
<br />
====templateDef ====<br />
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:<br />
0 Register ohne peer<br />
<peer>:both Register eines peers<br />
<peer>:short Register eines peers nur Short<br />
<peer>:long Register eines peers nur Long<br />
setzen.<br />
Man kann das template "dynamisch" gestalten, indem man einzelne Register beim templateSet übergibt. <br />
Erst einmal statische Templates. Param ist hier "0"<br />
<br />
set hm templateDef <templateName> <param1[:<param2>...]> <description> <reg1>:<val1> [<reg2>:<val2>] ... <br />
<br />
set hm templateDef t1 0 "TP1" OnTime:10 OffTime:20 OnDly:0 <br />
<br />
set hm templateDef t1 fromMaster <entity> 0 <br />
set hm templateDef t2 fromMaster <entity> <peer>:both <br />
set hm templateDef t3 fromMaster <entity> <peer>:short<br />
set hm templateDef t4 fromMaster <entity> <peer>:long<br />
<br />
set hm templateDef t4 fromMaster LichtWz remoteBtn1:long<br />
<br />
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<br />
<br />
set hm templateDef myTemplate anzeit:auszeit "licht schaltet ständig an und aus" OnTime:p0 OffTime:p1 OnDly:0<br />
<br />
set hm templateDef myAutoOff AnZeit "treppenhausschalter" ActionType:jmpToTarget OffTime:unused OnTime:p0 SwJtDlyOff:dlyOn SwJtDlyOn:no SwJtOff:dlyOn SwJtOn:on<br />
<br />
Die "Anzeit" ist der erste Parameter, also p0. Der Wert, den man bei Set einträgt wird in OnTime geschrieben. OnTime:p0<br />
<br />
Beim Definieren eines Templates wird die Registergültigkeit nicht geprüft. Das kommt beim Set.<br />
<br />
Mit dem Parameter del kann ein (fehlerhaftes) Template (hier myTemplate) wieder gelöscht werden. <br />
<br />
set hm templateDef myTemplate del<br />
<br />
====templateChk ====<br />
Template definitionen und zuweisungen (set) kann man mit <br />
set hm archConfig<br />
speichern und mit <br />
set hm loadConfig<br />
mach einem reboot laden. Welche templates einer entity zugewiesen sind kann man mit <br />
attr <entity> expert 12<br />
in den Readings sichtbar machen. Siehe auch templateUsg.<br />
<br />
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. <br />
get hm templateChk <br />
get hm templateChk [<filter>] <br />
get hm templateChk [<filter>] <templateName> <peer:[long|short]> [<param1> ...] <br />
get hm templateChk -f Rollo RolloHoch self01 5<br />
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.<br />
get hm templateChk -f Rollo RolloHoch self01:sort 5<br />
das selbe, nur für short Einträge<br />
<br />
====templateUsg ====<br />
Gibt eine Liste der zugewiesenen templates zurück<br />
get hm templateUsg <br />
get hm templateUsg sortTemplate<br />
get hm templateUsg sortPeer<br />
<br />
====templateExe ====<br />
Nach einem loadConfig oder einem templateChk können Fehler erkannt worden sein, die Register entspreche nicht dem Template. Mit diesem Kommando werden alle nicht korrekten Register in die Devices geschrieben. Sollte die Werte stimmen wird nichts gemacht. <br />
set hm templateExe<br />
<br />
Das Kommando kann also bedenkenlos eingesetzt werden, wenn die templates schon stimmen. Es wird nichts gesendet, keine Funklast erzeugt.<br />
<br />
====templateDel ====<br />
eine zuweisung des Templates kann gelöscht werden<br />
set hm templateDel <entity> <template><br />
<br />
===Temperaturlisten===<br />
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]]<br />
<br />
=== Registersätze kopieren ===<br />
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. <br />
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. <br />
HMInfo geht davon aus, dass die vom Gerät gelesene Konfiguration vor dem Kommando aktuell und komplett ist. <br />
set hm cpRegs Licht1:FB3_Btn2 Licht3:FB1_Btn4<br />
set hm cpRegs Licht2:FB3_Btn2 Licht2:FB1_Btn4<br />
set hm cpRegs Licht4:FB3_Btn2 Licht4:FB5_Btn2<br />
Die obigen Beispiele bewirken der Reihe nach:<br />
Duplizieren das Verhalten, das Fernbedienungsknopf 2 der Fernbedienung 3 bei Aktor Licht1 hervorruft auch nach Licht3 für Fernbedienungsknopf4 der Fernbedienung 1.<br />
Duplizieren das Verhalten, das Fernbedienungsknopf 2 der Fernbedienung 3 bei Aktor Licht2 hervorruft auch nach Licht2 (selber Aktor) für Fernbedienungsknopf4 der Fernbedienung 1.<br />
<br />
== Web Einträge und Readings ==<br />
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:<br />
:<code>set hm update </code><br />
erreicht. Mit dem Attribut autoUpdate kann man es automatisch regelmäßig starten.<br />
<br />
=== Fehlermeldungen ===<br />
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:<br />
Reading:<gutwert>. Wenn ein Reading mit einen anderen als dem "gutwert" gefunden wird, wird dies alarmiert. <br />
Beispiel: <br />
:<code>battery:ok </code><br />
hat eine HM Komponente ein Reading "battery" und dieses hat einen anderen Wert als "ok" wird dies alarmiert. <br />
In den Readings von HMInfo würde im Feherfall<br />
internal:<br />
ERR_names <devicename1>,<devicename2><br />
Readings:<br />
ERR_battery low:2<br />
<br />
Der default aller Error-meldungen ist<br />
battery:ok,sabotageError:off,powerError:ok,overload:off,overheat:off,reduced:off,motorError:no,error:none,uncertain:yes,smoke_detect:none,cover:closed<br />
<br />
Diese Zusammenfassung der Fehlermeldungen könnte man nutzen, um über notify einen Alarm auszulösen oder eine E-Mail zu senden. <br />
<br />
=== Warnungen===<br />
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. <br />
<br />
=== Statusmeldungen ===<br />
Analog zu den Fehlermeldungen kann man mit dem Attribut sumStatus gewisse Readings zählen lassen. Beipiel wäre <br />
attr HM sumStatus motor<br />
HMInfo zeigt in dem Reading I_sum_motor dann an, welcher Inhalt des Readings "motor" wie oft gefunden wurde. Es könnte so aussehen<br />
stop:on:4;stop:1;<br />
Vier Komponenten stehen auf motor: stop:on und eine steht auf motor: stop<br />
<br />
Das Internal '''I_HM_IOdevices''' zeigt die von HM Komponenten genutzten IOs und deren State. <br />
<br />
== Infos ==<br />
get hm models [-f <regexp>]<br />
get hm models<br />
get hm models -f remote<br />
get hm models -f HM_RC<br />
Zeigt alle in FHEM unterstützten Modelle und deren wesentliche Parameter. Man kann mittels regexp die Liste filtern.<br />
<br />
get hm param [<typefilter>] [-f <nameFilter>] parameter1 parameter2<br />
get hm param -d IODev DEF model<br />
get hm param -c -f Rollo peerList<br />
man kann sich listen von Parametern anzeigen lassen <br />
<br />
get hm register [<typefilter>] [-f <nameFilter>]<br />
zeigt Register in tabellarischer Form. <br />
<br />
get hm peerXref[<typefilter>] [-f <nameFilter>]<br />
gibt an, wer mit wem [[Peering (HomeMatic)|gepeert]] ist<br />
<br />
== Rücksetzen von Variablen und Zählern ==<br />
set HM clear [<typeFilter>] [Protocol|readings|msgStat|register|rssi]<br />
*register löscht alle Register-readings<br />
*readings löscht '''alle''' readings<br />
*Protocol löscht alle Protokol-einträge, pending Kommandos und Protokoll-fehler. <br />
*rssi löscht alle ermittelten RSSI Werte<br />
*msgStat setzt die Message Statistik zurück<br />
<br />
== Filter ==<br />
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<br />
set <name> <cmd> '''[-dcasevi]''' [params]<br />
entities according to list will be processed"<br />
d - device :include devices"<br />
c - channels :include channels"<br />
i - ignore :include devices marked as ignore"<br />
v - virtual :supress fhem virtual"<br />
p - physical :supress physical"<br />
a - aktor :supress actor"<br />
s - sensor :supress sensor"<br />
e - empty :include results even if requested fields are empty"<br />
<br />
Ein auf '''-d''' gefiltertes Kommando wird nur auf devices, nicht aber auf channels angewendet. <br />
<br />
Dann gibt es noch den '''nameFilter''', mit dem mittels regexp auf den Namen der Entity gefiltert werden kann<br />
-f Rollo # alle Entities mit Rollo im Namen<br />
-f ^Rollo$ # nur Entity mit Namen "Rollo"<br />
-f Rollo$ # nur Entity deren Name auf Rollo endet<br />
<br />
Die Filter kann man kombinieren mit <br />
-c -f Rollo # alle Kanäle mit Rollo im Namen<br />
<br />
Beispiel: <br />
Zeige mir die Parameter IODev und room der Devices mit Rollo im Namen<br />
set hm param -d -f Rollo IODev room<br />
<br />
<br />
== Attribute ==<br />
* '''autoArchive ''' automatisch archivieren von vollständigen Konfigurationen.<br />
* '''autoUpdate''' startet regelmäßig das Komamndo "update". Die Wiederholzeit wird eingestellt mit hh:mm. Sinnvoll erscheint z.B. alle 5 Minuten, also 00:05.<br />
* '''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.<br />
* '''configFilename''' legt einen default Namen fest, der bei save und archive genutzt wird. Default ist regSave.cfg.<br />
* '''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.<br />
==weiterführende Links==<br />
Templates <u>[[Homematic_Templates|HMtemplates]]</u><br />
== Quellen == <br />
* Thread [http://forum.fhem.de/index.php?topic=11035.0 HMinfo] im FHEM Forum<br />
* Thread {{Link2Forum|Topic=20119|LinkText=HMINfo, Intention, Sinn und Zweck}} im FHEM Forum<br />
<br />
[[Kategorie:HomeMatic supportDevice]]<br />
[[Kategorie:HOWTOS]]</div>Martinp876http://wiki.fhem.de/w/index.php?title=Homematic-Ger%C3%A4te%C3%BCbersicht&diff=23899Homematic-Geräteübersicht2017-12-29T10:32:55Z<p>Martinp876: </p>
<hr />
<div>Diese Seite strukturiert die vorhandenen Wiki-Seiten zu Homematic-Geräten in Gruppen zur leichteren Orientierung. Derzeit sind nicht alle Homematic-Geräte aufgeführt, da die zugehörigen Wiki-Seiten noch nicht erstellt wurden.<br />
<br />
Für alle Geräte mit AA/AAA-Batterien werden empfohlen: [http://www.ikea.com/de/de/catalog/products/80240505/ IKEA Akalisk AAA] und [http://www.ikea.com/de/de/catalog/products/50240502/ IKEA Akalisk AA], die sehr temperaturbeständig und dauerhaft sind. Die [http://www.elv.de/installationsadapter-homematic-smart-home.html Übersicht von ELV] zeigt die vorhandenen Installationsadapter (55mm Maßeinheit) zur Integration in vorhandene Schalterserien.<br />
<br />
== Homematic Managen ==<br />
{| class="wikitable mw-datatable"<br />
!style="width:350px"|Einsatzzweck<br />
!style="width:150px"|fhem Wiki<br />
!style="width:200px"|ELV<br />
!style="width:150px"|Nachfolger<br />
!style="width:650px"|Zu beachten<br />
|-<br />
|Zentrale CCU2<br />
|HM-Cen-O-TW-X-X-2<br />
|[http://www.elv.de/homematic-zentrale-ccu-2.html Produkt] [https://files.elv.com/Assets/Produkte/10/1035/103584/Downloads/HM-Cen-O-TW-x-x-2_UM_GE_eQ-3_web.pdf Anleitung]<br />
|<br />
|Einzige Möglichkeit, '''Homematic IP'''-Geräte anzusteuern<br />
|-<br />
|LAN Konfigurationsadapter<br />
|[[HM-CFG-LAN_LAN_Konfigurations-Adapter|HM-CFG-LAN]]<br />
|<br />
|[[HM-LGW-O-TW-W-EU_Funk-LAN_Gateway|HM-LGW-O-TW-W-EU]]<br />
|End-of-Sale, 230V Steckernetzteil<br />
|-<br />
|LAN Konfigurationsadapter<br />
|[[HM-LGW-O-TW-W-EU_Funk-LAN_Gateway|HM-LGW-O-TW-W-EU]]<br />
|[http://www.elv.de/homematic-funk-lan-gateway.html Produkt] [https://files.elv.com/Assets/Produkte/10/1040/104029/Downloads/104029_lan_gateway_um.pdf Anleitung]<br />
|<br />
|5VDC 1A, LAN-Firmwareversionen < 1.1.5 haben Stabilitätsprobleme<br />
|-<br />
|USB Konfigurationsadapter<br />
|[[HM-CFG-USB_USB_Konfigurations-Adapter|HM-CFG-USB]]<br />
|<br />
|<br />
|End-of-Sale, USB<br />
|-<br />
|Raspberry Pi Homematic-Modul<br />
|[[HM-MOD-RPI-PCB_HomeMatic_Funkmodul_für_Raspberry_Pi|HM-MOD-RPI-PCB]]<br />
|[http://www.elv.de/homematic-funkmodul-fuer-raspberry-pi-bausatz.html Produkt]<br />
|<br />
|1,8-3,6VDC, Aufsteckplatine für Raspberry Pi, empfohlene Lösung<br />
|-<br />
|Repeater<br />
|[[HM-Sys-sRP-Pl_Funk-Zwischenstecker_Repeater|HM-SYS-SRP-P1]]<br />
|<br />
|<br />
|End-of-Sale<br />
|}<br />
<br />
== Homematic DIY ==<br />
{| class="wikitable mw-datatable"<br />
!style="width:350px"|Einsatzzweck<br />
!style="width:150px"|fhem Wiki<br />
!style="width:200px"|ELV<br />
!style="width:150px"|Nachfolger<br />
!style="width:650px"|Zu beachten<br />
|-<br />
|Sendemodul 8-Kanal<br />
|[[HM-MOD-EM-8_8-Kanal-Sendemodul|HM-MOD-EM-8]]<br />
|[http://www.elv.de/homematic-8-kanal-sendemodul.html Produkt] [https://files.elv.com/Assets/Produkte/13/1329/132939/Downloads/132939_sendemodul_um.pdf Anleitung]<br />
|<br />
||2,3-3V/3,5-12V DC, für eigene Entwicklungen - Bastlermodul<br />
|-<br />
|Empfängermodul 8-Kanal<br />
|[[HM-MOD-Re-8_8-Kanal-Empfangsmodul|HM-MOD-Re-8]]<br />
|[http://www.elv.de/homematic-8-kanal-empfangsmodul.html Produkt] [https://files.elv.com/Assets/Produkte/13/1321/132143/Downloads/132143_Empfangsmodul_UM.pdf Anleitung]<br />
|<br />
|2,3-3V/3,5-12V DC, für eigene Entwicklungen - Bastlermodul<br />
|-<br />
|NC/NO-Zustands-Sendemodul<br />
|[[HM-SCI-3-FM_3-Kanal-Funk-Schließerkontakt-Interface|HM-SCI-3-FM]]<br />
|[http://www.elv.de/homematic-schliesserkontakt-interface-fuer-oeffner-und-schliesserkontakte.html Produkt] [https://files.elv.com/Assets/Produkte/9/914/91461/Downloads/91461_HM_SCI_3FMD1_GB_um.pdf Anleitung]<br />
|<br />
|CR2032 Batterie, für eigene Entwicklungen - Bastlermodul<br />
|-<br />
|Klingelsignalsensor<br />
|[[HM-Sen-DB-PCB_Klingelsignalsensor|HM-SEN-DB-PCB]]<br />
|[http://www.elv.de/homematic-funk-klingelsignalsensor-bausatz.html Produkt] [https://files.elv.com/Assets/Produkte/13/1328/132846/Downloads/132846_HM-Sen-DB-PCB_UM_G_eQ-3_150608_um.pdf Anleitung]<br />
|<br />
|2 AAA Batterien, sendet keine zyklischen Statusmeldungen, erkennt Signale 5-12V AC/DC<br />
|-<br />
|Relais-Schaltmodul<br />
|RSM1<br />
|[https://www.elv.de/elv-relais-schaltmodul-rsm1-bausatz.html Produkt]<br />
|<br />
|Unterstützt verschiedene Relaistypen, als Erweiterung für OpenCollector-Ausgänge<br />
|-<br />
|Funk-Schaltaktor Kleinspannung<br />
|[[HM-LC-Sw1-PCB 1-Kanal-Schaltaktor für Kleinspannung|HM-LC-Sw1-PCB]]<br />
|[https://www.elv.de/elv-homematic-funk-schaltaktor1fach-fuer-kleinspannunghm-lc-sw1-pcb-bausatz.html Produkt]<br />
|<br />
|wahlweise mit Kleinspannungsrelais oder open-collector-Ausgang nutzbar<br />
|-<br />
|Funk-Sendemodul, 8-Bit<br />
|[[HM-MOD-EM-8bit 3-Kanal-Sendemodul mit 8-Bit-Datenkanal|HM-MOD-EM-8Bit]]<br />
|[https://www.elv.de/elv-homematic-funk-sendemodul-8-bit-bausatz.html Produkt]<br />
|<br />
|Taster und Dateneingänge<br />
|}<br />
<br />
== Homematic Remote ==<br />
{| class="wikitable mw-datatable"<br />
!style="width:350px"|Einsatzzweck<br />
!style="width:150px"|fhem Wiki<br />
!style="width:200px"|ELV<br />
!style="width:150px"|Nachfolger<br />
!style="width:650px"|Zu beachten<br />
|-<br />
|Taster Unterputz, 2fach<br />
|[[HM-PB-2-FM_2fach-Funk-Wandtaster_für_Markenschalter|HM-PB-2-FM]]<br />
|[http://www.elv.de/homematic-funk-wandsender-fuer-markenschalter-2fach-unterputzmontage-komplettbausatz.html Produkt] [https://files.elv.com/Assets/Produkte/13/1324/132438/Downloads/132438_HM-PB-2-FM_UM_G_eQ-3_150317_um.pdf Anleitung]<br />
|<br />
|2 AAA Batterien, passend zu 55mm-Installationsrahmen verschiedener Hersteller <br />
|-<br />
|Taster Unterputz, 2fach<br />
|[[HM-RC-2-PBU-FM_Unterputz-Wandsender|HM-RC-2-PBU-FM]]<br />
|[http://www.elv.de/homematic-funk-wandsender-2-fach-fuer-markenschalter-230-v-unterputzmontage.html Produkt] [https://files.elv.com/Assets/Produkte/14/1422/142237/Downloads/142237_funkwandsender_um.pdf Anleitung]<br />
|<br />
|230V, passend zu verschiedenen Installationsrahmen<br />
|-<br />
|Taster, 2fach<br />
|[[HM-PB-2-WM55_2fach-Funk-Wandtaster|HM-PB-2-WM55]]<br />
|[http://www.elv.de/homematic-funk-wandsender-2fach.html Produkt] [https://files.elv.com/Assets/Produkte/9/992/99240/Downloads/99240_HM_PB_2_WM55_UM.pdf Anleitung]<br />
|<br />
|2 AAA Batterien, passend zu Installationsrahmen verschiedener Hersteller<br />
|-<br />
|Taster, 3 x 2fach<br />
|[[HM-PB-6-WM55 6fach-Funk-Wandtaster|HM-PB-6-WM55]]<br />
|[http://www.elv.de/homematic-funk-wandtaster-6fach.html Produkt] [https://files.elv.com/Assets/Produkte/13/1301/130113/Downloads/130113_6fach_Wandtaster_um.pdf Anleitung]<br />
|<br />
|2 AAA Batterien, passend zu Installationsrahmen verschiedener Hersteller<br />
|}<br />
<br />
{| class="wikitable mw-datatable"<br />
!style="width:350px"|Einsatzzweck<br />
!style="width:150px"|fhem Wiki<br />
!style="width:200px"|ELV<br />
!style="width:150px"|Nachfolger<br />
!style="width:650px"|Zu beachten<br />
|-<br />
|Wandtaster mit OLED Display<br />
|[[HM-PB-4DIS-WM_Funk-Wandtaster_mit_Display|HM-PB-4Dis-WM]]<br />
|[http://www.elv.de/homematic-funk-wandtaster-mit-display.html Produkt] [https://files.elv.com/Assets/Produkte/8/859/85975/Downloads/85975_Display_Wandtaster_v1.2_UM.pdf Anleitung]<br />
|<br />
|3 AAA Batterien, kleines Display, nur altweiß (nicht reinweiß)<br />
|}<br />
<br />
{| class="wikitable mw-datatable"<br />
!style="width:350px"|Einsatzzweck<br />
!style="width:150px"|fhem Wiki<br />
!style="width:200px"|ELV<br />
!style="width:150px"|Nachfolger<br />
!style="width:650px"|Zu beachten<br />
|-<br />
|Tasterschnittstelle, 4fach<br />
|[[HM-PBI-4-FM_Funk-Tasterschnittstelle_4fach|HM-PBI-4-FM]]<br />
|[http://www.elv.de/homematic-hm-pbi-4-fm-funk-tasterschnittstelle-4fach-unterputzmontage.html Produkt] [https://files.elv.com/service/manuals/76120_HM_PBI_4_FM_UM_GE_eQ_3_um.pdf Anleitung]<br />
|<br />
||CR2032 Batterie, für die Kombination mit Installationstastern verschiedener Hersteller<br />
|}<br />
<br />
{| class="wikitable mw-datatable"<br />
!style="width:350px"|Einsatzzweck<br />
!style="width:150px"|fhem Wiki<br />
!style="width:200px"|ELV<br />
!style="width:150px"|Nachfolger<br />
!style="width:650px"|Zu beachten<br />
|-<br />
|Fernbedienung, 12 Tasten<br />
|[[HM-RC-12_Funkfernbedienung_12_Tasten|HM-RC-12]]<br />
|[http://www.elv.de/homematic-funk-fernbedienung-12-tasten-weiss-1.html Produkt] [https://files.elv.com/service/manuals/Homematic/73968_um.pdf Anleitung]<br />
|<br />
|3 AAA Batterien, In Schwarz als HM-RC-12-B<br />
|-<br />
|Fernbedienung, 4 Tasten<br />
|[[HM-RC-4-2_Funkfernbedienung_4_Tasten|HM-RC-4-2]]<br />
|[http://www.elv.de/homematic-funk-handsender-4-tasten.html Produkt] [https://files.elv.com/Assets/Produkte/10/1053/105397/Downloads/105397_4tasten_sender_um.pdf Anleitung]<br />
|<br />
|AAA Batterie, Schlüsselanhänger, verschiedene Varianten HM-RC-Key4-2, HM-RC-Sec4-2<br />
|-<br />
|Fernbedienung, 19 Tasten<br />
|HM-RC-19<br />
|ADDME<br />
|<br />
|<br />
|-<br />
|Fernbedienung, 8 Tasten<br />
|HM-RC-8<br />
|ADDME<br />
|<br />
|<br />
|}<br />
<br />
== Homematic Schalten ==<br />
{| class="wikitable mw-datatable"<br />
!style="width:350px"|Einsatzzweck: Aussen<br />
!style="width:150px"|fhem Wiki<br />
!style="width:200px"|ELV<br />
!style="width:150px"|Nachfolger<br />
!style="width:650px"|Zu beachten<br />
|-<br />
|Schalter Aufputz 4fach<br />
|[[HM-LC-Sw4-SM_4fach_Schaltaktor_Aufputz|HM-LC-Sw4-SM]]<br />
|[http://www.elv.de/homematic-funk-schaltaktor-4fach-aufputzmontage.html Produkt] [https://files.elv.com/Assets/Produkte/7/767/76796/Downloads/76796_hm_lc_sw4_sm_um.pdf Anleitung]<br />
|<br />
|230V, IP65, enge Bauweise<br />
|}<br />
<br />
{| class="wikitable mw-datatable"<br />
!style="width:350px"|Einsatzzweck: Hutschiene<br />
!style="width:150px"|fhem Wiki<br />
!style="width:200px"|ELV<br />
!style="width:150px"|Nachfolger<br />
!style="width:650px"|Zu beachten<br />
|-<br />
|Schalter <br />
|[[HM-LC-Sw1-DR_1fach_Schaltaktor_Hutschiene|HM-LC-Sw1-DR]]<br />
|[http://www.elv.de/homematic-1-kanal-schaltaktor-im-hutschienengehaeuse-1.html Produkt] [https://files.elv.com/Assets/Produkte/14/1413/141379/Downloads/141379_schaltaktor_um.pdf Anleitung]<br />
|<br />
||230V, mit Tastereingang, auch als Bausatz verfügbar<br />
|-<br />
|Schalter 4fach<br />
|[[HM-LC-Sw4-DR_4fach_Schaltaktor_Hutschiene|HM-LC-Sw4-DR]]<br />
|[http://www.elv.de/homematic-funk-schaltaktor-4fach-hutschiene.html Produkt] [https://files.elv.com/Assets/Produkte/9/918/91836/Downloads/91836_Funk_Schaltaktor_UM.pdf Anleitung]<br />
|<br />
|230V, 4 TE, kein Tastereingang, auch als Bausatz<br />
|}<br />
<br />
{| class="wikitable mw-datatable"<br />
!style="width:350px"|Einsatzzweck: Unterputz<br />
!style="width:150px"|fhem Wiki<br />
!style="width:200px"|ELV<br />
!style="width:150px"|Nachfolger<br />
!style="width:650px"|Zu beachten<br />
|-<br />
|Schalter <br />
|[[HM-LC-SW1-FM_Schaltaktor_1-fach_UP|HM-LC-Sw1-FM]]<br />
|[http://www.elv.de/homematic-hm-lc-sw1-fm-unterputzschalter-1fach.html Produkt] [https://files.elv.com/Assets/Produkte/7/767/76793/Downloads/76793_HM_LC_Sw1_FM_um.pdf Anleitung]<br />
|<br />
|230V, mit Tastereingang, 16A<br />
|-<br />
|Schalter 2fach<br />
|[[HM-LC-SW2-FM_Schaltaktor_2-fach_UP|HM-LC-Sw2-FM]]<br />
|[http://www.elv.de/homematic-funk-schaltaktor-2fach-unterputzmontage-1.html Produkt] [https://files.elv.com/service/manuals/76793_HM_Unterputzschalter_UM.pdf Anleitung]<br />
|<br />
|230V, mit Tastereingang, 5A zusammen. 2 x HM-LC-Sw1-FM empfohlen.<br />
|-<br />
|Schalter <br />
|[[HM-LC-Sw1PBU-FM_Unterputz-Schaltaktor_1-fach|HM-LC-Sw1PBU-FM]]<br />
|[http://www.elv.de/homematic-funk-schaltaktor-fuer-markenschalter-1fach-unterputzmontage.html Produkt] [https://files.elv.com/Assets/Produkte/10/1030/103029/Downloads/103029_FunkSchaltaktor_um.pdf Anleitung]<br />
|<br />
|230V, passend zu 55mm-Installationsrahmen verschiedener Hersteller <br />
|-<br />
|Schalter PEHA<br />
|[[HM-LC-Sw1PB-FM_Schaltaktor_mit_Tasteraufsatz_1fach|HM-LC-Sw1PB-FM]]<br />
|<br />
|<br />
|230V, End-of-Sale<br />
|-<br />
|Schalter 2fach PEHA<br />
|[[HM-LC-Sw2PB-FM_Schaltaktor_mit_Tasteraufsatz_2fach|HM-LC-Sw2PB-FM]]<br />
|<br />
|<br />
|230V, End-of-Sale<br />
|}<br />
<br />
{| class="wikitable mw-datatable"<br />
!style="width:350px"|Einsatzzweck: Zwischenstecker<br />
!style="width:150px"|fhem Wiki<br />
!style="width:200px"|ELV<br />
!style="width:150px"|Nachfolger<br />
!style="width:650px"|Zu beachten<br />
|-<br />
|Schalter Zwischenstecker<br />
|[[HM-LC-Sw1-Pl2_Funk-Zwischenstecker-Schaltaktor_1fach|HM-LC-Sw1-Pl2]]<br />
|<br />
|[[HM-LC-Sw1-Pl-DN-R1|HM-LC-Sw1-Pl-DN-R1]]<br />
|End-of-Sale<br />
|-<br />
|Schalter Zwischenstecker<br />
|[[HM-LC-Sw1-Pl-DN-R1|HM-LC-Sw1-Pl-DN-R1]]<br />
|[https://www.elv.de/homematic-132989-funk-schaltaktor-zwischenstecker-fuer-smart-home-hausautomation.html Produkt] [https://files.elv.com/Assets/Produkte/13/1329/132989/Downloads/HM-LC-Sw1-Pl-DN-R1_UM_GEFN_eQ-3_150407.pdf Anleitung]<br />
|<br />
|Nachfolger des HM-LC-Sw1-Pl2<br />
|-<br />
|Schalter Frankreich, Polen, Belgien<br />
|ADDME<br />
|ADDME<br />
|<br />
|Artikelnummer 141127<br />
|-<br />
|Schalter England, Irland<br />
|ADDME<br />
|ADDME<br />
|<br />
|Artikelnummer 131132<br />
|-<br />
|Schalter Italien<br />
|ADDME<br />
|ADDME<br />
|<br />
|Artikelnummer 141129<br />
|-<br />
|Schalter Schweiz<br />
|ADDME<br />
|ADDME<br />
|<br />
|Artikelnummer 141130<br />
|}<br />
<br />
{| class="wikitable mw-datatable"<br />
!style="width:350px"|Einsatzzweck: Batterie<br />
!style="width:150px"|fhem Wiki<br />
!style="width:200px"|ELV<br />
!style="width:150px"|Nachfolger<br />
!style="width:650px"|Zu beachten<br />
|-<br />
|Schalter 1fach<br />
|[[HM-LC-Sw1-Ba-PCB_1-Kanal-Funk-Schaltaktor_für_Batteriebetrieb|HM-LC-Sw1_Ba-PCB]]<br />
|[http://www.elv.de/elv-homematic-schaltaktor-fuer-batteriebetrieb-fertiggeraet.html Produkt] [https://files.elv.com/Assets/Produkte/10/1048/104895/Downloads/104895_Funk_Schaltaktor_um.pdf Anleitung]<br />
|<br />
|4-15VDC oder 2-3VDC, Bausatz<br />
|-<br />
|Schalter 4fach<br />
|[[HM-LC-Sw4-Ba-PCB_4-Kanal-Funk-Schaltaktor_für_Batteriebetrieb|HM-LC-Sw4-Ba-PCB]]<br />
|[http://www.elv.de/homematic-4-kanal-funk-schaltaktor-fuer-batteriebetrieb-bausatz.html Produkt] [https://files.elv.com/Assets/Produkte/13/1305/130557/Downloads/130557_hm_schaltaktor_um.pdf Anleitung]<br />
|<br />
|7-15VDC, 160mA, schaltet 4 x 42VDC/30VAC, 1A auch als Bausatz<br />
|}<br />
<br />
== Homematic Steuern ==<br />
Für die Konfiguration der Jalousieaktoren ist [[HomeMatic_Type_Blind]] hilfreich.<br />
<br />
{| class="wikitable mw-datatable"<br />
!style="width:350px"|Einsatzzweck<br />
!style="width:150px"|fhem Wiki<br />
!style="width:200px"|ELV<br />
!style="width:150px"|Nachfolger<br />
!style="width:650px"|Zu beachten<br />
|-<br />
|Jalousieaktor Unterputz<br />
|[[HM-LC-BL1-FM_Funk-Jalousieaktor|HM-LC-BL1-FM]]<br />
|[http://www.elv.de/homematic-funk-rollladenaktor-1fach-unterputzmontage.html Produkt] [https://files.elv.com/Assets/Produkte/7/767/76799/Downloads/76799_HM_LC_Sw1_FM_um.pdf Anleitung]<br />
|<br />
|230V, 250W Motorlast<br />
|-<br />
|Jalousieaktor Unterputz PEHA<br />
|[[HM-LC-BL1-PB-FM_Unterputz_Jalousieaktor_PEHA|HM-LC-BL1-PB-FM]]<br />
|<br />
|<br />
|230V, End-of-Sale<br />
|-<br />
|Jalousieaktor Aufputz<br />
|[[HM-LC-Bl1-SM_Funk-Jalousieaktor|HM-LC-Bl1-SM]]<br />
|[http://www.elv.de/homematic-funk-rollladenaktor-1fach-aufputzmontage.html Produkt] [https://files.elv.com/Assets/Produkte/7/768/76800/Downloads/76800_hm_lc_bl1_sm_um.pdf Anleitung]<br />
|<br />
|230V, 800W Motorlast<br />
|-<br />
|Jalousieaktor Unterputz<br />
|[[HM-LC-Bl1PBU-FM_Unterputz-Jalousieaktor|HM-LC-Bl1PBU-FM]]<br />
|[http://www.elv.de/homematic-funk-rollladenaktor-fuer-markenschalter-1fach-unterputzmontage.html Produkt] [https://files.elv.com/Assets/Produkte/10/1030/103038/Downloads/103038_FunkRollladenaktor_um.pdf Anleitung]<br />
|<br />
|230V Motorlast, passend zu 55mm-Installationsrahmen verschiedener Hersteller<br />
|}<br />
<br />
{| class="wikitable mw-datatable"<br />
!style="width:350px"|Einsatzzweck<br />
!style="width:150px"|fhem Wiki<br />
!style="width:200px"|ELV<br />
!style="width:150px"|Nachfolger<br />
!style="width:650px"|Zu beachten<br />
|-<br />
|Dimmer Zwischenstecker Anschnitt<br />
|[[HM-LC-Dim1L-Pl-2_Funk-Zwischenstecker-Dimmaktor_1fach_Phasenanschnitt|HM-LC-Dim1L-Pl-2]]<br />
|<br />
|HM-LC-Dim1L-Pl-3<br />
|End-of-Sales<br />
|-<br />
|Dimmer Zwischenstecker Anschnitt<br />
|[[HM-LC-Dim1L-Pl-2_Funk-Zwischenstecker-Dimmaktor_1fach_Phasenanschnitt|HM-LC-Dim1L-Pl-3]]<br />
|[http://www.elv.de/homematic-funk-dimmaktor-zwischenstecker-phasenanschnitt.html Produkt] [https://files.elv.com/Assets/Produkte/7/767/76797/Downloads/76797_HM-LC-Sw1-Pl-2_UM_GE_eQ-3_120723_um.pdf Anleitung]<br />
|<br />
|Phasen'''an'''schnitt, identische Konfiguration<br />
|-<br />
|Dimmer Zwischenstecker Anschnitt<br />
|HM-LC-Dim1T-Pl-3<br />
|ADDME<br />
|<br />
|230V, Phasen'''ab'''schnitt<br />
|-<br />
|Dimmer Unterputz PWM/LED<br />
|[[HM-LC-Dim1PWM-CV_Dimmaktor_PWM_DC-LED|HM-LC-Dim1PWM-CV]]<br />
|[http://www.elv.de/homematic-funk-dimmer-1-fach-12v-pwm-fertiggeraet.html Produkt] [https://files.elv.com/Assets/Produkte/9/994/99444/Downloads/99444_Funk_Dimmaktor_um.pdf Anleitung]<br />
|<br />
|12-24VDC, 60VA Anschlußleistung<br />
|-<br />
|Dimmer PWM/LED<br />
|[[HM-LC-RGBW-WM_Funk-RGBW-Controller|HM-LC-RGBW-WM]]<br />
|[http://www.elv.de/homematic-funk-rgbw-controller.html Produkt] [https://files.elv.com/Assets/Produkte/14/1419/141952/Downloads/141952_rgbw_controller_um.pdf Anleitung]<br />
|<br />
|12-24VDC, 34W je Kanal, auch als Bausatz erhältlich<br />
|-<br />
|Dimmer Unterputz<br />
|[[HM-LC-DIM1T-FM_1-Kanal-Dimmer_UP|HM-LC-Dim1T-FM]]<br />
|[http://www.elv.de/elv-1-kanal-unterputzdimmer-phasenabschnitt.html Produkt] [https://files.elv.com/Assets/Produkte/9/918/91816/Downloads/91816_HM_LC_Dim1T_FM_um.pdf Anleitung]<br />
|<br />
|230V, 180W Anschlußleistung, Phasen'''ab'''schnitt<br />
|-<br />
|Dimmer Zwischendecke<br />
|HM-LC-Dim1T-CV<br />
|ADDME<br />
|<br />
|230V, Phasen'''ab'''schnitt<br />
|-<br />
|Dimmer Zwischendecke<br />
|HM-LC-Dim1L-CV<br />
|ADDME<br />
|<br />
|230V, Phasen'''an'''schnitt<br />
|-<br />
|Dimmer Unterputz<br />
|[[HM-LC-Dim1TPBU-FM_1-Kanal-Dimmer_UP|HM-LC-Dim1TPBU-FM]]<br />
|[http://www.elv.de/homematic-funk-dimmaktor-1fach-fuer-markenschalter-phasenabschnitt-unterputzmontage.html Produkt] [https://files.elv.com/Assets/Produkte/10/1030/103020/Downloads/103020_FunkDimmaktor_um.pdf Anleitung]<br />
|<br />
|230V, 180VA Anschlußleistung, passend zu 55mm-Installationsrahmen verschiedener Hersteller <br />
|-<br />
|Dimmer Aufputz, 2fach Abschnitt<br />
|HM-LC-Dim2T-SM<br />
|ADDME<br />
|<br />
|230V, Phasen'''ab'''schnitt<br />
|-<br />
|Dimmer Aufputz, 2fach Anschnitt<br />
|HM-LC-Dim2L-SM<br />
|ADDME<br />
|<br />
|230V, Phasen'''an'''schnitt<br />
|}<br />
<br />
== Homematic Messen ==<br />
{| class="wikitable mw-datatable"<br />
!style="width:350px"|Einsatzzweck<br />
!style="width:150px"|fhem Wiki<br />
!style="width:200px"|ELV<br />
!style="width:150px"|Nachfolger<br />
!style="width:650px"|Zu beachten<br />
|-<br />
|Zählermodul Gas, Strom<br />
|[[HM-ES-TX-WM_Zählersensor_für_Strom-_und_Gaszähler|HM-ES-TX-WM]]<br />
|[http://www.elv.de/homematic-komplettbausatz-zaehlersensor-sendeeinheit-strom-gas.html Produkt] [https://files.elv.com/Assets/Produkte/14/1401/140143/Downloads/140143_sensor_um.pdf Anleitung]<br />
|<br />
|Nur als Bausatz verfügbar, 4 AA Batterien, Gaszähler-Reedrelais leicht tauschbar<br />
|-<br />
|Schalter Hutschiene mit Leistungsmessung<br />
|[[HM-ES-PMSw1-DR_Hutschienen-Schaltaktor_mit_Leistungsmessung|HM-ES-PMSw1-DR]]<br />
|[http://www.elv.de/output/controller.aspx?cid=74&detail=10&detail2=51780 Produkt] [https://files.elv.com/Assets/Produkte/14/1411/141107/Downloads/HM-ES-PMSw1-DR_UM_G_150506.pdf Anleitung]<br />
|<br />
|230V, nur als Bausatz verfügbar, hohe Funklast durch Messung<br />
|-<br />
|Schalter Zwischenstecker mit Leistungsmessung<br />
|[[HM-ES-PMSw1-Pl_Funk-Schaltaktor_1-fach_mit_Leistungsmessung|HM-ES-PMSw1-Pl]]<br />
|[http://www.elv.de/homematic-funk-schaltaktor-1fach-mit-leistungsmessung-zwischenstecker.html Produkt] [https://files.elv.com/Assets/Produkte/13/1302/130248/Downloads/130248_schaltaktor_messen_um.pdf Anleitung]<br />
|<br />
|230V Zwischenstecker, hohe Funklast durch Messung<br />
|-<br />
|Füllstandsmesser<br />
|[[HM-Sen-Wa-Od_kapazitiver_Funk-Füllstandsmesser|HM-SEN-WA-OD]]<br />
|[http://www.elv.de/kapazitiver-fuellstandsmesser-hm-sen-wa-od-komplettbausatz.html Produkt] [https://files.elv.com/Assets/Produkte/10/1049/104945/Downloads/104945_HMSenWaOd_um.pdf Anleitung]<br />
|<br />
|3 AA Batterien, kapazitive Messung, z.B. für Zisternen<br />
|-<br />
|Temperatur/Luftfeuchte aussen<br />
|[[HM-WDS10-TH-O_Funk-Temperatur-/Feuchtesensor_außen_(OTH)|HM-WDS10-TH-O]]<br />
|[http://www.elv.de/homematic-hm-wds10-th-o-funk-temperatur-luftfeuchtesensor-oth.html Produkt] [https://files.elv.com/Assets/Produkte/7/769/76923/Downloads/76923_HM_WDS10_TH_O_UM_GE_eQ3_120921_um.pdf Anleitung]<br />
|<br />
|2 AA Batterien, Falsche Werte bei schwachen Batterien, nur bis -19,9°C<br />
|-<br />
|Temperatur/Luftfeuchte aussen<br />
|HM-WDS30-TO<br />
|[http://www.elv.de/homematic-hm-wds30-t-o-funk-temperatursensor-aussen.html Produkt] [https://files.elv.com/service/manuals/76857_HM-WDS30_T_O_GE.pdf Anleitung]<br />
|<br />
|Abgesetzter Sensor, nur bis -19,9°C<br />
|-<br />
|Temperatur/Luftfeuchte innen<br />
|[[HM-WDS40-TH-I_Funk-Temperatur-/Feuchtesensor_innen_(IT)|HM-WDS40-TH-I]]<br />
|[http://www.elv.de/homematic-funk-innensensor-ith.html Produkt] [https://files.elv.com/service/manuals/76998_HM_GE_WDS40_TH_I_GE_V1_1.pdf Anleitung]<br />
|<br />
|<br />
|-<br />
|Kombi-Sensor Wetter Aussen<br />
|[[HM-WDS100-C6-O_Funk-Kombi-Sensor_OC3|HM-WDS100-C6-O]]<br />
|[http://www.elv.de/homematic-funk-kombisensor.html Produkt] [https://files.elv.com/Assets/Produkte/13/1321/132192/Downloads/132192_kombisensor_um.pdf Anleitung]<br />
|<br />
|Im Vergleich zu Vantage Pro schlechte Messungen, schlechtere Böen-Erkennung<br />
|-<br />
|Differenz-Temperatur<br />
|[[HM-WDS30-OT2-SM_Differenz-Temperatur-Sensor|HM-WDS30-OT2-SM]]<br />
|[http://www.elv.de/homematic-differenz-temperatur-sensor-fuer-smart-home-hausautomation-1.html Produkt] [https://files.elv.com/Assets/Produkte/14/1434/143420/Downloads/143420_temperatur_sensor_um.pdf Anleitung]<br />
|<br />
|Fühler nicht dauerhaft wasserdicht<br />
|}<br />
<br />
== Homematic Sicherheit ==<br />
{| class="wikitable mw-datatable"<br />
!style="width:350px"|Einsatzzweck<br />
!style="width:150px"|fhem Wiki<br />
!style="width:200px"|ELV<br />
!style="width:150px"|Nachfolger<br />
!style="width:650px"|Zu beachten<br />
|-<br />
|Bewegungsmelder Innen<br />
|[[HM-Sec-MDIR_Funk-Bewegungsmelder_innen|HM-SEC-MDIR]]<br />
|<br />
|HM-Sec-MDIR-2<br />
|End-of-Sale, Nachfolgemodell identisch zu konfigurieren<br />
|-<br />
|Bewegungsmelder Innen<br />
|[[HM-Sec-MDIR_Funk-Bewegungsmelder_innen|HM-SEC-MDIR-2]]<br />
|[http://www.elv.de/homematic-bewegungsmelder-1.html Produkt] [https://files.elv.com/Assets/Produkte/13/1317/131776/Downloads/131776_hm_sec_mdir_2_um.pdf Anleitung]<br />
|<br />
|3 AA Batterien<br />
|-<br />
|Bewegungsmelder Außen<br />
|[[HM-Sen-MDIR-O_Funk-IR-Bewegungsmelder_außen|HM-SEN-MDIR-O]]<br />
|<br />
|HM-SEN-MDIR-O-2<br />
|End-of-Sale, Nachfolgemodell identisch zu konfigurieren<br />
|-<br />
|Bewegungsmelder außen<br />
|[[HM-Sen-MDIR-O_Funk-IR-Bewegungsmelder_außen|HM-SEN-MDIR-O-2]]<br />
|[http://www.elv.de/homematic-funk-ir-bewegungsmelder-aussen-2.html Produkt] [https://files.elv.com/Assets/Produkte/10/1041/104109/Downloads/104109_Funk_IR_um.pdf Anleitung]<br />
|<br />
|Es wird von Problemen mit Ameisen im Sensor und Ausfällen nach zwei Jahren berichtet<br />
|-<br />
|Bewegungsmelder außen<br />
|[[HM-Sen-MDIR-SM_Außen-Bewegungsmelder|HM-SEN-MDIR-SM]]<br />
|[http://www.elv.de/homematic-hm-sen-mdir-aussen-bewegungsmelder-komplettbausatz.html Produkt] [https://files.elv.com/service/manuals/84579_HM_Sen_MDIR_SM_um.pdf Anleitung]<br />
|<br />
|IP65 für Außeneinsatz, Bausatz<br />
|}<br />
<br />
{| class="wikitable mw-datatable"<br />
!style="width:350px"|Einsatzzweck<br />
!style="width:150px"|fhem Wiki<br />
!style="width:200px"|ELV<br />
!style="width:150px"|Nachfolger<br />
!style="width:650px"|Zu beachten<br />
|-<br />
|Fenster Drehgriffkontakt<br />
|[[HM-Sec-RHS_Funk-Fenster-Drehgriffkontakt|HM-SEC-RHS]]<br />
|[http://www.elv.de/homematic-funk-fenster-drehgriffkontakt-1.html Produkt] [https://files.elv.com/service/manuals/75643_HM_Sec_RHS_GE_V1_0.pdf Anleitung]<br />
|<br />
|LR44 Batterien, [http://www.techwriter.de/beispiel/funkeig1.htm Sendeeigenschaften verbessern]<br />
|-<br />
|Tür/Fenster-Kontakt<br />
|[[HM-SEC-SC_Tür-Fensterkontakt|HM-SEC-SC]]<br />
|[http://www.elv.de/homematic-hm-sec-sc-funk-tuer-fensterkontakt-1.html Produkt] [https://files.elv.com/service/manuals/76788_HM_Sec_SC_GE_V1_0_UM.pdf Anleitung]<br />
|<br />
|LR44 Batterien, [[HomeMatic_Type_threeStateSensor|Notwendige Konfiguration]]<br />
|-<br />
|Tür/Fenster-Kontakt (optisch)<br />
|[[HM-Sec-SCo_Tür-Fensterkontakt,_optisch|HM-SEC-SCo]]<br />
|[http://www.elv.de/homematic-ir-tuer-fensterkontakt.html Produkt] [https://files.elv.com/Assets/Produkte/13/1302/130297/Downloads/130297_fensterkontakt_optisch_um.pdf Anleitung]<br />
|<br />
|AAA Batterie, [[HomeMatic_Type_threeStateSensor|Notwendige Konfiguration]]<br />
|-<br />
|Zylinderschloss steuern<br />
|[[HM-SEC-KEY_KeyMatic|HM-SEC-KEY]]<br />
|[http://www.elv.de/homematic-funk-tuerschlossantrieb-keymatic-weiss-inkl-funk-handsender.html Produkt] [https://files.elv.com/Assets/Produkte/13/1317/131761/Downloads/131761_keymatic_um.pdf Anleitung]<br />
|<br />
|3 AA Batterien, eigener AES-Key ''dringend'' empfohlen, auch in Silber<br />
|}<br />
<br />
{| class="wikitable mw-datatable"<br />
!style="width:350px"|Einsatzzweck<br />
!style="width:150px"|fhem Wiki<br />
!style="width:200px"|ELV<br />
!style="width:150px"|Nachfolger<br />
!style="width:650px"|Zu beachten<br />
|-<br />
|Rauchmelder<br />
|[[HM-SEC-SD_Rauchmelder|HM-SEC-SD]]<br />
|<br />
|HM-Sec-SD-2<br />
|End-of-Sale<br />
|-<br />
|Rauchmelder<br />
|[[HM-SEC-SD_Rauchmelder|HM-SEC-SD-2]]<br />
|[http://www.elv.de/homematic-funk-rauchmelder-hm-sec-sd-2.html Produkt] [https://files.elv.com/Assets/Produkte/13/1314/131408/Downloads/131408_rauchmelder_um.pdf Anleitung]<br />
|<br />
|Lithium, 10 Jahresbatterie<br />
|-<br />
|Sirenensteuerung<br />
|[[HM-Sec-SFA-SM_Funk-Sirenensteuerung|HM-SEC-SFA-SM]]<br />
|[http://www.elv.de/homematic-funk-sirenenansteuerung-bidcos.html Produkt] [https://files.elv.com/Assets/Produkte/8/843/84392/Downloads/84392_HM_Sec_SFA_GE_V1_1_UM.pdf Anleitung]<br />
|<br />
|230V, stellt 2x12V 1A für Sirene und Blitzer zur Verfügung, Notakku 1.2Ah<br />
|-<br />
|Neigungssensor<br />
|[[HM-SEC-TIS_Funk-Neigungssensor|HM-SEC-TIS]]<br />
|[http://www.elv.de/homematic-funk-neigungssensor-hm-sec-tis.html Produkt] [https://files.elv.com/Assets/Produkte/8/831/83146/Downloads/83146_neu_HM_Sec_TIS_GE_UM.pdf Anleitung]<br />
|<br />
|CR2032, erkennt nur offen/zu, keine Winkel<br />
|-<br />
|Wassermelder<br />
|[[HM-Sec-WDS_Funk-Wassermelder|HM-SEC-WDS]]<br />
|<br />
|HM-SEC-WDS-2<br />
|End-of-Sale<br />
|-<br />
|Wassermelder<br />
|[[HM-Sec-WDS_Funk-Wassermelder|HM-SEC-WDS-2]]<br />
|[http://www.elv.de/homematic-funk-wassermelder.html Produkt] [https://files.elv.com/service/manuals/Homematic/83459_HM_Sec_WDS_D_v1_0_UM.pdf Anleitung]<br />
|<br />
|2 AA Batterien, unterstützt nicht die Alarmzentrale HM-SEC-Cen<br />
|-<br />
|Regensensor<br />
|[[HM-Sen-RD-O_Funk-Regensensor|HM-SEN-RD-O]]<br />
|[http://www.elv.de/homematic-funk-regensensor-1.html Produkt] [https://files.elv.com/Assets/Produkte/13/1302/130220/Downloads/130220_hm_regensensor_um.pdf Anleitung]<br />
|<br />
|7,5-30VDC 1W max, auch als Bausatz verfügbar<br />
|}<br />
<br />
== Homematic Anzeigen ==<br />
{| class="wikitable mw-datatable"<br />
!style="width:350px"|Einsatzzweck<br />
!style="width:150px"|fhem Wiki<br />
!style="width:200px"|ELV<br />
!style="width:150px"|Nachfolger<br />
!style="width:650px"|Zu beachten<br />
|-<br />
|Retro-Anzeige<br />
|[[HM-Dis-TD-T_Retro_Anzeige|HM-Dis-TD-T]]<br />
|[http://www.elv.de/homematic-statusanzeige-mit-batteriebetrieb-und-klappanzeige-komplettbausatz.html Produkt] [https://files.elv.com/Assets/Produkte/10/1037/103721/Downloads/103721_HM-Dis-TD-T_UM_G_150226_um.pdf Anleitung]<br />
|<br />
|Nur als Bausatz (enge Bestückung) verfügbar, Temperaturbereich 0°-50°C<br />
|-<br />
|Farbige Statusanzeige OLED<br />
|[[HM-Dis-WM55_Funk_Statusanzeige|HM-Dis-WM55]]<br />
|[http://www.elv.de/homematic-funk-statusanzeige-aufputzmontage-bausatz.html Produkt] [https://files.elv.com/Assets/Produkte/13/1326/132656/Downloads/132656_statusanzeige.pdf Anleitung]<br />
|<br />
|Passend zu 55mm-Installationsrahmen verschiedener Hersteller<br />
|-<br />
|B&W Statusanzeige ePaper<br />
|HM-Dis-EP-WM55<br />
|[http://www.elv.de/homematic-komplettbausatz-funk-statusanzeige-mit-e-paper-display.html Produkt] [https://files.elv.com/Assets/Produkte/14/1424/142414/Downloads/HM-Dis-EP-WM55_UM_GE_142413_160519.pdf Anleitung]<br />
|<br />
|Passend zu 55mm-Installationsrahmen verschiedener Hersteller<br />
|-<br />
|LED Statusanzeige 16fach<br />
|[[HM-OU-LED16_Funk-Statusanzeige_LED16|HM-OU-LED16]]<br />
|[http://www.elv.de/elv-homematic-statusanzeige-fertiggeraet.html Produkt] [https://files.elv.com/Assets/Produkte/10/1047/104798/Downloads/104798_HM_OU_LED16_um.pdf Anleitung]<br />
|<br />
|7,5VDC Netzteil<br />
|-<br />
|Funkgong mit Signalleuchte<br />
|[[HM-OU-CFM-Pl_MP3_Funk-Gong_mit_Signalleuchte|HM-OU-CFM-Pl]]<br />
|[http://www.elv.de/homematic-mp3-funk-tuergong-mit-signal-led.html Produkt] [https://files.elv.com/Assets/Produkte/9/990/99060/Downloads/99060_tuergong_um.pdf Anleitung]<br />
|<br />
|230V Steckdose, unterstützt abspielen von MP3s von Speicherkarte<br />
|}<br />
<br />
== Homematic Heizen ==<br />
Die Heizungsgeräte sind für den Inneneinsatz gedacht und werden mit AA/AAA-Batterien betrieben. Die Wiki-Seiten [[HomeMatic_Type_Thermostat|Homematic-Thermostaten]] und [[HomeMatic_HMInfo_TempList/Weekplan|Homematic-Temperaturlisten]] geben einen Überblick, wie Temperaturlisten zu lesen und zu speichern sind. Für den HM-CC-RT-DN gibt es bei ELV im Zubehör-Bereich eine große Anzahl von Ventiladaptern aus Plastik und Messing, manchmal helfen auch Cent-Münzen als Unterlegscheibe, erhöhen jedoch die Lautstärke.<br />
<br />
{| class="wikitable mw-datatable"<br />
!style="width:350px"|Einsatzzweck<br />
!style="width:150px"|fhem Wiki<br />
!style="width:200px"|ELV<br />
!style="width:150px"|Nachfolger<br />
!style="width:650px"|Zu beachten<br />
|-<br />
|Heizkörperthermostat<br />
|[[HM-CC-RT-DN_Funk-Heizk%C3%B6rperthermostat|HM-CC-RT-DN]]<br />
|[http://www.elv.de/homematic-heizkoerperthermostat-1.html Produkt] [https://files.elv.com/Assets/Produkte/10/1051/105155/Downloads/105155_thermostat_um.pdf Anleitung]<br />
|<br />
|<br />
|-<br />
|Heizkörperthermostat<br />
|[[HM-CC-VD_Funk-Stellantrieb|HM-CC-VD]]<br />
|<br />
|HM-CC-RT-DN<br />
|End-of-Sale<br />
|-<br />
|Wandthermostat<br />
|[[HM-CC-TC_Funk-Wandthermostat|HM-CC-TC]]<br />
|<br />
|HM-TC-IT-WM-W-EU<br />
|End-of-Sale<br />
|-<br />
|Wandthermostat<br />
|[[HM-TC-IT-WM-W-EU_Funk-Wandthermostat_AP|HM-TC-IT-WM-W-EU]]<br />
|[http://www.elv.de/homematic-funk-wandthermostat-1.html Produkt] [https://files.elv.com/Assets/Produkte/13/1320/132030/Downloads/132030_thermostat_um.pdf Anleitung]<br />
|<br />
|Passend zu Installationsrahmen verschiedener Hersteller<br />
|}<br />
<br />
== Homematic Wired ==<br />
Alle Homematic-Wired Geräte sind zur Hutschienen-Montage (DIN Rail) innerhalb eines Schaltschrankes gedacht. Die Geräte benötigen zum Betrieb ein Netzteil 24V DC innerhalb des Schaltschrankes. Der [https://de.wikipedia.org/wiki/EIA-485 RS485]-Bus wird von dem LAN-Gateway bereitgestellt und unterstützt maximal 127 Module. Zur Verkabelung eignet sich JSTY 4x2x0.6-Kabel.<br />
<br />
{| class="wikitable mw-datatable"<br />
!style="width:350px"|Einsatzzweck<br />
!style="width:150px"|fhem Wiki<br />
!style="width:200px"|ELV<br />
!style="width:150px"|Nachfolger<br />
!style="width:650px"|Zu beachten<br />
|-<br />
|LAN-Gateway<br />
|HMW-Sys-OP-DR<br />
|[http://www.elv.de/homematic-rs485-gateway-1.html Produkt] [https://files.elv.com/Assets/Produkte/10/1037/103755/Downloads/103755_rs485_gateway_um.pdf Anleitung]<br />
|<br />
|-<br />
|IO-Modul, 12xIN<br />
|HMW-Sen-SC-12-DR<br />
|[http://www.elv.de/homematic-wired-rs485-schliesserkontakt-12-eingaenge-hutschienenmontage.html Produkt] [https://files.elv.com/Assets/Produkte/8/858/85840/Downloads/85840_HMW_Sen_SC_12_DR_UM.pdf Anleitung]<br />
|<br />
|<br />
|-<br />
|IO-Modul 12xIN, 14xOUT<br />
|[[HMW-IO-12-Sw14-DR_Wired_RS485_I/O-Modul_12_Eingänge_14_Ausgänge|HMW-IO-12-SW14-DR]]<br />
|[http://www.elv.de/homematic-wired-rs485-i-o-modul-12-eingaenge-14-ausgaenge.html Produkt] [https://files.elv.com/Assets/Produkte/9/920/92011/Downloads/wired_rs485_um.pdf Anleitung]<br />
|<br />
|<br />
|-<br />
|IO-Modul 12xIN, 7xOUT<br />
|[[HMW-IO-12-Sw7-DR_Wired_RS485_I/O-Modul_12_Eingänge_7_Ausgänge|HMW-IO-12-SW7-DR]]<br />
|[http://www.elv.de/homematic-wired-rs485-i-o-modul-12-eingaenge-7-schaltausgaenge-1.html Produkt] [https://files.elv.com/Assets/Produkte/7/768/76805/Downloads/76805_HMWIO12DRV1_02_UM.pdf Anleitung]<br />
|<br />
|<br />
|-<br />
|Dimmer, Phasenanschnitt<br />
|HMW-LC-Dim1L-DR<br />
|[http://www.elv.de/homematic-wired-rs485-dimmaktor-1fach-phasenanschnitt-1.html Produkt] [https://files.elv.com/Assets/Produkte/7/768/76803/Downloads/76803_hmw_lc_dim1l_dr_um.pdf Anleitung]<br />
|<br />
|<br />
|-<br />
|Jalousieaktor<br />
|HMW-LC-Bl1-DR<br />
|[http://www.elv.de/homematic-wired-hmw-lc-bl1-dr-wired-rs485-rollladenaktor-1fach.html Produkt] [https://files.elv.com/Assets/Produkte/7/768/76802/Downloads/76802_hmw_lc_bl1_dr_um.pdf Anleitung]<br />
|<br />
|<br />
|-<br />
|Schalter, 2fach<br />
|HMW-LC-Sw2-DR<br />
|[http://www.elv.de/homematic-wired-hmw-lc-sw2-dr-rs485-schaltaktor-2fach.html Produkt] [https://files.elv.com/Assets/Produkte/7/768/76801/Downloads/76801_hmw_lc_sw2_dr_um.pdf Anleitung]<br />
|<br />
|<br />
|-<br />
|Überspannungsschutz<br />
|HMW-Sys-OP-DR<br />
|[http://www.elv.de/homematic-wired-rs485-ueberspannungsschutz.html Produkt] [https://files.elv.com/Assets/Produkte/8/859/85978/Downloads/85978_HMW_Sys_OP_DR_UM.pdf Anleitung]<br />
|<br />
|<br />
|-<br />
|Busabschluss-Widerstand<br />
|HMW-Sys-Tm-DR<br />
|[http://www.elv.de/homematic-wired-rs485-busabschluss-widerstand-hutschienenmontage-1.html Produkt] [https://files.elv.com/Assets/Produkte/7/768/76807/Downloads/75168_HMW_Sys_TM_UM.pdf Anleitung]<br />
|<br />
|<br />
|}<br />
<br />
[[Kategorie:HomeMatic Components|2Info]]</div>Martinp876http://wiki.fhem.de/w/index.php?title=HomeMatic_Devices_pairen&diff=23898HomeMatic Devices pairen2017-12-29T10:32:09Z<p>Martinp876: </p>
<hr />
<div>HomeMatic Geräte müssen mit dem für das HomeMatic-Protokoll eingesetzten IO-Device (zB [[CUL]], CUN, [[HomeMatic|Homematic IO's]]) ''[[Pairing (HomeMatic)|gepairt]]'' (deutsch: "gepaart") werden, damit sie von FHEM gesteuert oder ausgelesen werden können.<br />
<br />
<br />
Die Adresse eines HomeMatic Gerätes ist nicht frei einstellbar, sondern für jedes Gerät fest vorgegeben. Da die HM-Geräte über eine sehr komplexe Kanalstruktur verfügen, empfiehlt sich daher, die Geräte in FHEM per ''autocreate'' Funktion anlegen zu lassen, Eine nachträgliche Umbenennung oder manuelle Bearbeitung der erzeugten Konfigurationsdaten ist problemlos möglich.<br />
<br />
Zunächst mal muss man einen [[HomeMatic_Installieren|CUL/CUN/Homematic IO installieren]]. <br />
<br />
Einige Geräte werden mit aktivierter [[AES Encryption]] ausgeliefert (Meistens, aber nicht immer mit SEC im Namen). Das Anlernen an HM IO's funktioniert ohne Probleme, für alle CUL Derivate muss unbedingt der Hinweis im Artikel AES Encryption im Abschnitt I/O-Device <-> Gerät beachtet werden. '''Die dort beschriebene Installation sollte generell vorgenommen werden!'''<br />
<br />
Danach geht es hier weiter:<br />
<br />
= Grundlagen=<br />
Durch das Pairing wird ein HM-Gerät genau einem IO-Device (zB CUL) zugeordnet. Wenn ein Gerät mit dem IO-Device gepairt ist, kann es darüber gesteuert werden. <br />
<br />
Beim Pairing wird die HMID des IO-Device in das Gerät geschrieben. Das Pairing findet also im Wesentlichen im Gerät statt, nicht in FHEM selbst.<br />
<br />
Zu bemerken ist, dass ein IO-Device (zB CUL) standardmäßig die ID F11034 von FHEM erhält. Da viele HM-Geräte das IO-Device nur anhand der HMIDs erkennen, können alle in Reichweite der HM-Geräte befindlichen IO-Devices mit der in das HM-Gerät geschriebenen HMID das HM-Gerät steuern. Hinzu kommt, dass die ''autocreate'' Funktion die in Reichweite befindlichen HM-Geräte findet und automatisch einbindet. Nachbarn, die IO-Devices mit der gleichen HMID betreiben, können also HM-Geräte untereinander sehen und steuern!<br />
<br />
Es ist daher dringen zu empfehlen, die HMID vor dem Pairing der HM-Geräte mit: <br />
<br />
attr <CUL> hmId <6-stellige Hexadresse><br />
<br />
zu individualisieren. <br />
<br />
Gepairt wird nur das Device. Die Channels sind dem Device untergeordnet und somit implizit auch gepairt. <br />
<br />
'''Achtung:''' Ist ein Device gepairt werden Konfigurationsänderungen über die Zentrale (FHEM) vorgenommen. Man kann u.a. keine Kanäle mehr ''direkt'' peeren (verknüpfen). Stattdessen verwendet man Kommandos in FHEM. Siehe <u>[[Homematic_Peering_Beispiele|peeren]]</u><br />
<br />
= IO-Device in den Pairing-Modus versetzen =<br />
* CUL/CUN/HMLAN Konfigurator in den "Akzeptiere-Pairing-Requests-Modus" bringen:<br />
<br />
set <CUL> hmPairForSec 600<br />
<br />
600 bedeutet hier, dass das IO-Device 600 Sekunden, also 10 Minuten lang im Pairing-Modus ist.<br />
<br />
Bei aktivem Pairing-Modus gibt das IO-Device folgende ''Internals'' Variable zurück: <br />
<br />
hmPair 1<br />
<br />
Alternativ kann <br />
<br />
set <CUL> hmPairSerial <serial><br />
<br />
genutzt werden.<br />
<br />
= Devices pairen =<br />
<br />
Das Gerät wird in den Anlern- oder auch Konfigurationsmode versetzt. Es sendet hierzu eine entsprechende Nachricht an alle. <br />
Das Vorgehen ist stark vom Gerät(Typ) abhängig, bitte unbedingt das Handbuch lesen: Stichwort "anlernen". <br />
<br />
Falls das Gerät einen separaten Anlernknopf hat, ist der normalerweise nur ganz kurz zu drücken. <br />
Danach beginnt die LED regelmäßig zu blinken.<br />
<br />
Hat das Gerät keinen separaten Anlernknopf, muss in der Regel eine Taste solange gedrückt werden, bis die LED anfängt regelmäßig zu blinken.<br />
<br />
Kommt der Anlernvorgang in Gang, wird dies durch ein wechselndes, schnelles Blinken signalisiert. Kommt kein Anlernvorgang zustande, blinkt die LED regelmäßig für einen bestimmten Zeitraum (ca. 20 sec). <br />
Ist das Gerät schon gepairt, werden bei batteriebetriebenen Geräten eventuell auch noch nicht übertragende Daten gesendet. Dabei blinkt die LED auch unregelmäßig.<br />
{{Randnotiz|RNText=Hinweis: Das genaue Vorgehen ist bei jedem Gerätetyp anders -> unbedingt Handbuch genau lesen!}}<br />
In FHEM werden nun:<br />
* alle fehlenden Devices und Channels angelegt<br />
* das Register pairCentral im Device gesetzt. <br />
<br />
Ein save danach sichert die neu gepairten Geräte in der Konfiguration.<br />
<br />
Hinweis: Auch mit hmPairForSec kann jeweils nur '''ein''' Device gepaired werden. Für mehrere Devices den Vorgang bitte wiederholen.<br />
<br />
= Pairing verifizieren =<br />
Nur weil ein Gerät angelegt wurde, heißt das '''nicht''', dass es auch gepaired ist. In den Readings eines Devices muss stehen (list <name> oder im Webinterface):<br />
<br />
R_pairCentral 0xABCDEF<br />
<br />
ABCDEF steht dabei für die HMID des IO-Device (zB CUL). Wurde für das IO-Device kein attribute mit einer individuellen HMID gesetzt, sollte hier die Standard-ID F11034 stehen. Die führende 0x steht für den Hinweis auf eine HEX-Adresse. <br />
<br />
Ist das Pairing noch nicht abgeschlossen, kann man nach kurzer Pause den Befehl: <br />
<br />
set <HM-Gerät> getConfig <br />
<br />
absetzen, um zu prüfen, ob sich der Status zwischenzeitlich geändert hat. Wenn das Reading R_pairCentral nicht auftaucht oder der Wert mit set_ beginnt hat das Pairing '''nicht''' geklappt. Man kann entweder:<br />
* noch einmal probieren, ein getConfig auszulösen - vielleicht hat das Lesen nicht funktioniert<br />
* noch einmal pairen - das schadet nichts<br />
* die Anlerntaste / Configtaste / irgendeine Taste am Gerät (hängt vom konkreten Device ab) wiederholt drücken um die Datenübertragung anzustoßen.<br />
<br />
Alternativ kann man auch mit HMinfo einen Config check durchführen:<br />
<br />
define hm HMInfo<br />
get hm configCheck<br />
<br />
= Vorgehen bei Problemen =<br />
<br />
Wenn das Pairing nicht erfolgreich ist, das Gerät sich also nicht steuern lässt, ist es möglich, dass es schon bzw. noch mit einem anderen IO-Device gepairt ist. Dann das Gerät in den Auslieferungszustand bringen (siehe Handbuch, oft Knopf mindestens 5 Sekunden drücken, bis es blinkt, dann loslassen und nochmals 5 Sekunden drücken, bis es schneller blinkt) und danach erneut pairen. <br />
<br />
Alternativ kann das Pairing per Befehl gelöst werden. Siehe dazu unten. <br />
<br />
Wenn das zu pairende Geräte ein Empfänger ist, kann mit FHEM per Telnet oder in der Kommandozeile des Webinterfaces folgendes Kommando abgesetzt werden:<br />
<br />
set <CUL> hmPairSerial <10-stellige Seriennummer><br />
<br />
Die 10-stellige Seriennummer ist beim Empfängern idR. auf der Rückseite des Geräte aufgedruckt. Die Seriennummer fängt normalerweise mit Buchstaben an und endet mit Zahlen.<br />
<br />
Es gilt auch sicherzustellen, dass das zu pairende Gerät nicht bereits zuvor mit der Homematic Config Software gepairt wurde. Ist dies der Fall, so sollte das Pairing in der Homematic Config Software gelöscht und das Pairing in FHEM erneut durchgeführt werden.<br />
<br />
Beim Pairen ist, wie im normalen Betrieb auch, ein Mindestabstand (etwa 1-2 Meter) zwischen dem Sender der Zentrale (CUL, HMLAN etc.) einzuhalten, da die Funkempfänger sonst mit Übersteuerung reagieren und keine Kommunikation zustande kommt.<br />
Außerdem kann die Funklast beim Auslesen einer unfangreichen Konfiguration eines Gerätes bereits nach wenigen Versuchen das Limit der 1%-Regel erreichen. Sollte also scheinbar keine Kommunikation stattfinden können, ist auch zu prüfen, ob der Zentralensender sich deswegen temporär deaktiviert hat.<br />
<br />
= Gezieltes Pairing =<br />
Bei bereits bekanntem HM-Gerät kann man mit:<br />
<br />
set <Name HM-Gerät> pair<br />
<br />
das pairing überschreiben. Es funktioniert aber nur, wenn schon ein IO-Device eingetragen ist.<br />
<br />
= Pairing lösen =<br />
Das Pairing kann mit:<br />
<br />
set <Name HM-Gerät> unpair<br />
<br />
gelöst werden. Wichtig ist dabei, dass das IO-Device, das entpairt werden soll, mit der ursprünglich in das HM-Gerät geschriebenen HMID konfiguriert ist. <br />
<br />
Sollte man z.B. ein HomeMatic HM-CC-RT-DN Funk-Heizkörperthermostat und ein Fensterkontakt verbunden haben, so steht unter THERMOSTAT_WindowRec im Attribut peerIDs die ID des Fensterkontakts.<br />
Bei einem Defekt des Fensterkontakts sollte man wie im HM-CC-RT-DN beschrieben das unset durchführen. Hat man aber das Device Fensterkontakt gelöscht und das Pairing nicht durchgeführt, so kann man die Zuordnung im Heizkörperthermostat dennoch mit folgenden Befehl aufheben.<br />
<br />
set <Name HM-Gerät>_WindowRec peerBulk <peerID> unset<br />
<br />
<br />
[[Kategorie:HomeMatic Components|1toolsAndWork]]<br />
[[Kategorie:HOWTOS]]</div>Martinp876http://wiki.fhem.de/w/index.php?title=HomeMatic_Firmware_Update&diff=23897HomeMatic Firmware Update2017-12-29T10:31:46Z<p>Martinp876: </p>
<hr />
<div>Seit 2014 ist es möglich, bei einigen [[HomeMatic]] Komponenten selbst Firmware Updates durchzuführen. Vorher ging das nur per CCU oder durch Einsenden des Gerätes an ELV.<br />
Dabei gibt es verschiedene Möglichkeiten das Firmware Update durchzuführen. Um in FHEM die aktuelle Firmware nach dem Update angezeigt zu bekommen, ist ein erneutes Pairen mit FHEM notwendig. Es muss aber nicht gelöscht oder zurückgesetzt werden.<br />
<br />
== Varianten für Firmwareupdates ==<br />
=== Firmware Update mit CUL/HM-CFG-USB/HMUARTLGW unter FHEM ===<br />
FW Updates sind in FHEM möglich. Benötigt wird dafür ein [[CUL]] oder ein [[HM-CFG-USB USB Konfigurations-Adapter|HM-CFG-USB]] oder ein [[HMUARTLGW]]. Mit einem [[HMLAN]] ist ein Update nicht möglich.<br />
<br />
Vor dem Update ist sicherzustellen, dass das korrekte IO für das Device genutzt wird (falls mehrere IOs im System zu Verfügung stehen). Siehe Attribut IODev und IOgrp bei der Verwendung einer [[Virtueller Controller VCCU|VCCU]]. Ein HMLAN kann mit dem Befehl: <code>set <HMLAN Name> close</code> temporär ausgeschlossen werden.<br />
<br />
Um das Update durchführen zu können, wird die in dem entsprechenden Zip/tgz-File vorhandene .eq3-Datei benötigt. Bitte genau darauf achten, dass nicht versehentlich eine falsches Firmware-Datei verwendet wird. Der Vorgang selbst erfolgt mittels folgendem Befehl:<br />
:<code>set <device> fwUpdate <filename> <nowiki>[<time>]</nowiki></code><br />
<filename> ist der Name der .eq3 Datei inklusive absolutem oder relativem Pfad zu fhem-Root.<br />
Die Angabe von [<time>] ist optional. Es ist die Zeit in Sekunden, die FHEM wartet, bis das Device in den Bootloader-Modus versetzt wird. Bei den meisten Devices ist die Zeit nicht notwendig, da FHEM das Gerät selbst in den Bootloader-Mode versetzen kann.<br />
<br />
Bei einigen älteren FW-Versionen wie z.B. bei den [[HM-CC-RT-DN]] v1.0 geht das allerdings nicht automatisch. Um den Flashvorgang zu starten, müssen hier noch die Batterien entfernt werden und beim wiedereinlegen die beiden äußeren Knöpfe gedrückt werden. Jene Zeit, die man für eben diese Aktion benötigt, wird hier eingegeben. <br />
<br />
Wichtig: während des Updates können keine weiteren Nachrichten in FHEM von Homematic verarbeitet werden.<br />
<br />
Da nach dem Update immer noch die alte FW-Version in FHEM steht, kann man entweder bei einigen Geräten die Version mit<br />
:<code> set <device> getVersion </code><br />
auslesen oder wenn das Kommando wie z.B. bei den oben genannten Heizkörperventilen nicht zur Verfügung steht, genügt es, am Gerät selbst die Anlerntaste zu drücken (was am Beispiel der RTs bedeutet, dass die Boost-Taste für mindestens drei Sekunden gedrückt werden muss). Nach der Aktualisierung der Firmware-Information in FHEM, muss die [[Konfiguration]] noch gespeichert werden.<br />
<br />
=== Firmware Update mit CUL/HM-CFG-USB unter Linux ===<br />
Für Linux hat mgernoth ein Updatetool erstellt.<br />
<br />
Zunächst muss sichergestellt werden, dass alle benötigten Pakete installiert sind. Um das Tool zu installieren und auszuführen, müssen die folgenden Pakete mit den gezeigten Befehlen installiert werden. Unter Debian:<br />
<syntaxhighlight lang="bash"><br />
sudo apt-get install libusb-1.0-0-dev git build-essential<br />
</syntaxhighlight><br />
Unter OpenSuse 13.2 64 Bit:<br />
<syntaxhighlight lang="bash"><br />
sudo zypper install libusb-1.0-0-dev git <br />
sudo zypper install --type pattern devel_basis<br />
</syntaxhighlight><br />
<br />
Als nächstes wird der Sourcecode für das Tool heruntergeladen (vorher z.B. in den Pfad <code>/usr/src</code> wechseln):<br />
<syntaxhighlight lang="bash"><br />
git clone git://git.zerfleddert.de/hmcfgusb<br />
</syntaxhighlight><br />
Und mit den Anweisungen<br />
<syntaxhighlight lang="bash"><br />
cd hmcfgusb<br />
make<br />
</syntaxhighlight><br />
wird daraus eine ausführbare Datei erstellt.<br />
<br />
Weiterhin muss die nötige Firmware heruntergeladen und entpackt werden. Die offiziellen Updates gibt es unter [http://www.eq-3.de/downloads.html eq-3 Downloads]. Die Befehle, um beispielsweise die benötigte Datei für die Firmware Version 1.4 des HM-CC-RT-DN zu erhalten lauten:<br />
<syntaxhighlight lang="bash"><br />
wget http://www.eq-3.de/Downloads/Software/Firmware/hm_cc_rt_dn_update_V1_4_001_141020.tgz<br />
tar xvzf hm_cc_rt_dn_update_V1_4_001_141020.tgz<br />
</syntaxhighlight><br />
Zu guter Letzt muss noch das Tool mit einigen Parametern und der Seriennummer des HomeMatic Devices aufgerufen werden. Für ein Update mit einem CUL (<code>/dev/ttyACM0</code> ist in diesem Beispiel die Adresse des CULs) muss folgendes eingegeben werden:<br />
<syntaxhighlight lang="bash"><br />
sudo ./flash-ota -c /dev/ttyACM0 -f <FirmwareImageName>.eq3 -s <DeviceSerialNo><br />
</syntaxhighlight><br />
Für ein Update mit einem COC muss folgendes eingegeben werden (/dev/ttyAMA0):<br />
<syntaxhighlight lang="bash"><br />
sudo ./flash-ota -c /dev/ttyAMA0 -f <FirmwareImageName>.eq3 -s <DeviceSerialNo><br />
</syntaxhighlight><br />
Für ein Update mit HM-CFG-USB<br />
<syntaxhighlight lang="bash"><br />
sudo ./flash-ota -f <FirmwareImageName>.eq3 -s <DeviceSerialNo><br />
</syntaxhighlight><br />
Nun muss nur noch das HomeMatic Gerät in den Update-Modus versetzt werden. Wie das geht, steht in der jeweils mit der Firmwaredatei gelieferten "readme".<br />
<br />
=== Firmware Update mit HM-CFG-USB unter Windows ===<br />
Für ein Firmwareupdate unter Windows wird das "HomeMatic Firmware Update Tool" von eq-3 benötigt: [http://www.eq-3.de/downloads.html eQ-3 Downloads]. Zur Zeit ist das Update damit nur mit dem HM-CFG-USB-2 möglich, nicht aber mit dem HM-CFG-LAN oder dem HM-CFG-USB der ersten Generation.<br />
<br />
Nach dem Start muss die Seriennummer des HomeMatic-Device eingegeben und die Firmware-Datei ausgewählt werden. Dann wird das Update-Tool durch einen Klick auf den entsprechenden Button in "Bereitschaft" gesetzt und anschließend muss das HomeMatic-Gerät in den Update-Modus versetzt werden. Bei Unterputz-Geräten ist das eventuell gar nicht so einfach, man kann in diesem Fall aber von FHEM aus dem Gerät ein Kommando schicken um es in den Bootloader Modus zu bringen. Dies geht mit dem Befehl<br />
:<code>set <device> fwUpdate onlyEnterBootLoader</code><br />
Direkt danach sollte das Update Tool mit seiner Arbeit beginnen.<br />
<br />
Falls das Update-Tool beim Auswählen der Firmware-Datei abstürzt ("Home Matic Firmware Update Tool funktioniert nicht mehr"), dann stimmt wahrscheinlich etwas mit der Firmware-Datei nicht. Die Datei darf nicht ausgepackt, sondern muss als ".tar.gz"-Datei, so wie sie heruntergeladen wurde, benutzt werden. Es kann Probleme geben, wenn die Datei mit dem Internet Explorer heruntergeladen wurde. Am einfachsten ist es, die Datei mit einem anderen Browser herunterzuladen.<br />
<br />
== Mögliche Probleme ==<br />
Lässt sich die Firmware nicht OTA auf das HomeMatic-Device flashen, kann dies folgende Ursachen haben:<br />
* Die FHEM-Software ist nicht auf dem neuesten Stand. Bitte vorher ein ''update'' durchführen.<br />
* '''Entfernung''' zwischen Sender und Empfänger '''zu klein'''. 1,5 bis 2 m Abstand sollten beide Geräte zueinander mindestens haben.<br />
* '''Entfernung''' zwischen Sender und Empfänger '''zu groß'''. Überprüfen Sie die RSSI-Werte des zu flashenden Device. Schlechter als - 70 sollten sie nicht sein (also keine - 75 oder noch kleiner). Ansonsten muss der Abstand für die Dauer des Flashens verringert werden.<br />
* Durch wiederholte Firmware-Updates oder Update-Versuche hat die [[1% Regel]] zugeschlagen. Der dort genannte Notbehelf (Funkschnittstelle kurz stromlos machen) schafft Abhilfe.<br />
<br />
== Tool zur Firmware Versionsprüfung ==<br />
[[Datei:HM-FWUpdate-eQ3.png|mini|400px|right|Beispiel einer Liste der relevanten Firmware Updates<br />'''Legende:'''<br />1 - Link auf die eQ-3 Download-Seite <br />2 - Link auf die Details des HTTPMOD Device <br />3 - Link auf die Details des HomeMatic Device <br />4 - (Download) Link auf die Firmware Datei <br />5 - "reread": Aktualisierung dieser Liste auslösen]]<br />
Im FHEM-Forum wurden unter dem Titel {{Link2Forum|Topic=47729|LinkText=...Firmware Versionsprüfung}} die erforderlichen Definitionen für ein [[HTTPMOD]]-Device vorgestellt, das <br />
* für alle HomeMatic Devices der aktuellen FHEM-Umgebung<br />
* die derzeit benutzte Firmware Version mit<br />
* einem evtl. auf der eQ-3 Seite verfügbaren Update vergleicht und<br />
* alle für die aktuelle Installation relevanten Updates in einer Übersicht (siehe Screenshot) darstellt und<br />
* einmal täglich (alle 86400 Sekunden) automatisch ausgeführt wird; dieses Intervall sollte nicht verkürzt, sondern eher verlängert werden. Im Bedarfsfall kann durch anklicken von '''''reread''''' eine sofortige Aktualisierung ausgelöst werden.<br />
<br clear=all><br />
{{Randnotiz|RNTyp=y|RNText=Sollte eine alte (vor dem 15.3.2016) Version dieser Definitionen bereits in Benutzung sein (zu erkennen am Vorhandensein von ''<nowiki>reading0[2|3|4|5]*</nowiki>''-Attributen), dann wird empfohlen, das Device mit <code>delete eq3</code> zunächst komplett zu löschen und anschließend neu anzulegen.}}<br />
Die unten aufgeführten erforderlichen Anweisungen zur Erstellung dieser Übersicht sind<br />
* im wesentlichen über das Webinterface eingebbar (können aber auch "en bloc" in die fhem.cfg eingetragen werden - auch wenn das eigentlich nicht empfohlen ist)<br />
* der umfangreiche Perl-Code für das Attribut ''userReadings'' ist dargestellt für die Eingabe über das [[FHEMWEB|Webinterface]]<br />
* für das Attribut ''stateFormat'' ist die mehrzeilige Eingabe (zumindest derzeit, März 2016) nicht unterstützt, daher wurde der Code in eine Subroutine ausgelagert<br />
<br clear=all>{{Randnotiz|RNTyp=r|RNText='''Wichtige Änderungen:'''<br />
22.05.2016 - ''reading01Regex'' und ''reading01Format'' angepasst (eQ-3)<br />
}}<br clear=all><br />
<br />
=== Basis-Definitionen für Device eq3 ===<br />
<syntaxhighlight lang="text"><br />
define eq3 HTTPMOD http://www.eq-3.de/service/downloads.html 86400<br />
attr eq3 userattr enableControlSet event-on-change-reading event-on-update-reading reading01AutoNumLen reading01Format reading01Name reading01RegOpt reading01RegOpt:s,i,g reading01Regex readingMaxAge readingMaxAgeReplacementMode readingMaxAgeReplacementMode:text,expression,delete requestData.* showError showMatched stateFormat userReadings webCmd<br />
attr eq3 enableControlSet 1<br />
attr eq3 event-on-change-reading .*<br />
attr eq3 event-on-update-reading LAST_ERROR,MATCHED_READINGS<br />
attr eq3 reading01AutoNumLen 2<br />
attr eq3 reading01Format http://www.eq-3.de/%s<br />
attr eq3 reading01Name fw_link<br />
attr eq3 reading01RegOpt g<br />
attr eq3 reading01Regex <a.href="(Downloads\/Software\/Firmware\/[^"]+)<br />
attr eq3 readingMaxAge 10<br />
attr eq3 readingMaxAgeReplacementMode delete<br />
attr eq3 requestData.* suchtext=&suche_in=2&downloadart=11<br />
attr eq3 room eq3<br />
attr eq3 showError 1<br />
attr eq3 showMatched 1<br />
attr eq3 stateFormat {eq3StateFormat}<br />
attr eq3 webCmd reread<br />
</syntaxhighlight><br />
<br />
=== Definition/Code für Attribut userReadings ===<br />
Der "Zugang" zur Eingabe des Attributs ''stateFormat'' erfolgt über die Details des Device '''eq3''' (URL: ...8083/fhem?detail=eq3).<br />
[[Datei:HM-FWUpdate-eQ3-userReadings.png|mini|640px|left|"Der Weg" zur Eingabe von ''userReadings''; durch Klick in das Eingabefeld öffnet sich ein separates Fenster.]]<br />
<br clear=all>Der Perl-Code, der für das Attribut ''userReadings'' eingegeben werden muss:<br />
<syntaxhighlight lang="perl"><br />
newFwForDevices:MATCHED_READINGS:.* {<br />
my $ret = "";<br />
my @data;<br />
my @eq3FwList = map{@data = ReadingsVal("eq3","fw_link-".$_,"?") =~ m/Firmware\/(.*?)_update_V([\d_]+)_(\d\d)(\d\d)(\d\d)/; <br />
$data[0] =~ s/_/-/g;<br />
sprintf("%s:%s:%s.%s.%s:%s",$data[0],$data[1],$data[4],$data[3],"20".$data[2],$_);<br />
} ReadingsVal("eq3","MATCHED_READINGS","?") =~ m/fw_link-(\d\d)/g;<br />
<br />
foreach my $dev (devspec2array("TYPE=CUL_HM:FILTER=DEF=......:FILTER=subType!=(virtual|)")) {<br />
my $md = AttrVal($dev,"model","?");<br />
my $v = AttrVal($dev,"firmware","0.0");<br />
my ($h,$l) = split('\.',$v);<br />
foreach my $newFw (grep m/^${md}:/i,@eq3FwList) {<br />
my ($nh,$nl,$no,$date,$idx) = $newFw =~ m/^[^:]+:(\d+)_(\d+)_?(\d*):([^:]+):(\d\d)$/;<br />
if(($nh > $h) || (($nh == $h) && ($nl > $l))) {<br />
$ret .= "," if($ret ne "");<br />
$ret .= $dev." (".$md." | fw_".$v." => fw".$idx."_".$nh.".".$nl.($no?sprintf(".%d",$no):"")." | ".$date.")";<br />
}<br />
}<br />
}<br />
return ($ret eq "")?"no fw-updates needed!":$ret;<br />
}<br />
</syntaxhighlight><br />
<br />
=== Definition/Code für Attribut stateFormat ===<br />
Da der Code für ''stateFormat'' recht umfangreich ist, wäre er als Einzeiler kaum sinnvoll zu verwalten, würde also ohnehin meistens über einen externen Editor bearbeitet werden. Daher wurde er als eigene (Sub-)Routine mit dem Namen ''eq3StateFormat'' in (z.B.) [[99_myUtils anlegen|99_myUtils]] ausgelagert:<br />
<syntaxhighlight lang="perl"><br />
sub eq3StateFormat() {<br />
my $name = "eq3";<br />
<br />
my $ret ="";<br />
my $lastCheck = ReadingsTimestamp($name,"MATCHED_READINGS","???");<br />
$ret .= '<div style="text-align:left">'; <br />
$ret .= 'last <a title="eq3-downloads" href="http://www.eq-3.de/downloads.html">homematic</a>-fw-check => '.$lastCheck; <br />
$ret .= '<br><br>'; <br />
$ret .= '<pre>'; <br />
$ret .= "| device | model | old_fw | new_fw | release |\n"; <br />
$ret .= "------------------------------------------------------------------------------------\n"; <br />
my $check = ReadingsVal($name,"newFwForDevices","???"); <br />
if($check eq "no fw-updates needed!") { <br />
$ret .= '| '.$check.' |'; <br />
} else { <br />
my @devices = split(',',$check); <br />
foreach my $devStr (@devices) {<br />
my ($dev,$md,$ofw,$idx,$nfw,$date) = $devStr =~ m/^([^\s]+)\s\(([^\s]+)\s\|\sfw_(\d+\.\d+)\s=>\sfw(\d\d)_([\d\.]+)\s\|\s([^\)]+)\)$/; <br />
my $link = ReadingsVal($name,"fw_link-".$idx,"???"); <br />
$ret .= '| '; <br />
$ret .= '<a href="/fhem?detail='.$dev.'">'; <br />
$ret .= sprintf("%-23s",$dev); <br />
$ret .= '</a>'; <br />
$ret .= " | "; <br />
$ret .= '<b'.(($md eq "?")?' title="missing attribute model => set device in teach mode to receive missing data" style="color:yellow"':' style="color:lightgray"').'>'; <br />
$ret .= sprintf("%-23s",$md); <br />
$ret .= '</b>'; <br />
$ret .= " | "; <br />
$ret .= '<b'.(($ofw eq "0.0")?' title="missing attribute firmware => set device in teach mode to receive missing data" style="color:yellow"':' style="color:lightgray"').'>'; <br />
$ret .= sprintf("%6s",$ofw); <br />
$ret .= '</b>'; <br />
$ret .= " | "; <br />
$ret .= '<a title="eq3-firmware.tgz" href="'.$link.'">'; <br />
$ret .= '<b style="color:red">'; <br />
$ret .= sprintf("%6s",$nfw); <br />
$ret .= '</b>'; <br />
$ret .= '</a>'; <br />
$ret .= " | "; <br />
$ret .= sprintf("%-10s",$date); <br />
$ret .= " |\n"; <br />
} <br />
} <br />
$ret .= '</pre>'; <br />
$ret .= '</div>'; <br />
return $ret;<br />
}<br />
</syntaxhighlight><br />
<br />
=== Sondersituationen ===<br />
[[Datei:HM-FWUpdate-eQ3-check.png|mini|455px|right|Fehlerbedingung: Attribut ''firmware'' nicht gesetzt]]<br />
Das Tool überprüft gleichzeitig auch bestimmte Rahmenbedingungen, so z.B., ob bei allen HomeMatic Devices die Attribute ''model'' und ''firmware'' gesetzt sind. Sollte das nicht der Fall sein, wird das Device in der Liste <br />
* mit einem gelben "old_fw" Wert von 0.0 geführt; befindet sich der Mauszeiger über dem "0.0", wird der Hinweistext ''missing attribute firmware => set device in teach mode to receive missing data'' angezeigt (siehe Beispiel im Screenshot)<br />
* mit einem gelben {{Taste|?}} in der Spalte "model" angezeigt; befindet sich der Mauszeiger über dem "?", wird der Hinweistext ''missing attribute model => set device in teach mode to receive missing data'' angezeigt<br />
In diesem Fall sollte bei dem betreffenden Gerät versucht werden, mit ''getConfig'' die Daten zu aktualisieren bzw. vervollständigen.<br />
<br />
Darüber hinaus ist zu beachten, dass die Firmware-Version in den HomeMatic Geräten zwei"teilig" (Version.Release) abgelegt ist, die Firmware Update-Dateien jedoch drei"teilige" Versionskennungen (Version_Release_???) haben. Für den Vergleich, ob neue Firmware verfügbar ist, kann natürlich nur die zweiteilige Kennung verwendet werden, eine Änderung im dritten Teil der Versionskennung kann daher nicht automatisch erkannt werden.<br />
<br />
== Links ==<br />
* [http://www.eq-3.de/downloads.html Firmware Download] Seite von eq-3<br />
* Forenthread zur {{Link2Forum|Topic=47729|LinkText="Firmware Versionsprüfung"}}<br />
* [http://git.zerfleddert.de/hmcfgusb/ Firmware Update Tool] von mgernoth<br />
<br />
[[Kategorie:HomeMatic Components|1toolsAndWork]]<br />
[[Kategorie:HOWTOS]]</div>Martinp876http://wiki.fhem.de/w/index.php?title=HomeMatic_Nachrichten_sniffen&diff=23896HomeMatic Nachrichten sniffen2017-12-29T10:31:24Z<p>Martinp876: </p>
<hr />
<div>Um Probleme besser zu verstehen und Support zu ermöglichen kann man Roh-Nachrichten sniffen. Meist ist es sinnvoll, andere Logs zu dieser Zeit zu reduzieren und genauere Zeitstempel zu erzeugen. <br />
<br />
Die Nachrichten landen im Logfile.<br />
<br />
'''Hinweis:''' Falls die Attribute in die fhem.cfg gesetzt werden, sind diese erst nach einem 'rereadcfg' oder 'shutdown restart' aktiv. Bei erfolgter Eingabe über die Konsole bzw. das Web Interface werden die Parameter sofort übernommen.<br />
<br />
Wird die Logging-Funktion nicht mehr benötigt, so sollte diese wieder deaktiviert werden, um ein unnötiges Anwachsen des Logfiles zu verhindern. Dafür müssen lediglich die zuvor getätigen Schritte wieder rückgängig gemacht werden. Daher entweder die eingetragenen Zeilen wieder aus der Config-Datei löschen und die [[Konfiguration]] auf einen der oben beschriebenen Wege neu einlesen oder aber die Attribute einfach über die Konsole bzw. das Web Interface löschen.<br />
<br />
=== HMLAN/HMUSB/HMUART ===<br />
attr global verbose 1<br />
attr global mseclog 1<br />
attr <hmio> logIDs all,sys<br />
logIDs erlaubt das selektive loggen einzelner HM-Komponenten, was die Log-Größe erheblich reduzieren kann uns somit auch sehr lange Aufzeichnungen zulässt. Siehe auch [[HM-CFG-LAN_LAN_Konfigurations-Adapter#Attribute|logIDs]]. Diese Funktion steht analog auch beim neueren Funk-Lan-Gateway und dem Raspberry-Aufsteckmodul, beide Typ [[HMUARTLGW]], zur Verfügung.<br />
<br />
=== CUL/CUNO ===<br />
attr global verbose 1<br />
attr global mseclog 1<br />
attr <cul> verbose 4<br />
<br />
== Links ==<br />
* Quelle: {{Link2Forum|Topic=16563|LinkText=FHEM Forum}}<br />
<br />
[[Kategorie:HomeMatic Components|1toolsAndWork]]<br />
[[Kategorie:HOWTOS]]</div>Martinp876http://wiki.fhem.de/w/index.php?title=HomeMatic_Peering_Beispiele&diff=23895HomeMatic Peering Beispiele2017-12-29T10:31:01Z<p>Martinp876: </p>
<hr />
<div>Dieser Artikel beschreibt wie mit FHEM Homematic Sensoren und Aktoren gepeert werden können. Peering ist nicht zu verwechseln mit Pairing, d.h. dem Verknüpfen von Homematic Geräten mit einer Zentrale (wie beispielsweise FHEM). Details zum Pairing findet man [[HomeMatic_Devices_pairen|'''hier''']].<br />
<br />
= Grundlagen =<br />
Beim ''Peering'' (deutsch sinngemäß: Verbindung von Gleichen) handelt es sich um das Verknüpfen von Kanälen (Channels) verschiedender HomeMatic-Geräte, um diese auch ohne Zentrale kommunizieren zu lassen. Nach dem Peering sendet meist ein Sensorkanal (remote, push-button, Bewegungsmelder,...) einen Trigger an einen Aktorkanal des anderen Gerätes. <br />
Besonderheiten:<br />
* peeren kann man nur Channels, nicht HomeMatic-Geräte. Die Peer-Listen der verschiedenen Kanäle eines Gerätes sind unabhängig voneinander.<br />
* gepeert werden immer ein oder mehrere Sensorkanäle mit einem oder mehreren Aktorkanälen<br />
* der Sensor sendet einen Trigger, evtl. mit einem Zusatzwert. Es ist ''immer'' der Aktorkanal, der festlegt, welche Aktion ergriffen wird. Ein Button kann demnach gleichzeitig ein Einschalter für einen Aktor und ein Ausschalter für einen anderen Aktor sein.<br />
<br />
<br />
{{Hinweis|'''Achtung:''' Das in vielen mitgelieferten HomeMatic-Anleitungen beschriebene Peering von Kanälen ohne Zentrale funktioniert nur, wenn keines der beiden Geräte gepairt ist. Im Folgenden gehen wir davon aus, dass beide Geräte bereits mit einer Homematic-Zentrale (z.B. FHEM) [[HomeMatic_Devices_pairen|gepairt]] sind.}}<br />
<br />
== Kommandos ==<br />
<br />
=== peerChan ===<br />
<br />
set <sensChan> peerChan 0 <actChan> [single|dual] [set|unset]<br />
<br />
<code>peerChan</code> peert (verbindet) einen Sensorkanal mit einem Aktorkanal.<br />
Dabei ist <code>&lt;sensChan&gt;</code> der Name des Sensorkanals und <code>&lt;actChan&gt;</code> der Name des Aktorkanals.<br />
<br />
* Mit dem Schlüsselwort ''single'' wird genau dieser Sensorkanal gepeert. <br />
* Mit dem Schlüsselwort ''dual'' werden zwei zusammengehörende Sensorkanäle mit dem Aktorkanal verknüpft. Die beiden Sensorkanäle lösen unterschiedliche Aktionen aus, beispielsweise ''an'' und ''aus''.<br />
* Das Schlüsselwort ''set'' legt das Peering an, das Schlüsselwort ''unset'' hebt es auf.<br />
<br />
Das Kommando unterliegt den allgemeinen [[HomeMatic#Kommunikation|Regeln]]. Es wirkt auf zwei Geräte gleichzeitig, weshalb beide Geräte beobachtet werden sollten – ggf. muss an einem oder beiden Geräten die Anlerntaste gedrückt werden.<br />
<br />
=== peerIODev ===<br />
<br />
set <actChan> peerIODev <IO> <chan> [set|unset]<br />
<br />
<code>peerIODev</code> peert (verbindet) einen Aktorkanal mit einem I/O-Device.<br />
Dabei ist <code>&lt;IO&gt;</code> der Namen des I/O-Devices und <code>&lt;chan&gt;</code> die Nummer des virtuellen Kanals ist. Kanäle von 1 bis 50 sind zulässig.<br />
<br />
=== peerBulk ===<br />
<br />
set <sensChan> peerBulk <peer1,peer2,...><br />
<br />
<code>peerBulk</code> dient der Wiederherstellung einer gesicherten Konfiguration.<br />
Dieser Befehlt erlaubt eine Liste von Peers en-block in ein Gerät zu schreiben. Die Gegenstelle und die Kommunikation der Beiden wird nicht berücksichtigt.<br />
<br />
==Sensoren ==<br />
Ist ein Sensorkanal mit einem Aktorkanal gepeert, gibt es meist nur wenig mögliche Einstellungen. Wichtige Beispiele sind <br />
* Notwendigkeit, den Peer mit einem burst aufzuwecken (Register peerNeedsBurst). <br />
* Erwartung von AES-Verschlüsselung/Authentifizierung (Register expectAES).<br />
<br />
===LED===<br />
Ein ungepeerter Sensorkanal signalisiert einen Tastendruck meist mit gelber LED. Ist der Kanal gepeert, wird mit einer grünen LED signalisiert, dass ALLE Peers den Empfang des Triggers bestätigt (d.h. "ACK" gesendet) haben. Sollten nicht alle Peers eine Bestätigung senden, wird mit einer rot LED quittiert. <br />
<br />
==Aktoren==<br />
Ist ein Sensorkanal mit einem Aktorkanal gepeert, muss im Aktorkanal eingestellt werden, welche Trigger gültig sind und welche Aktionen ergriffen werden sollen. Im Channel wird ein Satz Register angelegt, die als Reading mit '''R-<peername>...''' zusammengefasst sind. Meist sind 2 Gruppen je Peer vorhanden, eine für langen '''lg''' und eine für kurzen '''sh''' Tastendruck. Die Register für long und short sind deckungsgleich, bis auf das Register multiExec in der Gruppe long.<br />
<br />
Für das Setzen des Wertes im Aktorkanal gilt die Syntax<br />
set <actChan> regSet <register> <value> <peername><br />
===Condition Table===<br />
Mit den Registern der Condition Table '''CT''' kann man Trigger filtern. So sendet beispielsweise ein Fensterkontakt einen Trigger mit einem Zusatzwert open=200 oder closed=0. Die CT hat 2 Vergleichswerte, '''Hi''' und '''Lo'''. Der Zusatzwert des Triggers wird entsprechend des Einträgen in der CT verglichen. Ist der Schalter z.B. an, dann wird auf den Eintrag in '''CTon''' genutzt. Steht dort '''geLo''' wird gprüft, ob der Zusatzwert des triggers grösser oder gleich dem Lo-Wert ist. Ist dies nicht der Fall, wird keine Aktion ausgeführt.<br />
Register zur Condition Table sind:<br />
CtDlyOff | literal | Jmp on condition from delayOff options:geLo,between,outside,ltLo,geHi,ltHi<br />
CtDlyOn | literal | Jmp on condition from delayOn options:geLo,between,outside,ltLo,geHi,ltHi<br />
CtOff | literal | Jmp on condition from off options:geLo,between,outside,ltLo,geHi,ltHi<br />
CtOn | literal | Jmp on condition from on options:geLo,between,outside,ltLo,geHi,ltHi<br />
CtValHi |0 to 255 | Condition value high for CT table<br />
CtValLo |0 to 255 | Condition value low for CT table<br />
Remotes liefern keinen Zusatzwert. Die Conditon Table wird nicht genutzt. <br />
===Jump Table===<br />
In der Jump Table wird zusammen mit ActionType festgelegt, welche Aktion ein gültiger Trigger ausführen soll. Die Aktion ist vom Gerät abhängig.<br />
<br />
===Interne Peers===<br />
Aktoren können eingebaute oder direkt angeschlossene Taster oder Tasteneingänge haben, die auch als Peers verarbeitet werden. Normalerweise sind diese nicht sichtbar, sie können aber durch Absetzen des Befehls <br />
set <device> regSet intKeysVisib visib<br />
sichtbar und einstelllbar gemacht werden.<br />
<br />
==Virtuelle Entities==<br />
Soll ein FHEM-Befehl bei einem Aktor nicht nur eine Aktion auslösen, muss er mit einem Kanal einer <u>[[HomeMatic#Virtuelle_Entities|virtuellen Entität]]</u> oder einer <u>[[HomeMatic#IO_Entities|IO Entität]]</u> gepeert werden. Das Peering erfolgt wie bei realen Homematic-Geräten. Achtung: da diese virtuellen Peers nicht in einem realen Gerät gespeichert werden, ist nach der Definition ein '''Save config''' nötig. <br /><br />
Dadurch lassen sich nicht nur einfache Befehle je Kanal aussenden, sondern die Peering-Listen in Aktoren nutzen um mit einem Funkbefehl z.B.<br />
*Schleifen zu starten (z.B. bei Alarmauslösung ein Pulsieren der Beleuchtung, alle x Min eine kurze Unterbrechung, ...)<br />
*Abläufe zu starten (z.B. Treppenhauslicht mit Vorwarnung bei Dimmern, ...)<br />
*mehrere Aktoren gleichzeitig schalten zu lassen<br />
Sonst müsste man für jede Zustandsänderung bzw. für jeden Aktor einen eigenen Befehl senden. Somit reagieren mehrere Aktoren auf ein FHEM-Kommando gleichzeitig.<br />
<br />
===IO Entities===<br />
<u>[[HomeMatic#IO_Entities|IO Entities]]</u> sind virtuelle Kanäle eines IO-Devices (z.B. [[Virtueller Controller VCCU|VCCU]], [[HM-CFG-LAN|HMLAN]], ...) und können somit gepeert werden. Hierfür gibt es das Kommando [[Homematic Peering Beispiele#peerIODev|peerIODev]].<br />
<br />
= Beispiele=<br />
== Peering der Kanäle einer Fernbedienung mit einem Aktor ==<br />
Dabei muss beachtet werden, dass auf den Fernbedienungen immer zwei Buttons zusammengehören, also z.B. lock/unlock, open/light oder Btn01/Btn02, Btn03/Btn04. Achtung: Für ein erfolgreiches Peering muss ggf. auf der Fernbedienung die Anlerntaste gedrückt werden.<br />
<br />
Bei einem "dual" Peering werden die beiden zusammengehörenden Kanäle der Fernbedienung mit einem Aktorkanal gepeert - einer der Buttons wirkt dann als "on", der andere als "off"-Schalter.<br />
<br />
set fb_Btn03 peerChan 0 blind<br />
peert die Buttons Btn03 und Btn04 mit dem Aktorkanal ''blind''<br />
<br />
Bei einem "single" Peering wird nur einer der beiden Kanäle der Fernbedienung mit einem Aktorkanal gepeert - als Aktion wird dann im Aktorkanal ein "toggle" eingetragen.<br />
<br />
set fb_Btn07 peerChan 0 blind single<br />
peert nur den Button Btn07 mit dem Aktorkanal ''blind''<br />
<br />
Das Unpeering, also das Löschen einer Paarung, erfolgt z.B. durch den Befehl<br />
set fb_Btn07 peerChan 0 blind single unset<br />
<br />
== Peering von I/O-Entities ==<br />
<pre><br />
set blind peerIODev HMLAN1 5<br />
set blind peerIODev HMLAN1 7 unset<br />
</pre><br />
<br />
[[Kategorie:HomeMatic Components|1toolsAndWork]]<br />
[[Kategorie:HOWTOS]]<br />
[[Kategorie:Examples]]</div>Martinp876http://wiki.fhem.de/w/index.php?title=HomeMatic_Register_programmieren&diff=23894HomeMatic Register programmieren2017-12-29T10:30:33Z<p>Martinp876: </p>
<hr />
<div><!-- Bitte noch an geeigneten Stellen Links auf diese Seite einfügen --><br />
{{Baustelle}}<br />
Ein HomeMatic-Gerät besitzt mehr oder weniger umfangreiche Registersätze, mit denen das Verhalten des Gerätes vielfältig feinkonfiguriert werden kann. Die damit erreichbare Funktionsvielfalt geht weit über die standardisierten Vorgaben einer einfachen Direktverknüpfung ([[Peering_(HomeMatic)|Peering]]) hinaus. <br />
<br />
<br />
== Grundlagen (in Auszügen) ==<br />
<br />
Im folgenden werden nur exemplarisch einige Grundlagen und einfache Beispiele benannt, ohne jeden Anspruch auf Vollständigkeit.<br />
<br />
FHEM unterstützt die Programmierung der Register mit dem Befehl ''regSet''. <peer> entfällt bei rein gerätebezogenen Programmierungen.<br />
:<code>set <name> regSet <register> <value> [<peer>] </code><br />
Darüberhinaus gibt es vor- oder selbstdefinierte [[HomeMatic_HmInfo_Templates_erstellen|Templates]] (Vorlagen), die alle erforderlichen Änderungen für standardisierte Anwendungen wie Treppenhauslichtschalter beinhalten. Die Anwendung von Templates auf Geräte wird protokolliert und der Registerzustand kann überprüft werden. Für viele Anwendungen genügt jedoch auch die einmalige Anwendung einer direkten Programmierung. Das genaue Verständnis der Vorgänge und Zusammenhänge ist nicht trivial, das Erlernen wird aber mit einer enormen erreichbaren Funktionsvielfalt belohnt. Viele wissenswerte Zusammenhänge sind im Homematic-Anhang der bekannten Einsteiger-Dokumentation erläutert, deren Lektüre zu Recht immer wieder empfohlen wird. Dieser Beitrag ist auch nur als Ergänzung zu verstehen!<br />
<br />
Die HomeMatic Aktoren (Schalter, Dimmer, ...) arbeiten so, wie es für verknüpften ([[Peering (HomeMatic)|peering]]) Sender vorgegeben ist. Sie nutzen Registersätze, die für jede Verknüpfung (peer) neu angelegt und gespeichert werden. Man kann also mit einem Taster ein- und ausschalten (toggeln), mit einem Tastenpaar gezielt ein- und ausschalten und mit einem weiteren Taster eine Zeitschaltung für 10 Sekunden starten. Dabei wird niemals der Taster oder der Schalter auf eine globale Aktion programmiert, sondern im Schalter (Aktor) die gewünschte Aktion für jeden verknüpften Taster separat gespeichert. Die auszulösende Aktion ist zudem abhängig vom aktuellen Zustand des Aktors und von der Länge des Tastendruckes (kurz oder länger - short or long).<br />
<br />
Kleines Beispiel:<br />
T1 schaltet S1 für 10 sec an<br />
T2 schaltet S1 an oder aus <br />
T3 schaltet S1 an <br />
T4 schaltet S1 aus. <br />
<br />
Diese Tabelle ist im Schalter S1 gespeichert.<br />
<br />
Schaltet man mit T3 den S1 an und drückt dann nach beliebiger Zeit kurz T1 geht S1 nach weiteren 10 sec aus. Schaltet man mit T1 kurz den S1 für 10 sec an, aber innerhalb dieser Zeit mit T3 nochmal an, dann bleibt S1 nach Ablauf der 10 sec an.<br />
<br />
Die verfügbaren Register unterscheiden sich im Gerät und in den jeweiligen Kanälen. <br />
Eine kurze Beschreibung der Register inklusive der erlaubten Werte erhält man durch:<br />
:<code>get <name> regList </code><br />
Dabei kann <name> ein Gerät oder ein separater Gerätekanal sein.<br />
<br />
== Spezielle Register (Auswahl) ==<br />
Im folgenden sollen einige Register vorgestellt werden, die in vielen Geräten vorhanden sind. ''Ergänzungen sind ausdrücklich erwünscht!''<br />
<br />
<br />
=== Gerätebezogene Register ===<br />
Gerätebezogene Register existieren für jedes HomeMatic-Gerät nur einmal und werden in der sogenannten '''List0''' gespeichert (in der FHEM-Oberfläche als Hexbytefolge unter ''RegL_00.'' zu finden).<br />
<br />
<br />
==== ''confBtnTime'' - Kurz oder lang und der Konfigurationsmodus ====<br />
Nicht immer sind die internen Tasten eines Gerätes ohne weiteres mit Aktionen für kurzen und langen Tastendruck programmierbar. Bei allen Hutschienen-Aktoren sowie den Zwischensteckern (mit nur einem Bedienknopf) versetzt ein langer Tastendruck (4 Sekunden) den Schalter normalerweise in den Konfigurations- bzw. Anlern-Modus, bei den in Unterputzdosen versenkbaren Schalt- und Dimmaktoren (-FM ohne PBU in der Bezeichnung) ohne eigenen Konfigurations-Button gilt dies sogar für die zur normalen Funktion extern angeschlossenen Taster. Dieses Verhalten kann man mit dem Register ''confBtnTime'' beeinflussen. Bis zum Ablauf der dort einstellbaren Zeit (in Minuten) nach dem Versorgen mit Strom (powerUp) erreicht man den Konfigurationsmodus wie bisher, danach interpretiert der Aktor die Tastendrücke stets als kurz (short) oder lang (long). Beispiel:<br />
:<code>set <name> regSet confBtnTime 2</code><br />
Möchte man den Aktor später zurücksetzen oder lokal konfigurieren, so erreicht man das ursprüngliche Verhalten in diesem Beispiel für die ersten zwei Minuten, nachdem man den Aktor (ausreichend lange) stromlos gemacht hat.<br />
<br />
<br />
==== ''intKeyVisib'' - Interne Tasten sichtbar machen ====<br />
Die internen "Tasten" eines Aktors (z.B. die Schaltwippe bei Wandschaltern/-tastern, der Bedienknopf bei Zwischensteckern, aber auch die angeschlossenen externen Taster bei Aktoren für Unterputzdosen oder die von außen zugängliche "Notbedientaste" etwa bei Zwischendecken-Dimmern) sind logisch ebenso mit dem Aktor verknüpft wie externe Bedienelemente wie Funkfernbedienungen oder per Funk verknüpfte Wandtaster. Ihre Betätigung wird (außer mit präparierter Firmware) zwar nicht gesendet (und kann daher von FHEM nicht "gelesen" werden), die vom Hersteller vorgesehenen Funktionen lassen sich aber genauso frei programmieren. Allerdings sind diese internen Verknüpfungen zur Vermeidung versehentlicher Programmierungen zunächst verborgen und müssen daher explizit sichtbar gemacht werden. <br />
<br />
Dies geschieht mit<br />
set <name> regSet intKeyVisib visib <br />
attr <name> expert 1<br />
Anschließend sind der oder die internen Taste(n) mit der Bezeichnung self01 (self02, ...) sichtbar und ihre Aktionen können gezielt wie bei einem externen Peer umprogrammiert werden.<br />
<br />
Wer nun auf die Idee kommt, man könne durch entsprechendes zusätzliches peering bei mehrkanaligen Geräten die (mehreren) internen Tasten beliebig zuweisen und so raffinierte Zusatzschaltungen auslösen, muss hier enttäuscht werden: Zwar kann man tatsächlich mit peerBulk bei den Aktorkanälen zusätzliche interne Peers eintragen und programmieren und mit einer Fernauslösung aus FHEM die neuen Verknüpfungen erfolgreich nutzen - das Gerät selbst reicht die Tastenbetätigungen aber immer nur an den ursprünglich dafür vorgesehenen Kanal weiter.<br />
<br />
<br />
==== ''ledMode'' - Funktion der Onboard-LED bei Bausätzen ====<br />
Die (batteriebetriebenen) -PCB-Aktoren und die 8-Kanal-Module haben kleine LED an Bord, die für Diagnosezwecke hilfreich sind, einem sparsamen Betrieb aber in der Regel entgegenstehen. Sie werden daher nur bei außergewöhnlichen Zuständen wie dem Anlernmodus, einem Reset, oder auch bei niedriger Batteriespannung als Hinweis an den Anwender benutzt und sind ansonsten ab Werk deaktiviert. Bei einer Dauerstromversorgung kann aber eine Schaltzustandsanzeige oder eine Quittung über eine Befehlsaussendung nicht nur zur Diagnose hilfreich sein.<br />
<br />
Besitzt das Gerät das Register ''ledMode'', so kann man mit<br />
:<code>set <device> regSet ledMode on</code><br />
die LED auch für die "normalen" Betriebszustände aktivieren. Sie zeigen dann bei Aktoren, ob der Aktor eingeschaltet ist (blinkend, wenn eine Einschaltzeitbegrenzung aktiv ist), und bei den Sensormodulen HM-Mod-EM8(bit) zeigt die zweifarbige LED den von Fernbedienungen bekannten Sendezustand mit gelb, dem dann ein grün oder rot folgt - je nachdem ob eine Quittung angefordert ist und ob sie erfolgreich empfangen wurde.<br />
<br />
Leider lässt sich umgekehrt die bei Wandtastern oder Fensterkontakten mitunter gewünschte Deaktivierung der LED nicht so bewerkstelligen - diese Geräte haben das entsprechende Register nicht. Da hilft nur ein Eingriff ins Gerät mit Gaffa oder schwarzem Edding... <br />
<br />
<br />
=== Kanalbezogene Register ===<br />
Kanalbezogene Register existieren für jeden Kanal eines Gerätes einmal und werden in der sogenannten '''List1''' gespeichert (in der FHEM-Oberfläche als Hexbytefolge unter ''RegL_01.'' zu finden). <br />
<br />
<br />
==== ''powerUpAction'' - Automatischer Knopfdruck bei (wiederkehrender) Stromversorgung ====<br />
Mit diesem Register (default ''off'') kann erreicht werden, dass ein Schaltaktor nach einem Stromausfall sich bei Wiederkehr der Versorgungsspannung automatisch einschaltet. Dies ist z.B. sinnvoll für Zwischenstecker mit Messfunktion ([[HM-ES-PMSw1-Pl Funk-Schaltaktor 1-fach mit Leistungsmessung|HM-ES-PMSw1-Pl]]), wenn dieser als Langzeitmonitor etwa für Kühlgeräte verwendet wird - nach einem Stromausfall bliebe der Kühlschrank sonst aus und der Inhalt würde verderben. <br />
:<code>set <name> regSet powerUpAction on</code><br />
Achtung: Das Setzen dieses Registers auf ''on'' bedeutet nicht immer einen eingeschalteten Aktor nach der Wiederkehr der Stromversorgung. Vielmehr wird nur ein ''short''-Ereignis auf den zugehörigen internen Taster ausgelöst, was nur im Normalfall zum Einschalten des Aktors führt - nicht aber wenn die Funktion dieses kurzen Tastendruckes gezielt verändert wurde, denn dann wird eben diese Aktion ausgeführt! Das gilt zum Beispiel auch für zeitlich begrenztes Einschalten. Als Alternative für eine lokale Schaltmöglichkeit bietet sich in solchen Fällen der lange Tastendruck an, sofern er vom Aktor unterstützt wird (so lässt sich die Einschaltzeit bei langem Tastendruck mit ''lgOnTime'' begrenzen). Dessen Aktion wird bei powerUp nicht ausgeführt.<br />
<br />
<br />
=== Verknüpfungsbezogene Register ===<br />
Diese Register sind am umfangreichsten und werden für jeden Verknüpfungspartner einzeln separat angelegt in der '''List3''' (''RegL_03.<peer>''). Die grundsätzlichen Funktionen und ihre Zusammenhänge sind ausführlich in der Einsteigerdokumentation erklärt, inklusive Skizzen für die sogenannte ''state machine''. Hier sollen daher nur die in den folgenden Beispielen verwendeten Register erklärt werden. <br />
<br />
<br />
==== ''shOnTime'' und ''lgOnTime'' - das interne ''on-for-timer'' von Schaltern oder Dimmern ====<br />
Die wohl populärsten Register begrenzen die Einschaltzeit eines Aktors. Um z.B. eine Steckdose für 10 sec bei Knopfdruck lokal einzuschalten kann man folgendes programmieren:<br />
:<code>set <name> regSet shOnTime 10 self01 </code><br />
<br />
''shOnTime'' ist dabei das zuständige Register für die Einschaltzeit bei kurzem (sh=short) Tastendruck, entsprechend gilt ''lgOnTime'' für einen langen Tastendruck. <br />
<br />
In den Readings werden die Register mit dem jeweiligen verknüpften Taster angezeigt, in unserem Fall also:<br />
:<code>R-self01-shOnTime </code><br />
<br />
Der Defaultwert für shOnTime ist 111600 und bedeutet unendlich (von FHEM mit "unused" dargestellt), d.h. die maximale einstellbare Zeit ist 111599 sec (knapp 31 Stunden). So kann man die Zeit löschen:<br />
:<code>set <device> regSet shOnTime 111600 self01 </code><br />
oder<br />
:<code>set <device> regSet shOnTime unused self01 </code><br />
<br />
Übrigens gibt es diese Register auch für die Ausschaltzeit.<br />
<br />
<br />
==== ''shCtOn'' und ''shCtOff'' - Bedingtes Schalten mit Schwellwerten ====<br />
Fernbedienungen (im weitesten Sinne, ''remote'') von HomeMatic übermitteln je nach Betätigungsdauer ''short''- oder ''long''-Trigger. Zustandsübermittelnde Sensoren (etwa ein Fensterkontakt oder Neigungssensor sowie Bewegungsmelder) senden ausschließlich ''short'', gekoppelt mit einem Wert zwischen 0 und 200, entsprechend 0-100% in 0,5-%-Schritten. Ob ein solcher Trigger vom Aktor verarbeitet wird, kann vom gesendeten Wert abhängen.<br />
<br />
HomeMatic kennt dazu (für jeden Peer und Triggertyp (short/long) separat) zwei Schaltschwellen Lo und Hi, die default bei 50 und 100 liegen. Ob ein Trigger in Relation zu diesen Schwellen verarbeitet wird, regeln u.a. die shCtxxx-Register. Wie auch bei den allgemeinen Schaltbedingungen stehen ''On'' und ''Off'' jeweils für den aktuellen Schaltzustand (Achtung: nicht den, der erreicht werden soll). Ihr Wert beträgt default "geLo" (greater or equal Lo), hier 50 und höher. Trigger für Werte darunter werden bei der Einstellung "ltLo" (less than Lo) verarbeitet. Diese Schwellen gibt es entsprechend auch für den Hi-Wert, also "geHi" oder "ltHi". Besonders interessant sind aber auch die Werte "outside" und "between", bezogen auf die beiden Schwellen Lo und Hi. In letzterem Fall wird der Trigger verarbeitet, wenn der Wert zwischen 50 und 100 liegt, bei "outside" entsprechend bei 0-49 oder 101-200.<br />
<br />
Sogenannte Three-State-Sensoren wie Fensterkontakt- oder -griffsensoren senden 0 für "closed" (geschlossen), 100 für "tilted" (gekippt) und 200 für "open" (offen). Gleiches gilt für Schalterkontaktinterfaces, die den Zustand eines angeschlossenen Schaltkontaktes übermitteln. Im Grundzustand (Vergleichsbefehl auf "geLo") führt daher nur der Trigger "offen" (200) zu einer Aktion. Ändert man den Vergleichsbefehl auf "ltLo", so wird lediglich "closed" ausgewertet, bei "between" ist es "tilted". Mit "outside" führt sowohl "closed" als auch "open" zu einer Aktion.<br />
<br />
Bei Bewegungsmeldern wird der mit übermittelte Helligkeitswert im Zusammenhang mit den (dann variabel einzustellenden) Schwellen als Kriterium für das Einschalten des Aktors mit herangezogen.<br />
<br />
<br />
==== ''shSwJtOn'' & Co. - Was soll passieren? ====<br />
Nachdem wir nun kennengelernt haben, wie man auswählt, '''welcher''' Anstoss von außen zu einer Aktion führt, hier ein kleiner Exkurs in die Beeinflussung, '''was''' daraufhin passieren soll. Diese Frage regelt die ''jump table'' und liefert damit das Regelwerk für die Abfolge der Aktionen, die ''state machine''. Ein HomeMatic-Aktor geht nämlich keineswegs einfach nur an oder aus. Vielmehr hangelt er sich nacheinander an einer Reihe von Zuständen entlang - auch das ist in der Einsteigerdokumentation erschöpfend beschrieben und soll hier nicht wiederholt werden. Ein Schalter durchläuft aber mindestens die Zustände<br />
Aus > Einschaltverzögerung > Ein > Ausschaltverzögerung > Aus > (usw)<br />
Hier soll reichen, dass am Ende jeder (Teil-)Kette in der Regel ein dauerstabiler Zustand bleibt, in der Regel ist das der Aus-Zustand und auch der Ein-Zustand, wenn dessen Laufzeit nicht durch ''shOnTime'' & Co. begrenzt ist. Ein- und Ausschaltverzögerung sind aber in der Regel 0 (Sekunden), so dass effektiv nur "Ein" und "Aus" übrig bleiben.<br />
<br />
Das Register ''shSwJtOn'' regelt, wohin die Reise geht, wenn ein gültiger ''short''-Trigger im eingeschalteten Zustand eintrifft, sinngemäß ''...Off'' im Auszustand und ''lg...'' für die ''long''-Trigger. Für ''shSwJtOn'' ist normalerweise als nächstes die Ausschaltverzögerung "dlyOff" vorgesehen. Da die Ausschaltverzögerung in der Regel 0 ist, folgt darauf, in ''shSwJtDly'' festgelegt, "off" usw. Die Zustände bilden so quasi einen Kreis, dessen Durchlauf von außen gelegentlich "angeschubst" wird. Mit diesen Registern kann man den Kreislauf aber auch umbiegen oder sogar unterbrechen, so dass ein eintreffender Trigger eben nicht zu einer Aktion führt. Als Ziele bieten sich, quasi selbstsprechend, "on", "dlyOff", "off" und "dlyOn" an - oder eben "no", was nichts anderes bedeutet, als dass der betreffende Trigger an dieser Stelle zu keiner Aktion führt.<br />
<br />
Bei einem Dimmer heißen die Register statt ''..Sw....'' nur ''..Dim....'' und es gibt ein paar mehr Bedingungen - die Funktion ist aber entsprechend gleich.<br />
<br />
<br />
==== ''shOnDly'' und ''shOffDly'' - es muss nicht immer sofort sein! ====<br />
Nicht nur welcher Anstoße welche Aktion auslöst, sondern auch wann oder wie schnell die Aktion ausgeführt wird, lässt sich in gewissen Grenzen einstellen. Die beiden genannten Register etwa regeln die Ein- oder Ausschaltverzögerung nach einem gültigen Trigger. So kann man nach einem Ausschaltbefehl einen Raum noch im Hellen verlassen, wenn das Licht noch ein paar Sekunden länger leuchtet.<br />
<br />
Bei Dimmern gibt es zusätzlich auch bei Ein- und Ausschaltvorgängen durch eine neu eingerichtete Verknüpfung eine sogenannte Rampenzeit von 0,5 Sekunden, in der das Licht hoch- oder heruntergedimmt wird. Durch Programmierung von ''shRampOnTime'' und ''shRampOffTime'' kann man ein sehr augenschonendes langsames Ein- oder Ausschalten des Lichts wie im Kino erreichen. Zwar gibt es die Zeiten auch für long-Trigger, aber da machen sie im Normalfall wenig Sinn - der lange Tastendruck löst immer einen manuellen Dimmvorgang aus.<br />
<br />
<br />
<br />
''(wird ergänzt)''<br />
<br />
<br />
== Praktische Beispiele ==<br />
Die folgenden Beispiele beschreiben nur in Kurzform die erforderlichen Aktionen. Weiterführende Informationen sind der Einsteigerdokumentation oder den o.g. Registerbeschreibungen zu entnehmen.<br />
Übrigens: ein einmal konfigurierter Vorgang für eine Verknüpfung kann aus FHEM auch bequem fernausgelöst (bzw. simuliert) werden. Der Aktor führt dabei genau die Aktion aus, die für die benannte Verknüpfung vorgesehen ist. Der kurze Knopfdruck auf den internen Knopf eines Aktors wird beispielsweise so simuliert:<br />
:<code>set <device> press short self01 </code><br />
<br />
<br />
=== Lokal bedienbarer Zeitschalter mit HomeMatic Aktoren: Pool für eine Stunde schalten ===<br />
Ich habe einen HM-LC-SW4-DR und der channel_01 schaltet die Poolzirkulationspumpe. Dies passiert zeitgesteuert zweimal am Tag. Manchmal möchte ich im Keller diese Pumpe einfach für eine Stunde aktivieren, der Aktor ist bequem erreichbar an der Wand.<br />
Die internen Tasten vom Hauptdevice (der Aktor hat vier Kanäle (channel), die in FHEM einzeln dargestellt werden) sichtbar machen:<br />
set LichtKeSW1 regSet intKeyVisib visib <br />
attr LichtKeSW1 expert 1 <br />
<br />
Jetzt sieht man im Channel 01 - LichtKeSW1_Sw01 den internen peer self01. (Channel 02 ist self02 usw.)<br />
Also jetzt einfach die Zeit eintragen:<br />
set LichtKeSW1 regSet shOnTime 3600 self01 <br />
<br />
Die Toggle Funktion der Taste bleibt erhalten. Ein zweiter Tastendruck schaltet die Pumpe auch sofort wieder aus. Während die Zeit läuft, blinkt die Status LED des Kanals.<br />
Die Zeitbegrenzung funktioniert in diesem Beispiel ohne jedes Zutun von FHEM und damit auch bei einem Ausfall des Servers.<br />
<br />
<br />
=== Es werde Licht! Automatisches Licht mit Tor oder Tür ===<br />
Im Kühlschrank geht das Licht ja schon praktischerweise automatisch an und aus, aber es gibt auch andere Situationen, in denen ein automatisches Licht sehr nützlich sein kann - in dunklen Abstellräumen oder Garagen. Vor allem weil man nicht vergessen kann es auszuschalten, weil es auch von allein ausgeht. Eine solche Funktion, so könnte man meinen, wird ganz einfach erreicht, indem man das Licht mit einem Aktor schalten lässt und diesen mit einem Tür- oder Fensterkontakt verknüpft. Hat man die beiden dann mit ''peerChan'' verknüpft, so wird man feststellen, dass das Licht mitnichten das Gewünschte tut: es schaltet sich beim Öffnen der Tür abwechselnd ein und aus und ignoriert das Schließen der Tür komplett.<br />
<br />
Verantwortlich für dieses "Fehlverhalten" sind die Register ''shCtOn'' und ''shCtOff''. Beide stehen nach der Verknüpfung auf "geLo". Wie bei den Registern oben erläutert, führt in diesem Fall nur die "offen"-Meldung des Türkontaktes zu einer Aktion. Das Öffnen der Tür soll den Aktor einschalten, das klappt. Das Schließen der Tür soll den eingeschalteten Aktor aber ausschalten. Also muss die Schaltbedingung im On-Zustand geändert werden (die Bezeichnungen natürlich durch die realen Namen des Schaltaktorkanals und des Türkontaktes ersetzen):<br />
:<code>set <Schalter> regSet shCtOn ltLo <Türkontakt> </code><br />
Nun führt auch das Schließen der Tür wunschgemäß stets zu einem Abschalten des Lichts. ''shCtOff'' muss auf "geLo" bleiben!<br />
<br />
Kombinieren ließe sich das noch mit einer Laufzeitbegrenzung etwa für eine Stunde - sollte man die Tür versehentlich offenlassen, so brennt das Licht nicht stundenlang. Vor allem geht das Licht dann auch aus, wenn aus welchem Grund auch immer die Schließmeldung verloren geht.<br />
:<code>set <Schalter> regSet shOnTime 3600 <Türkontakt> </code><br />
<br />
=== Lampe mit Kippschalter(n) fernschalten - eindeutig oder als Wechselschaltung ===<br />
Oft besteht der Wunsch, eine Lampe mit einem herkömmlichen Schalter (statt eines Tasters) fernzuschalten. So kann man einen herkömmlichen Schalter mit einer Schließerkontaktinterface wie dem [[HM-SCI-3-FM 3-Kanal-Funk-Schließerkontakt-Interface|HM-SCI-3-FM]] ergänzen (oder einem Kanal des [[HM-MOD-EM-8 8-Kanal-Sendemodul|8-Kanal-Sendemoduls]] in der Betriebsart ''sensor'') und wiederum die Verknüpfung mit dem Lampen-Aktor setzen. Ganz ähnlich wie bei der vorgenannten Abstellraum-Aufgabe führt nun aber das Schließen des Schalters nicht zu einem Einschalten. Daher ist nun <br />
:<code>set <Lampenaktor> regSet shCtOff ltLo <Sensorkontakt> </code><br />
das Mittel der Wahl, ''shCtOn'' muss dieses Mal auf "geLo" bleiben. Jetzt folgt der Aktor dem (sichtbaren) Schaltzustand des Schaltes - zumindest solange er nicht anderweitig ein- oder ausgeschaltet wird.<br />
<br />
Nun kann man auch mehrere Schalter so mit der Lampe koppeln. Das ergibt aber keine Wechselschaltung im herkömmlichen Sinn - um eine Lampe ein- oder auszuschalten, muss man den Schalter möglicherweise einmal zusätzlich auf die aktuelle Schaltposition kippen, ehe die nächste Betätigung den gewünschten Effekt bringt. Für Wechselschaltungen bietet sich daher das Kontaktinterface [[HM-SwI-3-FM]] (oder das erwähnte 8-Kanal-Sendemodul in der Betriebsart ''switch'') an. Hier führt jede Zustands''änderung'' zu einem Schaltvorgang.<br />
<br />
Hat man hingegen nur ein HM-SCI-3-FM zur Hand, lässt sich dieses Verhalten auch erreichen:<br />
:<code>set <Lampenaktor> regSet shCtOn outside <Sensorkontakt> </code><br />
:<code>set <Lampenaktor> regSet shCtOff outside <Sensorkontakt> </code><br />
<br />
=== Gezieltes Schalten eines (unsichtbaren) Aktors mit nur einer Taste ===<br />
Für so etwas braucht man gewöhnlich zwei Tasten. Koppelt man einen Schalt-Aktor mit nur einer Taste ("single" beim ''peerChan''-Kommando), so führt sowohl ein kurzer als auch ein langer Tastendruck immer nur zu einem Umschalten des Zustandes. Das ist unschön, wenn man den aktuellen Zustand nicht einsehen kann. <br />
<br />
Üblicherweise sind die Schaltabfolgen für eine Eintasten-Verknüpfung sowohl für kurze als auch lange Betätigungen gleich (bei Dimmern wird auf langen Tastendruck hingegen abwechselnd auf- oder abgedimmt). <br />
shSwJtOff = dlyOn # Ist Gerät aus, wird Einschaltverzögerung gewählt (die aber normal 0 ist)<br />
lgSwJtOff = dlyOn # dito, für lang<br />
shSwJtOn = dlyOff # Ist Gerät an, wird Ausschaltverzögerung gewählt (die aber normal 0 ist)<br />
lgSwJtOn = dlyOff # dito, für lang<br />
Hier kann man sich zunutze machen, dass man mit einem gezielten "no" oder "dlyOn" bzw. "dlyOff" im richtigen Register die Schaltfolge abbrechen oder umbiegen kann.<br />
Möchte man das Gerät <aktor> mit einem kurzen Tastendruck auf <button> ein- und mit einem langen Tastendruck ausschalten, so ändere man:<br />
:<code>set <aktor> regSet shSwJtOn dlyOn <button> </code><br />
:<code>set <aktor> regSet lgSwJtOff dlyOff <button> </code><br />
So laufen die entsprechenden Aktionen quasi ins Leere, wenn der Aktor bereits den gewünschten Zustand hat.<br />
<br />
Den umgekehrten Effekt (lang schaltet ein, kurz aus) erreicht man entsprechend mit<br />
:<code>set <aktor> regSet shSwJtOff dlyOff <button> </code><br />
:<code>set <aktor> regSet lgSwJtOn dlyOn <button> </code><br />
<br />
Welche Bedienhaptik man nun bevorzugt, muss man selbst entscheiden. In der Regel sollte die normale (sichere) Aktion "kurz" und die gefährlichere "lang" sein - eine PC-Stromversorgung mit einem kurzen Tastendruck versehentlich einzuschalten ist bestimmt besser als auszuschalten (das dann eben nur über lang) - für ein potentiell gefährliches Arbeitsgerät wie einen Heizofen wird es sicher andersherum sein.<br />
<br />
Sinngemäß verwendet der Autor sozusagen eine Hälfte davon als "Sicherheitsaktion" für einen [[HM-LC-Sw2PB-FM Schaltaktor mit Tasteraufsatz 2fach]] - der gewöhnliche Tastendruck auf die zugehörige Wippenseite schaltet den Aktor abwechselnd ein und aus, ein langer Tastendruck immer aus, dafür reicht:<br />
:<code>set <aktor> regSet lgSwJtOff dlyOff <button> </code><br />
<br />
Übrigens: Nichts anderes wird normalerweise auch automatisch beim Verknüpfen eines Aktors mit einem Tastenpaar an der entsprechenden Stelle gemacht - ist eine Taste nur zum Ausschalten gedacht, so wird in beiden Schaltzuständen entsprechend "dlyOff" eingetragen. Als "Sprungziel" müsste aber genauso gut auch "no" funkionieren.<br />
<br />
<br />
=== WARNUNG! - Selbsttätiges Blinken eines HM-Aktors ===<br />
Statt einer separaten Warnleuchte kann es durchaus sinnvoll sein, eine vorhandene Lampe zu Warnzwecken periodisch ein- und auszuschalten. Leider beherrschen die HomeMatic-Aktoren keine direkt aus FHEM erreichbare Blinkfunktion (ähnlich dem on-for-timer für eine Zeitbegrenzung), und das rhythmische Ein- und Ausschalten aus FHEM erzeugt eine recht hohe Funklast.<br />
<br />
Wir wissen aber, dass die Aktoren für jeden Peer nicht nur eine Ein-, sondern auch eine Ausschaltzeit speichern. Definiert man nun für einen Peer entsprechend beide Zeiten, so wird der Aktor bei einem Telegramm von diesem Peer sich entsprechend selbsttätig fortlaufend ein- und ausschalten. Jeder andere Schaltbefehl eines anderen Peers oder aus FHEM beendet die Schleife umgehend. So ließe sich das Blinken auch mit einer aktoreigenen Taste stoppen - oder starten, wenn man es entsprechend programmiert. Einen Zwischenstecker-Schalter beispielsweise kann man also (wenn man zuvor seine ''confBtnTime'' entsprechend setzt und so die langen Tastendrücke auswertbar macht) durch das Programmieren von ''lgOnTime'' und ''lgOffTime'' für den Peer "self01" wie gewohnt mit einem kurzen Tastendruck ein- und ausschalten und mit einem langen in den Blinkmodus versetzen.<br />
<br />
Einen Haken hat die Sache aber (möglicherweise): Der Aktor meldet seinen Schaltzustand natürlich periodisch. Allerdings tut er das mit einer gewissen Verzögerung. Beim Blinken in einem 2-Sekunden-Rhythmus kommen jedenfalls noch keine regelmäßigen Statustelegramme, die die Funklast erhöhen würden.<br />
<br />
Eine weitere Möglichkeit wäre, virtuelle Buttons (etwa einer VCCU) zum Ein- und Ausschalten der Blinkfunktion zu verwenden. "Opfert" man dafür zwei aufeinanderfolgende Kanäle, kann man die Aktoren mit "dual set" peeren und bekommt so einen Blink- und einen Deaktivierungsbutton ohne weitere Kopfstände. Anschließend passt man die short-Laufzeiten für den Einschaltkanal an: <br />
<br />
Ein Beispiel für einen Dimmer (als virtuelle Buttons dienen vccu_Btn8 und vccuBtn9):<br />
<br />
:<code>set <vccu_Btn8> peerChan 0 <dimmerkanal> dual set</code><br />
<br />
Nun kann man mit "set vccu_Btn9 press short" den Dimmer ein- und mit "set vccu_Btn8 press short" ausschalten. Das Blinken im Dimmer wird eingestellt mit <br />
<br />
:<code>set dimmer regSet shOnTime 1 vccu_Btn9</code><br />
:<code>set dimmer regSet shOffTime 1 vccu_Btn9</code><br />
<br />
Wird der Dimmer nun mit "set vccu_Btn9 press short" eingeschaltet, so blinkt er im 3-Sekunden-Takt: zu den jeweils 1 Sekunde Ein- und Auszeit gesellen sich noch 2x 0,5s Rampenzeit, sofern nichts anderes programmiert wurde.<br />
<br />
Natürlich kann man eine größere Anzahl von Aktoren mit den virtuellen Buttons peeren und so ein ganzes Feuerwerk zünden ...<br />
<br />
<br />
=== Einer nach dem Anderen! - Sequentielles Schalten mehrerer Aktoren ===<br />
Eine großflächige Beleuchtung mit viel Leistung sollte man aus Lastgründen niemals zugleich einschalten. Auch LED-Lampen ziehen im Einschaltmoment, wennauch extrem kurz, beträchtliche Ströme, die die von gewöhnlichen Glühlampen deutlich übersteigen können. Schaltet man mehrere Aktoren gleichzeitig mit einer Taste, so hilft eine individuelle Verzögerung des Einschaltvorgangs in jedem Aktor, die Sicherung vor dem Herausfliegen zu bewahren. Oder man macht gezielt einen Effekt daraus. Der Phantasie sind wenig Grenzen gesetzt...<br />
<br />
Hat man drei Aktoren "Aussenlicht1...3" mit dem Taster "Aussenlicht_Ein" gepeert, so erreicht man auf folgende Weise, dass sie beim Einschalten mit einer Verzögerung von jeweils einer Sekunde nacheinander einschalten.<br />
<br />
:<code>set Aussenlicht2 regSet shOnDly 1 Aussenlicht_Ein</code><br />
:<code>set Aussenlicht3 regSet shOnDly 2 Aussenlicht_Ein</code><br />
<br />
<br />
<br />
<br />
<br />
[[Kategorie:HomeMatic Components|1toolsAndWork]]</div>Martinp876http://wiki.fhem.de/w/index.php?title=Pairing_und_Peering&diff=23893Pairing und Peering2017-12-29T10:30:09Z<p>Martinp876: </p>
<hr />
<div>{{Todo|Dieser Artikel ist obsolet da pairen und peeren schon beschrieben sind. }}<br />
Pairing und Peering sind Begriffe aus dem [[HomeMatic]]-Programm von Sensoren und Aktoren.<br />
<br />
* Beim '''Pairing''' (deutsch: Paarung) wird ein HomeMatic-Gerät mit einem IO-Device (z.B. CUL/CUN/HM-LAN) verknüpft, so dass das HomeMatic-Gerät von FHEM über dieses IO-Device abgefragt und gesteuert werden kann. FHEM spielt hierbei die Rolle einer HomeMatic-Zentrale. Näheres zum Pairing siehe unter [[HomeMatic Devices pairen]].<br />
* Beim '''Peering''' (deutsch sinngemäß: Verbindung mit Gleichen) wird ein HomeMatic-Geräte-Kanal mit einem oder mehreren anderen HomeMatic-Geräte-Kanälen so verknüpft, dass es mit diesen Daten austauschen kann. Dabei kann es sich sowohl um Zahlenwerte handeln (z.B. die Solltemperatur), als auch um Kommandos (z.B. Schaltzustände). Näheres zum Peering siehe unter [[Homematic Peering Beispiele]].<br />
<br />
Ein direktes Peering zweier HomeMatic-Geräte ist nur möglich, wenn keines zuvor gepairt wurde. Anderenfalls ist das Peering nur noch indirekt, d.h. über die Zentrale (in diesem Falle also FHEM) möglich.<br />
<br />
<br />
[[Kategorie:HomeMatic Components|1toolsAndWork]]</div>Martinp876http://wiki.fhem.de/w/index.php?title=1%25_Regel&diff=238921% Regel2017-12-29T10:29:41Z<p>Martinp876: </p>
<hr />
<div>= 1% Relative Frequenzbelegungsdauer =<br />
Die Bundesnetzagentur schreibt für die Nutzung verschiedener ansonsten frei nutzbarer Frequenzbereiche sogenannte maximale relative Frequenzbelegungsdauern fest. Sinn dieser Maßnahme ist es, die Nutzung der Frequenzbänder durch mehrere Nutzer auch bei Reichweitenüberlagerung zu ermöglichen. Für 868,35&#160;MHz, also der Frequenz, in dem z.B. das HM, FS20 und FHT System arbeiten, sind ≤ 1% vorgeschrieben. Dies ergibt 36 Sekunden Sendedauer je Stunde. Besonders bei der eher langsamen Datenübertragung der FHT und FS20 Protokolle kann es zu Engpässen kommen.<br />
<br />
== Details ==<br />
Um einen Kommunikationskanal durch mehrere Teilnehmer effektiv zu nutzen, bieten sich mehrere Verfahren an. Im Wesentlichen sind dies:<br />
<br />
* Token-Verfahren. Senden darf nur, wer gerade ein von Teilnehmer zu Teilnehmer herumgereichtes "Pfand" (=Token) besitzt. Tokenverfahren sind aufwändig zu implementieren und erfordern bidirektionale Kommunikation.<br />
* LBT-Verfahren. Senden darf ein Teilnehmer nur, wenn er sich vorher durch "Lauschen" vergewissert hat, dass sonst niemand sendet, der Kanal also frei ist. (LBT = Listen before talk). Es ist theoretisch jedoch denkbar, dass zwei Sender zugleich lauschen, den Kanal frei vorfinden und zugleich anfangen zu senden. LBT Verfahren sind in frei nutzbaren Kanälen mit vielen Teilnehmern schwierig zu implementieren. (Die Kommunikation zwischen [[CUL]]/CUNO und [[RFR CUL]] arbeitet aber z.B. nach diesem Verfahren.)<br />
* Zeitbeschränkung. Jeder Teilnehmer darf nur sehr kurz senden. Die Sendedauer ist so zu wählen, dass jeder Teilnehmer eine signifikante Chance hat, zufällig auf einen freien Kanal zu treffen. Dies ist beispielsweise gegeben, wenn der Kanal zu 90 oder mehr Prozent frei ist.<br />
<br />
Bei LBT und Zeitbeschränkung sind außerdem Verfahren zu implementieren, die greifen wenn der Kanal nicht frei war, die Aussendung also durch Überlagerung einer anderen Sendung gestört wurde. In der Regel wird man den erfolglosen Sendeversuch nach einer zufälligen Zeit wiederholen.<br />
<br />
Die Verfahren sind in der obigen Reihenfolge weniger aufwändig zu implementieren, d.h. Zeitbeschränkung erfordert den geringsten Aufwand.<br />
<br />
Die Bundesnetzagentur schreibt vor, dass im Frequenzbereich von 868,000 bis 868,600&#160;MHz 1% "Duty cycle" ODER die Nutzung von LBT-Verfahren implementiert sind, wobei sie definiert:<br />
<br />
<dl><dd>''Die relative Frequenzbelegungsdauer (duty cycle) in&#160;% kennzeichnet die Dauer der Aussendungen eines Senders auf einer Frequenz bezogen auf 1 Stunde. Die Gesamtsendezeit kann auf mehrere Intervalle aufgeteilt werden.''</dd></dl><br />
und<br />
<br />
<dl><dd>''LBT: Verfahren, mit dem die Kanalbelegungssituation vor Beginn und während der Aussendung geprüft wird. Aussendung erfolgt nur bei freiem Kanal.''</dd></dl><br />
Zumindest wegen des geringen Implementierungsaufwandes hat ELV als Entwickler der FS20 / FHT / HomeMatic Funkkomponenten kein LBT verwendet, sondern beachtet vielmehr die maximale Frequenzbelegungsdauer.<br />
<br />
== Bedeutung für das FS20 / FHT Funksystem ==<br />
Aus der relativen Frequenzbelegungsdauer von 1% je Stunde, also nur 36 Sekunden je Stunde, ergeben sich für das FS20 / FHT System deutliche Einschränkungen. Insbesondere ist die [[Maximal nutzbare Geräte]] stark eingeschränkt. Wegen der umfangreichen bidirektionalen Kommunikation zwischen Raumreglern und der Zentrale mit einer im Vergleich zu HomeMatic eher geringen Bandbreite lassen sich beispielsweise sinnvoll nur etwa 10-12 Räume mit FHT über Funk steuern. <br />
<br />
Problematisch kann die 1% Regel auch in Debuggingphasen sein, wenn also neue FHEM Konfigurationen mehrfach in kurzer Folge ausprobiert werden.<br />
<br />
Praktisch umgesetzt ist das 1% Sendelimit z.B. im [[LOVF]] (= Limit-overflow). Eine FS20 Übertragung benötigt mindestens ca. 220ms also ca. 22 Sendeeinheiten. Ist die maximale Frequenzbelegungsdauer erreicht, dauert es also mindestens 22 Sekunden, bis erstmals wieder gesendet werden kann. <br />
<br />
Daraus ergibt sich, dass maximal 163 FS20 Kommandos pro Stunde gesendet werden können. Wird dieser Wert überschritten, meldet FHEM '''CUL TRANSMIT LIMIT EXCEEDED'''. Eine weitere Schaltung von FS20 Komponenten ist dann nicht mehr möglich. Dies ist insbesondere auch beim Einsatz von [[FS20_PIRA_Infrarot-Bewegungsmelder|Bewegungsmeldern]] von Bedeutung, wenn deren Sendeabstand sehr kurz eingestellt ist.<br />
<br />
== Bedeutung für das HomeMatic Funksystem ==<br />
HomeMatic verwendet eine höhere Datenübertragungsrate, sodass die Kommunikation wesentlich schneller abläuft und die Grenzen wesentlich weiter sind. Dennoch kann es auch bei HomeMatic vorkommen, dass die Grenzen erreicht werden.<br />
<br />
Überschlägig kann HM etwa 1600 Nachrichten Je Stunde senden. Dazu zählen auch ACKs.<br />
Ein Burst kostet 16 Messages. Es können also nur ca. 100 Bursts je Stunde gesendet werden. <br />
Das gilt jeweils für das Aufwecken eines Device, die folgenden Messages sind "billiger".<br />
<br />
Zu beachten ist allerdings, dass z.B. der [[HMLAN Konfigurator]] Sendungen 3mal wiederholt, wenn keine Antwort kommt. Sendet man also ein Burst an ein Device, das nicht aktiv ist, ist das Sendekontingent nach nur 30 Versuchen je Stunde verbraucht.<br />
<br />
Es gibt aber noch andere Prozesse die viel Funklast erzeugen.<br />
<br />
*Insbesondere ist bei FHEM Versionen ab Oktober 2013 das Attribut ''autoReadReg'' auf "4_reqStatus" gesetzt. Damit wird für jedes HM-Device mit diesem so gesetzten Attribut beim FHEM-Start ein ''getConfig'' durchgeführt, was viel Funkverkehr erfordert.<br />
<br />
Je nach Anzahl der Geräte kann dazu führen, dass insgesamt zu viel Funklast erzeugt wird, im Logfile erscheint dann eine Meldung wie:<br />
<br />
2013.10.03 13:41:18 2: HMLAN_Parse: HMLAN1 new condition ERROR-Overload<br />
<br />
Ab diesem Moment werden eben auch keine anderen Befehle mehr an weitere HM-Geräte geschickt, da das Funkkontingent aufgebraucht ist. Erst nach einer Stunde kann erneut gesendet werden. <br />
<br />
''autoReadReg'' auf "4_reqStatus" kann also dazu führen, dass nach einem Neustart HM sofort sein Funkkontingent aufgebracht hat.<br />
<br />
Als '''Notbehelf''' kann die Funkschnittstelle resetted oder ([[HMLAN Konfigurator]]) kurz stromlos gemacht werden. Dann wird der Zähler wieder auf Null gesetzt.<br />
Alternativ können so viele HM-Geräte wie möglich auf ''autoReadReg 0_off'' gesetzt werden.<br />
<br />
* Ausserdem ist zu berücksichtigen, dass sich bei Einschaltung des [[AES Encryption|Signing Requests]] der Funkverkehr in etwa verdoppelt, was bei grossen Installationen schon im Normalbetrieb zum Erreichen der Grenze führen könnte.<br />
<br />
== Links ==<br />
* [[Maximal nutzbare SlowRF Geräte]]<br />
<br />
* Bundesnetzagentur [http://www.bundesnetzagentur.de/cae/servlet/contentblob/134184/publicationFile/2570/FundstelleId5772pdf.pdf] Vfg. 20 / 2006<br />
[http://www.bundesnetzagentur.de/cae/servlet/contentblob/38206/publicationFile/2580/ShortRangeDevicesSRD_ID17299pdf.pdf] Vfg 30 / 2006, geändert mit Vfg. 39/2009<br />
<br />
[[Kategorie:Glossary]]<br />
[[Kategorie:FHT Components]]<br />
[[Kategorie:HomeMatic Components|2Info]]</div>Martinp876http://wiki.fhem.de/w/index.php?title=1%25_Regel&diff=238911% Regel2017-12-29T10:29:14Z<p>Martinp876: </p>
<hr />
<div>= 1% Relative Frequenzbelegungsdauer =<br />
Die Bundesnetzagentur schreibt für die Nutzung verschiedener ansonsten frei nutzbarer Frequenzbereiche sogenannte maximale relative Frequenzbelegungsdauern fest. Sinn dieser Maßnahme ist es, die Nutzung der Frequenzbänder durch mehrere Nutzer auch bei Reichweitenüberlagerung zu ermöglichen. Für 868,35&#160;MHz, also der Frequenz, in dem z.B. das HM, FS20 und FHT System arbeiten, sind ≤ 1% vorgeschrieben. Dies ergibt 36 Sekunden Sendedauer je Stunde. Besonders bei der eher langsamen Datenübertragung der FHT und FS20 Protokolle kann es zu Engpässen kommen.<br />
<br />
== Details ==<br />
Um einen Kommunikationskanal durch mehrere Teilnehmer effektiv zu nutzen, bieten sich mehrere Verfahren an. Im Wesentlichen sind dies:<br />
<br />
* Token-Verfahren. Senden darf nur, wer gerade ein von Teilnehmer zu Teilnehmer herumgereichtes "Pfand" (=Token) besitzt. Tokenverfahren sind aufwändig zu implementieren und erfordern bidirektionale Kommunikation.<br />
* LBT-Verfahren. Senden darf ein Teilnehmer nur, wenn er sich vorher durch "Lauschen" vergewissert hat, dass sonst niemand sendet, der Kanal also frei ist. (LBT = Listen before talk). Es ist theoretisch jedoch denkbar, dass zwei Sender zugleich lauschen, den Kanal frei vorfinden und zugleich anfangen zu senden. LBT Verfahren sind in frei nutzbaren Kanälen mit vielen Teilnehmern schwierig zu implementieren. (Die Kommunikation zwischen [[CUL]]/CUNO und [[RFR CUL]] arbeitet aber z.B. nach diesem Verfahren.)<br />
* Zeitbeschränkung. Jeder Teilnehmer darf nur sehr kurz senden. Die Sendedauer ist so zu wählen, dass jeder Teilnehmer eine signifikante Chance hat, zufällig auf einen freien Kanal zu treffen. Dies ist beispielsweise gegeben, wenn der Kanal zu 90 oder mehr Prozent frei ist.<br />
<br />
Bei LBT und Zeitbeschränkung sind außerdem Verfahren zu implementieren, die greifen wenn der Kanal nicht frei war, die Aussendung also durch Überlagerung einer anderen Sendung gestört wurde. In der Regel wird man den erfolglosen Sendeversuch nach einer zufälligen Zeit wiederholen.<br />
<br />
Die Verfahren sind in der obigen Reihenfolge weniger aufwändig zu implementieren, d.h. Zeitbeschränkung erfordert den geringsten Aufwand.<br />
<br />
Die Bundesnetzagentur schreibt vor, dass im Frequenzbereich von 868,000 bis 868,600&#160;MHz 1% "Duty cycle" ODER die Nutzung von LBT-Verfahren implementiert sind, wobei sie definiert:<br />
<br />
<dl><dd>''Die relative Frequenzbelegungsdauer (duty cycle) in&#160;% kennzeichnet die Dauer der Aussendungen eines Senders auf einer Frequenz bezogen auf 1 Stunde. Die Gesamtsendezeit kann auf mehrere Intervalle aufgeteilt werden.''</dd></dl><br />
und<br />
<br />
<dl><dd>''LBT: Verfahren, mit dem die Kanalbelegungssituation vor Beginn und während der Aussendung geprüft wird. Aussendung erfolgt nur bei freiem Kanal.''</dd></dl><br />
Zumindest wegen des geringen Implementierungsaufwandes hat ELV als Entwickler der FS20 / FHT / HomeMatic Funkkomponenten kein LBT verwendet, sondern beachtet vielmehr die maximale Frequenzbelegungsdauer.<br />
<br />
== Bedeutung für das FS20 / FHT Funksystem ==<br />
Aus der relativen Frequenzbelegungsdauer von 1% je Stunde, also nur 36 Sekunden je Stunde, ergeben sich für das FS20 / FHT System deutliche Einschränkungen. Insbesondere ist die [[Maximal nutzbare Geräte]] stark eingeschränkt. Wegen der umfangreichen bidirektionalen Kommunikation zwischen Raumreglern und der Zentrale mit einer im Vergleich zu HomeMatic eher geringen Bandbreite lassen sich beispielsweise sinnvoll nur etwa 10-12 Räume mit FHT über Funk steuern. <br />
<br />
Problematisch kann die 1% Regel auch in Debuggingphasen sein, wenn also neue FHEM Konfigurationen mehrfach in kurzer Folge ausprobiert werden.<br />
<br />
Praktisch umgesetzt ist das 1% Sendelimit z.B. im [[LOVF]] (= Limit-overflow). Eine FS20 Übertragung benötigt mindestens ca. 220ms also ca. 22 Sendeeinheiten. Ist die maximale Frequenzbelegungsdauer erreicht, dauert es also mindestens 22 Sekunden, bis erstmals wieder gesendet werden kann. <br />
<br />
Daraus ergibt sich, dass maximal 163 FS20 Kommandos pro Stunde gesendet werden können. Wird dieser Wert überschritten, meldet FHEM '''CUL TRANSMIT LIMIT EXCEEDED'''. Eine weitere Schaltung von FS20 Komponenten ist dann nicht mehr möglich. Dies ist insbesondere auch beim Einsatz von [[FS20_PIRA_Infrarot-Bewegungsmelder|Bewegungsmeldern]] von Bedeutung, wenn deren Sendeabstand sehr kurz eingestellt ist.<br />
<br />
== Bedeutung für das HomeMatic Funksystem ==<br />
HomeMatic verwendet eine höhere Datenübertragungsrate, sodass die Kommunikation wesentlich schneller abläuft und die Grenzen wesentlich weiter sind. Dennoch kann es auch bei HomeMatic vorkommen, dass die Grenzen erreicht werden.<br />
<br />
Überschlägig kann HM etwa 1600 Nachrichten Je Stunde senden. Dazu zählen auch ACKs.<br />
Ein Burst kostet 16 Messages. Es können also nur ca. 100 Bursts je Stunde gesendet werden. <br />
Das gilt jeweils für das Aufwecken eines Device, die folgenden Messages sind "billiger".<br />
<br />
Zu beachten ist allerdings, dass z.B. der [[HMLAN Konfigurator]] Sendungen 3mal wiederholt, wenn keine Antwort kommt. Sendet man also ein Burst an ein Device, das nicht aktiv ist, ist das Sendekontingent nach nur 30 Versuchen je Stunde verbraucht.<br />
<br />
Es gibt aber noch andere Prozesse die viel Funklast erzeugen.<br />
<br />
*Insbesondere ist bei FHEM Versionen ab Oktober 2013 das Attribut ''autoReadReg'' auf "4_reqStatus" gesetzt. Damit wird für jedes HM-Device mit diesem so gesetzten Attribut beim FHEM-Start ein ''getConfig'' durchgeführt, was viel Funkverkehr erfordert.<br />
<br />
Je nach Anzahl der Geräte kann dazu führen, dass insgesamt zu viel Funklast erzeugt wird, im Logfile erscheint dann eine Meldung wie:<br />
<br />
2013.10.03 13:41:18 2: HMLAN_Parse: HMLAN1 new condition ERROR-Overload<br />
<br />
Ab diesem Moment werden eben auch keine anderen Befehle mehr an weitere HM-Geräte geschickt, da das Funkkontingent aufgebraucht ist. Erst nach einer Stunde kann erneut gesendet werden. <br />
<br />
''autoReadReg'' auf "4_reqStatus" kann also dazu führen, dass nach einem Neustart HM sofort sein Funkkontingent aufgebracht hat.<br />
<br />
Als '''Notbehelf''' kann die Funkschnittstelle resetted oder ([[HMLAN Konfigurator]]) kurz stromlos gemacht werden. Dann wird der Zähler wieder auf Null gesetzt.<br />
Alternativ können so viele HM-Geräte wie möglich auf ''autoReadReg 0_off'' gesetzt werden.<br />
<br />
* Ausserdem ist zu berücksichtigen, dass sich bei Einschaltung des [[AES Encryption|Signing Requests]] der Funkverkehr in etwa verdoppelt, was bei grossen Installationen schon im Normalbetrieb zum Erreichen der Grenze führen könnte.<br />
<br />
== Links ==<br />
* [[Maximal nutzbare SlowRF Geräte]]<br />
<br />
* Bundesnetzagentur [http://www.bundesnetzagentur.de/cae/servlet/contentblob/134184/publicationFile/2570/FundstelleId5772pdf.pdf] Vfg. 20 / 2006<br />
[http://www.bundesnetzagentur.de/cae/servlet/contentblob/38206/publicationFile/2580/ShortRangeDevicesSRD_ID17299pdf.pdf] Vfg 30 / 2006, geändert mit Vfg. 39/2009<br />
<br />
[[Kategorie:Glossary]]<br />
[[Kategorie:FHT Components]]<br />
[[Kategorie:HomeMatic Components|1Info]]</div>Martinp876http://wiki.fhem.de/w/index.php?title=AES_Encryption&diff=23890AES Encryption2017-12-29T10:28:45Z<p>Martinp876: </p>
<hr />
<div>= Grundlagen =<br />
Anders als der Name vermuteten lässt, handelt es sich beim HM (HomeMatic) AES-Encryption Modus des "BidCos"-Protokolls nicht um verschlüsselten Funkverkehr, sondern um das Einschalten eines Signatur-Modus (AES-Challenge-Response (CR)). Hierbei muss sich der Sender durch das Signieren seiner Nachrichten mit einem allen Kommunikationspartnern bekannten AES-Schlüssel authentifizieren. Der Empfänger wird das Kommando nur ausführen, wenn die Authentifizierung korrekt ist.<br />
Die eigentliche Datenübertragung findet im Klartext statt und kann immer mitgelesen bzw. abgehört werden, jedoch werden keine Kommandos von nicht autorisierter Quellen ausgeführt.<br />
<br />
Der AES-Encryption Modus sichert, wenn eingeschaltet<br />
* das Ändern der Gerätekonfiguration<br />
* das Auslösen von Triggern (Tasten, Sensoren,...)<br />
* das Schalten von Aktoren<br />
<br />
== AES-Prinzip ==<br />
Der '''Advanced Encryption Standard''' (AES) ist ein im Auftrag der US-Regierung entwickeltes symmetrisches Verschlüsselungsverfahren, bei dem sowohl Sender als auch Empfänger über die Kenntnis eines ''geheimen'' Schlüssels verfügen müssen. Das AES-Verfahren ist öffentlich bekannt und erfüllt damit ein wesentliches Kriterium sicherer Verfahren, nämlich ihre Überprüfbarkeit. Bis heute ist kein Verfahren bekannt, mit dem man eine AES-Verschlüsselung ohne Kenntnis des Schlüssels "knacken" kann. Es gibt auch keine Hinweise darauf, dass die NSA dazu im Stande sein könnte.<br />
<br />
== Signatur ==<br />
Bei einer digitalen Signatur werden nicht Schlüssel verglichen, sondern das Ergebnis der Verschlüsselung bestimmter kurzer Datensätze. Ist das Ergebnis der Verschlüsselung bei Sender und Empfänger gleich, kennen bei den gleichen geheimen Schlüssel.<br />
<br />
= Kommunikationsstrecken =<br />
Der sichere Betrieb von Hausautomatisierungssystemen betrifft unterschiedliche Kommunikationspfade. <br />
* Von der SmartHome-Zentrale gibt es einen Weg zum Eingabeterminal (Web-Interface auf PC, Smartphone o.ä.), die Zentrale-Frontend-Schnittstelle. <br />
* Weiter gibt es einen Weg zum I/O-Gerät ([[HMLAN Konfigurator]], [[HM-CFG-USB USB Konfigurations-Adapter]], [[CUL]], [[CUN]], [[CUNO]]) welches die Brücke zur Funk- oder Kabelstrecke herstellt. Wenn FHEM die Zentrale bildet, ist das die FHEM-I/O-Schnittstelle.<br />
* Es folgt die I/O-Geräte-Schnittstelle, die Funk- oder Kabelstrecke.<br />
* Letztlich gibt es noch die Geräte-Geräte Schnittstelle für die direkte Kommunikation der HomeMatic-Geräte untereinander. <br />
<br />
== Zentrale ←→ Frontend ==<br />
Diese Schnittstelle ist in der Regel eine internetbasierte Verbindung, meist in Form eines Aufrufes im Web-Browser. Hier muss durch eines der standardisierten Sicherheitsverfahren im Internet für sichere Kommunikation gesorgt werden: Virtual Private Network (VPN), verschlüsseltes WLAN und HTTPS sind gängige Methoden, die hier nicht weiter diskutiert werden sollen.<br />
<br />
== Zentrale ←→ I/O-Device ==<br />
HomeMatic unterstützt auf dieser Strecke prinzipiell eine AES-Verschlüsselung, dies ist in FHEM allerdings nicht überall implementiert. Nutzt man stattdessen eine originale HomeMatic CCU2-Zentrale, kann hier AES aktiviert werden. Wenn FHEM die Zentrale ist, muss im [[HMLAN Konfigurator]] die netzwerkseitige AES-Verschlüsselung über die HM-PC-Software abgeschaltet werden, sonst kann FHEM nicht mit dem [[HMLAN Konfigurator]] kommunizieren. <br />
Das [[HM-LGW-O-TW-W-EU Funk-LAN Gateway]] kann mit und ohne LAN AES genutzt werden (Konfiguration mit LAN Konfigurator/Netfinder von eq3). Für LAN AES muss das Perl-Modul <code>Crypt::Rijndael</code> (Debian: <code>libcrypt-rijndael-perl</code>) installiert sein.<br />
<br />
Es sind 2 Schnittstellen zu betrachten: <br />
Nutzt man ein USB Interface besteht i.a. kein Sicherheitsproblem. Man muss sicherstellen, dass niemand in die Zentrale eindringen kann.<br />
Sollte man ein I/O-Device per LAN oder WLAN benutzen ([[HMLAN Konfigurator]], [[CUN]], [[CUNO]]) muss dieses Netz entsprechend gesichert sein. Entsprechende Verfahren (z.B. VLAN, Firewalls,...) werden hier nicht weiter besprochen.<br />
<br />
== I/O-Device ←→ Gerät ==<br />
Dieses Teilstück kann mit AES gesichert werden. <br />
Die Kommunikation auf Signaturbasis ist im Abschnitt [[#Ablauf|Ablauf]] beschrieben. <br />
<br />
Es kann ein [[HomeMatic#FHEM_als_Zentrale|HomeMatic]] IO oder ein [[CUL]] kompatibler Io genutzt werden. <br />
Die HomeMatic Module und IOs können AES von sich aus. Für alle [[CUL]]-kompatiblen Geräte muss das Perl-Modul <code>Crypt::Rijndael</code> (Debian: <code>libcrypt-rijndael-perl</code>) installiert sein.<br />
<br />
Bei CUL Kompatiblen Geräten kann es zu Timingproblemen kommen. Für CUL Geräte ist für HomeMatic generell die {{Link2Forum|Topic=31421|LinkText=TS Firmware}} angeraten!<br />
<br />
Beim Einsatz von AES-CBC, z.B. dem Rauchmelder HM-SEC-SD-2, wird generell das Perl-Modul <code>Crypt::Rijndael</code> (Debian: <code>libcrypt-rijndael-perl</code>) benötigt!<br />
<br />
== Gerät ←→ Gerät ==<br />
AES kann auch für die Kommunikation zwischen den Geräten aktiviert werden. Hierbei werden Trigger von Sensoren (z.B. Tasten) durch den Empfänger durch Anforderung einer AES-Signatur überprüft. Dies kann je Kanal aktiviert bzw. deaktiviert werden: Ein 2-Kanal Schalter kann also auf einem Kanal AES nutzen und auf dem anderen nicht.<br />
<br />
= Ablauf =<br />
Bei eingeschaltetem AES-Encryption Modus wird ein Kommando durch den Empfänger nicht sofort ausgeführt. Der Empfänger sendet vielmehr einen Binärwert mit Signaturanforderung an den Sender (Challenge), welche dieser mit seinem bekannten AES-Schlüssel kodieren und zurücksenden muss (Response). Der Empfänger vergleicht diese mit einem Wert, den er selbst aus der Verschlüsselung mit seinem Schlüssel erhält. Nur wenn beide verschlüsselten Datenwerte übereinstimmen, wird das zuerst erhaltene Kommando ausgeführt und der Empfänger quittiert mit einem ACK an den Sender.<br />
<br />
Die AES Challenge-Response Antwort wird mit dem System-Schlüssel erzeugt. Der System-Schlüssel wird von der Zentrale bzw. dem [[HMLAN Konfigurator]] auf alle gepairten HomeMatic Geräte verteilt. Ab Werk ist ein einheitlicher Standard-Schlüssel hinterlegt. Dieser ist in '''allen''' HM-Geräten gleich und '''muss''' somit vom User geändert werden um einen sinnvollen Schutz zu erreichen.<br />
<br />
== Overhead ==<br />
Es ist aus diesem Ablauf klar, dass der AES-Encryption Modus zu einer zusätzlichen Zeitverzögerung zwischen dem Absenden und dem Ausführen eines Kommandos führt. Im günstigen Fall kann diese etwa 200 ms betragen, in ungünstigen Fällen auch höher sein. Außerdem erhöht sich auf einer Funkstrecke mit AES-Encryption Modus die Funklast auf den dreifachen Wert. Wegen der 1%-Regel kann dies ein I/O-Gerät durchaus in die Überladung mit Befehlen steuern.<br />
<br />
Es ist deshalb zu empfehlen, den AES-Encryption Modus nur für sicherheitskritische HomeMatic-Geräte einzuschalten, etwa für Türöffner. Auch der Hersteller eQ-3 gibt diese Empfehlung.<br />
<br />
== Sicherheit ==<br />
Der genaue Ablauf des AES-Signaturverfahrens ist in "[https://git.zerfleddert.de/hmcfgusb/AES/ Dissecting HomeMatic AES]" beschrieben. Henryk Plötz hat die Sicherheit des Kommunikationsprotokolls in "[https://blog.ploetzli.ch/2015/on-the-security-of-aes-in-homematic/ On the Security of AES in HomeMatic]" näher betrachtet.<br />
<br />
= Aktivieren, Einrichten, Umgang in FHEM =<br />
== Zentrale ==<br />
*Der erste Schritt ist, in der virtuellen CCU von FHEM oder nur einem I/O-Device einen Schlüssel (Key) zu vergeben In FHEM kann mehr als ein Schlüssel hinterlegt sein (Attribute hmKey, hmKey2, hmKey3), als aktiv wird aber nur der Schlüssel mit dem höchsten Index betrachtet, und nur dieser wird, wie unten beschrieben, an ein Gerät übertragen. Fügt man einen neuen Schlüssel hinzu und ein Gerät ist gerade nicht aktiv, kann/muss das System den vorigen Schlüssel noch nutzen. <br />
** Der Systemverwalter muss sich den Schlüssel unbedingt merken. Er kann nicht aus den Geräten gelöscht werden! Im Zweifelsfall muss das Gerät kostenpflichtig von eQ-3 zurückgesetzt werden. <br />
** Die Schlüssel werden MD5 kodiert - man kann ihn im Klartext oder bereits kodiert eingeben. FHEM kodiert ihn, wenn er im Klartext eingegeben werden sollte. FHEM speichert das Attribut ausschließlich kodiert.<br />
:: <code>attr VCCU hmKey geheimerSchluessel</code><br />
*Der zweite Schritt besteht darin, den Schlüssel mit dem höchstenm Index mit dem gerätespezifischen FHEM-Kommando ''assignHmKey'' an alle gepairten Geräte zu übertragen, mindestens aber an diejenigen, bei denen der AES-Encryption Modus eingeschaltet werden soll. Es ist aber auch möglich, diese Aktion mit der HM Konfigurationssoftware (HM-PC-Software) oder einer CCU durchzuführen.<br />
:: <code>set Geraet assignHmKey</code><br />
:: <code>set Schalter assignHmKey</code><br />
Der aktuelle Schlüsselindex kann aus dem Reading <code>aesKeyNbr</code> des Geräts berechnet werden, wobei das Reading den im Funkprotokoll angeforderten Schlüssel wiederspiegelt, welcher den '''doppelten''' Wert des eigentlichen Schlüsselindex hat. Weiterhin muss beachtet werden, dass das Reading <code>aesKeyNbr</code> nur angepasst wird, wenn das Gerät eine Signatur anfordert, d.h. eine Schaltaktion ausgeführt oder ein Register geändert wird. '''Direkt nach dem <code>assignHmKey</code> hat das Reading noch einen veralteten Wert!'''<br />
<br />
== Geräte ==<br />
* Eine AES-Signatur muss vom Empfänger angefordert werden. Dementsprechend wird die Nutzung auch dort aktiviert. Dies wird durch das Setzen des Registers '''sign''' auf '''on''' erreicht, wobei es für jeden Kanal des Geräts separat gesteuert wird. <br />
:: <code>set Geraet sign on</code><br />
:: <code>set Schalter_Btn_01 sign on</code><br />
* Ein Sender, der mit einem Empfänger gepeert ist sollte wissen, dass dieser AES nutzen wird. Das Register '''expectAES''' ist hierbei auf on zu setzen. Hiermit kann der Sender überprüfen, ob tatsächlich eine AES-Transaktion stattgefunden hat und diese vom Gerät korrekt bestätigt wurde. Falls dies nicht der Fall ist, wird die Anfrage wiederholt bzw. dem Benutzer ein Fehler signalisiert.<br />
:: <code>set Schalter_Btn_01 regSet expectAES on Geraet</code><br />
* Die Zentrale kann ebenfalls eine AES-Signatur von einem Gerät anfordern, so sie einen Trigger empfängt. Hierzu ist im Device (und evtl. entsprechendem Kanal) eines Geräts das Attribut <code>aesCommReq</code> auf 1 zu setzen. Damit die Signatur angefordert wird, muss das Attribut auf jeden Fall auch im Gerät gesetzt werden, auch wenn nur ein einzelner Kanal betroffen ist. Hiermit kann die Überprüfung für ein Gerät sehr schnell deaktiviert werden, indem nur das Geräteattribut wieder entfernt wird (z.B. nach Factory-Reset nötig, wenn das Gerät den eigenen Schlüssel noch nicht kennt). Sollte die Signaturüberprüfung fehlschlagen, verarbeitet FHEM den Befehl nicht.<br />
:: <code>attr Geraet aesCommReq 1</code><br />
:: <code>attr Schalter aesCommReq 1</code><br />
:: <code>attr Schalter_Btn_01 aesCommReq 1</code><br />
<br />
= Nachteile, Einschränkungen =<br />
* Die zusätzliche Kommunikation führt zu einer Verzögerung von etwa 200ms je Vorgang.<br />
* Die erhöhte Nachrichtenlast schlägt sich in der Auslastung der IO-Devices nieder. Wenn zwischen Zentrale und dem Gerät AES-Signatur genutzt wird reduziert sich das stündliche Sendekontingent des IO-Devices, siehe [[1% Regel]]<br />
* Jedes Kommando und seine Bestätigung wird unverschlüsselt übertragen, so dass Beobachter von außen den Zustand jedes Aktors durch mitlesen des Funkverkehrs ermitteln können. Dies trifft auch bei selbst gesetztem Schlüssel zu.<br />
* Ein Sicherheitsgewinn ist nur gegeben, wenn ein eigener System-Sicherheitsschlüssel genutzt wird.<br />
<br />
== Hinweise ==<br />
Eine Steigerung der Sicherheit ergibt sich nur, wenn man den werksseitig vorgegeben Schlüssel ändert. Solange Angreifern der eigene Schlüssel unbekannt bleibt, ist ein Fremdschalten oder die Änderung der Konfiguration nicht mehr möglich, wohl aber ein Ermitteln des aktuellen Schaltzustandes.<br />
<br />
Wurde ein eigener Schlüssel vergeben der nicht mehr bekannt ist und wird dann die Zentrale zurückgesetzt oder ausgetauscht ohne die Komponenten vorher auf Werkseinstellung zurückzusetzen, sind die entsprechenden Komponenten '''nicht mehr verwendbar'''. Die Geräte müssen kostenpflichtig eingeschickt und zurückgesetzt werden. <br />
<br />
'''WICHTIG''': den eigenen Sicherheitsschlüssel gut und sicher aufbewahren.<br />
<br />
Wenn ein Gerät mit gesetztem eigenem Sicherheitsschlüssel an eine andere/neue CCU angelernt werden soll, wird während des Anlernvorgangs nach dem eigenen Sicherheitsschlüssel gefragt. Dieser muss also bereits in der neuen Zentrale vorliegen.<br />
<br />
Die AES-Signierung kann mit einigen Ausnahmen (hauptsächlich Dimmer mit älteren Firmware-Versionen) in jedem HM-Gerät separat je Kanal aktiviert/deaktiviert werden.<br />
In einigen Geräte wie z.B. KeyMatic kann die AES-Signierung nicht abgeschaltet werden. Diese Geräte kommunizieren '''immer''' AES-Signiert.<br />
<br />
== Bekannte Probleme ==<br />
* Durch Fehler in der Firmware einiger Aktoren/FW Versionen (HM-LC-Sw1-Pl und HM-LC-SW2-PB-FM) werden Toggle-Kommandos '''vor''' Eintreffen des Signingpaketes geschaltet. Beim HM-LC-SW1-PL mit Firmware Version 1.9 konnte dieses Verhalten nicht mehr reproduziert werden.<br />
*Die Schlüsselimplementation der CCU in älteren Firmwareversionen (vor 1.504) ist mit Bugs behaftet. Es ergeben sich Risiken selbst dann, wenn der Schlüssel bekannt ist. So darf der Schlüssel z.b. keinesfalls ein "&amp;" enthalten. Gelegentlich wird auch berichtet, dass garantiert richtig eingegebene Schlüssel bei Systemwechseln nicht akzeptiert wurden. '''WICHTIG''': Keine Sonderzeichen im eigenen Sicherheitsschlüssel verwenden.<br />
<br />
[[Kategorie:HomeMatic Components|2Info]]</div>Martinp876http://wiki.fhem.de/w/index.php?title=Bekannte_HomeMatic_Ger%C3%A4te&diff=23889Bekannte HomeMatic Geräte2017-12-29T10:27:59Z<p>Martinp876: </p>
<hr />
<div>Eine aktuelle Liste aller in FHEM unterstützten Homematik Geräte kann in FHEM mit HMInfo <u>[[Homematic HMInfo#Infos|HMInfo]]</u> und dem Kommando '''models''' erzeugt werden. <br />
<br />
<br />
[[Kategorie:HomeMatic Components|2Info]]</div>Martinp876http://wiki.fhem.de/w/index.php?title=CUL_HM&diff=23888CUL HM2017-12-29T10:26:50Z<p>Martinp876: </p>
<hr />
<div>{{Infobox Modul<br />
|ModPurpose=HomeMatic Geräte (über CUL oder HMLAN)<br />
|ModType=d<br />
|ModCmdRef=CUL_HM<br />
|ModForumArea=HomeMatic<br />
|ModTechName=10_CUL_HM.pm <br />
|ModOwner=martinp876 ([http://forum.fhem.de/index.php?action=profile;u=251 Forum] / [[Benutzer Diskussion:Martinp876|Wiki]])<br />
}}<br />
<br />
[[CUL_HM]] implementiert die Unterstützung für [[HomeMatic]]-Geräte, die über einen [[CUL]] oder <br />
[[HM-CFG-LAN LAN Konfigurations-Adapter|HMLAN Konfigurator]] angebunden sind.<br />
<br />
== Voraussetzungen ==<br />
HomeMatic [[Interface]]: CUL im HomeMatic Modus oder [[HM-CFG-LAN LAN Konfigurations-Adapter|HMLAN Konfigurator]].<br />
<br />
== Anwendung ==<br />
=== Define ===<br />
Details in der [http://fhem.de/commandref.html#CUL_HM commandref].<br />
<br />
define <name> CUL_HM <6-digit-hex-code|8-digit-hex-code><br />
<br />
=== Attribute ===<br />
Details in der commandref.<br />
<br />
==== Virtuelle CCU (VCCU) ====<br />
[[Datei:VirtualCCU.png|mini|400px|rechts|Standarddarstellung einer Virtual CCU im Webinterface]]<br />
:''→ Hauptartikel: [[Virtueller Controller VCCU]]''<br />
<br />
Eine ''Virtuelle CCU'' implementiert einen HomeMatic-Controller und abstrahiert von den I/O-Devices, beispielsweise [[CUL]].<br />
<br />
define vccu CUL_HM <hmId><br />
'''attr vccu model CCU-FHEM'''<br />
attr vccu IOList <ioDev1>[,<ioDev2>,…]<br />
<br />
'''Siehe auch:'''<br />
* Foren-Thread {{Link2Forum|Topic=23008|LinkText="HM virtual CCU"}} (April 2014)<br />
* Foren-Beitrag {{Link2Forum|Topic=24048|Message=194876|LinkText="virtual CCU (Homematic)"}} (August 2014)<br />
<br />
== Anwendungsbeispiele ==<br />
=== Virtuellen Aktor erstellen ===<br />
Ein virtueller Aktor ist nötig, damit Taster wie z.B. der [[HM-PB-6-WM55_6fach-Funk-Wandtaster|6fach-Wandtaster]] oder der [[HM-PB-2-WM55_2fach-Funk-Wandtaster|2fach-Wandtaster]] einen Tastendruck mit grünem Aufleuchten bestätigen. Diese Rückmeldung geben die Taster normalerweise wenn sie den Tastendruck an ihre [[Peering (HomeMatic)|Peers]] weitergeben haben. Hat man aber keine Homematic-Peers direkt gekoppelt (also nur die Zentrale [[Pairing (HomeMatic)|gepairt]]), leuchten die Taster lediglich orange.<br />
<br />
Mit einer virtuellen CCU kann man virtuelle Aktoren erstellen, mit denen man die Taster dann peeren kann. Zunächst muss dazu eine virtuelle CCU angelegt werden <code>define virtualCCU CUL_HM XXXXXX</code>, wobei XXXXXX der hmId des HMLAN-Interfaces entspricht (bzw. dessen was statt HMLAN verwendet wird). Mit <code>attr virtualCCU model CCU-FHEM</code> gibt man der CCU noch den korrekten Typ. <br />
Virtuelle Aktoren kann man in der benötigten Anzahl (d.h. Anzahl aller Tasterbuttons) nun mit <code>set virtualCCU virtual X</code> anlegen, wobei X der benötigten Anzahl virtueller Aktoren entspricht. Danach existieren die virtuellen Aktoren als z.b. <code>virtualCCU_Btn1, virtualCCU_Btn2</code> usw. in FHEM. <br />
<br />
Die Peerings zwischen Tastern und den Buttons stellt man dann folgendermaßen her (CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_01 und CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_02 sind jeweils die Buttons des Tasters CUL_HM_HM_PB_2_WM55_1F1xxx):<br />
<pre><br />
set CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_01 peerChan 0 virtualCCU_Btn1 single set<br />
set CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_02 peerChan 0 virtualCCU_Btn2 single set<br />
</pre><br />
<br />
Danach führt man ein <code>set CUL_HM_HM_PB_2_WM55_1F1xxx getConfig</code> aus und drückt einmal kurz den Anlern-Button des Tasters. Danach sollte der Taster mehrmals kurz orange blinken. <br />
<br />
Wenn alles geklappt hat wird nach dem betätigen der Taster in den States von CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_01 bzw. CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_02 ein "(to virtualCCU)" stehen. <br />
<br />
Save Config nicht vergessen :-).<br />
<br />
==== Tipps ==== <br />
* Es wäre auch möglich nur einen virtuellen Aktor anzulegen und alle Buttons damit zu peeren.<br />
<br />
[[Kategorie:HomeMatic Components|1toolsAndWork]] <br />
<!-- (Modulkategorie wird automatisch gesetzt) --></div>Martinp876http://wiki.fhem.de/w/index.php?title=HomeMatic_Register_programmieren&diff=23887HomeMatic Register programmieren2017-12-29T10:25:04Z<p>Martinp876: </p>
<hr />
<div><!-- Bitte noch an geeigneten Stellen Links auf diese Seite einfügen --><br />
{{Baustelle}}<br />
Ein HomeMatic-Gerät besitzt mehr oder weniger umfangreiche Registersätze, mit denen das Verhalten des Gerätes vielfältig feinkonfiguriert werden kann. Die damit erreichbare Funktionsvielfalt geht weit über die standardisierten Vorgaben einer einfachen Direktverknüpfung ([[Peering_(HomeMatic)|Peering]]) hinaus. <br />
<br />
<br />
== Grundlagen (in Auszügen) ==<br />
<br />
Im folgenden werden nur exemplarisch einige Grundlagen und einfache Beispiele benannt, ohne jeden Anspruch auf Vollständigkeit.<br />
<br />
FHEM unterstützt die Programmierung der Register mit dem Befehl ''regSet''. <peer> entfällt bei rein gerätebezogenen Programmierungen.<br />
:<code>set <name> regSet <register> <value> [<peer>] </code><br />
Darüberhinaus gibt es vor- oder selbstdefinierte [[HomeMatic_HmInfo_Templates_erstellen|Templates]] (Vorlagen), die alle erforderlichen Änderungen für standardisierte Anwendungen wie Treppenhauslichtschalter beinhalten. Die Anwendung von Templates auf Geräte wird protokolliert und der Registerzustand kann überprüft werden. Für viele Anwendungen genügt jedoch auch die einmalige Anwendung einer direkten Programmierung. Das genaue Verständnis der Vorgänge und Zusammenhänge ist nicht trivial, das Erlernen wird aber mit einer enormen erreichbaren Funktionsvielfalt belohnt. Viele wissenswerte Zusammenhänge sind im Homematic-Anhang der bekannten Einsteiger-Dokumentation erläutert, deren Lektüre zu Recht immer wieder empfohlen wird. Dieser Beitrag ist auch nur als Ergänzung zu verstehen!<br />
<br />
Die HomeMatic Aktoren (Schalter, Dimmer, ...) arbeiten so, wie es für verknüpften ([[Peering (HomeMatic)|peering]]) Sender vorgegeben ist. Sie nutzen Registersätze, die für jede Verknüpfung (peer) neu angelegt und gespeichert werden. Man kann also mit einem Taster ein- und ausschalten (toggeln), mit einem Tastenpaar gezielt ein- und ausschalten und mit einem weiteren Taster eine Zeitschaltung für 10 Sekunden starten. Dabei wird niemals der Taster oder der Schalter auf eine globale Aktion programmiert, sondern im Schalter (Aktor) die gewünschte Aktion für jeden verknüpften Taster separat gespeichert. Die auszulösende Aktion ist zudem abhängig vom aktuellen Zustand des Aktors und von der Länge des Tastendruckes (kurz oder länger - short or long).<br />
<br />
Kleines Beispiel:<br />
T1 schaltet S1 für 10 sec an<br />
T2 schaltet S1 an oder aus <br />
T3 schaltet S1 an <br />
T4 schaltet S1 aus. <br />
<br />
Diese Tabelle ist im Schalter S1 gespeichert.<br />
<br />
Schaltet man mit T3 den S1 an und drückt dann nach beliebiger Zeit kurz T1 geht S1 nach weiteren 10 sec aus. Schaltet man mit T1 kurz den S1 für 10 sec an, aber innerhalb dieser Zeit mit T3 nochmal an, dann bleibt S1 nach Ablauf der 10 sec an.<br />
<br />
Die verfügbaren Register unterscheiden sich im Gerät und in den jeweiligen Kanälen. <br />
Eine kurze Beschreibung der Register inklusive der erlaubten Werte erhält man durch:<br />
:<code>get <name> regList </code><br />
Dabei kann <name> ein Gerät oder ein separater Gerätekanal sein.<br />
<br />
== Spezielle Register (Auswahl) ==<br />
Im folgenden sollen einige Register vorgestellt werden, die in vielen Geräten vorhanden sind. ''Ergänzungen sind ausdrücklich erwünscht!''<br />
<br />
<br />
=== Gerätebezogene Register ===<br />
Gerätebezogene Register existieren für jedes HomeMatic-Gerät nur einmal und werden in der sogenannten '''List0''' gespeichert (in der FHEM-Oberfläche als Hexbytefolge unter ''RegL_00.'' zu finden).<br />
<br />
<br />
==== ''confBtnTime'' - Kurz oder lang und der Konfigurationsmodus ====<br />
Nicht immer sind die internen Tasten eines Gerätes ohne weiteres mit Aktionen für kurzen und langen Tastendruck programmierbar. Bei allen Hutschienen-Aktoren sowie den Zwischensteckern (mit nur einem Bedienknopf) versetzt ein langer Tastendruck (4 Sekunden) den Schalter normalerweise in den Konfigurations- bzw. Anlern-Modus, bei den in Unterputzdosen versenkbaren Schalt- und Dimmaktoren (-FM ohne PBU in der Bezeichnung) ohne eigenen Konfigurations-Button gilt dies sogar für die zur normalen Funktion extern angeschlossenen Taster. Dieses Verhalten kann man mit dem Register ''confBtnTime'' beeinflussen. Bis zum Ablauf der dort einstellbaren Zeit (in Minuten) nach dem Versorgen mit Strom (powerUp) erreicht man den Konfigurationsmodus wie bisher, danach interpretiert der Aktor die Tastendrücke stets als kurz (short) oder lang (long). Beispiel:<br />
:<code>set <name> regSet confBtnTime 2</code><br />
Möchte man den Aktor später zurücksetzen oder lokal konfigurieren, so erreicht man das ursprüngliche Verhalten in diesem Beispiel für die ersten zwei Minuten, nachdem man den Aktor (ausreichend lange) stromlos gemacht hat.<br />
<br />
<br />
==== ''intKeyVisib'' - Interne Tasten sichtbar machen ====<br />
Die internen "Tasten" eines Aktors (z.B. die Schaltwippe bei Wandschaltern/-tastern, der Bedienknopf bei Zwischensteckern, aber auch die angeschlossenen externen Taster bei Aktoren für Unterputzdosen oder die von außen zugängliche "Notbedientaste" etwa bei Zwischendecken-Dimmern) sind logisch ebenso mit dem Aktor verknüpft wie externe Bedienelemente wie Funkfernbedienungen oder per Funk verknüpfte Wandtaster. Ihre Betätigung wird (außer mit präparierter Firmware) zwar nicht gesendet (und kann daher von FHEM nicht "gelesen" werden), die vom Hersteller vorgesehenen Funktionen lassen sich aber genauso frei programmieren. Allerdings sind diese internen Verknüpfungen zur Vermeidung versehentlicher Programmierungen zunächst verborgen und müssen daher explizit sichtbar gemacht werden. <br />
<br />
Dies geschieht mit<br />
set <name> regSet intKeyVisib visib <br />
attr <name> expert 1<br />
Anschließend sind der oder die internen Taste(n) mit der Bezeichnung self01 (self02, ...) sichtbar und ihre Aktionen können gezielt wie bei einem externen Peer umprogrammiert werden.<br />
<br />
Wer nun auf die Idee kommt, man könne durch entsprechendes zusätzliches peering bei mehrkanaligen Geräten die (mehreren) internen Tasten beliebig zuweisen und so raffinierte Zusatzschaltungen auslösen, muss hier enttäuscht werden: Zwar kann man tatsächlich mit peerBulk bei den Aktorkanälen zusätzliche interne Peers eintragen und programmieren und mit einer Fernauslösung aus FHEM die neuen Verknüpfungen erfolgreich nutzen - das Gerät selbst reicht die Tastenbetätigungen aber immer nur an den ursprünglich dafür vorgesehenen Kanal weiter.<br />
<br />
<br />
==== ''ledMode'' - Funktion der Onboard-LED bei Bausätzen ====<br />
Die (batteriebetriebenen) -PCB-Aktoren und die 8-Kanal-Module haben kleine LED an Bord, die für Diagnosezwecke hilfreich sind, einem sparsamen Betrieb aber in der Regel entgegenstehen. Sie werden daher nur bei außergewöhnlichen Zuständen wie dem Anlernmodus, einem Reset, oder auch bei niedriger Batteriespannung als Hinweis an den Anwender benutzt und sind ansonsten ab Werk deaktiviert. Bei einer Dauerstromversorgung kann aber eine Schaltzustandsanzeige oder eine Quittung über eine Befehlsaussendung nicht nur zur Diagnose hilfreich sein.<br />
<br />
Besitzt das Gerät das Register ''ledMode'', so kann man mit<br />
:<code>set <device> regSet ledMode on</code><br />
die LED auch für die "normalen" Betriebszustände aktivieren. Sie zeigen dann bei Aktoren, ob der Aktor eingeschaltet ist (blinkend, wenn eine Einschaltzeitbegrenzung aktiv ist), und bei den Sensormodulen HM-Mod-EM8(bit) zeigt die zweifarbige LED den von Fernbedienungen bekannten Sendezustand mit gelb, dem dann ein grün oder rot folgt - je nachdem ob eine Quittung angefordert ist und ob sie erfolgreich empfangen wurde.<br />
<br />
Leider lässt sich umgekehrt die bei Wandtastern oder Fensterkontakten mitunter gewünschte Deaktivierung der LED nicht so bewerkstelligen - diese Geräte haben das entsprechende Register nicht. Da hilft nur ein Eingriff ins Gerät mit Gaffa oder schwarzem Edding... <br />
<br />
<br />
=== Kanalbezogene Register ===<br />
Kanalbezogene Register existieren für jeden Kanal eines Gerätes einmal und werden in der sogenannten '''List1''' gespeichert (in der FHEM-Oberfläche als Hexbytefolge unter ''RegL_01.'' zu finden). <br />
<br />
<br />
==== ''powerUpAction'' - Automatischer Knopfdruck bei (wiederkehrender) Stromversorgung ====<br />
Mit diesem Register (default ''off'') kann erreicht werden, dass ein Schaltaktor nach einem Stromausfall sich bei Wiederkehr der Versorgungsspannung automatisch einschaltet. Dies ist z.B. sinnvoll für Zwischenstecker mit Messfunktion ([[HM-ES-PMSw1-Pl Funk-Schaltaktor 1-fach mit Leistungsmessung|HM-ES-PMSw1-Pl]]), wenn dieser als Langzeitmonitor etwa für Kühlgeräte verwendet wird - nach einem Stromausfall bliebe der Kühlschrank sonst aus und der Inhalt würde verderben. <br />
:<code>set <name> regSet powerUpAction on</code><br />
Achtung: Das Setzen dieses Registers auf ''on'' bedeutet nicht immer einen eingeschalteten Aktor nach der Wiederkehr der Stromversorgung. Vielmehr wird nur ein ''short''-Ereignis auf den zugehörigen internen Taster ausgelöst, was nur im Normalfall zum Einschalten des Aktors führt - nicht aber wenn die Funktion dieses kurzen Tastendruckes gezielt verändert wurde, denn dann wird eben diese Aktion ausgeführt! Das gilt zum Beispiel auch für zeitlich begrenztes Einschalten. Als Alternative für eine lokale Schaltmöglichkeit bietet sich in solchen Fällen der lange Tastendruck an, sofern er vom Aktor unterstützt wird (so lässt sich die Einschaltzeit bei langem Tastendruck mit ''lgOnTime'' begrenzen). Dessen Aktion wird bei powerUp nicht ausgeführt.<br />
<br />
<br />
=== Verknüpfungsbezogene Register ===<br />
Diese Register sind am umfangreichsten und werden für jeden Verknüpfungspartner einzeln separat angelegt in der '''List3''' (''RegL_03.<peer>''). Die grundsätzlichen Funktionen und ihre Zusammenhänge sind ausführlich in der Einsteigerdokumentation erklärt, inklusive Skizzen für die sogenannte ''state machine''. Hier sollen daher nur die in den folgenden Beispielen verwendeten Register erklärt werden. <br />
<br />
<br />
==== ''shOnTime'' und ''lgOnTime'' - das interne ''on-for-timer'' von Schaltern oder Dimmern ====<br />
Die wohl populärsten Register begrenzen die Einschaltzeit eines Aktors. Um z.B. eine Steckdose für 10 sec bei Knopfdruck lokal einzuschalten kann man folgendes programmieren:<br />
:<code>set <name> regSet shOnTime 10 self01 </code><br />
<br />
''shOnTime'' ist dabei das zuständige Register für die Einschaltzeit bei kurzem (sh=short) Tastendruck, entsprechend gilt ''lgOnTime'' für einen langen Tastendruck. <br />
<br />
In den Readings werden die Register mit dem jeweiligen verknüpften Taster angezeigt, in unserem Fall also:<br />
:<code>R-self01-shOnTime </code><br />
<br />
Der Defaultwert für shOnTime ist 111600 und bedeutet unendlich (von FHEM mit "unused" dargestellt), d.h. die maximale einstellbare Zeit ist 111599 sec (knapp 31 Stunden). So kann man die Zeit löschen:<br />
:<code>set <device> regSet shOnTime 111600 self01 </code><br />
oder<br />
:<code>set <device> regSet shOnTime unused self01 </code><br />
<br />
Übrigens gibt es diese Register auch für die Ausschaltzeit.<br />
<br />
<br />
==== ''shCtOn'' und ''shCtOff'' - Bedingtes Schalten mit Schwellwerten ====<br />
Fernbedienungen (im weitesten Sinne, ''remote'') von HomeMatic übermitteln je nach Betätigungsdauer ''short''- oder ''long''-Trigger. Zustandsübermittelnde Sensoren (etwa ein Fensterkontakt oder Neigungssensor sowie Bewegungsmelder) senden ausschließlich ''short'', gekoppelt mit einem Wert zwischen 0 und 200, entsprechend 0-100% in 0,5-%-Schritten. Ob ein solcher Trigger vom Aktor verarbeitet wird, kann vom gesendeten Wert abhängen.<br />
<br />
HomeMatic kennt dazu (für jeden Peer und Triggertyp (short/long) separat) zwei Schaltschwellen Lo und Hi, die default bei 50 und 100 liegen. Ob ein Trigger in Relation zu diesen Schwellen verarbeitet wird, regeln u.a. die shCtxxx-Register. Wie auch bei den allgemeinen Schaltbedingungen stehen ''On'' und ''Off'' jeweils für den aktuellen Schaltzustand (Achtung: nicht den, der erreicht werden soll). Ihr Wert beträgt default "geLo" (greater or equal Lo), hier 50 und höher. Trigger für Werte darunter werden bei der Einstellung "ltLo" (less than Lo) verarbeitet. Diese Schwellen gibt es entsprechend auch für den Hi-Wert, also "geHi" oder "ltHi". Besonders interessant sind aber auch die Werte "outside" und "between", bezogen auf die beiden Schwellen Lo und Hi. In letzterem Fall wird der Trigger verarbeitet, wenn der Wert zwischen 50 und 100 liegt, bei "outside" entsprechend bei 0-49 oder 101-200.<br />
<br />
Sogenannte Three-State-Sensoren wie Fensterkontakt- oder -griffsensoren senden 0 für "closed" (geschlossen), 100 für "tilted" (gekippt) und 200 für "open" (offen). Gleiches gilt für Schalterkontaktinterfaces, die den Zustand eines angeschlossenen Schaltkontaktes übermitteln. Im Grundzustand (Vergleichsbefehl auf "geLo") führt daher nur der Trigger "offen" (200) zu einer Aktion. Ändert man den Vergleichsbefehl auf "ltLo", so wird lediglich "closed" ausgewertet, bei "between" ist es "tilted". Mit "outside" führt sowohl "closed" als auch "open" zu einer Aktion.<br />
<br />
Bei Bewegungsmeldern wird der mit übermittelte Helligkeitswert im Zusammenhang mit den (dann variabel einzustellenden) Schwellen als Kriterium für das Einschalten des Aktors mit herangezogen.<br />
<br />
<br />
==== ''shSwJtOn'' & Co. - Was soll passieren? ====<br />
Nachdem wir nun kennengelernt haben, wie man auswählt, '''welcher''' Anstoss von außen zu einer Aktion führt, hier ein kleiner Exkurs in die Beeinflussung, '''was''' daraufhin passieren soll. Diese Frage regelt die ''jump table'' und liefert damit das Regelwerk für die Abfolge der Aktionen, die ''state machine''. Ein HomeMatic-Aktor geht nämlich keineswegs einfach nur an oder aus. Vielmehr hangelt er sich nacheinander an einer Reihe von Zuständen entlang - auch das ist in der Einsteigerdokumentation erschöpfend beschrieben und soll hier nicht wiederholt werden. Ein Schalter durchläuft aber mindestens die Zustände<br />
Aus > Einschaltverzögerung > Ein > Ausschaltverzögerung > Aus > (usw)<br />
Hier soll reichen, dass am Ende jeder (Teil-)Kette in der Regel ein dauerstabiler Zustand bleibt, in der Regel ist das der Aus-Zustand und auch der Ein-Zustand, wenn dessen Laufzeit nicht durch ''shOnTime'' & Co. begrenzt ist. Ein- und Ausschaltverzögerung sind aber in der Regel 0 (Sekunden), so dass effektiv nur "Ein" und "Aus" übrig bleiben.<br />
<br />
Das Register ''shSwJtOn'' regelt, wohin die Reise geht, wenn ein gültiger ''short''-Trigger im eingeschalteten Zustand eintrifft, sinngemäß ''...Off'' im Auszustand und ''lg...'' für die ''long''-Trigger. Für ''shSwJtOn'' ist normalerweise als nächstes die Ausschaltverzögerung "dlyOff" vorgesehen. Da die Ausschaltverzögerung in der Regel 0 ist, folgt darauf, in ''shSwJtDly'' festgelegt, "off" usw. Die Zustände bilden so quasi einen Kreis, dessen Durchlauf von außen gelegentlich "angeschubst" wird. Mit diesen Registern kann man den Kreislauf aber auch umbiegen oder sogar unterbrechen, so dass ein eintreffender Trigger eben nicht zu einer Aktion führt. Als Ziele bieten sich, quasi selbstsprechend, "on", "dlyOff", "off" und "dlyOn" an - oder eben "no", was nichts anderes bedeutet, als dass der betreffende Trigger an dieser Stelle zu keiner Aktion führt.<br />
<br />
Bei einem Dimmer heißen die Register statt ''..Sw....'' nur ''..Dim....'' und es gibt ein paar mehr Bedingungen - die Funktion ist aber entsprechend gleich.<br />
<br />
<br />
==== ''shOnDly'' und ''shOffDly'' - es muss nicht immer sofort sein! ====<br />
Nicht nur welcher Anstoße welche Aktion auslöst, sondern auch wann oder wie schnell die Aktion ausgeführt wird, lässt sich in gewissen Grenzen einstellen. Die beiden genannten Register etwa regeln die Ein- oder Ausschaltverzögerung nach einem gültigen Trigger. So kann man nach einem Ausschaltbefehl einen Raum noch im Hellen verlassen, wenn das Licht noch ein paar Sekunden länger leuchtet.<br />
<br />
Bei Dimmern gibt es zusätzlich auch bei Ein- und Ausschaltvorgängen durch eine neu eingerichtete Verknüpfung eine sogenannte Rampenzeit von 0,5 Sekunden, in der das Licht hoch- oder heruntergedimmt wird. Durch Programmierung von ''shRampOnTime'' und ''shRampOffTime'' kann man ein sehr augenschonendes langsames Ein- oder Ausschalten des Lichts wie im Kino erreichen. Zwar gibt es die Zeiten auch für long-Trigger, aber da machen sie im Normalfall wenig Sinn - der lange Tastendruck löst immer einen manuellen Dimmvorgang aus.<br />
<br />
<br />
<br />
''(wird ergänzt)''<br />
<br />
<br />
== Praktische Beispiele ==<br />
Die folgenden Beispiele beschreiben nur in Kurzform die erforderlichen Aktionen. Weiterführende Informationen sind der Einsteigerdokumentation oder den o.g. Registerbeschreibungen zu entnehmen.<br />
Übrigens: ein einmal konfigurierter Vorgang für eine Verknüpfung kann aus FHEM auch bequem fernausgelöst (bzw. simuliert) werden. Der Aktor führt dabei genau die Aktion aus, die für die benannte Verknüpfung vorgesehen ist. Der kurze Knopfdruck auf den internen Knopf eines Aktors wird beispielsweise so simuliert:<br />
:<code>set <device> press short self01 </code><br />
<br />
<br />
=== Lokal bedienbarer Zeitschalter mit HomeMatic Aktoren: Pool für eine Stunde schalten ===<br />
Ich habe einen HM-LC-SW4-DR und der channel_01 schaltet die Poolzirkulationspumpe. Dies passiert zeitgesteuert zweimal am Tag. Manchmal möchte ich im Keller diese Pumpe einfach für eine Stunde aktivieren, der Aktor ist bequem erreichbar an der Wand.<br />
Die internen Tasten vom Hauptdevice (der Aktor hat vier Kanäle (channel), die in FHEM einzeln dargestellt werden) sichtbar machen:<br />
set LichtKeSW1 regSet intKeyVisib visib <br />
attr LichtKeSW1 expert 1 <br />
<br />
Jetzt sieht man im Channel 01 - LichtKeSW1_Sw01 den internen peer self01. (Channel 02 ist self02 usw.)<br />
Also jetzt einfach die Zeit eintragen:<br />
set LichtKeSW1 regSet shOnTime 3600 self01 <br />
<br />
Die Toggle Funktion der Taste bleibt erhalten. Ein zweiter Tastendruck schaltet die Pumpe auch sofort wieder aus. Während die Zeit läuft, blinkt die Status LED des Kanals.<br />
Die Zeitbegrenzung funktioniert in diesem Beispiel ohne jedes Zutun von FHEM und damit auch bei einem Ausfall des Servers.<br />
<br />
<br />
=== Es werde Licht! Automatisches Licht mit Tor oder Tür ===<br />
Im Kühlschrank geht das Licht ja schon praktischerweise automatisch an und aus, aber es gibt auch andere Situationen, in denen ein automatisches Licht sehr nützlich sein kann - in dunklen Abstellräumen oder Garagen. Vor allem weil man nicht vergessen kann es auszuschalten, weil es auch von allein ausgeht. Eine solche Funktion, so könnte man meinen, wird ganz einfach erreicht, indem man das Licht mit einem Aktor schalten lässt und diesen mit einem Tür- oder Fensterkontakt verknüpft. Hat man die beiden dann mit ''peerChan'' verknüpft, so wird man feststellen, dass das Licht mitnichten das Gewünschte tut: es schaltet sich beim Öffnen der Tür abwechselnd ein und aus und ignoriert das Schließen der Tür komplett.<br />
<br />
Verantwortlich für dieses "Fehlverhalten" sind die Register ''shCtOn'' und ''shCtOff''. Beide stehen nach der Verknüpfung auf "geLo". Wie bei den Registern oben erläutert, führt in diesem Fall nur die "offen"-Meldung des Türkontaktes zu einer Aktion. Das Öffnen der Tür soll den Aktor einschalten, das klappt. Das Schließen der Tür soll den eingeschalteten Aktor aber ausschalten. Also muss die Schaltbedingung im On-Zustand geändert werden (die Bezeichnungen natürlich durch die realen Namen des Schaltaktorkanals und des Türkontaktes ersetzen):<br />
:<code>set <Schalter> regSet shCtOn ltLo <Türkontakt> </code><br />
Nun führt auch das Schließen der Tür wunschgemäß stets zu einem Abschalten des Lichts. ''shCtOff'' muss auf "geLo" bleiben!<br />
<br />
Kombinieren ließe sich das noch mit einer Laufzeitbegrenzung etwa für eine Stunde - sollte man die Tür versehentlich offenlassen, so brennt das Licht nicht stundenlang. Vor allem geht das Licht dann auch aus, wenn aus welchem Grund auch immer die Schließmeldung verloren geht.<br />
:<code>set <Schalter> regSet shOnTime 3600 <Türkontakt> </code><br />
<br />
=== Lampe mit Kippschalter(n) fernschalten - eindeutig oder als Wechselschaltung ===<br />
Oft besteht der Wunsch, eine Lampe mit einem herkömmlichen Schalter (statt eines Tasters) fernzuschalten. So kann man einen herkömmlichen Schalter mit einer Schließerkontaktinterface wie dem [[HM-SCI-3-FM 3-Kanal-Funk-Schließerkontakt-Interface|HM-SCI-3-FM]] ergänzen (oder einem Kanal des [[HM-MOD-EM-8 8-Kanal-Sendemodul|8-Kanal-Sendemoduls]] in der Betriebsart ''sensor'') und wiederum die Verknüpfung mit dem Lampen-Aktor setzen. Ganz ähnlich wie bei der vorgenannten Abstellraum-Aufgabe führt nun aber das Schließen des Schalters nicht zu einem Einschalten. Daher ist nun <br />
:<code>set <Lampenaktor> regSet shCtOff ltLo <Sensorkontakt> </code><br />
das Mittel der Wahl, ''shCtOn'' muss dieses Mal auf "geLo" bleiben. Jetzt folgt der Aktor dem (sichtbaren) Schaltzustand des Schaltes - zumindest solange er nicht anderweitig ein- oder ausgeschaltet wird.<br />
<br />
Nun kann man auch mehrere Schalter so mit der Lampe koppeln. Das ergibt aber keine Wechselschaltung im herkömmlichen Sinn - um eine Lampe ein- oder auszuschalten, muss man den Schalter möglicherweise einmal zusätzlich auf die aktuelle Schaltposition kippen, ehe die nächste Betätigung den gewünschten Effekt bringt. Für Wechselschaltungen bietet sich daher das Kontaktinterface [[HM-SwI-3-FM]] (oder das erwähnte 8-Kanal-Sendemodul in der Betriebsart ''switch'') an. Hier führt jede Zustands''änderung'' zu einem Schaltvorgang.<br />
<br />
Hat man hingegen nur ein HM-SCI-3-FM zur Hand, lässt sich dieses Verhalten auch erreichen:<br />
:<code>set <Lampenaktor> regSet shCtOn outside <Sensorkontakt> </code><br />
:<code>set <Lampenaktor> regSet shCtOff outside <Sensorkontakt> </code><br />
<br />
=== Gezieltes Schalten eines (unsichtbaren) Aktors mit nur einer Taste ===<br />
Für so etwas braucht man gewöhnlich zwei Tasten. Koppelt man einen Schalt-Aktor mit nur einer Taste ("single" beim ''peerChan''-Kommando), so führt sowohl ein kurzer als auch ein langer Tastendruck immer nur zu einem Umschalten des Zustandes. Das ist unschön, wenn man den aktuellen Zustand nicht einsehen kann. <br />
<br />
Üblicherweise sind die Schaltabfolgen für eine Eintasten-Verknüpfung sowohl für kurze als auch lange Betätigungen gleich (bei Dimmern wird auf langen Tastendruck hingegen abwechselnd auf- oder abgedimmt). <br />
shSwJtOff = dlyOn # Ist Gerät aus, wird Einschaltverzögerung gewählt (die aber normal 0 ist)<br />
lgSwJtOff = dlyOn # dito, für lang<br />
shSwJtOn = dlyOff # Ist Gerät an, wird Ausschaltverzögerung gewählt (die aber normal 0 ist)<br />
lgSwJtOn = dlyOff # dito, für lang<br />
Hier kann man sich zunutze machen, dass man mit einem gezielten "no" oder "dlyOn" bzw. "dlyOff" im richtigen Register die Schaltfolge abbrechen oder umbiegen kann.<br />
Möchte man das Gerät <aktor> mit einem kurzen Tastendruck auf <button> ein- und mit einem langen Tastendruck ausschalten, so ändere man:<br />
:<code>set <aktor> regSet shSwJtOn dlyOn <button> </code><br />
:<code>set <aktor> regSet lgSwJtOff dlyOff <button> </code><br />
So laufen die entsprechenden Aktionen quasi ins Leere, wenn der Aktor bereits den gewünschten Zustand hat.<br />
<br />
Den umgekehrten Effekt (lang schaltet ein, kurz aus) erreicht man entsprechend mit<br />
:<code>set <aktor> regSet shSwJtOff dlyOff <button> </code><br />
:<code>set <aktor> regSet lgSwJtOn dlyOn <button> </code><br />
<br />
Welche Bedienhaptik man nun bevorzugt, muss man selbst entscheiden. In der Regel sollte die normale (sichere) Aktion "kurz" und die gefährlichere "lang" sein - eine PC-Stromversorgung mit einem kurzen Tastendruck versehentlich einzuschalten ist bestimmt besser als auszuschalten (das dann eben nur über lang) - für ein potentiell gefährliches Arbeitsgerät wie einen Heizofen wird es sicher andersherum sein.<br />
<br />
Sinngemäß verwendet der Autor sozusagen eine Hälfte davon als "Sicherheitsaktion" für einen [[HM-LC-Sw2PB-FM Schaltaktor mit Tasteraufsatz 2fach]] - der gewöhnliche Tastendruck auf die zugehörige Wippenseite schaltet den Aktor abwechselnd ein und aus, ein langer Tastendruck immer aus, dafür reicht:<br />
:<code>set <aktor> regSet lgSwJtOff dlyOff <button> </code><br />
<br />
Übrigens: Nichts anderes wird normalerweise auch automatisch beim Verknüpfen eines Aktors mit einem Tastenpaar an der entsprechenden Stelle gemacht - ist eine Taste nur zum Ausschalten gedacht, so wird in beiden Schaltzuständen entsprechend "dlyOff" eingetragen. Als "Sprungziel" müsste aber genauso gut auch "no" funkionieren.<br />
<br />
<br />
=== WARNUNG! - Selbsttätiges Blinken eines HM-Aktors ===<br />
Statt einer separaten Warnleuchte kann es durchaus sinnvoll sein, eine vorhandene Lampe zu Warnzwecken periodisch ein- und auszuschalten. Leider beherrschen die HomeMatic-Aktoren keine direkt aus FHEM erreichbare Blinkfunktion (ähnlich dem on-for-timer für eine Zeitbegrenzung), und das rhythmische Ein- und Ausschalten aus FHEM erzeugt eine recht hohe Funklast.<br />
<br />
Wir wissen aber, dass die Aktoren für jeden Peer nicht nur eine Ein-, sondern auch eine Ausschaltzeit speichern. Definiert man nun für einen Peer entsprechend beide Zeiten, so wird der Aktor bei einem Telegramm von diesem Peer sich entsprechend selbsttätig fortlaufend ein- und ausschalten. Jeder andere Schaltbefehl eines anderen Peers oder aus FHEM beendet die Schleife umgehend. So ließe sich das Blinken auch mit einer aktoreigenen Taste stoppen - oder starten, wenn man es entsprechend programmiert. Einen Zwischenstecker-Schalter beispielsweise kann man also (wenn man zuvor seine ''confBtnTime'' entsprechend setzt und so die langen Tastendrücke auswertbar macht) durch das Programmieren von ''lgOnTime'' und ''lgOffTime'' für den Peer "self01" wie gewohnt mit einem kurzen Tastendruck ein- und ausschalten und mit einem langen in den Blinkmodus versetzen.<br />
<br />
Einen Haken hat die Sache aber (möglicherweise): Der Aktor meldet seinen Schaltzustand natürlich periodisch. Allerdings tut er das mit einer gewissen Verzögerung. Beim Blinken in einem 2-Sekunden-Rhythmus kommen jedenfalls noch keine regelmäßigen Statustelegramme, die die Funklast erhöhen würden.<br />
<br />
Eine weitere Möglichkeit wäre, virtuelle Buttons (etwa einer VCCU) zum Ein- und Ausschalten der Blinkfunktion zu verwenden. "Opfert" man dafür zwei aufeinanderfolgende Kanäle, kann man die Aktoren mit "dual set" peeren und bekommt so einen Blink- und einen Deaktivierungsbutton ohne weitere Kopfstände. Anschließend passt man die short-Laufzeiten für den Einschaltkanal an: <br />
<br />
Ein Beispiel für einen Dimmer (als virtuelle Buttons dienen vccu_Btn8 und vccuBtn9):<br />
<br />
:<code>set <vccu_Btn8> peerChan 0 <dimmerkanal> dual set</code><br />
<br />
Nun kann man mit "set vccu_Btn9 press short" den Dimmer ein- und mit "set vccu_Btn8 press short" ausschalten. Das Blinken im Dimmer wird eingestellt mit <br />
<br />
:<code>set dimmer regSet shOnTime 1 vccu_Btn9</code><br />
:<code>set dimmer regSet shOffTime 1 vccu_Btn9</code><br />
<br />
Wird der Dimmer nun mit "set vccu_Btn9 press short" eingeschaltet, so blinkt er im 3-Sekunden-Takt: zu den jeweils 1 Sekunde Ein- und Auszeit gesellen sich noch 2x 0,5s Rampenzeit, sofern nichts anderes programmiert wurde.<br />
<br />
Natürlich kann man eine größere Anzahl von Aktoren mit den virtuellen Buttons peeren und so ein ganzes Feuerwerk zünden ...<br />
<br />
<br />
=== Einer nach dem Anderen! - Sequentielles Schalten mehrerer Aktoren ===<br />
Eine großflächige Beleuchtung mit viel Leistung sollte man aus Lastgründen niemals zugleich einschalten. Auch LED-Lampen ziehen im Einschaltmoment, wennauch extrem kurz, beträchtliche Ströme, die die von gewöhnlichen Glühlampen deutlich übersteigen können. Schaltet man mehrere Aktoren gleichzeitig mit einer Taste, so hilft eine individuelle Verzögerung des Einschaltvorgangs in jedem Aktor, die Sicherung vor dem Herausfliegen zu bewahren. Oder man macht gezielt einen Effekt daraus. Der Phantasie sind wenig Grenzen gesetzt...<br />
<br />
Hat man drei Aktoren "Aussenlicht1...3" mit dem Taster "Aussenlicht_Ein" gepeert, so erreicht man auf folgende Weise, dass sie beim Einschalten mit einer Verzögerung von jeweils einer Sekunde nacheinander einschalten.<br />
<br />
:<code>set Aussenlicht2 regSet shOnDly 1 Aussenlicht_Ein</code><br />
:<code>set Aussenlicht3 regSet shOnDly 2 Aussenlicht_Ein</code><br />
<br />
<br />
<br />
<br />
<br />
[[Kategorie:HomeMatic Components|toolsAndWork]]</div>Martinp876