eq3loop: eq3loop_write_master() return error: -14
Moderatoren: jmaus, Co-Administratoren
-
- Beiträge: 3034
- Registriert: 28.01.2016, 18:06
- System: CCU
- Wohnort: Hürth
- Hat sich bedankt: 16 Mal
- Danksagung erhalten: 274 Mal
Re: eq3loop: eq3loop_write_master() return error: -14
Hi!
Das werde ich mit Sicherheit nicht machen.
Der Fehler tritt nur in Zusammenhang mit dem RPC-Adapter von iOBroker auf, alle anderen getesteten Fremdsysteme mit derselben Funktion erzeugen dieses Problem bei mir nicht. Daher schließe ich die CCU als eigentlichen Verursacher aus. Es steht außer Frage, dass es durch irgendeine bestimmte Konstellation kommen muss, aber wäre die CCU hier die Ursache, müsste durch Historian und HomeAssistant dasselbe passieren und das tut es eben nicht.
Gruß,
Gerti
Das werde ich mit Sicherheit nicht machen.
Der Fehler tritt nur in Zusammenhang mit dem RPC-Adapter von iOBroker auf, alle anderen getesteten Fremdsysteme mit derselben Funktion erzeugen dieses Problem bei mir nicht. Daher schließe ich die CCU als eigentlichen Verursacher aus. Es steht außer Frage, dass es durch irgendeine bestimmte Konstellation kommen muss, aber wäre die CCU hier die Ursache, müsste durch Historian und HomeAssistant dasselbe passieren und das tut es eben nicht.
Gruß,
Gerti
Re: eq3loop: eq3loop_write_master() return error: -14
Guten Abend Zusammen,
mal wieder ein Update von meiner Seite mit einer sehr interessanten Beobachtung.
Auch wenn es nicht wirklich hilft, kontrolliere ich noch einmal täglich die Speicherauslastung meiner CCU. Wie bisher steigt die Speicherauslastung jeden Tag zwischen 0,5-1,0% an, so dass bei den 4GB RAM welche zur Verfügung stehen, die CCU bei ca. 30% Gesamtauslastung mit dem hier bekannten Fehler ausfällt, wobei ca. 23% auf den HMIPserver Dienst entfallen.
So weit so gut, nichts neues.
Bei der Kontrolle heute morgen auch nichts aufälliges. Gesamtauslastung lag bei 23,5% nach 16T20h Betrieb.
Heute Mittag erhalte ich eine Vielzahl an Fehlermeldungen, gucke nach und siehe da, ohne Absturz oder anderen Auffälligkeiten die Speicherauslastung ist runter auf 13,5% insgesamt bzw. 7,2% für den HMIPserver. Das ist in etwa die Auslastung nach einem Neustart und wenn sich die CCU beruhigt hat.
Selbst nach nunmehr 6 Stunden scheint die CCU stabil zu sein und die Speicherauslastung unverändert.
Es wäre zu schön, wenn von Geisterhand das Problem dauerhaft verschwunden wäre, in etwa so wie es gekommen ist. Aber noch ist es definitiv zu früh um sich zu freuen.
Warten wir mal!
Wer sich jetzt fragt welche Fehlermeldungen. Was ich aus den Logs lesen kann ist nicht viel. Was mir jedoch aufgefallen ist, dass in den Fehlermeldungen der Code (UniqueID) der Cloudmatic drinnen steht. Über Cloudmatic haben wir hier in diesem Zusammenhang bisher noch nicht gesprochen. Aber wer weiß. Cloudmatic funktionierte im Zusammenspiel mit der CCU die ganze Zeit.
Gruss Mutze
mal wieder ein Update von meiner Seite mit einer sehr interessanten Beobachtung.
Auch wenn es nicht wirklich hilft, kontrolliere ich noch einmal täglich die Speicherauslastung meiner CCU. Wie bisher steigt die Speicherauslastung jeden Tag zwischen 0,5-1,0% an, so dass bei den 4GB RAM welche zur Verfügung stehen, die CCU bei ca. 30% Gesamtauslastung mit dem hier bekannten Fehler ausfällt, wobei ca. 23% auf den HMIPserver Dienst entfallen.
So weit so gut, nichts neues.
Bei der Kontrolle heute morgen auch nichts aufälliges. Gesamtauslastung lag bei 23,5% nach 16T20h Betrieb.
Heute Mittag erhalte ich eine Vielzahl an Fehlermeldungen, gucke nach und siehe da, ohne Absturz oder anderen Auffälligkeiten die Speicherauslastung ist runter auf 13,5% insgesamt bzw. 7,2% für den HMIPserver. Das ist in etwa die Auslastung nach einem Neustart und wenn sich die CCU beruhigt hat.
Selbst nach nunmehr 6 Stunden scheint die CCU stabil zu sein und die Speicherauslastung unverändert.
Es wäre zu schön, wenn von Geisterhand das Problem dauerhaft verschwunden wäre, in etwa so wie es gekommen ist. Aber noch ist es definitiv zu früh um sich zu freuen.
Warten wir mal!
Wer sich jetzt fragt welche Fehlermeldungen. Was ich aus den Logs lesen kann ist nicht viel. Was mir jedoch aufgefallen ist, dass in den Fehlermeldungen der Code (UniqueID) der Cloudmatic drinnen steht. Über Cloudmatic haben wir hier in diesem Zusammenhang bisher noch nicht gesprochen. Aber wer weiß. Cloudmatic funktionierte im Zusammenspiel mit der CCU die ganze Zeit.
Gruss Mutze
-
- Beiträge: 3034
- Registriert: 28.01.2016, 18:06
- System: CCU
- Wohnort: Hürth
- Hat sich bedankt: 16 Mal
- Danksagung erhalten: 274 Mal
Re: eq3loop: eq3loop_write_master() return error: -14
Hi,
hast du iobroker laufen?
Wenn ja, schalte mal den rpc Adapter ab und starte dann die CCU neu.
Ich bin mir ziemlich sicher, dass Dein Problem dann behoben ist und es würde meine Beobachtung bestätigen, dass der Adapter irgendwas anders macht, als die anderen Brokersysteme, mit denen es das Problem nicht gibt.
Gruß
Gerti
hast du iobroker laufen?
Wenn ja, schalte mal den rpc Adapter ab und starte dann die CCU neu.
Ich bin mir ziemlich sicher, dass Dein Problem dann behoben ist und es würde meine Beobachtung bestätigen, dass der Adapter irgendwas anders macht, als die anderen Brokersysteme, mit denen es das Problem nicht gibt.
Gruß
Gerti
Re: eq3loop: eq3loop_write_master() return error: -14
Hi Gerti,
ja, ich habe den ioBroker am Laufen und habe dieses Thema hier im Februar aufgemacht.
Daher wundert mich ja auch das Verhalten. Ich hatte die Verbindung zum ioBroker bereits deaktiviert und die Speicherauslastung war unauffällig.
Ich teile Deine Meinung, dass es mit dem Adapter von ioBroker zusammenhängt.
Allerdings scheint wie von Geisterhand das Problem (zumindestens temporär) seit gestern Mttag verschwunden zu sein.
Wie geschrieben, die Speicherauslastung ist von jetzt auf gleich deutlich gesunken und seit gestern absolut stabil.
Ich beobachte das jetzt noch ein paar Tage und dann starte ich die CCU mal durch.
Btw. ioBroker Adapter ist seit dem letzten Neustart der CCU permanent verbunden.
Gruss Mutze
ja, ich habe den ioBroker am Laufen und habe dieses Thema hier im Februar aufgemacht.
Daher wundert mich ja auch das Verhalten. Ich hatte die Verbindung zum ioBroker bereits deaktiviert und die Speicherauslastung war unauffällig.
Ich teile Deine Meinung, dass es mit dem Adapter von ioBroker zusammenhängt.
Allerdings scheint wie von Geisterhand das Problem (zumindestens temporär) seit gestern Mttag verschwunden zu sein.
Wie geschrieben, die Speicherauslastung ist von jetzt auf gleich deutlich gesunken und seit gestern absolut stabil.
Ich beobachte das jetzt noch ein paar Tage und dann starte ich die CCU mal durch.
Btw. ioBroker Adapter ist seit dem letzten Neustart der CCU permanent verbunden.
Gruss Mutze
-
- Beiträge: 3034
- Registriert: 28.01.2016, 18:06
- System: CCU
- Wohnort: Hürth
- Hat sich bedankt: 16 Mal
- Danksagung erhalten: 274 Mal
Re: eq3loop: eq3loop_write_master() return error: -14
Hi!
Wenn im Rega-Adapter das Polling aktiv ist, dann kommt im Logfile (alles loggen) der CCU alle 30 Sekunden 130x folgende Zeile:
Ich frage mich gerade, woher das kommt.
Habe dazu auch im Forum und Google gesucht, bin aber nicht schlau daraus geworden.
Gruß,
Gerti
Wenn im Rega-Adapter das Polling aktiv ist, dann kommt im Logfile (alles loggen) der CCU alle 30 Sekunden 130x folgende Zeile:
Code: Alles auswählen
Jul 27 19:21:45 192.168.2.30 ReGaHss: Info: metadata property 'VALUE_LIST' does not exist [GetValueListProperty():iseDOMdp.cpp:425]
Habe dazu auch im Forum und Google gesucht, bin aber nicht schlau daraus geworden.
Gruß,
Gerti
-
- Beiträge: 12115
- Registriert: 20.11.2016, 20:01
- Hat sich bedankt: 848 Mal
- Danksagung erhalten: 2150 Mal
- Kontaktdaten:
Re: eq3loop: eq3loop_write_master() return error: -14
Je nachdem welches Skript fürs Polling genutzt wird (kenne mich da in ioBroker nicht aus) entweder von
https://github.com/ioBroker/ioBroker.hm ... Inv.fn#L34
oder von
https://github.com/ioBroker/ioBroker.hm ... ing.fn#L29
Den Methodenaufruf
Code: Alles auswählen
oSysVar.ValueList();
Code: Alles auswählen
if (iValueType == 16) { sValueList = oSysVar.ValueList(); }
Code: Alles auswählen
var oSysVarVL = oSysVar.MetaData("VALUE_LIST");
if (oSysVarVL) { sValueList = oSysVar.ValueList(); }
Aber ist ja auch nur eine Rega "Info"-Meldung...
-
- Beiträge: 3034
- Registriert: 28.01.2016, 18:06
- System: CCU
- Wohnort: Hürth
- Hat sich bedankt: 16 Mal
- Danksagung erhalten: 274 Mal
Re: eq3loop: eq3loop_write_master() return error: -14
Hi,
danke für den Hinweis.
Das es nur eine Info ist, habe ich schon gesehen, trotzdem könnte man es korrigieren.
Ich mache mal einen Change Request dazu auf.
Im Prinzip würde es ja reichen, die Zeile einfach in den Block für die Wertelisten zu verschieben.
Gruß
Gerti
danke für den Hinweis.
Das es nur eine Info ist, habe ich schon gesehen, trotzdem könnte man es korrigieren.
Ich mache mal einen Change Request dazu auf.
Im Prinzip würde es ja reichen, die Zeile einfach in den Block für die Wertelisten zu verschieben.
Gruß
Gerti
Re: eq3loop: eq3loop_write_master() return error: -14
Hallo,
ich möchte hier noch einmal eine finale Rückmeldung zu dem von mir geöffneten Problem abgeben, damit andere Leidtragende nicht die Hoffnung verlieren.
Nach nunmehr gut 2 Monaten kann ich berichten, dass das Problem nicht mehr auftritt. So plötzlich das Problem Ende Januar d. J. aufgetreten ist, so ist das Problem offensichtlich Anfang August d. J. wieder verschwunden. Zu diesem Zeitpunkt habe ich die Speicherauslastung vom HMserver eng überwacht und ohne ersichtlichen Grund ist die Speicherauslastung nach einem vorherigen kontinuierlichen Anstieg auf ein normales Maß gefallen und seitdem dort verblieben. Bedeutet, seit diesem Zeitpunkt belegt der HMserver im Durchschnitt 7% meiner CCU (Raspberry mit 4GB).
Seit diesem Zeitpunkt habe ich mehrere Fware Updates gefahren, die Zentrale neugestartet, Geräte an- und abgelernt und weitere normale Anpassungen vorgenommen. All diese Änderungen haben keinen Einfluss auf die Stabilität der CCU.
An dem grundsätzlichen Set-up, also CCU und auf einem gesonderten Raspberry den ioBroker und den CCU-Historian sind keine Änderungen erfolgt.
Erklären kann ich das alles natürlich nicht und es bleibt eine gewisse Unsicherheit, aber aktuell läuft das gesamte Set-up wie es soll und ich bin zufrieden.
Allen die mit einem vergleichbaren Problem zu kämpfen haben, wünsche ich die gleiche glückliche "plötzliche Heilung" des Problems.
Gruss
Mutze
ich möchte hier noch einmal eine finale Rückmeldung zu dem von mir geöffneten Problem abgeben, damit andere Leidtragende nicht die Hoffnung verlieren.
Nach nunmehr gut 2 Monaten kann ich berichten, dass das Problem nicht mehr auftritt. So plötzlich das Problem Ende Januar d. J. aufgetreten ist, so ist das Problem offensichtlich Anfang August d. J. wieder verschwunden. Zu diesem Zeitpunkt habe ich die Speicherauslastung vom HMserver eng überwacht und ohne ersichtlichen Grund ist die Speicherauslastung nach einem vorherigen kontinuierlichen Anstieg auf ein normales Maß gefallen und seitdem dort verblieben. Bedeutet, seit diesem Zeitpunkt belegt der HMserver im Durchschnitt 7% meiner CCU (Raspberry mit 4GB).
Seit diesem Zeitpunkt habe ich mehrere Fware Updates gefahren, die Zentrale neugestartet, Geräte an- und abgelernt und weitere normale Anpassungen vorgenommen. All diese Änderungen haben keinen Einfluss auf die Stabilität der CCU.
An dem grundsätzlichen Set-up, also CCU und auf einem gesonderten Raspberry den ioBroker und den CCU-Historian sind keine Änderungen erfolgt.
Erklären kann ich das alles natürlich nicht und es bleibt eine gewisse Unsicherheit, aber aktuell läuft das gesamte Set-up wie es soll und ich bin zufrieden.
Allen die mit einem vergleichbaren Problem zu kämpfen haben, wünsche ich die gleiche glückliche "plötzliche Heilung" des Problems.
Gruss
Mutze