Fazit HMCCU -> Dimmer

Begonnen von rabehd, 08 Februar 2025, 13:46:50

Vorheriges Thema - Nächstes Thema

rabehd

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
Da ich keine Anleitung zur Korrektur der HMCCUConfig.pm gefunden habe und auf 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.
Auch funktionierende Lösungen kann man hinterfragen.

zap

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.
2xCCU3 mit ca. 100 Aktoren, Sensoren
Entwicklung: FHEM auf Proxmox Debian VM
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: HMCCU, (Fully, AndroidDB)

rabehd

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.
Auch funktionierende Lösungen kann man hinterfragen.

frank

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.
was hindert dich, den dimmer weiterhin über cul_hm zu nutzen, wenn du es aktuell nicht über hmccu schaffst?
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

betateilchen

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.

-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

betateilchen

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.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

rabehd

#6
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 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.

 
Auch funktionierende Lösungen kann man hinterfragen.

zap

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.
2xCCU3 mit ca. 100 Aktoren, Sensoren
Entwicklung: FHEM auf Proxmox Debian VM
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: HMCCU, (Fully, AndroidDB)

rabehd

#8
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/
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?
Auch funktionierende Lösungen kann man hinterfragen.

zap

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.
2xCCU3 mit ca. 100 Aktoren, Sensoren
Entwicklung: FHEM auf Proxmox Debian VM
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: HMCCU, (Fully, AndroidDB)

rabehd

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
Auch funktionierende Lösungen kann man hinterfragen.

rabehd

Weiß jemand wie man ein Gerät aus der CCU erzeugt, welches in der HMCCUConf.pm nicht vorhanden, bzw. dort fehlerhaft ist?
Auch funktionierende Lösungen kann man hinterfragen.

Ralli

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.
Gruß,
Ralli

Proxmox 8.4 Cluster mit HP ED800G2i7, Intel NUC11TNHi7+NUC7i5BNH, virtualisiertes fhem 6.4 dev, virtualisierte RaspberryMatic (3.81.5.20250326) mit HB-RF-ETH 1.3.0 / RPI-RF-MOD, HM-LAN-GW (1.1.5) und HMW-GW, FRITZBOX 7490 (07.59), FBDECT, Siri und Alexa

rabehd

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?
Auch funktionierende Lösungen kann man hinterfragen.

Ralli

#14
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
Gruß,
Ralli

Proxmox 8.4 Cluster mit HP ED800G2i7, Intel NUC11TNHi7+NUC7i5BNH, virtualisiertes fhem 6.4 dev, virtualisierte RaspberryMatic (3.81.5.20250326) mit HB-RF-ETH 1.3.0 / RPI-RF-MOD, HM-LAN-GW (1.1.5) und HMW-GW, FRITZBOX 7490 (07.59), FBDECT, Siri und Alexa