[Diskussion für Wiki] Registerbezeichnungen A-Z (Namen, Erklärungen)

[martinp876]

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.

[martinp876]

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?

[Pfriemler]

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.