Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)

DS_Starter · 06 Mai 2020, 08:25:20

Moin Bernd,

ZitatDie SyncDB kann nur im gleichen Pfad liegen oder es ist z.B. auf dem NAS eine weitere DB-Instanz nötig (Client)!?

Die SyncDB kann irgendwo liegen, also auch auf einem NAS oder bei AWS zB.
Wenn du sie beispielsweise auf dem NAS einrichtest, defininierst du auf deinem _lokalen_ FHEM ein zweites DbLog-Device welches die Verbindung zu dem NAS herstellt. Du verhinderst aber das irgendwas geloggt wird (z.B. wie im Wiki beschrieben).

-> https://wiki.fhem.de/wiki/DbRep_-_Reporting_und_Management_von_DbLog-Datenbankinhalten#Inhalte_einer_prim.C3.A4ren_Datenbank_in_eine_andere_Standby-Datenbank_.C3.BCbertragen_.28syncStandby.29

Dieses neue DbLog-Device (DbLog_Standby im Beispiel) gibst du im Sync-Kommando an:

Code Auswählen

set DbRep_Source syncStandby DbLog_Standby

DbRep_Source ist dein DbRep welches mit der Quelldatenbank (auf dem Raspi) verbunden ist, d.h. mit dem DbLog-Device welches in deine Quelldatenbank loggt.

Hoffe das hilft dir weiter. Ansonsten gerne fragen.

LG,
Heiko

frober · 06 Mai 2020, 09:34:31

Danke Heiko,

soweit hatte ich das verstanden.

Aktuell liegt die Datenbank auf einem USB-Stick der am Raspi angeschlossen ist.

In der my.cnf ist datadir entsprechend angepasst.

Für das NAS etc. brauche ich, soweit mein Verständnis, einen Mariadb-Client oder einen weiteren Mariadb-Server. Dafür dürfte der Router zu schwach sein!?

Mein NAS ist älter, das muss ich erst noch umbauen (andere FW/ freies Debian o.ä.).

Wenn ich nun auf dem Raspi mit Mariadb die SyncDB anlege, liegt diese auf dem gleichen USB-Stick oder kann ich ein zweites datadir angeben?

Dann könnte ich einen weiteren USB-Stick mounten oder den "Router" als Pfad nutzen.

Kurz:
Kann man ein zweites datadir anlegen?
Würde der Router (TP-WR1043 mit openWRT) für einen Mariadb-Client reichen?

Grüße Bernd

DS_Starter · 06 Mai 2020, 11:16:03

Hallo Bernd,

ich glaube jetzt habe ich deine Fragen verstanden.

ZitatFür das NAS etc. brauche ich, soweit mein Verständnis, einen Mariadb-Client oder einen weiteren Mariadb-Server. Dafür dürfte der Router zu schwach sein!?

Router würde ich komplett ausschließen für MariaDB-Server. Falls das überhaupt geht handelt man sich mM nach nur Schwierigkeiten ein.

Thema NAS ... du brauchst auf dem NAS den Mariadb-Server. Den Mariadb-Client installiert man einfach mit, aber den braucht man grundsätzlich auf dem Gerät von welchem aus man auf den Server zugreifen will, also dem Raspi. Den wirst du dort auch bereits haben.

ZitatWenn ich nun auf dem Raspi mit Mariadb die SyncDB anlege, liegt diese auf dem gleichen USB-Stick oder kann ich ein zweites datadir angeben?

Verschiedene datadir geht nicht in einer my.cnf. Das ist ja die Konfiguration für den einen vorhandenen MaraDB Server.
Allerdings kannst du durchaus mehrere MySQL/MariaDB Server auf einer Hardware betreiben wenn diese Hardware die Leistungsfähigkeit (CPU,RAM) mitbringt.

Für dieses Setup musst du aber etwas mehr machen und dich etwas einfuchsen. Hier ->
http://download.nust.na/pub6/mysql/doc/refman/5.1/de/multiple-servers.html
ist zum Beispiel beschrieben wie man sowas erstellen kann.

Hoffe jetzt hab ich es getroffen.

LG,
Heiko

frober · 06 Mai 2020, 11:31:48

Jetzt passt es[emoji6]

Danke nochmals.

Schönen Tag noch und bleib gesund.
Bernd

DS_Starter · 06 Mai 2020, 12:13:08

Danke du auch !

BTW... du kannst alsStandby DB auch erstmal nur eine SQLite einsetzen. syncStandy kann ja auch mit unterschiedlichen Typen arbeiten.

LG,
Heiko

uwirt · 06 Mai 2020, 13:35:40

Ich habe das "at" wie beschrieben gemacht und erhalte folgenden Fehler im logfile:

Code Auswählen


2020.05.06 13:19:03 3: At.DbRep.LogDB.FindNaDevs: Please define Rep.LogDB.FindNaDevs first

Muss ich das zusätzlich definieren oder gibt es da einen Schreibfehler?

Ach ja und - wie kann ich die andauernd wiederkehrende Fehlermeldung im DbLog betreffend den fehlenden Tables unterbinden?

DS_Starter · 06 Mai 2020, 13:57:16

ZitatMuss ich das zusätzlich definieren oder gibt es da einen Schreibfehler?

Naja, das war ja nur ein Beispiel

Du must natürlich dein eigenes DbRep-Device statt "Rep.LogDB.FindNaDevs" eintragen welches du für das sqlCmd verwenden willst.

ZitatAch ja und - wie kann ich die andauernd wiederkehrende Fehlermeldung im DbLog betreffend den fehlenden Tables unterbinden?

verbose 0 im DbLog sollte helfen oder du könntest das DbLog-Device überhaupt mit disable = 1 deaktivieren. Du kannst eh nichts loggen und brauchst das Device nur für die Definition des DbRep.

uwirt · 06 Mai 2020, 14:57:54

Ok - danke, das funktioniert jetzt soweit. Ich versuche jetzt auch mittels timeOlderThan/allowDeletion die Anzahl der Readings auf die letzte halbe Stunde zu limiteren. Mal sehen ob das klappt?!

Nun meine nächste Frage. Wie kann ich aus der Kombination Reading/Value:

Code Auswählen


SqlResultRow_121       120|sur001|403470039|128|42|TCB|15.99|2020-05-06 13:59:16|0|noraw|1       2020-05-06 14:48:43

ein Reading/Value

Code Auswählen


TCB    15.99

zaubern?

Das ursprüngliche Reading "SqlResultRow_121" hat unterschiedliche Nummern.

flummy1978 · 06 Mai 2020, 15:22:51

Holla,

den Anstoß, dass es jemand anders eingerichtet hat und für mich jetzt hier demnächst der Umzug auf die neue Diskstation anliegt, hab ich das zweite Log Device und alles andere auch bei mir auch mal eingerichtet und hab 2 Fragen / Probleme damit:

1. Beim Ausführen des ganzen mit den Einstellungen aus dem Wiki u.a. attr DbRep_syncStandby_LiveDB timeDiffToNow d:5 - Denke das ist hier von Bedeutung.

list von dem betroffenem Device

Code Auswählen

Internals:
   .FhemMetaInternals 1
   CFGFN      
   DATABASE   user_fhem
   DEF        DBLogging
   FUUID      5eb2a8fc-f33f-8d79-0d07-0169629de19e3382
   FVERSION   93_DbRep.pm:v8.40.0-s21546/2020-03-30
   LASTCMD    syncStandby DBLoggingMonnestation
   MODEL      Client
   NAME       DbRep_syncStandby_LiveDB
   NOTIFYDEV  global,DbRep_syncStandby_LiveDB
   NR         153824
   NTFY_ORDER 50-DBLogging_Monnestation_syncStandby
   ROLE       Client
   STATE      error : SQL-Zeit: 
   TYPE       DbRep
   UTF8       1
   .attraggr:
   .attreour:
     state
   .attrminint:
   HELPER:
     DBLOGDEVICE DBLogging
     GRANTS     INDEX,CREATE ROUTINE,TRIGGER,DELETE,REPLICATION CLIENT,RELOAD,SHUTDOWN,ALTER,CREATE USER,INSERT,PROCESS,SHOW VIEW,EXECUTE,SHOW DATABASES,SELECT,ALTER ROUTINE,UPDATE,REPLICATION SLAVE,LOCK TABLES,CREATE VIEW,CREATE TEMPORARY TABLES,REFERENCES,FILE,DROP,EVENT,CREATE
     IDRETRIES  3
     MINTS      2019-09-22 01:30:00
     PACKAGE    main
     SQLHIST    
     VERSION    8.40.0
     CV:
       aggregation day
       aggsec     86400
       destr      2020-05-06
       dsstr      2020-05-01
       epoch_seconds_end 1588770211
       mestr      05
       msstr      05
       testr      15:03:31
       tsstr      15:03:31
       wdadd      259200
       yestr      2020
       ysstr      2020
     DBREPCOL:
       COLSET     1
       DEVICE     64
       EVENT      512
       READING    64
       TYPE       64
       UNIT       32
       VALUE      128
   Helper:
     DBLOG:
       state:
         DBLogging:
           TIME       1588766972.09021
           VALUE      initialized
   OLDREADINGS:
   READINGS:
     2020-05-06 15:04:35   errortext       DBD::mysql::st execute failed: Incorrect datetime value: ' ' for column `fhem_DB_LIVE`.`history`.`TIMESTAMP` at row 1 at ./FHEM/93_DbRep.pm line 11322.

     2020-05-06 15:04:35   state           error
Attributes:
   DbLogExclude .*
   aggregation no
   event-on-update-reading state
   fastStart  1
   group      FileLog
   icon       own-log
   role       Client
   room       System->Datenbank
   showproctime 1
   stateFormat { (ReadingsVal($name,"state", ""))." : SQL-Zeit: ".(ReadingsVal($name,"sql_processing_time", "")) }
   timeDiffToNow d:5
   verbose    4

Hier sieht man schon, dass die Abfragen einwandfrei funktionieren bis hin zu .... errortext DBD::mysql::st execute failed: Incorrect datetime value: ' ' for column `fhem_DB_LIVE`.....
Ausschnitt aus dem Log, nach dem Ausführen:

Code Auswählen

2020.05.06 15:04:27.277 3: DbRep DbRep_syncStandby_LiveDB - total lines transfered to standby database: 11084
2020.05.06 15:04:27.278 3: DbRep DbRep_syncStandby_LiveDB - number of lines inserted into "DBLoggingMonnestation": 11084
2020.05.06 15:04:27.293 4: DbRep DbRep_syncStandby_LiveDB - SQL execute: SELECT TIMESTAMP,DEVICE,TYPE,EVENT,READING,VALUE,UNIT FROM history where TIMESTAMP >= '2020-05-06' AND TIMESTAMP <= '2020-05-06 15:03:31' ;
2020.05.06 15:04:34.440 1: PERL WARNING: Use of uninitialized value $date in concatenation (.) or string at ./FHEM/93_DbRep.pm line 11312.
2020.05.06 15:04:34.440 1: stacktrace:
2020.05.06 15:04:34.441 1:     main::__ANON__                      called by ./FHEM/93_DbRep.pm (11312)
2020.05.06 15:04:34.441 1:     main::DbRep_WriteToDB               called by ./FHEM/93_DbRep.pm (8566)
2020.05.06 15:04:34.441 1:     main::DbRep_syncStandby             called by FHEM/Blocking.pm (194)
2020.05.06 15:04:34.442 1:     main::BlockingStart                 called by FHEM/Blocking.pm (107)
2020.05.06 15:04:34.442 1:     main::BlockingCall                  called by ./FHEM/93_DbRep.pm (2134)
2020.05.06 15:04:34.442 1:     main::DbRep_Main                    called by ./FHEM/93_DbRep.pm (976)
2020.05.06 15:04:34.442 1:     main::DbRep_Set                     called by fhem.pl (3772)
2020.05.06 15:04:34.443 1:     main::CallFn                        called by fhem.pl (1900)
2020.05.06 15:04:34.443 1:     main::DoSet                         called by fhem.pl (1932)
2020.05.06 15:04:34.443 1:     main::CommandSet                    called by fhem.pl (1243)
2020.05.06 15:04:34.443 1:     main::AnalyzeCommand                called by ./FHEM/01_FHEMWEB.pm (2709)
2020.05.06 15:04:34.444 1:     main::FW_fC                         called by ./FHEM/01_FHEMWEB.pm (981)
2020.05.06 15:04:34.444 1:     main::FW_answerCall                 called by ./FHEM/01_FHEMWEB.pm (590)
2020.05.06 15:04:34.444 1:     main::FW_Read                       called by fhem.pl (3777)
2020.05.06 15:04:34.444 1:     main::CallFn                        called by fhem.pl (753)
2020.05.06 15:04:34.445 1: PERL WARNING: Use of uninitialized value $time in concatenation (.) or string at ./FHEM/93_DbRep.pm line 11312.
2020.05.06 15:04:34.445 1: stacktrace:
2020.05.06 15:04:34.445 1:     main::__ANON__                      called by ./FHEM/93_DbRep.pm (11312)
2020.05.06 15:04:34.446 1:     main::DbRep_WriteToDB               called by ./FHEM/93_DbRep.pm (8566)
2020.05.06 15:04:34.446 1:     main::DbRep_syncStandby             called by FHEM/Blocking.pm (194)
2020.05.06 15:04:34.446 1:     main::BlockingStart                 called by FHEM/Blocking.pm (107)
2020.05.06 15:04:34.446 1:     main::BlockingCall                  called by ./FHEM/93_DbRep.pm (2134)
2020.05.06 15:04:34.447 1:     main::DbRep_Main                    called by ./FHEM/93_DbRep.pm (976)
2020.05.06 15:04:34.447 1:     main::DbRep_Set                     called by fhem.pl (3772)
2020.05.06 15:04:34.447 1:     main::CallFn                        called by fhem.pl (1900)
2020.05.06 15:04:34.448 1:     main::DoSet                         called by fhem.pl (1932)
2020.05.06 15:04:34.448 1:     main::CommandSet                    called by fhem.pl (1243)
2020.05.06 15:04:34.448 1:     main::AnalyzeCommand                called by ./FHEM/01_FHEMWEB.pm (2709)
2020.05.06 15:04:34.448 1:     main::FW_fC                         called by ./FHEM/01_FHEMWEB.pm (981)
2020.05.06 15:04:34.449 1:     main::FW_answerCall                 called by ./FHEM/01_FHEMWEB.pm (590)
2020.05.06 15:04:34.449 1:     main::FW_Read                       called by fhem.pl (3777)
2020.05.06 15:04:34.449 1:     main::CallFn                        called by fhem.pl (753)
2020.05.06 15:04:34.450 2: DbRep DbRep_syncStandby_LiveDB - DBD::mysql::st execute failed: Incorrect datetime value: ' ' for column `fhem_DB_LIVE`.`history`.`TIMESTAMP` at row 1 at ./FHEM/93_DbRep.pm line 11322.

2020.05.06 15:04:34.991 2: DbRep DbRep_syncStandby_LiveDB - DBD::mysql::st execute failed: Incorrect datetime value: ' ' for column `fhem_DB_LIVE`.`history`.`TIMESTAMP` at row 1 at ./FHEM/93_DbRep.pm line 11322.

2020.05.06 15:04:35.027 4: DbRep DbRep_syncStandby_LiveDB -> BlockingCall change_Done finished

Kann da jemand sehen wo das Problem liegt ? *grübel*

2. Es handelt sich um ein "copyStandby" nicht syncStandby richtig ? Wenn ich den o.g. Teil 2 mal ausführe, hab ich auch von allen Einträgen 2 in der ZielDB. Oder gibt es auch hier nochmal irgedwo eine Möglichkeit, wo vielleicht auch gelöschte Einträge mit synchronisiert werden ?

Code Auswählen


2020-05-05 23:59:49 	read_OG_SZ_conditions 	READINGSPROXY 	Humidity: 50.4 	Humidity 	50.4 		94065
2020-05-05 23:59:49 	read_OG_SZ_conditions 	READINGSPROXY 	Humidity: 50.4 	Humidity 	50.4 		44323

Ansonsten.... mal ehrlich Heiko. Mit jeder Funktioni die ich hier oder auch im DbLog eingesetzt hab, bin ich begeisterter von den beiden Modulen.. ist der Hammer

Viele Grüße
Andreas

DS_Starter · 06 Mai 2020, 15:32:40

Du könntest das Attribut sqlResultFormat = json setzen und es selbst dekodieren (siehe ComRef) oder du wendest das Modul expandJSON darauf an. Das wäre nur _ein_ möglicher Weg.
Schau dir auch mal das Wiki an -> https://wiki.fhem.de/wiki/DbRep_-_Reporting_und_Management_von_DbLog-Datenbankinhalten#Readingwerte_von_DbRep_in_ein_anderes_Device_.C3.BCbertragen

@Andreas

- das erste Problem kommt sicherlich daher dass du in deiner Quell-DB Datensätze ohne gültiges Datum hast, must du suchen und rausschmeißen

- das zweite Problem umgeht man am Besten indem man die Tabellen in der SyncDB mit einem primary Key anlegt. Steht direkt gleich zu Beginn des Kapitels im Wiki beschrieben -> https://wiki.fhem.de/wiki/DbRep_-_Reporting_und_Management_von_DbLog-Datenbankinhalten#Inhalte_einer_prim.C3.A4ren_Datenbank_in_eine_andere_Standby-Datenbank_.C3.BCbertragen_.28syncStandby.29

Danke Andreas

... da ist jahrelanges Entwickeln eingeflossen ....

Wenn ich mit Rasenmähen fertig bin kann ich weiter mit dir und Andreas fachsimpeln.

LG,
Heiko

flummy1978 · 06 Mai 2020, 15:59:01

Zitat von: DS_Starter am 06 Mai 2020, 15:32:40
- das erste Problem kommt sicherlich daher dass du in deiner Quell-DB Datensätze ohne gültiges Datum hast, must du suchen und rausschmeißen

- das zweite Problem umgeht man am Besten indem man die Tabellen in der SyncDB mit einem primary Key anlegt. Steht direkt gleich zu Beginn des Kapitels im Wiki beschrieben -> https://wiki.fhem.de/wiki/DbRep_-_Reporting_und_Management_von_DbLog-Datenbankinhalten#Inhalte_einer_prim.C3.A4ren_Datenbank_in_eine_andere_Standby-Datenbank_.C3.BCbertragen_.28syncStandby.29

Genau das war mein Ansatz .. ~~aber egal wie ich in der Tabelle suche, ich finde einfach auf Teufel komm raus keinen eintrag ohne Datum ;( Hast Du eine Idee dafür ?~~
Siehe da ... während ich den Beitrag geschrieben hab, hat die Geschichte mit dem Primary Key das Problem genauso gelöst. Wenn ich es jetzt doppelt ausführe gibt es 1. keine Fehlermeldung mehr und 2. keine doppelten Einträge

Aaahhh Schande über mein Haupt .... den Satz hab ich zig mal gelesen und gedacht "Ja stimmt .. hab ich eingefügt". Aber Depp wie ich bin, hab ich meine vorhandene Tabelle kopiert, statt die SQL Anweisung aus dem Wiki zu nehmen -.- Sorry ......
Aber es löscht immernoch keine Einträge richtig ? D.h. Einträge die gesynct wurden und später in der QuellDB gelöscht werden, werden dann in der ZielDB nicht mehr aktualisiert oder ?

Tante Edith ergänzt noch einen Schönheitsfehler
Nach jeder Abfrage kommt mit verbose 4 die Fehlermeldung Use of uninitialized value $date in concatenation (.) or string at ./FHEM/93_DbRep.pm betroffener Logteil:

Code Auswählen

2020.05.06 16:52:00.813 1: PERL WARNING: Use of uninitialized value $date in concatenation (.) or string at ./FHEM/93_DbRep.pm line 11312.
2020.05.06 16:52:00.814 1: stacktrace:
2020.05.06 16:52:00.820 1:     main::__ANON__                      called by ./FHEM/93_DbRep.pm (11312)
2020.05.06 16:52:00.820 1:     main::DbRep_WriteToDB               called by ./FHEM/93_DbRep.pm (8566)
2020.05.06 16:52:00.821 1:     main::DbRep_syncStandby             called by FHEM/Blocking.pm (194)
2020.05.06 16:52:00.821 1:     main::BlockingStart                 called by FHEM/Blocking.pm (107)
2020.05.06 16:52:00.821 1:     main::BlockingCall                  called by ./FHEM/93_DbRep.pm (2134)
2020.05.06 16:52:00.822 1:     main::DbRep_Main                    called by ./FHEM/93_DbRep.pm (976)
2020.05.06 16:52:00.822 1:     main::DbRep_Set                     called by fhem.pl (3772)
2020.05.06 16:52:00.823 1:     main::CallFn                        called by fhem.pl (1900)
2020.05.06 16:52:00.823 1:     main::DoSet                         called by fhem.pl (1932)
2020.05.06 16:52:00.823 1:     main::CommandSet                    called by fhem.pl (1243)
2020.05.06 16:52:00.824 1:     main::AnalyzeCommand                called by ./FHEM/01_FHEMWEB.pm (2709)
2020.05.06 16:52:00.824 1:     main::FW_fC                         called by ./FHEM/01_FHEMWEB.pm (981)
2020.05.06 16:52:00.824 1:     main::FW_answerCall                 called by ./FHEM/01_FHEMWEB.pm (590)
2020.05.06 16:52:00.825 1:     main::FW_Read                       called by fhem.pl (3777)
2020.05.06 16:52:00.825 1:     main::CallFn                        called by fhem.pl (753)
2020.05.06 16:52:00.826 1: PERL WARNING: Use of uninitialized value $time in concatenation (.) or string at ./FHEM/93_DbRep.pm line 11312.
2020.05.06 16:52:00.826 1: stacktrace:
2020.05.06 16:52:00.826 1:     main::__ANON__                      called by ./FHEM/93_DbRep.pm (11312)
2020.05.06 16:52:00.827 1:     main::DbRep_WriteToDB               called by ./FHEM/93_DbRep.pm (8566)
2020.05.06 16:52:00.827 1:     main::DbRep_syncStandby             called by FHEM/Blocking.pm (194)
2020.05.06 16:52:00.828 1:     main::BlockingStart                 called by FHEM/Blocking.pm (107)
2020.05.06 16:52:00.828 1:     main::BlockingCall                  called by ./FHEM/93_DbRep.pm (2134)
2020.05.06 16:52:00.828 1:     main::DbRep_Main                    called by ./FHEM/93_DbRep.pm (976)
2020.05.06 16:52:00.829 1:     main::DbRep_Set                     called by fhem.pl (3772)
2020.05.06 16:52:00.829 1:     main::CallFn                        called by fhem.pl (1900)
2020.05.06 16:52:00.829 1:     main::DoSet                         called by fhem.pl (1932)
2020.05.06 16:52:00.830 1:     main::CommandSet                    called by fhem.pl (1243)
2020.05.06 16:52:00.830 1:     main::AnalyzeCommand                called by ./FHEM/01_FHEMWEB.pm (2709)
2020.05.06 16:52:00.831 1:     main::FW_fC                         called by ./FHEM/01_FHEMWEB.pm (981)
2020.05.06 16:52:00.831 1:     main::FW_answerCall                 called by ./FHEM/01_FHEMWEB.pm (590)
2020.05.06 16:52:00.831 1:     main::FW_Read                       called by fhem.pl (3777)
2020.05.06 16:52:00.832 1:     main::CallFn                        called by fhem.pl (753)
2020.05.06 16:52:02.736 3: DbRep DbRep_syncStandby_LiveDB - total lines transfered to standby database: 7781
2020.05.06 16:52:02.737 3: DbRep DbRep_syncStandby_LiveDB - number of lines inserted into "DBLoggingMonnestation": 354

Zitat... da ist jahrelanges Entwickeln eingeflossen ....
Wenn ich mit Rasenmähen fertig bin kann ich weiter mit dir und Andreas fachsimpeln.

Das merkt man sofort ... Schönes Fachwissen super umgesetzt

Och Du .... ich hätte hier auch nochmal 350 m² zu mähen

Wobei .... 300 davon übernimmt der (Määäääh)Robbi .. das hält sich also in Grenzen

Grüße
Andreas

DS_Starter · 06 Mai 2020, 16:58:15

So .. fertsch

ZitatWobei .... 300 davon übernimmt der (Määäääh)Robbi .. das hält sich also in Grenzen

Das wird bei mir immer Handarbeit bleiben ... wegen der Bewegung

Sonst sonst man tatsächlich nur noch vor der Kiste, ohne Witz. Außerdem stehe ich mittlerweile den Dingern wegen dem Naturschutz etwas ablehnend gegenüber. Viele Kleintiere wie z.B. Igel fallen diesen Geräten zum Opfer. Vielleicht auch weil die Besitzer sie nicht richtig handhaben, mag sein $:-\$ .

ZitatAber es löscht immernoch keine Einträge richtig ? D.h. Einträge die gesynct wurden und später in der QuellDB gelöscht werden, werden dann in der ZielDB nicht mehr aktualisiert oder ?

Ja, du hast recht, müßte eigentlich copyStandby heißen. Es würde den Eintrag nicht löschen.
Sollte ursprünglich ein richtiges Sync werden, ist aber "nur" ein kopieren geworden und nun scheue ich mich den Set Befehl umzubenennen. Vielleicht baue ich es ja auch noch aus ... wer weiß.

Aber ich setze das Problem wegen dem fehlenden Timestamp mal auf meine ToDo. Wenn DbRep sowas unter die Finger bekommt, soll der Sync nicht abbrechen, sondern nur einen Logeintrag schreiben und den Datensatz beim Übertragen ignorieren. Dabei wird die Warnung:

PERL WARNING: Use of uninitialized value $date in concatenation (.) or string at ./FHEM/93_DbRep.pm line 11312.

gleich mit korrigiert.

LG,
Heiko

uwirt · 06 Mai 2020, 21:33:41

Das mit dem limitieren der Grösse des json-Readouts mit timeOlderThan/allowDeletion auf die letzte halbe Stunde zu machen funktioniert nicht.

Code Auswählen


defmod Libelium_Db DbRep Libelium_DbLog
attr Libelium_Db userattr reading01Name reading01Regex
attr Libelium_Db allowDeletion 1
attr Libelium_Db reading01Name air_temperature
attr Libelium_Db reading01Regex (?s)HUMB\|([0-9.]+)
attr Libelium_Db sqlResultFormat json
attr Libelium_Db timeOlderThan 900

setstate Libelium_Db done
setstate Libelium_Db 2020-05-06 21:18:43 SqlResult {"001":"ID|ID_WASP|ID_SECRET|FRAME_TYPE|FRAME_NUMBER|SENSOR|VALUE|TIMESTAMP|SYNC|RAW|PARSER_TYPE","002":"1|sur001|403470039|128|22|TCB|13.22|2020-05-06 
12:07:43|0|noraw|1","003":"2|sur001|403470039|128|22|HUMB|86.7|2020-05-06
12:07:43|0|noraw|1","004":"3|sur001|403470039|128|22|SOILT|14.60|2020-05-06 
12:07:43|0|noraw|1","005":"4|sur001|403470039|128|22|UV|32.27|2020-05-06
12:07:43|0|noraw|1","006":"5|sur001|403470039|128|22|TCC|12.00|2020-05-06 
12:07:43|0|noraw|1","007":"6|sur001|403470039|128|22|SOIL|5571.03|2020-05-06
12:07:43|0|noraw|1","008":"7|sur001|403470039|128|22|LW|0.000|2020-05-06 

... etc ...

21:13:25|0|noraw|1","585":"584|sur002|403470039|128|121|GMT|54|2020-05-06
21:13:25|0|noraw|1","586":"585|sur002|403470039|128|121|RSSI|52|2020-05-06
21:13:25|0|noraw|1","587":"586|sur002|403470039|128|121|RAM|40|2020-05-06
21:13:25|0|noraw|1","588":"587|sur002|403470039|128|121|STR|0|2020-05-06
21:13:25|0|noraw|1","589":"588|sur002|403470039|128|121|RAD|4.180645|2020-05-06
21:13:25|0|noraw|1"}
setstate Libelium_Db 2020-05-06 21:18:43 sqlCmd SELECT * FROM sensorParser WHERE id_wasp LIKE 'sur00_'
setstate Libelium_Db 2020-05-06 21:18:43 sqlResultNumRows 588
setstate Libelium_Db 2020-05-06 21:18:43 state done

Muss ich da was anders machen?

DS_Starter · 06 Mai 2020, 21:58:16

ZitatMuss ich da was anders machen?

Ja, mal die CommandRef zum sqlCmd lesen.

Dort steht:
....
Sollen die im Modul gesetzten Attribute "timestamp_begin" bzw. "timestamp_end" im Statement berücksichtigt werden, können die Platzhalter "§timestamp_begin§" bzw. "§timestamp_end§" dafür verwendet werden.
...

Es gibt auch Beispiele zur Verwendung.
Im Gegensatz zu anderen Befehlen weiß ich ja nicht was der User für SQL Statements absetzen möchte. Deswegen muss man an der Stelle Platzhalter verwenden um sie an der richtigen Stelle einzufügen.
D.h. die Attributwerte timestamp_begin bzw. timestamp_end werden in deinem Statement an den Stellen eingefügt wo du die Platzhalter platziert hast.

flummy1978 · 07 Mai 2020, 11:14:58

Moin,

Ich denke mal Du hast das schon korrekt und nicht als irgendwie Kritik verstanden

.... Ich schreibe hier ziemlich alles auf, was mir persönlich auffällt. Wenn es so gewollt ist oder ein Fehler von meiner Seite ist es ja ok. Wenn es ein mini Fehler wie "Use of uninitialized value..." den ich durch Zufall finde, hilft es Dir ja sicher auch

Zitat von: DS_Starter am 06 Mai 2020, 16:58:15
Ja, du hast recht, müßte eigentlich copyStandby heißen. Es würde den Eintrag nicht löschen.
Sollte ursprünglich ein richtiges Sync werden, ist aber "nur" ein kopieren geworden und nun scheue ich mich den Set Befehl umzubenennen. Vielleicht baue ich es ja auch noch aus ... wer weiß.

Ich (und bin mir sicher einige andere auch) hätte da vermutlich nichts dagegen, wenn Du da mal wieder Lust zu basteln hättest. Ich weiss nicht wie andere das DB Log ansich einsetzen, aber durch meine anderen Beiträge hier merkt man, dass ich zu den leuten gehöre die in 1-2 Jahren nicht in ihre DB schauen wollen und feststellen OooOOoo die DB hat 10 GB OooOOoo jetzt weiß ich auch warum das Ding immer langsamer wurde, in den letzten Wochen / Monaten.
Sprich ich nutze meine DB im aktuellen Zustand mit sehr vielen "Spammer" Werten. Aber manche Werte wie Wind, Regen, Helligkeit (vom Wetter), Messwerte der Stromzähler und andere werden teilweise im Live Betrieb nach 15 Min (Stichwort averageValue und writeToDbInTime

)oder nach 1 Woche oder 3 Monaten reduziert. Teilweise gibt es Daten die möchte man noch einen Monat später ins Detail wissen, oft reicht aber auch ein 15 min oder 1 Std Schnitt. Da wäre natürlich ein richtiges Syncen schon besser, weil man das perfekt als Backup nutzen könnte.

Wie gesagt ... je öfter ich mit den Modulen zu tun hab .... umso mehr schwärm ich davon

Komplett OT:

Zitat von: DS_Starter am 06 Mai 2020, 16:58:15
Das wird bei mir immer Handarbeit bleiben ... wegen der Bewegung Sonst sonst man tatsächlich nur noch vor der Kiste, ohne Witz. Außerdem stehe ich mittlerweile den Dingern wegen dem Naturschutz etwas ablehnend gegenüber. Viele Kleintiere wie z.B. Igel fallen diesen Geräten zum Opfer. Vielleicht auch weil die Besitzer sie nicht richtig handhaben, mag sein $:-\$ .

Ich hab hier noch so viel Handarbeit drum herum, da bin ich echt froh, dass ich das nicht zwingend machen muss. Körperlich betonter Job und n "selber-Kernsanierer-Haus", verlangt einem schon viel ab, aber dennoch kann ich irgendwo auch Deine Skepsis nachvollziehen. Das liegt in der Tat (oftmals) an der falschen Handhabe, weil man sie bei bestimmtem Wetter / Jahreszeit einfach mal weglassen muss. Dann hat man es nicht verhindert, aber schon minimiert.

VG
Andreas