Oberfläche zum Ändern von Registerwerten

[Thorsten Pferdekaemper]

Dieser Beitrag zeigt Homematic Wired! Die erste Preview für Funk ist in Beitrag 42!

Hi,
meiner Meinung nach ist "meine" Oberfläche auch für Peerings ganz gut gelungen. Ich habe hier mal ein paar Screenshots angehängt.

Das erste Bild zeigt, wie man in HMW zwei Kanäle verknüpft. Das ist im Prinzip "Standard-FHEM". Das "set ... peer ..." weiß, welche möglichen Partner es gibt und bietet diese zur Auswahl an. Dabei ist es egal, von welchem Ende man kommt. Das System kümmert sich auch automatisch darum, dass das Peering auf beiden Seiten eingetragen wird.
Der Taster im Bild ist tatsächlich schon mit etwas gepeert, daher erscheint darüber der Knopf "Peering Configuration".

Das zweite Bild zeigt einen ähnlichen Taster nach dem Druck auf "Peering Configuration". Der Taster ist mit vier Aktoren verknüpft, von denen man jetzt einen auswählt.

Dann werden (drittes Bild) alle möglichen Parameter angezeigt und können geändert werden. Mit "Write to Device" wird der Kram dann ins Device geschrieben. Vorher werden die Werte gegen die Definition in den Gerätebeschreibungsdateien geprüft.
Man hätte das ganze jetzt auch von einem der Aktoren aus machen können. Dann hätte man den Taster ausgewählt und wäre genau auf demselben "Formular" gelandet. 

Auf dem vierten Bild sieht man es etwas größer im Detail. Falls in der Gerätebeschreibungsdatei angegeben, werden die möglichen Werte zur Auswahl angeboten.

Vielleicht ist damit auch etwas verständlicher, was ich damit meine, wenn ich die Templates da irgendwie einbinden will. Der Screen mit den ganzen Settings ist natürlich erst einmal ziemlich heftig. An der Stelle könnte man den Benutzer erst einmal auswählen lassen, was das Peering überhaupt können soll. (D.h. man verknüpft das Peering mit einem Template.) Dann bietet man statt der ganzen "Register" die Parameter des Templates an.

Zum "Finden" der Peerings: Ich selbst weiß immer für mindestens eine Seite, wo das Device ist. Da die "Seite" bei mir egal ist finde ich dann auch einfach das Peering.
Aber: Man könnte den "Peering Configuration" (oder "Peering List") Button auch woanders hinmachen, z.B. an das IO-Device (als übergeordnete Instanz), an ein künstliches "Alle Devices" Device oder eben auch an ein Template. Das dürfte nicht wirklich schwierig sein.

Gruß,
   Thorsten

Dieser Beitrag zeigt Homematic Wired! Die erste Preview für Funk ist in Beitrag 42!

[martinp876]

Nur kurz: das Default Peer dual\single ist von eq3 in der fw hart kodiert.
Ich würde Peerchan abschaffen und alles mit peerbulk machen. Der Rest Templates.
Noch besser: peeren ist Teil der Templates. Hat den Nachteil länger Auswertungen.

Tja, nicht alles ist von mir versaut, hier war des eq3.
Und ich sehe schon wieder ein template "Fensterkontakt-Heizung".

[papa]

Ich denke die Defaults in der Firmware werden für das direkte Peering ohne CCU/FHEM gebraucht.

[Thorsten Pferdekaemper]

Nur kurz: das Default Peer dual\single ist von eq3 in der fw hart kodiert.

Ich habe mir die XMLs von HM-Funk noch nicht so genau angeschaut, aber bei Wired sind die Defaults auch meistens im XML angegeben. Allerdings habe ich den Eindruck, dass die Devices manchmal ihre Defaults nicht kennen. Gibt es bei Funk auch solche Effekte?

Noch besser: peeren ist Teil der Templates.

Kannst Du erklären, wie Du das meinst? In meiner Gedankenwelt ist das mit zwei Schritten ganz gut: Zuerst sagt man, was mit was gepeert ist (set ... peerBulk bei CUL_HM bzw. set ... peer bei HM485) und legt danach die Details fest, falls es nicht per Default schon passt. D.h. man weißt ein Template zu (CUL_HM) oder stellt die Register direkt ein (HM485, noch).

Tja, nicht alles ist von mir versaut, hier war des eq3.

Wieso versaut? Du scheinst ja wenig Vertrauen in Deine eigene Arbeit zu haben...

Gruß,
   Thorsten

[marvin78]

Es ist nichts daran versaut (im FHEM Bereich). Die Idee hinter den Templates ist, wie ich finde, genau so, wie es umgesetzt ist, sogar genial. Trotzdem könnte es eine bessere Oberfläche vertragen. Hier liegen wohl aber auch Limitierungen in FHEM, auch wenn man, wie Thorsten zeigt, einiges mehr machen kann, wenn man die Schiene convenience für wichtig genug hält. Zusammengefasst kann man sagen, dass eine Oberfläche genau auf den Templates, wie sie sind, aufbauen müsste um ein intuitives System zu erhalten, welches "Profis" und Anfänger (ich rede von ambitionierten Anfängern, nicht denen, die eine KlickiBunti Oberfläche erwarten, wenn sie sich an FHEM wagen) gleichermaßen mitnimmt.

[martinp876]

Ohne die ganze diskussion gelesen zu haben (sorry)
. korrekt, die oberfläche könnte besser sein. Hatte ich anfangs schon eingeworfen. Sehr unschön ist, dass man 3 mal refreshen muss. weiter unschön, dass der infotext zu den registern nicht sichtbar ist sowie die wertebereiche. Gibt man etwas falsches ein bekommt man allerdings diesen angezeigt.
. unortodox die eingabe ueber attribute. Passt allerdings, denn register sind faktisch attribute der templates.
.optimieren kann man die vergabe von templates... Da immer eine zeitaufwändige suche gestartet wird ist es allerdings beim device schlecht aufgehoben.
. das backend halte ich immernoch für absolut sinnvoll.

Wenn ich es aber weiter oben korrekt verstanden habe hat Thorsten beschlossen die hm oberfläche umzubauen und das modul somit zu uebernehmen.
Hm. Ich kann meine Versionen ja einfrieren und privat weiter machen. Kein Thema.

[papa]

Ich habe das Gefühl, dass das ganze hier zu keinem Ergebnis führt. Scheinbar lässt sich mein Wunsch, eine Oberfläche für das Setzen der Register nicht umsetzen. Somit schließe ich diese Diskussion und bedanke mich bei allen Beteiligten.

[papa]

Thorsten hat mich gebeten, das Thema wieder zu öffnen, da er noch etwas richtig stellen will.

[Thorsten Pferdekaemper]

.optimieren kann man die vergabe von templates... Da immer eine zeitaufwändige suche gestartet wird ist es allerdings beim device schlecht aufgehoben.

Solche Probleme habe/hatte ich auch bei HMW wenn es darum geht, die Liste der möglichen Peers anzuzeigen. Das kann man aber mit Caching lösen.

. das backend halte ich immernoch für absolut sinnvoll.

Ich glaube, das hatte ich auch so ungefähr gesagt.

Wenn ich es aber weiter oben korrekt verstanden habe hat Thorsten beschlossen die hm oberfläche umzubauen und das modul somit zu uebernehmen.

Ähm... Nein. Zumindest habe ich es nicht so gemeint. Auch wenn es für Dich so klingen mag würde ich nichts "gegen" Dich in CUL_HM machen wollen. Ich meinte eigentlich, dass ich mir mal (in den nächsten Wochen irgendwann) ein Testsystem aufbauen werde und das ganze mit den Templates erst einmal ausprobieren will. Dann wollte ich mal sehen, wie weit man kommen kann, ohne Deinen Teil zu ändern.

Ich habe das Gefühl, dass das ganze hier zu keinem Ergebnis führt.

Wieso denn das? Manchmal schreien halt nicht alle gleich "Hurra". Ich finde es sogar besser so, da man die ganze Sache erst einmal von allen Seiten betrachtet. Das ist wesentlich besser als schnell mal was eingebaut.

Scheinbar lässt sich mein Wunsch, eine Oberfläche für das Setzen der Register nicht umsetzen.

Genau. "Scheinbar" ist hier das richtige Wort, auch wenn Du vielleicht "anscheinend" gemeint hast. (Sorry für die Klugscheißerei.) Ich glaube immer noch, dass man das implementieren kann. Die Frage ist nur wie genau, ob über Templates oder direkt etc.

Gruß,
    Thorsten

[Pfriemler]

'woll. Ich wollte auch schon bezüglich der Schließung protestieren. Und ich möchte alle Beteiligten bitten, keine voreiligen persönlichen Schlußfolgerungen zu ziehen. Dass man in solchen Fragen nicht sofort einen allgefälligen Kompromiss findet, liegt in der Natur der Sache.
Und nochmal: niemand möchte hier was schlechtmachen, sondern nur verbessern. Das bedeutet auch,  gutes beizubehalten.

[FranzB94]

Hi!
Auch wenn ich im Moment wegen bestehender Wissenslücken noch nicht viel beitragen kann, finde ich dieses Thema sehr interessant. Falls dieser Thread geschlossen wird, sollten wir über das Thema in einem anderen Thread weiterdiskutieren.
Ich habe mich am heutigen Tage mal mit HMtemplate beschäftigt. Das Modul hatte ich schon vor längerem definiert. Da aber bei Aufruf der "Device specific help" keinerlei Beschreibung auftaucht, hatte ich angenommen, dass das Modul noch nicht fertig entwickelt ist.
Nach Martins Einwand (mit leider nur rel. kryptischer Beschreibung) hier, das man HM-Templates damit erstellen, editieren und löschen kann, habe ich nochmal experimentiert.
Und siehe da: Mit z.B. set <HMtemplate> edit DimOff (aus dem erscheinenden Drop-down-Menü) werden unter "Internals" und "Attributes" die im Template gesetzten Registerwerte angezeigt.
Eine Kombination aus der von Thorsten verwendeten viel verständlicheren Darstellung und den Infos aus HMtemplate würde nach meiner Meinung die Einarbeitung/Akzeptanz in/von Templates voranbringen.
Ein weiteres Thema beschäftigt mich auch sch einige Tage: Und zwar die Bedeutung der Vielzahl an Registern für die verschiedenen Aktoren und Sensoren. Erstrebenswert wäre eine Übersicht der Register und eine in Deutsch abgefasste Beschreibung der Bedeutung der kryptischen Bezeichnungen. Dazu will ich gern meinen Beitrag leisten. Leider habe ich derzeit nur Taster, Dimmer und Brandmelder. Von diesen habe ich die Register ausgelesen und werde übersetzen.
Vielleicht möchten sich weitere User beteiligen.

Gruss Franz

 

[Pfriemler]

@Franz: Wir sollten uns die Arbeit nicht doppelt machen. Im Wiki gibt es bereits unter dem Thema "Register programmieren" eine kurze Einleitung mit (bewusst) wenigen Beispielen, die derzeit umfassendes Behandlung befindet sich im von Martin (martin876) verfassten HomeMatic-Anhang zum Einsteiger-Doc.
Prinzipiell bin ich aber auch sehr für ein deutsches Register-Nachschlagewerk, am besten im Wiki. Das Verständnis vieler Register setzt aber oft auch das Verständnis der Verhaltensweise von HomeMatic allgemein voraus. Letzlich folgen die Registernamen einer gewissen Logik, die man auch recht schnell versteht.
Im Wiki befinden sich derzeit etliche "Homematic Type xyz"-Seiten mit unterschiedlichem Füllgrad. Mir schwebt vor, dort alle typspezifischen Register vorzustellen (oder wenigstens von dort zu verlinken), zusätzlich bräuchte es zumindest eine Seite für allgemeine, bei vielen Geräten vorhandene Register.
Zur Registererklärung habe ich auch bereits Texte auf der Platte, aber ich kann derzeit nicht "am Stück" daran arbeiten.
Ein weites Feld, was wir aber nicht hier erötern sollten.

[Thorsten Pferdekaemper]

Hi,
ich habe jetzt mal ein bisschen gebastelt. Das ganze ist momentan eher so eine Art Design(-naja-)Studie. Ob das so oder auch nur so ähnlich was wird will ich nicht versprechen. Momentan kann man Änderungen noch nicht einmal ins Gerät schreiben oder sonstwie speichern.
Da es Martin die Templates ganz wichtig sind, habe ich diesen eine zentrale Rolle gegeben.
Für den Rest siehe Screenshots.
Gruß,
   Thorsten

[rvideobaer]

Hallo Thorsten,

das sieht doch schon sehr gut aus, wenn das mal funktioniert wird dies vieles erleichtern. Aber möglicherweise auch Anfänger verleiten Änderungen vorzunehmen die mehr Probleme verursachen als lösen. 

Rolf

[papa]

Sehr cool !!!!

Ich würde mir da jetzt noch nicht so große Sorgen machen, welche Probleme möglicherweise entstehen können. Ich sehe hier dir einfache, verständliche Möglichkeit die Geräte und Peers zu konfigurieren. Das wird Anfängern auf jeden Fall sehr helfen. Ebenso wird die Nutzung der Templates stark vereinfacht, womit diese auch mehr eingesetzt werden. Also auf jeden Fall hauptsächlich Vorteile. Der Expertenmodus (Zugriff auf alle Register) könnte ja auch standardmäßig ausgeschaltet sein, um hier die Einstigeshürde etwas höher zu legen.