Hallo,
mit der Version configDB.pm 14845 vom 4.8.17 startet fhem nicht (mehr), die Tabelle "fhembinfilesave" existiert nicht.... irgendwann wurde diese ja konvertiert....und gelöscht...
Habe jetzt eine Version vom 14725 vom 16.7. und nun startet fhem wenigstens wieder!!
Bitte ganz schnell korrigieren!!! Weiss nicht was da noch kommt diesbezüglich!!
danke.
Nachtrag:
habe die Version 14845 nochmal "vorgeholt" aber vor dem Start eine leere Tabelle "fhembinfilesave" aus einer Kopie angelegt. Nun startet fhem auch wieder.
Aber das kanns ja nicht sein, im Modul steht ja "drop table...."
Bitte prüfen.
danke.
Deinem User fehlen für die Tabelle die Rechte für drop. Also anmelden an der DB und die rechte Nachträglich geben. Musste ich auch machen da FHEM sonst nicht gestartet ist
Da die Frage sicherlich aufkommen wird.
Hier ein Beispiel für eine MySQL Datenbank
GRANT SELECT,INSERT,UPDATE,DELETE,CREATE,LOCK TABLES,DROP ON `fhemConfigDB`.* TO 'fhem'@'%';
fhemConfigDB ist meine Datenbank und fhem mein User
Also mein DB-User "fhem" hat alle Rechte, schon immer...., ich glaube wir reden aneinander vorbei:
Die "fhembinfilesave" wurde nach der Konvertierung in "fhemb64filesave" ja gedropt, also gelöscht.
Bei meinem letzten RASPI-Start gestern startete fhem nicht mangels fehlender "fhembinfilesave"-Tabelle in Zeile 306 in configDB.pm
Diesen Fehler bitte ich auf den Grund zugehen...denn wenn ich die Tabelle manuell anlege ohne Inhalt, dannh startet auch fhem ganz normal wieder!!
Dann haben wir in der Tat aneinander vorbei geredet. Ich dachte er hätte nicht die Rechte zum dropen. Das war bei mir so gewesen.
Im übrigen startet FHEM bei mir auch ohne fhembinfilesave denn sie würde ja von configdb gelöscht.
ZitatDiesen Fehler bitte ich auf den Grund zugehen...
Du solltest vielleicht mal dem Grund auf den Grund gehen, wieso das bei DIR nicht funktioniert, bei (allen?) anderen Anwerdern hingenen schon, statt zu FORDERN Deinem persönlichen Grund auf den Grund zu gehen. ;D
Ich bin der Sache auf den Grund gegangen.
Zitat von: oldscout am 20 August 2017, 11:01:39
mangels fehlender "fhembinfilesave"-Tabelle in Zeile 306 in configDB.pm
Zeile 306 in configDB.pm wird nur ausgeführt, wenn es überhaupt noch eine entsprechende Tabelle fhembinfilesave in der Datenbank gibt. Das wird explizit vorher geprüft.
ja richtig, das ist der Fehler den ich auf der Kommandozeile bei fhem start bekomme. ich werde das nochmals morgen provozieren und einen screen-shot erzeugen.
An der Tatsache, dass Du die Ursache für DEIN Problem auf DEINEM System suchen musst, wird auch ein morgiger Screenshot nichts ändern.
Klingt nach einem klassische Popcorn Fall. Heute geh ich mal holen.
Ja es ist MEIN System, völlig richtig, das Problem trat seit der Konvertierung in das Base64 Format auf, hier der Screenshot:
Erstelle ich diese leere Tabelle, geht es wieder.
Nachtrag:
die Konvert-Routine ob "fhembinfilesave" existiert oder nicht wird hier in jedem Fall durchlaufen.
"if ($sth_test->fetch())......"
offensichtlich liefert dies nicht das gwünschte Ergebnis....
an dev0: ich habe nicht gefordert... es stand bitte ..... auf den Grund gehen....
Zitat von: oldscout am 21 August 2017, 06:28:48
offensichtlich liefert dies nicht das gwünschte Ergebnis....
welche Datenbank hast Du im Einsatz?
mysql, seit 3 Jahren...
Mit mysql funktioniert die Migration und die Prüfung auf die anschließende Tabellenexistenz problemlos.
Das ist mehrfach getestet und in der aktuellen FHEM Statistik sind alleine 30 FHEM Installationen verzeichnet, die mysql mit b64 benutzen.
Die Fehlerursache vermute ich nach wie vor in Deiner Datenbankinstallation.
ok, Datenbankfehler... Tabelle da, fhem startet, Tabelle weg, fhem startet nicht mit genannten Fehler.
an welcher Stelle kann ich da noch schauen, die Konvertierung ist durchgelaufen, fhemb64filesave existiert, solange fhem nicht neugestartet wird,z.b. nach Update geht es super.
Bis zur Konvertierung lief es auch. Wo also könnte der Fehler liegen?
Gibt es ev. Probleme hinsichtlich der Versionen perl/Mysql??
Meine Notlösung wird sein, dass ich den Block der Konvertierung auskommentiere/lösche bzw. das drop rausnehme, Konvertierung ist ja durch....wozu also jedesmal testen.
Keine schöne Lösung, aber eine.
Trotzdem würde ich mich noch über ein paar Hinweise freuen.
danke.
Zitat von: oldscout am 21 August 2017, 18:32:39
Trotzdem würde ich mich noch über ein paar Hinweise freuen.
ich habe keine, sonst würde ich sie Dir ja geben.
Moin moin,
offensichtlich ist oldscout nicht allein - ich habe seit der Umstellung auch das Problem:
Bei mir läuft fhem auf einem Raspberry 2, die Konigurationsdaten und Logs werden in der externen MySQL-Datenbank auf meinem NAS von QNAP im LAN gespeichert. Konkret läuft da MariaDB 5.5.51.
Der Fehler ist replizierbar:
- Fhem ist nicht aktiv. Aus einer alten Installation füge ich die alte korrekte Tabelle fhembinfilesave ein. Die Tabelle fhemb64filesave existiert nicht.
- Nach dem Start von fhem wird fhembinfilesave in fhemb64filesave konvertiert und fhembinfilesave gelöscht.
- fhem arbeitet problemlos.
- Fhem kann fehlerfrei beendet werden (shutdown oder über init-Skript)
- Fhem kann nicht mehr gestartet werden. Ursache ist die fehlende Tabelle fhembinfilesave - dass fhemb64filesave existiert, spielt keine Rolle.
- Ab hier kann ich nur noch die alte Tabelle fhembinfilesave aus dem backup wiederherstellen und die fhemb64filesave löschen, erst dann lässt sich fhem wieder starten - dann beginnt alles bei Ziffer 1.
Woran kann das liegen??? Offensichtlich scheint das ja bei den meisten fehlerfrei zu funktionieren. Betateilchen, welche Daten brauchst Du noch zur Fehleranalyse bzw. was kann ich hier vor Ort tun, um den Fehler zu vermeiden?
Hallo wieder,
ich bin doch nicht allein....... ;D
Der Test, ob die Tabelle fhembinfilesave existiert gibt bie mir immer das Array zurück... egal ob die Tabelle da ist oder nicht.
Hat sich die ganze DB irgendwie zerlegt? fhem läuft aber wie gewohnt... mysqlcheck gibt ein ok in allen Tabellen zurück.
an AitschPi: kommentiere das drop in configDB.pm aus und fhem startet erstmal. Ich habe einfach eine leere Tabelle fhembinfilesave erstellt.
Ich habe noch mysql 5.5.
Prüfe ich hingegen auf "irgendeine" noch nie existierende Tabelle in der DB, dann wird der Array-Zeiger als undefiniert zurückgegeben.
an CoolTux: wieviel Popcorn gab es schon???? ;)
Zitat von: oldscout am 24 August 2017, 07:12:38
an CoolTux: wieviel Popcorn gab es schon???? ;)
Hier im Forum über die Jahre. Eine Menge, glaube mir. Deswegen sind Udo und ich ja auch so "smart" ;D
Ah, jetzt weiß ich, woher "smart home" kommt... ;o)
Wenn die Prüfung auf die nicht mehr vorhandene Tabelle immer noch ein "true" zurückliefert, handelt es sich entweder um ein Problem der Datenbank selbst (Cache?) oder der perl Datenbanktreiber hat eine Macke.
Die Sache mit dem Cache ließe sich leicht prüfen: Nach der Migration den mysql Server einmal durchstarten.
Muss mal überlegen, ob ich die Prüfung anders umsetzen kann. Für mich ist das Problem, dass keine meiner mysql Installationen dieses Verhalten zeigt, das macht das Testen schwierig.
Könnte jemand von den "Betroffenen" bitte folgendes testen:
1. In der Konfigurationsdatei configDB.conf den parameter b64 mit 1 übergeben
%dbconfig= (
connection => "connectionString",
user => "user",
password => "password",
b64 => "1",
);
2. dann mit der hier angehängten Moduldatei testen
edit: die Datei befindet sich jetzt in SVN und kommt ab 24.08. automatisch per update
Läuft. ;o)
Was könnte ich für Dich "ferntesten"? Ursache könnte ja (bei mir) die externen Datenbanken (1x config, 1x log, gleiche Zugangsdaten), die mariaDB-mySQL-Version auf QNAP oder ein fehlerhaftes Modul in fhem selbst sein... So viele Möglichkeiten. Oder einfach so lassen, läuft ja jetzt?
Danke für die Rückmeldung, hatte die Änderung heute morgen einfach mal so während der Bahnfahrt ins Büro ausgedacht und eingebaut.
Zitat von: AitschPi am 24 August 2017, 08:38:28
Was könnte ich für Dich "ferntesten"?
Brauchst Du nicht, danke. Die Prüfung für den Migrationsmechanismus werde ich entsprechend umbauen und eine datenbankunabhängige Variante verwenden. Vermutlich werde ich die Konfigurationsdatei nach der Migration automatisch um den Parameter b64 erweitern und dann diesen Parameter prüfen. Das muss ich aber in Ruhe machen.
Wichtig ist, dass wir erstmal einen Workaround haben, falls noch mehr Fälle mit diesem Problem auftauchen.
Irgendwann fliegt die Migration ohnehin wieder aus der Moduldatei, aber das wird frühestens in einigen Monaten passieren (Kompatibilitätsgründe)
Danke. Und gut, dass Du mit der Bahn und nicht mit dem Auto fährst... ;o)
Gesendet von iPhone mit Tapatalk Pro
Eine BahnCard100 hat man nicht ohne Grund... :)
Bei mir läuft es auch jetzt. danke. :)
Hallo,
habe nochmals einen eigenen unabhängigen Test gemacht, wegen der Existenz der Tabelle:
1. fhem stop
2. mysql restart
3. fhem start
4. Array-Zeiger wird immer noch zurück gegeben.... Tabelle ist aber eigentlich seit gestern abend gelöscht.... kein cache-Problem??
Ich habe InnoDB als Datenbankformat.
Kannst Du mal bitte die angehängte Version von configDB.pm testen?
Hallo betateilchen,
alles ok bis jetzt, fhem startet ganz normal mit der Rev. 14955. :)
Für mein Verständnis: Mit der obigen Testversion funktioniert das Ganze nun auch ohne den Parameter b64?
(Die rev Nummer hilft mir nicht weiter, das ist die gleiche wie in der aktuellen produktiven Version)
Soll ich auch nochmal testen - dachte, dass wäre jetzt für oldscout gewesen...
Gesendet von iPhone mit Tapatalk Pro
Hallo,
ich habe den Parameter b64 in der configdb.conf bereits in der Testversion eingetragen und darin belassen.
Zitat von: betateilchen am 20 August 2017, 18:21:46
An der Tatsache, dass Du die Ursache für DEIN Problem auf DEINEM System suchen musst, wird auch ein morgiger Screenshot nichts ändern.
Ich hab das Popcorn ja auch genossen. Speziell diese Tüte hier.
Aber vielleicht mögen das nicht alle Anwender von ConfigDB und würde sich manchmal über mehr Hilfestellung in der doch offenbar komplexen Materie anstatt "Dein Problem" freuen.
Wie schön, daß der Fehler gefunden wurde.
Ciao, -MN
@oldscout: Hattest Du gestern die
gestern hier im Thread bereitgestellte Testversion ausprobiert? Bei der ist es völlig egal, ob es den Parameter b64 gibt oder nicht.
Zitat von: Morgennebel am 30 August 2017, 09:32:36
würde sich manchmal über mehr Hilfestellung ... freuen.
Diese Aussage ist eine ziemliche Unverschämtheit. Aber von Dir bin ich ja nix anderes gewohnt.
Zitat von: betateilchen am 30 August 2017, 10:21:11
Diese Aussage ist eine ziemliche Unverschämtheit. Aber von Dir bin ich ja nix anderes gewohnt.
Hach, mehr Popcorn. Persönliche Angriffe, statt einen vorsichtig formulierten Vorschlag inhaltlich und sachlich zu beantworten...
Ciao, -MN
Hallo betateilchen,
entschuldige, ich habe mich nur an der Revisionsnummer orientiert, da ich ein update gemacht hatte war das diese Version.
Habe eben (heute 13.20 Uhr) nochmal die Downloadversion aus dem Forum getestet, sowohl mit Parameter b64 als auch ohne, startet fhem beide Male fehlerfrei.
Kann der Parameter aus der configdb.conf damit entfallen oder ist der doch noch geplant?
VG
Ok, ich versuche es nochmal...
- An diesem Beitrag hängt eine Version von configDB.pm, die sich mit der rev 99999 melden sollte, wenn man versions aufruft.
- Diese Version sollte ohne den Parameter b64 funktionieren
Wenn jemand von den Anwendern, die bisher das Problem beim Starten hatten, dies bestätigen kann, werde ich diese Modulversion in das offizielle Update nehmen und hier aus dem Thread wieder entfernen.
Da ich selbst keine Installation habe, die das Fehlverhalten zeigt, kann ich es leider nicht selbst testen.
Betateilchen, ich bin heute noch bis spät unterwegs - werde es aber abends/nachts testen. Feedback kommt morgen. Danke noch/schon mal. ;o)
Gesendet von iPhone mit Tapatalk Pro
Hallo,
fhem startet mit der Version 99999 hier aus dem Forum fehlerfrei. Eben getestet. Allerdings wird unter version noch 14955 angezeigt ;)
So, familiär bedingt etwas später die Rückmeldung:
Zitat von: betateilchen am 30 August 2017, 13:58:27
Wenn jemand von den Anwendern, die bisher das Problem beim Starten hatten, dies bestätigen kann...
bestätigt, funktioniert.
Danke nochmal.
Danke an alle Tester.
Die Version wird inzwischen schon per update verteilt. Der Parameter b64 kann damit wieder entfallen.
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?
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.
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!)
cd /opt/fhem
perl fhem.pl configDB
und achte darauf, ob dabei Ausgaben auf der Konsole erscheinen.
Zitat von: Benni am 05 September 2017, 13:17:46
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).
Zitat von: betateilchen am 05 September 2017, 13:30:40
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!)
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:
# 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").
Zitat von: betateilchen am 05 September 2017, 13:30:40
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!
Zitat von: ronny332 am 05 September 2017, 14:24:48
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.
Zitat von: betateilchen am 05 September 2017, 14:53:24
???
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.
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.
Zitat von: ronny332 am 05 September 2017, 15:02:12
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.
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.
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.
Zitat von: ronny332 am 05 September 2017, 15:11:39
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.
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:
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.
Du verstehst überhaupt nicht, worum es mir geht. Sehr schade.
Egal. Ich bin hier raus.
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:
fhem@fhem:~$ perl fhem.pl configDB
exists: 0
Die Tabelle wird daher wohl nicht "gefunden" (in welcher Form auch immer das sein mag).
ok, danke.
Nächster Test bitte mit der Version, die hier angehängt ist.
Hallo,
das kommt heraus:
fhem@fhem:~$ perl fhem.pl configDB
looking for table fhembinfilesave
testing #1
table not found
Als Anhang nochmals ein Screenshot der vorhandenen Tabellen. Die neue b64 Tabelle wird sauber angelegt, die "_org" Tabelle ist meine Kopie des Originals vor der Migration.
Es erschließt sich mir nicht, warum die Tabelle nicht gefunden wird. Komischerweise gab es das Problem genau umgekehrt - auch bei mysql.
Ich habe gerade noch mehr debugging output eingebaut und hier angehängt. Bitte nochmal testen.
Langsam habe ich den Verdacht, dass der perl Datenbanktreiber für mysql bei InnoDB nicht korrekt arbeitet. Das ist jetzt schon das zweite Fehlerbild, das im Zusammenhang mit InnoDB auftritt.
Hier die Ausgabe.
fhem@fhem:~$ perl fhem.pl configDB
looking for table: fhembinfilesave
testing: #1
found: `fhem_configdb`.`fhemb64filesave`
found: `fhem_configdb`.`fhembinfilesave`
found: `fhem_configdb`.`fhembinfilesave_org`
found: `fhem_configdb`.`fhemconfig`
found: `fhem_configdb`.`fhemstate`
found: `fhem_configdb`.`fhemversions`
table not found
Um InnoDB als Fehler auszuschliessen, habe ich auch einen Test mit MyISAM als Datenbank-Engine gemacht. Der Fehler ist identisch.
cool... jetzt weiß ich, woher der Fehler kommt.
found: `fhem_configdb`.`fhembinfilesave`
Wenn ich diesen kompletten String nur gegen "fhembinfilesave" auf Gleichheit prüfe, kann das natürlich nie funktionieren.
Moment, gleich kommt noch eine Version zum Testen.
Bitteschön... nochmal zum Testen.
Einwandfrei! :)
fhem@fhem:~$ perl fhem.pl configDB
looking for table: fhembinfilesave (the hard way)...
testing: #1
found: `fhem_configdb`.`fhemb64filesave`
found: `fhem_configdb`.`fhembinfilesave`
need to migrate 36 files to base64
migrating ./db.conf : done.
migrating ./FHEM/FhemUtils/uniqueID : done.
migrating ./FHEM/template.layout : done.
migrating ./www/gplot/...
(die ganzen gplot Ausgaben habe ich gelöscht)
Aktiv nun wieder mit InnoDB, MyISAM funktioniert auch.
Super. Danke fürs Testen.
Die aktualisierte Modulversion wird ab morgen per update verteilt.
Mal schauen, wann der nächste Spezialfall um die Ecke kommt 8)
Trotzt Aktualisierung heute bekomme ich den Fehler (Der genauso im Log beim Neustart erscheint):
# perl fhem.pl configDB
looking for table: fhembinfilesave
testing: #1
found: `fhem_configDB`.`fhemb64filesave`
found: `fhem_configDB`.`fhemconfig`
found: `fhem_configDB`.`fhemstate`
found: `fhem_configDB`.`fhemversions`
table not found
Als Tabellen sind vorhanden:
'fhemb64filesave'
'fhemconfig'
'fhemstate'
'fhemversions'
configDB Version:
-----------------------------------------------------------------
configDB Database Information
-----------------------------------------------------------------
# $Id: configDB.pm 15012 2017-09-05 17:35:14Z betateilchen $
-----------------------------------------------------------------
DB Version:
mysqld Ver 10.1.26-MariaDB-0+deb9u1 for debian-linux-gnu on x86_64 (Debian 9.1)
Kann ich sonst noch etwas debuggen?
Kann mir nicht helfen. Ich sehe absolut keine Fehlermeldung. Wo genau ist der Fehler?
Ich sehe auch kein Problem.
Was bedeutet denn die Meldung?
table not found
nix. Alles gut.
Zitat von: bart am 06 September 2017, 13:22:59
Was bedeutet denn die Meldung?
table not found
Sind bestimmt Debug Meldungen. Sind mehr oder weniger uninteressant für den normalen User.
Die Meldung besagt zumindest, dass der User ein aktuelle FHEM einsetzt, denn diese Debug-Meldung gibts erst seit dem heutigen Update.
Diese Meldung wäre inhaltlich nur dann interessant, wenn FHEM nicht ordnungsgemäß funktionieren würde.
komisch... wenn ein Antivirusprogramm meldet, dass etwas nicht gefunden wurde, sind alle zufrieden und niemand kommt auf die Idee, dass das Ergebnis ein Fehler sei 8)
Zitat von: betateilchen am 06 September 2017, 14:29:11
komisch... wenn ein Antivirusprogramm meldet, dass etwas nicht gefunden wurde, sind alle zufrieden und niemand kommt auf die Idee, dass das Ergebnis ein Fehler sei 8)
Nun ja, bei einem
Antivirenprogramm geht ja auch jeder davon aus, dass nach unerwünschtem gesucht wird.
Bei einer Konfiguration erwartet man i.d.R. schon, dass alles wiedergefunden wird. ;)
(Bevor's wieder Haue gibt: Dass das hier was ganz anderes ist, ist mir schon klar! 8))
Heute ist mir FHEM abgestürzt, siehe
https://forum.fhem.de/index.php/topic,76651.msg685756.html#msg685756 (https://forum.fhem.de/index.php/topic,76651.msg685756.html#msg685756)
Beim Neustart kam diese Meldung
Starting fhem...
looking for table: fhembinfilesave
testing: #2
table not found
Muss mich diese Meldung beunruhigen ?
Vorhanden ist die Tabelle jedenfalls nicht
sqlite> .tables
fhemb64filesave fhemconfig fhemstate fhemversions
Dein Ernst?
https://forum.fhem.de/index.php/topic,75608.msg681692.html#msg681692
Zitat von: CoolTux am 15 September 2017, 10:11:31
Dein Ernst?
https://forum.fhem.de/index.php/topic,75608.msg681692.html#msg681692
oops , natürlich nicht...
Link angepasst...
Hallo zusammen,
leider muss ich mich auch noch einmal melden. Mit der letzten hier verteilten Version von Betateilchen lief FHEM nun eine ganze Weile, bis zum Update heute (ich hatte auch keine Updates mehr eingespielt).
Seit dem Update erscheint es mir so, als ob die Erkennung ob "fhembinfilesave" existiert, nicht korrekt funktioniert. FHEM startet nicht, hier die passende Meldung:
looking for table: fhembinfilesave
testing: #1
found: `fhem_configdb`.`fhemb64filesave`
found: `fhem_configdb`.`fhembinfilesave_org`
2017.09.19 21:49:47 1: PERL WARNING: DBD::mysql::db selectrow_array failed: Table 'fhem_configdb.fhembinfilesave' doesn't exist at configDB.pm line 312.
DBD::mysql::db selectrow_array failed: Table 'fhem_configdb.fhembinfilesave' doesn't exist at configDB.pm line 312.
2017.09.19 21:49:47 1: PERL WARNING: Issuing rollback() due to DESTROY without explicit disconnect() of DBD::mysql::db handle database=fhem_configdb;host=127.0.0.1;port=3306 at configDB.pm line 312.
Lege ich die Tabelle "fhembinfilesave" per Hand wieder an, so klappt der Start, der Inhalt der Tabelle wird migriert, die Tabelle danach gelöscht (soweit so richtig, soweit ich das verstehe).
Nach dem Start beginnt das Spiel aber leider wieder von vorne. Die Tabelle "fhembinfilesave" wird zwingend für einen Start benötigt.
Gerne teste ich wieder auf meinem System unter Anleitung woran es klemmen könnte, bis dahin sollte es mit der letzten Version von hier hoffentlich auch sauber laufen :-).
EDIT:
das Problem könnte bei mir liegen, bzw. an der Art, wie configDB erkennt, ob "fhembinfilesave" existiert. In meinem Fall hatte ich das Original als "fhembinfilesave_org" gesichert. Wenn ich den Perl Code richtig verstehe, ist es für die Substring Erkennung ggf. sogar schon genug, um aus ""fhembinfilesave_org" ein vorhandenes "fhembinfilesave" zu erkennen. Mit einer "fhembinfilesave_org" in "hfembinfilesave_org" umbenannten Tabelle startet FHEM normal mit einem
looking for table: fhembinfilesave
testing: #1
found: `fhem_configdb`.`fhemb64filesave`
found: `fhem_configdb`.`fhemconfig`
found: `fhem_configdb`.`fhemstate`
found: `fhem_configdb`.`fhemversions`
found: `fhem_configdb`.`hfembinfilesave_org`
table not found
Daher erstmal sorry für den "Alarm" ;-).
wer auf eigene Faust in der Konfigurationsdatenbank rumpfuscht, braucht sich nicht wundern, wenn irgendwas nicht mehr so funktioniert wie vorgesehen.
Für daraus resultierende Probleme fühle ich mich als Entwickler aber auch in keinster Weise verantwortlich.
Zitat von: ronny332 am 19 September 2017, 21:56:57
leider muss ich mich auch noch einmal melden. Mit der letzten hier verteilten Version von Betateilchen lief FHEM nun eine ganze Weile, bis zum Update heute (ich hatte auch keine Updates mehr eingespielt).
FHEM lief heute wunderbar. Heute update mit shutdown restart gemacht, ConfigDB meldet Fehler:
root@fhem:~# /etc/init.d/fhem start
Starting fhem...
looking for table: fhembinfilesave
testing: #2
table not found
Und diese table fehlt tatsächlich:
root@fhem:/opt/fhem# sqlite3 configDB.db
SQLite version 3.8.7.1 2014-10-29 13:59:56
Enter ".help" for usage hints.
sqlite> .tables
fhemb64filesave fhemconfig fhemstate fhemversions
Der Header der 98_configdb.pm:
root@fhem:/opt/fhem/FHEM# head 98_configdb.pm
# $Id: 98_configdb.pm 16218 2018-02-18 19:23:23Z betateilchen $
#
In restoreDir/2018-03-19/FHEM liegt keine 98_configdb.pm...
Betriebssystem www.devuan.org, Jessie:
root@fhem:/opt/fhem/restoreDir/2018-03-07/FHEM# uname -a
Linux fhem 3.16.0-5-amd64 #1 SMP Debian 3.16.51-3+deb8u1 (2018-01-08) x86_64 GNU/Linux
Danke, -MN
Wo bitte schön liest Du daraus einen Fehler?
Steht da Fehler, steht da Error?
Es ist eine normale Debugausgabe die Udo nur noch nicht auskommentiert hat.
Die Meldung gibt es seit Anfang des Jahres.
Zitat von: CoolTux am 19 März 2018, 18:37:31
Es ist eine normale Debugausgabe die Udo nur noch nicht auskommentiert hat.
Die Meldung gibt es seit Anfang des Jahres.
Nein, die gibt es schon viel länger, grob geschätzt seit August 2017.
Zitat von: Morgennebel am 19 März 2018, 18:34:11
Und diese table fehlt tatsächlich:
Das ist ein gutes Zeichen :)
Zitat von: betateilchen am 19 März 2018, 19:32:16
Nein, die gibt es schon viel länger, grob geschätzt seit August 2017.
Ist es wirklich schon wieder so lange her? Oh man.
Um genau zu sein: seit rev 15012 vom 05.09.2017
Davon abgesehen, dass diese Meldung seither beim FHEM Start jedesmal erscheint, habe ich hier im Forum schon bereits 10 Mal erklärt, dass diese Meldungen völlig normal und kein Grund zur Sorge sind.
Aber es gibt eben eine Handvoll (übrigens immer die gleichen) Leute, die mobben lieber erstmal rum, anstatt sich vorher zu informieren.
Zitat von: CoolTux am 19 März 2018, 18:37:31
Wo bitte schön liest Du daraus einen Fehler?
Steht da Fehler, steht da Error?
Stimmt. Das war mein Fehler (PECAB).
Das FHEM nicht startete, lag an den 1-Wire-Updates und den OW-Bibliotheken durch ein "update" verursacht. Nach einspielen aller Dateien aus dem restoreDir gings dann wieder.
Danke für die Geduld,
Ciao, -MN
Zitat von: betateilchen am 19 März 2018, 19:46:57
Aber es gibt eben eine Handvoll (übrigens immer die gleichen) Leute, die mobben lieber erstmal rum, anstatt sich vorher zu informieren.
Eine von Deiner abweichende Meinung zu vertreten ist kein Mobbing.
Bei der ConfigDB habe ich mich informiert, nutze sie seit Monaten. Bin aber nicht 100% überzeugt. Aber das ist meine Meinung, ich weiß, daß Du eine ganz andere hast und habe jetzt keine Lust, mich mit Dir zu streiten...
Ciao, -MN