attrTemplate für ZWave? Vorüberlegungen...

[Beta-User]

Hallo zusammen,

nachdem ich jetzt einerseits selbst so meine ersten Erfahrungen mit diversen ZWave-Komponenten gemacht habe und andererseits das Thema attrTemplate als Mechanismus ziemlich ausgereift und sehr flexibel ist, wollte ich mal allgemein zur Diskussion stellen, ob es sinnvoll ist, das Thema auch für ZWave anzugehen.

Da ZWave SetExtensions mitbringt, sollte das ja ohne weiteres gehen.

Was ich mir vorstelle:
Die Grund-Konfiguration von ZWave-Geräten erfolgt anhand der xml-files. Diese werden (außerhalb von FHEM) zentral verwaltet, es gibt ggf. kleinere Korrekturen oder Erweiterungen, wenn mal was fehlen sollte, was (noch) nicht zentral eingeflossen ist. Die xml-Files enthalten aber keine Optimierungen dahingehend, dass irgendwie FHEM-optimierte Parameter bereits gesetzt würden. Die Konfiguration via autocreate ist im Prinzip damit abgeschlossen, dass in FHEMWEB ersichtlich ist, welche Befehle (einschl. Konfigurationsparameter) es gibt, und welche Beschreibung zu den Parametern in der xml enthalten ist.

Ab diesem Moment ist man - etwas überspitzt formuliert - darauf angewiesen, dass das Gerät bereits glücklicherweise so funktioniert, wie es soll (das war in meiner Erinnerung nur bei den einfachen Fibaro-on/off-Aktoren so und vielleicht bei den Roller-Geräten im Rollladenmodus), oder man entweder "erraten" (oder austesten) muß, was denn jetzt die für FHEM passende Konfiguration ist, oder man hat das Glück, dass irgendwo im Wiki (https://wiki.fhem.de/wiki/Z-Wave#Ger.C3.A4te-Besonderheiten) oder im Forum zu finden ist, wie es (in etwa) geht.

Kurz: diese etwas beschwerliche Ausgangssituation ist nicht gerade förderlich für die Verbreitung der Technik an sich, obwohl es tolle Geräte von verschiedenen Herstellern gibt und die nach meinen bisherigen Erfahrungen auch in der Regel ganz gut miteinander zusammenarbeiten.

Meine Idee wäre jetzt, typische Konfigurationen und "FHEM-friendly"-Einstellungen via attrTemplate dann allg. zur Verfügung zu stellen. So könnte man z.B. die Konfiguration von einem Fibaro-Rollladenaktor für "Normalbetrieb" und im "venetian mode" per Radio-Option steuern, gleich die Einbindung in die Sprachsteuerung machen, ....  Damit hätte man auch eine zentrale Anlaufstelle, über die man Verbesserungsvorschläge, Fragen usw. einkippen könnte.

Allerdings habe ich Bedenken, ob das ganze aufgrund der Komplexität der Materie überhaupt möglich ist oder ob dann am Ende mehr Fragen als Antworten stehen. Daher wollte ich einfach mal vorab meine diesbezüglichen Gedanken mal unverbindlich in den Raum stellen.

(Ich wäre auch bereit, das als (Mit-) Maintainer erst mal anzuschieben).

Grüße, Beta-User

[tux75at]

Hallo Beta-User,

Ich glaube das wäre hilfreich. Ein Problem welches immer wieder mal bestehen kann ist eine Fehlkonfiguration, weil ein Standardwert nicht passt.
Sowas hatte ich bei einigen Geräten. Wenn man Gerätespezifisch ein Template hätte, bei dem man die Standardwerte beim Einbinden einstellen könnte, dann wären viele Probleme gelöst.
Ich denke aber, dass dies eher schwierig umzusetzen ist.

Etwas das ich mir wünschen würde ein einstellbares Template, auch wenn es nicht in FHEM ist, mit meinen Settings. Wenn man jetzt 10 Sensoren einbindet, eventuell noch Batteriebetrieben und danach diverse Einstellungen tätigen muss, dann vergisst man schnell mal eines und wundert sich, warum ein Gerät nicht/anders funktioniert. Batteriebetriebene Geräte sind zum Konfigurieren nicht wirklich userfriendly. Wenn diese Settings aus diesen Template übernommen und nach dem Einbinden automatisch eingespielt werden, dann wären alle Sensoren automatisch mit den gleichen und vor allem meinen Settings konfiguriert.

Mit dem Wildwuchs an Geräten wird es  schwierig/unmöglich alle Geräte zu unterstützen, hier müsste ein generischer Ansatz gewählt werden, der von den XML Files die möglichen Settings übernimmt. Damit wäre die Wartung der XML-Files wichtig. Ein Update dieser XML-Files muss man auch berücksichtigen.

Ich denke da schon etwas zu weit .... aber trivial wäre so etwas nicht ... hilfreich jedenfalls.

Gruß
Tux

[rcmcronny]

Ich bin auch sehr dafür

Ronny

[rudolfkoenig]

Die von OpenZWave "ausgeborgenen" XML-Files haben eine vergleichbare Funktion, das FHEM-Modul versteht aber nur einen Teil davon (Hilfe, Config-Beschreibung, Klasse-Hinzufuegen, Link zu Geraetedoku).  Ich meine es waere sinnvoll die XML-Dateien zu pruefen, evtl. kann man Arbeit sparen, wenn man dem ZWave Modul beibringt, mehr zu verstehen.
Ich uebernehme gerne das Beibringen, wenn man mir sagt, was sinnvoll waere.

Im ZWave-Modul gibt es auch einen geraetespezifischen Abschnitt (%zwave_deviceSpecial) mit 4 Geraeten, am liebsten waere es mir, diesen auszulagern, entweder in die XML-Dateien, oder in den zukuenftigen AttrTemplate

[rudolfkoenig]

Etwas das ich mir wünschen würde ein einstellbares Template, auch wenn es nicht in FHEM ist, mit meinen Settings. Wenn man jetzt 10 Sensoren einbindet, eventuell noch Batteriebetrieben und danach diverse Einstellungen tätigen muss, dann vergisst man schnell mal eines und wundert sich, warum ein Gerät nicht/anders funktioniert.

Dafuer kann man ein eigenes Template anlegen.
Etwas einfacher aber weniger flexibel ist ein notify, was man z.Bsp. mit "trigger notifyName NewDeviceName" aufrufen kann.

[krikan]

Die von OpenZWave "ausgeborgenen" XML-Files haben eine vergleichbare Funktion, das FHEM-Modul versteht aber nur einen Teil davon (Hilfe, Config-Beschreibung, Klasse-Hinzufuegen, Link zu Geraetedoku). 

Hast Du ein Beispiel? Mir ist nichts von "vergleichbare Funktion" bekannt.

Im ZWave-Modul gibt es auch einen geraetespezifischen Abschnitt (%zwave_deviceSpecial) mit 4 Geraeten, am liebsten waere es mir, diesen auszulagern, entweder in die XML-Dateien, oder in den zukuenftigen AttrTemplate

FDS223: https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/10_ZWave.pm#L686 müsste mMn durch die Erweiterung https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/10_ZWave.pm#L922 ff. überflüssig sein.

FGRM222: https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/10_ZWave.pm#L677 implementiert ozw durch eine Erweiterung der Command Class und nicht aus den XMLs.
Philio_PSE02 (https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/10_ZWave.pm#L692) und devolo siren (https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/10_ZWave.pm#L664) konnte bzw. kann(?) ozw nicht und wird afaik auch nicht in den XMLs abgebildet.
Bei den letzten dreien erkenne ich keine XML-basierte Lösung und evtl. AttrTemplate-Umsetzung kann ich nicht nachvollziehen. Muss man dann manuell die Befehle per attrTemplate zuweisen statt auf Automatik bei der Inklusion zu setzen (=Rückschritt) ?

Mir ist bei ZWave-AttrTemplate noch nicht klar, was ich mir vorstellen darf: Schließt das neben gesetzten Attributen auch eine automatische Konfiguration der config-Werte ein? Bei letzterem müsste man bspw. beachten, dass sich die Klartext-config-Befehle bei Aktualisierungen der XMLs immmer ändern können -> also besser configByte, configWord,.. nutzen.

Gruß, Christian

[Beta-User]

Danke mal vorab für vielfältige Echo.

Vielleicht nochmal zum besseren Verständnis mein derzeitiges Verständnis der Gesamtzusammenhänge:

Die Jeweiligen xml-files enthalten Infos, was prinzipiell mit einem Device möglich ist. Fehler, die auf der Ebene entstehen, kann (afaik) FHEM (und damit attrTemplate) nicht wirklich lösen. Der beste Weg ist, eventuelle Verbesserungen dort einzupfelgen, optimalerweise nicht auf FHEM-Ebene, sondern dort, wo die files herkommen (früher pepper etc. pp.). Updates in diesen Files wirken sich automatisch und zwingend dann aus, (spätestens,) wenn man die Modell-Abfrage macht; man hat als user keine (einfache) Möglichkeit, vorab zu erfahren, was (nach Änderungen: anders) passieren wird.

Die von OpenZWave "ausgeborgenen" XML-Files haben eine vergleichbare Funktion, das FHEM-Modul versteht aber nur einen Teil davon (Hilfe, Config-Beschreibung, Klasse-Hinzufuegen, Link zu Geraetedoku).  Ich meine es waere sinnvoll die XML-Dateien zu pruefen, evtl. kann man Arbeit sparen, wenn man dem ZWave Modul beibringt, mehr zu verstehen.
Ich uebernehme gerne das Beibringen, wenn man mir sagt, was sinnvoll waere.

Es wäre daher in jedem Fall zielführend, die in den XML's enthaltenen Infos bzw. Vorgaben (?) möglichst umfassend auszuwerten. Den Teil werde ich mir daher auch nochmal ansehen, bezweifle aber, dass ich die Bausteinchen korrekt zusammenbasteln kann ... Da werde ich wohl im mindesten Fall eine kleine Führung duch den Code brauchen

Ein Problem welches immer wieder mal bestehen kann ist eine Fehlkonfiguration, weil ein Standardwert nicht passt.

Sowas sollte sich über attrTemplate lösen lassen können, das Problem dürfte eher die Festlegung sein, wann denn ein Standardwert als "nicht passend" anzusehen ist. Das erfordert ggf. einen entsprechenden Austausch zwischen mehreren Usern und dann eben eine Entscheidung, was letztendlich zum "passenden" Standard erklärt werden soll. Nicht einfach, viel Detailarbeit, Mitwirkung der betreffenden User erforderlich...

=> MMn. aber der einzige Weg...

Vorteil: attrTemplate ist transparent. Man kann (!) als User vorher sehen, was passieren wird. Mit der Zahl der ggf. vorhandenen templates wird es unübersichtlich, aber da kann ggf. filter: helfen, wobei das auch Nachteile hat, wenn man wissen will, was denn für ähnliche Geräte die (vorgeschlagene) Lösung gewesen wäre.
Wäre auszutesten.

Nachteil: Derjenige, der die Hauptarbeit mit dem betreffenden template hat, benötigt es eigentlich nicht mehr . Leider kann man die Dinge hier nicht mehr so gut austesten wie z.B. bei MQTT2-Device, da der Erfolg sich eigentlich nur im Zusammenwirken mit der konkreten Hardware wirklich beurteilen läßt. Das erfordert dann ggf. mehr Disziplin beim "Ersteinreicher" und eine gewisse Frustrationstoleranz bei den "Erstanwendern", weil ggf. dann doch noch das eine oder andere an Wehwehchen dann erst später zu erkennen ist.

Etwas das ich mir wünschen würde ein einstellbares Template, auch wenn es nicht in FHEM ist, mit meinen Settings. Wenn man jetzt 10 Sensoren einbindet, eventuell noch Batteriebetrieben und danach diverse Einstellungen tätigen muss, dann vergisst man schnell mal eines und wundert sich, warum ein Gerät nicht/anders funktioniert.

Das könntest du mAn. bereits jetzt relativ leicht umsetzen, indem du die betreffenden Konfigurationsbefehle in ein passendes attrTemplate "gießt"; außerdem gibt es mit "archetype" noch ein Modul, das hier ggf. hilfreich sein könnte (ich kenne nicht mehr als das Stichwort). Siehe auch die Antwort von Rudi.

Batteriebetriebene Geräte sind zum Konfigurieren nicht wirklich userfriendly. Wenn diese Settings aus diesen Template übernommen und nach dem Einbinden automatisch eingespielt werden, dann wären alle Sensoren automatisch mit den gleichen und vor allem meinen Settings konfiguriert.

"automatisch" macht attrTemplate nichts, man muß das als Anwender aktiv starten. Das ist mAn. auch an sich gut so, weil wir über Optionen sprechen und darüber, wie sich das Device dann in FHEM verhalten soll. Das ist nicht zwingend für alle User dasselbe. Automatisieren läßt sich aber das Setzen von default-Settings, und man könnte es sogar so gestalten, dass man diese defaults überschreibbar macht (damit geht aber uU. ein Teil des Vorteils verloren, denn dann kann man es auch gleich "von Hand" machen).

Im ZWave-Modul gibt es auch einen geraetespezifischen Abschnitt (%zwave_deviceSpecial) mit 4 Geraeten, am liebsten waere es mir, diesen auszulagern, entweder in die XML-Dateien, oder in den zukuenftigen AttrTemplate

Habe da kurz reingeschaut und sehe diesen Teil eher außerhalb attrTemplate (den Wunsch an sich kann ich aber nachvollziehen). attrTemplate sollte nach Möglichkeit für den User noch halbwegs transparent sein (@Rudi: schon gut, was bei MQTT teilweise passiert, ist auch nicht immer besonders "transparent"... Wenn es keine bessere Stelle gäbe (?): notfalls können wir diese hashes auch in einem speziellen Attribut unterbringen, wenn das (für die Zukunft bzw. eventuelle weitere ähnliche Gerätespezialitäten) was hilft).

Mit dem Wildwuchs an Geräten wird es  schwierig/unmöglich alle Geräte zu unterstützen, hier müsste ein generischer Ansatz gewählt werden, der von den XML Files die möglichen Settings übernimmt. Damit wäre die Wartung der XML-Files wichtig. Ein Update dieser XML-Files muss man auch berücksichtigen.

Kannst du das etwas genauer erklären?
Mein (vorläufiger) Gedanke wäre, tatsächlich eher in die Richtung zu gehen, dass es (mind) ein attrTemplate pro Hardware (-Variante) gibt. Entweder man hat Glück, dass das Device schon jemand hilfsbereits in der Hand hatte und es ein (ausgereiftes...) template dazu gibt, oder man muß eben mithelfen, dass eines entsteht. Dass ein template für mehrere Devices (von unterschiedlichen Herstellern) paßt, dürfte eher die Ausnahme sein, aber dafür kenne ich eventuell auch einfach noch zu wenige Varianten; es wäre aber kein Problem, beispielsweise die Detailsteuerung dann über eine automatisierte Modell-Abfrage (option:) zu machen. Tendenziell dürfte es dem Bauchgefühl nach eher ein "spezieller Wildwuchs" werden wie sowas wie eine Art Baukastensystem nach Art von mqtt2.template (abgesehen von "generischen Eigenschaften" wie etwa den genericDeviceType zu setzen u.Ä.).

aber trivial wäre so etwas nicht ... hilfreich jedenfalls.

Es ist vermutlich alles andere als trivial . Und wenn wir erst noch intensiver darüber nachdenken müssen, wo welches Bausteinchen eigentlich hingehört, wird es richtig schwierig .

Aber wenn ich die Reaktionen so richtig deute, scheint es Bedarf (und Raum) zu geben für Verbesserung im Zusammenspiel zwischen FHEM und ZWave .

es waere sinnvoll die XML-Dateien zu pruefen, evtl. kann man Arbeit sparen, wenn man dem ZWave Modul beibringt, mehr zu verstehen.

Bisher habe ich einen Bogen um die Details zu dieser XML-Geschichte gemacht. Gibt es irgendwo einen Schnellkurs dazu, um sich da aufzuschlauen?
Bzw. anders rum: was könnten wir ggf. beitragen, damit wir die Brücke ggf. von beiden Enden her anfangen zu bauen?

Mir ist bei ZWave-AttrTemplate noch nicht klar, was ich mir vorstellen darf: Schließt das neben gesetzten Attributen auch eine automatische Konfiguration der config-Werte ein? Bei letzterem müsste man bspw. beachten, dass sich die Klartext-config-Befehle bei Aktualisierungen der XMLs immmer ändern können -> also besser configByte, configWord,.. nutzen.

Wie geschrieben: mir ist auch noch nicht so richtig klar, wo die Möglichkeiten und Grenzen ggf. liegen. attrTemplate würde es im Extremfall ermöglichen, einen kompletten Einrichtungsassistenten pro Device zu basteln, da man sämtliche FHEM-Befehle nutzen kann und auch Perl-Code. Soweit würde ich allerdings ungern gehen wollen (falls jemand anders das in diese Richtung versuchen will: ich muß nicht unbedingt auch nicht den Maintainer dazu machen... Eigentlich wollte ich das auch eher anschieben und bei Gelegenheit dann jemanden versuchen zu überzeugen, dass er das besser kann als ich, spätestens, wenn mal die Wege und Möglichkeiten geklärt sind ).
Das mit configByte etc. ist ein wichtiger Hinweis, das wäre dann also was, wo ich mich dann auch erst in das Zusammenspiel dieser ganzen Dinge tiefer eindenken müßte.

[Sanchez]

Moin,

mal als unbedarfter User von FHEM, aber mit einem ganzen Fuhrpark von ZWave-Geräten (nahezu ausschließlich):

Wozu Templates?

Alle meine Geräte habe ich über die Standard-"Get"-Werte nach dem inkludieren erstmal gesetzt und dann nach meinen Wünschen angepasst. Das ist doch für jeden Haushalt individuell. Und die Standard-Werte sind ja schon in den Geräten enthalten.

Bei MQTT ist das für mich ja ne logische Sache (Bevor ich das alle eintippe und setzte). Aber bei ZWave ist doch das (Grund-)Gerüst für jedes Gerät und was es kann vorhanden...



Gruß

[Beta-User]

Wozu Templates?

Ich habe den Gedanken deswegen in den Raum gestellt, weil es bei meinem - noch sehr kleinen - Fuhrpark leider nur sehr bedingt plug&play war, und ich will auch nicht ausschließen, dass ein Teil der Problemchen ggf. selbstverschuldet waren, über die ich so nach und nach gestolpert bin...

attrTemplate _kann_ da helfen, wo man was spezielles braucht, und ich bin auch immer froh, wenn ich nichts spezielles brauche. Mal meine Bilanz - in Teilen allerdings nur aus dem Gedächtnis:
- FGS 222: unproblematisch;
- 4-Button-Taster (baugleich wie SCHWAIGER ZHS03): Unproblematisch, dauerte uU. etwas, bis von dem dann Events an den Controller gemeldet wurden;
- Heatit Z-Push Button 8: Unproblematisch, weiß nicht mehr, ob da was konfiguriert werden musste, damit Events kamen (enttäuschendes Teil, da nicht mehr Events möglich wie bei dem mit 4 Tasten, aber immerhin paßt der fast in einen 55-er Rahmen)
- FGR-223: Ziemlich eigenwillige Konfiguration erforderlich (?), um den als Jalousie-Aktor (venetian blind=mit Dreh-Lamellenverstellung) in FHEM zu betreiben: https://forum.fhem.de/index.php/topic,100390.0.html;
- FGR-222: Kaum besser, aber als Jalousie-Aktor noch mit der "Spezialität", dass sich auch der Grundlevel ändert, wenn man die Lamellen verdreht => das mag AutoShuttersControl gar nicht, also habe ich ein paar userReadings erfunden, damit das (halbwegs) geht;
Beide brauchen mMn. Zusatzcode, um eine vernünftige Steuerung in FHEMWEB-DeviceOverview zu ermöglichen (für den 223-er steht das bei mir, den 222-er werde ich da irgendwann vermutlich auch integrieren);
- AEON Labs ZW095 Home Energy Meter Gen5: Mußte erst mit den Optionen rumspielen, bis überhaupt Messwerte gesendet wurden, und weiß bis heute nicht, ob da nicht noch Verbesserungspotential ist;
- FGS 223: unproblematisch, allerdings stand leider nirgends besonders deutlich, dass das Teil nur in Ausgangsrichtung Verbräuche messen kann.

Ergo habe ich den Eindruck, dass man häufig erst mal den Dreh finden muß und ggf. auch erst intensiver recherchieren muß, bis man _vielleicht_ irgendwo rausfinden kann, ob denn ein Device jetzt eher unproblematisch ist bzw. wirklich für den beabsichtigten Zweck tauglich oder nicht. Ich hatte es mir aber relativ bewußt einfach mal "irgendwas" an - lt. verfügbarer Gerätebeschreibung an sich voraussichtlich brauchbaren - Geräten auch auf Risiko beschafft, und wollte damit auch sehen, ob ZWave denn an sich plug&play ist oder eben eher nicht.

Ggf. könnte attrTemplate bei den "unproblematischen" auch einfach nur dazu dienen zu signalisieren, was denn tatsächlich unproblematisch ist...

Wie gesagt: die Schwierigkeiten, dass jedes Gerät erst auf den speziellen Zweck hin konfiguriert werden muss (und z.B. passende Assoziationen hergestellt werden müssen) kann attrTemplate sowieso nicht oder nur sehr bedingt beseitigen.

Es ist aber für mich sehr ok, wenn wir am Ende ggf. feststellen, dass es keine hinreichende Antwort auf das "wozu" gibt und wir das ganze sein lassen!

[Beta-User]

Die von OpenZWave "ausgeborgenen" XML-Files haben eine vergleichbare Funktion,

Hast Du ein Beispiel? Mir ist nichts von "vergleichbare Funktion" bekannt.

Schließe mich der Frage an. Bin auch etwas ratlos und habe zumindest in der openzwave_deviceconfig.xml zu den bei mir "problematischen" Geräten nichts gefunden, was in Richtung einer irgendwie erweiterten Konfiguration ginge; das sah zumindest in meinen Augen so aus, als würde da alles irgendwie verarbeitet, was da in der xml steht.

[rudolfkoenig]

Dann rudere ich halt zurueck
Hab mich wohl falsch erinnert, und es nicht kontrolliert.

[Beta-User]

War wirklich als Frage gedacht, kommt ja immer mal wieder vor, dass ich irgendwas wichtiges übersehe...

Mal schauen, vielleicht liefere ich mal bei Gelegenheit einen attrTemplate-Vorschlag für den/die Fibaro-Shutter-Dinger und anderes, dann ist es ggf. einfacher zu entscheiden, ob das wirklich hilfreich sein kann und dann ausgeweitet werden soll oder eben eher ein Rohrkrepierer wird.

An sich komme ich aber immer mehr zu dem Schluß, dass es vermutlich schon die passende Ebene wäre: Als Angebot, das man das an sich schon funktionale Device weiter konfiguriert bekommt mit Einstellungen/Vorgaben/Attributen, die jemand in FHEM schon mal ausgetestet hat und die ggf. auch zueinander passen (und Infos/Links, wo das weitere Umfeld dann ggf. zu finden ist).
Wie z.B. bei MQTT2_DEVICE auch kann man das Angebot annehmen, das nur als "Inspirationsquelle" ansehen oder das feature global komplett abschalten, wenn man es nicht hilfreich findet. Es ist eben "anders", weil man - anders als bei MQTT - in der Regel schon irgendwie funktionale Devices hat...

[Klaus.A]

Templates für ZWave ... mein erster Gedanke war: Warum, macht doch keinen Sinn?

Dann, nach etwas Überlegung: "Ja, bitte, wäre sehr hilfreich".

Warum?

Ich bin ausgehend von HomeMatic über einige Jahre mehr bei ZWave gelandet. Grund: In FHEM ist es als Hersteller-neutraler Standard nutzbar (abgesehen von der restriktiven Politik der Hersteller was die Bereitstellung von Firmware-Update-Files betrifft). ZWave ist für mich erste Wahl (neben HomeMatic). Ganz anders als HomeMatic IP, das ich als konzeptionellen Pfusch sehe: Nur ein I/O, kein richtiges Mesh-Netzwerk, nur Steckdosenschalter als Repeater - das funktioniert für mein Haus und Garten in keiner Weise.

Zurück zum Thema: Was immer wieder aufwendig ist das sind Einstellungen für mehrere gleichartige Geräte. Beispiel Bewegungsmelder. Ich möchte hier bestimmte eigene Einstellungen als Standard nutzen (Zeitfaktoren, Reaktion, Antworten). Das bedeutet aber bei mehr als 10 Meldern entweder alle einzeln einstellen oder ein eigenes Skript bauen. Da wären Templates als "Angebot für individuelle Einstellungen für mehrere Geräte" sehr hilfreich.

Das gilt auch z.B. für Rauchwarnmelder und deren Assoziationen. Das einmal zu regeln und dann für die individuelle Installation einstellen sorgt mit einem mal für Konsistenz.

Schön wäre es auch, bestimmte Readings optional zu löschen (Beispiel sind die "UNPARSED" Meldungen, "SEND_DATA", "CMD" ...) die immer wieder aufteten, keine Fehler sind sondern einfach das Ergebnis von Funkverkehr, der gelegentlich falsch interpretiert sein kann (Bitfehler in der Übertragung).

Soviel meine "2 Cents".

Gruß, Klaus

[Beta-User]

So.

Es gibt seit eben im svn zwei erste Dateien zum Thema:
Zum einen eine zwave.template, bei der aber eigentlich nur eineinhalb Dinge bisher funktionieren, nämlich die Konfiguration von einem Fibaro FGRM222 als Venetian Shutter und der download entsprechenden myUtils-Codes, der dazu ein wenig devStateIcon "kann" -  mit einem "aktiven" Icon für die Lamellenstellung...

Was auch geht, ist die Konfigurationsbefehle für den normalen Shutter-Modus abzusetzen, allerdings gibt es dann keine anderen devStateIcon-Angaben.

Das ist jetzt erst mal eher als Demo der Optionen gedacht und nicht wirklich "fertig" (der devStateIcon-Code könnte z.B. noch Aktivität anzeigen, wenn die Jalousie läuft und dann als Befehl ein "stop" abgeben, so dass der betreffende Taster in webCmd  auch überflüssig wird, und die Konfigurationsbefehle sind noch "Klartext" und nicht configWord usw., da muß ich mich dann auch erst einlesen...), es ging erst mal nur darum, das Prinzip zu zeigen, das ich für zielführend halte:

Eine Liste mit den ganzen Geräten. Man wählt sein Gerät und hat dann die Möglichkeit, das betreffende Gerät zweckentsprechend fertig zu konfigurieren. (Leider klappt wg. des downloads der myUtils-file das farewell nicht, aber damit wollte ich mich erst mal nicht aufhalten; ggf. muß man das einfach manuell machen lassen?)

Den FGRM222 habe ich hauptsächlich aus zwei Gründen gewählt: zum einen dürfte der relativ verbreitet sein, so dass ihr ggf. die Möglichkeit habt, diese Art des template-Codings am eigenen Device nachzuvollziehen, und zum anderen hat er nur das Hauptdevice, auf das sich alle Konfiguration bezieht...

Die nächste Hürde, die m.E. zu nehmen sein wird: Mehrkanalige. Da ist das Problem, dass das m.E. am besten so gemacht werden sollte, dass es egal ist, ob der User das Haupt-Device auswählt oder einen der Kanäle, das template muß irgendwie erkennen können, was das Hauptdevice ist und was welcher Sub-Kanal. Z.B. hat der FGS-223 das Power-Reading (Jalousie läuft, zumindest bei mir) im ersten Kanal, daher ist das bei diesem Typ das Device, der bei mir im betreffenden Raum angezeigt wird (der devStateIcon-Code kennt den auch ). Muß mal im Modulcode nachsehen, ob es da schon was passendes zur Identifizierung der Teildevices gibt, ansonsten war bei den ersten Versuchen der Eindruck, dass das vermutlich in eine passende Funktion ausgelagert werden sollte. Also falls dazu jemand einen Hinweis auf Modulcode oder eine andere schnelle Lösung hat: her damit...

Anbei noch ein Bildchen, was das template mit einer meiner Jalousien anstellt.

Bin mal gespannt auf eure Rückmeldungen, ob das auch aus eurer Sicht in die richtige Richtung geht?

Grüße, Beta-User

[krikan]

Erst einmal vielen Dank für Deine Arbeit.

Komplett getestet habe ich nur das "Einfachste": Löschen der Readings. Funktioniert; man könnte ggfs. noch UNKNOWN aufnehmen. Dieses Template sehe ich insgesamt kritisch. Wer die Bedeutung der Readings kennt und weiß, wann man die löschen kann, braucht das Template mMn nicht. Wer die Bedeutung nicht kennt, sollte besser nicht löschen, wenn er hier im Forum fragen stellt. Man hat aufgrund des Auftauchens der Readings in der list-Ausgabe Indizien für eventuelle Probleme/Lösungshinweise. Der Menübefehl fordert aber geradezu zum Klicken heraus. Frage mich auch, warum diese Readings in der Detailansicht überhaupt stören. Nutzt irgendwer die Detailsansicht als Frontendseite zum Bedienen und nicht nur als Konfigurationsseite für den Admin?

Das FGRM222-Template und den Code habe ich mir nur angeschaut, da ich bei Anwendung meine config der Aktoren zerschieße. Man bekommt beim Durchschauen Anregungen wie man Dinge (auch für andere Aktoren) umsetzen kann.

Gruß, Christian