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:
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.
Der beigefügte experimentelle Patch fügt einen Befehl template zu FHEM hinzu:
Usage: template def fhem|perl <name>(<args>) fileName
template del <name>
template list
Beispiel für Definition:
templ def fhem Heizung(fhtcode,name,alias,room,group) Heizung.templ
templ list
Beispiel für Verwendung:
$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.
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.
Ohne es naeher angeschaut zu haben: kann man das nicht als Modul anlegen?
Dann brauchst du gar nicht zu fragen, ob es aufgenommen wird.
es gibt von igami ein modul das glaube ich in diese richtung geht. mit fällt nur gerade her name nicht ein ...
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?
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
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
ZitatZur 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.
Zitat von: betateilchen am 05 März 2017, 12:50:06
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...
Zitat von: dev0 am 05 März 2017, 13:04:40
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.
Zitat von: betateilchen am 05 März 2017, 13:13:29
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.
ZitatDie 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? :)
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:
copy olddev newdev mydefpar1 attr1=val1 attr2=val2
Das fände ich auch einen guten (und verständlichen) Weg zur Umsetzung.
Zitat von: zap am 08 März 2017, 08:55:30
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:
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
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
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...
Zitat von: Dr. Boris Neubert am 09 März 2017, 22:05:08
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.
Zitat von: Dr. Boris Neubert am 09 März 2017, 22:05:08
- @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.
Hoppla, was ist denn hier passiert?
Zitat von: betateilchen am 09 März 2017, 22:55:04
Aber hör doch bitte damit auf, ...
Ich möchte keine Befehle empfangen, welche Vorschläge ich mache.
Zitat von: betateilchen am 09 März 2017, 22:55:04
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
Hallo KernSani,
Zitat von: KernSani am 09 März 2017, 22:40:09
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).
Zitat
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
Zitat von: rudolfkoenig am 05 März 2017, 14:45:10
Ich verstehe dieses Problem immer noch nicht. Kann jemand bitte so nett sein, und fuer einen "csrfToken" Geschaedigten das ganz langsam erklaeren? :)
define n notify foo:bar set lamp1 off;;set door open;;set alarm off;;set display text ";"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:
define n notify foo:bar set templ Tagschaltung()define m notify baz:bat set templ wirrerPerlCode(bla) Mit meinem im Eingangsbeitrag gemachten Vorschlag würde man schreiben:
define n notify foo:bar $Tagschaltung()define m notify baz:bat $wirrerPerlCode(bla)
@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:
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.
Zitat von: rudolfkoenig am 10 März 2017, 09:37:00
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:
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).
Zitat
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
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)?
Zitat
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
Zitat@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.
Zitat von: rudolfkoenig am 10 März 2017, 13:19:59
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.
Zitat von: Dr. Boris Neubert am 10 März 2017, 08:00:21
Ich möchte keine Befehle empfangen, welche Vorschläge ich mache.
Da stand nix von Befehl, sondern ganz klar "bitte".
Zitat von: Dr. Boris Neubert am 10 März 2017, 08:00:21
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.
Zitat von: rudolfkoenig am 10 März 2017, 09:37:00
@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:
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.
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.
Guten Morgen,
Zitat von: rudolfkoenig am 12 März 2017, 07:31:28
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?
Zitat
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
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:
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:
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:
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
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
Projekt ROLLO abgeschlossen. Template gefällt mir gut. Hab mal einen Wiki Artikel (https://wiki.fhem.de/wiki/Template) dazu begonnen....
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
# 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
# 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
template ./FHEM/tmpl_example.layout name=myDummy
in der config zu speichern, sodass es bei einem neustart auch aktualisiert wird?
Zitat von: igami am 20 März 2017, 06:15:38
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
# 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
# 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
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
Zitat von: igami am 20 März 2017, 06:15:38
Wäre es nicht sinnvoller das als
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
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=4714Und so steht das dann auch in der fhem.conf.
Viele Grüße
Boris
Zitat von: Dr. Boris Neubert am 23 März 2017, 19:14:51
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...
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.
Zitat von: betateilchen am 23 März 2017, 19:41:11
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.
Zitat
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!
ZitatWenn 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.
@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:
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.
Zitat von: betateilchen am 23 März 2017, 19:41:11
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.
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 (https://www.redensarten-index.de/suche.php?suchbegriff=~~Jedem%20Tierchen%20sein%20Pl%C3%A4sierchen!&bool=relevanz&suchspalte%5B%5D=rart_ou).
<offtopic>
Zitat von: betateilchen am 23 März 2017, 23:08:39
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.
ZitatWenn 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.
Zitat von: rudolfkoenig am 24 März 2017, 08:01:45
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.
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:
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.
ZitatVerstehe 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.
ZitatMir 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.
Zitat von: Dr. Boris Neubert am 24 März 2017, 10:43:29
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.
Zitat von: rudolfkoenig am 24 März 2017, 08:01:45
Das ist mir zu viel Aufwand an zentralen Stellen mit unueberschaubaren Nebenwirkungen.
Mir auch.
Ich verfolge mal Udos Vorschlag weiter, dem template auch ein define zu spendieren.
Zitat von: zap am 24 März 2017, 14:55:32
..., 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.
Zitat von: Dr. Boris Neubert am 24 März 2017, 19:58:48
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
Zitat von: zap am 26 März 2017, 21:33:02
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*
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.
Zitat von: zap am 29 März 2017, 19:17:30
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.