|
Überblick, welche Funk-Module RFNETHM trägt und in welchen Bauformen das Ganze läuft. Stand: v0.15.0.
Funk-Module (eine Variante anschließen)
| Modul |
Anschluss |
Versorgung |
Hinweis |
| HmIP-RFUSB (eq-3-Original) |
USB-Host |
5 V über USB |
unmodifizierter Stick, eq-3-Firmware bleibt drauf |
| RPI-RF-MOD |
40-Pin-Header |
5 V auf Pin 2/4 |
eigener On-Board-LDO, kein 3V3-Pfad — 3,3 V auf Pin 1 lässt das Modul stumm |
| HM-MOD-RPI-PCB |
40-Pin-Header |
3,3 V auf Pin 1 |
BidCoS-only ELV-Modul, keine LEDs/BTN am Header |
Der Funk-Teil bleibt immer der echte eq-3-Stack — RFNETHM ist reiner Transport.
Reset-Polarität (häufige Stolperfalle beim Eigenbau)
| Modul |
Reset-Pin (eQ3-Header) |
Polarität |
| HM-MOD-RPI-PCB |
Pin 12 |
active-LOW (0 = Reset, 1 = Run) |
| RPI-RF-MOD |
Pin 35 (alt-Reset) |
active-HIGH (1 = Reset, 0 = Run) |
Keine externen Pull-Ups auf der RST-Linie — der MCU muss aktiv treiben. Volle Pin-Tabelle: docs/breadboard_wiring.md.
Bauformen
1. Devkit-Bringup (Stand heute, verifiziert):
ESP32-S3-Devkit mit nativem USB-OTG-PHY (z. B. YD-ESP32-S3 V1.4) + Pin-Header für den HM-Slot, auf dem Breadboard verkabelt. Beide HM-Modul-Familien und der USB-Stick laufen darauf live.
2. Eigenes PCB (in Planung):
ESP32-S3-MINI-1-N8 + W5500 (kabelgebundenes Ethernet) + USB-A-Buchse für den HmIP-RFUSB + 40-Pin-HM-Slot. Die GPIO-Auswahl im Devkit-Stadium ist schon so getroffen, dass die Firmware-Pin-Defines beim PCB-Übergang nicht geändert werden müssen. Hintergrund: docs/ethernet_addition.md.
3. Variante B — Klon-Brücke (separate Bauform, ohne ESP32):
CP2102N mit OTP-Brand 1B1F:C020, die sich gegenüber dem Host als HmIP-RFUSB ausgibt. Eigenständiger Pfad, nicht Teil der ESP32-Netzwerk-Adapter-Linie — und kein Umgehen der ECDSA-Sperre des Original-USB-Pfads.
Strom
5 V / ~200 mA reichen fürs Devkit + Modul. Wer RPI-RF-MOD nutzt, muss zusätzlich 5 V auf den HM-Header (Pin 2/4) durchziehen.
Zeig her, was Du gebaut hast — gerne mit Foto. Fragen zur Verkabelung unter Q&A.
|