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
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
Ich bin auch sehr dafür :)
Ronny
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 :)
ZitatEtwas 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.
Zitat von: rudolfkoenig am 07 September 2020, 12:54:53
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.
ZitatIm 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
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.
Zitat von: rudolfkoenig am 07 September 2020, 12:54:53
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
Zitat von: tux75at am 07 September 2020, 12:12:37
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.
ZitatEtwas 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.
Zitat
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).
Zitat von: rudolfkoenig am 07 September 2020, 12:54:53
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).
ZitatMit 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.Ä.).
Zitataber trivial wäre so etwas nicht ... hilfreich jedenfalls.
Es ist vermutlich alles andere als trivial ;D . 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 :) .
Zitat von: rudolfkoenig am 07 September 2020, 12:54:53
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?
Zitat von: krikan am 07 September 2020, 13:50:45
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.
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...
:o
Gruß
Zitat von: Sanchez am 07 September 2020, 14:31:02
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 (https://forum.fhem.de/index.php/topic,112682.0.html), 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!
Zitat von: rudolfkoenig am 07 September 2020, 12:54:53
Die von OpenZWave "ausgeborgenen" XML-Files haben eine vergleichbare Funktion,
Zitat von: krikan am 07 September 2020, 13:50:45
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.
Dann rudere ich halt zurueck :)
Hab mich wohl falsch erinnert, und es nicht kontrolliert.
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...
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
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
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
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
ZitatEvtl. 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.
ZitatDu 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. :)
ZitatImmerhin 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
ZitatImmerhin 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.
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).
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 :) .
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 (https://forum.fhem.de/index.php/topic,100390.msg950248.html#msg950248) 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 (https://forum.fhem.de/index.php/topic,112682.0.html) angefangen (ist aber noch ungetestet!),
- zu guter Letzt ist das eine oder andere an Hinweisen und Links eingearbeitet (z.B. auch zum AEON Multisensor (https://forum.fhem.de/index.php/topic,114538.0.html)).
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 :P .
So, habe erst mal soweit fertig...
Für den ZW100 (https://forum.fhem.de/index.php/topic,114538.0.html) 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:
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.
ZitatEvtl. 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.
Zitat von: rudolfkoenig am 06 Oktober 2020, 17:39:16
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...
Sieht soweit ganz nett aus, bitte - wer heute testen/nachsehen will, wie das jetzt ausschaut - nach einem update auch noch
{ 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... :P