Oberfläche zum Ändern von Registerwerten

[papa]

Hallo Martin,

siehst Du eine Möglichkeit, das Ändern von Registern über die Weboberfläche zu unterstützen. Thorsten hat da für Homeatic-Wired einiges implementiert.

https://forum.fhem.de/index.php/topic,72728.msg703451.html#msg703451

Vielleicht lässt sich ja was davon wiederverwenden. Ich fände es schon praktisch, wenn mal man schnell ein Register per WebUI anpassen könnte.

Grüße
  Holger

[Thorsten Pferdekaemper]

Hi,
übrigens geht das bei Wired auch für Peerings. D.h. man muss zwar die Peerings noch per "set..." anlagen, aber dann kann man über eine ähnliche Eingabemaske die ganzen Werte setzen, wie z.B. die an-/aus-Zeiten.
Ich kann gerade keinen Screenshot machen, aber wenn das hier tatsächlich was wird, dann liefere ich das natürlich noch nach.
Gruß,
   Thorsten

[Pfriemler]

JAAA! Der Expertenmodus der CCU2 lässt grüßen! Den vermisse ich schon seit Anbeginn. Das öffnet zwar der Dekonfiguration durch Anfänger Tor und Tür, ermöglicht aber auch den weniger kommandozeilenaffinen Menschen ein Arbeiten ohne zweites Fenster (in dem die regList steht). Die Infos sind ja alle vorhanden.
Auch wenn es viel Arbeit wäre, es wäre toll. Allerdings schätze ich die Komplexität viel höher ein.
Aus dem Link: XML statt HMConfig.pm? puuuh ... eins nach dem anderen?

[papa]

Aus dem Link: XML statt HMConfig.pm? puuuh ... eins nach dem anderen?

Ohne jetzt den Code zu kennen, müsste man sich hier bestimmt auf eine Zwischendatenstruktur einigen, die sowohl aus den XMLs und aus der HMConfig erstellt werden kann. Diese wird dann für das UI verwendet. Entsprechend müsste auch das "Save" spezifisch umgesetzt werden.
Keine Ahnung, wie einfach oder aufwändig das ist.

[Pfriemler]

Das meinte ich gar nicht in Bezug auf die geänderte Oberfläche, sondern mehr wegen der mehr oder weniger händisch den ohnehin vorgegebenen XML (so denke ich zumindest) nachgezogenen HMConfig, die als Informationsquelle aber an sich ausreichend ist. Register und Werte werden ja bereits in der Oberfläche dargestellt. Save müsste dann den gesammelten Satz quasi zusammenfassen und am Stück schreiben, was beim Restore ganzer Listen auch längst unterstützt wird und bei manchen Aktionen (etwa wenn mehrere Register in einem Byte zusammengefasst sind) ohnehin passiert. Will sagen: das meiste ist mehr oder weniger schon da.

[Thorsten Pferdekaemper]

Hi,
das ganze läuft auch jetzt schon in HM485 über eine "Zwischenstruktur". Im Modul gibt es z.B. ein "get ... config", welches eine JSon-Struktur liefert, die die Parameternamen, Datentypen und Werte enthält. Das, was man auf der Oberfläche sieht, ist ein bisschen JavaScript, welches dieses JSon zu der Eingabemaske macht. Auf dem Weg zurück (also bei "save") bastelt das JavaScript dann ein "set ... config ..." zusammen, mit dem die Daten wieder ins Modul geschoben warden.
Das "get ... config" und "set ... config" ist natürlich etwas Wired-spezifisch, aber da könnte man ja leicht noch einen kleinen Layer dazwischenschieben.
Gruß,
   Thorsten

[Thorsten Pferdekaemper]

Hi,
also entweder ist Martin im Urlaub oder hat kein Interesse.
@Martin: Falls Du das liest, könntest Du sagen, ob Du prinzipiell Interesse daran hast? Es erwartet wohl niemand, dass Du das einfach (alleine) einbaust, aber ohne Dein ok als Maintainer bringt es eher nichts, wenn z.B. ich mir das genauer betrachte.
Gruß,
   Thorsten

[CoolTux]

Wenn nicht einfach kurz ne PN an Martin mit Link auf den Thread.

[Thorsten Pferdekaemper]

Hi,
inzwischen habe ich Martin erreicht. Er hat zu dem Thema die Templates in den Raum geworfen. Soweit ich es verstanden habe wären ihm die Templates in dieser Hinsicht wichtiger als die eigentlichen Devices. (@Martin: Bitte korrigieren, wenn ich das falsch verstanden habe.)
Ich habe daraufhin mal alles zu den Templates gelesen, was mir wichtig erschien. Allerdings habe ich sie nicht selbst ausprobiert, weil ich HM-Funk nur in meinem Produktiv-System habe und da nicht herumspielen will. (Vielleicht muss ich mir doch auch mal ein HM-Funk Testsystem aufbauen.) Kann mal jemand ein paar Screenshots zu den Templates machen und hier einstellen?

Ich habe das mit den Templates grob so verstanden, dass man sich ein paar Templates zusammendefiniert und diese dann verwendet, anstatt direkt in den Devices die Konfiguration zu ändern. Z.B. kann man dann für einen Aktorkanal sagen "Du bist ein Treppenlicht mit 90 Sekunden" anstatt die Register einzeln zu setzen. Das klingt ja erstmal ziemlich gut, auch wenn ich es bisher dank verständlicher Doku im Anfänger-PDF nicht vermisst hatte.

Ein paar Punkte finde ich allerdings (noch) nicht so gut:

• Man kann die Templates nicht im Device selbst verwenden, sondern nur von HMInfo aus.
  
• Man muss sich die Templates erst einmal selbst definieren. Es wäre schöner, wenn es mit der "Auslieferung" schon eine gewisse Liste von Standard-Templates gäbe.
• Es gibt auch für Templates keine echte Benutzeroberfläche wie bei HM-Wired. (Da bin ich mir noch nicht so sicher, daher würde ich gerne ein paar Screenshots sehen.)

Wenn ich persönlich jetzt die Templates (bzw. was ich davon verstanden habe) und der Wunsch nach einer HMW-ähnlichen Oberfläche für HM-Funk "verheiraten" sollte, dann würde ich in etwa folgendes vorschlagen:

• Wir liefern einen Satz von Standard-Templates aus
• Die Devices/Kanäle/Peerings bekommen eine Benutzeroberfläche ähnlich wie bei HMW.
• In der Benutzeroberfläche kann man sowohl Templates auswählen als auch direkt Register setzen. (Z.B. über einen Normalo-/Expertenmodus-Schalter.)
• Wenn Templates ausgewählt wurden, dann kann man die Parameter der Templates (ebenfalls) über die Benutzeroberfläche setzen.
• Das Erstellen der Templates selbst würde ich erst einmal in Ruhe lassen. Das ist dann eher etwas für Experten.

Klingt das sinnvoll?

Gruß,
    Thorsten

[Pfriemler]

Ohne selbst jemals aktiv mittun zu können mangels Wissen und Ressourcen, rede ich aber gern mit:

Alle 5 Punkte würde ich glatt unterschreiben.

Die Templates sind im groben "Programmiermakros", die aber für den Ungeübten mindestens genauso unhandlich sind wie eine reine Registerprogrammierung mit "regSet". Allerdings setzen sie eine Reihe von Registern gleich passend, richtig. Für mich sind sie keine Ersatz zur erweiteren Oberfläche, sondern eine Ergänzung. Wenn Du das so meinst: genau.

Es gibt auch bereits einen Template-Editor, mit dem bestehende Templates laden, die gewünschten Geräte auswählen, mit passenden Werten bestücken und dann auf die Geräte anwenden kann. Das ist schon etwas freundlicher, will aber auch erst gelernt sein. Im Grunde könnte diese Funktionalität voll in Deine Vorschläge integriert werden.

Zum Template-Erstellen gibt es angeblich noch andere Möglichkeiten, z.B. per Register vorher-nachher-Vergleich. Aber ein gutes Rudel sinnvoller Templates "ab Werk" anzubieten wäre extrem wichtig. Ein paar gibt es ja schon.

[Thorsten Pferdekaemper]

Ohne selbst jemals aktiv mittun zu können

Vielleicht doch: Du scheinst schon was mit den Templates gemacht zu haben. Könntest Du mal ein paar Screenshots zeigen?
Gruß,
   Thorsten

[martinp876]

habt ihr das durchdacht? Was ist der Sinn von templates, was sind dessen Addons? Ich denke die Betrachtung ist nicht komplett.
Ich hole einmal aus:

• Register sind Configurationsdaten. So etwas sollte man sichern.
• Attribute sind Configurationsdaten - die hat FHEM in der Hand. Man definiert, gut ist es
• Register sind extern, können sich verändern... man braucht also einen Soll- und einen Ist- Wert
• Register gehören nicht in Attribute und sind auch keine Readings. Vor ~4 Jahren ist mein Antrag abgelent worden, eine Config-Gruppe einzuführen. Seitdem bastle ich darum herum.
• Was ist also  notwendig? Welche Funktionen werden benötigt (Templates hin oder her):


• Funktion verify - sind alle Register wir geplant gesetzt
• Funktion execute - setze alle Register, (falls diese nicht schon korrekt sind)
• Funktion Sichern - speichere meine Config
• Funktion kopieren - erstelle eine kopie der Funktion

Templates sind das Mittel meiner Wahl. Aktuell wird ein Satz tempates ausgeliefert. In der Tat sind Tempaltes nichts für Anfänger. Das gilt für alle Register. Wer Register modifiziert kann auch templates erstellen.

Aus meiner Sicht sollte also Anfänger ausschliesslich Tempaltes nutzen. Es sollten alle gängigen/notwendigen in einem Repository zu Verfügung stehen. Bspw in Wiki.
Ein Anfänger kopiert das Template in das System und muss es nur noch zuweisen. Warum das (m.E.) gut ist? Es hat schon seinen Grund, warum es eq3 ebenso macht. Mittlerweile kann man auch dort Templates selbst erstellen.

Mir ist nicht klar, wer schon den Template editor (HMtemplate) ist sicher nicht so hübsch wir das HMW Frontend. Allerdings werden auch nicht - mit ausschliesslich FHME bordmitteln - Auswahllisten für alle Register angeboten. Habt ihr schon probiert? Unschön, dass man gelegentlich einen Reload der Webseite machen muss - der Rest ist drin.
Konkret: Wer hat schon ein template mit HMtemplate erstellt? HMInfo zählt nicht - das ist in der Tat kompliziert.

Template haben weiter den Vorteil, dass man Variablen nutzen kann. So kann ich einfach und abstrakt die Schaltzeit des Treppenhausschalters modifizieren. Oder (zwei Variablen) die Kombination BM mit Dämmerungswert und Einschaltdauer.

Ich gehe davon aus, dass kaum einer den BM korrekt aufsetzt. Man will typisch bei Bewegung schalten - aber bei Tastendruck übersteuern und entlos einschalten. Das zu erklären ist hinfällig und interessier den "normalen" Nutzer schlicht nicht. Er will diese Funktion und setzt sie als "normal" voraus.
"normale" Nutzer sind keine FHEM programmierer, wollen nicht mit dem Code sondern den Funktionen spielen. Register wollen sie nicht kennen. In FHEM sind viele "Spieler" unterwegs.
=> Registermanipulation ist etwas für "Experten"
=> Templates ist etwas für "User"

Schön wäre es, wenn nicht jeder(jedes System) ein eigenes Frontend in FHEM bauen muss um alles etwas schöner und etwas anders zu machen.

[papa]

Ich muss jetzt ehrlicherweise zugeben, das HMtemplates bisher komplett an mir vorbeigegangen sind. Muss ich mir erst mal ansehen, um mir eine Meinung zu bilden. Du hast ebenfalls Recht, dass Register extern sind und nicht ganz einfach zu handhaben sind.

Aber das komfortable Ändern von Registern wäre schon nett. Vielleicht bin ich da auch recht speziell. da ich bei Entwicklern von HM-Firmware oft mal eben einzelne Register umsetzen muss, um deren Funktionalität zu testen. Der "normale" User wird sicherlich eher einen ganzen Satz von Registern ändern, um bestimmte Effekte zu erzielen. Trotzdem macht es auch für diesen Sinn, eben mal die onTime zu ändern, ohne den ganzen Rest anzufassen.

[Pfriemler]

Ich möchte mich schonmal entschuldigen für das Zerpflücken, aber ich wollte dieses eine Mal ganz speziell auf einzelne Aussagen eingehen.
Soll nicht zur Regel werden.

Vielleicht doch: Du scheinst schon was mit den Templates gemacht zu haben. Könntest Du mal ein paar Screenshots zeigen?

Könnte jeder beisteuern, bei mir ist gerade die Zeit etwas knapp. Martin erwähnt "HMTemplate", ein eigenes Device sozusagen.
Ist das inzwischen nicht im SVN?

habt ihr das durchdacht? Was ist der Sinn von templates, was sind dessen Addons? Ich denke die Betrachtung ist nicht komplett.

Deswegen diskutieren wir das ja gerade.

Register sind Configurationsdaten. So etwas sollte man sichern.

Dafür gibt es bereits saveConfig bei hm.

Register sind extern, können sich verändern... man braucht also einen Soll- und einen Ist- Wert

Register ändern sich nicht spontan, sie werden konfiguriert.
Was Du meinst, sind die Soll/Ist-Vergleiche über Templates. Wurde ein Template gesetzt und nachträglich Register geändert?

In der Tat sind Tempaltes nichts für Anfänger. ... Aus meiner Sicht sollte also Anfänger ausschliesslich Tempaltes nutzen.

Diesen Widerspruch müsste man mal aufklären.

Mir ist nicht klar, wer schon den Template editor (HMtemplate) ist sicher nicht so hübsch wir das HMW Frontend.

Aber man könnte es dahin weiterentwickeln, darum geht es ja bisher allen hier.

Allerdings werden auch nicht - mit ausschliesslich FHME bordmitteln - Auswahllisten für alle Register angeboten.

Bezüglich HMW? Kann ich nicht beurteilen. Bezüglich HM wäre wünschenswert, dass die Oberfläche alle verfügbaren Register mit allen verfügbaren Werten anbietet. "regList" bereitet die Infos aus der HMConfig ja bereits hübsch auf, der Weg kann so weit nicht sein.

Konkret: Wer hat schon ein template mit HMtemplate erstellt?

Ich. Aber die Zahl der falschen Weichen, die man dahin nehmen kann, ist mir noch zu groß. Jeder der HMTemplate mal genutzt hat, wird das nachvollziehen können.

Template haben weiter den Vorteil, dass man Variablen nutzen kann. So kann ich einfach und abstrakt die Schaltzeit des Treppenhausschalters modifizieren. Oder (zwei Variablen) die Kombination BM mit Dämmerungswert und Einschaltdauer.

Das kann ich voll unterstreichen. Das macht ja auch den Sinn von Templates überhaupt aus.

Ich gehe davon aus, dass kaum einer den BM korrekt aufsetzt. Man will typisch bei Bewegung schalten - aber bei Tastendruck übersteuern und entlos einschalten.

Das muss nicht immer so sein - und deshalb gehört das gewünschte Tastenverhalten ebenfalls als Variable ins Template.

"normale" Nutzer sind keine FHEM programmierer, wollen nicht mit dem Code sondern den Funktionen spielen. Register wollen sie nicht kennen.

Jein. Martin, es macht absolut Sinn, für viele Standardanwendungen Templates zu benutzen. Aber gerade die Spieler wollen vielleicht auch Templates versuchsweise modifizieren und nicht immer alles "drüberbügeln". Dafür wäre ein geführter Expertenmodus, wie ihn die CCU2 anbietet und wie ihn Thorsten für HMW gebaut hat, empfehlenswerter als jeder "regSet-Einzeiler". Wenn das schon Experten sind, dann bin ich eben einer.

Schön wäre es, wenn nicht jeder(jedes System) ein eigenes Frontend in FHEM bauen muss um alles etwas schöner und etwas anders zu machen.

Der Vielfalt, die gerade HM bezüglich der Registermanipulationen bietet, wird FHEM derzeit in keiner Weise gerecht. Die Oberfläche muss ja auch nicht der Standard werden. In der CCU2 heißt das Ding "Expertenmodus" und wird normalerweise vor dem User versteckt.

[tndx]

Hallo zusammen,

ich hatte mich mal bei diesem Thema mit den Templates beschäftigt (https://wiki.fhem.de/wiki/HM-LC-Ja1PBU-FM_Funk-Jalousiesteuerung):

Tasterbelegung

Die Taster beim HM-LC-Ja1PBU-FM sind anders belegt als beim HM-LC-BIPBU-FM, identische Tasterbelegung lässt sich mit folgenden Befehlen erreichen:

set <name> regSet lgMaxTimeF 0.4 self01
set <name> regSet lgMultiExec on self01
set <name> regSet shMaxTimeF unused self01
set <name> regSet lgMaxTimeF 0.4 self02
set <name> regSet lgMultiExec on self02
set <name> regSet shMaxTimeF unused self02

Ich bin pro Peer auf 2 Templates gekommen je ein Template für long und short, mit dem Ergebnis, dass ich die 6 regSet-Einzelaufrufe auf 4 templateSet-Aufrufe hätte reduzieren können. Mit der Oberfläche zum Ändern der Registerwerte wäre ich, glaube ich, schneller zum Ziel gekommen.

Aber vielleicht habe ich auch nicht das gesamte Potential von den Templates ausgenutzt.