CommandDelete Quelle für ghost devices und ghost Attribute

[noansi]

Hallo Rudolf,

bei der Anwendung von CommandDelete können ghost devices und ghost Attribute unter "Mithilfe" von Modulentwicklern entstehen.

Ab fhem.pl Zeile 2398

Code Auswählen Erweitern

    delete($attr{$sdev});
    delete($defs{$sdev});
    delete($oldvalue{$sdev});
    DoTrigger("global", "DELETED $sdev", 1) if(!$temporary);

  }
  return join("\n", @rets);
}
werden die device Attribute und der device hash entfernt.
Dann wird der DELETED Trigger auf alle geladenen Module losgelassen.

Und damit hatte ich nach Anwendung eines 'delete CUNO2_WS868_One' Befehls im Log

Code Auswählen Erweitern

2026.10.03 10:08:21.826 1: Error devspec2array .*: >CUNO2_WS868_One< has no TYPE, but following keys: ><
Das gelöschte device war ein SVG Plot. Das SVG device hatte damit aber rein gar nichts zu tun.

Ursache war 10_CUL_HM.pm, welches auf den DELETED Trigger hin nochmal auf den device hash zugreifen wollte, um IOs ein potentielles Löschen eines HM-devices mitzuteilen (erforderlich).
Anmerkung: Statt dies über die UndefFn oder DeleteFn zu tun, wo der device hash noch exisitert siehe hier https://forum.fhem.de/index.php?msg=1369765.

Daher die Anregung zum Aufräumen und Bescheid geben als Änderung in fhem.pl:

Code Auswählen Erweitern

      delete($attr{$sdev}); #noansi: this delete may not persist
      delete($defs{$sdev}); #noansi: this delete may not persist
      delete($oldvalue{$sdev});
      DoTrigger('global', "DELETED $sdev", 1) if(!$temporary);
      if (defined($attr{$sdev})) {
        Log 1, "'CommandDelete $def' resulted in ghost attributes due to DELETED trigger! Notify modules maintainers of loaded modules to check NotifyFn!";
        delete($attr{$sdev}); #noansi: delete again
      }
      if (defined($defs{$sdev})) {
        Log 1, "'CommandDelete $def' resulted in ghost device due to DELETED trigger! Notify modules maintainers of loaded modules to check NotifyFn!";
        delete($defs{$sdev}); #noansi: delete again
      }

Damit werden ggf. entstandene ghost Einträge wieder entfernt und deutlich auf die Problemursache mit Behebungsmotivation aufmerksam gemacht.
Spezifischer lässt es sich an dieser Stelle nicht eingrenzen, welches Modul ein Problem macht. Nur das Log drumherum kann Hinweise liefern.


Im 10_CUL_HM.pm Fall sind es 'PERL WARNING: Use of uninitialized value in string eq at /opt/fhem/FHEM/10_CUL_HM.pm line' Log Einträge, die dann hier ab Zeile 1638

Code Auswählen Erweitern

    elsif ($evnt =~ m/^(DELETED|RENAMED) (.*?) ?/){
      my ($cmd,$ent,$new) =split(" ",$evnt." ");
      # $ent no longer exist
      # $new is the renamed (if rename)
      if (($evnt eq "DELETED" && $defs{$ent}{TYPE} eq "CUL_HM")
über '$defs{$ent}{TYPE}' ihren Ursprung haben und den gelöschten device Hash gleichzeitig neu entstehen lassen.
Die Semantik von DELETED im Sinne von "Hash exisitert wirklich nicht mehr" wurde nicht verstanden oder bedacht.
Das kann beim Programmieren sicherlich leicht passieren, aber deswegen sollten ghost hashes nicht Probleme an ganz anderer Stelle erzeugen.

Gruß, Ansgar.