CCU-Historian V2.0.0-beta.5 (auch für CCU3 V3.41.7)

Das Langzeitarchiv für HomeMatic

Moderator: Co-Administratoren

NickHM
Beiträge: 3729
Registriert: 23.09.2017, 12:04
Hat sich bedankt: 65 Mal
Danksagung erhalten: 119 Mal

Re: CCU-Historian V2.0.0-beta.5 (auch für CCU3 V3.41.7)

Beitrag von NickHM » 07.11.2018, 15:10

scorpionking hat geschrieben:
07.11.2018, 14:15

Der DUTY_CYCLE Datenpunkt existiert offensichtlich nur, wenn der DC mal über eine bestimmte Schwelle kam und ist spätestens nach einem Reboot wieder weg.
Dann lösche ich den jetzt einfach mal aus dem CCu Historian, mein DC ist ja in letzter Zeit immer schön unter 20%...
Ich würde den eher deaktivieren, als löschen.
Ist er gelöscht, wird er wieder neu angelegt, wenn er in der CCU erscheint. Dann ist das Problem wieder da, sobald der Datenpunkt wieder weg ist.

derrapf
Beiträge: 815
Registriert: 17.12.2012, 22:29

Re: CCU-Historian V2.0.0-beta.5 (auch für CCU3 V3.41.7)

Beitrag von derrapf » 15.11.2018, 00:13

Hi
Ich habe festgestellt dass ab dem 3.11 der Historian nichts mehr loggt.
Allerdings hab ich das erst gesehen als ich heute auf die Beta5 upgedate habe.
Ich habe das Logfile hier angehängt. Da kommen 1000de "Datenbank wird schon verwendet" Meldungen seit dem 28.10. Er scheint aber wie man am Screenshot sieht bis zum 3.11 funktioniert zu haben. Aufgrund der Grösse als Link:
https://www.dropbox.com/s/maajcqud43ck2 ... 0.log?dl=0
2018-11-14 23_52_45-Window.jpg
Ich habe heute auf beta5 upgedatet.
Das log von heute enthält auch ziemlich viele Fehler und angeblich kann das Konfgurationsfile nicht gelesen werden.
ccu-historian.log
(14.86 KiB) 38-mal heruntergeladen
Aber wie man Screenshot (der ist von der beta5) oben sieht, läuft der Historian eigentlich.
Er loggt auch wieder:
2018-11-15 00_16_26-Window.jpg
Deshalb zwei Fragen:
- Müssen mich das/die Logs beunruhigen?
- Wie kann ich herausfinden warum der Historian nicht mehr loggt?

Gruss Ralf

Mathias
Beiträge: 1767
Registriert: 03.11.2010, 10:25
System: CCU
Wohnort: Aachen
Hat sich bedankt: 58 Mal
Danksagung erhalten: 253 Mal
Kontaktdaten:

Re: CCU-Historian V2.0.0-beta.5 (auch für CCU3 V3.41.7)

Beitrag von Mathias » 18.11.2018, 19:57

Es gibt zwei Möglichkeiten:
  1. Der CCU-Historian wurde doppelt gestartet.
  2. Oder es hat sich ein Defekt in die Datenbank eingeschlichen.

Bitte mal einen Datenbank-Export mit der Kommandozeilenoption -createscript erstellen (s.a. Handbuch). Danach die Datenbankdatei löschen (history.mv.db) und mit der Kommandozeilenoption -runscript wieder herstellen.

Falls die Vorgehensweise keinen Erfolg bringt, dann das Reparaturwerkzeug einmal anwenden (s. Forum "Wiederherstellung einer defekten Datenbank").

Gruß
Mathias

blackbasket
Beiträge: 133
Registriert: 13.07.2018, 13:19
Hat sich bedankt: 6 Mal
Danksagung erhalten: 4 Mal

Re: CCU-Historian V2.0.0-beta.5 (auch für CCU3 V3.41.7)

Beitrag von blackbasket » 20.11.2018, 08:53

Hallo Mathias,

nachdem ich den CCU-Rechner neugestartet habe, war ich nun auch zum Update (von v1.2) gezwungen.
Ich erhalte folgende Fehlermeldung:

Code: Alles auswählen

2018-11-20 08:42:28|SEVERE |Exception: java.lang.IndexOutOfBoundsException
2018-11-20 08:42:28|SEVERE |Detail: java.lang.IndexOutOfBoundsException
        at org.jfree.chart.encoders.SunPNGEncoderAdapter.encode(SunPNGEncoderAda
pter.java:131)
        at trend$_run_closure1.doCall(trend.gy:218)
        at trend$_run_closure1.doCall(trend.gy)
        at mdz.Exceptions.lambda$0(Exceptions.java:84)
        at mdz.Exceptions.catchToLog(Exceptions.java:74)
        at mdz.Exceptions.catchToLog(Exceptions.java:84)
        at mdz.ccuhistorian.webapp.WebUtilities.catchToLog(WebUtilities.groovy:8
3)
        at trend.run(trend.gy:193)
        at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:534
)
        at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(Servlet
Handler.java:1351)
        at org.eclipse.jetty.servlets.CrossOriginFilter.handle(CrossOriginFilter
.java:186)
        at org.eclipse.jetty.servlets.CrossOriginFilter.doFilter(CrossOriginFilt
er.java:158)
        at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(Servlet
Handler.java:1322)
        at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java
:473)
        at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.j
ava:119)
        at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.jav
a:516)
        at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandl
er.java:226)
        at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandl
er.java:929)
        at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:
403)
        at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandle
r.java:184)
        at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandle
r.java:864)
        at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.j
ava:117)
        at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper
.java:114)
        at org.eclipse.jetty.server.Server.handle(Server.java:352)
        at org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.
java:596)
        at org.eclipse.jetty.server.HttpConnection$RequestHandler.headerComplete
(HttpConnection.java:1051)
        at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:590)
        at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:212)

        at org.eclipse.jetty.server.HttpConnection.handle(HttpConnection.java:42
6)
        at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEn
dPoint.java:508)
        at org.eclipse.jetty.io.nio.SelectChannelEndPoint.access$000(SelectChann
elEndPoint.java:34)
        at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEnd
Point.java:40)
        at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool
.java:451)
2018-11-20 08:42:28|WARNING|Committed before 400 java.lang.IndexOutOfBoundsExcep
tion
2018-11-20 08:42:28|SEVERE |Exception: Committed
2018-11-20 08:42:28|SEVERE |Detail: java.lang.IllegalStateException: Committed
        at org.eclipse.jetty.server.Response.resetBuffer(Response.java:1046)
        at org.eclipse.jetty.server.Response.sendError(Response.java:259)
        at trend$_run_closure2.doCall(trend.gy:227)
        at trend$_run_closure2.doCall(trend.gy)
        at mdz.Exceptions.lambda$0(Exceptions.java:84)
        at mdz.Exceptions.catchToLog(Exceptions.java:74)
        at mdz.Exceptions.catchToLog(Exceptions.java:84)
        at mdz.ccuhistorian.webapp.WebUtilities.catchToLog(WebUtilities.groovy:8
3)
        at trend.run(trend.gy:226)
        at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:534
)
        at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(Servlet
Handler.java:1351)
        at org.eclipse.jetty.servlets.CrossOriginFilter.handle(CrossOriginFilter
.java:186)
        at org.eclipse.jetty.servlets.CrossOriginFilter.doFilter(CrossOriginFilt
er.java:158)
        at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(Servlet
Handler.java:1322)
        at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java
:473)
        at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.j
ava:119)
        at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.jav
a:516)
        at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandl
er.java:226)
        at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandl
er.java:929)
        at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:
403)
        at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandle
r.java:184)
        at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandle
r.java:864)
        at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.j
ava:117)
        at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper
.java:114)
        at org.eclipse.jetty.server.Server.handle(Server.java:352)
        at org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.
java:596)
        at org.eclipse.jetty.server.HttpConnection$RequestHandler.headerComplete
(HttpConnection.java:1051)
        at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:590)
        at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:212)

        at org.eclipse.jetty.server.HttpConnection.handle(HttpConnection.java:42
6)
        at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEn
dPoint.java:508)
        at org.eclipse.jetty.io.nio.SelectChannelEndPoint.access$000(SelectChann
elEndPoint.java:34)
        at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEnd
Point.java:40)
        at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool
.java:451)
Kannst du mir sagen, was ich tun muss?

LG,
Marcel

PS: Muss die Firewall auf der CCU wirklich auf offen stehen oder reicht es, die Ports (https://github.com/mdzio/ccu-historian/ ... en-der-ccu) freizugeben?

blackbasket
Beiträge: 133
Registriert: 13.07.2018, 13:19
Hat sich bedankt: 6 Mal
Danksagung erhalten: 4 Mal

Re: CCU-Historian V2.0.0-beta.5 (auch für CCU3 V3.41.7)

Beitrag von blackbasket » 20.11.2018, 09:12

Hallo Mathias,

ich möchte direkt noch eine Frage hinterherschieben.

In v1.2 gab es

Code: Alles auswählen

session.maxInactiveInterval=1800
in der skeleton-header.gy. Für v2.0 finde ich den Wert nicht mehr. Kannst du mir verraten, wo er hingewandert ist?

Danke und LG,
Marcel

blackbasket
Beiträge: 133
Registriert: 13.07.2018, 13:19
Hat sich bedankt: 6 Mal
Danksagung erhalten: 4 Mal

Re: CCU-Historian V2.0.0-beta.5 (auch für CCU3 V3.41.7)

Beitrag von blackbasket » 20.11.2018, 09:42

Ok, die Frage zum Timeout hat sich erledigt. Ich habe den Wert unter

Code: Alles auswählen

webapp\WEB-INF\groovy\mdz\ccuhistorian\webapp
wiedergefunden :)

NickHM
Beiträge: 3729
Registriert: 23.09.2017, 12:04
Hat sich bedankt: 65 Mal
Danksagung erhalten: 119 Mal

Re: CCU-Historian V2.0.0-beta.5 (auch für CCU3 V3.41.7)

Beitrag von NickHM » 20.11.2018, 10:08

blackbasket hat geschrieben:
20.11.2018, 08:53

PS: Muss die Firewall auf der CCU wirklich auf offen stehen oder reicht es, die Ports (https://github.com/mdzio/ccu-historian/ ... en-der-ccu) freizugeben?
Guten Morgen

hatte 1.2 noch das alte Datenbankformat ?
Dann musst Du die Anleitung für die Konvertierung der Datenbank befolgen.

Unabhängig davon, kannst Du erst mal versuchen die Beta 5 mit einer neuen leeren DB zum Laufen zu bekommen.

- wenn die CCU die aktuelle FW 3.41 hat (oder 3.37) , dann brauchst Du die Beta5 von Historian
- es müssen nicht alle Ports offen sein. Nur die benötigten. Allerdings kann man zur Inbetriebnahme erst mal alle Ports öffnen nd wenn Historian läuft wieder die Firewall dicht machen.
Ob es sinnvoll ist im lokalen Netzwerk die Firewall der CCU zu nutzen, ist ein anderes Thema ...

- der eigentliche Fehler steht vermutlich im Log File vor der Java Fehlermeldung. Bitte mal den Log Level auf Finest stellen und das komplette Log vom Start bis zum Fehler hier rein stellen.

- welche CCU FW Version ?
- welche Hardware / Beriebssystem für den Historian Rechner?

blackbasket
Beiträge: 133
Registriert: 13.07.2018, 13:19
Hat sich bedankt: 6 Mal
Danksagung erhalten: 4 Mal

Re: CCU-Historian V2.0.0-beta.5 (auch für CCU3 V3.41.7)

Beitrag von blackbasket » 20.11.2018, 10:30

Hallo NickHM,
Guten Morgen
hatte 1.2 noch das alte Datenbankformat ?
Nein, soweit ich aus der Dokumentation entnehme, gilt das für V1.1 und älter.
Unabhängig davon, kannst Du erst mal versuchen die Beta 5 mit einer neuen leeren DB zum Laufen zu bekommen.
- wenn die CCU die aktuelle FW 3.41 hat (oder 3.37) , dann brauchst Du die Beta5 von Historian
- es müssen nicht alle Ports offen sein. Nur die benötigten. Allerdings kann man zur Inbetriebnahme erst mal alle Ports öffnen nd wenn Historian läuft wieder die Firewall dicht machen.
Ob es sinnvoll ist im lokalen Netzwerk die Firewall der CCU zu nutzen, ist ein anderes Thema ...
- der eigentliche Fehler steht vermutlich im Log File vor der Java Fehlermeldung. Bitte mal den Log Level auf Finest stellen und das komplette Log vom Start bis zum Fehler hier rein stellen.
Die Datenbank funktioniert und Werte kommen auch an. Nach einer Zeit kommt halt nur der Fehler. Ja, dass die CCU-Firewall vom Prinzip her überflüssig ist, denke ich mir auch. Ich habe die CCU sowieso in einem eigenen Netzsegment hinter einer HW-FW. Das Log-Level habe ich gerade von FINER auf FINEST umgestellt. Ich warte jetzt auf den Fehler.
- welche CCU FW Version ?
- welche Hardware / Beriebssystem für den Historian Rechner?
FW 3.41.11 auf der CCU
Win7 x64 Hyper-V-VM für den Historian (Java 8.191)

LG,
Marcel

blackbasket
Beiträge: 133
Registriert: 13.07.2018, 13:19
Hat sich bedankt: 6 Mal
Danksagung erhalten: 4 Mal

Re: CCU-Historian V2.0.0-beta.5 (auch für CCU3 V3.41.7)

Beitrag von blackbasket » 20.11.2018, 12:36

Hallo NickHM,

der Fehler taucht nicht mehr auf. Ich hatte zwischenzeitlich nur noch den DeviceType bei den beiden CCU3s entsprechend angepasst, da ich dann im Manual gesehen hatte, dass der Type auch gültig ist.

LG,
Marcel

NickHM
Beiträge: 3729
Registriert: 23.09.2017, 12:04
Hat sich bedankt: 65 Mal
Danksagung erhalten: 119 Mal

Re: CCU-Historian V2.0.0-beta.5 (auch für CCU3 V3.41.7)

Beitrag von NickHM » 20.11.2018, 14:19

ok, dass der Fehler erst im Betrieb auf tritt, hatte ich so nicht verstanden.
Da musst Du auf Mathias als Erfinder warten.

Und vergiss bitte nicht nach einiger zeit den Log Level wieder runter zu stellen :)

Antworten

Zurück zu „CCU-Historian“