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.
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:
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:
fhem("setreading myRaspberry ipAddress $txt");Die betreffenden Readings werden jedoch von der Kommandozeile aus korrekt geschrieben:
{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?
Zitat von: DocCyber am 13 Dezember 2023, 13:19:23Zum 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.
Zitat2023.12.13 12:52:39 1: ERROR evaluating my $SELF= $evalSpecials->{'%SELF'};{updateRaspberry()}: Undefined subroutine &main::updateRaspberry called at (eval 309) line 1.
Zitatsub updateRasperry() {
Zitat von: frank am 13 Dezember 2023, 13:34:00das glaube ich nicht.
Ich habe soeben erneut jeden einzelnen Befehlsblock in die Kommandozeile eingegeben. Sämtliche Rückgabewerte werden wie erwartet zurückgegeben.
Zitatsub 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.
updateRasperry ist nicht gleich updateRaspberry
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.
ZitatZum 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.
bei problemen mit setreading würde ich auf verdacht immer mit fhem-sleep testen:
fhem("sleep 0.1; setreading myRaspberry ipAddress $txt");
Zitat von: frank am 13 Dezember 2023, 14:56:51bei problemen mit setreading würde ich auf verdacht immer mit fhem-sleep testen
Danke, das versuche ich mal - warum schlägst du das vor?
setreading ist halt speziell.
commandref sagt zb:
ZitatNote: 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.
Zitatsetreading 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.