[gelöst] CommandDeleteReading löscht readings im BlockingCall nicht

[KölnSolar]

Guten Morgen,
ich habe ein seltsames Problem mit commandDeleteReading in meinem neuen Modul. Es löscht die Readings nicht, obwohl das Löschen protokolliert wird. Ich hab jetzt extra meinen ursprünglichen Funktionsaufruf etwas umgebaut, um die Returnwerte zu loggen.

Code Auswählen Erweitern

my $vartemp = "$hash->{NAME} Warn_0".$i."_.*";
Nina_Log $hash, 3, "String before deletereading: $vartemp";
$vartemp = CommandDeleteReading(undef, $vartemp);
Nina_Log $hash, 3, "return string after deletereading: $vartemp";
ergibt

Code Auswählen Erweitern

2019.08.13 21:31:30 3: Nina NinaTest: preparemessage.725 String before deletereading: NinaTest Warn_00_.*
2019.08.13 21:31:30 3: Nina NinaTest: preparemessage.727 return string after deletereading: Deleted reading Warn_00_ShortText for device NinaTest
Deleted reading Warn_00_EventID for device NinaTest
Deleted reading Warn_00_Event for device NinaTest
Deleted reading Warn_00_End for device NinaTest
Deleted reading Warn_00_Sendername for device NinaTest
Deleted reading Warn_00_MsgType for device NinaTest
Deleted reading Warn_00_Color for device NinaTest
Deleted reading Warn_00_Geocode for device NinaTest
Deleted reading Warn_00_Category for device NinaTest
Deleted reading Warn_00_Sender for device NinaTest
Deleted reading Warn_00_LongText for device NinaTest
Deleted reading Warn_00_Contact for device NinaTest
Deleted reading Warn_00_Instruction for device NinaTest
Deleted reading Warn_00_Severity for device NinaTest
Deleted reading Warn_00_Area for device NinaTest
Deleted reading Warn_00_Distance for device NinaTest
Deleted reading Warn_00_Creation for device NinaTest

Das ist aber "gelogen". Nachdem später(im Done-Teil eines BlockingCall)  die readings Warn_00_... (aber ohne z.B. Warn_00_Color !) neu angelegt werden, sehen die readings so aus:

Code Auswählen Erweitern

setstate NinaTest 2019-08-13 21:31:30 Warn_00_Area Harburg
setstate NinaTest 2019-08-13 21:31:30 Warn_00_Category Safety
setstate NinaTest 2019-08-02 18:32:43 Warn_00_Color orange
setstate NinaTest 2019-08-13 21:25:09 Warn_00_Contact Landesamt für Umwelt Brandenburg Referat Hydrologischer Landesdienst
setstate NinaTest 2019-08-13 21:31:30 Warn_00_Creation 2019-07-04T09:34:32+02:00
setstate NinaTest 2019-08-13 21:31:30 Warn_00_Distance 39.6020646227158
setstate NinaTest 2019-08-13 21:31:30 Warn_00_End 2019-09-04T09:24:00+02:00
setstate NinaTest 2019-08-13 21:31:30 Warn_00_Event 8
setstate NinaTest 2019-08-13 21:31:30 Warn_00_EventID BIWAPP-36637
setstate NinaTest 2019-08-13 21:31:30 Warn_00_Geocode Harburg
.
.

Wie man schon am timestamp sieht, sind readings wie z.B. Warn_00_Color "übrig" geblieben, obwohl sie doch gelöscht wurden. 

Einzige Idee der Ursache wäre der BlockingCall. Aber auch im Run-Teil bleibt das Problem bestehen. 

Werden die readings Warn_00_... nicht neu aufgebaut, funktioniert deren Löschung wie es sein soll.

Hat jemand eine Idee ?

Grüße Markus

[CoolTux]

Hallo Markus,

Das geht so nicht. Im BlockingCall wird ein Fork der laufenden Instanz gemacht. Und nur darin löschst Du die Readings. Aber der Fork wird ja am Ende gekillt und die Daten welche Du im Fork erhalten hast an den Elternprozess übertragen. Aber keine Änderungen innerhalb von FHEM.


Grüße

[rudolfkoenig]

Anders ausgedrueckt: wenn man im "richtigen" FHEM-Prozess was aendern will, muss man das aus dem BlockingCall "sagen" und dadurch hier veranlassen.
Entweder zum Schluss per finishFn, oder per BlockingInformParent.

Idealerweise meidet man BlockingCall, und verwendet stattdessen NonBlocking IO.
Insb. sowas wie eine Webseitenabfrage sollte das einfacher sein, als BlockingCall.

[KölnSolar]

Hi Cooltux,
schön, dass Du Dich meldest. Bei meiner Analyse hatte ich diese Empfehlung von Rudi gefunden, commandDeleteReading nicht in Modulen einzusetzen. Wollen wir das in UWZ u. Nina umbauen ?

Zu meinem Problem: Dachte ich es mir. Ich könnt schwören, dass es aber auch im Done-Teil nicht funktioniert hatte. Soll ich das Löschen dort noch einmal testen ?

Grüße Markus

Edit: Danke Rudi. Ich versuch das dann heute Abend mal zu verstehen. 

[CoolTux]

Hi Cooltux,
schön, dass Du Dich meldest. Bei meiner Analyse hatte ich diese Empfehlung von Rudi gefunden, commandDeleteReading nicht in Modulen einzusetzen. Wollen wir das in UWZ u. Nina umbauen ?

Zu meinem Problem: Dachte ich es mir. Ich könnt schwören, dass es aber auch im Done-Teil nicht funktioniert hatte. Soll ich das Löschen dort noch einmal testen ?

Grüße Markus

Edit: Danke Rudi. Ich versuch das dann heute Abend mal zu verstehen. 

Wäre ja CommandDeleteReading() nur durch readingsDelete() zu ersetzen. Können wir gerne machen.


Grüße

[KölnSolar]

Nicht ganz, oder ? readingsDelete() löscht ja nur genau ein reading.

Ich habs mal in Anlehnung an CommandDeleteReading() als Funktion so definiert:

Code Auswählen Erweitern

sub Nina_deletewarning($$) {

    my ( $hash, $readingspec ) = @_;

    my $message="";

    foreach my $reading (grep { /$readingspec/ }
                                keys %{$hash->{READINGS}} ) {
       readingsDelete($hash, $reading);
       $message .= "$reading \n"
    }

     $message = "deleted readings: $message" if($message);

     return $message;
}

mit call

Code Auswählen Erweitern

    my $param =  "^Warn_0${Counter}_.*".'$';
my $message = Nina_deletewarning($hash,$param);
Nina_Log $hash, 5, $message if ($message);


Mein Problem ist dann auch gelöst. Ich hatte tatsächlich bereits früher das Löschen in der finishFn gemacht. Hatte aber dort "seltsame" Ergebnisse. Nun ist mir klar geworden was mein Problem war: Mir war nicht bewusst, dass meine in konkreter Reihenfolge übergebenen Daten der blockingFN  und Übertragung dieser Daten an einen Hash in der finishFn im Hash dann in undefinierter Reihenfolge vorliegen.

Danke Euch beiden.