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 (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
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
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?
Zitat von: Pfriemler am 24 Oktober 2017, 14:21:48
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.
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.
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
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
Wenn nicht einfach kurz ne PN an Martin mit Link auf den Thread.
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
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.
Zitat von: Pfriemler am 31 Oktober 2017, 14:42:32
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
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.
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.
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.
Zitat von: Thorsten Pferdekaemper am 31 Oktober 2017, 17:39:06
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?
Zitat von: martinp876 am 31 Oktober 2017, 18:05:37
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.
ZitatRegister sind Configurationsdaten. So etwas sollte man sichern.
Dafür gibt es bereits saveConfig bei hm.
ZitatRegister 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?
ZitatIn 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.
ZitatMir 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.
ZitatAllerdings 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.
ZitatKonkret: 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.
ZitatTemplate 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.
ZitatIch 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.
Zitat"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.
ZitatSchö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.
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 (https://wiki.fhem.de/wiki/HM-LC-Ja1PBU-FM_Funk-Jalousiesteuerung)):
ZitatTasterbelegung
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.
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.
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.
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.
ZitatBezü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.
ZitatJeder 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" sectionZitatdie 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.
Hi Martin,
Zitat von: martinp876 am 01 November 2017, 08:05:12
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.
@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
8) 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
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!
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
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
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
@franz
Hast du hminfo eingerichtet?
Welchen Teil verstehst du nicht?
@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.
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.
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 (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.
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.
Zitat von: martinp876 am 01 November 2017, 21:00:35
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.
ZitatWas 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.
ZitatEin 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.
ZitatMir 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.
ZitatUm 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.
Zitat
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".
Zitat
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.
Zitat von: Pfriemler am 01 November 2017, 23:37:08
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.
ZitatWir 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.
Zitat von: martinp876 am 02 November 2017, 06:38:56
Ich will am Ende sehen, welche Aktoren/Peers ich gleichgeschaltet habe.
Das verstehe ich nicht. Was meinst Du damit?
ZitatSorry, 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.
Zitat von: papa am 02 November 2017, 09:10:56Wenn 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
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.
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.
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!
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".
Ich denke die Defaults in der Firmware werden für das direkte Peering ohne CCU/FHEM gebraucht.
Zitat von: martinp876 am 03 November 2017, 06:28:33
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?
ZitatNoch 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).
Zitat
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
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.
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.
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.
Thorsten hat mich gebeten, das Thema wieder zu öffnen, da er noch etwas richtig stellen will.
Zitat von: martinp876 am 03 November 2017, 19:52:37.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.
Zitat. das backend halte ich immernoch für absolut sinnvoll.
Ich glaube, das hatte ich auch so ungefähr gesagt.
Zitat
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.
Zitat von: papa am 03 November 2017, 20:10:56
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.
ZitatScheinbar 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
'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.
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
@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.
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
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
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.
Habe diese Diskussion gerade gefunden und muss sagen, dass ich das Vorläufige Ergebnis von Thorsten sehr gut finde. Es scheint ein Kompromiss zu sein, welcher beiden Seiten gerecht wird und dazu noch Nutzern (wie mir) helfen wird. Auch ich habe mich schon immer wieder geärgert, dass es doch irgendwie einfacher gehen muss und hatte die Templates bis dato noch nicht verstanden. Bin auch immer noch dran diese zu verstehen. Daher hoffe ich, dass es hier weiter geht.
Zum zweiten möchte ich die Idee der Erklärung der Register gerne aufgreifen und fragen, ob diese Diskussion an anderer Stelle fortgeführt wird und wenn ja wo? Auch hier sehe ich noch großen Bedarf und hoffe daher, dass es nicht untergeht. Gerne kann man hier auch gemeinsam dran arbeiten, dann ist die Last nicht auf einer Person alleine.
Hi,
erst einmal Danke für die Rückmeldungen.
Zitat von: rvideobaer am 28 November 2017, 23:42:52
Aber möglicherweise auch Anfänger verleiten Änderungen vorzunehmen die mehr Probleme verursachen als lösen. :-\
Das Argument ist ziemlich universal anwendbar. Wenn man es so sieht, dann sollte man gar nichts vereinfachen und wir sollten besser auf Assembler-Programmierung zurück gehen.
...aber ernsthaft: Wie müsste es aussehen, damit man das "Problem" nicht hat?
Zitat von: papa am 29 November 2017, 08:17:17Der Expertenmodus (Zugriff auf alle Register) könnte ja auch standardmäßig ausgeschaltet sein, um hier die Einstigeshürde etwas höher zu legen.
Das ist er im Prinzip momentan auch. Es läuft im Moment so: Der Expertenmodus wird als Eintrag in der Liste der Templates dargestellt (siehe Screenshots). Wenn man in den Konfigurationsdialog einsteigt, dann ist "expert" erst einmal nicht angeklickt. Man muss also immer zuerst in die Template-Auswahl gehen und explizit "expert" anklicken, um die Register zu sehen. Man sieht auch immer nur die Register, die nicht durch bereits gewählte Templates abgedeckt sind.
Wenn jemandem dazu was besseres einfällt, dann raus damit...
Zitat von: Amenophis86 am 29 November 2017, 09:00:35und hatte die Templates bis dato noch nicht verstanden. Bin auch immer noch dran diese zu verstehen. Daher hoffe ich, dass es hier weiter geht.
...ob das hier dabei wirklich sehr viel hilft weiß ich nicht. Vielleicht muss man die Dinger aber auch gar nicht wirklich verstehen, wenn wir es schaffen, eine einigermaßen vollständige Menge davon auszuliefern.
ZitatZum zweiten möchte ich die Idee der Erklärung der Register gerne aufgreifen und fragen, ob diese Diskussion an anderer Stelle fortgeführt wird und wenn ja wo? Auch hier sehe ich noch großen Bedarf und hoffe daher, dass es nicht untergeht.
Ich würde vorschlagen, Du machst dazu einen neuen Thread auf, gerne mit einem Verweis auf diesen hier. Außerdem würde ich vorschlagen, dazu einen Wiki-Artikel zu erstellen. Sobald es dazu Ergebnisse gibt, könnte man diese vielleicht in die Benutzeroberfläche einfließen lassen.
Gruß,
Thorsten
Zitat von: Thorsten Pferdekaemper am 29 November 2017, 11:14:58
Ich würde vorschlagen, Du machst dazu einen neuen Thread auf, gerne mit einem Verweis auf diesen hier. Außerdem würde ich vorschlagen, dazu einen Wiki-Artikel zu erstellen. Sobald es dazu Ergebnisse gibt, könnte man diese vielleicht in die Benutzeroberfläche einfließen lassen.
Würde hier Pfriemler den Vortritt lassen bzw @Pfriemler hast du da schon etwas gemacht? nicht, dass wir doppelt arbeiten. Immerhin hast du folgendes geschrieben:
Zitat von: Pfriemler am 04 November 2017, 17:29:19
Zur Registererklärung habe ich auch bereits Texte auf der Platte, aber ich kann derzeit nicht "am Stück" daran arbeiten.
Sobald das hier geklärt ist können wir das Thema aus der Diskussion herausnehmen.
Ja. Da war doch noch was. .. :D
Momentan tendiere ich zu einem Grundlagenartikel "Homematic Register A-Z erklärt". Könnten wir fachlich dort diskutieren oder in einem anderen Thread.
Hi!
Zitat von: Pfriemler am 04 November 2017, 17:29:19
@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.
Zitat von: Pfriemler am 29 November 2017, 13:17:06
Ja. Da war doch noch was. .. :D
Momentan tendiere ich zu einem Grundlagenartikel "Homematic Register A-Z erklärt". Könnten wir fachlich dort diskutieren oder in einem anderen Thread.
Zitat von: Thorsten Pferdekaemper am 29 November 2017, 11:14:58
Ich würde vorschlagen, Du machst dazu einen neuen Thread auf, gerne mit einem Verweis auf diesen hier. Außerdem würde ich vorschlagen, dazu einen Wiki-Artikel zu erstellen. Sobald es dazu Ergebnisse gibt, könnte man diese vielleicht in die Benutzeroberfläche einfließen lassen.
Es gibt also eine ganze Menge zielführender Vorschläge.
@Pfriemler: Die Erkenntnis über die Aufteilung in einen WIKI-Artikel über die allgemeinen Register einschließlich deren Erläuterung und die Darstellung der gerätespezifischen Register in den WIKI-Artikeln der jeweiligen Geräte hattest Du doch auch vor 25 Tagen schon. ;)
Ich bin gern bereit, mich aktiv an der Bearbeitung der allgemeinen Themen und der WIKI-Artikel für die Geräte zu beteiligen, die ich selbst in Verwendung habe. Nur aus diesen Geräten kann ich die Register auslesen.
Ich habe großen Respekt vor der programmiertechnischen Umsetzung der HM-Geräte durch Martin. Leider treibt mich das lesen des durch ihn verfassten Anhanges an Ulli's Grundlagendokumentes in schiere Verzeiflung. Der Text ist in Alltags-Straßendeutsch geschrieben und in einer Form, wie man sie verwendet wenn man die Thematik erklärt bekommt und sich dabei Kurznotizen macht. Damit kann ein Einsteiger aber nichts anfangen, da er die Zusammenhänge nicht kennt und sie aus dem Text auch nicht erfährt.
Es wäre also sehr schön, wenn Du dem hier geäußerten (fast schon Weihnachs-) Wunsch nachkommen würdest, einen Thread dazu zu eröffnen.
Ich werde auch mal einen Zugang zum WIKI beantragen.
@Thorsten: Ich finde die "Designstudie" geht voll in die richtige Richtung. Problematisch (u.a. für Anfänger) sehe ich, das Du die gleichen Register völlig anders benennst als Martin. Gibt es dafür einen Grund?
Gruß Franz
Zitat von: FranzB94 am 29 November 2017, 14:15:55
@Thorsten: Ich finde die "Designstudie" geht voll in die richtige Richtung. Problematisch (u.a. für Anfänger) sehe ich, das Du die gleichen Register völlig anders benennst als Martin.
Das kann eigentlich nicht sein, da ich alles über Martins Routinen oder zumindest Datenstrukturen ermittle. Ich würde auch gar nicht wissen, was ich da neues erfinden sollte.
Ich denke, es gibt hier ein Missverständnis. Könntest Du mir mal ein Beispiel geben, damit ich sehe, was Du meinst?
Gruß,
Thorsten
Zu Thorstens "Designstudie": JA, JA, JA! Sehr gut und genau wie ich mir das vorgestellt habe. Noch besser fände ich, wenn wir für den überwiegend deutschsprachigen Teil hier eine deutsche Registerübersetzung bekommen. Das dürfte aber überschaulich sein.
und zu den Registererklärungen: Ja, die Erkenntnis über einen nörtigen Wiki-Artikel ist sogar schon älter als 25 Tage. Ich habe aber auch noch ein Leben neben FHEM und das ist momentan mit genügend anderen Baustellen gesegnet. Und zu früh zu schnell loszulegen bereut man nur allzu gern. Die Wartezeit auf andere Ankündigungen ist jetzt aber durch und ich denke ich werde den einen oder anderen Abend in der Weihnachtszeit dafür nutzen können.
Hi Thorsten!
Vielleicht interpretiere ich da etwas falsch, aber ich beziehe mich auf dein Bild Peer4 im Beitrag #30
Bei mir sehen Benennungen der Register so aus:
R-HM_6TWS_05-shOnDly 0 s
R-HM_6TWS_05-shOnDlyMode setToOff
R-HM_6TWS_05-shOnLevel 100 %
R-HM_6TWS_05-shOnLvlPrio high
R-HM_6TWS_05-shOnMinLevel 10 %
R-HM_6TWS_05-shOnTime unused
R-HM_6TWS_05-shOnTimeMode absolut
R-HM_6TWS_05-shRampOffTime 0.5 s
R-HM_6TWS_05-shRampOnTime 0.5 s
R-HM_6TWS_05-shRampSstep 5 %
Gruß Franz
Hi,
Beitrag 30 ist Homematic Wired, Beitrag 42 ist der für Homematic (Funk).
Gruß,
Thorsten
Hi,
sorry, dass sich hier eine Weile nichts getan hat. Die Geräte- und Kanalregister (bzw. dazugehörige Templates) funktionieren schon ganz gut. Allerdings sind das ja eher die einfachen. Viel interessanter sind die Register für die Peerings. Blöderweise habe ich in meinem Testaufbau nur ein Thermostat und einen Fensterkontakt. Da gibt es aber gar nicht viel einzustellen und außerdem stimmt mit dem einzigen interessanten Register (winOpnTemp) etwas nicht. (Siehe https://forum.fhem.de/index.php/topic,80792.msg728467.html#msg728467).
Zusätzlich habe ich mir gerade ein langes Wochenende in der Heidelberger Uniklinik gegönnt, wo mein VPN nicht funktioniert hat.
Ich habe mir jetzt aber noch einen Aktor bestellt, den ich dann hoffentlich sinnvoll peeren kann. Dann sollte es weitergehen.
Gruß,
Thorsten
Wenn du einen rt hast sollte kanal 6 register mit peers haben.
Bei winopentemp des win kanals stimmt es mit den peers in der tat nicht. Etwas komplex da es aus allen Rastern fällt. Werde i h bei gelegenheit korrigieren.
Zitat von: Thorsten Pferdekaemper am 13 Dezember 2017, 20:56:03
Ich habe mir jetzt aber noch einen Aktor bestellt, den ich dann hoffentlich sinnvoll peeren kann. Dann sollte es weitergehen.
Hallo Thorsten,
ich könnte Dich mit Selbstbau Aktoren und/oder Remotes unterstützen. Die Regsiter für Peerings zwischen Remote und Switch sind schön groß :-)
Zitat von: martinp876 am 13 Dezember 2017, 21:16:39
Wenn du einen rt hast sollte kanal 6 register mit peers haben.
Genau. Ich habe mir jetzt mal einen HM-ES-PMSw1-PI und diese 8-Tasten Fernbedienung bestellt. Damit müsste ja das meiste zu simulieren sein.
Zitat
Bei winopentemp des win kanals stimmt es mit den peers in der tat nicht. Etwas komplex da es aus allen Rastern fällt. Werde i h bei gelegenheit korrigieren.
Das wäre nett. Ich hatte mich sowieso gewundert, dass die Register unabhängig vom Device immer genau dieselbe Bedeutung haben. Kann es sein, dass Du die Namen der Register selbst vergeben hast? Dann könntest Du ja "einfach" eins der winOpnTemp umbenennen. (Ich weiß, dass es dabei immer ein bisschen blöd ist, das ganze kompatibel zu "alten" Installationen zu halten.)
Zitat von: papa am 13 Dezember 2017, 21:52:57
ich könnte Dich mit Selbstbau Aktoren und/oder Remotes unterstützen.
Das ist nett, aber momentan noch nicht notwendig. Erst einmal muss das ganze mit meinen primitiv-Szenarien laufen und dann sehen wir weiter. Wichtiger wäre außerdem, wenn das noch jemand testen könnte, bevor ich es veröffentliche. Hast Du einen kompletten Testaufbau oder nur ein paar übrige Geräte?
Gruß,
Thorsten
Zitat von: Thorsten Pferdekaemper am 14 Dezember 2017, 09:58:20
Das ist nett, aber momentan noch nicht notwendig. Erst einmal muss das ganze mit meinen primitiv-Szenarien laufen und dann sehen wir weiter. Wichtiger wäre außerdem, wenn das noch jemand testen könnte, bevor ich es veröffentliche. Hast Du einen kompletten Testaufbau oder nur ein paar übrige Geräte?
Testen würde ich auf jeden Fall unterstützen. Meine Testgeräte sind hauptsächlich auf Breadboards aufgebaut. Habe aber noch einige Paltinen liegen. Könnte also was Universellen aufbauen, was dann entsprechend mit Software bestückt wird.
Ja, die namen sind von mir. Sehr stark angelehnt an die eq3 namen.
Aendern erzeugt probleme bei templates. Ist aber kein problem, da es keiner nutzt.
Zitat von: martinp876 am 15 Dezember 2017, 08:04:59
Aendern erzeugt probleme bei templates. Ist aber kein problem, da es keiner nutzt.
Ach nu sach doch nich sowas wieder ... ;D ...
Zitat von: papa am 15 Dezember 2017, 07:19:49
Testen würde ich auf jeden Fall unterstützen. Meine Testgeräte sind hauptsächlich auf Breadboards aufgebaut. Habe aber noch einige Paltinen liegen. Könnte also was Universellen aufbauen, was dann entsprechend mit Software bestückt wird.
Klingt gut. Das ist so ähnlich wie das, was ich mit HM-Wired mache. Ich werde allerdings noch ein bisschen brauchen. Ich will über die Feiertage meinen ganzen Kram nicht überallhin mitnehmen... D.h. es kann gut nächstes Jahr werden, bis ich wirklich etwas zu testen habe.
Zitat von: martinp876 am 15 Dezember 2017, 08:04:59
Ja, die namen sind von mir. Sehr stark angelehnt an die eq3 namen.
Aendern erzeugt probleme bei templates. Ist aber kein problem, da es keiner nutzt.
Das Problem, dass es keiner benutzt, versuchen wir ja gerade durch diese Aktion hier zu lösen...
Vielleicht kannst Du den Register-Namen ja auch kopieren. D.h. es gibt einen neuen Namen "winOpnTempPeer" (oder so), aber der alte Name ist im regSet immer noch "erlaubt".
Gruß,
Thorsten