Probleme mit CCU-Historian im Zusammenspiel mit CL-Studio seit Update 3.71.12.20231014 und später

[Baxxy]

Ich denke nicht das Jens (RM) vom "Stand jetzt" abrücken wird.
Ziel war es ja, das während der Bootphase kein externer Prozess auf die Schnittstellen zugreifen kann.
Umgesetzt wird das halt mit blockierten Schnittstellenports die erst am Ende der Bootphase freigegeben werden.

Externe Anwendungen und auch lokale AddOns müssen halt einen "Reconnect-Mechanismus" haben der solange zyklisch versucht eine Verbindung aufzubauen bis diese steht.

Ich habe hier mehrere verschiedene Testsysteme auf denen das problemlos mit dem Historian und anderen Anwendungen klappt.
(CL-Studio nutze ich aber nicht)

Alternativ muss eben mein Workaround zum laufen gebracht werden.
viewtopic.php?f=38&t=82024&start=10#p799934

[snirk]

Na dann installiere Dir doch einfach mal auf einem Deiner Testsysteme CL-Studio, es bedarf keiner weiteren Konfiguration, die bloße Installation des Addons reicht aus um die Probleme hervorzurufen.

Deinen Workaround bekomme ich leider nicht zum Laufen, warum er bei Dir funktioniert und bei mir nicht, kriege ich nicht raus. Ich habe alles umgesetzt wie von Dir beschrieben.

Ich arbeite jetzt an einem eigenen Workaround, der dafür sorgt, dass CCU-Historian nach dem Bootvorgang von RM nach einer Zeitverzögerung von 1-2 Minuten nochmal gestoppt und neu gestartet wird. Keine schöne Lösung, aber das sollte meine Probleme dann umschiffen.

Ich gebe Rückmeldung wenn ich erfolgreich war (oder auch nicht).

[Baxxy]

Na dann installiere Dir doch einfach mal auf einem Deiner Testsysteme CL-Studio

Habe ich gemacht, und ja ich kann die Probleme mit den SysVar's nachvollziehen.

Fakten:

• Das Problem hängt mit den gesperrten Ports beim Bootvorgang zusammen.
  Wenn ich meinen Workaround etabliere, und somit ohne gesperrte Ports starte, dann läuft alles
• Das Problem tritt nicht auf wenn nur Historian installiert ist.
• Das Problem tritt auf wenn zusätzlich CL-Studio installiert ist.

Bezüglich der Interfaces fängt sich der Historian indem er nach dem Timeout neu connected.

Die SysVars werden über Remote-Script geholt und hier klemmt irgendwas.
Nach dem Start wird 2x angemeckert:

Code: Alles auswählen

2024-04-22 23:05:50|SEVERE |Exception: Server returned HTTP response code: 503 for URL: http://127.0.0.1:8181/tclrega.exe
2024-04-22 23:05:51|SEVERE |Detail: java.io.IOException: Server returned HTTP response code: 503 for URL: http://127.0.0.1:8181/tclrega.exe

2024-04-22 23:05:51|SEVERE |Exception: Server returned HTTP response code: 503 for URL: http://127.0.0.1:8181/tclrega.exe
2024-04-22 23:05:51|SEVERE |Detail: java.io.IOException: Server returned HTTP response code: 503 for URL: http://127.0.0.1:8181/tclrega.exe

Danach dann alle 30s:

Code: Alles auswählen

2024-04-22 23:05:51|FINE   |Reading system variable values
2024-04-22 23:05:51|FINER  |Getting values of system variables
2024-04-22 23:06:21|FINE   |Reading system variable values
2024-04-22 23:06:21|FINER  |Getting values of system variables
2024-04-22 23:06:51|FINE   |Reading system variable values
2024-04-22 23:06:51|FINER  |Getting values of system variables
2024-04-22 23:07:21|FINE   |Reading system variable values
2024-04-22 23:07:21|FINER  |Getting values of system variables
2024-04-22 23:07:51|FINE   |Reading system variable values
2024-04-22 23:07:51|FINER  |Getting values of system variables
2024-04-22 23:08:21|FINE   |Reading system variable values
2024-04-22 23:08:21|FINER  |Getting values of system variables
2024-04-22 23:08:51|FINE   |Reading system variable values
2024-04-22 23:08:51|FINER  |Getting values of system variables
2024-04-22 23:09:21|FINE   |Reading system variable values
2024-04-22 23:09:21|FINER  |Getting values of system variables
2024-04-22 23:09:51|FINE   |Reading system variable values
2024-04-22 23:09:51|FINER  |Getting values of system variables
2024-04-22 23:10:21|FINE   |Reading system variable values
2024-04-22 23:10:21|FINER  |Getting values of system variables

Es gibt aber keine Rückgabe und somit wird auch nichts aufgezeichnet.
Warum Historian keine Remote-Script-Rückgabe erhält kann ich nicht sagen.

@Mathias: vielleicht guckst du dir das doch mal auf einem Testsystem an.

[snirk]

Vielen Dank für Deine ausführliche Analyse, Baxxy.

Mein Workaround ist umgesetzt und funktioniert. CCU-Historian wird nach dem Booten von RM nach zwei Minuten nochmal gestoppt und neugestartet, dann initialisiert Historian ohne Probleme und auch die Aufzeichnung der Sysvars funktioniert. Das ist eine unschöne Methode, umschifft aber die Probleme und ich kann die neueste RM-Version einsetzen zusammen mit RPI5.

Dein Workaround finde ich aber etwas eleganter, bekomme ihn aber nicht zum laufen. Im habe das Ganze nochmal überprüft und finde keinen Fehler in der Umsetzung. Mein /usr/local/etc/

Code: Alles auswählen

ls -al /usr/local/etc
total 64
drwxr-xr-x    5 root     root          4096 Apr 23 09:28 .
drwxr-xr-x   10 root     root          4096 Mar 14 19:29 ..
drwxrwxr-x   14 root     root          4096 Apr 23 09:01 config
drwx------    2 root     root          4096 Jan  3 11:33 logrotate.d
-rw-r--r--    1 root     root            32 Apr  4  2019 monit.id
-rw-r--r--    1 root     root           581 May 26  2020 monitCCUHistorian.cfg
-rwxr-xr-x    1 root     root           138 Apr 23 08:56 rc.postinit
drwx------    2 root     root          4096 Jan  1  1970 ssh
-rw-------    1 root     root           668 Jan 15  2018 ssh_host_dsa_key
-rw-r--r--    1 root     root           610 Jan 15  2018 ssh_host_dsa_key.pub
-rw-------    1 root     root           227 Jan 15  2018 ssh_host_ecdsa_key
-rw-r--r--    1 root     root           182 Jan 15  2018 ssh_host_ecdsa_key.pub
-rw-------    1 root     root           411 Jan 15  2018 ssh_host_ed25519_key
-rw-r--r--    1 root     root           102 Jan 15  2018 ssh_host_ed25519_key.pub
-rw-------    1 root     root          1679 Jan 15  2018 ssh_host_rsa_key
-rw-r--r--    1 root     root           402 Jan 15  2018 ssh_host_rsa_key.pub

Code: Alles auswählen

cat /usr/local/etc/rc.postinit
#!/bin/sh
# S50lighttpd direkt ohne Portsperren starten
touch /var/status/startupFinished
#printf "\nwrite file: /usr/local/postinit"

Im boot.log erscheint weiterhin die Fehlermeldung (Ausschnitt)

Code: Alles auswählen

Checking for Factory Reset: not required
Checking for Backup Restore: not required
Running seedrng: OK
Initializing System: rc.postinit, timeout: can't execute '/usr/local/etc/rc.postinit': No such file or directory
OK
Setup ca-certificates: OK

Ist das bloße Ablegen der /usr/local/etc/rc.postinit mit entsprechenen Inhalt und Rechten (0755) das Einzige, oder hast Du noch mehr vorgenommen? Muss vielleicht noch irgendwo eine Konfiguration angepasst werden? In Deinem früheren Post ist zu sehen dass noch mehr in Deinem /usr/local/etc liegt.

[Baxxy]

Mehr muss nicht gemacht werden. Anlegen, ausführbar machen und den Inhalt reinschreiben. Ich gucke mir das später nochmal an.
Es gibt mehrere dieser rc.* Dateien die zu unterschiedlichen Zeitpunkten aufgerufen werden. Für den Workaround reicht die rc.postinit

[Mathias]

Die SysVars werden über Remote-Script geholt und hier klemmt irgendwas.
...
Es gibt aber keine Rückgabe und somit wird auch nichts aufgezeichnet.
Warum Historian keine Remote-Script-Rückgabe erhält kann ich nicht sagen.

@Mathias: vielleicht guckst du dir das doch mal auf einem Testsystem an.

Ich schaue mir das mal an. Nach Verbindungsfehlern sollte sich das Lesen der SysVars von alleine wieder erholen.

Gruß
Mathias

[Baxxy]

nach dem Booten von RM nach zwei Minuten nochmal gestoppt und neugestartet

Geht mit nem Script-Einzeiler:

Code: Alles auswählen

system.Exec("monit restart ccu-historian");

Dein Workaround finde ich aber etwas eleganter, bekomme ihn aber nicht zum laufen.

Lösche mal deine angelegte rc.postinit

Code: Alles auswählen

rm -f /usr/local/etc/rc.postinit

Dann ein "Einzeiler" (kopieren einfügen):

Code: Alles auswählen

echo '#!/bin/sh' >/usr/local/etc/rc.postinit && echo 'touch /var/status/startupFinished' >>/usr/local/etc/rc.postinit && echo 'printf "\nwrite file via: /usr/local/rc.postinit\n"' >>/usr/local/etc/rc.postinit && chmod 0700 /usr/local/etc/rc.postinit

Zum testen dann:

Code: Alles auswählen

/usr/local/etc/rc.postinit

Sieht bei mir so aus (ich habe sie für den Test rc.postinit2 genannt)

Code: Alles auswählen

root@RM-Test-VM-96:~# /usr/local/etc/rc.postinit2

write file via: /usr/local/rc.postinit
root@RM-Test-VM-96:~#

[snirk]

Geht mit nem Script-Einzeiler:

Code: Alles auswählen

system.Exec("monit restart ccu-historian");

Danke für den Tipp!

Code: Alles auswählen

/usr/local/etc/config/rc.d/ccu-historian restart

geht auch..

Zum testen dann:

Code: Alles auswählen

/usr/local/rc.postinit

Da hat sich der Fehlerteufel eingeschlichen, müsste heißen:

Code: Alles auswählen

/usr/local/etc/rc.postinit

Jetzt habe ich den Knackpunkt gefunden, warum meine rc.postinit nicht funktionierte. In meiner Version hatte sich als Zeilenumbruch jeweils ein CRLF eingeschlichen, in Deiner Version sind nur LF. Das mag scheinbar das System nicht.

Geändert, nun funktioniert Dein Workaround auch bei mir.

Vielen Dank für Deine Unterstützung!

[Baxxy]

Da hat sich der Fehlerteufel eingeschlichen

Danke, hab's korrigiert damit niemand drüber stolpert.

nun funktioniert Dein Workaround auch bei mir

Sehr gut.

Wenn Mathias ggf. was findet/optimiert kann/sollte der Workaround wieder entfernt werden.

[Mathias]

Die Ursache ist wohl folgende: Beim ersten Erkunden der SysVar-Datenpunkte tritt der Zugriffsfehler auf. Die Liste der SysVar-Datenpunkte im CCU-Historian ist dann leer. Es werden keine SysVars ausgelesen, auch wenn die Verbindung wieder funktioniert. Erst wenn historian.metaCycle (Standard 1 Stunde) abgelaufen ist, werden die SysVar-Datenpunkte neu erkundet und werden dann auch gelesen. Da muss ich mal überlegen, wie das verbessert werden kann.