DBlog blockiert FHEM völlig wenn keine Verbindung zur DB auf NAS

[t.huber]

Hallo Experten.

wie dem Titel zu entnehmen ist läuft bei mir DBLog mit einer Datenbank auf dem NAS.
FHEM läuft auf einem Raspi 3
Wie ich in einem anderen Thread schon geschrieben hatte hatte ich nun schon 2x das Problem dass mein NAS (QNAP TS-453a) auf dem die DB des DBLog läuft zwar lief aber nicht mehr reagiert hat.
Dadurch ging plötzlich bei FHEM nichts mehr.
Die UI hat bei Browseraufruf nicht mehr reagiert.
Mit SSH kam man noch ganz normal auf das RPi3.
Wie in den Logs erkennbar war stoppte er irgendwo bei der Verbindungsaufnahme mit FHEM.
Nach ausschalten in der fhem.cfg lief FHEM nach sudo reboot wieder.
(Da wusste ich noch nicht das mein NAS nicht mehr reagiert hat)

Gestern hatte ich das gleiche wieder. Nach einem Hart-Neustart am NAS und einem Reboot am RPi3 reagierte FHEM wieder.
(Leider waren wie immer die RollingCodes der Rolladen nicht mehr synchron)

Da ich noch überhaupt keine Ahnung habe was da das NAS teilweis für ein Problem hat will ich zumindest sicherstellen das nicht jedesmal meine Hausautomatisation steht und im Nachgang tagelang Probleme hat (z.B. Rolladen)

2 Tipps habe ich im vorherigen (falslchen) Thread schon bekommen.

Davon abgesehen unterstützt DBLog einen Async Modus der die Events dann einfach lokal zwischenpuffert bis die DB wieder erreichbar ist,  statt zu blockieren.

Danke für den Hinweis. Ich habe nun den asynchronen Modus in den Attributes eingeschaltet.
Mal schauen wie es sich die nächsten Tage/Wochen verhält.
Muss ich sonst noch was dazu einstellen ?

Hast du die DB auf dem NAS?
Dann solltest du Deine Infrastruktur noch mal überdenken.

Ich dachte eigentlich das das genau der richtige Platz für die Datenbank wäre ..
Was könnte ich hier verbessern ?

Hat sonst schon mal jemand solche Probleme gehabt ?

[DS_Starter]

Im synchronen Modus besteht dieser Zusammenhang auf jeden Fall, da fhem und die Datenbank in diesem Modus "fest miteinander verbumden" sind.
Unter Anderem zur Lösung solcher Problematiken wurde der asynchrone Modus entwickelt. Die Daten werden zunächst gecacht und weggeschrieben wenn die DB verfügbar ist.

Somit ist asynchMode = 1 genau richtig. Ich betreibe die Infrastruktur ebenso, siehe footprint.

Sieh dir noch das Attribut syncInterval an ob du  eventuell den default ändern möchtest.
Und führe bitte noch ein

Code Auswählen Erweitern

set ... configCheck

aus und poste das Ergebnis.

Grüsse,
Heiko

[marvin78]

Dass du die DB auf dem NAS hast, ist wirklich nicht so schlimm. Was CoolTux damit meint, dass man die Infrastruktur überdenken sollte, weiß ich nicht. Grundsätzlich ist nichts falsch daran, die LogDB extern zu haben. Allerdings muss man sich dann auch im klaren darüber sein, dass die Infrastruktur stabil ist. An deiner Stelle würde ich dem Problem mit dem NAS auf die Spur gehen. Das halte ich für extrem wichtig.

[CoolTux]

Dass du die DB auf dem NAS hast, ist wirklich nicht so schlimm. Was CoolTux damit meint, dass man die Infrastruktur überdenken sollte, weiß ich nicht. Grundsätzlich ist nichts falsch daran, die LogDB extern zu haben. Allerdings muss man sich dann auch im klaren darüber sein, dass die Infrastruktur stabil ist. An deiner Stelle würde ich dem Problem mit dem NAS auf die Spur gehen. Das halte ich für extrem wichtig.

Mein Aussage ist etwas aus dem Kontext da die Fehlerbeschreibung hier fehlt auf die meine Aussage aufbaute.
Ich tippe auf Probleme im Netzwerk oder mit dem NAS an sich.

[Steffen@Home]

Hallo Zusammen,

hatte vor kurzem das selbe oder sehr ähnliche Problem.

Mein NAS(mit MariaDB) hat sich irgendwie aufgehängt bzw. hat nicht mehr reagiert.

Als ich den RPi in der Zeit neu gestartet habe ist dann FHEM beim Startversuch die Verbindung zur DB(auf NAS)aufzubauen dort hängen geblieben und hatte auch keinen Abbruch nach bestimmten Timeout oder sonst was.
Automatisierung ist somit auch still gestanden.

[marvin78]

Mein Aussage ist etwas aus dem Kontext da die Fehlerbeschreibung hier fehlt auf die meine Aussage aufbaute.

Habe ich mir gedacht.   Ich hatte bloß keine Lust, den anderen Thread zu lesen.

Meine Ansicht dazu: Nutzt man DBLog auf einer externen Datenbank, dann muss diese zuverlässig laufen und man sollte sie monitoren, das heißt, man sollte sich mitteilen lassen, wenn sie nicht mehr verfügbar ist und ggf. nötige Neustarts etc automatisch durchführen lassen.

[CoolTux]

Das monitoren sollte man so oder so machen. Selbst meine kleinen Raspi's werden überwacht und bei Dienst oder Totalausfall werde ich benachrichtigt. Des DB Dienst zu überwachen sollte keine Kunst sein.

[Thyraz]

Wahrscheinlich reicht es auf Events vom state Reading der DLog Instanz zu lauschen.

[Wernieman]

Ich würde ein solches Monitoring "extern" machen. Wenn FHEM dadurch z.B: nichtm laufen kann (reboot) bekommt man auch keine Monitoring-Info

[marvin78]

Ich würde ein solches Monitoring "extern" machen. Wenn FHEM dadurch z.B: nichtm laufen kann (reboot) bekommt man auch keine Monitoring-Info

Genau das meinte ich.

[Thyraz]

Passiert das denn auch bei gesetztem Attribut async?
Hätte vermutet, dass Fhem damit weder beim Start noch im Betrieb Probleme mit einem fehlenden DB-Server hat.

[DS_Starter]

Nein, mit asynch blockiert nichts wegen der DB. .. Ich präzisiere... beim Schreiben ! Beim Lesen, also der Darstellung von Plots muss man darauf achten plotfork = 1 gesetzt zu haben (fhemweb).
Ich persönlich denke dabei auch an Zustände die nicht unbedingt einen Fehler darstellen. Also zum Beispiel wenn die Synology gewartet wird, ein Packetupdate der DB auf dem NAS passiert oder ein Offline- Backup durchgeführt wird.
Das sind alles Zeiten in denen fhem blockieren würde weil es im synchronen Mode nicht an die DB kommt.
In solchen geplanten Ausfallzeiten kann man natürlich vorher in den Asynch-Mode schalten und hinterher wieder zurück wenn man nicht gänzlich auf asynch umschalten möchte.
Es gibt da viele Möglichkeiten ....

[t.huber]

Vielen Dank schon mal für die vielen Tipps und Erläuterungen.
Dann bin ich ja schon mal auf dem richtigen Weg.

Das mit dem NAS muss und möchte ich natürlich noch klären.

Ein Monitoring wäre sicherlich hilfreich und informativ.
So via PushBulltet-Nachricht.
Wäre das per IFTTT machbar/sinnvoll ?

Hier mal das Ergebnis des ConfigCheck:

Code Auswählen Erweitern

Result of connection check

Connection to database fhem successfully done.
Recommendation: settings o.k.

Result of encoding check

Encoding used by Client (connection): UTF8
Encoding used by DB fhem: UTF8
Recommendation: settings o.k.

Result of logmode check

Logmode of DbLog-device logdb is: asynchronous
Recommendation: settings o.k.

Result of table 'history' check

Column width set in DB fhem.history: 'DEVICE' = 32, 'TYPE' = 32, 'EVENT' = 512, 'READING' = 32, 'VALUE' = 32, 'UNIT' = 32
Column width used by logdb: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Recommendation: The relation between column width in table history and the field width used in device logdb don't meet the requirements. Please make sure that the width of database field definition is equal or larger than the field width used by the module. Compare the given results.
Currently the default values for field width are:

DEVICE: 64
TYPE: 64
EVENT: 512
READING: 64
VALUE: 128
UNIT: 32

You can change the column width in database by a statement like 'alter table history modify VALUE varchar(128);' (example for changing field 'VALUE'). You can do it for example by executing 'sqlCMD' in DbRep or in a SQL-Editor of your choice. (switch logdb to asynchron mode for non-blocking).
The field width used by the module can be adjusted by attributes 'colEvent', 'colReading', 'colValue',

Result of table 'current' check

Column width set in DB fhem.current: 'DEVICE' = 32, 'TYPE' = 32, 'EVENT' = 512, 'READING' = 32, 'VALUE' = 32, 'UNIT' = 32
Column width used by logdb: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Recommendation: The relation between column width in table current and the field width used in device logdb don't meet the requirements. Please make sure that the width of database field definition is equal or larger than the field width used by the module. Compare the given results.
Currently the default values for field width are:

DEVICE: 64
TYPE: 64
EVENT: 512
READING: 64
VALUE: 128
UNIT: 32

You can change the column width in database by a statement like 'alter table current modify VALUE varchar(128);' (example for changing field 'VALUE'). You can do it for example by executing 'sqlCMD' in DbRep or in a SQL-Editor of your choice. (switch logdb to asynchron mode for non-blocking).
The field width used by the module can be adjusted by attributes 'colEvent', 'colReading', 'colValue',

Result of check 'Search_Idx' availability

Index 'Search_Idx' exists and contains the recommended fields 'DEVICE', 'READING', 'TIMESTAMP'.
Recommendation: settings o.k.

Result of check 'Report_Idx' availability for DbRep-devices

You use at least one DbRep-device assigned to logdb, but the recommended index 'Report_Idx' is missing.
Recommendation: You can create the index by executing statement 'CREATE INDEX Report_Idx ON `history` (TIMESTAMP, READING) USING BTREE;'
Depending on your database size this command may running a long time.
Please make sure the device 'logdb' is operating in asynchronous mode to avoid FHEM from blocking when creating the index.
Note: If you have just created another index which covers the same fields and order as suggested (e.g. a primary key) you don't need to create the 'Report_Idx' as well !

[DS_Starter]

So wie ich sehe, ist dein DbLog nicht die aktuellste Version, du solltest updaten.

Wichtig ist noch die Feldbreiten von history/current anzupassen wie in der Empfehlung beschrieben, sonst können Fehler auftreten.
Der fehlende Index ist lediglich eine Performanceproblematik, aber solltest du auch anlegen.

Wenn du alles erledigt hast, bitte nochmal configCheck ausführen, es können weitere Empfehlungen folgen mit der neuesten DbLog-Version.

Grüße
Heiko

[t.huber]

Sodala

FHEM geupdatet. DBLOG hab ich dadurch von V2.22.13 auf V3.8.1 geupdatet.

Die Spalten-Breiten habe ich soweit alle erweitert.
Den fehlenden Index habe ich erstellt und das Attribut für die shutdowntime habe ich auch gleich noch gesetzt wie empfohlen vom Check.

Hier der neue Check: (ohne Darstellung im Code-Kasten, Da leidet die Lesbarkeit ohne Fett und Unterstrichen leidet)

Result of configuration read check
Connection parameter store type: file
Connection parameter: Connection -> mysql:database=fhem;host=192.168.1.3;port=3306, User -> fhemuser, Password -> read o.k.

Result of connection check
Connection to database fhem successfully done.
Recommendation: settings o.k.

Result of encoding check
Encoding used by Client (connection): UTF8
Encoding used by DB fhem: UTF8
Recommendation: settings o.k.

Result of logmode check
Logmode of DbLog-device logdb is: asynchronous
Recommendation: settings o.k.

Result of shutdown sequence preparation check
Attribute "shutdownWait" is set to: 2
Recommendation: The setting may be ok. But due to the Reading "background_processing_time" is not available (you may set attribute "showproctime"), the current
setting is only a rough estimate.

Result of table 'history' check
Column width set in DB fhem.history: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Column width used by logdb: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Recommendation: settings o.k.

Result of table 'current' check
Column width set in DB fhem.current: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Column width used by logdb: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Recommendation: settings o.k.

Result of check 'Search_Idx' availability
Index 'Search_Idx' exists and contains recommended fields 'DEVICE', 'READING', 'TIMESTAMP'.
Recommendation: settings o.k.

Result of check 'Report_Idx' availability for DbRep-devices
You use at least one DbRep-device assigned to logdb. Index 'Report_Idx' exists and contains recommended fields 'TIMESTAMP', 'READING'.
Recommendation: settings o.k.