Ein Adapter, der einen unmodifizierten HmIP-RFUSB-Stick (oder ein RPI-RF-MOD / HM-MOD-RPI-PCB am Pin-Header) ins Netzwerk hängt — statt ihn an einen lokalen USB-Port zu zwingen. Damit wird der Funk-Stick zu einem netzwerkweit erreichbaren BidCoS-/HmIP-Frontend für FHEM, Homegear, piVCCU oder RaspberryMatic — ohne dass eine echte CCU oder ein Pi am Funk-Standort stehen muss.
Status: Firmware v0.14.90 (2026-05-11), Devkit-Bringup abgeschlossen, alle vier Kreuze der Ground-Truth-Matrix (HB-RF-ETH × {HM-MOD, RPI-RF-MOD} und RFNETHM × {HM-MOD, RPI-RF-MOD}) live ge-flasht. Eigenes PCB ist in Planung.
HmIP-RFUSB RFNETHM dein Server
(eq-3 Original) (ESP32 + WLAN/Eth) (FHEM, Homegear,
piVCCU, RaspberryMatic)
USB ───────────► USB-Host
│
└─── WLAN/Ethernet ───► hb_rf_eth.ko
/dev/raw-uart
oder TCP-Socket
Alternativ statt USB-Stick: RPI-RF-MOD oder HM-MOD-RPI-PCB direkt auf den 40-Pin-Header — selber Adapter, gleicher Server-Pfad.
- Funkstandort frei wählbar. Stick steht da, wo der Empfang gut ist (Estrich, Garage, Pegel-Sweet-Spot); die Hausautomation läuft woanders.
- Drop-in für alle gängigen Stacks. Aus Sicht des Servers ist es
ein normales
hb_rf_eth-Gerät (Alex Reinerts Kernel-Modul) oder eine HM-MOD-RPI-PCB-Bridge (TCP/2330). Beide Wege gleichzeitig nutzbar. - Kein zusätzlicher Pi nötig. Wer bisher einen Pi nur als Funkträger nutzt, kann ihn ersetzen.
- Kein Custom-RF-Stack. Der Funk-Teil bleibt der echte eq-3-Stick mit eq-3-Firmware — alle BidCoS-/HmIP-Eigenheiten, AES, Pegelhandling sind genauso wie im Original.
| Port | Format | Was redet damit |
|---|---|---|
| UDP 3008 | HB-RF-ETH wire-format | hb_rf_eth.ko → /dev/raw-uart für piVCCU / RaspberryMatic |
| TCP 2330 | HMUARTLGW | FHEM CUL_HM, Homegear, jeder Stack der eine HM-MOD-RPI-PCB-Bridge erwartet |
| TCP 2329 | Raw-Bytestream | bmcond, eigene Tools, Reverse-Engineering |
| HTTP 80 | WebUI + REST | Status, OTA-Update, WLAN-Setup, Live-Log |
| mDNS | _raw-uart._udp:3008 |
Auto-Discovery (rfnethm-XXXX.local) |
Eingehende Funk-Frames werden gleichzeitig an alle verbundenen Clients gespiegelt. Senden ist mit einem TX-Master-Soft-Lock gegen Mehrfach-Schreiber abgesichert (erster Sender bekommt den Stick für 5 s, danach übernimmt der nächste; per WebUI festpinnbar).
- Funk-Hardware (eine Variante):
- HmIP-RFUSB-Stick (eq-3 Original, USB
1B1F:C020), oder - RPI-RF-MOD am 40-Pin-Header — braucht 5 V auf Header-Pin 2/4 (eigener on-board-LDO, kein 3V3-Pfad), oder
- HM-MOD-RPI-PCB am 40-Pin-Header — 3,3 V auf Pin 1 reicht
- HmIP-RFUSB-Stick (eq-3 Original, USB
- ESP32-S3-Devkit mit nativem USB-OTG-PHY (z.B. YD-ESP32-S3 V1.4)
und Pin-Header für den HM-Modul-Slot. Ein eigenes PCB (ESP32-S3-MINI-1
- W5500 + USB-A + HM-Slot) ist in Vorbereitung.
- 5 V / 200 mA Versorgung über die zweite USB-C-Buchse am Devkit.
Wer RPI-RF-MOD nutzt, muss zusätzlich 5 V auf den HM-Header (Pin 2/4)
durchziehen — siehe
docs/breadboard_wiring.md. - WLAN im Lab — Ethernet kommt mit dem eigenen PCB-Spin.
-
Flashen. Zwei Wege — entweder Source-Build via PlatformIO, oder direkt eines der vorgebackenen Binaries (siehe Section Vorgebackene Binaries unten) per
esptool.# Source-Build: pio run -e rfnethm -t upload -
WLAN provisionieren. Zwei Wege:
- Improv-Serial: Browser → improv-wifi.com → ESP über die Console-USB-Buchse verbinden → Credentials eingeben.
- Captive-AP-Fallback: erscheint nach 30 s als WLAN
RFNetHM XXXX, Handy verbindet sich, jede HTTP-Anfrage landet im Setup-Formular.
-
Im WebUI (
http://rfnethm-XXXX.local) Status checken; alle Funk-Frames stehen sofort am Netzwerk-Port bereit. -
Server-Seite konfigurieren:
- piVCCU / RaspberryMatic:
hb_rf_eth.komit der IP des RFNETHM laden (Schritt-Screenshot weiter unten unter RaspberryMatic / OpenCCU einbinden). - FHEM:
define hmusb HMUARTLGW rfnethm-XXXX.local:2330.
- piVCCU / RaspberryMatic:
Wer nicht selbst bauen will, findet unter
binaries/ zwei fertige Builds des jeweils aktuellen
Public-Release:
rfnethm-vX.Y.Z-factory.bin— Komplett-Image (bootloader + partition-table + ota_data + Applikation). Erst-Flash für ein jungfräuliches oder anders belegtes ESP32-S3.rfnethm-vX.Y.Z-ota.bin— nur die Applikation (offset0x10000). Für OTA-Updates über die WebUI, oder als gezielter Re-Flash auf bereits provisioniertes Gerät.
# 1) Erst-Flash via USB (ESP32-S3 im Download-Mode — BOOT-Button halten,
# RESET kurz, BOOT loslassen). Port-Pfad gegebenenfalls anpassen.
esptool.py --chip esp32s3 --port /dev/ttyACM0 --baud 921600 \
write_flash 0x0 binaries/rfnethm-v0.14.111-factory.bin
# 2) OTA-Update via WebUI (empfohlen sobald das Gerät im Netz ist —
# kein Druck auf BOOT-Button nötig, keine USB-Verbindung):
curl -X POST --data-binary @binaries/rfnethm-v0.14.111-ota.bin \
http://rfnethm-XXXX.local/api/ota
# 3) Reiner Re-Flash der Anwendung über USB (ohne Partition-Tabelle
# anzufassen — z.B. wenn nur ein neuer Build aufgespielt werden soll):
esptool.py --chip esp32s3 --port /dev/ttyACM0 --baud 921600 \
write_flash 0x10000 binaries/rfnethm-v0.14.111-ota.binesptool.py liegt bei PlatformIO bei (~/.platformio/penv/bin/esptool.py)
oder kommt out-of-the-box aus pip install esptool. Auf macOS / Windows
ist der Port-Pfad entsprechend /dev/cu.usbmodem* bzw. COMx.
Die eingebaute Web-Oberfläche unter http://rfnethm-XXXX.local/ zeigt
Sources, Sinks und System-Status als Kachel-Dashboard — inklusive
Reset-Reason, Heap- und Stack-HWM-Indikator für den Dauerlauf-Betrieb,
TX-Master-Soft-Lock pro Sink, Live-Log, OTA-Update und WLAN-Provisioning.
Light- und Dark-Theme sind per Toggle in der Headbar umschaltbar, die
Wahl wird pro Browser persistiert; ohne explizite Wahl folgt das
Theme der OS-Präferenz (prefers-color-scheme).
In RaspberryMatic bzw. OpenCCU unter System-Optionen → Erweiterte
Einstellungen trägst Du die IP-Adresse (oder den mDNS-Namen
rfnethm-XXXX.local) des RFNETHM in das Feld
„IP-Adresse (HB-RF-ETH)" ein und bestätigst mit Änderungen
speichern. Danach lädt RaspberryMatic den hb_rf_eth.ko-Pfad neu
und der angeschlossene HmIP-RFUSB-Stick (oder das RPI-RF-MOD am
Pin-Header) erscheint als lokales /dev/raw-uart.
Verifiziert (live gegen reale Hardware):
- USB-Host-Init des HmIP-RFUSB-Stick, Mode-Switch BL → App
- Beide HM-Modul-Familien am Pin-Header (HM-MOD-RPI-PCB / Co_CPU und RPI-RF-MOD / DualCoPro), Auto-Erkennung beim Boot
- HMUARTLGW-Codec byte-genau gegen Live-Captures
hb_rf_eth.ko-Pfad bis zur Aktor-Toggle-Schaltung in RaspberryMatic- FHEM
CUL_HM/ HMUARTLGW-Bridge bis Phase D (TX, RX, AES-Key-Storage) - Coprocessor-Firmware-Flash von beiden Modul-Familien über bmcond via UDP-Transport (RPI-RF-MOD 4.4.22 ⇆ 4.2.14, HM-MOD 2.8.6 ⇆ 2.2.1)
- Multi-Client-Fanout, TX-Master-Lock, mDNS, Captive-AP-Fallback, OTA
Nicht fertig:
- AES-Authentifizierung in der Legacy-Bridge (Phase E — mehrtägig, kein Blocker für AES-aware Devices).
- Eigenes PCB (Schaltplan und Pin-Mapping stehen; siehe
docs/decisions.md).
- Kein Drop-in-Replacement für den HmIP-RFUSB am unmodifizierten
RaspberryMatic-Kernel-Treiber: der USB-Pfad ist via ECDSA gesperrt
(bewusste Design-Entscheidung von Alex Reinert, wird respektiert).
Variante B des Projekts (CP2102N mit OTP-Brand
1B1F:C020) ist eine separate Bauform und ohne ESP32. - Kein eigenes Wireformat. UDP/3008 mit HB-RF-ETH-Frames und TCP/2330 mit HMUARTLGW sind die Default-Sprachen.
- Keine BidCoS-/HmIP-Protokoll-Interpretation in der Stick-Firmware — reiner Transport, alle HM-Logik bleibt downstream.
- Ja, wenn Du HmIP-Funk in einer Linux-Hausautomation (FHEM, Homegear, piVCCU, RaspberryMatic) nutzt und Funk-Standort vom Server-Standort entkoppeln willst.
- Ja, wenn Du einen alten Pi loswerden willst der nur den HmIP-Stick / das RPI-RF-MOD trägt.
- Nein, wenn Du eine vollständige CCU-Funktionalität ohne Server-Stack willst — dafür ist RaspberryMatic die richtige Adresse, RFNETHM ist nur der Funk-Adapter.
- Nein, wenn Du Klassik-Homematic-Funk (BidCoS, AskSinPP) ohne HmIP brauchst — da ist ein CUL/COC der bessere Match.
docs/intro.md— ausführliche Einführungdocs/breadboard_wiring.md— Verkabelung am Devkitdocs/ethernet_addition.md— Ethernet- Anbindung für den PCB-Spindocs/diagrams/— Architektur- und Message-Flow-Diagramme
GPL-2.0-or-later (analog PIIF / CULFW32). Listener-Code ist eigene Reimplementierung gegen die HB-RF-ETH-Spec — kein Copy aus dem CC-BY-NC-SA-4.0-lizenzierten Original-Repo.
RFNETHM ist ein Lab-Projekt aus dem Tostmann-RF-Lab.