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.
Zitat von: ThyrazDavon 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 ?
Zitat von: CoolTuxHast 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 ?
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
set ... configCheck
aus und poste das Ergebnis.
Grüsse,
Heiko
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.
Zitat von: marvin78 am 01 Februar 2018, 09:25:34
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.
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.
Zitat von: CoolTux am 01 Februar 2018, 12:35:18
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.
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.
Wahrscheinlich reicht es auf Events vom state Reading der DLog Instanz zu lauschen.
Ich würde ein solches Monitoring "extern" machen. Wenn FHEM dadurch z.B: nichtm laufen kann (reboot) bekommt man auch keine Monitoring-Info
Zitat von: Wernieman am 01 Februar 2018, 14:36:14
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.
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.
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 ....
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:
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 !
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
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.
Das sieht schon gut aus.
Jetzt schlage ich vor noch das Attr cacheEvents =2 zu setzen. Damit siehst du den Füllgrad des Cache mit Beginn eines Schreibzyklus. Ein Event wird auch erzeugt, Reading CacheUsage.
Setze dir dann das Attr cacheLimit auf einen hohen Wert gegenüber CacheUsage, also z.B. 50 * CacheUsage.
Dann baue dir ein notify welches den Event CacheUsage auswertet und lasse dir eine Message zustellen wenn zB. CacheUsage den Faktor 2 über dem Normalwert erreicht hat.
Dann weisst du dass deine DB nicht mehr so arbeitet wie sie soll und kannst dich darum kümmern.
Das wäre ein simples Monitoring.
Setze dir cacheLimit auf jeden Fall sehr hoch damit dblog nicht mit jedem Event in den Schreibzyklus abspringt sobald cacheLimit erreicht ist. Das Verhalten an dieser Stelle muss ich noch etwas nachbessern.
LG,
Heiko
Ich hab jetzt mal die CacheEvents eingeschaltet.
Jetzt geht mir glaube ich noch etwas Feingefühl ab was z.B. Normalwerte sind.
Der CacheUsage schwank bei mir in etwa zwischen 0 und 50.
51 war mal das höchste was ich in ca. 30min gesehen habe.
Deswegen habe ich das CacheLimit auf 2500 gesetzt (50*50)
Einen Notify hab ich mir eingerichtet der mich bei einem Wert des CacheUsage größer 100 per PushBullet benachrichtigt.
Dieser Notify ist so definiert:
define n_logdb_usage notify logdb:CacheUsage:.* {\
if (ReadingsVal("logdb","CacheUsage","") > 100){\
fhem("set Pushbullet.Tobias message NAS LogDB-Cache hoch !" )\
}\
}
Auszug aus der fhem.cfg ... deswegen die \ jeweils am Zeilenende.
Stimmt das soweit oder hab ich völlig falsch Wert verwendet ?
Zitat
Der CacheUsage schwank bei mir in etwa zwischen 0 und 50.
51 war mal das höchste was ich in ca. 30min gesehen habe.
Schau am Besten eine Weile im Eventmonitor nach CacheUsage. Dort den Filter auf .*CacheUsage.* setzen.
Dann bekommst du ein Gefühl was im normalen Betrieb der Durchschnitt ist.
Dein Notify sollte so passen (Pushbullet nutze ich nicht und weiß nicht ob die Message so richtig definiert wird).
Das ReadingsVal würde ich der Korrektheit wegen ändern in:
ReadingsVal("logdb","CacheUsage",0) > 100
Grüße
Heiko
Danke für den Hinweis !
Ich habe soeben eine neue Version 3.8.3 eingecheckt. Neben einigen weiteren Verbesserungen/Fixes habe ich das CacheUsage-Handling umgestellt.
Wenn cacheLimit erreicht ist, wird nach einem fehlerhaften Schreibvorgang ein erneuter Versuch frühestens nach syncInterval/2 gestartet.
Das entlastet fhem in diesem speziellen Fehlerfall.
Bitte updaten !
Grüße,
Heiko
Update wurde durchgeführt.
Hier anbei noch 2 Screenshots der CacheUsagePlots davor.
Brutal schlecht oder normal ?
ZitatBrutal schlecht oder normal ?
Warum schlecht ?
Das ist ja lediglich ein Überblick wieviel Events in einem System in der Zeit zwischen den Syncläufen im Cache landen. Dieser Wert wird überall verschieden sein. Ein schlecht oder gut gibts da eigentlich nicht.
Einen großen Ausreißer gibts bei 4 Uhr. Vllt. kannst du ihn dir erkären ... evtl. Backup-Lauf ?
Hier mal ein Auszug was den Cache hochtreiben kann.
Alle Rollläden zum gleichen Zeitpunkt fahren.
Und dazwischen noch ein Heizungsthermostat.
1 Minute Auszug:
TIMESTAMP 1 DEVICE TYPE EVENT READING VALUE UNIT
2018-02-09 06:55:05 logdb DBLOG CacheUsage: 37 CacheUsage 37
2018-02-09 06:55:08 Rolladen.Schlafzimmer.1S.2 SOMFY exact: 200 exact 200
2018-02-09 06:55:08 Rolladen.Wohnzimmer.EG SOMFY exact: 200 exact 200
2018-02-09 06:55:08 Rolladen.Wohnzimmer.1S SOMFY exact: 200 exact 200
2018-02-09 06:55:08 Rolladen.Schlafzimmer.1S.1 SOMFY exact: 200 exact 200
2018-02-09 06:55:08 Rolladen.Schlafzimmer.1S.2 SOMFY parsestate: Hoch parsestate Hoch
2018-02-09 06:55:08 Rolladen.Schlafzimmer.1S.2 SOMFY position: 200 position 200
2018-02-09 06:55:08 Rolladen.Wohnzimmer.EG SOMFY position: 200 position 200
2018-02-09 06:55:08 Rolladen.Wohnzimmer.1S SOMFY position: 200 position 200
2018-02-09 06:55:08 Rolladen.Schlafzimmer.1S.1 SOMFY position: 200 position 200
2018-02-09 06:55:08 Rolladen.Schlafzimmer.1S.2 SOMFY received: 20 received 20
2018-02-09 06:55:08 Rolladen.Schlafzimmer.1S.2 SOMFY state: closed state closed
2018-02-09 06:55:08 Rolladen.SZ.1S.2.Hoch.wd AT state: Next: 06:53:41 state Next 06:53:41
2018-02-09 06:55:08 Rolladen.Wohnzimmer.EG SOMFY state: closed state closed
2018-02-09 06:55:08 Rolladen.EG.Hoch AT state: Next: 06:53:41 state Next 06:53:41
2018-02-09 06:55:08 Rolladen.Wohnzimmer.1S SOMFY state: closed state closed
2018-02-09 06:55:08 Rolladen.1S.Hoch AT state: Next: 06:53:41 state Next 06:53:41
2018-02-09 06:55:08 Rolladen.Schlafzimmer.1S.1 SOMFY state: closed state closed
2018-02-09 06:55:08 Rolladen.SZ.1S.1.Hoch.wd AT state: Next: 06:53:41 state Next 06:53:41
2018-02-09 06:55:09 Rolladen.Wohnzimmer.EG SOMFY parsestate: Hoch parsestate Hoch
2018-02-09 06:55:09 Rolladen.Wohnzimmer.EG SOMFY received: 20 received 20
2018-02-09 06:55:10 Rolladen.Wohnzimmer.1S SOMFY parsestate: Hoch parsestate Hoch
2018-02-09 06:55:10 Rolladen.Wohnzimmer.1S SOMFY received: 20 received 20
2018-02-09 06:55:11 Rolladen.Schlafzimmer.1S.2 SOMFY exact: 140 exact 140
2018-02-09 06:55:11 Rolladen.Wohnzimmer.EG SOMFY exact: 140 exact 140
2018-02-09 06:55:11 Rolladen.Wohnzimmer.1S SOMFY exact: 140 exact 140
2018-02-09 06:55:11 Rolladen.Schlafzimmer.1S.1 SOMFY exact: 140 exact 140
2018-02-09 06:55:11 Rolladen.Schlafzimmer.1S.1 SOMFY parsestate: Hoch parsestate Hoch
2018-02-09 06:55:11 Rolladen.Schlafzimmer.1S.2 SOMFY position: 150 position 150
2018-02-09 06:55:11 Rolladen.Wohnzimmer.EG SOMFY position: 150 position 150
2018-02-09 06:55:11 Rolladen.Wohnzimmer.1S SOMFY position: 150 position 150
2018-02-09 06:55:11 Rolladen.Schlafzimmer.1S.1 SOMFY position: 150 position 150
2018-02-09 06:55:11 Rolladen.Schlafzimmer.1S.1 SOMFY received: 20 received 20
2018-02-09 06:55:11 Rolladen.Schlafzimmer.1S.2 SOMFY state: down state down
2018-02-09 06:55:11 Rolladen.Wohnzimmer.EG SOMFY state: down state down
2018-02-09 06:55:11 Rolladen.Wohnzimmer.1S SOMFY state: down state down
2018-02-09 06:55:11 Rolladen.Schlafzimmer.1S.1 SOMFY state: down state down
2018-02-09 06:55:14 Rolladen.Schlafzimmer.1S.2 SOMFY exact: 91 exact 91
2018-02-09 06:55:14 Rolladen.Wohnzimmer.EG SOMFY exact: 91 exact 91
2018-02-09 06:55:14 Rolladen.Wohnzimmer.1S SOMFY exact: 91 exact 91
2018-02-09 06:55:14 Rolladen.Schlafzimmer.1S.1 SOMFY exact: 91 exact 91
2018-02-09 06:55:14 Rolladen.Schlafzimmer.1S.2 SOMFY position: 90 position 90
2018-02-09 06:55:14 Rolladen.Wohnzimmer.EG SOMFY position: 90 position 90
2018-02-09 06:55:14 Rolladen.Wohnzimmer.1S SOMFY position: 90 position 90
2018-02-09 06:55:14 Rolladen.Schlafzimmer.1S.1 SOMFY position: 90 position 90
2018-02-09 06:55:14 Rolladen.Schlafzimmer.1S.2 SOMFY state: 90 state 90
2018-02-09 06:55:14 Rolladen.Wohnzimmer.EG SOMFY state: 90 state 90
2018-02-09 06:55:14 Rolladen.Wohnzimmer.1S SOMFY state: 90 state 90
2018-02-09 06:55:14 Rolladen.Schlafzimmer.1S.1 SOMFY state: 90 state 90
2018-02-09 06:55:17 Rolladen.Schlafzimmer.1S.2 SOMFY exact: 63.8181818181818 exact 63.8181818181818
2018-02-09 06:55:17 Rolladen.Wohnzimmer.EG SOMFY exact: 63.8181818181818 exact 63.8181818181818
2018-02-09 06:55:17 Rolladen.Wohnzimmer.1S SOMFY exact: 63.8181818181818 exact 63.8181818181818
2018-02-09 06:55:17 Rolladen.Schlafzimmer.1S.1 SOMFY exact: 63.8181818181818 exact 63.8181818181818
2018-02-09 06:55:17 Rolladen.Schlafzimmer.1S.2 SOMFY position: 60 position 60
2018-02-09 06:55:17 Rolladen.Wohnzimmer.EG SOMFY position: 60 position 60
2018-02-09 06:55:17 Rolladen.Wohnzimmer.1S SOMFY position: 60 position 60
2018-02-09 06:55:17 Rolladen.Schlafzimmer.1S.1 SOMFY position: 60 position 60
2018-02-09 06:55:17 Rolladen.Schlafzimmer.1S.2 SOMFY state: 60 state 60
2018-02-09 06:55:17 Rolladen.Wohnzimmer.EG SOMFY state: 60 state 60
2018-02-09 06:55:17 Rolladen.Wohnzimmer.1S SOMFY state: 60 state 60
2018-02-09 06:55:17 Rolladen.Schlafzimmer.1S.1 SOMFY state: 60 state 60
2018-02-09 06:55:20 Rolladen.Schlafzimmer.1S.2 SOMFY exact: 36.6363636363636 exact 36.6363636363636
2018-02-09 06:55:20 Rolladen.Wohnzimmer.EG SOMFY exact: 36.6363636363636 exact 36.6363636363636
2018-02-09 06:55:20 Rolladen.Wohnzimmer.1S SOMFY exact: 36.6363636363636 exact 36.6363636363636
2018-02-09 06:55:20 Rolladen.Schlafzimmer.1S.1 SOMFY exact: 36.6363636363636 exact 36.6363636363636
2018-02-09 06:55:20 Rolladen.Schlafzimmer.1S.2 SOMFY position: 40 position 40
2018-02-09 06:55:20 Rolladen.Wohnzimmer.EG SOMFY position: 40 position 40
2018-02-09 06:55:20 Rolladen.Wohnzimmer.1S SOMFY position: 40 position 40
2018-02-09 06:55:20 Rolladen.Schlafzimmer.1S.1 SOMFY position: 40 position 40
2018-02-09 06:55:20 Rolladen.Schlafzimmer.1S.2 SOMFY state: 40 state 40
2018-02-09 06:55:20 Rolladen.Wohnzimmer.EG SOMFY state: 40 state 40
2018-02-09 06:55:20 Rolladen.Wohnzimmer.1S SOMFY state: 40 state 40
2018-02-09 06:55:20 Rolladen.Schlafzimmer.1S.1 SOMFY state: 40 state 40
2018-02-09 06:55:21 HM_5F9980_Clima CUL_HM ValvePosition: 100 ValvePosition 100
2018-02-09 06:55:21 HM_5F9980 CUL_HM actuator: 100 actuator 100
2018-02-09 06:55:21 HM_5F9980 CUL_HM battery: ok battery ok
2018-02-09 06:55:21 HM_5F9980 CUL_HM batteryLevel: 3 batteryLevel 3
2018-02-09 06:55:21 HM_5F9980_Clima CUL_HM boostTime: - boostTime -
2018-02-09 06:55:21 HM_5F9980_Clima CUL_HM controlMode: auto controlMode auto
2018-02-09 06:55:21 HM_5F9980 CUL_HM desired-temp: 22.0 desired-temp 22.0
2018-02-09 06:55:21 HM_5F9980_Clima CUL_HM desired-temp: 22.0 desired-temp 22.0
2018-02-09 06:55:21 HM_5F9980 CUL_HM measured-temp: 20.7 measured-temp 20.7
2018-02-09 06:55:21 HM_5F9980_Clima CUL_HM measured-temp: 20.7 measured-temp 20.7
2018-02-09 06:55:21 HM_5F9980_Weather CUL_HM measured-temp: 20.7 measured-temp 20.7
2018-02-09 06:55:21 HM_5F9980 CUL_HM motorErr: ok motorErr ok
2018-02-09 06:55:21 HM_5F9980_Clima CUL_HM partyEnd: - partyEnd -
2018-02-09 06:55:21 HM_5F9980_Clima CUL_HM partyStart: - partyStart -
2018-02-09 06:55:21 HM_5F9980_Clima CUL_HM partyTemp: - partyTemp -
2018-02-09 06:55:21 wp_Wohnzimmer WEEKPROFILE profile_count: 1 profile_count 1
2018-02-09 06:55:21 HM_5F9980_Clima CUL_HM state: T: 20.7 desired: 22.0 valve: 100 state T: 20.7 desired: 22.0 valve: 100
2018-02-09 06:55:21 HM_5F9980_Weather CUL_HM state: 20.7 state 20.7
2018-02-09 06:55:23 Rolladen.Schlafzimmer.1S.2 SOMFY exact: 9.45454545454544 exact 9.45454545454544
2018-02-09 06:55:23 Rolladen.Wohnzimmer.EG SOMFY exact: 9.45454545454544 exact 9.45454545454544
2018-02-09 06:55:23 Rolladen.Wohnzimmer.1S SOMFY exact: 9.45454545454544 exact 9.45454545454544
2018-02-09 06:55:23 Rolladen.Schlafzimmer.1S.1 SOMFY exact: 9.45454545454544 exact 9.45454545454544
2018-02-09 06:55:23 Rolladen.Schlafzimmer.1S.2 SOMFY position: 10 position 10
2018-02-09 06:55:23 Rolladen.Wohnzimmer.EG SOMFY position: 10 position 10
2018-02-09 06:55:23 Rolladen.Wohnzimmer.1S SOMFY position: 10 position 10
2018-02-09 06:55:23 Rolladen.Schlafzimmer.1S.1 SOMFY position: 10 position 10
2018-02-09 06:55:23 Rolladen.Schlafzimmer.1S.2 SOMFY state: 10 state 10
2018-02-09 06:55:23 Rolladen.Wohnzimmer.EG SOMFY state: 10 state 10
2018-02-09 06:55:23 Rolladen.Wohnzimmer.1S SOMFY state: 10 state 10
2018-02-09 06:55:23 Rolladen.Schlafzimmer.1S.1 SOMFY state: 10 state 10
2018-02-09 06:55:24 Rolladen.Schlafzimmer.1S.2 SOMFY exact: 0 exact 0
2018-02-09 06:55:24 Rolladen.Wohnzimmer.EG SOMFY exact: 0 exact 0
2018-02-09 06:55:24 Rolladen.Wohnzimmer.1S SOMFY exact: 0 exact 0
2018-02-09 06:55:24 Rolladen.Schlafzimmer.1S.1 SOMFY exact: 0 exact 0
2018-02-09 06:55:24 Rolladen.Schlafzimmer.1S.2 SOMFY position: 0 position 0
2018-02-09 06:55:24 Rolladen.Wohnzimmer.EG SOMFY position: 0 position 0
2018-02-09 06:55:24 Rolladen.Wohnzimmer.1S SOMFY position: 0 position 0
2018-02-09 06:55:24 Rolladen.Schlafzimmer.1S.1 SOMFY position: 0 position 0
2018-02-09 06:55:24 Rolladen.Schlafzimmer.1S.2 SOMFY state: open state open
2018-02-09 06:55:24 Rolladen.Wohnzimmer.EG SOMFY state: open state open
2018-02-09 06:55:24 Rolladen.Wohnzimmer.1S SOMFY state: open state open
2018-02-09 06:55:24 Rolladen.Schlafzimmer.1S.1 SOMFY state: open state open
2018-02-09 06:55:35 logdb DBLOG CacheUsage: 114 CacheUsage 114
Rollläden etwas zeitversetzt schalten ?
Bestimmte/Unwichtige Werte nicht loggen ?
Die Frage die sich mir da stellt, wozu muss man das alles loggen?
Welche Werte brauchst Du für Kurz und Langzeit Logging. Was ist für Dich nach mehreren Tagen noch nützlich.
ZitatBestimmte/Unwichtige Werte nicht loggen ?
Wie cooltux schon schrieb, würde ich nur die Events loggen welche in irgendeiner Weise hinterher auch ausgewertet werden. Sei es es per SVG oder Ausgaben per DbRep. Informationen die in keiner Weise später relevant sind, würde ich nicht loggen. Macht dann ja keinen Sinn und verschwendet nur Ressourcen.
Und ganz allgemein würde ich auch nur die Events in meinem System erzeugen lassen, die ich für irgendeine Reaktion benötige. Andere Events würde ich unterdrücken. Die Werkzeuge dafür sind ja bekannt.
Zitat von: DS_Starter am 10 Februar 2018, 11:54:40
Und ganz allgemein würde ich auch nur die Events in meinem System erzeugen lassen, die ich für irgendeine Reaktion benötige. Andere Events würde ich unterdrücken. Die Werkzeuge dafür sind ja bekannt.
Obwohl die Empfehlung sinnvoll ist sorgt sie in der Praxis für viele Probleme. Selbst bei "Poweruser", Anfänger erst recht. Events werden nicht nur geloggt - sie steuern neben logischen Konstruktionen auch userreadings, externe frontends und werden (unischtbar) innerhalb von modulen verwendet.
Wer denkt schon bei Änderungen am system (nach Wochen/Monaten/Jahren) daran dass einzelne events mal unterdrückt wurden. Ich habe schon eine Menge, später daraus resultierende, Probleme hier gesehen. Die Leute wundern sich warum etwas nicht funktioniert was, laut Beschreibung, eigentlich gehen sollte.
Guten Abend,
bei dem Versuch DbLog zu installieren bin ich soweit gekommen, daß mein Device "logDb" ein connect anzeigt. Auch MYSQL zeigt per phpmyadmin die Datenbank mit den tables an.
Da aber keine log's weder in logDb noch mysql erscheinen habe ich configcheck gestartet -
Ergebnis :
Result of DbLog version check
Used DbLog version: 3.8.8
Recommendation: Your running version may be the current one. Please check for updates of DbLog periodically.
Result of configuration read check
Connection parameter store type: file
Connection parameter: Connection -> mysql:database=fhem;host=localhost;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): LATIN1
Encoding used by DB fhem: UTF8
Recommendation: Both encodings should be identical. You can adjust the usage of UTF8 connection by setting the UTF8 parameter in file '/opt/fhem/db.conf' to the right value.
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:
Recommendation: Due to Reading "background_processing_time" is not available (you may set attribute "showproctime"), there is only a rough estimate to
set attribute "shutdownWait" to 2 seconds.
Result of plot generation method check
WARNING - at least one of your FHEMWEB devices have attribute "plotfork = 1" not set. This may cause blocking situations when creating plots.
WEB: plotfork=0
WEBphone: plotfork=0
WEBtablet: plotfork=0
Recommendation: You should set attribute "plotfork = 1" in relevant devices
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
No DbRep-device assigned to logdb is used. Hence an index for DbRep isn't needed.
Recommendation: settings o.k.
mein Problem ist diese Fehlermeldung :
Result of encoding check
Encoding used by Client (connection): LATIN1
Encoding used by DB fhem: UTF8
Recommendation: Both encodings should be identical. You can adjust the usage of UTF8 connection by setting the UTF8 parameter in file '/opt/fhem/db.conf' to the right value.
wie muss ich hier vorgehen ?
Gruß Peter
Hallo Peter,
dir Ausgabe sagt:
Zitat
You can adjust the usage of UTF8 connection by setting the UTF8 parameter in file '/opt/fhem/db.conf' to the right value.
Du setzt also in deiner db.conf:
## for MySQL
####################################################################################
#%dbconfig= (
# connection => "mysql:database=fhem;host=<database host>;port=3306",
# user => "fhemuser",
# password => "fhempassword",
# # optional enable(1) / disable(0) UTF-8 support (at least V 4.042 is necessary)
utf8 => 1
#);
Allerdings kann das nicht die Ursache sein dass keine Einträge in deiner Datenbank erscheinen.
Beachte bitte dass im asynchronen Modus die Daten erst im Cache landen bevor sie in die DB geschrieben werden.
Wenn du nicht weiterkommst, setze dir verbose 4 oder gar 5 und poste neben einem list des DbLog-Devices auch die Einträge im Logfile bezüglich DbLog.
Grüße
Heiko
Hallo Heiko,
unglaublich schnelle Reaktion von Dir, bin selbst altersbedingt etwas langsamer.
Habe jetzt die db.conf geändert und der Fehler ist auch weg.
Hier nun das Logfile nach reopen :
2018.03.09 21:22:18 3: DbLog logdb: Reopen requested.
2018.03.09 21:22:18 3: DbLog logdb - Creating Push-Handle to database mysql:database=fhem;host=localhost;port=3306 with user fhemuser
2018.03.09 21:22:18 3: DbLog logdb - Push-Handle to db mysql:database=fhem;host=localhost;port=3306 created
2018.03.09 21:22:18 3: DbLog logdb - UTF8 support enabled
und das Reading :
Readings
CacheUsage 0 2018-03-09 21:28:40
NextSync 2018-03-09 21:28:48 or if CacheUsage 100 reached 2018-03-09 21:28:18
countCurrent 0 2018-03-09 21:28:35
countHistory 0 2018-03-09 21:28:35
state connected 2018-03-09 21:28:24
Gruß Peter
Hallo Heiko,
das "asyncMode" ist jetzt entfernt - aber ohne Änderung
habe vorhin verbose (5) vergessen - jetzt kommt in der Logfile :
2018.03.09 21:51:17 4: DbLog logdb -> ################################################################
2018.03.09 21:51:17 4: DbLog logdb -> ### start of new Logcycle ###
2018.03.09 21:51:17 4: DbLog logdb -> ################################################################
2018.03.09 21:51:17 4: DbLog logdb -> number of events received: 1 for device: global
2018.03.09 21:51:17 4: DbLog logdb -> check Device: global , Event: ATTR logdb verbose 5
2018.03.09 21:51:30 3: DbLog logdb: Reopen requested.
2018.03.09 21:51:30 3: DbLog logdb - Creating Push-Handle to database mysql:database=fhem;host=localhost;port=3306 with user fhemuser
2018.03.09 21:51:30 3: DbLog logdb - Push-Handle to db mysql:database=fhem;host=localhost;port=3306 created
2018.03.09 21:51:30 3: DbLog logdb - UTF8 support enabled
2018.03.09 21:51:30 4: DbLog logdb -> ################################################################
2018.03.09 21:51:30 4: DbLog logdb -> ### start of new Logcycle ###
2018.03.09 21:51:30 4: DbLog logdb -> ################################################################
2018.03.09 21:51:30 4: DbLog logdb -> number of events received: 1 for device: logdb
2018.03.09 21:51:30 4: DbLog logdb -> check Device: logdb , Event: state: connected
kann das die Ursache sein ? Hier werden Log-Fehler angezeigt !
2018.03.09 21:54:55 4: DbLog logdb -> check Device: Bild , Event: connection: active
2018.03.09 21:55:01 4: DbLog logdb -> ################################################################
2018.03.09 21:55:01 4: DbLog logdb -> ### start of new Logcycle ###
2018.03.09 21:55:01 4: DbLog logdb -> ################################################################
2018.03.09 21:55:01 4: DbLog logdb -> number of events received: 2 for device: Wlan_SMA_WR
2018.03.09 21:55:01 4: DbLog logdb -> check Device: Wlan_SMA_WR , Event: state: present
2018.03.09 21:55:01 4: DbLog logdb -> check Device: Wlan_SMA_WR , Event: presence: present
2018.03.09 21:55:01 4: DbLog logdb -> ################################################################
2018.03.09 21:55:01 4: DbLog logdb -> ### start of new Logcycle ###
2018.03.09 21:55:0
Hallo Peter,
bin auch nicht mehr der frischeste ;).
Asynchmode ist schon ok. Setzte es bitte wieder.
Du kannst dir den Cache anschauen mit "Set <device> listCache".
Zeige mal bitte ein List deines Devices. Ich vermute das DEF ist nicht ok.
Das was du gepostet hast sind keine Fehler. Das "check" besagt dass das zu loggende Event bewertet wird. Da hinterher das parsed bzw. added Event fehlt (siehe unten) kommen deine Events nicht durch den Regex-Filter.
Erfolgreiche Einträge für den Cache sehen etwa so aus:
2018.03.09 21:59:49.560 4: DbLog LogDB1 -> ################################################################
2018.03.09 21:59:49.561 4: DbLog LogDB1 -> ### start of new Logcycle ###
2018.03.09 21:59:49.562 4: DbLog LogDB1 -> ################################################################
2018.03.09 21:59:49.562 4: DbLog LogDB1 -> number of events received: 1 for device: USV
2018.03.09 21:59:49.563 4: DbLog LogDB1 -> check Device: USV , Event: state: OL
2018.03.09 21:59:49.564 5: DbLog LogDB1 -> parsed Event: USV , Event: state: OL
2018.03.09 21:59:49.564 4: DbLog LogDB1 -> added event - Timestamp: 2018-03-09 21:59:49, Device: USV, Type: NUT, Event: state: OL, Reading: state, Value: OL, Unit:
habe gerade mal im DEF ein bestimmtes Gerät eingetragen "EHT_Zaehlerstand:average",
nun kommt im Logfile :
2018.03.09 22:01:55 4: DbLog logdb -> ################################################################
2018.03.09 22:01:55 4: DbLog logdb -> ### start of new Logcycle ###
2018.03.09 22:01:55 4: DbLog logdb -> ################################################################
2018.03.09 22:01:55 4: DbLog logdb -> number of events received: 1 for device: EHT_Zaehlerstand
2018.03.09 22:01:55 4: DbLog logdb -> check Device: EHT_Zaehlerstand , Event: average: 13966.517
inclusive dem richtigen Eintrag.
Hier das List :
nternals:
COLUMNS field length used for Device: 64, Type: 64, Event: 512, Reading: 64, Value: 128, Unit: 32
CONFIGURATION /opt/fhem/db.conf
DEF /opt/fhem/db.conf EHT_Zaehlerstand:average
MODE synchronous
MODEL MYSQL
NAME logdb
NOTIFYDEV EHT_Zaehlerstand
NR 737
NTFY_ORDER 50-logdb
PID 7366
REGEXP EHT_Zaehlerstand:average
STATE connected
TYPE DbLog
UTF8 1
VERSION 3.8.8
dbconn mysql:database=fhem;host=localhost;port=3306
dbuser fhemuser
Helper:
COLSET 1
DEVICECOL 64
EVENTCOL 512
OLDSTATE initialized
READINGCOL 64
TYPECOL 64
UNITCOL 32
VALUECOL 128
Readings:
2018-03-09 22:01:53 countCurrent 0
2018-03-09 22:01:53 countHistory 0
2018-03-09 22:01:43 state connected
Cache:
index 0
Attributes:
DbLogType Current/History
cacheEvents 2
cacheLimit 100
room DBlog
shutdownWait 2
verbose 5
in meinem biblisches Alter von 72 bestimmt noch nicht ?
in listCache wird nichts angezeigt !
Zitatin meinem biblisches Alter von 72 bestimmt noch nicht ?
Ok, bis dahin habe ich noch ein bisschen. Alle Achtung dass du dich hier durchwurstelst 8)
Ja, ich denke ich habe das Problem gesehen. Dein DEF müsste so aussehen:
DEF /opt/fhem/db.conf EHT_Zaehlerstand:average.*
Denn nach "average" kommen noch Zeichen im Event (siehe auch Eventmonitor)
Danke für das Lob, das tut gut, aber nach 40 Jahren Fernmeldevermittlungsstellen-Bau in ganz Deutschland habe ich immer noch Spass an diesen Dingen.
Habe das geändert und erscheint auch wieder im Log - aber nicht in FHEM
2018.03.09 22:36:25 4: DbLog logdb -> ################################################################
2018.03.09 22:36:25 4: DbLog logdb -> ### start of new Logcycle ###
2018.03.09 22:36:25 4: DbLog logdb -> ################################################################
2018.03.09 22:36:25 4: DbLog logdb -> number of events received: 1 for device: EHT_Zaehlerstand
2018.03.09 22:36:25 4: DbLog logdb -> check Device: EHT_Zaehlerstand , Event: average: 13966.595
wo ist bei mir der Wurm drin ?
Gute Frage wo der Wurm steckt, sollte eigentlich so passen.
Da müssen wir uns rantasten. Ändere bitte das DEF nochmal so:
DEF /opt/fhem/db.conf EHT_Zaehlerstand.*:.*average.*
bemerke gerade, daß mein logdb nach ca. 60 sec auf
STATE initialized
springt, ist das ok ?
kann dann nur mit set rereadcfg wieder nach connect.
Glaube, daß ich das morgen nochmal ganz neu installiere, ist die
$Id: 93_DbLog.pm 16336 2018-03-05 21:55:44Z DS_Starter
die neueste (oder beste) Version oder gibt es da was anderes ?
wenn ich das so einstelle kommen im Logfile ungebetene :
DbLog logdb -> ################################################################
2018.03.09 23:03:01 4: DbLog logdb -> ### start of new Logcycle ###
2018.03.09 23:03:01 4: DbLog logdb -> ################################################################
2018.03.09 23:03:01 4: DbLog logdb -> number of events received: 4 for device: 15_Batterie
2018.03.09 23:03:01 4: DbLog logdb -> check Device: 15_Batterie , Event: cmd_nr: 2
2018.03.09 23:03:01 4: DbLog logdb -> check Device: 15_Batterie , Event: cmd: 2
2018.03.09 23:03:01 4: DbLog logdb -> check Device: 15_Batterie , Event: cmd_event: di_battery
2018.03.09 23:03:01 4: DbLog logdb -> check Device: 15_Batterie , Event: state: cmd_2
2018.03.09 23:03:01 4: DbLog logdb -> ################################################################
2018.03.09 23:03:01 4: DbLog logdb -> ### start of new Logcycle ###
2018.03.09 23:03:01 4: DbLog logdb -> ################################################################
2018.03.09 23:03:01 4: DbLog logdb -> number of events received: 5 for device: di_battery
2018.03.09 23:03:01 4: DbLog logdb -> check Device: di_battery , Event: cmd_nr: 2
2018.03.09 23:03:01 4: DbLog logdb -> check Device: di_battery , Event: cmd_seqnr: 2
2018.03.09 23:03:01 4: DbLog logdb -> check Device: di_battery , Event: cmd: 2.2
2018.03.09 23:03:01 4: DbLog logdb -> check Device: di_battery , Event: cmd_event: timer_2
2018.03.09 23:03:01 4: DbLog logdb -> check Device: di_battery , Event: state: cmd_2
Zitatbemerke gerade, daß mein logdb nach ca. 60 sec auf
STATE initialized
springt, ist das ok ?
Das kommt mir komisch vor, ist bei mir nicht so.
Zitat
DbLog logdb -> ################################################################
2018.03.09 23:03:01 4: DbLog logdb -> ### start of new Logcycle ###
2018.03.09 23:03:01 4: DbLog logdb -> ################################################################
2018.03.09 23:03:01 4: DbLog logdb -> number of events received: 4 for device: 15_Batterie
2018.03.09 23:03:01 4: DbLog logdb -> check Device: 15_Batterie , Event: cmd_nr: 2
2018.03.09 23:03:01 4: DbLog logdb -> check Device: 15_Batterie , Event: cmd: 2
2018.03.09 23:03:01 4: DbLog logdb -> check Device: 15_Batterie , Event: cmd_event: di_battery
2018.03.09 23:03:01 4: DbLog logdb -> check Device: 15_Batterie , Event: state: cmd_2
Die Events werden nur bewertet (deswegen ausgegeben), aber kommen genauso wenig durch den Filter (ist auch richtig so weil der Regex diese Devices nicht durchlässt). Also insofern ok.
Die Version ist auch die z.Zt. aktuellste.
Schauen wir morgen nochmal weiter. Das kann nicht viel sein.
Gn und VG
Heiko
auf jeden Fall noch danke für die Unterstützung und wünsche eine gute Nacht, bin morgen aber auch erst wieder zu späterer Stunde am Gerät.
Tschau
Zitat von: Peter aus Calw am 09 März 2018, 22:42:40
nach 40 Jahren Fernmeldevermittlungsstellen-Bau
Also wenn heutzutage jemand das Wort "Fernmelde" verwendet, werde ich immer ganz sentimental, und mir fallen dann so grundlegende Dinge wieder ein wie: "Amt im Rücken, rechts herum.", Wörter wie "Selbstwählferndienst", oder aber das mechanische Rattern von Hebdrehwählern.
Ist einiges anders geworden...
Aber der Spaß an der Technik bleibt.
Gruß
Danny
@moskito ... ja, damals wars, als ein Wechselplattenspeicher so um die 10 Scheiben mit insg. 250MB hatte und riesig (und schwer) war ... :)
@Peter:
Zitat
bemerke gerade, daß mein logdb nach ca. 60 sec auf
STATE initialized
springt, ist das ok ?
Habe den Grund dafür gefunden. Das ist in der Version normal wenn wie bei dir nichts geloggt wird. Ist etwas ungünstig und für den User beunruhigend. Werde das in der nächsten Version mit ändern.
Spare dir den Aufwand alles neu zu installieren. Sieht ja alles gut aus und das Problem finden wir sicher auch noch.
Setze im DbLog verbose 5 wenn noch nicht geschehen.
Hast du eventuell in den Quelldevices (z.B. in dem Device EHT_Zaehlerstand) das Attribut "DbLogExclude" gesetzt ?
Das würde das Verhalten deines DbLog erklären.
LG,
Heiko
Hallo Heiko, hallo Danny,
bin wieder am Ball !
Danny scheint auch schon im Loch gesessen zu haben - Amt im Rücken - rechts rum zählen war wichtig beim spleissen - war das so ?
Habe 1960 mit 14 meine Lehre beim Fernmeldeamt 3 in Stuttgart begonnen und hatte mit 17 ausgelernt.
Dann weg von der Post zum Amtsbau - Monteur -Altmonteur - Obermonteur - techn.Revisor - Teamleiter Revisoren - Montageleiter - Vertriebing. und dann nach Ende der Digitalisierung (203) mit 58 in die Rente.
So wars und jetzt stehen 3 Raspi, 2 Mini-PC und 2 richtige PC um mich rum und beschäftigen mich und Euch (tolle FHEM-Gemeinde).
Heiko, habe gestern Abend das DbLog in FHEM nochmal neu installiert mit dem gleichen Erfolg.
Auf meinem 2. Mini-PC mit der ich meine Hausanlage steuere habe ich die gleiche Problem.
Mache gerade neue Versuche, es wird in der Logfile gar nichts mehr mit Bezug auf DbLog angezeigt.
Hallo Heiko,
nun bin ich konfus, im Logfile kommt nur noch :
Warning: Unable to locate configuration directory, default config not loaded.
Error: Connection refused
was ist das denn ?
und jetzt das :
2018.03.10 16:46:58 1: FHEMWEB SSL/HTTPS error: SSL accept attempt failed because of handshake problems
2018.03.10 16:46:58 3: DbLog dblog - Creating Push-Handle to database mysql:database=fhem;host=localhost;port=3306 with user fhemuser
2018.03.10 16:46:58 3: DbLog dblog - Push-Handle to db mysql:database=fhem;host=localhost;port=3306 created
2018.03.10 16:46:58 3: DbLog dblog - UTF8 support enabled
2018.03.10 16:46:58 1: FHEMWEB SSL/HTTPS error: SSL accept attempt failed because of handshake problems
2018.03.10 16:46:59 4: Dhttps://forum.fhem.de/index.php/topic,83673.0.htmlbLog dblog: Records count requested.
scheint wieder am alten Stand :
2018.03.10 16:54:54 4: DbLog dblog -> ################################################################
2018.03.10 16:54:54 4: DbLog dblog -> ### start of new Logcycle ###
2018.03.10 16:54:54 4: DbLog dblog -> ################################################################
2018.03.10 16:54:54 4: DbLog dblog -> number of events received: 1 for device: EHT_Zaehlerstand
2018.03.10 16:54:54 4: DbLog dblog -> check Device: EHT_Zaehlerstand , Event: average: 13968.048
2018.03.10 16:55:36 4: DbLog dblog: Records count requested.
Hallo Peter,
das sind DbLog-Meldungen:
Zitat
2018.03.10 16:46:58 3: DbLog dblog - Push-Handle to db mysql:database=fhem;host=localhost;port=3306 created
2018.03.10 16:46:58 3: DbLog dblog - UTF8 support enabled
Das nicht, sondern FHEMWEB bzgl. SSL
Zitat
FHEMWEB SSL/HTTPS error: SSL accept attempt failed because of handshake problems
Hier hast du bloß was falsches reinkopiert und ist nur eine Ausgabe:
2018.03.10 16:46:59 4: DbLog dblog: Records count requested.
Um mal weiter zu kommen, setz mal bitte verbose level auf 5 im DbLog und poste die Ausgaben aus dem Logfile.
das war jetzt mit verbose 5 :
2018.03.10 16:54:54 4: DbLog dblog -> ################################################################
2018.03.10 16:54:54 4: DbLog dblog -> ### start of new Logcycle ###
2018.03.10 16:54:54 4: DbLog dblog -> ################################################################
2018.03.10 16:54:54 4: DbLog dblog -> number of events received: 1 for device: EHT_Zaehlerstand
2018.03.10 16:54:54 4: DbLog dblog -> check Device: EHT_Zaehlerstand , Event: average: 13968.048
2018.03.10 16:55:36 4: DbLog dblog: Records count requested.
hast noch gefragt wegen Eintrag DbExclude und DbInclude in EHT_Zä.. - kein Eintrag vorhanden
Hmm, um mal etwas reinzubekommen ändere mal bitte das DEF so ab:
DEF /opt/fhem/db.conf .*:.*
Jetzt wird alles erdenkliche geloggt. Können wir später wieder alles rauslöschen. Aber ich will erstmal was laufen sehen.
Ergebnisse :
2018.03.10 17:31:21 4: DbLog dblog -> ################################################################
2018.03.10 17:31:21 4: DbLog dblog -> ### start of new Logcycle ###
2018.03.10 17:31:21 4: DbLog dblog -> ################################################################
2018.03.10 17:31:21 4: DbLog dblog -> number of events received: 4 for device: 13_Wz
2018.03.10 17:31:21 4: DbLog dblog -> check Device: 13_Wz , Event: cmd_nr: 2
2018.03.10 17:31:22 4: DbLog dblog -> ################################################################
2018.03.10 17:31:22 4: DbLog dblog -> ### start of new Logcycle ###
2018.03.10 17:31:22 4: DbLog dblog -> ################################################################
2018.03.10 17:31:22 4: DbLog dblog -> number of events received: 1 for device: at_Ladeformat
2018.03.10 17:31:22 4: DbLog dblog -> check Device: at_Ladeformat , Event: state: 36.5
2018.03.10 17:31:22 4: DbLog dblog -> ################################################################
2018.03.10 17:31:22 4: DbLog dblog -> ### start of new Logcycle ###
2018.03.10 17:31:22 4: DbLog dblog -> ################################################################
2018.03.10 17:31:22 4: DbLog dblog -> number of events received: 4 for device: AT_Ladeformat
2018.03.10 17:31:22 4: DbLog dblog -> check Device: AT_Ladeformat , Event: cmd_nr: 2
2018.03.10 17:31:22 4: DbLog dblog -> ################################################################
2018.03.10 17:31:22 4: DbLog dblog -> ### start of new Logcycle ###
2018.03.10 17:31:22 4: DbLog dblog -> ################################################################
2018.03.10 17:31:22 4: DbLog dblog -> number of events received: 1 for device: IT_Temp_Vorhersage
2018.03.10 17:31:22 4: DbLog dblog -> check Device: IT_Temp_Vorhersage , Event: state: 8
2018.03.10 17:31:22 4: DbLog dblog -> ################################################################
2018.03.10 17:31:22 4: DbLog dblog -> ### start of new Logcycle ###
2018.03.10 17:31:22 4: DbLog dblog -> ################################################################
2018.03.10 17:31:22 4: DbLog dblog -> number of events received: 4 for device: di_wetter
2018.03.10 17:31:22 4: DbLog dblog -> check Device: di_wetter , Event: cmd_nr: 1
aber in countcurrent steht immer noch 0
Ja, es läuft auch nichts durch den Filter durch, wenn du tatsächlich auf verbose 5 umgestellt hast und trotzdem die Einträge "parsed" und "added" bei dir nicht kommen. Zum Vergleich wie es bei mir aussieht. Der Eintrag "parsed Event" kommt erst dann, wenn ein Event den DEF-Filter erfolgreich passiert hat und "added event" kommt wenn das Loggen nicht durch DbExclude bzw. DbInclude verhindert wird.
2018.03.10 17:37:24.742 4: DbLog LogDB -> ################################################################
2018.03.10 17:37:24.743 4: DbLog LogDB -> ### start of new Logcycle ###
2018.03.10 17:37:24.744 4: DbLog LogDB -> ################################################################
2018.03.10 17:37:24.744 4: DbLog LogDB -> number of events received: 5 for device: MyWetter
2018.03.10 17:37:24.749 4: DbLog LogDB -> check Device: MyWetter , Event: wind: 7
2018.03.10 17:37:24.750 5: DbLog LogDB -> parsed Event: MyWetter , Event: wind: 7
2018.03.10 17:37:24.751 4: DbLog LogDB -> added event - Timestamp: 2018-03-10 17:37:24, Device: MyWetter, Type: WEATHER, Event: wind: 7, Reading: wind, Value: 7, Unit: km/h
2018.03.10 17:37:24.752 4: DbLog LogDB -> check Device: MyWetter , Event: humidity: 65
2018.03.10 17:37:24.752 5: DbLog LogDB -> parsed Event: MyWetter , Event: humidity: 65
2018.03.10 17:37:24.753 4: DbLog LogDB -> added event - Timestamp: 2018-03-10 17:37:24, Device: MyWetter, Type: WEATHER, Event: humidity: 65, Reading: humidity, Value: 65, Unit: %
2018.03.10 17:37:24.754 4: DbLog LogDB -> check Device: MyWetter , Event: pressure: 990
2018.03.10 17:37:24.755 5: DbLog LogDB -> parsed Event: MyWetter , Event: pressure: 990
2018.03.10 17:37:24.756 4: DbLog LogDB -> added event - Timestamp: 2018-03-10 17:37:24, Device: MyWetter, Type: WEATHER, Event: pressure: 990, Reading: pressure, Value: 990, Unit: hPa
2018.03.10 17:37:24.757 4: DbLog LogDB -> check Device: MyWetter , Event: temperature: 15
2018.03.10 17:37:24.758 5: DbLog LogDB -> parsed Event: MyWetter , Event: temperature: 15
2018.03.10 17:37:24.759 4: DbLog LogDB -> added event - Timestamp: 2018-03-10 17:37:24, Device: MyWetter, Type: WEATHER, Event: temperature: 15, Reading: temperature, Value: 15, Unit: °C
2018.03.10 17:37:24.760 4: DbLog LogDB -> check Device: MyWetter , Event: wettertest: 07
2018.03.10 17:37:24.761 5: DbLog LogDB -> parsed Event: MyWetter , Event: wettertest: 07
2018.03.10 17:37:24.761 4: DbLog LogDB -> added event - Timestamp: 2018-03-10 17:37:24, Device: MyWetter, Type: WEATHER, Event: wettertest: 07, Reading: wettertest, Value: 07, Unit:
Da aber nichtmal "parsed" kommt bei einem Regex ".*:.*" gibt mir das schwer zu denken.
Mach nochmal bitte lein List von deinem jetzigen DbLog, mir fällt grad nichts sinnvolles ein.
hier das list von dblog :
Internals:
COLUMNS field length used for Device: 64, Type: 64, Event: 512, Reading: 64, Value: 128, Unit: 32
CONFIGURATION /opt/fhem/db.conf
DEF /opt/fhem/db.conf .*:.*
MODE asynchronous
MODEL MYSQL
NAME dblog
NR 736
NTFY_ORDER 50-dblog
PID 8712
REGEXP .*:.*
STATE initialized
TYPE DbLog
UTF8 1
VERSION 3.8.8
dbconn mysql:database=fhem;host=localhost;port=3306
dbuser fhemuser
Helper:
COLSET 1
DEVICECOL 64
EVENTCOL 512
OLDSTATE initialized
READINGCOL 64
TYPECOL 64
UNITCOL 32
VALUECOL 128
Readings:
2018-03-10 17:46:51 CacheUsage 0
2018-03-10 17:46:51 NextSync 2018-03-10 17:47:21 or if CacheUsage 500 reached
2018-03-10 17:31:11 countCurrent 0
2018-03-10 17:31:11 countHistory 0
2018-03-10 17:46:51 state initialized
Cache:
index 0
Attributes:
DbLogType Current/History
asyncMode 1
room DBlog
verbose 5
tut mir echt leid, dich so zu beanspruchen, kann es an mysql oder evt. an fhem liegen, hätte kein Problem das neu zu installieren da dieser PC Aspire revo als Ersatz-PC für meine Haussteuerung geplant ist, also im Moment als Testgerät.
Der eigentliche Grund meiner Anfrage von gestern :
Bei "update 93_DbLog.pm" war fhem per Browser erst nach mindestens 2-maligen start/stop von fhem wieder erreichbar.
Könnte das ein Indiz sein ?
An MySQL liegt es ganz bestimmt nicht und an FHEM an sich bezweifle ich auch. Das was ich sehe passt irgendwie nicht mit dem Ergebnis zusammen da alles richtig aussieht.
Sag mal, ist dein FHEM insgesamt aktuell. d.h. aktuell upgedated ?
Auch interressant wäre ein Auszug der Einträge die der Eventmonitor bringt.
Deine DEF-Änderungen machst du aber im FHEMWEB über den normalen DEF-Editor und nicht durch direktes editieren der fhem.cfg ?
Zitat
Bei "update 93_DbLog.pm" war fhem per Browser erst nach mindestens 2-maligen start/stop von fhem wieder erreichbar.
Könnte das ein Indiz sein ?
Eher nicht wenn ein Restart jetzt ganz normal funktioniert. So etwas ist schwierig zu beurteilen wenn es keine Fehlermitteilungen gibt die etwas aussagen.
Heiko nun mache ich mal ein update, habe das zwar schon mal gemacht, aber es schadet ja nicht.
werde Dir dann berichten, bis dahin ein herzliches Danke.
Hallo Heiko,
habe nun FHEM (version 5.8) neu installiert und dann auch DbLog wieder eingerichtet.
Mit dieser Ausgabe von 93_DbLog.pm (kam aus dem Netz) :
$Id: 93_DbLog.pm 11825 2016-07-21 05:40:59Z tobiasfaust $
DEF :
./db.conf EHT_Zaehlerstand:(average).*|ENT_Zaehlerstand:(average).*||EPE_Zaehlerstand:(average).*|EPV_Zaehlerstand:(average).*
wird mysql/phpmyadmin sofort befüllt :
Server: localhost »Datenbank: fhem »Tabelle: current
[code]SELECT * FROM `current`
+ Optionen
TIMESTAMP DEVICE TYPE EVENT READING VALUE UNIT
2018-03-10 21:16:11 EHT_Zaehlerstand VOLKSZAEHLER average: 13970.755 average 13970.755
2018-03-10 21:04:12 ENT_Zaehlerstand VOLKSZAEHLER average: state average:
2018-03-10 21:16:12 ENT_Zaehlerstand VOLKSZAEHLER average: 98691.537 average 98691.537
[/code]
hier noch list logdb :
Internals:
CFGFN
CONFIGURATION ./db.conf
DBMODEL MYSQL
DEF ./db.conf EHT_Zaehlerstand:(average).*|ENT_Zaehlerstand:(average).*||EPE_Zaehlerstand:(average).*|EPV_Zaehlerstand:(average).*
NAME logdb
NR 746
NTFY_ORDER 50-logdb
PID 7399
REGEXP EHT_Zaehlerstand:(average).*|ENT_Zaehlerstand:(average).*||EPE_Zaehlerstand:(average).*|EPV_Zaehlerstand:(average).*
STATE connected
TYPE DbLog
dbconn mysql:database=fhem;host=127.0.0.1;port=3306
dbuser fhemuser
Helper:
Dblog:
Countcurrent:
Logdb:
TIME 1520712994.98442
VALUE 6
Counthistory:
Logdb:
TIME 1520712994.93851
VALUE 38
State:
Logdb:
TIME 1520712986.12875
VALUE connected
Readings:
2018-03-10 21:16:34 countCurrent 6
2018-03-10 21:16:34 countHistory 38
2018-03-10 21:16:26 state connected
Attributes:
DbLogType Current/History
room DbLog
Habe in FHEM nach der Neuinstallation (aus dem Netz) zwar noch kein globales update gemacht aber so läuft es erstmal.
Würde dazu gerne Deine Meinung hören.
Gruß Peter
neues Ergebnis in phpmyadmin :
+ Optionen
TIMESTAMP DEVICE TYPE EVENT READING VALUE UNIT
2018-03-10 21:46:16 ENT_Zaehlerstand VOLKSZAEHLER average: 98691.537 average 98691.537
2018-03-10 21:46:16 EHT_Zaehlerstand VOLKSZAEHLER average: 13971.108 average 13971.108
2018-03-10 21:46:16 EPV_Zaehlerstand VOLKSZAEHLER average: 20826.009 average 20826.009
2018-03-10 21:46:05 PV_WR1 SMAUTILS etotal: 29583.926 etotal 29583.926
Hallo Peter,
erstmal soweit ok. außer dass das ein hornalter Stand ist. Auf jeden Fall komplett updaten.
Seit Juli 2016 hat sich enorm viel weiterentwickelt, nicht nur bei DbLog.
In deinem DEF ist ein "oder" (|) zuviel drin, aber das nur nebenbei. :)
Nach dem Update kannst du die neuen Features wie asynch-Mode und Anderes nutzen.
Grüße
Heiko
Hallo Heiko,
habe jetzt ein FHEM update gewagt und komme prompt nicht mehr per Browser an FHEM,
kann zwar fhem stoppen und starten, aber ohne Ergebnis.
mache morgen weitere Versuche.
Gute Nachtruhe und Grüße von Peter
Guten Morgen Peter,
scheint doch ein allgemeines Problem bei dir vorzuliegen. Aber ohne die Ausgaben und eventuelle Fehlermeldungen im Logfile kann man wenig dazu sagen.
Cooltux hat mal im Wiki eine Hinweisseite mit Tipps zur Fehlersuche erstellt. Vielleicht hilft es weiter:
https://wiki.fhem.de/wiki/FHEM_startet_nicht_-_Tipps_zur_Fehlersuche
Vielleicht solltest du einen neuen Thread mit deinen Problemen starten, denn der Titel dieses Threads passt nicht zu der jetzt diskutierten Problematik.
LG,
Heiko
ok Heiko,
ich lass das erst mal so laufen, bekomme ja die Daten die ich brauche.
Bedanke mich noch einmal für Deine Hilfe und bis auf ein anderes Mal.
Liebe Grüße Peter