ausfallsichere Rolladensteuerung

[MichaelN]

EDIT: nach Diskussion (siehe nachfolgende Beiträge) nochmal überarbeitet

Naja, ausfallsicher ist vielleicht etwas übertrieben. Aber der eine oder andere kennt vielleicht das Problem mit sporadischen Kommunikationsstörungen. Nichts gravierendes, aber ab und an fährt das eine oder andere Rollo nicht wie gewünscht. Ein danach abgesetzter Befehl wird aber ausgeführt.

Um diese sporadischen Kommunikationsstörungen zu umgehen habe ich mir folgendes ausgedacht:

1. Anlegen einer Systemvariablen für jedes Rollo:

2. In allen Programmen in denen das Rollo verfahren wird, wird diese Systamvariable auf den korrespondierenden Wert gesetzt.
Also, wenn man das Rollo öffnet auf "Oben", wenn man es schließt auf "Unten" und wenn man es in die Schattenposition fährt auf "Schatten".

Fahrbefehle-DANN.JPG (20.44 KiB) 1665 mal betrachtet

3. Für jedes Rollo ein Programm erstellen, das von dieser Systemvariable getriggert wird und überprüft ob der gewünschte Sollzustand erreicht ist. Wenn nicht, wird der Fahr-Befehl (für jedes Rollo mit einer individuellen Zeitverzögerung) ausgeführt und die Prüfung zeitversetzt nochmal angetriggert. Ich setze hier per Skript noch zeitverzögert die Systemvariable Telegramm, die dadurch nur im Falle des nachtriggerns eine Telegram-Nachricht auslöst. Das ist aber nice-to-have.

4. Eine Überprüfung, ob das Rollo schon die gewünschte Position hat, benötigt man in den auslösenden Programmen (siehe 2) nicht mehr, weil das ja dann durch das getriggerte Steuerungs-Programm (siehe 3) übernommen wird. Dort kann man ebenfalls alle weiteren Bedingungen reinpacken, die vor dem Verfahren geprüft werden sollen. Bei Türen z.B. den Zustand offen/geschlossen. Letzteres sollte man auch unbedingt tun, denn wenn man das nur in (2) prüft und in (3) wird nachgetriggert, dann ist der Aussperrschutz ggf. ausgehebelt.

[Xel66]

Diese Lösung besitzt m.E. durch den rekursiven Aufruf im ersten WENN etwas Bäng-Potenzial bezüglich des Duty Cycles. Ist der Aktor wirklich mal nicht erreichbar (Spannungsausfall, C26-Defekt), wird er im Takt von einer Minute immer wieder angesprochen. Darum habe ich eine ähnliche Lösung bei mir wieder verworfen.

Ich habe mir daher eine Lösung gebaut, die nach einer Ansteuerung eines auffälligen Aktors einmalig aktiv wird. Ein versetzt aufgerufenes Script im gleichen Programm schaut einfach nach dem Datenpunkt WORKING (dieser ist WAHR wenn der Aktor angesteuert wurde, aber die Rückmeldung noch nicht erfolgt ist) und sendet dann ein STOP. An dieser Stelle könnte man auch den ursprünglichen Fahrbefehl noch mal aufrufen. Aber bei mir hat sich herausgestellt, dass der Befehl meistens ausgeführt wurde, aber die Rückmeldung vermutlich wegen Funkkollisionen bei der CCU/RM nicht angekommen ist (ich fahre bei der Zentralsteuerung alle Rollladen mit kleinem Befehlsversatz von wenigen Sekunden quasi "gleichzeitig"). Durch das STOP wird der Status in der CCU/RM nur aktualisiert. Gleichzeitig wird noch ein Protokolleintrag sowie eine Telegram-Info abgesetzt. Anbei mal ein Besipiel für den Rollladen im Besucherklo.

Code: Alles auswählen

! Script zur Erkennung einer fehlenden Erfolgsmeldung mittels WORKING +++++++++++++++
if (dom.GetObject("Besucherklo").DPByHssDP("WORKING").Value()==true){
dom.GetObject("Besucherklo").DPByHssDP("STOP").State(1);
dom.GetObject("Protokolleintrag").State("Status Besucherklo korrigiert");
dom.GetObject("TelegramText").State("Status Besucherklo-Rollladen korrigiert");}

Dieses Script befindet sich nur in diesem einen Programm, weil das Besucherklo bzgl. der Funkverbindung maximal entfernt liegt und ab und zu mal funktechnisch unzuverlassig erreichbar ist (vermute mal die Funk-Alarmanlage des Nachbarn), denn der RSSI ist mit -75dBm eigentlich nicht so schlecht.

Gruß Xel66

[MichaelN]

Ja, an das Risiko einer Dauercshleife habe ich auch schon gedacht. Wenn ein Gerät z. B. Wg. Zu hohem DC nicht mehr erreichbar ist, wird dieses Verfahren den DC noch höher treiben. Das sollte man schon im Auge behalten. In der Regel sollte die einmalige Wiederholung des Fahrbefehls auch ausreichen, sonst ist da sowieso mehr im argen. Daher könnte man zur Sicherheit die wiederholte Setzung der Systemvariable rauswerfen.

[dtp]

Ich habe das bei mir derart gelöst, dass ich die aufgerufenen Rolllädenzustände in eine Systemvariable speichere und sie dann innerhalb einer festlegbaren Zeitspanne mittels eines CUxD-Timers aufrufe. Dann werden einfach noch mal alle Rollläden mit ihren jeweils abgespeicherten Sollwerten angesteuert. Natürlich wird vorher abgefragt, ob der jeweilige Istwert vom Sollwert abweicht, um ein unnötiges Ansteuern zu unterdrücken. Wenn man will, kann man das Spiel auch mehrmals wiederholen.

[MichaelN]

Ich merk schon, wenn ich so weitermache habe ich bald das zBSP nachgebastelt...

[MichaelN]

Sieht jemand in der Lösung noch ein anderes Bäng-Potential? Ich habe probeweise für 1 Rollo nun die Steuerung der Fahrbefehle komplett darüber gelöst. D.h. In allen WebUI-Programmen die direkte Ansteuerung der Behanghöhe durch das Setzen der Werteliste ersetzt. Test war erfolgreich.

ABER: abends um 17:30 schlossen sich auch alle Rollläden wie erwartet - nur als ich 2 Minuten später in die WebUI schauen wollte, war die tot.
Rote LED der CCU leuchtete dauerhaft, SSH Zugriff ging noch, ReGa lief nicht mehr. Habe das dann durch Reboot der CCU gelöst. Und nach dem Neustart die Routine nochmal durchgetestet. Lief wieder fehlerfrei.

Habe leider das Log-File nicht gesichert. Das war voll mit RPCXML Fehlern, ich vermute aber durch die Nichterreichbarkeit der ReGa. Den eigentlichen Auslöser habe ich nicht gefunden.

Jemand eine Idee, außer "reiner Zufall"?

[Xel66]

Der rekursive Befehl mit eiener Minute Verzögerung dürfte es eher nicht sein. Eher das letzte SONST WENN, denn es Triggert auf "bei Aktualisierung" das gesamte Programm - immer, auch wenn Du die Systemvariablen auf "Ruhe" setzt.

Gruß Xel66

[MichaelN]

Das ist mir bewusst, aber auch das wird ja nur einmal in einer Minute gemacht. Und das wiederum nur morgens, abends, und ggf. Wenn Sonne scheint. Also evt. 3-4x am Tag. Und der Ablauf funktioniert wir gewünscht. Ich lasse die SV protokollieren. Schaltet wie geplant jeweils einen Schritt weiter.

[Gerti]

Hi,

ich hatte hier mal meine Lösung vorgestellt:
https://connectedsmart.de/2019/04/08/ro ... version-1/
Da gibt es zwei "Ausbaustufen" und das hat absolut zuverlässig funktioniert.

Ende 2019 habe ich von Homematic Classic auf IP umgestellt (die Rollläden werden nach wie vor über Programme gefahren) und seitdem musste kein Rollladen mehr nachgetriggert werden. Ich lasse meine Programme aber weiter bestehen, denn die fressen ja kein Brot.

Nach meiner Erfahrung arbeitet die Kommunikation zu HmIP Aktoren deutlich zuverlässiger.

Gruß
Gerti

[Xel66]

Das ist mir bewusst...

Sicher? Kann ich mir nicht vorstellen. Geh mal auf die WebUI Status und Bedienung/Programme und schau Dir den Zeitstempel dieses Programms nach dem ersten echten Lauf mal ein paar Sekunden an. Du wirst staunen. Irgenwann gehen der CCU dann die Ressourcen aus, weil die bei jedem Programmlauf (so ca. alle drei Sekunden) die Timer für die Verzögerungen setzt. Dann geht sie in die Knie. Dann hast Du auch nichts mehr zu schauen. Bäng! Dir fällt da die Eigenheit, wie die CCU die Bedingungsprüfungen von Programmen triggert auf die Füße und bist da in eine ganz fiese Falle getappt. Wenn Du das letzte SONST WENN in ein separates Programm auslagerst, dürfte es funktionieren.

Gruß Xel66