Neues Modul HMCCU für Homematic CCU

[zap]

FHEM Standards werden noch immer ignoriert (keine Readings mit dem Namen pct, level, desired-temp und so weiter...), man braucht für alles Sonderfälle und userReadings, um es richtig hinzubiegen.

Es gibt keine FHEM Standards. Vielleicht CUL_HM "Standards". Um diese in HMCCU umzusetzen, müsste ich den generischen Ansatz komplett über Bord werfen und wie in CUL_HM in einer schier endlosen IF-THEN Orgie alle Gerätetypen als Einzelfälle betrachten. Das wird nicht passieren. Dann musst Du eben CUL_HM benutzen. Mit dem Attribut ccureadingname gibt es die Möglichkeit, einzelne Readings umzubenennen (z.B. 1.LEVEL:pct,0.LOWBAT:battery).

Das braucht Ewigkeiten und ist umständlich.

Was bitte schön ist einfach bei FHEM. FHEM ist mächtig und flexibel, aber sicher nicht "einfach" bzw. benutzerfreundlich.

Templates für die einfachsten Geräte sind noch immer nicht enthalten, obwohl ich diese schon einmal Copy&Paste fähig bereitgestellt hatte.

Deine sehr komplexen und umfangreichen Attribut-Templates konnte ich nicht 1:1 übernehmen, da sie sicher nicht den Geschmack jedes Nutzers getroffen hätten. Einige Attribute habe ich jedoch übernommen. Seit einiger Zeit gibt es die Möglichkeit, eigene Attribut-Templates in einer Config-Datei anzugeben. Darüber könntest Du Deine eigenen Templates relativ einfach definieren.

Offenbar noch mehr teils eher nutzlose Attribute, deren Namen nichts sagend oder inkonsistent sind. Flexibilität hin oder her, ist ja alles schön und gut. Aber soll man das auch benutzen können?

Im Vergleich zu anderen Modulen liegt HMCCU was die Anzahl der Attribute angeht eher im unteren Mittelfeld. Da gibt es viel "schlimmere".

[Loredo]

Es gibt keine FHEM Standards. Vielleicht CUL_HM "Standards".

Das kannst du so lange wiederholen, wie du möchtest, aber: Es gibt sie.
CUL_HM mag diese einmal initial forciert haben, dennoch setzen eine ganze Menge an Modulen und Funktionen darauf, dass bestimmte Readings die Namen "pct" oder "level" tragen. Da wären beispielsweise außerdem homebridge-fhem, HUEBridge/HUEDevice, Alarm, PHTV, HP1000, Wunderground. Viele Frontends setzen darauf, dass die Readings so heißen. Aktuell muss man peinlich genau darauf achten, welchen Gerätetyp man gerade vor sich hat um das richtige Reading zu verwenden. Bei dem einen heißt es so, bei dem anderen wieder anders... Für die Verwendung in einer structure muss man erstmal umständlich Mappings definieren, damit man HMCCU Geräte mit anderen Geräten wie z.B. CUL_HM und HUE mixen kann. Martin und André haben hier beide eine große Nutzerschaft bei den Modulen und setzen somit einfach einen Standard - Punkt.

Um diese in HMCCU umzusetzen, müsste ich den generischen Ansatz komplett über Bord werfen

Das ist schlichtweg nicht wahr und das habe ich auch nicht gefordert. Es lässt sich prima beides miteinander vereinen. Es geht mir darum, dass mir das Modul dabei hilft bessere Qualität in weniger Zeit bei der Definition der HMCCU Devices zu erhalten. Die Möglichkeiten sind ja wie gesagt da, aber man muss sich für jedes neue Gerät wieder und wieder durch einen Berg von Attributen und deren komplexen Möglichkeiten wühlen. Es ist toll, dass man das machen kann - wer das braucht soll es auch tun können.
Ich habe schon erklärt, dass man die LEVEL Werte in HMCCU IMHO _immer_ als pct und level interpretieren kann. Du hast nun zwar halbherzig/halbfertig Setter dafür eingebaut, das ist aber eben nur die halbe Miete und für sich allein genommen nutzlos bzw. erspart es nicht wieder und wieder für jedes einzelne HMCCU Gerät die gleichen userReadings anlegen zu müssen.

Mit dem Attribut ccureadingname gibt es die Möglichkeit, einzelne Readings umzubenennen (z.B. 1.LEVEL:pct,0.LOWBAT:battery)

Prima. Warum wird das Attribut nicht bei den Defaults direkt so für alle in Frage kommenden Readings gesetzt, dass diese FHEM Standard Readings entsprechend so benannt werden? Ich finde es auch nicht verwerflich die Readings doppelt zu führen, man kann die Events ja entsprechend einschränken. Es braucht nicht ein "entweder/oder", sondern ein "sowohl als auch".

Was bitte schön ist einfach bei FHEM. FHEM ist mächtig und flexibel, aber sicher nicht "einfach" bzw. benutzerfreundlich.

Das ist jedoch kein Grund, dass jedes Modul sein eigenes Ökosystem baut und sich nicht rechts und links umschaut, um sich möglichst einfach in FHEM einzufügen.
Ich will sicherlich HMCCU vollumfänglich beeinflussen _können_, wenn ich weiß warum ich das will. Dazu gehört aber nicht, dass ich das Modul erstmal so richtig hinbiegen _muss_, dass es sich an de facto Standards hält. Zumal ich das für jedes einzelne Device machen muss und bei Änderungen darf ich dann wieder duzende Geräte von Hand anfassen. Das ist langwierig und fehlerträchtig. Ein Computer ist dafür da mir solche Arbeit abzunehmen und Fehler zu ersparen.


IMHO ist FHEM dafür da unterschiedliche Hersteller und Technologien zusammenzuführen und schließlich gemeinsam in ähnlicher Art und Weise zu handhaben. Dazu gehört selbstverständlich, dass man versucht die gleichen Werte von unterschiedlichen Geräten verschiedener Hersteller vergleichbar zu machen. Eine Mapping Tabelle zu führen ala "bei dem Modul heißt der Wert so, bei dem anderen wieder so", wobei beide Werte eigentlich das selbe aussagen, ist nunmal aufwändig und macht alles nur noch komplexer. Im Grunde läuft es hier auch auf die Unit/RType Diskussion heraus. Ein gutes Beispiel ist aber ebenfalls, dass sich AV Module auf einen gewissen gemeinsamen Reading-Standard geeinigt haben und ich kann darin nur Vorteile erkennen.
Wir haben sehr viele Module, die sich NICHT an Standards halten, das finde ich schlimm genug. Nun kann man bei HMCCU aber nicht von einem Modul sprechen, welches lediglich eine kleine Gruppe adressiert (oder adressieren möchte). Im Gegenteil, es hat sicherlich das Potential genauso viele Nutzer anzusprechen wie CUL_HM es tut. Es hat aber den großen Nachteil, dass die Integration in FHEM viel aufwändiger ist, da es mit anderen Modulen nicht gut zusammenarbeitet und es sehr schwer und unübersichtlich wird, wenn man mit HMCCU Automationen in FHEM definieren möchte. Da ich davon ausgehe, dass dies der Hauptgrund ist, weshalb Menschen FHEM verwenden, sollte HMCCU darauf entsprechend eingehen.


Außerdem muss man sich auch die Frage stellen: Wer verwendet eine CCU2 statt einen CUL Stick o.ä.? Sicherlich doch auch eher die Nutzerschaft, die es sich leicht und einfach machen will, indem sie auf das setzen, was der Hersteller eq3 sich gedacht hat. Du betitelst HMCCU mit "best of both worlds". Das kann ich aber eben nicht erkennen und so nicht unterschreiben, denn jemand, der auf HMCCU mit einer CCU2 setzt, hat es deutlich schwieriger aus FHEM das beste rauszuholen als jemand, der CUL_HM verwendet (und dadurch dann andererseits die Sicherheit des Herstellerstandards aufgeben muss). Dein Versuch mit HMCCU beide Welten ideal zu verbinden verfehlst du deshalb meiner Ansicht nach momentan aufgrund der hohen Komplexität bei Wartbarkeit, Verlässlichkeit und der extrem hohen Einstiegshürde.
Hinzu kommt dann noch, dass sich Dinge auf unterschiedliche Arten lösen kann und ich nie so richtig weiß, ob ich mich jetzt darauf verlassen kann die bestmögliche Definition zu verwenden (Performance, Wartbarkeit, Zukunftssicherheit etc).

Deine sehr komplexen und umfangreichen Attribut-Templates konnte ich nicht 1:1 übernehmen, da sie sicher nicht den Geschmack jedes Nutzers getroffen hätten.

Die Komplexität rührt daher, dass HMCCU eben "zu" flexibel ist und eine extreme Menge an Attributen erfordert. Du hast selbst erklärt, weshalb du das so haben möchtest. Die Folge daraus sind selbstverständlich viele und auch sehr komplexe Attribute. Was hast du erwartet?
Die Attribute stellen den Versuch dar dein Modul einigermaßen in das FHEM Ökosystem und seine anderen Module zu integrieren. Ich möchte stark davon ausgehen, dass die überwiegende Mehrzahl der FHEM Benutzer dieses Interesse verfolgt. Ebenfalls bleibt die Freiheit erhalten Attribute danach abzuändern oder zu löschen. Wir sprechen hier ja auch nicht nur über die reinen FHEMWEB relevanten Attribute zur reinen Anzeige, die vielleicht einige anders haben wollen würden. Du hattest ja beschrieben du würdest solche Attribute ggf. als optional mit aufnehmen. Das hätte ich einen guten Kompromiss gefunden, auch wenn ich noch immer finde, dass es niemandem weh tut, wenn man initial und einmalig einige Attribute so setzt, dass man ein Gerät direkt und sinnvoll aus FHEMWEB heraus steuern kann. Es wird ja niemandem vorgeschrieben diese Einstellungen so zu belassen - es ist ein Template und per Definition ist eine solche Vorlage eben nach ihrer Anwendung beliebig änderbar und stellt nur einen gewissen Standard als Ausgangsbasis dar.

Im Vergleich zu anderen Modulen liegt HMCCU was die Anzahl der Attribute angeht eher im unteren Mittelfeld. Da gibt es viel "schlimmere".

Es ist weniger die reine Anzahl, sondern eher die Mischung aus deren Syntax, Bezeichnung und Kombination untereinander. Andere bezeichnen das als "sehr mächtig". Ich verwende diese Worte aber eben nur, wenn ich nicht dazu gezwungen werde mich dieser "Macht" ständig und wiederholt in einem Umfang zu stellen, der Pflege/Wartung und Setup neuer Systeme signifikant verkompliziert. Vor allem, wenn das eigentlich gar nicht so sein müsste und man niemandem etwas wegnähme, wenn diese Flexibilität optional und für einen sinnvollen Einsatz eben nicht zwingend erforderlich wäre.

[wagenkna]

Also Deine CCU hat die IP-Adresse 192.168.1.92, korrekt? Wenn Du vom FHEM Server aus ein ping auf diese Adresse absetzt, funktioniert das? Das müsste so ähnlich aussehen:

Code Auswählen Erweitern


macbook:~ zap$ ping 192.168.1.11
PING 192.168.1.11 (192.168.1.11): 56 data bytes
64 bytes from 192.168.1.11: icmp_seq=0 ttl=64 time=4.049 ms
64 bytes from 192.168.1.11: icmp_seq=1 ttl=64 time=2.454 ms
64 bytes from 192.168.1.11: icmp_seq=2 ttl=64 time=3.779 ms


Jetzt geht es ans eingemachte. Falls Du mit den folgenden Schritten nichts anfangen kannst, starte einfach mal die CCU neu und versuche nochmal, den RPC-Server zu starten.

1. Per SSH auf der CCU anmelden
2. Befehl eingeben: fuser 2001/tcp
3. Befehl in 2. sollte eine Zahl ausgeben, wenn nicht => CCU neu starten
4. Befehl eingeben: ps -ef | grep Zahl_aus_Punkt2
5. Befehl in 4. sollte eine Zeile ausgeben, die "rfd" enthält.

Beispiel (bei mir):

Code Auswählen Erweitern


# fuser 2001/tcp
355
# ps -ef | grep 355
  355 root     /bin/rfd -f /etc/config/rfd.conf -l 5
2879 root     grep 355
#


Die Fehlermeldung "Can't connect to ..." deutet darauf hin, dass der rfd Prozess auf der CCU nicht mehr läuft.

Hallo Zap,
unglücklicherweise habe ich seit gestern das gleiche Problem, leider als ich mit der HMCCU "rum" spielte. Hab den Raspberry jetzt zum dritten mal neu aufgesetzt....

Habe die CCU2  neu gestartet, leider kann der RPC Server nicht gestartet werden
Im Logfile kommt folgende Fehlermeldung
2016.12.27 20:09:07 1: HMCCU: Can't connect to CCU port2000
2016.12.27 20:09:07 1: HMCCU: CCU2 Start of RPC server failed
2016.12.27 20:24:46 1: HMCCU: Can't connect to CCU port2000
2016.12.27 20:24:46 1: HMCCU: CCU2 Start of RPC server failed
2016.12.27 20:25:36 1: HMCCU: Can't connect to CCU port2000
2016.12.27 20:25:36 1: HMCCU: CCU2 Start of RPC server failed
2016.12.27 20:46:45 1: HMCCU: Can't connect to CCU port2000
2016.12.27 20:46:45 1: HMCCU: CCU2 Start of RPC server failed

Bei der CCU2 wird keine Zahl angezeigt beim Kommando fuser 2000/TCP

Kannst du weiter helfen?

Bevor der Server abschmierte klappte die Kopplung zwischen FHEM auf Raspberry2 bzw. jetzt 3 und der CCU2

Besten Dank
weihnachtliche Grüße

[zap]

Ich vermute, du hast das Attribut rpcport auf 2000 gesetzt. Benutzt Du Bidcos-RF (Funk) oder Homematic wired? Die richtigen Werte für rpcport sind (mehrere möglich):

2000 = wired
2001 = bidcos-rf (Funk)
2010 = homematic ip
9292 = virtuelle Gruppengeräte

[Wernieman]

Mal eine Grundsatzfrage:
Die ccu2 kann und sollte in der Weboberfläche per User/Passwort geschützt werden. Verstehe ich es richtig, das dieses per Netzt, z.B: mit diesem Modul, nicht nötig ist?

[Loredo]

Mal eine Grundsatzfrage:
Die ccu2 kann und sollte in der Weboberfläche per User/Passwort geschützt werden. Verstehe ich es richtig, das dieses per Netzt, z.B: mit diesem Modul, nicht nötig ist?

Doch, du solltest weiterhin User/Passwort in der CCU setzen. Allerdings ist die RPC Schnittstelle, die HMCCU verwendet, nicht darüber geschützt, weshalb du bei der Konfiguration von HMCCU auch keine Logindaten eingeben musst, sondern nur die IP Adresse.
Der Zugriff auf die RPC Schnittstelle lässt sich aber immerhin auf bestimmte IP Adressen beschränken. Da macht es Sinn nur die IP des Servers anzugeben, auf dem FHEM läuft.

[zap]

Die Festlegung einer zulässigen IP Adresse für die RPC Schnittstelle hilft aber nur dafür. Die Homematic Script Schnittstelle (tclrega) bleibt trotzdem offen. Die lässt sich m.W. auch nicht blockieren.

Deshalb sollte man eine CCU auch niemals per Port Forwarding aus dem Internet erreichbar machen sondern besser einen VPN Zugang verwenden.

Ich hatte schonmal darüber nachgedacht, auf die JSON Schnittstelle der CCU2 umzusteigen. Leider funktioniert da die Eventbenachrichtigung nicht. Bei der JSON Schnittstelle kommt ein Authorisierungstoken mit UserID und Passwort zum Einsatz.

Update: Ich sehe gerade bei Loredos Screenshot doch den Punkt Homematic Script. Also möglicherweise lässt sich das doch auf einzelne IPs beschränken. Muss ich mal testen.

[Wernieman]

Danke für die Info!

[zentis666]

Hallo!
Könnte mir bitte jemand mit der Definition meiner Keymatic helfen?
Ich hab leider noch nichts fertiges finden können.
Das Gerät sieht folgendermaßen aus

Code Auswählen Erweitern


DEF MEQxxxxxxx
IODev hm_ccu
NAME HM_Sec_Key_S
NR 689
STATE true
TYPE HMCCUDEV
ccuaddr MEQxxxxxxx
ccudevstate Active
ccuif BidCos-RF
ccuname HM-Sec-Key-S
ccutype HM-Sec-Key-S
channels 2
statevals devstate
Readings HM-Sec-Key-S.0.AES_KEY 1
HM-Sec-Key-S.0.CONFIG_PENDING false
HM-Sec-Key-S.0.DUTYCYCLE false
HM-Sec-Key-S.0.LOWBAT false
HM-Sec-Key-S.0.RSSI_DEVICE 186
HM-Sec-Key-S.0.RSSI_PEER 196
HM-Sec-Key-S.0.STICKY_UNREACH false
HM-Sec-Key-S.0.UNREACH false
HM-Sec-Key-S.1.DIRECTION 0
HM-Sec-Key-S.1.ERROR 0
HM-Sec-Key-S.1.INHIBIT false
HM-Sec-Key-S.1.STATE 0
HM-Sec-Key-S.1.STATE_UNCERTAIN 0
state 0

Attributes
IODev hm_ccu
event-on-change-reading .*
room Homematic


Wenn ich abschliesse ist

Code Auswählen Erweitern

HM-Sec-Key-S.1.STATE 0
und
state 0

aufgeschlossen ist

Code Auswählen Erweitern

HM-Sec-Key-S.1.STATE 1
und
state 1

Danke schonmal und Gruß
Sven

[zap]

Bei der Keymatic würde ich es mal mit folgenden Attributen versuchen:

Code Auswählen Erweitern


ccureadingformat datapoint
statedatapoint 1.STATE
statevals lock:false,unlock:true
substitute STATE!(0|false):locked,(1|true):unlocked,2:open;LOWBAT,UNREACH!(0|false):no,(1|true):yes;STATE_UNCERTAIN!(1|true):manual;DIRECTION!0:none,1:up,2:down,3:undefined;ERROR!0:no,1:clutch_failure,2:motor_aborted
event-on-change-reading .*
eventMap /datapoint 1.OPEN true:open/


Abgeleitet aus der Doku (ich habe keine Keymatic):
http://www.eq-3.de/Downloads/eq3/download%20bereich/hm_web_ui_doku/hm_devices_Endkunden.pdf

Das sollte Dir folgende neue Set Befehle bereitstellen: lock, unlock, open

Wenn das so funktioniert, teile das bitte mit. Dann übernehme ich die Einstellungen in die Default Templates.

[zentis666]

Hallo zap,

vielen Dank für Deine Hilfe, funktioniert wie beschrieben!
Kannst Du so ins default template übernehmen.

Gruß
Sven

[zentis666]

Hallo zap,

eine Funktionalität der KeyMatic fehlt mir noch:
man kann das Schloss "sperren" im Falle einer Sabotage zum Beispiel.
Ich hab einen Fingerabdruck Sensor dran der das auslöst falls jemand das Gehäuse öffnet.

get deviceinfo gibt zurück

Code Auswählen Erweitern

CHN MEQXXXXXXX:0 HM-Sec-Key-S:0
  DPT {b} BidCos-RF.MEQXXXXXXX:0.UNREACH = false [RE]
  DPT {b} BidCos-RF.MEQXXXXXXX:0.STICKY_UNREACH = false [RWE]
  DPT {b} BidCos-RF.MEQXXXXXXX:0.CONFIG_PENDING = false [RE]
  DPT {b} BidCos-RF.MEQXXXXXXX:0.LOWBAT = false [RE]
  DPT {b} BidCos-RF.MEQXXXXXXX:0.DUTYCYCLE = false [RE]
  DPT {n} BidCos-RF.MEQXXXXXXX:0.RSSI_DEVICE = 186 [RE]
  DPT {n} BidCos-RF.MEQXXXXXXX:0.RSSI_PEER = 196 [RE]
  DPT {n} BidCos-RF.MEQXXXXXXX:0.AES_KEY = 1 [R]
CHN MEQXXXXXXX:1 HM-Sec-Key-S:1
  DPT {b} BidCos-RF.MEQXXXXXXX:1.STATE = true [RWE]
  DPT {b} BidCos-RF.MEQXXXXXXX:1.OPEN =  [W]
  DPT {f} BidCos-RF.MEQXXXXXXX:1.RELOCK_DELAY =  [W]
  DPT {b} BidCos-RF.MEQXXXXXXX:1.STATE_UNCERTAIN = false [RE]
  DPT {b} BidCos-RF.MEQXXXXXXX:1.INHIBIT = false [RWE]
  DPT {i} BidCos-RF.MEQXXXXXXX:1.ERROR = 0 [RE]
  DPT {i} BidCos-RF.MEQXXXXXXX:1.DIRECTION = 0 [RE]
  DPT {b} BidCos-RF.MEQXXXXXXX:1.INSTALL_TEST =  [W]

Müsste sein:
DPT {b} BidCos-RF.MEQXXXXXXX:1.INHIBIT = false
das hätte ich gerne in ein eigenes reading was ich ein und ausschalten kann.
Geht das mit HMCCU?

Gruß
Sven

[Loredo]

Ich habe jetzt einmal mit ccureadingname und substitute versucht die Readings so zu verbiegen, dass ich keine userReadings mehr benötigte.
Ich komme jedoch weder bei HMCCUCHN noch bei HMCCUDEV soweit, dass die Kanalnummer nicht mehr als Präfix mit enthalten ist. Daher erscheinen mir diese Attribute derzeit wenig nutzbar für die Angleichung an FHEM Standard-Readingnamen.


Bei HMCCUDEV wurde glaube ich gesagt, dass man nicht auf den Kanal-Präfix verzichten könne, weil Überlappungen bei den Readingnamen nicht auszuschließen wären. Nach Studium der eq-3 Doku zu den Datenpunkten würde ich aber sagen, dass es keine zu erwartenden Überlappungen gibt. Vielleicht habe ich aber auch etwas übersehen.


Ich erinnere mich, dass für HMCCUCHN einmal im Raum stand den Kanal 0 zusätzlich mit aufzuführen, um dort Zugriff auf Dinge wie LOWBAT, UNREACH etc zu bekommen. Diese Funktion konnte ich nicht finden, sofern sie schon eingebaut ist. Wäre sie da, dann würde ich vermutlich ausschließlich nur noch HMCCUCHN Geräte definieren und HMCCUDEV wäre komplett obsolete, sofern die Kanalpräfixe dort zwingend erhalten blieben. Ich verstehe wohl noch immer nicht, warum man den Unterschied zwischen HMCCUCHN und HMCCUDEV (noch) machen muss.

[zap]

Grundsätzlich kannst Du mit dem Befehl set datapoint jeden Datenpunkt ansprechen, der bei deviceinfo das "W" gesetzt hat.

Also z.B.

Code Auswählen Erweitern


set HM_Sec_Key_S datapoint 1.INHIBIT true


Das lässt sich natürlich auch mittels eventMap als Befehl abbilden:

Code Auswählen Erweitern


eventMap eventMap /datapoint 1.OPEN true:open/datapoint 1.INHIBIT true:inhibiton/datapoint 1.INHIBIT false:inhibitoff/


Nur als Hinweis: Manche Homematic Geräte werden auch über die Geräteeinstellungen bzw. Config-Parameter gesperrt. Die erreicht man im CCU WebUI über Einstellungen -> Geräte und dann beim jeweiligen Gerät den Button "Einstellen". Diese Art Parameter werden nicht über Datenpunkte abgebildet. Man erreicht sie nur mit dem Befehl set config.

[zap]

Ich habe jetzt einmal mit ccureadingname und substitute versucht die Readings so zu verbiegen, dass ich keine userReadings mehr benötigte.
Ich komme jedoch weder bei HMCCUCHN noch bei HMCCUDEV soweit, dass die Kanalnummer nicht mehr als Präfix mit enthalten ist. Daher erscheinen mir diese Attribute derzeit wenig nutzbar für die Angleichung an FHEM Standard-Readingnamen.

m.E. sollte das ohne Kanalnummer funktionieren. Du musst berücksichtigen, dass der zu ersetzende Readingname ein regulärer Ausdruck ist und lediglich der Teil des Readingnames ersetzt wird, der dem regulären Ausdruck entspricht. Beispiel

Readingname = 0.LOWBAT
Ersetzungsregel = LOWBAT:battery
Ergebnis: 0.battery

ABER:

Readingname = 0.LOWBAT
Ersetzungsregel = ^.*LOWBAT$:battery
Ergebnis: battery

Ok, die Doku ist an dieser Stelle ausbaufähig

Bei HMCCUDEV wurde glaube ich gesagt, dass man nicht auf den Kanal-Präfix verzichten könne, weil Überlappungen bei den Readingnamen nicht auszuschließen wären. Nach Studium der eq-3 Doku zu den Datenpunkten würde ich aber sagen, dass es keine zu erwartenden Überlappungen gibt. Vielleicht habe ich aber auch etwas übersehen.

Ja, die Mehrfach-Schalter hast Du z.B. übersehen. Da hat jeder Kanal seinen eigenen STATE Datenpunkt. In der Doku steht da immer Kanal 1-n.

Ich erinnere mich, dass für HMCCUCHN einmal im Raum stand den Kanal 0 zusätzlich mit aufzuführen, um dort Zugriff auf Dinge wie LOWBAT, UNREACH etc zu bekommen. Diese Funktion konnte ich nicht finden, sofern sie schon eingebaut ist. Wäre sie da, dann würde ich vermutlich ausschließlich nur noch HMCCUCHN Geräte definieren und HMCCUDEV wäre komplett obsolete, sofern die Kanalpräfixe dort zwingend erhalten blieben. Ich verstehe wohl noch immer nicht, warum man den Unterschied zwischen HMCCUCHN und HMCCUDEV (noch) machen muss.

Das ist eingebaut, es sei denn, Du setzt für ein HMCCUCHN Device das Attribut ccuflags auf nochn0.