HMCCU 5.0 Beta verfügbar

[zap]

Die Version 4.4 von HMCCU steht nun als Beta im SVN zur Verfügung. Die Beta-Phase wird bald enden (Stand Ende 2020). Da aber noch nicht alles getestet ist und stabil läuft, habe ich die 4 Module zunächst unter

Code: [Auswählen]

contrib/HMCCU/FHEM
sowie auf Github abgelegt.

Installation und Konfiguration

Code: [Auswählen]

update all https://raw.githubusercontent.com/zapccu/HMCCU/master/controls_HMCCU.txt
oder

Code: [Auswählen]

update all https://svn.fhem.de/trac/browser/trunk/fhem/contrib/HMCCU/controls_HMCCU.txt
Zurück zur alten Version 4.3

Dazu einfach FHEM Update ohne separate Quellenangabe ausführen.

Fehler und Erweiterungswünsche

Auf Github gibt es eine Liste der bekannten Fehler und Erweiterungswünsche: https://github.com/zapccu/HMCCU/issues

Vorgehen bei der Konfiguration:

• IO-Device mit Angabe der IP-Adresse der CCU definieren: define myCCU HMCCU IP-Addresse
• Zu verwendenden Schnittstellen auswählen: Aus Dropdown-Liste beim Attribut 'rpcInterfaces' die gewünschten Einträge auswählen
• RPC-Server starten: set myCCU on
• Optional: Autostart der RPC-Server aktivieren: attr myCCU rpcserver on
• Nachdem die RPC Server gestartet wurden (Status ist "running"), die FHEM Config speichern, da beim ersten Start der RPC-Server automatisch für jede ausgewählte Schnittstelle ein FHEM Device vom Typ HMCCURPCPROC angelegt wird

Autodetect von Homematic Geräten

Beim Starten von FHEM liest HMCCU nun alle Geräteparameter von der CCU. Diese Parameter werden verwendet, um bei der Definition eines Device in FHEM anhand der Kanalrolle das neue Device automatisch zu konfigurieren. Dadurch entfallen viele der bisher notwendigen Attribute. Die vorhandenen Devices der HMCCU Version 4.3 kann man auf das neue Verfahren umstellen, indem man für jedes Device einmal den Befehl

Code: [Auswählen]

set defaults reset ausführt. Dabei werden alle HMCCU 4.3 relevanten Attribute gelöscht. Grundsätzlich werden die bisherigen Attribute weiterhin unterstützt, sind aber nicht mehr explizit erforderlich.
Empfehlung: Wer keine allzu große Homematic-Installation hat, sollte überlegen, seine Geräte einfach neu zu definieren. Dann wird man bei der Gerätedefinition auch darauf hingewiesen, HMCCUCHN statt HMCCUDEV zu verwenden, sofern dies möglich und sinnvoll ist.

Definition von FHEM Devices für Homematic Geräte (Autodetect)

Wenn möglich sollte für die Definition von FHEM-Devices das Modul HMCCUCHN verwendet werden. Die meisten Homematic Geräte können über einen einzelnen Kanal gesteuert werden. Wenn HMCCUDEV verwendet wird, obwohl HMCCUCHN möglich ist, weist HMCCU darauf hin, dass HMCCUCHN verwendet werden sollte. Diese Empfehlung kann durch Angabe der Option 'force' beim 'define' ignoriert werden.

Hinweis: Der Kanal 0 ist sowohl bei HMCCUCHN als auch bei HMCCUDEV immer enthalten. Es ist also nicht notwendig, HMCCUDEV zu verwenden, nur im die Datenpunkte aus dem Kanal 0 als Readings darstellen zu können.

Automatische Definition von FHEM Devices mit 'get create' oder 'get createDev'

Der Autodetect-Mechanismus wird nun auch von den Befehlen get create und get createDev verwendet. Daher entfällt hier die Option 't=dev/chn'. Der bei diesen Befehlen anzugebende reguläre Ausdruck bzw. Name für den CCU Gerätenamen bezieht sich nun immer(!) auf Geräte, niemals auf Kanäle. HMCCU erkennt selbständig, ob ein HMCCUDEV oder ein/mehrere HMCCUCHN Device(s) angelegt werden müssen.

Der Befehl get deviceInfo in HMCCU (IO-Device) wurde erweitert. Er zeigt für das abgefragte Gerät eine Empfehlung an, ob HMCCUCHN oder HMCCUDEV für eine Gerätedefinition verwendet werden sollte.

Beispiel: Wenn alle Heizungsgruppen in der CCU mit "G-Heizung" beginnen, legt der folgende Befehl ein FHEM Device für jede Heizungsgruppe an und weist ihm die Attribute 'room' und 'group' zu. Die Geräte in FHEM werden mit dem Präfix "HM_" angelegt:

Code: [Auswählen]

get myCCU create G-Heizung.* p=HM_ room=Homematic group=Heizung
Hinweis: Für die Heizungsgruppen wird HMCCUDEV verwendet, da bei diesen neben dem eigentlichen Kanal zur Temperatursteuerung ein weiterer Kanal existiert, der den Zustand der eingebundenen Fenstersensoren abbildet.

Auch wenn HMCCU den Gerätetyp nicht exakt identifizieren kann, werden die Attribute 'statedatapoint' und 'controldatapoint' nun mit Auswahllisten vorbelegt, die verhindern, dass ungeeignete Datenpunkte für die Steuerung bzw. Statusanzeige ausgewählt werden. Wenn eines der beiden Attribute nicht verfügbar ist, hat das jeweilige Gerät keine lesbaren (statedatapoint) bzw. schreibbaren (controldatapoint) Datenpunkte. Wenn man die FHEM Eingabezeile für das Setzen dieser Attribute verwendet, kann jeder Datenpunkt angegeben werden. Ein 'statedatapoint' muss lesbar, ein 'controldatapoint' beschreibbar sein.

Sonderfälle

Sonderfall Fernbedienungen

Für Geräte mit mehreren identischen Kanälen wie z.B. Fernbedienungen empfehle ich, für jeden Kanal ein HMCCUCHN Device anzulegen. Wenn HMCCUDEV verwendet wird, setzt HMCCU die Attribute 'statedatapoint' und 'controldatapoint' auf den ersten verwendbaren Kanal. Um einen anderen Kanal (eine andere Taste) zu verwenden, müssen beide Attribute entsprechend angepasst werden.
Bei Verwendung von get create oder get createdev legt HMCCU automatisch ein HMCCUCHN Device je Schaltkanal an. An den Devicenamen wird die Kanalnummer angehängt.

Sonderfall Mehrfachschalter mit Kanalgruppen

Ein weiterer Sonderfall sind Mehrfachschalter mit Kanalgruppen, wie sie m.W. nur bei HmIP-Wired vorkommen. Bei diesen Geräten sind immer 2 oder 4 Kanäle zu einem Schaltausgang zusammengefasst. Hier muss zwingend HMCCUDEV verwendet werden, wenn sich Status- und Steuerungskanal unterscheiden. Auch hier erfolgt die Auswahl der gewünschten Kanäle über die Attribute 'statedatapoint' und 'controldatapoint'.

Neue / geänderte Befehle

Neue Befehle des Moduls HMCCU:

• set on/off: Startet oder stoppt die RPC-Server Prozesse, Abkürzung für set rpcserver on/off
• get ccuConfig: Liest die Konfigurationsparameter der CCU (Geräte, Programme, ...) neu ein
• get ccuDevices: Zeigt eine Liste aller Geräte der CCU an
• get create: Definiert FHEM Geräte für eine Gruppe von CCU Geräten. Die Auswahl von HMCCUDEV oder HMCCUCHN erfolgt automatisch
• get createDev: Definiert ein oder mehrere FHEM Gerät(e) für ein CCU Gerät. Die Auswahl von HMCCUDEV oder HMCCUCHN erfolgt automatisch
• get deviceinfo: Zeigt Detailinformationen zu einem CCU Gerät an inkl. Empfehlung für das für die FHEM Gerätedefinition zu verwendende Modul (HMCCUDEV oder HMCCUCHN)
• get paramsetDesc: Zeigt Detailinformationen zu den Parametern eines CCU Gerätes an

Standard Befehle der Module HMCCUDEV und HMCCUCHN:

Die Befehle der Module HMCCUDEV und HMCCUCHN wurden komplett überarbeitet. Viele redundanten Befehle sind weggefallen oder wurden durch andere ersetzt. Sorry, wenn dadurch Aufwand bei der Anpassung von Notifies oder DOIFs entstehen.

• set clear: Readings löschen
• set config: Ein oder mehrere Konfigurations- oder Link-Parameter setzen
• set datapoint: Einen oder mehrere Datenpunkte setzen
• set defaults: Default Attribute setzen. Sollte nur verwendet werden, wenn ein Gerät nicht automatisch von HMCCU erkannt wurde
• set readingFilter: Vereinfacht die Definition des Attributs 'ccureadingfilter'. Die gewünschten Datenpunkte können aus einer Liste ausgewählt werden. Das Attribut 'ccureadingfilter' wird automatisch aus der Auswahl heraus gesetzt

• get config: Liest Konfigurations- und Linkparameter und zeigt sie an. Damit alle Parameter als Readings erscheinen, müssen im Attribut 'ccuflags' die Flags 'showMasterReadings', 'showLinkReadings' 'showServiceReadings' und/oder 'showDeviceReadings' gesetzt werden
• get datapoint: Liest einen Datenpunkt
• get deviceInfo: Zeigt Informationen zu Kanälen und Datenpunkten eines Gerätes an. Die Ausgabe dieses Befehls zusammen mit der Ausgabe von get paramsetDesc hilft mir, nicht automatisch erkannte Geräte in HMCCU zu integrieren. Wenn also ein Gerät nicht erkannt wird, bitte diese beiden Befehle ausführen und die Ausgabe an mich schicken. Beide Befehle können auch direkt im I/O Device ausgeführt werden (also ohne vorher ein HMCCUDEV/CHN Device zu definieren)
• get paramsetDesc: Zeigt Detailinformationen zu den Parametern eines Gerätes an. Zur Verwendung s.o.
• get update: Aktualisiert alle Parameter und Datenpunkte eines Gerätes
• get values: Aktualisiert nur die Datenpunkte eines Gerätes

Für die genaue Syntax der Befehle siehe FHEM Commandref.

Readings

Per Default werden nur Readings zu Datenpunkten (Parameterset VALUES) angezeigt. Die Voreinstellung für 'ccureadingfilter' ist nun '.*'. D.h. es werden keine Datenpunkte gefiltert. Die Anzeige von Readings zum Device, zu Links oder zu Konfigurationsparametern wird über das Attribut 'ccuflags' im jeweiligen FHEM-Device gesteuert. Hier können die Flags 'showDeviceReadings', 'showMasterReadings', 'showLinkReadings' und/oder 'showServiceReadings' gesetzt werden, um die entsprechenden Readings anzeigen zu lassen.
Hinweise:

• Nur die Readings zu Datenpunkten werden von der CCU automatisch aktualisiert (sofern die RPC-Server gestartet sind). Alle anderen Readings müssen mit dem Befehl 'get config' explizit aktualisiert werden.
• Wenn Reading bezogene Attribute geändert werden und die betroffenen Readings bereits intern vorhanden sind, werden die Readings automatisch mit den intern gespeicherten Werten aktualisiert bzw. ergänzt

Einige wichtige Änderungen:

• HMCCU: Der interne RPC Server wurde entfernt. Es wird nur noch HMCCURPCPROC unterstützt. Das Flag procrpc muss nun nicht mehr gesetzt werden. Es wird immer der externe RPC Server verwendet.
• HMCCU: Neues globales Flag 'logCommand' für das Attribut 'ccuflags'. Dadurch werden alle set und get Befehle im FHEM Logfile protokolliert.

• Alle Module: Die Logfile Einträge wurden vereinheitlicht. Neben dem Modulnamen wird nun auch immer die Prozess-ID ausgegeben. Das hilft, Fehler in RPC Server Prozessen zuzuordnen

• HMCCURPCPROC: Jedes RPC-Device liest während der Definition bzw. der Initialisierung Gerätebeschreibungen von der CCU und speichert sie im I/O Device. Dies dauert auf einer CCU3 mit 80 Geräten einige Sekunden. Auf einer CCU2 dürfte es deutlich länger dauern. Dies verzögert den Start von FHEM
• HMCCURPCPROC: Fehler im Handling binärer RPC-Requests (CUxD) behoben.

[martinp876]

Bei mir funktioniert es nicht. Seit dem test, welcher schief ging, bekomme ich die RPC interfaces nicht mehr zum Laufen. Ich bin auf die 4.3 zurückgegangen - ohne Erfolg.
State "inactive/Error"
RPCState inactive

Code: [Auswählen]

Internals:
   CCUNum     1
   CFGFN      ./setup/c_hmCCU.cfg
   Clients    :HMCCUDEV:HMCCUCHN:HMCCURPC:HMCCURPCPROC:
   DEF        192.168.178.46
   FUUID      5c95d10d-f33f-1a31-fbb0-16b25dbd514f7621
   NAME       HMccu
   NOTIFYDEV  global,TYPE=(HMCCU|HMCCUDEV|HMCCUCHN)
   NR         733
   NTFY_ORDER 50-HMccu
   RPCState   inactive
   STATE      inactive/Error
   TYPE       HMCCU
   ccuip      192.168.178.46
   ccustate   active
   ccutype    CCU2/3
   host       192.168.178.46
   prot       http
   version    4.3.020
   READINGS:
     2020-01-06 11:33:16   battery_count   154
     2020-01-06 11:33:16   battery_list    Batterien OK
     2020-01-06 11:33:16   battery_match   0
     2020-01-06 11:33:16   battery_state   ok
     2020-01-05 16:02:45   count_channels  259
     2020-01-05 16:02:45   count_devices   28
     2020-01-05 16:02:45   count_groups    0
     2020-01-05 16:02:45   count_interfaces 3
     2020-01-05 16:02:45   count_programs  5
     2020-01-06 12:48:39   rpcstate        inactive
     2020-01-06 13:35:14   state           Error
   hmccu:
     defInterface BidCos-RF
     defPort    2001
     evtime     0
     evtimeout  0
     rpccount   0
     rpcports   
     updatetime 0
     adr:
     agg:
       battery:
         fcoll      comment
         fcond      any
         fdflt      Batterien OK
         felse      ok
         fexcl     
         fexpr      ^HMc_.*
         fpref      battery_
         fread      battery
         ftrue      low
         ftype      name
       voltage:
         fcoll      comment
         fcond      le
         fdflt      Batteriespannung OK
         felse      0
         fexcl     
         fexpr      (HM-CC-RT-DN|HM-TC-IT-WM-W-EU)
         fpref      voltage_
         fread      BATTERY_STATE
         ftrue      2.2
         ftype      type
     ccu:
       delay      180
       delayed    1
       timeout    1
     dev:
     ifports:
     interfaces:
     rpc:
Attributes:
   ccuaggregate name:battery,filter:name=^HMc_.*,read:battery,if:any=low,else:ok,prefix:battery_,coll:comment!Batterien OK;
name:voltage,filter:type=(HM-CC-RT-DN|HM-TC-IT-WM-W-EU),read:BATTERY_STATE,if:le=2.2,else:0,prefix:voltage_,coll:comment!Batteriespannung OK;
   ccudef-readingfilter .*
   ccudef-readingformat datapointlc
   ccudef-readingname 0.(LOWBAT|LOW_BAT):battery;..LEVEL:+pct;..SET_TEMPERATURE:desired-temp;..ACTUAL_TEMPERATURE:measured-temp;4.control_mode:controlMode
   ccudef-substitute AES_KEY!(0|false):off,(1|true):on;
LOWBAT,LOW_BAT!(0|false):ok,(1|true):low;
UNREACH!(0|false):alive,(1|true):dead;
MOTION!(0|false):noMotion,(1|true):motion;
DIRECTION!0:stop,1:up,2:down,3:undefined;
WORKING!0:false,1:true;
INHIBIT!(0|false):unlocked,(1|true):locked
   ccuflags   procrpc
   cmdIcon    on:general_an off:general_aus
   eventMap   /rpcserver on:on/rpcserver off:off/
   group      IOdev
   room       HMccu,Homematic
   rpcinterfaces BidCos-RF,HmIP-RF,VirtualDevices
   rpcport    2001,2010
   rpcserver  on
   stateFormat rpcstate/state
   stripnumber 2



[zap]

Lösche mal das Attribut rpcport und am besten auch eventuell vorhandene HMCCURPCPROC Devices. Dann FHEM neu starten.

Der Hash vom I/O Device enthält keine Interfaces. Das ist seltsam. Auch das Internal ccuinterfaces fehlt im I/O Device.

[martinp876]

Hat nicht funktioniert.
Ich werde erst am Wochenende wieder Zeit investieren können

[zap]

ok, bis dahin wird es noch das eine oder andere Update geben

[zap]

Ich habe die Module in contrib/HMCCU/FHEM aktualisiert. Die Befehle vom Modul HMCCUCHN wurden angepasst:

set paramset

Ersetzt set config und set rpcparameter. Beide Befehle stehen noch als Alias zur Verfügung. Die Syntax sieht so aus:

set <name> paramset [device] [<paramset>] <parameter>=<value>[:<type>]

Wenn die Option device angegeben ist, bezieht sich der Befehl auf die Geräteadresse. Ansonsten bezieht er sich auf den Kanal des HMCCUCHN Device.
Der Parameter paramset ist der Name eines gültigen Parameter Sets vom Gerät oder Kanal. Gültige Parameter Sets kann man sich mit dem Befehl get devicedesc anzeigen lassen.
Einige Parameter erfordern einen bestimmten Datentyp. Wenn type nicht angegeben ist, wird STRING angenommen. Weiter Datentypen sind BOOL, FLOAT, DOUBLE, INTEGER. Der Datentyp kann der Ausgabe von get paramsetdesc entnommen werden.

get devicedesc

get <name> devicedesc [channel|device]

Zeigt die Geräte- oder die Kanalbeschreibung an. Die Kanalbeschreibung enthält bei einem HMCCUCHN Device immer auch den Kanal 0.

get paramsetdesc

get <name> paramsetdesc [channel|device]

Zeigt die Beschreibung aller Parameter Sets eines Geräts oder eines Kanals an. Bei channel werden auch die Paramsets von Kanal 0 angezeigt.

get configlist

get <name> configlist [channel|device] [<paramset>|ALL] [<filter-expr>]

Zeigt die Parameter eines oder aller Parameter Sets eines Geräts oder eines Kanals an. Bei channel wird immer auch Kanal 0 angezeigt. Wenn keine Parameter Set angegeben wird, werden alle Parameter Sets angezeigt. Mit filter-expr kann die Ausgabe nach einem regulären Ausdruck gefiltert werden.

get config

get <name> config [channel|device] [<paramset>|ALL] [<filter-expr>]

Wie get configlist, speichert die Werte jedoch als Readings.

[martinp876]

Hört sich gut an (noch nichts getestet  )
Besonders gefällt mir der Ansatz, dass ch 0 und das device quasi nicht unterschieden werden.
A) das ist 90% da im set parmset der Anwender das wissen muss. Kannst du das nicht weglassen?
B) ich hätte es anders herum gemacht. Ch0 beinhaltet das device. Somit ist die addresse einer chn entity immer sernr:chan.

Konsequent durchgezogen verschmilzt also (im chan Sektor! ) das device komplett mit ch0. Der Anwender unterscheidet nicht mehr, braucht kein wissen ob ch0 ober device,... . Du solltest auch unterbinden, dass gesonderte entities angelegt werden können.
Die vereinheitlichung erlaubt dem Anwender immer noch alles, aber du hast weniger varianten. M.E. ist macht es auch das Verständnis einfachen. Ob der Parameter nun in ch0 oder dem device verwaltet wird ist schlussendlich egal und rein intern.
Es sowieso hilfreich dem Anwender solche Entscheidungen abzunehmen. Er fragt sich sofort was für einen Unterschied es macht. Keinen. Warum also muss er wählen?

Wieder ein langes Plädoyer 

[zap]

Ich hätte grundsätzlich nichts gegen die Verschmelzung von Channel 0 und dem Device, zumindest für den Anwender. Dann habe ich mir die Device- und Parameterset Descriptions angeschaut.
Laut Device Descriptions verfügt der Kanal 0 über die Parameter Sets "MASTER" und "VALUES". Das Device selbst nur über "MASTER". Ein Auslesen des Parameter Sets "MASTER" von Kanal 0 funktioniert jedoch nicht (zumindest habe ich bisher kein Device gefunden).

Kannst Du diesen Widerspruch erklären? Hier mal ein einfaches Beispiel für einen Fensterkontakt:

Device LEQ0919881
  PARAMSETS: MASTER

Channel LEQ0919881:0
  PARAMSETS: MASTER,VALUES
Channel LEQ0919881:1
  PARAMSETS: LINK,MASTER,VALUES

Wie soll ein Nutzer nun zwischen Device-MASTER und Kanal-0-MASTER entscheiden? Wie gesagt: Kanal-0-MASTER lässt sich nicht auslesen, obwohl er eigentlich da sein müsste. Wenn das immer so ist, kann ich Kanal-0-MASTER immer mit Device-MASTER gleich setzen und alles ist gut. Die Frage ist nur, kann man sich tatsächlich darauf verlassen.

Hier noch die Paramset Description. Wie du siehst, fehlt 0.MASTER

Channel 0
  Paramset VALUES
    AES_KEY: INTEGER [R] [] RANGE=0-127 DFLT=0 UNIT=
    CONFIG_PENDING: BOOL [R,E] [Visible,Sticky,Service] RANGE=0-1 DFLT=0 UNIT=
    DEVICE_IN_BOOTLOADER: BOOL [R,E] [Visible,Sticky,Service] RANGE=0-1 DFLT=0 UNIT=
    LOWBAT: BOOL [R,E] [Visible,Sticky,Service] RANGE=0-1 DFLT=0 UNIT=
    RSSI_DEVICE: INTEGER [R,E] [Visible,Sticky] RANGE=-2147483648-2147483647 DFLT=0 UNIT=
    RSSI_PEER: INTEGER [R,E] [Visible,Sticky] RANGE=-2147483648-2147483647 DFLT=0 UNIT=
    STICKY_UNREACH: BOOL [R,W,E] [Sticky,Internal] RANGE=0-1 DFLT=0 UNIT=
    UNREACH: BOOL [R,E] [Visible,Sticky,Service] RANGE=0-1 DFLT=0 UNIT=
    UPDATE_PENDING: BOOL [R,E] [Visible,Sticky,Service] RANGE=0-1 DFLT=0 UNIT=
Channel 1
  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=
  Paramset MASTER
    AES_ACTIVE: BOOL [R,W] [Visible,Sticky,Internal] RANGE=0-1 DFLT=0 UNIT=
    EVENT_DELAYTIME: FLOAT [R,W] [Visible,Sticky] RANGE=0.000000-7620.000000 DFLT=0.000000 UNIT=s
    MSG_FOR_POS_A: ENUM [R,W] [Visible,Sticky] RANGE=0-2 DFLT=2 UNIT=
    MSG_FOR_POS_B: ENUM [R,W] [Visible,Sticky] RANGE=0-2 DFLT=1 UNIT=
    TRANSMIT_TRY_MAX: INTEGER [R,W] [Visible,Sticky] RANGE=1-10 DFLT=6 UNIT=
  Paramset VALUES
    ERROR: ENUM [R,E] [Visible,Sticky,Service] RANGE=0-7 DFLT=0 UNIT=
    INSTALL_TEST: ACTION [E] [Visible,Sticky,Internal] RANGE=0-1 DFLT=0 UNIT=
    LOWBAT: BOOL [R,E] [Visible,Sticky] RANGE=0-1 DFLT=0 UNIT=
    STATE: BOOL [R,E] [Visible,Sticky] RANGE=0-1 DFLT=0 UNIT=

[martinp876]

zuerst einmal mein Status: Es funktioniert nicht.
Ich hatte einen Update gemacht, dann die 4 Files aus contribute ein-kopiert.
nachdem nichts funktioniert hat habe ich alle HMCCU-elemente aus Config entfernt und neu gestarted.
HMCCU wiki und best-practice genutzt die ccu neu anzulegen. RPC funktioniert nicht.
Zum Anlegen sollte es reichen, die ccu zu definieren und die RPC services in den Attributen zu wählen. Den Rest macht die SW selbst - korrekt?
Beim Anlegen des attr rpcinterfaces bekomme ich

HMCCU: Illegal RPC interface BidCos-RF

Wäre cool wenn du mir helfen könntest - sonst muss ich tiefer debuggen

zu deiner Frage:
Ich werde es testen, wenn es wieder läuft.
Grundsätzlich muss der Anwender nichts über "master" und "Values" wissen. (Link nicht vergessen, allerdings nur für Kanäle >0)

Ich definiere die Gruppen einmal so:
Register: Mein Begriff für remanente Einstellungen welche im Device vorgenommen werden können.
Master: Register welche der entity zugeordnet sind. Sind immer verfügbar (also nicht peer abhängig)
Values: dynamische, nicht remanente Werte wie Status, Batterie, Interface-status,....
Link: Nach dem direkten Peeren einer entity mit einer anderen wird ggf je ein Satz von Registern angelegt. Device und Channel 0 kann man nicht "peeren".
Für Link gibt es also EINE Definition je kanal und N Instanzen, je nachdem wie oft die Entity gepeert ist.

Bei der kombi-Entity Ch0/Device könnte man  die beiden Gruppen schlicht zusammenfassen.
Dem Anwender muss man folgende Infos transportieren
- Register (remanente Steicherung im Device)
  + Diese Werte kann er beeinflussen/setzen/Ändern und muss sie dem Device übertragen. ggf. das Device aufwecken,...
  + Unterschiedung cached, noch nicht übertragen, Setzen erledigt und geprüft,... sind hier wichtig
- Zustände(readings ausser Register-readings)
  + kann man manchmal setzen (level), sind nicht remanent und manchmal zur lesbar (Battery state)

MASTER ist bei Devices wohl immer angelegt, machmal aber leer.
Ich würde einmal einen RT als Testfall nutzen. Da hat eq3 einige besonderheiten eingebaut. Hier bspw sollte MASTER einiges an Inhalt haben. (in CUL_HM habe ich dies mutwillig für den User nach Kanal 4 "verschoben", weil es besser passt.)

[martinp876]

so, bin wieder "on-target". Das Problem war, dass HMCCUConf.pm "falsch" war. Scheinbar haben die kompletten Scripts gefehlt.
Das file in SVN ist korrekt. Wie auch immer dieses Update-Problem entstehen konnte, mir unklar. Vielleicht habe ich es auf selbst verschuldet...

nun kann ich auch testen. Hier also einmal ein RT Device.
Beim RT sehe ich gesonderten Handlungsberarf. Will sagen:
- typisch werden die Daten wie aus der CCU geliefert ausgegebe
- In wenigen Fällen, wie bei der "ellenlangen" Liste der RT oder TC Temparaturen sollte man eine Zusammenfassung erstellen - nur für die Temperaturlisten. Die lange Liste ist störend und hat in voller Länge keinen tieferen Sinn.
Aber hier sind tatsächlich Daten im MASTER des Device.
==> Grundsätzlich alle angegebenen Listen prüfen, auslesen, zusammenfassen, darstellen.

Code: [Auswählen]

   model: HM-CC-RT-DN
----No: 0 typ: dev
   :CHILDREN  : 7
   :FLAGS  : Visible
   :RX_MODE  : CONFIG,BURST,WAKEUP
   :UPDATABLE  : 1
IF type: MASTER
                           MIN |MAX |TYPE |UNIT |DEF |OPER |FLAGS |VALUE_LIST
 ADAPTIVE_REGULATION     : |3 |ENUM |- |- |RW |Visible |OFF with default values,OFF with determined values,ON |
 BACKLIGHT_ON_TIME       : |255 |INTEGER |s |1 |RW |Visible |- |
 BOOST_AFTER_WINDOW_OPEN : |1 |BOOL |- | |RW |Visible |- |
 BOOST_POSITION          : |1 |INTEGER |% |8 |RW |Visible |- |
 BOOST_TIME_PERIOD       : |7 |ENUM |- |- |RW |Visible |0 min,5 min,10 min,15 min,20 min,25 min,30 min |
 BURST_RX                : |1 |BOOL |- |1 |RW |Visible |- |
 BUTTON_LOCK             : |1 |BOOL |- | |RW |Visible |- |
 BUTTON_RESPONSE_WITHOUT_BACKLIGHT : |1 |BOOL |- | |RW |Visible |- |
 CYCLIC_INFO_MSG         : |255 |INTEGER |- |1 |RW |Visible |- |
 CYCLIC_INFO_MSG_DIS     : |255 |INTEGER |- |1 |RW |Visible |- |
 DAYLIGHT_SAVING_TIME    : |1 |BOOL |- |1 |RW |Visible |- |
 DECALCIFICATION_TIME    : |141 |INTEGER |minutes |66 |RW |Visible |- |
 DECALCIFICATION_WEEKDAY : |7 |ENUM |- |- |RW |Visible |SATURDAY,SUNDAY,MONDAY,TUESDAY,WEDNESDAY,THURSDAY,FRIDAY |
 DISPLAY_INFORMATION     : |2 |ENUM |- |- |RW |Visible |TIME,DATE |
 ENDTIME_FRIDAY_1        :5 |144 |INTEGER |minutes |36 |RW |Visible |- |
 ENDTIME_FRIDAY_10       :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
 ENDTIME_FRIDAY_11       :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
 ENDTIME_FRIDAY_12       :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
 ENDTIME_FRIDAY_13       :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
 ENDTIME_FRIDAY_2        :5 |144 |INTEGER |minutes |54 |RW |Visible |- |
 ENDTIME_FRIDAY_3        :5 |144 |INTEGER |minutes |102 |RW |Visible |- |
 ENDTIME_FRIDAY_4        :5 |144 |INTEGER |minutes |132 |RW |Visible |- |
 ENDTIME_FRIDAY_5        :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
 ENDTIME_FRIDAY_6        :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
 ENDTIME_FRIDAY_7        :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
 ENDTIME_FRIDAY_8        :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
 ENDTIME_FRIDAY_9        :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
 ENDTIME_MONDAY_1        :5 |144 |INTEGER |minutes |36 |RW |Visible |- |
 ENDTIME_MONDAY_10       :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
 ENDTIME_MONDAY_11       :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
 ENDTIME_MONDAY_12       :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
 ENDTIME_MONDAY_13       :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
 ENDTIME_MONDAY_2        :5 |144 |INTEGER |minutes |54 |RW |Visible |- |
 ENDTIME_MONDAY_3        :5 |144 |INTEGER |minutes |102 |RW |Visible |- |
 ENDTIME_MONDAY_4        :5 |144 |INTEGER |minutes |132 |RW |Visible |- |
 ENDTIME_MONDAY_5        :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
 ENDTIME_MONDAY_6        :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
 ENDTIME_MONDAY_7        :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
 ENDTIME_MONDAY_8        :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
 ENDTIME_MONDAY_9        :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
 ENDTIME_SATURDAY_1      :5 |144 |INTEGER |minutes |36 |RW |Visible |- |
 ENDTIME_SATURDAY_10     :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
 ENDTIME_SATURDAY_11     :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
 ENDTIME_SATURDAY_12     :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
 ENDTIME_SATURDAY_13     :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
 ENDTIME_SATURDAY_2      :5 |144 |INTEGER |minutes |132 |RW |Visible |- |
 ENDTIME_SATURDAY_3      :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
 ENDTIME_SATURDAY_4      :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
 ENDTIME_SATURDAY_5      :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
 ENDTIME_SATURDAY_6      :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
 ENDTIME_SATURDAY_7      :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
 ENDTIME_SATURDAY_8      :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
 ENDTIME_SATURDAY_9      :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
 ENDTIME_SUNDAY_1        :5 |144 |INTEGER |minutes |36 |RW |Visible |- |
 ENDTIME_SUNDAY_10       :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
 ENDTIME_SUNDAY_11       :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
 ENDTIME_SUNDAY_12       :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
 ENDTIME_SUNDAY_13       :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
 ENDTIME_SUNDAY_2        :5 |144 |INTEGER |minutes |132 |RW |Visible |- |
 ENDTIME_SUNDAY_3        :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
 ENDTIME_SUNDAY_4        :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
 ENDTIME_SUNDAY_5        :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
 ENDTIME_SUNDAY_6        :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
 ENDTIME_SUNDAY_7        :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
 ENDTIME_SUNDAY_8        :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
 ENDTIME_SUNDAY_9        :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
 ENDTIME_THURSDAY_1      :5 |144 |INTEGER |minutes |36 |RW |Visible |- |
 ENDTIME_THURSDAY_10     :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
 ENDTIME_THURSDAY_11     :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
 ENDTIME_THURSDAY_12     :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
 ENDTIME_THURSDAY_13     :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
 ENDTIME_THURSDAY_2      :5 |144 |INTEGER |minutes |54 |RW |Visible |- |
 ENDTIME_THURSDAY_3      :5 |144 |INTEGER |minutes |102 |RW |Visible |- |
 ENDTIME_THURSDAY_4      :5 |144 |INTEGER |minutes |132 |RW |Visible |- |
 ENDTIME_THURSDAY_5      :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
 ENDTIME_THURSDAY_6      :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
 ENDTIME_THURSDAY_7      :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
 ENDTIME_THURSDAY_8      :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
 ENDTIME_THURSDAY_9      :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
 ENDTIME_TUESDAY_1       :5 |144 |INTEGER |minutes |36 |RW |Visible |- |
 ENDTIME_TUESDAY_10      :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
 ENDTIME_TUESDAY_11      :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
 ENDTIME_TUESDAY_12      :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
 ENDTIME_TUESDAY_13      :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
 ENDTIME_TUESDAY_2       :5 |144 |INTEGER |minutes |54 |RW |Visible |- |
 ENDTIME_TUESDAY_3       :5 |144 |INTEGER |minutes |102 |RW |Visible |- |
 ENDTIME_TUESDAY_4       :5 |144 |INTEGER |minutes |132 |RW |Visible |- |
 ENDTIME_TUESDAY_5       :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
 ENDTIME_TUESDAY_6       :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
 ENDTIME_TUESDAY_7       :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
 ENDTIME_TUESDAY_8       :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
 ENDTIME_TUESDAY_9       :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
 ENDTIME_WEDNESDAY_1     :5 |144 |INTEGER |minutes |36 |RW |Visible |- |
 ENDTIME_WEDNESDAY_10    :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
 ENDTIME_WEDNESDAY_11    :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
 ENDTIME_WEDNESDAY_12    :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
 ENDTIME_WEDNESDAY_13    :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
 ENDTIME_WEDNESDAY_2     :5 |144 |INTEGER |minutes |54 |RW |Visible |- |
 ENDTIME_WEDNESDAY_3     :5 |144 |INTEGER |minutes |102 |RW |Visible |- |
 ENDTIME_WEDNESDAY_4     :5 |144 |INTEGER |minutes |132 |RW |Visible |- |
 ENDTIME_WEDNESDAY_5     :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
 ENDTIME_WEDNESDAY_6     :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
 ENDTIME_WEDNESDAY_7     :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
 ENDTIME_WEDNESDAY_8     :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
 ENDTIME_WEDNESDAY_9     :5 |144 |INTEGER |minutes |144 |RW |Visible |- |
 GLOBAL_BUTTON_LOCK      : |1 |BOOL |- | |RW |Visible |- |
 I_VALUE_EXTERN          :1 |2 |INTEGER |- |15 |RW |Visible |- |
 I_VALUE_INTERN          :1 |2 |INTEGER |- |15 |RW |Visible |- |
 LOCAL_RESET_DISABLE     : |1 |BOOL |- | |RW |Visible |- |
 LOW_BAT_LIMIT           :0 |12 |FLOAT |V |3 |RW |Visible |- |
 MANU_MODE_PRIORITIZATION : |5 |ENUM |- |- |RW |Visible |SET_TEMPERATURE_CHANGE_ONLY_BY_RT_TC_SC_SELF,SET_TEMPERATURE_CHANGE_BY_ALL,SET_TEMPERATURE_CHANGE_ONLY_BY_RT_TC_CCU_SELF,SET_TEMPERATURE_CHANGE_ONLY_BY_CCU,SET_TEMPERATURE_CHANGE_ONLY_BY_SELF |
 MIN_MAX_VALUE_NOT_RELEVANT_FOR_MANU_MODE : |1 |BOOL |- | |RW |Visible |- |
 MODUS_BUTTON_LOCK       : |1 |BOOL |- | |RW |Visible |- |
 PARTY_MODE_PRIORITIZATION : |5 |ENUM |- |- |RW |Visible |SET_TEMPERATURE_CHANGE_ONLY_BY_RT_TC_SC_SELF,SET_TEMPERATURE_CHANGE_BY_ALL,SET_TEMPERATURE_CHANGE_ONLY_BY_RT_TC_CCU_SELF,SET_TEMPERATURE_CHANGE_ONLY_BY_CCU,SET_TEMPERATURE_CHANGE_ONLY_BY_SELF |
 P_START_VALUE_EXTERN    :5 |45 |INTEGER |- |3 |RW |Visible |- |
 P_START_VALUE_INTERN    :5 |45 |INTEGER |- |3 |RW |Visible |- |
 P_VALUE_EXTERN          :25 |35 |INTEGER |- |3 |RW |Visible |- |
 P_VALUE_INTERN          :25 |35 |INTEGER |- |3 |RW |Visible |- |
 SHOW_WEEKDAY            : |1 |BOOL |- | |RW |Visible |- |
 TEMPERATUREFALL_MODUS   : |5 |ENUM |- |- |RW |Visible |DEAKTIV,AUTOMODE,AUTO + MANUMODE,AUTO + PARTYMODE,AKTIV |
 TEMPERATUREFALL_VALUE   :0.5 |2.5 |FLOAT |K |1.4 |RW |Visible |- |
 TEMPERATUREFALL_WINDOW_OPEN :5 |30 |FLOAT |�C |12 |RW |Visible |- |
 TEMPERATUREFALL_WINDOW_OPEN_TIME_PERIOD : |6 |INTEGER |minutes |15 |RW |Visible |- |
 TEMPERATURE_COMFORT     :15 |30 |FLOAT |�C |21 |RW |Visible |- |
 TEMPERATURE_FRIDAY_1    :5 |30 |FLOAT |�C |17 |RW |Visible |- |
 TEMPERATURE_FRIDAY_10   :5 |30 |FLOAT |�C |17 |RW |Visible |- |
 TEMPERATURE_FRIDAY_11   :5 |30 |FLOAT |�C |17 |RW |Visible |- |
 TEMPERATURE_FRIDAY_12   :5 |30 |FLOAT |�C |17 |RW |Visible |- |
 TEMPERATURE_FRIDAY_13   :5 |30 |FLOAT |�C |17 |RW |Visible |- |
 TEMPERATURE_FRIDAY_2    :5 |30 |FLOAT |�C |21 |RW |Visible |- |
 TEMPERATURE_FRIDAY_3    :5 |30 |FLOAT |�C |17 |RW |Visible |- |
 TEMPERATURE_FRIDAY_4    :5 |30 |FLOAT |�C |21 |RW |Visible |- |
 TEMPERATURE_FRIDAY_5    :5 |30 |FLOAT |�C |17 |RW |Visible |- |
 TEMPERATURE_FRIDAY_6    :5 |30 |FLOAT |�C |17 |RW |Visible |- |
 TEMPERATURE_FRIDAY_7    :5 |30 |FLOAT |�C |17 |RW |Visible |- |
 TEMPERATURE_FRIDAY_8    :5 |30 |FLOAT |�C |17 |RW |Visible |- |
 TEMPERATURE_FRIDAY_9    :5 |30 |FLOAT |�C |17 |RW |Visible |- |
 TEMPERATURE_LOWERING    :5 |25 |FLOAT |�C |17 |RW |Visible |- |
 TEMPERATURE_MAXIMUM     :15 |30.5 |FLOAT |�C |30.5 |RW |Visible |- |
 TEMPERATURE_MINIMUM     :4.5 |14.5 |FLOAT |�C |4.5 |RW |Visible |- |
 TEMPERATURE_MONDAY_1    :5 |30 |FLOAT |�C |17 |RW |Visible |- |
 TEMPERATURE_MONDAY_10   :5 |30 |FLOAT |�C |17 |RW |Visible |- |
 TEMPERATURE_MONDAY_11   :5 |30 |FLOAT |�C |17 |RW |Visible |- |
 TEMPERATURE_MONDAY_12   :5 |30 |FLOAT |�C |17 |RW |Visible |- |
 TEMPERATURE_MONDAY_13   :5 |30 |FLOAT |�C |17 |RW |Visible |- |
 TEMPERATURE_MONDAY_2    :5 |30 |FLOAT |�C |21 |RW |Visible |- |
 TEMPERATURE_MONDAY_3    :5 |30 |FLOAT |�C |17 |RW |Visible |- |
 TEMPERATURE_MONDAY_4    :5 |30 |FLOAT |�C |21 |RW |Visible |- |
 TEMPERATURE_MONDAY_5    :5 |30 |FLOAT |�C |17 |RW |Visible |- |
 TEMPERATURE_MONDAY_6    :5 |30 |FLOAT |�C |17 |RW |Visible |- |
 TEMPERATURE_MONDAY_7    :5 |30 |FLOAT |�C |17 |RW |Visible |- |
 TEMPERATURE_MONDAY_8    :5 |30 |FLOAT |�C |17 |RW |Visible |- |
 TEMPERATURE_MONDAY_9    :5 |30 |FLOAT |�C |17 |RW |Visible |- |
 TEMPERATURE_OFFSET      : |15 |ENUM |- |- |RW |Visible |-3.5K,-3.0K,-2.5K,-2.0K,-1.5K,-1.0K,-0.5K,0.0K,0.5K,1.0K,1.5K,2.0K,2.5K,3.0K,3.5K |
 TEMPERATURE_SATURDAY_1  :5 |30 |FLOAT |�C |17 |RW |Visible |- |
 TEMPERATURE_SATURDAY_10 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
 TEMPERATURE_SATURDAY_11 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
 TEMPERATURE_SATURDAY_12 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
 TEMPERATURE_SATURDAY_13 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
 TEMPERATURE_SATURDAY_2  :5 |30 |FLOAT |�C |21 |RW |Visible |- |
 TEMPERATURE_SATURDAY_3  :5 |30 |FLOAT |�C |17 |RW |Visible |- |
 TEMPERATURE_SATURDAY_4  :5 |30 |FLOAT |�C |17 |RW |Visible |- |
 TEMPERATURE_SATURDAY_5  :5 |30 |FLOAT |�C |17 |RW |Visible |- |
 TEMPERATURE_SATURDAY_6  :5 |30 |FLOAT |�C |17 |RW |Visible |- |
 TEMPERATURE_SATURDAY_7  :5 |30 |FLOAT |�C |17 |RW |Visible |- |
 TEMPERATURE_SATURDAY_8  :5 |30 |FLOAT |�C |17 |RW |Visible |- |
 TEMPERATURE_SATURDAY_9  :5 |30 |FLOAT |�C |17 |RW |Visible |- |
 TEMPERATURE_SUNDAY_1    :5 |30 |FLOAT |�C |17 |RW |Visible |- |
 TEMPERATURE_SUNDAY_10   :5 |30 |FLOAT |�C |17 |RW |Visible |- |
 TEMPERATURE_SUNDAY_11   :5 |30 |FLOAT |�C |17 |RW |Visible |- |
 TEMPERATURE_SUNDAY_12   :5 |30 |FLOAT |�C |17 |RW |Visible |- |
 TEMPERATURE_SUNDAY_13   :5 |30 |FLOAT |�C |17 |RW |Visible |- |
 TEMPERATURE_SUNDAY_2    :5 |30 |FLOAT |�C |21 |RW |Visible |- |
 TEMPERATURE_SUNDAY_3    :5 |30 |FLOAT |�C |17 |RW |Visible |- |
 TEMPERATURE_SUNDAY_4    :5 |30 |FLOAT |�C |17 |RW |Visible |- |
 TEMPERATURE_SUNDAY_5    :5 |30 |FLOAT |�C |17 |RW |Visible |- |
 TEMPERATURE_SUNDAY_6    :5 |30 |FLOAT |�C |17 |RW |Visible |- |
 TEMPERATURE_SUNDAY_7    :5 |30 |FLOAT |�C |17 |RW |Visible |- |
 TEMPERATURE_SUNDAY_8    :5 |30 |FLOAT |�C |17 |RW |Visible |- |
 TEMPERATURE_SUNDAY_9    :5 |30 |FLOAT |�C |17 |RW |Visible |- |
 TEMPERATURE_THURSDAY_1  :5 |30 |FLOAT |�C |17 |RW |Visible |- |
 TEMPERATURE_THURSDAY_10 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
 TEMPERATURE_THURSDAY_11 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
 TEMPERATURE_THURSDAY_12 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
 TEMPERATURE_THURSDAY_13 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
 TEMPERATURE_THURSDAY_2  :5 |30 |FLOAT |�C |21 |RW |Visible |- |
 TEMPERATURE_THURSDAY_3  :5 |30 |FLOAT |�C |17 |RW |Visible |- |
 TEMPERATURE_THURSDAY_4  :5 |30 |FLOAT |�C |21 |RW |Visible |- |
 TEMPERATURE_THURSDAY_5  :5 |30 |FLOAT |�C |17 |RW |Visible |- |
 TEMPERATURE_THURSDAY_6  :5 |30 |FLOAT |�C |17 |RW |Visible |- |
 TEMPERATURE_THURSDAY_7  :5 |30 |FLOAT |�C |17 |RW |Visible |- |
 TEMPERATURE_THURSDAY_8  :5 |30 |FLOAT |�C |17 |RW |Visible |- |
 TEMPERATURE_THURSDAY_9  :5 |30 |FLOAT |�C |17 |RW |Visible |- |
 TEMPERATURE_TUESDAY_1   :5 |30 |FLOAT |�C |17 |RW |Visible |- |
 TEMPERATURE_TUESDAY_10  :5 |30 |FLOAT |�C |17 |RW |Visible |- |
 TEMPERATURE_TUESDAY_11  :5 |30 |FLOAT |�C |17 |RW |Visible |- |
 TEMPERATURE_TUESDAY_12  :5 |30 |FLOAT |�C |17 |RW |Visible |- |
 TEMPERATURE_TUESDAY_13  :5 |30 |FLOAT |�C |17 |RW |Visible |- |
 TEMPERATURE_TUESDAY_2   :5 |30 |FLOAT |�C |21 |RW |Visible |- |
 TEMPERATURE_TUESDAY_3   :5 |30 |FLOAT |�C |17 |RW |Visible |- |
 TEMPERATURE_TUESDAY_4   :5 |30 |FLOAT |�C |21 |RW |Visible |- |
 TEMPERATURE_TUESDAY_5   :5 |30 |FLOAT |�C |17 |RW |Visible |- |
 TEMPERATURE_TUESDAY_6   :5 |30 |FLOAT |�C |17 |RW |Visible |- |
 TEMPERATURE_TUESDAY_7   :5 |30 |FLOAT |�C |17 |RW |Visible |- |
 TEMPERATURE_TUESDAY_8   :5 |30 |FLOAT |�C |17 |RW |Visible |- |
 TEMPERATURE_TUESDAY_9   :5 |30 |FLOAT |�C |17 |RW |Visible |- |
 TEMPERATURE_WEDNESDAY_1 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
 TEMPERATURE_WEDNESDAY_10 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
 TEMPERATURE_WEDNESDAY_11 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
 TEMPERATURE_WEDNESDAY_12 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
 TEMPERATURE_WEDNESDAY_13 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
 TEMPERATURE_WEDNESDAY_2 :5 |30 |FLOAT |�C |21 |RW |Visible |- |
 TEMPERATURE_WEDNESDAY_3 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
 TEMPERATURE_WEDNESDAY_4 :5 |30 |FLOAT |�C |21 |RW |Visible |- |
 TEMPERATURE_WEDNESDAY_5 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
 TEMPERATURE_WEDNESDAY_6 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
 TEMPERATURE_WEDNESDAY_7 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
 TEMPERATURE_WEDNESDAY_8 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
 TEMPERATURE_WEDNESDAY_9 :5 |30 |FLOAT |�C |17 |RW |Visible |- |
 VALVE_ERROR_RUN_POSITION : |1 |INTEGER |% |15 |RW |Visible |- |
 VALVE_MAXIMUM_POSITION  : |1 |INTEGER |% |1 |RW |Visible |- |
 VALVE_OFFSET            : |1 |INTEGER |% | |RW |Visible |- |
                           MIN |MAX |TYPE |UNIT |DEF |OPER |FLAGS |VALUE_LIST

----No: 0 typ: MAINTENANCE
   :DIRECTION  : NONE
   :DPs  : VALUES,MASTER
   :FLAGS  : Internal,Visible
   :PARAMSETS  : MASTER,VALUES
IF type: MASTER
IF type: VALUES
                           MIN |MAX |TYPE |UNIT |DEF |OPER |FLAGS |VALUE_LIST
 AES_KEY                 : |127 |INTEGER |- | |R |- |- |
 CONFIG_PENDING          : |1 |BOOL |- | |RE |Visible,Service |- |
 DEVICE_IN_BOOTLOADER    : |1 |BOOL |- | |RE |Service,Visible |- |
 INHIBIT                 : |1 |BOOL |- | |RWE |Visible |- |
 LOWBAT                  : |1 |BOOL |- | |RE |Visible,Service |- |
 RSSI_DEVICE             :-128 |127 |INTEGER |- | |RE |Visible |- |
 RSSI_PEER               :-128 |127 |INTEGER |- | |RE |Visible |- |
 STICKY_UNREACH          : |1 |BOOL |- | |RWE |Service,Sticky,Visible |- |
 UNREACH                 : |1 |BOOL |- | |RE |Sticky,Service,Visible |- |
 UPDATE_PENDING          : |1 |BOOL |- | |RE |Service,Visible |- |
                           MIN |MAX |TYPE |UNIT |DEF |OPER |FLAGS |VALUE_LIST


[zap]

Möglicherweise reden wir aneinander vorbei. Mein Problem ist nicht MASTER vom Device, sondern die Tatsache, dass sowohl das Device als auch der Kanal 0 jeweils einen MASTER haben (laut RPC Device Description). Wenn das nicht so wäre, könnte ich einfach den Kanal 0 mit dem Device gleichsetzen und könnte mir die leidige "device" Option in den Befehlen schenken.

Bei allen meinen Tests hat MASTER vom Kanal 0 niemals Werte geliefert. Auch eine Paramset Description kann man dafür nicht abfragen. Wenn das immer so wäre, könnte man also das Kanal 0 MASTER ignorieren bzw. automatisch auf das Device MASTER gehen. Die Frage ist halt: hat sich EQ-3 dabei etwas gedacht und gibt es Geräte, die im MASTER von Kanal 0 tatsächlich Parameter haben.

[martinp876]

Ich habe das noch nicht endgültig probiert, wo master zu finden sind und wo nicht. Ich sehe es aber
A) als notwendig immer auf inhalte zu prüfen. Eq3 könnte ein neues device  auf den markt bringen
B) für die implementierung den user interface als irrelevant, ob das register im device oder kanal0 enthalten ist. Der user bekommt einen registernamen in welchen er inhalte schreiben kann. Deine sw muss in diesem fall wissen ob es ins device oder den kanal geschrieben wird.

Semantisch verstehe ich kanal0 als das Kommunikations interface und device als kanalübergreifende settings.
Am interface kann man bisher wenig einstellen. Ich muss aber einmal prüfen wo die re-transmitt register verankert sind.
In culhm habe ich hier nicht unterschieden. Die addressierung geht gemäß eq3 nach listen. Diese haben einen wertebereich von 0 bis 9.
Der anwender muss sich aber darum nicht kümmern, das mache ich intern. Nur wenn er auf die raw ebene zugreift ist es relevant. Das hat nach meiner Kenntnis noch niemand genutzt (außer mir). Warum auch.

[martinp876]

So, habe nun (endlich) deine neuen Kommandos getestst. Allerdings ohne Erfolg.
Bei unterschiedlichen kanäle habe ich keine Antwort bekommen auf
- configlist device/channel
- config
- devicedesc device/channel
- paramsetdesc device/channel

Einzig deviceinfo geht wir vor.
Mache ich grundsätzlich etwas falsch?

[zap]

Oh!
Da habe ich wohl eine falsche Version von 88_HMCCURPCPROC im contrib eingecheckt. Da werden beim Start von FHEM leider die RPC Definitionen nicht gelesen.
Du kannst Dir behelfen, indem Du im jeweiligen HMCCURPCPROC DEvice einmal "get devicedesc" ausführst. Das liest die Paramset Definitionen neu ein. Danach müssten die Befehle funktionieren.
Ich checke auch gleich das korrigierte Modul ein.

Update: Hab's eingecheckt. Die anderen 3 Module sind von gestern Abend. Die musst Du natürlich auch installieren.

[martinp876]

klappt nun alles, danke.

Ich fange einmal mit dem Review an.
get <HMccuChn> paramsetdesc
Ich würde die Auswahl channel/device streichen. Mein Vorschlag ist wie schon vormals erwähnt, das "Device" im "Chan0" zusammenzufassen.
Wähle ich "Channel" als Option bei einem Kanal >0 bekomme ich immer auch Kanal0. Das macht keinen Sinn und ist typisch eh wenig interessante Info. Ch0 bezieht sich auf "die Kommunikation" und ist bei 90% aller Geräte identisch.
Antrag 1) Kanal 0 wird nur für Kanal 0 ausgegeben.
Antrag 2) Device wird immer automatisch bei Kanal 0 ausgegeben
Antrag 3) als Überschrift wäre der DeviceTyp und der KanalTyp schön

Beim Parametersatz "link" der Aktoren gibt es immer short/long. Diese sind identisch.
Einschub: Ausnahme ist Multiexec welches nur bei Long Sinn macht. Das unterschlage ich, da es am Ende weder einen inhaltlichen noch einen funktionalen oder semanitschen unterschied macht
Kompakter wäre es, den Block als short/long zu markieren und nur "short" anzuzeigen. Hinweis einbauen, dass Long parallel exitiert.
Antrag 4) short/long nur einmal darstellen
Anmerkung: Wenn der Linktyp short/long beinhaltet, dann komplett. Wenn der Linktyp dies nicht beinhaltet, dann auch komplett


get <HMccuChn> config/configList
- Ich sehe nicht, dass bei config die Register als Readings gespeichert werden
- ich verstehe nicht, warum man speichern in Readings manuell anstossen muss. Das sollte immer passieren, wenn gelesen wurde. In CUL_HM speichere ich die Register in "hidden" readings. Über das Attribut "expert" kann man es sichtbar schalten. Ok, ist einiges an Arbeit, die Umschaltung. Aber sinnvoll.

Zum Inhalt: Link Readings
Im Gegensatz zu Parameter-Description gibt es den Link Satz bei den eigentlichen Parametern. Link bedeutet, dass das Device gepeert ist und zu diesem peering ein Registersatz existiert.
=> für jedes einzelne Peering existiert ein Link-Datensatz.
=> du musst also zuerst die Links auslesen, dann die Link-Parametersätze
Antrag 5) Liste aller Peers des Kanals ausgeben.
Mit dem Hintergrund wird die Liste mit Unter ziemlich lang.
In CUL_HM habe ich aus genau diesem Grund bei der Ausgabe die tabellarische Form gewählt. Also eine Zeile je Register und eine Spalte je peer.
Bei Short/long habe ich es noch einmal verkürzt: eine Zeile je Register"Typ" und je eine Spalte je Peer-Short Peer-Long
Antrag 6) Tabelarische Ausgabe der Link-Basierenden Register


get <HMccuChn> Devicedescription
Antrag 7) eine Option Device/Channel. Device wie immer in Channel0 darstellen. Channel 0 in allen anderen Channels ausblenden.
Wie bei allen Kommandos
Antrag Ausblenden (unterdrücken) unnötiger Zeilen. Dies sind ADDRESS,INDEX,PARENT,VERSION
Antrag 9) Optional: Ausblenden (unterdrücken) leerer Zeilen.
Antrag 10) TARGET_ROLES ist eigentlich eine Liste. Dies sollte auch so dargestellt werden. Der Trenner ist das Leerzeichen. Das werden wir später noch brauchen, wenn PeeringOptionen ergründet werden

Channel IEQ0545891:0
  AES_ACTIVE: 0
  FLAGS: Visible,Internal
  PARAMSETS: MASTER,VALUES
  PARENT_TYPE: HM-LC-Dim1TPBU-FM
  TYPE: MAINTENANCE

Channel IEQ0545891:1
  AES_ACTIVE: 0
  DIRECTION: RECEIVER
  FLAGS: Visible
  LINK_TARGET_ROLES: SWITCH,WCS_TIPTRONIC_SENSOR,WEATHER_CS
  PARAMSETS: LINK,MASTER,VALUES
  PARENT_TYPE: HM-LC-Dim1TPBU-FM
  TYPE: DIMMER

get <HMccuChn> deviceinfo
das wird, nehme ich an, obsolet.

get <HMccuChn> datapoint
klappt bei mir nicht. Muss ich etwa besonderes tun?

Nachtrag:klappt jetzt.
Antrag 11) alle Datenpunkte aus der "VALUES" Liste auf einmal lesen und IMMER in Readings darstellen.
Das sind operationelle Zustände. Diese einzeln zu Lesen macht keinen Sinn, jeder will immer alle sehen. Diese müssen auch immer in Readings dargestellt werden. Bedingungslos!
Eingeltlich sollten die Readings automatisch, ohne Kommando, upgedated werden. Ein "force-read-device-states" wäre notwendig, wenn es bedenken beim automatischen update gibt. Sonst ist es obsolet.
Eine Ausgabe in ein Reply-Fenster ist nicht notwendig. Die Readings sind bedingungslos sichtbar. Methoden zum Abgragen/Ausgeben von Readings sind in FHEM standart. Modul-spezifische Methoden sollten nur angeboten werden, wenn es gewichtige Gründe gibt.