Files
Funksender-Tor/README.md
T
Dominic a5caf47b49 Empfänger auf reale Tor-Steuerung (esp32dev) umgestellt
- tor_empfaenger.yaml (ESP32-S3-Platzhalter) ersetzt durch tor_steuerung.yaml,
  das die bestehende ChatGPT-Konfig (Relais GPIO16, Türsensoren GPIO34/35,
  echte WLAN/API/OTA-Credentials) mit der CC1101-Empfangslogik zusammenführt
- CC1101 auf freie VSPI-Pins gelegt (GPIO4/5/18/19/23), da 16/34/35 belegt sind
- auto_sender_01.yaml verwendet dieselben Credentials wie der Empfänger
- README: Pintabelle für esp32dev, Hinweis auf Klartext-Secrets im Repo
2026-07-23 18:38:49 +00:00

234 lines
7.2 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# Funksender Tor
Automatische Toröffnung per 433 MHz. Jedes Fahrzeug bekommt einen kleinen Sender
am Zündungsplus, der Empfänger am Tor öffnet, sobald ein bekanntes Fahrzeug nah
genug ist. Kein Knopfdruck, keine App, kein Account.
**Hardware:** ESP32-C3 Super Mini + CC1101 (433 MHz) je Sender,
ein bestehender ESP32 DevKit (`tor-steuerung`) + CC1101 als Empfänger am Tor —
derselbe ESP, der schon Relais und Türsensoren steuert.
---
## Inhalt
- [Verdrahtung CC1101](#verdrahtung-cc1101)
- [Flashen](#flashen) — **hier steht der USB-TTL-Kram**
- [ESPHome einrichten](#esphome-einrichten)
- [Reichweite einstellen](#reichweite-einstellen)
- [Weiteres Fahrzeug hinzufügen](#weiteres-fahrzeug-hinzufügen)
- [Paketformat](#paketformat)
---
## Verdrahtung CC1101
Die Pins des CC1101 sitzen als **4 Zeilen à 2 Pins**, Antenne rechts:
```
① GND │ VDD ②
③ GDO0 │ CSN ④
⑤ SCK │ MOSI ⑥
⑦ MISO │ GDO2 ⑧
```
> **Achtung:** Pin 1 ist **GND**, Pin 2 ist **VDD**. Nicht die verbreitete
> Belegung mancher anderer CC1101-Boards annehmen, wo es umgekehrt ist —
> Vertauschen macht das Modul und ggf. den ESP heiß.
| CC1101 | Signal | ESP32-C3 Super Mini |
|--------|--------|---------------------|
| 1 | GND | `G` (links) |
| 2 | VDD | `3.3` (links) — **niemals 5V** |
| 3 | GDO0 | `GPIO3` (links) |
| 4 | CSN | `GPIO4` (links) |
| 5 | SCK | `GPIO6` (rechts) |
| 6 | MOSI | `GPIO7` (rechts) |
| 7 | MISO | `GPIO5` (rechts) |
| 8 | GDO2 | *frei lassen* |
Schema: [`doku/verdrahtung-cc1101.svg`](doku/verdrahtung-cc1101.svg)
(zeigt die Pin-Reihenfolge am CC1101 selbst — die Zuordnung zu GPIOs
unterscheidet sich je nach ESP-Board, siehe Tabellen oben/unten.)
### Empfänger (`tor-steuerung`, ESP32 DevKit)
GPIO16 (Relais) und GPIO34/35 (Türsensoren) sind schon belegt. Der CC1101
hängt deshalb an den freien VSPI-Standardpins:
| CC1101 | Signal | ESP32 DevKit |
|--------|--------|--------------|
| 1 | GND | GND |
| 2 | VDD | 3V3 |
| 3 | GDO0 | `GPIO4` |
| 4 | CSN | `GPIO5` |
| 5 | SCK | `GPIO18` |
| 6 | MOSI | `GPIO23` |
| 7 | MISO | `GPIO19` |
| 8 | GDO2 | *frei lassen* |
---
## Flashen
### Warum nicht über den USB-C-Anschluss?
Der ESP32-C3 hat einen eingebauten USB-Serial/JTAG-Controller. Unter Windows 11
sollte er automatisch als COM-Port erscheinen — **tut er aber nicht mehr, sobald
Zadig einmal auf ihm gelaufen ist.**
Was passiert war: Zadig ersetzt den nativen `usbser.sys` durch WinUSB bzw.
selbstgenerierte libwdi/libusbK-Treiber. Danach zeigt der Geräte-Manager zwar
einen COM-Port, aber esptool bekommt nur
```
A fatal error occurred: Failed to connect to ESP32-C3: No serial data received.
```
Das lässt sich reparieren (siehe unten), ist aber fummelig. **Der USB-TTL-Adapter
umgeht das Thema komplett.**
### USB-TTL-Adapter anschließen ← *das ist der Weg, der funktioniert hat*
> **Adapter zwingend auf 3.3 V jumpern.** Der ESP32-C3 ist nicht 5V-tolerant.
| USB-TTL-Adapter | ESP32-C3 Super Mini |
|-----------------|---------------------|
| TX | `GPIO20` (rechts, vorletzter Pin) |
| RX | `GPIO21` (rechts, letzter Pin) |
| GND | `G` (links, 2. Pin) |
| 3.3V | `3.3` (links, 3. Pin) |
TX und RX sind **gekreuzt** — das ist so richtig.
Das CC1101 kann angeschlossen bleiben, GPIO20/21 kollidieren mit nichts.
Liefert der Adapter auf 3.3 V zu wenig Strom, den ESP stattdessen über ein
USB-Netzteil an der USB-C-Buchse versorgen und vom Adapter nur TX, RX und GND
anschließen. **Nicht beide Quellen gleichzeitig.**
### Boot-Modus
**`GPIO9``G` brücken, danach erst Strom drauf.** Reihenfolge ist wichtig.
Nach dem Flashen die Brücke wieder entfernen.
### Ablauf
```bash
# 1. Verbindung prüfen — COM-Port des TTL-Adapters aus dem Geräte-Manager
python -m esptool --chip esp32c3 --port COM16 chip-id
```
Erwartete Ausgabe:
```
Chip type: ESP32-C3 AZ (QFN32) (revision v1.1)
Features: Wi-Fi, BT 5 (LE), Single Core, 160MHz, Embedded Flash 4MB (XMC)
MAC: 44:b1:76:18:cb:ec
```
```bash
# 2. Factory-Image flashen (nicht die normale .bin!)
python -m esptool --chip esp32c3 --port COM16 --baud 460800 \
write-flash 0x0 auto-sender-01.factory.bin
```
Bricht es bei 460800 ab, mit `--baud 115200` wiederholen.
Danach GPIO9-Brücke raus, Strom aus/an. Ab hier läuft alles über OTA —
der Adapter wird nicht mehr gebraucht.
`esptool` installieren falls nötig: `pip install esptool`
### Falls der interne USB doch mal repariert werden soll
Als Administrator:
```cmd
pnputil /enum-drivers | findstr /i "libwdi libusb"
pnputil /delete-driver oemXX.inf /uninstall /force
```
Alle gefundenen libwdi/libusbK-Pakete löschen, besonders das mit
`MS_COMP_USBSER` — das kapert systemweit jedes CDC-Gerät. Danach neu starten.
Windows zieht dann wieder `usbser.sys`.
**Zadig nicht mehr auf den ESP32-C3 loslassen.** Für den eingebauten
USB-Serial/JTAG ist es das falsche Werkzeug (außer man will JTAG-Debugging
über OpenOCD).
---
## ESPHome einrichten
Beide Geräte tragen WLAN-Zugangsdaten, `api`-Verschlüsselungskey und
OTA-Passwort **direkt in der YAML** statt über `secrets.yaml` — so war
`tor_steuerung.yaml` schon angelegt, und `auto_sender_01.yaml` verwendet
bewusst dieselben Werte, damit beide Geräte zusammenpassen.
> **Achtung:** Damit stehen WLAN-Passwort und Schlüssel im Klartext in diesem
> Repo. Nur vertretbar, wenn `git.dominicspringer.de` privat/intern bleibt.
> Soll das Repo öffentlich werden, vorher alles auf `!secret`-Verweise
> umstellen und eine lokale `secrets.yaml` (nicht committen) anlegen.
1. In ESPHome (HA-Add-on) das jeweilige Gerät anlegen bzw. die bestehende
`tor-steuerung` mit dem neuen Inhalt überschreiben
2. Inhalt der passenden Datei aus `esphome/` einfügen
3. Drei Punkte → **Install****Manual download****Factory format**
4. Mit esptool flashen (siehe oben)
`reboot_timeout: 0s` beim Sender ist kein Versehen: im Auto ist kein WLAN in
Reichweite, ohne diese Zeile startet der ESP alle 15 Minuten neu.
---
## Reichweite einstellen
Die Reichweite wird **nicht** am Sender begrenzt — alle Sender laufen mit voller
Leistung. Der Empfänger entscheidet anhand der Signalstärke (RSSI), ob das
Fahrzeug nah genug ist.
Der Schwellwert liegt als Schieberegler **„RSSI Schwelle"** in Home Assistant,
Änderungen brauchen kein Neuflashen.
Einmessen:
1. Empfänger-Log in ESPHome öffnen
2. Mit dem Fahrzeug in verschiedenen Abständen anhalten
3. RSSI-Werte notieren — z. B. `Fahrzeug 1, RSSI -73.5 dBm, LQI 12`
4. Den Wert bei der gewünschten Distanz (~5 m) als Schwelle setzen
Je näher der Wert an 0, desto kürzer die Reichweite. Startwert ist `-60`.
Nach jeder Öffnung greift eine **Sperrzeit von 60 Sekunden**.
---
## Weiteres Fahrzeug hinzufügen
In `auto_sender_01.yaml` nur die beiden Substitutions oben ändern:
```yaml
substitutions:
geraet: auto-sender-02
fahrzeug_id: "0x02"
```
Der Empfänger akzeptiert IDs `0x01` bis `0x0A` (110) und muss dafür **nicht**
angefasst werden. Sollen weniger Fahrzeuge erlaubt sein, im `on_packet`-Lambda
die Zeile `if (fz < 1 || fz > 10)` anpassen.
---
## Paketformat
4 Bytes, GFSK, 4800 Baud, CRC-16 aktiv, Sync `0xD391`:
| Byte | Inhalt |
|------|--------|
| 0 | `0xA7` Magic |
| 1 | `0x3C` Magic |
| 2 | Fahrzeug-ID (`0x01``0x0A`) |
| 3 | reserviert (`0x00`) |
Der Sender schickt das Paket alle 2 Sekunden, solange die Zündung an ist.