PERL WARNING: Use of uninitialized value in string ne at fhem.pl line 3918.

[rapster]

Hallo Rudi,

dieses Warning wird erzeugt wenn ein Reading mit einem Leerstring nach einem fhem-restart gesetzt/geändert wird und event-on-change-reading aktiv ist.

Code Auswählen Erweitern


define dummy dummy
attr dummy event-on-change-reading .*
{ readingsSingleUpdate($defs{dummy},"r","",1) }
save
shutdown restart
{ readingsSingleUpdate($defs{dummy},"r",1,1) }


Gruß
  Claudiu

[betateilchen]

Man setzt keine readings mit einem Leerstring!

[rapster]

Es geht nicht darum dass ich Leerstrings setzen möchte,
sondern dass ich Module anderer Entwickler verwende in denen nunmal Leerstrings gesetzt werden,
aus welchen Gründen auch immer.

Das Warning taucht nunmal bei jedem Fhem-Start dadurch bei mir auf

[rudolfkoenig]

betateilchen hat zwar Recht, allerdings sollte das nicht Claudiu ausbaden.
Habe fhem.pl gefixt und eingecheckt.

[rapster]

Danke

[Reinerlein]

Hallo Rudi, hallo betateilchen,

da hätte ich aber mal eine Frage zu der Bemerkung: warum soll ein Reading nicht mit einem Leerstring belegt werden?

Es gibt mittlerweile einige Module, die textuelle Informationen aus Fremdevices darstellen. In meinem Fall Sonos.
Natürlicherweise darf ein Text auch leer sein, so ist eine Zeichenfolge nunmal definiert. Da diese frei vom Anbieter (in meinem Fall Sonos) festgelegt werden, hat man ja noch nichtmal Einfluss auf den Inhalt.

Was sollte denn sonst mit leeren Texten passieren?

Grüße
Reiner

[betateilchen]

Ein reading ohne Inhalt sollte schlichtweg gar nicht existieren. Man kann den Leerstring immer noch als "defaultwert" bei ReadingsVal() in dem Moment generieren, wenn man den Readingwert tatsächlich benutzt.

[herrmannj]

hmm. Da vertrete ich den Standpunkt von Reiner, der ist logisch und schlüssig.

Im Kontext der Programmierung ist es doch durchaus entscheidend ob ein reading existiert und "empty" ist, oder ob es überhaupt nicht existiert. Mit dem fix von Rudi wird das glücklicherweise zur akademischen Frage. Danke.

vg
joerg

[rudolfkoenig]

Bei der akademischen Frage habe ich nach etwas Nachdenken auch meine Meinung geaendert.

[betateilchen]

Ich habe mir den Fix noch nicht angeschaut, soll das heissen, dass nun auch inhaltslose readings existieren dürfen? Das brächte die Logik einiger meiner Anwendungen völlig durcheinander.

Wenn dem tatsächlich so sein sollte, sollte man eine solche gravierende Änderung besser mit etwas Vorlauf ankündigen und nicht übers Knie gebrochen einfach einführen.

[Reinerlein]

Hallo,

ich glaube, hier gibt es ein falsches Verständnis von "Inhaltslos".
Ein String ist eine Zeichenkette, die in einem Fall eben auch kein Zeichen enthalten darf. Damit ist sie aber nicht Inhaltslos, sondern enthält die Information, dass an dieser Stelle eine Zeichenkette ohne Zeichen steht.

Inhaltslos ist in Perl als undef repräsentiert, und sagt aus, dass hier "nichts" drin ist. Also auch keine Zeichenkette...

Das Verhalten hat sich doch jetzt nicht maßgeblich verändert. Ich denke Rudi hat lediglich eine zusätzliche Prüfung für den ne-Vergleich bei Event-On-Change-Reading eingebaut.
Beim Sonos-Modul zumindest gibt es die leeren Strings nun schon fast drei Jahre, und Fhem (bzw. der jeweilige Benutzer davon) hatte bislang keine Probleme damit...

Grüße
Reiner

[betateilchen]

Es hat auch schonmal jemand mit mir darüber diskutiert, ob es kleine und große Leerzeichen gibt...

[Markus Bloch]

Es hat auch schonmal jemand mit mir darüber diskutiert, ob es kleine und große Leerzeichen gibt...

Oha, das wird mir eindeutig zu philosophisch....

Zum Thema: In meinen Yamaha-Modulen setze ich auch leere Readings, für die currentTitle,currentInterpret,currentAlbum,... -Readings. Wenn der Receiver auf Radio steht, werden alle anderen current*-Readings auf "" gesetzt,welche nicht für Radio anwendbar sind, damit nicht alte Daten in den Readings stehen, die nicht zum aktuellen Eingang gehören.

Die nicht anwendbaren Readings könnte man auch komplett löschen, aber dann fragen wieder alle, "wo sind denn die Readings?" und daher habe ich es so gelöst.

Was wäre denn dein Vorschlag?

Gruß
Markus

[betateilchen]

Was wäre denn dein Vorschlag?

Bei mir werden nur readings gesetzt, die auch einen "nutzbaren" Inhalt haben. Und ein Leerstring ist für mein Empfinden kein nutzbarer Inhalt. (Erinnert mich an die Bundeswehr: "Herr Oberst, ich melde, dass es nichts zu melden gibt!")

Das Thema "fehlende readings" ist für mich keines, da ReadingsVal() bei der Auslieferung eines Defaultwertes kein Problem mit nicht vorhandenen readings hat. Und bisher hatte kein Nutzer meiner Module ein Problem damit, dass ein reading wegen fehlender Nutzdaten nicht vorhanden war. Es gab diesbezüglich noch nie eine Rückfrage.

Für den Fall, dass ReadingsVal() bei einem reading auch einen Leerstring vorfinden könnte, läßt sich der Defaultwert immer noch auf "" definieren, wenn das Reading einfach nicht vorhanden wäre.

Der Sinn eines readings, in dem einfach nix drinsteht, wird sich mir nie erschließen.

[herrmannj]

Das Beispiel von Reiner und Markus zeigt doch sehr wohl einen sinnvollen Einsatz.

Ein Analogie ist mein Briefkasten als der Ort wo die Post reinkommt. Der Briefkasten ist dabei immer vorhanden, unabhängig davon ob der Briefträger etwas rein legt - oder auch nicht.

Es würde ja auch keinen Sinn machen den Briefkasten zu entfernen nur weil keine Post da ist. Die Readings müssten in diesem Fall ja ebenfalls aktiv entfernt werden. Das macht keinen Sinn.

Im übrigen ist eine Prüfung ob ein Reading vorhanden ist doch problemlos möglich: ReadingsVal (name, reading, undef) gibt "undef" wenn das reading nicht vorhanden ist.

vg
joerg