Auf vielfachen Wunsch und in Ausgliederung aus der Diskussion zu einer Oberflächenerweiterung für HM (https://forum.fhem.de/index.php/topic,78425.msg723043.html#msg723043) habe ich einen neuen WIKI-Artikel begonnen:
Homematic-Register von A-Z (Namen, Erklärung) (https://wiki.fhem.de/wiki/Homematic-Register_von_A-Z_(Namen,_Erkl%C3%A4rung))
Die Seite ist dafür gedacht, alle bekannten Register von Homematic zu listen, den Namen zu erklären und grundlegende Beschreibungen zu liefern. Einsatz- und Code-Beispiele sind in den Geräte-Wiki-Einträgen, den "Homematic Type"-Artikeln oder "Codeschnipseln" besser aufgehoben und würden die Liste nur unnötig aufblähen.
Ergänzend zur dortigen Diskussionsseite, die (später) fachlichem Diskurs vorbehalten sei, möchte ich hier dazu aufrufen, den Artikel gelegentlich zu lesen, mir Verbesserungsvorschläge oder sonstige Anmerkungen zu machen - und auch mitzutun, wenn weitgehend Einigkeit über das Schema herrscht.
Insbesondere dankbar bin ich auch für Hinweise, wo das eine oder andere bereits erschöpfend erklärt ist. "Meinen" Homematic-Register programmieren (https://wiki.fhem.de/wiki/HomeMatic_Register_programmieren)-Artikel habe ich bereits beliehen und werde ihn dort mit Verweis auf diesen neuen Index ausdünnen.
Der Prozess ist gerade erst angefangen und beinhaltet einige Fleißarbeit. Die Erläuterungen sind eine erste Fassung. Wer meint, etwas nicht zu verstehen: bitte sagt es.
Eigentlich wollte ich jedem Register ein Unterkapitel spendieren. Aber das Inhaltsverzeichnis würde ausufern. Daher gefällt mir die Tabellenform so wesentlich besser. Weitere Spalten wie ausführliche Beschreibung oder Übersetzung, Wertebereich etc. habe ich zugunsten einer vermutlich sehr variablen Fließtextmenge dann doch in der zweiten Spalte integriert, dort jeweils in die erste Zeile.
Einwände?
Hi,
hier ist ein Dump von alles Registern, die in FHEM bekannt sind (soweit ich das sehe). Es ist so zu lesen, dass die ungeraden $VAR-Angabe der Name des Registers ist und die geraden die jeweiligen dazugehörigen Eigenschaften. Die Eigenschaft 't' ist meistens ein kurzer erklärender Text.
Gruß,
Thorsten
EDIT: Das ganze wieder rausgeworfen, da es mit den code-Tags Schwierigkeiten gab.
Danke, das hilft mir beim Zusammensuchen. Den Kauderwelsch kann ich lesen.
Die kurzen Texte dürften die sein, die auch in "regList" ausgegeben werden und von Deiner Designstudie?
P.S.: Mit den Codetags stimmt was nicht.
Aufteilen auf mehrere Code-Bereiche, dann klappt's auch mit Code Tags. So lange Codes können sie nicht handeln.
Zitat von: Pfriemler am 30 November 2017, 10:20:53
Die kurzen Texte dürften die sein, die auch in "regList" ausgegeben werden und von Deiner Designstudie?
Ja und ja.
Zitat
P.S.: Mit den Codetags stimmt was nicht.
Seltsam, in der Vorschau sah das gut aus.
Ich hab's jetzt hier als Anhang drangehängt.
Gruß,
Thorsten
Zitat von: Thorsten Pferdekaemper am 30 November 2017, 10:32:56
Ich hab's jetzt hier als Anhang drangehängt.
Gesichert und lesbar.
Zur Sache: Wiederhole meine Frage insbesondere an die, die sich so eine Registerliste gewünscht haben: Ist das so angefangen ok? Soll ich so weitermachen?
Bei Thorstens Reaktion impliziere ich das JA jetzt mal ...
edit: Also bei insgesamt 442 bekannten Registern dürfte eine Tabelle die einzige Option darstellen. Das werde ich mir mal auch ein Programm zusammenbasteln, was die Register nach Listen vorsortiert und anschließend alphabetisch sortiert und die relevanten Daten inkl. Wertetabellen herauszieht. Und dann eine Datenbank mit den Erläuterungstexten dazu. So könnte man die Tabelle auch später reorganisieren ohne dass eine komplizierte händische Suche fällig wird.
Ich bin dann mal weg ... ;D
So ganz kapier ich noch nicht alles. min, max, lit, litInv, c (lit wenn lit(Inv) existiert), l (Liste), u (unit) sind mir dann wohl klar, na und t natülich.
s?, f?, d?, a?=> ein Blick in die HMConfig.pm ... da steht das meiste ja auch schon, inkl. Erläuterung. Und sortiert isses auch schon gut.
Das muss jetzt sacken...
Hi Pfriemler!
Prima. Der Anfang ist gemacht.
Die Tabelle im Designvorschlag 2 sollte aber mMn noch in mehr Spalten eingeteilt werden:
register - Register | range - Wertebereich | peer - Peer | description - Beschreibung
Es ist richtig, dass die Geräte(-bezeichnungen), die Register, die Wertebereiche und die englische Kurzbeschreibung in der hm.pm enthalten ist. Ziel der derzeitigen Aktion sollte es sein, die deutsche Bedeutung der englischen Registerbezeichnungen für Einsteiger zu erklären. Weiterhin sollte der Zusammenhang bzw. die Abfolge der Register bei Befehlen erklärt werden, damit auch der Einsteiger Abläufe erstellen kann.
Die Idee, mit einer Datenbank zu arbeiten ist sehr gut.
Gruß Franz
Den Wertebereich (bzw. bei Literalen die möglichen Werte) in eine extra Spalte auszulagern wird tatsächlich sinnvoll sein.
Aber was meinst du mit der peer-Spalte?
auch wenn es blöde klingt ....
die (Werte) Register sind vergleichbar einfach :-)
Da finde ich die State Machine deutlich spannender und habe die bis heute nicht verstanden :-) Und ja, das Einsteiger PDF habe ich auch schon mehrfach daraufhin durchgeackert
Was habt ihr vor?
Sämtliche Register sind in hmconfig enthalten. Mit Adresse, Wertebereich und literal.
Register einzeln zu beschreiben ist sinnlos. Es sind Gruppen und als solche zu beschreiben.
Im Prinzip sind die im einsteigerdoc seit Urzeiten 90% beschrieben. Wenn die Beschreibung unverständlich ist, sollte sie eben überarbeitet werden.
Wenn das Prinzip einer Zustandsmaschine nicht klar ist sollte das einmal nachgelesen werden. Allerdings ist es für Experten. Un die verstehen statemachine.
Alle anderen sollten sich auf Templates stützen. Experten können diese einfach erstellen und verbreiten.
lass mich mal machen und schaue dann. Sollte davon was ins Einsteigerdoc passen, gern. Die Statemachine werde ich nicht umfänglich neu erklären.
Ja, es steht in HMConfig. Aber nicht jeder kann das flüssig lesen. Die Vorgruppierung dort ist aber in der Tat sinnvoll. Allerdings wäre eine umfassende Erklärung der Registerzusammenhänge eher was für "Homematic type"-Artikel.
Ich dachte nicht, das jeder hmconfig verstehen soll. Es war ein Hinweis an dich, da du nach einer kompletten Liste der Register gefragt hast.
Des weiteren kannst du gerne die statemachine erklären oder das einsteigerdoc überarbeiten. Das kann man sicher verbessern. Unschön würde ich sehen, wenn es mehrfach erklärt wird. Wenn du alles umgänglich erklärst und das gesamte einsteigerdoc hm abbildest sollte man es zurückziehen. Es ist sonst immer problematisch für Anwender die nun gültige doc zu finden. Aus einem Hause sollte nur eine kommen.
Feel free das Doc zu überarbeiten, in Wiki zu integrieren oder zu löschen. Nur keine Konkurrenz erstellen.
Was mich wundert ist weiter der Ansatz, jedes Register separat zu erklären. Das verstehe ich nicht. Einige Register sollten von halbwegs aufgeweckten Usern allein durch die Kurzbeschreibung oder den Namen schon erklärt sein. Ein batlevel.... was könnte das bedeuten.... ein valvemaxpos könnte die maximale Position der Ventilöffnung sein. Ok, eine valveerrpos könnte hinterfragt werden. Die Position, wenn das Ventil in Fehler geht? Was könnten Fehler sein? Wissen wir nicht umgänglich. Sollte eigentlich einleuchtend sein, dass Batterie leer so etwas sein sollte. Und dass das entfernen einer Batterie das Ventil nicht in diese Position schiebt. Das geht zu schnell, kann nicht funktionieren.
Was erklärt werden sollte sind m.e eher Zusammenhänge, welch ein das einsteigerdoc nicht abdeckt. Ich denke die conditiontable kommt etwas zu kurz. Außerdem die virtuellen Kanäle eines Sommers sowie die Logic Verknüpfungen der selben. Weiter dessen kompletter Else Registerbranche.
Ich bin gespannt auf deine docu.
Ich sehe allerdings klar 2 Level:
Expert: der weiss sowieso was eine statemachine ist( ist in der Technik eine ganz normale Betrachtung, keine hm Erfindung) . Der kann mitdenken und braucht nur einige Hinweise.
Admin: dem sollte man komplette Anwendungen zu Verfügung stellen. Die macht man üblicherweise in Form von Templates. ( Muss auch nicht mein Ansatz von Templates sein- aber readytouse entities sollten es sein, keine Anleitungen setzen diese 5regs, peere hier und da....)
Das template kann man dann beschreiben.
M.e. setzen die wenigsten die Register für einen banalen treppenhausschalter mit bm sinnvoll. Mit dem template wäre das erledigt. Wer will schaut sich die Details an, wer nur anwenden will eben nicht.
Welchen Leserkreis willst du erreichen?
Hi!
@Pfriemler: Du hast eigentlich Recht, diese peer-Spalte ist nicht unbedingt notwendig, da sie in der Regel mit required gefüllt oder leer ist. Wenn man ein "get <HM-Gerät> regList" aufruft, dann erscheinen die von mir angegebenen Spalten in dieser Reihenfolge.
@Martin:
Ich wiederhole meine Meinung aus: https://forum.fhem.de/index.php/topic,78425.45.html (https://forum.fhem.de/index.php/topic,78425.45.html)
ZitatIch 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 Verzweiflung. 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/Fortgeschrittener aber nichts anfangen, da er die Zusammenhänge nicht kennt und sie aus dem Text auch nicht erfährt.
Zitat von: martinp876 am 02 Dezember 2017, 09:20:49
Was erklärt werden sollte sind m.e eher Zusammenhänge, welch ein das einsteigerdoc nicht abdeckt. Ich denke die conditiontable kommt etwas zu kurz. Außerdem die virtuellen Kanäle eines Sommers sowie die Logic Verknüpfungen der selben.Weiter dessen kompletter Else Registerbranche.
Wer soll denn bitte solch ein Buchstabengewirr verstehen?
Die Hilferufe im HM-Bereich sind doch vielfältig, aber es gibt keine verständlichen Anleitungen.
Noch einmal: Martin, es will und wird Dir keiner Deinen guten Ruf und Deine Kompetenz in der HM-Programmierung absprechen. Du solltest also im Sinne der Sache Deine Unterstützung einbringen.
Gruß Franz
@Martin. In großen Teilen gebe ich dir recht ABER es gibt tatsächlich noch User, die zwischen den beiden Gruppen liegen und das sogar in mehreren Schattierungen. Es gibt nicht nur Experten und Admins. Es gibt tatsächlich auch die Leute, denen man einzelne Register etwas ausführlicher erklärt und die dann die Zusammenhänge besser verstehen. Manchmal ist es nur ein kleiner Schubs.
Mir geht es nicht um eine Neufassung des Einsteigerdocs, diesbezüglich bin ich voll bei Martin. Hier geht es erst mal um nichts mehr als eine sinnvolle Zusammenfassung und Gruppierung der Register, Kurzbeschreibungen (die es bereits gibt) und einer Übersetzung (die es noch nicht gibt) nebst evtl. kurzer Erläuterungen.
Es wird sich als Nebeneffekt sicher einstellen, dass man bei eingehender Lektüre recht schnell den Sinn der Registerbezeichnungen selbst erahnen kann. Dann reicht im Zweifel ein Nachsehen im Wiki ob man richtig liegt.
Ich halte das Einsteigerdoc definitiv nicht für ein Meisterwerk. Und ich habe es schon ewig nicht mehr angesehen.
Was ich ausdrücken will ist, dass ich ein Beschreiben einzelner Register für wenig zielführend halte. Man muss Zusammenhänge verstehen, also Registergruppen, jumptable, conditiontable, long/short. Man muss Zuordnungen wie Peerings verstehen um zu wissen wie die Gruppen wirken.
Das versucht das Einsteigerdoc (offensichtlich nicht erfolgreich). Aber das könnte man jederzeit verbessern - und wenn es einer kann sollte er dies tun!
Ich hatte allerdings explizit nie die Absicht eine Statemachine zu erklären (sicher die Basis der Probleme der Anwender), auch wenn es Uli sich wünschte. Dazu gibt es Literatur ohne Ende, das sind Grundlagen. Meine Zielgruppe waren FHEM/HM Einsteiger. Nicht Einsteigern in Programmieren von Embedded Systems. Diese sollten damit m.E. nach kleinen Übungen zurechtkommen (glaube ich immer noch).
Man kann aber gerne eine Statemachine noch einmal erklären - warum nicht.
Wie gesagt, alles andere ist m.E. einfach am Registernamen und den Werten/Einheiten und der Kurzbeschreibung abzulesen. Bedenklich ist, dass Anwender nach Registern Fragen welche sie einfach in regTable finden könnten. Diesen kann man wenig helfen.
ok, offen sind Fragen wir bspw die Regelparameter der RT. Cool wenn das jemand so beschreiben kann, dass man gezielt seine Steuerung optimieren kann. Hier bin ich in der Tat gespannt.
Und klar gibt es alle Level zwischen, über und unter Expert und Admin. Wenn ich irgendwo Laie bin suche ich mir ein funktionierendes Template - oder zwei - schaue mir die Unterschieden an und lerne. Ich kann damit spielen und jederzeit wieder ein funktionierendes Template einspielen. Grundlegende Beschreibungen sind in CUL_HM schon vorhanden. Templates sind nicht verschlüsselt - im Gegenteil!
Und wenn ich keine Lust habe kann ich einfach ein funktionierendes Template nutzen und mich einer anderen Aufgabe widmen. Kein Wunder, dass eq3 genau diesen Weg gegangen ist.
Was ich angezweifelt haben ist, dass man mit einer Beschreibung einzelner Register einen Laien oder Admin weiterbringt.
Zusammenfassend bin ich überzeigt dass die Register ausreichend beschrieben sind wenn man die Zusammenhänge verstanden hat. Mehr brauche ich auch nicht - und ich habe die Register auch nur gesehen und kenne nicht mehr als in der Beschreibung steht.
ok, in deutsch ist die Kurzbeschreibung nicht eingepflegt. Aber so lang ist der Englische Text nicht.
Aber macht einfach einmal. Ich lasse euch nun in Ruhe arbeiten.
Ich habe einmal reingelesen. Die Beschreibung ist gut geschrieben -allerdings fehlt mir zumindest die technische Präzision sowie die Übersicht. So etwas hatte ich im Einsteigerdoc versucht.
Ich nehme einmal shCtOn/Off
- warum sind nicht alle Ct elemente beschrieben? Das kann man doch alles auf einmal erklären
- Die Annahme, dass Schalter nur Trigger ohne "Wert" liefern ist korrekt - typisch. Und Sensoren typisch kein long senden. Allerdings kann man das über einen virtuellen Sensor durchaus nutzen.
- Die Werte der 3-state Sensoren stimmen - wenn man sie nicht umprogrammiert. Man kann auch bei geschlossen ein 100% senden.
- Die Schwellwerte Lo und Hi liegen bei 50 und 100 - allerdings kann man das ändern. Muss man auch bei MotionDetector.
- Hi und Lo sind frei wählbar - sollte man ergänzen. Eigentlich sind das Level1 und Level2. Lo muss nicht kleiner sein als Hi. Und man braucht nicht beide.
- geHi ist greaterEqual. Es geht also von 100-255. 200 ist 100% - werte größer 200 sind also untypisch, aber explizit zugelassen.
- HM Werte beziehen sich gerne auf % Angaben wobei die Einheit 0,5% sind. Somit ist der %-Wert *2 gleich der einzustellende Wert
- 3-state sensoren liefern m.E. nicht 100 und 200. Nach Doku sind das 25% (50) und 90% (180)
- die Betrachtung der Übergänge dlyOn/Off sind essentiell für eine sinnvolle Nutzung von Bewegungsmeldern.
- Gerade ein Beispiel der Bewegungsmelder ist m.E. hier sinnvoll.
- haben die Anwender jetzt schon die Statemachine verstanden oder muss man das nicht?
- CT ist für Fernbedienungen also irrelevant. Kann ich zwar herauslesen - aber ich kenne es ja auch. Sollte man hier deutlich machen, dass eine FB diese Register ignorieren kann?
zu JT
- ich halte dlyOn/Off für druchaus sinnvoll - oft 0, aber nicht immer.
- die Statemachin muss nicht immer durchlaufen werden - man kann springen - nein, man springt! mit den Triggern. Technisch nicht korrekt.
- Der Kreis wird typisch nicht durchlaufen, da typisch zumindest ein Endlos-Zustand eingebaut ist. Somit kann man den Abauf nciht verbiegen, man MUSS. Welchen Wert man einträgt ist geschmackssache. Achtung aber bei Rolloaktoren. Hier kann man den Aktor physikalisch zerstören, wenn man die Wendezeit auslässt!
- Bei dimmern gibt es mehr Zustände - und daher auch mehr Bedingungen. Noch einmal anders ist es bei BlindAktoren
- warum gibt es bei Dimmern eine Rampenzeit von 0,5s? Man kann die Rampenzeit einstellen - so wie alle anderen Zeiten.
- ein long bei Dimmern löst keineswegs immer einen Dimvorgang aus. wieso sollte er? Das ist frei programmierbar. Und selbstverständlich kann man die Rampengeschwindigkeit bei Long festlegen.
Bei den Beispielen sehe ich das Schalten einer Lampe mit SCI-3-FM. Die Implementierung ist abenteuerlich, funktioniert nur bedingt und wir haben schon mehrfach davon abgeraten. Weiter kann man auch bei normalen Wechselschalten nicht an der Schaltstellung erkennen, ob das Licht leuchtet. Ich dachte weiter dass der SCI keinen sekundärwert liefert. Warum also die CT?
Weiter ist in diesem Beispiel die JT nicht beschrieben.
=> Kann ein Anfänger aufgrund dieser Beschreibung die Register setzen?
gezielten Schalten eines Aktors:
Hier frage ich mich nun, warum man nicht templates anbietet. Diese liefern nicht nur den kleinen Ausschnitt der Register sonden die kompletten notwendigen Registern. Ist das nicht deutlich einfacher?
Martin Du beziehst Dich vermutlich auf den "Schnupperkurs Registerprogrammierung" statt die Registerbeschreibung. Diese Beschreibung ist eigentlich bewusst als kleine Auswahl der Möglichkeiten gedacht, für jede Registerklasse/Liste ein treffendes Beispiel kann reichen. Die Übersicht soll das Registerverzeichnis liefern, ich werde dort bewusst von einer alphabetischen Sortierung abweichen und logisch zusammenhängende Register bündeln, wie schon in der HMConfig.pm.
Technische Präzision und Allgemeinverständlichkeit sind zusammen so gut wie nicht zu erreichen. Die Erwähnungen aller Möglichkeiten verwirren Anfänger eher als dass sie nützen, ich rede aus eigener Erfahrung. Aber einige Deiner Hinweise werde ich dort gern unterbringen, z.B. dass Lo und Hi sich nur auf die Defaultwerte beziehen, aber frei programmiert werden können. Allerdings: Auch wenn man es könnte, warum sollte man Lo höher als Hi setzen?
geLo/geHi: dachte ich eigentlich unmissverständlich erklärt zu haben: greater (or) equal, deutsch sollte ich ergänzen. Eine Obergrenze habe ich nicht genannt.
HM-Werte: Zitat: "...gekoppelt mit einem Wert zwischen 0 und 200, entsprechend 0-100% in 0,5-%-Schritten. " Steht schon da. Dass man bei Programmierungen etwa für Level Prozente angeben muss, kommt bisher in keiner Erklärung/Beispiel vor, wäre aber dann Pflicht gewesen, richtig.
3-state-Sensoren liefern nicht 0, 100 und 200? Werde ich mal checken. Testaktor, RHS.
dlyOn/dlyOff und Bewegungsmelder? für Treppenlichtautomaten zum Nachtriggern beim Flackern. Sonst suche ich noch. Bewegungsmelder ist eigentlich ein Klassiker für das Template, das würde ich lieber als Paradebeispiel dafür lassen, weil hier noch weit mehr Änderungen nötig sind.
Die Erklärung der Statemachine ist nur mit Grafiken sinnvoll, das ist im Einsteigerdoc gut gelungen und soll n.m.M. woanders nicht wiederholt werden. Hatte ich mich ansonsten dazu irgendwo ausführlich geäußert? Inhaltlich hast Du völlig recht.
CT ist für Fernbedienungen irrelevant weil wertefreier Trigger. Eine FB ignoriert gar nichts, das ist der Aktor, der bei Fernbedienungstriggern diese Register komplett ignoriert. Ja, das sollte bei der Erklärung der CT-Register erwähnt werden, in Zusammenhang auch bspw. dass alle Long-Register etwa bei Hardware-Bewegungsmeldern sinnfrei sind, auch wenn man das mit virtuellen Sensoren vielleicht doch nutzen könnte, aber das ist ja schon "HM-Hacking".
Default hat die Statemachine 2 Haltezustände, man kann beide zeitlich begrenzen oder aufheben und so einen Dauerkreislauf erzeugen. Wichtiger finde ich noch darauf hinzuweisen, dass der jeweils letzte Trigger die Regeln der aktuellen Statemachine bestimmen kann - etwa wenn man einen dauerhaft eingeschalteten Aktor mit einer Fernbedienung nachtriggert, für die eine Laufzeitbegrenzung eingestellt ist, und umgekehrt einen im Kreislauf (Blinken) befindlichen Aktor nur zur Ruhe bekommt, wenn man ihn durch einen anderen Peer (mit anderem Regelsatz) heraustriggert.
Die Erwähnung der 0,5-Sekunden-Rampenzeit erfolgt beim blinkenden Dimmer - "sofern nichts anderes programmiert wurde". Also?
Long löst default immer einen Dimmvorgang aus. Das reicht für den Anfang. :) . Ja, werde ich ergänzen, dass man auch das aushebeln kann.
Zum Beispiel mit dem SCI-3: was ist daran abenteuerlich? Doch, der SCI liefert Werte, der Swi nicht.
Ausgehend von einer festen Fern-Steuerung eines Aktors mit einem Schalter (follow) wird erklärt, dass bei Wechselschaltungen (also mehrere Schalter) genau diese Zuordnung nicht üblich bzw. sogar hinderlich ist und welche Komponenten man stattdessen normalerweise dafür einsetzt (Swi bzw. switch-mode), wenn man eine bestehende Wechselschaltung bei beizubehaltender Haptik nach HM überführt. Die Möglichkeit, durch Programmierung einen werteliefernden SCI wie einen wertelosen Swi benutzen zu können, dürfte weitgehend unbekannt sein.
Und zuguterletzt: Ja, das explizite Vorgeben einer Schaltrichtung je nach short oder long schreit förmlich nach einem template. Doch schadet es - wie bei allen Templates - eigentlich auch gar nicht, wenn man die Grundlagen für die Verhaltensänderung mal erwähnt.
Last but not least: Die Templatemöglichkeiten sind in diesem Beitrag unterbelichtet, natürlich. Ich finde, man sollte die Beispiele direkt mit Templates ergänzen.