Sporadische Programmverzögerung unerklärbar

[g55]

Unter RM gibt es viele Wege nativ an den DC zu kommen. Systemvariable, Datenpunkt

Danke. Bitte genauer : welche da wären ? Hab ich auch nicht grad aufm Schirm, da ich RM (noch) nicht einsetze ... Interessiert mich persönlich auch ... Vielleicht helfen etwas genauere Infos auch dem TE hier weiter, um die Anzahl der "suspekten", evtl. unnötigen Skripte zu reduzieren ...

[MichaelN]

Es existiert ganz schlicht eine Systemvariable "DutyCycle". Und man kann auch einen Datenpunkt des CCU Gerätes verwenden. Was aber gar nicht notwendig ist, da die systemvariable automatisch aktualisiert wird.

[Xel66]

@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.

Ich lehne mich mal weit aus dem Fenster und behaupte, in 9,9 von 10 Fällen sind sporadische Verzögerungen auf hängende Scripte für externe Abfragen zurückzuführen. Es hilft eben nur, genau diese externen Kommunikationen abzuschalten und ggf. so zu gestalten, dass sie nicht zu Verzögerungen führen. Reine WebUI-Programme verursachen solche Hänger im Allgemeinen (und Speziellen) nicht. Es ist ausschließlich auf Scripting sowie URL-Aufrufe in CUxD-Geräten zurückzuführen. Nicht umsonst bin ich gegenüber exzessivem Scripting (gerade wenn es um externe Kommunikation geht oder dem "Ersatz" von dem System innewohnende Funktionalitäten) so kritisch.

Und die Ursachen für Verzögerungen sind fast immer gleich gelagert. Der angefragte Server ist nicht erreichbar. Und die Gründe hierfür können vielfältig sein und die überwiegende Anzahl liegt nicht im Einflussbereich des Anwenders. Kann man für die Erreichbarkeit lokaler Geräte (Hue-Bridge, Shelly etc.) für deren Steuerung URL-Aufrufe notwendig sind noch selbst sorgen, sieht die Angelegenheit bei externen Servern schon anders aus. Als Ursachen kommen da von Wartungsarbeiten oder Ausfall des Servers, des Internetanschlusses, des Routers, des ISP oder irgendeines Rechners auf der Strecke dazwischen oder einfach auch nur Änderungen an der Webseite oder API des Servers alles Mögliche infrage. Solange sich aus extern abgefragten Servern noch irgendetwas für die CCU-Automation ableiten lässt, ist das Vorgehen noch nachvollziehbar. Geht es aber z.B. um die Abfrage von Spritpreisen, mit denen die CCU absolut nichts anfangen kann, wird es absolut grenzwertig.

Auch wenn externe Kommunikation grundsätzlich funktioniert, ist die Firmware der CCU einfach nicht für die externe Kommunikation gedacht. Die einzige Scriptengine (auf die auch die Programme zurückgreifen) arbeitet strikt seriell (arbeitet alle Befehle nacheinander ab) und kann eben nicht mal einen Thread warten lassen und woanders weitermachen. Und darum hängt es dann. Nun kann man systemnahe Befehle durch Anfügen eines kaufmännischen & in den Hintergrund schicken. Das funktioniert aber eben nur mit Fire&Forget-Aufrufen, bei denen keine Antworten des Servers innerhalb des Scripts verarbeitet und in Systemvariablen geschrieben werden müssen. Beispiele hierfür wären da Steuerbefehle an Shellys oder der Push-Versand usw. Bei der Abfrage von Internetservern (z.B. Wetterdienste) müssen aber Systemvariablen beschrieben werden. Sowas könnte man grundsätzlich auch per TCL machen und die entsprechenden Scripte im Hintergrund durch das embedded-Linux-Grundsystem ausführen lassen, die dann die Systemvariablen mit den entsprechenden Inhalten füllen. Aber die Standardvorgehensweise ist eben die Benutzung der ReGa-Scriptsprache. Und das ist das Grundproblem.

Vielleicht helfen etwas genauere Infos auch dem TE hier weiter, um die Anzahl der "suspekten", evtl. unnötigen Skripte zu reduzieren ...

Diese Scripte kann man aber nicht per Forum identifizieren, sondern nur, wenn man direkt vor dem System sitzt und eben die Programme und Geräte analysiert. Und da ist es relativ einfach, alles was nach URL-Aufruf aussieht ist erst mal suspekt und bedarf einer Begutachtung. Ich würde dazu das Programme-Drucken-Addon benutzen und von allen Programmen einen Ausdruck als PDF erstellen und diesen dann durchsuchen. Dann kann man sich noch ggf. eingerichtete CUxD-Geräte, die einen URL-Aufruf tätigen, anschauen. Aber bis auf die Geräte CUX2801001:2 und ...:9 scheint da nichts dabei zu sein, wobei das auch durch Scriptaufrufe dynamisch geändert werden kann und so nicht ersichtlich ist. Es ist nur auffälllig, das die URL die durch das CUX2801001:9-Gerät aufgerufen wird, aus einem fremden Adressbereich zu stammen scheint.

Gruß Xel66

[g55]

ch lehne mich mal weit aus dem Fenster und behaupte, in 9,9 von 10 Fällen sind sporadische Verzögerungen auf hängende Scripte für externe Abfragen zurückzuführen.

wie gesagt, da sind wir uns hier ja wohl einig. Die CCU ist nicht dafür ausgelegt. Die Unwägbarkeiten, wie du schreibst "Wartungsarbeiten oder Ausfall des Servers, des Internetanschlusses, des Routers, des ISP oder irgendeines Rechners auf der Strecke dazwischen oder einfach auch nur Änderungen an der Webseite oder API des Servers alles Mögliche". Daher sag ich ja, mach die wget-Anfragen "proper" mit "-T 2 -t 1" o.ä.. dann geht es auch.

Es existiert ganz schlicht eine Systemvariable "DutyCycle". Und man kann auch einen Datenpunkt des CCU Gerätes verwenden. Was aber gar nicht notwendig ist, da die systemvariable automatisch aktualisiert wird.

ok+Danke, und was is jedoch mit LAN-Gateways/HAPs in RM ? gibt es da auch entsprechende SVs/DPs für die Konfiguration des TE ? soweit ich das sehe, hat der TE auch Gateways ?

[Xel66]

Daher sag ich ja, mach die wget-Anfragen "proper" mit "-T 2 -t 1" o.ä.. dann geht es auch.

So einfach ist es leider nicht. Wenn Du fire&forget-Aufrufe (z.B. Schaltbefehle und Push) damit machst, dann funktioniert das prima. Verarbeitest Du aber Antworten des Servers (braucht man für Wetterdienstabfragen), dann kommt diese Empfehlung an ihre Grenzen. Da geht das nämlich nicht mehr.

Gruß Xel66

[g55]

Verarbeitest Du aber Antworten des Servers (braucht man für Wetterdienstabfragen), dann kommt diese Empfehlung an ihre Grenzen. Da geht das nämlich nicht mehr.

Nein, das geht auch. Man sollte eben im verarbeitenden Skript/Programm oder was auch immer eben die Validität der Daten auch bitteschön prüfen. Kommt da nix, dann eben ENDE, evtl. mit Fehlermeldung, ansonsten Auswerten der Daten. Ich prüfe im meinen Skripten immer, ob a) überhaupt Daten ankommen und b) ob diese valide sind.
Sich darauf verlassen, dass IMMER was Valides ankommt, ist mMn. blauäugig und führt eben zu solchen "Blinkereffekten" wie beim TE ... funktioniert ja, aber eben nicht immer

[Xel66]

Nein, das geht auch.

Man kann die Rückgabe aus einer Abfrage in einem im "Hintergund" laufenden wget-Abfrage innerhalb eines ReGa-Scripts ohne Script-Hänger verarbeiten? Das wäre mir neu. Kann mir auch nicht vorstellen wie das funktionieren soll, denn das Script muss ja auf das Ergebnis der Abfrage warten, um damit weiterzuarbeiten. Soll mir aber auch egal sein, ich habe beschlossen, solche Sachen zu meiden. Allerdings habe ich noch eine einzige Leiche im Keller (G**gl*-Kalenderabfrage). Das werde ich demnächst auch auf meine Tasker-Lösung umstellen, die ich hier vor ewigen Zeiten schon mal vorgestellt habe. Ansonsten nutze ich extern nur fire&forget-Aufrufe (Push, TTS). Intern frage ich noch meine Haustür-Cam ab. Dieses habe ich aber zusätzlich mit einer Ping-Device-Abfrage abgesichert und so etwas entschärft. Alles andere verbuche ich unter Restrisiko.

Aber Rückgaben auf Validität zu prüfen sollte jedem geläufig sein, der weiß was Code-Injection ist und welche Gefahren damit verbunden sind. Nun wird nicht unbedingt jemand eine CCU über diesen Weg angreifen (dazu ist das zu speziell und zu wenig zu holen), aber sie unbeabsichtigt zu destabilisieren ist durchaus drin. Die Firmware kommt ja schon ins Straucheln, wenn man HTML-Code in einer Systemvariable ablegt und diese Variable auf der Startseite anzeigen lässt (oder ist das inzwischen gefixt?).

Gruß Xel66

[g55]

Man kann die Rückgabe aus einer Abfrage in einem im "Hintergund" laufenden wget-Abfrage innerhalb eines ReGa-Scripts ohne Script-Hänger verarbeiten? Das wäre mir neu. Kann mir auch nicht vorstellen wie das funktionieren soll, denn das Script muss ja auf das Ergebnis der Abfrage warten, um damit weiterzuarbeiten.

Klar geht das, hatte ich ja schon in meinem Post geschrieben, Stichwort "CallBack".
Steht in der CUxD-Doku 2.6 auf Seite 108 :

"Soll nach einem Befehl mit längerer Laufzeit eine weitere Aktion ausgeführt werden, dann
würde bei Anwendung des CMD_RETS bzw. CMD_RETL Datenpunktes zum Programm-
aufruf die CCU für die gesamte Programmlaufzeit blockieren.
Aus diesem Grund gibt es die Möglichkeit, den Exit-Code eines per CMD_RUNS bzw.
CMD_RUNL aufgerufenen Befehls als Ereignis in einer Programmverknüpfung auszu-
werten und so eine Aktion nach Beendigung des Befehls auszuführen, ohne dabei andere
Programme für die gesamte Laufzeit dieses Befehls zu blockieren.
...
Nach der Abarbeitung wird der Wert des Exit-Codes im Datenpunkt CMD_RETS an die
CCU Logikschicht gesendet und kann asynchron mittels einer einfachen Programm-
verknüpfung abgefragt werden:"

Statt also in einem Skript immer wieder die gleiche Sequenz zu verwenden aus z.B.

Code: Alles auswählen

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());

wobei immer die CCU so lange steht, wie der Befehl eben dauert,
ist also zu empfehlen, die Antwort des Befehls asynchron auszuwerten, z.B.erst den Befehl raushauen

Code: Alles auswählen

dom.GetObject ("CUxD.CUX2801001:6.CMD_SETS").State (command);
dom.GetObject ("CUxD.CUX2801001:6.CMD_QUERY_RET").State (1);
dom.GetObject ("CUxD.CUX2801001:6.CMD_RUNS").State(1);

damit läuft die CCU sofort weiter.
im 2. Programm (siehe hier) dann eben auswerten :

Code: Alles auswählen

	...
	!--- Trigger is ok, also Rückgabewerte holen
	string s_reply = dom.GetObject("CUxD.CUX2801001:6.CMD_RETS").State();
	...

Damit habe ich auf meinem System keine Probleme mit blockierenden Skripts. Also entweder

• "fire & forget" mit CMD_EXEC oder CMD_RUNS, dann gibt es auch keine Ausgabe.
• oder eben Timeouts / max retries auf minimum setzen
• oder gleich mit CallBacks arbeiten, ist mMn. die sicherste Methode.

[Xel66]

...oder gleich mit CallBacks arbeiten, ist mMn. die sicherste Methode.

Ich muss zugeben, diese (verlinkte) Lösung hatte ich nur am Smartphone überflogen und nicht richtig verinnerlicht. Das sollte wirklich die Lösung sein. Ich werde mal, wenn ich dazu komme, meine Haustür-Kamera-Lösung überarbeiten. Die braucht manchmal etwas, um ein Bild zu schicken (ist über PowerLAN angebunden) und ich habe dann ein paar (3-5) Sekunden Delay. Ich schicke bei Bewegungserkennung vor der Haustür (BWM) und Abwesenheit ein Bild per Telegram. Dieser Vorgang blockiert mir manchmal die Öffnung der Tür, wenn ich sie mit dem Smartphone bediene. Nutze ich die direktverknüpfte Fernbedienung, gibt es das Problem logischerweise nicht. Im Moment nutze ich zwei Scripte (Bild holen und versenden) in einem Programm mit Zeitversatz. Danke für den Lösungsansatz.

Gruß Xel66

[Black]

Die CallBack Funktionalität ist, wenn man auf eine Antwort eines externen System wartet, die sauberste Implementation.

beschrieben ist es, wie g55 schon zitierte, in der CUXD Dokumentation.

beschrieben hatte ich einen praktischen, bei mir selber laufenden UseCase 2018 in dem Beitrag:

SUSV mit CallBack auswerten

Black