Neues Modul HMCCU für Homematic CCU

[autLaW]

Hallo zap,

danke das du dich gemeldet hast und auch herzlichen dank an dich für deinen persönlichen Aufwand den du mit diesem Modul betreibst!

So, zur Vollständigkeit:
-> "Parser.pm im gleichen Verzeichnis wie die Procedure.pm" ... ja, bei mir beide unter "C:\HomeServer\fhem-5.7\perl\site\lib\RPC\XML"

-> "aktuellen Versionen der Perl Module RPC::XML::Server und RPC::XML::Client sind installiert?" ... ja, folgenden Output habe ich bei der HMCCU Installation mitgeschrieben:

Code Auswählen Erweitern


perl\site\bin\cpanm RPC::XML::Client    -> Successfully installed RPC-XML-0.80
perl\site\bin\cpanm RPC::XML::Server       -> RPC::XML::Server is up to date. (1.73)


Update zu meinem Problem:
Inzwischen bin ich schon einen Schritt weiter. Mir ist eingefallen das ich bei der Installation von FHEM und HMCCU in der Konsole (CMD) zuerst den Pfad ergänzt habe (so wie es in der FHEM Win Installation beschrieben ist):

Code Auswählen Erweitern


PATH=C:\HomeServer\fhem-5.7\c\bin;C:\HomeServer\fhem-5.7\perl\bin;%PATH%


Also habe ich testweise FHEM in einer Konsole gestartet. Zuerst ohne die Pfad Modifikation (-> selber Fehler) und dann mit der Pfad Modifikation und plötzlich läßt sich der RPC Server starten 
Naja, das hätte mir eigentlich nicht passieren dürfen. 

Hier der dazu passende Log-Auszug:

Code Auswählen Erweitern


2016.11.29 08:36:01 2: HMCCU: Create child process with timeouts 0.01 and 0.25
2016.11.29 08:36:02 0: HMCCU: Child process for server CB2001 started with PID -1620
2016.11.29 08:36:02 0: RPC server(s) starting
2016.11.29 08:36:02 0: CCURPC: CB2001 Creating file queue /tmp/ccuqueue_2001
2016.11.29 08:36:02 0: CCURPC: Initializing RPC server CB2001
2016.11.29 08:36:04 0: CCURPC: Callback server created listening on port 7401
2016.11.29 08:36:04 1: CCURPC: CB2001 Adding callback for events
2016.11.29 08:36:04 1: CCURPC: CB2001 Adding callback for new devices
2016.11.29 08:36:04 1: CCURPC: CB2001 Adding callback for deleted devices
2016.11.29 08:36:04 1: CCURPC: CB2001 Adding callback for modified devices
2016.11.29 08:36:04 1: CCURPC: CB2001 Adding callback for replaced devices
2016.11.29 08:36:04 1: CCURPC: CB2001 Adding callback for readded devices
2016.11.29 08:36:04 1: CCURPC: CB2001 Adding callback for list devices
2016.11.29 08:36:04 0: CCURPC: CB2001 Entering server loop
2016.11.29 08:36:09 0: HMCCU: Received SL event. RPC server CB2001 enters server loop
2016.11.29 08:36:16 1: HMCCU: Registering callback http://192.168.1.13:7401/fh2001 with ID CB2001 at http://my.Remote.Location.xyz:2001/


D.h. der RPC Server funktioniert grundsätzlich auch unter Windows.

Nun aber zum nächsten Problem:
Wie man oben sehen kann wird der RPC Callback mit der lokalen IP Adresse (192.168...) bei der entfernten CCU registriert (DNS Name). Da mein FHEM und die CCU in unterschiedlichen Netzwerken sind und ich die Verbindung über das Internet aufbaue passiert natürlich folgendes:

Code Auswählen Erweitern


2016.11.29 08:38:23 1: HMCCU: RPC callback with URL http://192.168.1.13:7401/fh2001 initialized
2016.11.29 08:38:28 0: HMCCU: Periodical check found no RPC Servers
2016.11.29 08:38:28 1: HMCCU: Deregistering RPC server http://192.168.1.13:7401/fh2001 at http://my.Remote.Location.xyz:2001/
2016.11.29 08:38:43 0: HMCCU: All RPC servers stopped


@zap, ich denke ich brauche hier speziell deine Hilfe: wo kann ich im HMCCU Modul für meine lokale FHEM Installation einen DNS Namen hinterlegen der dann für die Callback Registrierung verwendet wird (anstatt der lokalen IP Adresse)? Bzw. ist der Callback Port immer 7401, oder kann man den einstellen?

Danke!

[zap]

Hallo zap,

danke das du dich gemeldet hast und auch herzlichen dank an dich für deinen persönlichen Aufwand den du mit diesem Modul betreibst!

Purer Eigennutz

D.h. der RPC Server funktioniert grundsätzlich auch unter Windows.

Erstaunlich finde ich, dass er die Queue-Files (/tmp/ccuqueue_xxx) anlegen kann. Wo landen die denn unter Windows?

Wie man oben sehen kann wird der RPC Callback mit der lokalen IP Adresse (192.168...) bei der entfernten CCU registriert (DNS Name). Da mein FHEM und die CCU in unterschiedlichen Netzwerken sind und ich die Verbindung über das Internet aufbaue passiert natürlich folgendes:

Code Auswählen Erweitern


2016.11.29 08:38:23 1: HMCCU: RPC callback with URL http://192.168.1.13:7401/fh2001 initialized
2016.11.29 08:38:28 0: HMCCU: Periodical check found no RPC Servers
2016.11.29 08:38:28 1: HMCCU: Deregistering RPC server http://192.168.1.13:7401/fh2001 at http://my.Remote.Location.xyz:2001/
2016.11.29 08:38:43 0: HMCCU: All RPC servers stopped


D.h. Dein Router registriert seine Internet IP vermutlich bei einem Dyn-DNS Dienst. Für die Verbindung der externen CCU richtest Du entsprechend eine Port-Weiterleitung ein, korrekt?

Schwierig. Beim Starten des RPC-Servers ermittelt HMCCU die eigene IP und regisitriert diese bei der CCU. Ich müsste eine Möglichkeit (zusätzliches Attribut) einbauen, damit man diese IP bei Bedarf durch einen Namen überschreiben kann (keine große Sache). Auch der Port ist momentan nicht frei konfigurierbar (auch das könnte ich lösen). Kommt dann in einer der nächsten Versionen. Hast Du mal darüber nachgedacht, einen VPN Tunnel aufzubauen? Spart die potenziell unsichere Freigabe von Ports auf dem Router.

Was mich wundert ist die Meldung "Periodical check found no RPC Servers". HMCCU prüft alle paar Sekunden, ob der RPC-Server Prozess noch läuft. Diese Prüfung scheint unter Windows fehl zu schlagen. D.h. der RPC-Server Prozess läuft vermutlich noch, HMCCU erkennt das aber falsch. Kannst Du diese Vermutung bitte verifizieren, d.h. prüfen, ob im Taskmanager der Prozess noch da ist (PID steht im Log)?

[autLaW]

Erstaunlich finde ich, dass er die Queue-Files (/tmp/ccuqueue_xxx) anlegen kann. Wo landen die denn unter Windows?

Nachdem ich auf meinem Homeserver nur eine Partition habe (c:) und wohl c:\tmp auch unter Windows standard ist ergab sich das Problem wohl nicht. Auf jeden Fall finde ich unter c:\tmp zwei Dateien ("ccuqueue_2001.dat" und "ccuqueue_2001.idx") die wohl vom Zeitstempel her neue angelegt werden wenn der RPC Server gestartet wird.

D.h. Dein Router registriert seine Internet IP vermutlich bei einem Dyn-DNS Dienst. Für die Verbindung der externen CCU richtest Du entsprechend eine Port-Weiterleitung ein, korrekt?

Ja genau. Beide Router haben eine dynamische DNS Registrierung und Anfragen können entsprechend über Port Forwards an die CCU bzw. FHEM geleitet werden.

Wenn du wie beschrieben den lokalen DNS-Namen + Port (FHEM seitige) einstellbar machen könntest wäre das toll.

Hast Du mal darüber nachgedacht, einen VPN Tunnel aufzubauen? Spart die potenziell unsichere Freigabe von Ports auf dem Router.

Ja, natürlich mache ich mir darüber Gedanken und ist wohl auch in Zukunft anzustreben. Derzeit scheitert es an den unterschiedlichen Routern und der begrenzten Zeit die ich investieren kann. 

Kannst Du diese Vermutung bitte verifizieren, d.h. prüfen, ob im Taskmanager der Prozess noch da ist (PID steht im Log)?

Nein, die Prozess-ID (wie im Log geschrieben) kann ich im Taskmanager nicht mehr finden. Es ist sogar so das kurz nach dem Starten wenn die PID ins Log geschrieben wird der Prozess auch nicht im Taskmanger sichtbar ist (bzw. ist vermutlich der Update der Anzeige so träge das ich es nicht sehe bevor der Prozess wieder weg ist).

[zap]

Nein, die Prozess-ID (wie im Log geschrieben) kann ich im Taskmanager nicht mehr finden. Es ist sogar so das kurz nach dem Starten wenn die PID ins Log geschrieben wird der Prozess auch nicht im Taskmanger sichtbar ist (bzw. ist vermutlich der Update der Anzeige so träge das ich es nicht sehe bevor der Prozess wieder weg ist).

Gut, möglicherweise startet der Perl fork() unter Windows auch nur einen neuen Thread, der in der Standardansicht des Taskmanagers nicht angezeigt wird. Bin leider aus der Windows Welt schon einige Jahre raus und nutze nur noch MacOS und Linux. Möglicherweise hilft der Befehl tasklist als Admin auf Konsolenebene ausgeführt. Es wäre nur gut zu wissen, ob der RPC-Server wirklich nicht mehr läuft. Gibt es noch andere Meldungen im Log als die, die Du schon gepostet hast?

Das eigentliche Problem ist jedoch die Art und Weise, wir HMCCU prüft, ob der RPC-Server läuft. Dazu wird nämlich per kill() ein Signal an den Prozess geschickt und das Ergebnis ausgewertet. Das dürfte unter Windows (vielleicht) nicht funktionieren.

[chris1284]

der in der Standardansicht des Taskmanagers nicht angezeigt wird

hier bieten sich auch tools wie der prozessexplorer anhttps://technet.microsoft.com/en-us/sysinternals/processexplorer.aspx

[autLaW]

möglicherweise startet der Perl fork() unter Windows auch nur einen neuen Thread, der in der Standardansicht des Taskmanagers nicht angezeigt wird

Ja, das kann ich jetzt auch bestätigen. Mittels Prozessexplorer (Danke an chris1284!) habe ich die im Log angeführte "PID" als Thread unter dem allgemeinen FHEM-Perl-Prozess gefunden. D.h. der RPC Server läuft tatsächlich weiter.
Anmerkung: wenn ich den "set wrkst_ccu rpcserver on" Befehl wiederholt ausführe dann werden jedes mal neue Threads erzeugt (wobei alle alten bestehen bleiben).

Gibt es noch andere Meldungen im Log als die, die Du schon gepostet hast?

Es gibt keine anderen Meldungen die auf das HMCCU Modul zurückzuführen sind, jedoch hatte ich aus dem vorhergehenden Auszug einige Meldungen gelöscht die nicht vom HMCCU Modul kommen.
Jedoch bei genauerem Hinsehen, fällt mir auf das diese Meldungen immer mit den HMCCU Meldungen gemeinsam auftreten (Anmerkung: der "Unknown Code" ist jedoch immer anders).

Das Betroffene Device ist mein HM-LAN Adapter ("HMLAN1") den ich in FHEM verwende um die lokalen HM Geräte zu integrieren.
Sehr interessant ist die Tatsache das diese Meldungen immer "vermeintlich" Zeitgleich innerhalb von einer Sekunde auftreten.
D.h. kann es hier eine Abhängigkeit zwischen HMCCU und HMLAN geben?

Code Auswählen Erweitern


2016.11.29 18:07:33 0: HMCCU: Received SL event. RPC server CB2001 enters server loop
2016.11.29 18:07:40 1: HMCCU: Registering callback http://192.168.1.13:7401/fh2001 with ID CB2001 at http://my.Remote.Location.xyz:2001/

2016.11.29 18:09:47 1: HMCCU: RPC callback with URL http://192.168.1.13:7401/fh2001 initialized
2016.11.29 18:09:47 1: 192.168.1.14:1000 disconnected, waiting to reappear (HMLAN1)
2016.11.29 18:09:47 1: HMLAN_Parse: HMLAN1 new condition disconnected
2016.11.29 18:09:47 1: HMLAN_Parse: HMLAN1 new condition init
2016.11.29 18:09:47 1: 192.168.1.14:1000 reappeared (HMLAN1)
2016.11.29 18:09:47 3: HMLAN1: Unknown code A0C5xxxxxxxxxxxxxxxxxxxxx32::-47:HMLAN1, help me!
2016.11.29 18:09:47 1: HMLAN_Parse: HMLAN1 new condition ok

2016.11.29 18:09:52 0: HMCCU: Periodical check found no RPC Servers
2016.11.29 18:09:52 1: HMCCU: Deregistering RPC server http://192.168.1.13:7401/fh2001 at http://my.Remote.Location.xyz:2001/
2016.11.29 18:10:07 0: HMCCU: All RPC servers stopped


Anmerkung: diese "HMLAN1: Unknown code A0C5xxxxxxxxxxxxxxxxxxxxx32::-47:HMLAN1, help me!" Log-Einträge habe ich schon lange.
Diese treten immer wieder am Tag auf. Ich hab sie bisher immer ignoriert.

[wuast94]

Ich habe es dann mal geschafft die CCU2 einzubinden und auch meine drei Thermostate einzubinden... allerdings frage ich mich jetzt wie ich das ganze schöner machen kann.

Wenn ich zb die Temperatur ändern will muss ich als befehl "set HM_HeizungBad datapoint 4.PARTY_TEMPERATURE <wert>" eingeben was ich eher umständlich finde.

Gibt es eine möglichkeit das schöner zu gestallten ? zb einen regler in fhem anlegen oder so etwas ? und sry wenn das schon geklärt oder gefragt worden ist aber in einzelnen threads suchen ist ja leider nicht möglich :/

[ph4]

Kann das bei mir nachvollziehen, ist ein Bug. Wird in der neuen Version (kommt noch diese Woche) behoben.

Bei den Attributen lässt sich noch das eine oder andere optimieren, speziell wenn Du Slider für das Dimmen verwenden möchtest. Das Attribut statechannel ist veraltet und bei controldatapoint fehlt die Kanalnummer (hat aber beides nichts mit dem Toggle Problem zu tun). Vorschlag:

Code Auswählen Erweitern


controldatapoint 1.LEVEL
statedatapoint 1.LEVEL
substitute LEVEL!#0-0:off,#1-100:on

# Datenpunkte filtern (je nach Wunsch). Ersetze xyz durch den Namen von Kanal 1 in der CCU oder lasse xyz! komplett weg.
ccureadingfilter xyz!(^LEVEL$|ERROR)

# Schlankere Readingnames
ccureadingformat datapoint

# Fuer den Slider
substexcl control
webCmd control:on:off
widgetOverride control:slider,0,10,100


Vielen Dank für die Info, habe ich gleich mal so umgesetzt. Ist wirklich nun deutlich übersichtlicher.

[Yil]

Ich habe in Sachen Dimmer mal die Darstellung des halbrunden Kreises (bei den Gerätedefinitionen, arbeitet im Bereich 0-1) auf die von Dir empfohlene Darstellung umgestellt, weil ich sie auch schöner zu bedienen finde und ich mehrere solcher Schieberegler habe:

Code Auswählen Erweitern

Internals:
   DEF        MEQ0395724 1
   IODev      HMCCU2
   NAME       WZ.Deckenbeleuchtung
   NR         1134
   STATE      0
   TYPE       HMCCUDEV
   ccuaddr    MEQ0395724
   ccudevstate Active
   ccuif      BidCos-RF
   ccuname    WZ.Deckenbeleuchtung
   ccutype    HM-LC-Dim1TPBU-FM
   channels   4
   statevals  devstate
   Readings:
     2016-12-02 12:14:02   1.LEVEL         off
     2016-12-02 12:14:02   1.LEVEL_REAL    0
     2016-12-02 05:31:23   2.LEVEL         1
     2016-12-02 12:14:02   2.LEVEL_REAL    0
     2016-12-02 05:31:23   3.LEVEL         1
     2016-12-02 12:14:02   3.LEVEL_REAL    0
     2016-12-02 12:14:02   control         0
     2016-12-02 12:14:02   state           off
Attributes:
   IODev      HMCCU2
   alias      Wohnzimmer Deckenlampe
   ccureadingfilter (LEVEL)
   ccureadingformat datapoint
   ccureadings 1
   ccuverify  2
   controldatapoint 1.LEVEL
   devStateIcon {Color::devStateIcon($name,"dimmer",undef,"state")}
   devStateStyle style="text-align:right;"
   event-on-change-reading .*
   group      Licht
   icon       light_ceiling
   room       Device,Wohnzimmer
   stateFormat {sprintf("%d",ReadingsVal($name,"1.LEVEL",0)*100)}
   statedatapoint 1.LEVEL
   stripnumber 2
   substexcl  control
   substitute LEVEL!#0-0:off,#1-100:on
   webCmd     control:on:off
   widgetOverride control:slider,0,10,100

Leider bekomme ich einen Fehler, wenn ich auf on oder off schalte (Unknown argument ...). Bei Werten auf dem Slider < 50 springt der Slider auf 0, das Licht wird nicht geschaltet, bei Werten > 50 springt er im 1.LEVEL auf 1, das Licht wird voll aufgedimmt. Irgendwas habe ich übersehen, oder?

[zap]

Da scheint das Attribut ccuscaleval zu fehlen:

ccuscaleval LEVEL:0:1:0:100

Dann sieht Dein stateformat auch etwas einfacher aus, nämlich nur LEVEL. Die Multiplikation mit 100 sowie das Teilen durch 100 beim setzen der Werte übernimmt HMCCU.

[Yil]

Das war's 

Thx

[martinp876]

ich habe einmal eine HMCCU eingerichtet - parallel zu meiner FHEM Installation.
das automatische einbinden ist schief gegangen da der default-name in der CCU ein Leerzeichen beinhaltet. Ich muss also erst alles umbenennen? Macht sicher sinn, muss man nur wissen. Wäre cool wenn zu fehlermendungen kommt bei Leerzeichen.

dann habe ich die Kanäle umbenannt - jeden einzeln ( schönes FHEM ). Hierbei kann ein Kanal den gleichen Namen haben wie das Device. Dann klappt es nicht wirklich meine ich. Das Device fehlte am Ende.

Weiter habe ich dann neue Namen vergeben. Die alten Devices haben weiter existiert.

=> wie kann ich einen sauberen Abgleich machen: Alle Devices eintragen, Fehler erkennen, Umbenannte löschen oder umbenennen? Ohne Sync der Gerätenamen sehe ich Probleme.

Es scheint mir so, dass hierbei noch mehr Entities angelegt werden als in FHEM. Ein Device ist a) das Device und b) Device mit Channel 0.
Es scheint demnach nicht die Absicht der des Moduls zu sein, ein umfassendes Abbild in FHEM zu erstellen - korrekt?

[DerTom]

Die CCU macht immer ein Leerzeichen in den Namen des Device oder des oder der Channel beim Anlernen. Da ich diese in der CCU aber nicht umbenennen möchte, wie kann ich diese in FHEM per

Code Auswählen Erweitern


get CCU2 devicelist create ...


importieren? Jedes Device oder Channel in der CCU umzubenennen ist sehr umständlich.

[zap]

ich habe einmal eine HMCCU eingerichtet - parallel zu meiner FHEM Installation.
das automatische einbinden ist schief gegangen da der default-name in der CCU ein Leerzeichen beinhaltet. Ich muss also erst alles umbenennen? Macht sicher sinn, muss man nur wissen. Wäre cool wenn zu fehlermendungen kommt bei Leerzeichen.

Was meinst Du mit automatischem Einbinden? Hast Du versucht, ein einzelnes Device oder einen einzelnen Channel in FHEM zu definieren oder wolltest Du per "get devicelist create" alles auf einmal anlegen?

Grundsätzlich unterstützen HMCCU,HMCCUDEV und HMCCUCHN CCU Geräte und Kanäle mit Leerzeichen im Namen, da die Kommunikation immer über die Seriennummer/Adresse erfolgt.
Das Problem ist das Define in FHEM. Bisher benutzen die Module nicht die neue Commandline Parserfunktion. Daher wird ein CCU Name mit Leerzeichen beim Define wie 2 Argumente behandelt. Man kann sich bei einem einzelnen Define aber behelfen, indem man statt des Namens die Seriennummer/Adresse angibt. Leider funktioniert das bei "get devicelist create" nicht (meine Schuld, wird korrigiert).

dann habe ich die Kanäle umbenannt - jeden einzeln ( schönes FHEM ). Hierbei kann ein Kanal den gleichen Namen haben wie das Device. Dann klappt es nicht wirklich meine ich. Das Device fehlte am Ende.

Ja, das liegt daran, dass HMCCU beim Ansprechen der CCU Geräte und Kanäle einen generischen "GetObject" Aufruf durchführt. CCU seitig ist alles ein Objekt, ob jetzt Kanal, Gerät, Systemvariable, Raum, usw. Daher darf ein Name in der CCU nicht doppelt verwendet werden. Sonst müsste HMCCU jedes mal den kompletten Objektbaum der CCU durchforsten und den Objekttyp überprüfen. Das wäre aufwändig und langsam.
Grundsätzlich würde ich eh dazu raten, sich für CCU Geräte und Kanäle ein eingängiges Namenskonzept zu überlegen. Das macht das Leben (nach der Umbenennung) leichter.

Weiter habe ich dann neue Namen vergeben. Die alten Devices haben weiter existiert.

Also die alten Devices in FHEM(?). Bei jeglicher Änderung an Geräten oder Kanälen in der CCU generiert HMCCU einen FHEM Event (es sei denn, ich habe da noch einen Bug drin). Sonderfall: Wenn man einen Namen in der CCU ändert, wird das Internal "ccuname" im FHEM Device automatisch angepasst. Ist aber nur Kosmetik, da die Kommunikation wie gesagt über Seriennummer/Adresse erfolgt.

=> wie kann ich einen sauberen Abgleich machen: Alle Devices eintragen, Fehler erkennen, Umbenannte löschen oder umbenennen? Ohne Sync der Gerätenamen sehe ich Probleme.

Grundsätzlich sollte der Befehl "get devicelist" das leisten. Ich habe jedoch bisher davon abgesehen, vorhandene FHEM Devices einfach zu löschen. Stattdessesn wird ein Device z.B. als "deleted" gekennzeichnet.

Es scheint mir so, dass hierbei noch mehr Entities angelegt werden als in FHEM. Ein Device ist a) das Device und b) Device mit Channel 0.
Es scheint demnach nicht die Absicht der des Moduls zu sein, ein umfassendes Abbild in FHEM zu erstellen - korrekt?

Es bleibt Dir überlassen, wie viele Entitiies Du in FHEM anlegst. Wenn Du ein Device mit HMCCUDEV anlegst, hast Du darin das Device selbst plus alle seine Kanäle an einer Stelle. Mit HMCCUCHN legst Du in FHEM ein Device für einen einzelnen Kanal an. Wenn Du nun "get devicelist create" mit einem ".*" verwendest, ist das nicht im Sinne des Erfinders, da dann sehr viele redundante Devices angelegt werden. In der nächsten Version kann man das automatische Anlegen von FHEM Devices auf CCU Geräte einschränken und Kanäle ignorieren.

Der Kanal 0 ist ein Sonderfall. Homematic Geräte haben keinen Kanal 0. Den fügt die CCU hinzu um dort Datenpunkte wie RSSI, LOWBAT oder UNREACH zu verwalten. Damit man diese Infos auch bei Devices vom Typ HMCCUCHN zur Verfügung hat, ist der Kanal 0 auch bei diesen Devices mit dabei.

@DerTom: Wie oben geschrieben: "get devicelist create" kann bald auch mit Leerzeichen in Namen umgehen. Ich empfehle trotzdem, sich ein Namenskonzept zu überlegen und das auch in der CCU umzusetzen.

[martinp876]

Nun, mein Anspruch mag nicht der Mai stream sein, ist eben nur meine Sicht und wie ich es realisieren würde, welche Funktionalität ich mir wünsche.
Zum ersten ist es ein sauberer und kompletter Abgleich der devices. der support mit Leerzeichen kommt habe ich verstanden. Gut.
Wenn ich ein devicelist mache werden alle devices gelesen, leider kann ich sie nicht sehen. Sie stehen in helper, also unsichtbar. Warum werden sie nicht ausgegeben wenn ich ein get absetze?

Leerzeichen halte ich für kritisch. Nun, ccu nutzt es. Ich würde diese strikt durch ein _ ersetzen. Aus die Maus. Das wird immer zu Problemen führen.

Der Kanal 0 existiert im device. Das ist schon korrekt, nur kann man diesen gut handeln, muss man den User nicht mit belasten. CUL_HM geht damit entsprechend um.

Ich werde weiter spielen. Ich vergleiche natürlich culhm mit hmccu.
Aktuell schneidet (kein Wunder, ich habe meine Vorstellung realisiert) culhm nicht schlecht ab. Was fehlt ist ein komfortables Frontend fuer Register und templates. Und das unschlagbaren timing der ccu beim msg senden, da werde ich nicht ran kommen.

Aber, kein falscher Eindruck: gute Arbeit!! Ich werde weiter meine Ideen vorbringen, was immer du damit machst.