Fehlermeldung trotz korrekter Befehle?

[DocCyber]

Hallo zusammen.

Ich habe zwei Fehlerkategorien, die möglicherweise zusammenhängen.

Zum einen finde ich einen Fehler im Logfile, obwohl die im Skript verwendeten Befehle auf der FHEM-Kommandozeile jeweils fehlerfrei ausgeführt werden.

Code Auswählen Erweitern

2023.12.13 12:52:39 1:  ERROR evaluating my $SELF=   $evalSpecials->{'%SELF'};{updateRaspberry()}: Undefined subroutine &main::updateRaspberry called at (eval 309) line 1.
Der Fehler taucht hier auf:

Code Auswählen Erweitern

sub updateRasperry() {
  # System abfragen
  # ---------------
  # * Hostname des RPi
  my $txt = qx(hostname);
  fhem("set myRaspberry $txt");
 
  # * IP-Adresse
  $txt = qx(hostname -I);
  my @words = split(/\s+/, $txt);
  $txt = $words[0];
  fhem("setreading myRaspberry ipAddress $txt");

  # * Raspberry Modell
  $txt = qx(cat cat /sys/firmware/devicetree/base/model);
  # Rückgabe ohne das erste Wort ('Raspberry')
  $txt =~ s/^[^ ]* //;
  fhem("setreading myRaspberry model $txt");
 
  # * Installationsdatum (Annahme: Datum ist das von /boot/overlays)
  $txt = qx(date -r /boot/overlays +"%d.%m.%Y");
  fhem("setreading myRaspberry installDate $txt");
 
  # * Freier Speicherplatz auf der SD-Karte
  # df (Disk Free) >> davon oberste zwei Zeilen >> davon die letzte Zeile
  $txt = qx(df -k | head -n 2 | tail -n 1);
  # Mit Regex  /\s+/  in einzelne Wörter aufspalten, die durch ein oder
  # mehrere Leerzeichen getrennt sein können.
  @words = split(/\s+/, $txt);
  # Das 4. Wort (Null-indexiertes Array) gibt den freien Speicherplatz,
  # der dann noch in Gigabyte umgerechnet und formatiert wird.
  $txt =sprintf("%.2f", $words[3]/1000000);
  fhem("setreading myRaspberry freediskspace $txt GB");
}


Zum zweiten stelle ich fest, dass das Schreiben von Readings immer mal wieder unterbleibt, wenn es aus einem Skript heraus erfolgt, also etwa so:

Code Auswählen Erweitern

fhem("setreading myRaspberry ipAddress $txt");Die betreffenden Readings werden jedoch von der Kommandozeile aus korrekt geschrieben:

Code Auswählen Erweitern

{fhem("setreading myRaspberry ipAddress $txt");;}Der Readings-Fehler ist allerdings leider nicht reproduzierbar.

Info
Zuvor hatte ich festgestellt, dass der Editor geänderten Code nicht immer zuverlässig gespeichert hatte, was ich auf SD-Kartenporblem zurückgeführt habe.
Deshalb habe ich vor wenigen Tagen eine brandneue SD-Karte installiert (Raspbian Bullseye Lite), ein FHEM-Backup erfolgreich zurückgespielt und ein FHEM-Update durchgeführt.


Wer hat Ideen, woran das liegen könnte?

[frank]

Zum einen finde ich einen Fehler im Logfile, obwohl die im Skript verwendeten Befehle auf der FHEM-Kommandozeile jeweils fehlerfrei ausgeführt werden.

das glaube ich nicht.

2023.12.13 12:52:39 1:  ERROR evaluating my $SELF=   $evalSpecials->{'%SELF'};{updateRaspberry()}: Undefined subroutine &main::updateRaspberry called at (eval 309) line 1.

sub updateRasperry() {

[DocCyber]

das glaube ich nicht.

Ich habe soeben erneut jeden einzelnen Befehlsblock in die Kommandozeile eingegeben. Sämtliche Rückgabewerte werden wie erwartet zurückgegeben.

sub updateRasperry() {

Natürlich bezieht sich das auf diese sub. Deshalb habe ich sie gepostet.

Aber ich kann auch beim x-ten Hinsehen und Prüfen keinen Fehler finden.

[rudolfkoenig]

updateRasperry ist nicht gleich updateRaspberry

[DocCyber]

Yow - Ich hab's in dieser Sekunde auch gesehen - nennt man wohl betriebsblind. 
Danke dir! 

Allerdings bleibt der zweite Teil meines ursprünglich Posts noch unbeantwortet.

[rudolfkoenig]

Zum zweiten stelle ich fest, dass das Schreiben von Readings immer mal wieder unterbleibt, wenn es aus einem Skript heraus erfolgt, also etwa so:

Moeglichkeiten:
- die Abarbeitug des Skripts bricht vorher ab. Die Ursache sollte im FHEM-Log stehen.
- das Skript wird gar nicht ausgefuehrt.
- die Abarbeitung wird vorher "normal" beendet.

[frank]

bei problemen mit setreading würde ich auf verdacht immer mit fhem-sleep testen:

Code Auswählen Erweitern

fhem("sleep 0.1; setreading myRaspberry ipAddress $txt");

[DocCyber]

bei problemen mit setreading würde ich auf verdacht immer mit fhem-sleep testen

Danke, das versuche ich mal - warum schlägst du das vor?

[frank]

setreading ist halt speziell.
commandref sagt zb:

Note: setreading won't generate an event for device X, if it is called from a notify for device X. Use "sleep 0.1; setreading X Y Z" in this case.

[rudolfkoenig]

setreading ist halt speziell.

Genaugenommen ist die Event-Generierung in FHEM speziell: um Endlosschleife zu vermeiden, kann man keine Events fuer Geraet X erzeugen, wenn man (direkt oder indirekt) von einem Geraet-X-Event getriggert ist.

setreading ist da nicht spezieller als set (oder trigger, usw).
Achtung: es geht nur um die Events: setreading wird weiterhin das Reading aendern, und set den Befehl ausfuehren, nur keine neuen Events mehr erzeugen.