Hallo zusammen,
kurze Frage - funktioniert DBLog mit multiplen Instanzen? Sprich, mehrere eigenständige FHEM-Rechner loggen gemeinsam in eine DB auf einem dritten Recher? Damit könnte ich mehrere Instanzen zentral aus einem DBlog heraus monitoren und visualisieren, so zumindest die Idee. Oder gibt das Chaos?
Grüße Sascha
Gesetz dem Fall, dass du mit MySQL arbeitest: In die gleiche DB auf jeden Fall. In die gleichen Tabelle: Das würde ich lassen und das wird auch nicht gut gehen.
Für die Antwort auf die Frage liegen jedoch zu wenig Infos vor (über was für eine Datenbank sprechen wir hier!?).
Jau, ist MySQL. Da mich FHEM2FHEM nur bedingt überzeugt war die Überlegung das in MySQL zusammenzuführen. Ich will einige alte Pi1 für Messungen benutzen, die aber nicht unbedingt alle für Plots separat ansteuern. MySQL läuft auf einem Win10 Rechner mit x5-Z8300, der sollte die Graphen der zusammengeführten Daten aufbereiten und im Intranet bereitstellen. Läuft momentan in der Kombi mit dem Hauptsystem FHEM, wenn ich aber einen Stack an Plots in der TabletUI auf einer Seite anzeigen lassen will ist das trotz PI3 recht zäh.
Daher war meine Idee - "Hey, was wäre wenn die alle in die selbe MySQL-Tabelle loggen und ich die Daten mit einer separaten Instanz visualisiere"..
Hi Tedious,
genau vor dem selbigen Problem stehe ich auch gerade. Habe einige GPIO Temperatur Fühler und diese loggen zur Zeit über FHEM2FHEM in die Logfiles.
Dieses gefällt mir aber auch nur bedingt, zumal ich gestern beim Test gesehen habe das der Dummy den Eintrag immer doppelt in die Datenbank inserted (in das Logfile ist es nur einmal).
Dadurch kam mir auch diese Idee, denn eine MYSQL / Postgresql Datenbank sollte hier keine Probleme haben. Bei der SQLITE wäre ich mir hierbei nicht so sicher das dieses Funktioniert.
Doch dadurch das wir in der Datenbank nur inserts + selects haben, kann ich mir keine Probleme vorstellen.
Hast du hierbei schon Erfahrungen sammeln können? Also funktioniert dieses bei dir?
Würde das sonst heute Abend mal umsetzen und dann berichten.
Ich habs jetzt so gelöst - der 1Wire-FHEM im Heizungskeller loggt gar nichts (kein Filelog), sondern ist nur via FHEM2FHEM angebunden. Die Hauptinstanz greift die Daten via cloneDummy ab und schreibt neue eigene Werte in die SQL-DB. Funktioniert hervorragend, und man sieht weder in FHEM noch in der DB dass es eigentlich zwei FHEM Installationen sind.
Danke für die schnelle Antwort, sieht so aus, als ob CloneDummy ( https://fhem.de/commandref_DE.html#cloneDummy ) die Lösung wäre.
Werde mir die möglichkeit mal offen halten, zur Zeit mache ich es halt mit einem normalen Dummy, wie schon geschrieben, inserted er den Eintrag so aber doppelt in die DB:
define HZ_Vorlauf_Brenner_Messung dummy
attr HZ_Vorlauf_Brenner_Messung alias HEIZUNG VORLAUF BRENNER MESSUNG
attr HZ_Vorlauf_Brenner_Messung group Heizung
attr HZ_Vorlauf_Brenner_Messung icon sani_heating
attr HZ_Vorlauf_Brenner_Messung room 01 Heizung
attr HZ_Vorlauf_Brenner_Messung stateFormat {sprintf "%.2f °C", ReadingsVal($name, "temperature", 0)}
define FileLog_HZ_Vorlauf_Brenner_Messung FileLog ./log/HZ_Vorlauf_Brenner_Messung-%Y-%m.log HZ_Vorlauf_Brenner_Messung
attr FileLog_HZ_Vorlauf_Brenner_Messung logtype text
attr FileLog_HZ_Vorlauf_Brenner_Messung room hidden
Somit hab ich schon mal zwei möglichkeiten ans Ziel zu kommen, danke :)
Da Datenbanken aber dafür ausgelegt sind, Multithreaded zu arbeiten, werde ich erst mal die MySQL option testen.
Glaube hier kommt auch der Spieltrieb etwas durch ;D
Zitat von: marvin78 am 21 Oktober 2016, 15:35:41
Gesetz dem Fall, dass du mit MySQL arbeitest: In die gleiche DB auf jeden Fall. In die gleichen Tabelle: Das würde ich lassen und das wird auch nicht gut gehen.
Die Antwort ist zwar schon etwas älter, aber da der Thread gerade wieder hervor gekramt wurde:
Es ist problemlos möglich, dass mehrere Instanstanzen/Clients/... in eine Datenbank und auch ein ein Tabelle schreiben. Die zitierte Aussage ist schlicht falsch, wenn es sich um eine MySQL DB handelt.
Immerhin konntest du nicht einfach auf "andere Meinung" klicken...
Von technischen Unmöglichkeiten habe ich überhaupt nicht gesprochen. Es geht eher darum, dass es schwierig wird, das zu verwalten ("...würde es lassen..."). Und ich habe geschrieben, dass das nicht gut gehen wird, weil es in der praktischen Umsetzung recht wahrscheinlich ist, dass es Probleme mit gleichen Devicenamen etc. geben könnte.
Zitat von: Kaufe am 07 Februar 2017, 10:37:23
Werde mir die möglichkeit mal offen halten, zur Zeit mache ich es halt mit einem normalen Dummy, wie schon geschrieben, inserted er den Eintrag so aber doppelt in die DB:
Wie gesagt, cloneDummy funktioniert 1a. Schaut bei mir so aus:
#FHEM2FHEM Keller
define Remoteserver FHEM2FHEM 192.168.192.23:7072 LOG:.*
attr Remoteserver room System
define WW_Vorlauf cloneDummy WW_Vor T
attr WW_Vorlauf DbLogExclude .*
attr WW_Vorlauf room Heizung
attr WW_Vorlauf stateFormat _state
define WW_Ruecklauf cloneDummy WW_Rueck T
attr WW_Ruecklauf DbLogExclude .*
attr WW_Ruecklauf room Heizung
attr WW_Ruecklauf stateFormat _state
define FB_Ruecklauf cloneDummy FB_Rueck T
attr FB_Ruecklauf DbLogExclude .*
attr FB_Ruecklauf room Heizung
attr FB_Ruecklauf stateFormat _state
define FB_Vorlauf cloneDummy FB_Vor T
attr FB_Vorlauf DbLogExclude .*
attr FB_Vorlauf room Heizung
attr FB_Vorlauf stateFormat _state
define Kessel_Vorlauf cloneDummy Kessel_Vor T
attr Kessel_Vorlauf DbLogExclude .*
attr Kessel_Vorlauf room Heizung
attr Kessel_Vorlauf stateFormat _state
define Kessel_Rucklauf cloneDummy Kessel_Rueck T
attr Kessel_Rucklauf DbLogExclude .*
attr Kessel_Rucklauf room Heizung
attr Kessel_Rucklauf stateFormat _stateDaraus baue ich mir denn die Grafiken:
Hi Marwin78,
klar verstehe ich deine Punkte, da der MySQL Administrationspunkt nicht ganz ohne ist. Bin nur lange genug als Linux Admin unterwegs, das mir "berechtigungsstufen + absicherung" auf Datenbank sowie Netzwerk-basis mir keine Probleme bereiten dürften. Die Tabelle ist zudem sehr einfach gehalten und hat keinerlei Keys, also sollten auch Dupplikate kein Problem sein. Wo ich mir schwierigkeiten vorstellen kann, vielleicht meinst du auch das, wenn beide FHEM instanzen in die selbige Datenbank schreiben mit dem selbigen DeviceName, denn hier kann GPLOT diesen dann nicht mehr auseinanderhalten.
@Tedious:
Spitze, danke schon mal für die Config, was mich wundert, dein Kessel heizt um 6 Uhr auf knapp 75 Grad auf? Ist das wegen Salmonellen Schutz? Oder was hat das für einen Hintergrund? Konnte es mir nicht verkneifen, meine Bilder auch mal anzuhängen :D
Danke trotzdem für euere Ideen und Antworten, bin schon ganz gespannt welche Lösung am besten Arbeitet :D
Das ist der Heizkreis zum Kessel. Komplizierte Geschichte, liegt am Aufbau des Heizungssystems. Ich messe das vor dem Mischer FBH am Abzweig für den WW-Kreis. Das läuft in den Wasserspeicher und erwärmt hier per Wärmetauscher das Brauchwasser auf 62°C.
@Marwin78,
muss zugeben das ich mir das ganze etwas anders vorgestellt habe, durch das Multible schreiben von verschiedenen FHEM instanzen kann ich mir ja die Werte nicht mehr in der GUI anzeigen, sprich nur noch via DB und nen Graph. Das macht nicht wirklich Sinn. Zudem gibt es sehr wohl einen Search index:
..........
CREATE TABLE `fhem`.`history` (TIMESTAMP TIMESTAMP, DEVICE varchar(32), TYPE varchar(32), EVENT varchar(512), READING varchar(32), VALUE varchar(32), UNIT varchar(32));
CREATE TABLE `fhem`.`current` (TIMESTAMP TIMESTAMP, DEVICE varchar(32), TYPE varchar(32), EVENT varchar(512), READING varchar(32), VALUE varchar(32), UNIT varchar(32));
GRANT SELECT, INSERT, DELETE, UPDATE ON `fhem`.* TO 'fhemuser'@'%';
CREATE INDEX Search_Idx ON `fhem`.`history` (DEVICE, READING, TIMESTAMP);
Habe mich nun doch alles auf CloneDummy umgeschrieben, stehe nun vor dem Problem das er Trotzdem alles doppelt in die Datenbank schreibt, von unterschiedlichen Devices .... Da das Device ja auch über Fhem2Fhem angebunden ist, schreibt er alles doppelt hinein. @Tedious wie hast du das gelöst, oder besteht bei dir das Problem vielleicht auch? Kannst du mir eine Beispiel-Config von beiden FHEMs schicken?
Aktiver FHEM der die Daten ausliest
define FHEM_HZ_HZ_Speicher_Vorlauf GPIO4 28-051xxxxxxxx
attr FHEM_HZ_HZ_Speicher_Vorlauf DbLogExclude .*
attr FHEM_HZ_HZ_Speicher_Vorlauf alias BOILER VORLAUF
attr FHEM_HZ_HZ_Speicher_Vorlauf event-on-change-reading temperature:0.05
attr FHEM_HZ_HZ_Speicher_Vorlauf icon sani_supply_temp
attr FHEM_HZ_HZ_Speicher_Vorlauf model DS18B20
attr FHEM_HZ_HZ_Speicher_Vorlauf pollingInterval 360
attr FHEM_HZ_HZ_Speicher_Vorlauf room GPIO
define HZ_Speicher_Vorlauf cloneDummy FHEM_HZ_HZ_Speicher_Vorlauf
attr HZ_Speicher_Vorlauf alias BOILER VORLAUF
attr HZ_Speicher_Vorlauf group Boiler
attr HZ_Speicher_Vorlauf icon sani_supply_temp
attr HZ_Speicher_Vorlauf room 01 Heizung
attr HZ_Speicher_Vorlauf stateFormat {sprintf "%.2f °C", ReadingsVal($name, "temperature", 0)}