Wie mit neuen Abhängigkeiten in bestehendem Modul umgehen?

[Thorsten Pferdekaemper]

Hi,
ich bin heute darauf Aufmerksam gemacht worden, dass die neue Version meines HM485-Moduls von den Perl Module XML::Simple und XML::SAX oder XML::Parser abhängt. Außerdem sieht es so aus, dass diese Module bei einer FHEM Installation nicht zwangsläufig vorhanden sind. Das ist jetzt natürlich ein bisschen blöd, weil dadurch ein "update" zu Problemen führt. Kann ich dagegen etwas tun?

(Details auch hier: https://forum.fhem.de/index.php/topic,70528.msg628922.html#msg628922)

Gruß,
    Thorsten

[Markus M.]

Zum Beispiel, in dem du im Modul selbst die Abhängigkeiten überprüfst und das einigermassen sauber abfängst, ohne dass das Modul nicht geladen wird und den Nutzern die komplette Config zerschiesst.

Code Auswählen Erweitern

  my $req = eval
  {
    require Crypt::CBC;
    Crypt::CBC->import();
    require Digest::MD5;
    Digest::MD5->import();
    1;
  };
  if(!$req)
  {
    $hash->{STATE} = "Crypt::CBC and Digest::MD5 are required!";
    $attr{$name}{disable} = "1";
    return undef;
  }


[Thorsten Pferdekaemper]

Hi,
ok, das hilft schon einmal gegen reflexhaftes "Save config" drücken. Allerdings muss man ja schon ziemlich schusselig sein, wenn es nach einem Update Fehlermeldungen hagelt und Devices fehlen und man dann erst einmal "Save config" drückt. (Oder verstehe ich da was falsch?)
...und außerdem funktioniert die ganze Sache dann nach dem update trotzdem nicht.
Ich hatte eher an etwas gedacht wie das update zu verhindern, wenn bestimmte Bedingungen nicht gegeben sind. Das geht aber wahrscheinlich nicht.
Gruß,
    Thorsten

[rudolfkoenig]

Nach einem eval frage ich lieber $@ ab, ob es gesetzt ist. Falls ja, dann liefere ich das zurueck bzw. protokolliere es im Log. Im vorherigen Beispiel wuesste damit der Benutzer, welche der beiden Module das Problem verursacht.

[Thorsten Pferdekaemper]

Nach einem eval frage ich lieber $@ ab, ob es gesetzt ist. Falls ja, dann liefere ich das zurueck bzw. protokolliere es im Log. Im vorherigen Beispiel wuesste damit der Benutzer, welche der beiden Module das Problem verursacht.

Das weiß der Benutzer sowieso schon, wenn er ins Log schaut. Da steht explizit "you may need to install the XML::Simple module".
Ich suche nach einer Möglichkeit, das Problem gar nicht erst auftreten zu lassen.
Gruß,
   Thorsten

[Markus Bloch]

Das kannst Du nicht direkt. Man kann entweder wie Rudi gesagt hat das Laden eines Moduls per eval testen. Wenn es nicht geladen werden kann, wird $@ mit der Fehlermeldung gesetzt.

Eine automatische Nachinstallation per cpan ist nicht möglich.

Alternativ versuchen das FHEM-Modul ohne  die Modulabhängigkeit implementieren. Das ist aber nicht immer so ohne weiteres möglich.

Ich würde an Deiner Stelle ebenfalls das Modul per eval in der DefineFn laden. Sollte das Modul nicht zur Verfügung stehen gibt die DefineFn eine entsprechende Fehlermeldung zurück. Die wird beim Start im Logfile protokolliert bzw. bei manueller Eingabe.

Gruß
Markus

[igami]

könnte man das Modul nicht einfach dann auf diabled setzen und den Fehler in den state schreiben oder so?

[Thorsten Pferdekaemper]

Hi,
danke für die Vorschläge, aber das hilft ja wie gesagt nicht wirklich. Das Ergebnis ist fast dasselbe wie nichts tun: Nach dem Update funktioniert nichts mehr. Ob noch eine schönere Meldung ausgegeben wird und ob jetzt die Geräte nicht mehr vorhanden sind oder ein bestimmtes Attribut gesetzt wird, halte ich für marginal.
Meiner Meinung nach ist es etwas unschön, dass man ein update nicht stoppen kann, wenn man schon vorher genau weiß, dass es zu Problemen führen wird. Das Update wird ja auch zurückgerollt, wenn etwas mit einer Datei nicht stimmt.
Wenn ich mit apt ein Paket installieren will, für das die Abhängigkeiten nicht gegeben sind, dann geht das ja auch nicht ohne weiteres.
Vielleicht könnten wir da mal was machen.
Gruß,
    Thorsten

[Markus Bloch]

Hi Thorsten,

Das ist generell eine gute Idee, gestaltet sich aber in der Praxis als äußerst schwierig. Gerade bei Perl-Modulen, welche kompiliert werden müssen, muss sichergestellt werden, das alle benötigten Tools (Compiler, Make, ...), sowie alle Header-Files der entsprechenden Libaries vorhanden sind. Hier ist leider der User in der Pflicht sich drum zu kümmern.

Es gibt in FHEM die Möglichkeit reine Perl-Module welche nicht kompiliert werden müssen, via Update mitzuliefern. Einige Module gibt es in kompilierte Form zwecks Performance (ich glaube die Module mit dem Zusatz "XS", bin mir da gerade nicht ganz sicher), als auch in reinem Perl-Code. Hier kann man gezielt auf kompilierte Abhängigkeiten verzichten. Solche Module könnte man dann via update mit ausliefern, sofern Rudi dem zustimmt. Dafür gibt es den Ordner FHEM/lib

Viele Grüße

Markus

[chris1284]

ich sags mal einfach ohne zu wissen ob technisch möglich: man müsste die fhem updatefunktion erweitrern das sie abhängigkeiten aus den modulen ließt (zb use Date::Parse;) und vor dem herunterladen versucht das perl module zu laden/ schauen ob es vorhanden ist. wenn das nicht geht, wird das update des modules nicht geladen und ein meldung ausgegeben (und natürlich das update wieter durchgeführt).

perl-module zu installieren ist dann wieder usersache und das aktuelle modul wird solange nicht geladen bis die abhänhigkeiten erfüllt sind.

[rudolfkoenig]

Vorschlag: Falls waehrend der Initialisierung ein Modul nicht geladen werden kann, dann wird die Definition einem "Platzhalter" Modul zugewiesen, und damit sichergestellt, dass die Daten aus fhem.cfg nicht verloren gehen. Falls jemand damit ein Problem sieht, bitte melden.

@chris1284: Um es richtig zu machen, muesste update den Modulcode ausfuehren, was etliche Nebeneffekte haben kann, unter anderem, dass update nie fertig wird (siehe Halteproblem). Eine vereinfachte Variante (Code nicht ausfuehren, nur nach use und require in bereits verwendeten Modulen suchen) hilft nicht: Das FHEM ZWave Modul unterstuetzt optional Verschluesselung, wenn man Crypt::Ryjndael installiert hat. Viele haben das nicht installiert, brauchen es aber auch nicht.

[Thorsten Pferdekaemper]

Das ist generell eine gute Idee, gestaltet sich aber in der Praxis als äußerst schwierig.

Ich hatte mir so etwas wie einen Pre-Update-Hook vorgestellt. D.h. ein Verzeichnis, in das Modulautoren eine Datei mit einer Prüfroutine ausliefern können. Nur wenn alle Prüfungen erfolgreich durchlaufen werden, wird das Update beendet, ansonsten zurückgerollt. (So wie momentan auch bei der Prüfung der Dateigröße.)
Sooo schwierig scheint mir das nicht.   

Es gibt in FHEM die Möglichkeit reine Perl-Module welche nicht kompiliert werden müssen, via Update mitzuliefern.

Ich fände es etwas hässlich, XML::Simple und ähnliches mit FHEM selbst auszuliefern.

ich sags mal einfach ohne zu wissen ob technisch möglich: man müsste die fhem updatefunktion erweitrern das sie abhängigkeiten aus den modulen ließt (zb use Date::Parse;)

Meiner Meinung nach bringt's das nicht, da ja nicht alle Module gleich gar nicht funktionieren, wenn eine Abhängigkeit fehlt. Außerdem würde mein Modul dann wahrscheinlich gar nicht mehr gehen, da manche Abhängigkeiten erst bei der Initialisierung generiert werden.
Ich denke, nur das Modul selbst kann wissen, was es wirklich braucht.

(und natürlich das update wieter durchgeführt).

Nein, genau das nicht. Dadurch wírd entweder das problematische Modul deaktiviert (was ja genau mein Problem ist) oder es wird eine alte Version in einem neuen FHEM verwendet. Das würde auch Probleme machen.

perl-module zu installieren ist dann wieder usersache und das aktuelle modul wird solange nicht geladen bis die abhänhigkeiten erfüllt sind.

Wie gesagt, genau das ist ja das Problem, was ich vermeiden will.

Vorschlag: Falls waehrend der Initialisierung ein Modul nicht geladen werden kann, dann wird die Definition einem "Platzhalter" Modul zugewiesen, und damit sichergestellt, dass die Daten aus fhem.cfg nicht verloren gehen. Falls jemand damit ein Problem sieht, bitte melden.

Ich sehe damit kein Problem, aber es würde für mich keinen Unterschied machen. Es nützt nur etwas gegen das reflexhafte "Save config", aber nach dem Update funktioniert trotzdem nichts mehr.
Also bitte das nicht für mich einbauen, ich brauche es nicht.

Ich werde es jetzt wahrscheinlich so machen, dass ich das ganze einfach mal in "meine" Standardauslieferung schiebe, vorher aber Warnungen im Forum ausgebe. Bei den meisten dürfte XML::Simple sowieso installiert sein und der Rest klickt hoffentlich nicht gleich auf "Save config" oder hat ein Backup.

Gruß,
   Thorsten

[rudolfkoenig]

Ich sehe damit kein Problem, aber es würde für mich keinen Unterschied machen. Es nützt nur etwas gegen das reflexhafte "Save config", aber nach dem Update funktioniert trotzdem nichts mehr.

Ok, dann nicht. Btw. update legt automatisch eine Kopie von fhem.cfg im jeweiligen restore Unterverzeichnis an.

[CoolTux]

Ok, dann nicht. Btw. update legt automatisch eine Kopie von fhem.cfg im jeweiligen restore Unterverzeichnis an.

Das wäre gerade meine Idee gewesen, einfach eine Kopie der cfg machen.
Problem!!! Die Experten mit ihren include cfg's. Aber meine Meinung dazu kennt Ihr ja.



Grüße

[Thorsten Pferdekaemper]

Ok, dann nicht. Btw. update legt automatisch eine Kopie von fhem.cfg im jeweiligen restore Unterverzeichnis an.

Das ist auf jeden Fall beruhigend.

Das wäre gerade meine Idee gewesen, einfach eine Kopie der cfg machen.
Problem!!! Die Experten mit ihren include cfg's. Aber meine Meinung dazu kennt Ihr ja.

Ich denke, dass ich damit leben kann. Das macht im Endeffekt echte Probleme relativ unwahrscheinlich, da folgendes zusammenkommen muss:

• Upgrade (d.h.) Verwendung von HM485 (HM-Wired)
• XML::Simple nicht installiert
• "Save config" gedrückt trotz Problemen
• fhem.cfg-Editierer

Ich glaube, dass ich wagen kann, das auf die Verwender loszulassen.

Danke&Gruß,
    Thorsten

[Benni]

Damit es nicht untergeht....


... hier gibt es noch eine Paralleldiskussion: https://forum.fhem.de/index.php/topic,71471.msg629763.html#msg629763

[Thorsten Pferdekaemper]

Ok, ich habe da auch mal meinen Senf dazugegeben.
Gruß,
   Thorsten

[Reinerlein]

Hallo,

könnte man nicht, analog zur integrierten Dokumentation, einen Bereich im Quelltext markieren, indem sich eine "Pre-Check-Funktion" befindet, die bei vorhandensein einfach per eval ausgeführt wird, und deren Ergebnis über die weitere Vorgehensweise von Update entscheidet?
Wenn da ein "false" (o.ä. wie "0") zurückkommt, wird das Update abgebrochen und zurückgerollt. Eine entsprechende Logausgabe sollte diese Funktion vor der Rückgabe an den Aufrufer (also update) selber wegschreiben...

Diese Funktion könnte auch vom Modul-Initialisierungsprozess verwendet werden, und vor dem Einrichten eines Devices damit Abhängigkeiten prüfen lassen. Das bleibt ja identisch.

Damit könnten alle Module, die das so implementieren, ohne Fehler gestartet werden, da fehlende Module (und andere Vorbedingungen) bereits in dieser Pre-Check-Funktion überprüft worden sind (sofern sauber vom Entwickler gemacht )

Code z.B.

Code Auswählen Erweitern


=pod
.
.
=begin precheckfunction
..Code zum Prüfen der Bedingungen und entsprechender Logausgabe und Rückgabe von 0 im Fehlerfall..
return 1;
=end precheckfunction
.
.
=cut


Oder gibt es Dinge, die man nicht in einen solchen Bereich schreiben darf? Da kenne ich mich zu wenig mit aus...

Grüße
Reinerlein

[rudolfkoenig]

 Diese Loesung gefaellt mir nicht: Damit wuerde ich (der aktuell HM485 nicht nutzt), bei jedem update unsanft daran erinnert, dass ich kein XML::Simple installiert habe. Und wenn die alte HM485-Doku den Rest vom commandref kaputtmacht, dann wird das in meiner Installation erst dann gefixt, wenn ich XML::Simple installiert habe.

[igami]

Also brauchen wir ein CPAN Modul welches beim define die benötigten Module nachinstalliert und neue Routinen für Entwickler mitbringt um in bestehenden Modulen darauf zu prüfen 

Es gibt sogar ein Perl Modul für CPAN
https://metacpan.org/pod/distribution/CPAN/scripts/cpan

[Reinerlein]

Hi Rudi,

wieso?
Natürlich muss eine Prüfung rein, dass das beim Update nur bei bereits geladenen Modulen geprüft wird.
Ich dachte so etwas gäbe es sowieso schon, oder kommt die Meldung mit dem notwendigen Neustart am Ende immer? Ich dachte die käme nur, wenn ein Modul geupdatet wurde, welches aktuell geladen und damit verwendet wird...

Grüße
Reiner

[Reinerlein]

Hi igami,

das wäre eher blöd, da man ja nicht immer unter allen Umständen ein Modul verwenden möchte. Ich mache das oft daran fest, was ich noch alles nachinstallieren müsste, und ob ich das dann überhaupt noch will...
u.U. gibt es ja auch Konflikte mit bestehenden Perl-Modulen usw.

Dieser Pre-Check gäbe mir genau diese Möglichkeit an die Hand...

Grüße
Reiner

[zap]

Wenn man so einen Precheck einführt, müsste auf jeden Fall auch die Version des CPAN Moduls mit rein. Auch mit verschiedenen Versionen gibt es immer wieder Überraschungen.

Allerdings ist der Precheck zumindest für mich kein Must-Have. Ich lebe schon seit (vielen) Jahren mit solchen Abhängigkeiten. In Perl sind es die Module, in C irgendwelche Shared Libraries, in Windows DLLs.

Nicht umsonst gibt es v.a. unter UNIX die "dependency hell". 😉

[Reinerlein]

Hi zap,

das stimmt wohl, und müsste von den Authoren der Module sinnvoll geprüft werden (was vermutlich nicht in allen Fällen sauber geht, aber dann startet das Device wenigstens erstmal, und macht vielleicht nicht mehr ganz das was es soll).
Hier geht es aber in erster Linie um eine nachträgliche, zusätzliche Abhängigkeit, die plötzlich nach einem Update zu einem Nicht-Funktionieren der Haussteuerung führen würde, bzw. die Konfiguration nachhaltig verändert...

Meiner Meinung nach darf bei einer Haussteuerung, die stets stabil lauffähig sein muss, niemals ein Update durchgeführt werden, dass zu einer (Teil-)Nichtfunktion der Steuerung führt, wenn es verhinderbar gewesen wäre. Solche neuen Abhängigkeiten können immer wieder vorkommen, es soll ja schließlich auch weitergehen mit den Modulen, und sollte dementsprechend abgefangen werden...

Ich beschäftige mich gerne mit meiner Steuerung, brauche aber auch eine gewisse Stabilität, da ich manchmal auch "aus Versehen" ein Update mache, und dann nicht stundenlang auf Fehlersuche gehen möchte.
Mich hat z.B. auch die "Zwangsaktivierung" des CSRFTokens massiv gestört. Das ging für mich schon in den Bereich der Bevormundung, da nach dem Update erstmal einiges nicht funktionierte. So etwas sollte man, und kann man auch recht einfach, anders einführen...

Was spricht denn nun wirklich gegen eine Vorabprüfung auf Modulfreiwilliger Basis von verwendeten/aktiven Modulen während des Update-Prozesses, mit der Möglichkeit dadurch das Update zurückzurollen/zu verhindern?
Ist es der Aufwand? Der hält sich bei meinem Vorschlag doch noch in Grenzen. Da sind ja wieder in Teilen die Modulauthoren gefragt, die den Part pflegen müssen...
Soweit ich weiß, kann das Update doch bereits ein "Rollback" durchführen, wenn eine Datei nicht geladen werden konnte. Also wäre die Hauptaufgabe nach dem Herunterladen eines Moduls dessen Precheck zu extrahieren (z.B.

Code Auswählen Erweitern

/=pod.*?=begin precheckfunction[\r\n]+(.*?)=end precheckfunction.*?=cut/is sicherlich noch ausbaufähig ) und per eval auszuwerten, und je nach Ergebnis weiterzumachen oder ein "Rollback" durchzuführen...
Oder übersehe ich da etwas?

Grüße
Reinerlein

[Thorsten Pferdekaemper]

Hi,
da habe ich anscheinend eine ganz schöne Diskussion losgetreten.

Diese Loesung gefaellt mir nicht: Damit wuerde ich (der aktuell HM485 nicht nutzt), bei jedem update unsanft daran erinnert, dass ich kein XML::Simple installiert habe. Und wenn die alte HM485-Doku den Rest vom commandref kaputtmacht, dann wird das in meiner Installation erst dann gefixt, wenn ich XML::Simple installiert habe.

Mit HM485 würde Dir das zwar wahrscheinlich nicht passieren, da man das mit "update add" erst einmal hinzufügen muss. ...und wenn man das getan hat, dann verwendet man es wahrscheinlich auch.
Prinzipiell gebe ich Dir aber Recht.
Das ganze in die Doku zu packen halte ich auch für keine so gute Idee. Wenn man so etwas machen will, dann wäre es meiner Meinung nach besser, dafür ein neues Verzeichnis anzulegen (z.B. updateCheck), in dem Dateien liegen, die denselben Namen wie die zugehörige Moduldatei hat. (Also bei mir z.B. updateCheck/00_HM485_LAN.pm.) Diese Datei hat dann eine sub (oder wird halt einfach komplett ausgeführt), die entweder undef oder eine Fehlermeldung zurückliefert.
Der update-Prozess müsste meiner Meinung nach dann in etwa so gehen:
1. Zuerst alle updateCheck-Dateien herunterladen.
2. Alle updateCheck-Dateien ausführen, zu denen es ein gleichnamiges geladenes Modul gibt.
3. Falls vorhanden: updateCheck-Meldungen ausgeben und update abbrechen (und updateCheck-Dateien wieder auf den alten Stand bringen)
4. Ansonsten normal weiter

Ich glaube, dass dieses Vorgehen funktionieren würde und alle angesprochenen Probleme vermeidet. Allerdings glaube ich nicht, dass ich selbst das tatsächlich verwenden werde, da bis das vorhanden ist, der Zug schon abgefahren sein dürfte.

Wenn man so einen Precheck einführt, müsste auf jeden Fall auch die Version des CPAN Moduls mit rein. Auch mit verschiedenen Versionen gibt es immer wieder Überraschungen.

Das müsste man dann der jeweiligen Implementierung im Modul überlassen.

Ich beschäftige mich gerne mit meiner Steuerung, brauche aber auch eine gewisse Stabilität, da ich manchmal auch "aus Versehen" ein Update mache, und dann nicht stundenlang auf Fehlersuche gehen möchte.
Mich hat z.B. auch die "Zwangsaktivierung" des CSRFTokens massiv gestört. Das ging für mich schon in den Bereich der Bevormundung, da nach dem Update erstmal einiges nicht funktionierte. So etwas sollte man, und kann man auch recht einfach, anders einführen...

Das ist jetzt zwar ein anderes Thema, aber meiner Meinung nach war Rudis Vorgehen hier vorbildlich. Es hat ja eine ganze Weile gedauert, bis das scharf geschaltet wurde. Die meisten Probleme gab es ja, weil Modulautoren es verpennt hatten, darauf zu reagieren (mea culpa...).

Gruß,
    Thorsten

[rudolfkoenig]

Meiner Meinung nach darf bei einer Haussteuerung, die stets stabil lauffähig sein muss, niemals ein Update durchgeführt werden, dass zu einer (Teil-)Nichtfunktion der Steuerung führt, wenn es verhinderbar gewesen wäre.

Meine Meinung: Wenn man auf einem Produktivsystem ein update macht, dann testet man es vorher auf einem Testsystem. Genauso, wie auf "richtigen" Produktionssystemen, da kostet ein Upgrade auch Energie/Zeit und damit Geld. Keiner ist gezwungen, ein update zu machen. Wenn man FHEM (wie die meisten) als Spielwiese betrachtet, dann ist ein Ausfall nach einem update kein wirkliches Problem, man kann ja immer zurueckrollen, notfalls aus einem backup.

Mich hat z.B. auch die "Zwangsaktivierung" des CSRFTokens massiv gestört.

Weiss nicht, was genau dich daran stoert:
- dass du als Benutzer betroffen bist: ich will es nicht in den Medien lesen, dass ich (als "Hersteller") Schuld bin, wenn ein "Hacker" mit FHEM Schaden anrichtet, weil ich elementare Sicherheitsmaengel, die vor Jahren gemeldet wurden, nicht behoben habe.
- dass du als Entwickler betroffen bist: Hoffentlich erhoeht das die Aufmerksamkeit auf meine Bitten, ein Feature zu testen. Dieses Feature war 1.5 Jahre vorhanden, ich habe mit 5.8 nur die Voreinstellung geaendert.

Was spricht denn nun wirklich gegen eine Vorabprüfung auf Modulfreiwilliger Basis von verwendeten/aktiven Modulen während des Update-Prozesses, mit der Möglichkeit dadurch das Update zurückzurollen/zu verhindern?

Dass es nur in sehr wenigen Faellen (wie hier) hilft, und sehr wahrscheinlich mir unbekannte Nebeneffekte hat, mit dem ich mich "Jahrelang" rumplagen werde.

/=pod.*?=begin precheckfunction[\r\n]+(.*?)=end precheckfunction.*?=cut/is

Ich kann das einbauen, falls Andere das auch als notwendig erachten. Ich wuerde das fuer alle aktuell geladene "Haupt"-Module (keine Hilfsmodule) durchfuehren. Falls es schiefgeht, dann wuerde ich versuchen alles zurueckzurollen. Ist vermutlich 3-4 Stunden Aufwand, es zu impementieren.

@Thorsten: dein Vorschlag ist mir weniger sympatisch, da man dadurch Aufgaben verteilt, und man diese selten benutzte Ecke eher vergisst. Ich lasse mich aber ueberzeugen.

[Thorsten Pferdekaemper]

Dass es nur in sehr wenigen Faellen (wie hier) hilft, und sehr wahrscheinlich mir unbekannte Nebeneffekte hat, mit dem ich mich "Jahrelang" rumplagen werde.

Wahrscheinlich insbesondere da der Befehl "update" dann zu Problemen führt und es relativ wahrscheinlich wird, dass die Probleme in irgendwelchen allgemeinen Bereichen im Forum aufschlagen und nicht unbedingt im Bereich zum betroffenen Modul.

Ich kann das einbauen, falls Andere das auch als notwendig erachten. Ich wuerde das fuer alle aktuell geladene "Haupt"-Module (keine Hilfsmodule) durchfuehren. Falls es schiefgeht, dann wuerde ich versuchen alles zurueckzurollen. Ist vermutlich 3-4 Stunden Aufwand, es zu impementieren.
@Thorsten: dein Vorschlag ist mir weniger sympatisch, da man dadurch Aufgaben verteilt, und man diese selten benutzte Ecke eher vergisst. Ich lasse mich aber ueberzeugen.

Ich persönlich fände das ziemlich "unordentlich", so etwas in der Doku zu verstecken. (Ich finde auch schon die Doku im .pm-File unordentlich.) Ich gebe aber zu, dass diese Ecke wahrscheinlich eher selten benutzt werden wird und dadurch in Vergessenheit geraten kann. Ich bin mir aber nicht sicher, ob es wirklich hilft, alles in eine Datei zu legen.
Ich wünsche mir sowieso schon seit längerem, dass jedes Modul sein eigenes Verzeichnis bekommt. Dann hätte man z.B. /opt/fhem/FHEM/10_HM485 als Verzeichnis und könnte dort alles reinpacken, was ein Modul so braucht (wie z.B. auch meine XML-Dateien). Man könnte dann auch schön Doku von Code trennen und auch solches Check-Coding separat halten. Eine ähnliche Diskussion gab es auch rund um einen Mechanismus zum automatischen Erkennen von (Netzwerk-)Geräten, bei denen man auch nicht zuerst die Moduldatei laden will, nur um dann zu erkennen, dass es dazu gar kein Gerät gibt.
 
Gruß,
   Thorsten

[Thorsten Pferdekaemper]

Hi,
ich habe das jetzt für HM485 so "gelöst":
Der problematische Teil wird per "eval" geladen und $@ wird ausgewertet. Falls nötig, werden die Devices in FHEM "blockiert" und der Fehler erscheint im Log. Außerdem wird per FW_detailFn eine detaillierte Fehlermeldung ausgegeben. Das sollte reichen.
Gruß,
   Thorsten