[HMdeviceTools.js (hm.js)] WebUI zur Register-Konfiguration/Templatehandling

[frank]

die aktuelle version von HMdeviceTools.js ist nun bei github zu finden.
durch einbundung des thirdparty-repository kann ein update nun über das "normale" fhem update bezogen werden.
siehe hinweise unter "Vorbereitungen" punkt 0.1.


das alt bekannte, aber leider wenig beachtete interface von @papa, zum einfachen konfigurieren der homematic-geräte-register, hat nun eine erweiterung bekommen. mit ein paar clicks kann man sich jetzt ein template erstellen und dieses den devices zuweisen. vielleicht schaffen es die ebenfalls zu unrecht unbeachteten templates von @martinp876 hiermit mal den durchbruch.

ich mach mal extra keine lange anleitung, um zu sehen, ob das handling des dynamischen interfaces intuitiv genug ist.


kurzanleitung:

Vorbereitungen:

0.1. automatischen download über den fhem update mechanismus einrichten. ein paar beispiele für den fhem update cmd sind in diesem post zu finden: https://forum.fhem.de/index.php/topic,112825.msg1197938.html#msg1197938

Code Auswählen Erweitern

update add https://raw.githubusercontent.com/frank962/fhem/main/autoupdate/controls_HMtools.txt
- die installierte version von HMdeviceTools.js kann über den fhem cmd "version" angezeigt werden

0.2. beim FHEMWEB device das neue file HMdeviceTools.js zusätzlich eintragen (leerzeichen getrennte liste):

Code Auswählen Erweitern

attr <myFHEMWEB> JavaScripts pgm2/HMdeviceTools.js
HMdeviceTools sollte nun nach dem aufrufen einer detailseite eines homematic devices über den internals sichtbar sein.

0.3. hminfo definieren sollte pflicht sein. ohne hminfo funktioniert nur der bisherige register editor (expert mode).

Code Auswählen Erweitern

define hminfo HMinfo
mit der zusätzlichen installation von HMinfoTools.js werden auch diverse status icons angezeigt.
https://forum.fhem.de/index.php/topic,112825.0.html

0.4 wichtig: damit keine neuen templates nach fhem restart verloren gehen, unbedingt die hinweise zur vorbereitung im wiki beachten (link beim fragezeichen). es muss natürlich auch eine config datei vorhanden sein, damit es nicht ständige meldungen in fhem.log gibt, da keine datei gefunden wird.

Code Auswählen Erweitern

attr hminfo autoLoadArchive 1_load
attr hminfo autoArchive 1


Anleitung:

1. wenn bereits ein zugewiesenes ("Set") template existiert, wird dieses beim start des interface automatisch selektiert. ansonsten wird mit dem expertmode eröffnet. über das obere "menü"-dropdown kann man zu jeder zeit die bearbeitungsebene wechseln. in der dropdown-liste sind alle augenblicklich verfügbaren templates zu sehen (grün:assigned, gelb:extern assigned, weiss: ungenutzt)

2.1. template erstellen (new template...) und definieren mit dem befehl "Define".
mit "Show" kann man eine "trockenübung" ausführen; der erzeugte define-befehl erscheint ganz unten im weissen define-output. auch zum tauschen mit anderen usern gedacht. farbcode beim auswählen der register => grün:register mit festem, entsprechend eingestelltem wert. gelb: register mit exklusivem parameter (single par). orange: mehrere register teilen sich ein parameter (multi par). weiss: register bleibt unbenutzt (off).

martin hat bereits einige templates erstellt, die automatisch zur verfügung stehen.

2.2. template zuweisen und ggf neue registerwerte setzen mit "Set"
nach erfolgreichem define wird das neue template automatisch selektiert (farbcode weiss). nun muss es nur noch zugewiesen werden. wenn durch das template keine registerwerte zu verändern sind, verändert sich nur der farbcode (grün) im dropdown. müssen durch die zuweisung registerwerte im device neu gesetzt werden, wird das popup geschlossen, da man nun erst einmal das setzen der neuen werte verifizieren sollte.

2.3 template zuweisung aufheben mit "Unassign".
farbe wechselt von grün auf weiss (ungenutzt) oder gelb (von anderem device/peer extern genutzt)

2.4 kombinierter befehl "Use" ("Set"/"Unassign") und hilfsbefehle "Use All" und "Use None"
wenn in der templateansicht die templatedetails "global usage" oder "all details" ausgewählt sind, erfolgt das zuweisen und abwählen des templates über den befehl "Use". in diesen detailansichten erscheint jeweils eine tabelle (link-tabelle) mit allen möglichen device/peer kombinationen, die das aktuell selektierte template nutzen können. bei der tabellenerstellung werden auch die aktuell genutzen "links" mit den aktuell verwendeten parameterwerten gesetzt, so dass man eine aktuelle übersicht über die "globale" nutzung dieses templates hat.
über die checkbox kann man das template entweder zuweisen oder eine zuweisung aufheben. ebenso lassen sich eventuelle parameter für jeden link setzen. sobald eine veränderung an der tabelle vorgenommen wird, die eine änderung der nutzung des templates zur folge hätte, erscheint der "Use" befehl und der name des jeweiligen links ändert die farbe. man "klickt" sich also zunächst die gewünschte nutzung des templates für alle links zusammen und muss am ende nur einmal "Use" benutzen, um sämtliche template zuweisungen und parameter änderungen in einem "rutsch" zu erledigen.
wird das template für einen link aktuell noch nicht genutzt, zeigen parameter inputs zu diesem link zunächst noch keine werte an. wird nun dieser link über die checkbox erstmalig ausgewählt, erfolgt ein request an das device, um die aktuellen registerwerte, die mit den parameterwerten korrespondieren, zu ermitteln. bei erfolg werden diese werte dann entsprechend eingestellt.
mit den hilfsfunktionen "Use All" und "Use None" kann man alle links auswählen oder abwählen.

2.5 template endgültig löschen mit "Delete".
ein template kann nur gelöscht werden, wenn es in keinem device genutzt wird (weiss).
generische templates, an der endung "_short" oder "_long" erkennbar, können nur gelöscht werden, wenn beide templates ungenutzt sind.


im günstigsten fall ein default template selektieren, eventuelle parameter ggf noch anpassen und mit einem click zuweisen (set).
und schon fertig. 

[frank]

hallo martin,

falls du neben hmccu noch lust auf coding hast, hätte ich noch ein paar wünsche. am besten natürlich über hminfo.
sollte hmccu die selbe schnittstelle (daten/befehle) zur verfügung stellen, wäre eine gemeinsame nutzung des interface besonders einfach. 



1. eine liste der fest eingebauten default templates.

die fest eingebauten templates kann man ja weder löschen noch editieren.
um das im interface zu unterbinden, könnte ich eine entsprechende liste gebrauchen.
am perfektesten für mich wäre eine kombination aus folgenden listen erweitert mit der angabe, ob es sich um ein default template handelt.

a. available templates für eine device:peer kombination, die im befehl "set <device> tplSet_<peer> <template>" zu finden ist.
b. zu jedem dieser templates die infos, die über "set hminfo templateUsgG sortTemplate" zu bekommen sind. wenn ein available template zusätzlich in anderen device:peer kombinationen assigned/benutzt wird, für jede weitere nutzung dieses templates eine zusätzliche zeile. so wie bei templateUsgG, wenn mehrfachnutzungen existieren.
c. in der 1.spalte mit dem templatenamen eine zusätzliche kennzeichnung für ein default template.


2. ein defmod befehl zum editieren existierender templates.

als workaround habe ich zur zeit nur einen komplexen ablauf im kopf.
a. alle template zuweisungen ermitteln, merken und lösen,
b. altes template löschen,
c. editiertes template definieren,
d. neues template wieder allen devices wie unter a. zuweisen.

eventuell hast du eine einfachere möglichkeit auf lager.


3. ein befehl zum übermitteln der "echten" definition eines templates

zum parsen/einlesen eines existierenden templates nutze ich "set hminfo templateList <template>".
auf diese weise wird der vorgang allerdings unnötig "sensibel/fragile", da die eigentliche definition des templates auf dem weg von hminfo zum interface mindestens über eine zusätzliche transformation (templateList) erfolgt.

[martinp876]

Hallo Frank,

Die Erweiterung von papa habe ich noch nicht gesehen - muss ich gleich einmal probieren. Wo finde ich die aktuelle Version von hm.js?

Zu den default templates: Diese sollte man schon editieren und löschen können (muss ich noch einmal prüfen...
Diese haben ich vor langer zeit gemacht. Ich nutze eine Reiha anderer Templates. Ich würde gerne eine Reihe von templates zu Verfügung stellen. Vor ab wäre ein Austausch sinnvoll, wie der "Mainstream" es haben will.
Mittlerweile ist das "Anwenden" von Templates ohne Zusätze (hm.js) möglich. Es muss nur definiert sein.
Zum Hintergrund: Template-definitionen und template-assignments werden im File "regConfig.cfg" gespeichert (hmInfo ist der "Verwalter") Beim normalen Save wird dies auch gespeichet. Man sollte es dann auch wieder laden. Hierzu

Code Auswählen Erweitern

attr hm autoLoadArchive 1
attr hm autoArchive 1

setzen.
In jeden Device, welches das Template nutzen "könnte" (da die Register vorhanden sind) erscheinen die Komamndos

Code Auswählen Erweitern

tplSet_<peer> [liste der möglichen templates]
also ein "click-only" kommando, nix tippen.
Ebenso ein Kommando die Templates zu löschen
Und weiter ein Kommando, die Parameter des Templates zu setzen (m.E. ein muss!)

Einzig das Erstellen ist gewöhnungsbedürftig. Aber mit dem Template-editor (in Wiki beschrieben) kann man dies auch "zusammenclicken". Hier habe ich auf eine js unterstützung gehofft, dann habe ich es eben ohne gemacht.

Zu deinen Ideen:
Die Templates würde ich in der Tat gerne übernehmen - von der Semantik und Syntax zu mindest. Aber noch fehlen mit bei HMCCU die Grundlagen. Einiges ist schon gut, anderes verstehe ich nicht und einigen werde ich nicht (zumindest für mich) modifizieren. Noch weiss ich nicht so recht, welche Richtung Dirk gehen will.

zu 1.
Löschen und editieren geht schon. Allerdings muss man das File regConfig.cfg über hmInfo nutzen und einlesen (loadConfig oder autoLoadArchive).
Die aktuelle Liste war eine Idee vor jahren. Ich würde sehr! gerne eine Liste von Templates bereitstellen, welche die Notwendigkeiten der Anwender  abblildet.
Eine (Um-)Frageliste am Ende.

zu 1 a) Im Kommando tplSet_<peer> gibt es schon eine drop-down list von templates. Diese reicht nicht? tplSet kommt im getcmdList nicht vor. also ein neues get kommando?
zu 1 b) Ein Template kann bei einem Kanal immer für alle seiner Peers genutzt werden. Es gibt auch templates ohne peers. De-facto ist es also ein Liste der nutzbaren Templates dieses kanal, also ein Subset aus  templateUsgG
zu 1 c)  nicht notwendig, siehe oben. Evtl wären unveränderliche default-templates sinnvol... ich hatte mich damals dagegen entschieden.

zu 2)
Schon einmal

Code Auswählen Erweitern

define ht HMtemplate
probiert? in "Internals" habe ich versucht eine anleitung einzupassen.. Editieren der Register geht über die Attribute.
https://wiki.fhem.de/wiki/HomeMatic_Templates
HMtemplate ist ein editor. Es könnte nach den editieren gelöscht werden - frisst aber kein Brot.

zu 3)
nun, du hast schon merkwürdige Vorstellungen, was ich mir antun will. Massochist bin ich nicht.
a) default templates werden aud HMConfig erst einmal eingelesen, wenn man noch nichts hat
b) HMInfo verwaltet template-definitionen (wer sonst) und auch das File regConfig.cfg. Der Name kann über attr hm configFilename festgelegt werden. Probiere einmal

Code Auswählen Erweitern


attr hm configFilename regConfig.cfg # default - kann man weglassen
get hm templateUsgG sortTemplate # liste der genutzten (icht nutzbaren)Templates  sortiert nach template
set hm saveConfig # das regConfig.cfg wird geschrieben. Hier enthalten sind alle Register-settings aber auch die template definitions und assignments
set hm loadConfig # regConfig wird gelesen (und alle fehlenden Register-settings/readings). Default templates sind dann Geschichte.
attr hm autoLoadArchive 1_load #regConfig.cfg wird nach FHEM start eingelesen, templates assigned und definitionen wieder hergestellt
get hm peerUsg # relativ neu. eine nach trigger sortierte listeder template nutzung. Ich habe für mich beschlossen, dass die Funktion jedes Peering über templates beschrieben wird

Das sollte für den Anfang reichen

So, nun die Fragen zu den default templates.
a) short/long
Am häufigsten hat man wohl einen Schalter (RTs später). Dieser ist gepeert mit einem Button oder BM. Zu definieren für dieses Peering ist nun die Reaktion auf short und auf long.
Option aa) man hat eine liste von Templates [on|off|toggle|ignore] (sicher noch mehr). Nun weist man dem peering 2 Templates zu, bswp short=on, long= ignore.
Option bb) man weist einem peering typisch ein template zu. Da man immernoch beide funktionsteile beschreiben muss quartiert sich die anzahl der templates. Also template für short_long = [on_on|on_off|on_ignore|on_toggle|off_on|off_off|...]
Ich bin zu option bb übergegangen da es einfacher in Device zu sehen ist. Da ich buttons bspw einer FB im Wohnbereich mehrfach nutze brauche ich sehr viele Konbinationen. Gerade ist eine neue notwendig geworden.
So nutze ich folgende Nomenklatur der Templates
<modelTyp><shortBehavior><longBehavior>
Beispiel
SwOnOff # für Switches: short= on, long = off
DimOffDown # für Dimmer: short= off, long = dimDown

b) template parameter
für einen Switch on will ich bswp die Ontime definieren. alle (ALLE) meine buttons schalten das List nur für eine Zeit ein. Das sind im Wohnzimmer einige Stunden. Aber irgendwann geht das Licht aus. Der Parameter ist einstellbar - das sind die template-paramenter. Die Frage ist, welche notwendig sind. Beispiel ist eben ein Schaltaktor. Möglich sind
- einschalt-dauer
- einschaltverzögerung
- ausschaltverzögerung
- Helligkeitslevel beim peering mit Bewegungsmeldern.
Der Template parameter kann dann in jeder Entity setz einfach geändert werden.
Übrigens haben meine RTs auch alle ein template. Hier stelle ich valvemax und boosttime individuell ein.

Ich warte auf das feedback

[frank]

nur kurz:
hm.js habe ich hier im ersten post angehängt.

[martinp876]

danke.
das Modul sollte hm.js sollte irgendwo anbgelegt werden. Zumindest in contribute. Der Name ist leider recht nichtssagend.

Meine Bewertung:
- Einsatz zur Definition eines Templates: Sehr gut.
     + man kann ein registerset  also template nutzen
      -  template parameter kann ich noch nicht hinzufügen - oder?
      - die Option "both" ist für peerings unterstützt. Short/long kann man nicht definieren. Kein Bedarf?
  - templates editieren: nicht unterstützt. Müsste man in hmInfo machen.
       - HMInfo hat (wie immer) für übergreifende Aktionen seine Berechigung. Somit sollte das editieren auch hier angelegt werden . HMTemplate könnte dann obsolet werden.
  - templates zuweisen: Ist gut.  Vorteil ist, dass man die Beschreibung sieht und die Parameter des Templates
    beides kann man auch direkt setzen  - allerdings mit weniger Beschreibung. Perfekt, dass die Werte aus dem Commandset umgesetzt werden!

Wie immer: Das Modul erlaubt User-freundliche Kommados mit a) Beschreibung b) Auswahllisten mehrer Parameter, Beschreibung der Parameter.
Das vermisste ich schon vor Jahren. Sollte generell zu verfügung gestellt werden. Das kann ich häufiger brauchen.

Ein "get" zu templates baue ich noch

[martinp876]

done.
get <entity> cmdList updated
get <entity> tplInfo implemented
Achtung: Auch HMConfig muss geladen werden.

Die Infos zu den Templates müsste ich sicher noch allgemeinverständlich gestalten. Wegen der geringen Nachfrage habe ich  mir keine Mühe mehr gegeben.
Hier ein paar Beispiele:
Bei RTs habe ich a) an den Regelparametern gespielt und b) die stelle ich Boost-Time und maxValve individuell ein. Alles andere ist identisch. Dafür mein Template als Kommando:

Code Auswählen Erweitern

set hm templateDef HeatDefault boost:valveMax "myDefault RT settings, enter boostTime and valveMax" showWeekday:off boostPeriod:p0 modePrioParty:all tempMax:30.5 valveMaxPos:p1 daylightSaveTime:off btnNoBckLight:off regAdaptive:on showInfo:time decalcTime:11:00 noMinMax4Manu:off tempOffset:0.0K decalcWeekday:Sat dayTemp:21 tempMin:4.5 nightTemp:17 boostPos:30 valveOffsetRt:0 valveErrPos:15 modePrioManu:all

Mein Standard template für ein-taster bedienung eines Schalters: Kurz ist ein, lang ist aus. Ich präferieren dedizierte Kommandos. Toggel nur mit Widerwillen.
natürlich wird das Licht nur für eine einstellbare Zeit eingeschaltet

Code Auswählen Erweitern

set hm templateDef SwOnOff timeOn "sh:on lg:off" shSwJtOn:no shActionType:jmpToTarget shSwJtOff:dlyOn lgActionType:off shOnDly:0 shSwJtDlyOn:on shSwJtDlyOff:dlyOn shOnTimeMode:absolut shOnTime:p0 shMultiExec:off


Hier ein Template für Blind - herunterfahren.

Code Auswählen Erweitern

set hm templateDef BlSmartStopDn 0 "from Master BlSmartStopDn > FB_09:both" shOnTime:unused lgCtRefOn:geLo shBlJtRefOn:on shBlJtDlyOn:dlyOff lgOffTime:unused lgOnLevel:100 shMaxTimeF:unused shBlJtOn:dlyOff lgOffDly:0 shBlJtOff:dlyOff lgCtOff:geLo lgOnTimeMode:absolut shBlJtRampOff:off lgCtRefOff:geLo shActionType:jmpToTarget lgCtValLo:50 shCtRampOff:geLo shBlJtDlyOff:refOff shCtRefOff:geLo shCtValLo:50 lgMaxTimeF:0.5 lgCtValHi:100 shBlJtRefOff:rampOff lgBlJtOn:dlyOff shCtOff:geLo lgBlJtDlyOff:refOff lgOnDly:0 lgOnTime:unused shBlJtRampOn:on shMultiExec:off shOnTimeMode:absolut lgMultiExec:on lgBlJtOff:dlyOff lgOffTimeMode:absolut shOffTime:unused lgBlJtRampOn:on lgDriveMode:direct lgBlJtRampOff:rampOff lgCtDlyOff:geLo shCtOn:geLo shCtRampOn:geLo lgCtRampOff:geLo lgActionType:jmpToTarget shCtDlyOff:geLo lgBlJtRefOff:rampOff shCtDlyOn:geLo lgBlJtRefOn:on shOffDly:0 shOffTimeMode:absolut lgBlJtDlyOn:dlyOff lgCtOn:geLo shCtRefOn:geLo shOnDly:0 lgCtDlyOn:geLo shCtValHi:100 shOffLevel:0 lgOffLevel:0 shOnLevel:100 lgCtRampOn:geLo shDriveMode:direct


Möglchkeiten aus HMtemplate:
ein

Code Auswählen Erweitern

get ht defineCmd <template>
gibt dir das Kommado zurück welches du zur Definition eines Tempaltes in die Kommandozeile pasten kannst. Voraussetzung: die  HMInfo-entity heist "hm". Die Idee ist, dass  jeder der meint ein cooles tempate zu haben er hier herausziehen und weitergeben kann.
Viel einfacher konnte ich es mir nicht mehr vorstellen.

[frank]

freut mich, dass es dir gefällt. dann sind wir augenblicklich schon 3. 

Meine Bewertung:
- Einsatz zur Definition eines Templates: Sehr gut.
     + man kann ein registerset  also template nutzen
      -  template parameter kann ich noch nicht hinzufügen - oder?
      - die Option "both" ist für peerings unterstützt. Short/long kann man nicht definieren. Kein Bedarf?

parameter definieren sollte funktionieren, siehe kurzanleitung punkt 2.1.
es könnte sein, dass dich die vielen, "gesperrten" einträge für die parameter irritiert haben. es ist immer nur der erste mögliche parameter aktiv. zuerst also nur p0.

hintergrund: da es "nur" 9 parameter geben darf, wollte ich von anfang an alle in der selekt liste sichtbar haben, damit man sie sparsam nutzt.
weil die parameter aber mit p0 beginnen und am ende eine kontinuierliche reihe ergeben müssen, deaktiviere ich die noch nicht benötigten einträge. aus vielen beiträgen hier im forum, habe ich ja gelernt, dass viele user auf "alles" klicken, was nicht rechtzeitig auf die bäume huscht. 

für short/long ist natürlich "bedarf". daher steht es bereits auf der todo liste im 1. post.
die reihenfolge in der todo liste zeigt meine aktuelle priorität.

- templates editieren: nicht unterstützt. Müsste man in hmInfo machen.
       - HMInfo hat (wie immer) für übergreifende Aktionen seine Berechigung. Somit sollte das editieren auch hier angelegt werden . HMTemplate könnte dann obsolet werden.

"templates editieren" baue ich hier ein und hat für mich oberste prio.

das betrifft ja meinen wunsch 2. von oben.
seit gestern abend habe ich aber ganz neue ideen zum editieren im kopf, so dass sich wunsch 2. etwas geändert hat.
bisher hatte ich zu kurz gedacht, da ich immer nur den infotext im auge hatte. wenn man aber parameter und register hinzufügen oder ändern will, muss man ja sowieso zuerst alle assignments entfernen und anschliessend neu setzen. somit funktioniert dann ja sowieso nur mein beschriebener workaround.
und wenn ich dann schon alle assignment daten einsammeln muss, kann ich auch gleich eine tabelle aller device:peer kombis erstellen, die das template aktuell nutzen. über checkboxen wird man die assignments dann auswählen können.

mein plan ist quasi ein 2-stufen-editieren des templates.
stufe 1 (basic): alle daten editieren, die die definition des eigentlichen templates betreffen (info, register, parameter).
stufe 2 (global): alle "link"- daten des templates editieren (assignments, parameter values).

das bringt mich dann zu meinem neuen wunsch 2. zum editieren:
eine liste aller möglichen (possible) device:peer kombinationen, die dieses template nutzen könnten. also zb:
"get hminfo templatePossibleDevices <template>"
idealerweise enthält die liste eine spalte mit den aktuellen parameter values bei device:peer kombis, die aktuell mit diesem template assigned sind. bei allen noch nicht genutzten kombis enthält die spalte, die aktuell gesetzten register values. zum initialen assignen (set) nehme ich immer die aktuellen register einstellungen, um die parameter zu füttern. so habe ich deine entity befehle tplSet_<peer> zumindestens verstanden. wenn du den values bei assigned device:peer kombis die jeweilige parameter id voranstellt ("p0:", "p1:", ...) kann ich dadurch ein assignment erkennen.

damit könnte ich dann ein "globales" assign/unassign/set realisieren.
allerdings sind meine ideen bisher immer ein stück weit von meinen fähigkeiten entfernt.

- templates zuweisen: Ist gut.  Vorteil ist, dass man die Beschreibung sieht und die Parameter des Templates
    beides kann man auch direkt setzen  - allerdings mit weniger Beschreibung. Perfekt, dass die Werte aus dem Commandset umgesetzt werden!

was meinst du mit weniger beschreibung? bei inputs, die keine auswahlliste haben, wird der value range am mauszeiger sichtbar, wenn der mauszeiger über dem element ist. die descriptions und inputs sollten identisch zu den register zeilen im expert mode sein. papa hatte diese sinnvolle "zerlegung" eigeführt. vermisst du etwas? könnte beim parsen verloren gegangen sein.

zu den descriptions bei den parametern habe ich noch folgende idee:
wenn im infotext zum template am ende eine irgenwie gekennzeichnete liste mit parameter beschreibungen existiert, werden diese texte bei den parametern entsprechend angezeigt.
wahrscheinlich besonders interessant bei nutzung von mult-parametern, die gleichzeitig mehrere register bedienen. zur zeit wird immer die description des registers benutzt, das in der definition des templates als erstes mit der entsprechenden parameter id auftaucht. 

gibt es eigentlich eine maximale länge für den infotext?

Möglchkeiten aus HMtemplate:
ein

Code Auswählen Erweitern

get ht defineCmd <template>
gibt dir das Kommado zurück welches du zur Definition eines Tempaltes in die Kommandozeile pasten kannst. Voraussetzung: die  HMInfo-entity heist "hm". Die Idee ist, dass  jeder der meint ein cooles tempate zu haben er hier herausziehen und weitergeben kann.
Viel einfacher konnte ich es mir nicht mehr vorstellen.

genau diesen cmd meinte ich mit meinem wunsch 3.
ich hätte es allerdings gerne über hminfo, um damit existierende templates zu parsen.
ich verfolge nämlich meinen vagen traum, das interface irgend wann in ferner zukunft quasi 1zu1 auf hmccu adaptieren zu können. je weniger beteiligte module für die requests, desto grösser die wahrscheinlichkeit.

aus hminfo wird dann hmccuinfo, und fertig. 

click dir mal ein template zusammen und benutze nicht den define button, sondern den show button.


gefundene fehler:

1. HM-LC-SW1PBU-FM.
wenn ich diesen mit einem fensterkontakt peere, gibts hierfür kein cmd "set <entity> tplSet_<peer>" im aktor. dadurch natürlich auch keine available templates. bei den fest gepeerten buttons self01/2 tauchen jeweils ca 1 dutzend default templates auf. nach meiner logik müssten beim fensterkontakt die selben templates auftauchen.

2. HM-LC-DIM1T-FM
bei diesem device fehlen mir leider diverse register. ich hatte es vor einiger zeit mal gepostet: https://forum.fhem.de/index.php/topic,105531.msg994652/topicseen.html#msg994652

3. HM-CC-TC
auch hier fehlen mir register, zb day-temp, night-temp, party-temp.

4. HM-ES-PMSW1-PL
hier kann ich im channel 02 beim register txThrPwr kein special unused mehr setzen. https://forum.fhem.de/index.php/topic,96646.0.html

könntest du nicht mal deine neuen hmccu device daten irgendwie mit den registerdaten aus HMConfig.pm vergleichen?
ich habe auch schon mal vergeblich danach geschaut, denn das gemisch aus subtype/clones/direkten -daten habe ich immer noch nicht durchschaut.



die neuen befehle schau ich mir morgen an, danke schon mal.

[martinp876]

So, mal sehen, das sich alles korrekt kommentiere

* Parameter sollten funktioniere => ok
* 9 Parameter sind m.E. reichlich. Ansonsten ist ein neues Template fällig.

wenn man aber parameter und register hinzufügen oder ändern will, muss man ja sowieso zuerst alle assignments entfernen und anschliessend neu setzen.

Das sehe ich definitiv nicht so. Unassign kommt nicht in Frage - widerspricht den Komzept.
Das (von mir vorgesehene) Vorgehen ist - und so nutze iches auch:
- will ich ein template ändern ändere ich das Template
   > die assigned entites divergieren - klar
   > ich starte ein "set hm templateExe"  => alle definitionen werden geschrieben
   > ich mache ein get hm templateChk => ich sehe den Zustand und kann aggieren
   > ich mache ein get hm configCheck => beinhaltet (natürlich) templateChk

kann ich auch gleich eine tabelle aller device:peer kombis erstellen

Die hast du schon in HMInfo

über checkboxen wird man die assignments dann auswählen können

cool. Hier reden wir aber definitiv über HMInfo. "In" einem Entity-context manipuliert man "die Entities". Will man übergreifend aggieren macht man das in HMinfo.
Bitte nicht die Systematik zerstören

"get hminfo templatePossibleDevices <template>"

mal sehen. Würde ich aber eigentlich in HMtemplate sehen. Mal schauen. Problem ist die Berechnung. Das könnte Rechenzeit kosten.... Da muss jedes Register des Templates mit den Registern aller Devices verglichen werden . Statisch möchte ich es nicht machen....

idealerweise enthält die liste eine spalte mit den aktuellen parameter values bei device:peer kombis, die aktuell mit diesem template assigned sind

nun steige ich langsam aus. Die Liste wird sehr lang. Und auch breit. Wofür brauchst du sie? Kann ein User damit umgehen und was ist das Ziel? Ist das für Nerds?

nehme ich immer die aktuellen register einstellungen,

So macht es das Assign kommando, korrekt.

wenn du den values bei assigned device:peer kombis die jeweilige parameter id voranstellt ("p0:", "p1:", ...) kann ich dadurch ein assignment erkennen.

dann wird das Kommando noch lääänger.

damit könnte ich dann ein "globales" assign/unassign/set realisieren.

nicht schlecht. Allerdings denke ich, muss ich hier an einem Konzept arbeiten, die Performance gering zu halten. Ich denke wir haben aber schon einige gute Funktionen. Wenn Anwender interessiert sind wenden sie es an, wenn nicht, nicht.
=> wir brauchen standard-templates. Ohne diese werden wir keinen Durchbruch erreichen.
=> welche templates brauchen wir? Welches Konzept (nicht des Codes, sondern der Templates) würdest du sehen?

was meinst du mit weniger beschreibung?

Um Templates zu assignen brauche ich das neue Frontend nicht, geht auch so - per drop-down. Der Simple-user will/soll die Register nicht sehen. Der Nerd schon.
Im Frontend ist "mehr als genug" info.

des registers benutzt, das in der definition des templates als erstes mit der entsprechenden parameter id auftaucht.

passt. Es wird nur selten ausnahmen mit multi.reg geben.

gibt es eigentlich eine maximale länge für den infotext?

nein

ich hätte es allerdings gerne über hminfo, um damit existierende templates zu parsen.

Verstanden. Aber HMtemplate parsed existierende templates.

gefundene fehler:
1. HM-LC-SW1PBU-FM.

sollte nicht sein. Allerdings: hast du schon ein getConfig gemacht? Ihc prüfe die vorhandenen Register, nicht die möglichen. Ohne getConfig sind die Register nicht vorhanden.
Könnte ich umstellen - aber das zuweisen wird scheitern, da ich die hex-werte beim Assign nicht rechnen kann. => nein, nicht umstellen.

HM-CC-TC auch hier fehlen mir register, zb day-temp, night-temp, party-temp.

werde ich prüfen... das Device habe ich nicht(mehr)

könntest du nicht mal deine neuen hmccu device daten irgendwie mit den registerdaten aus HMConfig.pm vergleichen?

die neuen nicht - da habe ich andere Wege. Aber da es handarbeit ist können fehler drin sein. Bei HMCCU geht es dann automatisch.

[martinp876]

Die Bugs sollten erledigt sein. Der Erste war heftiger, als erwartet. Allerdings ist die Registerliste schon komplett, nur die Anwendung hatte ein Problem. Systematisch also.

So nun erst einmal wieder eine meiner generellen Betrachtungen: Was/wie/wo templates
Use cases / user:
Ich gruppiere die User einmal digital in 2 Gruppen
A) Nerds: wollen alles steuern, freuen sich über komplexe kommandos bei welche sie viel einstellen können - wenn sie das Thema interessiert. FHEM developer sind erst einmal nerds. FHEM Nutzer zu 80%
B) User: wollen nichts einstellen. Plug&Play muss es gehen. Don't rtfm - das Kommando muss intuitiv sein, selbsterklärend. Alles über auswahllisten (maxilal) - Am Besten alles stellt sich selbst ein.

Ich beispielsweise bin... beides. wenn ich codiere bin ich Nerd. Nutze ich fremde Module bin ich User. Nutze ich mein Modul einige Zeit werde ich immer mehr user

=> m.E. werden templates nicht angewendet weil eine a) das Interface bei Einführung zu nerdig war b)  User sich vom "define"  haben abschrecken lassen anstatt sich auf "assign" zu konzentrieren c) die nach gereichten vereinfachungen nicht mehr beachtet wurden d) Nerd Anwender in panik gerieten, dass man ihnen Kontrolle nimmt und e) die User von den Nerds nicht in Richtung tempaltes geführt wurden.

Um templates zu "vermarkten" braucht es zu allererst
1) eine gute Abdeckung an funktionen durch "default templates". User wollen erst einmal nicht über Details nachdenken sondern fertige Lösungen einsetzen. Anpassen kommt "viel" später
2) Fokus auf "assign". Der User sollte wenig mit "define" in Konkakt kommen. Das schreckt ab

Natürlich gibt es die Nerd-anwendungen dann auch noch!

Bisher habe ich m.E. die User mit den vielen Optionen überfordert. Templates lassen "unendlich viel" Konzepte zu. Ich hätte nur eines bewerben sollen. Kannst du mir helfen, die Entscheidung zu treffen? Bei den wohl am meisten genutzten Templates (wenn es einmal so weit kommt) sind sicher die Schalter oder Dimmer zu nennen. Hier kann man
I) templates "both" definieren. Es wird also das Verhalten bei long und short press auf einmal definiert
II) templates "short" oder "long" separat definieren. Es werden deutlich weniger Templates definiert, aber es müssen immer 2 assigned werden
III) interne Funktion separiert. Ich habe bspw die Jumptable in einem und die CT in einem andere Template definiert. Das sind noch weniger Templates aber noch mehr assignments

Ich nutze aktuell die Version I).
Des weiteren brauchen wir die template parameter welche beinhaltet sein sollten.
Somit sehe ich für einen Schalter die einschaltzeit und ausschaltverzögerung.
Für Motion detector braucht man m.E. ein anderes Template. Dies soll erreichen, dass ein "on" den MD ausser Kraft setzt.
Switch template beginnen mit "SW"

Damit komme ich für I) auf
SwOnOn OnTime, OffDelay
SwOnOff OnTime, OffDelay
SwToggleOff OnTime, OffDelay
SwOffToggle OnTime, OffDelay
SwIgnoreToggle OnTime, OffDelay
SwOffOff
...
Ich habe als Funktion On/Off/Toggle/Ignore welche in jeder Kombination genutzt werden können.
Weiter habe ich Toggle2Cnt. Macht sinn, wenn man eine Button zum Schalten mehrer Aktoren nutzen will

Deine Meinung?


Noch ein Thema: Context.
Aktuell konzentrierst du dich voll auch CUL_HM. Bitte unbedingt beachten, dass CUL_HM Kanäle bearbeitet. Befinde ich mich in diesem Kontext sind kommandos welche entity-übergreifend sind (exterm) unpassend.
HMInfo ist die Übergreifende Entity. Alles was übergreifend ist (und bei Templates ist man schnell an dieser Stelle!) muss (MUSS) hier bearbeitet werden.
Daher meine Bitte, dass template-editieren auf der Ebene HMInfo bearbeitet wird. Es hat schon seinen Grund, warum ich HMTemplate gebaut habe. Schlussendlich halte ich das für den richtigen Weg, auch für deine übergreifenden Ideen.
HMTemplate wird, wenn du fertig bist, nicht mehr benötigt. Aber mir würde es gefallen wenn du deine Platfrom in HMTemplate integrierst, oder es ersetzt. De-facto stellst du einen Template-editor zu Verfügung.
Also das Assign und die Implementierung in CUL_HM ist fast komplett. Hier sollte nicht mehr passieren (ausser fixes).
HMInfo verwaltet die Templates, ist aber im Hintergrund.
Dein Frontend bietet nun eine Möglichkeit die templates übergreifend zu "bedienen". Ob du das nun an HMInfo oder in ein (neues) HMTemplate integrierst wäre mir egal. Zuerst sehe ich eine bessere visualisierung der Funktionen aus HMTemplate.

Deine Meinung?

[papa]

Bin auch schon Fan, auch wen ich noch keine Zeit hatte, es mir mal anzusehen. Schön, dass meine einfachen Anfänge weiter geführt werden.

[Pfriemler]

hm.js einkopiert: diverse fehlende Register. Klar, also:
FHEM-Update, 10_CUL_HM und HMConfig aus dem SVN dazu + reload = läuft! Sauber!

Vielleicht finde ich jetzt auch endlich mal mehr Zugang zu den Templates.

Einen Wunsch hätte ich noch: Templates kann ich anwenden ("set") und die Verknüpfung aufheben "unassign" (beides testweise mit autoOff_short auf self01 eines Steckdosenaktors probiert). Danach bleiben aber alle durch das Template gemachten Änderungen weiterhin aktiv. Ein Reset aller betreffenden Register wäre hilfreich.

Derzeit sehe ich keine andere Möglichkeit, als bei list3 das Peering aufzuheben und erneut zu setzen und für list0 und list1 das Gerät zurückzusetzen, wobei man es dann wieder neu pairen muss...
Selbst wenn es eine Defaults-Datenbank gäbe, müsste sie mit jeder Geräte-FW aktualisiert werden. Und list3-Defaults richten sich unter anderem danach ob single oder dual gepeert ist.

Eventuell könnte man auf Backups in regSave.cfg zurückgreifen. Die laufen aber m.W. auch nicht automatisiert ab, meine letzte ist vom August 2019.

Hat jemand von Euch dazu irgendeine Idee?

[frank]

moin martin,

du bist ja wie im rausch, ich komme kaum hinterher. 


der neue befehl "get tplInfo":

Code Auswählen Erweitern

templates for peerings serving short AND long press:
   SwToggleIgnore   params:timeOn                   Info:sh:toggle lg:ignore
device templates:
   hallo            params:                         Info:hallo@dies ist test 1.
   hallo1           params:                         Info:hallo@das ist test 2, @mit 3 zeilen.
   hallo2           params:                         Info:hallo@test 3 macht autowrap mkksdfhb mkksdfhb mkksdfhb mkksdfhb mkksdfhb mkksdfhb mkksdfhb mkksdfhb mkksdfhb mkksdfhb mkksdfhb mkksdfhb mkksdfhb mkksdfhb mkksdfhb mkksdfhb mkksdfhb mkksdfhb, @ende zeile 5.
templates for peerings serving short OR long press:
   SwCondAbove      params:condition                Info:Switch: execute only if condition level is above limit
   SwCondAbove      params:condition                Info:Switch: execute only if condition level is above limit
   SwCondBelow      params:condition                Info:Switch: execute only if condition level is below limit
   SwCondBelow      params:condition                Info:Switch: execute only if condition level is below limit
   SwOff            params:                         Info:Switch: off if trigger
   SwOff            params:                         Info:Switch: off if trigger
   SwOnCond         params:level cond               Info:switch: execute only if condition [geLo|ltLo] level is below limit
   SwOnCond         params:level cond               Info:switch: execute only if condition [geLo|ltLo] level is below limit
   SwOn             params:                         Info:Switch: on if trigger
   SwOn             params:                         Info:Switch: on if trigger
   SwToggle         params:                         Info:Switch: toggle on trigger
   SwToggle         params:                         Info:Switch: toggle on trigger
   autoOff          params:time                     Info:staircase - auto off after -time-, extend time with each trigger
   autoOff          params:time                     Info:staircase - auto off after -time-, extend time with each trigger
   motionOnSw       params:ontime brightness        Info:Switch: on for time if MDIR-brightness below level
   motionOnSw       params:ontime brightness        Info:Switch: on for time if MDIR-brightness below level

• in spalte 1 für den bereich "short OR long" fehlt noch "_short, _long" am ende der template namen.
• die gruppe device templates würde ich immer ganz oben ausgeben.
• wenn keine templates vorhanden sind, gibt es keine ausgabe/reaktion beim klicken auf den get befehl. eine mitteilung über diese tatsache, wie "no templates available", gäbe weniger irritationen.
• bei meinen "hallo"-templates siehst du im info text "klammeraffen" (@).
  im nächsten update werden sie für manuelle zeilenumbrüche zur formatierung verwendet. nur als hinweis, falls du deine default templates entsprechend "formatieren" möchtest.
  beim definieren über das interface werden die @ dann automatisch aus den newline-zeichen generiert, die durch die benutzung der return taste im info-inputelement entstehen.
  
  ohne substitution der \n hat hminfo templateDef leider einen leeren infotext erzeugt.

 

fehlende cmds "set tplSet_<peer>" für einen gepeerten fensterkontakt:

hierzu habe ich mal einen eigenen thread erstellt.
https://forum.fhem.de/index.php/topic,107137.0.html


template vermarktung:

Bisher habe ich m.E. die User mit den vielen Optionen überfordert. Templates lassen "unendlich viel" Konzepte zu. Ich hätte nur eines bewerben sollen. Kannst du mir helfen, die Entscheidung zu treffen? Bei den wohl am meisten genutzten Templates (wenn es einmal so weit kommt) sind sicher die Schalter oder Dimmer zu nennen. Hier kann man
I) templates "both" definieren. Es wird also das Verhalten bei long und short press auf einmal definiert
II) templates "short" oder "long" separat definieren. Es werden deutlich weniger Templates definiert, aber es müssen immer 2 assigned werden
III) interne Funktion separiert. Ich habe bspw die Jumptable in einem und die CT in einem andere Template definiert. Das sind noch weniger Templates aber noch mehr assignments

1. das wichtigste für mich ist ein eindeutiger und lesbarer template name.
dieser darf absolut keinen zweifel darüber aufkommen lassen, was das template macht. je weniger das template macht, desto einfacher, eindeutiger und kürzer kann der name sein.
jeder der die templateliste einmal genutzt hat (zb durch forenuser gelenkt), muss auch nach 6 monaten zweifelsfrei das selbe template sofort wiederfinden.

2. auch die subtype beschreibung zur unterscheidung schalter/dimmer finde ich im namen störend und verwirrend, da sie nichts zur funktionsbeschreibung des templates beiträgt. zur unterscheidung der templates leider nötig, sollte dieser zusatz aber nicht als präfix an der besten position des namens stehen. ich würde ihn für schalter gänzlich weglassen und bei dimmern im namen "verstecken" (vorletzte stelle vor short/long).
ebenso abkürzungen möglichst vermeiden und namensteile explizit durch tiefstriche von einander abgrenzen.
am anfang des namens muss die funktion stehen, und diese muss mit den funktionsnamen bei den set befehlen übereinstimmen. also bitte kein "autoOff", auch wenn der name wirklich schön ist, aber in fhem weiss irgendwann jeder, was on-for-timer ist. und danach wird auch gesucht.

3. weniger ist mehr.
eine zu lange templateliste ist auch erschreckend. besser im "einführungsangebot" (default templates) nur die wichtigsten. wir müssen die user erst "anfixen". weniger gebräuchliche "standard" templates würde ich aus diesem grund ins wiki auslagern. es ist ja total einfach uber set templateDef (copy&paste) zu erweitern. ausserdem kann man dadurch interessierte user langsam an weitere template funktionalitäten heranführen.


daher halte ich eine mischung aus II) und III) am optimalsten. modulares system, getrennt für short und long. die grundfunktionen sind quasi "basic"-templates, die jeweils mit "addon"-templates ausgebaut werden können. dabei sollten die basic templates das komplette parameterset beschreiben, um auf jedenfall eine definierte grundlage zu schaffen. addons ändern dann nur noch wenig.
im info text sollten dann bei basic templates hinweise zu sinnvollen addons stehen. und umgekehrt im addon hinweise zu sinvollen basic templates.


für schalter würde ich zur zeit folgendes vorschlagen. wobei mir noch eine sinnvolle/prägnante benamung (conditionText) der addons für die conditiontable fehlt auch müssen die conditition addons einfach sein. feste vorgaben für die bedingung scheint mir besser zu sein, als ein parameter. vielleicht anwendungsspezifische beschreibungen. jedenfalls sollten bm und fk gezieltes schalten ermöglichen können. insgesammt aber vielleicht eine obergrenze von 15-20 default templates, alles weitere ins wiki:

default (basic):
on_short
on_long
off_short
off_long
on-for-timer_short (mit parameter:onTime)
on-for-timer_long (mit parameter:onTime)
toggle_short
toggle_long
ignore_short
ignore_long

default (addons):
add_delayOn_short (mit parameter:onDelay)
add_delayOn_long (mit parameter:onDelay)
add_delayOff_short (mit parameter:offDelay)
add_delayOff_long (mit parameter:offDelay)
add_conditionText_short (mit parameter:)
add_conditionText_long (mit parameter:)

wiki (basic):
off-for-timer_short
off-for-timer_long
toggleToCnt_short
toggleToCnt_short


den zusätzlichen namenszusatz (_dim_) für dimmer templates würde ich an die vorletzte stelle verschieben.

on_dim_short
off_dim_long
pct_dim_short (mit parameter:level)


gruss frank

[frank]

Einen Wunsch hätte ich noch: Templates kann ich anwenden ("set") und die Verknüpfung aufheben "unassign" (beides testweise mit autoOff_short auf self01 eines Steckdosenaktors probiert). Danach bleiben aber alle durch das Template gemachten Änderungen weiterhin aktiv. Ein Reset aller betreffenden Register wäre hilfreich.

am besten vor dem spielen config sichern. 

aber mal ernsthaft:

wozu reset?
wenn es wirklich so viele unterschiedliche reset datensätze gibt, ist es doch einfacher das gewünschte verhalten neu zu setzen.
wenn man mal spielen will, könnte man auch vorher vom datensatz ein template aller register erstellen und nach dem spielen wieder drüberbügeln. dafür könnte ein button selectAll ganz nützlich sein.

ein manager interface zum handling von configs würde mir auch gefallen. sehe ich hier allerdings nicht.

gruss frank

[papa]

Um das Namensproblem zu lösen, könnte man doch noch einen "Alias"-Namen einführen. Dann kann der echte Name ruhig kryptisch sein. Im UI wird aber der "Alias" angezeigt. Dann kann es auch den gleichen Alias für die gleiche Funktion bei Schaltern/Dimmern/... geben.

Beim Setzen eines Templates würde ich mir wünschen, die Register und die Werte optional einzublenden. Ich weiss gerne, was passiert Ich hab mal einen Screenshort von meiner, alten Version angehängt.

[Pfriemler]

am besten vor dem spielen config sichern. 
aber mal ernsthaft:
wozu reset?

Ja, das mit dem Sichern vor der Änderung ist wohl doch der einfachste Weg. Vielleicht wäre genau das direkt vor "Apply" ein gangbarer Weg.
Im Dialog ein "alte Registerkonfiguration sichern"-Häkchen (kann ja default off sein)? Wäre sowohl für templates als auch für Expertenmodus gleichermaßen nützlich.
Global ist vielleicht keine so gute Idee. saveConfig an sich ist ja schon unterstützt, muss man nur aufrufen, ggf. als Einzeldatei - kann man ja jetzt schon bei jedem Gerät in einen individuellen Dateinamen exportieren. Nur ... statt der dezeit verwendeten "entity" (Device-Namen) würde ich würde eine Datei mit der (unveränderlichen) HmID vorschlagen, da diese auch etwaige spätere Namensänderungen des Device überlebt - saveConfig und Co verwenden ja derzeit den entity-Namen, und serialNr ist zumindest bei Kanälen nicht mehr unique.
Wobei: Vielleicht sogar noch ein kleines Textfeld als comment dazu? Dann wird es aber schon gänzlich inkompatibel zum bisherigen Mechanismus.
Daraus könnte man eventuell auch einfach Backups zum Restore ziehen, Zeitpunkt des Backups ist ja schon hinterlegt.
Nun noch ein Vergleich von backup und Istzustand mit markierten Änderungen ... (ach, man wird ja wohl mal träumen dürfen...)

Wozu Reset? Um wieder ein definiertes Verhalten herzustellen, besonders nach der dritten oder vierten Änderung, bei der man sich vertan hat. Ich persönlich bin ja mehr der Freund detaillierter Einzeländerungen, die so wenig wie nötig "verstellen". Der Aufwand eines Geräteresets oder einer Erneuerung der Verknüpfung ist zumindest in der Experimentierphase ja überschaubar, zumal man ja auch da seine Änderungen gewöhnlich protokolliert. Aber weiß man das nach einem halben Jahr noch?
Hin und wieder werden Geräte bei mir auch anderen Verwendungen zugeführt (besonders Zwischenstecker). Die hätte ich dann gern "rückstandsfrei".
Ist alles sehr speziell, ich weiß. Es geht auch ohne. Oder aber, wenn ich vor der ersten Verpfriemlung ein Backup mit entsprechendem Kommentar anlege.

Um das Namensproblem zu lösen, könnte man doch noch einen "Alias"-Namen einführen. Dann kann der echte Name ruhig kryptisch sein. Im UI wird aber der "Alias" angezeigt. Dann kann es auch den gleichen Alias für die gleiche Funktion bei Schaltern/Dimmern/... geben.

Das würde ich ja vollstens unterschreiben. Schon die gemischte Groß-Klein-Schreibweise der Abkürzungen ist für einen Nicht-Register-Kenner überraschend (wennauch nach dem Kennenlernen reproduzierbar logisch).

Derzeit frage ich mich noch, ob die Unterscheidung in Long/Short bei den Templatenamen nicht auch noch zu umgehen wäre. Beim HMTemplate von Martin wird das ja auch erst beim Konfigurieren der Parameter festgelegt. Schwierig wird das allerdings, wenn man z.B. ein autoOff sowohl für short als auch für long anwendet. Die zugrundelegenden Manipulationen beschränken sich ja hier bspw. nicht nur auf die Laufzeit, sondern auch auf das Tastenverhalten (Nachtriggern, keine Ausschaltmöglichkeit). Im Grunde müsste man die Parameter doppelt listen und einen getrennten Haken für beide Varianten setzen. Das alles umgeht die derzeitige Trennung in der Liste ganz elegant ...

Beim Setzen eines Templates würde ich mir wünschen, die Register und die Werte optional einzublenden. Ich weiss gerne, was passiert

auch das stünde auf meiner Wunschliste ...