Gelöst! CCU Historian 1.2.0 auf QNAP-Nas P419+ nicht stabil ? - DOCH läuft!

Das Langzeitarchiv für HomeMatic

Moderator: Co-Administratoren

Antworten
Matthes
Beiträge: 89
Registriert: 20.03.2016, 16:47

Gelöst! CCU Historian 1.2.0 auf QNAP-Nas P419+ nicht stabil ? - DOCH läuft!

Beitrag von Matthes » 23.06.2018, 13:07

Hallo Zusammen,

seit einiger Zeit versuche ich, den CCU-Historian Version 1.2.0 auf meinem NAS QNAP P419+ stabil ans Laufen zu bekommen. Dazu habe ich eine Anleitung im Netz gefunden, mit der ich es auch schaffe, dass CCU-Historian beim Starten des NAS mit startet und dann auch einige Tage läuft. Aber irgendwann – in unregelmäßigen Zeitabständen – läuft CCU-Historian nicht mehr. Ich merke das dann daran, dass die Website mit den Datenpunkten nicht mehr erreichbar ist.

Wenn ich dann den NAS neu starte, läuft es wieder einige Zeit, aber eben nicht zuverlässig.

Ein manueller Start mit PUTTY ist machbar, aber wenn ich das PUTTY-Fenster schließe, ist der CCU-Historian auch sofort wieder beendet. Das sollte aber eigentlich nicht sein.
So wie ich gelesen habe, sollte ein manuell gestarteter Prozess mit „ &“ am Ende der Befehlszeile auch nach beendet von PUTTY weiterlaufen. Funktioniert hier leider nicht.

Leider habe ich von Linux in jedweder Form keine Ahnung, ich kann hier nur gelesenes nachstellen.

Mein Aufruf in der „autorun.sh“ betrifft nur den CCU-Historian. Ich habe diese Datei erst anlegen müssen. Weiterhin habe ich JAVA erst installieren müssen.
Der Inhalt der autorun.sh lautet:

Code: Alles auswählen

cd /share/MD0_DATA/CCU-Historian/
sleep 180
/share/MD0_DATA/.qpkg/JRE_ARM/jre/bin/java -Duser.timezone=Europe/Berlin -jar /share/MD0_DATA/CCU-Historian/ccu-historian.jar &
Wie gesagt, das läuft auch. Der CCU-Historian wird zunächst gestartet, läuft einige Tage und ist dann plötzlich weg.

Den CCU-Historian dann manuell starten versuche ich mit dem Aufruf über eine Datei namens „ccu-historian-start.sh“, die ich in dem Freigabeordner abgelegt habe.

Der Inhalt der Datei „ccu-histrorian-start.sh“ lautet:

Code: Alles auswählen

cd /share/MD0_DATA/CCU-Historian
/share/MD0_DATA/.qpkg/JRE_ARM/jre/bin/java -Duser.timezone=Europe/Berlin -jar /share/MD0_DATA/CCU-Historian/ccu-historian.jar &
Starte ich damit, läuft der CCU-Historian trotz des Parameters „ &“ nur solange, wie auf dem Windows7 – PC das Putty-Fenster offen bleibt. Das verstehe ich auch schon mal nicht.

Hier ist mal der Inhalt meiner ccu-historian.config Datei:

Code: Alles auswählen

// CCU-Historian Konfiguration
// 
// Hinweise:
// Kommentarzeilen starten mit zwei Schrägstrichen (//). Alle Zeichen nach den Schrägstrichen
// werden ignoriert. Zeichenketten als Optionswert müssen von einfachen Anführungszeichen (')
// umschlossen sein. Weitere Informationen sind auch im Abschnitt 3 des Handbuchs zu finden.
//
// Liste der zur Verfügung stehen Konfigurationsoptionen mit ihren jeweiligen Standardwerten:
//
// logSystem.consoleLevel=Level.INFO
// logSystem.fileLevel=Level.INFO
logSystem.fileLevel=Level.FINEST
logSystem.fileName='./ccu-historian-%g.log'
logSystem.fileLimit=1000000
// logSystem.fileCount=5
logSystem.fileCount=500
//logSystem.binRpcLevel=Level.WARNING
logSystem.binRpcLevel=Level.FINER
// database.dir='./data'
// database.name='history'
// database.user='sa'
// database.password='ccu-historian'
// database.backup=''
database.webEnable=true
database.webPort=8082
database.webAllowOthers=true
// database.tcpEnable=false
// database.tcpPort=9092
// database.tcpAllowOthers=false
database.pgEnable=true
database.pgPort=5435
database.pgAllowOthers=true
// webServer.port=80
webServer.port=81
// webServer.dir='./webapp'
// webServer.logLevel=Level.WARNING
// webServer.historianAddress=''
webServer.historianAddress='10.88.14.10'
// webServer.trendDesigns ... (s.a. Abschnitt 7.4.1 im Handbuch)
// webServer.apiKeys=[]
// webServer.menuLinks ... (s.a. Abschnitt 4.4 im Handbuch)
// historian.metaCycle=3600000 // 1 Stunde
// historian.bufferCount=5000
// historian.bufferTime=0 
// devices.historianBinRpcPort=2099
// devices.historianXmlRpcPort=2098
// devices.historianAddress=null // eigene IP-Adresse automatisch ermitteln
// 
// Für jede Zentrale bzw. jedes Gerät müssen folgende zwei Optionen gesetzt werden
// (s.a. Abschnitt 3.2 im Handbuch):
// devices.device<Nr.>.type=<CCU1, CCU2 oder BINRPC> 
// devices.device<Nr.>.address='<IP-Adresse>'
//
// Optional können noch folgende Optionen gesetzt werden:
// devices.device<Nr.>.plugin<Nr.>.type=<CUXD oder HMWLGW>
// devices.device<Nr.>.sysVarDataCycle=30000
// devices.device<Nr.>.reinitTimeout=300000
// devices.device<Nr.>.writeAccess=false
// devices.device<Nr.>.watchdogProgram=''
// devices.device<Nr.>.watchdogCycle=300000 // 5 Minuten
// Bei Anbindung von mehreren Zentralen muss ein Präfix je Zantrale gesetzt werden!
// devices.device<Nr.>.prefix=''
//
// Es muss im Folgenden mindestens eine Zentrale bzw. Gerät konfiguriert werden:

// Typ der Zentrale: CCU1 oder CCU2
devices.device1.type=CCU2
// IP-Adresse der Zentrale
devices.device1.address='10.88.14.200'

// Falls CUxD verwendet wird, die Kommentarzeichen (//) vor folgender Zeile entfernen:
devices.device1.plugin1.type=CUXD

// Falls das HomeMatic Wired LAN Gateway verwendet wird, die Kommentarzeichen (//) vor 
// folgender Zeile entfernen:
// devices.device1.plugin1.type=HMWLGW

// Falls CUxD UND das HMWLGW verwendet wird, die Kommentarzeichen (//) vor folgenden
// zwei Zeilen entfernen:
// devices.device1.plugin1.type=CUXD
// devices.device1.plugin2.type=HMWLGW

// Zum Freischalten der Web-Links zu den Beispiel-Web-Seiten, die Kommentarzeichen (//) vor folgenden
// zwei Zeilen entfernen:
// webServer.menuLinks.link1.text='Beispiel 1 - Vorjahresvergleich'
// webServer.menuLinks.link1.address='/custom/example1.html'
Die log-Datei vom 15.06.2018 - dem Tage des letzten Beendens stelle ich hier mal ein:

Code: Alles auswählen

2018-06-15 00:07:41|FINE   |Sending method result: 
2018-06-15 00:07:41|FINE   |Sending method result: [, , , ]
2018-06-15 00:07:41|FINER  |Database: Getting data point with id BidCos-RF.NEQ1639084:4.PARTY_START_YEAR
2018-06-15 00:07:41|FINE   |Database: Inserting (Fri Jun 15 00:07:41 CEST 2018, 0, 2) into D_BIDCOS_RF_NEQ1639084_4_PARTY_START_YEAR
2018-06-15 00:07:41|FINER  |Database: Getting data point with id BidCos-RF.NEQ1639084:4.PARTY_STOP_TIME
2018-06-15 00:07:41|FINE   |Database: Inserting (Fri Jun 15 00:07:41 CEST 2018, 0, 2) into D_BIDCOS_RF_NEQ1639084_4_PARTY_STOP_TIME
2018-06-15 00:07:41|FINER  |Database: Getting data point with id BidCos-RF.NEQ1639084:4.PARTY_STOP_DAY
2018-06-15 00:07:41|FINE   |Database: Inserting (Fri Jun 15 00:07:41 CEST 2018, 1, 2) into D_BIDCOS_RF_NEQ1639084_4_PARTY_STOP_DAY
2018-06-15 00:07:41|FINER  |Database: Getting data point with id BidCos-RF.NEQ1639084:4.PARTY_STOP_MONTH
2018-06-15 00:07:41|FINE   |Database: Inserting (Fri Jun 15 00:07:41 CEST 2018, 1, 2) into D_BIDCOS_RF_NEQ1639084_4_PARTY_STOP_MONTH
2018-06-15 00:07:41|FINER  |Database: Getting data point with id BidCos-RF.NEQ1639084:4.PARTY_STOP_YEAR
2018-06-15 00:07:41|FINE   |Database: Inserting (Fri Jun 15 00:07:41 CEST 2018, 0, 2) into D_BIDCOS_RF_NEQ1639084_4_PARTY_STOP_YEAR
2018-06-15 00:07:41|FINE   |Call of method 'system.multicall' received with parameters [[[methodName:event, params:[BidCos-RF, MEQ1552261:4, CONTROL_MODE, 1]], [methodName:event, params:[BidCos-RF, MEQ1552261:4, FAULT_REPORTING, 0]], [methodName:event, params:[BidCos-RF, MEQ1552261:4, BATTERY_STATE, 2.2999999970197678]], [methodName:event, params:[BidCos-RF, MEQ1552261:4, VALVE_STATE, 0]], [methodName:event, params:[BidCos-RF, MEQ1552261:4, BOOST_STATE, 0]], [methodName:event, params:[BidCos-RF, MEQ1552261:4, ACTUAL_TEMPERATURE, 18.299999982118607]], [methodName:event, params:[BidCos-RF, MEQ1552261:4, SET_TEMPERATURE, 4.5]], [methodName:event, params:[BidCos-RF, MEQ1552261:4, PARTY_TEMPERATURE, 5.0]], [methodName:event, params:[BidCos-RF, MEQ1552261:4, PARTY_START_TIME, 0]], [methodName:event, params:[BidCos-RF, MEQ1552261:4, PARTY_START_DAY, 1]], [methodName:event, params:[BidCos-RF, MEQ1552261:4, PARTY_START_MONTH, 1]], [methodName:event, params:[BidCos-RF, MEQ1552261:4, PARTY_START_YEAR, 0]], [methodName:event, params:[BidCos-RF, MEQ1552261:4, PARTY_STOP_TIME, 0]], [methodName:event, params:[BidCos-RF, MEQ1552261:4, PARTY_STOP_DAY, 1]], [methodName:event, params:[BidCos-RF, MEQ1552261:4, PARTY_STOP_MONTH, 1]], [methodName:event, params:[BidCos-RF, MEQ1552261:4, PARTY_STOP_YEAR, 0]]]]
2018-06-15 00:07:41|FINE   |Call of method 'event' received with parameters [BidCos-RF, MEQ1552261:4, CONTROL_MODE, 1]
2018-06-15 00:07:41|FINER  |Event received: BidCos-RF.MEQ1552261:4.CONTROL_MODE, Fri Jun 15 00:07:41 CEST 2018, 1, 2
2018-06-15 00:07:41|FINER  |Database: Getting data point with id BidCos-RF.MEQ1552261:4.CONTROL_MODE
2018-06-15 00:07:41|FINE   |Database: Inserting (Fri Jun 15 00:07:41 CEST 2018, 1, 2) into D_BIDCOS_RF_MEQ1552261_4_CONTROL_MODE
2018-06-15 00:07:41|FINE   |Sending method result: 
2018-06-15 00:07:41|FINE   |Call of method 'event' received with parameters [BidCos-RF, MEQ1552261:4, FAULT_REPORTING, 0]
2018-06-15 00:07:41|FINER  |Event received: BidCos-RF.MEQ1552261:4.FAULT_REPORTING, Fri Jun 15 00:07:41 CEST 2018, 0, 2
2018-06-15 00:07:41|FINE   |Sending method result: 
2018-06-15 00:07:41|FINE   |Call of method 'event' received with parameters [BidCos-RF, MEQ1552261:4, BATTERY_STATE, 2.2999999970197678]
2018-06-15 00:07:41|FINER  |Event received: BidCos-RF.MEQ1552261:4.BATTERY_STATE, Fri Jun 15 00:07:41 CEST 2018, 2.2999999970197678, 2
2018-06-15 00:07:41|FINE   |Sending method result: 
2018-06-15 00:07:41|FINE   |Call of method 'event' received with parameters [BidCos-RF, MEQ1552261:4, VALVE_STATE, 0]
2018-06-15 00:07:41|FINER  |Event received: BidCos-RF.MEQ1552261:4.VALVE_STATE, Fri Jun 15 00:07:41 CEST 2018, 0, 2
2018-06-15 00:07:41|FINE   |Sending method result: 
2018-06-15 00:07:41|FINE   |Call of method 'event' received with parameters [BidCos-RF, MEQ1552261:4, BOOST_STATE, 0]
2018-06-15 00:07:41|FINER  |Event received: BidCos-RF.MEQ1552261:4.BOOST_STATE, Fri Jun 15 00:07:41 CEST 2018, 0, 2 
Sollten weitere log-Infos erforderlich sein, stelle ich diese gern zur Verfügung.

Was mich auch irritiert ist, dass der CCU-Historian sich anscheinend nicht automatisch neu startet, wenn er weg ist. Gibt es dafür evtl. eine Einstellung in der Config, die ich noch nicht kenne?

Gibt es eine Möglichkeit, den CCU-Historian auf den QNAP NAS P419+ stabil ans Laufen zu bekommen?

Über Hilfe würde ich mich sehr freuen.

Grüße aus dem Sauerland
Matthes
Zuletzt geändert von Matthes am 14.07.2018, 14:56, insgesamt 1-mal geändert.

NickHM
Beiträge: 1625
Registriert: 23.09.2017, 12:04

Re: CCU Historian 1.2.0 auf QNAP-Nas P419+ nicht stabil

Beitrag von NickHM » 23.06.2018, 13:50

hallo

meine bescheidenen Linux Kenntnisse sagen, dass ein angehängtes "&" dafür sorgt, dass der Prozess in den Hintergrund geschoben wird und Du wieder auf der Konsole arbeiten kannst. Ohne & siehst Du ja nur die Log Ausgaben von Historian.
Trotzdem läuft auch der Prozess im Hintergrund im Kontext des Users, der über Putty angemeldet ist. Putty weg, User weg, Prozess weg.

Ist das das Ende des logfiles vor dem Neustart? Ich sehe da nichts Aussergewöhnliches.

Wie viel Speicher hat das NAS? Ich hatte auf einem Synology das Problem, das Historian mit der zeit den RAM voll gemüllt hat (Java). Du könntest auf dem NAS mal den RAM Verbrauch des Prozesses beobachten. Vielleicht ist da das Problem und das Betriebssystem killt dann den Prozess.
Abhilfe schafft ein Parameter beim Start von Historian, der den Ram Verbrauch beschränkt.
Entweder mal im Handbuch nachlesen, im Forum suchen oder Mathias direkt fragen.

Mathias
Beiträge: 798
Registriert: 03.11.2010, 11:25
Wohnort: Aachen
Kontaktdaten:

Re: CCU Historian 1.2.0 auf QNAP-Nas P419+ nicht stabil

Beitrag von Mathias » 23.06.2018, 22:47

In der Konfigurationsdatei und in der Log-Datei kann ich auch nichts ungewöhnliches finden. Gibt es etwas im Syslog des QNAP zu diesem Zeitpunkt zu finden?

Unter Linux kannst Du mit dem Befehl nohup verhindern, dass ein Befehl beim Schließen der Konsole mit beendet wird.

Gruß
Mathias

Matthes
Beiträge: 89
Registriert: 20.03.2016, 16:47

Re: CCU Historian 1.2.0 auf QNAP-Nas P419+ nicht stabil

Beitrag von Matthes » 24.06.2018, 17:30

Hallo,

vielen Dank für die Rückmeldungen. Zunächst habe ich mal in die Startdatei „ccu-histrorian-start.sh“ den Befehl "nohup" vorangestellt. Danke für den Hinweis.

Den CCU-Historian habe ich gestern durch einen Neustart des NAS mit neu gestartet. Momentan läuft er noch.

Mein NAS hat 503MB nutzbaren RAM.
die Übersicht zeigt aktuell:

CPU-Auslastung 24 %
Gesamtspeicher 503 MB
Freier Speicher 111,96 MB

Somit also - denke ich - alles OK.

Ich werde das jetzt beobachten und wenn sich der CCU-Historian wieder beendet, die LOG-Datei vom CCU-Historian und dem NAS selbst mal prüfen. und die Auslastung danach feststellen.

Vielen Dank also bis hierhin,
ich melde mich, wenn ich neue Erkenntnisse habe.

Eine Frage ist aber noch offen:
Wenn der CCU-Historian sich selbst "wodurchauchimmer" beendet, gibt es eine Möglichkeit, dass das erkannt wird und der CCU-Historian automatisch neu gestartet wird?
Gibt es dafür einen Parameter in der Config oder kann man das mit einem Guardian unter Linux auf dem NAS realisieren?

Unter Windows kenne ich solche Möglichkeiten, die ich selbst in meinen Programmierungen unter VB6 auch schon eingesetzt habe.

Vielleicht kennt sich hier jemand in Linux entsprechend gut aus und kann mir einen Tipp geben.

Grüße aus dem Sauerland
Matthes

NickHM
Beiträge: 1625
Registriert: 23.09.2017, 12:04

Re: CCU Historian 1.2.0 auf QNAP-Nas P419+ nicht stabil

Beitrag von NickHM » 25.06.2018, 09:44

Hallo

das hatte ich vergessen zu schreiben, da immer mehr als ein Punkt zu beantworten ist :)

Wenn ein Prozess abstürzt dann kann er nicht mehr selbst darauf reagieren, da er tot ist :)
Die Funktion des Watchdog muss also von aussen kommen.
Und da musst Du mal im Linux Bereich suchen, ob es da entsprechende Möglichkeiten des Betriebssystems oder externe Tools gibt.

Bei mir sieht das so aus, dass ich manuell regelmäßig eine Historian Grafik abrufe und daran (leider entsprechend verspätet) merke, wenn Historian nicht mehr läuft. Seit dem ich von meinem NAS zurück auf einen extra Raspi gezogen bin, gibt es allerdings keine Probleme mehr.
Sicherlich könnte man eine Historian Seite automatisch mit einem Tool abfragen und wenn nicht die erwünschte Antwort kommt zumindest eine Benachrichtigung generieren.

Mathias
Beiträge: 798
Registriert: 03.11.2010, 11:25
Wohnort: Aachen
Kontaktdaten:

Re: CCU Historian 1.2.0 auf QNAP-Nas P419+ nicht stabil

Beitrag von Mathias » 26.06.2018, 07:05

Matthes hat geschrieben:Wenn der CCU-Historian sich selbst "wodurchauchimmer" beendet, gibt es eine Möglichkeit, dass das erkannt wird
Ja, die gibt es: Siehe Abschnitt 2.4 "Überwachung" in der Dokumentation. Wenn der CCU-Historian nicht mehr läuft, wird eine Alarmvariable in der CCU gesetzt.
Matthes hat geschrieben:und der CCU-Historian automatisch neu gestartet wird?
Da musst Du Dir etwas selber bauen.

Gruß
Mathias

Matthes
Beiträge: 89
Registriert: 20.03.2016, 16:47

Re: CCU Historian 1.2.0 auf QNAP-Nas P419+ nicht stabil

Beitrag von Matthes » 14.07.2018, 11:42

Hallo zusammen,

sorry, dass meine Rückmeldung doch etwas länger gedauert hat. Ich hatte viel zu tun, Termine außer Haus und einen PC-Chrasch.
Nun läuft aber alles wieder.

Bzgl. CCU Historien 1.2.0 auf meinem NAS kann ich erstmal sagen, dass es grundsätzlich stabil läuft. Wenn der Prozess mal nicht mehr läuft, hat es nachvollziehbar immer Netzwerkprobleme aus Sicht des NAS gegeben, dass der die CCU ni9cht mehr gesehen hat. z.B. Neustart der Fritz-Box wegen Firmware-Update oder DLS Ausfall (ja, gab es auch mal) usw.

Der Historian läuft stabil.

Mein NAS ist aber bzgl. Arbeitsspeicher und Prozessorauslastung dann schon so beschäftigt, dass ich die ISCSI-LUN zurückgenommen habe und eine größere SSD nun in meinem PC habe. Das war aber auch erst mit den neuen PC aufgefallen.

Noch keine Lösung habe ich für den Neustart des Historian bei laufendem NAS. Momentan behelfe ich mir mit einem kompletten Neustart des NAS, wenn der Historian mal nicht mehr läuft. Daran arbeite ich noch. Dazu habe ich gelesen, dass der Befehl "bash" dafür sorgen soll, dass das Beenden von Putty überlebt wird. "bash" hat mein NAS ni9cht von Hause aus, muss ich also nachinstallieren.

Wenn dafür eine Lösung habe, werde ich diese hier posten, braucht aber noch etwas Zeit, weil ich beruflich gerade sehr eingespannt bin.

Matthes
Beiträge: 89
Registriert: 20.03.2016, 16:47

Re: CCU Historian 1.2.0 auf QNAP-Nas P419+ nicht stabil

Beitrag von Matthes » 14.07.2018, 11:57

Wie kann ich eigentlich den Titel des Threats ändern? die Behauptung der Historian sei auf dem NAS nicht stabil ist ja widerlegt. ich würde gerne zumindest ein Fragezeichen anhängen und ggf. ein "Gelöst" davor.

Evtl. könnte das auch ein Moderator für mich netter Weise übernehmen?
Vielen Dank.

Grüße aus dem Sauerland
Matthes

NickHM
Beiträge: 1625
Registriert: 23.09.2017, 12:04

Re: CCU Historian 1.2.0 auf QNAP-Nas P419+ nicht stabil

Beitrag von NickHM » 14.07.2018, 13:17

Hallo

- Titel -> Du editierst einfach den Betreff Deines ersten Beitrages

- Neustart Historian
Historian wird beim Start des NAS über ein S99... Script gestartet ? Dann sollte ein Script benutzt werden, dass Parameter verarbeiten kann. S99... .sh start / stop / restart
Innerhalb des Scriptes wird der Parameter geprüft und eine Liste von Befehlen ausgeführt.
man kann das natürlich auch in Einzelschritten auf der Kommandozeile selbst machen

Herausfinden wie die PID (Prozess ID) von Historian lautet
mit kill "PID" den Prozess beenden
Historian neu starten

Ach ja, da wat ja das Problem. Wenn dann Putty beendet wird, läuft historian auch nicht mehr :(
Da hilft aber nicht "bash", denn das ist IMHO nur der Name für einen Kommandointerpreter.
Der entscheidende Befehl lautet viel mehr "nohub" oder "screen" (muss nachinstalliert werden)

Code: Alles auswählen

screen [Befehl/Programmname]
aufgerufen, um einen angegebenen Befehl oder das Programm in einer neuen Instanz von Screen zu starten. Wenn nun die Verbindung abbricht, läuft Screen im Hintergrund weiter, und nach einer erneuten Anmeldung kann man Screen mit dem Befehl

screen -x
wieder in den Vordergrund der neuen Shell holen. Die darin laufenden Prozesse bekommen davon nichts mit und laufen einfach weiter. Falls mehrere Instanzen von Screen laufen, dann zeigt der Befehl eine Liste mit IDs an, und der Befehl

screen -r [ID]
holt die gewünschte Instanz ins Terminal. Um eine Screen-Instanz auf Kommando in den Hintergrund zu verschieben, gibt es die Tastenkombination Strg-A, gefolgt von D.

Matthes
Beiträge: 89
Registriert: 20.03.2016, 16:47

Re: Gelöst! CCU Historian 1.2.0 auf QNAP-Nas P419+ nicht stabil ? - DOCH läuft!

Beitrag von Matthes » 14.07.2018, 15:01

Hallo NickHM,

vielen Dank. Titel ist geändert.

Dass der zu nutzende Befehlt Nohup heißt, habe ich inzwischen googeln können. Auch dass der Befehl nachinstalliert werden muss. Danke für die Info.

Das ist aber nicht so einfach da gibt es zig Suchergebnisse, die sich teilweise widersprechen und unterschiedliche Ansätze haben. Da bin ich noch nicht weiter und der Frust steigt.

OK, da suche ich mal weiter und mache dann ein eigenes Thema dafür auf, das hat ja mit der Lauffähigkeit des CCU-Historian auf einem QNAP Nas nicht direkt zu tun.

Vielen Dank noch mal.

Grüße aus dem Sauerland
Matthes

Antworten

Zurück zu „CCU-Historian“