Unser Hoftor hat einen elektrischen Antrieb. Das kommt meiner Bequemlichkeit sehr entgegen – ein Druck auf den Schalter und schon öffnet oder schließt sich das Tor wie von Geisterhand. Allerdings bleibt die Mühsal, sich physisch zum Schalter hinzubewegen. Also habe ich noch einen mobilen Sender angeschafft, der dann idealerweise in Griffweite liegt, was er aber aus purer Bosheit natürlich nie tut. Und so muss ich auch zu diesem jedesmal hinbewegen, also nachdem ich ihn zunächst gesucht habe. Unzumutbar!

Eine Lösung muss her!

Und die beseht natürlich darin, das Ganze in Homeassistant einzubinden, damit die Toröffnung auch vom Handy aus möglich wird. Zudem eröffnet das die Möglichkeit, eine Vielzahl praktischer Automatisierungen einzurichten. Also, sobald mir welche eingefallen sind.

Im Prinzip gäbe es mehrere Ansätze. Z.B. könnte man direkt per Kabel auf die Steuerung des Torantriebs zugreifen, aber dann bräuchte ich ein Kabel dahin. Also besser per Funk. Der konkrete Torantrieb ist ein Hörmann Versamatic P und im Gegensatz zu manch anderem Funk-Protokoll haben die Entwickler hier wohl ihre Hausaufgaben gemacht und das Ganze als verschlüsselte Kommunikation mit Rolling Codes implementiert. Das ist natürlich löblich, macht aber auch dem geplagten Heimautomatisierer das Leben schwer. Die simple Lösung mit 868Mhz Sender-Modul oder RTL-SDR fällt flach. Dann eben anders: Ich habe ja noch den stets unauffindbaren Handsender: Hörmann HS5-868-bs, wobei bs hier für BiSecur steht und nicht für B***s**t.

Hardware

Ich habe hier noch ein ESP8266 board (LoLIN NodeMCU) rumliegen. Damit will ich ihn steuern. D.h. wir haben am Ende drei Komponenten:

1. nodeMCU
2. Sender
3. Spannungsversorgung

Sender

Zunächst bauen wir mal den Sender auseinander – sein Gehäuse wird er nicht mehr brauchen. Dazu entnehmen wir erstmal die Batterie (AAA) und versuchen dann das Gehäuse zu öffnen, ohne es total zu ramponieren (obwohl das eigentlich wurscht ist, aber es gibt ja auch eine Bastlerehre!). Nach gründlichem Studium der Situation schließe ich, dass man die beiden schwarzen Plastik-Halbschalen auseinander hebeln kann. Ja, das geht, aber es ist ein sch*** Gefrickel. Am Ende war das Gehäuse offen und leicht verschrammt:

Schauen wir uns mal die Platine genauer an:

Der kleine goldene Nupsie unten in der Mitte ist der Plus-Kontakt der Batterie, der Minuspol kontaktiert auf der großen Massefläche auf Rückseite unten links (die auf der anderen Seite lustigerweise mit "+" beschriftet ist ?!?).

Auf der Vorderseite finden wir den Mikrocontroller (PIC18f26k20) und einen SX1209 Tranceiver.

Nun das Multimeter anschalten und RGB-LED und Tasten ein bisschen genauer unter die Lupe nehmen. Die RGB-LED auf dem Sender ist common anode und die Pinbelegung sieht so aus:

Wie man sieht, hat der Sender fünf Tasten. Auch diese haben eine gemeinsame Anode.

Drei davon benötigen wir:

1. Up: Tor auf
2. Down: Tor zu
3. Mitte gefolgt von up oder down: Abfrage des Torstatus. Das Ergebnis wird in Form von LED Blinken übermittelt: rot heißt offen und grün geschlossen, orange zeigt einen Zwischenzustand oder ein Problem an.

Die beiden übrigen Tasten haben momentan keine zugewiesene Funktion.

nodeMCU

Aber wie "drücken" wir die nun? Eine Möglichkeit wären Relais, d.h. der ESP steuert mit je einem IO Port ein Relais. Nun liefert so ein IO Port nicht genug Strom, um ein Relais anzusteuern, aber es gibt für fast kein Geld fertige Relais Karten, die von Mikrocontrollern angesteuert werden können. Aber ich finde das wäre mit Kanonen auf Spatzen schießen, denn wir rechnen mit winzigen Strömen und dazu braucht es kein Relais. Das andere extrem wäre, die beiden Leitungen am Schalter einfach ganz direkt auf je einen IO Port des ESP zu schalten. Im Prinzip ginge das, wenn man den Ausgang im open drain Mode betreibt. So 100% sympatisch ist mir das aber nicht und ich hätte schon gerne eine Trennung zwischen ESP und Sender. Und so habe ich mich entschlossen, Optokoppler zu verwenden, wie es die Relais-Karten übrigens auch tun. So soll das dann jeweils aussehen:

Bleibt noch die Frage, wie wir die Pulse an der RGB-LED auslesen. Auch hier tendiere ich zu zwei Optokopplern. Blau interessiert uns nicht und rot und grün leiten wir dann auf die LED des PC817. Die RGB-LED löten wir aus. Und so sieht das dann aus:

Übrigens ist in beiden Fällen (Schalter und LED) auf korrekte Polung zu achten! Also vor dem Verkabeln ausmessen.

Wieviele Ports brauchen wir nun am Ende? Ich komme auf 5:

1. Taste Auf
2. Taste Zu
3. Taste Status
4. LED rot
5. LED grün

Auf den ersten Blick klingt das nach 10 Leitungen, die wir zum Sender ziehen müssen, aber wie schon oben festgestellt sind sowohl die RGB-LED, als auch die Tasten jeweils common anode. D.h. wir sparen ein paar Leitungen. Am Ende brauchen wir vier plus drei:

Tasten

1. \(+\)
2. UP
3. Down
4. Status

LED

1. \(+\)
2. R
3. G

Spannungsversorgung

Dann brauchen wir noch eine Stromversorgung. Der NodeMCU wird normalerweise per USB versorgt, also mit 5V. Er hat einen Spannungsregler (AMS1117-3.3) an Bord mit dem er dann die 3.3V für den ESP erzeugt. Der Handsender ist 1.5V gewöhnt, also brauchen wir noch einen entsprechenden Spannungsregler dafür. Ein AMS1117-1.5 wäre gut, aber den habe ich nicht vorrätig. Dafür einen LM317, den kann man auf unterschiedliche Ausgangsspannungen einstellen, indem man einen kleinen Spannungsteiler baut. Laut Datenblatt geht das so:

Hm – WTF ist \(I_{adj}\)??? Und woher soll ich den kennen? Im Datenblatt fand ich den Satz

The LM317 is designed to minimize the \(I_{ADJUST}\) current and make this current constant with line and load changes. A 100μA current from the ADJUST pin represents an error term.

Also ist er offenbar \(<100µA\). D.h. wir reden von 100µV/Ω. Das ist wohl vernachlässigbar und die meisten Leute ignorieren diesen Term komplett in ihren Berechnungen, die ich online fand. Und genau das tue ich auch, jawoll!

Also:

Wenn R1 = 240Ω wie im Datenblatt, dann muss R2 einen Wert von 48Ω haben. Allerdings ist das kein Standardwert der E24 Reihe, d.h. das habe ich nicht da. Die nächstgelegenen Standardwerte wäre 47Ω und 51Ω. Das ergibt dann entweder 1.495V oder 1.516V – der Unterschied ist in der Praxis total wurscht und wir nehmen 51Ω. Und weil mein Schaltplan auch die Steuerung des Senders enthält, heißen die beiden hier R6 und R7:

Meine Vorstellung ist, das Ganze auf einer Lochstreifenplatine (die Variante bei der ein Streifen 3 Kontakte beinhaltet) aufzubauen inklusive NodeMCU, Optokoppler und Spannungsversorgung. Die Verbindung zum Sender würde ich gerne mit einem JST-Connector machen und auch die 5V von einem Steckernetzteil über einen JST-Connector anschließen.

Also habe ich eine Weile getüftelt, wie ich die Bauteile am besten auf meiner kleinen Platine anordne, damit alles passt und schließlich alle Bauteile auf der Platine verlötet.

Zunächst habe ich die drei Komponenten noch nicht untereinander verbunden, denn ich will das schrittweise testen, damit nix abraucht. Als erstes die Spannungsversorgung. Also 5V mit dem Labornetzteil auf den Eingang legen und messen was am Ausgang rauskommt – 1.508V – was will man mehr?

D.h. ich verbinde nun alle Spannungen:

• 5V Eingangsspannung auf \(V_{in}\) am nodeMCU und dazugehörige Masse
• 1.5V und dazugehörige Masse an den Sender

Dann löte ich noch schnell die RGB-LED am Sender aus und teste, ob der weiter funktioniert. Tut er – ich kann das Tor öffnen und schließen, wenn ich den entsprechenden Tasten-Pad kurzschließe. Nun da wieder Spannung auf der Sender-Platine ist, messe ich nochmal nach, wo bei den Pads Plus und Minus ist. Wie schon oben erwähnt sind auch die Taster common anode. Hier habe ich alle Anoden mit einem roten Punkt markiert:

Firmware

Nun brauchen wir noch eine Firmware. Ich mag ESPhome für solche Anwendungen, weil es super mit Homeassistant zu verbinden, leicht zu konfigurieren und ggf. auch stand-alone verwendbar ist. Und heutzutage kennen sich die gängigen KI-System gut mit der ESPhome YAML Syntax aus, so dass man sich den Grundstock im Nullkommanix bauen lassen kann und dann nur noch ein bisschen Feinarbeit leisten muss.

Also den nodeMCU via USB mit dem Computer verbinden und ESPhome starten. Dann die Firmware compilieren und flashen.

❯ esptool --port /dev/ttyUSB1 erase-flash


❯ esptool --port /dev/ttyUSB1 write-flash -fs 2MB -fm dout 0x0 gate.bin

Zum Testen verbinden wir den Sender noch nicht, sondern messen Durchgang an den Sekundärseiten der Optokoppler, die die drei Tasten steuern sollen. Über das Web-Interface der ESPhome Firmware steuern wir die entsprechenden Switch Elemente und schauen was passiert.

Hm – irgendwas läuft hier granatenmäßig schief: Das Modul taucht nicht im Netzwerk auf. Was'n da los? Also habe ich mich in die Config und Datasheets vertieft und auch die KI geschimpft. Wie es aussieht ist das Problem, dass wir D3 (GPIO0) verwenden, denn wenn der beim Boot auf low liegt, dann geht der ESP in den Flash mode. Und genau das ist ja der fall, weil wir da indirekt einen Pull-Down Widerstand haben. Grumpf! Also raus mit dem Widerstand und erneut testen. Ja – nun kommt er hoch. Und nun kann ich auch kurzzeitig den 3V Puls an D3 messen, wenn ich das im WEB Interface triggere. Gut.

Also ändern wir das endgültig und verwenden D7 (GPIO 13) statt D3. Dazu muss sowohl der Widerstand umziehen, als auch die Leitung zum Optokoppler. Nun ergänzen wir die noch fehlenden Leitungen (Masseseite der Optokoppler) und verbinden den Sender mit unserer Konstruktion. Letzteres war ein wahnsinniges Gefrickel und erforderte beherzen Flussmitteleinsatz, eine schöne feine Lötspitze und ein Stereomikroskop. Aber nun ist alles angelötet. Zuletzt habe ich die ganzen Lötstellen noch mit je einem Tropfen UV-Lötstopplack überzogen, um sie etwas zu schützen/stärken.

Und so sieht das Ganze nun aus:

Damit ist alles fertig verkabelt und wir können den letzten Test machen: die LED-"Sensoren". Nun die Switches UP gefolgt von Status je kurz via Web-GUI betätigen und abwarten, ob das Blinken registriert wird. Hm – das funktioniert eigentlich garnicht. Also Verdrahtung und Yaml File prüfen. OK – es liegt an der Firmware: Da steht

binary_sensor:
  - platform: gpio
    id: red_pulse
    name: "Red Pulse"
    pin:
      number: GPIO12  # D6
      mode: INPUT_PULLUP
      inverted: true
    on_press:
      - lambda: |-
          id(red_pulse_count)++;

Und analog für grün. Das ist in zweierlei Hinsicht falsch:

1. INPUT_PULLUP ist falsch, denn wir verwenden einen pull-down Widerstand und zwar extern, nicht intern.
2. inverted: true ist Stuss. Wir verwenden keine invertierte Logik. .

Also ausbessern, Firmware neu compilieren und diesmal können wir via Wifi flashen, das ist bequemer. Ah – diesmal sehe ich, dass sich die Sensoren green_pulse und red_pulse den Zustand wechseln und die Werte für red_pulse_count und green_pulse_count hochzählen. Allerdings muss da noch der Moment der Nullstellung verändert werden, denn Die Zahlen sind viel zu hoch. Nachdem ich das erledigt hatte, sah es schon besser aus, aber irgendwie lief es noch nicht 100% zuverlässig und irgendwie zählte er mal 6 und mal 7 Pulse. Also zeichnen wir das mal mit dem Oszilloskop auf, damit wir das ein für allemal sauber lösen können. Zuerst bei offenem Tor, und dann bei geschlossenem:

Wie man sieht, leuchten zunächst beide LEDs (rot und grün -> orange) einmal für ca. eine halbe Sekunde. Danach kommen dann entweder 3 lange (je ca. 1/2s) rote Pulse, oder 6 kurze (je ca. 1/4s) grüne. Der orange Puls zeigt noch den Tastendruck an, ist er vorüber, kann man auf die Antwort warten. Also habe ich die Delays im YAML file so angepasst, dass das sauber passen sollte. Nun läuft das stabil.

So sieht nun die Abfrage aus:

switch:
  - platform: gpio
    id: gate_query_cmd
    name: "Query Gate State"
    pin: GPIO13   # D7
    restore_mode: ALWAYS_OFF
    on_turn_on:
      - delay: 0.5s
      - switch.turn_off: gate_query_cmd
      - delay: 0.2s
      - switch.turn_on: gate_close_cmd
      - script.execute: reset_pulse_counters
      - script.execute: evaluate_gate_state

Und so das Log:

19:48:12    [I] [gate:123] red pulses: 0
19:48:12    [I] [gate:124] green pulses: 6
19:48:12    [I] [gate:127] Gate state: CLOSED

Jetzt fehlt nur noch ein Gehäuse und das Projekt ist abgeschlossen, bis auf die Einbindung in Homeassistant, aber das ist trivial: Unter Settings > Devices & Services > ESPhome gehen, dort Add device wählen und den API-Key angeben und schon ist das Gerät aktiv. Noch die Switches und den Torstatus ins Dashboard einbinden, fertig:

Vielleicht baue ich noch ein, dass der Torstatus in regelmäßigem Abstand abgefragt wird, damit ich auch mitbekomme, wenn das Tor über den Haupttaster an der Haustür gesteuert wurde. Für heute soll es aber genügen.

Fazit

Eigentlich lief das ganz gut, auch wenn die Künstliche Ignoranz schon ein paar Probleme in die Firmware eingebaut hat. Aber letztlich konnten wir die finden und beheben. Natürlich war das jetzt nicht Rocket Science, aber einige Arbeit und eine Menge Spaß hat es dennoch gemacht und ich freue mich über das Ergebnis. Und natürlich auch darüber, dass ich mir nun lustige Spielchen mit dem Tor in Homeassistant ausdenken kann.

Und hier noch der vollständige Schaltplan und das ESPhome config file zum Download.

Wie so oft bin ich nicht der erste, der sowas macht und so bin ich mitten im Projekt auf einen Seelenverwandten gestoßen, der einen recht ähnlichen Ansatz umgesetzt hat: Turais