Steuerung Garagentor mit Sensoren

Derzeit hab ich noch einen Meross Garagenöffner mit einem Sensor, der anzeigt, ob offen oder zu ist. Ich möchte das aber auf ZigBee umbauen. Das Relais dafür hab ich schon. Natürlich brauch ich auch einen Sensor, der mir anzeigt, ob es offen oder zu ist.
Ich hab jetzt allerdings zwei Sensoren quasi über (einer ist fix für die Garage reserviert) und frage mich, ob es etwas bringt, es mit zwei Sensoren zu machen. Einer würde mir anzeigen ob das Tor ganz zu und der andere ob es ganz offen ist. Hintergrund ist der, dass mein Tormotor die Fahrtrichtung teilweise selbst bestimmt. Wenn es ganz zu ist, macht er auf. Ist es ganz offen, macht er zu. Jetzt kommt aber das ABER. Ist es weder ganz offen noch ganz zu, dann fährt der Motor bei der nächsten Betätigung in die andere Richtung. Heißt also, wenn er vor dem Stopp das Tor öffnet, schließt er es beim nächsten Signal.
Mein Gedanke war jetzt, auf Basis der Sensoren zwar nicht die Fahrtrichtung zu bestimmen (das kann ich nicht) aber es doch soweit steuern, dass, wenn ich im Webfront auf schießen klicke, das Tor auf jeden fall geschlossen wird. Die Steuerung ist etwas kniffelig, müsste aber gehen.
Ist das Tor halb offen und er war vorher im „Schließen Modus“ und man klickt auf „Schließen“ dann fährt der Motor zuerst das Tor ganz hoch. Dies würde ich durch einen Sensor an der Endposition erkennen und dann noch einmal ein Signal nachschicken, damit der Motor das Tor schließt. Man müsste das dann so lange machen, bis der Sensort „Tor zu“ die entsprechende Rückmedung gibt. Wie ich das genau realisieren würde, weiß ich noch nicht. Ein paar Ideen hab ich schon. Geht so in die Richtung, dass ich eine Variable habe, die mir anzeigt, dass aktuell ein Vorgang aus IPS aktiv ist. Der ist true oder false. Die zweite Variable, die ich so und so brauche für das Webfront, würde mir den gewünschten Zustand wiedergeben. Entweder Offen oder Zu. Wählt man jetzt schließen, dann wird das Signal geschickt und gleichzeitig die Variable für „Vorgang aktiv“ auf true gesetzt. Nach etwa 30 Sekunden (solange dauert ein kompletter Vorgang von ganz zu nach ganz auf) könnte man abfragen, wo das Tor gerade ist. Ist es zu, ist alles gut und die Variable „Vorgang aktiv“ wird auf false gesetzt. Ist es jedoch ganz offen (Sensor für offen gibt geschlossen zurück), dann wird noch einmal ein Signal gesendet - an das Relais - und wieder gewartet. Bis eben zu ist.
Dann hätte ich noch die Auswahl der Variable im Webfront auf „disabled“ gesetzt, solange ein Vorgang aktiv ist. Damit hier nichts geändert werden kann.
Man könnte statt der Wartezeit auch die Sensoren auf Änderung abfragen und dann im Skript weitermachen. Somit ist es egal, wie lange es dauert.
Das einzige Problem das ich sehe ist, wenn das das Tor z.b. beim Schließvorgang aufgrund eines Hindernisses blockiert wird. Dann geht es nämlich wieder auf und gemäß meiner möglichen Steuerung macht er wieder zu. Hat dann einen leichten Slaptsitckkarakter :wink:
Was haltet ihr von meiner Idee? Oder gehts auch einfacher (ja, ich könnte den Antrieb tauschen).

Das ganze liest sich wie eine Kolumne zum 1. April.

Darf ich frage wie du zu der Annahme kommst? Das war nicht als Aprilscherz oder ähnliches gedacht. Aber vielleicht hast du mein Anliegen einfach nur nicht verstanden. Soll ja vorkommen. Ich erkläre es dir gerne noch einmal, wenn du willst.
Andererseits freut es mich, wenn ich dir ein Lächeln aufs Gesicht zaubern konnte. Wenn schon sonst nichts konstruktives von dir kommt, dann wenigstens das. Vielen Dank.
Für die Allgemeinheit: es handelt sich hierbei um keinen Aprilscherz.

Halte ich nicht für einen Aprilscherz, aber es wird nicht gehen.
Man braucht richtige Zustände, und der eine Taster reicht nicht. Es ist und bleibt bei mir eine Krücke (ein Taster) :joy:

Doch es funktioniert. Ich hab es in der Zwischenzeit glöst. Im Moment nur mit Variablen und noch nicht mit echten Sensoren aber die Logik funktioniert.
Ich kenne ja die Zustände. Mit einem Sensor für ganz zu und einen für ganz offen weiß ich was zu tun ist, weil das steht ja wieder in einer anderen Variablen. Und ich weiß, weil das wird in einer weiteren Variablen abgelegt, ob der gewünschte Vorgang schon abgeschlossen ist, oder nicht. Sind nur zwei Skripts und zwei Ereignisse. Mit dem wird der aktuelle und der gewünschte Zustand erkannt. Je nach Torstand (ganz zu oder ganz offen) wird halt noch einmal wenn notwendig ein Signal geschickt und er fährt letztendlich in die gewünschte Position. In der Simulation passt das.

Abwarten, wenn mal was ausfällt. Es reicht wenn IPS mal Offline ist, und du den Taster von Hand geschaltet hast.

Das ist berücksichtigt, weil bei manueller Bedienung, die ja nach wie vor funktioniert, die Variable ob der laufende Vorgang noch aktiv ist oder nicht, den Wert false hat. Somit wird lediglich der Zustand des Tores (offen, teilweise offen, zu) geändert, aber es erfolgt sonst keine Steuerung aus IPS. Die Sensoren und auch das Relais sind ja nur über die Logik von IPS verbunden. Ansonsten wissen die nichts voneinander.
IPS kann ausfallen und das Tor kann weiterhin manuell über einen Taster bedient werden. Der Taster bedient aber NICHT das Relais, sondern hängt parallel zum Relais am Motor.

Hi,
hat dein Tor einen Einklemmschutz oder wie das heißt? Ich hatte dich ja ein wenig in diese Richtung geschickt weil ich es mir ähnlich überlegte z.B. um Luftfeuchtigkeit regulieren zu können. Was mich abgehalten hat ist eben was passiert wenn es eine Blockade des Antriebs gibt. Hast Du das auch berücksichtigt. In meiner einfachen Version könnte das Tor dann den ganzen Tag hin und her fahren.

Ralf

Ja hatt es. Wenn es bei der Fahrt auf Wiederstand stößt, kehrt der Motor die Fahrtrichtung um. Das hab ich im Eingangspost schon erwähnt.
In diesem Fall könnte das von dir beschriebene Verhalten eintreten. Aber auch nur dann, wenn das Tor gearde beim Schließvorgang unbeobachtet ist. Was ich eigentlich nicht mache. Man könnte das aber noch insofern abfangen, indem man einen Art Zäher verwendet, der dann z.b. beim zweiten Versuch das Tor zu öffnen oder zu schließen den Vorgang abbricht. Dann würde das Tor entweder wieder voll auf oder vol zu gehen oder einfach stehen bleiben. Je nach Fehler. Das würde dann aber vom Motor und nicht von IPS gesteuert werden.

@udegens: Wie bist du denn drauf ?
Wenn hfichtinger das so machen möchte dann laß ihn doch. Genau das ist doch das schöne am basteln (und wir sind hier in der Bastelecke) das man ach mal unbekannte Wege geht um seine Ideen umzusetzen.
Wenn er zwei Taster möchte, dann soll er sie haben. Wenn man nur will und bereit ist den entsprechenden Aufwand zu spendieren so ist alles machbar. Ob das auch sinnvoll ist das ist vollkommen irrelevant - in der Bastelecke.

@hfichtinger: Ich denke schon das es wie angedacht funktionieren kann. Aber die schon von dir erkannte Problemstelle das du im Falle eines Hindernisses ein dauerndes AUF/ZU generierst halte ich für bedenklich. Das gibt dann nämlich nicht nur eine kleine, sondern eine ganz große Beule im Autodach. Hmm.
Ich denke du solltest falls nach einer gewissen Zeit der erwartete Zustand nicht erreicht wird die Automatik komplett abbrechen und eine Alarm auslösen. Besser ist das und spart Nerven.

Wie du siehst hatte ich auch schon mal über die Thematik nachgedacht, dann aber keine Lust mehr es auch umzusetzen.

Eine alternative Variante wäre, in dem du dem User nur vorgaukelst das es dedizierten Auf bzw. Zu Button gibt.
Sprich die Profile der Buttons entsprechend der erwarteten Fahrrichtung änderst. Im Falle eines unklaren Zustandes (der eh nur sehr selten auftritt) Alarm auslösen. Das kannst dann als Zusatzfeature anpreisen :wink:

gruß
bb

Muss sagen war komisch zu lesen. Aber denke verstanden.
Bei mir ist es ähnlich. Ich habe einen Sensor nur für Z. Alles andere ist dann auf. Mein Tor toggelt auch so.

Also wenn du auf ZU drückst fährst einfach dein Tor. Wenn dann nicht nach 30 Sek der ZU Befehl kommt, dann ist es ja in die Auf Position gefahren und gibst den schließen Befehl nochmal.

@bbernhard
Danke. Ich glaube das mit den Tastern ist etwas missverstanden worden. Die bestehenden Öffnungsmethoden gab es schon immer. Da wären ein Taster in der Garage und ein Schloss außen welches auch einen Taster bedient. Beide sind parallel geschalten und hängen am Motor. Vor etwa zwei Jahren ist ein Meross Öffner dazugekommen, der im Grunde auch nur ein potentianlfreies Relais ist und ebenso parallel hängt. Dieser soll weg und durch ein Zigbee Relais ersetzt werden.
Das mit den Fehlern wurde auch schon angesprochen und das werde ich mir überlegen.
Die Variable für das WF die zur Steuerung dient, ist eine „normale“ Variable. Die Startlogik dafür ist im Aktionskript hinterlegt. Wenn das Tor zu ist und man wählt „Schließen“ passiert … nichts. Ebenso bei ganz offen. Durch die zwei Sensoren am Anfang und am Ende gibt es noch den Zustand „Teilweise offen“. Da ich aber in IPS die Fahrtrichtung nicht steuern kann, färht das Tor einmal in irgend eine unbekannte Richtung. Am Ende kommt von einem der beiden Sensoren ein „geschlossen“ zurück. Je nach gewünschten gewählten Zustand passt das, oder es wird noch mal ein Signal an das Relais geschickt und das Tor fährt in die andere Richtung, die dann die richtige sein sollte, weil soviel Auswahlmöglichkeiten gibt es nicht. Und noch einmal, das ZigBee Relais wird NUR von IPS bedient. Eine manuelle Bedienung ist nicht vorgesehen, was aber auch egal wäre, weil es für IPS den selben Eindruck erweckt als wenn ich den Hardwaretaster in der Garage betätigte. Oder die Knöpfe am Motor direkt. Da würden höchstens die Sensoren zurückmelden, dass das Tor entweder offen oder zu ist.
Soviel Programmieraufwand wie ich ursprügnlich dachte ist es gar nicht. Etwas Logik mit den Sensoren und Vorgang einbauen und gut ist.

Da gebe ich dir recht, konnte es nicht besser beschreiben. Und ich hab mir während dem Schreiben so meine Gedanken gemacht. Ich mache es jetzt nicht Zeitgesteuert, sondern über Ereignisse die von den beiden Sensoren (sind normale Fenstersensoren) getriggert werden. Das funktioniert zuverlässig.
In der Zwischenzeit hab ich das mit dem Fehler auch einbauen können. Nach zwei Fehlerversuchen das Tor zu öffnen oder zu schließen, wird der gesamte Vorgang abgebrochen und der Motor bekommt kein Signal mehr. Inklusive Fehlermeldung über die Echos, Webfront und Log :wink:

Schon klar.
Darum meinte ich ja das es ggfls. ausreicht wenn du dem User nur vorgaukelst das er die Richtung auswählen kann.
Sprich es ist immer nur ein Button enabled - je nach Zustand deiner Sensoren.
In Wirklichkeit geben beide Buttons nur einen Impuls an das Relais, ohne weiter Logik.
Steht das Tor nicht in einer der Endpositionen d.h. die nächste Fahrrichtung ist so disablest beide Buttons und bittest nach Ablauf der typ. Fahrzeit um Kontrolle weil „Einklemmschutz ausgelöst“ oder so.
Frauen mögen das.

oder eben ohne Fake, so wie von dir angedacht.
Wichtig ist hier weiters das die Sensoren wirklich eng an den Endpositionen sitzen und exakt auslösen. Zumindest bei meinem Tor ist die ganze Mechanik recht wackelig da kann es schon mal vorkommen das nach den ersten 2-3 cm das Ding zu schwingen anfängt und dadurch der Einklemmschutz auslöst.- Allerdings erkennt das mein Sensor noch nicht (hab so wie du auch zwei) und die Logik kommt ins trudeln.
evtl. müßte man die Endlagesensoren direkt in der bestehenden Elektronik abfragen, weil nur dann bist auch synchron.

bb

Da gebe ich dir vollkommen recht. Ich simuliere die Sensoren derzeit auf meinen Schreibtisch. Die liegen da. Das Relais ist schon in IPS eingebunden aber noch nicht mit dem Motor verbunden. Ich hab mir überlegt, die Sensoren nicht ans Tor, sondern an den Schlitten der das Tor bewegt zu montieren. Also nur den einen Magneten. Die eignetlichen Sensoren dann auf die Metallschine die fest auf der Decke verschraubt ist. Da sollte theoretisch nichts wackeln.
Der Einklemmschutz sieht bei mir so aus, dass das Tor dann in die entgegengesetzte Richtung fährt. Es bleibt also nicht stehen.
Eingebaut wird am Wochenende. Dann kann ich mehr berichten.
Direkt abfragen kann ich jetzt ehrlich gesagt nicht sagen. Der Antrieb ist schon über 20 Jahre alt. Funktioniert aber noch wie am ersten Tag. Deswegen kommt auch ein Tausch nicht in Frage.

Hallo Freunde,

jetzt geb ich auch mal meinen Senf dazu. Ich habe eine sehr ähnliche Lösung mit 2 Sensoren (und einer Sicherheitsleiste, die spielt aber bei der Lösung keine Rolle).

Eine Hilfsvariable zeigt die letzte Fahrtrichtung und nordet sich bei einer vollen Öffnung oder Geschlossen wieder ein, falls mal mehrere Teilpositionen gefahren wurden (da wird stumpf die Variable gewechselt). Somit weiss ich wo das Tor hinfährt.

Dann habe ich eine Variable (+Skript) für Schließen und eins für Öffnen. Weil wenn das Tor ganz offen steht und ich öffnen möchte will ich das das Tor dort bleibt.

Eigentlich kein wirkliches Hexenwerk. Zumindest funktioniert das bei mir seit Jahren so.

lg
hagi

Mit zwei Variablen in Kombination mit den Sensoren funktioniert das natürlich auch. Eventuell erschwerend kommt bei mir noch hinzu, dass ich das Tor auch mit dem Echo öffnen und schließen möchte und da kann man nur eine Variable mit dem Shutter Profil verwenden. Man könnte natürich auch Szenen definieren, ja, aber das wollte ich nicht.
Aufgrund der Hinweise hab ich noch einen Sicherung eingebaut. Ist nach 100 Sekunden (in der Zeit schafft das Tor drei volle Fahrten) der Vorgang noch immer nicht abgeschlossen, dann wird er abgebrochen und eine Entsprechende Fehlermeldung ausgegeben. Mehr fällt mir jetzt nicht mehr ein.

Hi,
mal eine Frage aus Eigeninteresse. Welches Relais setzt Du ein? Ich hatte mir Shelly 1 (Tasmota) bestellt aber nachdem was ich gelesen habe erfüllt es nicht meinen Zweck. Ich habe mir jetzt noch " DC 12V 24V Ewelink ZigBee Relais Modul 433mhz Fernbedienung" bestellt.

Ralf

Dieses hier

Funktioniert perfekt mit Deconz und ConBeeII. Hat auch den Vorteil, zumindest für mich, dass ich ein einfaches USB Netzteil verwenden kann, von denen ich genügend zu Hause herumliegen hab.
Das ganze wird in einer Verteilerdose versteckt.

Moin,
ich habe bei mir die gleiche Schaltung, allerdings noch erweitert um einen Bewegungsmelder in der Garage (3 Minuten keine Bewegung startet den Schliessvorgang). Funktioniert seit Jahren …
Wenn ich hier aber von einer Hilfsvariablen lese, muss/kann ich wohl doch noch mal optimieren :wink: .
Mein letzter Defekt war ein kaputter BWM, da ging dann halt auch nichts mehr.

Grüße, Uwe