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

[Beta-User]

Danke erst mal für's Drübersehen!

Die Skepsis mit dem Löschen kann ich nachvollziehen, ging mir (allerdings erst mal aus anderen Gründen) ähnlich, andererseits: Evtl. könnte man über den Text in desc: uU. direkt auch auf entsprechende Abschnitte im Wiki/Forenthreads/... verweisen, über die der geneigte User dann näheres über die Bedeutung der Readings erfahren kann (ich habe die z.T. auch, mich aber bisher nicht intensiver damit beschäftigt, die Readings sind teilweise auch älter und es sieht so aus, als würde das ansonsten bisher soweit laufen...)?

Der Gedanke "attrTemplate" als Anregung war und ist auch z.B. bei MQTT2 oder HTTPMOD eine Teilmotivation gewesen, von daher ist das an der Stelle ggf. schon "Ziel erreicht". Andererseits ist es so, dass z.B. AutoShuttersControl bestimmte "Vorstellungen" davon hat, was ein Rollladenaktor an Vorgaben einhalten muß, damit das reibungslos funktioniert. Wenn wir sowas "nebenbei" als Quasistandard vorgeben, vermeiden wir damit uU. den einen oder anderen Frustmoment bei Leuten, die erst jetzt in das Thema einsteigen und sich sonst erst mal alles irgendwo zusammensuchen müssen.
Von daher sollte das ganze eben auch dazu dienen, "best practice" zu teilen (wobei ich nicht behaupten will, dass mein Code schon der Weisheit letzter Schluss ist... Z.B. den devStateIcon-Code sollte man dann ggf. zu einer einfachen dispatch-Anlaufstelle umbauen, damit er auch auf Modelle anderer Herseller paßt; dass dann intern eine ganze Menge weiterer Funktionsaufrufe realisiert werden müssen, war einer der Gründe, warum ich das ganze als package vercoded habe...). @krikan: Du kannst auch gerne "deine" aktuelle Konfiguration für den 222-er-Rollladen-(oder Gate-) Modus als Beispiel zur Verfügung stellen, dann kannst du zwar die aktuelle Config mit dem template zerschießen, aber eben auch wiederherstellen...
(Immerhin zeigt die Rückmeldung, dass die Struktur des attrTemplate "lesbar" ist; da würde mich interessieren, ob das allgemein so empfunden wird oder das ganze zu kryptisch ist bzw. wo ggf. Erklärungen erforderlich wären. Dann bessere ich ggf. https://wiki.fhem.de/wiki/AttrTemplate entsprechend nach).

Zum weiteren Vorgehen: wäre es zielführend, wenn man für jede Hardware einen Thread (oder bei unterschiedlicher Nutzung auch mehrere) hätte, um sich dann dort über die spezifischen Fragen auszutauschen? Darauf könnte man dann verlinken und hätte so auch einen "Info-Highway", über den der interessierte Anwender dann ggf. erfahren könnte, warum etwas so oder so durch das template vorgeschlagen wird...?

Das mit devStateIcon und den passenden Einstellugen für webCmd ist auch der Versuch, den Aktor via Device Overview komplett (vereinfacht) bedienbar zu machen, damit man eben nicht auf die "Admin"-Seite muß. Grade bei dem 223-er-Jalousie-Betrieb ist das eben "etwas tricky"...

Was das Identifizieren vom Hauptkanal und den Channel-Devices angeht, sollte das über die hexId gehen, da bin ich also zumindest gedanklich schon einen halben Schritt weiter. Problematisch ist aber ggf., dass man den Code m.E. zwingend abbrechen muss, wenn die Internals nicht vorhanden sind (muß mal checken, ob das nur ein theoretisches Problem ist, denke aber, dass das passieren kann, wenn ein Aktor nach FHEM-Start nicht erreichbar ist bzw. bei Batteriebetrieb: das Gerät sich das erste Mal wieder gemeldet hat? Wie angedeutet: ich bin noch nicht soooo tief in der ZWave-Materie drin, um wirklich ein Gesamtbild zeichnen zu können, wie das ganze denn Sinn macht oder eben auch nicht und wo ggf. die Probleme liegen...).

Grüße, Beta-User

[krikan]

Evtl. könnte man über den Text in desc: uU. direkt auch auf entsprechende Abschnitte im Wiki/Forenthreads/... verweisen, über die der geneigte User dann näheres über die Bedeutung der Readings erfahren kann

Ja.

Du kannst auch gerne "deine" aktuelle Konfiguration für den 222-er-Rollladen-(oder Gate-) Modus als Beispiel zur Verfügung stellen, dann kannst du zwar die aktuelle Config mit dem template zerschießen, aber eben auch wiederherstellen...

Da ich Anhänger von Steuerung im Hintergrund bin, gibt es hier kein schönes gepflegtes Frontend mit devStateIcon usw. Die Steuerung erfolgt über "oldschool"  at, notify, SUNRISE_EL verknüpft über ein wenig Perl-Code in myUtils. Templatefähig wären damit mMn nur das Setzen der config-Werte. Das bewerkstellige ich bisher einfach mit ein wenig copy/paste. Ich sehe mich nicht als geeigneten Kandidaten für die Nutzung von (ZWave-)Templates und das schließt auch die Lieferung von Vorlagen ein. 

Immerhin zeigt die Rückmeldung, dass die Struktur des attrTemplate "lesbar" ist; da würde mich interessieren, ob das allgemein so empfunden wird oder das ganze zu kryptisch ist bzw. wo ggf. Erklärungen erforderlich wären.

Die Meinung von anderen würde mich auch interessieren...

Gruß, Christian

[rudolfkoenig]

Immerhin zeigt die Rückmeldung, dass die Struktur des attrTemplate "lesbar" ist; da würde mich interessieren, ob das allgemein so empfunden wird oder das ganze zu kryptisch ist bzw. wo ggf. Erklärungen erforderlich wären.

Ich fuerchte wir vermischen hier zwei Aufgaben: das Template soll einerseits irgendetwas bewerkstelligen, andererseits soll die Anzeige des Template-Inhalts als Hilfestellung / Inspiration fuer den Benutzer dienen. Wenn man beim Bewerkstelligen Sonderfaelle abdeckt (Speech-Recognition, "komische" Readings loeschen, etc), oder Code zusammenfuehrt, um mehrere Faelle gemeinsam abzudecken (mit Lamelle drehen oder ohne), dann ist er schlecht geeignet als Unterrichtsmaterial fuer Anfaenger, da es unvermeidlich kompliziert wird.

Die richtige Loesung kenne ich nicht, ich persoenlich tendiere zu lieber einfach als perfekt.

[Beta-User]

Dass das ein ziemlich spezieller "Hybrid" aus vielen Teilelementen ist, ist klar.

Hauptziel aus meiner Sicht wäre, sowas wie einen (sinnvollen) Quasistandard für bestimmte Dinge zu setzen. Das ganze eher als Angebot an User mit mäßiger Erfahrung. Von daher sollten häufige Sonderfälle wie Sprachsteuerung mit abgedeckt werden, was eine gewisse Komplexität unvermeidlich macht und auch das Setzen von Attributen, die ggf. von einem nicht unwesentlichen Teil der User als verzichtbar angesehen werden (wie das Sprachsteuerungsthema oder icon/devStateIcon etc.).

Du, Rudi, hast aber vermutlich recht, damit dass einfacher lesbar ist, wenn man z.B. je ein eigenes attrTemplate für jeden Einsatzzweck des FGRM222 bereitstellt, da bin ich mit dem showcase-Denken wohl zu weit gegangen.

Das mit der "Inspiration" oder gar dem "Unterrichtsmaterial" würde ich weniger im Vordergrund sehen, das ganze sollte (bzw. muss) halt mind. so verständlich sein, dass möglichst viele User in der Lage sind, für ihre Devices was verwertbares zu liefern oder auch Verbesserungsvorschläge zu machen. Testen kann man das als Maintainer kaum, sobald irgendeine Interaktion mit der Hardware erfolgen soll oder muss. Eine gewisse Erfahrung mit der "Sprache" setzt das dann auf Seiten der mitwirkenden User schon voraus, die Frage ist eher, wie hoch die Hürde ist (das drumrum wie Sprachsteuerung etc. ist erfahrungsgemäß weniger das Problem).

[Beta-User]

Zwischenzeitlich gibt es für den FGRM222 drei attrTemplate, das "alte" Einheitstemplate und je eines für den Rollladen- und den Jalousie-Lamellen-Modus, damit das ganze etwas transparenter wird.
Der myUtils-Code ist jetzt als separater Download "vertemplatet", weil sonst das farewell "kaputt" ist, und das Package heißt jetzt so wie die Datei (das scheint allgemeine Konvention zu sein?).

Weiter "erkennt" das devStateIcon jetzt, wenn der Motor an ist und bietet dann statt der - sowieso falschen - aktuellen Positionsangabe über die Zahnräder das "stop"-Kommando an (das separate Icon ist entfallen). An sich könnte man den Code ohne weiteres ausbauen, dass er auch für den Rollladenmodus tauglich wäre, die Jalousie-Variante könnte man dann z.B. auch über ein zusätzliches Argument auswählbar machen.

Zwischenzeitlich habe ich auch den "Beipackzettel" zum FGRM222 etwas intensiver studiert und stelle mit einer gewissen Verwunderung fest, dass man sehr wohl Infos über Tastendrücke bekommen _kann_ (da hatte sich bei mir aus den Diskussionen rund um AutoShuttersControl im Hinterkopf festgesetzt, dass man lokale Schaltungen bei den Dingern nicht von vom Controller ausgelösten Kommandos unterscheiden könnte...)!
Super Sache, da man nicht nur den "einfachen Tastendruck" gemeldet bekommt, sondern auch Doppel- oder Trippel-Ereignisse (und die "long"-Events) - man kann die also im besten Sinn auch gleich als Scene-Controller verwenden!!!
Das ist imo ein "Killer-feature", mit dem die ZWave-Fibaro-Aktoren dann endgültig die Homematic-Dinger hinter sich lassen . (Werde mich jetzt dann auch mal etwas intensiver mit Lightscene auseinandersetzen).

Würde also - bezogen auf das template-Thema - dazu neigen, gleich abzufragen, ob der User die Tastendrücke haben will. Hat allerdings wieder im Dauerbetrieb etwas mehr Funkverkehr zur Folge, was mich an der Stelle etwas zögern läßt. (berechtigt?)

Das mal als kurze Zwischeninfo zu diesem Thema .

[Beta-User]

So, nächste Iteration ist im svn:

- Das shutter-devStateIcon ist jetzt sowohl für die Jalousie- wie Rollladen-Variante nutzbar, der Jalousiemodus geht über eine entsprechenden Parameter. Theoretisch sollte man das jetzt für anderere Typen relativ problemlos ausbauen können, denn

- der myUtils-Code enthält eine Routine, mit der die einzelnen Subdevices eindeutig bestimmt werden können (hoffe ich jedenfalls). Damit war es dann auch möglich, den

- FGR223 als template aufzunehmen.
Da ist jetzt das feature "sende (alle) Tastendrücke" standardmäßig aktiviert, das könnte man aber auch über eine Abfrage realisieren, das wäre nur ggf. fehleranfälliger wie z.B. eine "radio option" (was beim FGRM222 eine elegante Lösung wäre?).
Was ggf. noch fehlt, wäre die Assoziationen vorab richtig zu setzen. Bin noch nicht schlüssig, ob das aus diesem Thread der Weisheit letzter Schluss ist...
Jedenfalls zeigt dieses template am Ende auch einen

-dynamischen Raum an, in dem sich dann alle 3 zugehörigen Devices finden.
Das Problem dabei ist "nur", dass ggf. nicht das Browserfenster adressiert wird, in dem man grade gestartet ist, sondern ggf. eben ein zweites, so es offen ist. Da habe ich noch keine Idee, wie man das besser hinbekommt.
An sich wäre das auch ein tolles feature für die mehrkanaligen MQTT2_DEVICEs, aber wenn das "seltsame" Ergebnisse zeitigt, ist es eben nicht optimal.
Es gibt dazu auch ein "showcase"-Template, das nur diese Raumanzeige macht.

- Weiter habe ist mal der AEON Labs ZW095 angefangen (ist aber noch ungetestet!),

- zu guter Letzt ist das eine oder andere an Hinweisen und Links eingearbeitet (z.B. auch zum AEON Multisensor).

Mag mal jemand was dazu sagen, wie das "Empfinden" zum Thema Tastendrücke ist, und natürlich zu der Übung hier als solcher? Wenn es ingesamt die falsche Richtung ist, können wir das Experiment auch gerne abbrechen .

[Beta-User]

So, habe erst mal soweit fertig...

Für den ZW100 stehen jetzt auch im svn zwei Templates zur Verfügung (Batterie- und USB-Variante), die Links sollten jetzt auch alle funktional sein und die FGRM222-Geschichte habe ich zwischenzeitlich auch selbst genutzt. (Verschönern könnte man das ggf. noch, z.B. mit stateFormat, aber vorrangig ging's mir mal um die Richtung an sich.)

Was noch suboptimal ist:
Die "Klartextbefehle" sind nicht xml-änderungsfest. Daher wäre es besser, die in configByte/Long/Word zu schreiben. Das Problem dabei (außer, dass ich da auch erst am Einarbeiten bin, wann man was braucht): Es ist schlecht lesbar. Wenn man das Toolset also auch zur Verbreitung von Ideen nutzen will, ist es m.E. zu kryptisch, die sind nicht eben einsteigerfreundlich. Leider kann man nicht einfach den Rest der Zeile als Kommentar verwenden, sonst meckert FHEM ggf. über "too many arguments", und einen gangbaren workaround habe ich dazu auf die Schnelle auch nicht gefunden.

@Rudi:
Evtl. wäre es eine recht einfach zu realisierende Möglichkeit, solche Kommentare in FHEMWEB noch anzuzeigen und dann bei der Ausführung der Zeile z.B. alles wegzuschneiden, was mit zwei ## beginnt (eines dürfte zu wenig sein wg. Farbangaben in devStateIcon usw.)?
Beispiel:

Code Auswählen Erweitern

set DEVICE configByte 40 1 ##configReportOnlyOnThresholds Enabled

Ist sicher nicht das wichtigste Thema auf der Welt und es macht auch nur dann Sinn, wenn das ganze Toolset an sich für ZWave überhaupt weiterentwickelt werden soll. Ich habe dazu noch keine abschließende Meinung, denke aber, dass es helfen würde, die Einstiegshürden in ZWave@FHEM deutlich zu senken.

[rudolfkoenig]

Evtl. wäre es eine recht einfach zu realisierende Möglichkeit, solche Kommentare in FHEMWEB noch anzuzeigen und dann bei der Ausführung der Zeile z.B. alles wegzuschneiden, was mit zwei ## beginnt (eines dürfte zu wenig sein wg. Farbangaben in devStateIcon usw.)?

Einfach zu realisieren, ja, ich habe nur Angst von den Folgen, bzw. Auswuechsen.
Ich habe es aber eingebaut, nor risk, no fun.

[Beta-User]

Einfach zu realisieren, ja, ich habe nur Angst von den Folgen, bzw. Auswuechsen.
Ich habe es aber eingebaut, nor risk, no fun.

...ich versuche mal brav zu bleiben und das v.a. nicht in setList/readingList@mqtt2.template zu verwursten...

Ansonsten Danke!
Die schnelle Umsetzung klingt ein wenig danach, als wäre attrTemplate@ZWave deiner Meinung nach förderungswürdig.
Bin mal gespannt, was dann ab jetzt so an Fragen, Vorschlägen, ... kommt, mit den Devices, die hier so rumfliegen bin ich jedenfalls ziemlich "durch", ab jetzt wäre ich - abgesehen von den Aufräumarbeiten, vor allem im Gefolge dieses neuen features - auf Zuarbeit angewiesen...

[Beta-User]

Sieht soweit ganz nett aus, bitte - wer heute testen/nachsehen will, wie das jetzt ausschaut - nach einem update auch noch

Code Auswählen Erweitern

{ Svn_GetFile("FHEM/lib/AttrTemplate/zwave.template", "FHEM/lib/AttrTemplate/zwave.template", sub(){ AttrTemplate_Initialize() }) }
ausführen. Leider war die Zeit vor dem regulären update-Lauf nicht ganz ausreichend, (fast) alles auf configByte&Co unzustellen.

Vorläufig würde ich mal davon ausgehen, dass die letzte verbliebene Baustelle noch die Frage der sinnvollen Assoziierungen beim FGR-223 ist. Schaue ich mir bei Gelegenheit nochmal an, falls sich nicht vorher jemand anderes findet, der sich damit auseinandersetzen kann, will oder muss...