Yes! Ich kann endlich Apple Home Key nutzen!
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:
Mit dem Laden des Videos akzeptieren Sie die Datenschutzerklärung von YouTube.
Mehr erfahren
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.8Ich habe es zwar schon öfter mal gezeigt, aber der Vollständigkeit halber hier nochmal… Erstmal müssen wir einige zentrale Einstellungen vornehmen:
sudo raspi-configUnter “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 upgradeNach 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 --versionprü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 python3nachinstallieren.
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/mainIch 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.gitJetzt 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/activateNun lassen wir alle noch benötigten Abhängigkeiten installieren, welche das Script benötigt:
python3 -m pip install -r requirements.txtIn der Konfigurationsdatei muss jetzt noch der korrekte USB-Port für den RFID-Reader eingetragen werden:
sudo nano ~/apple-home-key-reader/configuration.jsonDie 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.pySo 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.serviceHier tragen wir folgende Infos ein:
[Unit]
Description=Apple Home Key Reader
Wants=network-online.target
After=network-online.target
[Service]
Type=simple
User=pi
WorkingDirectory=/home/pi/apple-home-key-reader
ExecStartPre=/bin/sleep 10
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 homekeywird das Ganze das als Systemdienst registriert und kann ab sofort auch über die Befehle
sudo service homekey startgestartet bzw. mit
sudo service homekey stopgestoppt werden.
Mit dem Befehl
sudo service homekey statuslä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:
| Adapter | Netzwerkkabel |
| – (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:
| Adapter | Netzwerkkabel |
| – (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:
Mit dem Laden des Videos akzeptieren Sie die Datenschutzerklärung von YouTube.
Mehr erfahren
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… 😭😭😭
70 Kommentare
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
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
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.
Joa – ich bin froh, dass es so schon mal sauber läuft. Optimierungspotenzial gibt es immer, klar…
Viele Grüße
Jörg
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 😉
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..
Es gibt wohl TTL/FTDI-to-Ethernet-Adapter. Damit könnte es eigentlich laufen – ohne Gewähr… 😀
Bei mir ist die UV tatsächlich auch knapp 10m weg. Und zu meiner Überraschung funktioniert es gut.
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?
Ja genau – sowas meinte ich 😀
Geil, das muss ich nachbauen!
Vielen Dank für die ausführliche Anleitung.
Hehe, gerne!
Dir viel Erfolg bei der Umsetzung!
Viele Grüße
Jörg
Ich hatte vor lauter Freude auch vergessen, mich zu bedanken! Du hast das Thema sehr schön und strukturiert zusammen gefasst!
Kein Ding. Gerne! 🙂
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 😀
Gerne!
Geht sicher auch mit nem ESP32 – braucht man “nur” die passende Software… 😂🫣
Ein Raspberry Pi Zero (2) (Affiliate-Link) könnte auch eine gute Möglichkeit sein.
Jup!
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 🙂
@Stefan das interessiert bestimmt einige … zB mich. 🙂
Hi Jörg,
könntest du bei Gelegenheit einige Details/Erfahrungswerte über den Türantrieb schreiben, dass sieht sehr interessant aus.
Danke dir.
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
@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.
Ach ja ich bin bei meiner Recherche immer über diesen Antrieb gestolpert:
https://www.hoermann.de/private-bauherren-und-modernisierer/antriebe/innentuer-antriebe/
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…
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
hier ging wohl ein Teil verloren.
from service import Service
File “”, line 1
(endpoint=)
^
SyntaxError: invalid syntax
Denke habe den Fehler gefunden. Falsche Pythen version.
👍 Schreib gerne nochmal – auch wenn es jetzt funktioniert. Welche Hardwareplattform du nutzt und wie performant alles läuft…
Viele Grüße
Jörg
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
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?
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
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
Gibt übrigens jetzt auch eine ESP32 Implementierung 🙂
https://github.com/rednblkx/HomeKey-ESP32
Cool. Danke für die Info!
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!
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
Danke dir! Habe den Code oben angepasst…
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 …
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!
Hi Jan!
Homebridge is the key in this case, true.
Best regards
Jörg
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.
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
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
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?
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.
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?
Hi,
vielen Dank für das Tutorial. Genau nach sowas habe ich gesucht! Ich werde mich demnächst mal dran wagen, allerdings ist mir aufgefallen, dass der verlinkte FTDI-USB-Adapter nicht mehr verfügbar ist. Hast du da einen anderen Affiliate Link für mich?
Beste Grüße,
Chung
Moin Jörg,
danke für die mega Anleitung!!! Hab es direkt umgesetzt und liebe es – auch wenn ich “nur” ein Nuki damit ansteuere.
Allerdings hab ich so mein Problem mit dem Autostart und weiß nicht recht, wieso. Ich aktiviere ihn wie beschrieben und erhalte nach dem Neustart vom Pi nur folgende Meldung:
michael@raspberrypi-test:~ $ sudo service homekey status
× homekey.service – Apple Home Key Reader
Loaded: loaded (/etc/systemd/system/homekey.service; enabled; preset: enabled)
Active: failed (Result: exit-code) since Wed 2024-03-06 12:09:33 CET; 12s ago
Duration: 2.400s
Process: 707 ExecStart=/home/michael/apple-home-key-reader/my_venv/bin/python main.py (code=exited, status=1/FAILURE)
Main PID: 707 (code=exited, status=1/FAILURE)
CPU: 926ms
Mar 06 12:09:33 raspberrypi-test python[707]: driver = AccessoryDriver(port=config[“port”], persist_file=config[“persist”])
Mar 06 12:09:33 raspberrypi-test python[707]: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Mar 06 12:09:33 raspberrypi-test python[707]: File “/home/michael/apple-home-key-reader/my_venv/lib/python3.11/site-packages/pyhap/accessory_driver.py>
Mar 06 12:09:33 raspberrypi-test python[707]: address = address or util.get_local_address()
Mar 06 12:09:33 raspberrypi-test python[707]: ^^^^^^^^^^^^^^^^^^^^^^^^
Mar 06 12:09:33 raspberrypi-test python[707]: File “/home/michael/apple-home-key-reader/my_venv/lib/python3.11/site-packages/pyhap/util.py”, line 52, >
Mar 06 12:09:33 raspberrypi-test python[707]: s.connect((“8.8.8.8”, 80))
Mar 06 12:09:33 raspberrypi-test python[707]: OSError: [Errno 101] Network is unreachable
Mar 06 12:09:33 raspberrypi-test systemd[1]: homekey.service: Main process exited, code=exited, status=1/FAILURE
Mar 06 12:09:33 raspberrypi-test systemd[1]: homekey.service: Failed with result ‘exit-code’.
lines 1-18/18 (END)
Kann damit leider nicht wirklich was anfangen… Hast du einen Tipp?
Fehler selbst gefunden …
Wenn ich beim Startscript folgendes ändere, klappt es auch nach einem harten Neustart.
After=network-online.target
Viele Grüße
Michael
leider habe ich trotz der Änderungen im Autostart-Script noch immer das Problem, dass der Autostart nicht klappt. Genau wie bei die beschrieben ist das Netzwerk noch nicht erreichbar beim Start,
Kann man das nochmal weitere Sekunden verzögern?
Hab es hinbekommen. Folgende Zeile hab ich vor ExecStart hinzugefügt um 10s zu verzögern:
ExecStartPre=/bin/sleep 10
Danke euch! Habe eure Anpassungen im obigen Code berücksichtigt…
Viele Grüße
Jörg
Was ist denn das für ein 6-fach Taster mit Display der in Loxone einbeunden zu sein scheint? Suche sowas auch schon länger.
Das ist der MDT BE-GT2TW.01 (Affiliate-Link) mit KNX-Schnittstelle, den ich auch schon vor über sieben Jahre im Blogpost Operation Smart Home – 3 Leitungskilometer und gefühlt 1.000 Arbeitsstunden später… vorgestellt hatte.
Bin nach wie vor 100%ig zufrieden damit. Habe in Summe 12 davon im Haus verbaut und noch einen im Schuppen – bisher noch kein einziger Ausfall. Und mehr Wandschalter gibt es bei uns nicht…
Viele Grüße
Jörg
Hallo Jörg,
da hast du mich wieder getriggert mit dem Thema Apple Home Key.
Großes Lob für die Anleitung – funktioniert echt super auf Anhieb. Ich bin mir nur noch unsicher ob mir das Sicherheitstechnisch reicht. Denn ich hab zwar ein Motorschloss, aber eben nicht so einen Motor an der Haustüre. Ich werde es glaube ich erst mal am Garagentor testen.
By the way, kann ich auch zwei Reader an des Raspi anschließen? Dann einfach 2 Sektionen in der Konfig reinpacken?
Viele Grüße
Markus
Hallo, tolle Lösung. Habe es getestet und es funktioniert wunderbar. Bei mir ist in meinem Haus ein Klingeldraht verbaut der recht lang ist. Gibt es wohl eine Lösung diesen zu nutzen. Für USB ist es deutlich zu lang. Habe es schon versucht. Vielleicht hat ja jemand eine Idee!
Danke
Stefan
Hallo Jörg,
Ich habe das nun schon eine Weile auf meinem Schreibtisch liegen und schalte zum Test damit das Licht an und aus …
Allerdings klemmt es manchmal, dann braucht man mehrere Versuche, ehe es klappt. Mir scheint es mit der Watch öfter zu passieren – mit dem Phone klappt es besser.
Hast Du das auch? Ich stelle mir das recht nervig vor, wenn man vor der Tür steht und das Teil dann rumzickt …
Erst dachte ich, das liegt am PiZero – aber auch mit einem Pi5 tritt das auf, es ist also keine Frage der Power.
Gruß,
Rudi
Liegt wohl am billigen PN532-Clone… Habe ich auch hin und wieder und habe deshalb beschlossen den “Original” zu holen. Siehe den nachfolgenden Kommentar von Joe…
Hallo Jörg,
ich habe das Projekt durch deine Idee aber mit dem ESP32 umgesetzt.
https://github.com/rednblkx/HomeKey-ESP32
Ich hatte erst einen China PN532, mit dem ich jedoch nur eine sehr geringe Reichweite hatte. Wir haben eine Holztür und mit dem Chip hinter dem Holzrahmen hatte ich keinen Empfang mehr. So etwas ähnliches hast du ja in deinem Video auch dokumentiert.
Ich habe mir jetzt das Original von Elechouse bestellt (V4).
Damit habe ich eine deutliche Verbesserung der Reichweite und komme problemlos durch den Holzrahmen.
Der original PN532 ist zwar wesentlich teurer, aber funktioniert auch deutlich besser.
Wo genau hast du den “Elechouse PN532 NFC V4” bestellt? Direkt bei www.elechouse.com? -> PN532 NFC RFID MODULE V4 (externer Link)
Viele Grüße
Jörg
PS: Mein Billig-Clone erkennt gefühlt alle 50 Mal mein iPhone nicht korrekt. Dann muss ich nochmal kurz Abstand nehmen und erneut ranhalten. Vermute, dass dieses “Problem” mit dem Original-PN532 weg sein wird, weshalb ich den auch mal testen will..
“Thank you for your order” 😀
Konnte nicht warten und hab das Teil auch nirgendwo anders als “Original” gefunden. 2 Stück “PN532 NFC RFID module V4” habe ich nun inkl. Versand nach Deutschland für 58,80 USD bestellt. Hoffe der Versand dauert nicht zu lange – von woher auch immer. Konnte auf der Seite spontan kein Impressum finden…
Hallo Jörg,
ich habe tatsächlich vom Hersteller direkt bestellt. Aber wenn es leider sehr teuer war (auch der Versand).
In D habe ich die original Platine nirgends gefunden.
Also ich habe mit den von dir verlinkten Aidpeen Modulen überhaupt keine Probleme. Die Reichweite mag zwar vielleicht nicht ans original rankommen, reicht aber für meine Zwecke. Hinter einer Siedle Blindabdeckung montiert habe ich trotzdem bei 2 cm noch gute Erkennung. Ich nutze allerdings auch einen ESP32 mit dem Code von rednblkx.
Danke für dein Feedback! Habe vorhin noch bissl mit den “Clones” rumgespielt. Zumindest bei mir haben die untereinander schon größere Unterschiede, was die Reichweite angeht. Der Beste funktioniert bereits bei gefühlt 5cm Entfernung, der Schlechteste erst so ab 2-3cm. Also entweder gleich einen Dreierpack der Billigen kaufen und rumprobieren, welcher am besten funktioniert oder aufs Original setzen. 😀
Hab jetzt ja mal 2 Originale bestellt – bin echt gespannt, wie die sich im direkten Vergleich schlagen. Für die 2 Originale hätte ich vermutlich mehrere Dutzend Nachbauten bekommen… :DDD
So oder so feiere ich die HomeKey-Zutrittslösung einfach jeden Tag, wenn ich Zuhause ankomme. Denke ich werde direkt auch noch einen Reader für den Schuppen nachrüsten, denn dort habe ich elektrische Rolltore verbaut, die nur noch auf einen weiteren externen “Trigger” von Homekey warten…
Bin gespannt auf deinen Erfahrungsbericht mit den originalen Modulen. falls die wirklich so viel besser sind, bestelle ich mir halt auch noch welche .. 😛
Ich feiere die Dinger trotzdem auch, hab” mittlerweile auch 3 Stück im Einsatz. Haustür, Schopf, Schlupftür Garage.
Einfach mega…
Hallo Jörg,
vorab: großes Danke für die Anleitung.
Bei mir klappt die Kommunikation zwischen iPhone und NFC nicht. Den I/O Fehler (letzte Zeile) bekomme ich nicht gedeutet. Irgendeine Idee?
(my_venv) pi@raspberrypi4:~/apple-home-key-reader $ sudo service homekey status
● homekey.service – Apple Home Key Reader
Loaded: loaded (/etc/systemd/system/homekey.service; enabled; preset: enabled)
Active: active (running) since Tue 2024-04-23 19:18:39 CEST; 2min 22s ago
Process: 24114 ExecStartPre=/bin/sleep 10 (code=exited, status=0/SUCCESS)
Main PID: 24120 (python)
Tasks: 2 (limit: 1593)
CPU: 3.173s
CGroup: /system.slice/homekey.service
└─24120 /home/pi/apple-home-key-reader/my_venv/bin/python main.py
Apr 23 19:21:00 raspberrypi4 python[24120]: ^^^^^^^^^^^^^^^^^^^^
Apr 23 19:21:00 raspberrypi4 python[24120]: File “/home/pi/apple-home-key-reader/my_venv/lib/python3.11/site-packages/nfc/clf/device.py”, line 100, in connect
Apr 23 19:21:00 raspberrypi4 python[24120]: found = transport.TTY.find(path)
Apr 23 19:21:00 raspberrypi4 python[24120]: ^^^^^^^^^^^^^^^^^^^^^^^^
Apr 23 19:21:00 raspberrypi4 python[24120]: File “/home/pi/apple-home-key-reader/my_venv/lib/python3.11/site-packages/nfc/clf/transport.py”, line 103, in find
Apr 23 19:21:00 raspberrypi4 python[24120]: raise error
Apr 23 19:21:00 raspberrypi4 python[24120]: File “/home/pi/apple-home-key-reader/my_venv/lib/python3.11/site-packages/nfc/clf/transport.py”, line 96, in find
Apr 23 19:21:00 raspberrypi4 python[24120]: termios.tcgetattr(open(‘/dev/%s’ % tty))
Apr 23 19:21:00 raspberrypi4 python[24120]: ^^^^^^^^^^^^^^^^^^^^^
Apr 23 19:21:00 raspberrypi4 python[24120]: OSError: [Errno 5] Input/output error: ‘/dev/ttyUSB0’
Hi Christian,
immer gerne! 😘
“Input/output error: ‘/dev/ttyUSB0’” -> denke dein Reader wird vom System anders eingebunden.
Gib doch mal folgenden Befehl in die Konsole ein:
ls -la /dev/serial/by-id/
Evtl. siehst du dann, unter welcher ID dein Adapter erkannt wird. Und dann entsprechend die Config-Datei anpassen…
Viele Grüße und Erfolg
Jörg
usb-Silicon_Labs_CP2104_USB_to_UART_Bridge_Controller_02IDSMBJ-if00-port0 -> ../../ttyUSB0 => stimmt schon bzw passt mit dem Eintrag im json zusammen.
Die Bezüge in den beiden py Dateien lassen etwas in Richtung Treiber vermuten. Kann aber nicht sein, da im erneuten Test gerade die Kommunikation funktioniert (nach Neustart des services). Ich schaue da in den nächsten Tagen nochmals drauf.