Autor Thema: HMCCU 4.4 Beta verfügbar  (Gelesen 9973 mal)

Offline zap

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3313
    • HMCCU
HMCCU 4.4 Beta verfügbar
« am: 05 Januar 2020, 19:49:52 »
Die Version 4.4 von HMCCU steht nun als Beta im SVN zur Verfügung. Da noch nicht alles getestet ist und stabil läuft, habe ich die 4 Module zunächst unter

contrib/HMCCU/FHEM

abgelegt. Wer die Module testen möchte, kopiert sie sich ins FHEM Verzeichnis.

WARNUNG! Die Software hat garantiert noch Fehler. Daher sei vor der Verwendung in produktiven Umgebungen gewarnt!

Ich freue mich über jedes Feedback.

Folgendes hat sich geändert bzw. ist neu:

  • 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: Der Befehl 'get parfile' sowie das Attribut 'parfile' wurden entfernt.
  • 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. Für das CUxD Interface funktioniert das leider noch nicht, daher habe ich es für diese Schnittstelle deaktiviert (es schießt die CCU ab).
  • HMCCURPCPROC: Fehler im Handling binärer RPC-Requests behoben.
  • HMCCURPCPROC: Neuer Befehl 'get devicedesc'. Liest die Geräte- und Parameterbeschreibungen aller CCU-Geräte, die dem Interface des RPC-Device zugeordnet sind und speichert sie im I/O Device.
  • HMCCUCHN/HMCCUDEV: Das Attribut 'ccucalculate' wurde um die Operation 'set' ergänzt. Dadurch kann man einem Reading bestimmte Werte eines oder mehrerer Datenpunkte zuweisen. Dabei werden auch Variablen unterstützt. Anwendungsbeispiele folgen.
  • HMCCUCHN/HMCCUDEV: Das Reading 'state' wird beim Start von FHEM nicht mehr auf 'pending' oder 'initialized' gesetzt. Dadurch bleiben Werte aus dem FHEM Statefile erhalten.
  • HMCCUCHN/HMCCUDEV: Das Attribut 'ccureadingname' akzeptiert nun beliebige Formate für Readingnames (s. commandref).
  • HMCCUCHN: Die Befehle 'get config', 'get configlist', 'get configdesc' basieren nun auf den Informationen, die beim Start der RPC Server von der CCU gelesen werden. Das beschleunigt diese Befehle, da keine / weniger RPC Requests abgesetzt werden.
  • HMCCUCHN/HMCCUDEV: Der Befehl 'get configlist' gibt nun Informationen zu den Parametersets MASTER und LINK aus.
  • HMCCUCHN/HMCCUDEV: Neuer Befehl 'get devicedesc' zur Ausgabe der Gerätebeschreibung.
« Letzte Änderung: 05 Januar 2020, 20:52:05 von zap »
2xCCU3, diverse Komponenten (Fenster, Rolladen, Themostate, Stromzähler, Steckdosen ...)
FHEM mit Raspi für CCU Integration.
IOBroker für UI (VIS), Hue, Sonos usw.
Maintainer der Module FULLY, Meteohub und HMCCU (Schnittstelle CCU-FHEM = best of both worlds approach

Offline martinp876

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 10696
Antw:HMCCU 4.4 Beta verfügbar
« Antwort #1 am: 06 Januar 2020, 13:41:19 »
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
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


Offline zap

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3313
    • HMCCU
Antw:HMCCU 4.4 Beta verfügbar
« Antwort #2 am: 06 Januar 2020, 13:56:53 »
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.
2xCCU3, diverse Komponenten (Fenster, Rolladen, Themostate, Stromzähler, Steckdosen ...)
FHEM mit Raspi für CCU Integration.
IOBroker für UI (VIS), Hue, Sonos usw.
Maintainer der Module FULLY, Meteohub und HMCCU (Schnittstelle CCU-FHEM = best of both worlds approach

Offline martinp876

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 10696
Antw:HMCCU 4.4 Beta verfügbar
« Antwort #3 am: 07 Januar 2020, 20:46:35 »
Hat nicht funktioniert.
Ich werde erst am Wochenende wieder Zeit investieren können

Offline zap

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3313
    • HMCCU
Antw:HMCCU 4.4 Beta verfügbar
« Antwort #4 am: 08 Januar 2020, 08:41:03 »
ok, bis dahin wird es noch das eine oder andere Update geben
2xCCU3, diverse Komponenten (Fenster, Rolladen, Themostate, Stromzähler, Steckdosen ...)
FHEM mit Raspi für CCU Integration.
IOBroker für UI (VIS), Hue, Sonos usw.
Maintainer der Module FULLY, Meteohub und HMCCU (Schnittstelle CCU-FHEM = best of both worlds approach

Offline zap

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3313
    • HMCCU
Antw:HMCCU 4.4 Beta verfügbar
« Antwort #5 am: 10 Januar 2020, 17:16:28 »
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.

« Letzte Änderung: 10 Januar 2020, 17:30:08 von zap »
2xCCU3, diverse Komponenten (Fenster, Rolladen, Themostate, Stromzähler, Steckdosen ...)
FHEM mit Raspi für CCU Integration.
IOBroker für UI (VIS), Hue, Sonos usw.
Maintainer der Module FULLY, Meteohub und HMCCU (Schnittstelle CCU-FHEM = best of both worlds approach

Offline martinp876

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 10696
Antw:HMCCU 4.4 Beta verfügbar
« Antwort #6 am: 10 Januar 2020, 18:42:56 »
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  ;)

Offline zap

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3313
    • HMCCU
Antw:HMCCU 4.4 Beta verfügbar
« Antwort #7 am: 10 Januar 2020, 19:00:39 »
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=

2xCCU3, diverse Komponenten (Fenster, Rolladen, Themostate, Stromzähler, Steckdosen ...)
FHEM mit Raspi für CCU Integration.
IOBroker für UI (VIS), Hue, Sonos usw.
Maintainer der Module FULLY, Meteohub und HMCCU (Schnittstelle CCU-FHEM = best of both worlds approach

Offline martinp876

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 10696
Antw:HMCCU 4.4 Beta verfügbar
« Antwort #8 am: 11 Januar 2020, 08:57:06 »
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
Zitat
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.)


Offline martinp876

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 10696
Antw:HMCCU 4.4 Beta verfügbar
« Antwort #9 am: 11 Januar 2020, 12:05:01 »
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.


   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

Offline zap

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3313
    • HMCCU
Antw:HMCCU 4.4 Beta verfügbar
« Antwort #10 am: 11 Januar 2020, 13:51:55 »
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.
2xCCU3, diverse Komponenten (Fenster, Rolladen, Themostate, Stromzähler, Steckdosen ...)
FHEM mit Raspi für CCU Integration.
IOBroker für UI (VIS), Hue, Sonos usw.
Maintainer der Module FULLY, Meteohub und HMCCU (Schnittstelle CCU-FHEM = best of both worlds approach

Offline martinp876

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 10696
Antw:HMCCU 4.4 Beta verfügbar
« Antwort #11 am: 11 Januar 2020, 16:07:26 »
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.

Offline martinp876

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 10696
Antw:HMCCU 4.4 Beta verfügbar
« Antwort #12 am: 11 Januar 2020, 16:52:18 »
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?

Offline zap

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3313
    • HMCCU
Antw:HMCCU 4.4 Beta verfügbar
« Antwort #13 am: 11 Januar 2020, 17:48:41 »
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.
« Letzte Änderung: 11 Januar 2020, 17:56:15 von zap »
2xCCU3, diverse Komponenten (Fenster, Rolladen, Themostate, Stromzähler, Steckdosen ...)
FHEM mit Raspi für CCU Integration.
IOBroker für UI (VIS), Hue, Sonos usw.
Maintainer der Module FULLY, Meteohub und HMCCU (Schnittstelle CCU-FHEM = best of both worlds approach

Offline martinp876

  • Moderator
  • Hero Member
  • ***
  • Beiträge: 10696
Antw:HMCCU 4.4 Beta verfügbar
« Antwort #14 am: 12 Januar 2020, 12:08:32 »
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 8) 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 :)

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

Zitat
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.


« Letzte Änderung: 12 Januar 2020, 12:18:17 von martinp876 »