Neuer ioBroker-Blog online: Monatsrückblick März/April 2026

[speedy]

Hallo Leute,
ich würde gerne den Status unseres Garagentors überwachen.
D.h. aber nicht nur offen bzw. geschlossen sondern wie weit offen bzw. geschlossen.
Denn offen muss nicht immer ganz offen bedeuten. Damit könnte man das Garagentor zum Lüften auch nur 10 cm öffnen...

Ich habe mir dazu gedacht, dass man diese Information über einen "rotary encoder" abgefragt bekommt. Dazu würde ich eine NodeMCU mit einem rotary encoder verwenden. Ein passendes Zahnrad mittels 3D Druck erstellt und gut ist es.
Via MQTT werden die Informationen alle 5 Sek. od. ähnlich an ioBroker übermittelt.

Zahnrad, NodeMCU mit Befestigung sind da. Software für die NodeMCU dachte ich an ESPEasy, da diese bereits fertig verfügbar ist, jedoch viel zu langsam.
Funktioniert, wenn ich mit der Hand den Encoder drehe, aber am Garagentorriemen dann einfach nicht mehr. Ich vermute, dass hier viel zu viele Impulse kommen.

Hätte jemand eine Idee bzw. evtl. bereits eine fertige Software welche dies schaft?

[umbm]

Hast du in espeasy den generic Pulse counter als device eingerichtet oder wie ist der Impulsgeber angebunden?

Oder:
Nimm ein anderes Zahnrad, um die Anzahl der Umdrehungen zu verringern.
Oder bringe andere Sensoren am Tor an, wie z.B. Reed-Kontakte wie bei Türsensoren, die auf verschiedenen Höhen anbringen.

[Ralla66]

@speedy
Auf / Zu Position des Tores mittels Kontakt.
Rest per Laufzeit.
Warum so kompliziert ?
Unnötige Traffics würde ich eh meiden.

[speedy]

@umbm
eingebunden als generic Pulse counter
anderes Zahnrad geht leider nicht, ich muss auf die Größe achten, da es auch in der Schiene platz haben muss
Reed-Kontakte in verschiedenen Höhen wäre eine Lösung aber nicht wirklich schön

@Ralla66
Auf / Zu als Position ist gut und da zwischen per Laufzeit wäre eine Möglichkeit, aber wenn auf 80% geöffnet wird und dann auf 20% geschlossen wird, dann wird es schwierig, da ein Torantrieb eine Anlaufzeit benötigt.
Daher wollte ich die Counts zählen, aber ich denke da muss ich mich nochmals selbst an die Programmierung machen.
Dachte nur, dass es auch andere Leute gibt, die ähnliches bereits umgesetzt haben.

Dennoch danke für eure Ideen ;)

[Ralla66]

Anlaufzeit, das könnte man ja testen.
Zumal die ja immer gleich ist,
Im Programm dann Anlaufzeit als Var anlegen.
Also Anlaufzeit x ms + Reale Laufzeit Tor x sec.
Wenn du ganz clever proggst nimmste die Laufzeit immer neu.
Von Zu = 0 % nach auf 100 % = x sec als Var.
So kannste die Laufzeit immer anpassen falls die Laufschiene mal ihr Fett verliert
oder die Geschichte schwergängig wird.
Denke mal damit wärest du gut bedient, zumal auch Toleranzen mit einspielen.
Hier dein Zahnrad und die E-Geschichte.
So mit 5 % Abweichung würde ich rechnen.
Klar geht sowas besser, dann wird es meist aber teuerer.
Und mal ganz ehrlich, ob das Tor nun 3 % Prozent mehr auf / zu steht ist nicht
wirklich interessant.
Zumal dir die Möglichkeit ja bleibt das raus zu proggen.
X sec Gesamtlaufzeit + - Korrekturwert % .

[speedy]

Hi, ich denke ich werde es mal so versuchen und dann prüfen / beobachten ob ich damit zufrieden bin

[Ralla66]

@speedy
Denke gut geproggt kommst du an 1% Abweichung.
Wie immer, der Progger sitzt vor dem Bildschirm.
:-)