Einheitlicher Weg, um Readings direkt weiterzuverwenden

[delMar]

Hallo Zusammen,

ich denke, es ist ein praktischer Use-Case, dass man den Output eines Devices (ein Reading) gern als direkten Input für ein anderes Device verwenden würde (entweder beim Define, oder als (Teil eines) Attribut).
Falls es das schon gibt: sorry. bitte um Link zur Doku.

Falls nicht, würde ich eine mögliche, einheitliche, Lösung auf verschiedenen Ebenen sehen:

1) für den FHEM-User zur Laufzeit eines Devices
Beispiel: Ein Bild, das per IPCAM aufgenommen wurde, soll per Telegram-Bot verschickt werden.
Dafür wird der lokale Pfad des Bildes (=Reading in IPCAM) als Parameter für den Telegram-Befehl benötigt.
Derzeit sieht die einfachste Lösung so aus, dass das aktuellste Bild immer den selben Namen trägt.

Mein Vorschlag:
Im Attribut-Wert steht zB

Code: [Auswählen]

cgi-bin/api.cgi?cmd=Snap&auth=[otherDeviceName:authHash]&width=1280&height=720AttrVal würde aber [otherDeviceName:authHash] erkennen und auswerten.
Zwecks Abwärtskompatibilität könnte man auch AttrVal2 einführen, analog zu Log3.
Nur AttrVal2 nimmt dann diese Erkennung und Auswertung vor.


2) Für den FHEM-User beim Anlegen eines Devices
Anstatt einer IP für ein Device möchte man zB die MAC-Adresse angeben (Audio-Receiver, Roboter, Kameras, etc)
Warum? Weil auch jede Handy-App die entsprechenden Geräte automatisch erkennt.
Für FHEM muss ich aber eine statische IP oder einen internen DNS-Eintrag erstellen.
Eine Syntax wie [#mac:ip(ab:ab:ab:ab:ab:ab)] könnte aber aus einem "mac" device die IP Adresse zur hier angegebenen Mac-Adresse auslesen (ob das dann ARP lookup macht, oder aus einem router vorhandene infos holt, soll an dieser stelle egal sein).
Die Syntax wäre hier anders, weil nicht aus einem Reading gelesen werden soll, sondern zB am Device 'mac' get ip mit der Mac-Adresse als Parameter.
Auch hier ist der Knackpunkt wieder: der Wert wird erst beim Lesen ausgewertet. In der Define-Methode, aber auch im Fall eines disconnects beim re-connect. (die IP-Adresse kann sich ja seit dem disconnect geändert haben).


3) Was bedeuten die Fälle 1 und 2 für den Modulautor?
Natürlich kann diese Fälle auch heute schon jeder Modulautor umsetzen, manche haben das ja auch gemacht.
Halt oft unterschiedlich - sowohl in Bedienung, als auch in Performance.
Und für jeden weiteren Modulautor (ich zeige auf mich) bedeutet es wieder, entweder nach einer guten copy/paste Lösung zu suchen, oder es sich selber überlegen.

Für Fall #1 habe ich AttrVal2 schon angesprochen.

Für Fall #2 wäre eine Utility-Methode hilfreich, die der Modulautor beim Auswerten der Parameter im Define verwendet.
Anstatt direkt den Wert aus den Parametern im Define oder im Set oder Get zu verwenden, wird ein Utility angeboten. zB

Code: [Auswählen]

my $var = dynamic($param); #(das 'dynamic' ist diskutabel. mir is grad nix besseres eingefallen)


Zugegeben, das Ganze kann auch über Notify gelöst werden - mach ich tatsächlich auch.
Unschön ist, dass bei jedem Update des Readings ein Attribut-Wert verändert wird.
Was zum unschönen (weil nicht durch mich aktiv verursachten) '?' neben Save config führt.
Zum Anderen werden eigentlich unnötige Events generiert, weil eben die Information bei jedem Update geschrieben wird, gelesen wird das Attribut aber vielleicht nur 2x am Tag.
Speziell in größeren FHEM-Setups kann das schon etwas Overhead sparen.


Und - last but not least:
Wir würden hier einen regelmäßigen Use-Case durch einheitlichen Code abdecken.
Das heißt, modulspezifischer oder userspezifischer Code muss nicht geschrieben werden.
Das heißt weiter, wenn wieder mal eine Perl-Optimierung oder deprecation daherkommt, kann das hinter den Kulissen für FHEM zentral gelöst werden. Es muss kein Gedanke daran verschwendet werden, wie man das den Modulautoren pro-aktiv näher bringt.


Falls dieses Konzept für euch stimmig ist, würd ich da gern mal lostüfteln.
Oder: falls jemand die Idee soo gut findet, das er das unbedingt sofort bauen will, dann wär das natürlich auch ok ;-)

So oder so: ich freu mich auf Feedback, Input, und Gedanken dazu.

Danke
schöne Grüße
Martin

[justme1968]

1. so etwas gibt es bereits für set. siehe set magic in der commandref.

im gegensatz zu set haben attribute aber das problem das man irgendwann entscheiden muss ob das ersetzen zum zeitpunkt des attribut setzen passieren soll oder zum zeitpunkt an dem das modul das attribut auswertet. um beides zu erlauben oder um das verhalten mit dem set einheitlich zu haben braucht es für den zweiten fall eine andere syntax.

fall 1 könnte man tatsächlich generell einbauen, hat aber eventuell das problem der abwärtskompatibilität. fall 2 ist nützlicher, ich weiss nicht wie viel module es tatsächlich gibt die diesen fall brauchen, und das ganze noch nicht implementiert haben. auf der anderen seite sind es nur 2 oder drei zeilen code...

2. ich bin der meinung das es grundsätzlich falsch ist mit mac adressen zu arbeiten. genau weil end anwender damit nicht in berührung kommen sollen gibt es ip adressen und auch noch den nächsten schritt der host namen. ganz abgesehen davon das mac adressen nicht geroutet (das betrifft dann auch alle docker installationen!) werden und man sich so auch noch im support probleme schafft gehören router die keine festen ip adressen oder alternativ die namensauflösung der dynamischen adressen erlauben verboten. statt sich auf nicht praktikable workarounds wie mac adressen einzulassen sollten lieber dinge wie upnp/ssdp oder bonjour/mdns und andere zeroconf techniken unterstützt werden. mac adressen haben im user space nichts zu suchen.

3. du schreibst von regelmäßigem use-case, ist das tatsächlich so? sind das probleme die schon mehrfach aufgetreten sind und die schon mehrfach und unterschiedlich implementiert wurden?

bitte nicht falsch und als nur negativ verstehen. 1. ist meiner meinung nach zum einen nicht wirklich allgemein mit einer einzigen syntax lösbar und zum anderen ist die im modul passend implementierte version sehr sehr klein. 2. ist meiner meinung nach ein absolutes no-go.

[rudolfkoenig]

1. der Attribut-Wert koennte optional ein Perl-Expression sein, was im Modul per eval (oder AnalyzePerlCommand) ausgewertet wird.

2. Ich gehe davon aus, dass "jede Handy App" die Erkennung ueber upnp/bonjour/etc macht, und nicht ueber ein Lookup von MAC-Adresse=>Hersteller=>GeraeteTyp. Abgesehen davon weiss ich nicht, wie FHEM an die MAC-Adresse kommen soll, es sei denn, wir sniffen am Interface. Habe ich was uebersehen?

[delMar]

Danke für die raschen Antworten.
Ich gehe nicht auf jeden einzelnen Punkt ein, um den Umfang etwas im Zaum zu halten.

siehe set magic in der commandref.

Ja, genau so. Danke. Das würd ich mir als User für die genannten Fälle wünschen.

der Attribut-Wert koennte optional ein Perl-Expression sein, was im Modul per eval (oder AnalyzePerlCommand) ausgewertet wird.

Auch EvalSpecials scheint stark in diese Richtung zu gehen.
In meinem Fall wäre die Lookup-Table halt kein Hash, sondern irgendwas mit $devspec und so...
Ich werd mir das genauer zu Gemüte führen. Danke

mac adressen haben im user space nichts zu suchen.

Wie definierst du denn dann eine fixe IP? Farbe im DHCP-Server eintragen funktioniert nicht. Das muss schon die MAC sein.
Und die Stärke einer Platform wie FHEM liegt eben darin, dass der Benutzer Dinge machen kann, an die der Entwickler nicht gedacht hat.
Wenn es mir erlaubt, für 20 Devices im DHCP-Server keine fixe IP einzutragen, weil ich in FHEM direkt die MAC Adresse angeben kann, dann find ich das spitze.
Und FHEM ist wirklich der einzige Grund, warum diese Geräte eine fixe IP haben.

ob das ersetzen zum zeitpunkt des attribut setzen passieren soll oder zum zeitpunkt an dem das modul das attribut auswertet

Eindeutig beim Lesen. Exklusiv. Um unnütze Events zu vermeiden. Beim Schreiben gehts ja jetzt über Notify auch schon.

du schreibst von regelmäßigem use-case, ist das tatsächlich so? sind das probleme die schon mehrfach aufgetreten sind und die schon mehrfach und unterschiedlich implementiert wurden?

Potentiell jedes einzelne Mal, wenn jemand mit curly braces arbeiten muss, um direkt AttrVal oder ReadingsVal aufzurufen.
Ich würd das gern wie bei der set magic als Standard-Feature in FHEM haben, als Modulautor, ohne auf "echten" Code ausweichen zu müssen.

Anderes Beispiel, vielleicht besser als das mit der MAC-Adresse: ein Utility für mathematische Funktionen.

Ich habe zwei Außentemperaturfühler. Einer im Norden, einer im Süden.
Ich ermittle aus beiden den Mittelwert und zeige diesen am FHEM-Display im Wohnzimmer an.
Sieht jetzt so aus:

Code: [Auswählen]

defmod nfyTempOutsideAvg notify heatpump:Temp-Aussen|HM_Temp_Outdoor:temperature {fhem('set dumTempOutside '.sprintf('%.f', (ReadingsVal('heatpump','Temp-Aussen',0) + ReadingsVal('HM_Temp_Outdoor','temperature',0))/2))}
Man muss das komplette set Kommando in curly braces setzen, damit das funktioniert. Ich habe einige Mehrzeiler dieser Natur bei mir in FHEM.

Ich würde das lieber schreiben als

Code: [Auswählen]

defmod nfyTempOutsideAvg notify heatpump:Temp-Aussen|HM_Temp_Outdoor:temperature set dumTempOutside [math:avg([heatpump:Temp-Aussen], [HM_Temp_Outdoor:temperature], 1)]
math wäre wohl wie ein Hilfsmodul oder ein Befehl implementiert, dass Durchschnitt, Summe, etc aus den übergebenen Werten (und in [] auch Readings) berechnen kann. Als letzten Parameter gibt man noch die gewünschte Zahl an Nachkommastellen an.
Im Unterschied zu Hilfsmodulen oder Befehlen wird es aber über die [] Syntax aufgerufen.

Mir ist bewusst, dass Code {...} als letzter Ausweg immer alles lösen kann. Mach ich ja auch seit 10 Jahren so. Und ich hab auch kein Problem mit Perl. Es ist das Werkzeug der Wahl. Fertig.
Aber selbst nach 10 Jahren, kosten mich und solche Fälle wie der Außentemperaturfühler immer Nerven und Google, bis ich die Syntax endlich richtig hinkriege.

Die Jahre haben mir auch gezeigt, dass die in Code selber gestrickten Teile jene sind, die im Lauf der Zeit zu Inflexibilität in meinem Gesamtsystem führen.
Weil sie am Grundgerüst "vorbeiprogrammiert" werden müssen.
Aber in Wahrheit nehmen sie auch FHEM als Basis viel an Flexibilität, weil alle Freiheiten, die ein User hat, die Bewegungsfreiheit der Entwickler für künftige Änderungen einschränkt.

Und deshalb finde ich ein

Code: [Auswählen]

[math:avg([heatpump:Temp-Aussen], [HM_Temp_Outdoor:temperature], 1)] besser, als die 99_Utility Methode:

Code: [Auswählen]

{math::avg(ReadingsVal('heatpump','Temp-Aussen'),ReadingsVal(' HM_Temp_Outdoor','temperature'), 1)}
was mich schlussendlich von der Sinnhaftigkeit meines Vorschlags überzeugt 

Deklarativ ist weniger flexibel, erlaubt aber bessere Kontrolle.

Danke fürs zuhören

schöne Grüße
Martin

[rudolfkoenig]

Und deshalb finde ich ein [math:avg([heatpump:Temp-Aussen], [HM_Temp_Outdoor:temperature], 1)] besser, als die 99_Utility Methode:

Wenn Du auf diese Schreibweise stehst, dann ist womoeglich DOIF was fuer dich, obwohl da mw. auch noch nicht mit math:avg angefangen wurde.
Ich halte das fuer den falschen Weg, weil man parallel zu perl eine weitere Sprache implementiert, was entweder elegant oder vollstaendig ist. Dokumentation und Bibliotheken fuer "alles Moegliche" sind nicht zu unterschaetzen. Die Wiederverwendbarkeit der erlernten Sprache ist marginal.

[delMar]

Guten Morgen.
Wir nähern uns dem Kern der Sache 

Wenn Du auf diese Schreibweise stehst, dann ist womoeglich DOIF was fuer dich, obwohl da mw. auch noch nicht mit math:avg angefangen wurde.

Genau, aus DOIF kenn ich das. Verwende ich (natürlich) auch.
Es geht mir garnicht so sehr um die Schreibweise.
Sondern darum, dass User einen Grund weniger haben, auf tatsächlichen Code zurückgreifen zu müssen.

Ich halte das fuer den falschen Weg, weil man parallel zu perl eine weitere Sprache implementiert, was entweder elegant oder vollstaendig ist.

In dem Satz fehlt wohl ein "nicht", aber vielleicht ist es auch ein Freud'scher Versprecher deinerseits und du weißt bloß noch nicht, dass du es wirklich elegant findest 
Ich seh das nicht als eine weitere Sprache.
Sondern man würde die bereits etablierte Syntax aus 'set magic', DOIF und einigen weiteren Modulen bloß an weiteren Stellen Einsetzbar machen.
Und diese Syntax auch zum Aufrufen von Utility-Methoden verwenden können.

Dokumentation und Bibliotheken fuer "alles Moegliche" sind nicht zu unterschaetzen.

Ich denk, dieser Aufwand wäre vergleichbar zu dem von Modulen. Wer eine Utility Methode schreibt und ins SVN geben will, muss diese dokumentieren.
Und es ist ja auch erlaubt, in FHEM eigene Befehle zu implementieren, was ich ebenfalls in der selben Liga sehe, und auch kein Problem zu sein scheint.

Die Wiederverwendbarkeit der erlernten Sprache ist marginal.

Das als "Sprache" zu bezeichnen verunsichert mich etwas.
Es geht doch nur darum, zu erlauben, dass Methodenaufrufe in eckige Klammern gesetzt werden, ohne über {} "echtes" Coding machen zu müssen.
Davon abgesehen: der Einsatzzweck ist FHEM. Wiederverwendbarkeit ist kein Kriterium.


Ergänzung:
Mach hier einen Tippfehler, und FHEM stirbt im schlimmsten Fall an "undefined subroutine"

Code: [Auswählen]

{math::avg(ReadingsVal('heatpump','Temp-Aussen'),ReadingsVal(' HM_Temp_Outdoor','temperature'), 1)}
Ich muss dann die Shell öffnen und FHEM manuell neu starten. Shutdown restart im UI geht dann nicht mehr.

Ein Tippfehler hier:

Code: [Auswählen]

[math:avg([heatpump:Temp-Aussen], [HM_Temp_Outdoor:temperature], 1)]
führt zu einer Fehlermeldung im Log.

[rudolfkoenig]

Es geht doch nur darum, zu erlauben, dass Methodenaufrufe in eckige Klammern gesetzt werden, ohne über {} "echtes" Coding machen zu müssen.

Als naechstes will man es aber auslagern, weil es doch zu maechtig geworden ist, und mehrfach verwendet werden koennte. Und eine Schleife und Variablen waeren auch praktisch. Wo ziehst du die Grenze? Vmtl bei "elegant aber nicht vollstaendig". Und muss staendig die Leute abwimmeln, die nur "das bisschen mehr" wollen. Aber wie gesagt, das ist meine Meinung, und jeder darf gerne seinen eigenen Weg gehen.

Mach hier einen Tippfehler, und FHEM stirbt im schlimmsten Fall an "undefined subroutine"

Normalerweise nicht, das wird per eval abgefangen.

[delMar]

Als naechstes will man es aber auslagern, weil es doch zu maechtig geworden ist, und mehrfach verwendet werden koennte. Und eine Schleife und Variablen waeren auch praktisch.

Nö. Weil es keine Sprache ist. Sondern nur die Möglichkeit, einen Methodenaufruf in eckige Klammern zu packen.

Wo kämen wir hin,
wenn alle sagten,
wo kämen wir hin,
und niemand ginge,
um einmal zu schauen,
wohin man käme,
wenn man ginge.

Sorry, der musste sein.

Wo ziehst du die Grenze?

Wo wurde denn bei set magic die Grenze gezogen?

Und muss staendig die Leute abwimmeln, die nur "das bisschen mehr" wollen.

Das ist natürlich schade. Ich meine aber, hier einen sinnvollen Scope und Anwendungsfall zu haben.

jeder darf gerne seinen eigenen Weg gehen.

Für Module und Befehle ist das ja machbar.
Dieser Vorschlag hier ist halt etwas, was wohl in die FHEM-Basis rein müsste und wohl sogar einen neuen Featurelevel nach sich ziehen würde.

Normalerweise nicht, das wird per eval abgefangen.

Ok, stimmt.

[justme1968]

Nö. Weil es keine Sprache ist. Sondern nur die Möglichkeit, einen Methodenaufruf in eckige Klammern zu packen.

doch. natürlich ist es eine sprache. es ist die sprache auf fhem ebene. und ein problem hier ist das weder ein echter parser noch eine wirklich fest definierte syntax verwendet wird. das macht zum einen erweiterungen extrem schwierig und zum anderen ist es unmöglich das ganze auf kompatibilität zu prüfen.

Wo kämen wir hin,
wenn alle sagten,
wo kämen wir hin,
und niemand ginge,
um einmal zu schauen,
wohin man käme,
wenn man ginge.

einfach los rennen ohne zumindest mal nachgedacht zu haben ob die richtung stimmt ist genau so doof.

vielleicht kommen wir aber weiter wenn wir versuchen die zwei oder drei dinge die in deinem vorschlag vermischt sind zu trennen.

was wäre wenn man statt zu versuchen eine neue syntax auszudenken sich besser daran macht die beschränkungen die es aktuell beim mischen von fhem und perl syntax gibt zu beheben. d.h. wenn man es ermöglicht fhem und perl auf einer gleichen zeile zu erlauben. also etwas wie defmod xyz name {test("abc", [d1:r1])}. dein beispiel von oben würde dann so aussehen:

Code: [Auswählen]

defmod nfyTempOutsideAvg notify heatpump:Temp-Aussen|HM_Temp_Outdoor:temperature set dumTempOutside {([heatpump:Temp-Aussen] + [HM_Temp_Outdoor:temperature])/2}
ich weiss aber noch nicht ob es eindeutig möglich ist die setmagic syntax innerhalb von perl zu entdecken und zu verwenden.

[delMar]

vielleicht kommen wir aber weiter wenn wir versuchen die zwei oder drei dinge die in deinem vorschlag vermischt sind zu trennen.

Danke, du bringst hier viel Klarheit rein.

d.h. wenn man es ermöglicht fhem und perl auf einer gleichen zeile zu erlauben. also etwas wie defmod xyz name {test("abc", [d1:r1])}. dein beispiel von oben würde dann so aussehen:

Code: [Auswählen]

defmod nfyTempOutsideAvg notify heatpump:Temp-Aussen|HM_Temp_Outdoor:temperature set dumTempOutside {([heatpump:Temp-Aussen] + [HM_Temp_Outdoor:temperature])/2}

Ja, das wäre viel besser.
Man muss nicht mehr den gesamten Kommando-Block als Perl formulieren. Und der fhem() Aufruf fällt weg.

was wäre wenn man statt zu versuchen eine neue syntax auszudenken

Ist das wirklich so?
Eckige Klammern sind doch in FHEM ein gewachsener Standard, nicht?

ich weiss aber noch nicht ob es eindeutig möglich ist die setmagic syntax innerhalb von perl zu entdecken und zu verwenden.

Vielleicht ein gutes Argument, doch keine Perl-Syntax zu verwenden.
Wenn ich Perl-Syntax verwende, hab ich das Gefühl, an eine Grenze in FHEM zu stoßen, für die es keine deklarative Lösung gibt.

P.S.

einfach los rennen ohne zumindest mal nachgedacht zu haben ob die richtung stimmt ist genau so doof.

Rennst du schon? Ich sitz hier noch und schreibe. 

[justme1968]

Vielleicht ein gutes Argument, doch keine Perl-Syntax zu verwenden.

ich denke wir sollten es auf jeden fall probieren. das wäre die flexibelste lösung die auch alle möglichen anderen anwendungsfälle unterstützen würde. und das ohne eine neue sprache zu erfinden.

[delMar]

fhem und perl auf einer gleichen zeile zu erlauben, das wäre auf jeden Fall schon mal eine riesen Verbesserung.

Danke, wenn du dir die Zeit dafür nehmen willst.

Nur so als Referenz:
Ich bin auch darüber gestolpert https://forum.fhem.de/index.php/topic,38276.0.html
Bestimmt erinnert ihr euch daran.

[delMar]

Ich versuche grade, hier erste Schritte zu machen.
Die Posts sind schon etwas umfangreicher hier, deshalb mal für mich, um ins Thema zu kommen.

Im IPCAM Modul möchte ich variable Teile für die URL zur Kamera verwenden können.

Wie ganz am Anfang schon mal erwähnt, würde im path-Attribut zB stehen:

Code: [Auswählen]

cgi-bin/api.cgi?cmd=Snap&auth=[otherDeviceName:authHash]&width=1280&height=720otherDeviceName:authHash wäre eben ein Wert, der im anderen Device zB alle zwei Stunden neu berechnet wird.

In IPCAM will ich nun diesen Wert dann auswerten, wenn get image aufgerufen wird.
Dh zur Laufzeit von get image wird aus dem Attribut gelesen und dann darin [otherDeviceName:authHash] gefunden und durch 8e805c91699c6ddd39838c2683807b2b ersetzt, das Attribut selber bleibt aber unverändert.
Falls kein device:reading gefunden wird, bleibt der String unverändert.

Kann ich dafür zB main::ReplaceSetMagic verwenden?
Wie würde der Aufruf aussehen?
Ich hab damit experimentiert, bin aber zu keinem Ergebnis gekommen.

Oder wäre eine andere Methode besser dafür? Notify wertet das Pattern [:] ja zB auch aus.
Ich bin leider nicht fit genug im Lesen vom Code, um hier die richtige Stelle zu finden, wo diese Ersetzung vorgenommen wird.

De facto würd ich gern eine vorhandene Methode aufrufen, oder zumindest die richtige Regex zum Rauskopieren finden 

Danke!


Update: fündig geworden. Danke an Loredo und TelegramBot.
Für alle anderen suchenden:

Code: [Auswählen]

my %dummy;
my ($err, @a) = ReplaceSetMagic(\%dummy, 0, ( $callbackCommand ) );
if ( $err ) {
  Log3 $name, 0, "parse cmd failed on ReplaceSetmagic with :$err: on  :$callbackCommand:";
} else {
  $callbackCommand = join(" ", @a);
}
Die Gründe für dummy und 0 als Parameter sind mir unklar, an dieser Stelle aber auch egal 

[rudolfkoenig]

Die Gründe für dummy und 0 als Parameter sind mir unklar[...]

Sowas kann man in fhem.pl nachschauen:
- $hash wird beim Evaluieren von {(...)} verwendet, um $DEV zu ersetzen, und die Authorisierung zu parametrisieren
- 0 besagt, ob bzw. in wie viele Teile das Ergebnis gesplittet werden soll. setreading haette gerne 3 Strings als Rueckgabewert, set will es aber nicht geteilt haben, stateFormat auch nicht.

[delMar]

Danke für die Erläuterung.
Wenns keine Einsprüche gibt, würde ich https://wiki.fhem.de/wiki/DevelopmentModuleAPI im Wiki um einen Eintrag zu ReplaceSetMagic ergänzen.

Sowas kann man in fhem.pl nachschauen:

Das stimmt, das mach ich auch. Oft sehe ich den Wald aber vor lauter Bäumen nicht.


Wenn diese kleine Anekdote hier erlaubt ist: im Zuge meiner "Ermittlungen" bin ich im letztens verlinkten Thread auf folgendes gestoßen (seht es mir nach, wenn das Thema an anderer Stelle bereits zu Ende diskutiert wurde):

OK, Ich habe mal angefangen: http://www.fhemwiki.de/wiki/DevelopmentModuleAPI

Deine Bemühungen in allen Ehren, aber ich halte das Vorhaben nach wie vor für sinnlos.

Also wenn es das Wiki mit Themen wie der DevelopmentModuleAPI nicht gäbe, hätte ich nie im Leben jemals ein Modul zustande gebracht.
Ich denke, es ist ein Gewinn für die Community, wenn Kern-Funktionen, die bereits stabil in Modulen genutzt werden, auch (gut) dokumentiert sind.
FHEM hat wohl eine Größe erreicht, wo es nicht mehr die Dokumentation ist, die Stabilität im Code verlangt und somit (gefühlt) Flexibilität wegnimmt.
Sondern die Vielzahl an Modulen, die diese Funktionen bereits verwenden.