DbLog - TimeOut und Co

[R1F800]

Moin Zusammen,

ich würde gerne meine LOG Files auf meine SQL DB auf meiner NAS verlegen.
Jetzt habe ich an dieser Stelle ein "Problem" mit der Persisitierung meiner Daten.
Die NAS begibt sich in den Ruhezustand bei NIchtbenutzung. Jetzt müssen aber beim Tageswechsel meine Durchscnittswerte, die ich loggen will, geschrieben werden.

Die NAS fährt also wieder aus ihrem SLEEP hoch .. das dauert aber ca. 5sec.
Kann ich dem DBLOG einen art Timeout mitgeben, so dass gewartet wird bis die Daten abgegeben wurden? >> ist doof, weil der Thread dann blockiert.
Oder gibt es eine andere Möglichkeit zur Umgehung dieses Laufzeitproblems? >> z.B. 30 sec. vorher einen PING auf die NAS

[guhu]

müsste das nicht durch Asynchron Mode schon geregelt sein?

[frober]

Wie wäre es vorher mit einem WOL ( Wake on lan)?
Gibt es sogar extra für Fhem

[R1F800]

Wie wäre es vorher mit einem WOL ( Wake on lan)?
Gibt es sogar extra für Fhem

OK... kann ich mal probieren ...
https://fhem.de/commandref.html#WOLset

Dann kann ich das Interval als ATTR setzen ... also alle 24h = 86400 sec aber wie biege ich den STARTzeitpunkt dem Sysoem bei ? also sagen wir 00:00:01 ?

[R1F800]

müsste das nicht durch Asynchron Mode schon geregelt sein?

Du meinst dann also

Code Auswählen Erweitern

ATTR <device> asyncMode=1 ?
attr <device> timeout 600

wobei der Timeout mit 600sec schon ein wenig lang uns ziemlich üppig dimensioniert ist.

[DS_Starter]

müsste das nicht durch Asynchron Mode schon geregelt sein?

guhu hat schon den wichtigen Hinweis gegeben und im Zusammenspiel mit WOL, wie frober schon hinwies, gut einsetzbar.

Wenn du den asynch einsetzt, bleiben alle zu loggenden Events zunächst im Speicher und werden in die DB geschrieben wenn die DB wieder verfügbar ist. Wann auch immer.

Hat aber auch Nachteile:

1. der RAM steigt während der Zeit (je nachdem wieviel Events warten)
2. Sollte FHEM während der Zeit aus irgendwelchen Gründen abstürzen, sind die Daten weg.

Du musst also selbst entscheiden in welchen Zeiträumen du wegschreiben willst und evtl. Datenverlust akzeptierst.
Das Interval stellst du aber auf z.B. 10 Minuten. DbLog erkennt wenn die DB nicht oben ist und versucht es später nochmal.

Du brauchst dich eigentlich nur um den WOL Rhyth­mus kümmern und nach WOL genügend Zeit geben damit alles weggegeschrieben werden kann.

bulkInsert = 1 ist auch hilfreich für solche Masseninserts.

[frober]

OK... kann ich mal probieren ...
https://fhem.de/commandref.html#WOLset

aber wie biege ich den STARTzeitpunkt dem Sysoem bei ? also sagen wir 00:00:01 ?

Mit einem 'at'

Code Auswählen Erweitern

define <XYZ> at *00:01 set <wol-device> on

[R1F800]

Noch eine kurze NAchfrage ,,
das config file
gehe ich recht in der Annahme, dass der PORT und die configs wie folgt aussehen:

     %dbconfig= (                                                   
        connection => "mysql:database=DBNAME;host=IPADRESSE;port=3306",       
        user => "fhemuser",                                         
        password => "fhempassword",
   
Die Tabelle in die dann die Werte inserted werden deklariere ich dann im DBlog selber?

Denn Datenbankname ist ja nicht Tabellenname.

[guhu]

Die Tabellen sind fest vergeben: history und current.

[R1F800]

Die Tabellen sind fest vergeben: history und current.

OK und wie sieht die Struktur aus ?
Wo gibt es da eine Beschreibung ?
Das ist ja schon eher etwas ungewöhnlich im Sinne der Datenmodellierung.

In der Referenz habe ich da "nur" create index gefunden.
UND ist dann tatsächlich der Aufbau JEDES neuen line inserts :  (DEVICE, READING, TIMESTAMP)

Welche Attributdefinitionen haben denn DEVICE und Reading?

EDIT:
OK hab es gefuinden : LINK zum CREATE TABLE

CREATE TABLE `fhem`.`history` (TIMESTAMP TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP, DEVICE varchar(64), TYPE varchar(64), EVENT varchar(512), READING varchar(64), VALUE varchar(128), UNIT varchar(32));
CREATE TABLE `fhem`.`current` (TIMESTAMP TIMESTAMP, DEVICE varchar(64), TYPE varchar(64), EVENT varchar(512), READING varchar(64), VALUE varchar(128), UNIT varchar(32));


Dann ist für mich DBLOG absolut unbrauchbar. Ich benötige eine native SQL Schnittstelle, mit der ich ordentlich in Tabellen Daten persistiere, die einer sauberen Datenmodellierung standhalten.
Dann ist ein CRON Job (pplae file) mit einem kleinen JAVA Prog (INSERTS) bestimmt besser geeignet.

[guhu]

der Sinn vom Logdb ist es sicherlich nicht, eine generische Datenbankschnittstelle zur Verfügung zu stellen, sondern eben Log-Daten zu speichern. Dafür ist es ganz gut geeignet. Durch die feste Struktur kann man bspw. einfach Plots erstellen.
Zusammen mit DBRep macht es bei mir genau das, was es soll.
Mehr "Persistenz" als die logs und die Objekte in fhem.cfg (und den Zustand in fhem.save) brauche ich bisher nicht. Kann natürlich sein, dass das bei Dir anders ist. Dann wäre in der Tat dblog ungeeignet.

[Guybrush]

Vielleicht sollte man die Frage erstmal grundlegend stellen, wieviele Einträge du täglich hast, die gespeichert werden sollen und vor allem wie häufig das am Tag passiert?

Es wäre imho völlig sinnfrei dein NAS im Standby Modus zu betreiben, wenn du hier regelmäßige Einträge vornimmst. Ich würde sogar sagen, dass man das NAS durchgehend laufen lassen sollte, wenn hier wenigstens stündlich Einträge passieren würden. Ich weiß ja nicht, was für Platten du in deinem NAS verbaut hast. Für NAS spezifizierte Platten sind aber allgemein eher für den Dauerbetrieb ausgelegt, so dass häufige Start/Stopp Zyklen die Lebenszeit verkürzen bzw. diese länger halten, wenn man sie durchgehend laufen ließe... Die Stromkosten sind ja Marginal bei ~3W im Idle je HDD.

[R1F800]

Vielleicht sollte man die Frage erstmal grundlegend stellen, wieviele Einträge du täglich hast, die gespeichert werden sollen und vor allem wie häufig das am Tag passiert?

Es wäre imho völlig sinnfrei dein NAS im Standby Modus zu betreiben, wenn du hier regelmäßige Einträge vornimmst. Ich würde sogar sagen, dass man das NAS durchgehend laufen lassen sollte, wenn hier wenigstens stündlich Einträge passieren würden. Ich weiß ja nicht, was für Platten du in deinem NAS verbaut hast. Für NAS spezifizierte Platten sind aber allgemein eher für den Dauerbetrieb ausgelegt, so dass häufige Start/Stopp Zyklen die Lebenszeit verkürzen bzw. diese länger halten, wenn man sie durchgehend laufen ließe... Die Stromkosten sind ja Marginal bei ~3W im Idle je HDD.

Da die Möglichkeit an dieser Stelle mit DBLOG ausserhalb meiner Anforderungen ist, ist die Frage nach Spindown  / Idle obsolet.

[Guybrush]

das macht keinen Unterschied ob du Logfiles oder DB nutzt. Dein Problem ist ja, dass das NAS zu lange braucht um hochzufahren und dafür suchst du nun workarounds. Da wirst du nur nichts perfektes finden, weil das grundlegend nicht asynchron passiert. Deswegen ja meine Anregung, dass du - wenns entsprechend häufige Einträge sind - einfach mal drüber nachdenken solltest das NAS dauerhaft laufen zu lassen. Alternativ unterstützen auch viele NAS USB Speicher. Das könntest du natürlich auch in Erwägung ziehen die Daten auf dem USB Stick zu schreiben und von dort dann per Skript aufs HDDs spiegeln. Ist aber alles unnötige Komplexität, wenn du mich fragst. Keep it simple ist oftmals der beste Ratschlag...