DbLog - Umstellung Betrieb auf SubProcess -> Tester gesucht

[thburkhart]

die gplot.cfgs habe ich mit einenem Namen versehen...

Code Auswählen Erweitern

# Created by FHEM/98_SVG.pm, 2015-02-05 17:43:13
# THB 2016-06-12
# THB 2020-03-30


set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set title '<TL> - <L1> '
set ytics
set y2tics
set grid ytics y2tics
set ylabel "Humidity (%)"
set y2label "Temperature in C"


set yrange [0:100]
# set y2range [-10:40]


#FileLog 4:temperature:10:
#FileLog 6:humidity:50:

#DbLog <SPEC1>:temperature:10:
#DbLog <SPEC1>:humidity:50:


plot "<IN>" using 1:2 axes x1y2 title 'Temperature' ls l0fill lw 1 with lines,\
     "<IN>" using 1:2 axes x1y1 title 'Humidity' ls l2 lw 1 with lines

[enno]

https://wiki.fhem.de/wiki/SVG-Plots_von_FileLog_auf_DbLog_umstellen

auf was steht dein DbLog ? bei mir ist das

Code Auswählen Erweitern

attr DbLogType Current/History und in den Plots

Code Auswählen Erweitern

LOGFILE HISTORY

[thburkhart]

bingo das wars

danke sehr !!!!!

seltsamerweise lief das mit der alten db prima

[thburkhart]

andere Frage:
auf dem Android SmartPhone  will sich die App mit denselben Zugangsdaten nicht mit der FHEM Datenbank verbinden.
Database FHEM
User fhemuser

woran könnte das liegen ?

[betateilchen]

Code Auswählen Erweitern


#FileLog 4:temperature:10:
#FileLog 6:humidity:50:

#DbLog <SPEC1>:temperature:10:
#DbLog <SPEC1>:humidity:50:


Die Zeilen mit #FileLog am Anfang solltest Du entfernen, wenn alle Werte aus der Datenbank kommen.

In den gplot Dateien selbst zu editieren, sollte man nur tun, wenn man wirklich weiß und verstanden hat, WAS man da tut.

[betateilchen]

woran könnte das liegen ?

Vielleicht daran, dass die Datenbank nur von localhost aus erreichbar ist?

[thburkhart]

Vielleicht daran, dass die Datenbank nur von localhost aus erreichbar ist?

das Smartphone ist doch wie mein Laptop im selben heimischen Netz ..  ?

[DS_Starter]

@SusisStrolch

Noch ne Kleinigkeit...
Beim FHEM Restart (sei es via "systemctl" oder "shutdown restart") verfällt FHEM erst einmal in eine "Schweigeminute".

Es gibt für Module die das benötigen die Möglichkeit den Shutdown zu verzögern (https://wiki.fhem.de/wiki/DevelopmentModuleIntro#X_DelayedShutdown).
DbLog ist eines davon um den Abschluß der letzten DB-Aktivitäten abzuwarten. Siehe auch das globale Attr maxShutdownDelay.
Im Logfile sieht man welche Devices den Shutdown verzögern, z.B.:

Code Auswählen Erweitern


2022.12.11 20:59:41.870 1: Server shutdown delayed due to SynCalTasks,SSCam.Keller,SynCal3,SynCal1,CamTER,SDS1,CamHE1,SynCal2,SSCam.Terrasse,SSCam.Hauseingang,CalHaus,SSCam.Carport,LogSQLITE1,SynCal.Abfall,SynCal,LogDB,SSCam.GiebelWest for max 10 sec
2022.12.11 20:59:41.886 2: DbLog LogSQLITE1 - Last database write cycle done
2022.12.11 20:59:41.887 2: DbLog LogSQLITE1 - stopping Subprocess >8567< ...
2022.12.11 20:59:41.890 2: DbLog LogSQLITE1 - Subprocess >8567< stopped
2022.12.11 20:59:41.907 2: DbLog LogDB - Last database write cycle done
2022.12.11 20:59:41.908 2: DbLog LogDB - stopping Subprocess >8564< ...
2022.12.11 20:59:41.911 2: DbLog LogDB - Subprocess >8564< stopped


Ich habe den Prozess im Modul jetzt noch etwas angepasst und ins contrib geladen.

Grade mal die 5.5.3 probiert - die zeigt noch immer das gleiche Verhalten bei einem mysql-Fehler.

Ich glaube mit der Fehlerbehandlung komme ich langsam an den Rand des Möglichen. "Pferdefuß" ist wie das DBI den Fehler zurückgibt.
In der V5.5.4 im contrib ist die Ausgabe in das Logfile im Fehlerfall erweitert.
So richtig gefällt mir das nicht und ich denke noch darüber nach die Behandlung doch noch in unserem Sinne abzuändern.

Trotzdem die V5.5.4 bitte mal testen wegen den beiden Änderungen.

[DS_Starter]

@SusisStrolch,

für dein Testszenario habe ich dir eine V  93_DbLog_V5.5.5_Test ins contrib geladen.
Bitte teste sie mit deinen fehlerhaften Events. Umbenennen natürlich.

Interessant wäre das Verhalten mit Attr commitMode = ac:on_ta:off sowie dem Standard basic_ta:on.

LG

[DS_Starter]

Ich habe die Serialisierung von JSON auf Storable umgestellt.

Das hat m.M. nach zwei wesentliche Vorteile.
JSON muss installiert werden. Es ist zwar davon auszugehen dass es bei den allermeisten Usern der Fall ist, sicher ist es wahrscheinlich nicht.
Storable ist bei aktuellem Perl 5 built-In.

Storable ist bei encode/decode signifikant schneller als JSON::(XS) -> https://github.com/trizen/perl-scripts/blob/master/Benchmarks/json_vs_storable.pl
Das sollte sich beim serialisieren/deserialisieren von größeren Datenmengen ausspielen.

Ist im contrib upgedated.

[DS_Starter]

@SusisStrolch ... gibt es noch irgendwelche Testergebnisse mit deinem Szenario ?

Ansonsten wäre die aktuell im contrib liegende Version soweit fertig um damit life gehen zu können falls mir nicht noch etwas auf/einfällt.

[thburkhart]

auch bei Euerm LaienJungspunt-Tester läuft alles prima

nach dem Startschuss nehme ich die Zeile

Code Auswählen Erweitern

attr global exclude_from_update 93_DbLog.pm

wieder raus ?

[DS_Starter]

nach dem Startschuss nehme ich die Zeile

attr global exclude_from_update 93_DbLog.pm

wieder raus ?

Ja, aber ich schreibe vorher wenn ich die neue V offiziell einchecke.
Paar Tage geben wir uns noch damit die User, die so mutig waren mitzumachen, nochmal ihre Meinung oder Hinweise abgeben können.

[Sany]

Kurzes Feedback:
habe die 5er Version auf einem Testsystem installiert, fast alle Versionen, die Du bereitgestellt hast. Lief jedesmal völlig ohne Probleme, keinerlei Fehlermeldungen im Log. Vor 3 Tagen habe ich dann die neueste Version (5.5.6) auf mein "Produktiv"-system losgelassen, auch hier keinerlei Fehler im Log, die DB arbeitet korrekt (Daigramme haben die aktuellen daten etc.)
Da ich immer noch nicht dazu kam, mich in DBrep reinzufuchsen bin ich momentan eher Typ Sammler, die DB ist bereits 10,5GB groß geworden. Performancemäßig kann ich nichts sagen, flutscht alles mindestens so gut wie vorher.
Attribute sind so gesetzt:

DbLogType History
asyncMode 1
bulkInsert 1
colEvent 0
event-on-change-reading state
useCharfilter 1

Ich denke das wäre so richtig für alles im Sub-prozess.
Tolle Arbeit für einen geschmeidigen Übergang zur neuesten Version. Vielen Dank dafür!


Gruß


Sany

[Frank_Huber]

Gestern alle Instanzen auf die neue Version hochgezogen.
keine negativen Beobachtungen. alles läuft wie gewohnt.