HMCCU 5.0 Beta verfügbar

[martinp876]

Da  bin ich nun zum ersten mal ganz klar anderer Meinung. 
In fhem hat absolut JEDES  device mehrere readings. Und m.W. macht das keiner so wie du. Fhem hat ausreichend Möglichkeiten,  so etwas zu realisieren. 
Ich finde es extrem Schade wenn man sich einfach über Konventionen hinwegsetzt.

Natürlich kann sich keiner den Namen aus DEF merken. Daher gibt es in jedem device neben DEF den NAME. Den kann man frei wählen.

Device kann man auch über die Adresse definiere ( wäre logisch)
Nutzt man den device Level braucht man diese Option. Daher befürworte ich channels.

Ich bin aktuell wirklich enttäuscht. Das Konstrukt wird dadurch wilder und entfernt sich vom üblichen  fhem. Schade.

[zap]

Da  bin ich nun zum ersten mal ganz klar anderer Meinung. 
In fhem hat absolut JEDES  device mehrere readings. Und m.W. macht das keiner so wie du. Fhem hat ausreichend Möglichkeiten,  so etwas zu realisieren. 
Ich finde es extrem Schade wenn man sich einfach über Konventionen hinwegsetzt.

Ich verstehe überhaupt nicht, was Du meinst. Selbstverständlich hat jedes Device mehrere Readings. Wo habe ich das Gegenteil behauptet? In meinem vorherigen Post kommt das Wort "Reading" nicht mal vor.

Natürlich kann sich keiner den Namen aus DEF merken. Daher gibt es in jedem device neben DEF den NAME. Den kann man frei wählen.

Device kann man auch über die Adresse definiere ( wäre logisch)
Nutzt man den device Level braucht man diese Option. Daher befürworte ich channels.

Ich bin aktuell wirklich enttäuscht. Das Konstrukt wird dadurch wilder und entfernt sich vom üblichen  fhem. Schade.

Kann ich alles nicht nachvollziehen, sorry. Ich nehme an, das ist ein Missverständnis.

Vielleicht wird es klarer mit einem Beispiel:

Angenommen, ich habe in der CCU einen Kanal, der wie folgt benannt ist: "Fenster-Wohnzimmer-Links", Adress = 000213C98DD91F:1

Wenn der Nutzer für diesen Kanal ein HMCCUCHN Device definieren möchte, hat er 2 Möglichkeiten:

1.

Code Auswählen Erweitern

define Fenster_Wohnzimmer_Links HMCCUCHN Fenster-Wohnzimmer-Links

2.

Code Auswählen Erweitern

define Fenster_Wohnzimmer_Links HMCCUCHN 000213C98DD91F:1

Das ist auch schon alles, was ich mit meinem letzen Post sagen wollte. Wo ist nun das Problem? Welcher Konvention widerspricht das?

P.S. Leider lässt FHEM nicht den gleichen "Zeichenraum" für Devicenames zu wie die CCU. Man kann die Namen also nicht einfach 1:1 übernehmen.

P.S.P.S. Auch folgendes ist mit HMCCUCHN möglich, wenn auch nicht häufig genutzt (2xHMCCUCHN für den gleichen Kanal):

Code Auswählen Erweitern

define Fenster_Wohnzimmer_Links HMCCUCHN Fenster-Wohnzimmer-Links
define Fenster_Wohnzimmer_Links_Test HMCCUCHN Fenster-Wohnzimmer-Links

Oder ein HMCCUCHN und ein HMCCUDEV (dafür könnte es schon eher Anwendungsfälle geben, gerade im UI Bereich):

Code Auswählen Erweitern

define Fenster_Wohnzimmer_Links HMCCUCHN Fenster-Wohnzimmer-Links
define Fenster_Wohnzimmer_Links_CCUDev HMCCUDEV Fenster-Wohnzimmer-Links-Dev

[zap]

Es gibt ein Update für die 4.4 Beta in contrib/HMCCU/FHEM. Die meisten Änderungen betreffen das HMCCUCHN Modul. Das Modul bietet nun folgende Befehle an:

get config: Liest die konfigurativen Parameter eines Kanals aus der CCU. Die Werte werden angezeigt und als Readings gespeichert. Es werden Parameter zum Device und zum Kanal gelesen. Außerdem werden Verknüpfungsparameter gelesen. Für die Experten: Der Befehl liest die Parameter Sets MASTER und LINK.

get values: List die Werte aus dem Parameter Set VALUES, also die Datenpunkte. Es werden die Werte vom zugeordneten Kanal sowie dem Kanal 0 gelesen. Die Werte werden angezeigt und als Readings gespeichert. Im Gegensatz zu "get update" verwendet "get values" die RPC Schnittstelle der CCU.

get update: Wie "get values", allerdings werden die Werte über die ReGa Schnittstelle mit Homematic Script gelesen. Diese Methode benötigt nur 1 CCU-Request, während "get values" einen Request je Kanal braucht.

get deviceDesc: Zeigt die Geräte- und Kanalbeschreibung an.

get paramsetDesc: Zeigt die Modell-Parameter an.

Beim Start von FHEM werden neben den Geräten und ihren Parametern auch die Verknüpfungen von der CCU gelesen. Die Verknüpfungen werden als Internals "receiver" und "sender" in die einzelnen FHEM Devices eingetragen. Somit ist nun auch in FHEM erkennbar, welche Geräte miteinander verknüpft sind.
Das ebenfalls neue Internal "ccurole" enthält die Rolle eines Kanals (HMCCUCHN) oder der Kanäle (HMCCUDEV). Beispiel: "SHUTTER_CONTACT".

Auch im Modul HMCCU gibt es einige Änderungen:

get ccuconfig: Liest die Geräte mit ihren Konfiguration inklusive der Verknüpfungen neu von der CCU.

get paramsetDesc: Zeigt die Parameterbeschreibung eines CCU Device an.

get deviceDesc: Zeigt die Gerätebeschreibung eines CCU Device an.

Aktualisierung von Readings:

Mittlerweile kommen die FHEM Devices weitgehend ohne die Attribute "substitute" und "ccuscaleval" aus. Die Werte werden abhängig von der Rolle eines Gerätes/Kanals automatisch angepasst. Beispiel: LEVEL wird automatisch von 0-1 auf 0-100 skaliert. Bei Fensterkontakten wird true/false automatisch durch open oder closed ersetzt.

Die nächsten Schritte:
- Übernahme der HMCCUCHN Funktionalität in HMCCUDEV.
- HMCCUDEV und HMCCUCHN "schlauer" machen, d.h. weitgehend automatisch an den Gerätetyp anpassen (Readings, Befehle, ...)

[zap]

Module nochmal aktualisiert. Übersicht siehe vorheriger Post.

[martinp876]

Nun, ich stimme nicht zu, bei den Grundsätzen.

Die DEFs kann ich nicht verwenden, da ich auch den CCU Geräte- oder Kanalnamen beim Define zulasse.

Namen sind besser - daher vergibt man auch "NAME". Mehr ist nicht notwendig. Das ist FHEM Standart, alles andere nicht.

Das will ich auch beibehalten für die, die nur einzelne Geräte der CCU in FHEM definieren möchten.

Einzelne Geräte zu definieren ist jederzeit möglich - auch ohne Sonderwege.

Namen kann man sich leichter merken als Adressen.

Ich verstehe den Inhalt der Aussage nicht. Adressen sind für den User indiskutabel. NAME ist sein zugang. Hatten wir schon. Es bedarf keiner sonderwege, ist alles incl. in Standard.

Außerdem ist es möglich, für ein CCU Gerät mehrere FHEM Devices zu definieren, z.B. um Werte unterschiedlich darzustellen oder einfach nur zum Testen.

Sind "Werte" etwas anderes als Readings? Dann habe ich es in der Tat nicht verstanden.

Das (für mich unumstößliche Prinzip) in FHEM ist, dass eine Entity ein-eindeutig definiert wird. Darstellungen und tests lassen sich alle (ALLE) mit FHEM bordmitteln erstellen. Das hat erst einmal nichts mit DEV und CHN zu tun.

In FHEM kenne ich nicht alles - aber ALLES was ich bisher genutzt habe arbeitet EXAKT nach dieser Devise. Als Anhänger einer STRIKTEN Nomenklatur ist und bleibt es ein böses Foul hiervon abzuweichen.
Mir sind hierbei jegliche Diskussionen über die Vorteile egal - sorry. Die Konformität in einer modulaen SW ist für mich nicht verhandelbar.

Was sehe ich nun als Konform - Das Layering-model.

A) Die Topographie
FHEM versteht sich als Zentrale. Es verbindet sich mit externen "Entites", also Sensoren und Aktoren. Diese sind typisch Schalter und Taster aber auch Wetterstationen, Stereoanlagen,..... .
Um diese zu Kontaktieren bedarf es möglicherweise IO devices.
=> Die CCU ist demnach ein IO device welches den Zugang zu den Aktoren/Sensoren ermöglicht. Nicht mehr.
=> Will ein User nicht alle Aktoren einbinden ist das kein Problem - warum auch.

B) Die Architektur
Es gibt also den Entity-Interface Layer welcher HMCCUCHN oder DEV ist. Hier werden die Entity Daten (Readings jeder Art) dargestellt und die Komamndos an die Entity geschickt.
Das Interface hierzu "nach oben" sollte möglichst einheitlich zu bestehenden sein.
=> Eine Entity wird also nur einmal definiert
=> die Darstellung/akkumulation/konsolidierung von Werten (Readings) in gesonderten Module (bereits sehr erfolgreich) angeboten
Die CCU ist demnach also für FHEM ein IO-Device. Nicht mehr. Jedes IO hat seine Eigenheiten, genau wie jede Kommunikation. Bei der CCU kann hat man caches mit welchen man umgehen muss. Es können virtuelle Devices erstellt werden, alles kein Problem.

Wenn der Nutzer für diesen Kanal ein HMCCUCHN Device definieren möchte, hat er 2 Möglichkeiten:

er braucht nur eine. Kein added value zu sehen - nur andere Methoden welche bei dir am Ende des Tagen komplexe Suchen und LUTs notwendig machen.

Leider lässt FHEM nicht den gleichen "Zeichenraum" für Devicenames zu wie die CCU. Man kann die Namen also nicht einfach 1:1 übernehmen.

Sollte für dich kein wirkliches Problem sein - oder? Ich habe aus dem Stand 2-3 Ideen, das zu lösen.

P.S.P.S. Auch folgendes ist mit HMCCUCHN möglich, wenn auch nicht häufig genutzt (2xHMCCUCHN für den gleichen Kanal):

Ist ja auch nicht sinnvoll.

Also nichts für ungut. Das ist meine Meinung, mein Verständniss von FHEM. Und bei Architektur, Konformotät und Layering sehe ich wenig bis keinen Spielraum für Abweichungen.
Ich wünsche mir eine geradlinige, einfachen Abstraktion der Entites in FHEM ohne jegliche Sonderwege (welche sonst auch keiner braucht).

[martinp876]

Die kommandos hören sich schon einmal hervorragend an.
Mal sehen, ob ich heute zum testen komme

So nebenbei: dass ich in der ccu die interfaces auswählen muss, welche genutzt werden ist unnötig. Das attribut sollte stillgelegt werden. Offensichtlich ermittelst du sowieso, welchen IF bedient werden kann. User interaktion ist unnötig.

Werte über die ReGa Schnittstelle mit Homematic Script gelesen. Diese Methode benötigt nur 1 CCU-Request, während "get values" einen Request je Kanal braucht.

Super. Was auch immer effizient ist, einfach und robust.

[zap]

Nun, ich stimme nicht zu, bei den Grundsätzen. Namen sind besser - daher vergibt man auch "NAME". Mehr ist nicht notwendig. Das ist FHEM Standart, alles andere nicht.
Einzelne Geräte zu definieren ist jederzeit möglich - auch ohne Sonderwege.Ich verstehe den Inhalt der Aussage nicht. Adressen sind für den User indiskutabel. NAME ist sein zugang.

....

Also nichts für ungut. Das ist meine Meinung, mein Verständniss von FHEM. Und bei Architektur, Konformotät und Layering sehe ich wenig bis keinen Spielraum für Abweichungen.
Ich wünsche mir eine geradlinige, einfachen Abstraktion der Entites in FHEM ohne jegliche Sonderwege (welche sonst auch keiner braucht).

Ich glaube, wir meinen das gleiche. Am besten Du schaust Dir die Module an, testest sie und sagst mir, was Du konkret gerne anders hättest. Die Missverständnisse entstehen vermutlich auch dadurch, dass ich nicht immer in "FHEM-Begriffen" spreche bzw. schreibe.

Speziell nochmal zum Thema NAME vs. Name: Auch hier meinen wir vermutlich das gleiche. Klar wird's so:

define NAME HMCCUCHN CCU-Name

Das ist auch schon alles, was ich damit sagen wollte. Es gibt den FHEM-NAME (den ich natürlich nicht in Frage stelle) und es gibt den CCU-Name. Die ganze Diskussion ist ja daraus entstanden, dass Du mal vorgeschlagen hast, ich solle den Lookup Adresse auf FHEM-Name über sie Gerätedefinition machen. Und ich wollte einfach nur darauf hinweisen, dass das nicht geht, da der Nutzer statt der CCU-Adresse auch den CCU-Namen angeben kann.

Zum Thema eindeutige Entities: Inszwischen hatte ich eine kleine Umfrage gestartet. Keiner scheint mehrere FHEM-Devices je CCU DEvice anzulegen. Das "Feature" ist also spätestens mit dem nächsten Update Geschichte und damit alles wieder schön FHEM-Standard konform.

[martinp876]

Da habe ich mich sicher unklar ausgedrückt.
Der Name der entity in der ccu, welcher auf Kanalbasis vergeben wird ist der ccu-name. Für fhem ist es nur ein reading oder internal. Nicht von Bedeutung, nur informativ. Einzige Nutzung ist bei der automatischen Definition. Hier konnte man es als default namen nutzen.

Der NAME in fhem ist, wenn wir uns aus Sicht fhem unterhalten, der Name der entity. Dieser wird in fhem genutzt um entities anzusprechen.

Die DEF, also definition, sollte eine ein- eindeutige Identifikation der entity sein. Unveränderlich. Da bietet sich die addresse wie nichts anderes an. Drängt sich auf. Für mich alternativlos.

Ich habe es nicht mehr komplett im Kopf. ich wollte das rpc interface umbenennen. Dabei wird in fhem das internal NAME geändert. Es wurde aber ein alias eingetragen. Das wollte ich nicht. Sonst hätte ich einen alias gesetzt. Das ist ein Beispiel einer nicht Konformität.  M.e. unnötig. Man kann es wie alle anderen auch machen.

[martinp876]

Ich habe einmal getestet. Dass ich die dinge anspreche bei welchen ich handlungbedarf sehe ist hoffenlich klar.
Das was schon gut geht sehe ich - danke dafür!

get config:
1) Die Kanalnummer in den Readings muss eliminiert werden. Wir sind Kontext-sensitiv / Objekt orentiert.
Ich weiss also, dass ich Kanal 1 nutze bzw will es nicht wissen. Ich sehe das "kellerlicht". Das macht auch Probleme beim systematischen Auslesen der Readings.
Maximal kann man es mit einer einzigen einstellung in HMCCU direkt umschalten.
2) Die LINK Reading sind ohne Angabe des Peers sinnlos. Das Reading zu Links braucht zwingend die Angabe des Peers. Hier muss demnach auch ein Reading-name welcher den Peer beinhaltet gewählt werden. Anders geht es nicht
3) das Internal "receiver" kann entfernt werden wenn der Kanal kein Receiver ist. Und Umgekehrt
4) Die Liste "sender" in Internals ist sehr hilfreich. Allerdings sollten die " #[OK]" entfernt werden. Eigentlich auch die [SENDER_BROKEN], aber da lasse ich mit mir reden.
Wenn das bei OK entfernt wird kann ich drauf clicken und den Peer betrachten.
5) im Rahmen der Objektorientierung sollte die Device Readings nicht im Kanal dargestellt werden. Das erweckt den Eindruck, dass diese nur für den Kanal eingestellt werden, as falsch ist.
6) Optimierung: Die Basis stimmt also schon. Allerdings hatte ich das identische Problem mit den Registern auch in CUL_HM (logisch, ist identisch). Mein Weg ist, die Anzeige der Readings zu schalten. Die Readings sind als immer vorhanden - je nach sichtbarkeit benenne ich sie um (Rudi war nicht bereit, ein Visiblity-flag einzuführen und hat die Unix-übliche "." variante als einzige Option zugelassen).
Implementiert habe ich das Attribut "expert" welchem ich am ende eine binär-kodierte Zahl hinterlegt habe. Muss der User natürlich nicht verstehen, es gibt vordefinierte settings. Ich extrahiere die Zahl am Begin des Strings und habe einen erklärenden Text nachfolgend. Ich unterscheide "wichtige" register, "alle" register, "raw" (kennt CCU nicht) und Template (muss HMCCU noch kennenlernen!) Hier könnte ich mir vorstellen:
expert 0_off
expert 1_defaultlReg
expert 2_allReg
expert 4_Template
expert 5_Template&defaultReg
expert 255_anything

Da steckt dann etwas arbeit drin. Du musst sämtliche betroffenen Readings von ".LONG_OFF_LEVEL" nach "LONG_OFF_LEVEL" umbenennen und zurück.
Weiter habe ich ein get Kommando im Angbot, welches die Abfrage einzelner Registerwerte erlaubt - oder das ganze als Tabelle.
Ersteres ist für weiterführene Module welche irgendetwas abfragen und Einstellen wollen
zweitere ist für Anwender welche ein Ansprechende Darstellung "in einem Fenster" haben wollen welche sie dann bspw mit einem Text-editor oder excel zwecks vergleich darstellen wollen.


get values:
1) Frage: was ist der Unterschied für den Anwender get update/values? Sind die Werte 'gleichwertig'? Ist das caching unterschiedlich? Wenn ja müssen wir dies internsiv betrachten. Wenn kein solltes du immer das gleiche Interface nutzen
2) Kanal 0 will ich im CHN immer noch nicht sehen. Ein Akkumulierter Status des kanal 0 ist notwendig (Protokol / error), alle Readings pauschal definitiv nicht.
3) Da es sich um einen Update handelt ist eine Anzeige im Resonse-Fenster eher hinderlich.

get update:
1) siehe oben. Warum 2 Kommandos? Was ist der added value?

get deviceDesc:
1) das Device gefällt mir hier nicht. Es zeigt mir nicht, was hier eingestellt werden kann. Mögliche Lösung sind 2 Kommandos. a) get deviceDesc und b) get desc.

get paramsetDesc:
1) hier brauche ich nur die Entity. Wenn ich das Device ändern will sollte ich auch das Device (also CHN_0) öffnen. Das ist bei Kontext-bezogenen Darstellungen so. Damit ist auch klarer, dass es alle Untergeordneten Kanäle betrifft.
2) die enums werden nicht dargestellt. Es macht keinen Sinn, anstelle der Enums die Werte anzuzeigen.
LONG_ACTION_TYPE: ENUM [R,W] [Visible,Sticky] RANGE=0-3 DFLT=1 UNIT=
Mit 0-3 kann keiner etwas anfangen.
3) Aufgrund der Anzahl der Parameter sollte man konsolidieren.
3a) Long/short sind immer identisch mit Ausnahme von Multiexec. Es reicht also diesen Satz einmal anzuzeigen
3b) die Angaben zu Wochenlisten sind entlos lang. Das muss zusammengefasst weren
4) (optional) UNIT könnte weggelassen werden, wenn es leer ist.
   Default ... hm. brauche ich nicht. Ich werden immer die Werte lesen, will ich wissen, was eingestellt ist. Aber es wird sicher jemanden interessieren, auch wennn er nichts damit anfangen kann.
5) Range sollte man nicht 0-8 darstellen sondern 0...8. Hat den Vorteil dass ggf auch -5...-1 sauber dargestellt werden kann.
Beispiel: -2147483648-2147483647 ist zumindest unschön. -2147483648...2147483647
Aber eingentlich sollte man es als Min/Max darstellen. Die einzelnen Parameter wird man intern abfragen müssen, wenn man die Eingabe der Datenpunkte unterstützt.

[martinp876]

Zu dem, was ich mir bei einer kompakten Registertabelle vorstelle hier ein Beispiel eines Rollos in meinem System.
Natürlich sind die Adressen durch Namen zu ersetzen. Es sind nicht alle Devices in der CCU angelernt - ich betreibe es parallel zu CUL_HM. Geht übrigens prima...

Ich denke die Menge der Daten macht deutlich, dass man diese nicht einfach in Readings plumbsen lassen kann. Es Bedarf einer Darstellung.
Auch das Aufräumen MUSS das Modul automatisch übernehmen. Bspw wenn man ein peering entfernt sind mit unter Duzende Register zu entfernen. Muss das System automatisch machen - geht nicht anders.

Natürlich sind Master und Link (Alles mit "ls") "Config" Daten und value "Operational".

So langsam will ich dann auch einmal bedienen. Nun habe ich so einen Steckdosenschalten. Da bekomme ich kein "on" Kommando. Allerdings ein on-for-timer. Das allerdings funktioniert nicht.
Diese Kommandos sollten automatisch generiert werden. Wenn ein Kanal ein Level Bool hat ist sind Kommandos "on/off/toggle" ohne Parameter schon einmal gesetzt. On-For-Timer muss ich noch einmal prüfen. Evlt geht dies nicht immer.... Die Messages sollten alle aber definiert und abrufbar sein. Daraus sollte sich viele Kommandos automatisch erstellen lassen.

Code Auswählen Erweitern

***  HMc_raEss_1 addr:JEQ0116737 chn:1
    AES_ACTIVE  : 0
    CHTyp  : BLIND
peerlist:@1743BF:2,@182083:10,@182083:9,HMc_raEss_1,JEQ0116737:2,HMc_fW_19,HMc_fW_20
@1743BF:2: UI_HINT:
@182083:10: UI_HINT:
@182083:9: UI_HINT:
JEQ0116737:1: UI_HINT: 5
JEQ0116737:2: UI_HINT:
MASTER: AES_ACTIVE: false
MASTER: CHANGE_OVER_DELAY: 1.2
MASTER: REFERENCE_RUNNING_TIME_BOTTOM_TOP: 29
MASTER: REFERENCE_RUNNING_TIME_TOP_BOTTOM: 29
MASTER: REFERENCE_RUN_COUNTER: 0
MASTER: STATUSINFO_MINDELAY: 3
MASTER: STATUSINFO_RANDOM: 0
MASTER: TRANSMIT_TRY_MAX: 6
OEQ1978993:19: UI_HINT:
OEQ1978993:20: UI_HINT:
VALUES: DIRECTION: NONE
VALUES: INHIBIT: false
VALUES: LEVEL: 1
VALUES: WORKING: false
Peer: @1743BF:2 long  short @182083:10 long  short @182083:9 long  short JEQ0116737:1 long  short JEQ0116737:2 long  short OEQ1978993:19 long  short OEQ1978993:20 long  short
ls: ACTION_TYPE: JUMP_TO_TARGET JUMP_TO_TARGET INACTIVE JUMP_TO_TARGET JUMP_TO_TARGET JUMP_TO_TARGET JUMP_TO_TARGET JUMP_TO_TARGET JUMP_TO_TARGET JUMP_TO_TARGET JUMP_TO_TARGET JUMP_TO_TARGET JUMP_TO_TARGET JUMP_TO_TARGET
ls: COND_VALUE_HI: 100 100 0 100 100 100 100 100 100 100 100 100 100 100
ls: COND_VALUE_LO: 50 50 0 50 50 50 50 50 50 50 50 50 50 50
ls: CT_OFF: VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO
ls: CT_OFFDELAY: VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO
ls: CT_ON: VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO
ls: CT_ONDELAY: VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO VALUE_GE_LO
ls: CT_RAMPOFF: X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO
ls: CT_RAMPON: X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO
ls: CT_REFOFF: X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO
ls: CT_REFON: X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO X GE COND_VALUE_LO
ls: DRIVING_MODE: DRIVE_DIRECTLY DRIVE_DIRECTLY DRIVE_DIRECTLY DRIVE_DIRECTLY DRIVE_DIRECTLY DRIVE_DIRECTLY DRIVE_DIRECTLY DRIVE_DIRECTLY DRIVE_DIRECTLY DRIVE_DIRECTLY DRIVE_DIRECTLY DRIVE_DIRECTLY DRIVE_DIRECTLY DRIVE_DIRECTLY
ls: JT_OFF: ON_DELAY RAMP_OFF NOP ON_DELAY RAMP_OFF RAMP_OFF RAMP_OFF RAMP_OFF ON_DELAY ON_DELAY RAMP_OFF ON_DELAY ON_DELAY ON_DELAY
ls: JT_OFFDELAY: ON_DELAY OFF NOP ON_DELAY OFF OFF OFF OFF ON_DELAY ON_DELAY OFF ON_DELAY ON_DELAY ON_DELAY
ls: JT_ON: ON_DELAY RAMP_OFF NOP ON_DELAY RAMP_OFF RAMP_OFF RAMP_OFF RAMP_OFF ON_DELAY ON_DELAY RAMP_OFF ON_DELAY ON_DELAY ON_DELAY
ls: JT_ONDELAY: RAMP_ON RAMP_OFF NOP RAMP_ON RAMP_OFF RAMP_OFF RAMP_OFF RAMP_OFF RAMP_ON RAMP_ON RAMP_OFF RAMP_ON RAMP_ON RAMP_ON
ls: JT_RAMPOFF: 8 8 NO_JUMP_IGNORE_COMMAND 8 8 8 8 8 8 8 8 8
ls: JT_RAMPON: OFFDELAY OFFDELAY NO_JUMP_IGNORE_COMMAND OFFDELAY OFFDELAY OFFDELAY OFFDELAY OFFDELAY ON OFFDELAY OFFDELAY OFFDELAY ON ON
ls: JT_REFOFF: OFF RAMPOFF OFF OFF RAMPOFF RAMPOFF RAMPOFF RAMPOFF OFF OFF RAMPOFF OFF OFF OFF
ls: JT_REFON: RAMPON ON RAMPON RAMPON ON ON ON ON RAMPON RAMPON ON RAMPON RAMPON RAMPON
ls: MAX_TIME_FIRST_DIR: 0.3 0.3 0.5 25.5 0.5 25.5 0.5 25.5 0.5 25.5 25.5 25.5 0.5 25.5
ls: MULTIEXECUTE: OFF OFF ON ON ON OFF ON
ls: OFFDELAY_TIME: 0 0 0 0 0 0 0 0 0 0 0 0 0 0
ls: OFF_LEVEL: 0 0 0 0 0 0 0 0 0 0 0 0 0 0
ls: OFF_TIME: 111600 111600 0 111600 111600 111600 111600 111600 111600 111600 111600 111600 111600 111600
ls: OFF_TIME_MODE: TIME_IS_ABSOLUTE TIME_IS_ABSOLUTE TIME_IS_ABSOLUTE TIME_IS_ABSOLUTE TIME_IS_ABSOLUTE TIME_IS_ABSOLUTE TIME_IS_ABSOLUTE TIME_IS_ABSOLUTE TIME_IS_ABSOLUTE TIME_IS_ABSOLUTE TIME_IS_ABSOLUTE TIME_IS_ABSOLUTE TIME_IS_ABSOLUTE TIME_IS_ABSOLUTE
ls: ONDELAY_TIME: 0 0 0 0 0 0 0 0 0 0 0 0 0 0
ls: ON_LEVEL: 1 1 1 1 1 1 1 1 1 1 1 1 1 1
ls: ON_TIME: 111600 111600 0 111600 111600 111600 111600 111600 111600 111600 111600 111600 111600 111600
ls: ON_TIME_MODE: TIME_IS_ABSOLUTE TIME_IS_ABSOLUTE TIME_IS_ABSOLUTE TIME_IS_ABSOLUTE TIME_IS_ABSOLUTE TIME_IS_ABSOLUTE TIME_IS_ABSOLUTE TIME_IS_ABSOLUTE TIME_IS_ABSOLUTE TIME_IS_ABSOLUTE TIME_IS_ABSOLUTE TIME_IS_ABSOLUTE TIME_IS_ABSOLUTE TIME_IS_ABSOLUTE

p.s.: Im Link ist jede Spalte ein halber registersatz. Also Short/long ist je eine Spalte je peer.

Das ist ein normales Device in einer Konfiguration. Extreme habe ich auch

[zap]

Das Fehlen von 'on' und 'off' ist ein Bug bzw. da habe ich etwas vergessen. Die Befehle toggle, on-for-timer, level, pst, up, down werden ja bereits automatisch generiert. Insofern ist das eine "kleine" Erweiterung.

Zum Thema formatierte Ausgabe: Momentan haben funktionale Dinge Vorrang (wie eben on/off). Mit den Feinheiten der Bildschirmausgabe beschäftige ich mich danach.

Derzeitiger Fahrplan (Reihenfolge):

- Funktionale Dinge in HMCCUCHN komplettieren
  - Automatische Generierung von Befehlen
  - Automatisches Erkennen von Einstellungen, die derzeit noch über Attribute gelöst sind
- Angleichung HMCCUDEV and HMCCUCHN
- Sync CCU/FHEM verbessern (RPC-Server Events usw.)
- Bildschirmausgaben

Das dauert halt, da ich immer Randbedingungen im Auge behalten muss:
- CCU unterstützt neben BidCos und HmIP noch mindestens 6 weitere Protokolle (die mir adhoc einfallen). Die entsprechenden Geräte muss ich entweder rausfiltern oder unterstützen
- Nicht alle CCU Protokolle bieten eine vollwertige RPC-Schnittstelle an
- Manche CCU RPC-Schnittstellen sind binär (kein XML/ASCII). Dafür gibt es keine Standard. Entsprechend implementiert das jeder anders.
- Es gibt User, die mehrere CCUs haben. HMCU unterstützt das zwar, jedoch muss ich aufpassen, dass ich da nichts kaputt mache
- Einige CCU Schnittstellen sind sehr fragil oder sind einfach buggy. Gerade mit CCU2 gibt es immer wieder Performance Engpässe.
- Ich darf keine undokumentierten "Spezialitäten" verwenden. Sowas rächt sich immer, spätestens wenn EQ-3 etwas verändert. Manchmal geht es nicht ohne (Abfrage der CCU Schnittstellen).
- ...

[zap]

Ich werde im Laufe der Woche hier immer mal wieder eine Antwort einfügen. Mit Tests oder direkten Kommentaren bitte bis Freitag warten, da die aktuelle Version im SVN die hier dokumentierten Änderungen noch nicht enthält.

• In Rot Dinge, die ich anders sehe bzw. wo es noch Diskussionsbedarf gibt
• In Blau Dinge, die ich so umsetze oder bereits umgesetzt habe

get config:
1) Die Kanalnummer in den Readings muss eliminiert werden. Wir sind Kontext-sensitiv / Objekt orentiert.
Ich weiss also, dass ich Kanal 1 nutze bzw will es nicht wissen. Ich sehe das "kellerlicht". Das macht auch Probleme beim systematischen Auslesen der Readings.
Maximal kann man es mit einer einzigen einstellung in HMCCU direkt umschalten.

Bei Device vom Typ HMCCUCHN haben die Readings per Default nun keine Kanalnummern mehr (gilt für alle Befehle, die Readings erzeugen oder aktualisieren).

2) Die LINK Reading sind ohne Angabe des Peers sinnlos. Das Reading zu Links braucht zwingend die Angabe des Peers. Hier muss demnach auch ein Reading-name welcher den Peer beinhaltet gewählt werden. Anders geht es nicht

Das sind Link unabhängige Parameter aus dem Parameter Set LINK. Diese können auch dann gelesen und gesetzt werden, wenn gar keine Verknüpfung vorhanden ist.
Beispiel für einen Fensterkontakt (Kanal 1):

Code Auswählen Erweitern

Paramset LINK
    EXPECT_AES: BOOL [R,W] [Visible,Sticky] RANGE=0-1 DFLT=0 UNIT=
    PEER_NEEDS_BURST: BOOL [R,W] [Visible,Sticky] RANGE=0-1 DFLT=0 UNIT=
Ich gehe davon aus, dass diese Parameter relevant sein können, sobald man eine Verknüpfung einrichtet. Insofern macht es für mich Sinn, solche - bezogen auf einen Kanal - globalen Link Einstellungen zuzulassen und auch anzuzeigen.

3) das Internal "receiver" kann entfernt werden wenn der Kanal kein Receiver ist. Und Umgekehrt

Du meinst, wenn in der Device Description keine LINK_SOURCE_ROLE oder keine LINK_TARGET_ROLE definiert ist? Warum gibt es dann für Kanäle, bei denen eine der Rollen fehlt, trotzdem Link-Einträge? Sind das dann Geräte interne Verknüpfungen (gibt es)?

4) Die Liste "sender" in Internals ist sehr hilfreich. Allerdings sollten die " #[OK]" entfernt werden. Eigentlich auch die [SENDER_BROKEN], aber da lasse ich mit mir reden.
Wenn das bei OK entfernt wird kann ich drauf clicken und den Peer betrachten.

Die OKs sind raus. Letztlich interessiert sowieso nur, ob ein Link "broken" ist. Dementsprechend werden nur noch Fehlerstati angezeigt.

5) im Rahmen der Objektorientierung sollte die Device Readings nicht im Kanal dargestellt werden. Das erweckt den Eindruck, dass diese nur für den Kanal eingestellt werden, as falsch ist.

Die sind jetzt raus. Die Readings werden so gemappt:
- LOW_BAT und LOWBAT auf "battery"
- UNREACH auf "activity"
- Alle anderen auf "devstate", sofern sie nicht den Status "normal" bzw "ok" haben.
Man kann die Readings aktivieren, indem man im Attribut "ccuflags" das Flag "devState" setzt. Das Flag "noChn0" wird ignoriert (das ist nun der Default).

6) Optimierung: Die Basis stimmt also schon. Allerdings hatte ich das identische Problem mit den Registern auch in CUL_HM (logisch, ist identisch). Mein Weg ist, die Anzeige der Readings zu schalten. Die Readings sind als immer vorhanden - je nach sichtbarkeit benenne ich sie um (Rudi war nicht bereit, ein Visiblity-flag einzuführen und hat die Unix-übliche "." variante als einzige Option zugelassen).
Implementiert habe ich das Attribut "expert" welchem ich am ende eine binär-kodierte Zahl hinterlegt habe. Muss der User natürlich nicht verstehen, es gibt vordefinierte settings. Ich extrahiere die Zahl am Begin des Strings und habe einen erklärenden Text nachfolgend. Ich unterscheide "wichtige" register, "alle" register, "raw" (kennt CCU nicht) und Template (muss HMCCU noch kennenlernen!) Hier könnte ich mir vorstellen:
expert 0_off
expert 1_defaultlReg
expert 2_allReg
expert 4_Template
expert 5_Template&defaultReg
expert 255_anything

Da steckt dann etwas arbeit drin. Du musst sämtliche betroffenen Readings von ".LONG_OFF_LEVEL" nach "LONG_OFF_LEVEL" umbenennen und zurück.
Weiter habe ich ein get Kommando im Angbot, welches die Abfrage einzelner Registerwerte erlaubt - oder das ganze als Tabelle.
Ersteres ist für weiterführene Module welche irgendetwas abfragen und Einstellen wollen
zweitere ist für Anwender welche ein Ansprechende Darstellung "in einem Fenster" haben wollen welche sie dann bspw mit einem Text-editor oder excel zwecks vergleich darstellen wollen.

get values:
1) Frage: was ist der Unterschied für den Anwender get update/values? Sind die Werte 'gleichwertig'? Ist das caching unterschiedlich? Wenn ja müssen wir dies internsiv betrachten. Wenn kein solltes du immer das gleiche Interface nutzen
2) Kanal 0 will ich im CHN immer noch nicht sehen. Ein Akkumulierter Status des kanal 0 ist notwendig (Protokol / error), alle Readings pauschal definitiv nicht.
3) Da es sich um einen Update handelt ist eine Anzeige im Resonse-Fenster eher hinderlich.

1) hatte ich schonmal geschrieben: "get update" nutzt die ReGa Schnittstelle der CCU. Benötigt nur einen Request, beliebig viele Kanäle eines CCU Device abzufragen. "get values" nutzt die RPC Schnittstelle. Hier ist ein Request je Kanal notwendig. Ich bin immer noch unschlüssig, ob ich "get values" behalten will oder nicht.

2) Ist nun so umgesetzt, siehe Kommentar weiter oben.

3) Du hattest ja darauf hingewiesen, dass es FHEM-Standard ist, dass jeder Get-Befehl Werte zurückgeben muss. Daran habe ich mich nun gehalten. Ein bißchen Standard ist nicht.

get deviceDesc:
1) das Device gefällt mir hier nicht. Es zeigt mir nicht, was hier eingestellt werden kann. Mögliche Lösung sind 2 Kommandos. a) get deviceDesc und b) get desc.

Im Moment lasse ich es so wie es ist. Es zeigt halt mehr Informationen an, als tatsächlich notwendig. Aber damit kann man erst mal leben.

get paramsetDesc:
1) hier brauche ich nur die Entity. Wenn ich das Device ändern will sollte ich auch das Device (also CHN_0) öffnen. Das ist bei Kontext-bezogenen Darstellungen so. Damit ist auch klarer, dass es alle Untergeordneten Kanäle betrifft.

Bitte nenne mir mal die Quelle bei EQ-3, wo beschrieben ist, dass Kanal 0 für das Device steht. Dann werde ich das sofort akzeptieren. Ansonsten gilt: Kanal 0 und das Device haben unterschiedlich Descriptions, verschiedene Parametersets und verschiedene Parameter. Insofern sind sie nicht identisch.

2) die enums werden nicht dargestellt. Es macht keinen Sinn, anstelle der Enums die Werte anzuzeigen.
LONG_ACTION_TYPE: ENUM [R,W] [Visible,Sticky] RANGE=0-3 DFLT=1 UNIT=
Mit 0-3 kann keiner etwas anfangen.

Hatte ich vergessen, die ENUM-Werte werden nun angezeigt.

3) Aufgrund der Anzahl der Parameter sollte man konsolidieren.
3a) Long/short sind immer identisch mit Ausnahme von Multiexec. Es reicht also diesen Satz einmal anzuzeigen
3b) die Angaben zu Wochenlisten sind entlos lang. Das muss zusammengefasst weren
4) (optional) UNIT könnte weggelassen werden, wenn es leer ist.
   Default ... hm. brauche ich nicht. Ich werden immer die Werte lesen, will ich wissen, was eingestellt ist. Aber es wird sicher jemanden interessieren, auch wennn er nichts damit anfangen kann.

Um die Konsolidierung der Ausgabe kümmere ich mich, wenn die funktionalen Themen umgesetzt sind. Das ist alles nur Info, für viele Nutzer eher zweitrangig.

5) Range sollte man nicht 0-8 darstellen sondern 0...8. Hat den Vorteil dass ggf auch -5...-1 sauber dargestellt werden kann.
Beispiel: -2147483648-2147483647 ist zumindest unschön. -2147483648...2147483647
Aber eingentlich sollte man es als Min/Max darstellen. Die einzelnen Parameter wird man intern abfragen müssen, wenn man die Eingabe der Datenpunkte unterstützt.

Wird jetzt als Min ... Max dargestellt.

[martinp876]

Die prio hört sich sinnvoll an!

Peerneedsburst ist ein linkspezifischer parameter. Ebenso wie expectaes. Das liegt bei sendern in der Liste 4. Der sensor sender MUSS  als Initiator wissen, ob der Empfänger uber burst geweckt werden muss. Ähnliches gilt für aes. Ich setze es in alles peerings sorgfältig, prüfe es im system check kommando und setze es automatisch beim peeren.Das ist alles für eine peer<>peer beziehung benötigt. Sonst für nichts.
Ich bin mir hier mehr  sicher. Ich habe es schon oft und intensiv genutzt. Diese register kenne ich persönlich

Zu receiver: bei ip decives ist offensichtlich der eingebaute button auch als taster und sender nutzbar. Ip habe ich noch nichts gemacht. Kommt wenn wir voranschreiten. Ansonsten ist ip faktisch wie rt. Mit wenigen erweiterungen.

Kanal0. Das ist im web interface so realisiert. Ein kanal 0 sehe ich hier nicht. Das ist zusammengafasst.
Warum sollte man es auch trennen? Es ist IMMER eine 1:1beziehung. Niemand muss den unterschied kennen. Es gibt keine überlappungen. Es kann keine verdopplung des kanal 0 geben. Es also zusammenzufassen entspricht dem ccu interface. Es zu trennen bietet keinerlei komfortgewinn sondern eine reduktion. Es verbaut keine eventuellen funktionalitäten für die Zukunft. Die granularität wird nicht verbessert.
Was spricht für die trennung? Ich sehe nichts ausser dass in einem internen interface eine interne unterschiedliche adresse genutzt wird. Diese sollte weitgehend sowieso unsichtbar sein.

[zap]

Nur zur Info: ich habe das Update noch nicht eingecheckt.

Nur mal aus Neugier: wie stellst Du Dir die Abbildung der Device Parameter in einem HMCCUCHN Device vor? Ich meine Paramset MASTER.

Sollen die Readings gar nicht dargestellt werden? Oder doch mit einem Kenner davor, der aufs Device hindeutet?
Setzen der Device Parameter dann doch mit einer "device" Option im Befehl?

Und nein, ich verlasse mich keinesfalls darauf, dass es keine Dopplungen bei Parametenamen in Device und Channel gibt.

[zap]

Ich habe das Update für die Beta mal eingecheckt. Gibt noch das eine oder andere Perl Warning. Aber läuft.