HMCCU 5.0 Beta verfügbar

[martinp876]

Das Wochenende wird eng bei mir. Unklar ob ich zum Testen komme.

Registerdarstellung. Schwierig. Ich meine in culhm einen flexiblen und sinnvollen weg gefunden zu haben. Ist aber nicht unerheblich arbeit deinerseits.
Mein Vorschlag:
1) register haben immer einen Präfix. Bei mir ist es "R-". Der Anwender sollte/muss/darf wissen, dass es sich um remandnte werte handelt. Ich als admin muss verstanden haben welcher Wert nach einem powerup im device stehen wird
2)link bezogene register haben den Präfix "R-<peername>"-. Hier beginnt schon der erste Arbeitsblock.
2a) bei chn musst du das rename einer peerentity abfangen und die register umbenennen.
2b) nicht vorhandene peers müssen zur Löschung der zugehörigen register führen. D.h. immer wenn du die peerliste eines kanals liest musst du prüfen ob die register der links vollständig sind, wenn nicht holen. Und ob ein peer nicht mehr peer ist, dann die readings löschen.
2c) in der dev Variante musst du dir für den peernamen etwas einfallen lassen. Besonders hässlich ist der Mischbetrieb. Ein grund, warum ich es mir nicht antun würde.
2d) in jedem fall muss ich die peerlists mit den peerreadings sofort und anhand der namen assoziieren können. Und drauf clicken.

3) register sind immer in de  readings. Ggf. Sind sie nicht sichtbar. Das reading hat dann den präPräfix ".".
4) der anwender kann den sichtbarkeitslevel über ein attribut steuern.  Hierzu habe ich registerklassen festgelegt
A) raw register. Das sind binärwerte welche du glücklicherweise nicht siehst.
B) default register. Hier habe ich ein paar aus gewählt welche ich für wichtiger hielt. Du könntest alle master register des kanals hier einsetzen. Dann  brauchst du keine selektionsliste.
C) nondefault regs. Konnten bspw die link register sein.
D) templates.das sind dann frei programmierbare registerabstraktionen. Das wird der eigentliche operator level.
Die sichtbarkeit der einzelnen level lässt sich über einen parameter mit bitmaske einstellen. Der user kann die suchtbarkeit über ein einziges attribut steuern. Je kanal. Sinnvoller default ist notwendig. Evtl in hmccu.

5) einzelne werte sind immer über ein get abfragbar. Für evtl. Nachgelagerte scriptverarbeitung.
6) register einer entity kann man über ein get als Tabelle abfragen. Möglichst kompakt und so, dass man es in ein excel bekommt.
7) temperaturlisten sollte man gesondert behandeln. Das ist eine unmenge an registern. Man kann sie hervorragend zusammenfassen. Das braucht man für ein- sowie Ausgabe. Ich stelle hier das profil eines tages in einem Reading dar. Selbstverständlich nur die relevanten. Wenn der letzte Eintrag rekannt ist werden die letzten verschluckt
Der temperaturlisten heisen R_x_templistSun wobei x =0 für sonntag die Sortierung erstellt. Also 1 für Mon


So, das war glaube ich das wesentliche.

P.s. um hm devices zu verstehen lohnt sich e.m. ein blick in das Einsteiger doc, Kapitel hm. Das habe ich vor jahren verfasst. Das Verständnis zu culhm ist nicht so wichtig für dich. Allerdings funktionieren die hm devices aller serien nach dem prinzip. Nich vom Namen "Einsteiger" abschrecken lassen wie viele, denen es unter der würde ist. Ich enpfehle es jedem, der sicher mit den ddvices umgehen will

[zap]

Ich denke, ich werde es so realisieren wie von Dir vorgeschlagen:
- Grundsätzlich werden alle Readings aktualisiert und gespeichert
- Readings können mit . ausgeblendet werden
- Ich verwende dafür das schon vorhandene Attribut "ccureadingfilter". Das werde ich noch etwas ausbauen in Richtung verschiedener Sichtbarkeitslevel.

Da ich jetzt schon alle Werte im Hash des FHEM Device speichere, sollte ein nachträgliches Umbauen der Readings auch keine große Sache sein.
Ist nicht schlimm, wenn Du nicht zum Testen kommst, habe ja noch genug zu tun

Mittlerweile sollten folgende Channel-Types weitgehend ohne Extra-Attribute out of the box funkionieren: SWITCH, BLIND, SHUTTER_CONTACT
Bei anderen Typen muss man nach wie vor "statedatapoint", "controldatapoint", "statevals", "substitute" usw. definieren, damit alles funktioniert.

[martinp876]

ok, hört sich gut an.

ccuReadingsFilter ist ok. Es sollte eine Option geben, welche mir erlaubt, einen einfachen default Filter zu nutzen.
Bei CULHM schalte ich Register per default aus. Diese werden nur bei gewissen maintenance aktionen temporär eingeschaltet. Templates sind dagegen immer an und zeigen mir die Funtktion abstrakt, lesbar und reproduzierbar an.

Noch ein Scenario zu duplikate entites:
In meiner Welt sind alle Channels instanziiert, jedes einmal. Nun habe ich bspw einen Button Channel mit einem Schalt-Channel gepeert.
Button Addr 11111111:3, name Btn_Wohn_rechts
Schalter Addr 22222222:5, name Licht_Wohn_Decke

In der jeweiligen Entity will ich die Referenz sehen, natürlich als Name und verlinkt. Jeden Peer nur einmal:
Btn_Wohn_rechts:
  PeerList:  Licht_Wohn_Decke,<otherPeer>,...
  R-Licht_Wohn_Decke-PeerNeedsBurst on
  R-Licht_Wohn_Decke-AESexpected off
  R-<otherPeer>-PeerNeedsBurst off
 
Licht_Wohn_Decke
  PeerList:  Btn_Wohn_rechts,<otherPeer4Switch>,...
  R-Btn_Wohn_rechts-onTime 100
  R-Btn_Wohn_rechts-offTime infinite
  R-<otherPeer4Switch>-onTime 1000

So etwas läuft fluffig wenn man eine 1:1 zuordnung von Adresse zu Name hat (FHEM typisch). Wenn du nun einen Kanal mehrfach instanziieren kannst ... was machst du dann? Alle Einträge duplizieren?

Du wirst eine Lösung brauchen. Mit der FHEM tpischen Installation (Adresse =DEF => Name ) gibt es diese Frage garnicht.

[zap]

Bei HMCCUCHN wird mittlerweile auf existierende Devices geprüft, jeder Channel hat also maximal 1 FHEM Device.

Bei HMCCUDEV muss ich doppelte Definitionen zulassen, v.a. wg. HmIP-Wired. Hier gibt es komplex Mehrfachaktoren, z.B. für FB-Heizungen. Da hast du ein Gerät mit 16 Kanälen, wobei jeweils 4 Kanäle verwendet werden, um einen Heizkreis zu steuern. Durch die Mehrfachdefiniton kann der Nutzer mit gerade mal 4 Devices seine 4 Heizkreise steuern. Alternative wären 16 HMCCUCHN Devices, und das ist nur der kleine FB-Aktor.
Macht die Welt unnötig kompliziert.

Vielleicht führe ich mal sowas wie einen virtuellen Kanal ein, der mehrere physikalische Kanäle zusammenfasst. Ist aber auch nicht trivial, da die Kanäle teilweis identische Datenpunkte haben.

[martinp876]

Das solltest du einführen. Allerdings solltest du die wortwahl virtuell tunlichst vermeiden. Der begriff ist schon belegt durch virtuelle kanäle der ccu selbst sowie bspw teamleads.
Was du einführen kannst sind groups, also funktionsgruppen. Diese sind funktional notwendig. Allerdings solltest du zuerst prüfen, was fhem bietet. Reading groups u.ä. wenn es damit abzudecken ist solltest du nichts neues erfinden. Ich kenne hier nicht alle optionen.

Mir würde hier eine allgemeine anwendung gefallen. Bspw habe ich rt und tc gepeert. Das ist also eine gruppe. Hier können es auch mehrere rts sein. Dann können noch fensterkontakte hinzukommen. Dies zusammen ergibt das heizmodul eines zimmers. Alle funktionskanäle des verbunds (funktionsgruppe) werden einbezogen. Automatisch nach auswerten der peerings.
Ein kanal kann in mehreren funktionsgruppen vorkommen. So z.b. der fensterkontakt in der home-security.

Somit könnte man den zwischenschritt der funktionsgruppen eines device gleich überspringen.

Chn:
Wenn du also nur eine instanziierung eines kanals zulässt kannst du gleich die adresse in def festlegen. Dann musst du nichts prüfen. Für mich der Königsweg.

Mischung:
Ein kanal kann nun, so verstehe ich es, in chn und auch (mehrfach) in dev angelegt werden. Bleibt die Frage nach der benamung der peerings weiter offen.

[zap]

Neue Versionen im Contrib.

Readings

Die Readings eines HMCCUCHN Device werden über die Attribute ccuflags und ccureadingfilter gesteuert. In ccuflags wird das Level festgelegt. Readings für Datenpunkte werden immer angezeigt (also Parameterset VALUES). In ccuflags können folgende Werte gesetzt werden:

showMasterReadings - Zeigt Readings vom Parameterset MASTER an (die Konfigurationsparameter)
showLinkReadings - Zeigt Readings vom Parameterset LINK an (1 Reading je Receiver und Parameter)
showDeviceReadings - Zeigt Readings vom Parameterset VALUES für den Kanal 0 und vom Parameterset MASTER für das Device an

Readings werden grundsätzlich nach den Angaben in ccureadingfilter nochmal gefiltert. Wenn man alle Readings haben möchte, setzt man:

Code Auswählen Erweitern

ccuflags = showMasterReadings,showLinkReadings,showDeviceReadings
ccureadingfilter = .*

ccureadingfilter hat den Default .* (alle Werte)

Das Prefix für Readings kann mit dem Attribut ccuReadingPrefix eingestellt werden. Defaults:

R- => MASTER Parameterset (Kanal)
D- => MASTER Parameterset (Device) und VALUES Parameterset (Kanal 0)
L- => LINK Parameterset (Kanal)
Werte im VALUES Parameterset haben kein Prefix.

Wenn Reading bezogene Attribute geändert werden, werden alle Readings automatisch aktualisiert (aus dem Cache in FHEM, nicht aus der CCU).

Es gibt einige Standard-Readings in jedem HMCCUCHN Device:

battery => low, ok oder unknown (keine Batterie)
activity => alive oder dead
devState => Liste von Fehlerzuständen aus Kanal 0 (ohne LOW_BAT und UNREACH, die über battery und activity dargestellt werden)

Set (Auszug)

Mit folgendem Befehl können Link-Parameter gesetzt werden:

set xy link Chn-Receiver Parameter=Value [...]
set xy link Dev-Receiver Channel Parameter=Value [...]
set xy link Parameter=Value [...]

Als Receiver kann man eine Kanaladresse oder den Namen eines HMCCUCHN Device angeben. In der 2. Variante wird der Name eines HMCCUDEV Device und zusätzlich eine Kanalnummer angegeben. Es werden nur existierende Receiver für den aktuellen Kanal akzeptiert.
Bei der 3. Variante werden die angegebenen Parameter für alle existierenden Receiver gesetzt.

Get (Auszug)

get config - Liest die MASTER und LINK Parameter Sets von Kanal und Device (Steuerung der Darstellung über ccuflags / ccureadingfilter)
get values - Liest die VALUES Parameter Sets vom aktuellen Kanal und Kanal 0 (   --- " --- )
get update - Liest alle Parameter Sets (noch nicht implementiert)

[martinp876]

Hört sich gut an.
Set xy link parameter
Ist ambitioniert und für anwender gefährlich. Würde ich nie verwenden. Ich würde es nicht anbieten. Du schreibst es dann folglich in alle peer datensätze die du anhand der gecachten peerlists kennst. Ich glaube das kommando macht neben mehr arbeit auch die Fehleranfälligkeit deutlich größer. Der funkverkehr zum device wird auch nicht belastet. Im Gegenteil, bei vielen peers ist es richtig viel. Das setzen von registern ist so das aufwändigste in der Luft.

Short und long sind dediziert als Parameter anzugeben. Passt.

Meine implementierung war (übersetzt)
Set xy param <register> <value> [<peer>]

Das kommando gilt dann für alle register. Peer / link/ master ... egal.
Sollte ein peer notwendig sein muss er angegeben werden, sonst gibt es eine fehlermeldung. Daher steht peer auch am ende er Parameterliste.
Für meinen geschmack eleganter weil 1 Kommando weniger.
DevReceiver Channel ist sicher ein Parameter in der schreibweise welche du in hmccudev generel nutzt.
Du solltest aber nicht von receiver reden. Das konnen auch sender assotiationen sein. Es sind schlicht linked channels. Immer channels > 0. Der begriff peer ist eigentlich eingeführt hierfür.

Die Darstellung der Link parameter ist spannend - wegen der namensgebung und der doppelten instanziierung der peers. Sehe ich hoffentlich heute abend.

[martinp876]

Die aktuelle Version crached in Zeile 4482.
Addresse ist ok
channel ist ok
parameterset ist aber der Parameter, nicht das set. Und dann cracht es - FHEM kommt nicht mehr hoch.

[martinp876]

ich habe die Funktion einmal abgeklemmt - jetzt bootet das System wieder.

Unklar:
- Das Update der Readings wird extrem verzögert gestartet
- Die Performance ist nicht sehr hoch - mir noch unklar, woran es liegt. Wenn es nicht besser wird werde ich es später betrachten müssen.

Klar:
- Nachdem ich die Readings abgeklemmt habe funktionieren auch die Readings nicht. Ich warte auf den Update.

Kommandos:
- Mein Rollo hat jetzt level und pct als Kommando. Warum doppelt?
- pct sollte einen Slider haben

[zap]

Den Fehler schaue ich mir gleich an. Einige Nutzer verwenden pct, andere level (bisher hatte ich nur pct). Aber ich bin gerade sowieso dabei, für diese Channel Role spezifischen Befehle eine etwas generischere Lösung zu bauen. Das ist mi mir momentan noch zu statisch. Ziel ist ja weiterhin, dass auch neue Geräte auf dem Markt sofort nutzbar sind, ohne dass ich die Module erst anpassen muss.

Bzgl. der Benennung Link Receiver: Ich verwende die Terminologie von EQ-3, d.h. Kanäle sind Sender/Receiver, wenn sie in der Link-Liste der CCU so benannt sind.

Den Set link Befehl werde ich entschärfen und nur noch den Receiver zulassen. Über die Zusammenlegung mit set config denke ich mal nach. Man könnte ja immer, wenn eine Receiver-Adresse angegeben ist, vom LINK Paramset ausgehen. Bei get gibt es ja auch kein get link.

Update: Dachte eigentlich, das ich mit der RPC Schnittstelle das meiste erschlagen kann. Finde aber immer mehr Punkte, die doch wieder die ReGa / HMScript Schnittstelle erforderlich machen. Aktuell: Verknüpfte CCU Systemvariablen. Die legt die CCU beim Anlernen eines Gerätes an. Sie verhalten sich wie normale Datenpunkte. Davon weiß RPC nichts.

Zum Fehler: Mach bitte nochmal ein Update, bei mir sehen die Zeilen ab 4482 so aus:

Code Auswählen Erweitern

# Modify value: scale, format, substitute
$sv = HMCCU_ScaleValue ($clHash, $c, $p, $v, 0);
$fv = HMCCU_FormatReadingValue ($clHash, $sv, $p);
$cv = HMCCU_Substitute ($fv, $clHash, 0, $c, $p, $chnType, $devDesc);
$cv = HMCCU_GetParamValue ($ioHash, $devDesc, $ps, $p, $fv) if ("$fv" eq "$cv");

[zap]

Das wöchentliche Update der Beta steht unter contrib/HMCCU/FHEM zur Verfügung.

Neu:

Der Befehl "set link" ist in "set config" aufgegangen. Um einen Link-Parameter zu setzen, verwendet man folgende Syntax:

set xy config receiver [channelNumber] Parameter=Value [...]

Der Parameter receiver ist entweder ...
- eine Kanaladresse
- der Name eines FHEM Device vom Typ HMCCUCHN oder HMCCUDEV
- ein CCU Kanalname

Wenn ein HMCCUDEV Device angegeben wird, muss zusätzlich die Nummer des Empfangskanals angegeben werden.

Sonst: Der Befehl "set defaults" kann nun einige Attribute anhand der Kanal-Rolle erkennen und setzen.

Unbedingt alle Module aus dem contrib Verzeichnis installieren, inkl. HMCCUConf.pm

[martinp876]

Receiver kann also ein Aktor oder ein Sensor sein. Na gut, es ist eben der peer.

Es gibt links ohne weitere Parameter. Ob es Parameter in Link gibt siehst du in der description.
Wenn keine da sind ist das kommando ungültig. Die Prüfung des Kommandos muss anhand der description erfolgen. Eine Auswahl an Optionen ist die Rückgabe bei Fehler

[martinp876]

habe gerade die Version 02.21 eingespielt

Code Auswählen Erweitern

2020.02.23 08:08:37.911 1: HMCCURPCPROC: [d_rpc178046BidCos_RF : 13359] RPC server CB2001178064178046 running
2020.02.23 08:08:37.919 1: HMCCU: [HMccu : 13359] All RPC servers running
2020.02.23 08:08:38.076 1: HMCCURPCPROC: [d_rpc178046BidCos_RF : 13359] Scheduled CCU ping every 300 seconds
2020.02.23 08:08:39.032 2: HMCCURPCPROC: [d_rpc178046BidCos_RF : 13365] CB2001178064178046 NewDevice received 226 device and channel specifications
2020.02.23 08:08:39.334 2: HMCCURPCPROC: [d_rpc178046HmIP_RF : 13366] CB2010178064178046 NewDevice received 103 device and channel specifications
Can't use string ("1") as a HASH ref while "strict refs" in use at ./FHEM/88_HMCCU.pm line 4498.

leider nix gefixed. Brauchst du Informationen?
a) Absturz muss verhindert werden - wir brauchen also eine Prüfung
b) muss ich irgend etwas neu einlesen? Habe ich alte Daten welche die Abfrage korumpieren?

[martinp876]

Update: Dachte eigentlich, das ich mit der RPC Schnittstelle das meiste erschlagen kann. Finde aber immer mehr Punkte, die doch wieder die ReGa / HMScript Schnittstelle erforderlich machen. Aktuell: Verknüpfte CCU Systemvariablen. Die legt die CCU beim Anlernen eines Gerätes an. Sie verhalten sich wie normale Datenpunkte. Davon weiß RPC nichts.

Deine Erkenntnis  erschreckt mich. Das ist doch irgendwie klar gewesen. Ich rate dringend dazu, ein Dokument zu schreiben, welches die Architektur beschreibt und namen definiert. Ebenso die Ziele der Module.

Eine Dokumentation (wird von SW-Schreibern oft ungern gemacht - dauert....) ist aus meiner Erfahrung exterm hilfreich, nciht nur für andere sondern auch für einen selbst, sich eine Architektur darzulegen und diese dann konsequent zu implementieren.  Es verhindert, dass man am Ende ein fragiles Kontrukt an SW erstellt hat welches nicht mehr wartbar ist. Professionell wäre man ohne dies sicher schnell am Ende.

Ich mache einmal einen Anfang.
1) Die Device Ebene (nicht mit DEV verwechseln)
- Device: ein externes Gerät welches es zu steuern gilt.
- channel: Funktionseinheit eines Devices
- Channel0: (unser Streitpunkt). Vereinigt daten der internen Device-ebene sowie des Channel 0. Das vereinfacht für den User einiges, da es überflüssig ist, eine weitere ebene (device-register) in einer weiteren Channe-art darzustellen.
- register: Remanente Konfigurationsdaten in einem Channel. Da Die Device-ebene aus User-sicht in Channel0 aufgeht ist diese Definition umfassend.
- values: Status-werte eines kanals
- peers: Links zwischen channels. Das sind immer Punkt-zu-Punkt Verbindungen
- virtuelle Devices: Nachbildungen von devices welche quasi den gleichen Regeln genügen. Hier ist luft zur präzisen definition

=> Diese Ebene lässt sich nahezu zu 100% aus dem RPC-Interface bedienen. Sicher kann man das Gateway auch nutzen, die Informationen zu erhalten, aber eben nur diese ebene. Man sollte die Level nicht mischen
=> DEV und CHN sollte man als Ebenen einführen. DEV ist m.E. nicht notwendig, aber möglich. Mit dieser Aussage im Hinterkopf (dokumentiert) . Unterste ebene ist das IO (HMCCU) auf welcher die Channels (HMCCUCHN) liegen sollten. HMCCUDEV sind dann gruppierungen von Channels. Wer keine Channels sehen möchte könnte diese "invisible" setzen. Damit hättest du eine saubere und eindeutige Struktur. Leider bist du nicht strikt und versuchtst den unsauberen Weg, alles in die HMCCU zu packen und nur noch visualisierungen der Entites in CHN und DEV zu erstellen.


2) CCU-Level
- Die CCU stellt diverse Funktionalität zu Verfügung. Diese spielt sich komplett on top der Device-ebene ab. Daher sollte eine separate Ebene eingeführt werden, welche die Elemente hier darstellt. Das sind nicht  nur Variablen sondern auch Scripte.
- Die Ebenen on Top der Devices kann komplett von FHEM abgefrühstückt werden. Allerdings ist dies langsamer und evtl nicht effizient. Will ein Anwender Scripten und Variablen,... aus der CCU nutzen sollte man diese Elemente als neue Typen in FHEM darstellen. Man könnte die Verknüpfungen darstellen (welche channels haben mir dem Script zutun (-indirekt-verlinkungen)
Die Ebene enthält neben Variablen auch Räume, gewerke,...

==> Würdest du dich entscheiden, die Ebenen konsequent zu trennen wäre es ein leichtes die Ebene Device erst einmal abzuschliessen. Du wärst m.E. schon lange fertig und könntest dich der Mehrwert-ebenen widmen.
==> Die bedienung, Konfiguration und überwachung der Device-ebene ist nicht schwer. RPC ist hierfür gedacht und zu 90% hinreichend
==> überdenke  noch einmal das Layering deiner SW-Architektur.

[zap]

habe gerade die Version 02.21 eingespielt

Code Auswählen Erweitern

2020.02.23 08:08:37.911 1: HMCCURPCPROC: [d_rpc178046BidCos_RF : 13359] RPC server CB2001178064178046 running
2020.02.23 08:08:37.919 1: HMCCU: [HMccu : 13359] All RPC servers running
2020.02.23 08:08:38.076 1: HMCCURPCPROC: [d_rpc178046BidCos_RF : 13359] Scheduled CCU ping every 300 seconds
2020.02.23 08:08:39.032 2: HMCCURPCPROC: [d_rpc178046BidCos_RF : 13365] CB2001178064178046 NewDevice received 226 device and channel specifications
2020.02.23 08:08:39.334 2: HMCCURPCPROC: [d_rpc178046HmIP_RF : 13366] CB2010178064178046 NewDevice received 103 device and channel specifications
Can't use string ("1") as a HASH ref while "strict refs" in use at ./FHEM/88_HMCCU.pm line 4498.

leider nix gefixed. Brauchst du Informationen?
a) Absturz muss verhindert werden - wir brauchen also eine Prüfung
b) muss ich irgend etwas neu einlesen? Habe ich alte Daten welche die Abfrage korumpieren?

Version 02.21 bezieht sich jetzt worauf ??

Die fragliche Zeile sieht im aktuellen Modul 88_HMCCU.pm so aus:

Code Auswählen Erweitern


4497: # Store raw value in client device hash
4498: HMCCU_UpdateInternalValues ($clHash, $chKey, $ps, 'VAL', $v);


Die Fehlermeldung passt irgendwie nicht dazu.

Es gibt links ohne weitere Parameter. Ob es Parameter in Link gibt siehst du in der description.
Wenn keine da sind ist das kommando ungültig. Die Prüfung des Kommandos muss anhand der description erfolgen. Eine Auswahl an Optionen ist die Rückgabe bei Fehler

Ich gehe davon aus, dass ein Link ohne Parameter auch kein Parameterset LINK besitzt. Das wird abgefragt und entsprechend eine Fehlermeldung ausgegeben. Die Parameter selbst werden tatsächlich noch nicht auf Gültigkeit geprüft.

Zu Dokumentation / Architektur / Channel vs. Device:

ich denke, dass HMCCUCHN mittlerweile Deiner Vorstellung entspricht, abgesehen vom leidigen 'device' Parameter. Letzteren kann man gerne ignorieren und stattdessen zusätzlich noch ein HMCCUDEV Device definieren, wenn man auf Device Parameter zugreifen möchte.

Wenn man alles architektonisch sauber aufsetzen wollte, müsste man ein mehrstufiges FHEM Client / Master Modell verwenden:

HMCCU >istMasterFür> HMCCURPCPROC >IstMasterFür> HMCCUDEV >IstMasterFür> HMCCUCHN

Darüber hatte ich ganz am Anfang mal nachgedacht, es dann aber aufgrund der Komplexität verworfen (eigentlich ist das FHEM Modell nur für eine (1 Ebene) Client-Master Beziehung gedacht).
Herausgekommen ist dann eben sowas:

HMCCURPCPROC <IstMasterFür< HMCCU >IstMasterFür> HMCCUCHN,HMCCUDEV

HMCCU ist der zentrale Vermittler, der alle Interfaces kennt.

Das ist aber immer noch um Längen strukturierter als die sonst üblichen, monolithischen Module in FHEM.

Für Dokumentation ist das Wiki der richtige Platz. Da gibt es auch schon einige Seiten.