Hallo zusammen,
ich bin neu in dem Forum und der Thematik, habe aber mit Hilfe der tollen Anleitungen hier FHEM mit DBLog und einer lokalen MySQL, sowie dem Charting Frontend konfigurieren können. Das funktioniert auch super, läuft aber noch alles auf meinem lokalen Windows PC.
Ich möchte nun statt der lokalen MySQL Datenbank aber eine MySQL Datenbank in einer Cloud nutzen, die Konfiguration über Command Line von meinem lokalen PC funktioniert auch, aber ich scheitere an der korrekten Konfiguration im db.conf File.
Die Verbindung funktioniert problemlos:
c:\FHEM>mysql -h fhem.mysql.xxx.com -u user@fhem --protocol=TCP -p
Meiner Meinung liegt es am den "@" Zeichen, welches ich im User-Name benötige.
Aktuell sieht meine db.conf so aus:
%dbconfig= (
connection => "mysql:database=fhem;host=fhem.mysql.xxx.com;protocol=TCP",
user => "user@fhem",
password => "passwort",
);
Ich habe schon versucht das "@" als ASCII Code (064, x40) einzufügen, bisher erfolglos - hier fehlt mir wahrscheinlich die korrekte Syntax.
Wenn jemand einen Tipp hat, wäre ich sehr dankbar.
Das @-Zeichen ist für MySQL/MariaDB ein Trenner zwischen Usernamen und Hostnamen.
Kannst Du daher nicht im Usernamen verwenden.
Ciao, -MN
Danke für die schnelle Antwort.
Das "@" ist, soweit ich es verstanden habe durch den Cloud Anbieter im Username vorgegeben, ohne klappt auch die Verbindung per Command-Line nicht.
Das wäre ärgerlich, wenn es damit gar nicht genutzt werden kann.
Hat denn Dein Klaut-Anbieter keine Doku?
Ciao, -MN
Versuche db.conf mal so zu definieren:
%dbconfig= (
connection => "mysql:database=fhemtest;host=fhem.mysql.xxx.com;port=3306",
user => "user\@fhem",
password => "passwort"
);
Nach der Änderung "set rereadcfg" und eventuell "set reopen". Beobachte auch Meldungen im Logfile. Mit nur "@" im Namen hättest du so etwas im Log finden können/müssen:
2018.01.15 18:07:28.338 1: PERL WARNING: Possible unintended interpolation of @fhem in string at (eval 659892) line 9.
2018.01.15 18:07:28.339 1: PERL WARNING: Variable "@fhem" is not imported at (eval 659892) line 9.
2018.01.15 18:07:28.339 1: PERL WARNING: (Did you mean &fhem instead?)
Grüße,
Heiko
Irgendwie will es nicht klappen, dass mein FHEM auf eine externe MySQL Datenbank zugreift. Ich bin inzwischen ein Stück weiter und habe in der Datenbank einen weiteren User (fhemuser) angelegt, mit dem ich von meinem lokalen PC auch per CMDLine auf die MySQL Datenbank zugreifen kann.
Wenn ich die db.conf aber für diese externe MySQL Datenbank konfiguriere:
%dbconfig= (
connection => "mysql:database=fhem;host=fhem.mysql.xxx.com;port=3306",
user => "fhemuser",
password => "password",
klappt der connect in FHEM nicht:
2018.01.15 19:55:26 4: Waiting for database connection
2018.01.15 19:55:31 3: DbLog logdb: Creating Push-Handle to database mysql:database=fhem;host=fhem.mysql.xxx.com;port=3306 with user fhemuser
2018.01.15 19:55:31 4: DbLog $name: Trying to connect to database
2018.01.15 19:55:31 5: Starting notify loop for logdb, 1 event(s), first is disconnected
2018.01.15 19:55:31 5: End notify loop for logdb
2018.01.15 19:55:31 4: Waiting for database connection
Ändere ich wieder auf die lokale MySQL, kommt die Bestätigung
2018.01.15 20:02:41 3: DbLog logdb: Creating Push-Handle to database mysql:database=fhem;host=127.0.0.1;port=3306 with user fhemuser
2018.01.15 20:02:41 3: DbLog logdb: Push-Handle to db mysql:database=fhem;host=127.0.0.1;port=3306 created
Irgendwo muss noch ein genereller Fehler drin sein. Hat jemand schon erfolgreich auf eine externe MySQL Datenbank (im Internet) zugreifen können?
Möglicherweise braucht man dafür einen anderen Perl DBD-Treiber.
Zum Beispiel wie den "Perl DBI Module for ECS":
https://aws.amazon.com/de/blogs/aws/perl_dbi_module/
Nur mal als Vermutung. Ich selbst habe keine Erfahrung damit.
Zitat von: DS_Starter am 15 Januar 2018, 18:16:54
Versuche db.conf mal so zu definieren:
%dbconfig= (
connection => "mysql:database=fhemtest;host=fhem.mysql.xxx.com;port=3306",
user => "user\@fhem",
password => "passwort"
);
Nach der Änderung "set rereadcfg" und eventuell "set reopen". Beobachte auch Meldungen im Logfile. Mit nur "@" im Namen hättest du so etwas im Log finden können/müssen:
2018.01.15 18:07:28.338 1: PERL WARNING: Possible unintended interpolation of @fhem in string at (eval 659892) line 9.
2018.01.15 18:07:28.339 1: PERL WARNING: Variable "@fhem" is not imported at (eval 659892) line 9.
2018.01.15 18:07:28.339 1: PERL WARNING: (Did you mean &fhem instead?)
Grüße,
Heiko
Hallo Heiko,
mit dem Backslash \ hat es letztendlich funktioniert, vielen Dank.
Damit sind die MySQL Daten schon mal in der Cloud. Als nächstes werde ich mir mal die Visualisierungslösungen dort anschauen, es macht ja keinen Sinn, die Daten erst von FHEM in die Cloud zu bringen und dann mit dem Frontend auf FHEM wieder lokal als Plot zu visualisieren. Es geht mir primär um das Logging einer Buderus Heizung mit KM200.
Gruß, Arne.
Hallo Arne,
toll dass es jetzt funktioniert.
Würde dir auf jeden Fall empfehlen DbLog in den asynchronen Modus zu schalten, damit dein FHEM entkoppelt ist von der Verfügbarkeit deiner Cloud-DB.
Es wäre für mich interressant wie gut (oder schlecht) das DbLog-Device mit dem Cloudservice funktioniert, zum Beispiel die Prozesszeiten.
Setze dir dazu das Attribut "showproctime=1".
Und auch wenn du es nicht nutzen willst, einfach zum Test mal in FHEM ein SVG anlegen und schauen wie sich das System damit verhält.
Würde mich freuen wenn du über deine Erfahrungen damit etwas berichten würdest (sicherlich auch für andere User interressant).
Grüße,
Heiko
Hi Heiko,
ich habe showproctime=1 jetzt mal für DBLog gesetzt. Aber wo sehe ich die Werte - oder muss ich verbose noch hochsetzen.
Bis jetzt läuft die Verbindung absolut stabil im synchronous Mode.
Ein Plot im Charting-Frontend dauert schon etwas länger (ca. 5-10 sec) - da habe ich aber keinen Vergleich zu einer lokalen mySQL DB auf meinem Raspberry PI.
Gruß, Arne.
Hi Arne,
Zitatich habe showproctime=1 jetzt mal für DBLog gesetzt. Aber wo sehe ich die Werte - oder muss ich verbose noch hochsetzen.
Es werden die Readings "background_processing_time" und "sql_processing_time" generiert, also nicht im Log mit verbose x. Aber das passiert nur wenn du in den asynchronen Modus schaltest. Sorry, dass ich es nicht erwähnt hatte.
ZitatBis jetzt läuft die Verbindung absolut stabil im synchronous Mode.
Erstaunlich und zugleich erfreulich. Keine Hänger bzw. freezes in FHEM ?
ZitatEin Plot im Charting-Frontend dauert schon etwas länger (ca. 5-10 sec)
Naja, bei mir dauert es < 1s, aber mein FHEM läuft auch auf einem NUC.
Aber immerhin doch recht erstaunlich. Wenn du die Zahlen der Readings noch posten könntest, würden wir ziemlich genau sehen wielange das Schreiben der Daten dauert.
Gruß,
Heiko
ok, das erklärt natürlich warum ich die processing times nicht gefunden habe.
Dumme Frage: wie setze ich die DBLog connection in async mode?
Danke.
Zitatwie setze ich die DBLog connection in async mode?
Attribut asyncMode = 1
Danke, einfacher als gedacht.
Hier mal die ersten Werte:
2018-01-31 20:54:46 DbLog logdb background_processing_time: 2.4080
2018-01-31 20:54:46 DbLog logdb sql_processing_time: 2.1040
2018-01-31 20:55:15 DbLog logdb sql_processing_time: 0.7177
2018-01-31 20:55:45 DbLog logdb background_processing_time: 1.1224
2018-01-31 20:55:45 DbLog logdb sql_processing_time: 0.8189
2018-01-31 20:56:45 DbLog logdb background_processing_time: 0.8568
2018-01-31 20:56:45 DbLog logdb sql_processing_time: 0.5381
2018-01-31 20:57:15 DbLog logdb background_processing_time: 0.8534
2018-01-31 20:57:15 DbLog logdb sql_processing_time: 0.5446
Sind das Sekunden?
Die mySQL liegt in Azure.
Normaler 16/1 DSL Anschluss.
Ja, das sind Sekunden.
Garnicht schlecht. Ich würde die DB im async Mode lassen, sonst hast du unter Umständen freezes.
Mach mal bitte noch ein set configCheck.
Danke Heiko.
configCheck gab die Empfehlung, shutdownWait auf 2 sec zu setzen (habe ich gemacht), sowie Encoding auf UTF8 (war LATIN1).
In 2 Wochen soll ich Glasfaser 500/100 bekommen, dann werde ich nochmal die processing times vergleichen.
Gruß, Arne.