EE stürzt kontinuierlich ab
Moderator: Co-Administratoren
Re: EE stürzt kontinuierlich ab
Hallo Leute,
ich kämpfe (bzw, kämpfte?) nun monatelang (über ein Jahr!) mit zahlreichen Restarts der EE - nach langwierigen Tests konnte ich die Probleme auf das Setzen von Variablen "von extern" eingrenzen (zumindest ist dies mitverantwortlich).
Die Änderung der Exec-Engine, der CCU-Firmware, oder auch der ganzen CCU brachten keinerlei Verbesserung.
Gesetzt habe ich die Variablen auf unterschiedlichste Weise, zuerst noch mit GETCCUSYSVAR, nun mit WebServer CL.
Je häufiger und je mehr Variablen ich setze, desto häufiger die Restarts - beim minütlichen Setzen von 10 Variablen war ein Restart spätestens nach 2 Tagen sicher.
Die letzten Wochen habe ich versucht zu optimieren und nur manche Variablen minütlich zu setzen, andere nur alle 5 Minuten - somit konnte ich die Restarts auf 2 / Woche reduzieren.
Alles in allem dennoch sehr unbefriedigend.
Letzte Woche hab ich mir ein Herz gefasst und bin auf Raspberrymatic umgestiegen - drei Dinge fallen hier sofort auf:
1.) deutlich geringere CPU-Auslastung (eh klar)
2.) deutlich mehr freier Speicher (ebenfalls klar)
3.) deutlich geringerer duty-cycle am Funkmodul
Ich habe nun testweise die Zyklen wieder auf minütlich gesetzt (10 Variablen) und stresse mit diversen Dingen meine Installation - ich habe nun seit 4 Tagen keinen einzigen Restart - klar noch viel zu früh eine verlässliche Aussage zu machen, dennoch steht für mich fest, dass es jedenfalls besser, wenn nicht sogar fehlerfrei läuft !
Wenn ich jetzt raten müsste tippe ich entweder auf ein timing-Problem (potentere CPU) oder - noch viel wahrscheinlicher - auf ein Memoryleak, welches aufgrund des größeren Speichers noch nicht aufgetreten ist (nach jedem EE-Restart stand wieder etwas mehr Speicher zur Verfügung).
Aber dies wurde in diesem Thread ja ohnedies bereits vermutet.
Intreressant wäre nun - ob auch andere EE-geplagte dies nachvollziehen können....
Hier ein paar Vergleichscharts (vor 13.02. CCU2, nach 17.02. Raspberry):
lg Pietro
ich kämpfe (bzw, kämpfte?) nun monatelang (über ein Jahr!) mit zahlreichen Restarts der EE - nach langwierigen Tests konnte ich die Probleme auf das Setzen von Variablen "von extern" eingrenzen (zumindest ist dies mitverantwortlich).
Die Änderung der Exec-Engine, der CCU-Firmware, oder auch der ganzen CCU brachten keinerlei Verbesserung.
Gesetzt habe ich die Variablen auf unterschiedlichste Weise, zuerst noch mit GETCCUSYSVAR, nun mit WebServer CL.
Je häufiger und je mehr Variablen ich setze, desto häufiger die Restarts - beim minütlichen Setzen von 10 Variablen war ein Restart spätestens nach 2 Tagen sicher.
Die letzten Wochen habe ich versucht zu optimieren und nur manche Variablen minütlich zu setzen, andere nur alle 5 Minuten - somit konnte ich die Restarts auf 2 / Woche reduzieren.
Alles in allem dennoch sehr unbefriedigend.
Letzte Woche hab ich mir ein Herz gefasst und bin auf Raspberrymatic umgestiegen - drei Dinge fallen hier sofort auf:
1.) deutlich geringere CPU-Auslastung (eh klar)
2.) deutlich mehr freier Speicher (ebenfalls klar)
3.) deutlich geringerer duty-cycle am Funkmodul
Ich habe nun testweise die Zyklen wieder auf minütlich gesetzt (10 Variablen) und stresse mit diversen Dingen meine Installation - ich habe nun seit 4 Tagen keinen einzigen Restart - klar noch viel zu früh eine verlässliche Aussage zu machen, dennoch steht für mich fest, dass es jedenfalls besser, wenn nicht sogar fehlerfrei läuft !
Wenn ich jetzt raten müsste tippe ich entweder auf ein timing-Problem (potentere CPU) oder - noch viel wahrscheinlicher - auf ein Memoryleak, welches aufgrund des größeren Speichers noch nicht aufgetreten ist (nach jedem EE-Restart stand wieder etwas mehr Speicher zur Verfügung).
Aber dies wurde in diesem Thread ja ohnedies bereits vermutet.
Intreressant wäre nun - ob auch andere EE-geplagte dies nachvollziehen können....
Hier ein paar Vergleichscharts (vor 13.02. CCU2, nach 17.02. Raspberry):
lg Pietro
--------------------------------------------
535 Kanäle in 130 Geräten
--------------------------------------------
535 Kanäle in 130 Geräten
--------------------------------------------
-
- Beiträge: 7151
- Registriert: 31.12.2006, 15:18
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Rhein-Main
- Danksagung erhalten: 35 Mal
Re: EE stürzt kontinuierlich ab
Hi,
Du setzt die Variablen nur über das Webserver-Interface, oder auch per xmlrpc direkt in die Exec-Engine?
Ich setze im Minutentakt bis zu 50 Variablen in HPCL über die xmlrpc-Methode per Variablenindex, und zumindest darüber kann ich nicht sagen, das es die Laufzeit verkürzt, allerdings habe ich es auch in den letzten Jahren nicht ausprobiert, die Variablen nicht von außen "reinzudrücken".
Ich werde das aber mal testen, das Raspi-WebCI zu stressen, ich fürchte nur, das es alles Tests sind, die "nichts" mit der echten Anlage zu tun haben, wo eine wahre Flut von ca. 3 Events pro Sekunde im Durchschnitt vom rfd und hs485d kommen. Und noch will ich die echte Anlage nicht auf den Raspi packen, auch wenn mich die Geschwindigkeit reizt...
Der Familienvater
Du setzt die Variablen nur über das Webserver-Interface, oder auch per xmlrpc direkt in die Exec-Engine?
Ich setze im Minutentakt bis zu 50 Variablen in HPCL über die xmlrpc-Methode per Variablenindex, und zumindest darüber kann ich nicht sagen, das es die Laufzeit verkürzt, allerdings habe ich es auch in den letzten Jahren nicht ausprobiert, die Variablen nicht von außen "reinzudrücken".
Ich werde das aber mal testen, das Raspi-WebCI zu stressen, ich fürchte nur, das es alles Tests sind, die "nichts" mit der echten Anlage zu tun haben, wo eine wahre Flut von ca. 3 Events pro Sekunde im Durchschnitt vom rfd und hs485d kommen. Und noch will ich die echte Anlage nicht auf den Raspi packen, auch wenn mich die Geschwindigkeit reizt...
Der Familienvater
Re: EE stürzt kontinuierlich ab
Ich verwende derzeit eigentlich nur den Webserver zum reinschieben und ab und an setvar zum rausschieben.
Hab da die letzten Monate aber zig Varianten durchprobiert- alle ohne maßgebliche Verbesserung.
Falls es in 1-2 Wochen immer noch keinen Restart gab, melde ich mich wieder - denn dann kann ich definitiv von einer epochalen Verbesserung sprechen.
Ich halt mir die Daumen...
Liebe Grüße Pietro
Hab da die letzten Monate aber zig Varianten durchprobiert- alle ohne maßgebliche Verbesserung.
Falls es in 1-2 Wochen immer noch keinen Restart gab, melde ich mich wieder - denn dann kann ich definitiv von einer epochalen Verbesserung sprechen.
Ich halt mir die Daumen...
Liebe Grüße Pietro
--------------------------------------------
535 Kanäle in 130 Geräten
--------------------------------------------
535 Kanäle in 130 Geräten
--------------------------------------------
-
- Beiträge: 7151
- Registriert: 31.12.2006, 15:18
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Rhein-Main
- Danksagung erhalten: 35 Mal
Re: EE stürzt kontinuierlich ab
Hi,
also ich habe mal eben die EE auf dem Raspi gequält, und 20.000 SetVarbyName-xmlrpc-Request auf die EE losgelassen, mit 1 ms Pause jedem Request, und dabei wild gemischt Ganzzahlen, Fließkomma, Zeichenketten, Zeit und Uhr-Variablen mit zufälligen Werten oder der aktuellen Uhrzeit/Datum, oder zufälligen Zeichenketten mit bis zu 75 Zeichen zugeschüttet.
In VBA, ziemlich genau so, vielleicht nicht immer schön, aber dafür selten, und ggf. schnell zusammengekloppt:
Feststellung:
Das geht echt fix!
Mit "Filterung" nur Zeichenketten-Variablen zu setzen
Dabei wächst die EE, ca. 400 kb pro Durchlauf, was ungefähr mit der Menge der gesendeten Zeichenkettenlänge übereinstimmt...
Beweis mit längeren Strings, zufällig 300 davor und zufällig 300 dahinter:
Ich wäre nicht ich , wenn ich das nicht auch mal über das CLWebI.ccc versuchen würde, sehr ähnlicher Code, wegen der Laufzeit aber nur 100 Durchgänge und keine 1000
Da scheint die Verarbeitung sauberer zu laufen, kein Wachstum feststellbar, dafür UM WELTEN langsamer, alles in allem bleibt aber die Belastung der EE im top bei max 4%, alles gut...
Da VisuWin auch über die xmlrpc-Schnittstelle der CCU geht, könnte es auch zu wachstum kommen, wenn die Visu offen ist, allerdings wird da ja deutlich öfter "gelesen", als geschrieben.
Ich gehe jetzt in Bett, bevor ich ein Schlafleck bekomme...
Der Familienvater
also ich habe mal eben die EE auf dem Raspi gequält, und 20.000 SetVarbyName-xmlrpc-Request auf die EE losgelassen, mit 1 ms Pause jedem Request, und dabei wild gemischt Ganzzahlen, Fließkomma, Zeichenketten, Zeit und Uhr-Variablen mit zufälligen Werten oder der aktuellen Uhrzeit/Datum, oder zufälligen Zeichenketten mit bis zu 75 Zeichen zugeschüttet.
In VBA, ziemlich genau so, vielleicht nicht immer schön, aber dafür selten, und ggf. schnell zusammengekloppt:
Code: Alles auswählen
Sub TestRaspiXMLRPC()
Dim Vars As Variant
Dim item As Variant
Dim result As String
Dim Host As String
Dim i As Long
Dim Counter As Long
Dim Startzeit As Date
Dim tempStr As String
Dim strLenSend As Long
Host = "rccu"
Vars = Array("TMP.LNGVAR1", "TMP.LNGVAR2", "TMP.SNGVAR10", "TMP.SNGVAR100", "TMP.SNGVAR1000", "TMP.SNGVAR20", "TMP.SNGVAR200", "TMP.SNGVAR2000", "TMP.STRTEMP", "TMP.UHRVAR", "TMP.ZEITVAR", "UNITTEST_CALLMAKRO.LNGCOUNT", "UNITTEST_CALLMAKRO.LNGTODO", "UNITTEST_RECURSE.STRSEARCHFOR", "UNITTEST_RECURSE.STRSEARCHIN", "UNITTEST_RECURSE.STRSOURCE", "UNITTEST_WRITEFILEONLY.STRDATEINAME", "UNITTEST_WRITEFILEONLY.STRFILENAME", "UNITTEST_WRITEFILEONLY.STRQUELLE", "UNITTEST_WRITEFILEONLY.STRTEMP")
Startzeit = Now
For i = 1 To 1000
For Each item In Vars
If Left(Split(item, ".")(1), 3) = "STR" Then
Select Case Left(Split(item, ".")(1), 3)
Case "LNG"
result = f_sSendRequestGetAnswer(Host, f_XMLSetVarByName(CStr(item), CLng(Rnd() * 2147000000)), 1000)
Counter = Counter + 1
Case "SNG"
result = f_sSendRequestGetAnswer(Host, f_XMLSetVarByName(CStr(item), CSng(Rnd() * 214700000#)), 1000)
Counter = Counter + 1
Case "ZEI"
result = f_sSendRequestGetAnswer(Host, f_XMLSetVarByName(CStr(item), Now), 1000)
Counter = Counter + 1
Case "STR"
tempStr = String(Rnd() * 30, "#") & CStr(Now) & String(Rnd() * 30, "#")
strLenSend = strLenSend + Len(tempStr)
result = f_sSendRequestGetAnswer(Host, f_XMLSetVarByName(CStr(item), tempStr), 1000)
Counter = Counter + 1
Case "UHR"
result = f_sSendRequestGetAnswer(Host, f_XMLSetVarByName(CStr(item), Format(Now, "hh:mm:ss")), 1000)
Counter = Counter + 1
Case Else
Debug.Print item
End Select
End If
Sleep 1
DoEvents
'Debug.Print result
'f_XMLSetVarByName
Next
Debug.Print Now & ": " & i & ". Runde, Requests: " & Counter
Next
Debug.Print DateDiff("s", Startzeit, Now) & " Sekunden für " & Counter & " Requests, strLenSend=" & strLenSend
End Sub
' Die Hilfsfunktionen
Public Function f_sSendRequestGetAnswer(Host As String, postData As String, Optional Timeout_ms As Long = 15000, Optional Port As Long = 2110) As String
Dim winHttpReq As New WinHttp.WinHttpRequest
'Debug.Print postData
winHttpReq.SetTimeouts 1000, 2000, 2000, Timeout_ms
winHttpReq.Open "POST", "http://" & Host & ":" & Port & "/RPC2", False
winHttpReq.SetRequestHeader "Content-Type", "text/xml"
winHttpReq.Send (postData)
f_sSendRequestGetAnswer = winHttpReq.ResponseText
Set winHttpReq = Nothing
'Debug.Print f_sSendRequestGetAnswer
End Function
Public Function f_XMLSetVarByName(Varname As String, Value As Variant) As String
f_XMLSetVarByName = _
"<?xml version=""1.0""?>" & vbCrLf & _
"<methodCall>" & vbCrLf & _
" <methodName>setvarbyname</methodName>" & vbCrLf & _
" <params>" & vbCrLf & _
" <param>" & vbCrLf & _
" <value><string>" & Varname & IIf(Len(CStr(Value)) > 0, "=" & IIf(TypeName(Value) = "String", """ & Value & """, Value), "") & "</string></value>" & vbCrLf & _
" </param>" & vbCrLf & _
" </params>" & vbCrLf & _
"</methodCall>"
End Function
Das geht echt fix!
Mit "Filterung" nur Zeichenketten-Variablen zu setzen
Code: Alles auswählen
26 Sekunden für 8000 Requests, strLenSend=392248
rccu:~ # grep "VmRSS" /proc/`pidof ExecEngine`/status|cut -d':' -f2|xa
rgs|cut -d' ' -f1|xargs
5904
rccu:~ # grep "VmRSS" /proc/`pidof ExecEngine`/status|cut -d':' -f2|xa
rgs|cut -d' ' -f1|xargs
6372
rccu:~ #
Beweis mit längeren Strings, zufällig 300 davor und zufällig 300 dahinter:
Code: Alles auswählen
28 Sekunden für 8000 Requests, strLenSend=2559580
rccu:~ # grep "VmRSS" /proc/`pidof ExecEngine`/status|cut -d':' -f2|xa
rgs|cut -d' ' -f1|xargs
6372
rccu:~ # grep "VmRSS" /proc/`pidof ExecEngine`/status|cut -d':' -f2|xa
rgs|cut -d' ' -f1|xargs
8944
Code: Alles auswählen
159 Sekunden für 800 Requests, strLenSend=252652
rccu:~ # grep "VmRSS" /proc/`pidof ExecEngine`/status|cut -d':' -f2|xa
rgs|cut -d' ' -f1|xargs
8944
rccu:~ # grep "VmRSS" /proc/`pidof ExecEngine`/status|cut -d':' -f2|xa
rgs|cut -d' ' -f1|xargs
8944
Da VisuWin auch über die xmlrpc-Schnittstelle der CCU geht, könnte es auch zu wachstum kommen, wenn die Visu offen ist, allerdings wird da ja deutlich öfter "gelesen", als geschrieben.
Ich gehe jetzt in Bett, bevor ich ein Schlafleck bekomme...
Der Familienvater
-
- Beiträge: 9118
- Registriert: 17.11.2012, 10:47
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Köln
- Hat sich bedankt: 37 Mal
- Danksagung erhalten: 286 Mal
Re: EE stürzt kontinuierlich ab
Hi,
Da lief ~ eine Woche absolut nichts ala Get und Set CCU und trotzdem schmierte die EE laufend ab.
Aber auch du schreibst als langjähriger HPCL-User von 'über ein Jahr'.
Das ist in etwa der Zeitpunkt, seitdem mir dies auch verstärkt auffällt.
Und soooo viel Neues ist bei mir in dem Jahr nicht hinzu gekommen.
Was ich aber eventuell am kommenden WE einmal testen werde:
RasperryMatic --> da gibt es eine spezielle EE-Anpassung.
Ist logisch, wobei ich das nicht nachvollziehen könnte:Pietro hat geschrieben:1.) deutlich geringere CPU-Auslastung (eh klar)
2.) deutlich mehr freier Speicher (ebenfalls klar)
Pietro hat geschrieben:3.) deutlich geringerer duty-cycle am Funkmodul
Hatte ich ein paar Seiten vorher bereits - für mich - ausschließen können.Pietro hat geschrieben:Intreressant wäre nun - ob auch andere EE-geplagte dies nachvollziehen können....
Da lief ~ eine Woche absolut nichts ala Get und Set CCU und trotzdem schmierte die EE laufend ab.
Aber auch du schreibst als langjähriger HPCL-User von 'über ein Jahr'.
Das ist in etwa der Zeitpunkt, seitdem mir dies auch verstärkt auffällt.
Und soooo viel Neues ist bei mir in dem Jahr nicht hinzu gekommen.
Predige ich dir seit Jahren.Familienvater hat geschrieben:Feststellung:Das geht echt fix!
Was ich aber eventuell am kommenden WE einmal testen werde:
RasperryMatic --> da gibt es eine spezielle EE-Anpassung.
Gruß Günter
pivccx mit 3.xx in Produktiv und Testsystem mit HM-, HM-W, HMIP- und HMIP-W Geräten, HPCx Studio 4.1,
L-Gateways, RS-L-Gateways, HAP, Drap, FHZ200x, vereinzelt noch FS2x-Komponenten.
HM / HM-IP: Zur Zeit knapp 300 Komponenten mit ??? Kanälen .
Ich übernehme für alle von mir gegebenen Hinweise, Tipps und Links keine Haftung! Das Befolgen meiner Tipps ist nur für Fachkundige gedacht und erfolgt auf eigene Gefahr!
pivccx mit 3.xx in Produktiv und Testsystem mit HM-, HM-W, HMIP- und HMIP-W Geräten, HPCx Studio 4.1,
L-Gateways, RS-L-Gateways, HAP, Drap, FHZ200x, vereinzelt noch FS2x-Komponenten.
HM / HM-IP: Zur Zeit knapp 300 Komponenten mit ??? Kanälen .
Ich übernehme für alle von mir gegebenen Hinweise, Tipps und Links keine Haftung! Das Befolgen meiner Tipps ist nur für Fachkundige gedacht und erfolgt auf eigene Gefahr!
-
- Beiträge: 7151
- Registriert: 31.12.2006, 15:18
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Rhein-Main
- Danksagung erhalten: 35 Mal
Re: EE stürzt kontinuierlich ab
Hi,
Der Familienvater
Das ging da weniger um die Raspi-Performance an sich, mehr um den Vergleich CLWebI-Performance zu xmlrpc. Mal schauen, ob ich mal Zeit finde, das mini-Raspi-Projekt auf die Ersatz-CCU2 zu packen, und dort die EE mit dem gleichen Zeug zu bombardieren, dann hat man mal den Vergleich, wie schnell CCU2 und Raspi sind.Daimler hat geschrieben:Predige ich dir seit Jahren.Familienvater hat geschrieben:Feststellung:Das geht echt fix!
Der Familienvater
-
- Beiträge: 9118
- Registriert: 17.11.2012, 10:47
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Köln
- Hat sich bedankt: 37 Mal
- Danksagung erhalten: 286 Mal
Re: EE stürzt kontinuierlich ab
Hi,
na dann haben wir ja beide etwas zu tun.
Wobei ich das mit dem 'kommenden WE' natürlich gaaaaanz schnell wieder zurück ziehe.
Kölle Alaaf.
na dann haben wir ja beide etwas zu tun.
Wobei ich das mit dem 'kommenden WE' natürlich gaaaaanz schnell wieder zurück ziehe.
Kölle Alaaf.
Gruß Günter
pivccx mit 3.xx in Produktiv und Testsystem mit HM-, HM-W, HMIP- und HMIP-W Geräten, HPCx Studio 4.1,
L-Gateways, RS-L-Gateways, HAP, Drap, FHZ200x, vereinzelt noch FS2x-Komponenten.
HM / HM-IP: Zur Zeit knapp 300 Komponenten mit ??? Kanälen .
Ich übernehme für alle von mir gegebenen Hinweise, Tipps und Links keine Haftung! Das Befolgen meiner Tipps ist nur für Fachkundige gedacht und erfolgt auf eigene Gefahr!
pivccx mit 3.xx in Produktiv und Testsystem mit HM-, HM-W, HMIP- und HMIP-W Geräten, HPCx Studio 4.1,
L-Gateways, RS-L-Gateways, HAP, Drap, FHZ200x, vereinzelt noch FS2x-Komponenten.
HM / HM-IP: Zur Zeit knapp 300 Komponenten mit ??? Kanälen .
Ich übernehme für alle von mir gegebenen Hinweise, Tipps und Links keine Haftung! Das Befolgen meiner Tipps ist nur für Fachkundige gedacht und erfolgt auf eigene Gefahr!
-
- Beiträge: 7151
- Registriert: 31.12.2006, 15:18
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Rhein-Main
- Danksagung erhalten: 35 Mal
Re: EE stürzt kontinuierlich ab
Hi,
also auch über CLWebI.ccc steigt der Speicherplatzbedarf der EE, meine Füllzeichen waren wohl schlecht gewählt, und Leerzeichen sollten bei Zeichenketten über CLWebI.ccc besser auch keine Enthalten sein.
Intern schreibt der Webserver einfach nur den Request um, und packt ihn in ein setvarbyname-xmlrpc-Call und schickt diesen an die EE (wusste gar nicht, das man mit tcpdump unter Linux auch das loopback-Interface belauschen kann, unter Win geht das nicht so einfach...).
Grundsätzlich kann man wohl festhalten:
CLWebI.ccc eignet sich eher, um seltener mal eben schnell ein paar Zahlenwerte oder "einfache" Zustände (ohne Leer/Sonderzeichen) zu setzen, mit Zeit-Werten wird es schon schwierig, weil die URL %-codiert werden muss, und der CLWebI.ccc sich nicht um die deCodierung kümmert, da wird dann versucht 20.02.2017%2011:00:08 per xmlrpc in die Zeitvariable zu drücken und aus der URL
wird
Was dazu führt, das in der Zeit-Variablen nachher 20.02.2017 20:01:00 steht.
Zeichenketten, mit Leerstellen oder codierungspflichtigen Zeichen können über CLWebI.ccc nicht gesetzt werden.
Ich habe RK heute morgen "nebenbei" darauf hingewiesen, das es ein Speicherproblem im xmlrpc geben könnte, mal schauen, wann ich was dazu von ihm höre.
Grundsätzlich ist es aber dann egal, ob es über xmlrpc geht, oder über CLWebI.ccc, oder auch über ExecCmd.exe, alles landet im xmlrpc, und verursacht aktuell (kleine) Probleme, und ich fürchte, eine laufende Visu verursacht aktuell auch (kleine) Probleme, die sich der Laufzeit zu größeren Problemen werden können. Wenn die grundsätzliche xmlrpc-Implementierung Probleme macht, dann verursacht ggf. auch jedes einzelne Event der CCU, was vom rfd oder hs485d kommt, ein (kleines) Problem, was sich auch wieder mit der Masse der Events zu einem großen Problem wird.
Der Familienvater
also auch über CLWebI.ccc steigt der Speicherplatzbedarf der EE, meine Füllzeichen waren wohl schlecht gewählt, und Leerzeichen sollten bei Zeichenketten über CLWebI.ccc besser auch keine Enthalten sein.
Intern schreibt der Webserver einfach nur den Request um, und packt ihn in ein setvarbyname-xmlrpc-Call und schickt diesen an die EE (wusste gar nicht, das man mit tcpdump unter Linux auch das loopback-Interface belauschen kann, unter Win geht das nicht so einfach...).
Grundsätzlich kann man wohl festhalten:
CLWebI.ccc eignet sich eher, um seltener mal eben schnell ein paar Zahlenwerte oder "einfache" Zustände (ohne Leer/Sonderzeichen) zu setzen, mit Zeit-Werten wird es schon schwierig, weil die URL %-codiert werden muss, und der CLWebI.ccc sich nicht um die deCodierung kümmert, da wird dann versucht 20.02.2017%2011:00:08 per xmlrpc in die Zeitvariable zu drücken und aus der URL
Code: Alles auswählen
http://rccu/addons/contronics/CLWebI.ccc?SETVARBYNAME&TMP.ZEITVAR=20.02.2017 11:00:08;
Code: Alles auswählen
<?xml version="1.0" encoding="UTF-8"?>
<methodCall>
<methodName>setvarbyname</methodName>
<params>
<param>
<value>TMP.ZEITVAR=20.02.2017%2011:00:08;</value>
</param>
</params>
</methodCall>
Zeichenketten, mit Leerstellen oder codierungspflichtigen Zeichen können über CLWebI.ccc nicht gesetzt werden.
Ich habe RK heute morgen "nebenbei" darauf hingewiesen, das es ein Speicherproblem im xmlrpc geben könnte, mal schauen, wann ich was dazu von ihm höre.
Grundsätzlich ist es aber dann egal, ob es über xmlrpc geht, oder über CLWebI.ccc, oder auch über ExecCmd.exe, alles landet im xmlrpc, und verursacht aktuell (kleine) Probleme, und ich fürchte, eine laufende Visu verursacht aktuell auch (kleine) Probleme, die sich der Laufzeit zu größeren Problemen werden können. Wenn die grundsätzliche xmlrpc-Implementierung Probleme macht, dann verursacht ggf. auch jedes einzelne Event der CCU, was vom rfd oder hs485d kommt, ein (kleines) Problem, was sich auch wieder mit der Masse der Events zu einem großen Problem wird.
Der Familienvater
-
- Beiträge: 9118
- Registriert: 17.11.2012, 10:47
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Köln
- Hat sich bedankt: 37 Mal
- Danksagung erhalten: 286 Mal
Re: EE stürzt kontinuierlich ab
Hi,
jetzt wird das einfache Abschmieren der EE aber langsam äußerst kompliziert.
Fakt bei mir:
Keine sets und gets, kein xml, kein tcl, kein clweb und die Visu ist ausschließlich temporär geöffnet --> Datt Dingen schmiert trotzdem ab.
Einzig die Zustände bestimmter Variablen / Sensoren schreibe ich wie Udo alle 10 Minuten in eine Datei (nicht über Allewerte ), welche ich per Init beim Neustart wieder einlese.
Ausserdem lasse ich diverse Schaltvorgänge und Sensorwerte (bei Änderung) in unterschiedliche Textfiles schreiben.
Aber auch hier könnte ich einmal die Zeitspanne erhöhen bzw. ausschalten.
Allerdings mit der Vermutung, dass auch dies nicht zum Ziel einer nicht mehr abschmierendenn EE führen wird.
jetzt wird das einfache Abschmieren der EE aber langsam äußerst kompliziert.
Fakt bei mir:
Keine sets und gets, kein xml, kein tcl, kein clweb und die Visu ist ausschließlich temporär geöffnet --> Datt Dingen schmiert trotzdem ab.
Einzig die Zustände bestimmter Variablen / Sensoren schreibe ich wie Udo alle 10 Minuten in eine Datei (nicht über Allewerte ), welche ich per Init beim Neustart wieder einlese.
Ausserdem lasse ich diverse Schaltvorgänge und Sensorwerte (bei Änderung) in unterschiedliche Textfiles schreiben.
Aber auch hier könnte ich einmal die Zeitspanne erhöhen bzw. ausschalten.
Allerdings mit der Vermutung, dass auch dies nicht zum Ziel einer nicht mehr abschmierendenn EE führen wird.
Gruß Günter
pivccx mit 3.xx in Produktiv und Testsystem mit HM-, HM-W, HMIP- und HMIP-W Geräten, HPCx Studio 4.1,
L-Gateways, RS-L-Gateways, HAP, Drap, FHZ200x, vereinzelt noch FS2x-Komponenten.
HM / HM-IP: Zur Zeit knapp 300 Komponenten mit ??? Kanälen .
Ich übernehme für alle von mir gegebenen Hinweise, Tipps und Links keine Haftung! Das Befolgen meiner Tipps ist nur für Fachkundige gedacht und erfolgt auf eigene Gefahr!
pivccx mit 3.xx in Produktiv und Testsystem mit HM-, HM-W, HMIP- und HMIP-W Geräten, HPCx Studio 4.1,
L-Gateways, RS-L-Gateways, HAP, Drap, FHZ200x, vereinzelt noch FS2x-Komponenten.
HM / HM-IP: Zur Zeit knapp 300 Komponenten mit ??? Kanälen .
Ich übernehme für alle von mir gegebenen Hinweise, Tipps und Links keine Haftung! Das Befolgen meiner Tipps ist nur für Fachkundige gedacht und erfolgt auf eigene Gefahr!