Eine log-DB mit mehreren fhem-Instanzen

[pc1246]

Hallo zusammen
Ich habe mal eine Frage. Ich habe eine log-DB erfolgreich (Dank DS-Starter) auf einer Synology laufen. Nun moechte ich aus Performancegruenden auf einen Thinclient wechseln. Das System ist aufgesetzt und laeuft auch, nur scheue ich mich noch vor dem Umzug. Ein erster Schritt waere jetzt, dass ich die DB von beiden Systemen aus nutzen koennte, und insbesondere mit dem neuen System die alten Daten ansehen kann. Ist das moeglich, oder fuehrt das zu Problemen? Wuerden doppelte Eintraege entstehen, wenn z.B. die PCA Steckdosen in beiden Systemen existieren, mit gleichen Namen!
Danke und Gruss
Christoph

[abc2006]

Hi,
mit dem neuen System die alten Daten ansehen sollte gehen.

logDB loggt (wie Filelog) keine Devices, sondern Events. Und wenn du deine Steckdosen auf beiden Systemen angelegt, hast, aber lediglich auf dem einen System den Empfänger konfigurierst, sollten bei dem anderen keine Events entstehen ...

Grüße,
Stephan

[devo]

Hallo Christoph,

meine mySQL-Datenbank liegt auch auf einem Server und meine drei Fhem-Instanzen greifen per LAN auf diese Datenbank zu. Das funktioniert prima.

[Amenophis86]

Einfach für jedes FHEM eine eigene DB in MySql anlegen. Haste keine Probleme. Ich habe zB für ein FHEM zwei DB am laufen. In der eine Langezeitwerte in der anderen zum testen, oder kurzzeit Werte.

[pc1246]

Einfach für jedes FHEM eine eigene DB in MySql anlegen. Haste keine Probleme. Ich habe zB für ein FHEM zwei DB am laufen. In der eine Langezeitwerte in der anderen zum testen, oder kurzzeit Werte.

Moin
Aber das ist genau das was ich nicht haben will!
Gruss Christoph

[Amenophis86]

JOa, war auch nur ein Beispiel und das es so geht, wie du willst wurde dir schon gesagt.

[DS_Starter]

Hallo zusammen,

von mir auch noch ein paar Bemerkungen dazu.
Prinzipiell kann man natürlich von mehreren FHEM Instanzen aus in einer zentralen DB (z.B. auf Synology) loggen.
Aber es ergeben sich ein paar Nebenwirkungen die man wissen/beachten sollte.

Die Datenbank, oder vielleicht genauer die Tabellen current/history sind nicht mandantenfähig. Das bedeutet, dass man nicht unterscheiden kann von welchem FHEM-Rechner/FHEM-Instanz die Datensätze gekommen sind.
Es könnte natürlich dazu führen dass doppelte Datensätze entstehen, sofern auf den loggenden FHEM-Servern gleiche Devices mit gleichen Readings vorhanden sind.
ABER Auswertungen durch SVG-Diagramme, DbRep usw. können NICHT bzgl. der Zuordnung der Daten bzgl. der jeweiligen Quell-FHEMs unterscheiden.
Das bedeutet, dass im ungünstigen Fall in den SVG's der FHEM-Instanzen die Werte aller FHEM-Instanzen (bei entsprechnenden Übereinstimmungen der Devices/Readings) enthalten sind und die Auswertung verfälschen können.

Ähnliches gilt für die current-Tabelle, die quasi von allen FHEM-Instanzen befüllt wird (wenn genutzt) und die Vorschlagsliste bei der Erstellung eines SVG die Daten ALLER FHEM-Instanzen anbieten wird, unabhängig davon ob sie von dort gekommen sind.

Also müßte man, meiner Meinung nach, sehr darauf achten dass es keine Device-Namen Doppelungen in den anzuschließenden FHEM-Instanzen gibt damit die Auswertungen dann nicht durcheinander kommen.

EDIT: Vielleicht noch der Hinweis, dass ich es so mache wie von Amenophis86 in #3 beschrieben. Es gibt nur eine MariaDB-Installation auf der Synology und in dieser sind 4 FHEM-Datenbanken enthalten in die verschiedene FHEM-Instanzen über DbLog-Devices hineinloggen.

Grüße
Heiko

[pc1246]

Hallo Heiko
Danke fuer deine Einschaetzung. Dann muss ich mal sehen, wie ich meinen Umzug gestalte.
Evtl. einfach radikal, da mir manche Namen eh nicht so wirklich gefallen
Gruss Christoph