[Refactoring] MySensors-Module

[Beta-User]

Hallo zusammen,

anbei mal ein Satz aktualisierter MySensors-Module. Habe die auch auf meinem Hauptsystem zum Testen laufen, weiß aber noch nicht, ob das alles stressfrei ist, weil doch einiges umgemodelt wurde.

Es ist einiges an perlcritic-Anregungen drin verarbeitet, aber ob das schon Bronzezeit ist...?

Was auch ging, war die "überflüssigen" Teile aus dem list zu verbannen, sehr schön!

Die verbliebenen perlcritic-Themen werden wohl etwas länger dauern, da ich die Anmerkungen zum Teil (noch) nicht verstehe und erst etwas Zeit (und Lust...) brauchen werde, um mich da einzudenken, was jeweils gemeint sein könnte.

Manche "Merkwürdigkeiten" - v.a. rund um Constants.pm - habe ich nicht wegbekommen, insbesondere geht es nicht so einfach, den EXPORT-Teil einfach nach vorne zu ziehen oder die Doppelungen in EXPORT_OK rauszunehmen... Im Moment habe ich noch keine Ahnung, wieso das so ist.

Zumindest habe ich die "Initialize"-Geschichte bei "Device" jetzt auch im Griff . Immer noch schlammig, aber hoffentlich mit dem wenigsten "Drumrum"...

Ich poste das vorrangig, damit die MySensors-Leute einen Ort haben, um die zu testenden Versionen zu bekommen, aber wenn wer mag, kann er gerne Kommentare abgeben oder Vorschläge zum "Entzerren" der "high complexity"-Codeteile liefern.

Grüße,
Beta-User

Nachtrag:
Anbei nur noch 00_MYSENSORS.pm und 10_MYSENSORS_DEVICE.pm, die beiden anderen braucht man seit der Fassung vom 09.05.2020 nicht mehr!

[zap]

Frage: welchen Vorteil hat

Code Auswählen Erweitern

$command eq ... and do {

gegenüber dem klassischen if elsif Konstrukt?

[RichardCZ]

Frage: welchen Vorteil hat

Code Auswählen Erweitern

$command eq ... and do {

gegenüber dem klassischen if elsif Konstrukt?

gar keinen.

           $key eq "altitude" and do {
...
            };

in Massen z.B. in 95_Astro

->

if ($key eq 'altitude') {
...
}

Da wollte jemand einfach nur mit logical shortcuts experimentieren.

[Beta-User]

Nun ja, war halt da und hat funktioniert...
perlcritic mosert auch nicht - im Gegensatz zu der elsif-Kaskade, die ich an anderer Stelle eingebaut habe. Die sollte man aber auch irgendwie eleganter als "nur" mit "if" lösen können...

[RichardCZ]

Der Punkt ist ja, dass "and do" weniger elegant ist als ein if.
Es ist ja äquivalent zu einer Ansammlung von ifs - keine if-elsif. Wenn man das also ersetzt, meckert perlcritic da auch nicht.

Logische Shortcuts sind eine tolle Sache - in Ausdrücken bei denen ein Wahrheitswert rauskullern soll:

if (mordsfunc(x) && $fast == 1) {...

kann man u.U. erheblich beschleunigen (wenn z.B. $fast == 1 oft nicht zutrifft), indem man die Sache einfach umdreht:

if ($fast == 1 && mordsfunc(x)) {...

dann wird mordsfunc(x) nämlich gar nicht ausgeführt.

Auch in if-elsif Ketten, oder tabular Ternaries... sollte man die wahrscheinlicheren und leicht abzufragenden Fälle
als erstes abhandeln. Im Notfall hilft ein Profiler oder einfache Prints.

[Sidey]

If else Schlangen lassen sich teilweise ganz gut mit Dispatch Tables ablösen.

Geht einfach, wenn es nur eine Variable zum Entscheiden gibt. Hat man mehrere kann man ggf. noch geschickt kombinieren oder mehrere Einträge auf den gleichen Code verweisen lassen.


Grüße Sidey

[Beta-User]

So,
zumindest ein kleiner weiterer update in der Sache...

Ein paar der "COMMAND_HANDLER"-Geschichten sind eliminiert, auch wenn ich "weniger elegant" jetzt nicht unbedingt als "dringenden Handlungsbedarf" übersetzen würde (?).

Etwas "Bauchweh" hatte ich mit den Block-grep-Modifikationen in Zeilen 191/194, aber zumindest ist mir das Testsystem nicht abgeschmiert beim rereadcfg... Scheint also zu passen. Damit wären wir mit überschaubarem Morphiumpflastereinsatz bei diesem Teilstück @perlcritic-level -3 .

If else Schlangen lassen sich teilweise ganz gut mit Dispatch Tables ablösen.

Klingt interessant, aber irgendwie habe ich Schwierigkeiten, das Stichwort, dieses Fragment

So bearbeitet, kann man das eventuell später noch weiter zu

Code Auswählen Erweitern

my %dispatch = (
    'ThermostatState' => \&_handleDies,
    'WallThermostat' => \&_handleDas,
...
);


und den Code z.B. in diesen Zeilen gedanklich zu einer spontanen Vollsynthese mit

Code Auswählen Erweitern

      MESSAGE_TYPE: {
        $type == C_PRESENTATION and do {
          onPresentationMsg($hash,$msg);
          last;
        };
        $type == C_SET and do {
          onSetMsg($hash,$msg);
          last;
        };
        $type == C_REQ and do {
          onRequestMsg($hash,$msg);
          last;
        };
        $type == C_INTERNAL and do {
          onInternalMsg($hash,$msg);
          last;
        };
        $type == C_STREAM and do {
          onStreamMsg($hash,$msg);
          last;
        };
      }
zu bewegen.

Sollte das am Ende einfach nur so sein?!?:

Code Auswählen Erweitern

my %dispatch = (
    'C_PRESENTATION' => \&onPresentationMsg($hash,$msg),
    'C_SET'              => \&onSetMsg($hash,$msg),
    'C_REQ'             => \&onRequestMsg($hash,$msg),
    'C_INTERNAL' => \&onInternalMsg($hash,$msg),
    'C_STREAM'   => \&onStreamMsg($hash,$msg),
);


(Aber wie dann abschubsen? Das ist doch erst mal ein "einfacher Hash", man müßte also erst "$dispatch{$type}" abfragen, bevor da was zurückkommt? Sorry, immer noch DAM).

Grüße,

Beta-User

[Sidey]

Hi Beta-User,

Du hast das mit den Dispatch Tables verstanden.
Ich habe das im 00_Signalduino schon so für get und set umgesetzt, weil mir das doch zu unübersichtlich wurde.

Die Referenz auf die Sub rufst du dann so auf:

Code Auswählen Erweitern

$dispatch{$Action}->($hash,$msg);

Hier auch ein paar Beispiele.
https://www.perlmonks.org/?node_id=456530

Grüße Sidey

[RichardCZ]

Sollte das am Ende einfach nur so sein?!?:

Code Auswählen Erweitern

my %dispatch = (
    'C_PRESENTATION' => \&onPresentationMsg($hash,$msg),
    'C_SET'           => \&onSetMsg($hash,$msg),
    'C_REQ'             => \&onRequestMsg($hash,$msg),
    'C_INTERNAL' => \&onInternalMsg($hash,$msg),
    'C_STREAM'   => \&onStreamMsg($hash,$msg),
);

Aber wie dann abschubsen?

Sidey hat eigentlich schon alle Zutaten beschrieben. Wenn Du es konkret willst,
ich würde es so schreiben:

Code Auswählen Erweitern

my $dispatch = {
    C_PRESENTATION => \&onPresentationMsg,
    C_SET          => \&onSetMsg,
    C_REQ          => \&onRequestMsg,
    C_INTERNAL     => \&onInternalMsg,
    C_STREAM       => \&onStreamMsg,
};

$dispatch->{$type}->($hash, $msg);


[Wzut]

Ich habe das im 00_Signalduino schon so für get und set umgesetzt

na also meine Gebete wurde erhört, gleich mal abschreiben gehen.....

[Beta-User]

Ähm, also irgendwie habe ich da jetzt so ziemlich alle Varianten durchgespielt...

Am "längsten lebt" Richards Variante, aber die zieht dann nach Eingang der ersten von einer Node gesendeten Meldung (vermutlich heartbeat=C_INTERNAL)  FHEM komplett in den Abgrund mit einem freundlichen Hinweis auf "Can't use an undefined value as a subroutine reference at ..." (Verweis auf die Zeile mit "$dispatch->{$type}->($hash, $msg);")
Die meisten anderen Kombinationen von %/$, Quotes, Klammern und -> verhindern das Starten der Module... Jetzt habe ich grade keine Lust mehr, dem weiter auf den Grund zu gehen (das Testen mache ich mit dem Hauptsystem) und kann auch einen Typo nicht ausschließen.

[RichardCZ]

Ähm, also irgendwie habe ich da jetzt so ziemlich alle Varianten durchgespielt...

Am "längsten lebt" Richards Variante, aber die zieht dann nach Eingang der ersten von einer Node gesendeten Meldung (vermutlich heartbeat=C_INTERNAL)  FHEM komplett in den Abgrund mit einem freundlichen Hinweis auf "Can't use an undefined value as a subroutine reference at ..." (Verweis auf die Zeile mit "$dispatch->{$type}->($hash, $msg);")
Die meisten anderen Kombinationen von %/$, Quotes, Klammern und -> verhindern das Starten der Module... Jetzt habe ich grade keine Lust mehr, dem weiter auf den Grund zu gehen (das Testen mache ich mit dem Hauptsystem) und kann auch einen Typo nicht ausschließen.

Wie wäre es mal den Code zu zeigen? Ich habe in solchen Fällen auch keine Lust auf Wahrsagerei.

Fehlermeldung besagt eigentlich nur, dass  $dispatch->{$type} undefiniert ist. M.a.W. Du bekommst einen $type rein, der nicht im Hash drin ist.

Code Auswählen Erweitern

ref $dispatch->{$type} eq 'CODE' ? $dispatch->{$type}->($hash, $msg) : Log("Irgendjemand versucht mir >$type< reinzudrücken");


[Sidey]

Du kannst auch einfach den commit in dein Repo hauen.
Dort kann man auch konkret Hilfestellung geben

[Beta-User]

Bitte etwas Geduld, ich hatte gestern nur keine Lust/Reserven mehr, das vollständige Bild zu liefern, und testen kann man mMn. nur, wenn man Hardware hat (oder das irgendwie aufwändig simmuliert).

(Der Code ist im wesentlichen aber genau das, was hier im ersten Beitrag verfügbar ist, ich habe dann gestern nur die 9 Zeilen von Richard wieder gegen die ursprüngliche MESSAGE_TYPE-Variante rückgetauscht...)

Bei Gelegenheit werde ich mal den Vorschlag mit dem Vorabtest auf den richtigen ref einbauen. Ist irgendwie seltsam, denn lt. Doku unter https://www.mysensors.org/download/serial_api_20#command sollte es wirklich nur diese $type geben; kann aber natürlich sein, dass da sehr viel mehr garbage über die Serielle Schnittstelle reinkommt, als ich bisher dachte...

Fortsetzung folgt .

(Und der Tipp mit dem Test war in etwa der Schubs, den ich brauchte, btw.. Mehr Kaffeesatzleserei war gar nicht meine Intention, es ging eher darum, rechtzeitig zu melden, dass "Houston" zu informieren ist, bevor Wzut da von "einfacher Gebetserhörung" ausgeht).

[Wzut]

bevor Wzut da von "einfacher Gebetserhörung" ausgeht

Was , wie ? also ich bin glücklich, bei mir läuft zum einen die "einfache" Variante von Richard also auch die Luxusversion %get / %set von Sidey aus 00_SIGNALduino
D.h. ich kann nun von Fall zu Fall und je nach Modul unterscheiden ob die einfache Version reicht oder ob es die aufgebohrte sein muß.

[RichardCZ]

Bei Gelegenheit werde ich mal den Vorschlag mit dem Vorabtest auf den richtigen ref einbauen. Ist irgendwie seltsam, denn lt. Doku unter https://www.mysensors.org/download/serial_api_20#command sollte es wirklich nur diese $type geben; kann aber natürlich sein, dass da sehr viel mehr garbage über die Serielle Schnittstelle reinkommt, als ich bisher dachte...

Ich habe ja schon ein wenig über "defensives Programmieren" schwadroniert, da hätte man natürlich im Beispiel den test auf coderef schon gleich mitliefern können, aber da behaupte ich jetzt einfach mal sowas sollte man autonom-automatisch zu meinen Skelettbeispielen dazutun. 

Vermutlich werden einige neue kreative Messages bzw. Werte für $type im Log auftauchen.

[Beta-User]

Ja, manche brauchen halt für die Defensive länger wie für Offensive...

Das Problem waren weniger "kreative" neue Message-types, sondern vielmehr die Auflösung der Constants. Die logs erspare ich euch, aber es wurden bei dem kurzen Test nur 0-4 ausgeworfen...

Habe daher erst mal nur schlicht und ergreifend  die nummerischen Werte als Referenz vorne eingetragen. Nicht so aussagekräftig, aber funktional.

Anbei zur Abwechslung dann mal wieder  Code, der tut, was er soll (zumindest scheint das erst mal so...).

[Sidey]

Kleine Info was das Thema Testen ohne Hardware betrifft.

Ich teste mein physisches Modul auch gänzlich ohne Hardware. Das geht durchaus.

Beispielsweise, wenn man über httpmod etwas von einem Webserver abruft, dann präpariere ich mir einen repräsentativen Output. Z.B. kann das der json Body sein.
Der routine, welche dann den Output prüft, übergebe ich den präparierten json und verifiziere ob das Ergebnis passt.

Das kann man dann variieren und auch Daten übergeben mit denen man erst mal nicht gerechnet hat.

Naja an alles zu denken ist schwer, aber so ein paar Standard Situationen wiederholen sich vom Prinzip immer wieder.

Im Endeffekt kann man fast alles ohne Hardware testen.
Sogar das DevIO Modul kann man ohne Hardware testeten.

Grüße Sidey

[Beta-User]

"Kann" ist klar, hatte ja auch schon gleich geschrieben, dass man das vermutlich simulieren kann, wenn man ohne Hardware testen will.

Für mich war nur die Frage, wie es _für mich_ einfacher ist. Da habe ich für Funktionstests die Optionen Echtsystem, Testsystem mit Hardware oder Software.
Meistens kommt da in meinem Fall "Echtsystem" (nach Test des Moduls auf Lauffähigkeit in einem Testsystem ohne Hardware) raus. Hat halt den Nachteil, dass ich nur dann teste, wenn ich notfalls direkt auch reparieren kann, aber den Vorteil, dass ich gleich sehe, ob es im realen Leben auch geht (ich weiß ja in etwa, wann welche Node was abliefern müßte).

Würde ich das in Software machen wollen, wäre das noch eine Baustelle, und die tue ich mir im Moment schlicht und ergreifend nicht an, selbst wenn es einfach sein sollte. Wenn, dann will ich auch verstehen, was da "Sache ist", sonst nützt dem Bauchgefühl nach auch das Testen wenig.

Für "Sonderfälle" hatte ich mal ein Testsystem mit Hardware, das ich aber schon länger nicht mehr angefaßt hatte (deswegen werden die elsif-Kaskaden bei den diversen Debug-Dingern wohl auch noch eine ganze Zeit Bestand haben, falls sich nicht jemand erbarmt, der grade zufällig was passendes rumliegen hat; das erfordert nämlich zu allem Überfluß auch noch speziellen Code auf der abzufragenden Node bzw. funktioniert nicht mit allen Transceiver-Varianten...)

[RichardCZ]

Device::MySensors::Message

sub gettime ...

kann das weg? Ich sehe nirgends eine Verwendung und es wird nichtmal exportiert.

[Beta-User]

Im ersten Post jetzt nochmal der komplette Satz mit dem aktuellen Stand.

Da ist dann auch "sub gettime" raus, danke für den Hinweis .

Noch nicht optimal:
Message.pm: der "Standort" der EXPORT-Teile. Muß wohl so sein, bzw. anderfalls braucht man wohl die {no ...}-lexical scopes analog Constants.pm.

MYSENSORS_DEVICE
- Die Reihenfolge im set-Command-Handler@(kommt bei Gelegenheit mal);
- "die eine" if-Kaskade (mal schauen).

Grüße, Beta-User

[Beta-User]

Im ersten Post nochmal eine Aktualisierung von  10_MYSENSORS_DEVICE.pm.

Habe die Command-Handler weiter reduziert und eine erste Testfasung für Stream-Type Messages (falls "jemand" an Bildübertragung interessiert ist...). Ist aber noch nicht groß getestet.

[RichardCZ]

Ich sehe bei Get ein löbliches

return sendClientMessage(...

(es fehlt ansonsten häufig in Modulen, dass Rückgabewerte weitergeschleift werden, da verliert man viel Information)
aber kurze Zeit später

        sendClientMessage($hash, cmd => C_INTERNAL, subType => I_SIGNAL_REPORT_REQUEST, ack => 0, payload => "R");
        return;

wasdasdenn?

Rein interessehalber: "=pod disable unused $types "

Kommen die nicht zur Verwendung oder ist das NYI?

Code Auswählen Erweitern

   if ($type == I_VERSION ||
      $type == I_ID_REQUEST ||
      $type == I_ID_RESPONSE ||
      $type == I_INCLUSION_MODE ||
      $type == I_FIND_PARENT ||
      $type == I_FIND_PARENT_RESPONSE ||
      $type == I_LOG_MESSAGE ||
      $type == I_SIGNAL_REPORT_REVERSE ||
      $type == I_LOCKED ||
      $type == I_REGISTRATION_REQUEST ||
      $type == I_REGISTRATION_RESPONSE ) {
        $hash->{$typeStr} = $msg->{payload};
        return;
    }

So lange wir hier nicht alle Allahu akbar oder Meschugge sagen und RTL (nein, nicht der Fernsehsender: https://en.wikipedia.org/wiki/Right-to-left) lesen, sollten die Operatoren immer am Anfang (Links) und nicht am Ende (Rechts) stehen. Alle. Auch Concats.

Die echt elegantere Lösung als

Code Auswählen Erweitern

if ($type == FOO) {
wurschtel wurschtel
}

if ($type == BAZ) {
wurschtel wurschtel
}


ist tatsächlich

Code Auswählen Erweitern

sub _onFoo {
wurschtel
}

sub _onBaz {
wurschtel
}

und dann Dispatch table. Wenn Du dann irgendwann eine Testsuite für das Modul schreiben willst, dankst Du Gott (oder mir), dass Dein Code bereits in schöne kleine testbare subs seziert ist.

Code Auswählen Erweitern

my $nextTrigger = main::gettimeofday()

Ne - echt nicht. Mach den use Time::HiRes selbst.

[Beta-User]

Hmm, also (im ersten Post wieder eine kleine Aktualisierung, nix wildes, aber da hatte sich noch ein "last;" versteckt, das hätte ggf. bei einem der vielen Tester schiefgehen können ).

Was return sendClientMessage() betrifft, war es teils schlicht mit dem guten Gefühl abgekupfert, dass es so flexibler sein könnte. Tatsächlich gibt die betreffende sub aber nix zurück und es ist mMn. in fast allen Fällen auch eine "fire&forget" Anweisung. Wenn man da was auswerten wollte, wird es schnell kompliziert, da ein Teil der messages nicht unbedingt gleich rausgeschickt werden (bei smartSleep-Nodes wird gequeued). Hab's jetzt trotzdem da auch umgebaut, wo ich drübergestolpert bin.

Wenn ich mal lustig bin, baue ich ggf. den "callback" für manche "get/set" noch ein, aber das ist etwas anderes: https://wiki.fhem.de/wiki/DevelopmentModuleIntro#X_AsyncOutput (@eventuelle kundige Mitleser: Das würde mich interessieren, wie das im Detail geht, kann ja eigentlich nix dramatisches sein...).


Was die deaktivierten Typen angeht, sind die mWn. tatsächlich nur zur Kommunikation node-2-node im C-code vorgesehen, werden aber nicht (außerhalb eventueller Debug-Meldungen an der seriellen Konsole der Arduinos) als regulärer Message-Inhalt ausgegeben. Das betrifft sogar einige der "älteren" Typen, die in dieser "or"-Struktur vergraben waren. War auch eher zur Vorbereitung gedacht, um da mal auszumisten und das löschen, was nichts bringt. (Es hatte mir jemand geraten, sukzessive vorzugehen ).

Und da hatte ich die verstreute "Soll ich damit was anfangen?"-Liste erst mal in "ja, und zwar speziell das...,", "ja, aber nur Internals updaten" und "wasndat?!?" sortiert, wobei der zweite Haufen vermutlich immer noch zu groß ist. Da gehört mind. die Hälfte auch in "wasndat?!?", aber das mußte ich mir nochmal im Detail ansehen... (und zwei -ziemlich unwichtige - Typen waren auch falsch umsortiert). Jetzt ist raus, was mAn. garbage ist...

Das mit dispatch hat zwar was, aber es hat auch seine Tücken, angefangen damit, dass das hier CONSTANT sind und das mit dem dispatchen daher nur geht, wenn man die nummerischen Entsprechungen verwendet. Das ist aber mMn. schlechter lesbar (den "Trick" mit dem "+" vorneweg, den hier jemand anderes propagiert hatte, hatte ich erfolglos getestet)...

In dem "Sammel-if" ist jetzt nicht mehr viel drin, und bei manchem (I_LOG_MESSAGE und I_LOCKED frage ich mich, warum das dann nicht als triggerndes Reading ausgeworfen wurde) (beides nie verwendet...). Nun ja, schön ist es nicht, aber andererseits ist die Frage, ob man
wegen der paar Werte einen hash aufmacht oder sonst einen Zinnober, zumal bei den Constants ja fraglich ist, ob der Wert dann wirklich sauber geprüft wird... .

Zu guter letzt ist es jetzt noch nach gefühlter Häufigkeit sortiert .

Da ich mich nicht in der Lage sehe, da eine Testsuite für zu entwickeln, braucht man mMn. den Code auch an der Stelle nicht weiter zu atomisieren, das ist zwar länglich, aber diese Teile sind so simpel, die verstehe sogar ich .

use Time::HiRes: Aye Sir! Hatte mich bisher nicht näher damit beschäftigt, wo die Funktion eigentlich ursprünglich mal herkam...

[krikan]

https://wiki.fhem.de/wiki/DevelopmentModuleIntro#X_AsyncOutput ([...] Das würde mich interessieren, wie das im Detail geht, kann ja eigentlich nix dramatisches sein...).

asyncOutput-Beispiele findest Du mehrere in https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/10_ZWave.pm

[Beta-User]

Hmm, das bringt mich leider nur bedingt weiter... Ich hatte mir das mal vor langem schon im Signalduino-Code angesehen, neulich mal wieder im MQTT2_DEVICE und habe leider immer noch nicht so richtig den Anpack, was jetzt wo genau ergänzt werden müßte, dass das klappt. Habe jetzt nochmal in den MQTT2_DEVICE-Code geschaut, da weiß ich besser, was da abläuft und es sind weniger Stellen.

Mal die Bruchstücke:
- Wenn ein get abgesetzt wird, kommt der if-Code aus https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/10_MQTT2_DEVICE.pm#L356 zum Einsatz.
- kommt irgendwas zurück, wird "checkForGet" dazwischengeschoben: https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/10_MQTT2_DEVICE.pm#L125

Aus der Zusammenschau würde ich also schließen, dass mir als "Brücke" fehlt, wo "$hash->{CL}" herkommt, aber alles, was ich dazu im Modul selbst finde, wäre https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/10_MQTT2_DEVICE.pm#L321, da wird ein hash gebaut und an fhem.pl übergeben. In fhem.pl findet sich dann zwar was, aber das klingt nach Zusammenhängen mit CommandSetReading, und ab da bin ich dann gedanklich weg...
Eigentlich müßte das eher was mit der Frage zu tun haben, ob der Befehl aus FHEMWEB oder telnet kam, denn dahin sollte ja die Rückmeldung gehen...

Vielleicht kannst du mir da dann noch den entscheidenden Tipp geben, wie der "Ring" zu schließen ist...?

[rudolfkoenig]

Von vorne:
- Benutzer will Antwort auf Frage
- Problem: die Antwort dauert laenger, das Modul will FHEM nicht blockieren
- Loesung: set/get/attr/define/modify setzt _fuer die Dauer des Modul-Funktionsaufrufs_ $hash->{CL} auf das "Client-Hash", d.h. die FHEMWEB/telnet/etc Verbindungsinstanz worueber der Befehl reingekommen ist.
- dieses $hash->{CL} muss man im modulspezifischen getFn/etc merken, die Abfrage ohne blockieren starten, und nichts zurueckliefern.
- wenn die Antwort eingetroffen ist (in ParseFn?), dann wird geprueft, ob das die Antwort auf die aussstehende Frage ist. Wenn ja, asyncOutput() wird mit der gespeicherten Variante von $hash->{CL} aufrufen.
- wenn die dazugehoerige Verbindung (FHEMWEB/telnet/etc) eine AsyncOutputFn implementiert, dann wird darueber dem Benutzer die Antwort mitgeteilt.

[Beta-User]

Ah, jetzt wird klarer, warum der Code in MQTT2_DEVICE sich so liest, als könnte man davon ausgehen, dass $hash-{CL} einfach da ist... Das ist der Fall, wenn der "Auslöser" aus FHEMWEB (&Co) heraus aufgerufen wird.

Bleibt die Frage, wie man es mit timeouts hält. MQTT2_DEVICE wartet 4 Sekunden, das finde ich eigentlich auch ganz ok, hier ist ähnlich unklar, ob und wann ggf. die Anfrage zugestellt werden kann. Eigentlich weiß man nur, wenn ein bestimmter Schlafmodus genutzt wird (was kaum einer macht), dass die Node nicht erreichbar ist...

Damit habe ich zumindest mal eine Blaupause, Danke! Mal sehen, wann ich dazu komme, diese "Verschönerung" einzubauen (da hat sich all die Jahre keiner wirklich dran gestört).

Eine abschließende Frage: Auf bestimmte Fragen gibt es mehrere Rückgabewerte bzw. manches läuft in einer Art "Schleife" (bestimmte Debug-Infos von den Nodes). "Schön" wäre es, diese Infos zu sammeln (falls die Node zeitnah Antwort liefert) und dann auch gebündelt auszugeben. Geht doch bestimmt auch?

[rudolfkoenig]

"Schön" wäre es, diese Infos zu sammeln (falls die Node zeitnah Antwort liefert) und dann auch gebündelt auszugeben

Dann sammele die Daten solange, bis der Timeout zuschlaegt, und gib sie dann in der Timeout-Routine alle auf einmal aus.
Oder Du kriegst vorher irgendwie mit, dass nichts mehr kommt.
Oder anders

[Beta-User]

Dann sammele die Daten solange, bis der Timeout zuschlaegt, und gib sie dann in der Timeout-Routine alle auf einmal aus.
Oder Du kriegst vorher irgendwie mit, dass nichts mehr kommt.
Oder anders

Danke. Ich glaube, der Groschen ist gefallen, siehe screenshot .

Aktualisiertes Modul im Anhang (heartbeat ist aber erst der Anfang...).

[rudolfkoenig]

Bin von der Praezision beeindruckt.
Ich meine zuletzt gelesen zu haben, dass Zeit "analog" ist (nicht in Quanten zerteilt), insofern plausibel

[Beta-User]

Na ja, über den effektiven Grad der Präzision mag man streiten, vermutlich müßte eine Schleife her, die das vielfach wiederholt, um alle Zufälligkeiten rauszufischen... Das dürfte nur am Ende wenig bringen, denn viel mehr wie eine Tendenz auf Frage, ob die Node "gut" zu erreichen ist, läßt sich darüber m.E. sowieso kaum rausfinden . Mir reicht es jedenfalls, wenn ich über diesen Wert nicht nur über die Geschwindigkeit des Einfärbens des Readings sehen kann, dass es einigermaßen schnell geht . Zeit für die Formatierung und weitere Überlegungen ist später noch, wenn man das wirklich braucht/will...

Für Vorschläge, wie man so eine "Pingzeit" "normierter" darstellt, bin ich aber wie immer offen .

Interessanter werden wohl ein paar der anderen Auswertungen, insbesondere zu RSSI und Extended_DEBUG...


Ein anderer Punkt, den ich aber erst irgendwann später angehen will: Man hat über die Sketche die Möglichkeit, einzelnen "ChildID's" Bezeichnungen zuzuweisen. ChildID's sind sowas wie "Kanäle" (kann alles mögliche sein: ein Relais, ein Temperaturfühler, alle Daten von einem BME280 (die man aber auch "vereinzeln" und unter separaten ChildID's versenden kann)). Nachdem ich jetzt die Vorzüge kennengelernt habe, die "split"-Geräte teilweise haben, wäre es ein nettes Gimmick, die heute als "Einheitsdevice" aufgebauten MYSENSORS_DEVICE-Geräte irgendwie splitten zu können. Muß mich da auch erst eindenken, aber falls jemand eine spontane Eingebung hat: Gerne...
(Denke über ein Attribut am IO nach und/oder eine Art "bridgeRegex" am Device).

Aber: eines nach dem anderen...

[RichardCZ]

Für Vorschläge, wie man so eine "Pingzeit" "normierter" darstellt, bin ich aber wie immer offen  .

Zu ping herüberschiel:

$ ping fhem.de
PING fhem.de (88.99.31.202) 56(84) bytes of data.
64 bytes from fhem.de (88.99.31.202): icmp_seq=1 ttl=53 time=15.1 ms
64 bytes from fhem.de (88.99.31.202): icmp_seq=2 ttl=53 time=17.0 ms
64 bytes from fhem.de (88.99.31.202): icmp_seq=3 ttl=53 time=15.1 ms
64 bytes from fhem.de (88.99.31.202): icmp_seq=4 ttl=53 time=15.4 ms


1/100stel ms - ist doch ausreichend.
Wiederholung um zu sehen ob es Varianzen gibt (nicht um besser einen Durschschnitt abschätzen zu können)
Und noch ein paar andere Dinge wie lost oder dupe Pakete



Spontane EIngebung wird in den nächsten 14 Tagen folgen, denn heute wird meine Mysensors Grabbelkiste geliefert.

[Beta-User]

Spontane EIngebung wird in den nächsten 14 Tagen folgen, denn heute wird meine Mysensors Grabbelkiste geliefert.

Da bin ich ja mal gespannt. Hast du jetzt nur RS485-Bauteile drin oder auch "Funker"?

1/100stel ms - ist doch ausreichend.
Wiederholung um zu sehen ob es Varianzen gibt (nicht um besser einen Durschschnitt abschätzen zu können)
Und noch ein paar andere Dinge wie lost oder dupe Pakete

ms-Angaben finde ich gut. Gestern hatte ich mich erst mal gefreut und euch an meinem allerersten Erfolgserlebnis zu dem Thema teilhaben lassen, da hatte ich erst mal noch gar keine konkrete Vorstellung, was da überhaupt kommt...

Was lost+dupe Pakete angeht, bin ich mal auf die Vorschläge gespannt. Ich gebe dabei aber zu bedenken, dass wir mit RS485 "Exotenhardware" betreiben und man das mMn. nicht so einfach auf Funknetzwerke übertragen kann. Das "Standardsetup" zu MySensors dürfte in vielen Fällen sein, dass es "einfache" Sensorik ist, deren Arduinos im Regelfall schlafen, ohne das dem Controller (=FHEM) mitzuteilen. Die wachen dann irgendwann auf, messen und versenden ihre Meßwerte per Funk, um dann wieder "leise" einzuschlafen. Diese Art Nodes kann man gar nicht anpingen oder abfragen... (deswegen gibt's diese timeout-Attribute: sendet die Node _von sich aus_ auch einen heartbeat, kann man u.a. darüber überwachen, ob die "aktiv" ist oder erwartete Nachrichten ausbleiben - sonst bräuchte man dazu externe Module).

(Dafür liefert RS485 "super-aussagefähige" RSSI-Werte zurück, you'll see). Und das "extended-Debug-Zeug" hat mWn. bisher außer mir max. eine Handvoll Leute je ausgetestet...

[Beta-User]

Und noch ein update im ersten Thread.

Jetzt gibt es "ms"-Ausgaben und Rückmeldungen zu noch ein paar mehr Anfragen. Vermutlich ist die Formatierung der Debug- und RSSI-Rückmeldungen nicht optimal, aber ich habe grade keine Nodes zum Testen .

Wenn sich die Downloadzahlen (=Tester?) nicht wesentlich erhöhen, lasse ich das jetzt noch eine Weile beim mir so laufen und checke das Gesamtpaket dann vermutlich am WE ein. perlcritic@MYSENSORS_DEVICE liefert bei -3 zwar noch ein paar Punkte, aber da warte ich dann auf Verbesserungsvorschläge von kundiger Seite...

[RichardCZ]

Code Auswählen Erweitern

*{'main::MYSENSORS_Initialize'} = *{'Initialize'};
->
sub main::MYSENSORS_Initialize { goto &Initialize };


letzteres schmiert wesentlich weniger in der Symboltabelle herum.

Ist dann das no strict überhaupt notwendig?



Bei den Uses immer erst die Systemmodule, dann die Projektmodule, dann die eigenen Module

use GPUtils qw(:all);
use Device::MySensors::Constants qw(:all);
use Device::MySensors::Message qw(:all);

use DevIo;

use Exporter ('import');
->

use Exporter ('import');

use DevIo;
use GPUtils qw(:all);

use Device::MySensors::Constants qw(:all);
use Device::MySensors::Message qw(:all);


Das ist robuster wenn irgendjemand irgendwo im Namespace rumschmiert. Und wenn das irgendwo auf die Schnauze fliegt, dann sind echt einige Exkremente am dampfen.
Und vielleicht innerhalb der Gruppen alphabetisch sortiert zur Übersicht.



  if ($init_done) {
    return Start($hash);
  } else {
    return;
  }

Das geht in 2 Zeilen - und sauberer/übersichtlicher.

return "Need at least one parameters"  <- *parameter



Puh - das ist ja gut gemeint:

Code Auswählen Erweitern

return "Unknown argument $a[1], choose one of " . join(" ", map {@{$sets{$_}} ? $_.':'.join ',', @{$sets{$_}} : $_} sort keys %sets)  if(!defined($sets{$a[1]}));

aber

Code Auswählen Erweitern

return "Unknown argument $a[1], choose one of "
    . join(" ", map {
        @{$sets{$_}} ? $_
                       . ':'
                       . join ',', @{$sets{$_}}
                     : $_
                   } sort keys %sets)
    if (!defined($sets{$a[1]}));


Das hat sicher die Grenze zum Einzeiler längst überschritten. (also auch meine aufgedrüselte version, die ja auch ein Einzeiler ist nur optisch formatiert)

Code Auswählen Erweitern

   sendMessage($hash,radioId => 0, childId => 0, cmd => C_INTERNAL, ack => 0, subType => I_INCLUSION_MODE, payload => $value eq 'on' ? 1 : 0);

Bitte keine Angst vor hübscher Formatierung (=Lesbarkeit):

Code Auswählen Erweitern

sendMessage($hash,
            radioId => 0,
            childId => 0,
            cmd     => C_INTERNAL,
            ack     => 0,
            subType => I_INCLUSION_MODE,
            payload => $value eq 'on' ? 1 : 0
        );

wobei hier ja eigentlich zwei Hashrefs übergeben werden sollten.


10_MYSENSORS_DEVICE

if ($command =~ m{time|reboot|clear|flash|fwType}xms) { # for speed reasons?

No, for brevity reasons. Und vergiss die \A \z Anker nicht - die da hoffentlich hingehören.

Code Auswählen Erweitern

if ($command eq "fwType") {
        if (@values == 1) {
          my ($type) = @values;
          if ($type =~ m{^\d*$}xms) {
            readingsSingleUpdate($hash, 'FW_TYPE', $type, 1);
          } else {
            return "fwType must be numeric";
          }
        }
        return;
      }

Der Reihe nach:

* Die Firmwareversion kann auch ein Leerer String sein? Nein? Siehste.
* Mongolische Ziffern möglich? Nein? Siehste.

Also ich würde es ja so machen:

Code Auswählen Erweitern

if ($command eq 'fwType') {
    my $type = shift @values // return;
    return "fwType must be numeric" if ($type !~ m{^[0-9]+$}xms); # ja ne is klar :-)
    return readingsSingleUpdate($hash, 'FW_TYPE', $type, 1);
}


Aber eigentlich sollte man es so machen:

https://forum.fhem.de/index.php?topic=88878.15 
https://wiki.fhem.de/wiki/MySensors_Starter_Guide
("Zwischenzeitlich wird ein update über den jeweiligen Transport-Layer (OTA) von HFEM unterstützt[5].") - was ist bitte HFEM?

Code Auswählen Erweitern

if ($command eq 'fwType') {
    my $type = shift @values // return;
    return "fwType must be numeric, but got >$type<." if ($type !~ m{^[0-9]{2,20}$}xms);  # begrenzt vielleicht? Keine Major.Minor?
    return readingsSingleUpdate($hash, 'FW_TYPE', $type, 1);
}


[Beta-User]

Anbei mal ein Satz mehr oder weniger ungetesteter Versionen, wird etwas Zeit benötigen, dass ich das dem "live-Härtetest" unterziehen kann, vorab gibt's aber noch ein paar Kleinigkeiten zu klären...

Code Auswählen Erweitern


sub main::MYSENSORS_Initialize { goto &Initialize };


Done. Dann kann man auch auf strict/refs verzichten.

Unklar: Was vars angeht. Das klappt mit den EXPORT-Variablen aber nur, wenn ich ein "our" davorschreibe (das hattest du irgendwann mal vorgeschlagen). Leider ist mir nur nicht so ganz klar, wo die Unterschiede liegen (bzw. wo ich das DAM-gerecht nachlesen kann...). Es ist daher jetzt in der "our"-Variante drin, mal sehen, ob mir das beim live-Test doch aus irgendwelchen Gründen um die Ohren fliegt...

Bei den Uses immer erst die Systemmodule, dann die Projektmodule, dann die eigenen Module [...]
Und vielleicht innerhalb der Gruppen alphabetisch sortiert zur Übersicht.

Dürfte jetzt passen...

Das geht in 2 Zeilen - und sauberer/übersichtlicher. [...]
return "Need at least one parameters"  <- *parameter

Ok, wir kommen langsam aber sicher zu den "Feinheiten"... Hab's da eleminiert, wo es mit grade vor der Flinte war, aber ohne Ansprucha uf Vollständigkeit...

Das hat sicher die Grenze zum Einzeiler längst überschritten. (also auch meine aufgedrüselte version, die ja auch ein Einzeiler ist nur optisch formatiert) [...]
Bitte keine Angst vor hübscher Formatierung (=Lesbarkeit):

Na ja, manche ererbten Juwelen sind halt wie sie sind... Habe die jetzt auch in den Fällen etwas abgestaubt, wo es mir beim Vorbeigehen ins Auge gespungen war .

wobei hier ja eigentlich zwei Hashrefs übergeben werden sollten.

Was will mir "eigentlich" sagen? Ändern? Also den hash vorher bilden und dann als solchen der Funktion übergeben? Irgendwo zentral ablegen und dann darauf verweisen? Weiß noch nicht so recht, habe etwas Sorge, dass es am Ende dann eher noch unübersichtlicher werden würde...

No, for brevity reasons. Und vergiss die \A \z Anker nicht - die da hoffentlich hingehören.

Hab' die Anker auch noch an ein "paar" anderen Stellen verteilt, dto. für die \s+-Geschichte samt Derivaten...

* Die Firmwareversion kann auch ein Leerer String sein? Nein? Siehste.
* Mongolische Ziffern möglich? Nein? Siehste.
[...]Aber eigentlich sollte man es so machen:[...]
Keine Major.Minor?

Danke für den Vorschlag, überzeugend...

Den Link interpretiere ich mal als diese Frage: "Warum nicht einfach auf eine bestimmte firmware-Datei verweisen und dazu einen upload-Befehl generieren, wie sonst in FHEM üblich?"

Nun ja, es gibt für MySensors eine Art "Muster-Controller", über den einige User früher ihre updates gemacht haben (also außerhalb FHEM). Der sieht diese Art der Verwaltung der firmwares und ein "auto-update-feature" vor, das eben über eine csv-Datei gesteuert wird und eine formalen Aufbau hat, was auch die Frage nach der Nummerierung beantwortet: dort sind afaik nur natürliche Zahlen vorgesehen, siehe https://www.mysensors.org/about/fota#launch-your-fota-update.

An sich wäre es wirklich mehr "FHEM-like", das händisch anzuschubsen, aber das würde das "auto-update-feature" brechen, daher habe ich den Aufwand bisher nicht getrieben und tendiere auch weiter dazu, das so zu lassen, wie es ist...



Noch was ganz anderes:

Soweit ich das überblicke, werden die drei Funktionen in Message.pm nur von 00_MYSENSORS.pm benötigt. Tendiere daher dazu, die schlicht und ergreifend da reinzubasteln...?
Deine Meinung?

Wenn man das dann vollständig machen wollte, wäre das auch mit Constants.pm die Frage, aber die wird eben tatsächlich von beiden Seiten her genutzt. Aber auch da wäre es vermutlich nicht so viel aufwand, das in die 00 mit reinzuwursteln.
Auch hier: Deine Meinung?

[Beta-User]

Live-Test steht noch aus, aber:

Anbei MYSENSORS/MYSENSORS_DEVICE, die ohne  Constants.pm und Message.pm in /lib auskommen... Ist jetzt beides in 00_MYSENSORS.pm integriert.

[Beta-User]

So, live-Test läuft - sieht soweit erst mal gut aus .

Die Module finden sich zum testen für "Freiwillige" jetzt wieder im ersten Post hier.

Das dispatchen mit "constant" klappt jetzt auch, aus http://neilb.org/reviews/constants.html (21 ways to use constant) habe ich den Trick geklaut, CONSTANT() zu verwenden. Hat aber bestimmt einen Pferdefuß...(?)

Wie auch immer, bei Gelegenheit sollte man vermutlich die "Startroutine" noch von eventbasiert auf timerbasiert umbauen, aber Rom und so... (@Richard: das mit der Startroutine ist ein spezielles FHEM-Thema, wir kommen ein andermal darauf zurück).

Das mit dem EXPORT scheint ein spezielles Thema zu sein, das ich noch nicht verstehe, aber auch da: Rom!

Jetzt mault perlcritic immer noch manches auf Level -3 an, aber für's erste wäre ich (evtl. bis auf das Initialisierungsthema) geneigt, den Stand aus dem ersten Post erst mal einzufrieren und das ganze dann in ein paar Tagen "as is" ins svn zu packen.

[Wzut]

Darf ich jetzt auch mal Klugscheissen ?
So wie dein Sub Set anfängt hatte ich es auch fast in jedem Modul , das @_ und das "böse" @a und dann die Teile int(@a) , $a[1], usw durchgekaut
Inzwischen steht bei mir da

Code Auswählen Erweitern

sub Set {

    my $hash = shift;
    my $name = shift;
    my $cmd  = shift // return "set $name needs at least one argument !";
    my $value = shift // '';

und warum gleich so früh if(!defined($sets{$a[1]})); ? Willst du mit aller Gewalt gleich raus wenn das FHEMWEB Fragezeichen kommt ?
lass es doch bei den den paar if commands einfach durchlaufen und gib ganz am Schluss immer das unknow aus

[Beta-User]

Darf ich jetzt auch mal Klugscheissen ?

...immer wieder gerne .

So wie dein Sub Set anfängt hatte ich es auch fast in jedem Modul , das @_ und das "böse" @a und dann die Teile int(@a) , $a[1], usw durchgekaut
Inzwischen steht bei mir da

...vielleicht sollte ich mir das @a/b nochmal vornehmen .
Und die ganzen shift's erweitern... (aber irgendwo hatte ich zu shift vs. (....)=@_ neulich gelesen: Wenn man das ganze nur intern aufruft, darf man auch etwas weniger "failsafe" programmieren....)

und warum gleich so früh if(!defined($sets{$a[1]})); ? Willst du mit aller Gewalt gleich raus wenn das FHEMWEB Fragezeichen kommt ?
lass es doch bei den den paar if commands einfach durchlaufen und gib ganz am Schluss immer das unknow aus

Ähm, ich tu' mich mit dem Teil des Codes auch immer schwer, wenn da so viele Referenzierungen drin sind, aber mMn. hat das hier nichts mit dem roten Fragezeichen zu tun, sondern es geht darum, ob der betreffende set-Command überhaupt vorhanden ist. Ist er das nicht, macht es keinen Sinn, weiterzumachen, sondern es dürfte eher wichtig sein, hier - as is - aufzuhören . Das erfüllt also mMn. genau den Zweck, den das shift oben ggf. auch gehabt hätte: failsafe's Programmieren...

[Wzut]

ok, dann vergleich mal das Ende von matchClient mit dem Ende von matchChan76GWClient ein paar Zeilen tiefer.
return $found if $found;
return;
habe ich mir inzwischen abgewönht und mache es wie in matchClient.

Log3($hash->{NAME}, 4, "$hash->{NAME}: matched firmware config request to hash $found, name: $found->{NAME}") if $found;

Steht da im Log wirklich was lesbares für $found ($found->{NAME} leuchtet mir ein ) , aber $found ist doch $defs{$d} ?
und ich fand die $hash->{NAME} immer gruselig da du in der foreach eh my $name = $hash->{NAME} hast kannst das doch auch vorziehen und dann nur noch $name verwenden.
Im Gegenzug hätte ich eher $clientname eingespart da nur 1x verwendet und direkt ins  AttrVal gepackt. 

[RichardCZ]

und warum gleich so früh if(!defined($sets{$a[1]})); ? Willst du mit aller Gewalt gleich raus wenn das FHEMWEB Fragezeichen kommt ?

Ob das jetzt in dem konkreten Fall so sein muss oder nicht, lasse ich mal dahingestellt, aber prinzipiell ja - sollte man so früh wie
möglich rausspringen wenn sich vergebliche Liebesmüh' abzeichnet.

Also anstelle

Code Auswählen Erweitern

sub x {
  my blah = shift;
  if (defined blah) {
    wurschtel
  }
  return;
}

eben

Code Auswählen Erweitern

sub x {
  my blah = shift // return;
  # Here we know blah MUST be defined
  # and we spare ourselves an if-Einrückung
  wurschtel

  return;
}

Es ist sogar wünschenswert mal einen if-Ast zu negieren und vorab "abzufackeln",
wenn man sich Einrückungen größerer Mengen Code spart.

Code Auswählen Erweitern

sub x {
  my blah = shift;

  if (mords && logic || function) {
   x-zeilen ellenlanges
   gewurschtel
  }

  return;
}
->

Code Auswählen Erweitern

sub x {
  my blah = shift;

  if (! (mords && logic || function)) { # bzw. De-Morgan
    return;
  }

  x-zeilen ellenlanges
  gewurschtel

  return;
}

[Beta-User]

Boah, ihr wollt's aber wirklich wissen...

"Komisch", dass man merkt, dass matchChan76GWClient eine der ersten komplexeren Funktionen war, die ich mühsam und mit viel Hokuspokus selbst anhand der Vorlage zusammengeschustert habe, da  sind noch ein paar Ausgaben im verbose 4 drin gewesen, die wirklich niemandem weitergeholfen hätten, die ich aber brauchte, um erst mal selber zu verstehen, was da in etwa abgeht ...

Hab's jetzt moderat angepaßt und hoffe, dass es dann auch noch funktioniert, wenn es wirklich mal einer brauchen sollte (das ist eine sehr spezielle Spezialfunktion, die man nur ernsthaft testen kann, wenn man mit der passenden Hardware rumoperiert oder sehr clever ist, was das Programmieren von Testsoftware angeht ).

Ansonsten habe ich set in die Richtung umgebaut wie vorgeschlagen, den Start timerbasiert verzögert (und notifyfn in MYSENSORS ganz ausgebaut), noch ein paar "each" verjagt und den Rest hoffentlich nicht kaputtgemacht .

Dateien zum Testen wie immer im ersten Post.

[Beta-User]

Ich weiß noch nicht wie ich es geschafft habe - vermutlich dunkle Experimente mit Mysensors (ohne Codeänderungen jedoch) - aber
[...]
Best guess ist, dass ich irgendwo was hardwaremäßig noch nicht richtig konfiguriert habe.

Code Auswählen Erweitern

MYSENSOR_0 erscheint.
Zumindest sind solche undefines vorher nicht aufgetaucht im Log.

Vorab mal OT: Das "zuckt" ja zumindest schon mal. Gratuliere!
Was diese "spezielle" Node angeht, solltest du dir nicht die großen Gedanken machen, das ist im wesentlichen (meistens(!)) unnützes "Beiwerk"; diese sind "0"-er Devices bei mir alle in einem "unused-devices"-Raum (ich habe mehrere GW's definiert).

K.A., wie deine Dunklen Experimente aussahen, aber bei mir erscheinen weder früher noch jetzt derartige Einträge und "trim" konnte ich im Quellcode auch nicht finden...

Ok. ShuttersControl schafft das vielleicht noch nicht, aber so ein MySensors/* kommt sicher bald hin.

Nett, dass du das dort schreibst, hier aber meine entsprechenden Anfragen nicht mal mit einem "warte noch" kommentierst (falls wir über dieselben Code-Teile sprechen (?)). Den Mehrwert der Aufsplittung wollte man mir "am anderen Ort" auch nicht erläutern (ich sehe da heute das erste Mal einen vielleicht nachvollziehbaren inhaltlichen Punkt...), und ehrlich gesagt ist mir diese "one in all"-Lösung mit den nur noch zwei Modulen/Dateien sehr viel sympatischer. Aber vielleicht schaffst du es ja, mir den Sinn dieser Aktion an sich und der Testerei im speziellen an einem Modul (=MySensors) zu erläutern, dessen Funktionalitäten ich halbwegs verinnerlicht habe...

[RichardCZ]

Nett, dass du das dort schreibst, hier aber meine entsprechenden Anfragen nicht mal mit einem "warte noch" kommentierst

Ich dachte bei der Aussage an sowas wie

lib/Protocol/MySensors.pm

wo dann ein parse(), check() etc. drin sein kann, was ja wirklich unabhängig von FHEM ist. Z.B. wenn man "mal eben" einen Protokoll Sniffer an die Leitung hängen möchte.
Und vielleicht könnte sowas ja auch MisterHouse gebrauchen.

[Beta-User]

Nun ja, das mag ja sein, aber ich hatte das Thema "reuse elsewhere" explizit angefragt (was zumindest bisher im FHEM-Kontext nicht so einfach ging und schlicht nicht gelebte Praxis war...).
Mein Thema ist daher weniger die Frage, ob es ggf. (sehr kleine...) Teile gibt, die teilbar sind, sondern eher, warum da kein "lass es" kam. Selbst wenn du sowas als "obvious" ansiehst: Ich stelle solche Frage deswegen, weil das aus meiner Warte nicht zwangsläufig obvious ist.

Was das sniffen angeht: Ich sehe auch kein Problem, z.B. ein RAW-Event-feature einzubauen wie in MQTT2_SERVER. Dann bekommt man die Daten innerhalb FHEM angezeigt (und könnte daran auch problemlos was anflanschen. Ich hatte aber in ca. 5 Jahren MySensors-Nutzung nie den großen Bedarf für sowas... OK, vielleicht sähe ich das heute anders, meine "Kenntnisse" sind auch andere jetzt.).