Yes! Ich kann endlich Apple Home Key nutzen!

IM EINSATZ?

Dann schau dir UNSEREN LOXKURS an und profitiere von unserem Wissen!

Ich hatte ja vor knapp fünf Monaten bereits einen Hilferuf verfasst, auf den sich zahlreiche Leser mit Vorschlägen gemeldet hatten, wie ich Apple Home Key nachrüsten könnte. Tausend Dank an dieser Stelle für euer Feedback! 😘😘😘

Nach diversen Fehlversuchen und Stunden des Herumfrickelns habe ich nun endlich die (vorerst) beste Lösung gefunden, um meine bestehende Zutrittslösung per Apple Home Key zu pimpen.

Am Ende war es dann doch gar nicht so schwer mit der von David empfohlenen Lösung, von der ich wirklich absolut begeistert bin. Deshalb möchte ich euch an dieser Stelle Schritt für Schritt erklären, wie auch ihr euer iPhone oder eure Apple Watch als Haustürschlüssel nutzen könnt mittels Apple Home Key.

Hier erstmal das Ergebnis, damit mach sich vorab schon mal ein Bild von Apple Home Key machen kann:

YouTube

Mit dem Laden des Videos akzeptieren Sie die Datenschutzerklärung von YouTube.
Mehr erfahren

Video laden

Benötigte Hardware für Apple Home Key

Um das von Apple genutzte NFC-Format nutzen zu können, benötigt man erstmal ein passendes Lese-Schreibmodul, welches die eingesetzten 13.56 MHz unterstützt. Genutzt habe ich am Ende den PN532-Reader (Affiliate-Link), welcher quasi am günstigsten ist und gleichzeitig auch die bautechnisch kleinste Platine besitzt, was später noch wichtig sein wird:

Um die Verbindung mit dem Rechner herstellen zu können, auf dem später die notwendige Software in Form eines Python-Scripts laufen wird, benötigt man dann noch einen günstigen FTDI-USB-Adapter (Affiliate-Link) – auch manchmal UART-Adapter genannt:

Die benötigten Jumper-Käbelchen waren sowohl beim FTDI-Adapter als auch beim PN532-Reader dabei – also doppelt – hält bekanntlich ja auch besser. Wer noch welche benötigt, holt sich am besten direkt ein Dupont Jumper Wire Set (Affiliate-Link), bei dem mehr als genug der benötigten Female-Female-Wires dabei sind.

Eine Verkabelungsskizze spare ich mir an dieser Stelle – schaut euch einfach die beiden obigen Abbildungen an, wie alles verdrahtet ist. Wobei ich sehe gerade, dass die graue und weisse Leitung relativ ähnlich aussehen – also nachfolgend doch eine kurze Skizze:

Als “Rechner” für Apple Home Key habe ich dann einfach einen uralten Raspberry Pi 2 B benutzt, der in meinem Netzwerk sowieso als MQTT-Broker fungiert.

Ihr könnt natürlich auch einen neueren Raspberry Pi 4 (Affiliate-Link) nutzen oder sonst irgend einen (alten) Linux-Rechner. Das genutzte Script würde vermutlich auch auf einem RPI 1 laufen, da es super wenig CPU-Leistung frisst.

Benötigte Software für Apple Home Key

Genutzt habe ich die von David empfohlene Freeware namens apple-home-key-reader (Github-Link) vom Entwickler kormax.

Das dort bereitgestellte python-Script, welches wir gleich auf dem RPI2 mit frisch installierten Raspberry Pi OS zum Laufen bringen werden, stellt euch ein virtuelles Schloss in der Home-App von Apple bereit, welches bei Annäherung des bekoppelten iOS-Devices (iPhone oder Apple Watch) schaltet und dann über eine “Automation” das “Objekt eurer Wahl”. Dazu später mehr…

So sieht das virtuelle Schloss – hier mit dem Namen “NFC Lock 0F0A0A” – dann am Ende in der Home-App aus:

Als Voraussetzung nutze ich also Raspberry Pi OS (externer Link), welches bequem und ohne Umwege direkt über den Raspberry Pi Imager (externer Link) auf eine Micro-SD-Karte geflasht werden kann.

Ich empfehle euch eine “Industrial Grade”-Karte einzusetzen, da diese für den Dauerbetrieb ausgelegt ist. Für solche Bastelprojekte habe ich deshalb auch immer mehrere Kingston 8GB Industrial Micro-SD-Karten (Affiliate-Link) auf Lager liegen:

8 GB reichen in diesem Fall locker aus. Aber ihr könnt natürlich auch eine größere Karte einsetzen…

Im Raspberry Pi Imager habe ich unter “OS WÄHLEN” einfach “Raspberry Pi OS (other)” -> “Rasbperry Pi OS (Legacy, 32-bit) Lite” gewählt:

Das ist für den RPI2 meiner Meinung nach die beste Wahl. Je nachdem, ob ihr einen neueren RPI einsetzen wollt und weitere Funktionen (z.B. Userinterface) benötigt, müsst ihr eben die für euch passende Variante wählen.

Mit dem Zahnrad rechts unten müsst ihr einen Haken bei der Option “SSH aktivieren” setzen und bei “Benutzername und Passwort setzen.” eben die gewünschten Login-Daten, die ihr später beim Zugriff per Terminal benötigt:

Nachdem das Image geflasht wurde und der Raspberry Pi gestartet ist, sucht ihr dessen IP-Adresse im Heimnetz und verbindet euch per SSH, damit wir die notwendige Software installieren können:

ssh pi@192.168.3.8

Ich habe es zwar schon öfter mal gezeigt, aber der Vollständigkeit halber hier nochmal… Erstmal müssen wir einige zentrale Einstellungen vornehmen:

sudo raspi-config

Unter “6 Advanced Options” muss der Punkt “A1 Expand Filesystem” ausgewählt werden, damit der gesamte Speicherplatz der SD-Karte nutzbar wird. Am Schluss wird der RPI neugestartet, sodass die getätigten Änderungen “eingespielt” werden.

Unter “5 Localisation Options” könnt ihr unter “L2 Timezone” dann noch eure korrekte Zeitzone auswählen. In meinem Fall “Europe” -> “Berlin”.

Damit das Betriebssystem auf den neuesten Stand gebracht wird, könnt ihr auch noch den nachfolgenden Befehl ausführen:

sudo apt-get update && sudo apt-get upgrade

Nach dem Neustart des System erneut per SSH einloggen und dann geht es endlich an die Installation des Home-Key-Scripts – fast…

Der per USB angeschlossene FTDI-Adapter von oben sollte mit dem Befehl

ls -la /dev/serial/by-id/

angezeigt werden im Format:

“lrwxrwxrwx 1 root root 13 Jan 25 09:49 usb-FTDI_FT232R_USB_UART_A5XK3RJT-if00-port0 -> ../../ttyUSB0”

Je nach Adapter kann das Ergebnis anders aussehen. “FTDI” und/oder “UART” sollte im Titel vorhanden sein und am Ende sollte etwas mit “/ttyUSB0” stehen. Kann auch …USB1 oder …USB2 sein. Merkt euch die Zahl am Ende – diese wird gleich noch wichtig.

Nachfolgend benötigen wir pyhton3, um die Befehle ausführen zu können. Dies sollte aber eigentlich bereits installiert sein. Das könnt ihr mit dem Befehl

python --version

prüfen. Bei mir wird dann bspw. “Python 3.11.2” angezeigt. Wenn ein Fehler angezeigt wird, könnt ihr Python mit dem Befehl

sudo apt install python3

nachinstallieren.

Jetzt geht es endlich an die Installation des Scripts, wobei wir diese in eine Art “virtuelle Umgebung” packen, was man heutzutage wohl so macht. Matthias von haus-automatisierung.com hat mich hierbei glücklicherweise supportet, da ich bei sowas nicht so wirklich fit bin. Danke dir Matthias!

Aber erstmal die Software selbst herunterladen:

wget https://codeload.github.com/kormax/apple-home-key-reader/zip/refs/heads/main

Ich musste jetzt noch git nachrüsten:

sudo apt install git

… um das gerade heruntergeladene apple-home-key-reader installieren zu können:

git clone https://github.com/kormax/apple-home-key-reader.git

Jetzt in das Verzeichnis wechseln

cd apple-home-key-reader/

Und jetzt basteln wir eine virtuelle Umgebung/Verzeichnis:

python3 -m venv my_venv
source my_venv/bin/activate

Nun lassen wir alle noch benötigten Abhängigkeiten installieren, welche das Script benötigt:

python3 -m pip install -r requirements.txt

In der Konfigurationsdatei muss jetzt noch der korrekte USB-Port für den RFID-Reader eingetragen werden:

sudo nano ~/apple-home-key-reader/configuration.json

Die Zeile mit Port habe ich entsprechend angepasst, sodass sie so aussieht:

“port”: “ttyUSB0”,

Die Datei dann mit “STRG + O” speichern und mit “STRG + X” schließen.

Wir möchten das Script natürlich dauerhaft laufen lassen – inkl. Autostart nach einem Reboot. Aber erstmal müssen wir das Script manuell ausführen, sodass wir den Pairing-Key einsehen können:

/home/pi/apple-home-key-reader/my_venv/bin/python main.py

So sollte es dann in etwa aussehen:

In meinem Fall habe ich die Home-App bereits gekoppelt, deshalb wird an dieser Stelle kein Pairing-Code mehr angezeigt. Startet ihr das Script zum ersten Mal, sollte dieser jedoch im Format 123-45-678 angezeigt werden.

Jetzt öffnet ihr am iPhone die “Home”-App und klickt rechts oben auf “+” und dann auf “Gerät hinzufügen”:

Dann wählt ihr oben “Weitere Optionen …”

Und nun sollte eine Liste von Geräten “IN DER NÄHE” auftauchen, in welcher das Schloss mit dem Titel “NFC Lock xxx” vertreten ist. Einfach anklicken und den Pairing-Key von oben eingeben. Wenn alles klappt, sollte die Konfiguration so nach 5-10 Sekunden abgeschlossen sein.

Jetzt sollte euer Schlüssel automatisch ohne weitere Zutun bei euren Karten auftauchen:

Nun könnt ihr versuchen euer iOS-Device an den Reader zu halten und beobachten, ob sich der Status des virtuellen Schlosses ändert. Dessen Status sollte abwechselnd nach einem erfolgreichen Schaltvorgang von “Aufgeschlossen” zu “Abgeschlossen” und umgekehrt toggeln.

Damit das iPhone nur kurz an den Reader gehalten und nicht vorher entsperrt werden muss, ist noch die Express-Funktion zu aktivieren, wie es auf der Apple-Website (externer Link) erklärt wird.

Dazu geht ihr auf dem iPhone in die “Einstellungen” und dann auf “Wallet & Apple Pay”. Bei “ANDERE KARTEN” sollte nun eurer digitaler Schlüssel angezeigt werden:

Hier einmal draufklicken und die “Expressfunktion” aktivieren – sofern ihr das eben möchtet:

Zum Schluss müssen wir das Script noch als Dienst hinterlegen, sodass es automatisch beim Systemstart ausgeführt wird.

Dazu schließen wir die noch von eben laufende Programmausführung erstmal mit “STRG + C”.

Jetzt bearbeiten wir mit dem nano-Editor eine neue Datei:

sudo nano /etc/systemd/system/homekey.service

Hier tragen wir folgende Infos ein:

[Unit]
Description=Apple Home Key Reader
After=syslog.target network.target

[Service]
Type=simple
User=pi
WorkingDirectory=/home/pi/apple-home-key-reader
ExecStart=/home/pi/apple-home-key-reader/my_venv/bin/python main.py
Restart=on-abort

[Install]
WantedBy=multi-user.target

Jetzt wieder mit “STRG + O” speichern und mit “STRG + X” schließen.

Mit dem Befehl

sudo systemctl enable homekey

wird das Ganze das als Systemdienst registriert und kann ab sofort auch über die Befehle

sudo service homekey start

gestartet bzw. mit

sudo service homekey stop

gestoppt werden.

Mit dem Befehl

sudo service homekey status

lässt sich der aktuelles Status abfragen.

Wer den Dienst wieder komplett “killen” möchte, gibt “sudo systemctl disable homekey” ein.

Aus meinem täglichen Leben

Das Ganze lief jetzt bereits seit einigen Tagen im Testbetrieb bei mir auf dem Schreibtisch absolut zuverlässig, sodass ich mich gestern entschieden habe die Installation produktiv für die Haustürsteuerung umzubauen.

Dazu musste ich erstmal meine Loxone Intercom aus dem selbstgedruckten Rahmen entfernen:

Dummerweise konnte ich meinen Minisaugnapf nicht finden und musste deshalb ein neues Handy Reparaturset (Affiliate-Link) bestellen, um die Intercom bzw. das NFC-Tastaturfeld aus dem Rahmen ziehen zu können. Da ich am Ende dann doch nicht warten konnte, bis das Set zugestellt wurde, habe ich kurzerhand ein bisschen Heisskleber auf die Oberfläche aufgetragen und aushärten lassen – und dann eben einfach daran gezogen…

Für die Verkabelung zum etwa sechs Kabelmeter entfernten Netzwerkschrank habe ich das vorhandene RJ45-Netzwerkkabel hergenommen, an dem bereits die Loxone Intercom mit vier Adern angeschlossen ist (zwei Adern für Strom und zwei Adern für Daten). Die anderen vier Adern des Netzwerkkabels habe ich dann genutzt, um die USB-Verbindung zwischen Raspberry Pi und FTDI-Adapter herzustellen.

Nachfolgend sieht man die Verkabelung mit Hilfe eines USB-Schraubanschluss-Terminal-Adapters (Affiliate-Link), da ich die Verdrahtung maximal flexibel gestalten wollte – und auch nicht auf Anhieb wusste, wie die Leitungsbelegung aussieht:

Die Belegung ist in meinem Fall:

AdapterNetzwerkkabel
– (GND)Braun/Weiss
D+Blau
D-Blau/Weiss
+ (VCC)Braun

Aber die Belegung kann bei euch natürlich auch abweichen. Am besten per Multimeter (Affiliate-Link) nachmessen, um sicherzustellen, dass es passt.

Auf der anderen Seite im Netzwerkschrank habe ich dann einen LAN-Splitter (Affiliate-Link) genutzt, da ich “minimalinvasiv” vorgehen wollte. Der LAN-Splitter ist der “rote Kasten”:

Das graue Netzwerkkabel links hängt dabei am Netzwerkport, welcher nach draussen zum Hauswandausschnitt mit der ganzen Technik führt.

Das grüne Netzwerkkabel am roten LAN-Splitter (Anschluss 2) geht auf einen PoE-Port meines UniFi-Switch und versorgt die Loxone Intercom – ohne jegliche Anpassung wie vorher auch. Hier benötigt man eben nur vier Adern, die über den Splitter aufgeteilt werden.

Das orangene Netzwerkkabel am Lan-Splitter (Anschluss 1) führt dann über einen weiteren USB-Schraubanschluss-Terminal-Adapters (Affiliate-Link) an den USB-Port des Rasperry Pi, welcher im Netzwerkschrank hängt:

Hier sieht die Belegung bei mir folgendermaßen aus:

AdapterNetzwerkkabel
– (GND)Grün/Weiss
D+Orange/Weiss
D-Orange
+ (VCC)Grün

Den Raspberry Pi 2 betreibe ich übrigens direkt per PoE-MicroUSB-Splitter (Affiliate-Link) an meinem UnifFi-Switch, sodass ich hier kein extra Netzteil benötige.

Den PN532-Reader wollte ich erst hinter der vorhandenen Intercom installieren. Das klappt auslesetechnisch aber nicht, da die Intercom das NFC-Signal zu sehr abschirmt. Deshalb habe ich mich kurzerhand dafür entschieden den Reader “unterputz” oberhalb des Wandausschnittes zu installieren:

Also quasi einfach von unten nach oben direkt zwischen Außenputz und dahinterliegender Dämmung reingeschoben. Vorher habe ich mit dem Schraubendreher etwas Dämmung “rausgepopelt”, dass eben genug Platz für den Reader ist. Hier sieht man die vier Leitungen vom NFC-Reader nach unten raushängen…

Das Gehäuse vom Wandausschnitt musste ich hier etwas ausschneiden, aber wozu hat man das gute alte Bosch Multitool (Affiliate-Link)… 😀

Und nun wieder die Blende einsetzen und die ganze Verkabelung “verstecken”. Zum Glück ist für alles mehr als genug Platz:

Am Ende dann einfach das iPhone an die richtige Stelle halten und schwupps:

Da ich die Home-Key-Funktion in Loxone nutzen möchte, um das dort angeschlossene Türschloss zu triggern, habe ich dann über Homebridge (externer Link) einen virtuellen Loxone-Schalter in die Home-App geschupst und dann einfach per Home-“Automation” gesagt, dass ein “Aufschließen” des “NFC Lock” den virtuellen Schalter namens “Haustür” in Loxone einschaltet:

In Loxone habe ich nach dem virtuellen “Haustür”-Schalter dann einen verzögerten Impuls, der den Schalter 3s nach Aktivierung wieder ausschaltet:

Der Schalter in Loxone triggert bei Aktivierung dann mein eigentliches Motorschloss, um meine Haustür zu öffnen. Das sieht man an dieser Stelle nicht…

Und zum Schluss noch eine Home-“Automation”, um das “NFC Look” wieder abzuschließen, sobald der Loxone-Haustür-Schalter einschaltet (also quasi direkt in dem Moment, wenn er vom NFC-Schloss getriggert wird):

Mit diesem Vorgehen stelle ich sicher, dass die Steuerung dauerhaft zuverlässig funktionieren sollte, auch wenn einmal eines der Systeme neustartet oder zwischenzeitlich “abkackt”. Sobald alle Geräte wieder verfügbar sind, sollte sich alles wieder “synchronisieren”. Und auch sollte so sichergestellt sein, dass die Tür nicht aus Versehen bei einem Neustart eines der Systeme (RPI oder Loxone Miniserver oder Homebridge) geöffnet wird.

Und ja ich weiss, Loxone lässt sich eigentlich auch nativ per Homekit in Apples “Home”-Universum integrieren (also ohne Umweg per Homebridge). Das hat bei mir aber noch nie zuverlässig funktioniert und ist mir zudem auch zu unflexibel. Aber das ist wieder ein anderes Thema.

Und für alle, die sich fragen, weshalb ich die USB-Verbindung zwischen der Unterputzdose und meinem Netzwerkschrank verlängert habe und nicht die serielle Verbindung zwischen Reader und FTDI-Adapter: USB lässt sich easy auf 5m verlängern, in meinem Fall sind auch 6m kein Stress. Hingegen lässt sich die serielle Verbindung zwischen Reader und FTDI zuverlässig wohl nur bis etwa 50cm betreiben. Achja – und der RPI sollte am Ende auch im Netzwerkschrank bleiben – also nicht im Wandausschnitt. Diese Option schied deswegen auch aus.

Zum Schluss nochmal ein dickes DANKESCHÖN an David, der mich mit seinem Kommentar erst auf die oben gezeigte Lösung gebracht hat und an Matthias von haus-automatisierung.com, der mich bei der softwareseitigen Umsetzung supportet hat.

Ich werde das fertige Ergebnis die kommenden Tage auch noch einmal per Video zeigen, damit man einen Eindruck davon bekommt, wie smooth das Ganze läuft… Ich bin wirklich begeistert!

UPDATE VOM 31.01.2024: Hier ist das versprochene Video:

YouTube

Mit dem Laden des Videos akzeptieren Sie die Datenschutzerklärung von YouTube.
Mehr erfahren

Video laden

YouTube-Direktlink

Jedenfalls bin ich gespannt, wie stabil das jetzt läuft bzw. wie der WAF so ausfallen wird. Solange es kein Gemecker gibt, sollte alles passen. Ach – in dem Kontext fand ich es übrigens krass, dass einfach alle per Home-App gekoppelten Endgeräte – auch die meiner Frau – automatisch mit dem Home-Key “Hallbude” ausgestattet wurden und adoc funktionierten. Sicherheitstechnisch sollte man sich also im Klaren sein, dass jeder User, der auf euer “Home”-Zuause Zugriff hat, auch den virtuellen Schlüssel erhält.

Wie sicher oder unsicher das Ganze am Ende ist – unabhängig von der Home-Sharing-Funktion -, weiss ich leider auch nicht. Klärt mich gerne per Kommentar auf, was ihr von der Lösung haltet…

PS: Verdammt, jetzt müsste ich mir fast schon eine neue Apple Watch Ultra (Affiliate-Link) holen – denn meine alte Watch ist echt am Ende.

Wenn die Ultra nur nicht so teuer wäre… 😭😭😭

46 Kommentare
  1. Hey Jörg,
    mal wieder vom allerfeinsten! Vielen Dank für den klasse Blogeintrag.

    Ich hoffe schwer dass sich mit iOS 17.4 in Bezug auf NFC was bewegt und evtl. Loxone die nötigen Rechte bekommt und es somit endlich nativ bereitstellen kann.
    Ansonsten werde ich mich auch an die von Dir vorgestellte Lösung machen.

    Vielen Dank und liebe Grüße
    Stef

    1. Danke! 🙂

      Ist da was mit 17.4 geplant?

      Loxone könnte es hardwareseitig ja ohne Probs mit dem NFC Code Touch. Aber ob das softwareseitig “so schnell” was wird?! Ich wage es zu bezweifeln. Bin Anfang Februar bei Loxone zu Gast und hake dort auch mal nach, was da geplant ist. Wäre nen ultra Alleinstellungsmerkmal…

      Auch wenns mit Loxone doch wirklich bald was werden sollte, find ich die Lösung hier immer noch interessant – zumindest für den Schuppen oder Ähnliches.

      Viele Grüße
      Jörg

  2. Hallo Jörg,
    wow ich hätte nicht gedacht, dass das so funktionniert – Cheapeau.
    Bei der Lösung muss man allerdings technisch schon gut versiert sein, ich würde mich da so nicht alleine rantrauen.
    Vielleicht ist ja ein Loxberry-Plugin ein guter Schritt um es zu vereinfachen. 🙂
    Das Thema Verlängerung der Leitung kann örtlich natürlich zu Herausforderungen führen, evtl. gibst da künftig ja was in Richtung Wireless, so dass man nur Strom benötigt.
    So oder so ein sehr feines Projekt, was du da umgesetzt hast.

  3. ich hab’s technisch auch noch nicht so ganz überrissen, aber glaube NFC macht bisher Probleme wenn die Gegenstelle (in dem Fall der CodeTouch) den Token nicht abgleichen kann, bzw. die nötige Zertifizierung fehlt. Gefährliches Halbwissen, aber so in der Art.
    Das könnte sich evtl. erleichtern. Ich hoffe sehr – denn mir geht’s wie Dir – bin schlüssellos unterwegs und ärgere mich immer wieder dass ich den NFC vom CodeTouch nicht mit dem iPhone/Watch benutzen kann.
    Hier der offizielle Apple Post:
    https://developer.apple.com/support/dma-and-apps-in-the-eu

    Viele Grüße, auch an die Loxonies – hoffen wir mal das Beste 😉

  4. Bei mir ist momentan noch das Problem, dass meine UV ca. 10m von der Sprechstelle sitzt. Das dürfte wohl kaum gut gehen.
    Ob das wohl mit irgendeiner Att von Wandler oder so geht?
    USB over TCP oder sowas in der Art? Netzwerk hätte ich bei der Sprechstelle, oder könnte auch noch was nachziehen..

  5. Ich dachte daran, sowas hier hinter der Sprechstelle zuplatzieren:

    https://de.aliexpress.com/item/32928307523.html

    Falls das überhaupt geht. Und dann müsste das Signal ja am Pi wieder von IP zurück übersetzt werden auf eine (virtuelle?) Sxhnittstelle?

  6. Mega, vielen Dank für die Anleitung!
    Denkst du man bekommt es auch irgendwie mit einem ESP32 (oder ähnlichem) zum Laufen? Raspi ist ja fast schon overkill 😀

    1. Danke nochmal für deinen Blog!
      Habe es auf einem Raspi Zero W zum Laufen gebracht 🙂 Bin schon ewig auf der Suche nach einer Lösung mit HomeKey gewesen.
      Jetzt muss ich das nur noch irgendwie an Haustüre bekommen 🙂

  7. Hi Jörg,
    könntest du bei Gelegenheit einige Details/Erfahrungswerte über den Türantrieb schreiben, dass sieht sehr interessant aus.
    Danke dir.

    1. Hi Thomas,

      gerne. Wollte eigentlich schon seit paar Jahren ausführlicher über den Schwingtürantrieb bloggen, da ich das Teil echt cool finde. Ist hiermit wieder auf der Agenda. 🙂
      Aber so kann ich zumindest auch meine Langzeiterfahrung teilen…

      Es handelt sich konkret um einen Dorma Porteo (externer Link), der zwar nicht ultra günstig ist, aber nach ein paar Jahren immer noch super funktioniert. Bisher ohne jeden Ausfall. Hatte da anfangs etwas Angst, aber die Technik scheint ausgereift zu sein. Das Teil wird – wie ich es verstanden habe – primär auch im gewerblichen Umfeld eingesetzt, von daher kann man da auch etwas mehr erwarten.

      Der Dorma Porteo ist im Grunde “stinkdoof”, kann aber glücklicherweise extern über ein potentialfreies Relais zum Aufschwingen bewegt werden – also über die Smart-Home-Zentrale (Loxone) gesteuert. Ein kurzer Impuls und die Tür schwingt auf. Vorausgesetzt natürlich die Haustür ist nicht verriegelt. Entsprechend hat es etwas an Finetuning gekostet, das über Loxone timingtechnisch so hinzubiegen, bis es reigungsfrei läuft. Ist in meinem Fall ein Zusammenspiel aus im Türrahmen integriertem Motortürschloss (KFV AS 2600), einem fest verbauten Reed-Kontakt und dem Dorma Porteo. Wenn die Tür öffnen soll, entriegelt erst das Motortürschloss und sobald der Reed-Kontakt meldet, dass die Tür einen Spalt geöffnet ist, bekommt der Schwingtürantrieb den Impuls, um die Tür komplett zu öffnen.

      Wenn man Tür jetzt offenhalten möchte, sendet man glaube ich alle 30s einen weiteren kurzen Impuls zum Porteo. Bleibt der Impuls aus, schließt die Tür – ich glaube nach genau 60s. Wenn man die Tür sofort schließen möchte, gibt man einen Doppelimpuls (innerhalb von 200ms oder sowas glaube ich). Der Antrieb erkennt dabei (auch beim Öffnen), ob etwas den Weg versperrt und stoppt dann instant, ohne dass man irgendwas – oder sich selbst – einquetschen würde. Beim Schließen gibt es auch eine Option, die man am Porteo über einen kleinen Dip-Schalter aktivieren kann, damit dieser kurz vor dem Zuziehen der Tür nochmal “Gas” gibt, sodass ein etwaiger kleiner Widerstand der Türdichtung überwunden werden kann. Habe ich auch aktiviert – und das hört man im Video auch durch das “Knallen” der Tür beim Schließen. Akustisch aber nicht stressig. Läuft normal auch ohne die Option aber gerade bei Sturm reicht der Luftstrom ins Haus (wenn die Terrassentür bspw. geöffnet ist) aus, damit die Tür dann nicht ganz schließt – zumindest nicht zuverlässig. Und das ist dann eben fail…

      Insgesamt finde ich den Porteo super praktisch, insbesondere wenn er eben nahtlos ins Smart Home integriert ist. In meinem Fall schließt die Tür dann beim Eintreten automatisch, wenn sich niemand mehr für 20s oder so im vorderen Dielenbereich aufhält – hier sind zwei Präsenzmelder verbaut, die mehrere Präsenzzonen auswerten können. Meine Frau findet den Porteo im Winter aber kacke, da die Haustür durch die Automatik einfach länger offen bleibt als per “Handbetrieb”. Dadurch geht mehr Wärme verloren und es “zieht”, wenn man in der Küche steht. Aktuell deaktiviere ich den Porteo deshalb an seinem Ein-/Ausschalter einfach im Winter. Dann lässt sich die Tür “ganz normal” öffnen und schließen – ohne merkbaren Widerstand. Einen leichten Widerstand gibt es, aber den finde ich sogar praktisch, da die Tür einfach in der Position verleibt, in der man sie losgelassen hat (auch halb geöffnet) – auch wenn es windig ist. Ich werde den Stromanschluss des Porteo demnächst aber über ein weiteres Relais schaltbar machen, um ihn dynmaisch aktivieren zu können. Anschlusstechnisch super easy, da alle Kontakte des Porteo sowieso auf Reihenklemmen im Schaltschrank “abgreifbar” sind. Hier benötige ich dann aber noch eine zusätzliche Softarelogik in Loxone, da der Porteo beim Einschalten des Stroms erstmal komplett schließt und dann direkt einmal komplett öffnet. Zu diesem Zeitpunkt muss dann das Türschloss entriegelt sein, sonst ersucht er einige Sekunden mit “Kraft” die Tür zu öffnen, was eben nicht klappt. Dann gibt er auf – konnte seine “Kontrollfahrt” dann aber nicht abschließen. Aber ist mit Loxone auch lösbar…

      Achso – der Türantrieb ist auch mega praktisch, wenn man nicht Zuhause ist und bspw. die Nachbarn oder den Paketboten (muss man natürlich vertrauen können, klar) kurz mal reinlassen möchte und der Porteo am Ende dann sicherstellt, dass die Haustür auch sicher wieder verschlossen und nicht nur angelehnt ist.

      Soviel erstmal zu dem, was mir spontan so dazu einfällt. Wenn du weitere Fragen hast, melde dich einfach…

      Viele Grüße
      Jörg

    2. @Jörg klasse schon mal vielen Dank für den ausführlichen Input. Das klingt nach vielen Vorteilen, allein dass etwas mehr Widerstand da ist … wie oft fliegt hier die Haustür zu, wenn die Terrassentür auf ist.
      Ich hab nach oben leider nur 5 cm Luft, da müsste ich etwas von der Brüstung wegnehmen. Stromzufuhr ist auch nicht an Ort und Stelle, müsste daher Aufputz verlegt werden – also schon etwas Aufwand.
      Mein größter Punkt, wir haben ein GU Halbautomatik Schloss, sprich die Verriegelung wird elektrisch zurückgezogen, aber dann gibt es eine Art Schnapper (wie in Geschäften), der vom Türantrieb krafttechnisch überwunden werden muss.

    3. Ach ja ich bin bei meiner Recherche immer über diesen Antrieb gestolpert:
      https://www.hoermann.de/private-bauherren-und-modernisierer/antriebe/innentuer-antriebe/

  8. Bezüglich ESP:
    Gleiches gilt auch für den Raspberry Pi Pico. Auf beiden läuft prinzipiell MicroPython, was ja prinzipiell das Ausführen des Skriptes erlauben sollte.

    Ich sehe da eher die Schwierigkeit, das Github Repo einzubinden auf solchen Embedded Devices. Da ist das auf dem “normalen” Pi schon deutlich einfacher…

  9. Hallo Jörg,
    super Anleitung genau das was ich schon lange suche.
    Bin gerade dabei einen Testaufbau zu machen. Allerdings erhalte ich beim Start:
    sudo /home/pi/apple-home-key-reader/my_venv/bin/python main.py
    Folgenden Fehler:
    Traceback (most recent call last):
    File “main.py”, line 8, in
    from accessory import Lock
    File “/home/pi/apple-home-key-reader/accessory.py”, line 6, in
    from service import Service
    File “”, line 1
    (endpoint=)
    ^
    SyntaxError: invalid syntax

    Kann aber die Datei fstring nicht finden. Hast du eine Ahnung?
    Gruß Josef

    1. hier ging wohl ein Teil verloren.

      from service import Service
      File “”, line 1
      (endpoint=)
      ^
      SyntaxError: invalid syntax

    2. 👍 Schreib gerne nochmal – auch wenn es jetzt funktioniert. Welche Hardwareplattform du nutzt und wie performant alles läuft…

      Viele Grüße
      Jörg

  10. Hallo Jörg, habe das System ganz neu aufgesetzt.
    Raspberry Pi 2 Model B Rev 1.1
    16GB Karte

    Bin jetzt soweit gekommen, dass ich in der HomeApp bei Gerät hinzufügen “NFC Lock XXXXXX” angezeigt wird.
    Nicht zert…. weiter und beim Konfigurationscode kann ich zwar 12345678 eingeben aber das Format sieht so aus 1234-5678 nicht wie du schreibst 123-45-678. Ich kann auch die Bindestriche nicht eingeben.
    Anschließend erhalte ich die Meldung Konfigurationscode falsch.
    Hast du eine Idee?

    Liebe Grüße
    Josef

    1. Nachtrag wo wird dieser Code eingegeben?
      Steht auf dem Terminal.

      To use the QR Code feature, use ‘pip install HAP-python[QRCode]’
      Enter this code in your HomeKit app on your iOS device: xxx-xx-xxx

      Brauche ich dafür auch eine Homebridge?

    2. Kann sein, dass ich in der Home-App auf dem iPhone am Ende auch diese andere Möglichkeit zur Einbindung genutzt habe: Gerät hinzufügen -> Weitere Optionen -> Mein Gerät wird hier nicht angezeigt -> Code eingeben. Müsste ich selbst nochmal ausprobieren. Auf einem der Wege mit manueller Eingabe des Codes lief es jedenfalls durch.

      Werde ich die kommenden Tage auch nochmal testen, da ich ohnehin noch ein Howto-Video davon machen wollte. Dann kann ich es sicher sagen, wie es läuft.

      Viele Grüße
      Jörg

    3. Dann warte ich mal dein Howto und begebe mich in den Urlaub. Du wirst sicher wieder etwas von mir hören. Ob es läuft oder nicht.
      Schönes Wochenende

  11. Großartig! Habe das bei mir auf einem Pi Zero W laufen, funktioniert praktisch verzögerungsfrei in Richtung HomeKit. Übrigens auch unter Python 3.12.2 (das Kompilieren der Version auf dem PI Zero brauchte allerdings Stunden ;-)).

    Dann steht noch der Einbau in Türnähe an. Zum Öffnen der Tür werde ich zunächst einen simplen elektrischen Türöffner via HomeKit-Steckdose & Automation anbinden. Dazu muss dann noch ein Kurzbefehl in HomeKit gefrickelt werden, der das NFC Schloß zeitverzögert wieder abschließt und auch den Türöffner nur begrenzte Zeit summen lässt. So zumindest der Plan.

    Danke für die perfekte Beschreibung und diese tolle Anregung!

  12. Kurze Ergänzung noch: Auf einem langsamen PI (wie meinem Zero W) startet der HomeKey-Service bereits bevor das (WLAN-) Netzwerk verbunden ist und bricht sofort ab. Diese Anpassung der /etc/systemd/system/homekey.service behebt das Problem:

    [Unit]
    Description=Apple Home Key Reader
    #löschen: After=syslog.target network.target
    #nachfolgende 2 Zeilen hinzufügen:
    Wants=network-online.target
    After=network-online.target

    [Service]
    Type=simple
    User=pi
    WorkingDirectory=/home/pi/apple-home-key-reader
    ExecStart=/home/pi/apple-home-key-reader/my_venv/bin/python main.py
    Restart=on-abort

    [Install]
    WantedBy=multi-user.target

    Grüße!
    Nils

  13. Hallo,
    ich habe ebenfalls schon sehr lange auf so eine Lösung gewartet. Eigentlich habe ich immer auf eine “out-of-the-box”-Lösung gewartet, aber je mehr ich drüber nachdenke, umso mehr gefällt es mir hier etwas tiefer einsteigen zu müssen!

    Eine Frage jedoch zum Aufbau von einem RP-Neuling:
    Warum verlängerst Du nicht das UART-Signal / -Kabel (sondern bridged zuerst auf USB und verlängerst das)?

    PS: Mein Motor-Schloss ist ein Mediator von Effeff /Assa-Abloy mit 3-Punkt-Verriegelung. Vielleicht für den einen oder anderen auch einen Blick wert …

  14. Hi,

    I successfuly integrated this HW NFC reader to Homekit and everythings work. But I have no idea, how to connect this NFC reader to Loxone.

    In Loxone, I have my electric door lock, but how I can read a NFC reader status in Loxone? It is possible only with homebridge?

    Thank you!

  15. Gerade mal nachgebaut – klappt super. Vielen Dank! 🙂

    Ein kleiner Fehler in der Anleitung: beim Erstellen des Image wird im Screenshot der Nutzer “admin” angelegt – später aber immer mit dem Standard-Nutzer “pi” gearbeitet. Das sollte natürlich aufeinander abgestimmt sein.

  16. Hallo,

    vielen Dank, tolles Tutorial und wirklich die Lösung, auf die ich auch gewartet habe. Habe schon mal die Komponenten besorgt und das Ganze läuft auch super (Ich hatte irgendwie einen FTDI, der nicht erkannt wurde bzw. für den kein ttyUSBx angelegt wurde. Nach 2 Stunden Fehlersuche, habe ich noch einen alten im Keller gefunden und es ging direkt…). Nun muss ich es noch draußen einbauen. Daher interessiert mich die Frage von Jan-Hendrik auch. Ich habe noch freie Buskabel und wollte die nutzen, um die Verbindung zwischen RFID-Leser und FTDI zu verlängern. Gibt es grundsätzlich Erfahrungen mit den maximalen Längen?
    Zusätzlich würde ich gerne zwei Schlösser (Haustür und Schuppen) mit zwei Lesegeräten steuern. Wie muss man da vorgehen, um auf einem Raspi zwei Schlösser zu erstellen?
    Viele Grüße
    Bob

  17. Hallo Jörg,
    so mit neuer Hardware funktioniert es zumindest soweit, dass in der Apple Home App das Schoss erkannt wird und auch schalten lässt.
    Da ich noch nicht Loxone verwende sondern noch auf Fhem bin habe ich Probelem mit der Automatisation. In Fhem habe ich 2 Dummy erstellt und über Homebride in die Home-App integriet. In welcher App kann ich deine vorgeschlagen Automatisation erstellen bzw die Dummy-Schalter mit dem Homekey verbinden?
    Danke für deinen Tipp.

    Gruß aus dem sonnigen Süden
    Josef

  18. Gibt es eiwgntlich eine Lösung, um gleichzeitig zum Homekey auch noch RFID TAGS am Leser zu nutzen?
    Schwiegereltern etc., die nicht in unserem Apple Home sind, hätten so Zugang.
    Müsste sicher parallel noch ein zweites Skript auf dem Device hinter dem Leser laufen?

    1. Ich bin gerade selbst einer möglichen Löwung auf der Spur. Im Repo für die ESP Variante steht:

      Any NFC Target that’s not identified as homekey will skip the flow and publishes the UID, ATQA and SAK on the same Authentication MQTT topic

      Somit könnte ich die Tags wohl per MQTT abgreifen.

      Oder im Zweifelsfalls noch parallel einen ESP anschließen, der dann nur die Tags liest. SPI müsste ja one-to-many können.

  19. Hallo,

    ich habe ein totales Verstöndnisproblem. Wenn ohnehin ein virtueller Schalter in Homekit interlegt wird, wieso dann nicht einfach ein NFC-Tag welcher in der Home App den virtuellen Schalter auf true setzt.

    Wo ist der da Unterschied?

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Das könnte dir auch gefallen