configDB - Fehler bei migrate

[fhainz]

Hallo!

Hab es nach langem suchen geschafft DBD::mysql auf einem Mac richtig zu installieren. (Das hilft)

Nun bekomme ich aber noch diese Fehlermeldung beim migrate:

Code Auswählen Erweitern

DBD::mysql::st execute failed: Data too long for column 'DEVICE' at row 1 at configDB.pm line 380.
DBD::mysql::st execute failed: Data too long for column 'DEVICE' at row 1 at configDB.pm line 380.
Issuing rollback() due to DESTROY without explicit disconnect() of DBD::mysql::db handle database=configDB;host=server.local;port=3306 at configDB.pm line 380.


Es werden 4 Tabellen werden angelegt, fhemconfig hat aber nur 8 Zeilen und fhemversions nur eine. Die anderen beiden Tabellen (fhemfilesave, fhemstate) sind leer.

Hat jemand eine Idee?

Grüße

[betateilchen]

Du hast in Deinem fhem irgendein Gerät mit einem Namen, der länger als 32 Zeichen ist.

[fhainz]

Ok. Hat das einen Grund warum ich nur 32 zur Verfügung hab? Ich würde ungern die ganzen devices umbenennen.

[betateilchen]

Ok. Hat das einen Grund warum ich nur 32 zur Verfügung hab?

Ja, weil ich bei der Entwicklung gedacht habe, dass 32 Zeichen ausreichend sein sollten

Du kannst das manuell über die mysql Konsole ändern:

DROP TABLE fhemconfig
CREATE TABLE IF NOT EXISTS fhemconfig(COMMAND CHAR(32), DEVICE CHAR(64), P1 CHAR(50), P2 TEXT, VERSION INT, VERSIONUUID CHAR(50))

Achtung: Devicenamen länger als 64 Zeichen machen keinen Sinn, weil auch DbLog die Begrenzung auf diese Länge verwendet.

Ich werde bei Gelegenheit über eine sinnvolle Migrationsmöglichkeit nachdenken, da ich diese Feldlänge ohnehin an DbLog anpassen wollte und das irgendwie automatisch passieren soll.

[fhainz]

Perfekt danke.
Hab gerade bei dbLog nachgesehen, da sind auch max. 32 Zeichen erlaubt.

[betateilchen]

Ich wusste doch, dass ich mich daran orientiert hatte. Dann werde ich bei mir nichts ändern. Wie ich auf die 64 eben kam - keine Ahnung.

In DbLog wirst Du das übrigens höchstwahrscheinlich nicht so einfach ändern können.
Solltest Du also irgendwann auf DbLog umstellen wollen, solltest Du wirklich über eine Umbenennung Deiner Devices nachdenken.

[fhainz]

Ok dann stell ich das bei mir in dbLog auch noch um.

Danke!

[betateilchen]

Hatte ich nicht grade geschrieben, dass das dort nicht so einfach funktionieren wird?

[fhainz]

Hast du das reineditiert? 

Ok schade... wollte als nächstes dblog angehen.
Dann werd ich erstmal beim FileLog bleiben, einen wirklichen Grund umzusteigen hab ich nicht. Wollte das ganze eigentlich nur mal ausprobieren.

[fhainz]

Beim starten mit configDB bekomm ich diesen Fehler:

Code Auswählen Erweitern

Can't locate RTypes.pm in @INC (@INC contains: /Library/Perl/5.16/darwin-thread-multi-2level /Library/Perl/5.16 /Network/Library/Perl/5.16/darwin-thread-multi-2level /Network/Library/Perl/5.16 /Library/Perl/Updates/5.16.2/darwin-thread-multi-2level /Library/Perl/Updates/5.16.2 /System/Library/Perl/5.16/darwin-thread-multi-2level /System/Library/Perl/5.16 /System/Library/Perl/Extras/5.16/darwin-thread-multi-2level /System/Library/Perl/Extras/5.16 .) at fhem.pl line 429.


Heißt das, dass die Datei auf einem System fehlt oder hat das was mit dem Problem von gestern zu tun? Weißt du wo ich die herbekomme?

[betateilchen]

ad-hoc Lösung: Kopiere die Datei RTypes.pm von /opt/fhem/FHEM nach /opt/fhem

Morgen kommt die Lösung per update, dann kannst Du die Datei aus /opt/fhem wieder löschen. Rudi hat an der Stelle heute nochmal was geändert, was nicht configDB kompatibel war.

Oder verwende die aktuelle Dateien configDB.pm und fhem.pl aus dem SVN.

[fhainz]

Oder verwende die aktuelle Dateien configDB.pm und fhem.pl aus dem SVN.

Hat geklappt danke. Nun läuft's!

[fhainz]

Ich hab noch etwas gefunden.
Im DEF Feld (notifys, at, readingsGroup, etc) verwende ich immer Zeilenumbrüche. Diese wurden beim migrieren mit einem \ ersetzt. Viele meiner Definitionen funktionieren somit nicht mehr. Sieht jetzt zB so aus:

Code Auswählen Erweitern

geofancy.currLoc_Fabian:.* {\  my $currLoc_Fabian = ReadingsVal("geofancy","currLoc_Fabian","0");\  my $homeStatus     = ReadingsVal("homestatusFabian","state","0");\  \  if( $currLoc_Fabian eq "home" && $homeStatus eq "absent" ) {\    fhem("set homestatusFabian present");\  }\  elsif( $currLoc_Fabian eq "underway" && $homeStatus eq "present" ) {\    fhem("set homestatusFabian absent");\  }\}

Gibt es da noch einen Bug beim migieren?

[betateilchen]

Gibt es da noch einen Bug beim migieren?

Eigentlich ist mir da kein Bug bekannt, da die Daten nicht aus der fhem.cfg in die Datenbank geschrieben werden, sondern aus der geladenen Konfiguration.

Davon abgesehen: solche Konstruktionen sind als Funktion in der 99_myUtils.pm viel besser aufgehoben als in einem DEF.

[fhainz]

Davon abgesehen: solche Konstruktionen sind als Funktion in der 99_myUtils.pm viel besser aufgehoben als in einem DEF.

Klar, längere Sachen packe ich normal immer in die 99_myUtils.pm. Bis auf die, teilweise sehr langen, ReadingsGroups DEF. Die kann man ja nicht auslangen. Oder? Aber wenns nur 2-3 Zeilen sind zahlt sich das nicht aus, finde ich. Dann bin ich bei einer möglichen Fehlersuche nur mehr am hin und her klicken und am unterschiedliche devices und Dateien öffnen.
Meine 99_myUtils.pm ist derzeit schon ziemlich unübersichtlich, wenn ich alle notify und at's auslagere find auch ohne Such Funktion gar nichts mehr Vielleicht mach ich mir mehrere 99_my*.pm Dateien. Eine für at's eine für notifys usw.

Also bleibt mir nichts anderes übrig alles alle betroffenen DEF's zu ändern?