Hallo zusammen,
ich möchte gerne die UI von meiner FHEM Instanz verbessern und bin dabei auf FUIP gestossen. Ich bin begeistert von FUIP und möchte gerne mein zusammengebasteltes TabletUI auf FUIP umbauen. Ich benutze (wie vermutlich viele hier) ein "TestFHEM" und ein "ProduktivFHEM".
Mein TestFHEM ist auf einem RaspiIII installiert unter Nutzung von configdb. FUIP funktioniert und ich kann ein set FUIP save absetzen. Obwohl FUIP und FHEM wie erwartet funktionieren, tauchen im LOG folgende Fehlermeldungen auf:
2019.12.28 10:37:00 1: PERL WARNING: Use of uninitialized value in pattern match (m//) at ./FHEM/42_FUIP.pm line 1401.
2019.12.28 10:37:00 1: PERL WARNING: Use of uninitialized value in pattern match (m//) at ./FHEM/42_FUIP.pm line 1403.
2019.12.28 10:37:00 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/42_FUIP.pm line 1406.
2019.12.28 10:37:00 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/42_FUIP.pm line 1412.
2019.12.28 10:37:00 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/42_FUIP.pm line 1420.
2019.12.28 10:37:00 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/42_FUIP.pm line 1437.
2019.12.28 10:37:00 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/42_FUIP.pm line 1461.
2019.12.28 10:37:00 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/42_FUIP.pm line 1472.
Vermutlich verweist jede Zeilennummer der Fehlermeldung auf den Typ meiner Testdevices...
Mein ProduktivFHEM ist auf einem NAS unter Nutzung von configdb als Dockercontainer installiert. Auf dem ProduktivFHEM taucht das eigentliche Problem auf: bei einem set FUIP save stürzt FHEM komplett ab. Im Log finde ich zu diesem Zeitpunkt folgende Fehlermeldungen:
2019.12.26 12:43:27 1: PERL WARNING: "my" variable $fields masks earlier declaration in same scope at ./FHEM/42_FUIP.pm line 3672.
2019.12.26 12:43:27 3: FUIP: Registering FUIP for URL /fuip
Vor einem Update gestern waren es auch Logeinträge wie dieser:
2019.12.27 16:00:23 1: PERL WARNING: DBD::mysql::st execute failed: Data too long for column 'content' at row 1 at configDB.pm line 396.
DBD::mysql::st execute failed: Data too long for column 'content' at row 1 at configDB.pm line 396.
2019.12.27 16:00:23 1: PERL WARNING: Issuing rollback() due to DESTROY without explicit disconnect() of DBD::mysql::db handle database=fhem;host=qnap_mysql;port=3306 at configDB.pm line 396.
Die v.g. Logeinträge brachten mich darauf, dass es ggf. an configdb liegt und ich habe versucht trotz Nutzung von configdb für FUIP eine Speicherung der Konfiguration in einer Datei zu versuchen. Ich habe dazu folgende Befehle ausgeführt:
configdb fileexport ./FHEM/lib/FUIP/config/FUIP_FUIP.cfg
configdb filedelete ./FHEM/lib/FUIP/config/FUIP_FUIP.cfg
Leider wurde von FUIP nicht die lokale Datei benutzt, sondern es wurde ein neuer Eintrag in configdb angelegt. Berechtigungsprobleme habe ich ausgeschlossen, da der Autosavemechanismuss (der auch lokale Dateien nutzt) tadellos funktioniert. Die Autosavedateien sind alle vorhanden.
Vielen Dank für jeden Tipp / Hilfe.
kleine Ergänzung:
Ich bin mir nicht sicher, ob es gewollt ist, dass die Datei ./FHEM/lib/FUIP/config/FUIP_FUIP.cfg innerhalb von configdb nicht editierbar ist. Die Befehle
configdb fileimport ./FHEM/lib/FUIP/config/FUIP_FUIP.cfg
configdb fileexport ./FHEM/lib/FUIP/config/FUIP_FUIP.cfg
funktionieren beide. Lesbar ist aber immer nur die lokale Datei, die die Datei innerhalb von configdb. Das ist bei allen anderen Dateien in configdb anders...
Ich dachte, dass sich die Fehlermeldungen durch ein Update verändert hätten. Ist leider nicht so. Der Absturz führt auch nach dem Update auf dem ProduktivFHEM zu folgenden Logeinträgen:
2019.12.28 16:32:37 1: PERL WARNING: DBD::mysql::st execute failed: Data too long for column 'content' at row 1 at configDB.pm line 396.
DBD::mysql::st execute failed: Data too long for column 'content' at row 1 at configDB.pm line 396.
2019.12.28 16:32:37 1: PERL WARNING: Issuing rollback() due to DESTROY without explicit disconnect() of DBD::mysql::db handle database=fhem;host=qnap_mysql;port=3306 at configDB.pm line 396.
Abrupt daemon termination, starting 10s countdown .../entry.sh: line 625: kill: (14923) - No such process
10/entry.sh: line 625: kill: (14923) - No such process
Ich bin mir nach vielen Versuchen mittlerweile sicher, dass es am Zusammenspiel zwischen FUIP und configdb liegt. Dies auch deshalb, weil der Autosavemechanismus von FUIP immer funktioniert und hierbei grundsätzlich als lokale Datei gespeichert wird (und configdb deshalb außen vor bleibt). Einen Fehler bei configdb schließe ich aus, weil sonst alles seit längerem fehlerfrei läuft.
Um FUIP das Speichern in der Datenbank abzugewöhnen habe ich die folgende Vorgehensweise mehrfach ausprobiert.
- Die vorhandene FUIP_FUIP.cfg mittels
"configdb fileexport ./FHEM/lib/FUIP/config/FUIP_FUIP.cfg" exportiert - Gecheckt ob Datei exportiert wurde, lesbar ist und ausreichende Berechtigungen vorhanden sind
- Datei in Datenbank mittels
"configdb filedelete ./FHEM/lib/FUIP/config/FUIP_FUIP.cfg" gelöscht - Gecheckt ob Datei in Datenbank gelöscht wurde und FHEM neugestartet.
Das Ergebnis nach dem nächsten
set FUIP savewar, dass die lokal vorhandene Datei ignoriert wurde und eine neue Datei in der Datenbank angelegt wurde. Ich hätte erwartet, dass bei lokal vorhandener Datei diese genutzt wird und keine neue Datei in der Datenbank angelegt wird. Eine erneutes "set FUIP save" nach einer Änderung der Standardconfig in der Datenbank brachte dann wieder den Absturz.
Danke für jeden Tipp.
Hi,
wahrscheinlich ist es sinnvoll, wenn wir uns erst einmal auf die configdb-Problematik konzentrieren. Der andere Kram sind nur Warnungen und haben wahrscheinlich nichts mit dem save-Problem zu tun.
Interessant finde ich diese Meldung:
Data too long for column 'content' at row 1...
Das sieht so aus, dass die configdb Probleme mit der Größe der FUIP-cfg-Datei hat. Das finde ich ein bisschen komisch, da man bei einer solchen Funktionalität (speichern einer ganzen Datei in einem Feld) von LONGBLOB bzw. LONGTEXT ausgehen würde, was 4GB fassen kann. Ich glaube nicht, dass Deine FUIP-cfg-Datei über 4GB liegt.
So gesehen würde ich das schon einen Fehler in der configdb nennen.
...aber das bringt uns hier gerade nicht weiter.
Könntest Du mal ausprobieren, ob es mit einem frisch angelegten FUIP-Device funktioniert? Außerdem wäre interessant, wie groß die FUIP-cfg-Datei ungefähr ist. Die Größe der Autosave-Dateien wäre hier ein guter Anhaltspunkt.
Zitat von: matrois am 28 Dezember 2019, 17:37:45
Um FUIP das Speichern in der Datenbank abzugewöhnen habe ich die folgende Vorgehensweise mehrfach ausprobiert.
Warum sollte das auch funktionieren? Gibt es ein anderes Device, bei dem so etwas funktioniert?
Gruß,
Thorsten
Hallo,
vielen Dank für die Rückmeldung.
Die Größe der Autosavedateien wird mit 63K angezeigt ("ls -lah").
ZitatGibt es ein anderes Device, bei dem so etwas funktioniert?
Die Hauptrichtung ist bei Verwendung von configdb eher in die Datenbank rein und nicht raus, daher habe ich es noch nicht so oft ausprobiert. Aus der Datenbank raus wollte ich hier nur zur Fehlereingrenzung und weil ich wegen dem funktionierenden Autosavemechanismus davon ausgehe, dass es ohne configdb klappen könnte.
Ich habe configdb schon länger im Einsatz und war von Folgendem ausgegangen:
Durch den Einsatz von configdb wird die Konfiguration fhem.cfg inkl. Versionierung in einer Datenbank gespeichert. Zusätzliche Dateien können mit "configdb filemove ..." in die Datenbank verschoben werden. Zwischen dem Speicherplatz als lokaler Datei und der Datenbank hatte ich eine Art Priorisierung erwartet (erst lokale Datei, dann Datenbank). Wahrscheinlich liege ich damit falsch.
Im Zusammenhang mit
ZitatData too long for column 'content' at row 1...
gibt es in der Datenbank "fhem" eine Tabelle "fhemb64filesave". Diese hat zwei Spalten:
- filename, Typ Text
- content, Typ Blob
Blob geht laut Wikipedia nur bis 64KiB. Also habe ich über phpmyadmin in der Struktur auf Longblob geändert.
Es funktioniert jetzt. Verwunderlich ist, dass es vorher nicht aufgefallen ist (sowohl bei mir als auch bei anderen). Ich habe nie in der Datenbankstruktur etwas geändert... Sorry nochmal für die völlig falsche Fährte und vielen Dank für den Tipp.