Sporadische Programmverzögerung unerklärbar

Allgemeines zur HomeMatic Haussteuerung

Moderator: Co-Administratoren

schonwiederich
Beiträge: 52
Registriert: 07.10.2016, 13:44
Hat sich bedankt: 3 Mal
Danksagung erhalten: 1 Mal

Re: Sporadische Programmverzögerung unerklärbar

Beitrag von schonwiederich » 09.10.2021, 19:55

Hallo an alle!

1000 Dank für Eure Ideen.

Bevor ich was zu den Punkten sagen kann, möchte ich nochmal auf die Rahmenparameter hinweisen unter denen das Problem aufgetreten ist.
Meine Homematic Installation läuft seit 4 Jahren nahezu unverändert.
Seit 3 Jahren läuft sie nahezu unverändert auf RM auf einem Raspi 3b.
Bislang problemfrei. Das Problemverhalten kommt also auf keinen fall durch ein neulich hinzugefügtes Programm oder eine Funktion oder ähnliches.

@Olsmatic: Child Prozesse konnte ich keine entdecken.
Davon abgesehen das ich in CuxD nicht soooo firm bin, konnte ich nichts weiter auffälliges entdecken.

@MichaelN & @Xel66: Zum Thema externe Kommunikation:
Thema 1: Den Tip von shartelt hatte ich wie beschrieben umgesetzt und die 3 OWM Skripts deaktiviert. Abends deaktiviert. Am nächsten morgen das typische Problemverhalten. Ich schlussfolgere daraus, das es die OWM Programme nicht gewesen sind, habe sie aber immer noch inaktiv.
Thema 2: Kommunikation in Programmen nach extern. = Ich kann keine weiteren Programme finden die dies tun.
Thema 3: Kommunikation an Netzwerkgeräte:
- ein Programm sendet folgendes auf einen Tastendruck hin:

Code: Alles auswählen

string url="http://192.168.0.67:80/tm/http?JomoSchrank=1";
system.Exec("wget -q -O /dev/null '"#url#"' &");
Das Ziel auf der IP .76 ist ein Medioal Gateway. Da das Programm auf Tastendruck ist dies nicht der Fehler.
- dann ein Programm welches per knopfdruck den logitech media server auf dem NAS ansteuert.

Code: Alles auswählen

string url="http://192.168.0.11:9002/index.html?player=b8%3A27%3Aeb%3A81%3A36%3A50&p0=stop";
dom.GetObject("CUxD.CUX2801001:10.CMD_EXEC").State("wget -q -O - '"#url#"'");
Die IP .11 so wie .12 ist Lan Port 1 und 2 vom NAS.

Zum Thema:

Code: Alles auswählen

	CUX2801001:9	rmax(65535) t(7200s) p(0)
			KEY-SHORT CMD_SHORT((echo '00*'; usleep 50000) | telnet 192.168.0.12:9090 status)
Ehrlich gesagt weiß ich nicht woher der command auf Kanal 9 kommt.
Ich vermute zu wissen was er tut: Über Telnet eine Verbindung zu meinem NAS aufzubauen.
Jedoch konnte ich in keinem meiner Programme die Nutzung von Kanal 9 finden.
@g55 Wenn ich das in der Shell laufen lasse kommt unmittelbar eine Reaktion mit "verbunden".

@g55: Was meinst Du mit "vielen" CuxD commands? Ich zähle 4 (inklusive Programme vlt. 5 oder 6). Sind das schon viele?
Systeminfos zur vollen Minute? Meinst Du zu jeder vollen Minute ? Denn das Programm läuft nur alle 5 Minuten.
Was da alle 5 Minuten läuft ist :

Code: Alles auswählen

!Auslastung
dom.GetObject("CUxD.CUX2801001:1.CMD_SETS").State("cat /proc/loadavg");
dom.GetObject("CUxD.CUX2801001:1.CMD_QUERY_RET").State(1);
var x = dom.GetObject("CUxD.CUX2801001:1.CMD_RETS").State();
var eins = (x.Substr(0,4).ToFloat()*100);
var zwei = (x.Substr(5,4).ToFloat()*100);
var drei = (x.Substr(10,4).ToFloat()*100);
   
dom.GetObject("y_CCU_Ausastung_1min").State(eins);
dom.GetObject("y_CCU_Ausastung_5min").State(zwei);
dom.GetObject("y_CCU_Ausastung_15min").State(drei);


!Uptime
dom.GetObject("CUxD.CUX2801001:1.CMD_SETS").State("cat /proc/uptime");
dom.GetObject("CUxD.CUX2801001:1.CMD_QUERY_RET").State(1);
integer tmpA = dom.GetObject("CUxD.CUX2801001:1.CMD_RETS").State();
integer tmpB = tmpA.StrValueByIndex(" ",0 ) ;
tmpB=tmpB.ToInteger();

integer tmpC=tmpB/86400;
tmpB=tmpB-(tmpC*86400);
dom.GetObject("y_CCU_Uptime").State(tmpC);


!Gesamter Speicher
dom.GetObject("CUxD.CUX2801001:1.CMD_SETS").State("cat /proc/meminfo | grep 'MemTotal:'");
dom.GetObject("CUxD.CUX2801001:1.CMD_QUERY_RET").State(1);
var y = dom.GetObject("CUxD.CUX2801001:1.CMD_RETS").State();
y = y.Substr(15,12);
var vier = (y.Substr(0,6).ToFloat()/1).ToString(0)#" MB";
dom.GetObject("y_CCU_total_mem").State(vier);

!Verfügbarer Speicher
dom.GetObject("CUxD.CUX2801001:1.CMD_SETS").State("cat /proc/meminfo | grep 'MemAvailable:'");
dom.GetObject("CUxD.CUX2801001:1.CMD_QUERY_RET").State(1);
var z = dom.GetObject("CUxD.CUX2801001:1.CMD_RETS").State();
z = z.Substr(15,12);
var fuenf = (z.Substr(0,6).ToFloat()/9.94132);
dom.GetObject("y_CCU_available_mem").State(fuenf);

!Freier Speicher
dom.GetObject("CUxD.CUX2801001:1.CMD_SETS").State("cat /proc/meminfo | grep 'MemFree:'");
dom.GetObject("CUxD.CUX2801001:1.CMD_QUERY_RET").State(1);
var w = dom.GetObject("CUxD.CUX2801001:1.CMD_RETS").State();
w = w.Substr(15,12);
var sechs = (w.Substr(0,6).ToFloat()/9.94132);
dom.GetObject("y_CCU_free_mem").State(sechs);

! CPU-Temperatur Raspberry Pi3 auslesen mit vcgencmd measure_temp
string command = "/usr/bin/vcgencmd measure_temp | awk '// { printf substr($1, length($1) -5, 4)}'";
dom.GetObject ("CUxD.CUX2801001:6.CMD_SETS").State (command);
dom.GetObject ("CUxD.CUX2801001:6.CMD_QUERY_RET").State (1);
dom.GetObject ("y_CCU_CPU_Temp_Zahl").State (dom.GetObject ("CUxD.CUX2801001:6.CMD_RETS").State());
!dom.GetObject ("Temperatur Raspberry").State (dom.GetObject ("y_CCU_CPU_Temp_Zahl").Value().ToString().Substr(0,5));

!Püft ob eine neue FW Version vorhanden ist
var url = "https://gitcdn.xyz/repo/jens-maus/RaspberryMatic/master/release/LATEST-VERSION.js";
! Firmwareupdate auslesen und reagieren (c) by Alchy
dom.GetObject("CUxD.CUX2801001:1.CMD_SETS").State("cat /boot/VERSION");
dom.GetObject("CUxD.CUX2801001:1.CMD_QUERY_RET").State(1);
var sold = dom.GetObject("CUxD.CUX2801001:1.CMD_RETS").State().StrValueByIndex("=",1).Substr(0,16);
dom.GetObject("CUxD.CUX2801001:2.CMD_SETS").State("wget -q -O - '"#url#"'");
dom.GetObject("CUxD.CUX2801001:2.CMD_QUERY_RET").State(1);
var snew = dom.GetObject("CUxD.CUX2801001:2.CMD_RETS").State().StrValueByIndex("'",1);
if (sold.Find(snew) == 0)
{ dom.GetObject("CCUsysVar_Firmware_Betriebsstand").State(sold);
dom.GetObject("CCUsysVar_Firmware_verfuegbar").State(snew);
dom.GetObject("CCUsysVar_Firmware_Neue_Version_vorhanden").State(false);} 
else { dom.GetObject("CCUsysVar_Firmware_Betriebsstand").State(sold);
dom.GetObject("CCUsysVar_Firmware_verfuegbar").State(snew);
dom.GetObject("CCUsysVar_Firmware_Neue_Version_vorhanden").State(true); };

!Schreibt die Anzhal an Service und Alarmmeldungen in Systemvariablen
var AnAM = dom.GetObject(40).Value();
dom.GetObject("CCUsysVar_CCU_Alarmmeldungen").State(AnAM);
var AnSM = dom.GetObject(41).Value();
dom.GetObject("CCUsysVar_CCU_Servicemeldungen").State(AnSM);

!Schreibt Systemzeit und Datum in Variable
var obj = dom.GetObject("CCUsysVar_CCU_Systemzeit_Tag");
string datzeit = system.Date("%d.%m.%Y");
obj.State(datzeit);
Ich denke Kanale 1,2 und 6 werden von diesen Skripten entsprechend benutzt.
Ich hatte das Abholen der Versionsnummer (da skriptbasiert und auch ein CCU "Zustand") mit in das Gesamtskript von oben gepackt um die Anzahl der Programme die insgesamt in der CCU liegen nicht unnötig hochzuschrauben.
Ich vermute ich sollte diesen Teil in ein seprates Programm schieben, das nur 1 mal am Tag (in der Nacht ) läuft , oder?

Müsste ich deine Timerempfehlung dann in das Script oben mit einbauen oder auf das command des CuxD Kanals?
Laienhaft vermute ich das die skripte den Inhalt der Commands auf den Kanälen erzeugen, dann würde es ja nur Sinn machen es in den scripten zu ändern, oder?

Da alle die CCU Statuswerte in einem einzigen Programm (siehe oben) abgefragt werden, habe ich dann etwas gewonnen, diese nicht weiter zur vollen Minute alle 5 Minuten laufen zu lassen, es würde die Auswertungslast für die Skript Engine doch dann nur "verlagern" und das war zuvor auch nie ein Problem.

Die CuxD aufrufe zu deaktivieren, würde ich dann über das deaktivieren der Programme machen die auf die Kanäle zugreifen, richtig?

Das CallBack Thema müsste ich mir erstmal in ruhe ansehen........

Deinen letzten Tip "die CuXD Commands" in der Shell laufen zu lassen habe ich nicht ganz verstanden.
Soll ich die einzelnen Skripte aus dem Programm oben alle mal in der Shell laufen lassen? Geht das überhaupt? Sorry für die dumme Frage.

DANKE !!!! AN ALLE!!!

g55
Beiträge: 236
Registriert: 02.10.2018, 19:24
System: Alternative CCU (auf Basis OCCU)
Hat sich bedankt: 59 Mal
Danksagung erhalten: 11 Mal

Re: Sporadische Programmverzögerung unerklärbar

Beitrag von g55 » 09.10.2021, 21:35

ok, besten Dank für Deine Rückmeldung 8)
das alles sieht für mich jetzt wirklich kritisch aus, weil du nie weist, ob deine Geräte per wget / CUxD / system.exec auch zeitig antworten ... das Risiko, das mal eben die Nas, Gateway, OWM, RM-GIT etc. mal eben NICHT zeitig antwortet ... kaputt, reboot, update o.ä..., ist mMn. bei dir eben sehr hoch und kann dadurch auch die CCU für eine ganze Weile blockieren :roll:

aber eins nach dem anderen ... in Kürze ohne Anspruch auf Vollständigkeit :wink: :
  • Timer : nö, nicht im script. Das entsprechende Programm zum Aufruf des Scripts wäre hier interessant, z.B. das Script für die Systeminfos, das lt. deinen Angaben alle 5 min läuft. Wie sieht bitte das Programm dafür aus ? screenshot wäre hilfreich ...
  • wget : wie schon vermutet, setzt du einige wget calls ab ... was ist den, wenn deine NAS / Mediala Gateway /RM-GIT mal aus Versehen rebootet / ausfällt ? Ohne die o.g. Parameter tT steht wohl deine CCU !!, keine Programm, kein script wird mehr ausgeführt, weil auf wget gewartet wird ...
  • CUxD-CMDs : wie in deinem Script ersichtlich, wird mehrfach die Sequenz "CMD_SETS, CMD_QUERY_RET, CMD_RETS" verwendet. Lt. CUxD-Doku hast du damit nix gegenüber system.exec gewonnen. bei CMD_RETS wird jedesmal auf das Ende des Befehls gewartet, bevor überhaupt das Script oder ein anderes Programm (weiter-)laufen kann ... das halte ich aufm RPI3 für etwas "gewagt" :wink:
  • Callback : im Prinzip einfach .. statt der Sequenz "CMD_SETS, CMD_QUERY_RET, CMD_RETS" aufteilen in 2 Programme mit 2 Skripten (siehe Anhang) :
    • nur den CMD-String zusammenbasteln und per "CMD_SETS, CMD_QUERY_RET, CMD_RUNS" absenden ... btw, der cmd-string für ALLE system-Infos siht bei mir im piVCCU so aus :

      Code: Alles auswählen

      cat /sys/class/thermal/thermal_zone0/temp; cat /proc/meminfo | grep 'Mem' | awk '{printf "%s " $2}'; echo; cat /proc/loadavg | awk '{print $1*100, $2*100, $3*100}'; echo `date +%s ; date -r /run +%s ; cat /proc/uptime | awk -F. '{ print $1 }'`
    • dann 2. Programm mit Trigger auf "CMD_RETS" bei Aktualisierung, dann 2. Script zur Auswertung der Rückgabe

schonwiederich hat geschrieben:
09.10.2021, 19:55
Deinen letzten Tip "die CuXD Commands" in der Shell laufen zu lassen habe ich nicht ganz verstanden.
Soll ich die einzelnen Skripte aus dem Programm oben alle mal in der Shell laufen lassen? Geht das überhaupt?
Du siehst im CuxD doch die Kanäle mit den entsprechenden CMD-Strings. Einfach per SSH auf die CCU anmelden und den String wie z.B. "wget -q -O - 'https://gitcdn.xyz/repo/jens-maus/Raspb ... VERSION.js" per C&P laufen lassen ... kommt bestimmt sofort ein Ergebnis, oder ? ... was ist jetzt wenn das RM-GIT mal weg ist ? lösch mal ein Zeichen in der URL ... das steht, oder ? mit wget -v statt -q sieht man dann mehr ...
schonwiederich hat geschrieben:
09.10.2021, 19:55
Die CuxD aufrufe zu deaktivieren, würde ich dann über das deaktivieren der Programme machen die auf die Kanäle zugreifen, richtig?
jep, Skripte werden ja über Programme aufgerufen, also mMn. einfach das entsrechende Programm deaktivieren ...
schonwiederich hat geschrieben:
09.10.2021, 19:55
Ich vermute ich sollte diesen Teil in ein seprates Programm schieben, das nur 1 mal am Tag (in der Nacht ) läuft , oder?
sehe ich auch so. System-Infos will ich ja auch alle paar Minuten haben, jedoch ein Check auf Updates ? Muß das überhaupt sein ? Liefert RM nicht irgendwie selbst eine Meldung, wenn Updates zur Verfügung stehen ? Sorry, kann ich nicht nachvollziehen, hab ja piVCCU :wink:
Dateianhänge
CUxD-CallBack.jpg
CUxD-cmdExec.jpg
Proxmox-MiniServer (J4125, 12GB RAM, nur SSDs, Proxmox 7.4-3), RM v3.69.7.20230506, abgesetztes, altes Funkmodul HM-MOD-RPI-PCB am RB-RF-ETH, ca. 5 HM- und 107 HMIP-Geräte, Addons : CUxD v2.10.1, eMail v1.7.6, XML-API v1.22, JB-HB v6.0, ProgrammeDrucken v2.6, CCU-Historian v3.3.1

MichaelN
Beiträge: 9679
Registriert: 27.04.2020, 10:34
System: CCU
Hat sich bedankt: 700 Mal
Danksagung erhalten: 1626 Mal

Re: Sporadische Programmverzögerung unerklärbar

Beitrag von MichaelN » 09.10.2021, 21:47

Ich verstehe auch nicht, warum man alle paar Minuten System Infos ermitteln muss. Hilft das bei der Haus Automation? Oder läuft das System so instabil?
LG, Michael.

Wenn du eine App zur Bedienung brauchst, dann hast du kein Smarthome.

Wettervorhersage über AccuWeather oder OpenWeatherMap+++ Rollladensteuerung 2.0 +++ JSON-API-Ausgaben auswerten +++ undokumentierte Skript-Befehle und Debugging-Tipps +++

g55
Beiträge: 236
Registriert: 02.10.2018, 19:24
System: Alternative CCU (auf Basis OCCU)
Hat sich bedankt: 59 Mal
Danksagung erhalten: 11 Mal

Re: Sporadische Programmverzögerung unerklärbar

Beitrag von g55 » 09.10.2021, 22:59

MichaelN hat geschrieben:
09.10.2021, 21:47
Ich verstehe auch nicht, warum man alle paar Minuten System Infos ermitteln muss. Hilft das bei der Haus Automation? Oder läuft das System so instabil?
muss man auch nicht :wink: ... ist jedoch manchmal sehr hilfreich 8)
bei mir war es eben am RPi3, dass CCU-Historian RAM quasi "gefressen" hat und der RPi3 in den SWAP gelaufen ist.... "unschön" ... daher mochte ich eben die Infos im WebUI auf der Startpage haben. wie gesagt, muss nicht, aber will ich :wink:
und ja, hilft bei der Automation, denn so hab ich Infos, ob das System läuft ... oder eben "grenzwertig" ist... war bei meinem RPi3 eben der Fall.
Da ich jetzt auf RPI4 + Funkmodul per ETH umgestiegen bin, hab ich diese Probleme nimmer = System stabil 8)
Trotzdem hab ich die Infos immer noch im WebUI ... sagt mir einfach : läuft jetzt stabil :lol:

wie gesagt : muss nicht ... kann aber hilfreich sein ... sollte man nur eben mMn. per ONE script + callback + Verzögerungen so effizient wie möglich programmieren, ohne das eben andere Abläufe beeinträchtigt werden. Is eben nur eine Rega und eine Script-Engine, da muss man wohl aufpassen + genau beobachten, was so passiert / passieren kann :P
Proxmox-MiniServer (J4125, 12GB RAM, nur SSDs, Proxmox 7.4-3), RM v3.69.7.20230506, abgesetztes, altes Funkmodul HM-MOD-RPI-PCB am RB-RF-ETH, ca. 5 HM- und 107 HMIP-Geräte, Addons : CUxD v2.10.1, eMail v1.7.6, XML-API v1.22, JB-HB v6.0, ProgrammeDrucken v2.6, CCU-Historian v3.3.1

schonwiederich
Beiträge: 52
Registriert: 07.10.2016, 13:44
Hat sich bedankt: 3 Mal
Danksagung erhalten: 1 Mal

Re: Sporadische Programmverzögerung unerklärbar

Beitrag von schonwiederich » 10.10.2021, 18:38

Die Commands auf den Kanälen reagieren in der commandzeile unmitellbar.
Setze ich bei dem Befehl der Firmwareabfrage einfach ein falsches zeichen in die URL, dann wartet das system 15 sekunden und kommt dann mit einer Meldung das weiter gewartet wird.

Code: Alles auswählen

/etc/config$ (echo '00*'; usleep 50000) | telnet 192.168.0.12:9090 status
00*

Connected to 192.168.0.12:9090
/etc/config$ (echo '00*'; usleep 50000) | telnet 192.168.0.12:9090 status
00*

Connected to 192.168.0.12:9090
/etc/config$ (echo '00*'; usleep 50000) | telnet 192.168.0.12:9090 status
00*

Connected to 192.168.0.12:9090
/etc/config$ (/usr/bin/vcgencmd measure_temp | awk '// { printf substr($1, length($1) -5, 4)}')
53.7
/etc/config$ (/usr/bin/vcgencmd measure_temp | awk '// { printf substr($1, length($1) -5, 4)}')
53.7
/etc/config$ (/usr/bin/vcgencmd measure_temp | awk '// { printf substr($1, length($1) -5, 4)}')
53.2
/etc/config$ (/usr/bin/vcgencmd measure_temp | awk '// { printf substr($1, length($1) -5, 4)}')
53.7
/etc/config$ (/usr/bin/vcgencmd measure_temp | awk '// { printf substr($1, length($1) -5, 4)}')
53.2
/etc/config$ (/usr/bin/vcgencmd measure_temp | awk '// { printf substr($1, length($1) -5, 4)}')
53.7
/etc/config$ (/usr/bin/vcgencmd measure_temp | awk '// { printf substr($1, length($1) -5, 4)}')
53.7
/etc/config$ (/usr/bin/vcgencmd measure_temp | awk '// { printf substr($1, length($1) -5, 4)}')
53.7
/etc/config$ (wget -q -O - 'https://gitcdn.xyz/repo/jens-maus/RaspberryMatic/master/release/LATEST-VERSION.js')
homematic.com.setLatestVersion('3.59.6.20211009', 'HM-RASPBERRYMATIC');
/etc/config$ (wget -q -O - 'https://gitcdn.xyz/repo/jens-maus/RaspberryMatic/master/release/LATEST-VERSION.js')
homematic.com.setLatestVersion('3.59.6.20211009', 'HM-RASPBERRYMATIC');
/etc/config$ (wget -q -O - 'https://gitcdn.xyz/repo/jens-maus/RaspberryMatic/master/release/LATEST-VERSION.js')
homematic.com.setLatestVersion('3.59.6.20211009', 'HM-RASPBERRYMATIC');
/etc/config$ (echo "load tclrpc.so; puts [xmlrpc xmlrpc_bin://127.0.0.1:32001 listBidcosInterfaces ]" |tclsh)
{ADDRESS CCU2GW0001 CONNECTED 1 DEFAULT 0 DESCRIPTION {} DUTY_CYCLE 11 FIRMWARE_VERSION 1.4.1 TYPE HMLGW2} {ADDRESS PEQ0628679 CONNECTED 1 DEFAULT 1 DESCRIPTION {} DUTY_CYCLE 3 FIRMWARE_VERSION 4.2.14 TYPE CCU2}
/etc/config$ (echo "load tclrpc.so; puts [xmlrpc xmlrpc_bin://127.0.0.1:32001 listBidcosInterfaces ]" |tclsh)
{ADDRESS CCU2GW0001 CONNECTED 1 DEFAULT 0 DESCRIPTION {} DUTY_CYCLE 11 FIRMWARE_VERSION 1.4.1 TYPE HMLGW2} {ADDRESS PEQ0628679 CONNECTED 1 DEFAULT 1 DESCRIPTION {} DUTY_CYCLE 3 FIRMWARE_VERSION 4.2.14 TYPE CCU2}
/etc/config$ (echo "load tclrpc.so; puts [xmlrpc xmlrpc_bin://127.0.0.1:32001 listBidcosInterfaces ]" |tclsh)
{ADDRESS CCU2GW0001 CONNECTED 1 DEFAULT 0 DESCRIPTION {} DUTY_CYCLE 11 FIRMWARE_VERSION 1.4.1 TYPE HMLGW2} {ADDRESS PEQ0628679 CONNECTED 1 DEFAULT 1 DESCRIPTION {} DUTY_CYCLE 3 FIRMWARE_VERSION 4.2.14 TYPE CCU2}
Das ist das programm das den Sytsemzustand alle 5 Minuten holt.
PS : Die Skripte darin sind alle nicht von mir, da ich leider nicht Skripten kann.
Unbenann11t.JPG

MichaelN
Beiträge: 9679
Registriert: 27.04.2020, 10:34
System: CCU
Hat sich bedankt: 700 Mal
Danksagung erhalten: 1626 Mal

Re: Sporadische Programmverzögerung unerklärbar

Beitrag von MichaelN » 10.10.2021, 18:46

Also alles was minütlich oder 5 minütlich geschieht würde ich auf ein absolutes Minimum reduzieren. Externe Datenquellen rufe ich z.B. maximal stündlich ab. Und auch nur solange wie nötig. Windstärke aus den Wettervorhersagen z.B. nur tagsüber und nur wenn auch Beschattungsbedarf besteht (andernfalls ist die Markise eh nicht draußen)
LG, Michael.

Wenn du eine App zur Bedienung brauchst, dann hast du kein Smarthome.

Wettervorhersage über AccuWeather oder OpenWeatherMap+++ Rollladensteuerung 2.0 +++ JSON-API-Ausgaben auswerten +++ undokumentierte Skript-Befehle und Debugging-Tipps +++

Xel66
Beiträge: 14165
Registriert: 08.05.2013, 23:33
System: Alternative CCU (auf Basis OCCU)
Wohnort: Nordwürttemberg
Hat sich bedankt: 585 Mal
Danksagung erhalten: 1500 Mal

Re: Sporadische Programmverzögerung unerklärbar

Beitrag von Xel66 » 10.10.2021, 19:31

MichaelN hat geschrieben:
10.10.2021, 18:46
Windstärke aus den Wettervorhersagen z.B. nur tagsüber und nur wenn auch Beschattungsbedarf besteht (andernfalls ist die Markise eh nicht draußen)
Never ever würde ich sowas wie eine Markisensteuerung von einer Wettervorhersage aus dem möglicherweise nicht verfügbaren Internet (Server down, Internetverbindung aus irgendeinem Grund nicht verfügbar) abhängig machen. Eine Automatisierung auf Basis einer Wettervorhersage würde ich allenfalls als predictive Heizungssteuerung (lohnt es sich, vormittags zu heizen oder ist am Nachmittag mit warmen Außentemperaturen zu rechnen) oder Bedienfreigaben (sperre ich das Ausfahren der Markise im Vorfeld in Abhängigkeit der Wettervorhersage bezüglich Regen oder Wind) abbilden. Und da reichen Abfragen im Abstand mehrerer Stunden.

Für wirkliche ereignisabhängige Steuerung (Regen, Wind) geht für mich an einer zuverlässigen lokalen Wetterstation kein Weg vorbei. Am besten auch noch mit entsprechenden Direktverknüpfungen. Aber meine Wetterstation wird zwar auch von ELV vertrieben, ist aber keine Homematic. Aber die von mir benutzten Implementation betrachte ich als zuverlässig, weil die einzige Unwägbarkeit die eigene WLAN-Verbindung ist.

Und auch den Beschattungsbedarf ermittle ich lieber auf Basis der lokalen aktuellen Sonneneinstrahlung (Sonnensensor in Verbindung mit einer azimutalen Sonnenstandsberechnung), als aus einer Vorhersage.

Gruß Xel66
-------------------------------------------------------------------------------------------
524 Kanäle in 146 Geräten und 267 CUxD-Kanäle in 34 CUxD-Geräten:
343 Programme, 334 Systemvariablen und 183 Direktverknüpfungen,
RaspberryMatic Version: 3.65.11.20221005 + Testsystem: CCU2 2.61.7
-------------------------------------------------------------------------------------------
Einsteigerthread, Programmlogik-Thread, WebUI-Handbuch

MichaelN
Beiträge: 9679
Registriert: 27.04.2020, 10:34
System: CCU
Hat sich bedankt: 700 Mal
Danksagung erhalten: 1626 Mal

Re: Sporadische Programmverzögerung unerklärbar

Beitrag von MichaelN » 10.10.2021, 19:42

Xel66 hat geschrieben:
10.10.2021, 19:31
Bedienfreigaben (sperre ich das Ausfahren der Markise im Vorfeld in Abhängigkeit der Wettervorhersage bezüglich Regen oder Wind) abbilden. Und da reichen Abfragen im Abstand mehrerer Stunden.
Genauso
LG, Michael.

Wenn du eine App zur Bedienung brauchst, dann hast du kein Smarthome.

Wettervorhersage über AccuWeather oder OpenWeatherMap+++ Rollladensteuerung 2.0 +++ JSON-API-Ausgaben auswerten +++ undokumentierte Skript-Befehle und Debugging-Tipps +++

g55
Beiträge: 236
Registriert: 02.10.2018, 19:24
System: Alternative CCU (auf Basis OCCU)
Hat sich bedankt: 59 Mal
Danksagung erhalten: 11 Mal

Re: Sporadische Programmverzögerung unerklärbar

Beitrag von g55 » 11.10.2021, 21:19

@Xel66 + @MichaelN : ja, ich stimme Euch im Prinzip ja zu ... nur hilft des mMn. dem TE = @schonwiederich grad net so viel bei seinen spezifischen Programmen und eben den sporadischen Verzögerungen. Irgendwas bremst in seinen Programmen/Skripten wohl die Rega/CCU aus und das gilt es mMn. zu finden und zu eliminieren.

Ich fang mal damit an, was mir jetzt in den letzten Posts so auffällt :
schonwiederich hat geschrieben:
10.10.2021, 18:38
Setze ich bei dem Befehl der Firmwareabfrage einfach ein falsches zeichen in die URL, dann wartet das system 15 sekunden und kommt dann mit einer Meldung das weiter gewartet wird
genau das meinte ich mit Timeout/Retries : wenn der wget ins Internet mal eben nicht so funktioniert (und darauf hast du ja wenig Einfluß), dann läuft der wget eben mal locker > 15 sec und dieser Zeit passiert auf der CCU eben NICHTS... kein Programm, kein script .
Ich würde daher bei wget wie gesagt immer die Parameter für Timeout/Retries anfügen, also z.B. "wget -q" einfach durch "wget -q -T 2 -t 1" ersetzen. damit ist wohl sicher, dass der wget spätestens nach 2s beendet wird. Das Programm/script, welches die Ausgabe des wget intepretiert, muss natürlich checken, das da eben nicht die üblichen Infos kommen und entsprechend reagieren.
schonwiederich hat geschrieben:
10.10.2021, 18:38
(echo "load tclrpc.so; puts [xmlrpc xmlrpc_bin://127.0.0.1:32001 listBidcosInterfaces ]" |tclsh)
hmm.... wozu ist das eigentlich im RM nötig ? Ich hab gelesen, dass RM den DC eh schon in SVs speichert, oder ? OK, ich hab piVCCU, da hab ich so ein skript laufen, um mir eine SV mit dem DC zu versorgen. Ist das bei RM also wirklich nötig ? weiß ich nicht ...
schonwiederich hat geschrieben:
10.10.2021, 18:38
Das ist das Programm, das den Sytstemzustand alle 5 Minuten holt.
jep, hatte ich vermutet, dass du hier die Zeitsteuerung der CCU einsetzt, die geht eben immer auf die volle Minute :roll: . Oben hatte ich mein Programm mal angehängt ... Verzögerung 313s ... entzerrt das ganze bei mir zumindest...
BTW, es gibt auch im CUxD das Wrapper-Device, welches Systems-Infos im 10s-Takt holen kann 8) . hab ich mal ausprobiert, siehe Doku, S. 68 :

Code: Alles auswählen

CUX-SYSTEM:0       (Aktualisierung alle 10s)    
CUX-SYSTEM:0.CPU10 - 10s CPU load (siehe CUxD-Statusseite)
CUX-SYSTEM:0.LAVG1M - load average (1 minute)
CUX-SYSTEM:0.LAVG5M - load average (5 minuten)
CUX-SYSTEM:0.LAVG15M - load average (15 minuten)
CUX-SYSTEM:0.PROCS - Anzahl der gestarteten Prozesse
CUX-SYSTEM:0.CUXDMEM - akt. CUxD Speicherverbrauch in Bytes
CUX-SYSTEM:0.MEMUSED - CCU Speicherverbrauch in kB ohne Cache
Damit könnte man evtl. schon wesentliche Systeminfos verfügbar machen (als Datenpunkt statt SV, aber erstmal egal...). OK, die CPU-Temperatur und Version ist da jetzt nicht drin, ist halt die Frage, was man wirklich braucht / haben will und wofür ?

also meine Vorschläge an @schonwiederich wären jetzt eines nach dem anderen:
  • das (echo "load tclrpc.so; puts [xmlrpc xmlrpc_bin://127.0.0.1:32001 listBidcosInterfaces ]" |tclsh) prüfen, of das im RM für den DC in SVs überhaupt nötig ist. Vielleicht können andere, die sich mit RM besser auskennen, das evtl. kommentieren...
  • das "wget -q -T 2 -t 1" ausprobieren in scripten, die wget verwenden ... laufen lassen und sehen, ob der sproradische Fehler auftritt.
  • deine SystemInfos mal einfach abschalten, d.h. das Programm deaktivieren ... laufen lassen und sehen, ob der sproradische Fehler auftritt.
"Hope it helps"
Proxmox-MiniServer (J4125, 12GB RAM, nur SSDs, Proxmox 7.4-3), RM v3.69.7.20230506, abgesetztes, altes Funkmodul HM-MOD-RPI-PCB am RB-RF-ETH, ca. 5 HM- und 107 HMIP-Geräte, Addons : CUxD v2.10.1, eMail v1.7.6, XML-API v1.22, JB-HB v6.0, ProgrammeDrucken v2.6, CCU-Historian v3.3.1

MichaelN
Beiträge: 9679
Registriert: 27.04.2020, 10:34
System: CCU
Hat sich bedankt: 700 Mal
Danksagung erhalten: 1626 Mal

Re: Sporadische Programmverzögerung unerklärbar

Beitrag von MichaelN » 11.10.2021, 21:22

Unter RM gibt es viele Wege nativ an den DC zu kommen. Systemvariable, Datenpunkt
Das Skript ist nicht nötig.
LG, Michael.

Wenn du eine App zur Bedienung brauchst, dann hast du kein Smarthome.

Wettervorhersage über AccuWeather oder OpenWeatherMap+++ Rollladensteuerung 2.0 +++ JSON-API-Ausgaben auswerten +++ undokumentierte Skript-Befehle und Debugging-Tipps +++

Antworten

Zurück zu „HomeMatic allgemein“