Ich habe mir zum Testen eine Umgebung aufgebaut und dort Homematic per HMCCU angebunden.
Im Produktivsystem nutze ich VCCU mit HMUARTLGW. Damit bin ich seit Jahren zufrieden.
Der Testaufbau dient der Migration in Container und der Option zu HomematicIP.
Leider ist HMCCU nicht nutzbar, bzw. die Unterstützung ist für mich nicht ausreichend.
HM-LC-Sw1-Pl-2
HM-ES-PMSw1-Pl
HM-LC-Sw1-Pl-DN-R1
HM-Sec-SCo
HM-LC-Bl1-FM
sind korrekt im FHEM vorhanden.
Für mich wichtig sind aber auch
HM-LC-DIM1PWM-CV
HM-RC-12
Die beiden Gerätetypen sind nicht nutzbar.
Bei der Fernbedienung HM-RC-12 erscheinen keine Readings welche man als Tastendruck auswerten kann.
Fpr den Dimmer HM-LC-DIM1PWM-CV wired nur ein Kanal angelegt. Da hat mal jemand behauptet es wäre so, das stimmt aber nicht. https://forum.fhem.de/index.php?topic=123686.msg1192501#msg1192501 (https://forum.fhem.de/index.php?topic=123686.msg1192501#msg1192501)
Da ich keine Anleitung zur Korrektur der HMCCUConfig.pm gefunden habe und auf https://forum.fhem.de/index.php?topic=140640.0 (https://forum.fhem.de/index.php?topic=140640.0) keine Tipps kamen, fällt für mich HMCCU raus.
(Die Kanäle kann man zwar manuell anlegen, aber dort sind sie nicht steuerbar)
Weitere Gerätetypen habe ich dann nicht mehr getestet.
Schade, aber verständlich.
Grundsätzlich kann man mit HMCCU jedes Homematic Gerät in FHEM integrieren und steuern. Nur der bequeme Weg per "get createDev" steht nur für Geräte zur Verfügung, deren Kanäle und Rollen in HMCCUConf.pm hinterlegt sind.
Für alle anderen Geräte verwendet man das klassische define. Die Steuerung erfolgt dann über "set datapoint" und "set config". Alle notwendigen Informationen für diese Befehle (Namen und Bedeutung der Datenpunkte und Parameter) kann in dem umfangreichen PDF von EQ-3 nachgelesen werden.
Für die Fernbedienung gilt das gleiche wie für die Abfrage aller Tastendrücke: Die CCU schickt nur Events zu Tastendrücken, wenn die Tasten in einem Dummy Programm in der CCU zumindest abgefragt werden. Das ist auch kein Fehler von HMCCU. In anderen Smarthome Plattformen wie zB ioBroker und Homeassistant funktioniert es auf die gleiche Weise.
Dann musst du dir wohl über kurz oder lang eine Alternative zu Homematic suchen. Gerade bei Zigbee gibt es da inzwischen viele und v.a. günstigere Alternativen.
Der Hinweis zu den Tastendrücken könnte schon hilfreich sein, danke. Das heißt aber auch Neues lernen.
Der wichtigste Punkt wäre für mich die Verwendung der Dimmer. Da ist in der HMCCUConf.pm ein Fehler, weil vor einiger Zeit jemand hier im Forum seine CCU nicht bedienen konnte und behauptet hat die hätten nur einen Kanal. Ich denke das selbst zu korrigieren erfordert noch neues Wissen.
Ich habe leider für die Dimmer keine Alternative außerhalb Homematic gefunden. Ein Dimmer mit mehreren logisch verbundenen Kanälen ist mir noch nicht aufgefallen.
Ich könnte es in FHEM nachbilden, hier halte ich Hardware aber für die bessere Lösung.
Zitat von: rabehd am 11 Februar 2025, 09:56:01Der wichtigste Punkt wäre für mich die Verwendung der Dimmer. Da ist in der HMCCUConf.pm (https://hmccuconf.pm/) ein Fehler, weil vor einiger Zeit jemand hier im Forum seine CCU nicht bedienen konnte und behauptet hat die hätten nur einen Kanal. Ich denke das selbst zu korrigieren erfordert noch neues Wissen.
was hindert dich, den dimmer weiterhin über cul_hm zu nutzen, wenn du es aktuell nicht über hmccu schaffst?
Zitat von: rabehd am 11 Februar 2025, 09:56:01Der Hinweis zu den Tastendrücken könnte schon hilfreich sein, danke. Das heißt aber auch Neues lernen.
Dazu muss man nichts lernen. Du musst nur ein "Programm" anlegen, in dem die Tasten alle erwähnt werden. Es muss noch nichtmal eine Aktion zugewiesen werden. Das Ganze kann man sich zusammenklicken, siehe Screenshot aus debmatic für eine 8-Kanal-Fernbedienung. Man kann in dem Programm auch mehrere Fernbedienungen auf gleiche Art und Weise hinterlegen und muss nicht für jede ein eigenes Programm erstellen.
Und auch, wenn man nur "Tastendruck kurz" ausgewählt hat, reicht das völlig, um auch lange Tastendrücke in FHEM gemeldet zu bekommen.
Zitat von: rabehd am 11 Februar 2025, 09:56:01Der wichtigste Punkt wäre für mich die Verwendung der Dimmer. Da ist in der HMCCUConf.pm ein Fehler, weil vor einiger Zeit jemand hier im Forum seine CCU nicht bedienen konnte und behauptet hat die hätten nur einen Kanal. Ich denke das selbst zu korrigieren erfordert noch neues Wissen.
Wenn dem tatsächlich so ist und es wirklich ein "Fehler" in der HMCCUConf.pm ist, kann ich mir schwer vorstellen, dass der Maintainer das nicht korrigieren würde.
Zitat von: betateilchen am 11 Februar 2025, 11:26:12Dazu muss man nichts lernen. Du musst nur ein "Programm" anlegen, in dem die Tasten alle erwähnt werden. Es muss noch nichtmal eine Aktion zugewiesen werden. Das Ganze kann man sich zusammenklicken, siehe Screenshot aus debmatic für eine 8-Kanal-Fernbedienung. Man kann in dem Programm auch mehrere Fernbedienungen auf gleiche Art und Weise hinterlegen und muss nicht für jede ein eigenes Programm erstellen.
Ich konnte es noch nicht abschätzen, danke für den Input.
Das probiere ich auf jeden Fall, auch wenn ich die zukünftige Verwendung der CCU erstmal nicht mehr plane.
Zitat von: betateilchen am 11 Februar 2025, 11:28:18Wenn dem tatsächlich so ist und es wirklich ein "Fehler" in der HMCCUConf.pm (https://hmccuconf.pm/) ist, kann ich mir schwer vorstellen, dass der Maintainer das nicht korrigieren würde.
Zumindest hat zap nicht in der Richtung reagiert. Ich glaube auch gelesen zu haben, das er weg von FHEM ist und deshalb nur noch wenig für Pflege aufwendet.
Sein Verweis auf define wird wohl die hmccuconfig umgehen. Das hatte ich schon mal mit wenig Wissen probiert, die Kanäle liesen sich nicht einstellen.
Zitat von: frank am 11 Februar 2025, 10:16:18was hindert dich, den dimmer weiterhin über cul_hm zu nutzen, wenn du es aktuell nicht über hmccu schaffst?
Aktuell nichts, solange ich nicht HomematicIP brauche. Ich plane FHEM in Docker-Container, dafür muss HMUARTLGW durchgereicht werden oder per IP angebunden werden. Es gibt also noch viel auszuprobieren.
Zum Dimmer, hier: https://www.eq-3.de/Downloads/eq3/download%20bereich/hm_web_ui_doku/HM-Script_4-Datenpunkte.pdf
Ab Seite 72.
Ein normaler Kanal und 3 virtuelle. Bisher konnte mir niemand die 4 Kanalrollen nennen. Wenn die korrekt in HMCCUConf wären, müsste ein HMCCUDEV angelegt werden.
Zitat von: zap am 11 Februar 2025, 21:05:12Bisher konnte mir niemand die 4 Kanalrollen nennen.
Das sollte möglich sein. ;)
Danke für Deine Antwort und die Bereitschaft zu helfen.
Der Dimmer hat 3 vituelle Kanäle, die man als eigene Dimmer betrachten kann. Man kann alle Befehle für jeden Kanal ausführen.
Die 3 virtuellen Kanäle sind logisch miteinander verknüpft und deren Ergebnis ist der "normale" Kanal.
Die Verknüpfung geht auf der CCU oder über das setzen der Register.
Erklärt ist das hier https://de.elv.com/elvwissen/elvhilft/virtuelle-homematic-aktorkanaele-und-ihre-verknuepfungslogik/ (https://de.elv.com/elvwissen/elvhilft/virtuelle-homematic-aktorkanaele-und-ihre-verknuepfungslogik/)
Sind alle Kanäle mit OR verknüpft und K1 steht auf 20, K2 auf 35 und K3 auf 10, dann kommt real 35 raus.
Bei meinem Aquarium habe ich einen Kanal mit NOR verknüpft und kann damit den Kanal als Wolken nutzen und die Sonne reduzieren.
Fazit: nur die 3 virtuellen Kanäle dürfen verändert werden. Der "normale" (Ergebnis-) Kanal zeigt nur das Ergebnis an.
Hilft das?
Die Funktionsweise der virtuellen Kanäle ist bekannt. Bei HmIp weit verbreitet.
Mir würde die Ausgabe von "get deviceInfo" für den Dimmer helfen. Kann im IO Device ausgeführt werden mit Namen oder Adresse des Dimmers als Parameter. Den Dimmer kann man bei "get deviceInfo" im IO Device normalerweise aus der Dropdown Liste auswählen.
Ist es das was Du brauchst?
DEV HM-LC-Dim1PWM-CV LEQ0878063 LEQ0878063 interface=BidCos-RF type=HM-LC-Dim1PWM-CV
CHN LEQ0878063:0 HM-LC-Dim1PWM-CV LEQ0878063:0
0.UNREACH = false {b} [RE]
0.STICKY_UNREACH = false {b} [RWE]
0.CONFIG_PENDING = false {b} [RE]
0.DUTYCYCLE = false {b} [RE]
0.RSSI_DEVICE = -128 {i} [RE]
0.RSSI_PEER = -184 {i} [RE]
0.DEVICE_IN_BOOTLOADER = false {b} [RE]
0.UPDATE_PENDING = false {b} [RE]
0.AES_KEY = 0 {i} [R]
CHN LEQ0878063:1 HM-LC-Dim1PWM-CV LEQ0878063:1
1.LEVEL = 0.000000 {a} [RWE]
1.OLD_LEVEL = {b} [W]
1.LEVEL_REAL = 0.000000 {f} [RE]
1.RAMP_TIME = {f} [W]
1.ON_TIME = {f} [W]
1.RAMP_STOP = {b} [W]
1.INHIBIT = false {b} [RWE]
1.ERROR_REDUCED = false {b} [RE]
1.ERROR_OVERHEAT = false {b} [RE]
1.DIRECTION = 0 {i} [RE]
1.INSTALL_TEST = {b} [W]
1.WORKING = false {b} [RE]
CHN LEQ0878063:2 HM-LC-Dim1PWM-CV LEQ0878063:2
2.LEVEL = 0.000000 {a} [RWE]
2.OLD_LEVEL = {b} [W]
2.LEVEL_REAL = 0.000000 {f} [RE]
2.RAMP_TIME = {f} [W]
2.ON_TIME = {f} [W]
2.RAMP_STOP = {b} [W]
2.INHIBIT = false {b} [RWE]
2.ERROR_REDUCED = false {b} [RE]
2.ERROR_OVERHEAT = false {b} [RE]
2.DIRECTION = 0 {i} [RE]
2.INSTALL_TEST = {b} [W]
2.WORKING = false {b} [RE]
CHN LEQ0878063:3 HM-LC-Dim1PWM-CV LEQ0878063:3
3.LEVEL = 0.000000 {a} [RWE]
3.OLD_LEVEL = {b} [W]
3.LEVEL_REAL = 0.000000 {f} [RE]
3.RAMP_TIME = {f} [W]
3.ON_TIME = {f} [W]
3.RAMP_STOP = {b} [W]
3.INHIBIT = false {b} [RWE]
3.ERROR_REDUCED = false {b} [RE]
3.ERROR_OVERHEAT = false {b} [RE]
3.DIRECTION = 0 {i} [RE]
3.INSTALL_TEST = {b} [W]
3.WORKING = false {b} [RE]
Device detection:
StateDatapoint = 1.LEVEL [DIMMER]
ControlDatapoint = 1.LEVEL [DIMMER]
Recommended module for device definition: HMCCUCHN
Device description
Device LEQ0878063 HM-LC-Dim1PWM-CV LEQ0878063 [HM-LC-Dim1PWM-CV]
CHILDREN: LEQ0878063:0,LEQ0878063:1,LEQ0878063:2,LEQ0878063:3
FIRMWARE: 2.9
FLAGS: Visible
INTERFACE: VEQ1111743
PARAMSETS: MASTER
RF_ADDRESS: 2901055
ROAMING: 0
RX_MODE: ALWAYS,LAZY_CONFIG
UPDATABLE: 1
Channel LEQ0878063:0 HM-LC-Dim1PWM-CV LEQ0878063:0 [MAINTENANCE]
AES_ACTIVE: 0
DIRECTION: NONE
FLAGS: Visible,Internal
PARAMSETS: MASTER,VALUES
PARENT: LEQ0878063
PARENT_TYPE: HM-LC-Dim1PWM-CV
Channel LEQ0878063:1 HM-LC-Dim1PWM-CV LEQ0878063:1 [DIMMER] known
AES_ACTIVE: 0
DIRECTION: RECEIVER
FLAGS: Visible
LINK_TARGET_ROLES: SWITCH,WCS_TIPTRONIC_SENSOR,WEATHER_CS
PARAMSETS: LINK,MASTER,VALUES
PARENT: LEQ0878063
PARENT_TYPE: HM-LC-Dim1PWM-CV
Channel LEQ0878063:2 HM-LC-Dim1PWM-CV LEQ0878063:2 [VIRTUAL_DIMMER]
AES_ACTIVE: 0
DIRECTION: RECEIVER
FLAGS: Visible
LINK_TARGET_ROLES: SWITCH,WCS_TIPTRONIC_SENSOR,WEATHER_CS
PARAMSETS: LINK,MASTER,VALUES
PARENT: LEQ0878063
PARENT_TYPE: HM-LC-Dim1PWM-CV
Channel LEQ0878063:3 HM-LC-Dim1PWM-CV LEQ0878063:3 [VIRTUAL_DIMMER]
AES_ACTIVE: 0
DIRECTION: RECEIVER
FLAGS: Visible
LINK_TARGET_ROLES: SWITCH,WCS_TIPTRONIC_SENSOR,WEATHER_CS
PARAMSETS: LINK,MASTER,VALUES
PARENT: LEQ0878063
PARENT_TYPE: HM-LC-Dim1PWM-CV
Weiß jemand wie man ein Gerät aus der CCU erzeugt, welches in der HMCCUConf.pm nicht vorhanden, bzw. dort fehlerhaft ist?
Du kannst es komplett manuell selbst mithilfe der Attribute anlegen/definieren/zum korrekten Funktionieren bringen. Das einzige, was du am Anfang brauchst, ist die Geräte-Adresse aus der CCU und je nachdem, ob du über HMCCUCHN oder HMCCUDEV gehen möchtest noch mit Doppelpunkt und Kanalnummer oder eben ohne. Die Hilfe von HMCCU ist dazu sehr umfangreich.
Zitat von: Ralli am 23 Februar 2025, 07:32:37Du kannst es komplett manuell selbst mithilfe der Attribute anlegen/definieren/zum korrekten Funktionieren bringen. Das einzige, was du am Anfang brauchst, ist die Geräte-Adresse aus der CCU und je nachdem, ob du über HMCCUCHN oder HMCCUDEV gehen möchtest noch mit Doppelpunkt und Kanalnummer oder eben ohne. Die Hilfe von HMCCU ist dazu sehr umfangreich.
Und wie geht das?
Ernsthaft?
Das steht wirklich alles sehr gut beschrieben in der Hilfe zu HMCCU bzw. zu HMCCUCHN und HMCCUDEV und ich würde hier nur wiederkauen.
Du musst es halt lesen, anwenden, ausprobieren und nachschärfen.
Ein Beispiel für ein Dimmer-Device, welches über HMCCUDEV definiert ist:
defmod TMO_Deckenlicht HMCCUDEV OEQ123456
attr TMO_Deckenlicht IODev CCU2
attr TMO_Deckenlicht ccureadingfilter (UNREACH|^LEVEL$|DIRECTION)
attr TMO_Deckenlicht ccuscaleval LEVEL:0:1:0:100
attr TMO_Deckenlicht cmdIcon on:general_an off:general_aus
attr TMO_Deckenlicht controldatapoint 1.LEVEL
attr TMO_Deckenlicht event-on-change-reading 0.UNREACH,control,state
attr TMO_Deckenlicht eventMap {usr=> { '^(100|[1-9][0-9]|[1-9])$' => 'datapoint 1.LEVEL ".$1."' }}
attr TMO_Deckenlicht statedatapoint 1.LEVEL
attr TMO_Deckenlicht statevals on:100,off:0
attr TMO_Deckenlicht stripnumber 1
attr TMO_Deckenlicht substexcl control
attr TMO_Deckenlicht substitute ERROR_OVERHEAT,ERROR_OVERLOAD,ERROR_REDUCED!(0|false):no,(1|true):yes;;LEVEL!#0-0:off,#1-100:on;;DIRECTION!0:none,1:up,2:down,3:undefined
attr TMO_Deckenlicht webCmd control:on:off
attr TMO_Deckenlicht widgetOverride control:slider,0,10,100
Und hier ein Beispiel für ein Homematic-Wired-Device (Kanal eines Multi-IO-Gerätes) über HMCCUCHN:
defmod AB_Fenster HMCCUCHN OEQ123456:2
attr AB_Fenster IODev CCU2
attr AB_Fenster event-on-change-reading state
attr AB_Fenster statedatapoint SENSOR
attr AB_Fenster substitute SENSOR!(1|true):open,(0|false):closed
Aktuell fehlt in der HMCCUConf.pm die Definition der Rolle "VIRTUAL_DIMMER". Die werde ich ergänzen.
Aber(!): HMCCU unterstützt nicht mehrere Control-Datenpunkte. D.h. Set-Befehle wie z.B. "set pct" können sich im selben FHEM-Device nur auf einen von 2 identischen Kanälen beziehen (in diesem Fall Kanal 2 oder 3).
Es gibt 2 Möglichkeiten:
1) Aktuell, wenn solange HMCCUConf.pm noch nicht angepasst wurde:
Ein HMCCUDEV anlegen:
define FHEM-Device HMCCUDEV Adresse forceDev
Eigentlich sollte dabei automatisch statedatapoint und controldatapoint auf 1.LEVEL zeigen (kann man mit einem "List" prüfen). D.h. Set-Befehle beziehen sich auf 1.LEVEL (was Du nicht möchtest, wenn ich es richtig verstehe, was aber valide ist, wenn jemand die Verknüpfungslogik nicht benötigt).
Du kannst aber trotzdem LEVEL in den den beiden virtuellen Kanälen 2+3 ändern mit:
set FHEM-Device datapoint 2.LEVEL Wert
set FHEM-Device datapoint 3.LEVEL Wert
Mit dem Attribut eventMap (FHEM Standard) kannst Du Dir dafür auch Shortcuts definieren, z.B.
set FHEM-Device pct2 Wert
set FHEM-Device pct3 Wert
2) Nach Anpassung der HMCCUConf.pm
Dann wird "get createDev" 3 HMCCUCHN Devices anlegen. Dann ist die Steuerung der Kanäle sauber getrennt, aber eben mit 3 Devices.
Zitat von: zap am 25 Februar 2025, 10:01:162) Nach Anpassung der HMCCUConf.pm (https://hmccuconf.pm/)
Dann wird "get createDev" 3 HMCCUCHN Devices anlegen. Dann ist die Steuerung der Kanäle sauber getrennt, aber eben mit 3 Devices.
Bei Cul_HM sind es 4 Device.
Einmal das "Master"-Device mit den 3 Channels. Da läßt sich beim Dimmer nichts einstellen.
Die 3 Channels als eigene Device sind wie eigene Dimmer, was ich auch erwarte.
Für mich die beste Lösung.
Zitat von: zap am 25 Februar 2025, 10:01:16define FHEM-Device HMCCUDEV Adresse forceDev
Eigentlich sollte dabei automatisch statedatapoint und controldatapoint auf 1.LEVEL zeigen (kann man mit einem "List" prüfen). D.h. Set-Befehle beziehen sich auf 1.LEVEL (was Du nicht möchtest, wenn ich es richtig verstehe, was aber valide ist, wenn jemand die Verknüpfungslogik nicht benötigt).
Du kannst aber trotzdem LEVEL in den den beiden virtuellen Kanälen 2+3 ändern mit:
set FHEM-Device datapoint 2.LEVEL Wert
set FHEM-Device datapoint 3.LEVEL Wert
Das klappt ganz gut. Alle Channels in einem Device ist übersichtlich.
Man müßte da aber aktuell mit userreadings arbeiten, denn die Radings pct, level und state zeigen nicht die realen Wert des gesamten Dimmers, sondern des Channel 1. Ich hätte hier den Wert aus LEVEL_REAL erwartet.
bei den Set-Befehlen such ich noch. Die Ramp-Zeit geht wohl verloren. Da war wohl auch mal so bei CUL_HM.
ZitatInternals:
CFGFN
DEF LEQ0878063 forceDev
FUUID 67bd9eec-f33f-294e-d189-2e3de0c5567ee37c
IODev RaspberryMatic
NAME LD_blau_2.Mond
NR 317
STATE 95
TYPE HMCCUDEV
ccuaddr LEQ0878063
ccudevstate active
ccuif BidCos-RF
ccuname HM-LC-Dim1PWM-CV LEQ0878063
ccurolectrl DIMMER
ccurolestate DIMMER
ccusubtype HM-LC-Dim1PWM-CV
ccutype HM-LC-Dim1PWM-CV
eventCount 39
firmware 2.9
readonly no
OLDREADINGS:
READINGS:
2025-02-25 11:56:47 1.DIRECTION none
2025-02-25 11:56:47 1.ERROR_OVERHEAT false
2025-02-25 11:56:47 1.ERROR_REDUCED false
2025-02-25 11:43:56 1.INHIBIT false
2025-02-25 11:56:47 1.LEVEL 95
2025-02-25 11:56:47 1.LEVEL_REAL 10
2025-02-25 11:56:47 1.WORKING no
2025-02-25 11:51:35 2.DIRECTION NONE
2025-02-25 11:51:35 2.ERROR_OVERHEAT false
2025-02-25 11:51:35 2.ERROR_REDUCED false
2025-02-25 11:43:56 2.INHIBIT false
2025-02-25 11:51:35 2.LEVEL 88
2025-02-25 11:56:47 2.LEVEL_REAL 10
2025-02-25 11:51:35 2.WORKING false
2025-02-25 11:46:22 3.DIRECTION NONE
2025-02-25 11:46:22 3.ERROR_OVERHEAT false
2025-02-25 11:46:22 3.ERROR_REDUCED false
2025-02-25 11:43:56 3.INHIBIT false
2025-02-25 11:46:22 3.LEVEL 90
2025-02-25 11:56:47 3.LEVEL_REAL 10
2025-02-25 11:46:22 3.WORKING false
2025-02-25 11:43:56 activity alive
2025-02-25 11:56:47 control 95
2025-02-25 11:56:47 devstate ok
2025-02-25 11:56:47 hmstate 95
2025-02-25 11:56:47 level 95
2025-02-25 11:56:47 pct 95
2025-02-25 11:43:56 rssidevice N/A
2025-02-25 11:43:56 rssipeer N/A
2025-02-25 11:43:56 sign off
2025-02-25 11:56:47 state 95
hmccu:
channels 4
detect 1
devspec LEQ0878063
forcedev 1
nodefaults 0
role 0:MAINTENANCE,1:DIMMER,2:VIRTUAL_DIMMER,3:VIRTUAL_DIMMER
setDefaults 0
cmdlist:
get
set toggle:noArg stop:noArg on-for-timer on-till up on:noArg down pct off:noArg level
control:
chn 1
dpt LEVEL
dp:
0.AES_KEY:
VALUES:
NVAL 0
SVAL off
VAL 0
0.CONFIG_PENDING:
VALUES:
NVAL 0
SVAL false
VAL 0
0.DEVICE_IN_BOOTLOADER:
VALUES:
NVAL 0
SVAL false
VAL 0
0.DUTYCYCLE:
VALUES:
NVAL 0
SVAL false
VAL 0
0.RSSI_DEVICE:
VALUES:
NVAL N/A
SVAL N/A
VAL -65535
0.RSSI_PEER:
VALUES:
NVAL N/A
SVAL N/A
VAL -65535
0.STICKY_UNREACH:
VALUES:
NVAL 0
SVAL false
VAL 0
0.UNREACH:
VALUES:
NVAL 0
SVAL alive
VAL 0
0.UPDATE_PENDING:
VALUES:
NVAL 0
SVAL false
VAL 0
1.DIRECTION:
VALUES:
NVAL 0
ONVAL 2
OSVAL down
OVAL 2
SVAL none
VAL 0
1.ERROR_OVERHEAT:
VALUES:
NVAL 0
SVAL false
VAL 0
1.ERROR_REDUCED:
VALUES:
NVAL 0
SVAL false
VAL 0
1.INHIBIT:
VALUES:
NVAL 0
SVAL false
VAL 0
1.LEVEL:
VALUES:
NVAL 95
ONVAL 95.5
OSVAL 96
OVAL 0.955000
SVAL 95
VAL 0.950000
1.LEVEL_REAL:
VALUES:
NVAL 10
ONVAL 34
OSVAL 34
OVAL 0.340000
SVAL 10
VAL 0.100000
1.WORKING:
VALUES:
NVAL 0
ONVAL 1
OSVAL yes
OVAL 1
SVAL no
VAL 0
2.DIRECTION:
VALUES:
NVAL 0
ONVAL 1
OSVAL UP
OVAL 1
SVAL NONE
VAL 0
2.ERROR_OVERHEAT:
VALUES:
NVAL 0
SVAL false
VAL 0
2.ERROR_REDUCED:
VALUES:
NVAL 0
SVAL false
VAL 0
2.INHIBIT:
VALUES:
NVAL 0
SVAL false
VAL 0
2.LEVEL:
VALUES:
NVAL 88
ONVAL 20.5
OSVAL 20
OVAL 0.205000
SVAL 88
VAL 0.880000
2.LEVEL_REAL:
VALUES:
NVAL 10
ONVAL 34
OSVAL 34
OVAL 0.340000
SVAL 10
VAL 0.100000
2.WORKING:
VALUES:
NVAL 0
ONVAL 1
OSVAL true
OVAL 1
SVAL false
VAL 0
3.DIRECTION:
VALUES:
NVAL 0
ONVAL 1
OSVAL UP
OVAL 1
SVAL NONE
VAL 0
3.ERROR_OVERHEAT:
VALUES:
NVAL 0
SVAL false
VAL 0
3.ERROR_REDUCED:
VALUES:
NVAL 0
SVAL false
VAL 0
3.INHIBIT:
VALUES:
NVAL 0
SVAL false
VAL 0
3.LEVEL:
VALUES:
NVAL 90
ONVAL 67.5
OSVAL 67
OVAL 0.675000
SVAL 90
VAL 0.900000
3.LEVEL_REAL:
VALUES:
NVAL 10
ONVAL 34
OSVAL 34
OVAL 0.340000
SVAL 10
VAL 0.100000
3.WORKING:
VALUES:
NVAL 0
ONVAL 1
OSVAL true
OVAL 1
SVAL false
VAL 0
roleChannels:
DIMMER 1
MAINTENANCE 0
VIRTUAL_DIMMER 2,3
roleCmds:
get:
set:
down:
channel 1
ps VALUES
role DIMMER
rpc 0
subcount 1
syntax V:LEVEL:?delta=-10
usage down [delta]
subcmd:
000:
args -10
dpt LEVEL
fnc
max 1.000000
min 0.000000
parname delta
partype 2
ps VALUES
scn 000
type FLOAT
unit 100%
level:
channel 1
ps VALUES
role DIMMER
rpc 0
subcount 1
syntax V:LEVEL:?level
usage level level
subcmd:
000:
args
dpt LEVEL
fnc
max 1.000000
min 0.000000
parname level
partype 2
ps VALUES
scn 000
type FLOAT
unit 100%
off:
channel 1
ps VALUES
role DIMMER
rpc 0
subcount 1
syntax V:LEVEL:0
usage off
subcmd:
000:
args 0
dpt LEVEL
fnc
max 1.000000
min 0.000000
parname LEVEL
partype 3
ps VALUES
scn 000
type FLOAT
unit 100%
on:
channel 1
ps VALUES
role DIMMER
rpc 0
subcount 1
syntax V:LEVEL:100
usage on
subcmd:
000:
args 100
dpt LEVEL
fnc
max 1.000000
min 0.000000
parname LEVEL
partype 3
ps VALUES
scn 000
type FLOAT
unit 100%
on-for-timer:
channel 1
ps VALUES
role DIMMER
rpc 0
subcount 2
syntax V:ON_TIME:?duration V:LEVEL:100
usage on-for-timer duration
subcmd:
000:
args
dpt ON_TIME
fnc
max 85825945.600000
min 0.000000
parname duration
partype 2
ps VALUES
scn 000
type FLOAT
unit s
001:
args 100
dpt LEVEL
fnc
max 1.000000
min 0.000000
parname LEVEL
partype 3
ps VALUES
scn 001
type FLOAT
unit 100%
on-till:
channel 1
ps VALUES
role DIMMER
rpc 0
subcount 2
syntax V:ON_TIME:?time V:LEVEL:100
usage on-till time
subcmd:
000:
args
dpt ON_TIME
fnc
max 85825945.600000
min 0.000000
parname time
partype 2
ps VALUES
scn 000
type FLOAT
unit s
001:
args 100
dpt LEVEL
fnc
max 1.000000
min 0.000000
parname LEVEL
partype 3
ps VALUES
scn 001
type FLOAT
unit 100%
pct:
channel 1
ps VALUES
role DIMMER
rpc 0
subcount 3
syntax 3:V:LEVEL:?level 1:V:ON_TIME:?time=0.0 2:V:RAMP_TIME:?ramp=0.5
usage pct level [time] [ramp]
subcmd:
000:
args
dpt LEVEL
fnc
max 1.000000
min 0.000000
parname level
partype 2
ps VALUES
scn 003
type FLOAT
unit 100%
001:
args 0.0
dpt ON_TIME
fnc
max 85825945.600000
min 0.000000
parname time
partype 2
ps VALUES
scn 001
type FLOAT
unit s
002:
args 0.5
dpt RAMP_TIME
fnc
max 85825945.600000
min 0.000000
parname ramp
partype 2
ps VALUES
scn 002
type FLOAT
unit s
stop:
channel 1
ps VALUES
role DIMMER
rpc 0
subcount 1
syntax V:RAMP_STOP:1
usage stop
subcmd:
000:
args 1
dpt RAMP_STOP
fnc
max 1
min 0
parname RAMP_STOP
partype 3
ps VALUES
scn 000
type ACTION
unit
toggle:
channel 1
ps VALUES
role DIMMER
rpc 0
subcount 1
syntax V:LEVEL:0,100
usage toggle
subcmd:
000:
args 0,100
dpt LEVEL
fnc
max 1.000000
min 0.000000
parname LEVEL
partype 3
ps VALUES
scn 000
type FLOAT
unit 100%
up:
channel 1
ps VALUES
role DIMMER
rpc 0
subcount 1
syntax V:LEVEL:?delta=+10
usage up [delta]
subcmd:
000:
args +10
dpt LEVEL
fnc
max 1.000000
min 0.000000
parname delta
partype 2
ps VALUES
scn 000
type FLOAT
unit 100%
state:
chn 1
dpt LEVEL
Attributes:
cmdIcon on:general_an off:general_aus
substexcl pct|level
webCmd level:on:off
widgetOverride level:slider,0,10,100