[gelöst] Fehler beim fhem-start configDB

[ronny332]

Moin zusammen,

einen neuen Fred möchte ich ungerne aufmachen, aber mein Problem bezieht sich auch auf die aktuell ausgelieferte ConfigDB Version (das letzte Update hatte ich Ende Juli laufen lassen, also schon eine Weile her).

In meinem Fall crasht FHEM beim Start zwar nicht, aber die Migration schlägt fehl. Als Datenbank kommt Mysql zum Einsatz, alle Rechte sind vorhanden (ich hatte die Schritte per Hand probiert, sowohl ALTER wie z.B. auch DROP funktionieren einwandfrei mit dem verwendeten Zugang).
Die b64 Tabelle hat nach dem ersten Starten einen einzigen Eintrag (UniqueID...), alle anderen Values der alten Tabelle werden nicht übernommen. Die alte Tabelle wird aber (zum Glück) auch nicht gelöscht.
Das "Spiel" kann ich endlos wiederholen. B64 Table löschen, FHEM starten, Tabelle mit einem Eintrag wieder da. FHEM Shutdown, Tabellen löschen, ...

Da u.A. alle meine GPlot Files in der Tabelle gespeichert sind, funktioniert FHEM zwar nach dem Start, aber eben komplett ohne Graphen (was noch nicht funnktioniert habe ich nicht probiert, sondern aus dem RestoreDIR die alten Versionen erneut eingespielt).

Ich sehe weder einen Fehler im Log, noch in der Shell.

Kann man das Debugging von ConfigDB so erhöhen, dass mehr angezeigt wird?

[Benni]

Nachdem dein letztes update davor ja schon länger her war, ist dir vielleicht auch folgende Information durch die Lappen gegangen:

https://forum.fhem.de/index.php/topic,74302.0.html

vielleicht liegt es ja an der fehlenden Perl library.

[betateilchen]

Benni, manchmal würde ich mir wünschen, Du würdest Dich mit solchen Antworten, die niemandem weiterhelfen, einfach mal ein paar Stunden zurückhalten...


@ronny332

Starte mal FHEM bitte direkt auf der Konsole. (vorher natürlich FHEM korrekt beenden!)

Code Auswählen Erweitern



cd /opt/fhem
perl fhem.pl configDB



und achte darauf, ob dabei Ausgaben auf der Konsole erscheinen.

[ronny332]

Nachdem dein letztes update davor ja schon länger her war, ist dir vielleicht auch folgende Information durch die Lappen gegangen:

https://forum.fhem.de/index.php/topic,74302.0.html

vielleicht liegt es ja an der fehlenden Perl library.

Danke für den Tip, das war es leider nicht (die Library ist installiert).

Benni, manchmal würde ich mir wünschen, Du würdest Dich mit solchen Antworten, die niemandem weiterhelfen, einfach mal ein paar Stunden zurückhalten...


@ronny332

Starte mal FHEM bitte direkt auf der Konsole. (vorher natürlich FHEM korrekt beenden!)

Code Auswählen Erweitern



cd /opt/fhem
perl fhem.pl configDB



und achte darauf, ob dabei Ausgaben auf der Konsole erscheinen.

Auch bei dieser Art des Starts passiert nicht wirklich etwas spannendes (keine weiteren Fehlermeldungen etc.), aber Danke für die Idee.

Vom Prinzip scheint Base64 auch zu funktionieren. Die angesprochene Unique ID habe ich eben mal gelesen und dekodiert:

Code Auswählen Erweitern

# This file is auto generated.
# Please do not modify, move or delete it.

uniqueID:ac9198a3c8888ef24349f1f7a2b42a94%

Das sieht mir schon nach der richtigen Idee aus.

Im FHEM Log steht rein gar nichts Auffälliges, weder beim ersten Start (vor der Migration), noch danach. Lediglich die fehlenden (nicht gefundenen) Daten werden angemeckert, aber das ist natürlich nicht der Grund, sondern einfach die Konsequenz.

Die Verbindung selber funktioniert (gut sichtbar durch "configdb info").

[Benni]

Benni, manchmal würde ich mir wünschen, Du würdest Dich mit solchen Antworten, die niemandem weiterhelfen, einfach mal ein paar Stunden zurückhalten...

Das kann ich ja vorher nicht wissen 
Werde mich aber in Zukunft dann eben raushalten!

[betateilchen]

Auch bei dieser Art des Starts passiert nicht wirklich etwas spannendes ..., aber Danke für die Idee.

Das war keine "Idee", sondern der erste Schritt, Dir bei der Lösung Deines Problems zu helfen.

[ronny332]

Das war keine "Idee", sondern der erste Schritt, Dir bei der Lösung Deines Problems zu helfen.

Oh, sorry, falsch ausgedrückt. Jede Art von Hilfe ist absolut Willkommen, egal ob "Idee" oder "erster Schritt zur Lösung" .

Es sieht mir immer mehr danach aus, dass wirklich "nur" die Konvertierung von den Blobs in B64 kodierte Blobs nicht klappt. Die Funktion danach ist scheinbar fehlerfrei.
Da es sich um nur 36 Einträge in der Tabelle handelt, kommt mir gerade die "Idee" die Konvertierung einfach per Hand zu machen. Das löst zwar nicht das eigentliche Problem, aber das Resultat dürfte wieder nutzbar sein.

[betateilchen]

Hier kommt der zweite Schritt.

Teste bitte die angehängte Version von configDB.pm und starte FHEM manuell von der Konsole. Dann poste die Ausgaben während des FHEM Starts.

[betateilchen]

Da es sich um nur 36 Einträge in der Tabelle handelt, kommt mir gerade die "Idee" die Konvertierung einfach per Hand zu machen.

Das brauchst Du nicht. Wir müssen eine funktionierende Lösung finden.

[ronny332]

Das Problem liegt an der Stelle auf dem Screenshot. Die Tabelle wird, wenn ich den Code richtig verstehe, nicht als existent erkannt, daher wird mein printf mit "reached" erreicht, das "never reached" aber niemals.
Als zweiten Screenshot füge ich mal die Datenbank selber (PhpMyAdmin) an. Der ganze Rechner ist ein Intel NUC mit Debian 8, Software technisch nichts Spezielles oder Exotisches.

Nachtrag:
Die Variable $exists einmal per Hand gültig gemacht und die Migration lief sauber durch.
Ich habe die originale Tabelle noch aufgehoben, falls Interesse daran besteht, es noch genauer zu testen. Mir persönlich fehlt hier im Perl Umfeld der Weitblick, daher wären schon Anweisungen notwendig, was ich wie testen soll um den möglichen Fehler noch genauer zu reproduzieren.

[betateilchen]

Es hilft mir nicht, wenn Du selbst irgendwas rumwurschtelst und dann meinst, mir gute Tipps geben zu müssen.

Da ich den Fehler bei mir nicht reproduzieren kann, bin ich als Entwickler auf die Mithilfe der Anwender angewiesen, bei denen ein Problem existiert. Aber Deine Bereitschaft zur Mitarbeit läßt zu wünschen übrig.

Immerhin habe ich versucht, eine Lösung zu finden, die vielleicht auch anderen Anwendern helfen könnte, falls das Problem nochmal auftritt.

daher wären schon Anweisungen notwendig, was ich wie testen soll um den möglichen Fehler noch genauer zu reproduzieren.

Noch klarere Anweisungen als in meinem vorletzten Beitrag fallen mir leider nicht ein.

[ronny332]

Hallo,

wie geschrieben: die Tabelle habe ich aufgehoben, die Stelle des Problems genannt. Der Fehler entsteht an der Stelle in der $sth_test mit table_info() befüllt wird.
Das hieraus abgeleitete $exists ist leer/fehlerhaft, sprich nicht true.

Da der Fehler reproduzierbar ist (ich brauche lediglich die b64 Tabelle löschen und die alte wieder einspielen), sehe ich absolut nicht fehlende Bereitschaft zur Mitarbeit (sowas hat mir glaube ich in all meinen Jahren im Opensource Bereich noch nie irgend ein Beteiligter gesagt ).

Unter Anleitung gehe ich gerne die Stellen durch, die zur Lösung des Problems beitragen können.

Nachtrag:
Das hier habe ich eben erst wirklich verarbeitet:

Code Auswählen Erweitern

mir gute Tipps geben zu müssen.

Wo gebe ich denn wem gute Tips? Bis eben war mir gar nicht klar, wer das Modul geschrieben hat. Meine Aussagen sind Feststellungen, die ich mache um allen hier Helfenden Anwensenden möglichst viele Details zu liefern und damit Ihre Zeit zu sparen.

[betateilchen]

Du verstehst überhaupt nicht, worum es mir geht. Sehr schade.

Egal. Ich bin hier raus.

[ronny332]

Der Grund für "Du verstehst überhaupt nicht, worum es mir geht. Sehr schade." war der Doppelpost mit dem angefügten Quell Code und dem weiteren Post mit dem Inhalt "Das brauchst Du nicht. Wir müssen eine funktionierende Lösung finden.".
Den Quellcode habe ich schlicht und einfach nicht gesehen (0 Downloads beim Counter sollten das gut zeigen).

Ich teste es eben durch.

Hier das Resultat:

Code Auswählen Erweitern

fhem@fhem:~$ perl fhem.pl configDB
exists: 0

Die Tabelle wird daher wohl nicht "gefunden" (in welcher Form auch immer das sein mag).

[betateilchen]

ok, danke.

Nächster Test bitte mit der Version, die hier angehängt ist.