${ccuNotReadyHint} nach Neustart des CCU-Historian

[papi]

Hallo zusammen,

ich bräuchte mal bitte Eure Hilfe:

Da mein CCU-Historian der gerade erfolgten Zeitumstellung nicht nachgekommen ist und damit jetzt eine Stunde daneben lag, habe ich mir überlegt, die Timezone seines Docker-Containers von "TZ=UTC" auf "TZ=Europe/Berlin" zu stellen, was laut date-Abfrage in der Console des CCU-Historian (ich nutze den Portainer) auch zu einer korrekten Uhrzeit führte.

Seitdem startet der CCU-Historian aber nun nicht mehr. Vorsichtshalber habe ich die Zeitzone erstmal wieder zurückgestellt, um meine Veränderungen rückgängig zu machen, aber das brachte keine Besserung.

Im Log des Historian finde ich nun wiederkehrend folgende Fehlermeldung:

2023-11-04 09:44:04|SEVERE |Detail: java.io.IOException: Server returned HTTP response code: 503 for URL: http://192.168.1.114:2000
at mdz.hc.itf.hm.HmXmlRpcClient.init(HmXmlRpcClient.groovy:55)
at mdz.hc.itf.hm.HmXmlRpcInterface.init(HmXmlRpcInterface.groovy:123)
at mdz.hc.itf.hm.HmReinitTask$_checkInterfaces_closure1$_closure3$_closure4.doCall(HmReinitTask.groovy:83)
at mdz.hc.itf.hm.HmReinitTask$_checkInterfaces_closure1$_closure3$_closure4.call(HmReinitTask.groovy)
at mdz.Exceptions.lambda$0(Exceptions.java:84)
at mdz.Exceptions.catchToLog(Exceptions.java:74)
at mdz.Exceptions.catchToLog(Exceptions.java:84)
at mdz.hc.itf.hm.HmReinitTask$_checkInterfaces_closure1$_closure3.doCall(HmReinitTask.groovy:82)
at mdz.hc.itf.hm.HmReinitTask$_checkInterfaces_closure1$_closure3.call(HmReinitTask.groovy)
at mdz.hc.itf.hm.HmReinitTask$_checkInterfaces_closure1.doCall(HmReinitTask.groovy:77)
at mdz.hc.itf.hm.HmReinitTask$_checkInterfaces_closure1.call(HmReinitTask.groovy)
at mdz.Exceptions.lambda$0(Exceptions.java:84)
at mdz.Exceptions.catchToLog(Exceptions.java:74)
at mdz.Exceptions.catchToLog(Exceptions.java:84)
at mdz.hc.itf.hm.HmReinitTask.checkInterfaces(HmReinitTask.groovy:73)
at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(Unknown Source)

Er scheint also die URL: http://192.168.1.114:2000 meiner CCU plötzlich nicht mehr öffnen zu können, wenn ich das richtig deute.
Rufe ich die URL nebst Port im Browser zu Fuß auf, zeigt mir die dort befindliche CCU "${ccuNotReadyHint}".
(Ja, die Authentifizierung in der CCU ist natürlich abgeschaltet, sonst hätte es ja auch 10 Minuten vorher nicht noch funktioniert.)
Wenn ich meine Zeitzonen-Anpassung mal außen vorlasse, ist es doch seltsam, dass durch einen einfachen Restart des CCU-Historian plötzlich dieser Effekt auftritt?!

Meine Frage ist zunächst, ob sich an der Firmware der CCU in letzter Zeit etwas maßgeblich verändert hat, das zu diesem Effekt führen könnte?
Wird der Port anderweitig verwendet oder muss er umgeleitet werden? Ich finde auch sonst nichts Weiteres dazu.
Ich hatte bei der Suche einen Beitrag Beitrag von Roland M. zu ähnlicher Thematik gesehen, konnte mit seiner Aussage aber nicht viel anfangen. Es ging hier um die Firmware RM 3.71.12.20230826, die auch ich momentan noch auf der CCU habe, da ich von Jens gelesen hatte, dass die aktuelle RM-Version noch den ein- oder anderen Pferdefuß hatte, da wollte ich erstmal abwarten.
Meine Problemstellung hier habe ich extra nicht im Vorbenannten Thread angehangen, da mir nicht bekannt ist, ob der Fehler überhaupt zu dieser Thematik gehört. Sollte dem so sein, mag man meinen Beitrag gerne verschubsen.

Wäre super, wenn sich mal jemand meines Problems annehmen würde.

P.S: Ich habe auch noch das alte XML-API-Addon in Gebrauch, da mit der neuen 2.0 bei mir gar nichts mehr funktionieren würde.

Danke und Gruß
Michael

[Mathias]

Gibt es zu diesem Zeitpunkt Meldungen im System-Log der CCU? Wurde die CCU neu gestartet?

Ein Szenario, wie dies mit dem CCU-Historian zusammenhängen könnte, fällt mir nicht ein.

[papi]

Nein, leider nichts dergleichen in der CCU.

Ich habe aber mal eben eine CCU-Historian-Windows-Version auf meine Büchse draufgezogen, da passiert quasi dasselbe.
Es kommt die gleiche Fehlermeldung, aber hier kann der Historian zumindest den Webserver starten und ist auf Port 80 erreichbar, das bekommt ein in meinem Docker nicht hin.

Hier der Log-Inhalt von meiner Windows-Version:

2023-11-04 15:44:11|SEVERE |Exception: Server returned HTTP response code: 503 for URL: http://192.168.1.114:2000
2023-11-04 15:44:11|SEVERE |Detail: java.io.IOException: Server returned HTTP response code: 503 for URL: http://192.168.1.114:2000
at mdz.hc.itf.hm.HmXmlRpcClient.init(HmXmlRpcClient.groovy:55)
at mdz.hc.itf.hm.HmXmlRpcInterface.init(HmXmlRpcInterface.groovy:123)
at mdz.hc.itf.hm.HmReinitTask$_checkInterfaces_closure1$_closure3$_closure4.doCall(HmReinitTask.groovy:83)
at mdz.hc.itf.hm.HmReinitTask$_checkInterfaces_closure1$_closure3$_closure4.call(HmReinitTask.groovy)
at mdz.Exceptions.lambda$0(Exceptions.java:84)
at mdz.Exceptions.catchToLog(Exceptions.java:74)
at mdz.Exceptions.catchToLog(Exceptions.java:84)
at mdz.hc.itf.hm.HmReinitTask$_checkInterfaces_closure1$_closure3.doCall(HmReinitTask.groovy:82)
at mdz.hc.itf.hm.HmReinitTask$_checkInterfaces_closure1$_closure3.call(HmReinitTask.groovy)
at mdz.hc.itf.hm.HmReinitTask$_checkInterfaces_closure1.doCall(HmReinitTask.groovy:77)
at mdz.hc.itf.hm.HmReinitTask$_checkInterfaces_closure1.call(HmReinitTask.groovy)
at mdz.Exceptions.lambda$0(Exceptions.java:84)
at mdz.Exceptions.catchToLog(Exceptions.java:74)
at mdz.Exceptions.catchToLog(Exceptions.java:84)
at mdz.hc.itf.hm.HmReinitTask.checkInterfaces(HmReinitTask.groovy:73)

[Mathias]

Die CCU weist den Historian mit 503 (Service Unavailable) zurück. Der CCU-Historian kann daran nichts ändern. Da muss etwas in der CCU im argen sein.

[papi]

Sehe ich auch so, darum meine Frage, ob sich in der CCU etwas geändert hat.
Ich habe daran selber schon länger nichts mehr gemacht, da blieb mir nur die Frage nach der Firmware.

[papi]

Boah neeee, ne? Ich brech´zusammen!

Gerade habe ich mal die Docker-Einstellungen des Containers auf der Synology geöffnet, anstatt ihn, wie sonst immer, mittels Portainer zu befummeln und da fiel es mir wie Schuppen aus den Haaren:
Im CCU-Historian-Container war unter "Port-Einstellungen" bei "Lokaler Port" "Automatisch" eingestellt, damit hat der CCU-Historian nach dem heutigen Neustart (wegen der Anpassung der Zeitzone) einen anderen/neuen Port bekommen und ich habe es nicht bemerkt, sondern stattdessen weiterhin den alten, gebookmarkten Port aufgerufen. Das Ding hat sogar die ganze Zeit munter weitergearbeitet!

Ich habe ihm nun den alten Port wieder fest aufs Auge gedrückt, nun klappts auch wieder.
(Kann man tatsächlich nicht einfach so ändern, ich habe den ganzen Container wieder mittels Portainer, mit angepassten Port-Einstellungen, dupliziert und den Alten gelöscht)
Super, mal wieder ca. 6h Zeit verschwendet, mit solch einem selbstgebauten Sch....

Der erwähnte Fehler mit dem Port 2000 ist übrigens noch immer da. Vermutlich habe ich ihn auch schon sehr lange, aber es funktioniert alles trotzdem, darum ist er mir wohl auch nie aufgefallen. Ich führe ihn hier nochmal explizit an:

2023-11-04 16:43:04|SEVERE |Exception: Server returned HTTP response code: 503 for URL: http://192.168.1.114:2000
2023-11-04 16:43:04|SEVERE |Detail: java.io.IOException: Server returned HTTP response code: 503 for URL: http://192.168.1.114:2000

Wenn mal jemand drüber stolpert, wäre ich für einen Tipp dankbar! Bis dahin verbreitere ich jetzt mein Akzeptanz-Spektrum, um den restlichen Samstag noch genießen zu können.

Danke Mathias und Allen, die sich bemüht haben!

[Mathias]

Es kann natürlich noch Folgendes sein: Auf Port 2000 der CCU läuft der Schnittstellenprozess BidCos-Wired. Dieser existiert nur wenn Du auch ein HMWLGW im Einsatz hast. Ansonsten ist die Schnittstellenprozess nicht vorhanden. In der ccu-historian.config kann angegeben werden, ob der Schnittstellenprozess für BidCos-Wired abgefragt werden soll.

[papi]

Ich glaube, wir sind sehr nah dran.
In meiner Config habe ich "devices.device1.plugin1.type=HMWLGW" aktiv, wohl da ich davon ausging, dass meine beiden selbstgebauten CCU2-LAN-GWs damit erfasst werden.

Sie standen auch als Datenpunkte (für deren jeweiligen Duty-Cycle) mit drin, wurden aber nicht (mehr) bedient. Vermutlich da ich sie mal umbenannt habe, standen sie sogar jeweils doppelt drin und die Zentrale/CCU3 war außerdem aufgeführt. Ich hatte damit 5 Leichen in der Datenpunktliste, die auch beim Start des Historian im Log bemängelt wurden. Habe ich danach ausgewertet, haben sie aber auch wirklich mal Daten geliefert, zuletzt die CCU3, bis Juli´23. Die Anderen CCU2LGWs hatten wohl schon Juli´22 ihre Kommunikation unbemerkt eingestellt.
Da ich die Duty-Cycles auch über SysVars bekomme, ist das aber nicht dramatisch, ich habe die Fünf jetzt gelöscht.

Mal konkret: Ich habe eine RaspberryMatic mit Funkmodul-Aufsatz, CUxD und den beiden o.g. Freunden.
Brauche ich für die umgefrickelten CCU2s kein Plugin?

Ich kommentiere die eingangs erwähnte HMWLGW-Zeile in der Zwischenzeit mal aus und sehe, was passiert...

2023-11-05 07:01:07|INFO |CCU-Historian V3.4.0
2023-11-05 07:01:07|INFO |(C)MDZ (info@ccu-historian.de)
2023-11-05 07:01:10|INFO |Starting base services
2023-11-05 07:01:11|INFO |Connecting to database
2023-11-05 07:01:15|INFO |Starting database web server
2023-11-05 07:01:16|INFO |Setting up device 1
2023-11-05 07:01:16|INFO |Creating HM script client for http://192.168.1.114:8181/tclrega.exe
2023-11-05 07:01:16|INFO |Setting up plug-in 1
2023-11-05 07:01:16|INFO |Configured following interfaces: BidCos-RF, HmIP-RF, SysVar, CUxD
2023-11-05 07:01:17|INFO |Starting interfaces
2023-11-05 07:01:17|INFO |Starting XML-RPC server on port 2098
2023-11-05 07:01:17|INFO |Starting historian
2023-11-05 07:01:18|INFO |Starting web server
2023-11-05 07:01:19|INFO |Web server port: 80

Sieht eigentlich sehr gut aus. Ich vermisse zumindest gerade nichts!?

[Mathias]

Das HMWLGW ist nur für HM-Classic Wired-Komponenten. Wenn Du diese nicht hast, dann also in der Konfiguration löschen,

[papi]

Dankeschön!