History: Restart alle paar Minuten - Downgrade geht nicht
-
Jetzt wird im debug-mode jedes empfangene Datum dreifach eingetragen:
history.0 2018-03-12 03:50:09.095 debug value not changed hm-rpc.1.CUX9000007.1.STATE, last-value=2, new-value=2, ts=1520823009084 history.0 2018-03-12 03:50:09.095 debug value not changed hm-rpc.1.CUX9000007.1.STATE, last-value=2, new-value=2, ts=1520823009084 history.0 2018-03-12 03:50:09.093 debug value not changed hm-rpc.1.CUX9000007.1.STATE, last-value=2, new-value=2, ts=1520823009084 history.0 2018-03-12 03:50:09.062 debug value not changed hm-rpc.1.CUX9000009.1.STATE, last-value=1, new-value=1, ts=1520823009050 history.0 2018-03-12 03:50:09.062 debug value not changed hm-rpc.1.CUX9000009.1.STATE, last-value=1, new-value=1, ts=1520823009050 history.0 2018-03-12 03:50:09.060 debug value not changed hm-rpc.1.CUX9000009.1.STATE, last-value=1, new-value=1, ts=1520823009050Dann gab es noch sowas
!
2018-03-11 10:45:29.180 - [34mdebug[39m: history.0 Min-Delta ignored because no number hm-rpc.0.JEQ012345678.1.MOTION, last-value=true, new-value=false, ts=1520761529168 2018-03-11 10:45:34.007 - [32minfo[39m: web.0 2018-03-11T09:45:34.006Z Connected system.user.admin 2018-03-11 10:45:34.149 - [34mdebug[39m: history.0 use parallel requests 2018-03-11 10:45:34.188 - [34mdebug[39m: history.0 use parallel requests 2018-03-11 10:45:34.214 - [34mdebug[39m: history.0 got 1 datapoints for data.0.Lock.FrontDoor.rfid.alive 2018-03-11 10:45:34.218 - [34mdebug[39m: history.0 after getCachedData: length = 1, isFull=false 2018-03-11 10:45:34.318 - [34mdebug[39m: history.0 after getFileData: cacheData.length = 1, fileData.length = 408 2018-03-11 10:45:34.331 - [34mdebug[39m: history.0 Send: 408 values in: 121ms 2018-03-11 10:45:34.335 - [34mdebug[39m: history.0 sendTo "getHistory" to system.adapter.web.0 from system.adapter.history.0 2018-03-11 10:45:34.820 - [34mdebug[39m: history.0 got 0 datapoints for hm-rpc.1.CUX9000007.1.STATE 2018-03-11 10:45:34.850 - [34mdebug[39m: history.0 got 1 datapoints for hm-rpc.1.CUX9000009.1.STATE 2018-03-11 10:45:34.953 - [34mdebug[39m: history.0 Send: 218 of: 508 in: 804ms 2018-03-11 10:45:34.955 - [34mdebug[39m: history.0 sendTo "getHistory" to system.adapter.web.0 from system.adapter.history.0 2018-03-11 10:45:34.971 - [34mdebug[39m: history.0 Send: 171 of: 269 in: 783ms 2018-03-11 10:45:34.972 - [34mdebug[39m: history.0 sendTo "getHistory" to system.adapter.web.0 from system.adapter.history.0 ! -
Bin jetzt nach heftigen downgraden und Pausieren einiger Adapter auf einem restart von history pro Tag. Nach einigen Restarts gibt es aber generelle Probleme. So geht es also nicht weiter.
Möchte demnächst das System neu aufsetzen, möglichst in einen Zustand, bei dem ein reconnect der DB keinen restart von History auslöst und möglichst wenige reconnects auftreten.
Welche Konfigurationen (node, npm, js-controller, admin, history, HM-adapter etc.) laufen stabil? Kann mir jemand Tipps geben?
-
Hi,
bei mir läuft alles auf latest und stabil!
Ich verstehe einige Dinge aus deinem Log nicht. An sich sollte es nie vorkommen das Adapterinstanzen parallel mehrfach laufen. Das stellt an sich der js-controller sicher.
Also überhaupt das da zwei History-Instanzen laufen ist komisch. Das wäre aber das einzige was in meinen Augen das doppellogging erklären würde. Nur mal um sicherzugehen: Die Logs hier kommen aus dem Admin oder aus dem "echten Logfile"? Wenn Admin - zeigt das echter Logfile das gleiche? (Nicht das Admin Müll anzeigt).
Ich denke nicht das Versionsänderungen hier helfen werden - das kann an sich alles gar nicht sein :-(
Ich hätte malversucht alle Adapter auszuschalten. Dann iobroker neustarten, Log ansehen, dann die wichtigen Adapter und History starten - eins nach dem anderen und immer wieder log beobachten. Und am besten History auf Debug lassen.
-
Vielen Dank!
Ich verstehe es leider auch nicht.
Logfile zeigt immer nur einen History-enabled Eintrag pro Datenpunkt.
Im Admin-Log Window werden aber nach history Neustart eine immer wachsende Zahl von History enabled pro Datenpunkt gezeigt.
Das scheint auch plausibel, weil mit jedem Neustart die ganze enable Prozedur länger dauert und nauch einigen Neustarts gar nicht mehr ganz durchläuft.
-
oookkkkk …wenn das Logfile nur eins anzeigt dann ist es eher ein Thema vom Admin bzw vom "streamed logging handling für Admin".
Das Logfile auf Platte hat hier "mehr recht" als die Admin-Anzeige
Welche Version js-controler? Welche Version Admin?
-
Admin ist
2018-03-21 10:16:38.917 - [32minfo[39m: admin.0 starting. Version 2.0.9 in /opt/iobroker/node_modules/iobroker.admin, node: v6.13.1Controller
`2018-03-21 10:16:32.839 - [32minfo[39m: host.orangepiplus2e iobroker.js-controller version 1.2.3 js-controller starting[/code]` Habe jetzt mal nur das Nötigste am Laufen. Das erste History enablen geht immer flott, bei Folgeaktionen dauert es immer lämnger. Hatte auch schon früher ab und an ein reconnect DB, aber ohne den history Neustart. Wenn Du sagst, daß Dein "neuestes" System stabil läuft, dann kann ich mal eine nächtliche Neuinstallation wagen. Bin immer nur unsicher welches node, npm etc mit was kompatibel ist und wie man dann das richtige zusammenbekommt. Die udate / upgrade -Feinheiten sind mir noch immer fremd. Liegt wohl daran, dass ich mich bisher nicht wirklich damit beschäftigt habe - weil ich es auch nicht wirklich musste. -
Beim Einschalten von web meldet sich history und sagt etwas von "parallel requests". Hat das was zu bedeuten?
!
2018-03-21 10:39:16.980 - [32minfo[39m: web.0 2018-03-21T09:39:16.980Z Connected system.user.admin 2018-03-21 10:39:16.991 - [32minfo[39m: web.0 2018-03-21T09:39:16.990Z Connected system.user.admin 2018-03-21 10:39:17.317 - [34mdebug[39m: history.0 use parallel requests 2018-03-21 10:39:17.375 - [34mdebug[39m: history.0 use parallel requests 2018-03-21 10:39:17.401 - [34mdebug[39m: history.0 use parallel requests 2018-03-21 10:39:17.423 - [34mdebug[39m: history.0 use parallel requests 2018-03-21 10:39:17.475 - [34mdebug[39m: history.0 use parallel requests 2018-03-21 10:39:17.529 - [34mdebug[39m: history.0 use parallel requests 2018-03-21 10:39:17.602 - [34mdebug[39m: history.0 use parallel requests 2018-03-21 10:39:17.824 - [32minfo[39m: web.0 2018-03-21T09:39:17.824Z Connected system.user.admin 2018-03-21 10:39:17.875 - [32minfo[39m: web.0 2018-03-21T09:39:17.875Z Connected system.user.admin 2018-03-21 10:39:17.899 - [32minfo[39m: web.0 2018-03-21T09:39:17.899Z Connected system.user.admin 2018-03-21 10:39:18.026 - [32minfo[39m: web.0 2018-03-21T09:39:18.025Z Connected system.user.admin 2018-03-21 10:39:18.189 - [32minfo[39m: web.0 2018-03-21T09:39:18.188Z Connected system.user.admin 2018-03-21 10:39:18.281 - [32minfo[39m: web.0 2018-03-21T09:39:18.280Z Connected system.user.admin 2018-03-21 10:39:18.396 - [34mdebug[39m: history.0 use parallel requests 2018-03-21 10:39:18.333 - [32minfo[39m: web.0 2018-03-21T09:39:18.333Z Connected system.user.admin 2018-03-21 10:39:18.689 - [32minfo[39m: web.0 2018-03-21T09:39:18.689Z Connected system.user.admin 2018-03-21 10:39:18.991 - [34mdebug[39m: history.0 got 1 datapoints for data.0.Ofi.heating.WC.H-rel !
Web is so konfiguriert! ````
IP: IPv4 0.0.0
Port: 8082
Verschlüsselung(HTTPS): No
Authentifikation: No
Puffer: No
Socket.IO Instanz (Optional): integriert (Wird von Rickshaw oder Vis benutzt)
Nur Web-Sockets: no
Eingebautes 'Simple-API': yes (Gehe aber mit meinen ESP8266 direkt über simple API-Port)
Laufen unter Anwender: AdminNach einiger zeit: >! ```` 2018-03-21 10:39:20.862 - [34mdebug[39m: history.0 sendTo "getHistory" to system.adapter.web.0 from system.adapter.history.0 2018-03-21 10:39:20.866 - [34mdebug[39m: history.0 got 0 datapoints for data.0.heating.Keller-See.H-rel 2018-03-21 10:39:20.868 - [34mdebug[39m: history.0 after getCachedData: length = 0, isFull=false 2018-03-21 10:39:20.950 - [34mdebug[39m: history.0 after getFileData: cacheData.length = 0, fileData.length = 412 2018-03-21 10:39:20.953 - [34mdebug[39m: history.0 Send: 395 values in: 87ms 2018-03-21 10:39:20.955 - [34mdebug[39m: history.0 sendTo "getHistory" to system.adapter.web.0 from system.adapter.history.0 2018-03-21 10:39:20.999 - [34mdebug[39m: history.0 use parallel requests 2018-03-21 10:39:21.044 - [34mdebug[39m: history.0 use parallel requests 2018-03-21 10:39:21.104 - [34mdebug[39m: history.0 use parallel requests 2018-03-21 10:39:21.134 - [34mdebug[39m: history.0 use parallel requests 2018-03-21 10:39:21.180 - [34mdebug[39m: history.0 got 1 datapoints for hm-rpc.1.CUX9002005.0.RSSI_PEER >! ```` -
Admin ist
2018-03-21 10:16:38.917 - [32minfo[39m: admin.0 starting. Version 2.0.9 in /opt/iobroker/node_modules/iobroker.admin, node: v6.13.1Controller
`2018-03-21 10:16:32.839 - [32minfo[39m: host.orangepiplus2e iobroker.js-controller version 1.2.3 js-controller starting[/code]` Habe jetzt mal nur das Nötigste am Laufen. Alles stable Versionen, von daher sollte es keinerlei Probleme haben. ~~[quote]~~ Das erste History enablen geht immer flott, bei Folgeaktionen dauert es immer lämnger. Wie oft schaltest DU das einund aus? :-) Or jetzt zum testen? ~~[quote]~~ Hatte auch schon früher ab und an ein reconnect DB, aber ohne den history Neustart. Das Reconnect weist an sich darauf hin das ggf zuviel Last auf dem System ist. Diese "States-DB" ist eine "in-memory-DB" auf Port 900x und wird vom jscontroller bereitgestellt. Darüber bekommt der Adapter Zugriff auf die States inkl. Updates und so. Ein "Reconnect" heisst dasdie Verbindung weg war und das sollte an sich nicht vorkommen. ~~[quote]~~ Wenn Du sagst, daß Dein "neuestes" System stabil läuft, dann kann ich mal eine nächtliche Neuinstallation wagen. ` ` Das "neuestes" hast Du reingemogelt ... Mein System hab ich vor 2 Jahren installiert und seitdem nur geupdatet ... Das System läuft aber auf dem Latest Repo und nicht "Stable". ~~[quote]~~ Bin immer nur unsicher welches node, npm etc mit was kompatibel ist und wie man dann das richtige zusammenbekommt. ` ` Es sei denn DU brauchst spezielle Adapter ist nodejs 4.x mit npm 3 (was da standard ist) immer noch passend. Node 6 geht auch. node 8 ist grenzwertig :-) Nodejs 4 ist noch bis April offiziell supported, dann sollte man Richtung nodejs 6 gehen. (oder halt 8) ` ` ` ` ``` ` -
Beim Einschalten von web meldet sich history und sagt etwas von "parallel requests". Hat das was zu bedeuten? `
Das sind "getHistory"-Abfragen von flot/riskshaw. "parallel requests" heisst an der Stelle das zur Verarbeiten und Sammeln der Statistikdaten mehrere Threads verwendet werden - ist aber nur zur Datenaufbereitung.
Wieviele Datenpunkte hast Du aktiv im History-Adapter?
-
Danke, ein paar hundert, HM komplett. Das aber schon lange und die Zahl hat sich in jüngster Zeit kaum erhöht.
Bin unterwegs, schaue heute Abend nach der Zahl
-
Wie geht es denn dem System so? Bedenke das "History" das ganze in JSON-Files auf die Platte legt und ggf immer das ganze File neu schreibt wenn Daten dazukommen. Das ist recht viel "I/O", was sich ggf dann in CPU-Auslastung ausdrückt.
Die Alternativen wie SQL oder InfluxDB sind ab einer gewissen Größe vorzuziehen
-
Bis vor der letzten Updaterunde ging es dem System entspannt und jetzt auch noch - wenn nicht gerade die history-enable Geschichte einsetzt oder sich gerade hochschaukelt.
CPU-Auslastung zwischen 0.05 bis 0.5 selten mehr im Normalbetrieb.
Die "reconnect DB" gab es wie gesagt früher auch ab und an aber ohne Folgeaktionen seitens history.
Zur Zahl der subscibierten items: Die HM-Adapter habe ich seinerseits alle global subscribiert. Das läuft schon lange so. Dann noch einige Werte von diversen ESP8266 über simpleApi, wenig tradfri, Xiami robovac, seit einiger Zeit ein wenig sonoff und vielleicht 15 RFLink Geräte.
Habe jetzt im Logfile die Anzahl Zeilen der history-enable events gezählt.
Beim ersten Durchlauf waren es um 7700 und beim zweiten um 11617 Zeilen.
Ich habe ersten nicht verstanden warum es so viele sind (so viele Geräte habe ich nicht) und warum die Zahl von Durchlauf zu Durchlauf schwankt.
Die History-Daten werden auf eine 32GB SSD geschoben, die via USB-Sata-Adapter angebunden ist. Ist aber schon geraume Zeit so und war bis zur letzten update session auch stabil.
Pro Tag werden normalerweise 5 bis 6 MByte history-Daten erzeugt. Das geht schon geraume Zeit so problemlos.
Mit MySQL und Influx kenne ich mich noch gar nicht aus.
Wenn mein PC läuft sind oft 20 browser Tabs mit FLOT-Diagrammen auf. Da sieht man dann nach dem Hochfahren aus dem Resume mode auch mal 70 "Connected system.user.admin" im Logfile, die der Frefox wohl im Hintergrund generiert.
-
Danke für Deine Geduld.
Aus dem Logfile (/opt/iobroker/log/iobroker.log.2018-03-20) eines Starts von gestern. Das ist das kleinste history-enable Ereignis der letzten Tage was ich auf die Schnelle finden konnte. history-log war da noch auf info.
Startet mit
!
2018-03-20 09:44:23.139 - [32minfo[39m: history.0 enabled logging of hm-rpc.0.BidCoS-RF.0.INSTALL_MODE 2018-03-20 09:44:23.145 - [32minfo[39m: history.0 enabled logging of hm-rpc.0.BidCoS-RF.1.LEVEL 2018-03-20 09:44:23.148 - [32minfo[39m: history.0 enabled logging of hm-rpc.0.BidCoS-RF.1.PRESS_LONG 2018-03-20 09:44:23.150 - [32minfo[39m: history.0 enabled logging of hm-rpc.0.BidCoS-RF.1.PRESS_SHORT 2018-03-20 09:44:23.195 - [32minfo[39m: history.0 enabled logging of hm-rpc.0.BidCoS-RF.2.LEVEL 2018-03-20 09:44:23.198 - [32minfo[39m: history.0 enabled logging of hm-rpc.0.BidCoS-RF.2.PRESS_LONG 2018-03-20 09:44:23.205 - [32minfo[39m: history.0 enabled logging of hm-rpc.0.BidCoS-RF.2.PRESS_SHORT 2018-03-20 09:44:23.212 - [32minfo[39m: history.0 enabled logging of hm-rpc.0.BidCoS-RF.3.LEVEL 2018-03-20 09:44:23.220 - [32minfo[39m: history.0 enabled logging of hm-rpc.0.BidCoS-RF.3.PRESS_LONG 2018-03-20 09:44:23.226 - [32minfo[39m: history.0 enabled logging of hm-rpc.0.BidCoS-RF.3.PRESS_SHORT 2018-03-20 09:44:23.255 - [32minfo[39m: history.0 enabled logging of hm-rpc.0.BidCoS-RF.4.LEVEL 2018-03-20 09:44:23.269 - [32minfo[39m: history.0 enabled logging of hm-rpc.0.BidCoS-RF.4.PRESS_LONG 2018-03-20 09:44:23.272 - [32minfo[39m: history.0 enabled logging of hm-rpc.0.BidCoS-RF.4.PRESS_SHORT !endet mit
!
2018-03-20 09:44:31.558 - [32minfo[39m: history.0 enabled logging of rflink.0.channels.EV1527_5.SWITCH_07 2018-03-20 09:44:31.559 - [32minfo[39m: history.0 enabled logging of rflink.0.channels.EV1527_5.SWITCH_0a 2018-03-20 09:44:31.560 - [32minfo[39m: history.0 enabled logging of rflink.0.channels.EV1527_5.SWITCH_0e 2018-03-20 09:44:31.562 - [32minfo[39m: history.0 enabled logging of data.0.motion.Hobby-doorCounterToday 2018-03-20 09:44:31.563 - [32minfo[39m: history.0 enabled logging of data.0.motion.Hobby-doorCounterUntilMidnight 2018-03-20 09:44:31.564 - [32minfo[39m: history.0 enabled logging of data.0.motion.Hobby-doorCounter 2018-03-20 09:44:31.565 - [32minfo[39m: history.0 enabled logging of data.0.motion.Hobby-DoorClosed 2018-03-20 09:44:31.566 - [32minfo[39m: history.0 enabled logging of rflink.0.channels.EV1527_6.SWITCH_07 2018-03-20 09:44:31.568 - [32minfo[39m: history.0 enabled logging of rflink.0.channels.EV1527_6.SWITCH_0a 2018-03-20 09:44:31.569 - [32minfo[39m: history.0 enabled logging of rflink.0.channels.EV1527_6.SWITCH_0e 2018-03-20 09:44:31.570 - [32minfo[39m: history.0 enabled logging of rflink.0.channels.EV1527_8.SWITCH_07 2018-03-20 09:44:31.571 - [32minfo[39m: history.0 enabled logging of rflink.0.channels.EV1527_8.SWITCH_0e 2018-03-20 09:44:31.573 - [32minfo[39m: history.0 enabled logging of rflink.0.channels.EV1527_8.SWITCH_0a !
auf Zeite 3846, gezählt mit notepad++Also keine unmittelbaren Doppelungen und läuft rasch durch.
Habe eine Stichprobe von 10 Zeilen auf Doppelungen untersucht
Ausbeute:
! ```
2018-03-20 09:44:29.745 - [32minfo[39m: history.0 enabled logging of hm-rpc.0.IEQ0243774.0.CONFIG_PENDING_ALARM[/code]
...
~~[code]~~2018-03-20 09:44:25.683 - [32minfo[39m: history.0 enabled logging of hm-rpc.0.IEQ0243774.0.CONFIG_PENDING [/code] -
Und wie gesagt: Logfile hat recht. Also hast du ca. 2846 Datenpunkte im History aktiviert. Ist erstmal ok so. alles gut.
Jetzt die nächste Frage: Wie oft kommt denn diese "enabled" Arie im echteh Logfile? Sollte nur EINMALIG kommen wenn der History-Adapter gestartet wird. Danach sollte das einfach laufen.
-
Ja, so war das auch das letzte Jahr seit ich auf den OPI umgezogen bin und ich hatte logfiles von 10k bis 60k /Tag. Aber seit der letzten update-Runde startete history enable nach jedem "reconnect DB", was vorher nicht der Fall war und von diesen reconnect DB gab es auch mehr. In Abständen von ca. 10, 20, 60 Minuten. Scheint eher "zufällig" Das logfile schwoll auf 20 MB an, fast nur history enabled Einträge, history log Infostufe.
Habe gestern um 10:20 ioBroker mit den wichtigsten Adaptern gestartet und erst mal Ruhe.
Habe gestern Abend um 20:34 RFLink zugeschaltet und dort ein neues Gerät eingebaut.
Heute um 00:14 gab es wieder ein event (history log debugstufe)
!
2018-03-22 00:14:35.614 - [34mdebug[39m: history.0 Min-Delta reached hm-rpc.0.LEQ053xxxx.2.POWER, last-value=0.06, new-value=0.05, ts=1521674067985 2018-03-22 00:14:35.616 - [34mdebug[39m: history.0 value not changed hm-rpc.0.LEQ0539xxxx.2.CURRENT, last-value=0, new-value=0, ts=1521674067990 2018-03-22 00:14:35.618 - [34mdebug[39m: history.0 Min-Delta reached hm-rpc.0.LEQ053xxxx.2.VOLTAGE, last-value=232.2, new-value=232.8, ts=1521674067992 2018-03-22 00:14:35.620 - [34mdebug[39m: history.0 Min-Delta reached hm-rpc.0.LEQ053xxxx.2.FREQUENCY, last-value=49.98, new-value=49.99, ts=1521674067993 2018-03-22 00:14:36.726 - [34mdebug[39m: history.0 statesDB connected 2018-03-22 00:14:36.786 - [33mwarn[39m: history.0 Reconnection to DB. 2018-03-22 00:14:36.852 - [34mdebug[39m: history.0 statesDB connected 2018-03-22 00:14:36.892 - [33mwarn[39m: history.0 Reconnection to DB. 2018-03-22 00:14:37.083 - [32minfo[39m: history.0 starting. Version 1.5.3 in /opt/iobroker/node_modules/iobroker.history, node: v6.13.1 2018-03-22 00:14:37.109 - [32minfo[39m: history.0 starting. Version 1.5.3 in /opt/iobroker/node_modules/iobroker.history, node: v6.13.1 2018-03-22 00:14:37.221 - [34mdebug[39m: history.0 value not changed hm-rpc.1.CUX9000009.1.STATE, last-value=0, new-value=0, ts=1521674077201 2018-03-22 00:14:37.224 - [34mdebug[39m: history.0 value not changed hm-rpc.1.CUX9000007.1.STATE, last-value=3, new-value=3, ts=1521674077207 2018-03-22 00:14:37.825 - [32minfo[39m: history.0 enabled logging of hm-rpc.0.updated 2018-03-22 00:14:37.826 - [32minfo[39m: history.0 enabled logging of hm-rpc.0.BidCoS-RF.0.INSTALL_MODE 2018-03-22 00:14:37.828 - [32minfo[39m: history.0 enabled logging of hm-rpc.0.BidCoS-RF.1.LEVEL 2018-03-22 00:14:37.828 - [32minfo[39m: history.0 enabled logging of hm-rpc.0.BidCoS-RF.1.PRESS_LONG 2018-03-22 00:14:37.829 - [32minfo[39m: history.0 enabled logging of hm-rpc.0.BidCoS-RF.1.PRESS_SHORT 2018-03-22 00:14:37.829 - [32minfo[39m: history.0 enabled logging of hm-rpc.0.BidCoS-RF.2.LEVEL 2018-03-22 00:14:37.830 - [32minfo[39m: history.0 enabled logging of hm-rpc.0.BidCoS-RF.2.PRESS_LONG 2018-03-22 00:14:37.831 - [32minfo[39m: history.0 enabled logging of hm-rpc.0.BidCoS-RF.2.PRESS_SHORT 2018-03-22 00:14:37.831 - [32minfo[39m: history.0 enabled logging of hm-rpc.0.BidCoS-RF.3.LEVEL !
…...2018-03-22 00:14:51.387 - [32minfo[39m: history.0 enabled logging of rflink.0.channels.EV1527_5.SWITCH_0a 2018-03-22 00:14:51.388 - [32minfo[39m: history.0 enabled logging of rflink.0.channels.EV1527_5.SWITCH_0e 2018-03-22 00:14:51.389 - [32minfo[39m: history.0 enabled logging of data.0.motion.Hobby-doorCounterToday 2018-03-22 00:14:51.390 - [32minfo[39m: history.0 enabled logging of data.0.motion.Hobby-doorCounterUntilMidnight 2018-03-22 00:14:51.391 - [32minfo[39m: history.0 enabled logging of data.0.motion.Hobby-doorCounter 2018-03-22 00:14:51.392 - [32minfo[39m: history.0 enabled logging of data.0.motion.Hobby-DoorClosed 2018-03-22 00:14:51.393 - [32minfo[39m: history.0 enabled logging of rflink.0.channels.EV1527_6.SWITCH_07 2018-03-22 00:14:51.394 - [32minfo[39m: history.0 enabled logging of rflink.0.channels.EV1527_6.SWITCH_0a 2018-03-22 00:14:51.394 - [32minfo[39m: history.0 enabled logging of rflink.0.channels.EV1527_6.SWITCH_0e 2018-03-22 00:14:51.395 - [32minfo[39m: history.0 enabled logging of rflink.0.channels.EV1527_8.SWITCH_07 2018-03-22 00:14:51.396 - [32minfo[39m: history.0 enabled logging of rflink.0.channels.EV1527_8.SWITCH_0e 2018-03-22 00:14:51.397 - [32minfo[39m: history.0 enabled logging of rflink.0.channels.EV1527_8.SWITCH_0a 2018-03-22 00:14:51.398 - [32minfo[39m: history.0 enabled logging of rflink.0.channels.EV1527_9.SWITCH_07 2018-03-22 00:14:51.398 - [32minfo[39m: history.0 enabled logging of rflink.0.channels.EV1527_9.SWITCH_0e 2018-03-22 00:14:51.399 - [32minfo[39m: history.0 enabled logging of rflink.0.channels.EV1527_9.SWITCH_0a 2018-03-22 00:15:56.060 - [34mdebug[39m: history.0 Min-Delta reached hm-rpc.1.CUX9002008.1.DEW_POINT, last-value=-3.1, new-value=-3.14, ts=1521674156052 2018-03-22 00:15:56.072 - [34mdebug[39m: history.0 Min-Delta reached hm-rpc.1.CUX9002008.1.ABS_HUMIDITY, last-value=3.74, new-value=3.73, ts=1521674156059 2018-03-22 00:17:37.412 - [34mdebug[39m: history.0 value not changed hm-rpc.0.HEQ051xxxx.1.TEMPERATURE, last-value=19.4, new-value=19.4, ts=1521674257398 2018-03-22 00:17:37.434 - [34mdebug[39m: history.0 value not changed hm-rpc.0.HEQ051xxxx.1.HUMIDITY, last-value=37, new-value=37, ts=1521674257421 2018-03-22 00:17:44.117 - [34mdebug[39m: history.0 value not changed hm-rpc.0.MEQ04xxxx.4.CONTROL_MODE, last-value=0, new-value=0, ts=1521674264108 2018-03-22 00:17:44.127 - [34mdebug[39m: history.0 value not changed hm-rpc.0.MEQ044xxxx.4.FAULT_REPORTING, last-value=0, new-value=0, ts=1521674264118 2018-03-22 00:17:44.139 - [34mdebug[39m: history.0 value not changed hm-rpc.0.MEQ044xxxx.4.BATTERY_STATE, last-value=2.4, new-value=2.4, ts=1521674264131 2018-03-22 00:17:44.166 - [34mdebug[39m: history.0 value not changed hm-rpc.0.MEQ044xxxx.4.VALVE_STATE, last-value=0, new-value=0, ts=1521674264137 2018-03-22 00:17:44.173 - [34mdebug[39m: history.0 value not changed hm-rpc.0.MEQ044xxxx.4.BOOST_STATE, last-value=0, new-value=0, ts=1521674264139 >! ```` -
Zur Zeit sieht es so aus:
root@orangepiplus2e:~# ps auxww|grep history root 16753 0.0 0.0 3668 756 pts/0 S+ 10:16 0:00 grep history root 28003 2.7 1.2 137476 25452 ? Sl Mar21 39:24 io.history.0 root@orangepiplus2e:~# -
Aus meiner Sicht sind es zei Themen:
-
reconnect DB. Das habe ich schon seit Anfang des Jahres viewtopic.php?p=118988#p118988 . Bisher aber friedlich ohne sichtbare Auswirkungen.
-
Jetzt startet aber history eine Runde enable nach dieser Fehlermeldung. Die neuen histories haben dann dummerweise auch noch den letzten Datenpunkt wiederholt eingetragen, was meine Kurven von täglich (nur einmal täglich) gemessenen Werten verunstaltet. Wahrscheinlich ein gewolltes Feature, was in meiner Konstellation aber unschön ist.
Wenn ich wüsste, dass eine Neuinstallation hülfe, könnte ich eine Nachtschicht einlegen. Habe gerade Urlaub.
Wenn ich wüßte wie dem connection loss auf die Spur kommen kann würde ich natürlich auch das tun. Aber dazu reichen meine EDV-Kenntnisse nicht. Hätte nicht mal bei Windows ne Idee, geschweige den bei Linux. Wenn es keine passenden Logs oder Ereignisanzeigen gibt, wüßte ich auch nicht wo man heutzutage noch nachschauen kann. Glaube nicht, daß das an der SSD liegt, so langsam ist die auch wieder nicht - zumindest nicht an Windows.
-
Hey! Du scheinst an dieser Unterhaltung interessiert zu sein, hast aber noch kein Konto.
Hast du es satt, bei jedem Besuch durch die gleichen Beiträge zu scrollen? Wenn du dich für ein Konto anmeldest, kommst du immer genau dorthin zurück, wo du zuvor warst, und kannst dich über neue Antworten benachrichtigen lassen (entweder per E-Mail oder Push-Benachrichtigung). Du kannst auch Lesezeichen speichern und Beiträge positiv bewerten, um anderen Community-Mitgliedern deine Wertschätzung zu zeigen.
Mit deinem Input könnte dieser Beitrag noch besser werden 💗
Registrieren Anmelden563
Online32.8k
Benutzer82.7k
Themen1.3m
Beiträge