Fehlerfreier Zugriff auf $EVTPART{ID} in Notify

[FHEMAN]

Ich möchte das sicher vielen negativ bekannte Thema hier einmal als Wunsch reinstellen:

Zugriff auf nicht vorhandene EVTPARTs soll einen Leerstring zurückgeben

Ich denke, ich muss nicht erklären, warum es angenehmer ist, hier keine Fehlermeldung zu bekommen. Der Hintergrund für diese Zugriffsverletzung ist soweit klar. Auch, dass es eher eine Unschönheit ist. Dennoch hoffe ich auf anders lautende Lösungen, als ein paar Perl Schleifen in der myUtils zu drehen.. mit dem Ziel, es für den User so einfach wie möglich zu halten.

Da ich davon ausgehe, dass bei einigen FHEM Usern wahre Schätze in der fhem.cfg schlummern, hat genau hierfür bestimmt schon jemand eine schöne Lösung implementiert. Den würde ich gerne bitten, sein Wissen zu teilen!!

Danke und Gruß
Ronny

[igami]

du kannst einen one-liner daraus machen

Code Auswählen Erweitern


$EVTPARTX?$EVTPARTX:0

Aber das Problem verstehe ich nicht, bzw. habe ich nicht. Meine notifys sind so angelegt, dass nur das Event ausgewertet wird, was ich haben möchte und dann gibt es auch den Eventpart den ich haben möchte.

[betateilchen]

Ich möchte das sicher vielen negativ bekannte Thema hier einmal als Wunsch reinstellen:

Zugriff auf nicht vorhandene EVTPARTs soll einen Leerstring zurückgeben.

Davon halte ich nicht viel. Ein Leerstring ist immer noch ein programmtechnisch verwendbarer Rückgabewert, der in diesem Fall ein falsches Ergebnis provozieren würde.

Viel besser fände ich eine Lösung, die mitteilt, wieviele EVTPARTs es überhaupt gibt. Beispielsweise eine $sepcials{EVTPARTCOUNT}. Dann kann ich die das in eigener Verantwortung in einem notify oder wo auch immer in einem Oneliner auswerten.

[FHEMAN]

Davon halte ich nicht viel. Ein Leerstring ist immer noch ein programmtechnisch verwendbarer Rückgabewert, der in diesem Fall ein falsches Ergebnis provozieren würde.

Wäre ein Leerstring nicht eindeutig? Ich meine, es kann einem Notify doch kein Parameter "Leerstring" übergeben werden? Oder meinst Du, weil bei numerischen Operationen dann fälschlicherweise 0 angenommen wird?

Viel besser fände ich eine Lösung, die mitteilt, wieviele EVTPARTs es überhaupt gibt. Beispielsweise eine $sepcials{EVTPARTCOUNT}. Dann kann ich die das in eigener Verantwortung in einem notify oder wo auch immer in einem Oneliner auswerten.

Das fände ich genau so gut. Hauptsache ein Oneliner und nicht immer die gleichen Schleifchen in jedem Notify.

[herrmannj]

kann da auch nicht ganz folgen: undef ist doch absolut eindeutig.

Bin voll bei Igami und Betateilchen:

du kannst einen one-liner daraus machen

Code Auswählen Erweitern


$EVTPARTX?$EVTPARTX:0

Aber das Problem verstehe ich nicht, bzw. habe ich nicht. Meine notifys sind so angelegt, dass nur das Event ausgewertet wird, was ich haben möchte und dann gibt es auch den Eventpart den ich haben möchte.

Igamis Lösung ist imho absolut korrekt: Willst Du wissen ob das event existiert teste auf undef. Ansonsten musst Du doch wissen wofür Du das notify schreibst - sprich was Du erwartest. Fehlerbehandlung nach dem Vorschlag von Igami mit dem default (der ja keinesfalls immer 0 oder leerstring sein muss!) nach dem Doppelpunkt ..

vg
joerg

[FHEMAN]

Als konkretes Beispiel verwende ich EVTPART gerade in einem cmdalias. Dabei kann es vorkommen, dass ich einen zweiten Parameter übergebe. Aber eben nicht immer.
Die Abfrage

Code Auswählen Erweitern

if ($EVTPART2) oder

Code Auswählen Erweitern

if(defined $EVTPART2) liefert bei mir die Fehlermeldung. Etwas anderes ist

Code Auswählen Erweitern

$EVTPARTX?$EVTPARTX:0 doch auch nicht, nur eine andere if Notation?

[betateilchen]

Als konkretes Beispiel verwende ich EVTPART gerade in einem cmdalias.

Dann poste doch mal das "konkrete Beispiel". Denn für die Verwendung in cmdalias ist EVTPARTx eigentlich nicht gedacht.

Der Vorschlag von igami ist nicht schlecht, er wird aber auch zu einer perl Warnung führen, wenn EVTPARTx gar nicht existiert.
Stattdessen würde ich lieber folgendes verwenden, um zu prüfen, ob eine Variable überhaupt existiert und einen default-Wert zurückzuliefern, falls nicht:

Code Auswählen Erweitern

$EVTPARTx //= <defaultWert>;

[FHEMAN]

Stattdessen würde ich lieber folgendes verwenden, um zu prüfen, ob eine Variable überhaupt existiert und einen default-Wert zurückzuliefern, falls nicht:

Code Auswählen Erweitern

$EVTPARTx //= <defaultWert>;

Das funktioniert leider auch nicht, da $EVTPARTx bei meinen Tests dann grundsätzlich den Default Wert annimmt.

Mein Workaround sieht nun folgendermaßen aus, vielleicht hilft es manch anderen (auch wenn sich scheinbar niemand daran stört ):

Code Auswählen Erweitern


if (my $EVTP2 = (split(/\s+/,$EVENT))[2]) {
fhem("setreading A B " . $EVTP2);
}

Wichtig war mir, Code und Abfragen zu reduzieren.

Hat jemand noch einen anderen, besseren (fertigen) Lösungsvorschlag hierzu?

[betateilchen]

Das ist das Vorgehen bei Perfunktionen mit optionalen Parametern, richtig?

Nicht wirklich. Aber es kann Dir bei Deinem obskuren Vorhaben vielleicht weiterhelfen.

[FHEMAN]

Meinst du mir "obskur" mein Vorhaben selbst oder wie ich es versuche zu lösen? Unabhängig davon bin ich dadurch mal wieder über das nervige EVENTPARTS Usage gesteuert und plädiere immer noch dafür, hier schon im Standard eine Lösung bereitzustellen. Meiner Meinung nach stolpert da jeder FHEM User schon nach den ersten Notify Gehversuchen drüber und muss sich dann um einen Workaround kümmern. Und das muss ja nicht sein.

[betateilchen]

Meiner Meinung nach stolpert da jeder FHEM User schon nach den ersten Notify Gehversuchen drüber

Ich bin in all den Jahren, in denen ich mich mit fhem beschäftige, noch nie darüber gestolpert, weil ich noch nie auf die Idee kam, überhaupt mit EVTPARTx zu arbeiten. In meinen notify und Funktionen verwende ich immer den gesamten EVENT und splitte den selbst auf, dann habe ich alle Informationen, die ich brauche, inklusive der Anzahl der Elemente.

[betateilchen]

Ausserdem ist und bleibe eine "PERL Warning" eine einfache Warnung und ist noch lange kein Fehler. Warum man um solche Warnungen immer wieder so ein Drama hier im Forum machen muss, wird sich mir in diesem Leben wohl nicht mehr erschließen. Noch dazu, wo man die Warnung auch einfach abschalten könnte, wenn man sie wirklich loswerden will.

[FHEMAN]

... ich noch nie auf die Idee kam, überhaupt mit EVTPARTx zu arbeiten.

Es wird angeboten. Also sollte es doch auch fehlerfrei funktionieren. Nur, weil jeder sein Problem einfach auf eigene Faust umschiffen kann, muss dies ja keine gute Lösung darstellen. Und unsinnige Fehler im Log sollten meiner Meinung nach ebenfalls weitestgehend vermieden werden. Aber das ist eine Grundsatzfrage, die ich, mit Verlaub, besonders mit Dir, lieber betateilchen, nicht klären möchte.

Warum man um solche Warnungen immer wieder so ein Drama hier im Forum machen muss ...

Ich finde es ziemlich schade, dass ein Drama um manche Verbesserungswünsche gemacht wird. Und seien sie für den erfahrenen, langjährigen FHEM User noch so klein, minderwertig und unnötig. Selbstredend verdient hier keiner Geld mit solchen Anpassungen. Aber sollte es nicht im grundsätzlichen Interesse sein, das Produkt an allen Stellen stabiler und robuster zu machen?

[FHEMAN]

Stattdessen würde ich lieber folgendes verwenden, um zu prüfen, ob eine Variable überhaupt existiert und einen default-Wert zurückzuliefern, falls nicht:

Code Auswählen Erweitern

$EVTPARTx //= <defaultWert>;

Das funktioniert leider auch nicht, da $EVTPARTx bei meinen Tests dann grundsätzlich den Default Wert annimmt.

Mein Workaround sieht nun folgendermaßen aus, vielleicht hilft es manch anderen (auch wenn sich scheinbar niemand daran stört ):

Code Auswählen Erweitern


if (my $EVTP2 = (split(/\s+/,$EVENT))[2]) {
fhem("setreading A B " . $EVTP2);
}

Wichtig war mir, Code und Abfragen zu reduzieren.

Hat jemand noch einen anderen, besseren (fertigen) Lösungsvorschlag hierzu?