Templates in FHEM

Begonnen von Dr. Boris Neubert, 05 März 2017, 11:58:33

Vorheriges Thema - Nächstes Thema

Dr. Boris Neubert

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.
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

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:


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.
2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

rudolfkoenig

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.

betateilchen

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.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Dr. Boris Neubert

Ich verfolge mal Udos Vorschlag weiter, dem template auch ein define zu spendieren.
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

Dr. Boris Neubert

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.
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

zap

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
2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

betateilchen

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*
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

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.
2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

betateilchen

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.


-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!