Lösung

 

Schaltung

Beide Ausgänge des Rollladenaktors für Hoch- und Runterfahren werden mit dem Relais (Kontakt A1, an A2 kommt der Nullleiter) verbunden. Die beiden geschalteten Kontakte (13/14) des Relais' werden mit den Anschlüssen des Torantriebs verbunden, an denen der Tastimpuls signalisiert werden muss.

 

 

Konfiguration

In der Konfiguration des Rollladenaktors werden die Laufzeiten für das Öffnen bzw. Schließen auf ca. zwei Sekunden eingestellt. Darüber hinaus muss die Anzahl der Fahrten, nach denen eine Kalibrierungsfahrt erfolgt (siehe: neu kalibrieren nach ..), auf "0" eingestellt werden.

 

 

  

Funktionsweise

Drückt man an dem Rollladenaktor auf ZU, wird für zwei Sekunde das Relais geschlossen; bei einem Druck auf AUF ebenso. Hierdurch wird der Torantrieb in Bewegung gesetzt und das Tor öffnet bzw. schließt je nach Zustand, in dem es sich befand.

Geht man jetzt diszipliniert zu Werke und drückt nur bei geschlossenem Tor auf AUF und nur bei geöffnetem Tor auf ZU, so zeigt das Rollladensymbol in der Smarthome App das Tor in der richtigen Stellung. Ist der Status des Tores unbekannt, kann man in der Fernbedienung der Smarthome App den Zustand am zur Kontrolle eingesetzten Tür-/Fensterkontaktes einsehen.
Sollte durch falsche Reihenfolge beim Drücken auf AUF/ZU oder Bedienung des Torantriebs über eine andere Quelle die Anzeige in der App falsch sein, kann man mit einem Druck auf die eigentlich falsche Taste (AUF/ZU) dies (sogar aus der Ferne) korrigieren.

 

Statusanzeige: offenes Tor     Statusanzeige: geschlossenes Tor

Ist das Tor AUF, aber es wird als ZU angezeigt (Symbol des Rollladenaktors), so muss dennoch auf ZU gedrückt werden. Dies kann mittels der entsprechenden manuellen Situation oder am Rollladenaktor selbst geschaltet werden. Diese Aktion hat zur Folge, dass sich der Torantrieb in Bewegung setzt und das Tor schließt. Die Rollladenaktoranzeige verbleibt auf der Anzeige ZU. Die Welt ist anschließend also wieder in Ordnung.

Diese Akrobatik wäre nicht vonnöten, könnte die Aktion Rollladen schließen bedingt ausgeführt werden, d.h.: Der Rollladenaktor schaltet nur bei einem Druck auf ZU, wenn der Rollladen im System als AUF vermerkt ist. Leider schaltet der Rollladenaktor bei einem Druck auf ZU auch dann, wenn der Rollladen als ZU im System registriert ist. Das verstehe wer will.

 

Das Ganze ist ziemlich unausgegoren implementiert.

 

Automatisierungen

glücklich ist, wer noch Situationen hat

manuelle und automatische Situationen zur täglichen Steuerung

 

Situation zur Steuerung des Tores

Die Situationen Garage AUF bzw. ZU bewirken dasselbe wie ein Druck auf den Rollladenaktor.

 

Um das Tor mittels einer einzigen Situation zu öffnen und zu schließen, wird eine manuelle Situation AUF-ZU definiert, die bei ihrer Aktivierung das Tor öffnet und bei ihrem Beenden es wieder schließt. Hierzu muss man in der Konfiguration der Situation in der Option ENDE den Schaltzustand geschlossen aktivieren. 

 

manuelle Situation AUF-ZU konfigurieren

 

Situation für vergessliche Leute

 

Die folgende Situation, welche zeit- und sensorgesteuert (Helligkeitssensor und Tür-/Fensterkontakt) konfiguriert wird, dient dazu, das Garagentor zu schließen, wenn es zwischen Sonnenuntergang und Sonnenaufgang richtig dunkel ist.

WENN Sonnenuntergang < Zeit UND Helligkeit < Sollwert UND Tor offen DANN Tor schließen.

 

Garage abends ZU

Bei der Verwendung dieser Situation ist jedoch Vorsicht geboten!

 

Falls deren Bedingungen hinsichtlich Zeit und Helligkeit erfüllt sind, wird sie beim manuellen Öffnen des Tores natürlich aktiviert. Dies wiederum sorgt dafür, dass das Relais anzieht und das Tor in der Regel zum Stillstand bringt.

 

Im Zeitintervall Sonnenuntergang - 4 Min. < aktuelle Zeit < Sonnenuntergang + 60 Min. schließt diese Situation das Tor, wenn zusätzlich der aktuelle Helligkeitswert im gewählten Wertebereich des Lichtsensors liegt. Kommt man also spät nachts nach Hause, so sollte beim manuellen Bedienen der Torsteuerung diese Situation nicht wie oben beschrieben dazwischen funken.

 

(sinnlose) Regeln(?)

Seit der Version 5.8 der Smarthome App von Ende Mai 2020 kann auch in der DANN-Sektion der WENN .. DANN .. DANACH .. Kontrollstruktur eine Verzögerung eingepflegt werden. Dies ermöglicht nun endlich die im Folgenden angemahnten Steuerungsmöglichkeiten (automatisches Schließen) leidlich (und recht umständlich) zu realisieren.

 

was in der alten Version alles nicht ging ..

 

Nach einigen Anlaufschwierigkeiten und nach dem letzten Update hatte ich die Hoffnung, dass die Entwickler doch noch eine sinnvolle Steuerungslogik implementiert hätten. Leider weit gefehlt.

 

Man hat offenbar bloß den Geschmack der Mehrheit zutreffen gesucht und eine in der Tat komfortable Steuerung für Beleuchtungszwecke etabliert. Alles Andere, was rechts und links davon möglich gewesen wäre, hat man tunlichst ausgeklammert.

 

So funktioniert die im Folgenden vorgestellte Regel nur, wenn mal wieder das System klemmt. Dabei ist sie eigentlich ganz einfach gestrickt: Ist das Garagentor zwischen Sonnenuntergang und Sonnenaufgang geöffnet, so soll eine Nachricht verschickt werden, dass es in zehn Minuten geschlossen wird; nach Ablauf dieser Zeit wird das Tor geschlossen und man wird in einer weiteren Meldung darüber informiert.

 

Wer so schlicht denkt, hat leider die Rechnung ohne die viel subtiler denkenden Entwickler gemacht.

 

In den letzten Tagen funktionierte diese Regel wie gewünscht und ich wollte schon jubeln. Leider war das Ganze auf massive Störungen im System zurückzuführen, die offenbar die Reaktionen der Homebase so stark verzögert haben, dass die Regel wie eigentlich gewünscht arbeitete. Übrigens - allein, dass auch in der DANACH-Sektion die Dauer zusätzlich zur Option Dauer in der DANN-Sektion eingerichtet werden könnte, ermöglichte bereits eine Lösung für dieses Problem.

 

Tatsächlich geschieht folgendes: Die Regel arbeitet zunächst wie gewünscht. Sind jedoch einmal die Reaktionszeiten der Homebase nicht verzögert, dann sind die Bedingungen in der WENN-Sektion schon wieder wahr, bevor der Tür-/Fensterkontakt das Tor als geschlossen melden kann - schließlich währt das Schließen des Tores für das System ja nur die min ein bis zwei Sekunden äußerst kurze Schaltzeit. Daher startet die Regel erneut und das Spiel würde unermüdlich die ganze Nacht so weitergehen.

 

Was in der neuen Version endlich (leidlich zufriedenstellend) möglich ist ..

Die hier vorgestellten Lösungen beruhen auf der WENN .. DANN .. DANACH .. Struktur und deren Optionen Verzögerung und Dauer. Diese Kontrollstruktur sollte man keineswegs mit der in der Informationstechnik üblichen WENN .. DANN .. SONST .. Steuerung vergleichen, allzu verschieden sind deren Eigenschaften.

 

Seit der App Version 5.8 gibt es die Möglichkeit, sowohl in der DANN-Sektion als auch DANACH-Sektion eine Verzögerung einzupflegen. Hierbei ist die Wirkung dieser Option jedoch in beiden Sektionen unterschiedlich. Dieser Unterschied ermöglicht endlich eine leidlich praktikable Lösung für neue Regeln.

 

Es ist nach wie vor nur äußerst umständlich möglich, vorab die Schließung des Tores anzukündigen und sie etwa um zehn Minuten verzögert zu veranlassen - aber es geht.

 

Bei den nachfolgenden Lösungen und deren Umsetzungen ist zu berücksichtigen, dass die Entwickler geradezu Fallstricke - in Form der Optionen Dauer und Verzögerung - ausgelegt haben, die man so auch nur für eine Beleuchtungssteuerung benötigt:

 

• Option Dauer ..
• Wird in der DANN-Sektion eine Dauer eingepflegt, so ist zwingend eine DANACH-Sektion erforderlich.
• Die Option Dauer kann nicht in der DANACH-Sektion verwendet werden.
• Weitere Verwirrung dürfte die Option Verzögerung stiften.
•  Wird sie in der DANN-Sektion eingefügt, so sorgt sie für zweierlei: Zum Einen verzögert sie die auszuführenden Aktionen um die definierte Zeitspanne, zum Anderen wird nach deren Ablauf die Anfangsbedingung erneut geprüft und nur wenn diese noch immer zutrifft, werden die vorgesehenen Aktionen ausgeführt.
• Wird diese Option Verzögerung in der DANACH-Sektion eingefügt, so verzögert sie nicht nur die Ausführung der in dieser Sektion definierten Aktionen, sondern erhält den Zustand aus der DANN-Sektion.

 

In den nachfolgenden Beispielen wurden bewusst unterschiedliche Lösungsstrategien verwandt, um die programmtechnischen Unwägbarkeiten und ihre Umschiffung aufzuzeigen. Ausgestattet mit diesen Erfahrungen sollten eigene Lösungen kein Problem mehr sein.

 

Garagentor nachts automatisch schließen

1. Versuch

Die erste App schließt das Garagentor automatisch zwischen Sonnenuntergang und Sonnenaufgang und meldet das Ergebnis via PUSH-Nachricht.

 

Garagentor nachts automatisch schließen

Die Verzögerung in der DANN-Sektion ist erforderlich, damit sich das Tor nicht gleich wieder zu schließen sucht bzw. gestoppt wird, wenn man nachts nach Hause kommend das Garagentor öffnet - schließlich sind bei (bereits teilweise) geöffnetem Tor die Anfangsbedingungen in der WENN-Sektion erfüllt. Sie muss also mindestens so lange währen, wie das Garagentor zum Öffnen benötigt. Zum Auslösen des Schließens wird hier eine Szene "Garagentor öffne/schließen" eingesetzt

 

In der hier vorgestellten Regel wird eine Verzögerung von zehn Minuten vorgeschlagen. Diese Zeitspanne zwischen Öffnen und Schließen des Tores sollte sicherlich ausreichen, das Auto in der Garage einzuparken, aber ggf. reicht diese Zeit nicht für ein zusätzliches Be- bzw. Entladen aus. Für diesen Fall muss man daran denken, bei Bedarf diese Regel zu deaktivieren.

 

Da für das System der Schließvorgang nur die Zeit umfasst, die der Rollladenaktor schaltet - das sind i.d.R. lediglich ein bis zwei Sekunden - ist die Angabe einer Dauer erforderlich, welche diesen Vorgang mindestens solange aktiv hält, bis das Tor auch tatsächlich geschlossen ist. In der Regel sollte die hier vorgeschlagene Zeitspanne von einer Minute ausreichend sein.

 

Hinweis: Ohne diese Dauer wären während des Schließen die Bedingungen in der WENN-Sektion erfüllt, der Rollladenaktor würde erneut schalten und das Tor durch diesen Impuls i.d.R. zum Stillstand bringen.

 

Die in der DANACH-Sektion für die Funktion dieser Regel absolut entbehrliche PUSH-Meldung wurde eingefügt, da diese Sektion vorhanden sein muss, wurde in der DANN-Sektion eine Dauer eingepflegt.

 

2.Versuch

Möchte man das Schließen des Garagentores vorweg ankündigen, hilft die hier geschilderte Regel weiter. Hier nutzt man die Besonderheit der Option Verzögerung in der DANN-Sektion.

 

Schließen des Tores vorweg ankündigen

Funktionsweise ..

 

Ist das Garagentor geöffnet, so wird nach der eingestellten Verzögerungszeit von einer Minute (die zwingend länger sein muss, als das Tor zum Schließen benötigt!) die Ankündigung der Schließung des Tores abgesandt. Diese Vorgang wird für die Dauer von fünf Minuten aufrechterhalten, bis die Aktionen in der DANN-Sektion ausgeführt werden, in der das Tor geschlossen wird und eine Nachricht darüber abgesandt wird.

 

Da der Schließvorgang für das System nur die Zeit umfasst, in der der (Rollladen)Aktor schließt (meint nur ein bis zwei Sekunden), sind die Anfangsbedingungen schon wieder erfüllt, obwohl das Tor noch gar nicht geschlossen ist. Die Folge ist, die Regel wird erneut gestartet.

 

Die Verzögerung in der DANN-Sektion sorgt nun dafür, dass die Regel nicht erneut ausgeführt wird. Nach ihrem Ablauf ist das Garagentor geschlossen und die Regel wird abgebrochen.

 

Garagentor bei Abwesenheit automatisch schließen

Die zweite Regel sorgt dafür, dass das Garagentor sich bei Abwesenheit nach zehn Minuten schließt und eine PUSH-Meldung versandt wird.

 

Garagentor bei Abwesenheit automatisch schließen

Die Verzögerung in DANN-Sektion ist zwingend erforderlich, da sie verhindert, dass das Schließen des Tores zum Stillstand kommt, wird in der DANAC

Auch hier ist die DANACH-Sektion zwingend erforderlich - allerdings aus einem völlig anderen Grund. Ohne die in dieser Sektion eingepflegte Verzögerung (hier von einer Minute) würde die Regel sich bereits nach der Schaltzeit des Rollladenaktors (von ein bis zwei Sekunden) erneut aktivieren: Da nach dieser Zeitspanne das Tor noch nicht vollständig geschlossen ist, treffen die Bedingungen in der WENN-Sektion erneut zu. Die Verzögerung muss also größer als die Zeit zum Schließen des Tores gewählt werden. Die ansonsten für die Bereitstellung der korrekten Funktionsweise redundante DANACH-Sektion wird genutzt, um mittels einer PUSH-Meldung den Abschluss der Aktion anzuzeigen.

 

Zustandsmeldung als PUSH-Nachrichten erzeugen 

Will man sich lediglich über den Zustand des Garagentores informieren lassen, so gibt es auch hier einige Hürden zu überwinden. Die Entwickler würden ihrem Ruf nicht gerecht werden, hätten sie nicht auch hierzu Verwirrendes beizutragen.

 

Ziel ist es, dass alle fünf Minuten eine PUSH-Nachricht versandt wird, die über den Zustand des Tores informiert.

 

Erster Versuch ..

PUSH-Meldung bei geöffnetem Garagentor

Leider liefert diese Regel nicht das Gewünschte. Sie wird genau einmal ausgeführt und das war's. Wenn man genau hinschaut, kann man den Grund erkennen: Es wird nicht der Zustand (offen bzw. geschlossen), sondern dessen Änderung erfasst.

 

zweiter Versuch ..

Benachrichtigung über geöffnetes Tor mit Zeitspanne

Diese Regel tut endlich genau das, was gewünscht ist: Alle fünf Minuten wird eine PUSH-Meldung versandt. Der entscheidende Unterschied ist auf den ersten Blick kaum zu erkennen. Bei genauerem Hinschauen sieht man, dass ein kleines Wörtchen ausgetauscht wurde: wird → ist.

 

Eine weitere Besonderheit ist, dass nach Ablauf der Verzögerung die Anfangsbedingungen (erneut) geprüft werden. Nur wenn diese noch immer zutreffen, wird die PUSH-Meldung versandt.

 

Merke: Wird in der WENN-Sektion nur ein Sensor eingefügt, so wird dessen Änderung bewertet. Verknüpft man den Wert des Sensor jedoch mittels UND mit einem Zeitintervall, so wird der Zustand des Sensorwertes selbst ausgewertet. Es kommt noch verrückter: Verwendet man statt der UND- eine ODER-Verknüpfung, wird wieder die Änderung bewertet. Ist doch alles logisch, oder?😜

 

dritter Versuch für tagsüber ..

offenes Garagentor melden (tagsüber)

Diese Regel meldet tagsüber, ob das Garagentor (noch) offen ist. Im Gegensatz zur obigen Regel für nachts, in der die PUSH-Meldung um fünf Minuten verzögert versandt wird, erfolgt hier die Meldung direkt beim Eintritt in die Regel.

 

So ganz rund gelingt die Lösung hiermit jedoch nicht. Da eine Dauer in der DANN-Sektion verwendet wird, muss eine DANACH-Sektion vorhanden sein. Hier erhält man dann eine abschließende PUSH-Nachricht, den Zustand des Tores ggf. nochmals zu prüfen.

 

 

Fazit ..

 

Wird beim ersten Versuch vom System die Zustandsänderung bewertet, so spielt im zweiten der Zustand selbst die entscheidende Rolle.

 

Das ist für mich reinste Agrarinformatik: Kraut&Rüben.

 

Warum geht die Entwicklungsabteilung nicht endlich einmal daran, ordentliche Arbeit abzuliefern? Nicht nur für unbedarfte und der Informatik wenig zugetane Kunden ist dies völlig verwirrend. Es gehört zu einer ordentlichen Programmierung, dass für den Anwender klipp und klar erkennbar ist, was in den Bedingungen bewertet wird. Diese beiden Beispiele zeigen, dass man nur mit recht viel Aufwand erkennen kann, dass völlig schlampig und intransparent zwischen Zustand (Pegeltriggerung) und Zustandsänderung (Flankentriggerung) gewechselt wird, wobei bei der letzteren es gar zwischen zwei Arten zu unterscheiden gilt: AN/AUS oder AUS/AN.

trauriges Fazit

Ansprüche

Da entwickeln unsere Vorfahren phantastische Theorien und Strategien - hier allen voran George Boole - um sinnvolle Lösungen durch mathematische und logische Verknüpfungen zu ermöglichen, und was machen die Entwickler heutzutage? Sie gehen hin und kastrieren deren Möglichkeiten, um den Geschmack der Masse zu treffen: Man hatte offenbar den speziellen Fall einer Beleuchtungssteuerung im Blickfeld und vergaß mehr oder weniger alles Andere. Es gilt offenbar in unserer Gesellschaft ein Erhaltungssatz: Quantität x Qualität = const.

 

Alternativen

Dabei wäre es mit den heutzutage zur Verfügung stehenden, üblichen Kontroll- und Befehlsstrukturen ein Leichtes gewesen, nicht nur die - ohne Wenn und Aber gute - Lösung für Beleuchtungszwecke, sondern auch obige Regel realisieren zu können: WENN .. DANN .. SONST .. in Verbindung mit TIMERn hätten die Lösungen geliefert.

 

Hier sollte endlich ein Umdenken stattfinden. Statt jene unter den Kunden, die auch ohne digitale Agenda 4.0 bereits informationstechnische Grundlagen beherrschen, zu verwirren, sollte man diese einzubinden suchen. Die Lösungen, welche ambitionierte Kunden entwickeln könn(t)en, wären statt Ursachen für Kritik eine Bereicherung für Qivicon. Um die unbedarfteren Gemüter vor sich selbst zu schützen, sollte man einen Expertenmodus implementieren, der die hierzu notwendigen optionalen Steuerungsbefehle zugänglich macht. Damit jedoch am Ende alle in den Genuß von diesen Erweiterungen kommen können, sollte es möglich sein, diese Lösungen als Makros zu realisieren. Ein in den Anfängen bescheidener Satz an Kontrollstrukturen und Befehlen bereitzustellen, sollte dem Entwicklerteam gewiss möglich sein.

 

Verweise ..
Im Qivicon-Forum und auch in der Telekom hilft Community sind hier und hier Threads zu finden, die im Zusammenhang bzw. Vorfeld mit der Erstellung dieser Lösung entstanden sind.

 

 Viel Erfolg ..

.. beim Basteln wünscht euch legro.