Hi,
in einer von extern aufgerufenen Prozedur innerhalb eines Moduls möchte ich den $hash ermitteln.
Das kann ich ja bekanntermaßen mit $def{DeviceName} machen.
Aber wie komme ich an den Namen des Devices? Ich kann diesesen NICHT der Prozedur als Parameter mitgeben
Maximal kenne ich noch den ModulNamen, nicht aber die DeviceInstanz :(
Also irgendwas musst Du schon haben, aus nichts kann man selten was machen. Auch wenn das uns Ossis oft nachgesagt wird. Also entweder $name oder $hash oder irgendwas anderes was die Instanz einmalig bezeichnet.
Wenn es ein device ist, das es von diesem TYPE nur ein einziges Mal gibt, kannst Du mit defInfo() arbeiten.
Wenn es vom gleichen TYPE mehrere devices gibt, erscheint mir Dein Vorhaben generell wenig sinnhaftig.
schade eigentlich, dachte das irgendetwas gibt...
Hi,
wie soll denn das rein logisch gehen? Die Prozedur wird von "extern" aufgerufen und die Übergabe eines Device-Namens ist nicht möglich. Woher würdest Du dann selbst wissen, welches Device gemeint ist?
Das ist so, wie wenn man in eine Menschenmenge hineinruft "sag mir mal Deinen Namen".
Gruß,
Thorsten
konkret geht es um die X_DbLog_splitFn. Die ist in (fast) jedem Modul implementiert um die events in Reading/value/unit aufzuteilen.
Im DBLog Modul wird daher auf das Vorhandensein dieser Prozedur geprüft:
if($modules{$dtype}{DbLog_splitFn})
...
($reading,$value,$unit) =
&{$modules{$dtype}{DbLog_splitFn}}($event);
Jetzt möchte ich die Prozedur mit einem 2ten Parameter aufrufen, also das aufrufende Device mitgeben. Damit hat dann das Modul die Möglichkeit den $hash zu bilden und auf Devicespezifische Variablen zuzugreifen.
Da aber nun in den Modulen nur ein Parameter erwartet wird, wird es jetzt überall "krachen"...
Gibt es eine Möglichkeit abzufragen, wieviel Parameter die Prozedur erwartet?
Dann könnte man es ja so machen:
if($modules{$dtype}{DbLog_splitFn}) {
if (AnzahlArgs($modules{$dtype}{DbLog_splitFn} == 1) {
($reading,$value,$unit) = &{$modules{$dtype}{DbLog_splitFn}}($event);
} elseif (AnzahlArgs($modules{$dtype}{DbLog_splitFn} == 2) {
($reading,$value,$unit) = &{$modules{$dtype}{DbLog_splitFn}}($device, $event);
}
[...]
Erstens ist die Funktion noch lange nicht in fast jedem Modul enthalten (eher umgekehrt) Und zweitens ist mir immer noch nicht klar, welchen Sinn das Ganze haben soll. ???
Woher nimmst Du die Information, aus welchem Modul Du die splitFn aufrufen willst? Dafür muss es doch eine Basis geben, die normalerweise ein device ist. Ansonsten ist doch das Modul überhaupt nicht geladen und die splitFn gar nicht vorhanden.
Hat denn $event nicht sowieso den Device-Namen mit drin?
Ansonsten: So ganz kapiere ich es nicht. Die X_DbLog_splitFn, die Du aufrufen willst, gehört die zu Deinem Modul oder zu einem fremden Modul (oder mehreren fremden Modulen)? Falls ersteres, warum bastelst Du Dir dann nicht einfach eine neue Funktion, die Du dann aufrufst? Falls letzteres: ...dann hast Du keinen Einfluss auf die Funktion, es wäre also auch nicht sinnvoll, irgendwas an den Parametern zu ändern.
Ich glaube nicht, dass Perl zur Laufzeit die Anzahl der Formalparameter kennt. Ich glaube, dass das intern einfach eine Liste ist, die immer beliebig viele Einträge haben kann.
Gruß,
Thorsten
Das $event hat leider nicht den Devicenamen drin. Daz gehört nur: Reading,Value,Unit
Ich müsste dann zusätzlich auf Vorhandensein einer X_DbLog_splitFn2 prüfen...
Dachte es geht eleganter mit einer Prüfung, wieviel Argumente die Prozedur haben will
Hi,
ich kapier's immer noch nicht. Wenn Du selbst diese Funktion schreibst, dann weißt Du doch sowieso schon, ob sie da ist oder nicht. ????
Vielleicht musst Du mal ein bisschen weiter ausholen und erklären, was Du wirklich machen willst.
Gruß,
Thorsten
Ich versuch es dir mit diesen Auszügen zu erklären:
Integration von DBLog in eigene Module: http://www.fhemwiki.de/wiki/DbLog#Integration_von_DBLog_in_eigene_Module
FHEM Development ModulIntro: http://www.fhemwiki.de/wiki/DevelopmentModuleIntro#X_DbLog_splitFn
Ein Beispiel der Integration im 10_MAX.pm: https://sourceforge.net/p/fhem/code/8382/
Innerhalb von DBLog (also in meinem Modul) prüfe ich, ob das Modul des generierenden Events diese SpitFn bereitstellt. Falls ja kann sauber die Unit getrennt ins DBLog geschrieben werden. Falls nein, ist das Value im DBlog ggf mit einer Einheit versehen. Problem dann: Charts die Zahlenwerte benötigen funktionieren nicht. Deshalb ist es wichtig die Unit vom Value getrennt zu speichern
Nun gibt es aber Situationen, wo der Modulautor (zb. vom km_200.pm Modul den $hash benötigt. Diesen bekommt er nur über den Devicenamen. Also überlege ich, den DBLog_splitfn zu erweitern und den Devicenamen mit zu übergeben.
Ohne mehr Logik, müssten jetzt alle DbLog_splitfn Funktionen in den implementierten Modulen daruafhin aber angepasst werden. Ich möchte aber abwärtskompatibel bleiben...
aber die notifyFn verrät doch den device namen ?
vg
joerg
Die splitFn ist grundsätzlich modulspezifisch, nicht devicespezifisch, festgelegt.
Als Entwickler eines Moduls, das eine eigene splitFn bereitstellt, würde ich mich standhaft weigern, an dieser Tatsache irgendetwas zu verändern, was für mich völlig
unsinnig unlogisch erscheint.
Zitat von: herrmannj am 19 Juli 2016, 14:33:16
aber die notifyFn verrät doch den device namen ?
Genau. Und genau deshalb ist auch in DbLog_Parse sowohl der deviceName als auch type und der komplette event bekannt.
Warum man da nun nochmal solche Kopfstände machen möchte, ist mir völlig schleierhaft.
Wenn der Modulautor von km_200.pm damit irgendein Problem hat, soll er sich darum kümmern, sein Modul so kompatibel zu machen, dass es sich an die vorhandenen Vorgaben hält.
Hi,
was passiert denn, mal so rein theoretisch betrachtet, in Perl, wenn man einer Funktion einen Aktualparameter mehr übergibt, als sie Formalparameter hat? Eigentlich gar nichts, oder?
Gruß,
Thorsten
das kommt auf die deklaration an. man kann auch funktionieren mit optionalen parametern deklarieren und diese dann angeben oder auch nicht.
die xxxFn haben aber alle samt keinen prototypen und werden auch alle ohne strict aufgerufen. d.h. man kann beliebig viele zusätzliche parameter hinten an hängen. es liegt dann am aufgerufen diese zusätzlichen parameter auch auswerten.
das ganze ist ohne probleme rückwärts kompatibel so lange man nicht an der reihenfolge dreht.
aber: warum ein modul das die einheiten abschneiden will wissen muss aus welcher instanz das reading kommt erschliesst sich mir auch nicht.
übrigens:
module sollten si einheiten verwenden und diese nicht zusätzlich in die readings schreiben.
falls das modul pro instanz andere einheiten verwendet entspricht das nicht den fhem richtlinien, falls das modul nicht-si einheiten verwendet auch nicht. beides macht prinzipiell mit anderen frontends probleme und verhindert ein automatisches umrechnen.
für einen modul und frontend unabhängigen layer um die einheiten zu internationalisieren gibt es schon vorschläge.
gruss
andre
puuh, dachte nicht das es so kompliziert ist zu erklären...
Im VBUS-Device Modul werden gibt es pro Device eine Deklaration. zb:
"7e21" => {"name" => "DeltaSol_MX_Heizkreis", "cmd" => "0100", "fields" => [
{ "offset" => 0,"name" => "Vorlauf_Soll_Temperatur","bitSize" => 15,"factor" => 0.1,"unit" => "°C" },
{ "offset" => 2,"name" => "Betriebsstatus","bitSize" => 8},
]},
"7e31" => {"name" => "DeltaSol_MX_WMZ", "cmd" => "0100", "fields" => [
{ "offset" => 0,"name" => "Waermemenge","bitSize" => 31,"factor" => 1,"unit" => "Wh" },
{ "offset" => 8,"name" => "Waermemenge_heute","bitSize" => 31,"factor" => 1,"unit" => "Wh" },
{ "offset" => 12,"name" => "Waermemenge_Woche","bitSize" => 31,"factor" => 1,"unit" => "Wh" },
]},
Das Device wird so angelegt:
define Dev1 VBUSDEV 7e21
Damit sind in diesem Device alle Definitionen für 7e21 gültig.
In der VBUSDEV implementierten VBUSDEV_DbLogSplitFn wird nur das event übergeben. Ich weiß in der VBUSDEV_DbLogSplitFn nicht, welche Readings und Units in DIESEM (zb. 7e21) gültig und gesetzt sind.
Plan war, die Definitionen per match mit dem event abzugleichen, die passende Definition zum event zu ermittelt und die korrekte Einheit daraus zu setzen.
Aktuell mache ich es mit "suche letztes Leerzeichen, dahinter ist die Einheit". "Wenn kein Leerzeichen, dann Einheitslos"
Zitatdie xxxFn haben aber alle samt keinen prototypen und werden auch alle ohne strict aufgerufen. d.h. man kann beliebig viele zusätzliche parameter hinten an hängen. es liegt dann am aufgerufen diese zusätzlichen parameter auch auswerten.
das ganze ist ohne probleme rückwärts kompatibel so lange man nicht an der reihenfolge dreht.
Das war der entscheidene Hinweis, Danke an Andre. Damit funktioniert auch alles bei mir getestete noch...
Habe die MiniAnpassung in Revision 11823 commited