Oberfläche zum Ändern von Registerwerten

[martinp876]

Viel zu Antworten... viele Themen.
@tndx:
Unklar, was du genau gemacht hast. Templates hatte ich in HMInfo eingeführt - der Editor HMTemplate ist deutlich später gekommen. Klar muss man sich einmal an die bedienung gewöhnen. hm - habe ich noch garkein Wiki erstellt...
https://forum.fhem.de/index.php/topic,72766.msg643701.html#msg643701
hatte keinen Antworten hervorgerufen.
Wie beschrieben, das ist ein Editor - Templates erstellen / ändern / zuweisen.

Erstennen und ändern ist für Fortgeschrittene - zuweisen ist für alle.
Verwalten ist auch dabei.

Code Auswählen Erweitern

Aber vielleicht habe ich auch nicht das gesamte Potential von den Templates ausgenutzt.
ohne genau zu wissen, was du gemacht hast würde ich dennoch klar behaupten - weder ausgenutzt noch den Umfang erfasst (nicht böse gemeint - das hat fast keiner)

Noch einmal einer der wichtigsten Punkte: um Config Daten von externen Devices (Also alle HM devices und devices mit eigenen, remanenten config daten) auch nur einigermasen sauber bedienen zu können braucht man einen Soll und einen Ist Wert. Bisher leisten das nur Templates.

[martinp876]

nächste Antwort ... @ Pfriemler

• HMTemplate ist seit einiger Zeit aktiv. Installation einfach und komplett ungefährlich
• saveConfig: habe ich selbst gemacht. Ist ohne templates bei weitem nicht leistungsfähig genug. Es speichert IST-Werte. Das macht für einiges Verhalten Sinn. Es bedient aber - ohne Templates - keine SOLL-Wert Verwaltung. Nutzt man templates sind darüber auch SOLL Werte beinhaltet - in saveConfig (ich macht nicht jedes mal etwas neues)
• Register ändern sich spontan - leider.  Aus meiner Sicht gilt "Vertwauen ist gut - Systeme müssen kontrolliert werden". Alles, was ich nicht kontrollieren kann ist Mist. bspw durch:


• reset - lokal oder remote
• peeren / noch maliges peeren
• device austausch
• Device Fehler HW/FW
• Bedien Fehler
• Template erstelle ist nichts für Anfänger. Templates nutzen ist klar für Anfänger
• Für mich unverständlich geht es leider keiner an Templates interessiert.

• Bezüglich HM wäre wünschenswert, dass die Oberfläche alle verfügbaren Register mit allen verfügbaren Werten anbietet



• regList zeigt die möglichen Register.
• regTable zeigt die genutzten Register
• HMTemplate bietet eine geführte Möglichkeit der Registeränderung - und eine geführte Möglichkeit der Template-Zuweisung. Schade, dass es keiner nutzt.

• Jeder der HMTemplate mal genutzt hat, wird das nachvollziehen können.

  ok, klare Ansage. Leider hatte ich bisher noch kein feedback. Deine Anmerkung kann ich daher auch nicht verstehen. Es steht sogar eine Anleitung wie vorzugehen ist in der "internal" section

• die Spieler wollen vielleicht auch Templates versuchsweise modifizieren

  logisch. Kann man doch. Templates kann man kopieren, modifizieren,... alles da. Soll und wird nicht verhindert.

Ich sehe es immer noch so wie vor 4 Jahren: FHEM ist nicht konsequent aufgebaut.
CUL_HM ist ein API für HM-RF. Das ist eigentlich kein User Interface. Das ist ein Experten Interface. Ausser zum Spielen will keiner die Oberfläche nutzen - das will man von weiter oben.
FHEM bietet keine Instants CUL_HM welche über den Devices steht.
Ich habe den (klägliche) Versuch mit HMinfo gestartet. Hier kann man HM-RF Devices en wenig kontrollieren. Auf diese Ebene sollten alle Aktionen für HM-RF Devices zu verfügung stehen welche mehr als ein Device betreffen. Eigentlich sollte alles (innerhalb von HM-RF) von hier aus gesteuert werden. Insbesondere peeren, Verhalten zuweisen (templates), Zustandskontrolle, Konfig Kontrolle. Natürlich nicht der "operational layer". Licht schalten gehört nicht dazu.

[tndx]

Hi Martin,

Viel zu Antworten... viele Themen.
@tndx:
Unklar, was du genau gemacht hast. Templates hatte ich in HMInfo eingeführt - der Editor HMTemplate ist deutlich später gekommen. Klar muss man sich einmal an die bedienung gewöhnen. hm - habe ich noch garkein Wiki erstellt...

Danke für die Info, ich habe mich in der Tat damit beschäftigt, als es HMTemplate noch nicht gab. Ich habe aber deswegen nicht weiter gemacht, weil es mir nicht weit genug ging. Ich hätte, wie gesagt, an Stelle von 8 regSet-Aufrufen 6 templateSet-Aufrufe gebraucht, kaum Ersparnis, ich hätte es deutlich besser gefunden, wenn ich pro Device nur einen Aufruf gebraucht hätte, also eine Art Makro. Werde mir bei Gelegenheit noch Mal HMTemplate anschauen.

[martinp876]

@tndx
verstehe ich nicht ganz. In deinem Beispiel setzt du für 1 Device 2 Register je für short und long sowie 2 Peers (self01 und self02).
Wie könnte man das vereinfachen... Gedanken...
Template erlaubt dir ein Template für short UND long oder short ODER long zu erstellen. Diese Entscheidung muss man immer treffen - die Granularität wird geändert.
short UND long (both) beeinflusst Register eines Peers eben für langen und Kurzen Tastendruck "auf einmal". Ich kann also eine typische Rollosteuerung oder dimmer aufbauen. Short fährt komplett, long nur so lange ich drücke.
Das ist übersichtlich. Ich prüfe/liste/stelle dar alle meine Rollos und sehe welche Peers up und welche down bedienen,...
Short oder long nutze ich für Sammeltasten. So nutze ich eine "besondere" FB um alle Lichter abzuschalten - und die Heitung aus. Aber nur bei langem Druck soll alles ausgehen (gute Nacht). Bei einem Kurzen nicht. Also habe ich eine "swNop" template das den Peer "short" ignoriert und einen "swOff" welche ich bei "long" einsetzen - für diesen Peer.
=> ist also Geschmackssache.

Aber erst einmal musst du wissen, was du willst.
Das Festlegen des Templates ist ein Kommando. Mit HMTemplate natürlich mehrere Clicks. Du musst die Register zusammenclicken... Ich weiss ja nicht, was du willst.
In HMTemplate ist es am Einfachsten beim Erstellen, wenn du die Register aus einem Device importierst.
1) defTmpl: Enter mode define template (Name muss erst einmal angegeben werden)
2) attr tpl_type:nur short oder long? Both? oder "nicht-peer-register"?
2a)  refresh browser (unschön -aber die Attribute-Optionen werden sonst nicht erneuert)
3) attr tpl_source: von welchem Device willst du die Parameter holen
3a)  refresh browser (unschön -aber die Attribute-Optionen werden sonst nicht erneuert)
4) attr tpl_peer: welcher Peer soll als default herhalten
4a)  refresh browser (unschön -aber die Attribute-Optionen und Readings werden sonst nicht erneuert)
=> alle in frage kommenden Register sind in den Attribute enthalten.
5) lösche alle Register-attribute welche nicht im Template enthalten sein sollen
6) setze die Register-attribute auf die Werte, welche du genau so haben willst.
7) tpl_description setzen - Beschreibung deiner Wahl
Optional
wenn du Parameter haben willst (Einschaltzeit eines Treppenhausschalters,... ) in tpl_params setzen. Also einen Namen für den Parameter
9) setze den Namen den Parameters als Registerwert.
Optional Ende
10) set save oder set saveAs (erstelle eine Kopie)
11) set dismiss  - Ende definition

[tndx]

Hi Martin,

ohne jetzt Deine detaillierte Anleitung ausprobiert zu haben, mein Use Case ist der folgende:

ich habe einen Jalosieaktor und will aus ihm einen Rolladen-Aktor machen. Mich würde als Endanwender gar nicht interessieren, dass es long- und short-Press-Ereignisse gibt und dass es 2 Peers zu ändern gilt. Ich will entweder sagen "mache aus Jalousie-Aktor einen Rolladen-Aktor" oder "klicke in der Oberfläche bei bestimmten Feldern bestimmte Werte an", Rest interessiert mich als Endanwender nicht... Und an der Stelle empfinde ich die Templates als zu starr. Ist aber nur meine persönliche Meinung, bitte nicht übel nehmen

Die Anleitung schaue ich mir aber bei nächster Möglichkeit genau an, versprochen!

[Thorsten Pferdekaemper]

Hi,

ich habe jetzt eine ganze Weile überlegt, wie man das ganze hier etwas "moderieren" könnte. So richtig weiß ich aber auch nicht. Mir fällt momentan etwas schwer, den Zusammenhang der Diskussion über die Templates mit dem eigentlichen Thema des Threads zu finden. ...aber vielleicht gelingt das ja noch.
Leider habe ich momentan auch kein HM-Funk-Testsystem und auf meinem Produktiv-FHEM spiele ich nicht herum. Screenshots will mir auch keiner schicken. Also weiterhin erstmal alles theoretisch.
Wenn ich mir die Doku über die Templates ansehe, dann sieht es so aus, dass man erst einmal zwei weitere Instanzen (HMInfo und HMTemplate) anlegen muss, um das überhaupt verwenden zu können. Das mag im Einzelnen einfach sein, aber zumindest für mich ist es konzeptionell einfacher und verständlicher, das im Gerät so einzustellen, wie ich es brauche.

Ich sehe auch nicht wirklich ein, warum man ein Device nicht am Device konfigurieren sollte, sondern eine Ebene höher. Wenn ich bei einem Heizungsthermostat z.B. das Button-Lock setzen will, dann ist meiner Meinung nach der natürliche Weg, das Ding in FHEM aufzurufen und die zugehörige Einstellung zu ändern.
Ich bin auch nicht unbedingt der Meinung, dass der Zustand in FHEM unbedingt führend ist, wenn es um Registerwerte geht. Wenn ich etwas am Device selbst ändern kann und das auch tue, dann erwarte ich von FHEM, dass es diesen neuen Zustand auch anzeigt. Anders gesagt: Für mich sind die Werte in den EEPROMs der Devices führend, nicht die in FHEM. Es kann natürlich (Fehler-)Zustände geben, bei denen es gut ist, wenn man einen gespeicherten Zustand wiederherstellen kann, aber für mich ist das nicht der Normalfall und auch keine essentielle Funktion. Normalerweise funktionieren die Geräte ja ganz gut und vergessen ihre Einstellungen nicht.

Ansonsten finde ich die Idee der Templates im Prinzip gut. Mich wundert aber nicht, dass die Dinger kaum jemand verwendet: Experten brauchen sie nicht und Anfänger verstehen sie nicht oder suchen erst gar nicht danach (warum auch?). Anders gesagt: Es ist für alle einfacher, ohne Templates auszukommen.
Meiner Meinung nach könnte man das aber ändern, womit wir wieder beim Thema wären. Meine Idee sieht ungefähr so aus, ohne dass das sonderlich durchdacht ware und ohne mal auf den Aufwand zu achten.

• Wir finden einen Mechanismus, über den man Templates "ausliefern" kann. D.h. es sollte für alle gängigen Anwendungsfälle ein Template geben.
• Die Devices bekommen in FHEM eine Konfigurationsoberfläche ähnlich wie bei HM-Wired.
• In der Konfigurationsoberfläche weißt man dem Device/Kanal/Peering geeignete Templates zu. Z.B. sagt man dort "dieses Peering ist ein Treppenhausschalter". Möglicherweise kann man sogar Defaults hinterlegen. Wenn man z.B. einen Taster mit einem Rollladenaktor peert, dann ist meistens klar, was man will.
• In der Oberfläche kann man dann (vor Allem) die Parameter der Templates ändern. (Ich glaube verstanden zu haben, dass man momentan die Werte im Template selbst ändert. Das kommt mir aber so abstrus vor, dass ich da von einem Missverständnis meinerseits ausgehe.)
• Wenn der Benutzer unbedingt will, dann kann er in einen Expertenmodus schalten, durch den alle Register eingabebereit werden. Im Prinzip könnte man das sogar mit Hilfe eines "Experten-Templates" implementieren, bei dem alle Register als Parameter zur Verfügung stehen.

Ich würde davon ausgehen, dass so etwas breite Verwendung finden würde.

Ich habe momentan noch ein paar Sachen für Wired offen, die ich noch erledigen will, aber danach habe ich mir vorgenommen, mal ein HM-Funk-Testsystem zusammenzubasteln. In Perl geht ja so einiges, da kann man das ganze vielleicht als Zusatzpaket "oben drauf" packen. Wie Martin sagt ist ja im Back-End alles vorhanden, wie z.B. regList, regTable etc.

Gruß,
    Thorsten

[FranzB94]

Hi!
Ich setzt erst seit einigen Wochen HM-Dimmer und Schalter ein. FHEM mit HM und FS20 ist bei mir aber schon längere Zeit in Betrieb. Um in die Möglichkeiten von HM tiefer einzusteigen, habe ich mich in den letzten Tagen mit der command.ref, dem WIKI und dem Pdf Heimautomatisierung mit fhem beschäftigt.
Martin hat bei der Entwicklung der HM-Module mMn unbestritten viel geleistet. Leider kann er die Theorie und Sachverhalte nicht so rüberbringen, das sie von Anfängern und Fortgeschrittenen (bin selbst seit Jahrzehnten Dipl.-Ing.) verstanden werden. Vielleicht könnte er sich bemühen, die Beschreibungen logischer aufeinender aufzubauen. Man hat manchmal den Eindruck es wird aufgeschrieben, was ihm gerade in dem Moment einfällt, ohne auf den Kontext zu achten. Das ist natürlich für das Verstehen des Zusammenhanges nicht gerade förderlich.
Da Deutsch nicht seine Muttersprache ist, gibt es oft ungewöhnliche Sätze, die zum Verständnis des Sachverhaltes auch nicht gerade beitragen.
So kann man auch oft keine Verbesserungstexte vorschlagen, da man selbst noch Mühe hat, den techn. Zusammenhang zu verstehen.

Gruss Franz   

[martinp876]

Da stimme ich Thorsten schön Mal nicht zu.
Was du auch immer unter "führend" verstehst, für mich ist führend, was ich setzen will. Nicht was gesetzt ist. Punkt.
Es ist möglich, dass das setzen nicht funktioniert. Muss ich alles nachsehen? Bullshit.
Ein Experte braucht keine Templates? Auch Blödsinn ( sorry). Auch ein Experte will ein settings das er erfunden hat kopieren. Er will prüfen, ob es auch im eprom angekommen ist. Das macht das template, hminfo.
Die Nutzung durch Anfänger ist doch nur ein kleiner Teil.
Mir ist nicht klar, warum keiner das sehen kann. Ich habe devices getauscht und reseted. Alles einfach mit Templates.
Ich habe mir ein verhalten definiert. Das setze ich jetzt immer wieder ein. Und das obwohl ich glaube kein Anfänger in hm zu sein.
Aber ihr seit in guter Gesellschaft. Rudi wollte überhaupt keine Register in fhem. Konfiguration. Ist extern von fhem, so vor 4 Jahren. Prof Henning ist\war der Meinung, dass man von devices kein ACK braucht. Man sieht schon, wenn es funktioniert. Hier ist es das gleiche. Nun, ich brauche beides und habe die Register implementiert.
Da Templates nicht Teil des devices sind sind sie eine Ebene höher angesiedelt.
Hminfo braucht man, da es alle hmrf devices kontrolliert. Wer das anders macht braucht es nicht.
Um einen Editor zu haben und Attribute nutzen zu können -definiert- braucht man eben ein eigenes device. Nach dem editieren kann man es löschen.
Fhem Bordmittel bieten hier nichts.

Hm scheinbar brauche nur ich Templates. Genau wie hminfo, actiondetector oder Register selbst.
Sorry, wie du merkst verstehe ich die Diskussion ob oder nicht template schlicht nicht. Das wie könnte man diskutieren.
Scheinbar alles unnötig in hmw

[martinp876]

@franz
Hast du hminfo eingerichtet?
Welchen Teil verstehst du nicht?

[Pfriemler]

@Thorsten: Ich liefere gern Screenshots, aber vor Montag habe ich nicht genug Zeit, um mal ein Template mit zwei "Spielgeräten" zu benutzen und das zu dokumentieren.

Ich bin in vielem bei Thorsten. Zum Beispiel bei Einstellsachen beim Device. ButtonLock, ledMode, Einschalten bei Stromwiederkehr - alles sollte ganz einfach einstellbar sein.
Verknüpfungen: vom Template beginnend verfeinern. Martin sagt richtig: Der User möchte einen Effekt, ohne Hintergrundwissen. Also Auswahlboxen: Aktor, Aktion, Partner, Parameter, abschicken. Am liebsten ohne sich noch darum zum kümmern wie das Template überhaupt genau heißt. Es muss über seine funktionserklärende Beschreibung allein identifizierbar sein. Änderungen: alle Boxen vorbestückt, einen Parameter ändern, abschicken. Wenn es gefällt, so kopieren auf zweiten Aktor und zweiten Peer. Oder es geht so einfach, dass man es im Kopf hat und onthefly nachbaut. Aktor entkoppeln, durch neuen ersetzen: Knopfdruck.
Die CCU2 verwaltet nicht ohne Grund Verknüpfungen in einem eigenen separaten Menü. Links der eine, rechts der andere Partner. Kann meinetwegen auch oben/unten sein. Haben wir einen auch nur annähernd so komfortablen Mechanismus? Wir könnten es noch besser: mit den Feinheiten direkt in der Verknüpfung. Ist es logisch, dass die Funktion des Tastendrucks im Aktor gespeichert wird? Nein. Technisch ist es perfekt so, logisch will der User bei der Taste sehen, was ihre Betätigung in der Verknüpfung bewirkt.
Wenn das alles easy mit den Templates wie bisher funktioniert, dann habe ich es bis jetzt nicht kapiert. Aber ich schaue es mir erst nochmal an. Eben wie man ein template anwendet, verifiziert, später prüft und/oder restauriert. Wenn ich das kapiert habe, melde ich mich hier wieder mit Vorschlägen wie es besser sein könnte.

Um das ganze verständlich machen zu können, kann man jetzt schon helfen. Gerade für das Wiki habe ich eine Reihe Ideen, wie man es besser ordnen und bündeln kann. Aber dazu anderswo mehr.

Unabhängig davon: Ursprungsgedanke war die "ich-klick-mir-eine-Config-aus-möglichen-Werten-zusammen"-Idee. Derzeit klicke ich das im Kopf zusammen: sg, lg,On,Off,Dly,Min,Max,Dim,Jt,Ct - wenn man es verstanden hat und zwanzigmal geschrieben, dann erahnt man den passenden Begriff intuitiv. Bin ich nicht sicher, mache ich "get regList", und merke mir den richtigen Begriff. Trage ihn von Hand ein. Schon ein copy&paste ist mühsam. Nein, ich will die Auswahlmöglichkeiten hinter dem Register, mit Kurzbeschreibung, Sollwert, Istwert. Markierung ob übereinstimmt oder nicht.

[martinp876]

Warum unbedingt im die Ecke denken.
Ein User ( jeder) will eine Funktion. Natürlich muss er diese kennen. Die braucht einen Namen. Und eine Kurzbeschreibung. Und evtl eine lange in Wiki.
Alles ohne Namen lässt sich nicht verwalten, man kann nicht darüber sprechen. War noch nie eine gute Idee.
Schon damit bin ich bei template.
Ich will am Ende sehen, welche Aktoren/Peers ich gleichgeschaltet habe. Wie kann ich das ohne Namen?

Sich eine Ebene (aus Faulheit) zu sparen ist schlicht unprofessionell und zu kurz gesprungen. Register von einem device zum nächsten zu kopieren ist schon lange eingebaut. Das empfehle ich allerdings nie, das ist etwas für Profis.

Wenn ich einen Datensatz habe der funktioniert will ich den mehrfach nutzen. Der muss also ausserhalb des devices verwaltet werden. Alles andere ist gemurxt. und es tut doch nicht weh.
Es ist sträflich, alles in eine Ebene pressen zu wollen. Es gibt scheinbar einige welche hminfo nutzen um die Sinnhaftigkeit der Installation zu prüfen. Nicht pro device sondern in einem Zug.

Sorry, wenn ihr das alles flach machen wollt kann ich mich nicht erwärmen. Das ist für mich zu weit weg von guter professioneller sw Architektur. Das ist tiefer Bastlerlevel. Nichts für ungut. Gute sw ist hierarchisch und hat layer.

[papa]

Ich denke, dass beide Mechanismen - direktes einfaches Ändern von Regsitern und vordefinierte, wiederholbare Templates - benötigt werden. Bei der Verknüfung von Peers spielen die Templates voll ihr Stärke aus. Aber gerade beim Ausprobieren oder schnell mal z.B. die Zeit ändern, würde das direkte Interface zu den Registern einfach von Vorteil sein.
Wenn ich mir was wünschen dürfte - hätte ich gerne eine grafische Oberfläche, welche die Verbindungen zwischen Geräten visualisiert. Etwas sowas wie das hier

http://visjs.org/examples/network/nodeStyles/images.html

Auf den Geräten könnte man die Register für List0 & List1 anpassen. Die Kanten sind die Funktionen der Verknüfung - sprich die Templates. Hier könnte man vorhandene Template-Parameter anpassen oder in den Experten-Modus zum direkten Bearbeiten der Register wechseln. Neue Verknüpfungen werden durch Anlegen neuer Kanten inklusive Auswahl der Funktion (Template) erzeugt.

[Thorsten Pferdekaemper]

Hi,
wieder einmal gäbe es zu jedem der einzelnen Punkten viel zu sagen, aber das ist wahrscheinlich nicht wirklich zielführend. Ein paar Punkte möchte ich aber kommentieren.

Da stimme ich Thorsten schön Mal nicht zu.

Ich glaube, dass wir im Grunde gar nicht so weit auseinander liegen. ...aber sehen wir mal.

Was du auch immer unter "führend" verstehst, für mich ist führend, was ich setzen will. Nicht was gesetzt ist. Punkt.
Es ist möglich, dass das setzen nicht funktioniert. Muss ich alles nachsehen? Bullshit.

Ich sehe ein, dass das für Dich so ist und dass Du Dich wunderst, wenn man es anders sieht. Im Prinzip wollte ich nur sagen, dass man es auch anders sehen kann, nicht dass man es anders sehen muss.

Ein Experte braucht keine Templates? ...

Das war von mir vielleicht etwas überspitzt dargestellt. Vielleicht kann man es auch so formulieren: Ein Experte kommt möglicherweise gar nicht darauf, dass er etwas vermisst, weil er es auch so ganz gut hinbekommt.

Mir ist nicht klar, warum keiner das sehen kann. Ich habe devices getauscht und reseted. Alles einfach mit Templates.

Mir ist nicht klar, dass Du nicht siehst, dass ich gar nicht gegen das alles bin. Das sind ja alles sinnvolle Funktionen. Ich bin auch nicht gegen die Templates.

Um einen Editor zu haben und Attribute nutzen zu können -definiert- braucht man eben ein eigenes device.

Braucht man nicht. Ich mache das bei Wired auch direkt im Device.

Hm scheinbar brauche nur ich Templates. Genau wie hminfo, actiondetector oder Register selbst.
Sorry, wie du merkst verstehe ich die Diskussion ob oder nicht template schlicht nicht. Das wie könnte man diskutieren.

Meiner Meinung nach verstehst Du nur nicht, dass die Diskussion gar nicht um "Templates oder nicht" geht. Die Frage (Deine Frage!) war eher, warum kaum jemand die Templates benutzt. Die Diskussion geht meiner Meinung nach bereits nur um das "wie".

Scheinbar alles unnötig in hmw

Sagen wir mal: In HMW (noch) nicht implementiert. Das ist aus verschiedenen Gründen aber nicht "schlimm" (soweit ich das sehe):

• Durch die Konfigurationsoberfläche ist die Konfiguration (incl. Peerings) so einfach geworden, dass die Zeitersparnis durch die Funktionen der Templates relative klein wäre.
• Wired ist strukturell einfacher. Z.B. gibt es in Peerings nur Taster und Aktoren. Es gibt zwar Devices, die Analogwerte lesen bzw. ausgeben, aber die kann man nicht peeren.
• Es gibt viel weniger HMW-Benutzer als bei HM-Funk.
• Anscheinend sind die Geräte intern zuverlässiger. Was man mal ins EEPROM schreibt bleibt auch so.

Dennoch wurden schon Wünsche geäußert, die in die Richtung der Templates gehen, wie z.B. das Speichern und Wiederherstellen.

Die CCU2 verwaltet nicht ohne Grund Verknüpfungen in einem eigenen separaten Menü. Links der eine, rechts der andere Partner. Kann meinetwegen auch oben/unten sein. Haben wir einen auch nur annähernd so komfortablen Mechanismus?

Meiner Meinung nach ist es bei HM-Wired ähnlich komfortabel. 

Wir könnten es noch besser: mit den Feinheiten direkt in der Verknüpfung. Ist es logisch, dass die Funktion des Tastendrucks im Aktor gespeichert wird? Nein. Technisch ist es perfekt so, logisch will der User bei der Taste sehen, was ihre Betätigung in der Verknüpfung bewirkt.

Naja, man könnte darüber streiten, wo das logisch hingehört. Ich habe es bei HM-Wired deshalb so gemacht, dass es egal ist. D.h. Du kannst von beiden Seiten kommen und die Details eines Peerings ändern. 

Ich will am Ende sehen, welche Aktoren/Peers ich gleichgeschaltet habe.

Das verstehe ich nicht. Was meinst Du damit?

Sorry, wenn ihr das alles flach machen wollt kann ich mich nicht erwärmen. Das ist für mich zu weit weg von guter professioneller sw Architektur. Das ist tiefer Bastlerlevel. Nichts für ungut. Gute sw ist hierarchisch und hat layer.

Das mit den Layern in der Software hat etwas mit dem inneren Aufbau zu tun, nicht notwendigerweise wie man es dem Benutzer präsentiert. Wir können doch komplett alles so lassen wie es ist, nur der Einstieg für den Benutzer soll einfacher werden.

Wenn ich mir was wünschen dürfte - hätte ich gerne eine grafische Oberfläche, welche die Verbindungen zwischen Geräten visualisiert.

Naja, in der Regel sind halt zwei Kanäle verknüpft. Da sähe die Grafik eher etwas entartet aus. Lauter Inseln mit zwei Kanälen und einer Linie dazwischen.

Gruß,
    Thorsten

[Pfriemler]

So. Nochmal. Ganz. Langsam.
@papa: Die Idee mit der Grafik werden wir hier nicht hinbekommen... aber im Prinzip: Ja. S.u.

@martin: Du wiederholst Dich, und ich wiederhole mich auch. Nochmal:
1. Niemand stellt hier Sinn und Zukunft von HMInfo, HMTemplate und Templates in Frage, auch ich nicht. Es geht um das Wie für den User und damit auch um Optik und Zugriff. Niemand will eine Eben streichen oder etwas "flach machen".

2. Der Thread geht eigentlich um komfortables Registerprogrammieren auf der Oberfläche. Thorsten demonstriert das auch optisch auf HMW, und die CCU2 hat das auch eingebaut. Dass das im Detail dann hinter den Templates vorbeigeht und den Sicherungs-und Prüfmechanismus ad absurdum führt, ist mir auch klar. Aber wir sollten das Risiko beim User lassen. Wobei das kein wirkliches Risiko sein muss, wenn man tiefer denkt - aber dazu ein andermal.
Mir persönlich würde ja schon reichen, wenn hinter regSet eine Dropdownliste der in diesem Kontext erlaubten Register erscheint und nach deren Auswahl die Funktionsbeschreibung angezeigt und ein weiteres Dropdown mit den erlaubten Werten für dieses Register. Dennoch hat eine auf die reine Gerätekonfiguration beschränkte Tabelle wie Thorstens HMW zusätzlichen Charme. Dort bitte NICHT die Peerkonfiguration, denn die ist in einem separaten Verknüpfungseditor viel besser aufgehoben. Dennoch wäre es chic, von dort per Klick zum Verknüpfungseditor zu kommen, der aber logisch auf einer anderen Ebene (über den Devices) liegt.

3. Ja, ich will eine Zentralebene zur Administration, globalen Datensicherung, Verknüpfungsüberprüfung etc. "am Stück". Das auf Device-Ebene herunterzulegen wäre blöd, natürlich, was sonst.

4. Und ja, ich möchte - und das ist eine andere Baustelle als das hier - einen Verknüpfungseditor. Wenn wir konsequent denken, hat schon das peerChan auf Deviceebene nichts verloren. Der Verknüpfungseditor hingegen erstellt und löscht ggf die Verknüpfungen, und dort werden sie mit Templates voreingestellt, feingetunt (was u.U. nur das Anpassen der Variablen der Templates bedeutet). Ab hier ist es eine interne Designfrage, ob diese Verknüpfungen nur als angewendete Templates mit Variablen gespeichert werden oder ob die hier per Expertenmodus zukonfigurierten Extrawürste Bestandteil eines konkret devicebezogen Soll-Registersatzes (also beide List3) werden. Ideal, wenn man an genau dieser Stelle aus der Feinkonfiguration ein User-Template erstellen kann.
Auch wäre gut, wenn man mit wenigen Handgriffen ein nicht mehr verfügbares Device aus einer Verknüpfung (durch Defekt oder Löschung) durch ein anderes ersetzen kann. Das ist eine Funktion, die sicher noch öfter benötigt werden wird, wenn die ersten HM-Geräte durch Alterung dauerhaft ausfallen (ich sage nur "C26").
Übrigens: Etliches davon kann Martins Template-Editor jetzt bereits, und die Mechanismen dahinter stehen auch schon längst bereit.
Und dieser Verknüpfungseditor sollte nur einen Mausklick entfernt vom Device erreichbar sein, genauso wie man heute schon mit "Probably associated with" zu einem mit Notify, DOIF, SVG oder sonstewas verknüpften anderen Device wechselt,

5. Es ist ebenso eine interne Designfrage, ob man List0 und List1 auf Geräteebene komfortabel editieren kann oder ob man auch hier einfach Templates anwendet (mit dem Zusatznutzen, dass die Sollkonfig gespeichert und kontrolliert werden kann). Wenn man hingegen Name und Icon in FHEM am Device einstellen muss, aber für eine simple Funktionsprogrammierung in die übergeordnete Ebene wechseln muss, um von dort ein Template auf das Device anzuwenden, das ist DAS um die Ecke gedacht. Das kann ja im Hintergrund so geschehen, sollte für den User aber nur einen Mausklick entfernt sein. 

6. Ich habe nie von namenlosen templates geredet. Ich meine nur, dass ein für den User sichtbares Template bspw. nicht "TreppeAutomat" oder "BewMelder" heißen sollte, sondern "Treppenhausfunktion" - oder "Treppenlichtautomat", wie genau meinte ich ist egal - der User soll nur sofort erkennen können was gemeint ist. Dafür können auch drei oder vier Wörter nötig sein, wie "Zeitbegrenztes Einschalten bei kurzem Tastendruck". Letzteres wäre ein ziemlich sperriger Name für eine Templatedatei. Die Analogie dazu wäre die von Device-Namen und Device-Alias: Der Name ist eindeutig, aber der User sieht und benutzt den Alias. Bei den Modulnamen und ihren .pm ist es auch ähnlich.

[Pfriemler]

und noch ein paar Sachen hinterhergeschoben, statt edit:
zu 4.: Verknüpfungseditor: peerChan erstellt ja eine Verknüpfung und wendet ein (wo eigentlich?) festgelegtes Schema an, schon unterschiedlich ob ein oder zwei Tasten verknüpft werden. Das geschieht derzeit teilweise fehlerhaft, etwa bei der Kombi von Schaltaktor und Fensterkontakt oder Wandthermostat und Schaltaktor. Schon deshalb fände ich es sinnvoll, gleich beim Erstellen der Verknüpfung anzugeben, was erreicht werden soll. Wenn dort also bereits die Templates "bei Fuß" stehen, werden sie sicher auch gern angewendet.

Übrigens ist die Verknüpfung Wippentaster <-> Aktor schon eine dreiseitige: Dem Aktor stehen zwei Tasten mit unterschiedlichen Funktionen gegenüber, deren Funktionsbeschreibung besser (nur) dort sichtbar ist. Nicht umsonst fragen User ständig, wie sie den Taster programmieren müssen um das oder das zu erreichen. Wenn ich da drücke, soll das und das passieren. Also sollte man es auch optisch dort einstellen können. Genau das kann ein Verknüpfungseditor leisten. Der derzeitige Zustand ist doch ein Horror: ich suche in den ellenlangen Registerlisten eines mit zwei Wandtastern und zwei Fernbedienungen gepeerten Dimmers nach der Rampenzeit für das Dimmen bei kurzem Tastendruck mit der Suchfunktion des Browsers effizienter als mit den Augen allein.

Kann nur nochmal raten: die CCU2 hat m.M.n. viele sinnvolle und verständliche Dialoge zur Konfiguration (natürlich fehlt ihr auch vieles). Nicht wenige hier sind auch deswegen zur separaten CCU2 und zap's HMCCU gewechselt. Was gut ist, sollte man nachbauen oder sogar verbessern.

und zum Thema spontane Registerfehler: Der bisher einzige Fehler, der mir je aufgefallen war, hat die HMID eines Gerätes im laufenden Betrieb geändert. Für FHEM und configCheck was das alte Gerät weg und ein neues da, inklusive Autocreate. Korrigiert konnte da nichts werden. War auch nicht nötig, nach einem provozierten Stromausfall am betroffenen Gerät und dem Reboot war alles wieder korrekt.