Setzen einer Systemvariablen wird "verschluckt" (bei verlangsamter Programmausführung)

[MichaelN]

Das einfachste wäre ja den störrischen Aktor ans Ende der Abarbeitung zu stellen und zu schauen ob das Problem dann weg ist. Kostet 5 Sekunden.

[Xel66]

Da die Originalprogramme nicht sichtbar sind (Wink mit dem Zaunfeld), ist es eigentlich müßig, darüber zu diskutieren, denn man kann über die Ursache nur spekulieren und die Glaskugel bemühen. Vermutlich werden aber die Rückmeldungen des triggernden Aktors verzögert, weil in dieser Zeit das Funkmodul versucht, den nicht vorhandenen Aktor zu kontaktieren (listen before talk). Diese fehlenden Rückmeldungen verursachen dann vermutlich die verzögerte Abarbeitung des Prozesses. Auch halte ich die gleichzeitige Ansteuerung mehrerer Aktoren per "sofort" in Deinem Beispielprogramm für nicht funktionssicher. Grundsätzlich sollte die CCU das gerade im Falle von HmIP handlen können, aber im Falle von schwer oder nicht erreichbaren Aktoren kann das LBT (listen before talk) ein Bein stellen. Bei klassischem Homematic würden die Aktoren schlichtweg nicht reagieren und die CCU eine Kommunikationsstörungsmeldung werfen.

Gruß Xel66

[Baxxy]

Ich finde es interessant das ein unerreichbarer Aktor den "Programmdurchlauf" zum stocken bringt. Hatte ich bisher noch nichts von gehört/gelesen.

Dachte bisher das die ReGa die Befehle stur an den entsprechenden Dienst (rfd, HM/HmIP-Server) weitergibt und nicht auf Rückmeldung wartet.

Das muss ich mal testen. Gibt's da irgendwas wie man die Laufzeit eines Programmes bestimmen kann?

[shartelt]

Das muss ich mal testen. Gibt's da irgendwas wie man die Laufzeit eines Programmes bestimmen kann?

speicher Dir Werte in ne DB, dann siehstes am Timestamp?

[MichaelN]

Gibt's da irgendwas wie man die Laufzeit eines Programmes bestimmen kann?

Skript als ersten Und letzen Befehl und dort einen Eintrag ins Fehlerprotokoll schreiben

Aber ich glaube mittlerweile, daß wir nicht das vollständige Bild sehen, denn:

entweder baue ich mir einen eigenen TCL-Daemonprozess auf der Raspberrymatic bzw. erweitere einen bereits von mir entwickelten) oder ich setze es per Java-Script unter ioBroker

Ich vermute mal sehr stark, daß der störrischen Aktor auch Effekte auf die eingesetzte Middleware hat und diese ggf. Die CCU mit Anfragen "bombardiert" und damit zeitweise ausser Gefecht setzt. Sowas haben wir ja schon öfter hier gesehen.

[Xel66]

Dachte bisher das die ReGa die Befehle stur an den entsprechenden Dienst (rfd, HM/HmIP-Server) weitergibt und nicht auf Rückmeldung wartet.

Das wird wohl auch so sein, aber das andere Programm wird ja wohl (Glaskugel) durch die vollzogene Rückmeldung eines anderen Aktors getriggert und diese Rückmeldung kommt wahrscheinlich nicht zum Zug, weil der damit Aktor wartet, bis die CCU ausgefunkt hat. Ist aber alles Spekulation. Kann man sicher mit "alles loggen" herausbekommen.

Mir ist auch nicht verständlich, warum man Aktoren in einem Programm anspricht, von denen man weiß, dass sie sich nicht im System befinden. Gerade bei Weihnachtsbeleuchtung könnte man ein entsprechendes Programm machen, welches diese Aktoren anspricht und durch Setzen einer Saisonvariable unwirksam gesetzt werden kann, solange man die Funktion nicht benötigt.

Gruß Xel66

[mule]

Das wird wohl auch so sein, aber das andere Programm wird ja wohl (Glaskugel) durch die vollzogene Rückmeldung eines anderen Aktors getriggert und diese Rückmeldung kommt wahrscheinlich nicht zum Zug, weil der damit Aktor wartet, bis die CCU ausgefunkt hat. Ist aber alles Spekulation. Kann man sicher mit "alles loggen" herausbekommen.

Deine Glaskugel hat recht. Hierzu hatte ich nichts weitergeschrieben und auch nicht die Programme gepostet, da es in diesem Thread ja nicht um die Verzögerung/Verlangsamung gehen sollte.

Mir ist auch nicht verständlich, warum man Aktoren in einem Programm anspricht, von denen man weiß, dass sie sich nicht im System befinden. Gerade bei Weihnachtsbeleuchtung könnte man ein entsprechendes Programm machen, welches diese Aktoren anspricht und durch Setzen einer Saisonvariable unwirksam gesetzt werden kann, solange man die Funktion nicht benötigt.

Da bin ich voll bei Dir und das Ganze ist auch schon längst geändert. Ich hätte allerdings auch nicht mit derartig starken Verzögerungen gerechnet (man sieht ja im zu Anfangs geposteten Systemprotokoll, dass das Ganze bei ca. 22 Sekunden liegt), da mir ein derartiges Verhalten bis dato nicht bekannt war und anscheinend anderen hier auch nicht.

[mule]

Aber ich glaube mittlerweile, daß wir nicht das vollständige Bild sehen, denn:

entweder baue ich mir einen eigenen TCL-Daemonprozess auf der Raspberrymatic bzw. erweitere einen bereits von mir entwickelten) oder ich setze es per Java-Script unter ioBroker

Das hier geschilderte Problem war ein kleiner Teil von meiner Beleuchtungssteuerung, welche wiederum verknüpft ist mit der Rolladensteuerung. Die Rolladensteuerung läuft seit geraumer Zeit als eigen entwickelter TCL-Prozess mit parametriebaren Logikbausteinen und Ansteuerung von Somfy-Rolläden (hatte ich hier im Forum auch irgendwann mal veröffentlicht). Dies würde hier den Rahmen aber komplett sprengen. Da ich eh komplett von HM-Script und HM-GUI weg will werde ich auch die Beleuchtungssteuerung komplett neu und mit anderen Programmiermitteln umsetzen.

Ich vermute mal sehr stark, daß der störrischen Aktor auch Effekte auf die eingesetzte Middleware hat und diese ggf. Die CCU mit Anfragen "bombardiert" und damit zeitweise ausser Gefecht setzt. Sowas haben wir ja schon öfter hier gesehen.

Nein, da ich die Logik dann komplett anders umsetzen werde und dies inklusive der Möglichkeit HM-Komponenten bewusst zu "deaktivieren", so dass diese gar nicht mehr angesteuert werden. So etwas Ähnliches habe ich für mich schon im Bereich von Servicemeldungen vor etlichen Jahren umgesetzt.

Aber wie schon geschrieben: Es geht mir hier nicht darum eine Problemlösung für meinen konkreten Anwendungsfall zu finden (da weiß ich mir schon zu helfen und habe mir hier auch schon geholfen), sondern dem Grund für das merkwürdige Verhalten auf die Schliche zu kommen, so dass ggf. andere nicht in die Falle tappen oder (falls überhaupt möglich) das Problem (wenn es denn nicht so bewusst designed ist) zu beheben.

[mule]

Ansonsten: Erst einmal Danke an Alle für die Diskussion.

ich werde hoffentlich am Wochenende die Zeit finden die Doku zur Reproduktion des Themas auf das Wesentliche zusammenzufassen und dann erneut hier mit Programmen und entsprechenden Screenshots zu posten.

[Xel66]

...sondern dem Grund für das merkwürdige Verhalten auf die Schliche zu kommen...

Für mich ist der Grund laut der Symptombeschreibung (und Glaskugel) das LBT (listen before talk).

Gruß Xel66