edit...
Damit es erstmal wieder läuft:
https://wiki.fhem.de/wiki/Update#Update_ging_schief_-_restore_letzte_funktionierende_Version
Zitat von: fhempi am 06 April 2021, 14:00:45
Ist die neueste Version vom 10.03.21 ?
Wenn ja, dann sollte ich doch nicht der Einzige mit dem Problem sein ? Es sei denn, eine spezielle Config spielt hier eine Rolle
Was soll denn DIE neueste Version sein?
Es gibt quasi jeden Tag mindestens ein Update für ein Modul (s. https://svn.fhem.de/trac/browser/trunk/fhem?order=name). Insofern vermutlich nein, ist es nicht.
Poste doch mal das komplette Logfile von einem Versuch FHEM hochzufahren.
Du musst wohl oder übel im Debug Mode starten. Siehe Wiki https://wiki.fhem.de/wiki/FHEM_startet_nicht_-_Tipps_zur_Fehlersuche#Neue_M.C3.B6glichkeit_des_Debuggen
Da wird versucht eine main::GetUpdate Funktion auf zu rufen die es nicht gibt. Da hat sich entweder jemand verschrieben oder es ist noch was anderes.
Zitat von: fhempi am 06 April 2021, 15:50:56
Komme damit auch nicht weiter, nix besonderes im log zu sehen nach 3762 Zeilen
2021.04.06 15:19:24 5: End notify loop for d_RaumTemp
2021.04.06 15:19:24 5: End notify loop for global
2021.04.06 15:19:24 0: Featurelevel: 6
2021.04.06 15:19:24 0: Server started with 222 defined entities (fhem.pl:23613/2021-01-25 perl:5.028001 os:linux user:pi pid:16104)
dann kommt auf Konsolenebene wieder:
pi@fhem:/opt/fhem $ perl fhem.pl -d fhem.cfg > /home/pi/startlog.txt
Undefined subroutine &main::GetUpdate called at fhem.pl line 3379.
Hänge das doch mal hier an, vielleicht sehen die anderen ja mehr.
Man könnte in der 99_myUtils.pm eine sub GetUpdate() anlegen, dann verschwindet erstmal die Fehlermeldung und man kann nachschauen, was danach nicht funktioniert.
Wobei ich durchaus der Meinung bin, es müsste sich im Logfile irgendein Hinweis finden lassen, was die Meldung verursacht. Eventuell könnte auch stacktrace weiterhelfen.
Hast Du irgendwelche Module welche Du ausserhalb des FHEM SVN updatest? Also zusätzliche update Repositories?
Zeil mal ein update list
Ups Fehler
Das wird es auch nicht sein.
löschen mit
update delete https://raw.githubusercontent.com/klein0r/fhem-style-haus-automatisierung/version-2/controls_ha_theme.txt
Bei der Suche nach dem Fehler bin ich im übrigen auf andere Sachen gestoßen. Ist also nicht schlecht wenn man mal hier und da stöbert. Die Entwickler habe ich bereits informiert. Ich denke aber nicht das es etwas mit Deinem Problem zu tun hat.
Benutzt Du 47_OBIS? Ist das einzige wo ich etwas in der Richtung gefunden habe.
Dann lege am besten wirklich mal eine myUtils an mit einer Funktion mit dem Funktionsnamen. So wie Udo sagte. Danach schauen wir mal. Eventuell finden wir so raus wer da aufruft.
Lege erstmal nur die Sub an, mehr nicht. Damit startet dann hoffentlich erstmal FHEM
Ok. Dann mach mal bitte
sub GetUpdate {
my $hash = shift;
my $name = $hash->{NAME}
if( ref($hash) eq 'HASH'
and exists($hash->{NAME}
);
Log3( $name, 1, qq{DEBUG!!! myUtils Name ist $name} );
}
Wir versuchen es mal so
...my $foo = 'ba' if $baz?!?
Vielleicht eher caller?
https://kb.wisc.edu/iam/page.php?id=4309
(https://kb.wisc.edu/iam/page.php?id=4309)(und ergänzend mal ein grep nach der sub über die cfg laufen lassen kann auch nicht schaden)
Zitat von: Beta-User am 12 April 2021, 14:05:18
...my $foo = 'ba' if $baz?!?
Vielleicht eher caller?
https://kb.wisc.edu/iam/page.php?id=4309
(https://kb.wisc.edu/iam/page.php?id=4309)(und ergänzend mal ein grep nach der sub über die cfg laufen lassen kann auch nicht schaden)
Können wir dann auch gerne noch probieren.
irgendwie sieht mir das nach einer verwaisten myUtils-Geschichte aus, das grep sollte daher auch die myUtisl-Dateien umfassen.
Ansonsten: qed...
sub GetUpdate {
my ( $package, $filename, $line ) = caller();
Log3( $name, 1, qq{DEBUG!!! myUtils Name ist $filename, $package, $line} );
}
Hoffe das geht so. Ungetestet
eher:
sub GetUpdate {
my $parent = ( caller(1) )[3];
my $file = ( caller(1) )[2];
Log3( $name, 1, qq{DEBUG! myUtils Name ist $file, $parent} );
}Aber es sieht so aus, als käme man der Sache auch so näher...
Oder den caller-Stack noch um eines erhöhen.
Aber wenn es aus fhem.pl aufgerufen wird, klingt das danach, als wäre der Aufruf in der cfg zu finden.
Zitat von: fhempi am 12 April 2021, 14:23:17
Global symbol "$name" requires explicit package name (did you forget to declare "my $name"?) at ./FHEM/99_myUtils.pm line 35.
Ah, sorry, einfach undef statt $name (ohne Quotes).
Hab den Fehler gefunden. Steckt im 98_ComfoAir.pm.
Moment bitte.
ändere Zeile 395 in 98_ComfoAir.pm.
InternalTimer(gettimeofday()+1, "ComfoAir::GetUpdate", $hash, 0);
Ändere Zeile 804
InternalTimer(gettimeofday()+$hash->{INTERVAL}, "ComfoAir::GetUpdate", $hash, 0)
Ich werde Stefan einen Patch zukommen lassen
Ähm, das ist doch gepackaged!?!
Dann paßt dieser Befund mAn. nicht zu der Fehlermeldung aus dem ersten Post:
&main::GetUpdate
Oder findet da ein Export statt?
Zitat von: fhempi am 12 April 2021, 14:37:34
Ok, DANKE ! , geändert, scheint zu laufen :)
Wie war Deine ERSTE Version des subGetUpdate () ? um
2021.04.12 14:01:46 1: DEBUG!!! myUtils Name ist KWL
Dein Beitrag um 13:59 VOR der Änderung ? dabei kam der Hinweis auf KWL bzw. 98_ComfoAir ...
Keine Ahnung mehr.
Aber nun lösche erstmal die myUtils Funktion und dann schauen wir mal ob es noch läuft
Wo kommt KWL her?
Nochmal: Diese Funktion von Stefan ist es vermutlich eher nicht, und es macht beim Starten ggf. Sinn, direkt ein update anzufordern.
Falls KWL die Vorgängerversion war von dem ComfAir-Ding: Diese (99-utils?) Datei umbenennen!
schau mal, ob du noch ein "WHR962" definiert hattest.
Ah, sorry, das deckt sich nicht mit dem patch:
Zitat von: CoolTux am 12 April 2021, 14:31:31
ändere Zeile 395 in 98_ComfoAir.pm.
InternalTimer(gettimeofday()+1, "ComfoAir::GetUpdate", $hash, 0);
Ändere Zeile 804
InternalTimer(gettimeofday()+$hash->{INTERVAL}, "ComfoAir::GetUpdate", $hash, 0)
Da scheint im Original die erste Fassung so gestanden zu haben:
InternalTimer(gettimeofday()+1, "GetUpdate", $hash, 0);@CoolTux: Vermutlich ist das mit +1 schon gewollt, nur der Verweis geht ins Leere und sollte entweder mit dem Package-Prefix sein wie vorgeschlagen, oder eben dann als Funktionsreferenz übergeben werden:
InternalTimer(gettimeofday()+1, \&GetUpdate, $hash, 0);
...dachte ich mir auch, nachdem ich die Diskrepanz zwischen dem Post hier und dem Patch gesehen habe - siehe meinen editierten Vorpost...
InternalTimer(gettimeofday()+1, "GetUpdate", $hash, 0);
Dieser Aufruf der Funktion InternalTimer sorgt dafür das die Funktion GetUpdate im main Kontext aufgerufen wird. Das ist aber falsch. Denn die Funktion liegt im package Kontext von ComfoAir
ACHTUNG!!! Das sind 2 unterschiedliche Zeilen welche geändert werden müssen
:o
Oh, sorry, wer lesen kann ist klar im Vorteil... ::)
Sollte aber m.E. trotzdem eher als Funktionsreferenz übergeben werden...
InternalTimer(gettimeofday()+1, \&GetUpdate, $hash, 0);
Zitat von: Beta-User am 12 April 2021, 15:03:48
:o
Oh, sorry, wer lesen kann ist klar im Vorteil... ::)
Sollte aber m.E. trotzdem eher als Funktionsreferenz übergeben werden...
InternalTimer(gettimeofday()+1, \&GetUpdate, $hash, 0);
Nein das wäre auch falsch!
Aha...
Jedenfalls bei WeekdayTimer und anderen klappt das:
https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/98_WeekdayTimer.pm#L146
Zitat von: Beta-User am 12 April 2021, 15:19:43
Aha...
Jedenfalls bei WeekdayTimer und anderen klappt das:
https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/98_WeekdayTimer.pm#L146
$hash->{UpdFn} = \&WeekdayTimer_Update;
Weil Du das hier machst
Nein. Es klappt, weil es im selben namespace ist...
Z.b. RHASSPY kennt keine UpdFn: https://github.com/drhirn/fhem-rhasspy/blob/0.4.7b/10_RHASSPY.pm#L361 (https://github.com/drhirn/fhem-rhasspy/blob/0.4.7b/10_RHASSPY.pm#L361), RandomTimer auch nicht: https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/98_RandomTimer.pm#L165 (https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/98_RandomTimer.pm#L165)
bedeutet das die Referenz \&Subname das selbe wäre wie PACKAGENAME::Subname
Zu mindest würde es mir so einleuchten.
Auf jeden Fall vielen Dank für die Klärung und den Hinweis. Es sieht in der Tat mit \& für mich sauberer aus.
Zitatbedeutet das die Referenz \&Subname das selbe wäre wie PACKAGENAME::Subname
Funktional ja, im Detail nicht ganz:
a) ist es eine Referenz, theoretisch kann man auch auf Funktionen außerhalb des eigenen namespace referenzieren. Die Frage ist dann aber eher, warum man sowas braucht. In der Regel wird man benötigte Funktionen importeren;
b) es ist eben kein "Text": Man darf also keine Quotes verwenden.
Meine meisten neueren Sachen im package-Kontext sind in der Regel an diesen Stellen dann reine Referenzierungen (auch die Verweise in Initialize wie im Auszug aus WDT).
Alles klar. Ich danke Dir.
Hallo,
ich habe nach einem Update das Problem das Fhem nicht mehr startet und "Undefined subroutine &main::GetUpdate " ist der letzte Log eintrag. Gibt es schon eine Lösung hierzu?
Steht doch alles im Thread.
Wende Dich bitte an den Entwickler des Moduls ComfoAir.
Oh danke! Habe, zugegeben, nicht alles im Detail gelesen. Sorry.
Hallo,
heute habe ich ein Update durchgeführt und die fhem startet danach nicht mehr.
Im Logfile kommt:
"Undefined subroutine &main::CUL_HM_AttrInit called at ./FHEM/98_HMinfo.pm line 1021."
Im Header von dieser 98_HMinfo.pm steht :"# $Id: 98_HMinfo.pm 24816 2021-08-01 18:53:15Z martinp876 $"
Ich habe einfach aus dem Backup die vorherige 98_HMinfo.pm rausgeholt, in FHEM ersetzt und es läuft wieder.
Die alte 98_HMinfo.pm "# $Id: 98_HMinfo.pm 19495 2019-05-30 09:17:45Z martinp876 $.".
Der erste Test (Zugriff auf Aktoren, Rolladen Steuerung etc.) zeigt keine Probleme. Dennoch bin ich mir nicht sicher ob der Austauch dieser einer Datei in Ordnung ist oder wäre es besser ein komplettes Restore zu machen?
Grüße, Marian
damits hier nicht wieder 2 diskussionen gibt --> https://forum.fhem.de/index.php/topic,122313.0.html