ausfallsichere Rolladensteuerung

[MichaelN]

Habe ich gerade gemacht.
1. Zeitstempel 12:06:52
2. Zeitstempel 12:07:52

Wie erwartet

@Xel66: ich habe es jetzt mehrfach getestet. Absturz der CCU erfolgt nicht. Kann ich auch momentan nicht nachvollziehen. Ich vermute, Du spielst darauf an, das irgendwie ständig das Programm getriggert wird. Das passiert aber nicht.
1. Ich setze SV auf "Oben", Programm wird getriggert
2. Programm stellt fest "Oben" ist true und die Behanghöhe ebenfalls
3. Rollo fahren, SV sofort auf "Ruhe" und verzögert auf "Oben"
4. Programm wird getriggert; stellt fest "Ruhe" ist nirgendwo eine true Bedingung, geht wieder schlafen
5. Nach 1 Minute geht SV auf "oben"
6. Programm wird getriggert; SV "oben" ist true; Behanghöhe aber nicht; läuft bis zum SONST-WENN. Dort ist SV "oben" true
7. SV wird auf "Ruhe" gesetzt
8. Programm wird getriggert; stellt fest "Ruhe" ist nirgendwo eine true Bedingung, geht wieder schlafen

Es wird also binnen 60 Sekunden 4x getriggert. Das sollte die CCU doch verkraften. Kann man irgendwo nachsehen, ob da was "vollläuft"?

[MichaelN]

@Gerti: deine Version 1 ist ja das gleiche Prinzip, das ich mir auch überlegt habe. Unterschied, und da bin ich nicht drauf gekommen, Du prüfst auf "Aktualisierung". Das löst das Problem, das ich hatte und deswegen zwischendurch auf "Ruhe" umschalte. Ich vermute aber mal, daß bei Dir tatsächlich Xel66 Hinweis zutrifft, daß Dein Programm dann während des Rollo Laufs kontinuierlich aufgerufen wird?!

[Gerti]

Hi,

wird es nicht.
Aktualisierung triggert beim Rollladen einmal beim losfahren und einmal beim ankommen.
Während der Fahrt wird keine Aktualisierung getriggert.

Gruß
Gerti

[MichaelN]

Stimmt, Du aktualisierst die Variable ja auch erst nach 1 Minute. Dann muss ich bei mir nur auf Aktualisierung umstellen und kann mir dann den überflüssigen Status Wechsel auf "Ruhe" sparen. Sehr gut.

[Xel66]

Es wird also binnen 60 Sekunden 4x getriggert. Das sollte die CCU doch verkraften. Kann man irgendwo nachsehen, ob da was "vollläuft"?

Ja, das sollte sie verkraften. Mach mal Deinen virtuellen Programmlauf mit nicht erreichbarem Aktor. Und nein, leider kann man da nichts direkt sehen. Der Speicherverbrauch sollte ansteiegen, weil viele Timer getriggert werden. Ich hätte eine häufigere Triggerung erwartet. Vielleicht ist da was in aktuellen Firmwareversionen verändert worden. Man muss sich gerade in komplexeren Programmen immer vor Augen halten, dass auch die Prüfung auf "bei Änderung" Teil der Bedingungsprüfung des Programms ist und nicht als Trigger im Vorfeld geprüft wird. So hätte ich auch die ständige Aktualisierung der Sysvar "Rollo_Sued_Befehl" als Trigger für das letzte SONST WENN erwartet. Aber vermutlich kommt dieses nur zum Tragen, wenn eine weiterer anderer Trigger mit in dem Bedingungsblock wäre. An der Stelle verhält sich die ReGa etwas merkwürdig. Ich habe diesbezüglich damals nur meine Experimente gemacht, um das Verhalten zu analysieren und bin da auf einige Ungereimtheiten gestoßen. Ich habe keinen tieferen Einblick, wie die ReGa wirklich arbeitet, sondern nur meine Verhaltensanalysen, die vielleicht auch nicht jeden Anwendungsfall abdecken.

Gruß Xel66

[MichaelN]

Die SysVar wird ja nicht ständig aktualisiert, sondern nur 4x mal. Aber dank dem Tip von Gerti werde ich selbst das noch weiter reduzieren.

Edit: umgesetzt, zigmal getestet, arbeitet stabil und ohne Absturz. Nun werde ich das mal in der Praxis beobachten.

[MichaelN]

Läuft jetzt seit ein paar Tagen stabil, auch mit den anderen Rollos. Die Lösung sieht nun so aus wie bei Gerti.
Zusätzlich setze ich die Variable Telegram zeitverzögert per Skript und setze die Zeitverzögerung im letzten Sonst-Wenn wieder zurück. Dies bewirkt, das ich nur dann eine Telegramm-Nachricht bekommen, wenn ein Nachtriggern erforderlich war. Per Skript musste ich es lösen, weil ich aus Sicherheitsgründen den Haken bei "laufende Verzögerungen beenden" nicht rausnehmen wollte, dies für die Telegramm-Nachricht aber erforderlich ist.