Hallo!
Hab es nach langem suchen geschafft DBD::mysql auf einem Mac richtig zu installieren. (Das hilft (http://stackoverflow.com/questions/6383310/python-mysqldb-library-not-loaded-libmysqlclient-18-dylib?answertab=votes#tab-top))
Nun bekomme ich aber noch diese Fehlermeldung beim migrate:
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
Du hast in Deinem fhem irgendein Gerät mit einem Namen, der länger als 32 Zeichen ist.
Ok. Hat das einen Grund warum ich nur 32 zur Verfügung hab? Ich würde ungern die ganzen devices umbenennen.
Zitat von: fhainz am 26 April 2014, 13:24:26
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 8)
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.
Perfekt danke.
Hab gerade bei dbLog nachgesehen, da sind auch max. 32 Zeichen erlaubt.
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.
Ok dann stell ich das bei mir in dbLog auch noch um.
Danke!
Hatte ich nicht grade geschrieben, dass das dort nicht so einfach funktionieren wird?
Hast du das reineditiert? :o
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.
Beim starten mit configDB bekomm ich diesen Fehler:
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?
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.
Zitat von: betateilchen am 26 April 2014, 14:39:46
Oder verwende die aktuelle Dateien configDB.pm und fhem.pl aus dem SVN.
Hat geklappt danke. Nun läuft's!
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:
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?
Zitat von: fhainz am 26 April 2014, 15:05:54
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.
Zitat von: betateilchen am 26 April 2014, 15:28:00
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?
grrrrrrr......
gib mir doch wenigstens mal eine halbe Stunde Zeit, um mich um das Thema zu kümmern.
Sry war mir nicht klar das du dich gleich darum kümmerst.
Bin schon still..
*grübel*
(abgesehen davon, dass ich in einem Jahr Nutzung von fhem nie auf die Idee kam, ein DEF mehrzeilig anzulegen)
Ich kann jetzt bei der Migration die mehrzeiligen DEF korrekt importieren und die at und notify funktionieren auch.
Aber sobald Du das zum ersten Mal editieren willst, verhunzt der FHEMWEB Editor (egal ob Standard oder codemirror) das DEF wieder - aber nur beim ersten Mal.
Ich habe gerade eine neue Version von configDB.pm bereitgestellt: # $Rev: 5671 $
Damit sollte die Migration funktionieren.
Nach der Migration sind die mehrzeiligen DEF in einzeilige DEF umgewandelt.
Wird nach der Migration die Mehrzeiligkeit durch Editieren wiederhergestellt, bleibt sie auch in configDB erhalten.
Bitte testen und berichten. Danke.
Danke das funktioniert schon fast perfekt.
at, notifys, watchdogs hab ich überprüft, da passt alles. Die readingsGroups haut es teilweise noch zusammen.
Sieht zB nun so aus:
ZitathomeTwilight:,<Helligkeit>,twilighthomeTwilight:,<Helligkeit Wetter>,twilight_weatherhomeTwilight:,<Wetter>,condition_txt homeTwilight:,<Sonnenaufgang>,sr_weather homeTwilight:,<Sonnenuntergang>,ss_weatherhomeTwilight:,<Tageslänge>,tageslaenge
Meinst du kriegst du das auch noch hin? Ansonsten wäre es nicht so wild. Die paar readingsGroups könnte ich per hand machen, das wäre nicht das Problem.
readingsGroups kenne ich überhaut nicht.
Was ist da genau das Problem?
Wie sieht es in der fhem.cfg aus?
Wie sollte es aussehen?
Normalerweise sieht die o.G. readingsGroup so aus
homeTwilight:,<Helligkeit>,twilight
homeTwilight:,<Helligkeit Wetter>,twilight_weather
homeTwilight:,<Wetter>,condition_txt
homeTwilight:,<Sonnenaufgang>,sr_weather
homeTwilight:,<Sonnenuntergang>,ss_weather
homeTwilight:,<Tageslänge>,tageslaenge
in der cfg:
define TwilightWerte readingsGroup homeTwilight:,<Helligkeit>,twilight\
homeTwilight:,<Helligkeit Wetter>,twilight_weather\
homeTwilight:,<Wetter>,condition_txt\
homeTwilight:,<Sonnenaufgang>,sr_weather \
homeTwilight:,<Sonnenuntergang>,ss_weather\
homeTwilight:,<Tageslänge>,tageslaenge
attr TwilightWerte alias Umwelt
attr TwilightWerte group Wetter
attr TwilightWerte mapping ;
attr TwilightWerte notime 1
attr TwilightWerte room 5. Wohnung
Die Problemstellen sind oben rot markiert. Ich denke wenn kein Leerzeichen nach dem Letzten Zeichen ist (nach sr_weather war zufällig eines, oben grün) klappt die Migrierung nicht richtig.
Anbei noch 2 screenshots.
Ich sehe weder rote Markierungen noch Screenshots.
Das Ganze funktioniert bei der Migration deshalb nicht, weil am Ende einer Zeile kein Semikolon steht. Mal schauen, ob ich da noch was machen kann.
Zitat von: betateilchen am 26 April 2014, 17:48:37
Ich sehe weder rote Markierungen noch Screenshots.
Sehr eigenartig.
Rote Markierung im quote
(http://thumbs.picr.de/18090527fx.jpg) (http://show.picr.de/18090527fx.jpg.html)
Screenshots
(http://thumbs.picr.de/18090519uw.jpg) (http://show.picr.de/18090519uw.jpg.html)
und mit picr kannst Du offenbar auch nicht umgehen 8)
Kannst Du mal bitte die angehängte Version testen, bevor ich sie einchecke?
Mangels selbst eingesetzter readingsGroup kann ich das nicht selbst ausprobieren.
nein, ich weiss schon, die Version funktioniert nicht.
Stimmt :)
jetzt aber... (hoffentlich)
Super, das migrate funktioniert jetzt ohne Probleme!
Danke dir vielmals für deine Mühe!
Grüße
Zitat von: fhainz am 26 April 2014, 18:19:36
Super, das migrate funktioniert jetzt ohne Probleme!
bis der nächste mit irgendwelchen dubiosen DEFs um die Ecke kommt 8)
Zitat von: betateilchen am 26 April 2014, 16:14:01
Wird nach der Migration die Mehrzeiligkeit durch Editieren wiederhergestellt, bleibt sie auch in configDB erhalten.
Nach einem Neustart ist die Mehrzeiligkeit leider wieder verschwunden :(
Könntest du, wenn du Zeit hast, da nochmals nachschauen?
Grüße
ich hatte vor einigen Tagen Rudi schon gebeten, darüber nachzudenken, wie man das Lesen/Bearbeiten/Schreiben von mehrzeilign DEFs kapseln kann, um solche Probleme künftig zu umgehen. Das zerhackstückeln kommt nicht aus der configDB sondern aus dem Frontend, weil dort anhand der Unterscheidung zwischen fhem.cfg und configDB derzeit noch manches doppelt implementiert ist. Wir sind gerade dabei, das zu ändern und zu standardisieren. Ich hoffe, dass da auch in Bezug auf die DEFs etwas besseres rauskommt. Bitte um Geduld.
http://forum.fhem.de/index.php/topic,22927.msg162980.html#msg162980
Klar, keine Hektik genieß erstmal deinen Urlaub! ;)
Wenn Du morgen alle anstehenden aktuellen Updates gemacht hast, kann ich Dir im Anschluss eine Testversion geben, mit der Du prüfen kannst, ob das Problem mit den mehrzeiligen DEFs darin behoben ist. Wenn ich danach das OK von Dir bekomme, kann ich die Änderung veröffentlichen. Bei mir scheint das jetzt korrekt zu funktionieren.
Zitat von: betateilchen am 13 Mai 2014, 22:09:10
Wenn Du morgen alle anstehenden aktuellen Updates gemacht hast, kann ich Dir im Anschluss eine Testversion geben, mit der Du prüfen kannst, ob das Problem mit den mehrzeiligen DEFs darin behoben ist. Wenn ich danach das OK von Dir bekomme, kann ich die Änderung veröffentlichen. Bei mir scheint das jetzt korrekt zu funktionieren.
Wenn Du noch einen Tester benötigst, dann mach ich das gerne... :)
Updates sind gemacht, ich warte auf die neue Version.
Grüße
heute abend, wenn ich wieder zuhause bin.
*grmpf* grade hat mir das fhem-Update die Testversion überschrieben - das kommt davon, wenn man im völlig übermüdeten Zustand irgendwas am Computer macht.
so, jetzt aber...
Testversion im Anhang, mit der jetzt auch mehrzeilige DEFs (hoffentlich) funktionieren.
Funktioniert wunderbar!
Vielen Dank für deinen Einsatz!
Grüße
Danke für den Test und die Rückmeldung.
Dann gibts die Version morgen offiziell per Update :)
configdb klaut seit heute Backslashs aus der Konfiguration. Bei mir hier bei den Icondefinitionen für die Farbe "Icon\@Farbe".
teste mal bitte die Version hier im Anhang.
Damit kommen viele Meldungen mit nicht definierten Geräten. Das Log fängt so an:
2014.05.15 12:22:54 0: Server shutdown
2014.05.15 12:22:54 2: DbLog myDbLog waiting for shutdown
2014.05.15 12:23:03 3: modpath must point to a directory where the FHEM subdir is
2014.05.15 12:23:03 1: define telnetPort telnetPort telnet 7072 global
: Usage: define <name> telnet { [IPV6:]<tcp-portnr> [global] | [IPV6:]serverName:port }
2014.05.15 12:23:04 1: define WEB WEB FHEMWEB 8083 global
: Usage: define <name> FHEMWEB [IPV6:]<tcp-portnr> [global]
2014.05.15 12:23:04 3: Please define WEB first
2014.05.15 12:23:04 3: Please define WEB first
2014.05.15 12:23:04 3: Please define WEB first
ok, dann nimm bitte die Version von gestern.
Ich habe hier aktuell keine Möglichkeit, Änderungen selbst zu testen, ich muss mir das in Ruhe anschauen.
Grundsätzlich hängt das Problem mit der gestern abend gebauten Änderung für die mehrzeiligen DEFs zusammen.
Ich habe folgende Änderung an dem heutigen Update durchgeführt, damit funktioniert es wieder bei mir.
foreach my $l (@dbconfig) {
$l =~ s/[\r\n]/\n/g;
$l =~ s/\\\n/\n/g;
# if($l =~ m/\\*$/) { # Multiline commands
# $l =~ s/\\/\n/g;
# }
ja, aber damit funktionieren die mehrzeiligen DEFs nicht mehr, falls Du welche in Deinem System hast.
Sicher?
Mehrmals gespeichert und neu gestartet.
Ich hatte übersehen, dass es eigentlich zwei Änderungen sind ;)
Sitze grade im Zug und werde mich unterwegs mal damit befassen. Dieses bescheuerte regexen von DEFs treibt mich langsam aber sicher zur Weissglut.
Danke erstmal für Deinen Tipp.
Irgendwie habe ich bei Deiner Änderung trotzdem Bauchschmerzen.
Im ersten regexp ersetzt Du alle \r oder \n durch \n was erstens für \n sinnlos ist und zweitens dazu führt, dass das Ganze dann auf nicht-unix-Systemen höchstwahrscheinlich nicht mehr funktionieren wird.
Im zweiten regexp ersetzt Du dann alle \ \n durch \n was durchaus im Sinne des Erfinders und das eigentlich gewollte Ergebnis ist.
Irgendwie muss ich das noch umstricken. Es mag sein, dass Deine Änderung auf bestehenden Installationen funktioniert, aber bei der erstmaligen Migration geht das vermutlich daneben.
Ich hab das jetzt mal ausgiebig getestet und Deine Variante eingecheckt. Mal sehen, wann die nächsten karierten Maiglöckchen mit Backslash auftauchen :P
Es braucht eigentlich nur eine Ersetzung:
$l =~ s/\\(\r\n|\n)$/\n/g;
Zitat von: stromer-12 am 15 Mai 2014, 21:40:33
Es braucht eigentlich nur eine Ersetzung:
$l =~ s/\\(\r\n|\n)$/\n/g;
Mac Zeilenende fehlt noch
$l =~ s/\\(\r\n|\n|\r)/\n/g;