Templates in FHEM

[Dr. Boris Neubert]

Hallo,

ich schlage den Einbau von Templates als neue Funktionalität in FHEM vor. Ich schreibe dazu drei Beiträge.

• Anwendungsfälle (dieser Beitrag)
• Implementierung (nächster Beitrag mit Patch für fhem.pl)
• Problem/Diskussion (übernächster Beitrag)

Viele Grüße
Boris

Anwendungsfälle:

• Zur Definition von gleichartigen Geräten wiederholt sich die Konfiguration regelmäßig mit meist nur geringen Abweichungen bei den Parametern. Die sich wiederholende Konfiguration wird daher in einem Template abgelegt. Das Template wird dann in der Konfiguration unter Angabe der für die variablen Teile zu ersetzenden Parameter aufgerufen.
• Um mehrere Kommandos hinter at und notify zusammenzuhalten, muss das Semikolon als Befehlstrenner als ;; maskiert angegeben und alles in einer Zeile geschrieben werden. Die Auslagerung der Kommandofolge in ein Template soll diese Maskierungen überflüssig machen und die Benutzung klarer machen.
• Bei Verwendung von Perl-Kode in FHEM müssen Zeilenenden mit \ und Semikolons mit ;; maskiert werden. Die Verwendung von Templates soll es erlauben, unmaskierten Perl-Kode zu schreiben.

Beispiel zu einem FHEM-Template:

Code Auswählen Erweitern

define %name% FHT %fhtcode%
attr %name% IODev CUN
attr %name% alias %alias%
attr %name% group %group%
attr %name% icon icoTempHeizung.png
attr %name% room %room%,Anlagen/Heizungen

define watchdog.%name% watchdog %name% 00:15:00 SAME set %name% report2 255
attr watchdog.%name% group %group%
attr watchdog.%name% room Control/Heizungen

define %name%.log FileLog /opt/fhem/log/%name%-%Y%m.log %name%:.*
attr %name%.log group %group%
attr %name%.log icon icoLog.png
attr %name%.log logtype fht
attr %name%.log room Control/Heizungen

define %name%.weblink SVG %name%.log:%name%:CURRENT
attr %name%.weblink label sprintf("Temperatur: %.0f °C (%.0f °C .. %.0f °C)  Aktor: %.0f %% (%.0f %% .. %.0f %%)", $data{currval1}, $data{min1}, $data{max1}, $data{currval2}, $data{min2}, $data{max2} )
attr %name%.weblink room %room%
attr %name%.weblink alias %alias%

So sehen bei mir alle Definitionen von FHTs aus. Die Zeichenketten in der Form %...% sind die variablen Elemente.

[Dr. Boris Neubert]

Der beigefügte experimentelle Patch fügt einen Befehl template zu FHEM hinzu:

Code Auswählen Erweitern

Usage: template def fhem|perl <name>(<args>) fileName
       template del <name>
       template list

Beispiel für Definition:

Code Auswählen Erweitern

templ def fhem Heizung(fhtcode,name,alias,room,group) Heizung.templ
templ list

Beispiel für Verwendung:

Code Auswählen Erweitern

$Heizung(1B2B,hzgwz,Heizung Wohnzimmer,Wohnzimmer,Heizung)

Die Datei Heizung.templ hat genau den Inhalt aus dem vorigen Beitrag.

Es ist nur der Teil ausprogrammiert, der dem ersten Anwendungsfall entspricht.

[Dr. Boris Neubert]

Ich habe den Kode nicht weiter ausprogrammiert, bevor ich nicht Gewissheit habe, dass er auch eine Chance hat, aufgenommen zu werden.

Die Schwierigkeit liegt in AnalyzeCommandChain, wo man die Unterscheidung zwischen Kommando, Subkommando (hinter at und notify) und Perl explizit ausprogrammieren muss.

[rudolfkoenig]

Ohne es naeher angeschaut zu haben: kann man das nicht als Modul anlegen?
Dann brauchst du gar nicht zu fragen, ob es aufgenommen wird.

[justme1968]

es gibt von igami ein modul das glaube ich in diese richtung geht. mit fällt nur gerade her name nicht ein ...

[Dr. Boris Neubert]

Der erste Anwendungfall ginge wohl noch als Modul. Bei den beiden anderen muss man aber doch AnalyzeCommandChain aufbohren, nicht wahr?

Die Anwendungsfälle 2 und 3 ließen sich aber auch lösen, wenn wir einen Parser einführen (Parse-RecDescent). Aber wo ist der Freiwillige dafür?

[justme1968]

das modul heißt archetype.

zum parsen und den ; ... dazu hatte ich in dem ParseParams thread schon mal einen vorschlag gemacht. vielleicht können wir das wiederbeleben

[betateilchen]

Hallo Boris,

willst Du nicht erstmal die Baustelle "RTypes", die vor langer Zeit auf Dein Bestreben in die fhem.pl eingebaut wurde, zuende bringen, bevor jetzt eine neue Baustelle eröffnet wird?

Grundsätzlich sind templates eine gute Idee. Aber in Homematic gibt es solche Templates seit Jahren. Aber ausser martin und mir nutzt die offenbar niemand, wenn man sich viele Homematic Probleme anschaut, die immer wieder im Homematic-Bereich diskutiert werden und die sich vermeiden ließen, wenn man mit templates arbeiten würde.

Wenn man wirklich

Zur Definition von gleichartigen Geräten wiederholt sich die Konfiguration regelmäßig mit meist nur geringen Abweichungen bei den Parametern.

betrachtet, kann man das auch in vielen Fällren mit dem bereits vorhandenen Befehl "copy" abfackeln, dem man ja die abweichenden Parameter im define für das Zieldevice einfach mitgeben kann.

So ganz erschließt sich mir der Nutzen Deines Vorschlages noch nicht wirklich, wenn ich mir den dagegenstehenden Aufwand betrachte und außerdem in Betracht ziehe, welche Möglichkeiten FHEM bereits bietet (setdefaultattr, copy, ...), um solche wiederkehrenden Dinge einfacher zu erledigen.

[dev0]

Aber in Homematic gibt es solche Templates seit Jahren. Aber ausser martin und mir nutzt die offenbar niemand,

Aus FHEM Anwendersicht:

Als ich vorzeiten gelesen hatte, dass es Homematic Templates gibt, fande ich das sehr spannend. Die Details hatte ich aber auf Anhieb nicht verstanden und da es eine "homematic only Lösung" war auch nicht weiter verfolgt. Ich hätte mich halt einarbeiten müssen, aber das war es mir, für 1(!) Modul, an der Stelle nicht wert. Es lief ja schon alles.
Wäre es ein generelles Konzept gewesen, dass an allen möglichen Stellen zu verwänden wäre, dann hätte ich das mit bestimmt gemacht...

[betateilchen]

Wäre es ein generelles Konzept gewesen, dass an allen möglichen Stellen zu verwänden wäre, dann hätte ich das mit bestimmt gemacht...

Ein generelles Konzept, wie jetzt hier diskutiert, würde aber höchstwahrscheinlich bei den vielen Sonderlocken, die Homematic hat/braucht, auch nicht funktionieren. Somit hätten wir dann schon

• Homematic templates
• "generelles Konzept"
• FHEM-interne, bereits vorhandene Möglichkeiten, wie oben schon beschrieben
• archetype

Aus Entwickler- und Supportersicht:

Wie willst Du den Anwendern eine Vielzahl solcher "Ideen" für ähnliche Aufgabenstellungen so vermitteln, dass sie verständlich bleiben und so, dass auch Otto Normalverbraucher und Lieschen Müller weiß, wann welcher Ansatz der "richtige" ist? Meiner Ansicht nach schaffen wir damit nur noch mehr Unverständnis und noch mehr Probleme als jetzt schon existieren.

[dev0]

Meiner Ansicht nach schaffen wir damit nur noch mehr Unverständnis und noch mehr Probleme als jetzt schon existieren.

Wenn man aber keine neuen Weg testet, dann wird sich auch nichts weiterentwickeln. FHEM ist kein out-of-the-box Produkt. Das weiß Du, als "alter Hase", wahrscheinlich viel besser als ich. Ob es sich durchsetzt oder auch nicht, wird man sehen... mMn hat die Idee zumindest Potenzial dazu.

[rudolfkoenig]

Die Schwierigkeit liegt in AnalyzeCommandChain, wo man die Unterscheidung zwischen Kommando, Subkommando (hinter at und notify) und Perl explizit ausprogrammieren muss.

Ich verstehe dieses Problem immer noch nicht. Kann jemand bitte so nett sein, und fuer einen "csrfToken" Geschaedigten das ganz langsam erklaeren?

[zap]

Könnte man nicht anstelle der Einführung von Templates den Copy-Befehl erweitern? Der Befehl unterstützt ja schon die variable Angabe des DEF-Teils.
Wären eigentlich nur noch optionale Parameter zu ergänzen, die Attribute ersetzen.

Beispiel:

Code Auswählen Erweitern


copy olddev newdev mydefpar1 attr1=val1 attr2=val2


[betateilchen]

Das fände ich auch einen guten (und verständlichen) Weg zur Umsetzung.

[KernSani]

Könnte man nicht anstelle der Einführung von Templates den Copy-Befehl erweitern? Der Befehl unterstützt ja schon die variable Angabe des DEF-Teils.
Wären eigentlich nur noch optionale Parameter zu ergänzen, die Attribute ersetzen.

Beispiel:

Code Auswählen Erweitern


copy olddev newdev mydefpar1 attr1=val1 attr2=val2


Dies entspricht im Wesentlichen der bereits vorhandenen "import raw" Funktionalität, die ich persönlich für ausreichend halte, um schnell bestehende Definitionen in ein neues Device zu übernehmen.
Auch das Sharing komplexer Szenarien lässt sich über "import raw" leicht realisieren.

Einen echten Mehrwert hätten Templates für mich dann, wenn ich an einer zentralen Stelle Änderungen vornehmen kann, die dann Auswirkungen auf alle auf dem Template basierenden Devices hat.
 
Grüße,

Oli

[Dr. Boris Neubert]

Hallo,

ich habe mir die von Euch vorgeschlagenen Lösungen angesehen:
- Ich kann nicht erkennen, wie ich den Anwendungsfall aus meinem Eingangsbeitrag rationell mit copy und setdefaultattr bewerkstelligen könnte: Anlage von 4 zusammenhängenden Geräten mit einer Namenskonvention und Konvention für Attribute.
- Archetype habe ich mir angesehen und halte durch dieses Modul den Anwendungsfall auch nicht abgedeckt. Zudem habe ich größte Mühe, zu verstehen, wie das Modul benutzt wird.
- @KernSani: was ist die "import raw"-Funktionalität?

Mein Vorschlag entspricht im wesentlichen den aus C bekannten Makros. Ich halte eine solche Funktionalität im Framework für sinnvoll und nützlich. Auch um Einsteigern die Arbeit zu erleichtern, indem für komplexe Konfigurationen Templates in einer Sammlung zur Verfügung gestellt werden.

Wenn eine Makro-/Template-Funktionalität in fhem.pl keine Zustimmung/kein genügendes Interesse findet, werde ich den Weg über ein Modul gehen. Das macht die Benutzung dann weniger anwenderfreundlich.

Viele Grüße
Boris

[KernSani]

Hi Boris,

ich meinte den "Raw definition" button unten beim device - Dieser ist meines Erachtens ausreichend um Devices zu kopieren oder komplexe Definitionen zu importieren (sie - angepasst - zu kopieren ist damit etwas aufwändiger, weil ich es pro Device machen muss).
Generell halte ich deinen Ansatz für gut, um z.B. immer wiederkehrende Fragen (Wie kann ich meine Rolläden bei Sonnenuntergang herunter lassen und bei Sonnenaufgang wieder hoch?) oder eben auch komplexere Szenarien als template mit auszuliefern. Ob sie genutzt werden würde? Keine Ahnung... Für mich persönlich sehe ich aktuell keinen Anwendungsfall...

[betateilchen]

sinnvoll und nützlich. Auch um Einsteigern die Arbeit zu erleichtern, indem für komplexe Konfigurationen

• Anfänger sollten keine komplexen Konfigurationen haben, sondern sich einarbeiten und verstehen, was sie eigentlich tun
• man sollte Anfängern ihre Lernerfolge nicht durch Template-Sammlungen, deren Hintergründe von Anfängern eh nicht auf Anhieb zu durchschauen sind, wegnehmen.

Templates mögen ein probates Mittel für Leute sein, die genau wissen, wozu sie die einsetzen. Aber hör doch bitte damit auf, die Templates mit der Argumentation "für Anfänger" vermarkten zu wollen - das wird bei Anfängern nicht funktionieren, die verstehen doch oft am Anfang noch nicht einmal den Zusammenhang zwischen device, reading und attribute.

Du kannst diese Templates für Dich bauen und nutzen. Oder auch als Modul, wie von Rudi schon vorgeschlagen. Auch in meiner Konfiguration gibt es bestimmte Konstrukte, die mir die tägliche Arbeit erleichtern. Aber die würde ich nie in FHEM veröffentlichen, weil ich dann aus den Support-Anfragen gar nicht mehr rauskäme.

Eine grundsätzliche und zwangsweise Verankerung solcher Templates in jeder FHEM-Installation halte ich weiterhin nicht für zielführend.

[betateilchen]

- @KernSani: was ist die "import raw"-Funktionalität?

Diese Frage hätte m.E. von Dir als Entwickler, der gerade solche Vorschläge wie "Templates" macht, eigentlich nicht kommen dürfen.

[Dr. Boris Neubert]

Hoppla, was ist denn hier passiert?

Aber hör doch bitte damit auf, ...

Ich möchte keine Befehle empfangen, welche Vorschläge ich mache.

Diese Frage hätte m.E. von Dir als Entwickler, der gerade solche Vorschläge wie "Templates" macht, eigentlich nicht kommen dürfen.

Was möchtest Du mir damit sagen?

Viele Grüße
Boris

[Dr. Boris Neubert]

Hallo KernSani,

ich meinte den "Raw definition" button unten beim device - Dieser ist meines Erachtens ausreichend um Devices zu kopieren oder komplexe Definitionen zu importieren (sie - angepasst - zu kopieren ist damit etwas aufwändiger, weil ich es pro Device machen muss).

Danke für die Aufklärung. Ich bin gedanklich bei der händischen Konfiguration, weil ich das Webfrontend außer für die Erstellung von .gplot-Dateien nicht zu Konfigurationszwecken nutze.

Einen impliziten Wunsch sollte ich dazu noch offen legen, nämlich die Konfigurationsdatei übersichtlich zu halten, indem wiederkehrende Strophen nicht immer wieder sondern nur einmal hingeschrieben werden müssen. Dies erhöht die Wartbarkeit, weil nicht jedes Gerät angefasst werden muss, wenn man systematisch Änderungen vornehmen will.

Dein Aspekt, an zentraler Stelle Änderungen vornehmen zu können, die dann auf alle Devices übernommen werden, würde damit auch abgedeckt werden, indem das Template geändert und die Konfiguration neu verarbeitet wird (erfordert Neustart, aber wenn die grundsätzliche Akzeptanz gegeben ist, würde man dafür auch eine Lösung ohne Neustart finden).

Generell halte ich deinen Ansatz für gut, um z.B. immer wiederkehrende Fragen (Wie kann ich meine Rolläden bei Sonnenuntergang herunter lassen und bei Sonnenaufgang wieder hoch?) oder eben auch komplexere Szenarien als template mit auszuliefern.

Danke für die Zustimmung.

Viele Grüße
Boris

[Dr. Boris Neubert]

Ich verstehe dieses Problem immer noch nicht. Kann jemand bitte so nett sein, und fuer einen "csrfToken" Geschaedigten das ganz langsam erklaeren?

Code Auswählen Erweitern

define n notify foo:bar set lamp1 off;;set door open;;set alarm off;;set display text ";"

Code Auswählen Erweitern

define m notify baz:bat { perl;;code;; \
  if(bla) \{ ... \} ...\
  print("}");; \
}


Ausgangssituation und Zielsetzung: In beiden Fällen habe ich Mühe, die richtige Maskierung zu setzen. Ich würde gerne die Befehlsfolgen in umaskierten FHEM-Befehlen bzw. unmaskierten Perl schreiben und dann verwenden können.

Vermutlich würde dies aber auch durch ein Template-Device (hier mit Namen templ) erledigt werden können:

Code Auswählen Erweitern

define n notify foo:bar set templ Tagschaltung()

Code Auswählen Erweitern

define m notify baz:bat set templ wirrerPerlCode(bla)

Mit meinem im Eingangsbeitrag gemachten Vorschlag würde man schreiben:

Code Auswählen Erweitern

define n notify foo:bar $Tagschaltung()

Code Auswählen Erweitern

define m notify baz:bat $wirrerPerlCode(bla)

[rudolfkoenig]

@Boris:
Ich wuerde die Indirektion "templ def type name param...", gefolgt von "$name(param,...)" entfernen.

Type "fhem" finde ich sinnvoll, und wuerde es mit parseParams (https://forum.fhem.de/index.php/topic,52242.msg440262.html#msg440262) implementieren:

Code Auswählen Erweitern

templ def Heizung.templ name=hzwgz fhtcode=1B2B alias="Heizung Wohnzimmer" room=Wohnzimmer group=Heizung
Ein "templ del Heizung.templ name=hzwgz", was die per def angelegten Definitionen entfernt, sollte auch machbar sein.

Type "perl" finde ich falsch: wir haben mit DOIF bereits eine Alternative, dessen Syntax die Benutzer verwirrt, das reicht. Man hat die Moeglichkeit Perl-Funktionen zu verwenden, und da muss man nichts zusaetzlich wg. Variablenersetzung erklaeren.

Falls ich was falsch verstanden habe, bitte korrigieren.

[Dr. Boris Neubert]

Ich wuerde die Indirektion "templ def type name param...", gefolgt von "$name(param,...)" entfernen.

Type "fhem" finde ich sinnvoll, und wuerde es mit parseParams (https://forum.fhem.de/index.php/topic,52242.msg440262.html#msg440262) implementieren:

Code Auswählen Erweitern

templ def Heizung.templ name=hzwgz fhtcode=1B2B alias="Heizung Wohnzimmer" room=Wohnzimmer group=Heizung

Keine Indirektion: verstehe ich und ich finde keinen Grund für Indirektion; template def hätte das Makro definiert und das Template aus der Datei geladen, template use dann das Makro ausgeführt. Es geht aber auch gleich template use (statt def) und die Datei wird jedesmal geladen, wenn ein template use aufgerufen wird.

ParseParams: ist mehr FHEM-like (statt des funktionalen Stils à la C-Makro).

Ein "templ del Heizung.templ name=hzwgz", was die per def angelegten Definitionen entfernt, sollte auch machbar sein.

Das bräuchte man dann eigentlich nicht mehr. Es sei denn, dass mitgeschrieben wird, was template use tut, um es rückgängig zu machen. Frage an @KernSani: wie würdest Du Dir die Benutzung von Templates vorstellen (Beispielkommandofolge), um nach Änderung des Templates in der Datei die Geräte neu anzulegen? Oder reicht Dir die Möglichkeit über shutdown restart?

@Rudi: wie würde

Code Auswählen Erweitern

define n notify foo:bar set templ Tagschaltung() geschrieben werden?

Wie würde man die Variablen im Template markieren (im Vorschlag mit %NAME%, weil diese Zeichenkette vermutlich nie vorkommt und man dann stumpf Stringersetzung verwenden kann)?

Type "perl" finde ich falsch: wir haben mit DOIF bereits eine Alternative, dessen Syntax die Benutzer verwirrt, das reicht. Man hat die Moeglichkeit Perl-Funktionen zu verwenden, und da muss man nichts zusaetzlich wg. Variablenersetzung erklaeren.

Lass uns das bitte einen Moment zurückstellen.

Viele Grüße
Boris

[rudolfkoenig]

@Rudi: wie würde
define n notify foo:bar set templ Tagschaltung()
geschrieben werden?

Gar nicht, da das nur in der "perl" Variante sinnvoll ist, und da bin ich ja dagegen.

[Dr. Boris Neubert]

Gar nicht, da das nur in der "perl" Variante sinnvoll ist, und da bin ich ja dagegen.

Ich bin überzeugt. Wenn man das braucht, kann man auch gleich das ganze define in ein Template packen.

[betateilchen]

Ich möchte keine Befehle empfangen, welche Vorschläge ich mache.

Da stand nix von Befehl, sondern ganz klar "bitte".

Was möchtest Du mir damit sagen?

Nichts anderes, als dass es vielleicht manchmal sinnvoll ist, sich mit den zur Verfügung stehenden Mitteln von FHEM auseinanderzusetzen. Insbesondere, wenn man nicht tagesaktuell die Weiterentwicklung von FHEM beobachtet und im Blick hat (was man von niemandem erwartet). Manchmal haben sich einfach schon neue Werkzeuge/Möglichkeiten ergeben, die eine aufkommende Frage schon beantworten können oder Lösungsansätze für ein "Problem" bieten. Und gerade von Entwicklern erwarte ich ein solches Vorgehen noch viel eher als von einem reinen Anwender.

Speziell die "raw definition" in der Detailansicht ist nun wirklich nicht neu, sondern (geschätzt) ein halbes Jahr alt.

[Dr. Boris Neubert]

@Boris:
Ich wuerde die Indirektion "templ def type name param...", gefolgt von "$name(param,...)" entfernen.

Type "fhem" finde ich sinnvoll, und wuerde es mit parseParams (https://forum.fhem.de/index.php/topic,52242.msg440262.html#msg440262) implementieren:

Code Auswählen Erweitern

templ def Heizung.templ name=hzwgz fhtcode=1B2B alias="Heizung Wohnzimmer" room=Wohnzimmer group=Heizung

Das habe ich jetzt so realisiert. Bitte finde anbei die Patches dazu.

[rudolfkoenig]

Das ist alles perfekt, bis auf die Tatsache, dass es Teil von fhem.pl ist.
Wieso nicht als eigenstaendiges Modul?

Statt open..close wuerde ich FileRead() verwenden, dann darf das template im configDB gespeichert sein.

[Dr. Boris Neubert]

Guten Morgen,

Wieso nicht als eigenstaendiges Modul?

Alte Gewohnheit. Es wandert nach 98_template.pm und wird im Laufe des Tages eingecheckt.

Bei der Codebeschau ist mir ein Überbleibsel in fhem.pl aufgefallen: in Zeile 369 steht die Hilfe zu restore, was aber auch ein eigenes Modul ist.

Sollten nicht noch mehr Befehle in Module ausziehen?

Statt open..close wuerde ich FileRead() verwenden, dann darf das template im configDB gespeichert sein.

Danke für den Tipp. Baue ich ein.

Viele Grüße
Boris

[KernSani]

Hallo Boris,

ich komme jetzt endlich mal dazu, das zu testen... Mein konkreter Anwendungsfall: Ich habe vor, meine Rollläden auf das ROLLO Modul umzustellen.

Meine Erkenntnisse/Wünsche:
1.) Es wäre schon, wenn das Anlegen eines template files aus FHEM heraus unterstützt werden würde, sowas wie:

Code Auswählen Erweitern

template create myTemplate.tpl
2.) Ich glaube betateilchen hatte es irgendwo erwähnt: configDB Nutzer müssen das File zunächst importieren (Doku ergänzen?). Mit Punkt 1 dürfte das auch erschlagen werden.
3.) Feste Dateiendung zum Editieren in "Edit Files" (mein template heisst jetzt .layout
4.) Defaultwerte wären klasse... sowas in der Art wie %meinWert:defaultWert% - wenn "meinWert" bei template use mitgegeben wird, wird dieser Wert genommen, ansonsten der defaultWert 
5.) nachdem ich nun mein Template erstellt hatte, wollte ich es testen, aber:

Code Auswählen Erweitern


Error on reading tmpl_rollo.layout from database!


Das File existiert in der DB, ich kann es editieren... Nur der template Befehl findet es nicht...
Das Logfile sagt nicht viel:

Code Auswählen Erweitern

2017.03.18 00:09:05 4: WEB_192.168.1.112_52487 POST /fhem&fw_id=1695&room=Unsorted&fwcsrf=csrf_189884894786425&cmd=template+show+tmpl_rollo.layout+; BUFLEN:0
2017.03.18 00:09:05 5: Cmd: >template show tmpl_rollo.layout<
2017.03.18 00:09:05 4: configDB reading file: tmpl_rollo.layout
2017.03.18 00:09:05 4: WEB: /fhem&fw_id=1695&room=Unsorted&fwcsrf=csrf_189884894786425&cmd=template+show+tmpl_rollo.layout+ / RL:1975 / text/html; charset=UTF-8 / Content-Encoding: gzip

Eine Idee, wie ich weiter vorgehen könnte?

Grüße,

Oli

[KernSani]

Hi Boris,

ich habe das template file aus der db gelöscht und nochmal neu importiert und jetzt funktioniert es... Keine Ahnung, was da schief stand. Ich dachte, das hätte ich gestern auch schon gemacht...

Grüße,

Oli

[KernSani]

Projekt ROLLO abgeschlossen. Template gefällt mir gut. Hab mal einen Wiki Artikel dazu begonnen....

[igami]

Wenn ich das richtig verstehe ist template nur zum anlegen von devices da, spätere Änderungen sind nicht möglich, oder?
Beispiel:
ich nehme das template aus dem wiki

Code Auswählen Erweitern


# my Template File ./FHEM/tmpl_example.layout
define %name% dummy
define di_%name% doif ([%name]) (set %device" on)
attr di_%name do always

und merke später, dass ich ja gerne auch ein icon für den dummy hätte

Code Auswählen Erweitern


# my Template File ./FHEM/tmpl_example.layout
define %name% dummy
attr %name% icon Icon_Fisch
define di_%name% doif ([%name]) (set %device" on)
attr di_%name do always

Das wirkt sich dann ja nicht auf die bestehenden devices aus.

Wäre es nicht sinnvoller das als

Code Auswählen Erweitern


template ./FHEM/tmpl_example.layout name=myDummy

in der config zu speichern, sodass es bei einem neustart auch aktualisiert wird?

[KernSani]

Wenn ich das richtig verstehe ist template nur zum anlegen von devices da, spätere Änderungen sind nicht möglich, oder?
Beispiel:
ich nehme das template aus dem wiki

Code Auswählen Erweitern


# my Template File ./FHEM/tmpl_example.layout
define %name% dummy
define di_%name% doif ([%name]) (set %device" on)
attr di_%name do always

und merke später, dass ich ja gerne auch ein icon für den dummy hätte

Code Auswählen Erweitern


# my Template File ./FHEM/tmpl_example.layout
define %name% dummy
attr %name% icon Icon_Fisch
define di_%name% doif ([%name]) (set %device" on)
attr di_%name do always

Das wirkt sich dann ja nicht auf die bestehenden devices aus.

Wäre es nicht sinnvoller das als

Code Auswählen Erweitern


template ./FHEM/tmpl_example.layout name=myDummy

in der config zu speichern, sodass es bei einem neustart auch aktualisiert wird?

Im Gegensatz zu früheren Äußerungen bin ich mir nicht sicher, dass das zielführend wäre. Möglicherweise hsbe ich ja manuell bereits ein anderes Icon gesetzt o.ä.
Ich verpasse meinen mit Hilfe von template erstellten Devices ein user Attribut mit dem Templatenamen, so lassen sie sich schnell identifizieren und ggf. (kontrolliert) ändern

[Dr. Boris Neubert]

Wäre es nicht sinnvoller das als

Code Auswählen Erweitern


template ./FHEM/tmpl_example.layout name=myDummy

in der config zu speichern, sodass es bei einem neustart auch aktualisiert wird?

So verwende ich es und so habe ich es mir gedacht, als ich es erfunden habe. Ich definiere einmal im Template eine Litanei von zig Zeilen und definiere dann alle gleichartigen Devices im Gleichtakt mit

Code Auswählen Erweitern

template Heizung.template name=Wohnzimmer fhtcode=4711
template Heizung.template name=Kinderzimmer fhtcode=4712
template Heizung.template name=Schlafzeimmer fhtcode=4713
template Heizung.template name=Bad fhtcode=4714

Und so steht das dann auch in der fhem.conf.

Viele Grüße
Boris

[betateilchen]

Und so steht das dann auch in der fhem.conf.

Wenn Du damit die fhem.cfg meinst, verstösst das gegen bisher geltende Konventionen, die u.a. besagen, dass in den Konfigurationsdaten nur "define", "attr", "include" und Kommentare zulässig sind.

Seit Jahren kämpfen wir damit, den Anwendern beizubringen, dass keine Befehle wie "set" in die Konfiguration gehören, und jetzt kommst Du mit sowas um die Ecke...

[KernSani]

Ein configdb list wirft mir ganz normale defines für die via template erzeugten devices aus. Kenne aber die Funktionsweise von configdb nicht um jetzt sagen zu können, wie das tstsächlich abgelegt ist.

[Dr. Boris Neubert]

Wenn Du damit die fhem.cfg meinst, verstösst das gegen bisher geltende Konventionen, die u.a. besagen, dass in den Konfigurationsdaten nur "define", "attr", "include" und Kommentare zulässig sind.

Dann wird die Konvention jetzt um "template" erweitert. "template" ist nichts anderes als "include' mit Parametersubstitution.

Seit Jahren kämpfen wir damit, den Anwendern beizubringen, dass keine Befehle wie "set" in die Konfiguration gehören, und jetzt kommst Du mit sowas um die Ecke...

Wie kommst Du bitte darauf, dass ich ein Template benutzen möchte, um einen set-Befehl in die fhem.conf zu schreiben, oder dieses einem Anwender empfehlen würde? Das käme mir nie in den Sinn. Ich sehe auch nicht, dass irgendeines der Beispiele in diesem Thema ein set im Template enthalten würde.

Also bitte!

[rudolfkoenig]

Wenn Du damit die fhem.cfg meinst, verstösst das gegen bisher geltende Konventionen, die u.a. besagen, dass in den Konfigurationsdaten nur "define", "attr", "include" und Kommentare zulässig sind.

Das stimmt insoweit, dass nur diese Befehle wieder mit save gespeichert werden.

Die beschriebene Methode der nachtraeglichen Template-Aenderung ist fuer mehr als 99% der FHEM-Anwender nicht praktikabel: man darf dabei keine FHEM Definitionen oder Attribute live aendern, es muss alles ueber fhem.cfg erfolgen, save darf man nicht verwenden. Das man sowas Anfaengern nicht zeigt, ist selbstverstaendlich.

@KernSani: configdb und fhem.cfg sollte in diesem Fall keinen Unterschied machen, nur dass "configdb manuell editieren" nur was fuer hartgesottene ist.

[betateilchen]

@Boris: ich bin gegen diese Konventionserweiterung. configDB braucht und benutzt kein includes und wird somit auch Deinen template Befehl nicht unterstützen.

Dass Du irgendwo set Befehle empfiehlst, habe ich nirgends geschrieben, vielleicht solltest Du etwas sorgfältiger lesen. Aber Du beschreibst die Verwendung von template in der Konfiguration, was letztendlich auch nix anderes ist als ein bisher nicht zulässiger Befehl.

Warum erweiterst Du Deine 98_template.pm nicht um eine DefineFn? Nirgends steht, dass ein commanModul sowas nicht haben darf.

Würde es eine DefineFn geben, könnte man sowas machen:

Code Auswählen Erweitern

define Wohnzimmer template Heizung.template fhtcode=0815

Und die DefineFn übernimmt den Rest. Damit wären die bisherigen Konventionen eingehalten und die Syntax für die Verwendung fände ich nebenbei gesagt auch noch logischer und besser zu merken.

[Dr. Boris Neubert]

Seit Jahren kämpfen wir damit, den Anwendern beizubringen, dass keine Befehle wie "set" in die Konfiguration gehören, und jetzt kommst Du mit sowas um die Ecke...

Mein Deutsch-Modul scheint defekt zu sein.

[betateilchen]

Ja, offensichtlich, denn es reißt Textteile aus ihrem umgebenden Kontext.

Aber das ist ja nicht das erste Mal, dass Du mir aus meinen Beiträgen falsche Unterstellungen präsentierst, weil Du in aus ihrem Kontext gerissenen Textbrocken falsche Inhalte hineininterpretierst. Warum Du das immer wieder tust - keine Ahnung. Aber wenn Dir das so großen Spaß macht - nur zu. Jedem Tierchen sein Pläsierchen.

[Dr. Boris Neubert]

<offtopic>

Aber das ist ja nicht das erste Mal, dass Du mir aus meinen Beiträgen falsche Unterstellungen präsentierst, weil Du in aus ihrem Kontext gerissenen Textbrocken falsche Inhalte hineininterpretierst. Warum Du das immer wieder tust - keine Ahnung. Aber wenn Dir das so großen Spaß macht

Ich vermute, dass es an der großen Zahl von Du-Botschaften liegt, die ich empfange. Und jetzt reißen wir uns wieder am Riemen und kommen zurück
</offtopic>

zur Sache:

Wenn template in der Konfiguration bei Benutzern des save-Kommandos überleben soll, muss es eine Sonderbehandlung geben. template-Befehle müssen gespeichert werden und die aus Templates generierten Geräte nicht (siehe CommandInclude, $comments; und VOLATILE). Das hat den durchaus erwünschten Nebeneffekt, dass während des Programmlaufs erfolgte Änderungen an den via template definierten Geräten nicht persistent werden.

[rudolfkoenig]

Wenn template in der Konfiguration bei Benutzern des save-Kommandos überleben soll, muss es eine Sonderbehandlung geben.

Das ist mir zu viel Aufwand an zentralen Stellen mit unueberschaubaren Nebenwirkungen.

Die gleiche Funktionalitaet kann aber auch im template Modul implementiert werden: wenn template die erzeugten Instanzen merkt, dann koennte der Benutzer die im template Datei durchgefuehrten Aenderungen mit einem "template apply" Befehl aktivieren.

[Dr. Boris Neubert]

Die gleiche Funktionalitaet kann aber auch im template Modul implementiert werden: wenn template die erzeugten Instanzen merkt, dann koennte der Benutzer die im template Datei durchgefuehrten Aenderungen mit einem "template apply" Befehl aktivieren.

Ich meine, dass wir über komplementäre Aufgaben reden.

Verstehe ich Dich richtig, dass Dein Vorschlag darauf zielt, Änderungen an per template erzeugten Devices ins Template zurückzuspielen? Das ist meinerseits nicht gewünscht.

Mir geht es darum, dass der Befehl "template ..." bei Ausführung des Befehls "save" wieder in der Konfigurationsdatei landet und die aus dem Template heraus erstellten Dateien nicht. Letzteres ist m.E. über das VOLATILE-Internal aus dem template-Command-Modul abbildbar. Die Rettung von "template ..." möglicherweise auch, wenn das Template-Modul die Zeile "template ..." in die %comments schmuggelt (wie es fhem.pl macht). Das habe ich aber nicht weiter analysiert.

[zap]

Ich verwende in meinem Modul HMCCU ebenfalls eine Art Templates. Mangels Alternative habe ich die Homematic Geräteparameter in 2 Hashes in einem separaten Modul HMCCUConf.pm abgelegt.

Mit Deinem Template Befehl könnte man die Geschichte nun zwar nicht einfacher, jedoch leichter verständlich und pflegbar machen. Dazu bräuchte es aber eine kleine Erweiterung des template Befehls, da ich gerne die Templates für alle Homematic Geräte in eine Template-Datei packen würde. Ich stelle mir folgende Syntax-Erweiterung für template-Dateien vor, um mehrere Templates in einer Datei zu packen:

Code Auswählen Erweitern


template MyTemp1 {
   define %par1% XYDEV %par2%
   attr %par1 room %par3%
}

template MyTemp2 {
   define %par1% ABDEV %par2%
}


Alternative könnte man auch die Klammern weg lassen und nur irgendwo ein "template MyTemp1:" einfügen. Ab dieser Zeile beginnt dann ein neues Template.

Der eigentliche Befehlsaufruf wäre ähnlich wie jetzt, jedoch um den Namen des zu verwendenden Templates ergänzt. So würde man eine Flut von Template-Files vermeiden und könnte zusammengehörige Templates in einer Datei ablegen und auch leicht an andere Nutzer weitergeben.

Für die Ablage der Template-Dateien könnte man im FHEM Verzeichnis ein Standardverzeichnis "templates" anlegen.

[rudolfkoenig]

Verstehe ich Dich richtig, dass Dein Vorschlag darauf zielt, Änderungen an per template erzeugten Devices ins Template zurückzuspielen?

Nein. Es geht mir darum, nachtraegliche Aenderungen an Template-Dateien bei allen per Template erzeugten Geraeten zu aktivieren.

Mir geht es darum, dass der Befehl "template ..." bei Ausführung des Befehls "save" wieder in der Konfigurationsdatei landet

Ich habe das auch so verstanden, dein Vorschlag hat fuer mich aber zu viele Haken. Zusaetzlich zu deinen Punkten faellt mir ein:
- bei den so erzeugten Geraeten darf man keine Attribute modifizieren, und das in allen Frontends.
- so erzeugte Geraete darf man nicht loeschen
- die Frontends muessen eine Liste der Templates zeigen, damit man das modifizieren kann. Es gibt aber kein Konzept fuers Modifizieren von Befehlen, nur von Geraeten.
- Wenn ein Geraet nicht gespeichert wird (wg. VOLATILE), gehen auch alle Readings verloren.

Man kann natuerlich alles irgendwie loesen, aber der Aufwand ist mir zu hoch.

[betateilchen]

Die Rettung von "template ..." möglicherweise auch, wenn das Template-Modul die Zeile "template ..." in die %comments schmuggelt (wie es fhem.pl macht). Das habe ich aber nicht weiter analysiert.

Brauchst Du nicht analysieren. configDB kennt nicht nur keine includes sondern auch keine comments, weil die dort keinen Sinn machen.

Das ist mir zu viel Aufwand an zentralen Stellen mit unueberschaubaren Nebenwirkungen.

Mir auch.

[Dr. Boris Neubert]

Ich verfolge mal Udos Vorschlag weiter, dem template auch ein define zu spendieren.

[Dr. Boris Neubert]

..., um mehrere Templates in einer Datei zu packen...

Für die Ablage der Template-Dateien könnte man im FHEM Verzeichnis ein Standardverzeichnis "templates" anlegen.

Es geht Dir  darum, mehrere Templates in einer Datei haben zu können?

Zu dem Thema mit den Standardverzeichnis gab es kürzlich schon eine Regung im Kontext der gplot-Dateien. Das Thema Verzeichnisse und Trennung Programm/Konfiguration muss noch gären.

[zap]

Es geht Dir  darum, mehrere Templates in einer Datei haben zu können?

Genau. Hintergrund: bei Homematic hat jeder Gerätetyp andere Attribute. Eine Datei wäre da m.E. Besser als 30 einzelne

[betateilchen]

Genau. Hintergrund: bei Homematic hat jeder Gerätetyp andere Attribute. Eine Datei wäre da m.E. Besser als 30 einzelne

ein ideales Einsatzgebiet für eine Konfigurationsdatenbank...

*duck-und-weg*

[zap]

Kein Grund für "duck und weg". Ich befürworte auch eine Config-DB. Allerdings verbindlich, d.h. dann müsste fhem.cfg wirklich komplett ersetzt werden und das wird vermutlich nicht passieren.
Unter diesen Voraussetzungen möchte ich meine Module jedenfalls nicht von einer DB abhängig machen. Da erscheint mir das Template Konzept praktikabler, zumal die Templates so auch leichter editierbar sind.

[betateilchen]

Unter diesen Voraussetzungen möchte ich meine Module jedenfalls nicht von einer DB abhängig machen. Da erscheint mir das Template Konzept praktikabler, zumal die Templates so auch leichter editierbar sind.

Das sind/wären sie auch bei einer Datenbank.

Aber das setzt eben voraus, dass man sich damit einfach mal auseinandersetzt, wozu viele Entwickler leider nicht bereit sind. Der configDB wird immer mit (falschen) Vorurteilen und Behauptungen darüber begegnet, was damit angeblich NICHT funktioniert, anstatt herauszufinden, welche Möglichkeiten dort inzwischen vorhanden sind, wovon die textbasierte Konfiguration nur träumen kann. Aber das ist ein anderes Thema - das mich inhaltlich trotzdem immer wieder maßlos ärgert.